Boycott systemd

[mobinmob]

Off Topic

Το κακό είναι πως δεν είναι όλα φάση WebKit που όλα είχαν ξεκινήσει με την KHTML του KDE

Ε, δεν συμβαίνει συχνά αυτό
Τώρα ακόμα και το qt χρησιμοποιεί το fork

[happybear]

Κανε και κακά, χεστήκαμε και μεις.

Δεν περίμενα σοβαρότερη απάντηση είναι η αλήθεια, worth the try though.

Η μασημένη τροφή, δεν παίζει, όπως και το να ανοίξουμε εδώ αναλύσεις.

Τις αναλύσεις τις κάνει ο mobinmob (σοβαρός λόγος και μετρημένος) και sorry δε θα σε ρωτήσουμε κιόλας.

[linuxer]

Δεν περίμενα σοβαρότερη απάντηση είναι η αλήθεια, worth the try though.

Τις αναλύσεις τις κάνει ο mobinmob (σοβαρός λόγος και μετρημένος) και sorry δε θα σε ρωτήσουμε κιόλας.

Όποιος θέλει μετρημένο και σοβαρό λόγο, εκφράζεται αντίστοιχα, χωρίς να προκαλεί.

[mobinmob]

Off Topic

Τις αναλύσεις τις κάνει ο mobinmob (σοβαρός λόγος και μετρημένος) και sorry δε θα σε ρωτήσουμε κιόλας.

Ε... ευχαριστώ, αλλά δεν έκανα καμιά ανάλυση! Ο καθένας έχει το στυλ του, οι προσωπικές αντιπαραθέσεις δεν έχουν νόημα. Αν δεν μπορείς να μιλήσεις με κάποιον κάπου πρέπει να υπάρχει ignore list. Υλικό για όσους γνωρίζουν αγγλικά υπάρχει πάντως. Δεν είναι καλά οργανωμένο (...), αλλά υπάρχει.

[linuxer]

Off Topic

Υλικό για όσους γνωρίζουν αγγλικά υπάρχει πάντως. Δεν είναι καλά οργανωμένο (...), αλλά υπάρχει.

Σε λίγο καιρό, με το καλό θα υπάρχει οργανωμένο και στα Ελληνικά.

[Asfodelus]

Οφείλω να αναγνωρίσω την βοήθεια που μου πρόσφερε ο @mobinmob τόσο με τα γραπτά του όσο και σε προσωπική επικοινωνία (με άφθονα links) στην προσπάθεια μου να ξεδιαλύνω το κουβάρι των διάφορων inits. Μπορεί να μην συμφωνούμε σε όλα, αλλά η διαφωνίες στα τεχνικά είναι σεβαστές. Εύχομαι κάποια στιγμή να βρει χρόνο και να μοιραστεί με όλους τις γνώσεις του. Ένα από τα συμπεράσματα της συζήτησης είναι πως δεν υπάρχει επαρκής τεκμηρίωση των εναλλακτικών.

Αν όσοι είναι αντίθετοι στο systemd είχαν το καθαρό μυαλό του, η κατάσταση των σχετικών συζητήσεων δεν θα ήταν τόσο τοξική. Στην τελική, με ελάχιστες εξαιρέσεις, σε αυτήν την συζήτηση όλοι το τι είναι το καλύτερο για το ελεύθερο λογισμικό αναζητούμε.

[megahead13]

Οφείλω να αναγνωρίσω την βοήθεια που μου πρόσφερε ο @mobinmob τόσο με τα γραπτά του όσο και σε προσωπική επικοινωνία (με άφθονα links) στην προσπάθεια μου να ξεδιαλύνω το κουβάρι των διάφορων inits. Μπορεί να μην συμφωνούμε σε όλα, αλλά η διαφωνίες στα τεχνικά είναι σεβαστές. Εύχομαι κάποια στιγμή να βρει χρόνο και να μοιραστεί με όλους τις γνώσεις του. Ένα από τα συμπεράσματα της συζήτησης είναι πως δεν υπάρχει επαρκής τεκμηρίωση των εναλλακτικών.

Αν όσοι είναι αντίθετοι στο systemd είχαν το καθαρό μυαλό του, η κατάσταση των σχετικών συζητήσεων δεν θα ήταν τόσο τοξική. Στην τελική, με ελάχιστες εξαιρέσεις, σε αυτήν την συζήτηση όλοι το τι είναι το καλύτερο για το ελεύθερο λογισμικό αναζητούμε.

