LINUX.ORG.RU

Devuan Excalibur 6

 , ,


4

6

Основные новые возможности и изменения в Devuan 6 Excalibur по сравнению с предыдущим релизом (Devuan 5 Daedalus):


🧩 1. Обязательное объединение /usr (Merged-/usr)

  • Теперь объединённый /usr — обязательный.
  • Все каталоги /bin, /sbin, /lib* символически связаны в /usr.
  • При обновлении с Daedalus необходимо установить пакет usrmerge до апгрейда.

🐧 2. Основа – Debian 13 Trixie

  • Devuan 6 наследует все улучшения Debian 13 (ядра, драйверы, пакеты, инструменты).
  • При этом сохраняет основную цель проекта Devuan — предоставление возможности работы с init-системами, отличными от systemd (sysvinit, runit, OpenRC).

🧱 3. Обновлённый инсталлятор и образы

  • Новые установочные ISO и Live-образы для amd64 и других архитектур (arm, riscv64, ppc64el).
  • Минималистичные и «netinstall» варианты доступны на mirrors.
  • i386 больше не поддерживается официальным образом ядра — только пакеты без linux-image.

🔊 4. PipeWire по умолчанию вместо PulseAudio

  • Новая мультимедийная подсистема PipeWire рекомендована к установке.
  • Обеспечивает меньшую задержку звука, унифицированную работу в консоли и GUI.
  • Поддержка через pipewire, pipewire-pulse, wireplumber.

💿 5. Новая структура CD-наборов

  • Разделение по типам установки:

    • CD-1: минимальный сервер
    • CD-2: серверная установка
    • CD-2+3+4: MATE или XFCE
    • CD-2+3+5: LXDE или LXQt
  • Для KDE и Cinnamon рекомендуется использовать «netinstall» или «desktop» ISO.


🧍 6. Восстановлена поддержка /run/utmp

  • Вновь работает регистрация сеансов входа (login(8)/run/utmp), что улучшает совместимость с классическими инструментами учёта пользователей.

🌐 7. Обновлённая инфраструктура репозиториев

  • Основные репозитории доступны через:

    • HTTP: http://deb.devuan.org/
    • Tor: tor+http://devuanfwojg73k6r.onion/
  • Репозитории синхронизируются каждые 30 минут.

  • Добавлены новые секции: excalibur, excalibur-security, excalibur-updates, excalibur-proposed.


⚙️ 8. Non-Free Firmware доступно при установке

  • Все установочные образы теперь содержат non-free firmware, которое устанавливается только при необходимости (например, Wi-Fi).
  • Можно отключить установку в режиме Expert install.
  • В live-образах можно удалить прошивки после загрузки (/root/remove_firmware.sh).

🐋 9. Официальные Docker-образы

  • Devuan теперь официально предоставляет образы Docker:

    docker pull devuan/devuan:excalibur
    
  • Обновляются синхронно с релизами и доступны на Docker Hub.


🧰 10. Улучшенные инструменты и служебные пакеты

  • Актуализированы версии reportbug, devuan-keyring, installer, и др.
  • Совместимость с Debian Trixie улучшена для миграции с Debian 13.

>>> Devuan 6 Excalibur Release Notes



Проверено: hobbit ()
Последнее исправление: cetjs2 (всего исправлений: 4)

Теперь объединённый /usr — обязательный. Все каталоги /bin, /sbin, /lib* символически связаны в /usr.

Так до сих пор не понимаю эту хрень. Если идея была в том, чтобы корень оказался подвешеным в виртуальной ФС то надо было доделывать.

kirill_rrr ★★★★★
()
Ответ на: комментарий от tinykey

Они в любом случае должны писаться.

А ещё логи должны читаться. Желательно любым инсструментом а нетолько журналцтл.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Желательно любым инсструментом а нетолько журналцтл.

Кому желательно? Мне вот нахрен не сдалось в ворде их читать. Авторам systemd - тоже.

zabbal ★★★★★
()
Ответ на: комментарий от zabbal

Да не, разве в 21 веке кому то может понадобиться просто кинуть все логи на какую нибудь почту и прочитать их там со смартфона? Бред...

kirill_rrr ★★★★★
()

Помнится @CrX негодовал в комментариях к моей новости про недостаточную публицистичность текста и точки с запятой. Как тебе здесь с публицистичностью от ИИ - всё норм? Пунктуация ок? Стилистика?

