Boycott systemd

[GoofyX]

Ένα link σχετικό με το systemd: http://www.tecmint.com/systemd-replaces-init-in-linux/

[tritonas00]

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

η μπορουσες να διαβασεις τοτε το output του pacman κατα το update που ελεγε για το /etc/udev/rules.d/80-net-setup-link.rules

Ετσι το εχω ακομα

Κατα τα αλλα, με μισο ματι την πηρα την αλλαγη σε systemd στο arch τοτενες.

Μας κατσικωθηκε με το ζορι, οπως και προσφατα το pulseaudio με το skype (ευτυχως το δευτερο υποστηριζει εξοδο στο dmix της alsa...)

O lennart εχει και αλλα ωραια σχεδια...

[petran_18]

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

[GoofyX]

Ορίστε ένα άλλο άρθρο: http://0pointer.net/blog/projects/th...est-myths.html

Από το blog του δημιουργού του systemd, του Lennart Poettering.

[imitheos]

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

Δυστυχώς όμως το single point of failure ισχύει. Παραβλέπωντας συνομωσιολογικά σενάρια με hackers που θα ασχοληθούν όλοι να βρουν προβλήματα στον systemd (που έχει μια δόση αλήθειας), μην ξεχνάμε ότι το init τρέχει σαν PID 1. Ο πυρήνας αντιμετωπίζει διαφορετικά το PID 1 και όταν αυτό crashάρει, τότε βαράει kernel panic. Ένα κλασικό init είναι περίπου 30kb ενώ το systemd (στο debian) είναι 1.5MB. Όσο καλός developer να είναι αυτός που το αναπτύσσει, φαντάσου πόσο πιθανό είναι να υπάρχει κάποιο leak ή bug (ειδικά σε C) το οποίο να σου ρίξει όλο το σύστημα.

Εδώ υπάρχει ένα καλό μήνυμα με κριτική στο systemd και στο τέλος έχει τον απολύτως βασικό κώδικα που χρειάζεται να τρέχει σαν PID 1 και όλα τα άλλα να τρέχουν από ένα script όπως στο sysvinit. Δες πόσο τεράστιος κώδικας είναι

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

Όπως ειπώθηκε και από άλλο παιδί, συνήθως οι αλλαγές βρίσκονταν στα script και όχι στο /sbin/init οπότε δεν χρειαζόσουν τίποτα.

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

Φαινομενικά είσαι μια χαρά εννοείται. Και τα windows μια χαρά δουλεύουν για ένα end-user. Όταν θα αρχίσουν να βγαίνουν τα προβλήματα είναι το θέμα Να μη ξεχνάμε ότι και τζάμι να παίζει κάτι, κάποια φορά θα χρειαστείς να αλλάξεις κάποια ρύθμιση και θέλεις αυτό να γίνεται εύκολα. Εδώ ο Ted Ts'o (developer του ext4 filesystem) αναφέρει πόση μανούρα ήταν να ψάχνει να βρίσκει ποια xml αρχεία έπρεπε να πειράξει στο policykit και στο systemd για να κάνει κάτι που ήθελε και που παλιά γινόταν σε 5 δευτερόλεπτα.

Το πρόβλημα του systemd (ίσως σε αυτό φταίει η αλαζονική συμπεριφορά "εμείς γνωρίζουμε το καλό σου" του lennart) είναι ότι αλλάζει τα πάντα χωρίς να παρέχει ένα λόγο. Για παράδειγμα, μέχρι τώρα πολύς κόσμος είχε το /usr σε ξεχωριστό partition (είτε είχε κάποιο σοβαρό λόγο είτε γιατί το διάβασε σε ένα από τους χιλιάδες οδηγούς που το σύστηναν ή ποιος ξέρει γιατί). Ήρθε ο lennart και είπε ότι αυτό το setup δεν χρειάζεται και δεν έχεις κανένα λόγο να έχεις ξεχωριστό /usr οπότε με systemd δεν θα παίζει και ζήτησε από τον κόσμο να επιχειρηματολογήσει γιατί χρειάζεται ξεχωριστό /usr.

