Systemd ohno

[AJenbo]

Jeg kan se de ikke kan lide SystemD pga. den indeholder flere binær der skal arbejde sammen om flere opgraver og der med ikke mener det underbygger Unix filisofien, men ville det ikke også gælde for Debian som også er en støre samling binære der skal arbejde sammen om mange ting, så hvor for forke den

[lath]

Jeg kan se de ikke kan lide SystemD pga. den indeholder flere binær der skal arbejde sammen om flere opgraver og der med ikke mener det underbygger Unix filisofien, men ville det ikke også gælde for Debian som også er en støre samling binære der skal arbejde sammen om mange ting, så hvor for forke den

Det er vist det man kan kalde for en ret fri oversættelse af deres budskab.

/Lars

Edit 1: typo rettet

[lath]

Jeg mener at http://boycottsystemd.org/ beskriver problemet med systemd meget godt:

Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.

1. The rundown systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, mDNS/DNS-SD, the Linux console and other things all wrapped into one. The agenda for systemd to be an ever-growing and invasive middleware for GNU/Linux was elucidated in a 2014 GNOME Asia talk2. Keep it simple, stupid.
   

2. systemd's journal files (handled by journald) are stored in a complicated binary format3, and must be queried using journalctl. This makes journal logs potentially corruptible, as they do not have ACID- compliant transactions. You typically don't want that to happen to your syslogs. The advice of the systemd developers? Ignore it. The only way to generate traditional logs is to run a standard syslogd like rsyslog alongside the journal4. There's also embedded HTTP server integration (libmicrohttpd). QR codes are served, as well, through libqrencode.
   

3. Since systemd is very tightly welded with the Linux kernel API, different systemd versions are incompatible with different kernel versions and portability is unnecessarily hampered in many components. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, serving as an obstacle to developing software portable with both Linux variations and other Unix-like systems. It also raises some issues backporting patches and maintaining long-term stable systems.
   

4. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago5. The integration of the device node manager, which was once a part of the Linux kernel, is not a decision that is to be taken lightly. The political implications of it are high, and it makes a lot of packages dependent on udev, in turn dependent on systemd, despite the existence of forks, such as eudev. Starting with systemd-209, the developers now have their own, non-standard and sparsely documented sd-bus API that replaces much of libdbus's job, and further decreases transparency. Further, they intend to migrate udev to this new transport, replacing Netlink and thus making udev a systemd-only daemon6. The effects of this move are profound.
   

5. systemd features a helper which captures coredumps and directs them either to /var/lib/systemd/coredump... or the journal, where they must be queried using coredumpctl7. The latter behavior was a default and is likely to return8. It assumes that users and admins are dumb9, but more critically, the fundamentally corruptible nature of journal logs makes this a severe impediment, and an irresponsible design choice. It can also create complications in multi-user environments related to privileges.
   

6. systemd's size makes it a single point of failure. As of this writing, systemd has had 9 CVE reports, since its inception in March 201010. So far, this may not seem like that much, but its essential and overbearing nature will make it a juicy target for crackers, as it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical.
   

7. systemd is viral by its very nature, due to its auxiliaries exposing APIs, while being bound to systemd's init. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment often makes use of systemd components, such as logind, and support for non-systemd systems is becoming increasingly difficult. Under Wayland, GNOME relies on logind, which in turn requires and is a part of systemd11. More and more maintainers are going to require systemd for this reason, and similar instances like it. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. Other dependent packages include the Weston compositor, Polkit, upower, udisks2, PackageKit, etc. It's also worth noting that systemd will refuse to start as a user instance, unless the system boots with it as well - blatant coercion12.
   

8. systemd clusters itself into PID 1, rather than acting as a standalone process supervisor. Due to it controlling lots of different components, there are tons of scenarios in which it can crash and bring down the whole system. We should also mention that in order to reduce the need for rebooting, systemd provides a mechanism to reserialize and reexecute systemctl in real time, however, if this fails, of course, the system goes down. There are several ways that this can occur13, including an inability to reload a previous, potentially incompatible state. This happens to be another example of SPOF and an unnecessary burden on an already critical component (init).
   

9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much14. In general, the systemd developers' idea of a standard libc is one that has bug-for-bug compatibility with glibc.
   

