Цифровая энтропия: почему ваш сервер с аптаймом в 1000 дней — это ходячий мертвец, и как с этим жить

Представьте сервер «Феникс» с аптаймом в 986 дней — гордость любого админа, живая легенда стойки. А теперь представьте, что после планового перезапуска он больше не включился. RAID-контроллер мёртв, диски — тоже. Это и есть цифровая энтропия.

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

Почему Vibe-кодинг с ИИ — это как строить дачу в 90-е

Вокруг «вайб-кодинга» с ИИ много мечтаний: менеджеры хотят заменить дорогих разрабов, а разрабы — делегировать ИИ всю рутину. Но автор статьи предлагает посмотреть на этот тренд через неожиданную, но до боли знакомую метафору.

Он сравнивает такой подход со строительством дачи в 90-е. Помните, как дома строили без планов, из того, что удалось достать? Полубитый кирпич, старая бытовка, шифер с чужой стройки — в ход шло всё. Главное — энтузиазм, а не экспертиза.

В итоге получается цифровой «домик Нуф-Нуфа»: выглядит рабочим, но без фундамента и архитектуры. Автор задаёт главный вопрос: вы пробовали перестраивать такую дачу? Разберёмся, почему «потом перепишем» — плохая стратегия.

Старый iPhone 8 отказался умирать и стал OCR-сервером на солнечных батареях

Что вы делаете со старым айфоном после апгрейда? Чаще всего он отправляется в ящик стола. Но один iPhone 8 получил новую, неожиданную работу — он стал полноценным OCR-сервером, который уже больше года работает в режиме 24/7.

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

Но как превратить потребительский смартфон в надёжный сервер? Как обойти печально известные ограничения iOS на фоновые процессы и заставить приложение работать без перебоев? И как обеспечить стабильное питание, когда за окном месяцами нет солнца?

Погрузимся в детали этого безумного, но невероятно крутого DIY-проекта.

Игры из эфира: как радио сделало гейминг доступным каждому

«Скачай новую игру по радио!» — сегодня это звучит как бред, но в 1980-е, задолго до Интернета, это было реальностью. Энтузиасты придумали гениальный способ распространять софт: раз программа на кассете — это просто звук, значит, этот звук можно передать в радиоэфир!

Представьте картину: вы сидите у приёмника с кассетным магнитофоном наготове. Вместо музыки из динамиков раздаётся оглушительный писк и визг, похожий на сигнал модема. Вы торопливо жмёте «Record», а потом загружаете эту запись в свой ZX Spectrum. Через несколько минут на экране появляется игра.

Но как это вообще работало в реальности? Как инженеры заставляли программы, «скачанные» в Голландии, запускаться на компьютерах в Югославии? Что говорили случайные слушатели, наткнувшиеся на этот «шум» в эфире? И почему эта удивительная эпоха «радио-загрузок» так внезапно закончилась?

Погрузимся в удивительную историю времён, когда радио было главным файлообменником.

Что, если объединить дюжину 56K-модемов в 2025 году? Энтузиасты из команды The Serial Port задались именно этим вопросом, чтобы установить рекорд скорости коммутируемого доступа. Их главная цель — запустить YouTube.

Для эксперимента собрали стенд из двенадцати модемов Courier V.Everything 56K, VoIP-модуля Cisco и ПК на Windows XP. Технология Multilink PPP позволила объединить пропускную способность всех модемов в один логический канал.

Для сравнения: в 2000 году «широкополосным доступом» считалась скорость от 200 Кбит/с. Команда поставила себе задачу превзойти этот показатель, чтобы смотреть видео в минимальном качестве (240p).

Путь к рекорду был непростым. Первая попытка на старом ПК с Windows ME и двумя модемами была успешной, но при попытке добавить больше портов система столкнулась с конфликтами драйверов.

Пришлось перейти на более «современный» IBM Think Center 2004 года с Windows XP. Но и там возникла проблема: две одинаковые платы расширения не работали вместе из-за совпадения адресов COM-портов. Решением стала установка плат от разных производителей.

В итоге, после всех манипуляций, система заработала. Дюжина модемов одновременно набрала номер и достигла общей скорости соединения 668,8 Кбит/с.

Этого хватило для стриминга видео с YouTube! После небольшой первоначальной задержки ролик шёл плавно и без буферизации. Примечательно, что до этого никто в мире, судя по всему, не использовал больше четырёх модемов в MPPP одновременно.

Far Manager для Linux/macOS повзрослел: обзор главных фич far2l за 2025 год

2025-й стал для far2l годом, когда разработчики закрыли старые «долги» и реализовали фичи, о которых сообщество просило годами. Первой пала вечная боль всех пользователей — встроенный терминал. Помните, как при копировании длинные логи или ошибки компилятора рвались на части? Всё, это в прошлом. Терминал полностью переработали, и теперь он работает как у «взрослых».

