NixOS: идея, до которой индустрия доросла только сейчас.

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

История началась в 2003 году, когда исследователь Элко Долстра и его коллеги в Утрехтском университете запустили проект Nix. Это исследовательский проект, который включал пакетный менеджер и собственный декларативный язык. Идея была сделать так, чтобы пакеты и зависимости собирались предсказуемо, не конфликтовали между собой и не превращали систему в хаос после очередного обновления. Чуть позже из этой логики вырос NixOS, где тот же подход применили уже ко всей операционной системе.

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

Это особенно интересно на фоне обычных Linux‑дистрибутивов. Там текущее состояние системы часто является результатом длинной цепочки действий: что‑то поставили, что‑то удалили, где‑то поправили конфиг, где‑то забыли. В NixOS логика другая: ты описываешь желаемое состояние, а система приводит машину именно к нему. Если новая конфигурация не взлетела, предыдущее состояние никуда не исчезает.

😏 Почему NixOS набирает популярность именно сейчас? Потому что индустрия наконец доросла до его сильных сторон. Чем больше у команды окружений, CI/CD, инфраструктуры как кода и цены ошибки, тем важнее воспроизводимость и предсказуемость. То, что раньше выглядело как нишевая экзотика, сегодня все чаще выглядит как очень здравый инженерный выбор.

Многие современные immutable‑системы по сути идут в ту же сторону, куда NixOS пошел еще много лет назад.

А если хочется не просто прочитать про Nix, а разобраться, как он работает на практике, приходите на наш открытый воркшоп.

📹 Открытый воркшоп в рамках ИнженеркаТех Плюс, 18 марта в 19:00 по МСК. Александр Сергеев из сообщества RULKC, Russian Linux Kernel Community, расскажет про Nix и функциональный подход к пакетам и сборке.

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

Зарегистрироваться тут

Как появился Docker?

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

В 2013 году биткойн впервые пробивает тысячу долларов, а Сноуден сливает PRISM. У людей начинает появляться ощущение и понимание, что интернет-сервисы, которыми они пользуются каждый день, могут быть частью конвейера доступа к данным. На этом фоне у всего IT живёт боль в виде окружения. Чтобы запустить приложение в среде, нужно было вручную настраивать сотни зависимостей. Малейшее несовпадение версии и всё падает. Виртуальные машины помогали, но они были слишком тяжелыми.

В этом же году в компании dotCloud во главе с его основателем Соломоном Хайксом делали сервис, в котором ты загружаешь код и он запускается на сервере без ручной настройки. Для этого им нужен был внутренний инструмент, который упаковывает приложение вместе с окружением.В какой-то момент они поняли, что их облачный бизнес идет так себе, а вот штука для управления контейнерами получился бриллиант.

Так Хайкс впервые представил Docker на PyCon. В своем докладе он упоминал, что айти индустрия страдала от проблемы под названием “матрица ада”. То есть чтобы запустить каждое приложение в каждой среде, нужно было вручную настраивать сотни зависимостей. Малейшее несовпадение версии библиотеки и всё падает. Виртуальные машины помогали, но они были слишком тяжелыми. Это оказалось сильнее, чем первоначальная бизнес-идея dotCloud.

В Linux уже были на тот момент механизмы изоляции, но собрать это можно было, однако повторить - сложно. Первопроходцы Solaris Zones в 2004 году были не хуже. Но Docker единственный упаковал контейнеры так, что ими стало удобно пользоваться: рецепт сборки в Dockerfile, слои для переиспользования и публичный реестр по умолчанию. Он победил за счет удобного UX.

Докер так быстро стал стандартом, что другие игроки испугались монополии на формат. И чтобы не расколоть индустрию, закрепили нейтральный стандарт - OCI (Open Container Initiative).

Подписывайтесь на наш Telegram-канал. Там мы публикуем полезные подборки от инженеров и делимся инсайтами.

С чего и как начинался Apache?

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

Apache Kafka, Apache Spark, Apache Hadoop, Apache Nifi, Apache Iceberg… сколько ещё «Apache-чего-то» мы знаем? Это не бренд-линейка и не одна компания, а следствие того, что в середине 90-х несколько инженеров собрали процесс, который умеет бесконечно выпускать инфраструктурные проекты. 

