Проект Pico-100BASE-TX представляет собой впечатляющее программное решение для микроконтроллеров Raspberry Pi RP2040 и RP2350, позволяющее им работать как передатчики Fast Ethernet со скоростью 100 Мбит/с. Реализация использует технологию "bit-banging" - программную передачу данных без специализированного оборудования, что является значительным техническим достижением. Проект включает в себя UDP фреймер для обработки сетевых пакетов, что делает его практически полезным для реальных сетевых приложений.

Разработчикам удалось преодолеть ограничения микроконтроллеров, реализовав высокоскоростную Ethernet-связь исключительно программными средствами. Это демонстрирует потенциал современных микроконтроллеров для сложных сетевых задач, открывая возможности для создания сетевого оборудования на базе недорогих плат Raspberry Pi. Проект особенно интересен энтузиастам IoT и разработкам, требующих высокоскоростной сетевой связи в компактном и экономичном исполнении.

• Пользователи жалуются на сложность работы с JSONB в PostgreSQL, особенно при извлечении данных из вложенных структур, требующих сложных запросов.
• Критикуется недостаточная понятность документации PostgreSQL по функциям работы с JSON, что затрудняет освоение для новичков.
• Отмечается, что встроенные функции JSONB в PostgreSQL мощны, но их синтаксис может быть неинтуитивным для простых задач.

Опубликована подробная диаграмма стека сети Linux, созданная Hrvoje Horvat из Ericsson Nikola Tesla. Диаграмма охватывает все уровни сетевого стека: виртуализацию и контейнеры, сокеты, TCP/UDP и нижние уровни с GRO, RPS, RFS и GSO, планировщик сети, NetFilter, управление трафиком, драйверы устройств и функции, ускоренные сетевой картой. Каждый раздел содержит советы по оптимизации и статистику.

Диаграмма доступна в формате PDF (5.4 МБ) и является частью книги "Operativni sustavi i računalne mreže - Linux u primjeni". На момент публикации материал получил 515 просмотров и 380 загрузок. Работа распространяется под лицензией Creative Commons Attribution 4.0 International, что позволяет свободно использовать и распространять диаграмму при обязательном указании автора.

• Диаграмма показывает, как пакет проходит через iptables и Netfilter, что вызвало обсуждение о сложности и важности визуализации в Linux.
• Участники обсуждали, что такие диаграммы редко охватывают контейнеры и виртуализацию, и что отсутствие обновлений может сделать их устаревшими.
• Были вопросы о доступности этих диаграм на разных языках и о том, где можно найти больше информации о книге, из которой они были взяты.
• Также обсуждались вопросы о том, как эти диаграммы могут быть использованы в образовательных целях и о том, что делает их такими полезными для понимания сложных систем.
• В конце, обсуждалось, что такие диаграммы могут быть трудны для чтения в формате PDF и что было бы полезно иметь SVG версию.

HTTP/3 — это новая версия протокола HTTP, работающая поверх QUIC (Quick UDP Internet Connections) вместо традиционного TCP. Основное преимущество — решение проблемы "head of line blocking", когда потеря одного пакета блокирует всю передачу данных. HTTP/3 использует UDP, что позволяет параллельно обрабатывать пакеты без ожидания восстановления связи. Протокол включает встроенную безопасность с TLS 1.3 и поддерживает 0-RTT handshakes для снижения задержки при повторных подключениях.

Книга подробно разбирает эволюцию протокола: от HTTP/2 с его ограничениями TCP до современных возможностей QUIC. HTTP/3 сохраняет такие функции HTTP/2, как мультиплексирование запросов и приоритизацию, но с улучшенной производительностью. Особое внимание уделено техническим деталям: работа с потоками, сравнение с HTTP/2, а также критика и перспективы развития. Документ доступен на нескольких языках и представляет собой исчерпывающее руководство для разработчиков, интересующихся современными веб-протоколами.

• Обсуждение охватывает отсутствие обновлений документации HTTP/3, проблемы с потерей пакетов в HTTP/2, и то, что HTTP/3 уже поддерживается большинством браузеров и сайтов, но документация и инструменты отстают.
• Участники обсуждают, что HTTP/3 в основном использует UDP, что вызывает споры о безопасности и приватности, а также то, что TCP может быть выключен в будущем.
• Также обсуждается, что HTTP/3 уже активно используется, но не всегда очевидно, что это именно он, так как внешне это может быть незаметно.
• Участники также отмечают, что документация и инструменты для HTTP/3 развиты недостаточно, и что будущее HTTP/4 неясно.
• В конце обсуждение сдвигается к тому, что HTTP/3 уже здесь и сейчас, и мы должны начать его использовать и развивать экосистему вокруг него.

Firefox переписывает свой стек UDP для QUIC на Rust, чтобы использовать современные системные вызовы и повысить производительность. Около 20% HTTP-трафика браузера уже идёт через HTTP/3 поверх QUIC/UDP, а старый код на NSPR не поддерживает многопакетные операции вроде sendmmsg или аппаратное ускорение сегментации (GSO/GRO).

Новый движок построен на основе библиотеки quinn-udp и показывает впечатляющие результаты: в CPU-нагруженных сценариях пропускная способность выросла с менее 1 Гбит/с до 4 Гбит/с. Основная сложность заключалась в поддержке старых версий ОС, включая Android 5. Проект также усиливает безопасность благодаря использованию memory-safe языка и тесной интеграции с существующей Rust-реализацией QUIC во Firefox.

