Boycott systemd

[ESP1982]

Το βάζω μήπως ενδιαφέρεται κάποιος που ακούει καλά και μπορεί να αντέξει τον ήχο. Προσπάθησα να το παρακολουθήσω αλλά δεν καταλάβαινα τίποτα από ό,τι ελέχθη. Άλλες δύο εκδοχές που βρήκα έχουν ακόμη χειρότερο ήχο.

Proudly provided by pulseaudio? :P

[patch]

Proudly provided by pulseaudio? :P

Έγραψες!

[GoofyX]

Ορίστε, φαγωθήκατε με τον Lennart και ανέλαβε ο Linus να διορθώσει την κατάσταση.

https://git.kernel.org/cgit/linux/ke...d3a5a21a661171

Pull x86 fixes from Ingo Molnar: "This is unusually large, partly due to the EFI fixes that prevent accidental deletion of EFI variables through efivarfs that may brick machines. These fixes are somewhat involved to maintain compatibility with existing install methods and other usage modes, while trying to turn off the 'rm -rf' bricking vector.

[mrsaccess]

Θέλεις tmux; Θέλεις screen; Όχι φιλαράκι, εδώ είναι systemd...

https://bugs.debian.org/cgi-bin/bugr...cgi?bug=825394

Οι devs πρέπει να διαγωνίζονται για το ποιος θα κάνει την μεγαλύτερη βλακεία, δεν υπάρχει άλλη εξήγηση.

[imitheos]

Θέλεις tmux; Θέλεις screen; Όχι φιλαράκι, εδώ είναι systemd...

https://bugs.debian.org/cgi-bin/bugr...cgi?bug=825394

Οι devs πρέπει να διαγωνίζονται για το ποιος θα κάνει την μεγαλύτερη βλακεία, δεν υπάρχει άλλη εξήγηση.

"Μην κολλάς σε παρωχημένες πρακτικές του παρελθόντος. Δείξε μας ένα use case που τα tmux / screen είναι χρήσιμα" (απάντηση σε ξεχωριστό /usr).

"Κανείς μας δεν τεστάρει tmux οπότε καλύτερα να μην υποστηρίζεται. Αν σε καίει να παίζει, στρώσου και γράψε patches που να υλοποιούν την συμβίωση του tmux με το systemd" (απάντηση νομίζω σε dbus δεν θυμάμαι).

[mrsaccess]

«Lennart πρόσεχε γιατί έξω ψιλοβρέχει» όπως λέει και το καλό, παλιό ανέκδοτο.

[megahead13]

"Μην κολλάς σε παρωχημένες πρακτικές του παρελθόντος. Δείξε μας ένα use case που τα tmux / screen είναι χρήσιμα" (απάντηση σε ξεχωριστό /usr).

"Κανείς μας δεν τεστάρει tmux οπότε καλύτερα να μην υποστηρίζεται. Αν σε καίει να παίζει, στρώσου και γράψε patches που να υλοποιούν την συμβίωση του tmux με το systemd" (απάντηση νομίζω σε dbus δεν θυμάμαι).

Έχεις τα links;;

[karakou]

Έχεις τα links;;

Αυτα που συζητατε στο θρεντ ειναι μια ρυθμιση ειτε μεσω /etc/systemd/logind.conf
ειτε μεσω cli
loginctl enable-linger user,
το λενε μαλιστα στο mail list σαν απαντηση.
Επιθυμητη συμπεριφορά το βρισκω οταν κανει logout ο χρηστης να τερματιζονται οι διεργασιες που αυτος ξεκινησε. Αν οχι επιθυμητη σιγουρα σωστη λογικη προγραμματιστικα αφου υπαρχει πλεον η εννοια του user/session scope.

[megahead13]

Αυτα που συζητατε στο θρεντ ειναι μια ρυθμιση ειτε μεσω /etc/systemd/logind.conf
ειτε μεσω cli
loginctl enable-linger user,
το λενε μαλιστα στο mail list σαν απαντηση.
Επιθυμητη συμπεριφορά το βρισκω οταν κανει logout ο χρηστης να τερματιζονται οι διεργασιες που αυτος ξεκινησε. Αν οχι επιθυμητη σιγουρα σωστη λογικη προγραμματιστικα αφου υπαρχει πλεον η εννοια του user/session scope.

Αντί απάντησης αυτό που λέει κάποιος στο bug report:

You are missing the point. The way people using Linux (or any UNIX for that matter) have been starting background processes for the last 30 years is to just run it with nohup <command> & or in a screen session. Now suddenly systemd wants to change this, by having you jump through extra hoops. If there was a damn good reason for this, I would maybe say, ok, migrating to the new way is worth the pain. But I really don't see what the benefit of this change is, apart from maybe cleaning up some stray gconf and pulseaudio processes from the list of processes.

