Μια (μη αντικειμενική) σύγκριση των init systems.

[anon54176929]

@konfou

Πράγματι. Από την άλλη το ίδιο δεν ισχύει και για τη πλειονότητα όσων ήταν ενάντια στα shell scripts προ το systemd;

Όχι ακριβώς. Τότε δεν έβλεπες τον κάθε τυχόντα να κάνει κατεβατά αναρτήσεων σε προσωπικές ή μη ιστοσελίδες εναντίον κάποιου init χωρίς καν να ξέρει πώς στο καλό δουλεύει αυτό, δεν είχες φαινόμενα «SysV-free» ας πούμε, δεν υπήρχαν διαμάχες μεταξύ οπαδών (όχι χρηστών) διανομών επειδή τύγχανε η μία να χρησιμοποιεί SysV-style init και η άλλη BSD-style scripts και γενικότερα δεν προσπαθούσε η μια πλευρά να αμαυρώσει την άλλη.

@konfou

Η διαφορά είναι πως δεν μπορείς να περάσεις τα dbus messages σε ένα text editor ή να χρησιμοποιήσεις ένα editor για να τα στείλεις ή να τα επεξεργαστείς γράφοντας σε sockets ή virtual filesystem.

Και τι είναι αυτό που σε υποχρεώνει να χρησιμοποιήσεις text editor; Κάποια συμπαντική τεχνολογική αλήθεια; Νομίζω ότι εδώ βρίσκεται μια ακόμα κακή έκφραση της «φιλοσοφίας του Unix». Δε μπορούν τα πάντα να γίνουν με τον οποιονδήποτε έναν και μοναδικό τρόπο και είναι άσχημο να περιορίζουμε τους ορίζοντές μας στον τρόπο αυτόν.

@konfou

Το έχει σαφή προσανατολισμό θεωρώ ισχύει ακόμη περισσότερο στο s6. Ένα init/supervisor και τέλος. Όπως και ότι χρησιμοποιεί υπάρχοντα συστατικά και προσπαθεί να βελτιστοποιήσει ό,τι γινόταν.

Βεβαίως, αν εννοείς ως προσανατολισμό του s6 το «να μην είναι systemd». Αλλιώς, σε καμία περίπτωση. Για παράδειγμα, το systemd είναι Linux-exclusive. Το «exclusive» εδώ δηλώνει ότι οι δημιουργοί του αποφάσισαν συνειδητά να μην υποστηρίζουν 156 διαφορετικούς πυρήνες αλλά να συνδεθούν στενά με έναν. Βρες μου μια αντίστοιχα στοχευμένη κίνηση του s6 για έναν τόσο σημαντικό παράγοντα. Και θα σε παρακαλέσω να μην κάνεις κακή εναλλαγή των εννοιών. Το init του systemd είναι απλά ένα init και τέλος και ένας supervisor δεν είναι init. Το έργο που ονομάζεται systemd είναι μια σουίτα λογισμικών η οποία περιλαμβάνει και το init αλλά δεν ταυτίζεται με αυτό.

Επίσης, εσύ ανέφερες ότι το s6 θα συνδεθεί με ένα frontend για το οποίο θα δημιουργηθεί μια νέα γλώσσα. Αυτό όχι απλά δεν είναι χρήση υπαρχόντων συστατικών αλλά είναι και διαμετρικά αντίθετο με αυτήν.

@konfou

Αυτό είναι καθαρά προσωπική σου άποψη και όχι γενική αλήθεια.

Σοβαρά τώρα; Όταν τόσο στο ευρύτερο ΕΛ/ΛΑΚ όσο και συγκεκριμένα στο Linux είχαμε και συνεχίζουμε να έχουμε ασταμάτητη αντιπαλότητα μεταξύ των δύο (ακραίων) πλευρών;

@konfou

Ξαναδές τα 2-4,6 αλλά με s6 αντί Linux. Γενικά αυτές οι προτάσεις είναι αρκετά γενικές.

Όχι απλά θα τα ξαναδώ, θα τα ξαναγράψω κιόλας:

