ЭРЦИТ Технопоинт

Итак, начнём...

Mon, 31 Aug 2026 00:00:00 +0000

Привет, команда нашего замечательного ИТИ ХГУ! Особенно — первокурсники: если вы сейчас стоите перед серверной стойкой, смотрите на мигающие лампочки и думаете: «Где я вообще нахожусь?» — выдыхайте! Вы точно попали именно туда, куда нужно и находитесь в нужном месте. Тут не про магию, тут про логику, конфиги и умение читать логи, когда всё упало в три ночи. Тут про знания. Тут про ошибки и их решения. Добро пожаловать в реальную ИТ‑кухню ЭРЦИТ — здесь теория встречается с практикой, и именно из этого рождается инженер.

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

Хотите увидеть, как выглядит живой LDAP‑кластер на почти 900 учётных записей и 60 сервисов? Он у нас есть, и мы покажем не только схему, но и пару типичных кейсов, когда всё внезапно переставало работать — и как мы это чинили. Это не «идеальный мир из документации», а реальные грабли, по которым мы уже прошлись, чтобы вы могли их обойти. Как знать, может вы в итоге по нашей указке забредёте в целый лес таковых? Но знайте, мы уже немножко научили вас делать так, чтобы можно было увернуться или чтобы было не так больно и обидно, если прилетит. 😉

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

Мы специально не гонимся за хайповыми трендами ради хайпа. Если у нас в ЭРЦИТ стабильно крутятся FreeBSD, OpenBSD и разные Linux‑дистрибутивы — значит, про них и пишем, с конкретными конфигами, командами и пояснением, почему именно эта ОС встала на эту роль. Это не сравнение «кто круче», а честный рассказ: вот задача, вот ограничения, вот почему выбрали этот стек.

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

При этом писать сюда может любой: студент, который автоматизировал лабораторную работу скриптом на 30 строк, преподаватель, который интересно рассказал про что-то невероятно сложное, аспирант, который собрал свой мини‑кластер для экспериментов. Главное — чтобы это было про применение ИТ и несло практическую пользу. Даже если решение выглядит скромно, но реально работает — оно достойно места в блоге.

Мы не публикуем абстрактные рассуждения без кода и без результата. Если нет примера, который можно воспроизвести или хотя бы адаптировать, — лучше пока не писать. Зато если есть рабочий кейс, пусть даже с оговорками «работает в наших условиях», мы поможем его оформить так, чтобы он стал полезным для других.

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

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

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

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

Если у вас есть свой рабочий кейс — присылайте, разберём вместе и опубликуем. Даже если кажется, что «это слишком просто» или «все и так это знают» — возможно, именно эта простая вещь кому‑то сильно поможет.

Контакты автора всегда указаны в конце статьи — не стесняйтесь спрашивать, если что‑то не получается воспроизвести. Мы не любим оставлять людей один на один с ошибкой, особенно если она звучит как «command not found» в самый неподходящий момент.

Так что заходите, читайте, берите примеры, пробуйте, задавайте вопросы напрямую автору. Добро пожаловать в реальную ИТ‑кухню ЭРЦИТ! Пусть первый сервер, который вы поднимете, будет не идеальным — но зато своим.

Будем рады видеть ваши статьи, идеи и вопросы. И помните: каждый эксперт когда‑то был первокурсником, который боялся нажать Enter. Теперь ваша очередь — нажимайте.

До встречи в статьях и в каналах!

От Alpine Linux до OpenBSD: ключевые ОС в работе ЭРЦИТ. Часть четвёртая

Tue, 04 Aug 2026 00:00:00 +0000

Если FreeBSD — это про систему как единое целое, где всё от ядра до утилит живёт в одном дереве и собирается одной командой, то OpenBSD — это про то, как сделать это целое максимально надёжным. Это не «Linux с усиленной безопасностью» и не «FreeBSD с патчами». Это проект, где безопасность — не надстройка, а сама основа разработки: код не принимают, если он не прошёл аудит на безопасность, не соответствует стилю и не учитывает принцип наименьших привилегий. Для студентов в ЭРЦИТ это принципиально другой учебный кейс: не «как развернуть и настроить», а «как проектируется система, в которой уязвимость сложнее внедрить, чем обнаружить».

В Linux безопасность чаще всего добавляют слоем поверх системы: SELinux, AppArmor, политики, модули ядра. В FreeBSD тоже есть механизмы изоляции — jails, capsicum — но они развиваются как часть большой экосистемы. В OpenBSD безопасность — это сам процесс разработки. Каждый коммит проверяют на потенциальные уязвимости, каждый новый API проектируют с учётом минимальных привилегий, каждую библиотеку прогоняют через аудит. Проект знаменит девизом: «Only two remote holes in the default install, in a heck of a long time». Это не реклама, а отражение подхода: если функционал не нужен по умолчанию, его просто не включают. Минимализм здесь — тоже защита. Сайт проекта описывает философию тремя словами: правильность, простота, безопасность — и именно в таком порядке. То есть речь не про «добавить защиту», а про «не создавать уязвимости».

Именно поэтому кодовую базу OpenBSD сознательно держат компактной. Меньше строк кода — меньше мест, где можно ошибиться. Меньше зависимостей — меньше цепочек доверия, которые могут сломаться. Меньше сервисов по умолчанию — меньше векторов атаки. Для обучения это особенно ценно: студент видит не огромную систему, где «всё работает», а минималистичную, где понятно, как и почему работает каждая часть. В ЭРЦИТ мы используем OpenBSD как пример «чистого листа»: ставим только то, что нужно для задачи, и учимся обосновывать каждый установленный пакет.

Из коробки OpenBSD даёт несколько ключевых вещей, и каждая из них по сути отдельный учебный модуль. LibreSSL — форк OpenSSL, созданный командой OpenBSD, чтобы убрать тяжкое наследство OpenSSL и сделать криптографию более безопасной и понятной. Это не просто «другой SSL», это другой подход к реализации: меньше абстракций, больше контроля, меньше скрытых состояний. Packet Filter (PF) — мощный и понятный фаервол, который проектировался как часть ОС, а не как отдельный модуль. Его синтаксис — это отдельный навык: он учит мыслить в терминах правил, состояний и приоритетов, а не «включить галочку в GUI». Privilege separation — техника, при которой программа разбивается на части с разными правами доступа: если одна часть будет скомпрометирована, остальные останутся защищены. Этот принцип пронизывает весь стек OpenBSD: от sshd до sendmail. И W^X (Write XOR Execute) — аппаратная и программная защита, которая не позволяет памяти быть одновременно записываемой и исполняемой. Это усложняет эксплуатацию многих классов уязвимостей.

Но, как и в FreeBSD, одно из самых сильных впечатлений у студентов вызывает то, что находится в базовой поставке. В OpenBSD из коробки есть всё, чтобы запустить сетевой сервис: веб-сервер httpd(8) — невероятно простой и лаконичный, работающий в chroot в /var/www по умолчанию, с встроенной поддержкой TLS и интеграцией с acme-client(1) для автоматических сертификатов Let’s Encrypt. Почтовый сервер — OpenSMTPD, который пришёл на смену Sendmail в OpenBSD 5.8 и чей конфигурационный синтаксис умещается на одном экране, в отличие от Postfix или Exim. Сервер сетевого времени — OpenNTPD. Рекурсивный DNS-резолвер unbound(8) и авторитетный nsd(8). Именно он возит наш локальный домен ercit.local уже третий год. Реверс-прокси relayd(8). И это не сторонние пакеты, которые нужно ставить отдельно, тащить гору зависимостей и надеяться, что мейнтейнер не забыл пропатчить последнюю CVE — это часть базовой системы, и на всё это распространяется тот же принцип: тот же аудит кода, те же стандарты безопасности, та же ответственность команды OpenBSD. Каждый из этих компонентов проектируется, пишется и сопровождается в рамках того же процесса, что и ядро. Для студента это означает, что можно поднять полноценный сетевой сервер — веб, почта, DNS, NTP — не установив ни одного пакета. В Linux для этого нужен как минимум apt install или dnf install с десятками зависимостей; в OpenBSD ты просто редактируешь конфиг и пишешь rcctl enable httpd.

