LINUX.ORG.RU

Devuan Excalibur 6

 , ,


4

5

Основные новые возможности и изменения в 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)
Ответ на: комментарий от AS

Потому, что если они грохнутся, можно зайти по ssh и поднять. А если грохнется init, то только бежать ножками. Иногда много километров. Или не очень много, но по пробкам.

Зачем?

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

Ваще не очевидно. Зачем куда-то бежать чтобы починить сервер? Ты вообще видел серверы? Ты знаешь что такое BMC? Ты знаешь про crash kernel? Ты вообще хоть что-нибудь знаешь?

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

Ваще не очевидно. Зачем куда-то бежать чтобы починить сервер? Ты вообще видел серверы? Ты знаешь что такое BMC? Ты знаешь про crash kernel? Ты вообще хоть что-нибудь знаешь?

Я много чего знаю. И из этого много чего совсем не нужно, если нет systemd. Ввиду того, что без systemd вероятность применения падает в разы (или, даже, десятки) и можно и сбегать.

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

Я много чего знаю.

Очевидно, что нет.

И из этого много чего совсем не нужно, если нет systemd.

Ты обо всем этом только что узнал.

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

Ввиду того, что без systemd вероятность применения падает в разы (или, даже, десятки) и можно и сбегать.

Ты все ещё не знаешь что такое crash kernel и почему бегать никуда не нужно.

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

Почему тебя не смущает рестарт nginx и postgresql, которые куда более сложные и от которых реально зависит бизнес?

Потому что у бизнеса они реплицированы в кластере ?

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

Ты обо всем этом только что узнал.

Я об этом знал, когда тебя, поди, в проекте не было. Так-то у меня в столе аллюминиевая доска лежит Intel Desktop Server Integration Specialist (или около того, надо поискать, чтобы точный текст вспомнить) от 1999 года.

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

Я об этом знал, когда тебя, поди, в проекте не было.

Ну, нет? Ты собирался куда-то ногами бежать чинить падение сервера.

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

Тогда и нет проблемы с падением хоста?

