Boycott systemd

[ESP1982]

Έλα systemd, πάμε δυνατά να τα σπάσουμε όλα.

[ifaigios]

Αν δηλαδή η διανομή δεν μπει στον κόπο να το αλλάξει (ίσως να το αλλάζουν όλες οι διανομές που δίνουν systemd, δεν το έχω ψάξει), τότε η μεταβλητή sysrq θα έχει τιμή 16 δηλαδή θα παίζει μόνο το sync και έτσι δεν μπορείς να τρέξεις reisub αν κολλήσει το σύστημα ή ό,τι άλλο θέλεις να τρέξεις.

Σιγά ρε παιδιά, ένα sane (και safe) default όρισαν οι άνθρωποι, ακριβώς για αυτούς που δε θα μπουν στον κόπο να το αλλάξουν. Το Arch για παράδειγμα έχει απενεργοποιημένο το sysrq για λόγους ασφαλείας πολύ πριν το systemd (τουλάχιστον από το 2011 που το τρέχω, το disabled ήταν πάντα το default). Από εκεί και πέρα η κάθε διανομή και ο κάθε χρήστης μπορεί να κάνει ό,τι νομίζει.

[mrsaccess]

Σιγά ρε παιδιά, ένα sane (και safe) default όρισαν οι άνθρωποι, ακριβώς για αυτούς που δε θα μπουν στον κόπο να το αλλάξουν. Το Arch για παράδειγμα έχει απενεργοποιημένο το sysrq για λόγους ασφαλείας πολύ πριν το systemd (τουλάχιστον από το 2011 που το τρέχω, το disabled ήταν πάντα το default). Από εκεί και πέρα η κάθε διανομή και ο κάθε χρήστης μπορεί να κάνει ό,τι νομίζει.

Μπορεί να το είχε απενεργοποιημένο αλλά μπορούσες να το ενεργοποιήσεις στο boot time και αυτό το έσπασαν. Μπορούσες να το ενεργοποιήσεις στο sysctl και αυτό το έσπασαν.
Αφού τσαντίστηκες, έβρισες κλπ, βρήκες τρόπο να το ρυθμίσεις στο systemd και μάντεψε τι, μετά από λίγο το έσπασαν κι αυτό και έπρεπε να ξαναψάχνεις. ΓΙΑΤΙ ΕΤΣΙ ΓΡΑΦΕΤΑΙ ΤΟ ΚΑΛΟ ΛΟΓΙΣΜΙΚΟ, ΝΑ ΤΑΛΑΙΠΩΡΕΙ ΤΟ ΧΡΗΣΤΗ.

Για κάτι τέτοια θυμάμαι κοροϊδεύαμε τα windows...

[ifaigios]

Μπορεί να το είχε απενεργοποιημένο αλλά μπορούσες να το ενεργοποιήσεις στο boot time και αυτό το έσπασαν. Μπορούσες να το ενεργοποιήσεις στο sysctl και αυτό το έσπασαν.
Αφού τσαντίστηκες, έβρισες κλπ, βρήκες τρόπο να το ρυθμίσεις στο systemd και μάντεψε τι, μετά από λίγο το έσπασαν κι αυτό και έπρεπε να ξαναψάχνεις. ΓΙΑΤΙ ΕΤΣΙ ΓΡΑΦΕΤΑΙ ΤΟ ΚΑΛΟ ΛΟΓΙΣΜΙΚΟ, ΝΑ ΤΑΛΑΙΠΩΡΕΙ ΤΟ ΧΡΗΣΤΗ.

Για κάτι τέτοια θυμάμαι κοροϊδεύαμε τα windows...

Ε; Μια χαρά δουλεύει ακόμα το:

sysctl kernel.sysrq=1

όπως και το:

echo "kernel.sysrq=1" >> /etc/sysctl.d/99-sysctl.conf

