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

Πολλά ακούγονται για τα διάφορα εναλλακτικά inits Αλλά κανένας από όσους εναντιώνονται στο systemd δεν μπήκε στον κόπο να μας πει που υστερούν και που υπερτερούν. Ο Laurent Bercot, γνωστός και σαν Ska ή skarnet κάνει επιτέλους μια σύγκριση. Σαν τον δημιουργό του s6 [1] η γνώμη του μετράει, αλλά δεν μπορεί να χαρακτηριστεί προφανώς αντικειμενική. Επίσης δεν πρέπει να ξεχνάμε πως κάθε σύστημα έχει και τον δικό του σχεδιασμό, στόχους και χρήσεις.

[1] Ένα ενδιαφέρον εναλλακτικό init system που έχει υιοθετηθεί από 2 μικρές διανομές. Στο παρόν φόρουμ θα βρείτε αναλυτική παρουσίαση του

Ελπίζω να αποτελέσει επιτέλους μια βάση για κάποιο σωστό διάλογο, χωρίς ανοησίες του στυλ μας παρακολουθεί η NASA. Με μια ελπίδα ζει κανείς :grinning: :grinning: :grinning:

Requirement OpenRC systemd s6-rc 0.5.2.1
Extremely reliable? :-1: Not really. OpenRC’s code paths are more convoluted than they need to be. :-1: :-1: No. systemd is known for its complexity and unpredictability. :+1: Yes. s6-rc is as simple and straightforward as a service manager can be.[/color]
Lightweight? Reasonably. OpenRC consumes a little more resources than would strictly be needed. :-1: :-1:No. systemd uses way too many resources for system infrastructure software. :+1: Yes. s6-rc was designed to be as lightweight as possible.
Easy to bootstrap? :+1: Yes. OpenRC is C and shell. Yes. systemd is C. However, it only supports the GNU libc, which may be a problem for musl-based distributions. :+1: Yes. s6-rc is C.
Reproducible service environment? :-1::-1: No. OpenRC starts services as scions of the openrc or service command. :+1: Yes. systemd always spawns the services from pid 1. :+1: Yes. s6-rc always spawns the services from its supervision tree.
Working with a supervision system? :-1:Not really. OpenRC can spawn rudimentary supervisors for its daemons, but the supervisors are not supervised themselves and offer few benefits. :+1: Yes. systemd provides process supervision itself. :+1: Yes. s6-rc works with the s6 process supervision system.
Guarantees system bootability? :-1: :-1: No. A configuration change can make the system unbootable. :-1: :-1: No. A configuration change can make the system fail to boot — or even to shut down. :+1: Yes. If a configuration applies successfully, the system will boot.
Parallel? :-1: Not really. OpenRC has a parallel mode that has never worked properly and is actively discouraged by its developers. :+1: Yes, and too much: systemd cheats and ignores some dependencies in order to start services faster. It impacts its reliability and predictability. :+1: Yes. s6-rc starts services exactly when it’s safe to do so.
Supports readiness notification? :-1::-1: No. OpenRC’s startup sequence is full of race conditions. Yes, via the sd_notify protocol. :+1: Yes, via the s6 notification protocol.
Interfaces with external events? :-1::-1: No, which is a main reason why Alpine aims to replace it. systemd supports dynamic events internally, and provides its own network manager, but does not interface with other software. :-1: :-1: No. The 0.5.2.1 version of s6-rc uses a static service database and does not accommodate external events.
Declarative service files? Simple services can be configured purely declaratively. For complex cases, code snippets are still needed. :+1::+1:The unit files are as declarative as can be. :-1::-1:Service configuration files are scripts, no syntactic sugar is provided to the user.
Usable in containers? In theory yes, but OpenRC embeds a lot of policy that makes it difficult to adapt and more of an annoyance than the benefit is worth. :-1:As with everything systemd, the features are there, as long as you fully opt into the model; here, the host has to run systemd. Plus, systemd does not support musl, and is too big to be a good fit for containers. :+1: s6-rc is small and separates mechanism from policy, so it’s possible to write container-specific service sets.

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

Προσωπική γνώμη

Επιτέλους κάποια σοβαρότητα από κάποιον που δεν γουστάρει το systemd γιατί από την σοβαρότητα κάποιων υποστηρικτών και διανομών, χορτάσαμε, ευχαριστώ :grinning: Αν θέλεις να αντικαταστήσεις κάτι θα πρέπει πρώτα να γνωρίζεις τι κάνει καλά ο ανταγωνιστής σου και τι κάνει λάθος. Και να κάνεις κάτι καλύτερο, αν τα καταφέρεις. Όχι να είσαι απλά “αντί”…

Η σύγκριση γίνετε μόνο στο systemd-init και το systemd κάνει πολύ περισσότερα, αλλά ας μείνουμε στο init κομμάτι μόνο. Δεν συμφωνώ καθόλου με τις δυο πρώτες θέσεις. Την δεύτερη την κατανοώ λιγάκι, μιας και το κείμενο έχει γραφτεί για τις ανάγκες του Alpine Linux που δεν είναι μια διανομή γενικής χρήσης. Η διανομή χρησιμοποιεί την musl οπότε δεν έχει κανένα νόημα η θέση 3. Στην πραγματικότητα, για “πολιτικούς” λόγους το θεωρώ πλεονέκτημα. Είμαι υπέρ του GPL και η musl δεν είναι. Αλά η σοβαρή ερώτηση είναι: “Τι δεν υποστηρίζει η musl και δεν μπορεί να τρέξει το systemd;” Μάλλον κάποια χαρακτηριστικά ασφάλειας του πυρήνα, και άρα δεν κάνει πλήρη χρήση των δυνατοτήτων του. Επίσης δεν αναφέρει καν την λέξη cgroup στο κείμενο…

Την θέση “Guarantees system bootability? " δεν την κατάλαβα καθόλου. " If a configuration applies successfully, the system will boot.” Μα το θέμα είναι στην αντίθετη περίπτωση… Επίσης δεν κατάλαβα το “Interfaces with external events?” την στιγμή που κάνει χρήση του D-Bus.

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

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

Διαβάστε

  • H πηγή του πίνακα: skarnet.com: projects
  • Για το Alpine Linux και γιατί χρειάζεται κάτι σαν το systemd:

Ρε με τι ασχολουμαστε εξαιτιας του γνωστου τρολ :slight_smile:
Κοιτα να δεις , προσωπικα δεν με ενδιαφερει πως λεγεται το init system της διανομης. Αυτο που θελω ειναι να κανει σωστα την δουλεια του. Και για το κλασικο “το systemd κανει πολλα περισσοτερα απο οσα πρεπει” , θα απαντησω το κλασικο “αν τα κανει σωστα , ας τα κανει”.

Απο την αλλη , υπαρχει και το εξης. Το systemd προωθειται πολυ απο redhat/fedora , που προωθουν το gnome , που πλεον gnome και systemd εχουν γινει κωλος και βρακι.
Αυτο σημαινει οτι θα εξελιχθει πολυ πιο γρηγορα/σωστα/ευκολα σε σχεση με αλλα σχετικα παρατημενα init systems.
Λογω της καταστασης αυτης , ολες οι εφαρμογες που στηριζουν την λειτουργια τους σε services , ερχονται με systemd services. Dropbox , teamviewer , vm tools , κλπ κλπ ερχονται με systemd services. Αν εισαι σε διανομη με αλλο init system απλα ατυχησες , θα πρεπει να ψαξεις αν καποιος κυκλοφορησε καποιο systemd service για την εφαρμογη που θες ή να κατσεις μονος σου να μετατρεψεις το systemd service σε service για το init system της διανομης σου… χαιρετα μας τον πλατανο δηλ.