10. systemd's complicated nature makes it harder to extend and step outside its boundaries. While you can more or less trivially start shell scripts from unit files, it's more difficult to write behavior that goes outside the box, what with all the feature bloat. Many users will likely need to write more complicated programs that directly interact with the systemd API, or even patch systemd directly. One also needs to worry about a much higher multitude of code paths and behaviors in a system-critical program, including the possibility of systemd not synchronizing with the message bus queue on boot, and thus freezing. This is as opposed to a conventional init, which is deterministic and predictable in nature, mostly just serially execing scripts.
    

11. Ultimately, systemd's spread is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and is just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.
    

12. systemd doesn't even know what it wants to be. It is variously referred to as a "system daemon" or a "basic userspace building block to make an OS from", both of which are highly ambiguous. It engulfs functionality that variously belonged to util-linux, wireless tools, syslog and other projects. It has no clear direction, other than the whims of the developers themselves. Ironically, despite aiming to standardize Linux distributions, it itself has no clear standard, and is perpetually rolling.
    

Links i [ ] kan findes på web siden.

Hvad kunne jeg så vælge som erstatning for SysV-init og Systemd?
Det er launchd som blev udviklet af Apple til MAC OS X 10.4. Koden er licenseret under Apache Licensen.

Man page for launchd(8):https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/launchd.8.html

Der er også en Google TechTalk om launchd:

http://youtu.be/mLwn_TbBntI

/Lars

[AJenbo]

Hvad kunne jeg så vælge som erstatning for SysV-init og Systemd?
Det er launchd som blev udviklet af Apple til MAC OS X 10.4. Koden er licenseret under Apache Licensen.

Eller Upstart som vil være at finde i ubuntu i mindst 4½ år frem

[martin joergensen]

Systemd har da sneget sig ind på mit system Ubuntu 14.04
Jeg er dog stadig ikke gået i gang med at læse mig op på det.

[lath]

Systemd har da sneget sig ind på mit system Ubuntu 14.04
Jeg er dog stadig ikke gået i gang med at læse mig op på det.

Det er ikke den fulde udgave.
Se wikipedia siden for systemd under "adoption" > Ubuntu

/Lars

[NickyThomassen]

Af ovenstående årsager, har jeg lidt svært ved at overskue systemd's indflydelse på et system.

Og under alle omstændigheder kan jeg ikke se det rationelle i, at det tager systemd så mange programmer at erstatte sysV init.

Desværre har vi ikke noget at skulle sige; Debian rykker fra næste udgave over på systemd, og på trods af tidligere forbeholdenhed, følger Ubuntu med derefter. Hovedårsagen fra Debians vedligeholdere, er at det ville blive uoverkommeligt, at stå alene tilbage med sysV init som en af de eneste distro'er i Linux land.

Jeg tror det er på tide at prøve noget nyt inden da. Desværre er Debian en af de mest konservative Linux'er der er, så noget nyt bliver en *BSD. Sikkert FreeBSD.

Uden at gå ind i den flame-war der stadig kører over systemd, så syntes jeg det er ærgerligt at se tingende udvikle sig sådan her. På den anden side er det forfriskende at se, hvor lidt almindelige brugers mening og frihed er værd, når bare én fyr får en god idé, og udviklere/vedligeholdere gerne vil spare tid.

[AJenbo]

SystemD erstatter mere end blot SysV og jeg syndes ofte det glemes når der laves et skema som overstående, det burde enten kun inkludere de dele der erstatter SysV eller der burde laves et tilsvarende der indeholder alle de dele som SystemD erstatter.

[Jimmyfj]

Back to square one?

GNU/Linux er en Unix-KLON ikke UNIX - May I remind you: GNU=GNU is Not UNIX. Der findes mange eksempler på software, der gør mere end én ting under Linux, og det har da fungeret upåklageligt gennem 30+ år.

For den mere "politisk korrekte" bruger, med hang til udfordringer, findes der, som allerede nævnt alternativer som FreeBSD, GhostBSD, NetBSD o.s.v.

Selv har jeg prøvet denne: http://www.pcbsd.org/ og kan kun anbefale den, rigtig varmt endda.