Ещё и синий кит такой миленький - прелесть, правда?

zabbal ★★★★★
()
Ответ на: удаленный комментарий

Вообще говоря, ничто не мешает экспортировать все эти логи в текст и потом почитать с телефона.

liksys ★★★☆
()
Ответ на: комментарий от liksys

Юзкейси раздельного /usr в студию.

Я вас умоляю, это ставят не чтобы юз, а чтобы «я не такой как все, я против системы, мне 13 лет» ;)

zabbal ★★★★★
()
Ответ на: комментарий от liksys

Вообще говоря, ничто не мешает экспортировать все эти логи в текст и потом почитать с телефона.

Там даже экспортировать не надо - формат JEF отлично документирован, сделать аналог systemd-journal-remote, который будет выдавать принятое хоть в RSS, хоть в SMS - работа на пару вечеров даже без помощи ИИ.

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

zabbal ★★★★★
()
Ответ на: комментарий от kirill_rrr

А ещё логи должны читаться. Желательно любым инсструментом а нетолько журналцтл.

А есть проблема чтения логов из journald с помощью любого инструмента, который умеет на вход получать текст? Где разница между journalctl -u foobar | grep ... и zcat /var/log/foobar.log.1.gz | grep ...?

tinykey
()
Ответ на: комментарий от kirill_rrr

С появлением overlayfs это все стало чрезвычайно бессмысленным. Даже без учета initrd.

tinykey
()
Ответ на: удаленный комментарий

А с чего ты решил что авторы systemd обязаны поддерживать настолько идиотские хотелки мамкиных админов локалхоста?

Ну вообще это постоянная практика любых продавцов appliance, от свичей до стораджей. Другое дело что сдампать данные из журнала и сдампать логи из /var/log это абсолютно эквивалентные задачи.

tinykey
()
Ответ на: комментарий от tinykey

что не так-то с systemd?

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

Простенькая задача: сразу после поднятия сети запустить nfs-клиент и подмонтировать nfs-разделы, на которых часть необходимых для работы ресурсов. Раньше это 2 мин работы, а сейчас? Прописывать для каждого юнита, чтобы он ждал запуска условного nsf-moutn-dirs?

Собственно, чтобы рулить Линуксом, было достаточно знать sh и bash + любимый т/р, а теперь ещё и написание юнитов и список команд и ключей, чтобы рулить конкретно systemd.

mister_VA ★★
()
Ответ на: комментарий от zabbal

Помнится @CrX негодовал в комментариях к моей новости про недостаточную публицистичность текста и точки с запятой. Как тебе здесь с публицистичностью от ИИ - всё норм? Пунктуация ок? Стилистика?

Нет, не ок. Новость по хорошему требует работы корректора. Я сейчас не могу, может кто ещё поправит. (Речь о списке в пункте 5 как минимум).

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от monk

Это никому не нужно. Если хочешь тонкого клиента - делай по-человечески с rootfs по сети целиком, а это - полумера какая-то.

liksys ★★★☆
()
Ответ на: комментарий от liksys

На кой rootfs? /etc у каждого свой, ядро своё (потому что оборудование может быть разное). Программы общие, обновлять их удобно централизованно.

monk ★★★★★
()
Ответ на: комментарий от monk

И если вдруг сеть отвалилась, то в /bin и /sbin достаточно инструментов для анализа, что произошло.

monk ★★★★★
()
Ответ на: комментарий от monk

На кой rootfs?

Проще обновлять.

/etc у каждого свой

Такого быть не должно. Ты должен раздавать разные /etc централизованно с сервера, если нужно.

ядро своё (потому что оборудование может быть разное)

Открой для себя модульное ядро в 2025 году.

И если вдруг сеть отвалилась

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

Проще обновлять.

Ты говоришь про обновление /usr, и следом говоришь про собтственные /bin и /sbin, которые делят удобство обновления на ноль, потому что у тебя уже есть вагон нецентрализованных данных.

liksys ★★★☆
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Если хочешь тонкого клиента

Это вообще не для тонкого клиента. Это для объединения неизменяемых частей ОС. Общий /usr позволяет обновлять сразу все. Но это не тонкие клиенты: /boot, /etc, /var и /home у каждого свой.

monk ★★★★★
()
Ответ на: комментарий от mister_VA

Ну, например, длинные команды и ключи, причём вовсе не единообразные.

Это правда.

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

Что ты имеешь в виду?