Ε, δώστε κι εδώ δημόσια τα άφθονα links για τα εναλλακτικά init systems! Μην είστε παρτάκηδες!

[linuxer]

Ε, δώστε κι εδώ δημόσια τα άφθονα links για τα εναλλακτικά init systems! Μην είστε παρτάκηδες!

Υπάρχουν στο linuxer.gr, στο Artix Linux Wiki & στο Gentoo Wiki, για την ώρα.

Επίσης υπάρχουν πάμπολλες πηγές στο γιατί όχι systemd.

[Moho]

Υπάρχουν στο linuxer.gr, στο Artix Linux Wiki & στο Gentoo Wiki, για την ώρα.

Επίσης υπάρχουν πάμπολλες πηγές στο γιατί όχι systemd.

Μπορεί και να υπάρχουν, αλλά άμα δεν μπορώ να τις κάνω copy/paste, τότε so much for freedom of information

[linuxer]

Μπορεί και να υπάρχουν, αλλά άμα δεν μπορώ να τις κάνω copy/paste, τότε so much for freedom of information

Ctrl+Click και ανοίγει το link σε άλλο tab

[ESP1982]

Μα ακριβώς αυτό περιμένω να γίνει όταν κάνω logout από μια γραφική συνεδρία. Το nohup το λέει και το όνομα είναι για το τερματικό. Επειδή όμως πριν τα cgroups δεν μπορούσε αυτό να γίνει. Άρα να μην διορθωθεί κάτι λάθος γιατί έτσι κάναμε τόσο καιρό; Να δώσω ένα πρακτικό παράδειγμα. Χρησιμοποιώ cinnamon που δυστυχώς δεν υποστηρίζει systemd ακόμα. Κάποιες φορές κάποια παιγνίδια στο steam κολλάνε και τρέχουν στο background χωρίς παράθυρο. Ακόμα και αν κάνω logout παραμένουν. Γιατί;

Δεν ήμουν συγκεκριμένος, δεν εννοούσα σε καμία περίπτωση X forward.