Τελος τα επιχειρηματα περι ταχυτητας ειναι ανυποστατα. Εχω πολλες εγκαταστασεις διαφορων διανομων με διαφορα DEs και systemd και ολες μπουταρουν κατω απο τα 10 secs.
Τελευταια σε ενα χρεπολαπτοπ (με φτηνιαρικο ssd) , εγκατεστησα archlinux/xfce/systemd και το boot γινεται σε 5-6 secs. Πρωτη φορα στην ζωη μου χρειαστηκα να κανω εξτρα ρυθμισεις στο lightdm που ξεκινουσε τοσο γρηγορα (οπως και το υπολοιπο συστημα δηλ) που οι gpu drivers δεν ηταν “ετοιμοι” και το lightdm fail-αρε…
Aρα μεταξυ init systems που μπουταρουν σχετικα το ιδιο γρηγορα , θα προτιμησω το πιο πληρες.

Να κλεισω με αυτο που λεω παντα , αν το systemd καποια στιγμη κριθει ανεπαρκες , λαθος , τρυπιο ή οτιδηποτε , η κοινοτητα θα φτιαξει κατι αλλο … προσωπικα με εχει βολεψει πολυ το systemd , εχει λογικη στις διεργασιες , στις ονομασιες και στην λειτουργια του.

2 «Μου αρέσει»

Είναι εμφανείς οι προκαταλήψεις του Bercot στο κείμενό του και ορισμένες αναφορές λιγότερο ή περισσότερο ανακριβείς.

Το αστείο όμως είναι ότι ένας από τους “αγίους” των “anti-systemd” πιστών παραδέχεται εμμέσως πλην σαφώς ότι το systemd έχει και καλά στοιχεία που αξίζει να αντιγραφούν.

Περιμένω σε λίγα χρόνια να δημιουργηθεί το s1000 init που θα κάνει ακριβώς ό,τι και το systemd σήμερα. Άλλωστε, η σπατάλη πόρων χωρίς πραγματική ουσία είναι ίδιον κάποιων πτυχών του ΕΛ/ΛΑΚ. Αλλά θα έχει πλάκα να διαβάζουμε τα “επιχειρήματα” κάποιων τότε.

1 «Μου αρέσει»

extremely reliable
service configuration files are scripts

Δυσκολεύομαι να πω την αλήθεια να δω πως αυτά τα δύο ισχύον ταυτόγχρονα.

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

@Soulrain

Ναι, φαίνεται κάπως biased. Ψάχνοντας το λίγο, δεν είναι απαραίτητο να χρησιμοποιούνται shell scripts (όπως νόμιζα) αλλά κι άλλες γλώσσες (Perl, κτλ) ενώ σου δίνει και το execlineb που υλοποιεί μια DSL ειδικά για δημιουργία υπηρεσιών. Αυτό ίσως απλοποιεί αρκετά τη χρήση ενώ διατηρεί το πλεονέκτημα πως είναι πιο ευέλικτο σε σχέση με unit services.

Το πιο σημαντικό πρόβλημα του όμως είναι πως δεν έχει κάποιο frontend έτοιμο αλλά είναι υπό ανάπτυξη[0]. Πιστεύω όταν (και αν) ολοκληρωθεί μαζί με το file format (unit-like) που θα χτίζεται πάνω σε scripts θα είναι καλή εναλλακτική στο κομμάτι του init και service supervision (αφού το sytemd τώρα εμπεριέχει και boot manager, DNS resolver, network config, …).

@Asfodelus

Στο παρακάτω λινκ

https://forums.gentoo.org/viewtopic-t-1105854.html

λέει πως θα μπορούσε το cgroups να χρησιμοποιηθεί στον s6. Βασικά η ιδέα είναι φτιάχνεις ένα cgroup-based babysitter πρόγραμμα που κάνει wrap κάποια υπηρεσία. Ο σύνδεσμος που δίνει για παράδειγμα δυστυχώς δεν δουλεύει.

Ο συγγραφέας είναι υπέρ των “Declarative service files” και θεωρεί την έλλειψη τους μειονέκτημα. Μια δηλωτική προσέγγιση (Prolog, Makefiles, systemd) που το σύστημα πρέπει να βρει τι θα κάνει και όχι το πως έχει πλεονεκτήματα και κάνει το σύστημα ευκολότερο.

Και όπου η προσέγγιση αυτή αποτυγχάνει ή γίνετε πολύπλοκη μπορείς πάντα να καταφύγεις σε ένα κλασικό script, αυτό που καλεί την υπηρεσία. Σε κάθε σύστημα εκκίνησης η υπηρεσία μπορεί να είναι ένα εκτελέσιμο ή κάποιο script. Και αυτό μπορεί να είναι σε οποιαδήποτε γλώσσα: bash, python, ruby, perl, tcl, …

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

Αλλά το πλεονέκτημα είναι αυτό: Ένας τρόπος είναι να μάθεις 20 εργαλεία το καθένα με διαφορετική σύνταξη και ένα ακόμα depedency για να κάνεις ένα hardening. Το script απο 100 γραμμές θα γίνει 200 και ελάχιστοι θα μπορούν να το καταλάβουν. Η άλλη περίπτωση είναι έχεις διαθέσιμα ότι χρειάζεσαι και να γράψεις κάποιες δηλώσεις

Για παράδειγμα σε ένα service που υπάρχει στον υπολογιστή μου

[Service]
Type=oneshot
Environment="BORG_RELOCATED_REPO_ACCESS_IS_OK=yes"

# Security settings for systemd running as root, optional but recommended to improve security. You
# can disable individual settings if they cause problems for your use case. For more details, see
# the systemd manual: https://www.freedesktop.org/software/systemd/man/systemd.exec.html
LockPersonality=true
# Certain borgmatic features like Healthchecks integration need MemoryDenyWriteExecute to be off.
# But you can try setting it to "yes" for improved security if you don't use those features.
MemoryDenyWriteExecute=no
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
# Restrict write access
# Change to 'ProtectSystem=strict' and uncomment 'ProtectHome' to make the whole file
# system read-only be default and uncomment 'ReadWritePaths' for the required write access.
# Add local repositroy paths to the list of 'ReadWritePaths' like '-/mnt/my_backup_drive'.
ProtectSystem=full
# ProtectHome=read-only
# ReadWritePaths=-/root/.config/borg -/root/.cache/borg -/root/.borgmatic

CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_RAW

# Lower CPU and I/O priority.
Nice=19
CPUSchedulingPolicy=batch
IOSchedulingClass=best-effort
IOSchedulingPriority=7
IOWeight=100

Μπορεί η υπηρεσία να τρέξει χωρίς όλα αυτά; Μάλλον ναι. με την ίδια ασφάλεια; Όχι. Καταλαβαίνεις τι κάνουν; Ίσως να κάνεις μια μαντεψία σε μερικά (χωρίς να διαβάσεις το documentation) και μάλλον θα είσαι κοντά στην αλήθεια. Μπορείς να τα κάνεις χωρίς το SystemD; Προφανώς ΝΑΙ. Δεν μπορεί μια υπηρεσία συστήματος να κάνει κάτι που δεν μπορεί να κάνει ο πυρήνας και το hardware.

Αλλά μπορείς ΕΣΥ να το κάνεις; Δεν ξέρω για σένα, αλλά εμένα θα μου έπαιρνε ώρες διαβάσματος και πειραματισμού και θα έφτιαχνα ένα τεράστιο script.

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