Υπάρχει μια αρχή που λέγεται "teapot in the sun/sky" που λέει ότι η ευθύνη βαρύνει αυτόν που ισχυρίζεται κάτι και όχι τους υπολοίπους. Αν εγώ βγω και πω ότι αυτή τη στιγμή υπάρχει μια τσαγιέρα που κινείται σε τροχιά γύρω από τη γη, εγώ είμαι αυτός που πρέπει να το αποδείξω και όχι όλοι οι υπόλοιποι να το καταρρίψουν. Δεν μπορώ να πω "αφού δεν μπορείτε να αποδείξετε ότι δεν υπάρχει, άρα υπάρχει". Το systemd είναι αυτό που άλλαξε μια συμπεριφορά που δούλευε χρόνια οπότε αυτό είναι που πρέπει να επιχειρηματολογήσει γιατί δεν πρέπει να έχουμε ξεχωριστό /usr και όχι ο κόσμος το αντίθετο.

Το ξεχωριστό /usr ήταν ένα από αυτά που προκάλεσαν ντόρο για αυτό το ανέφερα αλλά δεν είναι η μόνη τέτοια αυθαίρετη αλλαγή που έκανε.

Ορίστε ένα άλλο άρθρο: http://0pointer.net/blog/projects/th...est-myths.html

Από το blog του δημιουργού του systemd, του Lennart Poettering.

Όλα τα μηνύματά του είναι προπαγανδιστικά που παρουσιάζουν το systemd σαν καταπληκτικό και έχουν παραπλανητικές πληροφορίες. Για παράδειγμα θυμάμαι παλιά σε μια σελίδα έγραφε ότι το systemd έχει 2 dependencies (την libdbus και δεν θυμάμαι ποια άλλη) και ακριβώς από κάτω ανέφερε 45 πράγματα που υποστηρίζει το systemd τα οποία όμως εννοείται πως για να τα υποστηρίξει μπαίνουν ένα κάρο optional dependencies. Είναι όπως οι διαφημίσεις αυτοκινήτων που λένε "από 9000 ευρώ έως 150 άλογα". Ή έχει 2 dependencies και υποστηρίζει @@ ή υποστηρίζει όλα αυτά αλλά έχει 30 dependencies. Επίσης πολύς κόσμος έχει γράψει κριτική (μεταξύ τους και εγώ) και τα σχόλιά τους δεν αναρτήθηκαν ποτέ στο site γιατί κόπηκαν.

Σίγουρα θα το έχετε διαβάσει αλλά ακολουθεί ένα παράδειγμα της συμπεριφοράς των devs. Ο πυρήνας κάνει expose την command line του ώστε να την χρησιμοποιήσουν προγράμματα. Μία πολύ γνωστή flag είναι η debug την οποία έβλεπε ο systemd και έκανε spam στα logs τα κέρατα με συνέπεια να μπλοκάρει ο δίας. Το bug λύθηκε αμέσως και μάλιστα μπήκε και υποστήριξη στον πυρήνα για rate-limiting ώστε να μην υπάρχει ξανά τέτοιο θέμα αλλά οι devs του systemd δεν δέχονταν ότι ήταν bug και όπως πάντα πετούσαν το μπαλάκι στους άλλους.
1 2 3 4

Επίσης να πω δεν ισχύει το επιχείρημα που ακούω συχνά "άμα θέλεις το βάζεις". Αν θυμόμαστε καλά, κάποιος έκατε και έγραψε τα policykit, consolekit, κτλ. Προωθήθηκαν από κάποιες διανομές με αποτέλεσμα οι devs αυτών των διανομών να τα περάσουν στα projects που δουλεύουν (πχ kde, gnome, κτλ) με αποτέλεσμα να είσαι αναγκασμένος να τα έχεις. Το ίδιο γίνεται και με το systemd. Αν μπει ως hard dependency στο KDE, υπάρχει διανομή που να μπορεί να μην το βάλει ?

Η κριτική που δέχεται το systemd θα ήταν απείρως μικρότερη αν σου έδινε το δικαίωμα να μην το βάλεις (τώρα ακόμη το έχουμε αλλά μιλάμε για το μέλλον).

Still Hungry

[petran_18]

Αν υπάρχει μια δόση αληθειας σε όσα λέγονται για το systemd και αν υποθέσουμε ότι οι devs σε αλλα project/διανομές είναι στοιχειωδώς λογικοί, δεν θα έπρεπε να κάνουν στην άκρη το systemd η έστω να μην κάνουν το kde/οποιο άλλο project να εξαρτάται;

Συμφωνώ με όσα λες ημίθεε και έχω αυτήν την εύλογη απορία. Αν καταλαβαίνω καλά δεν είναι και πολύ σύμφωνη με το ελεύθερο λογισμικό αυτή η τακτική. Θυμάμαι αντίστοιχα να διαφωνούν για το ballo στο νήμα του KDE. Αν ένας dev έχει complex/μεγαλομανίες η έτρωγε φάπα στο σχολειo δε χρωστάει όλη η κοινότητα.

