Boycott systemd

[mrsaccess]

Το systemd είναι το git. Μέσα σε ελάχιστα χρόνια αντικατέστησε το init system και τα init tools όλων των μεγάλων binary διανομών αλλάζοντας ένα κατεστημένο που υπήρχε για πολλά χρόνια. Αντίστοιχα το git σύντομα αντικατέστησε τα υπόλοιπα cvs συστήματα αλλάζοντας το κατεστημένο του central repo με το distributed repo.
Κάθε φορά που γίνεται συζήτηση για git ή γενικά για cvs εμφανίζονται πολλοί έμπειροι χρήστες που εξηγούν γιατί το git είναι κακό, γιατί το mercurial είναι κλάσεις ανώτερο κλπ.

[megahead13]

http://igurublog.wordpress.com/2014/...ainst-systemd/

[imitheos]

Το systemd είναι το git. Μέσα σε ελάχιστα χρόνια αντικατέστησε το init system και τα init tools όλων των μεγάλων binary διανομών αλλάζοντας ένα κατεστημένο που υπήρχε για πολλά χρόνια. Αντίστοιχα το git σύντομα αντικατέστησε τα υπόλοιπα cvs συστήματα αλλάζοντας το κατεστημένο του central repo με το distributed repo.
Κάθε φορά που γίνεται συζήτηση για git ή γενικά για cvs εμφανίζονται πολλοί έμπειροι χρήστες που εξηγούν γιατί το git είναι κακό, γιατί το mercurial είναι κλάσεις ανώτερο κλπ.

Μπορείς να μου περιγράψεις τα "winning features" του systemd για σένα ?

Το "υπάρχει περισσότερη συμβατότητα" δεν το θεωρώ επιχείρημα γιατί αν ήταν έτσι έπρεπε να έχουμε όλοι από χρόνια RPM και να έχουν εκλείψουν όλα τα άλλα formats.

[megahead13]

Μπορείς να μου περιγράψεις τα "winning features" του systemd για σένα ?

Πχ έχει ενσωματωμένο dhcp server και client

http://www.phoronix.com/scan.php?pag...tem&px=MTY1Mjc

[KernelPanic]

Πχ έχει ενσωματωμένο dhcp server και client

http://www.phoronix.com/scan.php?pag...tem&px=MTY1Mjc

Καθώς ntp και http interface... Φήμες λένε οτι η νέα version θα εχει και το τελικό χρήστη ενσωματομενο

[megahead13]

[GoofyX]

Σωθήκαμε... Θα παίρνει IP σε λιγότερο από 50ms, αντί των 500ms...

Ο παραλληλισμός του systemd με το git μάλλον άτυχος. Το git δημιουργήθηκε από κάποιον ικανό developer και κάνει ένα συγκεκριμένο πράμα. Source versionsing. Το systemd δημιουργήθηκε για να αντικαταστήσει ένα πράμα και να κάνει άλλα 25 επιπλέον.

[mrsaccess]

Μπορείς να μου περιγράψεις τα "winning features" του systemd για σένα ?

Το "υπάρχει περισσότερη συμβατότητα" δεν το θεωρώ επιχείρημα γιατί αν ήταν έτσι έπρεπε να έχουμε όλοι από χρόνια RPM και να έχουν εκλείψουν όλα τα άλλα formats.

Καταρχήν δεν υποστηρίζω το systemd, υποστηρίζω όμως (α) τις επιλογές των developer που εμπιστεύομαι (β) την ανάγκη για αλλαγή και πρόοδο. Χρησιμοποιώ και υποστηρίζω την μοναδική μεγάλη διανομή που αντιστέκεται έμπρακτα στην πλήρη καθιέρωση του systemd και έχει κάνει fork το udev· το Gentoo. Είναι ωστόσο η ίδια διανομή που εδώ και χρόνια έχει εγκαταλείψει το sys-v-init για το δικό της OpenRC.

Επίσης έχω δει διάφορες τεχνολογίες που αρχικά δεν μου άρεσαν (πχ networkmanager, pulseaudio) αλλά πλέον είναι αναπόσπαστο κομμάτι του Linux desktop, ξεπερνούν σε δυνατότητες τις αντίστοιχες άλλων λειτουργικών και φυσικά δεν φαντάζομαι το desktop/workstation χωρίς αυτές.