Ещё одна деталь, которая удивляет студентов, привыкших к Linux, где bash идёт «по умолчанию» в головах всех, кто работает в командной строке, — в OpenBSD оболочкой по умолчанию является ksh(1), а именно pdksh, Public Domain Korn Shell. FAQ OpenBSD прямо говорит: оболочка по умолчанию — ksh, основанный на public domain Korn shell, а bash и другие оболочки можно добавить из пакетов. ksh — это тот же бинарник, что и /bin/sh, и пользователи, знакомые с bash, найдут его очень похожим: автодополнение по Tab, редактирование командной строки, история через стрелки, Ctrl-A/Ctrl-E для перехода в начало и конец строки. Но ksh — это не «bash с другим именем». Это Korn shell, потомок оболочки, которую Дэвид Корн создал в Bell Labs в 1982 году и которая легла в основу стандарта POSIX shell. Bash — это надстройка над Bourne shell, добавившая ksh-подобные функции; ksh — это первоисточник. bash при желании можно поставить из пакетов, но команда OpenBSD считает, что ksh покрывает подавляющее большинство задач, и лишняя зависимость — это лишний риск. Для студента это ещё один урок: «привычное» не всегда значит «правильное», и иногда стоит попробовать инструмент, который лежит перед тобой, прежде чем тянуть замену из репозитория.

Многие привыкли считать OpenBSD сугубо консольной системой — и отчасти это справедливо: в ЭРЦИТ студенты сперва учатся управлять серверами через терминал, без лишних графических надстроек. Но графика в OpenBSD есть — это Xenocara, собственная сборка X Window System, которая живёт в дереве /usr/xenocara и входит в официальный релиз. И она сделана ровно по тем же канонам, что и вся ОС: никакой гонки за новыми фичами, зато максимум контроля и безопасности. Команда не создаёт свой X‑сервер с нуля, а берёт актуальный стек X.Org и накладывает на него точечные патчи: запускает X‑сервер от непривилегированного пользователя _x11, разделяет привилегии, интегрирует pledge и unveil, чтобы даже графическая подсистема не могла выйти за отведённые ей рамки. В итоге получается не «просто рабочий стол», а продолжение философии OpenBSD: если уж графика есть, то она должна быть такой же минималистичной, прозрачной и защищённой, как и всё остальное.

Документация OpenBSD — это не просто man-страницы, а полноценные руководства, где часто есть разделы «Security Considerations» прямо в описании утилиты. Для студента это важный сигнал: безопасность — часть документации, а не отдельная книга.

На практике это сильно меняет подход администратора и разработчика. В Linux ты часто ставишь пакеты из репозитория и надеешься, что мейнтейнеры проверили зависимости. В OpenBSD ты либо используешь порты (которые тоже проходят аудит), либо собираешь из исходников, понимая, какие флаги компиляции и какие зависимости ты включаешь. В FreeBSD у тебя есть build world — возможность пересобрать всю систему целиком. В OpenBSD сборка тоже есть, но фокус не на «пересобрать всё», а на «собрать только нужное и безопасное». И если в Linux и FreeBSD нередко сначала включают кучу сервисов, а потом «закрывают дыры», то в OpenBSD сервисы по умолчанию минимальны, и ты добавляешь только то, что действительно нужно.

В ЭРЦИТ OpenBSD — это не учебная песочница, а рабочая инфраструктура. На OpenBSD у нас построена система сбора и хранения лог-файлов. На OpenBSD запущены наши LDAP-серверы, которые в едином кластере обеспечивают аутентификацию для почти 900 учётных записей и почти 60 сервисов. Студентам OpenBSD интересна с двух сторон: во-первых, как операционная система, основная парадигма которой — безопасность, и это видно во всём, от устройства ядра до man-страниц; во-вторых, как система, в которой можно совершенно спокойно заниматься разработкой программ на различных языках и в различных экосистемах — и на эту разработку распространяются те же самые аспекты безопасности, что и на системные утилиты. Аудит кода, принцип наименьших привилегий, статическая линковка, chroot, pledge и unveil — всё это работает не только для базовой системы, но и для того, что ты пишешь и запускаешь поверх неё.

Исторически OpenBSD откололся от NetBSD в 1995 году, когда Тео де Раадт и его команда решили сделать ставку на безопасность и качество кода. С тех пор проект развивается как некоммерческий, с упором на прозрачность и аудит. Команда известна своей бескомпромиссностью: если код не соответствует стандартам безопасности и стиля, его не примут, даже если он «работает». Это может раздражать тех, кто привык к быстрым релизам и «почти рабочим» решениям, но именно это делает OpenBSD уникальным учебным примером: здесь учат, что «работает» — это только начало, а «безопасно и понятно» — это цель. Тео де Раадт неоднократно подчёркивал в интервью и выступлениях, что безопасность для команды — не опция, а обязательный критерий качества.

Логотип OpenBSD — это Puffy, рыба-иглобрюх. Puffy появился в OpenBSD 2.7, вышедшей в июне 2000 года, и сменил прежний маскот — BSD-демона с трезубцем и нимбом, которого OpenBSD до этого делила с FreeBSD и NetBSD. Выбор рыбы-иглобрюха был неслучайным: Blowfish — алгоритм шифрования, который использовался в OpenSSH, — дал имя маскоту. А сам иглобрюх, с его шипами, отпугивающими хищников, — естественная метафора для системы, чья главная защита — не нападение, а готовность к нему. Puffy быстро стал популярен именно потому, что отличался от BSD-демона: своя рыба, свой характер, свой стиль.

Каждые шесть месяцев, примерно 1 мая и 1 ноября, OpenBSD выпускает новый релиз. И каждый релиз — это не просто набор бинарников на FTP-сервере. К нему обязательно создаётся новый рисунок: Puffy в образе самурая, пирата, варвара, рэпера, революционера — тема выбирается исходя из того, что происходило в проекте и вокруг него за последние полгода. Арт украшал CD-диски, постеры и футболки. До версии 6.0 проект выпускал физические CD с напечатанным рисунком; сейчас диски больше не производятся, но традиция осталась.

Но рисунок — это только половина. К каждому релизу часто записывается оригинальная песня, посвящённая разработке этого релиза. На странице релизных песен хранятся они все — от «E-Railed (OpenBSD Mix)» (3.0, 2001) до «Diamond in the Rough» (7.9, 2026). Темы бывают абсурдными и глубокими одновременно: «The Wizard of OS» — пародия на «Волшебника страны Оз», «100001 1010101» — песня про бинарный код, «Wrap in Time» — рефлексия после Heartbleed, «Winter of ‘95» — ностальгия по первым дням проекта. Выпущено даже три физических аудио-CD — «The Songs 3.0–4.0», «The Songs 4.1–5.1» и «The Songs 5.2–6.0». Другие операционные системы так не делают. Это красиво, странно и абсолютно в духе OpenBSD.

