Boycott systemd

[GoofyX]

Στο G+ βρήκα το παρακάτω link: http://boycottsystemd.org/

Το έγραψε ένας τύπος και αναφέρει αρκετούς λόγους για τους οποίους το systemd είναι κακό εξαρχής και πρέπει να μην υιοθετηθεί. Αρκετοί από τους λόγους που δίνει θεωρώ ότι έχουν βάση.

Στο Gentoo δεν έχω μεταβεί σε systemd ακόμη. Είναι όντως τόσο κακό όσο αναφέρει ο τύπος αυτός; Ήδη αρκετές διανομές το έχουν επιλέξει...

[KernelPanic]

Κατα την ταπεινή μου άποψη ναι...
Μπορεί να είναι καλό για desktop environments και να εξηπηρετεί admins που έρχονται απο windows περιβάλλον αλλα για Enterpise IT δεν με έχει πείσει ακόμα (και δεν το βλέπω να με πείθει και συντομα)...

Ας ελπίσουμε οτι στο gentoo θα συνεχίσουν την υποστήριξη στο openrc...

[giorgosts]

https://news.ycombinator.com/item?id=7639170

Spittie 132 days ago | link

Okay, I like to think as myself as an open minded individual. I'm not a systemd fanboy either, I just research and use what I believe it's better for myself. There is a reason why I can't consider the anti-systemd guys seriously: It all seems FUD to me. Take for example point 8, "you have to reboot to update systemd. Okay, not really, but the update might go wrong!". Really?

Going point by point:

1. As the site says, systemd is both an init system and a collection of programs that make sense to have in a system. One can already strip most of everything from it (I think only journald is mandatory), and there is usually a stable api between every component, so one can simply replace them.