Πάμε στα winning features από τα ελάχιστα που έχω δει. Η συμβατότητα είναι το πιο σημαντικό όσο και να μην σου αρέσει. Σήμερα δουλεύω σε CentOS, αύριο θα κληθώ να δουλέψω σε Debian, μεθαύριο σε CoreOS —το αύριο και το μεθαύριο είναι σχεδόν κυριολεκτικά, δεν εννοώ του χρόνου. Το πιο ενοχλητικό όταν αλλάζεις διανομές είναι τα init scripts της καθεμιάς, τα διαφορετικά directories, τα διαφορετικά εργαλεία. Τουλάχιστον με το systemd είναι κοινά. Υπάρχει ένας κοινός τρόπος να πεις «θέλω αυτό να ξεκινήσει πριν από αυτό».

Ένα άλλο όπως είπα είναι τα logs. Μπορείς να δεις logs ανά service με καθαρά, τυποποιημένα timestamp και σαφή διαχωρισμό ανάμεσα στα reboot του μηχανήματος κλπ. Για να στήσεις το ίδιο με syslog θα χάσεις πολύ χρόνο από την ζωή σου. Φυσικά τα σημαντικά σου log μπορείς να τα προωθήσεις και σε ένα άλλο σύστημα (πχ syslog-ng).
Επειδή όμως πρέπει να σκεφτόμαστε και λίγο, είναι πράγματι συχνό φαινόμενο τα corrupted logs στο systemd; Αμφιβάλλω. Το corruption από που έρχεται; Από το systemd; Τότε ναι, είναι τεράστιο bug. Μήπως έρχεται από το filesystem; Αν ναι, είναι πραγματικά πρόβλημα του systemd ή του administrator που θεωρεί φυσιολογικά τα corruptions στο filesystem;

Χλευάζουν μερικοί γιατί έχει δική του υλοποίηση dhcp. Πόσες φορές στη ζωή σου έχεις ασχοληθεί με τον dhcp client του συστήματός σου που ενοχλείσαι τώρα; Εγώ έχω ασχοληθεί μόνο όταν είχε πρόβλημα —πχ σε μια VM hosting εταιρεία δεν δούλευε κανένας dhcp cllient στο VM μου για το IPv6 και αναγκάστηκα να το βάλω static. Το ίδιο θα γίνει και με το dhcp του systemd, μόνο στα προβλήματα θα το δούμε.

Ο τρόπος που λειτουργεί το syslog, ο cron, το ntp κλπ δεν έχει αλλάξει εδώ και πάρα πολλά χρόνια. Οι Η/Υ, το λογισμικό, τα λειτουργικά συστήματα είναι μια επιστήμη ζωντανή, δεν υπάρχει λόγος για στασιμότητα. Απλώς μερικοί είναι άνετοι με την πρόοδο που δεν μπορούν να αντιληφθούν (πχ στο κώδικα του kernel) αλλά αντιδρούν στην πρόοδο αυτών που ξέρουν.

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

[mobinmob]

Χρησιμοποιώ και υποστηρίζω την μοναδική μεγάλη διανομή που αντιστέκεται έμπρακτα στην πλήρη καθιέρωση του systemd και έχει κάνει fork το udev· το Gentoo. Είναι ωστόσο η ίδια διανομή που εδώ και χρόνια έχει εγκαταλείψει το sys-v-init για το δικό της OpenRC.

Λυπάμαι, αλλά εδώ κάνεις λάθος και σε σημείο μάλιστα παράξενο για έναν χρήστη του gentoo... Το OpenRC δεν εγκαταλείπει το sysvinit, δεν τρέχει σαν pid 1. Είναι συλλογή προγραμμάτων και scipts που τρέχουν πάνω στο/από το sysvinit και προσθέτουν δυνατότητες - ξέρω ότι έχει γίνει προσπάθεια να τρέχει πάνω στο busybox init και με τα busybox applets για embedded μηχανήματα. Προσωπικά, αν το systemd έτρεχε έτσι θα είχα πολύ λιγότερα προβλήματα μαζί του. Έτσι τρέχουν σχεδόν όλες οι supervision suites (daemontools, runit, perp, s6...).