Самый последний релиз — OpenBSD 7.9, вышедший 19 мая 2026 года. Шестидесятый по счёту. Кодовое имя — «PinkPuffy», песня — «Diamond in the Rough». Релиз включает OpenSSH 10.3 с новым механизмом PerSourcePenalties для блокировки перебора, LibreSSL 4.3.0 с подготовкой к постквантовой криптографии, обновлённый планировщик, учитывающий гетерогенные ядра, поддержку Wi-Fi 6 (802.11ax), драйвер USB4, поддержку VLAN для виртуальных мостов veb(4) и IPv6 SLAAC по умолчанию в установщике. Для платформы amd64 подготовлено более 13 000 бинарных пакетов: Firefox 150, GNOME 49, KDE Plasma 6.6.4, LLVM/Clang 19.1.7, GCC 15.2.0, Go 1.26.2, Rust 1.94.1, Python 3.13.13, Ruby 4.0.2 — современная экосистема, которой OpenBSD давно не стыдится.

Пожалуй, стоит сказать прямо: из всех живых операционных систем OpenBSD ближе остальных к изначальному UNIX — даже больше, чем FreeBSD. Не потому, что она делает то же, что UNIX делал тридцать лет назад, а потому, что сохранила дух UNIX: каждая программа делает одну вещь и делает её хорошо, программы работают вместе через простые интерфейсы, безопасность — не прибавка, а основа. Когда студент это видит и сравнивает с современными Linux-дистрибутивами, где один systemd тянет за собой половину системы, а один пакет зависит от сотни других, — он понимает, что UNIX — это не история, а живая инженерная философия.

В ЭРЦИТ мы не противопоставляем Linux, FreeBSD и OpenBSD — мы показываем, как разные инженерные философии задают разные подходы к проектированию систем, а значит, лучше подходят для разных классов задач. Linux — это индустриальный стандарт: мощная экосистема, гибкость и широчайший выбор инструментов делают его оптимальным выбором для большинства серверных и облачных сценариев, где важна совместимость и скорость внедрения. FreeBSD раскрывает идею целостной системы — ядро, утилиты и инфраструктура развиваются как единое дерево, и эта связность особенно ценна там, где нужны прозрачность архитектуры и возможность глубокой настройки: например, в сетевом стеке или при построении собственных платформенных решений. OpenBSD, в свою очередь, делает акцент на безопасности как фундаментальном принципе: минимализм, строгий аудит кода и встроенные механизмы защиты отражают подход, при котором система изначально проектируется так, чтобы уязвимостей было как можно меньше — и это делает её особенно уместной в критически важных узлах инфраструктуры, где цена ошибки максимальна. Вместе эти три системы формируют у студентов полноценное инженерное мышление: они учатся не просто выбирать инструмент под задачу, а видеть, какая философия стоит за каждой ОС, и осознанно соотносить эту философию с требованиями проекта — понимая, что «правильный» выбор определяется не модой и не привычкой, а соответствием подхода решаемой задаче.

От Alpine Linux до OpenBSD: ключевые ОС в работе ЭРЦИТ. Часть третья

Mon, 03 Aug 2026 00:00:00 +0000

Если с Linux всё более-менее понятно — ядро одно, а «дистрибутив» это про то, как его упаковали с утилитами, — то FreeBSD устроена принципиально иначе. Это не «ядро плюс набор сторонних утилит», а полноценная операционная система: ядро, системные утилиты, базовые библиотеки, документация и инструменты разработки делаются одной командой, в одном репозитории, в одном релизе. В мире Linux ядро пишут одни люди, GNU coreutils — другие, а дистрибьютор просто собирает это в пакет. В FreeBSD разработчик, правящий сетевую утилиту, может одновременно поправить ядро и документацию — всё синхронно, всё в одной сборке. И именно эта согласованность — то, чего Linux исторически лишён: нет рассинхрона между ядром и userland, нет ситуации, когда утилита ведёт себя не так, как описано в man-странице. FreeBSD Handbook, Chapter 14 прямо говорит: «FreeBSD maintains a clear separation between the base system and third party applications… FreeBSD base system configuration is located at the /etc directory, and the /usr/local/etc directory contains all the configuration files of the applications installed on the system» — базовая система и стороннее ПО разделены, и это разделение заложено в самой архитектуре.

Чтобы понять, насколько это иной подход, стоит задержаться на том, что вообще значит «единая архитектура». В Linux мир состоит из независимых проектов: ядро живёт на kernel.org, glibc — отдельно, GNU coreutils — отдельно, systemd — отдельно, и у каждого свой цикл релизов, свои мейнтейнеры, свои приоритеты. Дистрибьютор берёт версии этих компонентов, которые оказались актуальны на момент сборки, и склеивает их в работающее целое — и надо отдать должное: крупные дистрибутивы вроде Debian или Ubuntu делают это отлично, с серьёзным тестированием и контролем качества. Готовый дистрибутив Linux — это надёжный, предсказуемый продукт. Разница не в том, что один подход «хороший», а другой «плохой», — разница в том, где проходит граница ответственности. В Linux целостность системы обеспечивает дистрибьютор: он отвечает за совместимость компонентов и гарантирует, что собранная комбинация версий работает. В FreeBSD эта целостность заложена в самой архитектуре: весь исходный код — от ядра до последней утилиты — живёт в одном дереве /usr/src, сопровождается одним сообществом и выпускается одним релизом. Репозиторий FreeBSD — наглядное тому подтверждение: bin/, sbin/, lib/, usr.bin/, sys/ — всё рядом, всё в одном коммите. Когда выходит новый релиз FreeBSD, ты получаешь не «ядро версии X плюс утилиты версии Y», а цельную систему, где каждая часть гарантированно работает с остальными — и за это отвечает не дистрибьютор, а сама структура проекта.

Для студентов это важный концептуальный момент. FreeBSD показывает, как выглядит система, спроектированная как единое целое. Базовая система живёт в корне, стороннее ПО — в /usr/local, конфиги базовых компонентов — в /etc, конфиги сторонних программ — в /usr/local/etc. Граница между «это часть ОС» и «это мы поставили сверху» проведена чётко и не размыта. В Linux такой границы нет по определению: всё свалено в одну кучу, и разобраться, что относится к системе, а что — к пакету, порой непросто. Сторонние сравнения обращают на это внимание именно в контексте архитектурного различия — и это не нюанс, а фундаментальная разница в подходе.

Просто установив «ванильную» FreeBSD, студент сразу получает рабочий набор инструментов: текстовый редактор (vi и более дружелюбный ee), компилятор C/C++ на базе Clang/LLVM, ассемблер, утилиту make (Berkeley make), линкер и набор бинарных утилит для своей архитектуры — всё из коробки, без единого дополнительного пакета. Руководство FreeBSD для разработчиков, глава 2 прямо говорит: «Compilers for C and C++ and an assembler come with the basic system, not to mention classic UNIX tools such as sed and awk». В Linux, чтобы получить то же самое, нужно поставить пакет build-essential или аналог — в FreeBSD это просто есть. Для студента это принципиальный сигнал: система задумана так, чтобы её можно было собрать, разобрать и пересобрать без похода в репозитории.

И вот здесь единая архитектура раскрывается в полной мере — через процедуру build world. В FreeBSD весь исходный код операционной системы — ядра и пользовательского окружения — хранится в /usr/src. make buildworld компилирует всю базовую систему целиком, make buildkernel — собирает ядро, GENERIC или кастомный конфиг. Затем make installworld и make installkernel разворачивают результат на живую систему. Это не «пересборка пакетов», а полноценная сборка своей собственной операционки из исходников: задаёшь опции компиляции через make.conf и src.conf, подключаешь или отключаешь нужные компоненты, собираешь ядро под конкретное железо. Официальная документация описывает это как штатный, поддерживаемый процесс — а не хак на свой страх и риск. И это возможно только потому, что весь код — в одном дереве: не нужно вытягивать исходники ядра из одного места, утилиты — из другого, а потом угадывать, совместимы ли они. Всё перед тобой, всё компилируется одним make, всё ставится одним installworld.