• Το s6 δεν ήταν φιλοσοφικά (δε λέω ιδεολογικά) κινούμενο και όπου χρειάστηκε δε δίστασε να πάει κόντρα σε παλιότερες φιλοσοφίες ανάπτυξης κλπ. Φυσικά και είναι φιλοσοφικά κινούμενο και θεωρώ αστείο το να πιστεύει κάποιος ότι πάει κόντρα σε παλιότερες φιλοσοφίες ανάπτυξης όταν η φράση «follows the Unix philosophy (one job → one tool) as closely» βρίσκεται μόλις στη δεύτερη αράδα της σελίδας του s6-linux-init. Αν κάνει ο Bercot ποτέ κάποια δήλωση η οποία να έρχεται σε ευθεία αντίθεση με τους επίσης φιλοσοφικά κινούμενους συνεισφέροντες/χρήστες που έλκονται από το s6, να μου την παραθέσεις. Τα αντίστοιχα για τον Torvalds πιστεύω ότι τα γνωρίζεις.

• Το s6 είχε και αυτό πολέμιους ως προς τον τρόπο που έκανε πράγματα. Όπως; Έχεις δει εσύ κάποιον να κάνει «anti-s6» δημοσιεύσεις, για παράδειγμα; Μην ξεχνάς επίσης ότι η biased σύγκριση με την οποία άρχισε το παρόν νήμα έγινε από τον… δημιουργό του s6.

• Το s6 έχει ακόμα κάποια μειονεκτήματα έναντι άλλων λύσεων. Μιλάμε για ένα λογισμικό που ακόμα έχει ανολοκλήρωτα σημαντικά τμήματα, οπότε δεν υφίσταται καν σύγκριση. Αν θεωρήσουμε ότι η τελική εκδοχή του θα κάνει αυτά που αναφέρει ο δημιουργός του ότι θέλει, και πάλι θα έχει μειονεκτήματα έναντι ήδη υπαρχουσών λύσεων (εξ ου και ο Bercot αναγνωρίζει ότι κοίτα να δεις που το systemd κάνει και καλά πράγματα). Η ειδοποιός διαφορά με το Linux είναι ότι το s6 δεν πρόκειται ποτέ να «κατακτήσει» τον τομέα του αναπτύσσοντας πλεονεκτήματα που υπερκαλύπτουν τα μειονεκτήματά του.

• Το s6 δεν είναι η «απόλυτη» λύση σε κάθε τομέα όπου έχει εφαρμογή και σε κάποιους από αυτούς τους τομείς υστερεί. Είναι όμως η «καλύτερη» λύση overall από όσες υπάρχουν σήμερα. Ξανά, μιλάμε για ένα ανολοκλήρωτο έργο που οι τομείς εφαρμογής του αυτήν τη στιγμή είναι…; 2-3 niche διανομές; Επίσης, είναι λογικά αδύνατο μια λύση να είναι overall «καλύτερη» όταν σε πραγματικές συνθήκες δεν είναι καν ολοκληρωμένη και δεν έχει δοκιμαστεί ούτε στο μισό του εύρους τομέων εφαρμογής κάποιας άλλης.

Βλέπεις λοιπόν ότι οι προτάσεις δεν είναι και τόσο γενικές;

[konfou]

Όχι ακριβώς

Τι σχέση έχει αυτό που γράφεις με αυτό που απάντησα εγώ; Έγραψε κανένας που δεν του άρεσαν τα shell scripts κάποια εναλλακτική; Αυτό είπα.

Και θα σε παρακαλέσω να μην κάνεις κακή εναλλαγή των εννοιών

Εννοούσα το ένα και το άλλο (όπως συχνά λέγεται C/C++ ενώ είναι ξεκάθαρα διαφορετικές γλώσσες) όχι είναι εναλλασσόμενες έννοιες. Σωστή παρατήρηση.

Edit: Βέβαια σε ολόκληρο το thread μιλάμε στο πλαίσιο σύγκρισης με το systemd το οποίο ξεκίνησε με σκοπό την ενοποίηση αυτών των δύο (δες άρθρο Lennard που δόθηκε παραπάνω). Οπότε μάλλον άκυρη παρατήρηση.

Το έργο που ονομάζεται systemd είναι μια σουίτα λογισμικών η οποία περιλαμβάνει και το init αλλά δεν ταυτίζεται με αυτό