Μιλούσα για services που γίνονται για παράδειγμα deploy μέσω κάποιου CI tool, σηκώνονται στο background και _πρέπει_ να μείνουν μετά το logout (π.χ. κάνω deploy κάτι που σηκώνει ένα service στο port <χ>). Συνήθως -από τη μεριά μου τουλάχιστον- πάντα τα σηκώνω σε ένα tmux, detach και logout. Ποιός όμως ο λόγος να φάει fail → να ψάχνω σε 10 μεριές αντί να έχουν ένα κοινό changelog για σημαντικές αλλαγές? (υπόδειγμα για current στο OpenBSD: https://www.openbsd.org/faq/current.html )

Τι εννοείς; Το documentation είναι τεράστιο και εκτεταμένο. Ο κώδικας έχει 20% σχόλια. Το μόνο πρόβλημα είναι πως πρέπει να ξαναδιαβάσει κανείς, για πλήρη χρήση. Στην πράξη οι παλιές μέθοδοι δουλεύουν και έχει ένα ομαλό μονοπάτι μετάβασης. Αυτός είναι ένας απο τους λόγους που έχει επικρατήσει.

Να κάνω παραπομπή στο OpenBSD faq πάλι; Κατά τη γνώμη μου πάλι, το γεγονός ότι είναι τεράστιο και εκτεταμένο, δεν το κάνει απαραίτητα καλό και σωστό. Θα μου πεις αν έχω συνηθίσει από OpenBSD manpages, πού πάω;

Ένας άλλος μεγάλος λόγος, είναι και το μουλάριασμα του Lennart, ο οποίος πάντα παίρνει αμυντική στάση και οι απαντήσεις του είναι 'move along, nothing to see here', έχοντας γενικά έναν υποτιμιτικό τόνο (τουλάχιστον έτσι το παρσάρω από τη μεριά μου).

Ναι, ο systemd όντως ΛΥΝΕΙ προβλήματα (βασικά μόνο ένα μπορώ να σκεφτώ ) . Το θέμα είναι πως έχει αρχίσει να καταπίνει τα πάντα, να σπάει compatibility χωρίς να υπάρχει τρόπος να το γνωρίζεις εκ των προτέρων και να καταλήγει να δημιουργεί περισσότερα προβλήματα από όσα λύνει.

Off Topic

Σημείωση: ο λόγος σύγκρισης με το OpenBSD στο επίπεδο του documentation γίνεται γιατί με ~30 άτομα manpower βλέπω καλύτερο, σωστότερο και πιο user friendly documentation από μία εταιρία με πολύ μεγαλύτερο δυναμικό + το community που έχει από πίσω.

[Asfodelus]

ατά τη γνώμη μου πάλι, το γεγονός ότι είναι τεράστιο και εκτεταμένο, δεν το κάνει απαραίτητα καλό και σωστό.

Αλλά αν συγκρίνεις την κατάσταση με τα εναλλακτικά inits η κατάσταση θα είναι σαν την μέρα με την νύχτα. Όχι μόνο από πλευράς δυνατοτήτων αλλά και από πλευράς τεκμηρίωσης. Πριν 5 χρόνια ίσως η τεκμηρίωση του `systemd` να μην ήταν καλή, αλλά σήμερα δεν ισχύει ποια αυτό.

Αν έχω ένα παράπονο είναι πως είναι τεράστιο. Δεν μπορώ να κρίνω απο το BSD αλλά τα βρίσκω πολύ καλά. Η πλήρη τρομώδεις λίστα

https://www.freedesktop.org/software/systemd/man/

Επίσης υπάρχει το https://freedesktop.org/wiki/Software/systemd/ και το https://systemd.io/ καθώς και μια σειρά άρθρων στο http://0pointer.net/blog/ και πολλά βίντεο σε συνέδρια. Επίσης υπάρχει πολύ πληροφορία διάσπαρτη σε blogs, stack overflow κλπ..

Αλλά θα συμφωνήσω πως αυτά δεν αρκούν. Ένα man page είναι χρήσιμο όταν ξέρεις την εντολή. Πολλές γωνίες του είναι ξεχασμένες και μόνο όσοι τις χρησιμοποιούν τις γνωρίζουν και δεν έχουν μεταφέρει την γνώση σε άρθρα σε blogs. Και έχει πολλά directives. Διαβολεμένα πολλά

https://www.freedesktop.org/software...irectives.html

Πάρε για παράδειγμα το `AllowedCPUs=` ή το `BlockIODeviceWeight=` ή το `DevicePolicy=`. Όλα έχουν μια ιστορία να πουν με περιπτώσεις που είναι χρήσιμα. Ευτυχώς στην πράξη αρκεί να ξέρεις ένα μικρό ποσοστό από αυτές. Αλλά αυτές οι ιστορίες δεν έχουν γραφτεί. Ίσως να φταίει το που να πας να μπλέξεις. Έχω γράψει λίγες εκατοντάδες αρθράκια για το Linux, οδηγούς παρουσιάσεις προγραμμάτων κλπ. Συνήθως κάποιος έλεγε ένα ευχαριστώ. Όταν άρχισα να γράφω για systemd εισέπραξα αντίθετα πολλές βρισιές και κατάρες.

Μιλούσα για services που γίνονται για παράδειγμα deploy μέσω κάποιου CI tool, σηκώνονται στο background και _πρέπει_ να μείνουν μετά το logout

Και εκεί το παλιό καλό nohup παίρνει τον πούλο Σκέψου το όμως ως εξής: Παλιά είχαμε δυο τύπους προγραμμάτων τις "υπηρεσίες συστήματος" και τα "προγράμματα χρήστη". Τα παραπάνω δεν είναι ούτε στην μια κατηγορία, ούτε στην άλλη. Ας τα ονομάσουμε ελλείψει καλύτερου όρου ως "υπηρεσίες χρήστη". Σε ένα τυπικό UNIX δεν μπορείς να έχεις τίποτε άλλο. Και οι δαίμονες δεν ήταν κάτι άλλο από ένα hack με double fork. Αλλά με τα api του Linux μπορείς να κάνεις κάτι καλύτερο. Να τα βάλεις μέσα σε ένα cgroup (πιθανά και σε ενα BSD jail - διαφώτισε μας) και να μην μπορεί να ξεφύγει τίποτα και να τα κρατάς εκεί μέσα και να τα προσέχεις ) https://linux-user.gr/t/gia-ta-cgrou...h-istoria/2238. Σαν ένα bonus μπορείς να έχεις και καλύτερο έλεγχο των resources μην σου μείνει στο χέρι ο server γιατί έχεις εκεί και ένα CI.

