Boycott systemd

[mobinmob]

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."

[megahead13]

Ήμαρτον μ' αυτό το νούμερο!

[mrsaccess]

Η systemd-logind πρέπει να γίνεται restart κάθε 1000 ssh logins αλλιώς το κάθε login καθυστερεί 25 δευτερόλεπτα.

Κάποτε τέτοια διαμάντια βλέπαμε μόνο στο knowledge database της Microsoft.

[imitheos]

Η systemd-logind πρέπει να γίνεται restart κάθε 1000 ssh logins αλλιώς το κάθε login καθυστερεί 25 δευτερόλεπτα.

Κάποτε τέτοια διαμάντια βλέπαμε μόνο στο knowledge database της Microsoft.

ΑΧΑΧΑΧΑΧΑΧΑ

Πως δεν το πρόσεξα πιο νωρίς αυτό. Όντως μόνο στα Windows Millenium βλέπαμε κάτι τέτοια. Άντε και σε ανώτερα ο systemd.

[mrsaccess]

Και ναι, μόλις το χτύπησα το bug σε πολλούς server.
Κάποιος να του πάρει το keyboard από τα χέρια ρε παιδιά!

[megahead13]

Εγώ θα 'λεγα κάποιος να του τα κόψει τα χέρια καλύτερα να πάψει να... αυτό*!

Spoiler:

* σε -κίζεται τελειώνει

[imitheos]

Κατανοώ ότι κανένα από τα τρία δεν ενδείκνυται για όλους τους χρήστες και πολλοί μάλιστα θα πουν ότι δεν κάνουν για servers (άσχετο rant αλλά πώς μου την δίνουν αυτοί που μόνο το debian stable και το centos καταδέχονται για servers και όλα τα άλλα τα σνομπάρουν), αλλά χαίρομαι και για τις τρεις επιλογές μου (Slackware, Gentoo, NetBSD). Όσο στο vila bajo ακόμη τρίβουν να φύγουν τα bugs του systemd, εμείς παίζουμε με τις τάπες των βαρελιών από την βαρεμάρα που δεν χαλάει τίποτα.

Τρέχω Slackware-current (το οποίο επίσημα δεν πρέπει να τρέχει σε production μηχανήματα) εδώ και χρόνια σε servers και παίζει απροβλημάτιστα. Μία μόνο φορά θυμάμαι bug με σοβαρές επιπτώσεις σε ολόκληρη την ιστορία του -current. Ήταν τότε που αποφασίστηκε από κάποιους να χρησιμοποιείται ο κατάλογος /srv αντί για τον κλασικό /var/www/htdocs/whatever και το script που έκανε την μετάβαση είχε ένα bug που έσβηνε ολόκληρο τον κατάλογο με τις σελίδες του server. Δόξα τον Bob είχα backup.

Και δεν είναι μόνο το θέμα του systemd. Γενικά μιλάμε για Non-bullshit διανομή που ασχολείται με την ουσία και όχι με χαζομάρες. Το στήνεις σε 10 λεπτά λόγω του μικρού αριθμού πακέτων και υπάρχουν σχεδόν τα πάντα μέσα για ένα server. Στο μόνο που υστερεί είναι ότι λόγω έλλειψης pam / ldap δεν μπορείς να το χρησιμοποιήσεις για σύνδεση σε domain. (Υπάρχουν hints ότι τώρα που βγήκε από την μέση το 14.2 και θα αρχίσει πάλι η ανάπτυξη, θα μπει και pam αλλά μέχρι να το δούμε είναι μόνο φήμη).

Τα NetBSD / OpenBSD είναι το ίδιο non-bullshit και εύκολα στο στήσιμο με το slack και με την ίδια σταθερότητα.

Το Gentoo είναι επίσης πολύ σταθερό (να πω την αλήθεια το ~arch δεν το πολύ εμπιστεύομαι για server λόγω του πολύ μεγάλου αριθμού πακέτων και λόγω των απείρων σεναρίων αλληλεπίδρασης μεταξύ των προγραμμάτων λόγω use flags που δεν μπορούν να δοκιμαστούν όλα αλλά το σκέτο arch είναι μια χαρά) και το μόνο κακό που έχει είναι οι χρόνοι compile αλλά για ένα server που θα έχει λίγα πακέτα και δεν θα έχει ολόκληρο το kde και το libreoffice, οι χρόνοι θα είναι μικροί και υποφέρονται. Επίσης σχεδόν όλοι οι πάροχοι σου δίνουν έτοιμο image για gentoo οπότε υποθέτω πως υπάρχει κόσμος που το εμπιστεύεται για server και τους το ζητάει σαν επιλογή.