In fact, I believe that half of the complains about systemd would disappear if it all the tools were developed in a different repository and not under a "systemd umbrella" (Isn't one of the major point pro-BSD the fact that the base system is all developed together?)

2. If you want to use systemd but have plain-text logs, journald can pass everything to syslog and similar daemons. What everyone forget is the bonus that journald provides: no more "cat /var/log/*.log | grep <program> | sort -u" and hope that applications log in the same format, I have everything in a single place and can browse them by unit, by user, by time, by urgency...

3. I can agree with that. But it's not that sysinitv or upstart worked on non-linux systems (without ugly hacks)

4. And? I'm not sure what's the problem here. udev and dbus are mandatory by pretty much anything that's not a .sh script nowadays.

5. Okay, fair point. "It assumes that users and admins are dumb" can you really blame them?

6. Fair point again, systemd is bigger than sysinitv. But that's almost saying that we should all use microhttpd instead of nginx/apache because it's smaller.

Also the simple fact that it's included in RHEL 7 mean that it got audicted by RH, which make me feel safe.

7. That's just FUD. Here's Gnome 3.10 running on OpenBSD: http://undeadly.org/cgi?action=artic...20140219085851

Gnome will depend on systemd when under wayland, that's instead a fact. Actually, on logind, which has an api that anyone can reimplemnt (https://blogs.gnome.org/ovitters/201...ome-and-logind...)

8. Not true, again. Right now, on my system:

pgrep -l systemd
1 systemd
354 systemd-journal
386 systemd-udevd
766 systemd-logind
1190 systemd
1754 systemd

Also, I still fail to see why "it's big, it will fail" is a thing. What matters is code quality, not size.

9. Fair point.

10. This might or not be possible, I don't have much experience in writing unit files so I don't really know the limits.

11. Nobody is forcing anyone to adopt systemd. It's getting adopted because distributions and developers think it's better.

And after months/years of complains about systemd, I still haven't seen anyone trying to produce anything that has the same advantages for sysadmins and programmers.

Really, that's how it feels: "I'm going to complain and complain and complain, but I won't lift a finger to change the course of events".

Can anyone make a point in favor of sysinitv (or against systemd) without bringing in abstract concept as "Unix philosophy" and plain wrong facts

[karakou]

Αν κ δεν είμαι κανας γκουρου της c ούτε του λίνουξ, κάποια απο τα επιχειρήματα που παραθέτει είναι εύλογα. Παρόλαυτα το systemd είναι κάτι θετικό(a single point of aministration but not a single point of failure) και δουλεύει καλά προς στιγμή. Ενταξει η μετάβαση είναι δύσκολη στην αρχη αλλά αξίζει το κόπο. Χρειάζεται να μάθεις πραγματάκια που για κάποιον που ξερει ήδη κάποιες γλώσσες προγραμματισμου και bash/λινουξ administrating(έναν δεινόσαυρο π.χ) είναι ενοχλητικό, αλλά το learning curve δεν είναι τόσο απότομο.

[KernelPanic]

a single point of aministration but not a single point of failure

Συνήθως αυτα πάνε μαζι...

Και ρωτάω εγω τώρα: παίρνωντας PID 1 το systemd και αυξάνοντας το attack surfuce μέσω του userland πόσο επιτυχία μπορεί να έχει το παραπάνω?

Επίσης τί γίνεται αν πρεπει να κάνεις update το systemd ή κάποιο απο τα components του ? Μάλλον reboot...

Αυτό σε traditional unix servers δεν είναι αποδεκτό... Ο μόνος λόγος για να κανεις reboot 1 unix server ήταν κάποιο critical kernel patch to οποιο δεν μπορούσε να γινει apply on the fly...

Αν είναι το linux na γίνει σαν τα windows με 1 σωρό apis και αδιαφανείς διαδικασίες με βλέπω να στρέφομαι σε BSD...

[megahead13]

Συνήθως αυτα πάνε μαζι...

Και ρωτάω εγω τώρα: παίρνωντας PID 1 το systemd και αυξάνοντας το attack surfuce μέσω του userland πόσο επιτυχία μπορεί να έχει το παραπάνω?

Επίσης τί γίνεται αν πρεπει να κάνεις update το systemd ή κάποιο απο τα components του ? Μάλλον reboot...

Αυτό σε traditional unix servers δεν είναι αποδεκτό... Ο μόνος λόγος για να κανεις reboot 1 unix server ήταν κάποιο critical kernel patch to οποιο δεν μπορούσε να γινει apply on the fly...

Αν είναι το linux na γίνει σαν τα windows με 1 σωρό apis και αδιαφανείς διαδικασίες με βλέπω να στρέφομαι σε BSD...

Ως sys admin δεν έχω πρόβλημα με το κλασσικό SYS V Init (είναι κάτι που ποτέ δε με απασχόλεισαι), χωρίς να λέω πως δεν πρέπει να προχωρήσουμε με κάτι καινούργιο. Από την άλλη δε με έχει πείσει κανένα από τα upstart ή systemd. Ειδικά με την περίπτωση του systemd δεν καταλαβαίνω γιατί να πρέπει να είναι dependency για DEs ή να προσπαθεί να πάει να τα κάνει όλα. Όταν πρόκειται για unixoserverοκαταστάσεις είμαι περισσότερο της λογικής "Do only one thing and do it good" και "Keep it stupid simple". Το ότι είναι παιδί της Redhat και επίσημα είναι στο RHEL7 δε μου λέει κάτι ως λειτουργικότητα και ως άξιος αντικαταστάτης των SYS V init scripts (ως σταθερός κώδικας όμως ναι).

Τώρα όσον αφορά τα γυρνάω όλα σε BSD, μακάρι να ήταν έτσι απλά. Γιατί εντάξει όταν πρόκειται για πράγματα όπως web ή ftp server ή για το αν είσαι ένας μικρομεσαίος οργανισμός. Όταν όμως μιλάμε για μεγάλους οργανισμούς ή για εμπορικές εφαρμογές που επίσημα υποστηρίζουν μόνο Redhat, Debian/Ubuntu, Suse (άντε και κάνα Solaris) τα πράγματα δεν είναι απλά, ιδιαίτερα δε όταν πληρώνεις κάτι χοντρά μαρούλια για licenses/support...

[GoofyX]

Συνήθως αυτα πάνε μαζι...

Και ρωτάω εγω τώρα: παίρνωντας PID 1 το systemd και αυξάνοντας το attack surfuce μέσω του userland πόσο επιτυχία μπορεί να έχει το παραπάνω?

Επίσης τί γίνεται αν πρεπει να κάνεις update το systemd ή κάποιο απο τα components του ? Μάλλον reboot...

Αυτό σε traditional unix servers δεν είναι αποδεκτό... Ο μόνος λόγος για να κανεις reboot 1 unix server ήταν κάποιο critical kernel patch to οποιο δεν μπορούσε να γινει apply on the fly...

Αν είναι το linux na γίνει σαν τα windows με 1 σωρό apis και αδιαφανείς διαδικασίες με βλέπω να στρέφομαι σε BSD...

Όταν έπρεπε το init αντίστοιχα να ενημερωθεί, δεν γινόταν reboot; Τι αλλάζει δηλαδή με το systemd σε σχέση με το κλασικό init;

[KernelPanic]

@megahead13 Συμφωνω 100% μαζί σου και αυτο λέω και παραπάνω οτι το systemd δεν με έχει πείσει για αντικαταστάτη του SYS V.

Τώρα όσον αφορά τα γυρνάω όλα σε BSD, μακάρι να ήταν έτσι απλά. Γιατί εντάξει όταν πρόκειται για πράγματα όπως web ή ftp server ή για το αν είσαι ένας μικρομεσαίος οργανισμός. Όταν όμως μιλάμε για μεγάλους οργανισμούς ή για εμπορικές εφαρμογές που επίσημα υποστηρίζουν μόνο Redhat, Debian/Ubuntu, Suse (άντε και κάνα Solaris) τα πράγματα δεν είναι απλά, ιδιαίτερα δε όταν πληρώνεις κάτι χοντρά μαρούλια για licenses/support...

δυστυχώς το ξέρω απο 1ο χέρι...

- - - Updated - - -

Όταν έπρεπε το init αντίστοιχα να ενημερωθεί, δεν γινόταν reboot; Τι αλλάζει δηλαδή με το systemd σε σχέση με το κλασικό init;

Το initd στηρίζεται περισσότερο σε shell scripts ( Ο C κωδικα ειναι σχετικα μικρός και δεν θυμαμαι να εχει αλλαξει για αρκετα χρόνια. , Αν κάνω λάθος διορθωστε με ) ενω to systemd είναι γραμμένο σε C οπότε οπως καταλαβαίνεις μια αλλάγή στον κωδικα χρειάζεται recompile κτλ κτλ ( για να μην αναφέρω dependencies και τα σχετικα)...

[mrsaccess]

Όταν έπρεπε το init αντίστοιχα να ενημερωθεί, δεν γινόταν reboot; Τι αλλάζει δηλαδή με το systemd σε σχέση με το κλασικό init;

Το /sbin/init είναι ένα εκτελέσιμο 2kb που απλώς τρέχει σαν daemon. Επί της πράξης δεν κάνει τίποτα και έχει να ανανεωθεί πάρα πολλά χρόνια. Αντίθετα το systemd μόνο καφέ δεν κάνει και ο λόγος για αυτό είναι πως δεν τρέχεις το λειτουργικό σου σε καφετιέρα. Αν το έτρεχες εκεί, το systemd θα έκανε και τον καφέ.

Σε γενικές γραμμές είναι βάσιμες οι κατηγορίες που ακούγονται. Είναι σημαντικό όμως να ξεχωρίσουμε πως το systemd δεν είναι απαραίτητα κακό από τεχνική πλευρά και έχει πολλά θετικά στοιχεία.
Το κακό imo είναι πως στην πράξη είναι ένα τεράστιο μονολιθικό πακέτο χωρίς προτυποποίηση. Μπορεί να σπάει σε πολλά εκτελέσιμα και κάποια από αυτά να έχουν μια μικρή τεκμηρίωση αλλά είναι αδύνατο αυτή την στιγμή να φτιάξει κάποιος μια εναλλακτική συμβατή υλοποίηση για ολόκληρο ή ένα μέρος του systemd.
Δυστυχώς Ubuntu, Debian, Arch (και νομίζω OpenSUSE) το κατάπιανε αμάσητο. Αφού το ανέπτυξε η Redhat, τα RHEL, CentOS, Fedora το κατάπιανε εκ των ων ουκ άνευ. Επομένως δεν μπορείς να το αποφύγεις.
Το καλό είναι πως πλέον υπάρχει μια κάποια ομοιογένεια μεταξύ των διανομών. Αν υπάρξει και κάποιο default format για packaging μπορείς να ξεχάσεις τις πολλές διανομές, θα μείνει μια binary και το Gentoo.

[dimitri_ns]

.
Το καλό είναι πως πλέον υπάρχει μια κάποια ομοιογένεια μεταξύ των διανομών. Αν υπάρξει και κάποιο default format για packaging μπορείς να ξεχάσεις τις πολλές διανομές, θα μείνει μια binary και το Gentoo.

Από δω το πήγες, από κει το πήγες, τόφερες τελικά εκεί που έπρεπε
Αν επαληθευτείς μας βλέπω να ξεμένουμε με sabayon και gentoo

[ESP1982]

Είναι σημαντικό όμως να ξεχωρίσουμε πως το systemd δεν είναι απαραίτητα κακό από τεχνική πλευρά και έχει πολλά θετικά στοιχεία.

Όπως τα predictable device names τύπου:

systemd-udevd[10581]: renamed network interface wlan1 to wlp0s29f7u2

Admin's inferno είναι αυτό, όχι init.

[MitsakosGR]

Όπως τα predictable device names τύπου:

systemd-udevd[10581]: renamed network interface wlan1 to wlp0s29f7u2

Admin's inferno είναι αυτό, όχι init.

Το systemd την κάνει αυτή τη μλκία και κάθε φορά πρέπει να πειράζω όλα τα αρχεία των δικτύων;;;!!!!
Και μέχρι τώρα το συμπαθούσα...

[ESP1982]

Το systemd την κάνει αυτή τη μλκία και κάθε φορά πρέπει να πειράζω όλα τα αρχεία των δικτύων;;;!!!!
Και μέχρι τώρα το συμπαθούσα...

Σε ποιό από τα over 9000 files το κάνεις αυτό;

[MitsakosGR]

Σε ποιό από τα over 9000 files το κάνεις αυτό;

Στο Arch στα αρχεία του netctl... Βέβαια τώρα βρήκα ότι αν το ξεκινήσεις με net.ifnames=0 τα κάνει όλα eth0 και wlan0 οπότε από εδώ και πέρα τέρμα οι παραμετροποιήσεις...

[esquellot]

Μια χαρά είμαι με systemd σε gentoo. Δεν έχω κανένα παράπονο. Αν δεν έκανε τη δουλειά του σωστά θα το ξήλωνα και θα έβαζα πάλι openRC.