Замечательное обсуждение issue gpsd - не поленитесь вникните в суть проблемы, поищите незнакомые понятия, походите по ссылкам в Wikipedia (этого более чем достаточно) и дело, конечно, не в глобальном потеплении, хотя случись так, что Земля закрутилась бы чуть быстрее, то проблемы бы в этом году не было бы.
Вот этот кусок кода в итоге был удалён:

if (0 < session->context->leap_seconds &&
19 > session->context->leap_seconds &&
2180 < week) {
/* assume leap second = 19 by 31 Dec 2022
* so week > 2180 is way in the future, do not allow it */
week -= 1024;
...

В GPS есть недели, которые хранятся в 10 битах - эпоха GPS - всего около 20 лет на эпоху и счётчик несколько раз уже был обнулён. Почему не увеличить разрядность, вероятно потому что со спутниками это плохо получается да и миллионы всяких устройств не очень это переживут. Естественно этот момент учитываются в программах вроде gpsd и там применяются числа большей разрядности и в коде мы видим, что недели сравниваются с 2180, как датой в далёком будущем.
Ещё есть дополнительные секунды, чтобы мы слишком сильно не выбивались из естественного земного суточного цикла. Так вот, дополнительных секунд сейчас 18 по меркам GPS, 2180 недель это 23 октября 2021, автор считал что 31 декабря 2022. Таким образом добавление новой секунды после этой даты привело бы к незапланированному откату, ещё до истечения текущей GPS эпохи. Секунду, кстати, могут и отнять, что может произойти ближайшее время.

Хорошо, наверное, быть автором популярного не коммерческого opensource проекта. Прекрасный пример для всего на свете, о том как хрупок наш мир, во всех отношениях.

Есть повод почитать про Evil Bit.

ICANN обновила 11 принципов управления корневой системой доменных серверов. Полностью документ в PDF.

Про glue records на примере google.com - что, зачем и почему с запросами dig.

Системы контроля и ограничения могут являться и являются инструментами для DDoS атак разных типов умножения TCP трафика, ввиду того что принимают решение раньше чем закончится рукопожатие TCP или вовсе не принимая его в расчёт и таким образом обходить его ограничения. Включая, в том числе, и национальные системы блокировок, что усугубляет ситуацию массовостью и обязательностью внедрения. В полной версии подробнее и есть немного про Россию.

З.Ы. Наверное, из этого может получиться способ, в принципе, объективно определять использование системы блокировок на участке сети и возможно, даже, его тип.

Сети - сложные штуки и всегда будут оставаться сложными, хотя бы потому что мир сложен. А ещё потому что они проектируются людьми которые не сразу понимают что к чему, а потом сложностью затыкают те дыры которые уже спроектировали. И поэтому, кстати, все новые штуки призванные уменьшить сложность её только увеличивают.

https://habr.com/ru/company/yandex/blog/126709
И даже сейчас такое может случиться.

Ну, с днём редистрибуции, парни! За OSPF не чокаясь.

Haiku OS 20 лет, если не отмечали 18 августа то ещё не поздно. Напоминания про те времена, когда деревья были большими.

Ядру Linux исполнилось 30 лет https://opennet.ru/55678/

На Хабр хорошо известные всем работникам провайдеров факты про оптические трансиверы. Они есть хорошие и плохие, основная разница как правило, в том как разные устройства с ними работают, и не обязательно это выражается в том что не удаётся определить модуль, бывают совершенно странные и непредсказуемые заскоки.
Перегрев плохо, но обычно достаточно остудить и всё нормализуется. Выходят из строя, из моей практики, редко и даже очень редко. Когда варят оптику - лучше выключить, но чтобы прямо сгорали не встречал, хотя в err-disabled порт уходил. Из моего опыта, даже если вставить 80км друг напротив друга в 1-2 метрах, то скорее всего будет работать 1-3dBm прожуётся на приёме.
Прошивать можно, но лучше купить те которые понимаются вашими устройствами, не обязательно это будут родные. Cisco в статье упомянули лишь однажды и правильно, цена на Cisco модули запредельная в 10-20 раз больше чем аналоги, и разницы - никакой. Просто не забываем мантру:

service unsupported-transceiver
no errdisable detect cause gbic-invalid

И даже для серверов такое есть, правда не для всех.

Интересно, но за большую часть своей сетевой карьеры мне, по-большому счёту, не приходилось сталкиваться с отладкой работы именно приложений. А понял я это когда покинул стройные, но не многочисленные ряды альтернативных интернет провайдеров и влился в мир большого, конечно кровавого, энтерпрайза. И это, как говорится, совсем другая разница, когда твоей конечной или если хотите начальной точкой является конкретное приложение на конкретном месте, а никак не порт на коммутаторе.

Теперь мои сети это NAT, netflow, NBAR, QoS, ACL, VPN и NGFW и относительно простая, по моим меркам, маршрутизация, то что я привык считать за настоящую сетевую задачу. Ощущение такое что пересел с потрёпанного, но крепкого muscle car, даже скорее с какой-то из машин Безумного Макса где педаль газа всегда выжата на максимум, и съехал со сто полосного и почти пустого шоссе в центр, забитого под завязку, гигантского города где вынужден пробиваться по узким улочкам не более 20км/ч на длиннющем лимузине.

Я очень рад что история с ТСПУ обошла меня стороной, нет конечно, это про всех про нас, но непосредственно пощупать его руками загнав гвоздь в собственную сеть мне не пришлось. Я рад что наконец нашёл применение всему тому, что удалось почерпнуть из учебников и курсов, Cisco в том числе, где большая часть это всё же энтерпрайз, не зря свою сертификацию они переименовали. Я рад что cмог принести немного большого Интернета с собой, там где RIRы, RPKI, мультихоминг и IXы, и сделать ещё одну его часть лучше.

Необычно теперь смотреть на работу провайдеров со стороны клиента, это более чем полезный опыт, но его надо приобретать работая в провайдерах, чтобы сделать их лучше, надеюсь что никого не будут раздражать в этом новом взаимодействии находясь с другой стороны баррикад. Коллегам большой привет, в провайдерах по-прежнему лучшие сетевики, просто будьте более доброжелательны и снисходительны к своим клиентам.

Что ещё осталось попробовать - Tier-1, IX, вендора, интегратора, ЦОД, облака, bigtech, стартап, если ничего нового не придумают.

Контроль доступа на основе ролей (RBAC) что об этом думают в Tailscale, но про их реализацию в самом конце. В основном это сравнение и описание принципов построения различных концепций контроля доступа, их реализация в существующих решениях, шаг за шагом приближаясь к описываемой системе. Хорошая и длинная статья по теме, если никогда не интересовались этим раньше.

RSA/SHA1 теперь будет отключен по умолчанию в OpenSSH для генерации сигнатур, возможность включить обратно останется. Ключи это не затронет.

За кулисами индийского Интернет провайдера не самая радужная картина. С нашими реалиями не сравнить, у нас много лучше, хотя аналогии можно попытаться поискать.

Вы же не забываете включать IPv6 в Docker?

Мой друг подкинул мне ссылку про проклятое современное ПО - sad but true, такова реальность. Надо было слушать товарища Столлмана, а не считать его борцом с ветряными мельницами, так что во многом это то что мы сами и построили. А 20-25 лет назад можно было посмеиваться над загнивающим западом качая варез с BBS и покупать пиратские диски со 100500 программами на все случаи жизни, и не иметь ни одной не сломанной, включая WinRAR. А теперь, теперь мы сами себе не принадлежим. Пойду, наверное, пересмотрю Revolution OS, для вдохновения.

Когда-нибудь BGP таки разжалуют из протоколов маршрутизации, а пока читаем новый RFC9107 призванный улучшить RR за счёт знаний внутренних метрик IGP.

RFC9109 где NTP теперь будет использовать разные порты если работает в режиме клиента, а не только 123. И это реально большая проблема, потому что NTP - везде, каждая безделушка держит у себя клиента, упустим тот факт что не всегда корректно настроенного, что позволяет его использовать как очень удобный амплификатор для DDoS. Поэтому, основываясь, как раз на том факте что NTP это src udp 123 можно красиво загнать весь такой трафик в небольшой PAT, не рандомизировав, но хотя бы перемешав порты. Теперь, в ближайшем времени, сами клиенты так смогут и это хорошо.

А ещё один RFC791 вчера скромно отметил свой юбилей. Несмотря на возраст используется всеми и на покой не собирается, хотя вроде и преемник есть.

Если не видели Eltex CLI изнутри, что называется сравните с Cisco. Но на самом деле все видимые отличия лежат как раз в настройках маршрутизации в статье не затронутой. Есть отдельная от interface vlan сущность interface ip, где, например, настройка OSPF cost для 15 вилана из статьи выглядит вот так:

interface ip 192.168.2.21
ip ospf cost 10

Однако, та же настройка в OSPFv3 будет уже внутри interface vlan:

interface vlan 15
ipv6 ospf cost 10

Всё согласно документации. На других модельках формат команд может немного отличаться, так что обращайте на это внимание.

К ACL тоже придётся привыкать, показанный в статье management ACL отличается от того который используется для пакетного фильтра. Вот правило для пропуска любых TCP ACK из 10.0.0.0/8:

permit tcp 10.0.0.0 0.255.255.255 any any any match-all +ack ace-priority 10

Указание source и destination портов наравне с подсетями обязательно, в данном примере - any. Порядковый номер правила ace-priority находится в конце строки.

Есть, конечно, и другие мелочи, но в целом пользоваться можно. В своё время они оставили мне очень положительные впечатления.