(*) Το δεν έχουν σχέση υπό την τεχνική έννοια. Το systmed δεν είναι ένας init manager είναι ένας system manager υπο την ίδια ένοια ότι το gnome δεν έιναι ένας διαχειρηστής παραθύρων, αλλά ένα desktop environment

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

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

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

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


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

O σοφός λαός λέει “ακόμα δεν τον είδαμε Γιάννη τον βαπτίσαμε”. Η κατάσταση αυτή την στιγμή έχει ως εξής: το Alpine βγήκε στην ζητιανιά για να μπορέσει να πληρώσει ένα developer για ένα χρόνο να το φτιάξει. Ας πούμε πως το καταφέρνει, γιατί όλοι ξέρουμε πως όταν ένας developer λέει ένα χρόνο, θα το έχει τελειώσει σε ένα χρόνο :grin:

Αλλά όπως μας έχει μάθει και ο Fred Brooks στο The Mythical Man-Month - Wikipedia από ένα πρόγραμμα που τρέχει, να το μετατρέψεις σε μια υπηρεσία θέλεις 10πλάσια προσπάθεια. Θέλεις ένα καλό documentation και ο Bercot δεν έχει καταφέρει να γράψει ποτέ κάτι καλό, θέλει test, θέλει να διορθώσεις τα ατελείωτα λάθη όταν ο κόσμος αρχίσει να το χρησιμοποιεί σε σενάρια που δεν έχουν προβλεφθεί και ελεγχθεί. Δεν είναι μια δουλεία για ένα άτομο, που και στην τελική δεν ξέρεις αν θα συνεχίσει και να είναι διαθέσιμος.

Αν τα καταφέρει και παραδώσει στο Alpine αυτό που υποσχέθηκε και το Alpine αποφασίσει να το ενσωματώσει, θα έχει κάποια χρήση, αλλά η Alpine είναι μια διανομή ειδικού σκοπού. Είναι προσανατολισμένη σε containers, όπου έτσι και αλλιώς υπάρχουν μικρότερες ανάγκες και το κυριότερο ποιο προβλέψιμα configurations. Ο κόσμος του desktop που μας ενδιαφέρει είναι πολύ ποιο πολύπλοκος.

Δεν τα λέω αυτά αρνητικά, απλά έτσι έχει η κατάσταση και μακάρι να τα καταφέρει. Και αν κάποια στιγμή προκύψει κάτι καλύτερο απο το systemd προκύψει και αποδείξει την αξία του, οι σοβαρές (*) διανομές θα το εξετάσουν και ίσως και να το χρησιμοποιήσουν. Τα λογισμικά δεν είναι φετίχ και κάθε διανομή θέλει να χρησιμοποιήσει το καλύτερο για το use case της.

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

Η διαφορά βρίσκεται τόσο στη φιλοσοφία όσο και στην υλοποίηση. Ενώ το
systemd (μιλώντας για το init και services supervisor εδώ) είναι μια
γιγάντια βάση κώδικα για να διαβάζει και να εκτελεί τα service files,
στο s6 (και τα υπόλοιπα inits που συνήθως αναφέρονται μ´ εξαίρεση το
upstart) τα ίδια τα service files είναι κώδικας. Πέρα της ευελιξίας που
ανέφερα (καλό), αυτό ελαχιστοποιεί και τα πιθανά bugs στον ίδιο το
manager (καλό) αφού τα μεταφέρει στα scripts (κακό). Το οποίο γίνεται
πρόβλημα όταν λάβει κάποιος υπόψιν, αυτό που είπες, ότι δεν είναι ποια
απλά αρχεία με δηλώσεις (κακό). Γι΄ αυτό αν η DSL, που μπορεί απλά να
είναι embedded σε κάποια υπάρχουσα γλώσσα, σχεδιαστεί κατάλληλα είναι
δυνατό να έχεις ένα συνδυασμό των πλεονεκτημάτων (ευελπιστώντας χωρίς
των μειονεκτημάτων) των δύο μεθόδων. Και εδώ να αναφέρω το Shepherd που
τρέχει στο GNU Guix System που βασικά είναι το ακριβώς προηγούμενο, με
τα unit service files να είναι κώδικας γραμμένος σε Guile
(Scheme). Βασικά ο Shepherd έχει τα χαρακτηριστικά του systemd init συν
την αμεσότητα κι ευελιξία μιας (very) high-level γλώσσας
προγραμματισμού.

Ναι, αυτό είναι ένα κομμάτι που οι περισσότερες συζητήσεις εναλλακτικών
παραβλέπουν, αν και βρίσκεται στο όνομα του project. Ο συνδυασμός
βασικών (όχι απαραίτητα αναγκαίων) για ένα σύγχρονο σύστημα εργαλείων σε
μια σουίτα είναι αρκετά βολικός και απλοποιεί τη διαχείριση αυτού. Τώρα
αν αντί για systemd κάποιος χρησιμοποιήσει κάποια των εναλλακτικών init
θα χρειαστεί και εναλλακτικές για τα υπόλοιπα εργαλεία. Ακόμη και σε
Guix, αν και το configuration γίνεται μέα σε ένα ενιαίο περιβάλλον, ad
hoc χρήση παραμένει ζήτημα γιατί έχει να κάνει με τα frontends των
διαφορετικών εργαλείων.

@Soulrain

Πώς την απλοποιεί
ολλά από τα οποία ήταν μεγάλα σε μέγεθος και πολύπλοκα

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

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

Σωστός προβληματισμός. Το σκέφτηκα κι εγώ. Αλλά από την άλλη το frontend
του systemd (systemctl) δεν έχει αλλάξει σημαντικά (καθόλου?) τη
τελευταία δεκαετία.

1 «Μου αρέσει»

Η καρδία του systemd και αυτό που μου αρέσει είναι τα API και οι προδιαγραφές. Ανεξάρτητα του τι πρόγραμμα ρυθμίζει το δίκτυο, αν χρησιμοποιεί τα συγκεκριμένα API, θα μπορέσεις να το ρυθμίσεις με ένα γραφικό τρόπο, θα μπορέσεις να πάρεις πληροφορίες με ένα τυποποιημένο τρόπο, αντί να ανοίγεις ένα subshell να τρέχεις ένα ip/ifconfig και να κάνεις parse την πληροφορία.

Μια DSL δεν είναι πανάκεια και είναι μια λιγότερο καθαρή λύση. Και έχεις επιπλέον τα λάθη της ίδιας της υλοποιήσης του DSL. Σε κάποιες γλώσσες (Ruby, Lisp) μπορεί να είναι δυνατά και να θυμίζουν περισσότερο αρχείο ρυθμίσεων παρά πρόγραμμα, αλλά σε κάποιες άλλες απλά θα είναι κλήσεις συναρτήσεων.

Πάντα μια ποιο απλή προσέγγιση είναι να κάνεις όσα μπορείς με δηλώσεις και για το 0.1% που δεν μπορείς να καταφεύγεις σε script. Τώρα το “είναι μια γιγάντια βάση κώδικα που διαβάζει και εκτελεί τα service files” απο που προκύπτει ακριβώς; Το δέντρο των εξαρτήσεων είναι ένα spanning tree κάτι αλγοριθμικά απλό που δεν το κάνει καν, οι εξαρτήσεις είναι στην δομή του δίσκου. Στο ότι περιέχει κώδικα για να θέσει πχ το ionice και το nice; Αυτός ο κώδικάς είναι απλός και αν θέλεις αυτή την εργασία θα τον έχεις έτσι και αλλιώς σε εξωτερικό πρόγραμμα. Και αν έχεις 10 τέτοια διαφορετικά απο 10 διαφορετικά άτομα και περισσότερο κώδικα θα έχεις και μεγαλύτερη επιφάνεια επίθεσης και περισσότερες ευπάθειες.