Με άλλα λόγια re-inventing the wheel γιατί... έτσι. Τα ίδια με τα περισσότερα που έχουν κάνει μέχρι τώρα (binary logs, dhcp, ntp, κτλ).

[karakou]

Με αυτο το τροπο ειναι το user session σε ενα scope νοικοκυρεμενο υπο τον ελεγχο του systemd-logind με το cgroup του με ολα τα processes κατω απο ενα tree. Για ποιο λογο να υπαρχουν πιθανοτητες για zombie processes μετα το logout του χρηστη; Φαντασου τις επιπλοκες που μπορει να φερει ενα zombie process αν δεν ειναι σωστα ρυθμισμενα τα limits π.χ.

[mrsaccess]

Με αυτο το τροπο ειναι το user session σε ενα scope νοικοκυρεμενο υπο τον ελεγχο του systemd-logind με το cgroup του με ολα τα processes κατω απο ενα tree. Για ποιο λογο να υπαρχουν πιθανοτητες για zombie processes μετα το logout του χρηστη; Φαντασου τις επιπλοκες που μπορει να φερει ενα zombie process αν δεν ειναι σωστα ρυθμισμενα τα limits π.χ.

Ναι, ναι, για πες μας τις επιπλοκές από τα zombie processes του χρήστη!

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

Όπως πολύ σωστά ειπώθηκε, τα μόνα user processes που βλέπουμε εδώ και χρόνια να τρέχουν μετά το logout, είναι σε desktop συστήματα και είναι το gvfs-fuse και άλλες 1-2 χαζομάρες, τα οποία ουδέποτε προκάλεσαν πρόβλημα. Αν έχουν άλλα δεδομένα στο systemd, ας μας τα δείξουν.

[karakou]

Καταλαβαινω οτι ξερεις απο λινουξ κ προγραμματισμο οποτε σκεψου το systemd-logind σα κωδικα/δαιμονα που εχει posix capabilities inhereted απο systemd (pid 1) και αναλαμβανει να περιορισει το user.slice χωρις να γινονται escalate privileges απο τις διεργασιες χρηστη. Δεν ειναι ευκολος κωδικας security wise. Τετοια προβληματα προσπαθει να λυσει το systemd, not an easy task.
Φιλικά

[imitheos]

Με αυτο το τροπο ειναι το user session σε ενα scope νοικοκυρεμενο υπο τον ελεγχο του systemd-logind με το cgroup του με ολα τα processes κατω απο ενα tree. Για ποιο λογο να υπαρχουν πιθανοτητες για zombie processes μετα το logout του χρηστη; Φαντασου τις επιπλοκες που μπορει να φερει ενα zombie process αν δεν ειναι σωστα ρυθμισμενα τα limits π.χ.

Δεν διαφωνώ σαν ιδέα με αυτό που λες αλλά διαφωνώ με το βάρος που του δίνει πολύς κόσμος. Τι επιπλοκές θα φέρει το zombie process με κακώς ρυθμισμένα limits ?

Το πρώτο ας το πούμε server που διαχειρίστηκα ήταν ένα pii-233 με 128MB μνήμη (ή 256 δεν θυμάμαι). Δούλευαν ταυτόχρονα γύρω στους 30-40 χρήστες και φυσικά πολλές φορές έμεναν zombie processes. Το να μην σκοτώνεται ο gamin, ο gpg-agent, και ο pulseaudio όταν βγαίνει ο χρήστης σε υπολογιστές με τους σημερινούς επεξεργαστές και τα σημερινά ποσά μνήμης δεν νομίζω ότι θα νοιαστεί κανείς.

[karakou]

Ολα αυτα τα user processes που ανεφερες δεν εχουν σκοπο υπαρξης με το περας του user session, για ποιο λογο να μεινουν;Θα κανει τι ssh forwarding κ θα θελει να τρεχει το gpg-agent; Ή μηπως θα τρεχει soundserver κ θα θελει το pulseaudio ανοιχτο; Αν ειναι τοσο σημαντικο κατι τετοιο μπορει ειτε να τα τρεχει σα system services ή να κανει τις ρυθμισεις που αναφερθηκαν, δε καταλαβαινω το ντορο που γινεται για το least surprise principle. Αντι να επιβραβευουμε τα programming/sysadmin best practices, εμεις επιμενουμε σε κατι που χαλαει τη ζαχαρένια μας. Λες κ εχει σπασει ολο το λειτουργικο με μια ρυθμιση ασφαλείας.

[imitheos]

Ολα αυτα τα user processes που ανεφερες δεν εχουν σκοπο υπαρξης με το περας του user session, για ποιο λογο να μεινουν;Θα κανει τι ssh forwarding κ θα θελει να τρεχει το gpg-agent; Ή μηπως θα τρεχει soundserver κ θα θελει το pulseaudio ανοιχτο;

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