Οπότε εδώ μπαίνει το .... διάβασμα . Θα πρέπει να μάθεις τους νέους τρόπους. Ίσως να το βρεις και ποιο εύκολο και να λες "βρε πως τα έκανα έτσι τόσο καιρό"

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

Μια ενδιαφέρουσα ιστορία για το tmux είναι πως οι devs του systemd πήγαν στο αποθετήριο του και έκαναν ένα pull request https://github.com/tmux/tmux/issues/428. Στο internet επικράτησε τρέλα. Αρρρρρργκκκ το systemd είναι χταπόδι.

Ctrl+Click και ανοίγει το link σε άλλο tab

Το να σε αντιγράφουν πάντως είναι η καλύτερη μορφή κολακείας

Σήμερα με μεγάλη μου χαρά βρήκα πως οι όροι χρήσεως που είχα γράψει για ένα φόρουμ μεταφέρθηκαν αυτούσιες ως έχει σε ένα άλλο. Και πραγματικά χάρηκα πολύ που με αυτό το λίγο βοήθησα κάποιον άλλον Τούς έβγαλα με άδεια χρήσης creative commons ακριβώς για αυτό τον λόγο. Αλλά ρε παιδιά εν έτη 2020 φτιάχνετε ένα φόρουμ με SMF, δεν θα κρίνω το τεχνολογικό stack, αλλά διαβάζετε τι κοπιάρετε. Λέτε μέσα για επίπεδα χρηστων, παράσημα και άλλα κουλά που το SMF δεν έχει

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

[imitheos]

Αντί για κατεβατά λοιπόν ενάντια σε ένα σύστημα παρουσιάστε τα άλλα συστήματα. Δείξετε μας τα θετικά τους και που πλεονεκτούν.

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

Οι δε non-systemdδάκηδες

Παρουσιάστε τα + και - των προτάσεων σας

Αυτό είναι, κατ εμέ, μια παγίδα στην οποία έπεσαν πολλοί χρήστες, μεταξύ τους και έμπειροι, στην αρχή του systemd. Στην αρχή του systemd, αυτό ήταν το κύριο επιχείρημα που ακολουθούσε η πλευρά του systemd (χωρίς φυσικά να κατηγορώ εσάς ότι ανήκετε σε αυτή την πλευρά). Το πρόβλημα όμως είναι ότι όταν επιχειρείς να αλλάξεις κάτι (είτε το παλιό είναι καλό είτε κακό), εσύ έχεις την ευθύνη της απόδειξης. Εσύ κάνεις ένα ισχυρισμό. Οι του systemd έπρεπε να αποδείξουν γιατί πρέπει να υιοθετηθεί, και τότε και μόνο τότε να αρχίσει να δοκιμάζεται και φυσικά μόνο σε "unstable" διανομές όπως rawhide, κτλ. Αυτό όμως δεν έγινε ποτέ. Αντίθετα, υιοθετήθηκε σε κανονικές διανομές με τους χρήστες να γίνουν άθελα τους alpha testers του systemd.

Και οποιοσδήποτε εξέφραζε γνώμη ενάντια στον systemd, έπαιρνε αυτή την απάντηση που δώσατε. "Γιατί πρέπει να κρατήσουμε το sysvinit;", "Επιχειρηματολόγησε γιατί θέλεις ξεχωριστό /usr (κάτι που έπαιζε για χρόνια και χάλασε για μια χαζομάρα και θα μπορούσε να φτιάξει σε dt αλλά από εγωϊσμό δεν παραδέχθηκαν ότι έκαναν λάθος σχεδιασμό στο udev);", κτλ.

Δεν λέω ότι δεν έχει καλά πράγματα ο systemd (πχ ο Asfodelus ανέφερε ότι μπορείς εύκολα να βρεις αυτό που θες λόγω του binary logging), να θυμίσω όμως ότι ο journald και όλα αυτά τα "καλά" υλοποιήθηκαν πολύ πιο μετά. Όταν ενσωματώθηκε σε διανομές, δεν προσέφερε τίποτα σε σχέση με τις εναλλακτικές και μετά είχαμε αυτή την ανήθικη / ανάποδη γραμμή επιχειρηματολογίας του στυλ "πες γιατί να μην ενσωματωθεί"

[mobinmob]