Ну как нет, всё равно чинить, однако на аптайм не должно повлиять в теории, только на больших нагруженных постресах не всегда переключение проходит гладко :(

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

Ну, нет? Ты собирался куда-то ногами бежать чинить падение сервера.

Малыш, ты мал и глуп, ты не видал больших зал... В общем этих. Ты, наверное, подумал о стойках с Супермикро, HP, Intel в конце концов, с UPS и генератором рядом, и 100500 денег в месяц на их обслуживание и т.п. Увы, но так бывает не всегда.

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

Кстати если одна из нод HA СУБД падает, это ведь не значит, что её надо сразу же тупо перезапускать, что обычно рекламируют пиарщики systemd ?

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

Ну как нет, всё равно чинить, однако на аптайм не должно повлиять в теории, только на больших нагруженных постресах не всегда переключение проходит гладко :(

Я ни разу не видел падение на апдейте systemd, если честно. Но вот тревожный @AS пытается представить это как какую-то катастрофу, которая домокловым мечом висит над всеми. Но, как выясняется, если ты компетентен, то даже падение systemd тебе не помешает.

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

Малыш, ты мал и глуп, ты не видал больших зал… В общем этих. Ты, наверное, подумал о стойках с Супермикро, HP, Intel в конце концов, с UPS и генератором рядом, и 100500 денег в месяц на их обслуживание и т.п. Увы, но так бывает не всегда.

Любые современные серверы имеют встроенный BMC. Даже российские. Crash kernel вообще не требует поддержки железа. Перестань позориться, мы уже понял что ты просто ламер.

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

Кстати если одна из нод HA СУБД падает, это ведь не значит, что её надо сразу же тупо перезапускать, что обычно рекламируют пиарщики systemd ?

Отчего нет? В master-master оно прекрасно вернется. Если не вернется, мониторинг с утра тебе об этом скажет.

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

Любые современные серверы имеют встроенный BMC. Даже российские. Crash kernel вообще не требует поддержки железа. Перестань позориться, мы уже понял что ты просто ламер.

Ты сам не позорься. Сервер он захотел, чтобы ему выдали. С BMC.

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

Ты сам не позорься. Сервер он захотел, чтобы ему выдали. С BMC.

Если сервера нет, на нем и ядро упасть не может. И проблемы нет.

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

Но вот тревожный @AS пытается представить это как какую-то катастрофу, которая домокловым мечом висит над всеми.

У меня давно бук с systemd, и я вижу, что с ним иногда происходит (1, буквами: ОДИН). И не хочу такого же на сервере получить однажды.

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

Если сервера нет, на нем и ядро упасть не может. И проблемы нет.

Ну-ну. То есть если без BMC, то ты увольняешься. Ну вперёд. Скатертью.

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

У меня давно бук с systemd, и я вижу, что с ним иногда происходит (1, буквами: ОДИН). И не хочу такого же на сервере получить однажды.

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

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

Ну-ну. То есть если без BMC, то ты увольняешься. Ну вперёд. Скатертью.

Найди мне сервер без BMC на рынке, пожалуйста.

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

Но, как выясняется, если ты компетентен, то даже падение systemd тебе не помешает.

Как достали эти оценки systemd троллей «компетентен/некомпетентен».

Думаешь ваших инженеров, разработавших systemd, все считают компетентными, а творение пределом совершенства? LOL

Если высказать все претензии к systemd, тут страниц не хватит и времени всё это описывать!

Для контор, которые на обслуге у «приходящих одминов», да ваш systemd подходит, потому что действительно его конфиги довольно хорошо передаваемы из рук одного админа в руки другого, на этом собственно его преимущества с учётом высоких требований к надёжности и KISS заканчиваются, потому что под капотом там слишком много всего, что нужно далеко не для каждого use case.

Почему в Talos Linux никогда не было systemd? (обрезок загрузчика не считается) Почему при этом он прекрасно рулит сотнями и тысячами узлов в кластерах?

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от sanyo1234

Если высказать все претензии к systemd, тут страниц не хватит и времени всё это описывать!

Если высказывать тревогу. Претензии (технические) тут пока высказал только я (асинхронщина в homed).

Почему в Talos Linux никогда не было systemd?

Потому что им так захотелось.

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

Найди мне сервер без BMC на рынке, пожалуйста.

Берёшь https://procase.ru/3u/ru330/ (ибо короткий, лезет в очень небольшой шкаф). Берёшь дешман-материнку, напихиваешь сетевых карт, один hdd и уносишь на очередной забытый объект на чердак.

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

Претензии (технические) тут пока высказал только я (асинхронщина в homed).

Просто надоело уже, все косточки systemd уже перетёрли давным давно в других ветках, лень плодить дубли.

Потому что им так захотелось.

Прикинь, критикам systemd в этой ветке он тоже не нравится, прикольно да!?

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

Какое отношение это все имеет к промышленной эксплуатации?

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

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 2)
Ответ на: комментарий от sanyo1234

Просто надоело уже, все косточки systemd уже перетёрли давным давно в других ветках, лень плодить дубли.

Но 20 страниц как-то нафлудили же. Значит не лень. Вероятно сказать просто нечего кроме «там сложно нам тревожно».

Прикинь, критикам systemd в этой ветке он тоже не нравится, прикольно да!?

Да и плевать, аргументов-то нет.

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

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

Какое-то днище. Положи малинку в корпус, подключив её по serial console к серверу.

И вот из-за systemd у тебя вероятность «пойдёшь и поменяешь» возрастает кратно, так как обновлять их, всё же, нужно.

Я так и не понял где проблема.

Self-healing работает так:

  1. Обновляемся
  2. systemd падает
  3. Загружается crash kernel
  4. Собирает дамп
  5. Отправляет сервер в ребут
  6. Загрузились

Проблемы все ещё нет.

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

Да и плевать, аргументов-то нет.

Ссылку на аргумент я тут приводил. Он один абсолютно самодостаточен. Это я про offline update.

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

Ссылку на аргумент я тут приводил. Он один абсолютно самодостаточен. Это я про offline update.

Эм:

systemd.offline-updates — Implementation of offline updates in systemd

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

Какое-то днище. Положи малинку в корпус, подключив её по serial console к серверу.

Как я на неё попаду? :-) 100500 малинок с модемами и звонить на них что ли? :-)

Ибо OSPF на этой лабуде, и интернета без неё не будет.

Отправляет сервер в ребут
Загрузились

Правда загрузились? Правда-правда? :-)

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

Как я на неё попаду? :-) 100500 малинок с модемами и звонить на них что ли? :-)

То есть у вас есть куча железа по городу к которому нет доступа? А зачем его вообще обновлять тогда?

Правда загрузились? Правда-правда? :-)

А что помешает-то?

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

Правда загрузились? Правда-правда? :-)