[imitheos]

Αν υπάρχει μια δόση αληθειας σε όσα λέγονται για το systemd και αν υποθέσουμε ότι οι devs σε αλλα project/διανομές είναι στοιχειωδώς λογικοί, δεν θα έπρεπε να κάνουν στην άκρη το systemd η έστω να μην κάνουν το kde/οποιο άλλο project να εξαρτάται;

Δεν έχω κάποιο σοβαρό επιχείρημα αλλά μεταξύ σοβαρού και αστείου, έχεις προσέξει ποτέ κάτι ατάλαντες/ους που πρωταγωνιστούν σε 15 σειρές ή που σώνει και καλά πρέπει να έχουν δική τους εκπομπή μόνο και μόνο επειδή τα έχουν με κάποιο μεγάλο κεφάλι σε κανάλι και τις προωθεί ? Και ενώ όλοι οι συνεργάτες τους τραβάνε τα μαλλιά τους, και όλοι κριτικοί γράφουν αρνητικές κριτικές δεν γίνεται τίποτα ?

Αυτό μου έρχεται στο μυαλό για τον lennart και την παρέα του. Ό,τι σαχλαμάρα (pulseaudio, systemd, whatever) σκέφονται, όσο χάλια και αν είναι αυτή και όσο άσχημα να χαλάει το σύστημα των χρηστών, αυτή θα γίνει merge στη fedora και το ubuntu και μετά θα ξεκινήσει η κατρακύλα.

Σκέψου πόσα init έχουν βγει και ενώ τα χρησιμοποιούσε για καιρό κάμποσος κόσμος παρόλα αυτά δεν προχώρησαν. Και πριν κάποιος πει ότι ήταν μικρά τυχαία projects, το daemontools δεν το έγραψε κάποιος τυχαίος.

Δεν έχω κανένα πρόβλημα με τον lennart να γράψει ό,τι θέλει αρκεί να μην το φορτωθώ εγώ. Για παράδειγμα στο gentoo δημιούργησαν το openrc. Δεν ξέρω πόσο καλό είναι (αν και μου φαίνεται καλό). Δεν ήρθε όμως κανένας από το gentoo να με αναγκάσει εμένα που τρέχω slackware να το εγκαταστήσω. Το portage του gentoo και το pacman του Arch είναι ομολογουμένως από τα καλύτερα package managers και παρόλα αυτά δεν ανάγκασαν κανέναν από άλλες διανομές να τα χρησιμοποιήσουν.

Μόνο τα projects του lennart πάντα θα τα φορτωθούμε όλοι.

[petran_18]

Δεν έχω κάποιο σοβαρό επιχείρημα αλλά μεταξύ σοβαρού και αστείου, έχεις προσέξει ποτέ κάτι ατάλαντες/ους που πρωταγωνιστούν σε 15 σειρές ή που σώνει και καλά πρέπει να έχουν δική τους εκπομπή μόνο και μόνο επειδή τα έχουν με κάποιο μεγάλο κεφάλι σε κανάλι και τις προωθεί ? Και ενώ όλοι οι συνεργάτες τους τραβάνε τα μαλλιά τους, και όλοι κριτικοί γράφουν αρνητικές κριτικές δεν γίνεται τίποτα ?

Αυτό μου έρχεται στο μυαλό για τον lennart και την παρέα του. Ό,τι σαχλαμάρα (pulseaudio, systemd, whatever) σκέφονται, όσο χάλια και αν είναι αυτή και όσο άσχημα να χαλάει το σύστημα των χρηστών, αυτή θα γίνει merge στη fedora και το ubuntu.

njoy

Spoiler:

[imitheos]

Όσον αφορά το θέμα του bloat και πιο πολύ του single point of failure, να προσθέσω κάτι ακόμη.

Ένα καλό του systemd είναι ότι είναι modular και συνδυάζει πολλά components που σε αφήνει να επιλέξεις εσύ ποια θέλεις. Όταν όμως όλες αυτές οι υποδομές συνδυάζονται σε ένα binary, αυτό αυξάνει κατά πολύ τις πιθανότητες του να υπάρχει πρόβλημα (και λόγω pid 1 οποιαδήποτε leak / bug να έχει αποτέλεσμα panic).