Ένα άλλο όπως είπα είναι τα logs. Μπορείς να δεις logs ανά service με καθαρά, τυποποιημένα timestamp και σαφή διαχωρισμό ανάμεσα στα reboot του μηχανήματος κλπ. Για να στήσεις το ίδιο με syslog θα χάσεις πολύ χρόνο από την ζωή σου. Φυσικά τα σημαντικά σου log μπορείς να τα προωθήσεις και σε ένα άλλο σύστημα (πχ syslog-ng).
Επειδή όμως πρέπει να σκεφτόμαστε και λίγο, είναι πράγματι συχνό φαινόμενο τα corrupted logs στο systemd; Αμφιβάλλω. Το corruption από που έρχεται; Από το systemd; Τότε ναι, είναι τεράστιο bug. Μήπως έρχεται από το filesystem; Αν ναι, είναι πραγματικά πρόβλημα του systemd ή του administrator που θεωρεί φυσιολογικά τα corruptions στο filesystem;

Μπορείς να ψάξεις τόσο τον bugtracker του systemd, όσο και τα fora των διανομών που το υιοθέτησαν σχετικά γρήγορα. Παλιότερα ήταν πολύ συχνότερο φαινόμενο και διόρθωσαν πολλά bugs για να μειώσουν τα σχετικά προβλήματα. Τώρα γιατί κατέληξαν στο "ε, καλά όταν συμβαίνει κάνουμε rotation", δεν ξέρω.
Με το journal έχουν κάνει αρκετά λάθη (τα πιο σημαντικά τα έχουν διορθώσει). Για μια περίοδο η προκαθορισμένη συμπεριφορά του journald ήταν να σώζει στα αρχεία του journal και τα crash dumps με συνέπεια να γίνονται... τεράστια, άλλες φορές απασχολούσε τον επεξεργαστή υπερβολικά κ.λπ. Από πλευράς καθαρά θεωρητικής είναι άψογο : έχεις ένα σημείο που μπορείς να δεις ακριβώς τι έχει συμβεί έχοντας όλες της πληροφορίες. Από πρακτικής πλευράς, όχι και τόσο
Έχω την αίσθηση ότι βιάστηκαν να το ενσωματώσουν και φοβάμαι ότι δεν είναι το μόνο.
Α, και για logs ανά service με ακριβέστατα timestamps, ρίξε μια ματιά στα link παραπάνω...

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

Γιατί δεν είναι -μόνο- τεχνική απόφαση η υιοθέτησή του

[imitheos]

Καταρχήν δεν υποστηρίζω το systemd, υποστηρίζω όμως (α) τις επιλογές των developer που εμπιστεύομαι (β) την ανάγκη για αλλαγή και πρόοδο. Χρησιμοποιώ και υποστηρίζω την μοναδική μεγάλη διανομή που αντιστέκεται έμπρακτα στην πλήρη καθιέρωση του systemd και έχει κάνει fork το udev· το Gentoo. Είναι ωστόσο η ίδια διανομή που εδώ και χρόνια έχει εγκαταλείψει το sys-v-init για το δικό της OpenRC.

Δεν είμαι ενάντια στην αλλαγή. Είμαι ενάντια στην αλλαγή που γίνεται απλά για την αλλαγή και που σε αναγκάζει να την ασπαστείς.

Παραδείγματα:
1) Ένας logger που χρησιμοποιείται από πολύ κόσμο είναι ο sysklogd. Του λείπουν πολλά features για αυτό έχουν βγει εναλλακτικές όπως syslog-ng, rsyslog, κτλ τα οποία έχουν πχ πιο εύκολο και αξιόπιστο remote logging και διάφορα άλλα features. Εφόσον χρησιμοποιείς gentoo γνωρίζεις καλύτερα από εμένα ότι σου επιτρέπει να εγκαταστήσεις οποιαδήποτε λύση logger θέλεις.
2) Mailer. Κλασική επιλογή το sendmail αλλά λόγω πολλών security bugs που είχε στο παρελθόν και δύσκολου configuration βγήκανε ένα κάρο εναλλακτικές όπως postfix, κτλ. Πάλι εγκαθιστάς όποια θέλεις και το σύστημά σου δουλεύει τζάμι.

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