Простенькая задача: сразу после поднятия сети запустить nfs-клиент и подмонтировать nfs-разделы, на которых часть необходимых для работы ресурсов. Раньше это 2 мин работы, а сейчас? Прописывать для каждого юнита, чтобы он ждал запуска условного nsf-moutn-dirs?

А где разница с OpenRC? Там тот же механизм зависимостей.

Собственно, чтобы рулить Линуксом, было достаточно знать sh и bash + любимый т/р, а теперь ещё и написание юнитов и список команд и ключей, чтобы рулить конкретно systemd.

Просто раньше вся эта логика ложилась внутрь самих скриптов запуска. Теперь она снаружи. Объем задач-то особо не изменился.

tinykey
()
Ответ на: комментарий от monk

Возможность подключать /usr по NFS, например.

Это правда никому не нужно. Просто монтируешь через overlayfs все что захочешь и работаешь.

tinykey
()
Ответ на: комментарий от liksys

Ты должен раздавать разные /etc централизованно с сервера, если нужно.

Зачем? Если у каждой машины он свой, смысл его дублировать на центральном сервере?

Открой для себя модульное ядро в 2025 году.

И? Модулями уже можно планировщик переключать?

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

Так всё необходимое должно быть локально. Графический интерфейс для этого точно не нужен.

Ты говоришь про обновление /usr, и следом говоришь про собтственные /bin и /sbin, которые делят удобство обновления на ноль, потому что у тебя уже есть вагон нецентрализованных данных.

То, что должно быть одинаковое у всех, централизованно. Ядро на каждом узле своё. Настройки свои. /bin и /sbin обновляются крайне редко и если даже обновляются, они маленькие, это быстро.

monk ★★★★★
()
Ответ на: комментарий от tinykey

Просто монтируешь через overlayfs все что захочешь и работаешь.

Потом под этот оверлей файлы в /bin запихивать тяжело. То есть лишние проблемы на ровном месте, которых при отдельном /usr нет.

monk ★★★★★
()
Ответ на: комментарий от monk

То, что должно быть одинаковое у всех, централизованно. Ядро на каждом узле своё. Настройки свои. /bin и /sbin обновляются крайне редко и если даже обновляются, они маленькие, это быстро.

А есть смысл с этим страдать в век golden image? Отправляешь сервер в ребут, к нему приходит httpboot, dd’ой раскатывает нужный образ Linux поверх диска и уходит. Установка длится меньшее чем ребут.

tinykey
()
Ответ на: комментарий от monk

Потом под этот оверлей файлы в /bin запихивать тяжело. То есть лишние проблемы на ровном месте, которых при отдельном /usr нет.

С /usr есть столько лишних проблем, что файлы в /bin кажутся сущей мелочью.

tinykey
()
Ответ на: комментарий от liksys

Я же написал. Чтобы приложения были общие на всех рабочих станциях. Но при этом настройки и данные у каждой свои. /usr - это репозиторий приложений. И смысла дублировать их на каждый компьютер обычно нет. Диски, конечно, большие, но их можно использовать для хранения данных, а не для индивидуальной копии одних и тех же приложений.

monk ★★★★★
()
Ответ на: комментарий от monk

Например?

Например на десять минут пропала сеть из-за шторма, NFS отвалился по таймауту, у всех развалились рабочии станции.

tinykey
()
Ответ на: комментарий от tinykey

Отправляешь сервер в ребут, к нему приходит httpboot, dd’ой раскатывает нужный образ Linux поверх диска и уходит.

А локальные данные как обратно вернуть? И что делать, если сетевуха сбойнула, локально ведь в таком случае вообще ничего нет.

monk ★★★★★
()
Ответ на: комментарий от monk

Чтобы приложения были общие на всех рабочих станциях.

Чтобы приложения были общими, сделай общий rootfs. Остальное монтируй через overlayfs, как сказали выше. Всё, проблема решена.

Ты вон пишешь про проблемы с overlayfs, но как-то забываешь, что современные пакетные менеджеры не рассчитаны на работу с отдельным /usr и не могут положить только /usr-файлы куда-то, они все хотят как минимум chroot.

liksys ★★★☆
()
Ответ на: комментарий от tinykey

Например на десять минут пропала сеть из-за шторма, NFS отвалился по таймауту, у всех развалились рабочии станции.

Если работа подразумевает необходимость сети, то она остановится вне зависимости от /usr по NFS.

monk ★★★★★
()
Ответ на: комментарий от monk