Θα χρησιμοποιήσω άλλη μια φορά το gentoo ως παράδειγμα γιατί η source φύση του κάνει πιο εύκολο να περιγράψω αυτό που θέλω.

COMMON_DEPEND=">=sys-apps/util-linux-2.20:0=
	sys-libs/libcap:0=
	acl? ( sys-apps/acl:0= )
	audit? ( >=sys-process/audit-2:0= )
	cryptsetup? ( >=sys-fs/cryptsetup-1.6:0= )
	curl? ( net-misc/curl:0= )
	elfutils? ( >=dev-libs/elfutils-0.158:0= )
	gcrypt? ( >=dev-libs/libgcrypt-1.4.5:0=[${MULTILIB_USEDEP}] )
	gudev? ( >=dev-libs/glib-2.34.3:2=[${MULTILIB_USEDEP}] )
	http? (
		>=net-libs/libmicrohttpd-0.9.33:0=
		ssl? ( >=net-libs/gnutls-3.1.4:0= )
	)
	idn? ( net-dns/libidn:0= )
	introspection? ( >=dev-libs/gobject-introspection-1.31.1:0= )
	kmod? ( >=sys-apps/kmod-15:0= )
	lz4? ( >=app-arch/lz4-0_p119:0=[${MULTILIB_USEDEP}] )
	lzma? ( >=app-arch/xz-utils-5.0.5-r1:0=[${MULTILIB_USEDEP}] )
	pam? ( virtual/pam:= )
	python? ( ${PYTHON_DEPS} )
	qrcode? ( media-gfx/qrencode:0= )
	seccomp? ( sys-libs/libseccomp:0= )
	selinux? ( sys-libs/libselinux:0= )
	abi_x86_32? ( !<=app-emulation/emul-linux-x86-baselibs-20130224-r9
		!app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] )"

Οτιδήποτε βλέπουμε πριν από ερωτηματικό είναι optional dep. Έτσι βλέπουμε ότι εγώ μπορώ να ενεργοποιήσω την lz4 και την kmod και την acl, ένας άλλος να επιλέξει την acl, την curl και γενικά υπάρχουν 1000 πιθανοί συνδυασμοί. Παραβλέποντας το γεγονός ότι ο ίδιος ο lennart έχει πει ότι κάποια σενάρια δεν τους ενδιαφέρουν και δεν τα τεστάρουν, ακόμη και να ήθελαν να τεστάρουν τα πάντα, δεν μπορούν να το κάνουν όταν μιλάμε για τόσους συνδυασμούς.

Ποιος σου εγγυάται ότι ενώ υπό κανονικές συνθήκες είναι rock stable, δεν θα υπάρχει κάποιο bug που θα γίνεται trigger μόνο στον 35ο συνδυασμό που τρέχεις εσύ ?

Βέβαια, πολλές από τις optional deps είναι χρήσιμες σε πολύ κόσμο οπότε θα είναι ενεργοποιημένες σχεδόν σε όλες τις binary διανομές και έτσι δεν θα έχουμε τόσα πολλά σενάρια όσα περιέγραψα αλλά και πάλι κανείς δεν σου εγγυάται ότι υπάρχουν επαρκείς δοκιμές.

[petran_18]

.

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

Και με βάση ποια/ποιανού κριτήρια αποφασίζεται ποια είναι ενδιαφέροντα? Εγώ θέλω κάτι που δεν έχει κανεις άλλος γιατί έτσι. Γιατί δεν είναι windows και με το λογισμικό μπορώ να κάνω ότι θέλω και να μου το επιτρέπει.

Όχι να αποφασίζει ένας dev (και πάλι με τι κριτήρια?) τι ανάγκες έχω η τι και πως θα τρέχω το λογισμικό.

[mobinmob]

Εδώ υπάρχει ένα καλό μήνυμα με κριτική στο systemd και στο τέλος έχει τον απολύτως βασικό κώδικα που χρειάζεται να τρέχει σαν PID 1 και όλα τα άλλα να τρέχουν από ένα script όπως στο sysvinit. Δες πόσο τεράστιος κώδικας είναι

Δείτε και το επόμενο post στο ewontfix

Όπως ειπώθηκε και από άλλο παιδί, συνήθως οι αλλαγές βρίσκονταν στα script και όχι στο /sbin/init οπότε δεν χρειαζόσουν τίποτα.