Επίσης έχω δει διάφορες τεχνολογίες που αρχικά δεν μου άρεσαν (πχ networkmanager, pulseaudio) αλλά πλέον είναι αναπόσπαστο κομμάτι του Linux desktop, ξεπερνούν σε δυνατότητες τις αντίστοιχες άλλων λειτουργικών και φυσικά δεν φαντάζομαι το desktop/workstation χωρίς αυτές.

Δεν είναι το μεγαλύτερο χαρακτηριστικό γνώρισμα των Linux, *BSD, κτλ αλλά ένα από τα γνωρίσματά τους είναι η ελευθερία επιλογής που δίνουν στον χρήστη. Εγώ αυτή τη στιγμή δεν χρησιμοποιώ ούτε networkmanager ούτε pulseaudio. Τα μηχανήματά μου έχουν στατική ip και δεν αλλάζουν συχνά δίκτυο και δεν με ενδιαφέρει να στέλνω ήχο remotely ή ποιος ξέρει τι. Το mixing της alsa και τα άλλα features της μου αρκούν. Για να μην παρεξηγηθώ χρησιμοποιώ τον εαυτό μου απλά ως παράδειγμα. Υπάρχουν χρήστες που δεν χρειάζονται την Χ υποδομή όσο τέλεια και να είναι. Όσο χρήσιμο και να είναι το NetworkManager, μπορείς να μην το τρέξεις αν δεν θέλεις.

Πάμε στα winning features από τα ελάχιστα που έχω δει. Η συμβατότητα είναι το πιο σημαντικό όσο και να μην σου αρέσει. Σήμερα δουλεύω σε CentOS, αύριο θα κληθώ να δουλέψω σε Debian, μεθαύριο σε CoreOS —το αύριο και το μεθαύριο είναι σχεδόν κυριολεκτικά, δεν εννοώ του χρόνου. Το πιο ενοχλητικό όταν αλλάζεις διανομές είναι τα init scripts της καθεμιάς, τα διαφορετικά directories, τα διαφορετικά εργαλεία. Τουλάχιστον με το systemd είναι κοινά. Υπάρχει ένας κοινός τρόπος να πεις «θέλω αυτό να ξεκινήσει πριν από αυτό».

Συνεχίζω να μην το θεωρώ πλεονέκτημα γιατί το init system είναι ένα σημείο διαφοροποίησης. Πάλι θα χρειαστείς να μεταβείς από rpm σε deb ή κάποια άλλη διαφορά.

Ένα άλλο όπως είπα είναι τα logs. Μπορείς να δεις logs ανά service με καθαρά, τυποποιημένα timestamp και σαφή διαχωρισμό ανάμεσα στα reboot του μηχανήματος κλπ. Για να στήσεις το ίδιο με syslog θα χάσεις πολύ χρόνο από την ζωή σου. Φυσικά τα σημαντικά σου log μπορείς να τα προωθήσεις και σε ένα άλλο σύστημα (πχ syslog-ng).

Υπάρχουν και τώρα λύσεις για αυτό αλλά είναι υποτυπώδεις με parsing των text logs και αμφίβολα αποτελέσματα οπότε αυτό που λες είναι όντως πλεονέκτημα. Υποκειμενική προσωπική μου άποψη είναι ότι χάνει όμως την αξία του λόγω του binary format που χρειάζεται το systemd binary (ή κάποιο component του) για να διαβαστεί το log. Προτιμώ την ευελιξία του να μπορώ να κάνω grep για ό,τι θέλω και να μπορώ να διαβάσω το log οπουδήποτε. Ας πούμε ότι έχω ένα δεύτερο μηχάνημα με FreeBSD και συνδέω εκεί ένα δίσκο για να δω κάτι. Μπορώ να διαβάσω κάπως το log χωρίς υποστήριξη για systemd ?