Όσο για τον χώρο που καταλαμβάνει στην μνήμη δεν είναι κάποια ένδειξη. Δεν θυμάμαι αν είναι το 40% ή το 60% του χώρου που δεν είναι κώδικας, άλλα κείμενο για να μπορέσει να δώσει κατανοητά μηνύματα σφάλματος. Ας πούμε πως τα βγάζουμε αυτά και μειώνουμε την μνήμη στο μισό και έχουμε μηνύματα της μορφής ‘Error 404’ . Πιό το όφελος; Θα το θέλαμε ;

ΥΓ: Έχεις δοκιμάσει καθόλου το Shepherd; Μου αρέσουν πολύ οι LISP-like γλώσσες και θα ήθελα να ακούσω μια γνώμη

Εκτός και αν μου ξέφυγε, δεν αναφέρεται κάπου ότι το execlineb θα λειτουργεί αποκλειστικά με αυτην την ειδικά σχεδιασμένη γλώσσα.

Σε κάθε περίπτωση όμως, και μόνο αυτό το «ειδικά σχεδιασμένη γλώσσα» είναι αρνητικό σε πρώτη φάση. Γιατί; Γιατί καλεί κάθε ενδιαφερόμενο προγραμματιστή να αγνοήσει τις γνώσεις και την εμπειρία που έχει αποκτήσει σε άλλες γλώσσες οι οποίες χρησιμοποιούνται ευρύτατα και να μάθει κάτι νέο απ’ το μηδέν, το οποίο μάλιστα θα είναι και «νεογνό» ως έργο. Αυτό αμέσως-αμέσως θα στερήσει συνεισφορές.

Το frontend μπορεί να μην έχει αλλάξει (γιατί δε χρειάζεται, ίσως), έχει αλλάξει όμως σημαντικά το backend. Στην περίπτωση του s6 και του θέματος που συζητάμε, δεν υπάρχει καν frontend ενώ και το backend δεν είναι ολοκληρωμένο. Μην ξεχνάς ότι το systemd αναπτυσσόταν για αρκετά χρόνια πριν τύχει ευρείας αποδοχής.

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

@Asfodelus

Μια DSL δεν είναι πανάκεια

Συμφωνώ. Τίποτα δεν είναι.

είναι μια λιγότερο καθαρή λύση

Διαφωνώ. Ειδικά παίρνοντας υπόψιν το σύνδεσμο παραπάνω για το systemd.exec. Με ένα grep βρίσκω συνολικά 130 terms με το καθένα να έχει 100~300 λέξεις εξήγηση. Αλλά ο όγκος πληροφορίας δεν είναι το πρόβλημα. Τσεκάροντας στο Archive[0], 5 χρόνια πριν υπήρχαν μόλις 70 terms. Συμπέρασμα είναι πως προστίθενται συνεχώς νέα terms για ζητήματα που δεν είχαν προβλέψει το οποίο μεταφράζεται ως επιπλέον κώδικας (read: bugs). Και το ερώτημα εδώ είναι: πόσα από αυτά έχουν overlap στη λειτουργία τους; Ανάλογα την απάντηση μπορούμε να δούμε τι ισχύει. Όμως ποιος θα διαβάσει μια νοβέλα documentation;

Διάλεκτοι Lisp, Lua και κάποιες άλλες, είναι γλώσσες προγραμματισμού που μπορούν να χρησιμοποιηθούν (χρησιμοποιούνται βασικά) ως configuration γλώσσες (data). Το θέμα είναι ότι άμα δώσεις άπειρες δυνατότητες μπορεί να καταλήξεις με ένα χάος. Οπότε το σχέδιο είναι πως παροτρύνεις τη χρήση ενός μέρους (που δίνεται ή φτιάχνεις) της γλώσσας (embedded DSL).

Είχα δοκιμάσει το GuixSD σε VM αλλά δεν έκανα κάτι τρομερό με τα Shepherd service files. Το ενδιαφέρον στο Shepherd είναι πως σου παρέχει ένα template που είναι ιδανικό για τις περισσότερες χρήσεις και βασικά αντιγράφει τα unit files του systemd. Συνεπώς μπορεί κάποιος να το χρησιμοποιήσει όμοια. Η διαφορά είναι πως αυτό από το file αποτελεί βασικά ένα πρόγραμμα οπότε δεν περιορύσσεσαι στο template. Φυσικά υπάρχει και μια σημαντική διαφορά με το s6. Στο Shepherd, o κώδικας, ο ίδιος ο init manager βασικά, που διαβάζει αυτά τα αρχεία είναι στην ίδια γλώσσα με αυτά αρχεία.

(off-topic) Άμα θες πάντως, εκτός από τη Guile μπορείς να εγκαταστήσεις και τον ίδιο το Guix package manager πάνω στο υπάρχον σύστημα (όπως snap και flatpak τελευταία χρόνια). Γενικά Nix (χρησιμοποιεί τη Nix DSL) και Guix (κλώνος του προηγούμενου αλλά χρησιμοποιεί Guile) θεωρούνται να οι πιο προχωρημένοι (βάση δυνατοτήτων) package managers στο Unix κόσμο. Επίσης στο θέμα γλωσσών η Racket προάγει το λεγόμενο γλωσσο-προσανατολισμένου παραδείγματος προγραμματισμού. (/off-topic)

Ως παράδειγμα πλεονεκτήματος των scripts, αυτό που είπαμε και παραπάνω, αρκετές φορές έχει τύχει να δημιουργώ ένα αρκετά απλό script που έκανε wrap κάποιο πρόγραμμα μόνο και μόνο να το καλέσω από το unit. Από τη μια άποψη καλό γιατί υπάρχει σαφής διαχωρισμός κώδικα, που ωστόσο ο κώδικας δεν είναι το κύριο σημείο, και configuration. Από την άλλη αποτυγχάνει ως service manager γιατί σε αναγκάζει να παράκαμψεις το manager για να κάνεις τη δουλειά σου.

@Soulrain

Εκτός και αν μου ξέφυγε, δεν αναφέρεται κάπου ότι το execlineb θα λειτουργεί αποκλειστικά με αυτην την ειδικά σχεδιασμένη γλώσσα.

https://skarnet.org/software/execline/

execline is a (non-interactive) scripting language, like sh - but its syntax is quite different from a traditional shell syntax. The execlineb program is meant to be used as an interpreter for a text file; the other commands are essentially useful inside an execlineb script.

Το execlineb είναι ο script parser.

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

Αυτή την εναντίωση σε DSLs τη βλέπω συχνά. Ωστόσο είναι ανευ βάσης αν απλά κάποιος σκεφτεί πως αυτές βρίσκονται παντού: awk, bash, CSS, make, cmake, R, SQL, TeX, VimL, …, ή ακόμα και JS στις αρχές (με αποκλειστική χρήση για client-side scripting). Γενικά μια DSL είναι καλή λύση σε αρκετά προβλήματα. Επιπλέον, κάτι ακόμα που βλέπω συχνά, η δυσκολία δεν είναι στο να μάθεις μια γλώσσα αλλά στο να μάθεις τη λογική που μπορεί να έχει μια γλώσσα. Η διαφορά είναι πως αυτή η λογική μεταβιβάζεται (π.χ. Python σε Ruby).