To systemd θα μπορούσε να σχεδιαστεί σαν service manager χωρίς να τρέχει σαν pid 1, όπως κάνουν εδώ και χρόνια τα daemontools, οπότε δεν θα χρειαζόταν επανεκκίνηση του μηχανήματος.
Νομίζω ότι και τώρα θέλουν να το πετύχουν (ίσως κάνοντας execve στο εκτελέσιμο της νέας έκδοσης ; ).

Όλα τα μηνύματά του είναι προπαγανδιστικά που παρουσιάζουν το systemd σαν καταπληκτικό και έχουν παραπλανητικές πληροφορίες.

Από την συζήτηση εδώ:

One of Lennart's best talents is to take 20-year old ideas that haven't caught the mainstream world because they weren't properly advertised; to mix them up in a way that forsakes all concept of modularity; and to present the result as the most revolutionary and brilliant thing ever. If he was half as good an engineer as he is a communicator, the world would be a much better place.

Επίσης να πω δεν ισχύει το επιχείρημα που ακούω συχνά "άμα θέλεις το βάζεις". Αν θυμόμαστε καλά, κάποιος έκατε και έγραψε τα policykit, consolekit, κτλ. Προωθήθηκαν από κάποιες διανομές με αποτέλεσμα οι devs αυτών των διανομών να τα περάσουν στα projects που δουλεύουν (πχ kde, gnome, κτλ) με αποτέλεσμα να είσαι αναγκασμένος να τα έχεις. Το ίδιο γίνεται και με το systemd. Αν μπει ως hard dependency στο KDE, υπάρχει διανομή που να μπορεί να μην το βάλει ?

Αυτό που έχει γίνει στο gnome είναι να χρησιμοποιούνται dbus interfaces του systemd-logind. Ένα από τα projects στο Summer of Code είναι να υλοποιηθούν αυτά (και όχι μόνο) ανεξάρτητα από το systemd για το openbsd. Η προσπάθεια ονομάζεται "systembsd".
Ο Wayland θα χρειάζεται το logind για να έχει πρόσβαση σε συσκευές χωρίς να τρέχει σαν root. To ενδιαφέρον είναι πως το logind μπορούσε να δουλέψει με ένα μικρό patch χωρίς να χρειάζεται να τρέχει το systemd (init) , μέχρι την έκδοση 214 -αν θυμάμαι καλά. Από εκεί και πέρα, η διαχείριση των cgroups πέρασε στο "κεντρικό" systemd binary...
BTW, ο τελευταίος maintainer του consolekit ήταν ο Poettering.

[megahead13]

Με τις μαλακίες που κάνουν θα βγάλουν όλη τη Unix/Linux βιβλιογραφία που διαβάζουμε τόσα χρόνια άχρηστη!! O Linus έχει τοποθετηθεί επί του συγκεκριμένου θέματος;;

[KernelPanic]

O Linus έχει τοποθετηθεί επί του συγκεκριμένου θέματος;;

Απ' οτι γνωρίζω περα απο το επεισόδιο με τον Kay οχι.

[mrsaccess]

Με τις μαλακίες που κάνουν θα βγάλουν όλη τη Unix/Linux βιβλιογραφία που διαβάζουμε τόσα χρόνια άχρηστη!! O Linus έχει τοποθετηθεί επί του συγκεκριμένου θέματος;;

Δεν είναι τόσο δύσκολη η μετάβαση και έχει το καλό πως πλέον υπάρχει περισσότερη συμβατότητα ανάμεσα στις διανομές. Έχει τα θεματάκια του ο systemd αλλά και τα init scripts δεν είναι περίπατος.

[KernelPanic]

.... το καλό πως πλέον υπάρχει περισσότερη συμβατότητα ανάμεσα στις διανομές.

ουτε καν θελω να φανταστω την στιγμή που το systemd θα είναι και package manager...

Αν θέλουμε 1 σύστημα που να ειναι 100% συμβατό με τις αλλές διανομες, τον ίδιο package manager σε ολες κτλ κλτ γιατί δεν γυρίζουμε στα windows ?

Go ahead, kids, spackle over all of that unsightly runlevel stuff. Paint over init and cron, pam and login. Put all of that into PID1 along with dbus. Make it all pretty and whisper sweet nothings about how it's all taken care of and you won't have to read a manual or learn any silly command-line stuff. Tune your distribution for desktop workloads. Go reinvent Windows.

το παραπάνω απο με βρίσκει απόλυτα συμφωνο.. (ολόκληρο το αρθρο: You have your Windows in my Linux