Επειδή όμως πρέπει να σκεφτόμαστε και λίγο, είναι πράγματι συχνό φαινόμενο τα corrupted logs στο systemd; Αμφιβάλλω. Το corruption από που έρχεται; Από το systemd; Τότε ναι, είναι τεράστιο bug. Μήπως έρχεται από το filesystem; Αν ναι, είναι πραγματικά πρόβλημα του systemd ή του administrator που θεωρεί φυσιολογικά τα corruptions στο filesystem;

Τα text logs (συνήθως) ανοίγονται για append και προσθέτονται γραμμές και μάλιστα σε πολλούς loggers υπάρχει επιλογή με την οποία (σε βάρος των επιδόσεων) μπορείς να κάνεις sync μετά από κάθε γραμμή οπότε αν πέσει το ρεύμα θα χάσεις μόνο τις τελευταίες γραμμές χωρίς να γίνει corrupt όλο το log.

Χλευάζουν μερικοί γιατί έχει δική του υλοποίηση dhcp. Πόσες φορές στη ζωή σου έχεις ασχοληθεί με τον dhcp client του συστήματός σου που ενοχλείσαι τώρα; Εγώ έχω ασχοληθεί μόνο όταν είχε πρόβλημα —πχ σε μια VM hosting εταιρεία δεν δούλευε κανένας dhcp cllient στο VM μου για το IPv6 και αναγκάστηκα να το βάλω static. Το ίδιο θα γίνει και με το dhcp του systemd, μόνο στα προβλήματα θα το δούμε.

Δεν το θεωρώ επιχείρημα γιατί με αυτό το σκεπτικό, πόσες φορές ασχολήθηκες με το παλιό dhcp client ? ή με τα init scripts ? Οι περισσότεροι desktop users δεν ξέρουν καν τι είναι τα init scripts. Εκκινούν το pc και φορτώνονται αυτόματα όλες οι υπηρεσίες που έχει επιλέξει η διανομή. Ο μέσος χρήστης ζήτημα να χρησιμοποιεί το 50% των δυνατοτήτων του sysvinit (πόσο μάλλον προχωρημένων script όπως το OpenRC που ανέφερες). Γιατί χρειάζονται το systemd ?

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

Επίσης κακό επιχείρημα. Γιατί προχώρησε το cd όταν το minidisc ήταν σαφώς ανώτερο ? Γιατί προχώρησε το msdos όταν το drdos και άλλα ήταν ανώτερα ? Γιατί προχώρησε το consolekit/policykit/whatever όταν, σύμφωνα με τα λόγια των systemd devs, ήταν μια μάπα και μισή (εντωμεταξύ κάποιοι από αυτούς ανέπτυξαν και εκείνο). Μπορούμε να συνεχίσουμε ως αύριο.

Συνήθως τέτοιες επιλογές γίνονται με βάση πολιτικές, marketing, κτλ και όχι λόγω ανωτερότητας του κώδικα. Παραφράζοντας το γνωστό ρητό, όταν μια χαζομάρα την αποδέχονται "οι μεγάλες binary διανομές" δεν παύει να είναι χαζομάρα.

[mobinmob]

Μπορείς να μου περιγράψεις τα "winning features" του systemd για σένα ?

Το "υπάρχει περισσότερη συμβατότητα" δεν το θεωρώ επιχείρημα γιατί αν ήταν έτσι έπρεπε να έχουμε όλοι από χρόνια RPM και να έχουν εκλείψουν όλα τα άλλα formats.