Νομίζω το έχω αναφέρει εκτενέστατα αυτό.

Και τι είναι αυτό που σε υποχρεώνει να χρησιμοποιήσεις text editor

Ότι είναι text μάλλον; Ή ότι όλα τα Unix εργαλεία μπορούν να διαβάσουν και να δουλέψουν με text; Επίσης όπως έγραψα “Δεν είναι το ίδιο αν και έχει πλεονεκτήματα.”

Επίσης, εσύ ανέφερες ότι το s6 θα συνδεθεί με ένα frontend για το οποίο θα δημιουργηθεί μια νέα γλώσσα

Τα έχεις μπερδέψει. Frontend είναι το interface με το οποίο δουλεύει ο χρήστης (π.χ. systemctl). Προφανώς κι αυτά θα είναι νέα εργαλεία. Η γλώσσα βρίσκεται στο κομμάτι το configuration (backend). Επίσης πρόσεξε το ό,τι γινόταν. Μια νέα γλώσσα μπορεί να εισαχθεί αλλά θα καλεί εργαλεία του συστήματος. Περαιτέρω νέα εργαλεία που θα εισάγει το s6 θα μπορούν να καλεσθούν έξω από τον ίδιο το manager. Τέλος θα ξανααναφέρω για άλλη μια φορά πως μια DSL δεν είναι άγνωστη στο κόσμου του Unix (δες awk).

Σοβαρά τώρα;

Για το τι; Κάνεις μια ψεύτικη σύγκριση (“Εκείνος που βάζει την τεχνολογία πάνω από την ιδεολογία θα τη θεωρήσει απόλυτα θετική”) που ξεκάθαρα τοποθετεί ένα πάνω από το άλλο για να προάγεις τη δικιά σου άποψη. Και ξαναλέω σύγκρινε *BSD (ολοκληρωμένο) με Linux διανομές (άθροισμα μερών που αποτελείται).

θεωρώ αστείο το να πιστεύει κάποιος ότι πάει κόντρα σε παλιότερες φιλοσοφίες ανάπτυξης

Συγκριτικά με systemd.

Έχεις δει εσύ κάποιον να κάνει «anti-s6» δημοσιεύσεις, για παράδειγμα

Ξαναδιάβασε αυτό το thread που έγραψες την απάντηση.

πάλι θα έχει μειονεκτήματα έναντι ήδη υπαρχουσών λύσεων

Ναι. Είναι ίδια πρόταση με αυτή που έγραψες.

Δεκτό ότι το 6 δεν ισχύει. Αναφερόμουν μόνο στο πρώτο κομμάτι πως δεν είναι απόλυτη λύση.

[anon54176929]

@konfou

Έγραψε κανένας που δεν του άρεσαν τα shell scripts κάποια εναλλακτική;

Πιθανότατα όχι, γιατί η εποχή και οι ανάγκες της ήταν εντελώς διαφορετικές, με συνέπεια να μην έχει προκύψει ακόμα το κενό «πέρα από τα shell scripts». Ο @Asfodelus όμως αναφέρθηκε σε κάτι που συμβαίνει σήμερα, δεν ανακάτεψε διαφορετικές εποχές.

@konfou

Σωστή παρατήρηση. […] Οπότε μάλλον άκυρη παρατήρηση.

Νόχι

@konfou

Ότι είναι text μάλλον; Ή ότι όλα τα Unix εργαλεία μπορούν να διαβάσουν και να δουλέψουν με text ; Επίσης όπως έγραψα “Δεν είναι το ίδιο αν και έχει πλεονεκτήματα.”

Υποθέτω (διόρθωσέ με αν λανθάνω) ότι έχεις παραμείνει στη «φιλοσοφία του Unix» και δεν κατάλαβες σωστά αυτό που έγραψε ο @Asfodelus παραπάνω. Η φράση του «Αν αντικαταστήσεις το “text streams” με “dbus messages” έχεις ακριβώς το ίδιο πράγμα, γνώμη μου.» αφορά το αποτέλεσμα, όχι τον τρόπο. Το αποτέλεσμα είναι η επικοινωνία και αυτή επιτυγχάνεται και στις δύο περιπτώσεις. Ο τρόπος διαφέρει. Αυτό κατάλαβα εγώ και ας μας το διευκρινίσει ο ίδιος.