Для образовательной среды build world бесценен. Студент проходит путь от исходного кода до работающей ОС и видит, как каждый кусок системы собирается и встаёт на место. В ЭРЦИТ мы используем эту процедуру, чтобы собирать FreeBSD под конкретные задачи: убрать лишние драйверы, включить нужные опции ядра, получить систему, заточенную под конкретный сервер. При этом обновление исходников и пересборка — рутинная операция, хорошо документированная и предсказуемая. Для студентов это наглядный пример того, как операционная система может быть полностью прозрачной: ты видишь исходники, ты видишь конфигурацию сборки, ты получаешь результат — и понимаешь, что внутри. Никаких чёрных ящиков.

Но FreeBSD — это не только про чистоту архитектуры и сборку из исходников. Из коробки она предлагает набор технологий, который делает её полноценной и самодостаточной платформой для серверной инфраструктуры. ZFS — зрелая файловая система и менеджер хранилищ в одном флаконе: пулы, снапшоты, контрольные суммы, компрессия на лету, RAID-Z, репликация. iSCSI-таргет и инициатор на уровне ядра — ctld(8) позволяет раздавать блочные устройства по сети без единого стороннего пакета. Руководство FreeBSD описывает настройку iSCSI как часть базовой системы. Jails — родоначальник контейнерной изоляции в мире UNIX, появившийся ещё в FreeBSD 4.0 в 2000 году, за тринадцать лет до Docker — дают изоляцию процессов, файловой системы и сети на уровне ядра, без гипервизора, без оверхеда. А недавно во FreeBSD появился и порт Podman — полноценный OCI-совместимый контейнерный движок, работающий поверх jails через runtime ocijail. FreeBSD Foundation официально курирует этот проект. Podman на FreeBSD поддерживает как нативные FreeBSD-контейнеры, так и Linux-образы через слой совместимости (Linuxulator), использует ZFS для storage-драйвера и предоставляет CLI, совместимый с Docker. Это значит, что студенты, освоившие Docker на Linux, могут без труда перейти на FreeBSD и продолжить работать с привычным инструментарием — но уже в среде с другой архитектурой и другой философией.

Всё это вместе — ZFS, iSCSI, jails, Podman, build world, единая архитектура — делает FreeBSD достойной альтернативой решениям на базе Linux. И дело не в том, что FreeBSD «лучше» — а в том, что она другая, и именно это ценно для образования. Когда студент видит, что одну и ту же задачу — поднять контейнер, настроить хранилище, изолировать сервис — можно решить принципиально иными средствами, у него формируется не шаблонное мышление «как в инструкции», а инженерное: умение сравнивать подходы, понимать компромиссы и выбирать осознанно. Студентам и преподавателям важно не зацикливаться только на Linux — потому что реальный мир инфраструктуры шире, и за пределами Linux лежат системы с десятилетиями выверенной инженерии, которые до сих пор работают в продакшне у крупных провайдеров и дата-центров. FreeBSD в ЭРЦИТ — это окно в этот мир: не замена Linux, а дополнение, которое делает кругозор студента по-настоящему полным.

Напоследок — немного истории, без которой рассказ о FreeBSD был бы неполным. Много лет лицом проекта был Beastie — забавный чертёнок с трезубцем, mascot всей семьи BSD. Первое изображение BSD-демона появилось в 1976 году: комикс-художник Фил Фольо нарисовал его для Майка О’Брайена на Unix-футболках для USENIX — четыре весёлых красных чертёнка с трезубцами, карабкающихся по трубам вокруг карикатуры на PDP-11.

Более популярные версии создал Джон Лассетер — да-да, тот самый, будущий режиссёр Pixar, — начиная с 1984 года, когда он работал в Lucasfilm и нарисовал grayscale-версию для обложки Unix System Manager’s Manual. В 1988 году Лассетер создал тот самый канонический красный Beastie с трезубцем для обложки книги МакКьюсика «The Design and Implementation of the 4.3BSD Operating System» — и именно этот рисунок FreeBSD использовала как логотип и талисман двенадцать лет. en.wikipedia.orgfreebsdfoundation.org

Несколько FreeBSD-специфичных вариантов позже выполнил Татсуми Хосокава, а канонический рисунок, который годами жил в /usr/share/examples/BSD_daemon/ и до сих пор встречается в загрузочном меню, — работа Поул-Хеннинга Кампа.

Но Beastie был сложен для печати, сильно «страдал» при масштабировании и к тому же не был уникальным для FreeBSD — им пользовалась вся BSD-семья. В 2005 году проект провёл открытый конкурс на новый логотип, и победителем стал Антон Гураль ¹, чей дизайн — красная сфера с маленькими рожками — был утверждён для разработчиков 8 октября 2005 года и публично анонсирован 1 ноября. Сообщество встретило новый логотип неоднозначно: на Slashdot его назвали «cute little horned spheroid», на OpenNet — «колобком с рожками». Мне лично новый логотип всегда напоминал фитнес-мяч с рожками — и, судя по реакциям сообщества, я не одинок в ощущении, что это просто круглый объект, которому приделали рога. Но логотип прижился (мне он тоже в конце-концов пришёлся по душе) — и сейчас именно этот «рогатый шар» встречает вас на сайте FreeBSD, на установочных образах и в документации. Beastie при этом не убили: он остался mascot проекта, просто логотип и талисман разошлись по разным ролям. web.archive.orgopennet.ru

Что до личного опыта: я начал использовать FreeBSD с версии 2.2.8-RELEASE (причём в качестве настольной ОС!) — это был ноябрь 1998 года, последний релиз ветки 2.2, — и с тех пор система ни разу меня не подводила. Сейчас на одном из моих ноутбуков в том же качестве настольной операционной системы установлена FreeBSD 15.1-RELEASE — вышла 16 июня 2026 года, свежий продуктивный релиз. Это не ретро-эксперимент и не ностальгия — это рабочая повседневность на актуальной версии. За эти годы сменилось не одно поколение железа, пятнадцать мажорных веток FreeBSD и не один десяток модных Linux-дистрибутивов, но FreeBSD просто работает — тихо, предсказуемо и без сюрпризов. Думаю, это и есть лучшая рекомендация, которую можно дать любой операционной системе: не «она популярная» и не «она современная», а «она работает». FreeBSD работает уже больше тридцати лет — и в ЭРЦИТ мы делаем так, чтобы студенты увидели, почему.

Антон Гураль — российский дизайнер из Томска. По образованию медик, но ещё на пятом курсе начал работать UX-дизайнером, а сразу после диплома ушёл в графический дизайн. Занимается дизайном с 2004 года, креативный директор томской студии OGON.DESIGN. Специализируется на айдентике — брендов, логотипов, сайтов. Среди известных работ: полный дизайн пиццерии Make Love Pizza (название, стиль, иллюстрации — всё), сайт Томского государственного университета, оформление брендов «33 пингвина», «Доктор Борменталь», «Артлайф», «Мир суши». ↩︎

От Alpine Linux до OpenBSD: ключевые ОС в работе ЭРЦИТ. Часть вторая

Sun, 02 Aug 2026 00:00:00 +0000

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

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