Μια ενδιαφέρουσα ιστορία για το tmux είναι πως οι devs του systemd πήγαν στο αποθετήριο του και έκαναν ένα pull request https://github.com/tmux/tmux/issues/428.

Αυτό δεν είναι PR, είναι issue... Δηλαδή δεν έδωσαν κώδικα, απλά ενημέρωσαν για την αλλαγή (μετά από bug reports) και πρότειναν το tmux να γράψει κώδικα για επικοινωνία με το dbus ή με το PAM. Μόνο πολύ αργότερα στο thread ενημερώνουν για το linger, αφού έχει προσπαθήσει να λύσει το πρόβλημα αλλιώς ο dev. Αυτό δεν είναι ακριβώς θετικό παράδειγμα για τον τρόπο με τον οποίο αλληλεπιδρά το systemd με το σύμπαν γύρω του.

- - - Updated - - -

Οι του systemd έπρεπε να αποδείξουν γιατί πρέπει να υιοθετηθεί, και τότε και μόνο τότε να αρχίσει να δοκιμάζεται και φυσικά μόνο σε "unstable" διανομές όπως rawhide, κτλ. Αυτό όμως δεν έγινε ποτέ. Αντίθετα, υιοθετήθηκε σε κανονικές διανομές με τους χρήστες να γίνουν άθελα τους alpha testers του systemd.

Έπρεπε, αλλά δεν ήταν αναγκαίο. Υπήρχαν και άλλοι τρόποι να προωθηθεί :P

- - - Updated - - -

Οπότε εδώ μπαίνει το .... διάβασμα . Θα πρέπει να μάθεις τους νέους τρόπους. Ίσως να το βρεις και ποιο εύκολο και να λες "βρε πως τα έκανα έτσι τόσο καιρό"

Είμαι σίγουρος πως το γνωρίζεις, απλά το αναφέρω για άλλους στο thread. Τα cgroups έχουν filesystem interface, δεν χρειάζεται να τρέχεις systemd για να τα χρησιμοποιήσεις. Είναι μεταξύ άλλων ο τρόπος που τα χρησιμοποιούν το openrc και τα σχετικά εργαλεία του nosh.

- - - Updated - - -

Off Topic

Off Topic
Σημείωση: ο λόγος σύγκρισης με το OpenBSD στο επίπεδο του documentation γίνεται γιατί με ~30 άτομα manpower βλέπω καλύτερο, σωστότερο και πιο user friendly documentation από μία εταιρία με πολύ μεγαλύτερο δυναμικό + το community που έχει από πίσω.

To OpenBSD FAQ και τα manpages του, όπως και το FreeBSD handbook είναι υποδείγματα documentation. Στο voidlinux γίνεται αντίστοιχη προσπάθεια με το handbook και χρησιμοποιούν τα ίδια εργαλεία για τις manpages

[Asfodelus]

Αυτό είναι, κατ εμέ, μια παγίδα στην οποία έπεσαν πολλοί χρήστες, μεταξύ τους και έμπειροι, στην αρχή του systemd.

Εγώ πάντως όπως και πολύ άλλοι έπεσα στην αντίθετη παγίδα

Κάποιος πριν ρώτησε αν το systemd το είχε γράψει η Microsoft τι θα άλλαζε; Να ρωτήσω και εγώ στο ίδιο στυλ :

* Αν το systemd δεν το έγραψε κάποιος που είχε γράψει το pulseaudio τι θα άλλαζε;

* Αν αυτός που το είχε γράψει, ζούσε σε καλύβα στο βουνό και έτρωγε βρούβες, αντί να δουλεύει σε μεγάλη εταιρεία τι θα άλλαζε;

Γιατί πρέπει να κρατήσουμε το sysvinit;

Έλα μου ντε! Αλήθεια όποιος το προτιμά απέναντι μιας οποιασδήποτε άλλης λύσης να πάει στο βουνό να τρώει βρούβες

Το πρόβλημα όμως είναι ότι όταν επιχειρείς να αλλάξεις κάτι (είτε το παλιό είναι καλό είτε κακό), εσύ έχεις την ευθύνη της απόδειξης. Εσύ κάνεις ένα ισχυρισμό.

Πολύ σωστά. Αλλά παραπέμπω στο https://lwn.net/Articles/385536/ . Θεωρώ πως η ανάγκη είχε τεκμηριωθεί επαρκώς.