Но это только начало. В свежих версиях появился новый, быстрый и многопоточный плагин для архивов с настоящим прогресс-баром. Наконец-то добавили долгожданный встроенный хекс-редактор — больше не нужно запускать внешние утилиты. А вишенкой на торте стало человеческое меню «Открыть с помощью...», которое работает не хуже, чем в GUI.

Выясним, как эти и другие нововведения превращают far2l из простого файлового менеджера в полноценную среду для работы в консоли.

PostgreSQL 18: новый асинхронный I/O ускоряет запросы до 3-х раз. Что происходит?

Представьте очередь в супермаркете, где каждый ждёт, пока предыдущий покупатель полностью расплатится. Примерно так же работали с диском и старые версии PostgreSQL: одна операция за раз, с томительным ожиданием. Но в 18-й версии всё изменилось.

Новая подсистема асинхронного ввода-вывода (AIO) позволяет базе данных отправлять на диск сразу пачку запросов, не блокируя основную работу. Результат — ускорение чтения в 2-3 раза. Но как именно работает эта магия? Что там под капотом, и какие ещё мощные фичи, от умных индексов до новых типов UUID, скрываются в этом релизе?

Разберёмся в главном обновлении PostgreSQL этого года и выясним, как выжать из него максимум производительности.

Дедлайны горят, команда работает на кофе и панике, а до релиза ещё неделя кранча. Знакомая ситуация?

В игре «Стартап-кранч» за ментальное здоровье и продуктивность команды отвечает новый базовый специалист — Дэйли Ремайндер. Она не даст вашим разрабам выгореть и напомнит, что иногда нужно отрываться от IDE.

Её суперсила — в научном подходе. Каждый день в своём телеграм-канале она напоминает команде, как сделать жизнь и работу чуть лучше. А для самых сложных случаев у неё есть «ультимейт» в подписке — практические гайды и обзоры исследований, которые помогут оптимизировать всё: от сна до концентрации.

Нанимайте этого спеца в свой стартап, чтобы ваша команда работала не много, а умно (и выигрывала призы) 👈

VSCode тормозит: история одного расследования

Знакомая ситуация: ваш любимый VSCode вдруг начинает зависать, Copilot замолкает, а коммиты не отображаются. Первая реакция — перезапустить. Вторая — смириться. Но автор этой статьи решил пойти до конца и устроил настоящее детективное расследование.

Вместо того чтобы наугад отключать плагины или винить железо, он использовал встроенные инструменты диагностики. Первый же подозреваемый нашёлся быстро: Process Explorer показал, что процесс расширений отъедает 99% CPU. Стало ясно — виноват один из плагинов.

Но как найти того самого виновника среди десятков установленных расширений? Оказывается, в VSCode есть штатный инструмент, который методом «деления пополам» помогает быстро вычислить «убийцу» производительности.

Проследим за ходом этого расследования и узнаем, какое именно расширение оказалось крайним.

Встречайте BI-672: самое производительное процессорное ядро, разработанное в России

На конференции «Микроэлектроника 2025» анонсировали новое процессорное ядро от компании CloudBear — BI-672 на архитектуре RISC-V. И это не просто очередное обновление. Ядро стало первым в России, преодолевшим значимый рубеж производительности в 1 SpecInt2017 на ГГц.

Такой скачок стал возможен благодаря полной переработке микроархитектуры. Но насколько велика разница по сравнению с прошлой версией? Как новое ядро выглядит на фоне серьёзного конкурента вроде Arm Cortex A75 в «больших» тестах? И какие именно изменения под капотом позволили добиться такого результата?

Посмотрим на детальные графики производительности и заглянем в планы разработчиков.

Как часто вы думаете о Римской империи… (cтатическом анализе кода)

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

Когда-то это была лишь теория отцов-основателей вроде Алана Тьюринга, а сегодня — AI-ассистент, встроенный в вашу IDE. Но как произошёл этот переход? Когда появился первый «Цезарь» статического анализа, и как он выглядел? И какие «варвары» (в виде багов) пали в боях за чистоту кода?

Проследим всю историю этой технологии — от теорем Гёделя до GPT-ассистентов.

Почему «скучный» код — это признак мастерства, а не посредственности

Вспомните фильмы о боевых искусствах: новичок постоянно прыгает и показывает flashy-приёмы, а мастер остаётся почти неподвижным, но его один удар решает всё. Автор статьи утверждает, что в программировании так же: желание использовать все модные инструменты — от Redis до очередей — признак новичка. Мастерство же в том, чтобы выбрать простейшее рабочее решение.