Εδώ μπορεί κάποιος να κάνει ένσταση πως δεν μιλάμε για προγραμματιστές αλλά για sysadmins. Άμεσα κοιτώντας τα προηγούμενα παραδείγματα φαίνεται πως sysadmins κι αυτοί χρησιμοποιούν κάποιες τέτοιες ειδικευμένες γλώσσες (awk, bash) όπως και γενικές φυσικά (Perl, Python, …).

Τέλος διάβασε τη πρώτη παράγραφο. Το systemd αν και χρησιμοποιεί configuration files με κάποια συγκεκριμένη δομή (ini-style) εν τέλη δεν είναι τόσο πιο απλό από το μάθεις μια επιπλέον γλώσσα.

Επίσης σε κανένα σημείο δεν νομίζω να είπα πως θεωρώ το s6 ολοκληρωμένο. Και φυσικά η ανάπτυξη του δεν θα περιοριστεί στο frontend. Κάθε άλλο το frontend είναι λιγο παρατημένο. Τέλος το systemd προπορεύεται αλλά έχει απλωθεί σε αρκετά μέρη του συστήματος και τα resources είναι περιορισμένα. Οπότε ένα πραγματικά συγκεντρωμένο dev team με σκοπό μόνο το init θα μπορούσε (άποψη) να το φτάσει.

Δηλαδή κάποιος θα κάτσει να σπαταλήσει χρόνο και έμπνευση για να δημιουργήσει μια ολοκαίνουργια γλώσσα που ουσιαστικά θα είναι κάτι σαν υποκατάστατο του sh, την οποία γλώσσα θα αξιοποιεί ένα init που θα βασίζεται σε scripts. Θα σου φαινόταν περίεργο αν σου έλεγα ότι όλο αυτό κατά πάσα πιθανότητα θα είναι μια όμορφη φούσκα (η καινούργια γλώσσα) που θα καταλήξει τελικά στο ίδιο πρόβλημα (το shell scripting);

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

Σύμφωνα με ποιο κοινά αποδεκτό κριτήριο ή παραδοχή; Ισχυρίζεσαι σοβαρά ότι αυτή η συγκεκριμένη δομή, η οποία υπάρχει με παρεμφερείς μορφές σε διάφορες υλοποιήσεις λογισμικών, δεν είναι τόσο πιο απλή από το να μάθεις μια ολοκαίνουργια γλώσσα; Επίσης, μη μένεις μόνο στο developer/sysadmin κομμάτι αλλά σκέψου και τον παράγοντα της αλληλεπίδρασης με τον χρήστη, γιατί και από αυτόν θα ζητηθεί να μάθει κάτι καινούργιο.

Ούτε κι εγώ είπα ότι το είπες κάπου. Ως επιπρόσθετο πρόβλημα το ανέφερα. Τέλος, δε μπορεί να πιστεύεις πραγματικά ότι ένα λογισμικό με μια κάποια πορεία στον χρόνο, με ευρύτατη αποδοχή, με χιλιάδες συνεισφέροντες και άλλους τόσους δυνητικούς (αυτό με τα περιορισμένα resources πού ακριβώς το στηρίζεις;), με τη στήριξη όλων των «μεγάλων» διανομών αλλά και με εταιρικό backing μπορεί να «απειληθεί» από ένα αναλογικά μικρότερο (κατά πολύ) έργο, το οποίο δε διαθέτει ούτε καν το ένα τέταρτο σε πόρους (ανθρώπινους και μη). Θεωρώ ότι η άποψή σου αυτή είναι περισσότερο ευσεβής πόθος.

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

Δηλαδή κάποιος θα κάτσει να σπαταλήσει χρόνο και έμπνευση για να δημιουργήσει μια ολοκαίνουργια γλώσσα

“Δηλαδή κάποιος θα κάτσει να σπαταλήσει χρόνο και έμπνευση για να δημιουργήσει X.” Φυσικά και ναι! Αν ο δημιουργός θεωρεί πως ο σχεδιασμός αυτός έχει πλεονεκτήματα. Μπορείς να ξανακοιτάξεις τα παραδείγματα που έδωσα παραπάνω. Και, σχετικό πιστεύω, αξίζει κανείς να δει το θρυλικό comment στο HN από ένα expert χρήστη Linux στο Dropbox (My YC app: Dropbox - Throw away your USB drive | Hacker News) και γιατί αυτή η πρόταση δείχνει μια λάθος φιλοσοφία να έχει κάποιος.

την οποία γλώσσα θα αξιοποιεί ένα init που θα βασίζεται σε scripts

Δεν καταλαβαίνω τι ακριβώς θες να πεις, οπότε θα απαντήσω και τις δυο εκδοχές.

i. Παραμένει script. Δεν αλλάζει κάτι. Αντί να χρησιμοποιείται όμως sh, Perl, κτλ δημιουργείται μια ειδικού σκοπού γλώσσα που απλοποιεί το scripting εργασιών και δημιουργεί τους αναγκαίους περιορισμούς ώστε αυτά να είναι ασφαλή (δυνατό γιατί μιλάμε για συγκεκριμένο πρόβλημα). Είναι το λάθος που έκανα στην αρχή, που πίστευα ότι υποστηρίζει μόνο shell scripting.

Βέβαια στο forum λινκ που έδωσα παραπάνω λέει πως και απλά shell scripts δεν είναι κατ´ ανάγκη πολύπλοκα μιλώντας για OpenRC και BSD. Δυστυχώς δεν έχω εμπειρία σε αυτά τα συστήματα και γνωρίζω μόνο τα sysvrc scripts που… ναι, δεν ήταν και ότι καλύτερο.

ii. Το ίδιο το s6 είναι γραμμένο σε C. Γι´ αυτό και το σχόλιο μου προηγουμένως σε σύγκριση με το Shepherd του Guix. Η διαφορά είναι πως τα συστατικά είναι διαχωρισμένα σε αρχεία και επαναχρησιμοποιήσιμα. Τσεκάροντας με ένα ack το κώδικα του systemd για κάποια από τα terms θα δεις πως υπάρχει ένα tight coupling με τα terms να εμφανίζονται σε πολλαπλά αρχεία (modules).

Θα σου φαινόταν περίεργο αν σου έλεγα ότι όλο αυτό κατά πάσα πιθανότητα θα είναι μια όμορφη φούσκα (η καινούργια γλώσσα) που θα καταλήξει τελικά στο ίδιο πρόβλημα (το shell scripting);

Όχι, αλλά μένει να δούμε. Όπως ειπώθηκε και παραπάνω “ακόμα δεν τον είδαμε Γιάννη τον βαπτίσαμε.” Προσωπικά δεν έχω χρόνο να ασχοληθώ με την ανάπτυξη οπότε θα δω το όποιο αποτέλεσμα προκύψει τελικά.

αλλά στη λογική του να μην αξιοποιούνται τα υπάρχοντα εργαλεία με κάποιον καινοφανή τρόπο