Επίσης, οποιαδήποτε αναφορά στο Unix δεν είναι θέσφατο και η περίφημη «φιλοσοφία» του δε μπορούσε -προφανώς- να λάβει υπόψη της τις υπερπολύπλοκες ανάγκες των επόμενων δεκαετιών. Αυτό σημαίνει ότι έχει σημαντικά κενά, τα οποία επί του παρόντος καλύπτονται από πράγματα που δεν είναι Unix (ο πυρήνας Linux ας πούμε) ή δεν ακολουθούν απαρέγκλιτα τη «φιλοσοφία» αυτού. Ένα επιχείρημα της μορφής «το Χ είναι λάθος γιατί δεν είναι Unix/δεν ακολουθεί τη φιλοσοφία του Unix» είναι ένα κακό επιχείρημα σήμερα, τόσες δεκαετίες μετά.

@konfou

Frontend είναι το interface με το οποίο δουλεύει ο χρήστης […] μια DSL δεν είναι άγνωστη στο κόσμου του Unix (δες awk)

Τι ακριβώς έχω μπερδέψει; Μιλάς για κάτι διαφορετικό από το s6-frontend; Αν όχι, μπορεί αυτό να λειτουργήσει χωρίς το execline, για το οποίο απαιτείται αυτή η νέα γλώσσα; Κι αφού τέλος πάντων κάπου χρειάζεται μια νέα γλώσσα, πώς αυτό συνιστά χρήση υπαρχόντων εργαλείων;

Επίσης, δεν ξέρω γιατί κάνεις άκυρες αναφορές (το awk δεν είναι συστατικό με το οποίο χτίστηκε κάποιο σύστημα init, άρα άθελά σου παραβλέπεις το use case για χάρη της υποστήριξης προς τις DSL) αλλά ναι, θα συμφωνήσουμε ότι μια DSL δεν είναι άγνωστη και θα προσπεράσω και την αναφορά στο Unix που δεν έχει νόημα. Όμως, η συγκεκριμένη DSL που θα γραφτεί για το execline είναι εντελώς άγνωστη.

@konfou

Για το τι; Κάνεις μια ψεύτικη σύγκριση (“Εκείνος που βάζει την τεχνολογία πάνω από την ιδεολογία θα τη θεωρήσει απόλυτα θετική”) που ξεκάθαρα τοποθετεί ένα πάνω από το άλλο για να προάγεις τη δικιά σου άποψη. Και ξαναλέω σύγκρινε *BSD (ολοκληρωμένο) με Linux διανομές (άθροισμα μερών που αποτελείται).

Με δουλεύεις, δε μπορεί. Ισχυρίζεσαι δηλαδή ότι είτε δεν υπάρχει καμία διαμάχη μεταξύ ιδεολόγων και πραγματιστών στο ΕΛ/ΛΑΚ είτε αυτή δε βασίζεται στο δίπολο ιδεολογία-πραγματισμός; Και ενώ συζητάμε για ένα θέμα όπου οι σφοδρές αντιδράσεις έχουν προκύψει ξεκάθαρα για ιδεολογικούς λόγους; Και μάλιστα φτάνεις στο σημείο να κατηγορήσεις τον συνομιλητή σου ότι κάνει ψεύτικη σύγκριση για να προαγάγει την άποψή του. Τι να πω, ευχαριστώ για την προσβολή φίλτατε.

Δε μπορώ να συγκρίνω πράγματα αν δε μου δώσεις έναν παράγοντα σύγκρισης. Θέλεις το ιδεολογικό υπόβαθρο; Τις τεχνικές προσεγγίσεις; Κάτι άλλο; Αν έχει κάποια σημασία, να σου αναφέρω ότι προσωπικά θα ήθελα το integration των BSDs στο Linux (όχι απαραίτητα με τον ίδιο επακριβώς τρόπο) και έχω εκφραστεί πολλές φορές στο παρελθόν αρνητικά για την ανάπτυξη-σκορποχώρι που έχουμε στις διανομές.

@konfou

Συγκριτικά με systemd.

