Názory k článku
Proč přejít na systemd

Tohle se tedy povedlo - systemd neumí pracovat se samostatným oddílem /sys. Tedy pokud není libdbus v root partition... Copak je to zásadní problém pro nalezení jedné knihovny?

No nevim, ten seznam vyhod systemd proti sysvinit mi prijde spis jako seznam nevyhod. Takova integrace s plymouth mi dost pije krev, nejde to zrusit. Povinnost linux cgroups v kernelu mi taky prijde spis k placi. Interfacing via dbus je megazlo, atd.

Zda se mi, ze to s Linuxovym prostredim jde delsi dobu dost z kopce. Nejhorsi na tom je, ze se vyvojari nesnazi o zadnou zpetnou kompatibilitu, takze ty svoje blaboly nuti vsem.

To souhlasim .. ale treba se casem objevi zpusob, jak to dat dohromady se starym init-em, napr. ze stary init udela zakladni system a systemd to prevezme od casti kde se jedna jiz o uzivatelsky runlevel. Jako asi by to znamenalo dalsi sesloziteni o jednu uroven (initrd, init, systemd), ale prineslo by to ty nove moznosti i pro stavajici uzivatele kteri nechcou menit vse (napr. jako ja - bude me system po upgradu s tak zasadni zmenou fungovat?)

Ja myslim ze kompatibilitu se SysV initem potrebujete akorat na urovni sysv-like startovacich skriptu. Coz systemd poskytuje.

Nevim jestli jste se nekdy v posledni dobe divali, jaky propletenec skriptu a jednoucelovych hacku je soucasny boot (myslim prave tu oblast pred startem uzivatelskeho runlevelu). Treba lvm i SW RAID se musi startovat jak v initrd, tak v rc.sysinit (a stejne tam nektere konfigurace - treba RAID 1+0 - nejdou udelat. Nastesti ted uz kernel umi nativni RAID-10.

Sice z toho nemam uplne dobry pocit, ze se stare dobre citelne shellskripty nahrazuji needitovatelnymi kompilovanymi programy, ale je-li vyhodou ze kazdy program nedela svoji polofunkcni variantu PID-souboru a testu jestli bezi (/etc/init.d/$sub­system status), tak jsem ochoten to vymenit.

-Yenya