Εννοείται πώς όλοι όσοι συμμετέχουν στον παρόν νήμα τα ήξεραν αυτά που έγραψα, απλά τα έγραψα μήπως διαβάσει κάποιος άλλος το νήμα για να ξέρει ότι υπάρχουν επιλογές εκτός systemd.

[megahead13]

Κατανοώ ότι κανένα από τα τρία δεν ενδείκνυται για όλους τους χρήστες και πολλοί μάλιστα θα πουν ότι δεν κάνουν για servers (άσχετο rant αλλά πώς μου την δίνουν αυτοί που μόνο το debian stable και το centos καταδέχονται για servers και όλα τα άλλα τα σνομπάρουν), αλλά χαίρομαι και για τις τρεις επιλογές μου (Slackware, Gentoo, NetBSD).

Ημίθεε, καλά όσα λες, αλλά δυστυχώς Slackware, Gentoo, *BSD σε πολλές περιπτώσεις όντως δεν κάνουν για servers στο enterprise. Και δε μιλάω για web, ftp, email, routing, κτλ servers, αλλά για servers/workstations (physical ή virtual δεν έχει σημασία) που τρέχουν εφαρμογές με πανάκριβες άδειες χρήσης για τις οποίες οι software vendors σου λένε υποστηρίζουμε μόνο RHEL (πολλές φορές ούτε καν CentOS/Scientific), SLES (κουβέντα για OpenSuse φυσικά) και Ubuntu/Debian Stable. Μπορώ να αναφέρω άπειρα παραδείγματα από το χώρο στον οποίο εργάζομαι τα τελευταία ~6 χρόνια. Σε τέτοιες περιπτώσεις και μάλιστα όταν έχεις ένα προϊόν που πρέπει να βγει στην αγορά, δε μπορείς να κάνεις ταρζανιές με τα USE flags του Gentoo, όσο και να το θες. Τα παραπάνω τα έχω γράψει και στην αρχή του νήματος

[imitheos]

Ημίθεε, καλά όσα λες, αλλά δυστυχώς Slackware, Gentoo, *BSD σε πολλές περιπτώσεις όντως δεν κάνουν για servers στο enterprise. Και δε μιλάω για web, ftp, email, routing, κτλ servers, αλλά για servers/workstations (physical ή virtual δεν έχει σημασία) που τρέχουν εφαρμογές με πανάκριβες άδειες χρήσης για τις οποίες οι software vendors σου λένε υποστηρίζουμε μόνο RHEL (πολλές φορές ούτε καν CentOS/Scientific), SLES (κουβέντα για OpenSuse φυσικά) και Ubuntu/Debian Stable. Μπορώ να αναφέρω άπειρα παραδείγματα από το χώρο στον οποίο εργάζομαι τα τελευταία ~6 χρόνια. Σε τέτοιες περιπτώσεις και μάλιστα όταν έχεις ένα προϊόν που πρέπει να βγει στην αγορά, δε μπορείς να κάνεις ταρζανιές με τα USE flags του Gentoo, όσο και να το θες. Τα παραπάνω τα έχω γράψει και στην αρχή του νήματος

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

Έγραψα αυτά που έγραψα πιο πολύ για κάποιον που θα νευριάσει με το Χ bug του systemd και ψάχνοντας για λύση θα πέσει πάνω στο νήμα και δεν ήξερε ότι υπάρχουν διανομές στις οποίες μπορείς (ακόμη) να μην έχεις systemd.

[mobinmob]

Στο μόνο που υστερεί είναι ότι λόγω έλλειψης pam / ldap δεν μπορείς να το χρησιμοποιήσεις για σύνδεση σε domain. (Υπάρχουν hints ότι τώρα που βγήκε από την μέση το 14.2 και θα αρχίσει πάλι η ανάπτυξη, θα μπει και pam αλλά μέχρι να το δούμε είναι μόνο φήμη).

To περίεργο είναι πως έχουν υπάρξει τουλάχιστον 2 προσπάθειες για να υπάρξει υποστήριξη pam (και μία στο zenwalk παλιότερα αν δεν κάνω λάθος) και δεν έχει γίνει πρόοδος...

Εννοείται πώς όλοι όσοι συμμετέχουν στον παρόν νήμα τα ήξεραν αυτά που έγραψα, απλά τα έγραψα μήπως διαβάσει κάποιος άλλος το νήμα για να ξέρει ότι υπάρχουν επιλογές εκτός systemd.

Σε αυτές μπορεί κάποιος να προσθέσει και το debian stable - υποστηρίζεται κανoνικά το sysvinit. Για desktop υπάρχουν και άλλες επιλογές

[karakou]

Μιλατε για bugs στο systemd και προτεινετε διανομές που δεν υποστηριζούν pam. Μονο εγω βλεπω την αντιφαση στο επιχείρημα;