Το s6 πάει κόντρα σε παλιότερες φιλοσοφίες ανάπτυξης συγκριτικά με το systemd; Αυτό λες; Αν ναι, ελπίζω να μη χρειάζεται να σου εξηγήσω γιατί είναι λανθασμένη άποψη.

@konfou

Ξαναδιάβασε αυτό το thread που έγραψες την απάντηση.

Νομίζω ότι γράφω με σαφήνεια αλλά σε περίπτωση που παρερμήνευσες, χρησιμοποίησα τη λέξη «πολέμιους» (όχι «διαφωνούντες») και δεν αναφέρθηκα πουθενά σε τεχνικές διαφωνίες. Το «anti-s6» είναι κυριολεκτικό. Υπάρχει κάποια «s6-free» διανομή; Βλέπεις κάποια ιδιαίτερη αντίδραση προς αυτό που να παρεκκλίνει εντελώς από το τεχνικό σκέλος; Έχει δημιουργηθεί έστω ένας ιστότοπος από υποστηρικτές ή συνεισφέροντες σε κάποιο άλλο σύστημα init αποκλειστικά για την παραπληροφόρηση περί του s6; Μήπως είδες εδώ κάποιον που προτιμά άλλο init να διαδίδει ανακρίβειες για το s6;

@konfou

Ναι. Είναι ίδια πρόταση με αυτή που έγραψες.

Δεν είναι, γιατί την αποκόβεις και αγνοείς το σημαντικότατο στοιχείο ότι το Linux (ή το systemd, αν θέλεις να πάμε εκεί) αυτήν τη στιγμή επικρατεί και υπερνικά τον «ανταγωνισμό». Και σου ξαναλέω, το Linux έλυσε ένα πρόβλημα, δεν το διαχειρίστηκε απλά με άλλον τρόπο, όπως κάνει το s6 ή άλλα εναλλακτικά inits.

@konfou

Αναφερόμουν μόνο στο πρώτο κομμάτι πως δεν είναι απόλυτη λύση.

Ξανά, δεν υφίσταται σύγκριση μεταξύ ενός λογισμικού με δεκάδες (εκατοντάδες; χιλιάδες;) τομείς εφαρμογής και ενός άλλου που, επί του παρόντος, «δεν υπάρχει». Το Linux δεν είναι η απόλυτη λύση αλλά είναι η ιδανικότερη για αυτούς τους δεκάδες-εκατοντάδες-χιλιάδες τομείς στους οποίους χρησιμοποιείται. Αντίθετα, το s6 δεν έχει σπάσει καν το τσόφλι για να μπορούμε να πούμε οτιδήποτε.

[konfou]

@anon54176929

αφορά το αποτέλεσμα, όχι τον τρόπο

Α, οκ. Λοιπόν το θέμα με το text interface όπως το εξήγησα είναι πως δεν χρειάζεσαι να χρησιμοποιήσεις κάποιο ειδικό εργαλείο για να αλληλεπιδράσεις με κάποιο πρόγραμμα ή υπηρεσία. Π.χ. για να χρησιμοποιήσω dbus για να στείλω ένα notification χρειάζομαι ένα ειδικό εργαλείο (π.χ. notify-send) που μιλάει στη συγκεκριμένη υπηρεσία. Ενώ ένα text-based interface θα ήταν (θεωρητικό παράδειγμα, δεν πιστεύω πως υπάρχει υλοποίηση αν και μπορεί) να στείλω κείμενο (π.χ. echo “message” >) στο /sys/notify. Αυτό εννοείται όταν το Unix μιλάει για text streams. Συνεπώς τόσο ο τρόπος όσο και η αλληλεπίδραση διαφέρουν. Αυτή τη στιγμή το userland είναι ένα mix όπου όπου έχουμε τα διάφορα εργαλεία διαχείρισης του Linux όπως και τα /proc και /dev filesystems. Τώρα καθαρά σαν αποτέλεσμα θα είναι το ίδιο (θα έχεις ένα notification).

Αν όχι, μπορεί αυτό να λειτουργήσει χωρίς το execline

Αυτό ακριβώς λέω. Το θέμα είναι ότι χωρίς το execline χρησιμοποιείς απλά shell scripts οπότε πολύ πιθανό (χωρίς να γνωρίζω για OpenRC και BSD rc.d) να καταλήξεις στα προβλήματα προ δεκαετίας. Όσο για τα υπόλοιπα εργαλεία πιστεύω από τη δικιά σου χρήση στο Linux θα έχεις καταλάβει ότι το bash (ή όποιο shell χρησιμοποιείς) δεν στέκει μόνο του.