αν το θες μόνιμα ενεργό. Αν το έχεις κάνει αυτό δεν υπάρχει περίπτωση να σπάσει κάτι καθώς τα αρχεία στο /etc/sysctl.d/ έχουν προτεραιότητα σε σχέση με αυτά στο /usr/lib/sysctl.d/ (εκεί που βάζει αρχεία το systemd). Η μόνη αλλαγή που έγινε πριν χρόνια στο Arch είναι ότι σταμάτησε να φορτώνεται το deprecated αρχείο /etc/sysctl.conf. Και φυσικά όταν έγινε αυτό βγήκε η αντίστοιχη ανακοίνωση για να αποφευχθούν σπασίματα.

[megahead13]

Να δεχτώ τα επιχειρήματα περί sysrq. Γιατί όμως ανακατεύονται με πράγματα με τα οποία καμία σχέση δεν (πρέπει να) έχει ένα init system;; Βλέπε παραπάνω link για το DNS, παλιότερα περί ενσωματωμένου DHCP server και client, κτλ. Για να μην (ξανα)πούμε περί PID 1, binary logs που μπορεί να γίνουν corrupted, κτλ συν η όλη συμπεριφορά των systemd devs που δε φτιάχνουν bugs, αγνοούν επιδεικτικά τους devs από άλλα σημαντικά projects του Linux ecosystem, κτλ

[imitheos]

Σιγά ρε παιδιά, ένα sane (και safe) default όρισαν οι άνθρωποι, ακριβώς για αυτούς που δε θα μπουν στον κόπο να το αλλάξουν. Το Arch για παράδειγμα έχει απενεργοποιημένο το sysrq για λόγους ασφαλείας πολύ πριν το systemd (τουλάχιστον από το 2011 που το τρέχω, το disabled ήταν πάντα το default). Από εκεί και πέρα η κάθε διανομή και ο κάθε χρήστης μπορεί να κάνει ό,τι νομίζει.

Μερικές φορές υπάρχει θέμα με τον 3d οδηγό της κάρτας γραφικών (ή με το btrfs ή με ποιος ξέρει τι) και κολλάει το σύστημα. Αυτό μπορεί να γίνει ακόμη και με "stable" εκδόσεις προγραμμάτων και ακόμη και σε ένα desktop σύστημα που ο χρήστης δεν πειράζει τίποτα. Όσο σταθερό και να είναι (ή όχι) το linux, μπορεί να κολλήσει. Σε αυτές τις περιπτώσεις είναι πολύ χρήσιμο το sysrq. Ένα απλό sync και umount μέσω sysrq μπορεί να είναι η διαφορά μεταξύ λίγων χαμένων αρχείων και πάρα πολλών χαμένων αρχείων (ή ακόμη και όλου του fs στην περίπτωση του btrfs πριν 1-2 χρόνια).

Όπως και να έχει το θέμα, χρήσιμο ή όχι, το sysrq είναι κάτι που η πλειοψηφία των χρηστών (από οδηγούς που έχει διαβάσει) περιμένει ότι μπορεί να το χρησιμοποιήσει σε περίπτωση ανάγκης.

Το "safe" που λένε πολλοί δεν ισχύει σαν επιχείρημα γιατί η απενεργοποίηση του sysrq αποτρέπει μόνο κάποιον που έχει φυσική πρόσβαση από το να κάνει ζημιά. Όπως είναι γνωστό (και αδιαμφισβήτητο), όταν κάποιος έχει φυσική πρόσβαση στο μηχάνημά σου, all bets are off. Μπορεί να σου κάνει ό,τι θέλει και δεν θα τον σταματήσει η απενεργοποίηση του sysrq.

Με λίγα λόγια, δεν ήταν καλή αυτή η επιλογή του arch να το κλείσει γιατί δεν προσφέρει τίποτα στον χρήστη και _ίσως_ αφαιρεί δυνατότητες από τον χρήστη. Εκτός αυτού, όπως είπε ο megahead13, δεν έχει καμμία δουλειά ο systemd να ανακατεύεται με τέτοιες υποδομές.

Ε; Μια χαρά δουλεύει ακόμα το:

sysctl kernel.sysrq=1

όπως και το:

echo "kernel.sysrq=1" >> /etc/sysctl.d/99-sysctl.conf

αν το θες μόνιμα ενεργό.