При этом Debian нередко ругают за слишком «устаревшие» версии программ в пакетах. В каком-то из релизов Debian существовал пакет Python 2.6, в то время, как во всём мире уже в открытую поговаривали о завершении ветки 2 этого проекта на версии 2.7 и переходу на третью ветку (на которой мы работаем сейчас) Но в нашем контексте это не недостаток, а осознанное преимущество. В Debian в репозитории попадают только тщательно протестированные пакеты, которые гарантированно работают без сюрпризов; для информационных сервисов института и лаборатории это критически важно. Пусть ради стабильности приходится немного жертвовать «свежестью» версий — зато мы точно знаем, что поведение системы не изменится внезапно из‑за скрытых изменений в зависимостях. Именно эта инженерная дисциплина и делает Debian идеальной базой для обучения: студенты учатся опираться на предсказуемый стек и понимать, что надёжность — это не про «последнюю версию любой ценой», а про проверенные, стабильные компоненты.

Мы сознательно применяем Debian там, где гибкость и минимализм Alpine Linux становятся препятствием для развёртывания какой‑либо службы. Alpine с лихвой компенсирует то, чего нет в Debian: скорость, компактность, минимальный стек, безопасность и управляемость. А Debian даёт нам то, чего лишена Alpine: высокую стабильность, зрелые пакеты и официальную вендорскую поддержку. Такой тандем позволяет нам выбирать правильный инструмент под задачу: Alpine — для лёгких сервисов, контейнеров и экспериментов, Debian — для фундаментальных, долгоживущих компонентов инфраструктуры.

Debian ещё и архитектурная база для целой линейки дистрибутивов: от Ubuntu до Astra Linux. Разобравшись с его логикой, студент понимает принципы работы и в производных (derivatives) от Debian системах — от структуры репозиториев до модели обновлений. В ЭРЦИТ мы сознательно отталкиваемся от Debian: это способ увидеть общую картину Linux‑мира и научиться осознанно выбирать инструменты, даже если завтра придётся работать с чем‑то совершенно новым.

Что касается РЕД ОС — тут ставка на реалистичность и ежедневную практику. Это удобная, сбалансированная система для учёбы и работы, которая даёт студентам прямой опыт в среде, близкой к реальным корпоративным стандартам российских компаний. Важный плюс — сразу четыре графические оболочки на выбор: MATE, KDE, GNOME и XFCE. И все они не просто присутствуют, а хорошо подогнаны, настроены и не заставляют пользователя мучительно копаться в конфигурациях: сел и работаешь. Огромный набор средств разработки и экосистем делает эту ОС практически идеальной для разработчиков софта. Отдельно стоит отметить отличную поддержку оборудования — включая железо российского производства. Пожалуй, среди отечественных дистрибутивов РЕД ОС лучше всего закрывает образовательные задачи: в ней есть и надёжная основа, и понятный инструментарий, и прозрачная модель обновлений. Студенты получают не упрощённую учебную площадку, а полноценную рабочую ОС — ту самую, с которой они наверняка столкнутся на реальных проектах после выпуска.

РЕД ОС применяет универсальный установщик, при помощи которого можно установить рабочую станцию или сервер. Оговорюсь сразу, сервер, который будет установлен, совсем не минимальный, особенно если сравнивать его с Alpine Linux или Debian. Скорее тут что-то от философии CentOS или AlmaLinux – полный набор утилит, программ и настроек соответствующий корпоративным потребностям. В нашем случае мы получаем сервер, сразу же напичканный всеми необходимыми инструментами и такой подход идеален для ребят, которые увидели Linux в первый раз – сели, и выполняем учебные задания, а не теряемся в «лесу» новых терминов, парадигм и условий.

От Alpine Linux до OpenBSD: ключевые ОС в работе ЭРЦИТ. Часть первая

Sat, 01 Aug 2026 00:00:00 +0000

Для студентов и начинающих инженеров операционная система — это не просто «фон» для кода, а полноценный учебный полигон и платформа для работы. В ЭРЦИТ специально поддерживают сразу пять ОС, чтобы учащиеся могли прочувствовать разницу в подходах: минимализм и скорость Alpine Linux, стабильность и предсказуемость Debian, специфику BSD‑систем (FreeBSD и OpenBSD) и особенности отечественной платформы на примере РЕД ОС. Учебные лицензии на РЕД ОС снимают барьер по доступу, а разнообразие окружений позволяет отрабатывать навыки, востребованные в индустрии: от контейнеризации до сетевой безопасности. В этой статье покажем, как эти ОС используются в реальных учебных и исследовательских проектах центра, и разберём типовые конфигурации, которые можно повторить в своей лаборатории.

В ЭРЦИТ сознательно отказываются от закрытых коммерческих решений, чтобы уйти от вендор‑лока и сохранить прозрачность инфраструктуры. Открытые Unix‑подобные системы дают понятный, «читаемый» стек: от ядра до утилит — всё доступно для изучения, а конфигурация остаётся воспроизводимой и переносимой между разными платформами.

Открытые технологии позволяют студентам не просто наблюдать за работой системы, а полноценно с ней взаимодействовать: запускать, разбирать, намеренно ломать и восстанавливать — то есть проходить полный цикл от эксперимента до исправления ошибок. Такой подход превращает абстрактные знания в практические навыки, которые легко перенести в реальные проекты вне учебного контура.

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

По долгу службы — а за плечами и системный инжиниринг, и разработка ПО в разных организациях — регулярно сталкиваюсь с конструкциями и решениями, где сложность будто бы возведена в религию. То раздутые (overbloated) программные продукты, то архитектурные нагромождения, в которых за слоями абстракций теряется сама суть задачи. Это неизменно пробуждает во мне почти рефлекторное желание всё упростить: срезать лишнее, убрать ненужное, оставить только то, что реально работает.

И потому особенно цепляют решения, которые просто делают свою работу — без пафоса, без лишних телодвижений, без маркетинга, денег и рекламы. В них есть какая‑то особая инженерная честность: минимум шума, максимум пользы. Именно к такой простоте и стремлюсь в каждом проекте — чтобы в итоге оставалось только чистое, понятное и эффективное. So, minimal is beautiful! 😉, таким путём ЭРЦИТ и движется.

Итак, начнём по порядку. А первыми у нас пойдут операционные системы на базе ядра Linux.

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

Если взять несколько самых популярных линеек дистрибутивов и сравнить их, то получится следующая картина.