είναι εντελώς άγνωστη

Αυτό είναι το θέμα. Δεν είναι εντελώς άγνωστη. Είναι shell-like. Θες να μου πεις ότι αν έχεις χρησιμοποιήσει bash θα έχεις δυσκολία να χρησιμοποιήσεις csh; Μπορείς να το δοκιμάσεις μόνος σου. Πιστεύω πάνω από ένα απόγευμα δεν θα χρειαστείς. (Ή καλύτερα δοκίμασε fish που έχει και ωραίο interactive usage και μπορεί να σου αρέσει.)

δεν υπάρχει καμία διαμάχη μεταξύ ιδεολόγων και πραγματιστών στο ΕΛ/ΛΑΚ είτε αυτή δε βασίζεται στο δίπολο ιδεολογία-πραγματισμός

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

Το tight coupling ιδιαίτερα στο κώδικα δεν είναι απόλυτα θετικό. Δεν ξέρω γιατί το πιστεύεις. Ακόμα και στα BSD υπάρχει σαφής διαχωρισμός μεταξύ των διαφορετικών κομματιών. Στο NetBSD μάλιστα σε τέτοιο σημείο που μπορείς να τραβήξεις όλους τους drivers έξω (ψάξε rumpkernel). Το ίδιο ισχύει και για την αλληλεπίδραση (μπορείς να χρησιμοποιήσεις κομμάτια έξω από το πρόγραμμα κι ανεξάρτητα της ίδιας της σουίτας). Συνεπώς, ναι μπορείς να έχεις ένα integrated (όχι απαραίτητα καλό ή κακό) αναπτυσσόμενο και διαχειρίσιμο σύστημα (π.χ. BSD) αλλά δεν είναι απαραίτητο το tight coupling (π.χ. systemd) που αναφέρω.

Αν ναι, ελπίζω να μη χρειάζεται να σου εξηγήσω γιατί είναι λανθασμένη άποψη.

Θα ήθελα να μου πεις. Αλλά ξανά: το s6 συγκριτικά με το ίδιο το systemd. Αυτή τη στιγμή το s6 είναι το νέο (ο ανταγωνιστής) και το systemd το παλιό. Μπορεί να ξαναχρησιμοποιεί παλαιότερες ιδέες από αυτό ιδέες αλλά εδώ κάνουμε σύγκριση με το systemd.

Νομίζω ότι γράφω με σαφήνεια αλλά σε περίπτωση που παρερμήνευσες

Οκ, λάθος. Αλλά το ίδιο ίσχυε με το Linux εκτός και αν γνωρίζεις κάτι άλλο. Δεν υπήρχαν anti-Linux campaigns. Και η διαμάχη micro vs monolithic με τον Tanenbaum ήταν διαφωνία (debate).

Δεν είναι

Είναι. Συγκεκριμένα:

Το Linux έχει ακόμα κάποια μειονεκτήματα έναντι άλλων λύσεων

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

[anon54176929]

@konfou

Λοιπόν το θέμα με το text interface όπως το εξήγησα […] Τώρα καθαρά σαν αποτέλεσμα θα είναι το ίδιο (θα έχεις ένα notification).

Προφανώς γνωρίζω και συμφωνώ με ό,τι έγραψες. Το πρόβλημα εδώ είναι ότι υπάρχει αυτή η προσκόλληση στο text interface. Ως υλοποίηση, όπως και οποιαδήποτε άλλη υλοποίηση, δε μπορεί ποτέ να επαρκεί για κάθε τρόπο χρήσης. Το D-Bus είναι μια διαφορετική υλοποίηση που τυγχάνει να συγκεντρώνει κάποια αποδοχή και ενσωμάτωση από διανομές και άλλα λογισμικά.