Φυσικά μπορείς να το αλλάξεις. Ένας χρήστης όμως που δεν γνωρίζει, θα αφήσει την default ρύθμιση για αυτό αυτή πρέπει να είναι "sane" όπως είπες. Αν με πάρει ένας φίλος που κόλλησε το σύστημά του την ώρα που έγραφε μια εργασία, και έχει sane default ρυθμίσεις, μπορώ να του πω πάτα alt-printscreen-τάδε,-δείνα και έτσι να χάσει όσο το δυνατόν λιγότερα δεδομένα. Εκείνη την στιγμή που θα το χρειαστεί, δεν θα μπορώ να το ενεργοποιήσω.

Γιατί όμως ανακατεύονται με πράγματα με τα οποία καμία σχέση δεν (πρέπει να) έχει ένα init system;;

+1

Έχουν το ίδιο πρόβλημα που κατηγορούσαμε τόσα χρόνια την Microsoft. Το Not Invented Here σύνδρομο. Ενώ υπάρχουν καλές λύσεις άλλων, αυτοί θέλουν να τα υλοποιήσουν όλα οι ίδιοι με τον τρόπο τους γιατί ο τρόπος των άλλων δεν είναι καλός. Μόνο ο δικός τους τρόπος είναι καλός.

[KernelPanic]

Έχουν το ίδιο πρόβλημα που κατηγορούσαμε τόσα χρόνια την Microsoft. Το Not Invented Here σύνδρομο. Ενώ υπάρχουν καλές λύσεις άλλων, αυτοί θέλουν να τα υλοποιήσουν όλα οι ίδιοι με τον τρόπο τους γιατί ο τρόπος των άλλων δεν είναι καλός. Μόνο ο δικός τους τρόπος είναι καλός.

+ όσα θες


(Ρε λές οι devs του systemd να είναι βαλτοι απο τους μικρομαλακους )

[megahead13]

+1

Έχουν το ίδιο πρόβλημα που κατηγορούσαμε τόσα χρόνια την Microsoft. Το Not Invented Here σύνδρομο. Ενώ υπάρχουν καλές λύσεις άλλων, αυτοί θέλουν να τα υλοποιήσουν όλα οι ίδιοι με τον τρόπο τους γιατί ο τρόπος των άλλων δεν είναι καλός. Μόνο ο δικός τους τρόπος είναι καλός.

Να φτίαξουν τότε δίκό τους DHCP server, DNS server, NTP server, κοκ ΕΚΤΟΣ systemd και να μη μας ζαλίζουν A ρε Linus κάτσε φτιάξε ένα init system της προκοπής, όπως έκανες και με το git, να μην καθόμαστε ν' ασχολούμαστε με τον κομπλεξικό Poettering και το παρεάκι του.

[mobinmob]

Υπάρχουν εξαιρετικά εναλλακτικά init/service managers - το πρόβλημα δεν είναι πια εκεί. Το πρόβλημα είναι ποιός θα τα υιοθετήσει -που σημαίνει ότι πέρα από την προσπάθεια της αλλαγής init, θα κυνηγά τα "πλοκάμια" του systemd που είναι εξάρτησεις σημαντικών προγραμμάτων. Δες τι γίνεται με το logind και το gnome. Το guix χρειάστηκε να κάνει fork το logind (elogind) για να μπορεί να έχει πλήρες gnome χωρίς το systemd. Οι υπόλοιπες διανομές που δεν επέλεξαν να πάνε σε systemd είτε α) τρέχουν το systemd-logind με το systemd-shim (που δεν αναπτύσσεται πλέον), είτε β) χρησιμοποιούν consolekit2, το οποίο είναι καλό και χρυσό αλλά δεν προσφέρει όλες τις δυνατότητες του logind που χρησιμοποιούνται από άλλα προγράμματα. Προς το παρόν το μόνο άμεσα ορατό είναι η αδυναμία να κάνεις halt/reboot από τον σχετικό διάλογο του gnome και το όχι και τόσο ορατό είναι η δυνατότητα να τρέχεις τον X χωρις να είναι suid root.

- - - Updated - - -

