Если вы пользуетесь Linux и регулярно созваниваетесь через Discord, Teams, Telegram, Телемост и другие программы, то наверняка сталкивались с проблемой шумоподавления.
Где-то встроенный шумодав работает нормально, где-то его нет вообще.
Я раньше использовал NoiseTorch (долго и велосипедно настраивать), пробовал EasyEffects (очень громоздко и избыточно). А недавно нашёл HushMic.
Устанавливаешь, запускаешь, выбираешь свой физический микрофон — и получаешь отдельный виртуальный источник уже с шумоподавлением. И всё это настраивается буквально за пару минут и кликов.
Джастин Шрёдер показал любопытный образец того, как сегодня может вестись разработка. В твите Шрёдер выложил фотографию, на которой MacBook смотрит встроенной в крышку веб-камерой на собственный экран через зеркало. Как утверждает разработчик, таким способом он улучшает поддержку графики AMD Radeon в Omarchy.
Как объясняет в комментариях к твиту Шрёдер, зеркало как раз позволяет при отладке оценивать не скриншот, а изображение на физическом дисплее ноутбука. Что именно происходит на экране, разобрать тяжело из-за невысокого разрешения снимка и зеркального отражения. Если судить по его другому твиту, саму веб-камеру под Linux Шрёдер запускает с помощью T1Bridge — открытого проекта Standard Agents, добавляющего поддержку Apple T1 и iBridge, включая камеру FaceTime HD. Справа (слева на отражении в зеркале) открыт интерфейс приложения LocalSend: в папку /home/justin-schroeder/Downloads только что передали две фотографии в файловом формате HEIC. Слева, судя по характерным строкам Ran и Explored, работает Codex CLI компании OpenAI.
Сам Шрёдер — разработчик открытого программного обеспечения и создатель dmux, инструмента для параллельной работы с агентами программирования. Эта утилита запускает Codex, Claude Code и другие агенты в отдельных панелях tmux, создавая для каждой задачи отдельную ветку и рабочий каталог Git. Беглый поиск показывает, что к Omarchy Шрёдер имеет непосредственное отношение как контрибьютор: 9 сентября он отправил в проект патч, исправляющий работу адаптера Wi-Fi фирмы Broadcom на MacBookPro13,3. Судя по всему, сейчас он как раз занимается доводкой Omarchy на этой машине.
Переход на Astra Linux SE 1.8 — вопрос времени для многих организаций. Регуляторы требуют, но детальной информации о том, что именно изменилось, на рынке мало. Документация есть, а живого разбора с настройкой — нет.
Программа: ⭐ Что изменилось в версии 1.8 по сравнению с 1.6/1.7 ⭐ Почему миграция вызывает сложности и где возникают типичные ошибки ⭐ Настройка защиты и администрирование в реальном времени ⭐ Курсы по Astra Linux SE 1.8: для пользователей и администраторов. Даты старта, специальная цена для участников вебинара
Что нужно для участия: базовое знание Linux, опыт с Astra Linux SE 1.6/1.7 будет плюсом.
📆 Когда: 11 сентября в 17:00 (Мск) 👨🎓 ️Спикер: Брейман Александр, эксперт в области разработки и архитектуры ПО
OpenAI объявила о доступности предварительной версии десктоп-приложения ChatGPT для платформы Linux, предоставляющего интерфейс для использования ChatGPT, ChatGPT Work и ИИ-агента Codex. Приложение доступно для загрузки в форматах deb и rpm в сборках для архитектур x64 и ARM64. Заявлена поддержка дистрибутивов Ubuntu 24.04/26.04, Debian 13 и Fedora 43/44.
Антипаттерн при работе с VPS: почему не стоит постоянно работать под root? Работать под root на VPS удобно: перед командами не нужно вводить sudo. Но ошибка может затронуть весь сервер, а безопасность VPS требует разделять обычные и административные действия.
Почему работа под root удобна и опасна? В Unix доступ к файлам и управление процессами зависят от пользователя и его групп. Root может изменять системные файлы, управлять службами, пакетами и сетью. При постоянной работе под root ошибка в команде способна затронуть системные файлы и службы. Опечатка в пути команды удаления или ошибка в скрипте, запущенном от root, может стереть системные файлы, изменить права на каталоги и остановить сервисы. При запуске от обычного пользователя ущерб чаще ограничен его правами. Украденный ключ, разрешающий вход под root, или пароль этой учётной записи сразу дают административные права. Ключ обычного пользователя даёт доступ только с его правами. Получение root-прав зависит от настроек sudo, пароля, уязвимостей и ошибок конфигурации.
Как правильно: отдельный пользователь и sudo.
В Ubuntu или Debian создайте пользователя и добавьте его в группу sudo:
adduser operator
usermod -aG sudo operator
Добавьте публичный ключ в файл .ssh/authorized_keys в домашнем каталоге нового пользователя и проверьте вход по SSH. Затем задайте параметр в
/etc/ssh/sshd_config:
PermitRootLogin no
Проверьте конфигурацию и примените изменения без разрыва текущих подключений:
sshd -t && systemctl reload ssh
Мини-чек-лист безопасного старта на VPS
• Отдельный пользователь создан, команды запускаются через sudo.
Всё, что оно делает - показывает текст текущей песни в верхней панели. Тексты песен извлекаются с помощью lrclib.net. Также есть небольшое меню настроечек, текст можно переместить в левый или правый угол панели. Тестировал его на Fedora 44 Workstation, GNOME 50. Вроде работает. Публиковать его я не хочу, мне лень этим заниматься. Но если кто-то хочет потестить - оно валяется на github
Адриан Мастронарди (занимается созданием и управлением инженерными организациями, стоящими за выпуском ПО) выпустил книгу под названием «Полсекунды». В ней подробно рассматривается попытка создания бэкдора в xz в 2024 году. Книга распространяется бесплатно под (несвободной) некоммерческой лицензией CC, запрещающей создание производных работ.
Как я «размораживал» тачпад ноутбука Acer Aspire ES1-521
Был у меня ноутбук Acer Aspire ES1-521. У ноутбука имелась возможность отключить тачпад, чтобы не мешался во время работы с клавиатурой. Делалось это по Fn + F7. Вот только тачпад после такого действа зависал намертво: повторное нажатие не помогало. Даже перезагрузка оказывалась бессильной! Единственный способ выйти из затруднительной ситуации — выключить ноутбук, подождать пару часов и включить снова.
По всей видимости, проблема в железе. Возвращать Windows я не собирался. И поэтому в ней не проверял. Обновлять BIOS (с версии 1.07) не хотелось, дабы не испортить столь ценный аппарат окончательно. Ещё надо было бы попробовать имитацию извлечения батареи (делается она продолжительным нажатием скрытой кнопочки на донышке, совсем как кнопка сброса роутера к заводским настройкам). Но что-то мне подсказывало, что без толку... Да и непрактично это.
В итоге я уверил себя в том, что временное отключение тачпада — функция полезная и заманчивая, но не жизненно необходимая.
Кроме большой проблемы, была и маленькая. Вот сидишь себе спокойно в Kali Linux с Xfce (например, в версии 2026.3), никаких сочетаний Fn + не нажимаешь. Закрываешь крышку ноутбука, открываешь, снова закрываешь и снова открываешь (по сути закрываешь крышку на экране ввода имени пользователя и пароля). А тачпад после таких манипуляций не отзывается.
Чисто интуитивно я решил глянуть на загруженные драйверы. Просматривая выданный командой lsmod | sort список сверху донизу, я заприметил модуль ядра psmouse. Выгрузил его, загрузил... О, чудо! Тачпад заработал как ни в чем не бывало. Оставалось только приурочить перезагрузку модуля к открытию крышки ноутбука.
На этом шаге мне пришлось-таки залезть в Сеть. Пришёл к такому решению, ибо асинхронное ожидание в Python я не осилил:
def listen_for_lid_open_event():
process = subprocess.Popen(
['upower', '--monitor-detail'],
stdin=subprocess.DEVNULL,
stderr=sys.stderr,
stdout=subprocess.PIPE)
while not process.poll():
raw_line = process.stdout.readline()
decoded_line = str(raw_line, DEFAULT_ENCODING)
lid_open = 'lid-is-closed: no' in decoded_line
if lid_open:
reload_psmouse_module()
Есть у нас один заказчик. Весь в Windows. Решил переезжать на российское. На бумаге всё выглядит понятно: выбирает дистрибутив, разворачивает сервисы, переносит приложения, постепенно уходит от прежнего стека. Упирается в версию Samba, которой в родных репах нет. Пакет конфликтует с системными библиотеками. Yum (dnf) не может разрешить зависимости и ломается. Решили просто: подключили репы CentOS, перетерли половину системных пакетов. На тесте взлетело. В продакшен – уже риск.
Вопрос, который сразу возникнет: «А почему просто не собрать Samba из исходников?»
Для тестовой лабы – ок. Для прода с сотнями пользователей – нет. И вот почему.
Почему это проблема, а не просто настройка
Когда для домена (Samba, Kerberos, DNS) вы собираете из исходников илилезете в чужие репозитории – вы теряете три вещи:
Поддержку вендора В договоре чёрным по белому: только штатные репозитории. Подменили пакет или поставили самосбор – тикет закроют фразой «сами собрали, сами и поддерживайте».
Безопасные обновления Выходит апдейт от вендора. При левых репах – dnf update падает с конфликтом зависимостей. При самосборе – вы вообще не получите апдейт, чинить каждую CVE придётся руками.
Сертификацию (ФСТЭК/Минцифра) И левый репозиторий, и самосбор аннулируют сертификат моментально. На проверке это увидят.
Важное уточнение для тех, кто вспомнит EPEL EPEL подключают к RHEL для установки дополнительного софта, которого нет в базе. Он не трогает системные пакеты. В нашем кейсе – родной репозиторий ОС не содержал нужной версии критического пакета (Samba). Пришлось лезть в чужой репозиторий и заменять базовые пакеты. Это совсем другая история.
Коротко про вендора
Вендор скажет ровно одно: «Ваша система — не наша сборка. Приходите, когда переустановите без левых реп и самосборов».
Никто не приедет, не поправит, не подстрахует. Вы один на один с костылём.
Вывод
Столкнулись с тем, что роль не ставится из родного репозитория?
Плохие решения: подключать левые репозитории и подменять пакеты, собирать из исходников в продуктиве.
Правильные решения: Взять другую российскую ОС, где эта роль работает из коробки. Потребовать от вендора добавить нужные пакеты в свой репозиторий. Отказаться от этой роли/стека, если ОС его не тянет.
Подмена пакетов в продуктиве – не выход, а вход в ад техподдержки.
⚡️ Linux Roadmap: подробный практический курс от нуля до уверенного администратора в 2026 году
Это пошаговый маршрут изучения Linux с упором на практику. Каждый раздел содержит объяснение «почему это устроено именно так», разбор команд и обязательные задания, которые нужно выполнить руками в терминале. Чтение без повторения навыка не даёт — держите терминал открытым рядом с этим текстом.
Как работать с этим курсом: идите сверху вниз, не перепрыгивайте разделы; каждую команду набирайте руками, а не копируйте; в конце каждого блока выполняйте задание; специально ломайте систему в виртуалке и чините — это лучший способ учиться.
Собрал клиент AmneziaVPN для Ubuntu 22 ...и сделал это через Dockerfile, который Вы можете отредактировать для любого дистрибутива
Зачем понадобилось
Свежие блокировки Роскомнадзора отрезали меня от различных VPN, которыми я периодически пользовался для доступа к зарубежным продуктам, официально в РФ не представленным. Например, к Gemini.
Моей последней надеждой стала self-hosted Амнезия. Я восстановил доступ на всех своих устройствах, кроме одного - домашнего ПК под GPU-вычисления, работающего на Ubuntu 22.04.
Последние версии клиента AmneziaVPN 22-ю убунту не поддерживают: релизы для Linux собираются на Ubuntu 24.04, поэтому есть ограничения в поддержке дистрибутивов из-за версии glibc.
Как это может помочь другим
22-я убунта - это всего лишь пример. Если Ваши вкусы специфичны, да настолько, что AmneziaVPN не работает на выбранном дистрибутиве, докерфайл с лёгкостью можно адаптировать. Единственная дистрибутиво-зависимая часть в докерфайле - вызов apt-get
Что сделано
Я подготовил докерфайл, который из чистого образа ubuntu:22.04 устанавливает Qt и все прочие зависимости, качает репозиторий клиента AmneziaVPN, собирает проект и готовит инсталлятор. Выходная сборка, for my best knowledge, аналогична релизам авторов проекта. Вот здесь PR в официальный репозиторий со всеми объяснениями.
Я писал докерфайл в личных целях, мог что-то не учесть, открыт к критике и предложениям.
Как воспользоваться
Подготовка
Докерфайл качает официальный Qt-инсталлятор (я работал по инструкции вот здесь), поэтому потребуются активный Qt-аккаунт и IP-адрес не из РФ. Qt запрещает скачивания по российским IP-адресам. Нужно либо включить VPN, либо собирать на хостинге за пределами РФ (например, Казахстан). Да, я знаю, что это недостаток - пока не придумал, что с этим делать.
По умолчанию инсталлятор Qt смотрит на учётные данные в файле $HOME/.local/share/Qt/qtaccount.ini. Этот файл прокидывается в докер, поэтому он должен быть на машине для сборки. Если этого файла нет, можно перед запуском докера скачать любой GUI/CLI установщик Qt и пройти в нём страницу логина. Если не хочется возиться с инициализацией аккаунта на машине, то я оставил лазейку по прямой передаче логопасса в докер.
Сборка
Скачать мой форк репозитория, перейти в папку с ним и запустить докер.
4 × V100 SXM2 против современных GPU: ищем команду для комплексного баттла архитектур в ML-инференсе
Привет, Хабр!
Пока все охотятся за новыми GPU, мы разворачиваем проект NeuralTower на древнем, но очень неплохом enterprise-железе: 4 × NVIDIA V100 SXM2 32GB (суммарно 128 GB HBM2). Внутри мезонинов карты объединены по сверхбыстрой шине NVLink, а сами мезонины подключены к плате через четыре физических разъема PCIe x16 под управлением двух чипов-свитчей PLX. Работает всё это на вручную собранном Gentoo Linux + вручную собранные библиотеки.
Пока на коленках, но мы победили софтверные ограничения vLLM для SM 7.0 под CUDA 12.x, упаковали стек в Docker, заменили FlashAttention на адаптированный xFormers и принудительно зафиксировали float16. Система стабильно держит Tensor Parallelism на все 4 карты, с учетом гибридной топологии.
Цель: провести многогранный сравнительный тест
Мы хотим столкнуть лбами нашу old-enterprise топологию с современными картами архитектуры SM 8.0+ (например, 4 × RTX 3090 / 4090, 4 × A100 или H100).
Для теста планируем запускать тяжелые модели: Qwen-32B в чистом FP16 или Llama-70B в квантовании AWQ/GPTQ. Просто у нас нет больше чем 128Gb, а так модели можем согласовать.
Мы ищем единомышленников с доступом к современным 4-карточным ригам, чтобы собрать комплексную матрицу метрик, а не только банальный TPS:
Метрики инференса: Time-to-First-Token (TTFT), общая скорость генерации TPS и задержки при разной длине контекста.
Аппаратная эффективность: Насколько внутренний NVLink и PLX-свитчи с поддержкой GPUDirect P2P на старом железе обходят по шине «гражданские» материнские платы с PCIe x16/x8 при распределении весов через Tensor Parallelism.
Эффективность памяти: Поведение и утилизация KV-кэша vLLM на пропускной способности HBM2 против современной GDDR6X/HBM3.
Экономика вычислений: Соотношение чистой производительности к стоимости б/у оборудования и его энергопотреблению (Performance per Watt / Per Dollar).
Отдельный открытый вопрос: очень хотелось бы сравнить влияние архитектур на итоговое качество генерации (perplexity / alignment), но в команде пока идут споры о методике замера на разных версиях движков. Если у вас есть готовые идеи, как это корректно протестировать - будем рады обсудить.
Что с нас, что с вас?
С нас: Полностью готовые Docker-контейнеры. Развертывание тестового окружения на вашей стороне займет 10 минут. Думаем, Docker/Linux x64
С вас: Запуск тестов на вашем железе и сбор логов.
Когда?
Возможны варианты. Но надеемся уже провести тесты в середине лета.
Все результаты мы объединим, детально проанализируем и опубликуем здесь же, на Хабре, в виде большого технического исследования с графиками.
Если у вас есть подходящие мощности и вам интересно принять участие в баттле железных архитектур - пишите в комментарии или в ЛС! Давайте сделаем крутой материал.
Здесь многих морщит, когда они видят откровенно ИИ-шный текст, недостаточно хорошо отражающий суть того о чем он как бы написан. НО!
Вот появилась тут буквально вчера статья на тему "старый ноутбук, мало памяти, zram, swapspaces". Явно - писана с помощью ИИ, и как справедливо было замечено - из серии "как нарисовать сову": долго готовим рабочее место и инструменты, потом рисуем один глаз, второй, ну а потом остальную сову.
Провисела она тут весьма недолго, пока писал комментарий - ее закидали помидорами и убрали. Тем не менее, по сути статья полезная: я взял и попробовал. И оно, оказывается, работает, и даже неплохо. Просто автор не дописал, как "дорисовать остальную сову".
Автор, если ты это видишь - сделай людям доброе дело, распиши подробнее. Я б сам написал - но получится, типа украл чужую статью, а это не очень красиво. Но тема-то интересная...
Задача: 1. чтобы раскладки us и ru переключались как обычно, а rs - по требованию. 2. Чтобы при попытке переключить раскладку - мы возвращались в привычный цикл usru
Зачем: Третья раскладка бывает полезна, но зачастую она не нужна во время работы и конфликтует с мышечной памятью, которая за 30+ лет перед клавиатурой выучила, что есть только две раскладки :)
Что же делать: На примере - добавим раскладку сербской латиницы, причём - вариант QWERTY, где Z и Y сидят на привычных местах.
Добавляем в систему раскладку сербской латиницы в варианте Qwerty, делается это через Keyboard -> Layouts
Заходим в терминал и пишем: setxkbmap -query Видим примерно такое:
вешаем на одно сочетание клавиш (у меня, например, для удобства, Alt+Shift+1) (выбираем на вкус для X11 или Wayland)
Скрипт намбер ту:
#!/bin/bash
FILE1="/tmp/clp.saved"
FILE2=$(mktemp /tmp/clp.XXXXXX)
trap 'rm -f "$FILE2"' EXIT
# xclip -o -selection primary > "$FILE2"
wl-paste --primary > "$FILE2"
if [ ! -s "$FILE1" ] || [ ! -s "$FILE2" ]; then
notify-send "Ошибка" "Нет текста для сравнения"
exit 1
fi
meld "$FILE1" "$FILE2"
вешаем на другое сочетание клавиш (у меня, например, Alt+Shift+2)
Изолента и реактивный двигатель — вот всё, что нам нужно. Лучше, чем ничего, по крайней мере… Первый скрипт сохраняет выделенный текст во временный файл /tmp/clp.saved. Второй скрипт сохраняет выделенный текст в другой временный файл /tmp/clp.XXXXXX, открывает их оба в нашем любимом Meld, мы на всё это дело любуемся, сравниваем, закрываем Meld, после чего скрипт удаляет этот второй временный файл со случайным постфиксом, чтобы не болтался зря. Первый, /tmp/clp.saved пока остаётся, чтобы было удобно с одним и тем же «первовыделенным» сравнивать несколько вариантов, и его всегда можно переопределить первым скриптом.
lazy-tmux — быстрый и «ленивый» менеджер сессий tmux
Весь мой рабочий процесс происходит внутри сессий tmux. Долгое время я использовал tmux-resurrect + tmux-continuum. Они работали… но с нюансами. Иногда терялись все сохранённые сессии, а при множестве активных сессий всё оставалось загружено в память, в частности, запущенные nvim процессы, которые поднимаю lsp, что со временем отъедало все больше и больше ОЗУ.
Я мне нужен был инструмент, который показывает все сессии в виде дерева, но загружает их только когда я впервые перейдёте в одну из них.
Так родился lazy-tmux, написанный на Go. Ключевые фичи:
Сохраняет текущую сессию, конкретную сессию или все сессии целиком. Снимки сохраняют окна, панели, layout, команды (например, npm, docker-compose, редакторы) и опционально scrollback историю шела.
Ленивое восстановление: поднимается только выбранная сессия. RAM не расходуется на всё сразу.
Интерактивный TUI браузер с деревом сессий, окон и панелей, таблицей с активными командами, временем последнего снимка, количеством окон/панелей и статусом сессии. Поддержка fuzzy search для быстрого поиска.
Навигация и полное управление сессиями и окнами с клавиатуры в TUI браузере сессий.
Гибкая сортировка сессий и окон через флаги --session-sort и --window-sort
Можно заменить встроенный TUI на fzf, использую облегчённый бинарник.
Автосейв через фоновый демон, периодически снимающий все сессии на диск.
Восстановление при старте tmux для автоматизации workflow.
Проект ещё молодой, но буду рад любой помощи и идеям по улучшению: GitHub issues
Команда проекта ReactOS сообщила о значительном прогрессе в обеспечении совместимости с проприетарными видеодрайверами. Благодаря серии исправлений и внедрению подсистем KMDF (Kernel‑Mode Driver Framework) и WDDM (Windows Display Driver Model) удалось реализовать поддержку примерно 90% драйверов GPU для Windows XP и Windows Server 2003. До внесения изменений запуск многих фирменных драйверов либо заканчивался сбоем, либо работал нестабильно. Теперь же в свежих ночных сборках ветки 0.4.16 наблюдается устойчивая работа драйверов от различных производителей, включая Intel, NVIDIA и AMD.
Среди прочего, продемонстрирована работа ReactOS на реальном оборудовании и загрузка с установленными драйверами для видеокарт уровня Intel GMA 945, Nvidia GeForce 8800 GTS и GTX 750 Ti и AMD Radeon HD 7530G. Отдельно отмечается успешный запуск на мобильной графике, например Nvidia Quadro 1000M, где помимо 2D/3D‑ускорения также функционируют звук и сетевые подключения. В дополнительных тестах также подтверждена работа на более редких и устаревших конфигурациях, включая ноутбук с Radeon Xpress 1100, а также на высокопроизводительных видеокартах, таких как Nvidia GTX Titan X.
Особую роль сыграл принятый в основную ветку проекта патч для подсистемы управления памятью, который повысил стабильность работы драйверов и снизил количество сбоев при инициализации графических адаптеров.
Разработчик Роман Гущин (Roman Gushchin) из команды мейнтейнеров ядра Linux в Google объявил о доступности новой ИИ-системы Sashiko для проверки кода с помощью искусственного интеллекта. Внутри Google она уже используется для выявления проблем, и теперь она доступна публично и охватывает все сообщения, отправленные в список рассылки ядра Linux. Гущин пояснил, что Sashiko смогла обнаружить около 53% ошибок на основе неотфильтрованного набора из 1000 недавних проблем ядра Linux с меткой «Исправления:».
NixOS: идея, до которой индустрия доросла только сейчас.
Кажется, NixOS наконец выходит из категории системы «для своих» и становится все заметнее в инженерной среде. Это закономерно: он очень точно попал в проблемы, с которыми команды массово столкнулись только в последние годы.
История началась в 2003 году, когда исследователь Элко Долстра и его коллеги в Утрехтском университете запустили проект Nix. Это исследовательский проект, который включал пакетный менеджер и собственный декларативный язык. Идея была сделать так, чтобы пакеты и зависимости собирались предсказуемо, не конфликтовали между собой и не превращали систему в хаос после очередного обновления. Чуть позже из этой логики вырос NixOS, где тот же подход применили уже ко всей операционной системе.
В этом и был главный поворот. Nix с самого начала смотрел на систему не как на набор вручную настроенных файлов и команд, а как на то, что можно описать целиком. Пакеты хранятся изолированно, разные версии могут спокойно жить рядом, а состояние машины задается через конфиг. За счет этого обновления становятся атомарными.
Это особенно интересно на фоне обычных Linux‑дистрибутивов. Там текущее состояние системы часто является результатом длинной цепочки действий: что‑то поставили, что‑то удалили, где‑то поправили конфиг, где‑то забыли. В NixOS логика другая: ты описываешь желаемое состояние, а система приводит машину именно к нему. Если новая конфигурация не взлетела, предыдущее состояние никуда не исчезает.
😏 Почему NixOS набирает популярность именно сейчас? Потому что индустрия наконец доросла до его сильных сторон. Чем больше у команды окружений, CI/CD, инфраструктуры как кода и цены ошибки, тем важнее воспроизводимость и предсказуемость. То, что раньше выглядело как нишевая экзотика, сегодня все чаще выглядит как очень здравый инженерный выбор.
Многие современные immutable‑системы по сути идут в ту же сторону, куда NixOS пошел еще много лет назад.
А если хочется не просто прочитать про Nix, а разобраться, как он работает на практике, приходите на наш открытый воркшоп.
📹 Открытый воркшоп в рамках ИнженеркаТех Плюс, 18 марта в 19:00 по МСК. Александр Сергеев из сообщества RULKC, Russian Linux Kernel Community, расскажет про Nix и функциональный подход к пакетам и сборке.
Если вы хотите получить полный контроль над окружением и наконец закрыть вопрос воспроизводимых сборок, этот воркшоп для вас. Разберем ключевые концепции Nix и наглядно покажем, чем он отличается от привычных систем управления пакетами.