Είναι το D-Bus «καλύτερη» ή «χειρότερη» λύση; Εξαρτάται από το use case. Έχει πλεονεκτήματα και μειονεκτήματα; Σαφέστατα. Έπαθαν ξαφνικά παράκρουση οι διανομές και τα λογισμικά που το χρησιμοποιούν έναντι του text interface; Δε νομίζω ότι πιστεύεις κάτι τέτοιο, όπως δε μου έχεις δώσει και κανένα δικαίωμα να σε θεωρώ βαρεμένο με αναφορές όπως «τα πήραν οι τάδε», «το επέβαλαν οι δείνα» κλπ. Συνεπώς, για να τύχει τέτοιας ευρείας αποδοχής, ίσως κάτι κάνει με προτιμότερο τρόπο από τις εναλλακτικές λύσεις.

@konfou

Αυτό είναι το θέμα. Δεν είναι εντελώς άγνωστη. Είναι shell-like. Θες να μου πεις ότι αν έχεις χρησιμοποιήσει bash θα έχεις δυσκολία να χρησιμοποιήσεις csh; Μπορείς να το δοκιμάσεις μόνος σου. Πιστεύω πάνω από ένα απόγευμα δεν θα χρειαστείς. (Ή καλύτερα δοκίμασε fish που έχει και ωραίο interactive usage και μπορεί να σου αρέσει.)

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

Προτιμώ το zsh αλλά το παράδειγμά σου θεωρώ ότι ενισχύει τη θέση μου. Δεν προέκυψε τυχαία ο όρος «bashisms» για παράδειγμα και φυσικά δεν είναι όλα τα shells πλήρως συμβατά μεταξύ τους. Ομοίως, αν ορίσω το zsh ως βασικό shell ολόκληρου του συστήματος θα έχω πολλά προβλήματα (εννοώ εδώ ότι η ίδια λύση επαρκεί για τις ανάγκες μου ως χρήστης αλλά είναι προβληματική σε μεγαλύτερο επίπεδο).

Στα πλαίσια της ενημέρωσης όμως, επειδή (αυτονόητα) δε γνωρίζω οτιδήποτε έχει γραφτεί για το execline, θα ήθελα -αν γνωρίζεις- να με παραπέμψεις σε κάποια πηγή όπου αναλύονται όσο το δυνατόν πιο αντικειμενικά τα μειονεκτήματα που παρουσιάζουν τα ήδη υπάρχοντα shells (ή DSLs) ώστε να κρίθηκαν ανεπαρκή για αυτό που θέλει να κάνει ο Bercot. Ειλικρινά θέλω να μάθω.

@konfou

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

Δε με προσέχεις και με στεναχωρείς. Στο ίδιο ακριβώς σχόλιο λέω «Εγώ προσωπικά είμαι στη μέση και πιστεύω ότι πρέπει να πασχίζουμε πάντα να επιτυγχάνουμε τον ιδανικό συνδυασμό των δύο και να μην είμαστε αρνητικά διακείμενοι by default σε κάποια από τις δύο πλευρές, ή να κατανοούμε πότε χρειάζεται η μία πλευρά να υπερβεί ελαφρώς την άλλη.».

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

@konfou

Θα ήθελα να μου πεις. Αλλά ξανά: το s6 συγκριτικά με το ίδιο το systemd. Αυτή τη στιγμή το s6 είναι το νέο (ο ανταγωνιστής) και το systemd το παλιό. Μπορεί να ξαναχρησιμοποιεί παλαιότερες ιδέες από αυτό ιδέες αλλά εδώ κάνουμε σύγκριση με το systemd.

Η φιλοσοφία του s6 ή του systemd δεν είναι αποκομμένες από τον κόσμο. Το παλιό στη συγκεκριμένη περίπτωση είναι η «φιλοσοφία του Unix», η συμβατότητα με το POSIX, το shell scripting κλπ. Το νέο ήταν το systemd, που συνειδητά απέρριψε αυτά τα δύο (αν και όχι ολοκληρωτικά). Και το s6 είναι το νεότερο ως έργο αλλά βασίζεται στην «απαρχαιωμένη» προσέγγιση του παρελθόντος.

@konfou

Οκ, λάθος. Αλλά το ίδιο ίσχυε με το Linux εκτός και αν γνωρίζεις κάτι άλλο. Δεν υπήρχαν anti-Linux campaigns. Και η διαμάχη micro vs monolithic με τον Tanenbaum ήταν διαφωνία (debate).

