Το παρόν τεστ γίνεται σε KVM και έχουν γίνει καθαρές εγκαταστάσεις.
Arch (systemd) - Πάνω αριστερά
Artix (runit) - Κάτω αριστερά
Artix (openrc) - Πάνω δεξιά
Οι εγκαταστάσεις περιλαμβάνουν: Arch : base base-devel linux linux-firmware connman Artix(OpenRc) : base base-devel openrc linux linux-firmware connman Artix(Runit) : base base-devel runit elogind-runit linux linux-firmware connman
Το μόνο service που προστέθηκε και στα 3 συστήματα είναι αυτό του connman και δεν έγινε καμία άλλη αλλαγή.
Το κάθε εικονικό σύστημα αποτελείται από :
2 cores
2048 ram
Αρχικά να τονίσω πως χρησιμοποίησα το Artix διότι είναι Arch-based και πατάει πάνω στα arch repo για οποιαδήποτε αλλαγή κάνει. Δεν το βρίσκω δίκαιο να κάνω test init σε διαφορετικές διανομές.
Αυτά δεν αρκούν για να κριθεί ποιο είναι τελικά το πιο γρήγορο init αλλά είναι μία δοκιμή με ίδια βάση.
Υ.Γ: Το edit μου είναι άθλιο καθώς δεν έχω ιδέα, ελπίζω να δείξετε κατανόηση!
Απ’ότι φαίνεται το πάνω αριστερά σύστημα εμφανίζει πρώτο το TTY το οποίο είναι το systemd. Αμέσω μετά ακολουθάει το κάτω αριστερά το οποίο είναι με runit και τελευταίο με αρκετή διαφορά έρχεται το openrc.
Να τονίσω πως δεν έκανα καμία αλλαγή στα init και είναι χωρίς παραμετροποιήσεις. Μόνο στο systemd αφαίρεσα το quiet για να εμφανίσει αυτά που φορτώνονται! (δεν επηρεάζει την ταχύτητα).
Με παραμετροποιήσεις μπορεί κάποιο άλλο init να είναι πιο γρήγορο και περιμένω τα σχόλια σας να τα δοκιμάσω με μεγάλη ευχαρίστηση! Προς το παρόν το systemd κερδίζει σε ταχύτητα.
Φαίνεται να έπεσα μέσα, καθώς το rc.conf, όπως υπάρχει στο αντίστοιχο πακέτο του OpenRC για το Artix, έχει ως προεπιλογή την παράμετρο `#rc_parallel=“NO”. Δεν είναι ακριβώς απλή ρύθμιση*, γι’ αυτό από το upstream υπάρχει η παρακάτω προειδοποίηση:
WARNING: whilst we have improved parallel, it can still potentially lock
the boot process. Don’t file bugs about this unless you can supply
patches that fix it without breaking other things!
*Για τα πρακτικά, το OpenRC δεν είναι πραγματικό init αλλά προεκτείνει ένα ήδη υπάρχον (συνήθως το SysV).
To OpenRC εδώ και χρόνια είναι “πραγματικό” init. Έχει το δικό του init binary, δεν εξαρτάται από το sysvinit. Μπορεί να τρέξει πάνω σε άλλο init (όπως μπορούν και τα runit, s6/s6-rc/66) αν το θέλει κάποιος, αλλά αυτό είναι άλλη υπόθεση ;)
Πες το σημασιολογία, αν θέλεις, αλλά το openrc-init είναι init (αν και όχι η συνήθης υλοποίηση, ούτε καν στο Gentoo), το OpenRC όμως δεν είναι. Εξ ορισμού, ένα πραγματικό (ή «πραγματικό») init δε μπορεί να τρέξει πάνω σε άλλο init.
Το openrc-init είναι το πρόγραμμα που χρησιμοποιείται για init στο artix. Είναι μέρος του ίδιου πακέτου με τα υπόλοιπα τμήματα του openrc, όπως το runit-init που χρησιμοποιείται στο voidlinux είναι μέρος του ίδιου πακέτου με το runsvdir, το runsv, το chpst… Άρα μιλάμε για το σύνολο. Ναι, όλα αυτά που ανέφερα πριν είναι service/system managers που μπορούν να τρέξουν και σαν πλήρη init systems. Το ότι μπορεί να τρέξει τμήμα τους που κάνει service management πάνω σε άλλο init είναι ωραίο παράδειγμα modularity.
Αν μιλάμε συγκεκριμένα για το Artix, τότε συμφωνούμε. Γενικά όμως, όταν υπάρχει αναφορά στο OpenRC, κατά 99,9% δεν εννοεί το openrc-init. Γι’ αυτό ανέφερα παραπάνω ότι ούτε καν η κυριότερη διανομή Linux που χρησιμοποιεί το OpenRC (και στην οποία εμφανίστηκε η πρώτη υλοποίηση) δε χρησιμοποιεί από προεπιλογή και το openrc-init.
Όσον αφορά το modularity και συγκεκριμένα για το OpenRC (δεν έχω άποψη για το runit), αυτό ήρθε έμμεσα αφού ο στόχος της δημιουργίας ήταν να προσδώσει χαρακτηριστικά που έλειπαν από τα «παραδοσιακά» inits. Ούτε καν έλεγχο των services δεν είχε στις πρώτες εκδόσεις.
Εδώ όμως, κατά τη γνώμη μου, όπως υλοποιείται το modularity μπορεί να θεωρηθεί και αρνητικό, καθώς δε θα μπορέσει ποτέ να υποστηρίξει με τον ίδιο τρόπο τα χαρακτηριστικά ενός συστήματος όπως ένα αμιγώς system-specific init/service manager. Δεν είναι τυχαίο ότι ακόμα, και παρά την ύπαρξη του openrc-init, χρησιμοποιείται το rc.conf για την παραμετροποίηση (από το SysV, βεβαίως).
Ναι, θεώρησα δεδομένο ότι μιλούσαμε για το artix, αφού η σύγκριση του θέματος έγινε με αυτό. Δεν διαφωνώ στα υπόλοιπα, απλά επισήμανα ότι πλέον το OpenRC είναι πλήρες ;)
Το OpenRC είναι modular (ως ένα βαθμό) από την φύση του και αυτό είναι λογικό, αφού σχεδιάστηκε σαν rc-system, προφανώς…
Με τον ίδιο τρόπο προφανώς όχι. Το ίδιο καλά… παίζει Αν είναι καλοσχεδιασμένο μπορεί. Το OpenRC έχει επεκταθεί ουκ ολίγες φορές. Προσωπικά δεν θα το πρότεινα, καθώς πιστεύω ότι υπάρχουν καλύτερες λύσεις, αλλά αναπτύσσεται και χρησιμοποιείται.
Δεν έχω ιδέα τι εννοείς με το rc.conf…
Το sysvinit δεν έχει κάτι τέτοιο by default. Τα init/rc systems των BSDs έχουν. Από εκεί προέρχεται η ιδέα στο openRC, στα παλιά arch initscripts, στο void-runit. Ακόμα και σ’ αυτές τις περιπτώσεις, το rc.conf δεν κάνει ακριβώς την ίδια δουλειά σε όλα, καθώς είναι προσαρμοσμένο στις ανάγκες των διανομών και των διαφορετικών init systems. Στο δε openRC είναι παράδοξο να το αναφέρεις σαν χαρακτηριστικό αντίθετο στο modularity ή στην παραμετροποίηση, καθώς αυτό ήταν το πρώτο initsystem με per-service configuration files.
Μα δε… μπορεί. Όταν υποστηρίζονται ταυτόχρονα πολλαπλά συστήματα, αναπόφευκτα γίνονται μικρές ή μεγαλύτερες θυσίες ως προς τη βελτίωση της υποστήριξης για ένα σύστημα ώστε να διαφυλαχθεί η συμβατότητα με τα υπόλοιπα. O πυρήνας Linux και ο αντίστοιχος των BSDs, ας πούμε, δεν έχουν τα ίδια χαρακτηριστικά. Πρακτικά είναι αδύνατο ένα σύστημα init/service manager/supervisor να υποστηρίζει «άψογα» και τους δύο στο διηνεκές και να αξιοποιεί στο έπακρο τις δυνατότητές τους.
Τόσο το SysV όσο και τα BSD rc scripts και τα λοιπά είναι στην ουσία διαφορετικές υλοποιήσεις του αρχικού rc από τον κόσμο του UNIX και ορισμένα χαρακτηριστικά τους αλληλεπικαλύπτονται. Μπορεί το SysV να μην έχει αρχείο rc.conf από προεπιλογή, δύναται όμως να λειτουργήσει με αυτό χωρίς να είναι απαραίτητη η ύπαρξη ενός BSD-style init, ενώ υπήρχε (δε γνωρίζω αν υπάρχει ακόμα) και ένα binary CLI εργαλείο ονόματι… sysv-rc-conf (όχι τυχαία) για το SysV.
Έγραψα τη φράση «Εδώ όμως, κατά τη γνώμη μου, όπως υλοποιείται το modularity[…]» και, επειδή μάλλον δεν ήταν όσο σαφής νόμιζα, διεκρινίζω ότι εννοούσα την ταυτόχρονη υποστήριξη πολλαπλών συστημάτων και inits.
Έχουν προφανώς κοινή (στο επίπεδο της… έμπνευσης) καταγωγή, αλλά αρκετά διαφορετική εξέλιξη. Προφανώς με κοινά στοιχεία, κάνουν παρόμοια δουλειά άλλωστε.
Αξίζει να δεις το paper για το νέο τότε (2001) rc.d system του NetBSD από τον Luke Mewburn για την εξέλιξη και τις διαφορές.
Από τότε έχουν αλλάξει αρκετά, αλλά όχι η βασική λογική στα BSDs, με εξαίρεση τις σημαντικές βελτιώσεις του OpenBSD. Το σύντομο paper/ανακοίνωση του Antoine Jacoutot στην AsiaBSDCon 2016 είναι εξαιρετικό καθώς ασκεί κριτική στις υπάρχουσες λύσεις και εξηγεί την λογική που οδήγησε στον νέο μηχανισμό.
Το sysv-rc-conf δεν έχει και πολύ σχέση με το rc.conf. Ρυθμίζει με tui ή cli το ποιά services αρχίζει σε ποιό runlevel (symlinks), δεν ρυθμίζει κεντρικά σε ένα αρχείο το σύστημα. Φαντάζομαι δεν είχες την τύχη (ή την ατυχία, όπως το πάρει κανείς…) να το χρησιμοποιήσεις.
Εμένα μου ήρθαν μνήμες από το SuSE (έκδοση 6.0?). Σκάλιζες το σύστημα με το YaST και έφτιαχνε ένα τεράστιο αρχείο rc, που δεν καθόσουν να το σκαλίσεις που έκανε εκκίνηση το σύστημα. Οι μνήμες μπορεί να είναι λάθος, και σίγουρα τότε δεν είχα τις γνώσεις και την σημερινή εμπειρία.
Έχει να κάνει με την σχεδίαση και τους στόχους. Δεν είναι αδύνατο, ούτε όμως χωρίς κόστος. Δεν ξέρω γιατί συγκρίνεις διαφορετικά λειτουργικά (…), αλλά και εκεί μπορείς να εκμεταλλευτείς στο καθένα τις δυνατότητές του. Το nosh π.χ. μπορεί να χρησιμοποιήσει τόσο jails, όσο και cgroups. Το καθένα βέβαια εκεί που υπάρχει.
Αν βέβαια κάποιος γράψει ένα init system/service manager που εξαρτά την λειτουργία του αποκλειστικά από χαρακτηριστικά ενός OS, ε… προφανώς δεν μπορεί να τρέξει σε άλλο.
Γιατί ένα πλεονέκτημα του systemd* -το οποίο systemd αναφέρθηκε στο παρόν νήμα- και ταυτόχρονα μια καλή ένδειξη του ότι η «συμβατότητα με τα πάντα» υστερεί σε ορισμένα σημεία είναι το γεγονός ότι σχεδιάστηκε εξαρχής ως Linux-specific. Αυτό σημαίνει, για παράδειγμα, ότι δε θα κάνει θυσία αν ποτέ εμφανιστεί ένα χαρακτηριστικό στον πυρήνα Linux, η ενσωμάτωση του οποίου θα επηρεάζει τη συμβατότητα με τα BSD-style init scripts (ή αντίστροφα).
Αυτό επικρίθηκε από ορισμένους, έλα όμως που προκάλεσε και συζητήσεις στον κόσμο των BSDs για να υλοποιήσουν κάτι αντίστοιχο.
*Το αναφέρω ως αντίθεση με το OpenRC και τα αντίστοιχα.
Όχι, δεν είχα την «ατυχία» (για να ευθυμήσουμε λίγο) καθότι από πιτσιρίκος (σε Linux χρόνια) μέχρι τώρα είμαι «ασύμβατος» με το Debian και γενικότερα τις deb-based διανομές για το desktop μου. Καλά να είναι και να τις χρησιμοποιεί ο κόσμος αλλά εγώ προσωπικά έχω άλλη διαδρομή.
Από το modularity πήγες στην υποστήριξη πολλών OS (κάτι που δεν ανέφερα μέχρι τότε, άλλωστε το θέμα αφορά linux) για να καταλήξεις στο systemd. Εξαιρετικά
Το θέμα αφορά inits και supervisors και δεν υπάρχει κάποια αναφορά στο ότι η όποια συζήτηση αφορά αποκλειστικά το Linux.
Ως προς το modularity, διευκρίνισα παραπάνω τι εννοούσα. Δεν έχω σκοπό να “πάω” κάπου, μια απλή αναφορά ήταν. Αντίστοιχη αναφορά θα μπορούσε να γίνει και για τις διανομές που υλοποίησαν BSD-style init scripts γιατί οι υπάρχουσες λύσεις δεν τις κάλυπταν.
Δεν παρακολουθώ στενά τα BSDs για να σου πω το αποτέλεσμα. Θεωρώ όμως ότι και μόνη η συζήτηση είναι ενδεικτική της αναζήτησης μιας καλύτερης λύσης και δείχνει “υγεία”.
Αν είναι καλοσχεδιασμένο μπορεί. Το OpenRC έχει επεκταθεί ουκ ολίγες φορές. Προσωπικά δεν θα το πρότεινα, καθώς πιστεύω ότι υπάρχουν καλύτερες λύσεις, αλλά αναπτύσσεται και χρησιμοποιείται.