Men. Du bevæger dig tilbage til det driver/kompatabilitets-helvede Linux var for år tilbage, og for hvad? For at kunne leve op til en filosofi fra slut 60'erne? Den glade hippie/flower-power-tid?

Men tilbage til PC-BSD. Har du ikke noget imod at læse op på noget anderledes, er denne BSD-distro suveræn. Den bygger på Free-BSD og er lige til at gå til selv for begyndere. Den har grafisk installer, som er let at arbejde med. Den er pænt hurtig i det daglige, og æstetisk er den smuk.

Men, men. Linux ER og BLIVER Linux, systemd eller ej. Systemd er relativ ny, det samme var sysV Init og Upstart engang.
Giv systemd en chance. Hvis den viser sig ikke at være tilstrækkelig VIL der komme en alternativ løsning.

Jeg mener at det er hysterisk at have mistro til systemd alene på grund af, at det er EN mands ide. Hvordan vil du forsvare den påstand velvidende, at Linux jo også er EN mands ide, og den mand er Linus Thorwalds.

[NickyThomassen]

Back to square one?

I bedste fald bliver systemet vel stående hvor det er, men jeg kan ikke se at det skulle være et skridt tilbage. Jeg har p.t. 2 init-scripts jeg selv har skrevet, og min forståelse af systemd er, at de måske vil virke. Hvis bare et af dem skal kodes om, så er min tid bedre brugt på at holde fast i sysV. For ikke at nævne, at jeg slipper for at lære systemd at kende. Imellem Postfix, Apache og andre serverprogrammer, er det ikke ligefrem et nyt init-system jeg har løst til at bruge tid på.

Når jeg starter et system op, så kører det sjældent under 12 timer inden jeg slukker det igen, så opstartstid er ligegyldigt. Dertil bruger jeg mine computere som servere, flere af dem er uden GUI fx. De er specifikt købt til Linux og kan køre uden proprietære drivere. Og efter at Debian nedlagde backports, er man enten tilbage til apt-pinning eller make, hvor *BSD'ernes Ports system leverer mere tidssvarende software, uden at man selv skal finde The Source.

Så nej, jeg har ikke som sådan et abstrakt ønske om de glade '60, men bare fordi en ny generation kommer til, behøves den vel ikke pr. automatik genopfinde den dybe tallerken.

Linus var "bare" interesseret i et OS der virkede. Han har aldrig forsøgt at belemre andre med hans kode, eller ladet som om han var bedre end andre. Dertil er han jo kun én blandt mange der har bidraget til det vi kender som Linux i dag. GCC er fx lavet af GNU.

Udvikleren af systemd har bl.a. udtalt

One goal of systemd is to unify the dispersed Linux landscape a bit. We try to get rid of many of the more pointless differences of the various distributions in various areas of the core OS. As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration.

http://0pointer.de/blog/projects/the-biggest-myths

In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!

https://archive.fosdem.org/2011/interview/lennart-poettering

Open Source Community "Quite a Sick Place To Be In"