Αν και η ερώτηση δεν απευθύνεται σε μένα:
Το μεγάλο πλεονέκτημα του systemd για μένα είναι ο έλεγχος που μπορείς να έχεις πάνω στους daemons που τρέχεις με αυτό. Μπορείς να ρυθμίσεις το περιβάλλον στο οποίο εκτελούνται με μεγάλη λεπτομέρεια, να παρακολουθήσεις αν εκτελούνται, να τους επανεκκινήσεις "καθαρά" αν αυτοί κρασάρουν. Μάλιστα, οι daemons δεν μπορούν να.. ξεφύγουν από το έλεγχο, ακόμα κι αν κάνουν double fork, ενώ μπορεί ο έλεγχος να είναι και σε ομάδες proccesses (π.χ. στους workers του nginx). Σε αυτόν τον τομέα παίρνει τα καλύτερα χαρακτηριστικά από τις supervision suites και με την βοήθεια των cgroups και όχι μόνο τα βελτιώνει σημαντικά.
Το γεγονός ότι τα κάνει αυτά διαβάζοντας ini files τα οποία μπορούν να διαβαστούν και να γραφτούν εύκολα από οποιαδήποτε γλώσσα προγραμματισμού το καθιστά επίσης ελκυστικό.
Αν ο journald ήταν απλά ένα φίλτρο που ανακατεύθυνε τα logs στο syslog, θα το χειροκροτούσα. Το systemd κάνει πραγματικά αξιόπιστο logging: κολλά έναν μικροσκοπικό logger σε κάθε proccess, διαβάζει stdout και stderr και τα συλλέγει γνωρίζοντας την προέλευσή τους. BTW, το ίδιο κάνουν και τα daemontools και οι απόγονοί τους, αλλά δεν σώζουν σε binary και μάλιστα με ηλίθιες δικαιολογίες...
Δεν διαφωνώ με αυτές τις δυνατότητες. Διαφωνώ με τον τρόπο υλοποίησης και με το τι έχει μαζέψει από εκεί και πέρα. Πιστεύω ότι θα μπορούσε να κάνει την δουλειά του χωρίς να είναι όλη η λογική αυτή στο pid 1...

[imitheos]

Αν και η ερώτηση δεν απευθύνεται σε μένα:
Το μεγάλο πλεονέκτημα του systemd για μένα είναι ο έλεγχος που μπορείς να έχεις πάνω στους daemons που τρέχεις με αυτό. Μπορείς να ρυθμίσεις το περιβάλλον στο οποίο εκτελούνται με μεγάλη λεπτομέρεια, να παρακολουθήσεις αν εκτελούνται, να τους επανεκκινήσεις "καθαρά" αν αυτοί κρασάρουν. Μάλιστα, οι daemons δεν μπορούν να.. ξεφύγουν από το έλεγχο, ακόμα κι αν κάνουν double fork, ενώ μπορεί ο έλεγχος να είναι και σε ομάδες proccesses (π.χ. στους workers του nginx). Σε αυτόν τον τομέα παίρνει τα καλύτερα χαρακτηριστικά από τις supervision suites και με την βοήθεια των cgroups και όχι μόνο τα βελτιώνει σημαντικά.

Πολύ χρήσιμο όντως. Δεν θα μπορούσε όμως να γίνει με κάποια υποδομή του posix ? Ή αν το posix είναι ανεπαρκές (που είναι σε πολλά θέματα) με κάποιο νέο τρόπο αλλά σε συνεργασία με τα *BSD αντί για την αλλαζονική τακτική που ακολουθείται ?

[mrsaccess]

@mobinmob
Το OpenRC είναι ένα σύστημα init, οπότε αντιμετωπίζει το init σαν ένα απλό εκτελέσιμο που θα μπορούσε να αντικατασταθεί.
Όσο αφορά τα υπόλοιπα, δίνεις μια καλή και τεκμηριωμένη άποψη και αναγνωρίζεις πως το systemd δεν έχει μόνο αρνητικά και προφανώς δεν μπορώ να πω κάτι γιατί αυτό λέω κι εγώ από την αρχή.

@imitheos
Το πρόβλημα εξακολουθεί να είναι πως την επιλογή δεν στην αφαίρεσαν οι developers του systemd αλλά οι developers των διανομών. Είναι οι ίδιοι άνθρωποι που ανέκαθεν σου επέβαλλαν πράγματα. Μπορούσες φυσικά να έχεις ένα setup που δεν υποστηρίζεται επίσημα και με το systemd αυτό έγινε δυσκολότερο αλλά δεν άλλαξε η ουσία του πράγματος.

Όσο αφορά το package management σε διαφορετικές διανομές, μου είναι συνήθως πολύ μικρότερο πρόβλημα από το init system και το custom setup στο /etc.