Τώρα αν βιάστηκε να μπει στις διανομές: Μπορεί να κάνω λάθος και διορθώστε με, αλλά στο RedHat δεν βιάστηκε καθόλου να μπει. Έχει τα "κορόιδα" του Fedora για πειραματόζωα. Στο Arch όπως τεκμηρίωσε παραπάνω ο mobinmob μπήκε γιατί το βρήκαν ποιο εύκολο.

Εκεί που κρίθηκε το παιγνίδι ήταν στο Debian. Και το Debian είναι μια ιδιάζουσα διανομή μιας και θέλει να υποστηρίζει 45 επεξεργαστές και 62 πυρήνες. Εκεί έγινε ένα καλό debate. Συζητήθηκαν επι μακρόν τα καλά και τα κακά. Απο τότε άρχισα σιγά σιγά να αλλάζω γνώμη. Κατ αρχήν τα "πήρα στην κράνα" με το Devuan. Όχι προς θεού γιατί φτιάξανε την διανομή, αλλά γιατί δεν την έφτιαξαν νωρίτερα. Αν είσαι σε μια ομάδα με κοινούς στόχους και συζητάς, πρέπει και να αποδέχεσαι το αποτέλεσμα της συζήτησης. Αλλιώς, αν έχεις ήδη αποφασίσει, αποχωρείς και τραβάς τον δρόμο σου.

Και έχουμε την "κατάρα της τελευταίας έκδοσης" (rolling distro με ακούτε. ;Oχι το kde δεν βιάστηκε ποτέ να βγάλει μια τελευταία έκδοση που να ήταν ημιτελής. Ποτέ!! Το Gnome to ιδιο. Ποτέ !! Δεν θεωρώ πως υπήρξε κάποια βιασύνη στην υιοθέτηση του (άλλωστε ακόμα και σήμερα το συζητάμε) . Τουλάχιστον καμία παραπάνω από οποιονδήποτε γράφει κάτι καινούργιο και θέλει να το δει να χρησιμοποιείτε.

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

Τα cgroups έχουν filesystem interface, δεν χρειάζεται να τρέχεις systemd για να τα χρησιμοποιήσεις.

Τίποτα δεν έχει ανάγκη το systemd για να το χρησιμοποιήσεις! Δεν προσθέτει τίποτα στο τι μπορεί να κάνει ο πυρήνας. Απλά το κάνει εύκολο. Το έξυπνο στα cgroups θα ήταν να προσθέσεις κάποια εξάρτηση και να τα χρησιμοποιείς έμμεσα, ώστε να είσαι ασφαλής στις αλλαγές και να το κάνεις ευκολότερα. Και πάντα μπορείς να αντικαταστήσεις ενα bash script των 150 γραμμών με ένα των 250 γραμμών ;-)

Ας δούμε για παράδειγμα την ντιρεκτιβα "CPUAffinity=". Είναι χρήσιμη στο 0.1% των περιπτώσεων. Αλλά υπάρχει εκεί και είναι ορατή μπροστά μου. Μπορώ με μια γραμμή να το ενεργοποιήσω και να δω αν έχει νόημα σε κάποια περίπτωση. Αν δεν την είχα θα μπορούσα να το κάνω, αλλά θα ήθελε πολύ διάβασμα και δεν θα έμπαινα στον κόπο :P. Αυτό είναι το μεγάλο πλεονέκτημα κατ εμέ. Κάνει εύκολα προσβάσιμα όλα τα καλούδια του πυρήνα, που αλλιώς μπορεί να μην ήξερα καν πως υπάρχουν. (Ταυτόχρονα το κάνει δύσκολο να γίνει porting σε BSD, άλλο αυτό).

Το πρόβλημα όμως είναι ότι όταν επιχειρείς να αλλάξεις κάτι (είτε το παλιό είναι καλό είτε κακό), εσύ έχεις την ευθύνη της απόδειξης. Εσύ κάνεις ένα ισχυρισμό.

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

ΥΓ: Δεν είμαι τυφλός οπαδός καμίας λύσης. Αν και πρέπει να ομολογήσω πως σήμερα εδώ ακούγομαι έτσι :P. Όπως στο παρελθόν ήμουν ενάντια και σήμερα άλλαξα γνώμη, εξακολουθώ να επιτρέπω στον εαυτό μου το δικαίωμα να το πράξει ξανά στο μέλλον.