(kommentarerne er også ret spændende http://beta.slashdot.org/story/208149)

Så at sammenligne de to fyre er lidt som at sammenligne æbler og bananer.

[AJenbo]

Men du burde vel og kunne se fordelen ved at skrive 1 init script som så vill fungere på både fedora, ubuntu og Debian. Som det er i dag ville det være nødvendigt med 3 init scripts.

[lath]

Men du burde vel og kunne se fordelen ved at skrive 1 init script som så vill fungere på både fedora, ubuntu og Debian. Som det er i dag ville det være nødvendigt med 3 init scripts.

Jeg er sikker på at @NickyThomassen og jeg har det på samme måde.

Jeg bruger ikke et mix af forskellige distros (for eksempel Fedora, Ubuntu, og Debian) som server styresystem på mine servere, da det er uhensigtsmæssigt at der er op til flere måder at lave server vedligeholdelse på. Det uhensigtsmæssige er mere unødvendigt arbejde.

Der er derfor kun en type af init script for mine servere.
Jeg kan nævne at jeg tænker på at give Debian sparket som mit server styresystem. Det vil så blive erstattet af FreeBSD.

/Lars

[AJenbo]

Det er jo så nettop dette problem der ville blive mindsket/fjernet i fremtiden, så det er lige for det lyder som om du augmentere for SystemD.

[lath]

Det er jo så nettop dette problem der ville blive mindsket/fjernet i fremtiden, så det er lige for det lyder som om du augmentere for SystemD.

Nej, systemd er og bliver klyt-kode med drastisk forøget kompleksitet og tæt kobling, og er derfor alt andet end Keep It Simple, Stupid (KISS).

Jeg stoler ikke på et PID=1 program der er så komplekst som systemd.
Hvis systemd har PID 1 og systemd processen crasher, så rydder kernen alle andre programmer på computeren, da forældreprocessen over alle forældreprocesser (systemd) er død.
Det er nøjagtig den samme mekanisme som er i spil hvis du åbner en terminal og starter et program, og dræber terminalprocessen. Resultatet er at terminalprocessen dør, og at alle processer der er barn af terminalprocessen også dør.

/Lars

[NickyThomassen]

@AJenbo

Det er rigtigt at jeg kun burde sammenligne sysV og den ene komponent fra systemd som skal erstatte den, men går noget af designideen så ikke af systemd? De har jo netop lavet systemd så bredt fordi de mener init, syslogging, dbus og hvad ellers hører sammen. Den ansvarlige vedligeholder fra Arch skrev ved overgangen

I have spent too much time arguing against the perceived deficiencies of systemd (such as: "it is not written in bash", "it was started by Lennart Poettering", "I don't like the (optional) on-disk format of the journal", "it uses dbus", "systemd's PID1 does more and is bigger than sysvinit's PID1", "I think there might be this other project that possibly is doing something similar. I don't really know anything about it, but I'm pretty sure it is better than systemd" and I'm sure there are many more). I strongly believe that 1) all of these perceived deficiencies are not deficiencies, but are actually benefits 2) even if I'm wrong, these things are not hugely important. So, with that out of the way: let's ignore all of those old boring arguments and I'll outline a few things that I find awesome about systemd, and why I think we should all be very excited about soon being able to use it

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Hans argumenter er ganske gode, og jeg vil da også skynde mig at sige, at selvfølgelig er der fordele ved systemd fremfor sysV, alt andet ville da være underligt. Problemet med hans argument er, at det kan vendes på hovedet: Jo, der er fordele ved systemd, men de kan ikke opveje ulemperne, og selv hvis jeg tager fejl, er det ikke ret vigtigt(!). Det samme gælder for at strømline de forskellige distroer, for hvorfor så have dem? Ubuntu og Mint er "bare" variationer, og kunne ligeså godt blive nedlagt igen. Udviklerne omkring de 2 distroes GUIs kunne så arbejde sammen med resten af Debians udviklere. Det ville give projektet mulighed for, at lave et grundsystem som både kan servere og skrivebordscomputere, imens de forskellige GUI folk kan lave højt specialiseret skriveborde, som giver den sande skrivebordsoplevelse.

Senere hen kunne Debians unstable branch blive til en rigtig rolling release branch, og Gentoo og de andre kunne også nedlægges. Til sidst mangler kun at få assimileret GNUs folk, men de er nok en tabt sag. Med kun én Linux distro ville der ikke længere være problemer med tilpasning af software og den slags, og oldschool systemer som X ville nemmere kunne vedligeholdes / erstattes. Canonical og Red hat kunne betale serverudgifter og udviklere som Thorvals, og stadig sælge specialiseret udgaver af denne Super Linux.

Som @Lath er inde på, så bruger jeg Debian af nogle ret specifikke årsager, og selvom systemd åbenbart ikke er nem at argumentere for/imod, så syntes jeg bruddet er for stort. Hvis jeg var til den slags ændringer, så brugte jeg Ubuntu, og det er ikke ment som kritik, men som en helt klar ros af Ubuntu. Og i min mening også årsagen til at der ikke kun er én distro, men flere. For jeg håber da at vi er enige om, at der ikke som sådan findes "Den rigtige måde (TM)" at gøre tingende på, når det kommer til computere.

Jeg foretrækker min software støvet, konservativ og gennemtestet, men det er ligesom om det er ved at blive en fy-ting. Jeg er nok enten ved at blive gammel, eller også kan bedre forbinde med kulturen omkring de gamle systemer som UNIX og X, eller, universet forbyde det, både og.