Nogen er ikke særlig glade for: systemd

Nyheder om Open Source, Ubuntu, andre distributioner og meget mere.
lath
Indlæg: 5095
Tilmeldt: 27. apr 2008, 02:16
IRC nickname: lars_t_h
Geografisk sted: Fyn

Re: Nogen er ikke særlig glade for: systemd

Indlæg af lath »

Jimmyfj skrev:For mig at se er det misinformation at påstå, at systemd ikke overholder UNIX-princippet med ét program, ét job, rigtig godt udført.

Misinformation?

Det er et spørgsmål om software design, og i systemds tilfælde laver den for mange urelatede ting i den samme process.
Det var derfor jeg skrev at det var en god ide - lavet på en dårlig måde.

Som uddannet datamatiker og it-ingeniør har jeg som mange andre der er professionelle ud i softwareudvikling sædvanligvis et helt bestemt sæt af holdninger til hvad der er klyt-kode, og hvad der ikke er klyt-kode.
Det er ikke unikt for softwareudviklere at et fag har nogle markante meninger til hvad der er godt, og hvad der er klamp - det findes i alle fag.

systemd er en god ide, men den er desværre implementeret så den lander i klyt-kode kategorien, fordi den har et dårligt software design.

/Lars
Jeg er Software ingeniør (Diplomingeniør) i Informationsteknologi og indlejede systemer, hvor indlejrede systemer er computer (microcontroller) + elektronik i for eksempel et TV, en router, en vaskemaskine og den slags
AJenbo
Admin
Indlæg: 20878
Tilmeldt: 15. nov 2009, 15:04
IRC nickname: AJenbo
Geografisk sted: Vanløse, København

Re: Nogen er ikke særlig glade for: systemd

Indlæg af AJenbo »

Må jeg tilføjer at jeg også er professionel software udvikler med over 10 års erfaring, og er enig med, Jimmyfj, selv om jeg ikke rigtig syndes det er et argument der rigtig kan bruges til noget.
gaffa

Re: Nogen er ikke særlig glade for: systemd

Indlæg af gaffa »

Selvom det er lidt ligegyldigt, så er min holdning at jeg aldrig vil bruge en opstarter med SystemD's design. Heldigvis er der igen der tvinger mig til at bruge SystemD, så jeg håber da bare at de har det sjovt med at skrive en opstarter (og alt det andet de har ambitioner om at den skal gøre) og drager sig en masse brugbare erfaringer.... og held og lykke med debug arbejdet, der bliver en noget større opgave end det er med init's design! :)

3) it allows dbus/udev to go back to doing the task they are meant to do: both udev and dbus are currently (mis)-used to start daemons/long-running services on demand. In the case of dbus this is by design, but in the case of udev it is not. Either way, it is not what those daemons were built to do, so in keeping with the UNIX principle of one task per daemon, it is great that we can now let systemd (whose job it is to manage daemons) take this over. That is, udev and dbus can both signal systemd to start a certain daemon, and it will behave like if it was started in any other way (you have the logs, status etc). One problem that this solves is the inherent race-condition in some daemons (I think bluetoothd was guilty of this at some point) allowing both being started as soon as possible on boot (say by putting it in DAEMONS), and to be started on-demand by dbus. Systemd makes sure that both these things can happen, and if they do happen at the same time you will only end up with one instance of the daemon as expected.


Det er lidt en spøjs kommentar, der ihvertfald har en idé om hvad dbus og udev må og ikke må bruges til. Det bliver så efterfulgt af en selvmodsigelse at dbus er designet til formålet alligevel. Måske vil det være mere produktivt at fokusere på de opstart-scripts personen er irriteret over?

Jeg vil gætte på at sætningen om "keeping with the UNIX principle of one task per daemon", er et svar i irritation over en anden der har brugt det som argument. Jeg kan hvertfald ikke umiddelbart se hvad der menes og jeg har ikke hørt om det princip før eller hørt det brugt så forkert.

Det er vel hverken dbus eller udev's skyld, hvis de skal starte et program der er dårligt kodet? De gør det de skal.

Man kan da ikke bebrejde init, hvis eneste formål er at starte det du siger at den gør det og man kan da ikke bebrejde udev at den udfører opsætning den får besked på? Det der må være tale om er en uenighed om hvilket design man bedst kan lide og man kan ikke blive enige om holdninger medmindre man har den samme.

Doesn't that seem a lot more straightforward? Yes, it's more functions,
but each function is a lot more obvious. This follows the unix rule of "do
one thing, and do that thing well", instead of trying to make one function
do many very different things depending on what you actually want done..

Linus
Kilde: http://yarchive.net/comp/linux/hibernation.html#13