Чому systemd - це погано?

Навколо systemd вже кілька років ходять «холивары». Systemd прийшов до нас на заміну System V Init в Linux. Є як прихильники systemd, так і його противники. Давайте розглянемо, чим же так поганий systemd:

1. Systemd порушує філософію Unix «Робити одну річ і при цьому добре», представляючи просто складний набір нев'язких бінарників. Його зона відповідальності давно вже виріс за рамки системи ініціалізації і починає розповсюджуватися на управління живленням, пристроями, точками монтування, cron-му, шифровнием диска, API сокетів, журналами (syslog), конфігурацією мережі, управлінням сесій, предчтение(readahead), визначення розділів, реєстрація контейнерів [віртуалізація], управління ім'ям хоста-часом-локаллю, mDNS/DNS-SD, консолі Linux та інші штуки — все в одному. На порядку денному — подальше розширення systemd і його впровадження в середу GNU/Linux було з'ясовано під час «2014 GNOME Asia talk». Дайте нам KISS.

2. Журнали systemd (для journald) зберігаються в дуже складному бінарному форматі і можуть бути запитані лише journalctl. Це робить журнали потенційно повреждаемыми і вони не мають ACID-сумісних транзакцій. Ви б не хотіли, щоб з системними журналами щось сталося. Порада від systemd розробників? Забийте. Єдиний шлях створити традиційні логи — це запустити syslogd як rsyslog разом з journald. Так само там є вбудований HTTP сервер. QR коди теж можна віддавати через нього, за допомогою libqrencode.

3. Так як systemd дуже зав'язаний на API ядра Linux, різні версії systemd несумісні з різними ядрами і портируемость безглуздо знижена в різних компонентах. Це політика ізолювання [systemd], яка, звичайно ж, вганяє екосистему Linux в свою власну клітку, працюючи як перешкода у розробці портируемого як з Linux, так і Unix-деривативами. Так само це породжує труднощі з бекпортированием змін до системою тривалої підтримки.

4. udev і dbus стають обов'язковими залежностями. За фактом, udev був влитий в гілку systemd дуже давно. Інтеграція менеджера «node device»( який був частиною Linux ядра) — це нелегке рішення. Тут висока політична підоснова (мається на увазі політика розробників) і багато пакетів, що залежать від udev, стали залежні від systemd, незважаючи на форки начебто eudev. Починаючи з systemd-209 розробники ввели власний нестандартний і малодокументированный sd-bus API, який заміщує деякі завдання libdbus. Далі вони вирішили перенести udev на цей новий транспорт, замінили Netlink і зробили udev наглухо прив'язаним до systemd демоном. Ефект, звичайно, значний.

5. systemd являє хелпер який знімає coredump-и (дампи ядра) і перенаправляє їх або в /var/lib/systemd/coredump або в journal, де вони повинні бути запитані через coredumpctl. Останнє, причому — була поведінка за замовчуванням і його схоже повернуть. Це означає, що користувачів та адмінів тримають за ідіотів, але більш важливо, в основі своїй схильна до пошкоджень природа логів journald перетворює це в серйозну перешкоду і безвідповідальний вибір при дизайні системи. Також це може створити ускладнення в багатокористувацьких середовищах в плані привілеїв.

6. Розмір systemd (мабуть, у файлах і мегабайтах — прим.пер.) перетворює його в велику «єдину точку відмови». На момент написання systemd мав 9 звітів CVE (вразливості) з початку впровадження у березні 2010. Начебто і не багато, але його всепроникна (в плані відповідальності за компоненти) і важлива суть може стати ласим шматочком для зломщиків, так як його широта менше ніж ядро, але настільки ж критично наслідків (прим. пер. — по мені так це вже лицемірство і лукавство.)

7. systemd має вірусний характер, його розширення додають нові API, але продовжуючи залежати саме від його ініціалізації. Його охоплення функціональності і розповзання як залежність по купі пакетів означає, що мейнтейнери дистрибутивів будуть зобов'язані змушувати перехід або зносити геть (старе). Наприклад, GNOME зазвичай використовує компоненти systemd начебто logind і підтримка не-systemd систем стає складною. Під Wayland GNOME використовує logind який знову змушує використовувати systemd. Все більше мейнтейнерів прописують в залежності systemd з цієї причини. Швидке зростання у прийнятті в такі дистрибутиви, як Debian, Arch Linux, Ubuntu, Fedora, openSUSE показує, що багато хто намагається застрибнути в потяг, іноді бездумно (може тут не точно переклав). Наприклад, дивно, що від нього залежать Weston compositor, Polkit, upower, udisks2, PackageKit, і тп. Так само нічого особливо не дає те, що systemd не хоче запускатися під користувачем.

8. systemd запускає (clusters — тісниться, юрмиться — прим. пер.) себе під PID 1, замість того щоб працювати як окремий гіпервізор процесів. Так як він контролює купу компонентів, існує темрява варіантів, в яких він може померти (закрашиться) і відправити в небуття всю систему (див. вище про точку відмови). Ми також відзначаємо, що щоб знизити потреби перезавантаження, systemd надає механізм для перезапуску systemctl в реальному часі. Але якщо з ним не так, то система знову йде крахом. Так само є різні шляхи, як це може статися, включаючи неможливість прочитати попередній несумісне стан. Це, схоже, інший приклад SPOF (одна точка відмови) і непотрібному тягаря і так вже критичне комноненте (init).

9. systemd розроблений з glibc-в-розумі і не особливо підтримує інші libc-и. Загалом, ідея розробників systemd у стандартної бібліотеки libc — та, що баг-в-баг повторить glibc.

10. Складна «душевна» організація systemd (метафора пер.) робить дуже складною розширення за межами його власних рамок (середовища) розробки. В той час, як запустити йшов скрипт з файлів модулів як-то можна, досить складно написати реалізацію поведінки, яка йде з коробки, з урахуванням усіх цих крутих фіч. Багато користувачів частіше хочуть написати складні програми, які прямо взаємодіють з API systemd, або навіть модифікувати (исходники). Хтось може потурбуватися про велику кількість шляхів у коді у критичною для системи програмі, включаючи можливість того що systemd не синхронізується з шиною повідомлень при завантаженні і зависне. Це протилежно традиційному иниту, який визначаємо і передбачуваний по архітектурі.

11. У кінцевому рахунку, поширення systemd символічно трохи більше ніж просто systemd. Воно показує радикальний зсув у мисленні спільноти Linux. І не обов'язково позитивному. Це зрушення здебільшого орієнтовані на десктоп, обмежує вибір, изоляционистский, велосипедостройный і просто величезна-антипаттерный. Якщо ваше завдання потурати найменшим дільнику, робіть це. Але ми подивимося в якусь іншу сторону.

12. systemd взагалі схоже не знає що за хренью він хоче бути. Він іноді описаний як «system daemon» або «базовий блок в просторі користувача щоб зробити ОС», обидва терміна дуже неоднозначні. Він поглинає функціональність яка був util-linux, бездротовим інструментів (wireless tools), syslog і іншим проектам. У нього немає чіткого напрямку, крім як примхи самих розробників. Що цікаво, незважаючи на цілі по стандартизації дистрибутивів Linux, у нього немає чіткого стандарту і він по суті просто котиться, як перекоти-поле.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.