Υπήρξαν και υπάρχουν ακόμα, τόσο εντός όσο και εκτός του ΕΛ/ΛΑΚ. Απλά έτυχε οι περισσότερες από αυτές να καταλήξουν στο περιθώριο, αν και πολύ επίπονα. Το Linux πολεμήθηκε από Uniχάδες, BSDάδες, εν μέρει από το FSF, από εταιρείες ιδιοταγών λογισμικών και άλλους.

@konfou

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

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

[konfou]

@anon54176929

όσο το δυνατόν πιο αντικειμενικά

Η μόνη σύγκριση που υπάρχει είναι αυτή του Bercot στη σελίδα του (συγκεκριμένα execline: why execline and not sh) και δεν θα την έλεγα αντικειμενική. Βασικά δεν θα την έλεγα καν σύγκριση. Το χειρότερο είναι πως δεν υπάρχει κανένα παράδειγμα σε ολόκληρη τη σελίδα, όχι για δημιουργία υπηρεσιών αλλά απλή χρήση, οπότε μάλλον ισχύουν αυτά που είπατε εσύ και ο @Asfodelus πως δεν τον ενδιαφέρει συνεργασία και το κάνει γιατί μπορεί να το κάνει.

Επίσης μάλλον πρέπει να αναιρέσω κάποια από αυτά που είπα γιατί δεν μου φαίνεται για γλώσσα ειδικού τομέα (DSL) αλλά απλά για μια διαφορετική shell γλώσσα που ναι μεν έχει κάποιους περιορισμούς (που λογικά, αλλιώς δεν έχει νόημα, θα ελαττώνει τα bugs) αλλά δεν είναι σχεδιασμένη ειδικά γι´ αυτό το σκοπό. Συνεπώς πιθανώς πράγματι καταλήγουμε στο πρόβλημα shell scripting. Χωρίς να είμαι σίγουρος λόγο έλλειψης docs. Βασικά θα πάρω πάντοτε τη λύση με τα πιο ολοκληρωμένο docs παρά αυτή που είναι κάπως καλύτερα τεχνικά. Θέλω πάντως να δω πως θα λειτουργήσει το unit-like file format, αν και με τους ρυθμούς ανάπτυξης δεν το βλέπω σύντομα (ή ποτέ).

Θα παραμείνω στη θέση όμως πως αν ήταν όπως τη παρουσίασα (συνδυασμός των δύο μεθόδων) μου φαίνεται καλή ιδέα (για τους λόγους που έχω αναλύσει) και πιστεύω το Shepherd το καταφέρνει (δες GNU Shepherd user services — 2020 — Blog — GNU Guix). Βέβαια μπορεί απλά να μεροληπτώ επειδή μου αρέσει ολόκληρο το σύστημα και Lisp διάλεκτοι. Επίσης μου αρέσει η ιδέα (χωρίς να το θεωρώ απόλυτα αναγκαίο εφόσον εκτός από systemd δεν ισχύει ούτε για το Shepherd) να υπάρχει διαχωρισμός σε εργαλεία όσο φυσικά δεν επηρεάζει τη παραγωγικότητα.

Κατακλείδα: μένει να δούμε πως θα πάει. Ειδικά τώρα που υποτίθεται έχει κάποιο χρονικό περιθώρια για να παραδώσει ένα έργο στο Alpine.

[Asfodelus]

@konfou Το φόρουμ είναι ανοικτό και θέλει μια παρουσίαση του Shepherd και γιατί όχι κάποιον οδηγό. Ψήνεσαι να μας το παρουσιάσεις; Και ίσως να είναι και ο καλύτερος τρόπος για να το κατανοήσεις εσύ καλύτερα. Kαι γιατί όχι και το guix;

[konfou]

Το θέμα δεν είναι να κάνω οδηγό για το Shepherd αλλά ότι αυτό τρέχει σε μια διανομή που είναι ριζικά διαφορετική από οποιαδήποτε άλλη και συνεπώς χρειάζεται πολύ καλές βάσεις για να χρησιμοποιηθεί αν και η εγκατάσταση είναι τετριμμένη. Βασικά μιλάμε για αρκετά niche κοινό. Επίσης είμαι Nix club παρά Guix.