Καταλαβαίνεις ότι ολόκληρο το systemd είναι μια σουίτα εργαλείων από το μηδέν; Γιατί αυτό σου φαίνεται εντάξει στη μία περίπτωση αλλά περίεργο στην άλλη που είναι το ίδιο ακριβώς πρόβλημα; Εφόσον μάλιστα μια shell-like γλώσσα είναι αναμενόμενο (ως απαραίτητο) να χρησιμοποεί αρκετά από τα υπάρχοντα εργαλεία το s6 είναι πιο κοντά σε αυτό που θεωρείς καλύτερη λογική. Περαιτέρω ισχύει ο διαχωρισμός που ανέφερα παραπάνω στα συστατικά που σημαίνει ότι αυτά μπορούν να χρησιμοποιηθούν έξω από το s6. Κάτι που δεν ισχύει με το systemd βέβαια το οποίο υπάρχει ανεξάρτητα απ´ οτιδήποτε άλλο.

Οι περιπτώσεις που ανέφερες δεν έχουν καμία σημασία

Φυσικά κι έχουν! Δείχνει πως γλώσσες ειδικού σκοπού (τομέα) μπορούν να χρησιμοποιηθούν σε πλήθος προβλημάτων. Ιδιαίτερα προβλήματα που απαιτείται να δημιουργηθεί κάποια λογική.

καθώς δε σχετίζονται με την εκκίνηση ενός λειτουργικού συστήματος.

Σωστά. Εδώ ανέφερα κάποια παραδείγματα ωστόσο άφησα έξω το σημαντικότερο. Το upstart που χρησιμοποιούσαν Ubuntu και Fedora προ του systemd χρησιμοποιούσε το ίδιο παράδειγμα, δηλαδή τα jobs του ήταν scripts αλλά πιο structured και άλλη syntax από shell scripts. Αλλά και αν το upstart δεν υπήρχε αυτό θα σήμαινε ότι απλά υπάρχει κενό ώστε κάποιος να το κάνει πρώτος.

Γιατί το systemd κέρδισε έναντι του upstart; Προσωπικά ήμουν εντάξει με upstart, όπως είμαι εντάξει τώρα με systemd. Ανάμεσα σε άλλους τεχνικούς (και μη;) λόγους θα πω πως ο σημαντικότερος είναι γιατί δεν αντικαθιστούσε μόνο το init (όπως μίλησα σε προηγούμενο ποστ). Είναι κάτι που ισχύει στο s6 εκ σχεδιασμού επειδή θεωρείται θετικό. Ωστόσο εγώ μιλάω μόνο για το init (νομίζω αυτό είναι το θέμα του thread) και το κομμάτι του σχεδιασμού παρά αν θα γίνει δημοφιλές κάποια στιγμή.

Σύμφωνα με ποιο κοινά αποδεκτό κριτήριο ή παραδοχή;

Εδώ ό,τι και να πω θα το αρνηθείς απ´ ότι καταλαβαίνω εφόσον ήδη αναφέρθηκα στο ποια είναι η δυσκολία. Τα αναρίθμητα και συνεχώς αυξανόμενα terms στα οποία είσαι περιορισμένος. Και εδώ εμφανίζεται αυτό που ανέφερα στο προηγούμενο μου ποστ: τι overlap υπάρχει μεταξύ αυτών; Όπως και με υπάρχοντα εργαλεία σε ένα Unix σύστημα; Που είναι ο ίδιος προβληματισμός εσύ εξέθεσες για το s6. Επίσης όπως ανάφερα παραπάνω το systemd αναγκάζει το χρήστη να αποκτήσει μια απόλυτα systemd-specific γνώση που δεν είναι καθόλου πρόβλημα (γι´ αυτό άλλωστε μαθαίνουμε να χρησιμοποιούμε και κάποια εξειδικευμένα προγράμματα) αν δεν υπάρχει εναλλακτική. Αλλά αυτό είναι που το s6 θέλει να αποδείξει λάθος.

Επίσης, επειδή ξεφύγαμε πολύ στο κομμάτι μιας ειδικής γλώσσας, όπως ανέφερα κι αρχικά στα σχέδια υπάρχει και ένα unit-like file format. Βασικά αυτό αλλάζει την αρχιτεκτονική από (systemd) binaries <- unit files <- scripts σε (s6) binaries <- scripts <- unit files. Περαιτέρω πιο πολύπλοκα scripts θα μπορούν να γραφούν σε μια γενική scripting γλώσσα. Γενικά, αν δεν διάβασες το forum λινκ που έδωσα, το s6 παίρνει αρκετές ιδέες από το systemd εφόσον δεν είναι απόλυτα ενάντια στο systemd αλλά στην υλοποίηση αυτού.

αυτό με τα περιορισμένα resources πού ακριβώς το στηρίζεις;

Κάθε project έχει περιορισμένα resources. Αν πιστεύεις πως ένα project έχει τη δυνατότητα για άπειρη ανάπτυξη προς κάθε κατεύθυνση είσαι λάθος. Μια απλή απόδειξη είναι πως οι drivers του πυρήνα για κάποια hardware είναι underdeveloped. Φυσικά εδώ μιλάμε για μικρότερο scale, αλλά το ίδιο ισχύει για τους συνεισφέροντες.

να «απειληθεί» από ένα αναλογικά μικρότερο

Φαντάζομαι εδώ αναφέρεσαι στο κομμάτι της δημοφιλότητας; Δεν είμαι σίγουρος να πω την αλήθεια γιατί βρίσκεις ενδιαφέρον το αν θα γίνει κάτι δημοφιλές. Προφανώς το s6 δεν θα γίνει δημοφιλές όπως ήδη ανάφερα παραπάνω και οι λόγοι δεν είναι απαραίτητα το ίδιο το init.

αυτή είναι περισσότερο ευσεβής πόθος.

Ίσως ή, πιο σωστά, πιθανώς. Αλλά μη ξεχνάμε και τις ρίζες του ίδιου του Linux ως ένα pet project ενός Φιλανδού φοιτητή. Επίσης μάλλον δεν γνωρίζεις αλλά τα πρώτα χρόνια το systemd αναπτύσσονταν εξ´ ολοκλήρου από το Lennard ως pet project και επιπλέον συνεισφέροντες ήρθαν όταν έγινε το default στο Fedora (μπορείς να τσεκάρεις το commit history). Συνεπώς το μικρότερο έργο (systemd) υπερνίκησε αυτό (upstart) με κάποια πορεία στο χρόνο και εταιρικό backing.

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

Ισχύει. Κακό; Πιστεύω πως όχι. Περισσότερα από αυτά δημιουργούνται σ´ ελεύθερο χρόνο γιατί είναι κάτι που αρέσει στον dev παρά ως καταναγκαστικό έργο. Άλλωστε αυτή είναι η φιλοσοφία του ΕΛ/ΛΑΚ. Αυτά βέβαια αν τα έργα βασίζονται πράγματι σε μια ιδέα και δεν είναι κάτι ασήμαντο όπως ένα Rewrite it in X ή ένα ακόμη distro.

Γιατί ο τρόπος που έκανε τις εξαρτήσεις το upstart ήταν ανάποδα. Οι τεχνικές λεπτομέρειες έχουν αναλυθεί στο Rethinking PID 1 και το κυριότερο τις θέσεις αυτές έχουν υποστηρίξει και οι ίδιοι οι δημιουργοί του upstart.

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

image

Εκκρεμούν 166 pull requests στα διάφορα κομμάτια του από πολλούς ανθρώπους, ενώ έχει 1400 issues. Την τελευταία μόνο εβδομάδα:

Excluding merges, 17 authors have pushed 88 commits to main and 88 commits to all branches. On main, 276 files have changed and there have been 2,957 additions and 2,369 deletions . Κάποιος Zbigniew Jędrzejewski-Szmek είχε τις περισσότερες και με διαφορά. 2.600 άνθρωποι το έκαναν fork οι περισσότεροι για να κάνουν μια αλλαγή και να την στείλουν πίσω

