LINUX.ORG.RU
 

Systemd 29


0

1

16 июня, тихо и незаметно вышла 29-ая версия новой системы инициализации для Linux. Среди её возможностей основными являются:

  • событийно-ориентированная система параллельного запуска сервисов;
  • управление через dbus;
  • упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C для управления консолью, установки локали, запуска fsck, монтирования файловых систем и др.;
  • возможность запуска сервисов по появлению данных в сокете, запуску или остановке других сервисов, наличию подключённых устройств или смонтированных файловых систем;
  • встроенное упреждающее чтение с диска;
  • интеграция с cgroups;
  • совместимость со старыми скриптами, предназначенных для использования с SysVinit.

Всё это даёт возможность загружать систему за время порядка 10 секунд и выключать за 1 секунду.

В новой версии были незначительно изменены Makefile-ы, и было добавлено 2 пункта в TODO:

  • посылать сигнал, когда загрузка завершена;
  • при неудачном запуске сервиса попытаться перезапустить его.

Будем надеяться, что в следующей 30 версии мы увидим эти новые фичи.

>>> Исходники

>>> О systemd и ссылки

>>> Подробности


 ← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 →
[#]  
X10Dead
>>-----Цитата---->>

интеграция с cgroups

<<-----Цитата----<<

Отличная новость.

** ()
[#] Ответ на: комментарий от X10Dead 17.06.2011 16:11:57  

>>интеграция с cgroups

>Отличная новость.

Что-то не так? В systemd есть автоматическая группировка процессов на основе cgroups. Она ещё конфликтует с аналогичной системой, появившейся в 2.6.38 ядре.

** ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 16:18:32  
X10Dead

Что, я похож на тролля?
Я так понял что как раз эту проблему пофиксили, и это хорошо.

** ()
[#]  
aidaho

>Всё это даёт возможность загружать систему за время порядка 10 секунд и выключать за 1 секунду.

Это какой-то сферический в вакууме сервер занимающийся ничем, следует полагать?

** ()
[#]  
geekless

> событийно-ориентированная система запуска сервисов с параллельным запуском демонов;

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

> управление через dbus

Где теги [закопать][не нужно][xml головного мозга]?

> упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C

В чью-то голову вдруг пришла идея писать скрипты на Си, за окном неспешно шел XXI век...

> интеграция с cgroups

Слоупоки такие слоупоки.

> Всё это даёт возможность загружать систему за время порядка 10 секунд и выключать за 1 секунду.

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

** ()
[#]  

> упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C

Наконец-то хоть кто-то осуществил этот шаг. А то все только и горазды кричать, что скрипты (sh/python/perl) для быстрого proof-of-concept, а потом надо переписывать на нормальные языки, но до переписывания так и не доходило.

anonymous ()
[#] Ответ на: комментарий от aidaho 17.06.2011 16:26:01  

>Это какой-то сферический в вакууме сервер занимающийся ничем

Это мой нетбук.

** ()
[#] Ответ на: комментарий от geekless 17.06.2011 16:26:52  

>В чью-то голову вдруг пришла идея писать скрипты на Си,

Там не скрипты, а скомпиленные программы.

http://0pointer.de/blog/projects/systemd.html

Читать отсюда:

>Keeping the First User PID Small

>Просто поразительно, особенно если учитывать, что всё это прекрасно делается без сабжа.

Но при этом сливает в функциональности. Конечно, можно же и все демоны выпилить, ФС не проверять, шрифты и кеймапы не устанавливать, тогда и за 3 секунды можно загрузиться.

>Учитывая, что демон — это обозначение сервисной программы в юниксе, масло получилось необычайно масляное.

Исправлю.

** ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 16:26:57  
aidaho

>Это мой нетбук.

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

** ()
[#]  

> Всё это даёт возможность загружать систему за время порядка 10 секунд и выключать за 1 секунду.

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

***** ()
[#] Ответ на: комментарий от aidaho 17.06.2011 16:34:43  

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

У меня там дефолтнейший набор из udev, dbus, NetworkManager, gdm, syslog-ng и всяких ConsoleKit и PolicyKit, которые грузятся сами. А при нажатии на "Выключить" в гноме systemd просто рассылает всем процессам сигналы, иксы вырубаются около секунды, потом почти мгновенно (порядка 0,2 секунды) размонтируются ФС и выключается. Но в арче был какой-то глюк, связанный с тем, что syslog-ng не выключался, поэтому часто выключение зависало на 3 минуты. В Генте не встречал этого бага.

** ()
[#]  
Coldead

Чем он лучше OpenRC?

* ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 16:31:45  
geekless

> http://0pointer.de/blog/projects/systemd.html

Таки там отлично описано, что проблема не со скриптами, а с большим количеством процессов, которые приходится запускать из них. Абсолютно не понятно, что мешало разрабу взять для скриптов любой язык, не требующий порождения отдельного процесса на каждый чих: Tcl, Io, Lisp, JS, тысячи их. Писать в XXI веке высокоуровневую загрузочную логику на Си — это надо иметь поражение мозга, чтобы до такого додуматься.

> Но при этом сливает в функциональности. Конечно, можно же и все демоны выпилить, ФС не проверять, шрифты и кеймапы не устанавливать, тогда и за 3 секунды можно загрузиться.

Чтобы загрузиться до графического логина на среднестатистическом десктопе, нужно:
* прогнать инициализирующие события по udev
* смонтировать файловые системы
* поднять сислог
* поднять dbus
* поднять *dm с иксами.
Всё.

Хоть тресни, а быстрее в иксы не попадёшь.

> ФС не проверять

Если не проверять, станешь ССЗБ. А проверять из надо до того, как на них что-нибудь запишется. Так что раз в N загрузок задержка старта будет под какой угодно системой инициализации.

> шрифты и кеймапы не устанавливать

Или же устанавливать после запуска *dm. И все остальные службы запускать тоже.

** ()
[#] Ответ на: комментарий от geekless 17.06.2011 16:45:36  
Manhunt

> Писать в XXI веке высокоуровневую загрузочную логику на Си — это надо иметь поражение мозга, чтобы до такого додуматься.

+1, лютая жесть. "I wrote most of Avahi and PulseAudio, among other stuff. Right now I am focusing on systemd which I created" Как много зла может принести миру всего лишь один человек :(

*** ()
[#] Ответ на: комментарий от geekless 17.06.2011 16:45:36  
geekless

Еще добавлю:

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

** ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 16:41:08  
aidaho

Прокси-сервер, к примеру, постарается обслужить все текущие запросы перед остановкой, 10-20 секунд. Десктоп, увязший по колено в свопе, тоже по щелчку пальцев не потухнет.
А что касается запуска, то там кучка биосов будет в несколько раз дольше инициализироваться.

В общем гном за 10 секунд — не абы какое важное достижение. Это наверное с ssd?

** ()
[#] Ответ на: комментарий от Manhunt 17.06.2011 16:54:23  
aidaho

>Avahi and PulseAudio

Avahi то чем не угодил? ALSA с dmix тоже никто не отменял, пульсу никогда не использовал, но вещь определенно полезная.

** ()
[#] Ответ на: комментарий от geekless 17.06.2011 16:45:36  

> прогнать инициализирующие события по udev

Не нужно. Можно запускать сервисы по мере активации устройств, что и делает systemd.

>поднять сислог

Тоже не критичен.

И это можно делать одновременно, что и делает systemd.

** ()
[#] Ответ на: комментарий от geekless 17.06.2011 16:26:52  
Mystra_x64

>за окном неспешно шел XXI век...

Вы таки предлагаете переписать наконец на моно?

***** ()
[#] Ответ на: комментарий от geekless 17.06.2011 16:45:36  
Mystra_x64

>JS

Как раз можно было бы линупс и закопать.

***** ()
[#] Ответ на: комментарий от aidaho 17.06.2011 16:59:58  

> Десктоп, увязший по колено в свопе, тоже по щелчку пальцев не потухнет.

У меня нет свопа. И прокси-сервера на нетбуке.

>Это наверное с ssd?

Нет, обычный винт.

** ()
[#] Ответ на: комментарий от Manhunt 17.06.2011 16:54:23  

про пульсу не согласен, с остальным согласен. Мой арч до инит3 загружается за 4 секунды, без всяких системД или ССД-дисков. И кеды ещё секунд 15-20 секунд.

* ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 17:39:59  
geekless

> Не нужно. Можно запускать сервисы по мере активации устройств, что и делает systemd.

Ага. Запустить иксы до инициализации ядерного видеодрайвера. Фантастика на грани техники.

> И это можно делать одновременно, что и делает systemd.

Монтировать /var одновременно с записью данных туда? :D

> одновременно

У меня система без всякого systemd пускает одновременно демоны, которые возможно так запустить. Что я делаю не так?

** ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 17:39:59  

>> поднять сислог

> Тоже не критичен.

Бгг.

***** ()
[#] Ответ на: комментарий от Manhunt 17.06.2011 16:54:23  
geekless

Пульса у меня звук по сети гоняет. А вот остальное действительно зло.

** ()
[#] Ответ на: комментарий от geekless 17.06.2011 17:54:31  

>Запустить иксы до инициализации ядерного видеодрайвера.

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

С обычным инитом сначала udev проинициализирует все устройства, потом начнут запускаться демоны.

>Монтировать /var

Только очень суровые ССЗБ так делают.

** ()
[#]  
firestarter

А чем оно лучше Upstart?

> при неудачном запуске сервиса
попытаться перезапустить его.

A в Upstart respawn давно есть.

*** ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 18:03:47  
geekless

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

Интересно, а как же "появятся" устройства, если udev будет жевать сопли, вместо того, чтобы просмотреть отложенную очередь событий, составленную ядром при инициализации шин?

> инициализации сети

Путаем втыкание драйвера на сетевой интерфейс и реальную инициализацию сети с назначением адресов и другими магическими обрядами?

> > Монтировать /var

> Только очень суровые ССЗБ так делают.

В общем-то, всё ясно. Ну значит, вы как раз целевая аудитория для systemd. Больше вопросов не имею.

** ()
[#]  

> событийно-ориентированная система параллельного запуска сервисов

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

> управление через dbus

У init-а? 0_о А кто запустит dbus чтобы дать команду init-у запустить dbus? А если dbus убить - init уведет систему в kernel panic? Нафиг!

> замена схожим по функциональности кодом на C ...

То есть теперь, чтобы добавить в pre-boot монтирование собственных каталогов нужно не поправить несколько строк скрипта, а пересобрать init-демон? Какой идиот это придумал?

> возможность запуска сервисов по появлению данных в сокете

Не нужно в init-е, есть xinetd, это его работа.

> наличию подключённых устройств или смонтированных файловых систем

Тоже не нужно в init-е. Есть udevd и udisks.

> встроенное упреждающее чтение с диска

Внезапно, readahead.

> интеграция с cgroups

Не нужно в init-е. Есть ulatencyd.

> совместимость со старыми скриптами, предназначенных для использования с SysVinit

Хрен там, а не совместимость. Юзеры Fedora15 это хорошо почувствовали на себе.

ВЫВОД: НЕ НУЖЕН! ЗАКОПАТЬ!

anonymous ()
[#]  

> Всё это даёт возможность загружать систему за время порядка 10 секунд и выключать за 1 секунду.

О да, это был эпик баг, когда systemd снимал питание раньше, чем ядро успевало отмонтировать файловые системы. Кстати, его уже поправили? Или fsck до сих пор после выключения в systemd ругается "filesystem is NOT clean"?

anonymous ()
[#] Ответ на: комментарий от X10Dead 17.06.2011 16:20:57  

> Я так понял что как раз эту проблему пофиксили, и это хорошо.

Нихрена там не пофиксили. systemd при старте отключает эту фичу в ядре и использует собственную группировку. ulatencyd в свою очередь, если детектит, что он запущен вместе с systemd, отключает cgroups у себя и работает на порядок хуже.

anonymous ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 18:03:47  
x3al

>Только очень суровые ССЗБ так делают.
Что, /run ещё нет, а systemd уже хочется?

**** ()
[#] Ответ на: комментарий от anonymous 17.06.2011 18:38:59  
geekless

Хороший, годный анонимус в треде. Всё правильно написал.

** ()
[#]  
AX

Что только люди не делают, лишь бы на init-ng не переходить.

**** ()
[#]  
unikum

Чем примечательна 29-я версия? Их выпускают довольно часто.

*** ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 17:44:10  
aidaho

>У меня нет свопа. И прокси-сервера на нетбуке.

Ну вам, в принципе, выше уже прямым текстом сказали о том, на что я намекаю.

>Нет, обычный винт.

Быстро.

** ()
[#]  

Леннарт как всегда фееричен. Нет, конечно, я не против его поделок вообще. Просто политика дистров такова, что его велосипеды пихают почти во все бинарные дистры по-дефолту без возможности удаления.

Такое ощущение, что редхату больше делать нечего, кроме как пропихивать поделки этого дарования.

ЗЫЖ а за автоматический перезапуск упавших сервисов надо сразу расстреливать. Даже в венде до такого не додумались, кажется.

anonymous ()
[#] Ответ на: комментарий от anonymous 17.06.2011 21:02:30  
geekless

> за автоматический перезапуск упавших сервисов надо сразу расстреливать. Даже в венде до такого не додумались, кажется.

Перезапускает, но ограниченное число раз. Если правильно помню.

** ()
[#] Ответ на: комментарий от Mystra_x64 17.06.2011 17:41:58  
LongLiveUbuntu

Конечно. Но лучше на Java. А исполнять на Java-процессоре.

* ()
[#] Ответ на: комментарий от anonymous 17.06.2011 18:38:59  

>А кто запустит dbus чтобы дать команду init-у запустить dbus?

systemd же и запустит, когда надо будет.

>А если dbus убить - init уведет систему в kernel panic?

Может, ещё и rm -rf --no-preserve-root / сделает? Перезапустит и делов-то.

>чтобы добавить в pre-boot монтирование собственных каталогов нужно не поправить несколько строк скрипта, а пересобрать init-демон?

Поправить скрипт - это костыль. Для монтирования есть /etc/fstab. systemd его прекрасно понимает.

>> наличию подключённых устройств или смонтированных файловых систем

>Есть udevd и udisks.

Они и скажут init'у, что "появился такой-то bluetooth-адаптер", а systemd же запустит bluetoothd. Или "появился раздел жёсткого диска", systemd увидит, что в /etc/fstab в последней колонке напротив него не 0, скажет systemd-fsck, чтобы тот запустил fsck.

>Не нужно в init-е, есть xinetd, это его работа.

>Внезапно, readahead.

>Не нужно в init-е. Есть ulatencyd.

Зачем куча костылей, если есть всё в одном флаконе?

** ()
[#] Ответ на: комментарий от anonymous 17.06.2011 18:41:38  

>О да, это был эпик баг, когда systemd снимал питание раньше, чем ядро успевало отмонтировать файловые системы.

К счастью, я с этим багом не столкнулся.

** ()
[#] Ответ на: комментарий от x3al 17.06.2011 19:01:28  
>>-----Цитата---->>

Что, /run ещё нет, а systemd уже хочется?

<<-----Цитата----<<
max@laptop ~ $ ls -l /run/
итого 28
drwxrwxr-x 2 root root   60 Июн 17 21:41 console
drwxr-xr-x 2 root root   80 Июн 17 21:41 ConsoleKit
drwxr-xr-x 2 root root   60 Июн 17 21:41 dbus
-rw-r--r-- 1 root root    4 Июн 17 21:41 dbus.pid
drwx--x--x 4 root gdm    80 Июн 17 21:41 gdm
-rw-r--r-- 1 root root    4 Июн 17 21:41 gdm.pid
drwxrwxr-x 5 root root  100 Июн 17 21:42 pm-utils
-rw-r--r-- 1 root root    5 Июн 17 22:09 ppp0.pid
-rw-r--r-- 1 root root 8192 Июн 17 22:09 pppd2.tdb
srw-rw-rw- 1 root root    0 Июн 17 21:41 sdp
srwxrwxr-x 1 root root    0 Июн 17 21:41 syslog-ng.ctl
-rw-rw-r-- 1 root root    4 Июн 17 21:41 syslog-ng.pid
drwxr-xr-x 4 root root  160 Июн 17 21:41 systemd
drwxr-xr-x 7 root root  160 Июн 17 22:11 udev
drwxr-xr-x 2 root root   40 Июн 17 21:41 user
-rw-rw-r-- 1 root utmp 3456 Июн 17 21:41 utmp
max@laptop ~ $ ls -l /var/run/
итого 28
drwxrwxr-x 2 root root   60 Июн 17 21:41 console
drwxr-xr-x 2 root root   80 Июн 17 21:41 ConsoleKit
drwxr-xr-x 2 root root   60 Июн 17 21:41 dbus
-rw-r--r-- 1 root root    4 Июн 17 21:41 dbus.pid
drwx--x--x 4 root gdm    80 Июн 17 21:41 gdm
-rw-r--r-- 1 root root    4 Июн 17 21:41 gdm.pid
drwxrwxr-x 5 root root  100 Июн 17 21:42 pm-utils
-rw-r--r-- 1 root root    5 Июн 17 22:09 ppp0.pid
-rw-r--r-- 1 root root 8192 Июн 17 22:09 pppd2.tdb
srw-rw-rw- 1 root root    0 Июн 17 21:41 sdp
srwxrwxr-x 1 root root    0 Июн 17 21:41 syslog-ng.ctl
-rw-rw-r-- 1 root root    4 Июн 17 21:41 syslog-ng.pid
drwxr-xr-x 4 root root  160 Июн 17 21:41 systemd
drwxr-xr-x 7 root root  160 Июн 17 22:11 udev
drwxr-xr-x 2 root root   40 Июн 17 21:41 user
-rw-rw-r-- 1 root utmp 3456 Июн 17 21:41 utmp
max@laptop ~ $ mount | grep '/run'
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)

Внезапно, пора бы уже вылезти из криокамеры. /run давно есть, а /var/run смонтирован как bind /run'а для обратной совместимости.

** ()
[#] Ответ на: комментарий от Coldead 17.06.2011 16:41:57  

>Чем он лучше OpenRC?

В OpenRC нет практически никаких фич, которые имеет systemd. И на моём нетбуке он грузил за 30 секунд, что недопустимо.

** ()
[#] Ответ на: комментарий от AX 17.06.2011 19:46:07  

>Что только люди не делают, лишь бы на init-ng не переходить.

Хотел перейти ещё до появления systemd. Но выяснилось, что его давно забросили.

** ()
[#] Ответ на: комментарий от unikum 17.06.2011 20:08:47  

>Чем примечательна 29-я версия? Их выпускают довольно часто.

Я сделал diff 28 и 29, там ничего особенного нет. Нового кода нет, небольшие изменения Makefile'ов, добавлено 2 пункта в TODO.

** ()
[#]  
Freiheits-Sender

Пока его версия не достигнет как минимум v1.1, дистры с этой ситемой лучше избегать ИМХО

** ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 23:17:40  

> Перезапустит и делов-то.

Даже если его удалить? Или не установить? Или если он просто не запускается, например, из-за кривого апдейта одной из библиотек зависимостей? Будет перезапускать его вечно? Бред.

> Поправить скрипт - это костыль. Для монтирования есть /etc/fstab. systemd его прекрасно понимает.

Во-первых, он его понимает криво. Небольшое отступление от формата или нестандартное имя NFS-раздела подвешивают загрузку на 10 минут. Во-вторых, костыль - это запихивать в systemd функции mount-а, а правка скрипта - это решение задачи.

Предположим, я хочу оставить корень и /usr в read-only. Пусть, например, это - дополнительная защита сервера. Или, может, у меня SSD-диск и я хочу избежать лишних операций записи. Для этого мне нужно выполнить несколько действий, смонтировать некоторые каталоги в tmpfs или mount-bind-ом на другие разделы. Если этого не сделать - система не запустится. И этого нельзя сделать из fstab-а, потому что mtab - тоже находится на корне, и в него тоже не должна выполняться запись, корень вообще не должен становиться rw.

Сейчас я могу это сделать, изменив несколько скриптов в /etc/rc*, потому что это - обычные скрипты на баше. А что мне делать с кодом на С? Перекомпилировать каждый раз, когда я хочу что-то изменить?

> Они и скажут init'у, что "появился такой-то bluetooth-адаптер", а systemd же запустит bluetoothd.

И зачем для этого systemd? udev отлично выполняет запуск программ при появлении устройств. Так много лет работает usb_modeswitch.

> Или "появился раздел жёсткого диска", systemd увидит, что в /etc/fstab в последней колонке напротив него не 0, скажет systemd-fsck, чтобы тот запустил fsck.

А если я этого не хочу? А если это - битая флешка, и мне нужно восстановить с нее файлы, а fsck добьет то, что там осталось? Если в fstab-е было noauto, значит никаких действий быть не должно, и точка. Если не было - он должен монтироваться и проверяться при загрузке. Не надо решать за меня, что мне нужно. Система должна делать то, что ей сказано. Это - не винда. Я не должен каждый раз угадывать, что на этот раз может произойти.

Кстати, был и такой баг в systemd, он монтировал даже то, что отмечено noauto. Это исправили?

anonymous ()
[#] Ответ на: комментарий от gentoo_root 17.06.2011 23:17:40  

> Зачем куча костылей, если есть всё в одном флаконе?

Неужели надо объяснять основы unix? "Write programs that do one thing and do it well." Когда есть отдельные программы для каждой задачи - есть выбор, я могу их комбинировать и настраивать как мне нужно. Когда есть одна программа, которая пытается делать все, я связан возможностями и глюками этой одной программы.

Два варианта: нормальный init+dbus+xinetd+udev+readahead+ulatencyd против systemd все-в-одном.

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

Когда-то был devfs, потом ему на смену пришел udev, если через два года придет newdevd, то в первом варианте его можно будет заменить, а остальные компоненты будут работать, во втором варианте жесткая зависимость от udev сделает систему незагружающейся вообще.

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

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

Пока init-демон являлся маленькой пускалкой bash-скриптов - все было замечательно. Даже если что-то не так - всегда можно открыть скрипты и легко найти ошибку или исправить проблему. Но когда проблема - внутри systemd, то чем исправить ее, легче признать ошибку фичей, что Леннарт обычно и делает. А ошибки в systemd еще править и править. `shutdown -h 10m` когда заработает?

На данный момент мы имеем: критически важный для системы init-демон не имеет ни прямой ни обратной совместимости, содержит море ошибок и вызывает кучу проблем, а в перспективе, зная любовь Леннарта к виндоподобным монстрам, он будет создавать этих проблем еще больше. При этом заставляет отказаться от кучи возможностей, которые были раньше, и не дает НИ ОДНОЙ НОВОЙ возможности взамен. Втопку такой init.

Леннарт хоть раз писал что-то, что работало из коробки?

anonymous ()
 ← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 →
Linux General