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

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

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

Ещё один инструмент для анализа записей об интернет ресурсах irrexplorer.nlnog.net и примеры его использования.

Свежий срез на тему: "Сколько инструкций процессора используется в программах" - на этот раз в sqlite3, в разных вариантах компиляции. Сравнивать можно с этим.

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

Типичная ситуация и иллюстрация к картинке выше, в которой со слов интегратора они молодцы, а провайдер и клиент ничего не могут. Расскажу как подобная история выглядит со стороны провайдера, хотя сейчас я работаю со стороны "большого" клиента.

Не всегда, но очень часто когда подключается какой-то "большой" клиент с офисом в Москве, то сотрудники в его филиалах не обладают никакой компетенцией и возможностью принимать хоть какие-то решения. Даже если в местном штате есть IT в каком-то виде, то любое действие через согласование в Москве, доступов никаких и никуда, максимум что могут шнурок переткнуть. И когда ты проходишь этот уровень и выходишь на специалиста из головного офиса, то часто первая реакция - у нас так работает в 100500 местах мы ничего менять не будем, ваши схемы нам не интересны, нужен белый IP на интерфейсе, оптика мультимод, RIP и ещё куча других условий на выбор, чтобы было как везде, мы ваш клиент делайте как хотите.

У провайдера, к слову, тоже есть типовые схемы, которые работают для гораздо большего количества абонентов, чем филиалов у вновь подключаемого "большого" клиента, и с гораздо более разнообразным зоопарком оборудования. С той стороны не ожидают, вот вообще, услышать квалифицированного ответа, т.е. никакой речи о том чтобы договориться не идёт, но в конечном счёте когда этот квалифицированный ответ получают то становится проще и если повезёт начинается общение профессионалов. Да, и часто после этого получается даже посмотреть, а иногда и настроить оборудование клиента как лучше, а не как надо. Показать в ответ свой конфиг тоже не проблема, собственно мы видим это из статьи.

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

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

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

Исторический экскурс про разницу между клавишами Enter и Return. Про MAC не знаю, на PC клавиатура, как физическое устройство генерирует SCAN коды клавиш. Это идентифицирует каждую клавишу самостоятельно и позволяет обрабатывать любые их сочетания хоть два Enter, три и четыре клавиши одновременно в том числе. У этих кодов нет никаких осмысленных действий пока их не обработает драйвер и даже дальше, превращаясь в ASCII или другой код, дело за программой как его интерпретировать. Понятно, что в какой-то момент произошла логическая трансформация от "Возврата каретки" к "Подтверждению ввода", вероятно из-за желания не плодить новых клавиш, хотя этот период в развитии клавиатур тоже присутствует, но в статье этот момент показан очень слабо, впрочем, рекомендую сходить по ссылкам, там гораздо интереснее.

История развития протоколов автоконфигурации сетевого стека начиная с ARP. В блоге APNIC уже обобщение и дополнение оригинального письма John Gilmore живого свидетеля процесса.

Управление трафиком в BGP в 7 частях (2, 3, 4, 5, 6, 7). Рассуждения от Russ White - как передать трафик через определённую точку, как принять трафик через определённую точку, и как не дать другой AS передавать ваш трафик.

Ещё в копилку Reno vs. Cubic vs. BBR на этот раз для Старлинка в Австралии, в сравнении с геостационарным доступом и оптикой - BBR победил везде.

Посмотрите какая у RETN вещица есть - rtt.retn.net, показывает задержки из конца в конец по своей сети и замечательно дополняет вот этот инструмент с картой магистралей. Самые внимательные могут поискать разницу между магистральной сетью и маршрутами в ней.

Я очень сильно удивился когда на 3 курсе университета в начале 2000-х в рамках изучения ассемблера мы стали изучать CP/M, правда не долго. Потом, даже получилось написать свой симулятор 8080 и несколькими периферийными устройствами с потактовым исполнением и возможностью вмешиваться в это исполнение на каждом такте и компилятор ассемблера впридачу, который в итоге превратился в симулятор КР580ВМ80А перед аттестацией ).

Для «на попробовать» больше чем хватало, но реальный софт с той же CP/M конечно запускать было бесполезно, на выходе можно было увидеть только состояния регистров и количество отработанных тактов. По ссылкам в статье есть рабочий эмулятор со всем чем нужно, ну и для всех желающих CP/M, кому важна лицензионная чистота, теперь доступна без ограничений.

Исходные тексты операционной системы CP/M доступны для свободного использования https://opennet.ru/57497/

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

Учимся на чужих ошибках, читаем хронологию событий и гадания по BGP и Netflow о том что происходило с большим канадским провайдером Rogers на протяжении 15 часов аварии. Cloudflare, даже, вели прямой эфир. Объяснения самого оператора пока сводятся к тому что мы делали работы, а потом всё сломалось и обещаниям найти причины и всё улучшить. А пока можно делать ставки что это было, редистрибьюция BGP в OSPF или с автоматизацией переборщили.

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

Где-то с 2013 года по 2018 я очень внимательно следил за состоянием нескольких сетей в моём городе, точнее пытался следить за всеми, отлавливал изменения маршрутов, изменение записей в RIR и пользовался для этого сервисами RIPE NCC через whois.ripe.net и riswhois.ripe.net, вот так:

whois -h riswhois.ripe.net -- "-F 8.8.8.8/32"
% Connected to backend ris-whois08.ripe.net
3356  8.0.0.0/9
3356  8.0.0.0/12
15169  8.8.8.0/24

Сразу видим все анонсы включая менее специфичные которые покрывают заданный. Так вот, увидеть 2000::/3 или /8 покрывающие твои сети было совсем не редкостью, наверное это не редкость и сейчас. (У меня остались архивы, но поиска к ним нет, а быстро настоящие примеры найти не получилось). В норме трафик идёт по более специфичному маршруту, но вот если он пропадёт то тут уж не обессудьте, получатель вашего трафика будет другой.

13 утверждений (часть два, три и четыре) про последние дни нашего мира Интернета. Это не предсказания, а описание окружающей действительности с конкретными ссылками. Самое важное утверждение - первое, которое раскрывается в нескольких последующих, а дальше всё следствия. Потеряв возможность, отказавшись от неё, лично заботится о своих системах и своих пользователях, в конечном итоге, мы потеряли всё остальное. Можно прочитать сразу целиком, или в первоисточнике.