В начале веба одним из главных серверов был NCSA httpd, написанный при Университете Иллинойса и быстро ставший популярным. Однако в момент поддержка затормозилась из-за банального увольнения сотрудника. Тем временем интернет рос, а с ним нагрузка и требования, поэтому команды выкручивались так, как некоторые живут до сих пор: брали исходники и накладывали поверх свои маленькие исправления, которые инженеры пересылали друг другу по почте. Пришло все к тому, что у всех был один и тот же сервер, но собранный из разных заплаток и никто не был уверен, у кого версия “правильная”. 

В 1995-м несколько людей, которым это надоело, решили начать собирать улучшения вместе, превращая россыпь патчей в единый, поддерживаемый продукт. Так появился ранний Apache HTTP Server. Брайан Белендорф (один из основателей) утверждает, что предложил название Apache из уважения к индейскому племени апачей за их выносливость и тактическое мастерство. Позже кто-то из команды заметил, что это звучит как «a patchy server» с дословным переводом - “сервер из заплаток”. Шутка всем понравилась и она стала частью фольклора. 

Позже основатели поняли, что ценность не только в самом сервере, а в том, как они его делают - открыто, через обсуждения и самое важное, через идею, что комьюнити важнее кода. Когда Apache HTTP Server стал критически важным для отрасли, в 1999 году оформили Apache Software Foundation как некоммерческую организацию, которая даёт проектам юридическую оболочку, инфраструктуру и стандарты управления, чтобы они не зависели от одного автора. Так Apache стала не «серия продуктов», а фабрикой зрелых open-source проектов. 

Фонд НЕ пишет Kafka или Spark “в офисе”, он предоставляет правила и среду, в которой разные команды могут запускать и развивать проекты. Сделано это для того, чтобы ими можно было пользоваться в продакшене десятилетиями, а не пока стартап не продался. В мире Apache считается, что если у проекта крутой код, но нет живого сообщества - значит проект мертв. Именно поэтому у них такая жесткая процедура приема проектов, где проверяют не столько строчки кода, сколько то, умеют ли люди договариваться. На сегодняшний день под крылом Apache находится более 350 проектов.

Apache стал Apache потому что когда-то люди устали жить на локальных костылях и сделали общий проект из “заплаток”. Превратили этот опыт в организацию, которая умеет масштабировать не код, а сотрудничество. Поэтому сегодня ты видишь одно слово в названии у сотен инструментов. Это метка зрелости процесса и того, что проект построен так, чтобы пережить своих создателей и остаться в проде, где ему и место.

Подписывайтесь на наш Telegram-канал ИнженеркаТех. Там мы публикуем полезные подборки от инженеров и делимся инсайтами.

Краткая история появления паролей и их эволюция

Помнишь свой первый пароль, когда только-только появился онлайн-банкинг? Дай угадаю - 123456? Или, может, qwerty?

С первых крупнейших утечек эпохи бума интернета (привет, Yahoo и их 3 миллиарда слитых аккаунтов!) многие так и не осознали, насколько важно ставить надежный пароль. А те, кто осознал, упустили другой пугающий факт: сегодня даже самый качественный и сложный пароль не спасает от взлома.

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

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

🤬 Как ломалась наша защита:

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

2000-е, промышленные катастрофы. Интернет взлетел, миллионы людей в сети. Но компании хранили наши пароли прямо в открытом виде. Хакеры вскрывали базы (как было с сервисом RockYou) и с ужасом понимали, что половина планеты защищает свои деньги словом password.

2010-е, иллюзия контроля. Индустрия запаниковала и ввела СМС-коды и Push-уведомления. Кажется, теперь-то мы спасены? Нет. В 2022 году хакеры сломали мега-корпорацию Uber гениально просто. Они купили пароль сотрудника в дарквебе и закидали его телефон пушами: «Разрешить вход?». Через полчаса непрерывного спама мужик просто устал, психанул и нажал «Да». Человеческая психика стала главной уязвимостью.

😏 Наши дни

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

Встречайте Passkeys. Больше никаких паролей на серверах. Ваш телефон создает уникальную математическую пару ключей. Открытый ключ улетает на сайт, а закрытый - намертво вшивается в чип вашего смартфона и никогда его не покидает.

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

🛡С праздником! Берегите свои данные.

Как защищать данные для шифрования файлов в репозитории, сканирования утечек и организации внешнего хранения секретов, можно узнать в нашем хендбуке DevSecOps: защита данных в Git и Kubernetes на примере YandexCloud. Ссылка в нашем телеграм-канале