[mobinmob]

Από τις διανομές/λειτουργικά που έχουν προταθεί στα τελευταία posts, μόνο το Slackware δεν έχει PAM.

[mobinmob]

How to Crash Systemd in One Tweet
https://www.reddit.com/r/linux/comme..._in_one_tweet/
https://news.ycombinator.com/item?id=12600413

[dimitri_ns]

How to Crash Systemd in One Tweet
https://www.reddit.com/r/linux/comme..._in_one_tweet/
https://news.ycombinator.com/item?id=12600413

Αραγε υπάρχει επιστροφή ?
Keep it simple

[imitheos]

How to Crash Systemd in One Tweet
https://www.reddit.com/r/linux/comme..._in_one_tweet/
https://news.ycombinator.com/item?id=12600413

Αραγε υπάρχει επιστροφή ?
Keep it simple

Bugs, oversights, off-by-one λάθη θα υπάρχουν πάντα σε όλα τα software απλά το κακό με το systemd είναι ότι αποδεικνύουν συνέχεια ότι ο καθένας γράφει ό,τι θέλει και ή οι reviewers δέχονται τα πάντα χωρίς να τα κοιτάνε ή δεν υπάρχουν καν reviewers. Επίσης, χωρίς να θέλω να το παίξω ο μέγας programmer, σε κάποιους από τους devs λείπουν γνώσεις σε system programming. Μπορεί να έχουν καταπληκτική γνώση της C σαν γλώσσα αλλά αυτό δεν σημαίνει ότι ξέρουν να γράφουν σωστό κώδικα με signals, IPC, δαίμονες, network, κτλ.

Όταν έγραψε κάποιος την συνάρτηση αυτή τι είχε στο μυαλό του με το συγκεκριμένο assert ? Ο πρώτος κανόνας του fight clubassert είναι ότι δεν υποκαθιστά τον έλεγχο. Δεν το χρησιμοποιείς δηλαδή για να ελέγξεις κάτι που έδωσε ο χρήστης ή αν πέτυχε η malloc ή γενικά όπου θα έβαζες ένα if που θα έτρεχε μετά κάποια cleanup συνάρτηση που θα επέστρεφε ένα χρήσιμο μήνυμα λάθους στον χρήστη αλλά το χρησιμοποιείς για εσένα για συνθήκες που δεν μπορούν με τίποτα να ισχύουν ώστε να σε βοηθήσει στο debugging αν η συνάρτησή σου δεν παίζει σωστά (για αυτό το λόγο άλλωστε δεν κάνει τίποτα το assert αν ο κώδικας γίνει compile με NDEBUG). Η χρήση δηλαδή του assert σε αυτό το σημείο προδίδει ελλειπή γνώση της γλώσσας.

Επίσης ξέχασα να αναφέρω ότι ειδικά σε βιβλιοθήκες και δαίμονες, το assert είναι σχεδόν πάντα λάθος πρακτική (ειδικά σε PID1 δαίμονες). Φαντάζεσαι να κράσαρε η ssh σύνδεσή σου σε ένα critical μηχάνημα επειδή μια μαλακία βάρεσε ένα assert ?

Κάποιοι λένε στο github να αλλάξει το assert σε assert (n >= 0) ώστε να παίζει σωστά. Αφενός και σε αυτή την περίπτωση θα είναι λάθος λόγω της λογικής που περιέγραψα πριν αλλά επίσης θα είναι λάθος από την άποψη ότι το n ορίζεται ως size_t επομένως είναι πάντα θετικό οπότε το assert είναι άχρηστο.

Δυστυχώς το assert χρησιμοποιείται λάθος από πολλούς οπότε υπό άλλες συνθήκες δεν θα έλεγα τίποτα. Ο κ. Lennart όμως μας τα κόβει πολύ παχιά και έχει ένα ύφος δέκα καρδιναλίων ενώ δεν γνωρίζει βασική C

Edit: Εν τέλει έγινε commit ένα fix που προτάθηκε στο github. Άργησε να γίνει commit κάποιες ώρες επειδή οι γαμάτοι reviewers βρήκαν λάθος indentation (όχι ότι δεν πρέπει να τηρείται το σωστό indentation που ορίζει το project αλλά μιλάμε για critical bug) και τελικά ο ίδιος που έγραψε το patch λέει ότι μελετώντας καλύτερα τον κώδικα είδε ότι δεν είναι σωστό αυτό που έκανε και τώρα πρότεινε κάποια άλλη λύση.

Μιλάμε για QA με @@ όχι παίξε γέλασε. Οι reviewers προσέχουν τι κάνουν commit και περνάνε μόνο σωστά patches.