Ας δούμε τώρα αυτό:

image

Καμία απολύτως δραστηριότητα την τελευταία εβδομάδα. Μόλις 18 issues. Είχε σε όλη την ιστορία του 8 pull requests. Με όρους του github είναι ένα νεκρό έργο. Ο δημιουργός δεν έχει συνηθίσει στην συνεργασία με άλλους.

Και πολύ καλά κάνει και όπως λέμε και στην Κρήτη “Ξά ντου”. Δικαίωμα του τι θα κάνει και τι δεν θα κάνει και δεν θα το κρίνω εγώ. Αλλά για να το εμπιστευθώ στην διανομή που θα επιλέξω, και για να το εμπιστευθεί μια σοβαρή διανομή, θέλει κάτι που να έχει bus factor μεγαλύτερο του ένα(1).

ΥΓ: Βρίσκω ελαφρά διασκεδαστικό, πώς η μεγάλη πλειοψηφία που εναντιώνετε ενεργά στο sytemd δεν έχει καθίσει να συζητήσει και να υποστηρίξει ενεργά με κώδικα κάτι διαφορετικό. Συνήθως απλά τρόλαρουν και κάνουν θόρυβο. Συχνά το αποτέλεσμα είναι να καταλήξει ο άλλος στο συμπέρασμα πως είτε Windows είτε Linux με παρακολουθεί το ίδιο η MASA άρα γιατι να μπλέκω (και εδώ είναι που γίνετε καθόλου διασκεδαστικό). Ίσως αυτά τα νούμερα να εξηγούν και το μέγα επιχείρημα περί back doors και δυσκολία να αναλύσεις τις χιλιάδες γραμμές κώδικα. Είναι απλό άντε να έχουν γράψει στην ζωή τους κανένα bash script :grinning:

Κάτσε να το αποσαφηνίσω αυτό για να καταλάβεις καλύτερα τι εννοώ. Υπάρχει μια πλευρά (στην οποία εντάσσομαι κι εγώ) που θεωρεί ότι η χρήση shell scripts για την εκκίνηση υπηρεσιών από ένα init είναι μια λύση που πλέον είναι παρωχημένη και δεν επαρκεί για όλες τις σύγχρονες ανάγκες ενός λειτουργικού. Αυτή η πεποίθηση δεν προέκυψε έπειτα από την εμφάνιση του systemd αλλά πάντα επιθυμούσαμε κάτι «καλύτερο». Ήρθε λοιπόν το systemd και έδωσε αυτό το «καλύτερο», το οποίο ταυτόχρονα προσφέρει και ενοποίηση. Φυσικά, δεν είναι το μοναδικό «καλύτερο» και τίποτα δεν αποκλείει την εμφάνιση μιας προτιμότερης λύσης. Είναι όμως, αυτήν τη στιγμή, η ιδανικότερη λύση που έχουμε γιατί λύνει πολλά από αυτά που για την προαναφερθείσα πλευρά θεωρούνται προβλήματα των παλιότερων inits.

Με βάση αυτήν τη θεώρηση λοιπόν, το να καταβάλει κάποιος κόπο για να δημιουργήσει εκ του μηδενός μια λύση που φιλοδοξεί να είναι «καλύτερη» του systemd αλλά στην πράξη θα είναι μια διαφορετική μορφή shell scripting, είναι σπατάλη χρόνου και κόπου που δε λύνει καν το βασικό πρόβλημα.

Φυσικά, δεν ισχυρίζομαι ότι τα παραπάνω είναι «η μοναδική αλήθεια». Προσπάθησα απλά να εξηγήσω συνοπτικά το γιατί ορισμένοι απομακρυνόμαστε από τον συνδυασμό init + shell scripts και γιατί τέτοιες λύσεις έχουν πια μηδαμινές πιθανότητες να κινήσουν το (προγραμματιστικό ή μη) ενδιαφέρον μας.

Ναι, αυτό είναι ένα από τα βασικά χαρακτηριστικά ενός ενοποιημένου συστήματος. Εδώ, κατά την προσωπική μου άποψη, έχουμε μια λανθασμένη έκφραση της «φιλοσοφίας του Unix», η οποία χρησιμοποιείται και ως αντεπιχείρημα. Οι εκφραστές αυτής της «φιλοσοφίας» αγνοούν α) ότι εμφανίστηκε σε μια εποχή που οι τεχνολογικές ανάγκες ήταν απείρως λιγότερο πολύπλοκες από τον σημερινό κόσμο και β) ότι, όπως κάθε άλλη προσέγγιση, έχει και μειονεκτήματα και δε μπορεί να θεωρείται «be-all and end-all» λύση για οποιαδήποτε ανάγκη.

Το systemd δε σχεδιάστηκε για να είναι επαναχρησιμοποιήσιμο, ούτε υποστηρίζει πως είναι. Έχει σαφή προσανατολισμό και πάει κόντρα στη «φιλοσοφία του Unix» και σε άλλα «ιδεολογικά τοτέμ» (επίτρεψέ μου τον όρο) του ΕΛ/ΛΑΚ. Δεν είναι το μοναδικό έργο λογισμικού που το κάνει αυτό. Υπάρχουν και άλλα που χρησιμοποιούνται ευρύτατα, ενδεχομένως χωρίς καν να το αντιλαμβάνονται οι χρήστες τους.

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

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

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

Δεν πιστεύω στην άπειρη ανάπτυξη. Αυτό που πιστεύω είναι ότι, αν υποθέσουμε ότι υπάρχει ένα Χ εύρος συνεισφερόντων και πόρων, και έχουμε δύο έργα, από τα οποία το ένα συγκεντρώνει το 95% αυτού του εύρους και το άλλο έχει το υπόλοιπο 5%, το πρώτο έχει σημαντικά μεγαλύτερες δυνατότητες και προοπτικές ανάπτυξης. Γι’ αυτό ανέφερα στο προηγούμενο σχόλιο ότι μερικές φορές οι δημιουργοί δεν εκτιμούν σωστά τις δυνατότητές τους και τις απαιτήσεις.

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

  1. To Linux έλυσε ένα πρόβλημα. Δεν ήταν διαφορετικός τρόπος διαχείρισης ενός υφιστάμενου προβλήματος.
  2. Το Linux δεν ήταν φιλοσοφικά (δε λέω ιδεολογικά) κινούμενο και όπου χρειάστηκε δε δίστασε να πάει κόντρα σε παλιότερες φιλοσοφίες ανάπτυξης κλπ.
  3. Το Linux είχε και αυτό πολέμιους ως προς τον τρόπο που έκανε πράγματα (π.χ. monolithic vs microkernel).
  4. Το Linux έχει ακόμα κάποια μειονεκτήματα έναντι άλλων λύσεων (ας πούμε, στον τομέα του networking κάποιοι BSDάδες γελάνε).
  5. Το Linux δε δημιουργήθηκε ως «anti-τάδε» και ήταν πάντα δεκτικό.
  6. Το Linux δεν είναι η «απόλυτη» λύση σε κάθε τομέα όπου έχει εφαρμογή και σε κάποιους από αυτούς τους τομείς υστερεί. Είναι όμως η «καλύτερη» λύση overall από όσες υπάρχουν σήμερα.

Εδώ συνηθίζω να λέω ότι το «μπορώ να το κάνω» δε σημαίνει και ότι «έχει νόημα να το κάνω» και μάλλον συμφωνείς στην τελευταία σου πρόταση.

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