Ευτυχώς το kdbus δεν προχώρησε όπως σχεδιαζόταν -προφανώς γιατί στον kernel είναι οπισθοδρομικοί και δεν καταλαβαίνουν το ταλέντο και το όραμα κάποιων...

[karakou]

Υπάρχουν εξαιρετικά εναλλακτικά init/service managers - το πρόβλημα δεν είναι πια εκεί. Το πρόβλημα είναι ποιός θα τα υιοθετήσει -που σημαίνει ότι πέρα από την προσπάθεια της αλλαγής init, θα κυνηγά τα "πλοκάμια" του systemd που είναι εξάρτησεις σημαντικών προγραμμάτων. Δες τι γίνεται με το logind και το gnome. Το guix χρειάστηκε να κάνει fork το logind (elogind) για να μπορεί να έχει πλήρες gnome χωρίς το systemd. Οι υπόλοιπες διανομές που δεν επέλεξαν να πάνε σε systemd είτε α) τρέχουν το systemd-logind με το systemd-shim (που δεν αναπτύσσεται πλέον), είτε β) χρησιμοποιούν consolekit2, το οποίο είναι καλό και χρυσό αλλά δεν προσφέρει όλες τις δυνατότητες του logind που χρησιμοποιούνται από άλλα προγράμματα. Προς το παρόν το μόνο άμεσα ορατό είναι η αδυναμία να κάνεις halt/reboot από τον σχετικό διάλογο του gnome και το όχι και τόσο ορατό είναι η δυνατότητα να τρέχεις τον X χωρις να είναι suid root.

- - - Updated - - -

Ευτυχώς το kdbus δεν προχώρησε όπως σχεδιαζόταν -προφανώς γιατί στον kernel είναι οπισθοδρομικοί και δεν καταλαβαίνουν το ταλέντο και το όραμα κάποιων...

Να μας πει ο Λινους τι διανομη χρησιμοποιει στα pc/router του, αν αυτη εχει systemd και τελος τη γνωμη του για το systemd και τις εξελιξεις. Θα ειχε ενδιαφερον η αποψη καποιου που σιγουρα ξερει καλυτερα το λινουξ απο εμας. Απο τη στιγμη που εγραψε το git εχει αποψη και για το gnu περα απο το kernel.

[mobinmob]

Επίκληση στην αυθεντία
Την τελευταία φορά που τον θυμάμαι να μιλά γι αυτό, είχε Fedora -άρα και systemd. Έχει μιλήσει λίγο για το systemd σε παλιότερη Debconf, το video υπάρχει στο thread.

[GoofyX]

Σε ένα βίντεο με Q&A session με τον Linus, είχε μείνει ουδέτερος στο θέμα, ενώ τον είχαν ρωτήσει και συγκεκριμένα γι' αυτό. Θυμάμαι που είχε πει ότι έχει καλά να δείξει το systemd (πχ. boot speed)... Μάλλον θεωρεί το θέμα (του init) είτε λυμένο, είτε ότι δεν τον απασχολεί καν (μάλλον το δεύτερο).

[mobinmob]

http://arstechnica.com/information-technology/2016/06/here-comes-flatpak-a-competitor-to-ubuntus-cross-platform-linux-apps/
While snaps can be used to package both server and desktop applications, Flatpak developers say that "Flatpak is designed to run inside a desktop session and relies on certain session services, such as a dbus session bus and a systemd --user instance. So, is not a good match for a server."

O package manager πρέπει να εξαρτάται από το init system... γιατί έτσι μας αρέσει (TM).

[mobinmob]

Καλώς μας ήρθε ο νέος και βελτιωμένος τρόπος να προσαρτούμε συστήματα αρχείων - systemd-mount.

[imitheos]

Καλώς μας ήρθε ο νέος και βελτιωμένος τρόπος να προσαρτούμε συστήματα αρχείων - systemd-mount.

The systemd-ls command is similar to the traditional ls command on Linux systems but with some differences.

Lennart describes in the documentation for systemd-ls, "instead of listing files directly and immediately, systemd-ls schedules it through the service manager job queue, so that it may pull in further dependencies (such as mounting NFS shares), and may make use of the auto-mounting logic. Listing files was never so much fun."