• Увеличение пропускной способности UDP до 4 Гбит/с и снижение нагрузки на CPU благодаря оптимизациям в библиотеке quinn-udp
• Критика скорости в 4 Гбит/с как недостаточной для высокоскоростных сетей и обсуждение ограничений системных вызовов и шифрования
• Вопросы о работе механизмов GSO/GRO для UDP и обработки пакетов, приходящих не по порядку
• Обсуждение поддержки проектов с открытым исходным кодом, в частности, вклад Mozilla в Quinn кодом, но не финансированием
• Дебаты о целесообразности использования самоподписанных сертификатов в HTTP/3 для LAN и соображения безопасности

TernFS — экзабайтная распределенная файловая система с поддержкой нескольких регионов

XTX — алгоритмическая торговая фирма, использующая статистические модели для прогнозирования цен. По мере роста вычислительных мощностей потребности в хранилищах также увеличивались. Изначально использовались NFS и коммерческие решения, но в итоге было принято решение разработать собственную файловую систему — TernFS.

TernFS теперь доступна как открытое ПО на GitHub. В статье объясняется её архитектура и ключевые детали реализации.

Зачем ещё одна файловая система?

Крупные tech-компании часто разрабатывают собственные распределенные файловые системы из-за их критической важности. XTX оказалась в аналогичной ситуации и создала TernFS как универсальное решение для хранения — от «холодных» данных до временных файлов для обмена между GPU-задачами.

Возможности TernFS:

• Масштабируемость до десятков экзабайт, триллионов файлов и миллионов одновременных клиентов.
• Избыточное хранение данных для защиты от сбоев дисков.
• Отсутствие единой точки отказа в службах метаданных.
• Поддержка снимков файлов для защиты от случайного удаления.
• Работа в нескольких регионах.
• Агностичность к оборудованию, использование TCP/IP.
• Эффективное использование разных типов хранилищ (SSD, HDD).
• Доступ через собственный API (TCP/UDP) и модуль ядра Linux.
• Минимальные зависимости для сборки (C++, Go, RocksDB).

Ограничения:

• Файлы неизменяемы после записи.
• Не подходит для очень маленьких файлов (медиана — 2 МБ).
• Ограниченная пропускная способность при создании/удалении директорий.
• Отсутствие встроенной системы разрешений.

Разработка началась в 2022 году, с 2023 года система используется в production. К середине 2024 года все ML-задачи работают на TernFS. По состоянию на сентябрь 2025 года система хранит более 500 ПБ на 30 000 дисках и 10 000 SSD в трёх дата-центрах, с пиковой пропускной способностью в несколько ТБ/с. Потерь данных не зафиксировано.

Высокоуровневая архитектура

Основной API TernFS реализован четырьмя службами:

• Шарды метаданных — хранят структуру директорий и метаданные файлов.
• Координатор междиректорных транзакций (CDC) — выполняет транзакции между шардами.
• Службы блоков — хранят содержимое файлов.
• Реестр — хранит информацию обо всех службах и мониторит их.

Диаграмма взаимодействия служб TernFS и клиентов.

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

• Обсуждение технических особенностей TernFS: отсутствие RDMA, использование TCP/IP, репликация данных, ограничение на минимальный размер файла (~2MB), специализированная система метаданных.
• Сравнение с другими файловыми системами (CephFS, Lustre, GPFS): различия в архитектуре, производительности, поддержке POSIX и целевых use cases.
• Вопросы о бизнес-модели и масштабах данных XTX: хранение >500PB для ML-моделей в трейдинге, критика "отсутствия реальной ценности".
• Обсуждение лицензии (GPLv2-or-later/Apache-2.0) и предложения по улучшению документации (добавление примеров использования).
• Замечания о нишевых решениях для больших данных: акцент на immutable-данные, сложности с метаданными для tiny files, специализация под конкретные задачи.

Mosh — мобильная оболочка, заменяет SSH.

• Роуминг: меняйте сеть (Wi-Fi, LTE, Ethernet) — соединение живёт.
• Сон и обрывы: ноут спит, связь пропадает — Mosh ждёт и возобновляет.
• Без задержки: локальный эхо-ввод, предсказания подчёркиваются при плохой связи.
• Простота: не требует root, работает как обычный процесс, логинится через SSH, затем переключается на UDP.
• UTF-8: единственная кодировка, чинит юниксовые баги.
• Control-C: UDP-протокол не блокирует буферы, всегда прерывает процесс.

Поддерживаются GNU/Linux, BSD, macOS, Solaris, Android, Chrome, iOS.

• Mosh по-прежнему решает проблему «роуминга» и высокой латентности, но многие перешли на SSH поверх WireGuard/Tailscale.
• Часть пользователей жалуется на баги рендеринга, отсутствие проброса портов и OSC52, а также на замороженную разработку.
• Альтернативы: Eternal Terminal, shpool, wezterm, а также анонсируемый Rust-проект на WebRTC.
• На iOS популярен ShellFish (с tmux и интеграцией Files), Blink Shell теряет позиции.
• Для мобильных/спутниковых каналов Mosh всё ещё «спасательный круг», но кто-то предпочитает просто «терпеть» дропы через tmux/screen.