Επίσης, στην προκείμενη περίπτωση των εναλλακτικών inits, αν πάρουμε τα κείμενα των δημιουργών τους και αφαιρέσουμε τα αμιγώς φιλοσοφικά τμήματα και όσα δεν έχουν την παραμικρή σχέση με την τεχνολογία, δε θα μείνουν παρά ελάχιστες παράγραφοι. Αυτό, για εμένα, είναι ενδεικτικό του ότι οι προσπάθειες αυτές δε βασίζονται σε τεχνικές διαφορές και μια τέτοια προσέγγιση είναι λανθασμένη. Να το πω πεζά, αν το μηχάνημα κάποιου δε μπουτάρει, δε θα σκεφτεί ποτέ «δεν πειράζει μωρέ, αρκεί που ο Μπάμπης τηρεί το POSIX». Θα πάει κατευθείαν στο έργο του Τάκη που μπορεί να μην ενδιαφέρεται ιδιαίτερα για το POSIX αλλά κάνει κανονική εκκίνηση. Αντίστοιχες θα είναι και οι σκέψεις του ενδιαφερόμενου συνεισφέροντα.

Ας μιλήσουμε και για την φιλοσοφία του UNIX. Αυτή δεν είναι κάτι που έχει γραφτεί κάπου, αλλά ο καθένας την ερμηνεύει όπως θέλει. Ας πάρομε τον Douglas McIlroy - Wikipedia. Σύμφωνα με αυτόν είναι:

  • Write programs that do one thing and do it well.
    Γράψτε προγράμματα που κάνουν ένα πράγμα και το κάνουν καλά.
  • Write programs to work together.
    Γράψτε προγράμματα που συνεργάζονται μεταξύ τους
  • Write programs to handle text streams, because that is a universal interface.
    Γράψτε προγράμματα που επικοινωνούν μεταξύ τους με ροές κειμένου

Ας τα δούμε ένα ένα

  • Το systemd-init κάνει ένα πράγμα διαχειρίζεται τις υπηρεσίες συστήματος και τις εξαρτήσεις τους και το κάνει καλά.
  • Επίσης έχει ένα σύνολο ανεξάρτητων διαφορετικών προγραμμάτων που συνεργάζονται μεταξύ τους.
  • Εδώ πρόσεξε πως μιλάει για την επικοινωνία μεταξύ των προγραμμάτων και όχι για text files.

Ας μείνουμε λίγο στην τελευταία θέση. Αυτή είναι προσανατολισμένη στις σωληνώσεις και το τερματικό. Κάτι που παρά τα ψιλοπροβλήματα (έχεις προσπαθήσει ποτέ να κάνεις parse κάποιο csv file) είχε νόημα όταν η διασύνδεση σου ήταν το τερματικό. Αλλά οι υπηρεσίες συστήματος ήταν έξω από αυτό το μοντέλο, δεν μίλαγες ποτέ με μια βάση δεδομένων με σωληνώσεις. αλλά με κάποιο μηχανισμό IPC. Και πριν λίγες μέρες διάβαζα για τα προβλήματα να περάσεις ένα key-up event απο SSH. Και τα γεγονότα που ενδιαφέρουν ένα σύστημα διαχείρισης του υπολογιστή είναι κυρίως ασύγχρονα.

Η επικοινωνία στο systemd έχει περάσει μέσα από ένα ασύγχρονο δομημένο δίαυλο επικοινωνίας το D-Bus. Αν αντικαταστήσεις το “text streams” με “dbus messages” έχεις ακριβώς το ίδιο πράγμα, γνώμη μου.

Είναι ένας άμεσο αποτέλεσμα λοιπόν της ίδιας της φιλοσοφίας του UNIX όπως αυτή έχει μορφή την επόμενη χιλιετία από την δημιουργία της. Και για το επιχείρημα περί μονολιθικότητας επειδή είναι σε ένα μόνο αποθετήριο: Αλήθεια το UNIX πότε ήταν χωρισμένο σε διαφορετικά κομμάτια; Ακόμα και σήμερα στο BSD θα βρεις όλο το λειτουργικό, τον πυρήνα, το σύστημα εκκίνησης και όλα τα εργαλεία σε ένα μονολιθικό αποθετήριο. Είναι αυτό στην φιλοσοφία του UNIX ;

1 «Μου αρέσει»

Στο Linux έχουμε τις γνωστές «διανομές», που ουσιαστικά είναι διάφορα στρώματα λογισμικού που επικάθονται το ένα πάνω στο άλλο και η ενσωμάτωση πάσχει σε σημεία.

Στον κόσμο των BSDs, αντίθετα, δεν υπάρχουν «διανομές» αλλά ανεξάρτητα λειτουργικά που χτίζονται «from the ground up» με συγκεκριμένα συστατικά και πολύ καλή ενσωμάτωση.

Η λέξη-κλειδί εδώ είναι η «ενσωμάτωση» (integration στα Ελληνικά). Αυτό το χαρακτηριστικό είναι μέγα αρνητικό για όσους ασπάζονται απόλυτα τη «φιλοσοφία του Unix» αλλά ταυτόχρονα σε ορισμένες περιπτώσεις προσφέρει αποτελέσματα και δυνατότητες που η φιλοσοφία αυτή δε θα μπορούσε ποτέ να προσφέρει.

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

1 «Μου αρέσει»

Ναι, όπως ανάφερα υπάρχουν και άλλοι λόγοι. Επίσης συγκρίνεις την ανάπτυξη του systemd τώρα που υπάρχει σε κάθε σημαντική διανομή και corporate backing με το s6 που δεν υπάρχει πουθενά παρά μόνο σε διανομή που έχει φτιαχτεί μόνο για να τρέχει αυτό και χωρίς sponsorship. Φυσικά το s6 υπάρχει σχεδόν μια δεκαετία τώρα κι αυτό αλλά η σύγκριση παραμένει άνιση.

πώς η μεγάλη πλειοψηφία που εναντιώνετε ενεργά στο sytemd δεν έχει καθίσει να συζητήσει και να υποστηρίξει ενεργά με κώδικα κάτι διαφορετικό

Πράγματι. Από την άλλη το ίδιο δεν ισχύει και για τη πλειονότητα όσων ήταν ενάντια στα shell scripts προ το systemd; Σε αυτή τη περίπτωση μάλιστα μια εναλλακτική ήταν απαραίτητη. Αυτό ισχύει γενικά στο ΕΛ/ΛΑΚ. Υπάρχουν ανάγκη από λύσεις/εναλλακτικές αλλά τελικά δεν γίνεται κάτι μέχρι να έρθει κάποιος που θα τραβήξει μπροστά.

Edit:

Αν αντικαταστήσεις το “text streams” με “dbus messages” έχεις ακριβώς το ίδιο πράγμα, γνώμη μου.

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

@Soulrain

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

Αυτός που βάζει την ιδεολογία πάνω από την τεχνολογία θα τη θεωρήσει απόλυτα αρνητική. Εκείνος που βάζει την τεχνολογία πάνω από την ιδεολογία θα τη θεωρήσει απόλυτα θετική.

Αυτό είναι καθαρά προσωπική σου άποψη και όχι γενική αλήθεια. Συγκεκριμένα μου θυμίζει το “The Cathedral and the Bazaar” προσαρμοσμένο στην αρχιτεκτονική που μπορεί να έχει ένα σύστημα. Σύγκρινε επίσης ανάπτυξη *BSDs και Linux διανομών. Εdit: Που είδα γίνεται παρακάτω.

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

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

1 «Μου αρέσει»