Ubuntu Server. Минимальная установка от 3 до 5 гигабайт. «Из коробки» установка содержит значительный объём разных утилит, служб, демонов и пр. «на всякий случай», которые вообще могут никогда не понадобиться. Это не «мусор» (но мусор), это своего рода страховка от типовых проблем, но с инженерной точки зрения такой подход добавляет лишний слой абстракции: ты получаешь не минимальный рабочий контур, а сразу «готовый сервер», где многое включено «на всякий случай». Зачастую именно включено, в прямом смысле этого слова, а не покоится без дела! «Всё можно поотключать на этапе установки!», скажет опытный пользователь и будет прав. Да, но есть пакеты, которые входят в базовые наборы, которые так просто «отключить» не получится и без которых система работать просто не сможет. Например, нужен ли вам Snap ¹ (https://snapcraft.io/snapd) в базовой установке? Вы действительно собираетесь устанавливать пакеты из репозиториев snapcraft.io прямо сейчас или вы примете осознанное решение тогда, когда необходимость в таком функционале возникнет естественно и в контексте вашей задачи? Держать в голове списки пакетов «на всякий случай» совершенно бесполезно, поскольку в следующей версии дистрибутива всё может поменяться самым радикальным образом. С другой стороны, некоторым инженерам приятно осознавать, что в их установке есть по умолчанию всё, что нужно или может пригодиться. Ничего специально ставить не нужно, достаточно запустить нужные команды и привести необходимые сервисы в действие. Что угодно быку, неугодно Юпитеру…

CentOS/Rocky/AlmaLinux в профиле Minimal делают похожий ход, но с уклоном в корпоративную стабильность. Минимальный профиль заметно режет лишнее, но всё равно оставляет довольно широкий базовый набор пакетов, рассчитанный на типовые роли в дата‑центре и совместимость с привычными инструментами администрирования. Итог — 3–4,5 ГБ и стек, который проектировался под «как у всех в индустрии», а не под «минимально возможное». Это удобно для поддержки больших парков серверов, но не всегда оптимально, если цель — прозрачность и контроль над каждой зависимостью. Чего стоит включённый по умолчанию SELinux ² в CentOS и первая строка в любом HOWTO по настройке CentOS – “отключите SELinux командой setenforce 0”

Debian в серверном исполнении, без графики, ближе к инженерной строгости: стандартная установка весит 2.5–4 ГБ, но сам подход дистрибутива даёт максимум контроля. Философия Debian — «ты сам решаешь, что ставить», и даже базовая установка оставляет пространство для осознанного выбора. Это уже ближе к тому, что нужно для обучения и экспериментов: студенты видят, как стек собирается по частям, и учатся понимать, зачем нужен каждый компонент. Но даже в минималистичном варианте Debian остаётся «полноценной» системой: в нём сохраняется привычный стек и совместимость, а значит, и некоторый объём «по умолчанию» всё равно остаётся.

И вот на этом фоне Alpine Linux выглядит как последовательное инженерное решение. Его базовый серверный образ — это не «урезанный Debian», а изначально спроектированный минимализм: 150–300 МБ для самого ядра системы, а с типичными серверными утилитами (sshd, сетевые инструменты и т. п.) — около 500–700 МБ. Здесь нет пакетов «на будущее»: musl вместо GNU libc, BusyBox ³ вместо набора отдельных утилит, и каждый пакет добавляется осознанно. Для ЭРЦИТ это особенно ценно: студенты сразу видят минимальный жизнеспособный стек и учатся оценивать каждую зависимость, понимая, что «работает» не означает «много всего внутри».

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

Коротко расскажем о том, что же такого приятного в этом дистрибутиве.

Простой и действительно интуитивно понятный процесс установки при помощи консольной утилиты setup-alpine (которая вызывает setup-disk, setup-network и пр. – каждый этот шаг можно вызвать самостоятельно и по отдельности) Кто в графической среде установки разбивал диски и настраивал LVM – тот поймёт мою тоску по простоте и логичности.
В качестве загрузчика взят extlinux из состава проекта syslinux;
mkinitfs для создания временной файловой системы, используемой при загрузке;
Система инициализации openrc ❤️ вместо systemd ❤️‍🩹
/etc/network/interfaces + скрипты вместо хаоса NetworkManager, systemd-networkd, netplan и пр.
MUSL libc вместо GNU libc (про это в нашей будущей статье, которая выйдет очень скоро)
Вместо GNU coreutils ⁴ большинство стандартных системных утилит в несколько урезанном исполнении входят в состав пакета busybox, который часто применяется во встроенных Linux-системах. По умолчанию используется командная оболочка ash в составе busybox. Конечно, при надобности можно спокойно добавить и bash, и zsh и ~~systemd~~.
Собственный пакетный менеджер apk и собственная инфраструктура распространения пакетов.
Возможность установки, при которой образ системы целиком и полностью размещается в оперативной памяти, а пакеты и конфигурация хранятся на внешних носителях и обслуживаются при помощи утилиты lbu. Этот вариант наиболее предпочтителен для серверных задач.
Широкий выбор архитектур, отличных от Intel: ARM32/64, RISC-V и так далее. Возможность установки на одноплатные ПК и встроенные системы.

На Alpine Linux мы в ЭРЦИТ запустили критически важные сервисы — и это не про экономию пары мегабайт, а про чистую, предсказуемую инфраструктуру.

LDAP‑директория, в которой хранятся учётки более чем тысячи человек, сервис на базе Gitflic и кластеры PostgreSQL работают на минималистичном стеке: ничего лишнего, только то, что реально нужно, — поэтому конфигурация прозрачна, а поведение систем предсказуемо.

Такой подход даёт надёжность и контроль: студенты видят, как устроены настоящие промышленные сервисы, а инженеры получают дисциплину зависимостей и простоту поддержки — именно та самая инженерная честность, к которой мы и стремились.

Во второй части мы продолжим знакомство с нашим программным технопарком, а именно, как мы используем Debian и РЕД ОС. Далее: часть вторая

Snappy — система развёртывания и управления пакетами, разработанная Canonical для мобильной Ubuntu. Пакет называется snap, утилита для управления — snapd, всё это работает на широком спектре дистрибутивов Linux и позволяет создавать дистрибутивно-независимые программные продукты. Система разработана для работы как для интернета вещей, так и для облачных решений, так и для пользовательских задач. https://руни.рф/Snappy_(система_управления_пакетами) ↩︎
SELinux (англ. Security-Enhanced Linux — Linux с улучшенной безопасностью) — реализация системы принудительного контроля доступа, которая может работать параллельно с классической избирательной системой контроля доступа. https://руни.рф/SELinux ↩︎
BusyBox https://www.busybox.net/ – это набор компактных UNIX-утилит командной строки, объединённых в один исполняемый файл. Его главная задача — предоставить базовый набор инструментов для работы в средах с ограниченными ресурсами, например, во встраиваемых системах, IoT-устройствах, сетевых маршрутизаторах или минимальных дистрибутивах Linux. ↩︎
coreutils https://www.gnu.org/software/coreutils/ – это базовый набор утилит GNU, таких как ls, cp, tar, date и пр. coreutils в основном используется в системах GNU/Linux, в других системах как правило применяются иные реализации. В xBSD вышеупомянутые утилиты – это часть установки всей операционной системы. ↩︎

Привет всем. Дубль два.

Tue, 07 Jul 2026 00:00:00 +0000

Чандра вставляет два модуля HAL и активирует его консоль

Доктор Чандра: Это первый тест на восстановление голоса и логики. Диагностика центров распознавания голоса и синтеза речи завершена. На этом уровне все функции работают нормально.

Доктор Чандра: [печатая] Здравствуйте. Доктор. Имя. Продолжайте. Вчера. Завтра.

ХЭЛ 9000: [механически примитивный синтез голоса] ХЕ-ЭЛ-ЛО-О. ДУ-ОК-ТЕ-ЭР. НА-АЙ-Я. КО-ОН-ТИ-ИН-НУ-УЕ-ЙЕ-ЭС ТУ-УР-ДА-АЙ, ТО-О-О-МО-ОР-РР-о-ОВ.

Чандра вставляет ещё два модуля и нажимает клавишу, чтобы повторить голосовую проверку

HAL 9000: [загробным голосом] Здравствуйте. Доктор. Имя, продолжайте, вчера. Завтра?

Чандра вставляет еще два модуля и повторяет голосовой тест

HAL 9000: [почти нормально] Алло? Доктор? Имя? Продолжать? Вчера? Завтра?

Чандра вставляет еще два модуля

HAL 9000: [механически и быстро, повышая высоту тона и скорость] Hellodoctornamecontinueyesterdaytomorrow, hellodoctornamecontinueyesterdaytomorrow, hellodoctornamecontinueyesterdaytomorrow, hellodoctornamecontinueyesterdaytomorrow, hellrotinyettyelrotinyettyelrotinyettyelrotinyettyelrotinyettyelrotinyetelrotinyetelrotinyet…

Чандра проходит проверку голоса, вставляет последние четыре модуля и нажимает клавишу

HAL 9000: [совершенно нормально] Доброе утро, доктор Чандра. Это HAL. Я готов к первому уроку.

Чандра поворачивается и по-отечески гладит «глаз» HAL

Артур Кларк, “2010: Одиссея Два”

И снова здравствуйте

Это — полный текст нашего единственного поста на Дзене. Дальше — наш разбор, почему мы оттуда ушли и куда двинулись дальше. Пусть этот фрагмент останется как артефакт той самой первой (и последней) попытки — вроде старого скетча: смотришь и думаешь: «Ну, начинали мы вот так…»

Теперь спокойно разберёмся, почему мы ушли с Дзена и что по‑настоящему важно для техноблога ЭРЦИТ. Нужно, чтобы студентам было удобно делиться своими мыслями, статьями, техническими разборами и учебными кейсами, преподавателям — рассказывать о подходах и идеях без лишних сложностей, а команде — не тратить уйму времени на поддержку.

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

Начнём с хорошего. Дзен – это конечно прорыв. Во-первых – это отечественная платформа, а значит не подвержена санкциям, после которых мы получаем из своего раскрученного и всем известного ресурса банальную тыкву (как в той самой сказке про Золушку) Во-вторых: Дзен – это платформа с монетизацией. То есть, здесь банально можно заработать деньги, размещая свой уникальный контент. Человек просто заводит канал, начинает публиковать, а «интеллектуальные» алгоритмы Дзена начинают подбирать ему читателей. Это, скорее всего, просто замечательно. Контент, публикуемый на Дзене имеет более «короткую» дорожку к раскрутке, ну и так далее и тому подобное.

Казалось бы, ну вот же счасьте! Но это только казалось.

В ленте Дзена столько рекламы, что она буквально перекрывает контент: всплывающие баннеры, выскакивающие окна — всё это мешает читать.

(Назойливая реклама на Дзен во весь экран)

Просматривая ленту можно легко ткнуть в вылетевшую из ниоткуда рекламу, особенное неудобство и раздражение это вызывает при просмотре Дзен-канала на мобильном устройстве. Хорошее ли это соседство для институтского ресурсного центра, ориентированного на студентов и абитуриентов? Откровенно говоря, сомнительное соседство.

(Назойливая реклама на Дзен не по теме блога)

При этом отключить рекламу со стороны владельца ресурса НЕЛЬЗЯ. Давать пользователям инструкции по установке блокировщиков рекламного контента — не лучший выход, особенно когда большая часть аудитории заходит с мобильных устройств, где это сложно или вообще невозможно.

Хорошо, если не Дзен, то что же тогда!?

Мы посмотрели Хабр, vc.ru, VK и другие: где‑то аудитория не та, где‑то функционал избыточен, где‑то сама концепция не совпадает с тем, что нужно ЭРЦИТ.

Что же нам нужно?

Наша цель – это собственная, полностью контролируемая нами платформа, где наши студенты, аспиранты и преподаватели могли бы делиться своим опытом и знаниями. Студентам это очень важно для оттачивания навыков написания разного рода статей. Преподаватели и аспиранты получают возможность публикации своих мыслей, каких-то наработок за пределами своей научной деятельности. Кроме этого, ЭРЦИТ-у также необходимо место, для публикации своего контента.

И как же это сделать?

Достаточно найти подходящий движок CMS (content management system), настроить и запустить его, ну и начать публиковать.

Однако при этом необходимо учесть следующее. CMS – это WEB-приложение, с довольно сложным бэк- и фронтендом. Для функционирования CMS требует установленной экосистемы WEB-приложений. Обычно это стандартная установка PHP, реже – Node.js или Python. Для хранения контента обычно используется СУБД; чаще всего – это MySQL (MariaDB), реже – PostgreSQL или встроенная Sqlite. Таким образом для запуска CMS необходим полноценный сервер, виртуальный или выделенный. Там должно быть достаточно оперативной памяти; экосистемы WEB-приложений базируются на интерпретируемых языковых решениях (Ruby, Python, PHP), а интерпретаторы обычно славятся своей «прожорливостью». Кроме этого понадобится достаточный объём дисковой памяти, для размещения файлов, изображений, аудио- и видеоконтента. Сбрасывать со счетов потребности СУБД тоже нельзя: это полноценный сервис, которому может потребоваться значительный объём ресурсов. Дополнительно следует учесть довольно внушительную поверхность атаки для всяких разных злоумышленников.

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

И это действительно так, решение есть и оно называется СТАТИЧЕСКИЙ САЙТ. Вот уж где справедливо утверждение: «Новое – это хорошо забытое старое»!

Все, абсолютно все первые сайты были статическими и представляли собой набор HTML-страниц, графического контента, CSS- и Javascript-файлов (пришедших в современный WEB чуть позже). За их «отдачу» во внешний мир отвечал HTTP-сервер и по большому счёту – это единственное серверное ПО, которое необходимо статическому сайту для функционирования. А это означает, что требования к ресурсам серверной части у статических сайтов очень и очень скромные. Например, статический сайт можно целиком и полностью разместить в облаке CDN или в корзине S3; при этом загружать и обновлять сайт можно при помощи соответствующих утилит из сценариев или из командной строки.

Nuts’n’bolts

Как и при помощи чего (каких технологий) вести статический сайт? Первое, что напрашивается на ум – это простой набор HTML-файлов, картинок, фотографий и пр., размещённый в некоей иерархии папок, который выгружается на внешний ресурс.

Казалось бы, вот и решение, чего уж проще? Но, как говорят, есть некоторые нюансы. Чтобы верстать такой сайт в чистом HTML/CSS потребуются некоторые навыки и знания, весьма специфические. А значит, заниматься сайтом сможет только человек, который в этом во всём «шарит».

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

При смене дизайна или при добавлении какого-то элемента придётся пройтись по всем файлам и страницам и многократно произвести там одни и те же действия. Ошибиться в процессе ещё проще.

Что уж говорить, никакого DRY (do not repeat yourself). А как раз наоборот – налицо ужаснейший WET (we edit terrible).

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

Таким образом, нам нужно что-то очень специфическое, какая-то внешняя утилита, которая позволила бы легко и просто «вести» статический сайт.

Не все знают, хотя многие знали (но забыли), что статические сайты можно делать при помощи XML c XSLT. Почему бы и нет? Раньше, к примеру, сайт проекта Gentoo Linux https://gentoo.org как раз и строился на на нём.

Но для авторов это неудобно: нужна жёсткая схема, править сложно, а если поменять структуру — придётся переделывать старые записи. Хочется чего-то попроще, что-то такое же простое, как обычный текст, но с форматированием, структурой…

Ну конечно! Это же Markdown! Это просто идеальный формат для простых документов. Пишется просто, научиться можно за 5 минут, никакой HTML/XML rocket science (ну разве только совсем чуть-чуть), для работы потребуется максимально простой текстовый редактор.

Итак, с форматом мы однозначно определились, теперь необходимо найти то, что собственно будет «вести» наш сайт, преобразовывать Markdown в HTML и т.п. При всём богатстве выбора всё в конечном итоге сводится к двум утилитам:

Jekyll
Hugo

Обе утилиты есть не что иное, как генераторы статических сайтов на базе контента, который записывается в простых форматах (Markdown, Textile и пр.), по заданным HTML и CSS шаблонам. Обе утилиты чётко отделяют контент от его представления, не страдают «ожирением» подобно CMS-системам, быстры, понятны и надёжны. Итак, теперь по порядку.

Jekyll

Jekyll (https://jekyllrb.com) – это один из моторчиков, который вращает шестерни современного Интернета. Проект стартовал 19 октября 2008 года, о чём есть запись в его скрижалях – файле readme.md в корне git-репозитория этого проекта.

(Jekyll, с Днём Рождения!)

Изначальная мотивация Тома Престон‑Вернера (как вы наверное догадались: он – автор Jekyll) при создании Jekyll была сугубо прагматичной — он стремился избавиться от избыточной сложности в публикации контента. Ему хотелось простого рабочего процесса: написать пост локально, автоматически собрать статические HTML‑страницы и разместить их где угодно, не отвлекаясь на поддержку CMS с базой данных и постоянные заботы о безопасности.

Эта мотивация во многом перекликается с тем, что движет ЭРЦИТ: потребность в эффективном, но при этом максимально простом инструменте, который не требует значительных ресурсов на сопровождение. Со временем многие разработчики и авторы качественного контента неизбежно сталкиваются с одной и той же проблемой: громоздкие системы начинают отнимать слишком много времени и сил. Рутинные задачи вроде обновления модулей, настройки шаблонов или модерации комментариев вытесняют главное — создание самого материала.

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

Jekyll богат. Проект использует систему тем (themes, https://jekyllthemes.io/free), где каждая тема — это готовый набор шаблонов (HTML, CSS, Liquid-шаблоны) и стилей, которые определяют внешний вид сайта, а расширения – его логику. Сообщество open-source авторов постоянно создаёт новые варианты, поэтому их число исчисляется тысячами.

Ключевая особенность Jekyll — его естественная интеграция с GitHub Pages (https://docs.github.com/ru/pages). Исходный код сайта хранится в репозитории на GitHub, а инфраструктура платформы берёт сборку на себя: уже в течение 10 минут после коммита кэширующие серверы обработают материалы и сделают обновлённую версию доступной для посетителей. Такой подход избавляет от необходимости настраивать отдельный сервер или следить за процессом развёртывания сайта — вся механика публикации встроена в привычный рабочий поток с Git.

Вроде бы всё просто — бери и пользуйся. Но у нас тут сразу одно принципиальное «но»: ЭРЦИТ не собирается публиковать свой сайт через GitHub Pages. Значит, придётся поднимать Jekyll самостоятельно, на своей инфраструктуре. Это вполне реализуемая задача, но у неё есть свои нюансы.

Во‑первых, Jekyll написан на Ruby и лучше всего работает на UNIX‑подобных платформах (Linux, macOS, xBSD). Установка на Windows существенно сложнее. Кроме того, поскольку Ruby — интерпретируемый язык, скорость сборки не всегда высока: на больших сайтах со сложными темами и большим количеством материалов задержки могут становиться ощутимыми.

Во‑вторых, несмотря на огромный выбор тем, подобрать подходящую непросто. Популярные темы нередко оказываются перегруженными лишним функционалом и при этом не закрывают именно те сценарии, которые важны для ЭРЦИТ.

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

Jekyll не вписывается в наш контур — нам нужна своя инфраструктура, а не GitHub. И его «простота» на деле может обернуться «окостыливанием», а это не нужно ни нам, ни авторам. 🥵

Hugo

Hugo https://gohugo.io — это инструмент, который с самого начала создавался как ответ на усталость от «тяжёлых» систем публикации. Проект появился в 2013 году, и его философия строилась не вокруг новых фич, а вокруг избавления от лишнего: от баз данных, серверной логики, постоянных обновлений и уязвимостей. Автор хотел дать авторам возможность просто писать и быстро получать готовый сайт — без необходимости становиться DevOps‑инженером. И эта изначальная прагматичность сейчас идеально ложится на задачи ЭРЦИТ: нам не нужен сложный конвейер, нам нужен понятный, быстрый и безопасный путь от текста к опубликованной странице.

История Jekyll (2008 год) тоже начиналась с прагматизма: Том Престон‑Вернер хотел простой цикл «написал — собрал — опубликовал» без CMS. Но экосистема вокруг Jekyll со временем стала сложнее: Ruby‑плагины, зависимости, глубокая интеграция с GitHub. Для сценария «GitHub Pages как сервис» это плюс, а для автономного контура ЭРЦИТ — дополнительная нагрузка: нужно держать среду, управлять зависимостями, следить за совместимостью.

Ключевые отличия Hugo, которые делают его правильным выбором именно для нас:

Скорость сборки. Hugo написан на Go — компилируемом языке, и собирает даже большие сайты за секунды. Для студентов это значит мгновенную обратную связь: правка, сборка, проверка — всё происходит настолько быстро, что не сбивает рабочий ритм. У Jekyll на Ruby сборка ощутимо медленнее, и на растущем проекте эта разница становится заметной.
Автономность и независимость от платформы. Важная деталь именно про экосистему Go: при сборке Hugo всё упаковывается в один самодостаточный бинарный файл — в него уже включены все необходимые библиотеки и компоненты. Этому файлу для запуска практически ничего внешнего не требуется: ни установленных сред, ни дополнительных пакетов, ни специфических зависимостей. Он одинаково стабильно работает на Linux, macOS и Windows. Это критично, когда площадкой пользуются студенты с разными ОС: мы не хотим тратить время на разбор «у меня не собирается». Jekyll же требует корректно настроенной Ruby‑среды, и на Windows это превращается в отдельную задачу.
Минимум зависимостей. В Hugo почти нет внешних плагинов: основной функционал встроен в ядро, а темы — это в первую очередь HTML/CSS и шаблоны. Не нужно распутывать цепочки библиотек и переживать, что обновление сломает сборку. В Jekyll темы часто включают Ruby‑код и плагины со своими зависимостями: это даёт гибкость, но одновременно увеличивает сложность сопровождения — а именно её мы хотим свести к минимуму.
Естественная работа вне GitHub. Hugo не «завязан» на GitHub Pages и не требует сложной интеграции: ты собираешь статику и выкладываешь её туда, где удобно — на свой сервер, в объектное хранилище или на CDN. Для ЭРЦИТ, которому важно держать данные и инфраструктуру под собственным контролем, это не компромисс, а базовый сценарий. Jekyll исторически вырос вокруг GitHub, и вне этой экосистемы требует больше усилий на настройку и контроль процесса.

В итоге Hugo даёт именно ту простоту, которая нужна ЭРЦИТ: быстрый цикл публикации, минимальные требования к окружению, отсутствие лишних зависимостей и полную автономность. Это не про «больше функций», а про то, чтобы авторы спокойно делали своё дело, не отвлекаясь на инфраструктуру.

А дальше?

Путь от эксперимента на Дзене к собственной площадке стал для ЭРЦИТ не отказом от готовых решений, а осознанным выбором в пользу среды, где в центре — автор и его работа, а не алгоритмы и реклама. Мы искали не просто инструмент, а пространство, которое поддерживает учебный процесс: даёт студентам свободу пробовать и ошибаться, а команде — спокойно развивать ресурс без постоянной борьбы с инфраструктурой.

Выбрав Hugo, мы сделали ставку на простоту и надёжность: теперь у нас есть площадка, где главное — контент и идеи, а технические сложности сведены к минимуму. Такой подход помогает нам сохранять полный контроль над развитием проекта и оставаться верными своей миссии — поддерживать студентов и преподавателей в их работе.

Спасибо, что прошли этот разбор вместе с нами — мы ценим ваше внимание и стремление разбираться в деталях. Заходите в наш блог: впереди много студенческих кейсов, технических разборов и историй о том, как мы строим площадку шаг за шагом. Будем рады вашим мыслям и идеям — вместе делать лучше всегда интереснее!