@mobinmob και @imitheos
Δεν μπορώ να δεχτώ τις κατηγορίες για marketing κλπ. Το Arch είναι μια ανεξάρτητη διανομή με ελάχιστη εμπορική χρήση, δεν μπορεί να το πιέσει κανείς να γυρίσει σε systemd. Το Debian είναι ο ορισμός της free software διανομής και ανεξάρτητο από vendors. Δεν γίνεται αυτοί οι άνθρωποι να επηρεαστούν από τον οποιοδήποτε. Μην ξεχνάμε μάλιστα πως το Ubuntu γύρισε σε systemd μόνο όταν το υιοθέτησε το Debian (επομένως δεν υπήρχε πίεση από εκεί).
Πραγματικά θα ήταν απίστευτα ανησυχητικό αν κάποιος είχε την δύναμη να επέμβει έτσι στο οικοσύστημα του Linux.

[mobinmob]

Πολύ χρήσιμο όντως. Δεν θα μπορούσε όμως να γίνει με κάποια υποδομή του posix ? Ή αν το posix είναι ανεπαρκές (που είναι σε πολλά θέματα) με κάποιο νέο τρόπο αλλά σε συνεργασία με τα *BSD αντί για την αλλαζονική τακτική που ακολουθείται ?

Τα supervisions suites που κατάγονται από τα daemontools του djb δουλεύουν καλά σε όλα τα posix compatible λειτουργικά, αλλά με την προϋπόθεση να να μην πάνε οι daemons στο backgound/να μην κάνουν double fork γιατί έτσι δεν μπορείς να κάνεις αξιόπιστο tracking. Αυτός είναι και ένας από τους λόγους που αρκετοί daemons έχουν flag για να μην κάνουν... daemonise :P
Τα control groups έχουν την δυνατότητα να βάλλουν "ετικέτες" σε group από proccesses και να "δεσμεύσουν" μια proccess ώστε να μπορείς να της στείλεις signals ακόμα κι αν αυτή κάνει double fork και αλλάξει pid. Έτσι, ξεπερνάς τις δυσκολίες των supervision suites (οι οποίες μπορούν να επεκταθούν φαντάζομαι...) και εκεί που χρησιμοποιούσες rlimits για να ορίσεις το περιβάλλον που θα τρέξει ένας daemon μπορείς να κάνεις το ίδιο για όλες τις proccesses που είναι "παιδιά" του.
Δεν νομίζω πως υπάρχει κάτι αντίστοιχο σε άλλα unix-like, σίγουρα θα μπορούσε να βρεθεί μια κοινή λύση, αλλά...

- - - Updated - - -

@mobinmob
Το OpenRC είναι ένα σύστημα init, οπότε αντιμετωπίζει το init σαν ένα απλό εκτελέσιμο που θα μπορούσε να αντικατασταθεί.

Τίποτα από το OpenRC δεν τρέχει σαν pid 1. Αυτό για μένα είναι τεράστια διαφορά
Για την εξάπλωση/υιοθέτηση του systemd: Δεν μου αρέσουν οι... θεωρίες συνωμοσίας, αλλά όταν δεν είναι καθαρά τεχνικό ένα ζήτημα, είναι λάθος να μην λαμβάνουμε υπ' όψιν μας μη τεχνικούς παράγοντες. Μια τέτοια αλλαγή σε μια διανομή είναι και θέμα "πολιτικής".
Έτυχε να παρακολουθήσω την αλλαγή στο arch και στο debian και είναι αρκετά διαφορετική ιστορία το πως και το γιατί έγινε αυτή η κίνηση από τις 2...

[megahead13]

Τίποτα από το OpenRC δεν τρέχει σαν pid 1. Αυτό για μένα είναι τεράστια διαφορά
Για την εξάπλωση/υιοθέτηση του systemd: Δεν μου αρέσουν οι... θεωρίες συνωμοσίας, αλλά όταν δεν είναι καθαρά τεχνικό ένα ζήτημα, είναι λάθος να μην λαμβάνουμε υπ' όψιν μας μη τεχνικούς παράγοντες. Μια τέτοια αλλαγή σε μια διανομή είναι και θέμα "πολιτικής".
Έτυχε να παρακολουθήσω την αλλαγή στο arch και στο debian και είναι αρκετά διαφορετική ιστορία το πως και το γιατί έγινε αυτή η κίνηση από τις 2...

Μπορείς να αναφέρεις συνοπτικά;;