Но разве это не путь к «большому кому грязи»? И что делать с масштабированием? Автор считает, что одержимость будущим масштабом — главный грех SaaS-разработки, а настоящий инжиниринг как раз и заключается в поиске самого простого, а не самого навороченного пути.

Разберёмся в этом контринтуитивном подходе и выясним, почему YAGNI — возможно, главный принцип из всех.

Чистовики патриарха. О трёх последних книгах Олега Цилюрика

Редактор издательства «БХВ» делится тёплой историей о легендарном программисте Олеге Цилюрике (1951 — 2024). Всё началось с поисков переводчика для классики O’Reilly, а привело к открытию готовой рукописи Олега Ивановича, которая легла в основу его собственных шедевров о Linux.

Результатом стал монументальный труд «Расширения ядра Linux. Драйверы и модули», который многие считают достойным наследником классики Linux Device Drivers. Олег Иванович до последнего демонстрировал невероятную самоотдачу, лично вычитывая вёрстку и дебажа старый код. Это был человек огромного масштаба, который в 70+ лет планировал изучать Rust и C++23.

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

Кустарные вакуумные триоды Клода Пайяра. Часть первая. Знакомство, общие положения

Зачем в обществе потребления, где всё можно купить, вручную создавать технологию столетней давности? Ответ — в ностальгии, эстетике и чистой радости созидания. Познакомимся с Клодом Пайяром — французским радиолюбителем и «самодельщиком Божьей милостью», который в своём гараже воссоздал производство винтажного вакуумного триода 1920-х годов.

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

Посмотрим на удивительную мастерскую Клода Пайяра и разберём первый этап этого электровакуумного чуда — работу со стеклом.

28 сентября человек, подаривший нам Всемирную паутину, — сэр Тим Бернерс-Ли, — опубликовал эссе с вопросом, который волнует каждого: «Останется ли интернет свободным?».

Он вспоминает, как в 34 года был одержим идеей объединить интернет и гипертекст. Он рисовал схемы на досках, на салфетках, даже палкой на снегу, убеждая коллег в CERN. Его вера была проста: если дать людям простой инструмент, он раскроет творчество и сотрудничество в глобальном масштабе.

Для того чтобы в сети было всё, она должна была быть для всех. А значит — бесплатной. И поэтому в 1993 году он убедил CERN отдать технологию World Wide Web в общественное достояние. Бесплатно. Навсегда.

Сегодня, глядя на своё изобретение, Бернерс-Ли задаёт тот же вопрос: остался ли интернет свободным? И сам же отвечает: нет. Горстка гигантских платформ собирает наши личные данные, чтобы торговать ими с кем угодно — от маркетологов до репрессивных правительств.

Мы больше не клиенты — мы продукт. Наши данные — товар. Алгоритмы, вызывающие зависимость, разрушают психическое здоровье подростков, а вредоносный контент сеет дезинформацию и насилие в реальном мире. Это совсем не то, о чём он мечтал.

Где-то между его видением Web 1.0 и рассветом социальных сетей Web 2.0 мы свернули не туда. Сейчас мы на новой развилке, и имя ей — искусственный интеллект. Повторим ли мы те же ошибки? Бернерс-Ли уверен: мы не можем позволить, чтобы с ИИ произошло то же самое. Власть снова рискует оказаться в руках тех, кто контролирует данные.

Но решение есть. И оно двойное. Первое — технологическое. Это протокол Solid, который он и его команда разрабатывали в MIT. Идея проста: вместо того чтобы ваши данные хранились в десятках разрозненных «колодцев» у корпораций, они находятся в одном месте. У вас. Вы — владелец. А приложения лишь запрашивают у вас доступ, который вы можете дать или не дать.

Второе решение — институциональное. Правительства слишком медлительны, а Big Tech никогда не пойдёт на то, на что пошёл CERN — некоммерческая организация, позволившая отдать интернет бесплатно. Поэтому нам нужна новая, независимая структура уровня CERN для международного исследования ИИ, свободная от коммерческого давления.

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

Как победить CMake: отладка CMake-скриптов

Каждый, кто работал со сложными CMake-скриптами, знает эту боль: чтобы понять, что происходит, приходится утыкивать код message()-логами и молиться. Автор статьи долгое время страдал так же, пока не обнаружил, что в CMake есть секретное оружие.

Оказывается, начиная с версии 3.27, в CMake есть встроенный пошаговый отладчик, а с 3.18 — профилировщик. Можно ставить брейкпоинты, смотреть переменные и анализировать время выполнения, как в нормальном коде! Но, кажется, об этих инструментах до сих пор мало кто знает.

Разберёмся, как настроить и использовать встроенный отладчик и профилировщик CMake в VSCode и других IDE, чтобы навсегда забыть про отладку логами.