А локальные данные как обратно вернуть?

Какие локальные данные? Настройки лежат в том же имаже, рабочие данные станции лежат на другом разделе / lvm томе / raid / whatever.

И что делать, если сетевуха сбойнула, локально ведь в таком случае вообще ничего нет.

Httpboot будет долбиться до последнего.

tinykey
()
Ответ на: комментарий от monk

Поэтому работать надо по сети и обеспечивать нормальную сеть в первую очередь. А локальное барахло - это всё чушь и полумеры.

liksys ★★★☆
()
Ответ на: комментарий от monk

Если работа подразумевает необходимость сети, то она остановится вне зависимости от /usr по NFS.

Ну да, только когда сеть появиться она продолжиться без необходимости ребутать все машины в офисе.

tinykey
()
Ответ на: комментарий от liksys

но как-то забываешь, что современные пакетные менеджеры не рассчитаны на работу с отдельным /usr и не могут положить только /usr-файлы куда-то, они все хотят как минимум chroot.

Так на NFS сервере тому пакетному менеджеру всё есть. А на клиентах он особо и не нужен.

monk ★★★★★
()
Ответ на: комментарий от monk

Ты не понял. Пакетному менеджеру для работы нужен chroot, из которого ты будешь старательно выкорчевывать свой /usr. И это говоря о том, что помимо /usr современному софту захочется что-то положить и в другие каталоги.

liksys ★★★☆
()
Ответ на: комментарий от tinykey

Настройки лежат в том же имаже

Вот опять. Лишние телодвижения. Поменял что-то в /etc, иди менять в образе, а то затрётся.

Httpboot будет долбиться до последнего.

И толку, если, например, через mii-tool надо параметры поменять.

monk ★★★★★
()
Ответ на: комментарий от liksys

Вы явно не поняли сути. Как сделать автомонтирование СРАЗУ после поднятия сети и ДО запуска всего остального? Ибо не всё сможет заработать без заранее примонтированного.

mister_VA ★★
()
Ответ на: комментарий от monk

Вот опять. Лишние телодвижения. Поменял что-то в /etc, иди менять в образе, а то затрётся.

Ты не меняешь ничего в /etc. Ты меняешь образ и перезаливаешь его.

И толку, если, например, через mii-tool надо параметры поменять.

Какие параметры? Смотри, все очень просто:

  1. Говоришь серверу через ipmitool что он теперь httpboot
  2. Он идет грузить инсталлер golden image
  3. Если он не прищел через 10 минут, цикл повторяется

Все.

tinykey
()
Ответ на: комментарий от liksys

И это говоря о том, что помимо /usr современному софту захочется что-то положить и в другие каталоги.

В /etc всё равно вручную править под конкретные задачи. В /var по идее ничего из пакета ставиться не должно, так как там изменяемые данные, всё создаётся при настройке приложения.

monk ★★★★★
()
Ответ на: комментарий от tinykey

Ты меняешь образ и перезаливаешь его.

На работающей станции? Или как в Windows любое изменение настроек = перезагрузка?

monk ★★★★★
()
Ответ на: комментарий от monk

В /etc всё равно вручную править под конкретные задачи. В /var по идее ничего из пакета ставиться не должно, так как там изменяемые данные, всё создаётся при настройке приложения.

Пффф. На этом сразу можно заканчивать. В /var ставится дохрена всего.

tinykey
()
Ответ на: комментарий от monk

На работающей станции? Или как в Windows любое изменение настроек = перезагрузка?

Именно. Если мы говорим про тотальный контроль (иначе зачем нам шареный /usr) – контроль тотальный. Если он не тотальный, смысл в шареном /usr пропадает.

tinykey
()
Ответ на: комментарий от tinykey

Что ты имеешь в виду?

Раньше посмотрел /etc/init.d и /etc/rc.* и всё понял.

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

И для их чтения достаточно знать sh, знать systemd было не нужно. Не нужно было знать команды systemd для руления и т.д. Т.е. systemd – это ДОПОЛНИТЕЛЬНЫЙ набор инструментов, но НЕ заменяющий.

mister_VA ★★
()
Ответ на: комментарий от tinykey

Если он не тотальный, смысл в шареном /usr пропадает.

Смысл в том, чтобы не дублировать идентичные данные на все рабочие станции.

monk ★★★★★
()
Ответ на: комментарий от mister_VA

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

liksys ★★★☆
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)