Теперь куда интереснее другое: у вас пришел новый апдейт ядро, там баг, сетевая карта роняет ядро в панику. Что вы будете делать?

Напомню, что ядро падает от любой ерунды, например когда неправильно моргает лампочкой:

Intel Wired LAN Driver Updates 2025-09-16 (ice, i40e, ixgbe, igc) Kohei Enju does not fail probe on LED setup failure which resolves a kernel panic in the cleanup path, if we were to fail.

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

Окей, так и запишем: ни строчки кода в жизни ни написал, но мнение имеешь.

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

Дальше объяснять?

Нет. Всем и так понятно, что у тебя двойные стандарты. Оставлять сервисы запущенными в окружении обновленной версии тебе норм, как ты описывал выше, разведя ко-ко-ко про перезагрузки и винду, а systemd не перезапускать тебе не норм.

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

А если грохнется init, то только бежать ножками.

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

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

Ввиду того, что без systemd вероятность применения падает в разы

Статистику в студию.

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

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

Там ещё веселее – у него, похоже, промышленный appliance без A/B установки и OOB доступа.

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

Потому что у бизнеса они реплицированы в кластере ?

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

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

Ты сам не позорься. Сервер он захотел, чтобы ему выдали. С BMC.

КВМ купи и не мучайся. К любому PC подойдет, не говоря уже о сервере.

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

Так-то у меня в столе аллюминиевая доска лежит Intel Desktop Server Integration Specialist

Можешь нарезать на ней закусь под стопочку. Объясняю, как надо:

Во-первых, как тебе уже дважды написали, сбои ядра надо обрабатывать.

Во-вторых, BMC.

В-третьих, если нет BMC - купи KVM.

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

В-пятых, весь софт должен быть обмазан мониторингами и авторестартами по возможности. С systemd это реализовать проще всего.

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

В-пятых, весь софт должен быть обмазан мониторингами и авторестартами по возможности. С systemd это реализовать проще всего.

В-шестых, если у тебя 1000 одинаковых железок, надо их обновлять образами ОС с предварительным, а не каждую отдельно ansible’ом, прости господи.

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

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

Можно подумать юнит не сломатся если какой то мейтейнер изменит параметры запуска или зависимости на незивестные тебе.

Конфиги systemd декларативные

Что мешает тебе написать инит-скрипт в декларативном виде?

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

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

Это обычные динамические сущности, существование которых зависит от хоста. Раз, два. И они не имеют никакого отношения к обсуждаемому вопросу

О нет, они имеют отношение! Они встроены в зависимости дерева юнитов и усложняют его. Но самая проблема в том, что поведение home.mount и то что написано в /etc/fstab может быть разными вещами и вот у тебя образовался кривой юнит. Какой с(т)ранной хренью это может обернуться? Да Х.З. Но даже банальное подвисание на полторы минуты таймаута при выключении - уже неприятный косяк из ничего.

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

Если для сервиса - создается системный юнит с буквальным before/after.

После чего тебе требуется провести дебаггинг документации, которую тебе нашёл гугл, методом обратного инжиниринга...

В твоем случае, выучить баш и написать портянку. Ини-файл на 5 строчек будет короче.

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

Собственно в 99% случаев в системд это именно так и делается через rc.local. Только это явно не заслуга системд а баг, который рано или поздно устранят. По религиозным причинам.

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

Как заставить что-то запуститься перед exim но после dbus?

Очевидно в алфавитном порядке. Можно тупо взять и переименовать неудобные индексы на удобные тебе, их не так много. А можно придумать что нибудь типа S01dbz-запускаю_свою_хрень.

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

А люди используют.

Да боже упаси! Пинок под зад и больше с этим {чудаком} не общаться. А то хрен его знает что он ещё выкинет и кому на голову.

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

По формату файла unit

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

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

Обновление может сломать именование и поломать приоритеты.

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

что ты дурачок и нациклил какую-то хрень.

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

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

И раз уж исторически так сложилось, что именно systemd (не OpenRC, runit, dinit, s6 и прочие) первым стал теснить sysvinit, то пусть уж будет он как основной линуксовый

Это не правда. Первым начал теснить upstart из убунту. Не изучал, но по всем отзывам было лучше и инита, и системд. Только Каноникал имел проблемы с деньгами а гном3 занял непримиримую позицию системд-онли и в итоге бабло порешало вопрос - всем прочим требовалось вкладывать деньги и усилия в войну стандартов.

kirill_rrr ★★★★★
()
Ограничение на отправку комментариев:
Тема будет перемещена в архив .