Obarun - 66 δέντρα και υπηρεσίες και δαίμονες

Όλα τα συστήματα δεν είναι ίδια. Θα βρείτε συχνά τον όρο service και τον όρο daemon. Πολλές φορές δεν υπάρχει διαφορά και άλλες υπάρχει. Σε ορισμένες περιπτώσεις το service είναι ένα ολόκληρο πρόγραμμα που τρέχει κανονικότατα στο background και περιμένει εντολές. Σε άλλες, ο daemon, είναι ένα κομματάκι του προγράμματος αυτού που περιμένει ένα signal (σινιάλο) για να ξεκινήσει το κύριο πρόγραμμα ή να κάνει κάποιες μετατροπές στην λειτουργία του, κλπ,
H αρχή πολλών νέων συστημάτων είναι το daemontools, στο οποίο βασίστηκε το runit, perp, s6, nosh, minit, cinit, ninit, και το anopa που είναι σαν front του s6. To nosh έχει ιδιαίτερο ενδιαφέρον.

Όταν ξεκινάει ένα σύστημα η κύρια λειτουργία είναι να διαβαστεί το σύνολο του πυρήνα (κέρνελ) και να ανιχνευτεί το μηχανικό υλικό (hardware) για να ξέρει το σύστημα τι κάνει τι και που βρίσκεται το κάθε τι. Πληκτρολόγιο και ποντίκι για να μιλάς στο μηχάνημα, γραφικά/monitor/printer για να σου μιλάει αυτό, δίσκοι, κάρτες νέτγουορκ, κλπ. Υπάρχουν διάφορα είδη συστημάτων δίσκων/αρχείων που μπορεί να διαχειριστεί το λίνουξ, fat, ntfs, ext2,3,4, btrfs, zfs (νέο κόλπο με τρομερές επιδόσεις - υπάρχει στήριξη για 100% χρήση zfs στο Obarun) και πρέπει αυτά τα filesystem fs να αναγνωριστούν και να ελεγχθούν ότι είναι σωστά πριν ξεκινήσει το μηχάνημα. Επίσης γίνεται ορισμός της διαχείρισης της μνήμης ram/swap. Για να λειτουργούν όλα αυτά και στο μέλλον και να μην προκύπτουν συχνές βλάβες, ότι κάνει το σύστημα για να ξεκινήσει πρέπει αντίστροφα να το κάνει και στο τέλος για να σταματήσει. Ένα γιγαντιαίο κεφάλαιο του init που υποτιμάται από χρήστες και συχνά ακούγεται το “λίνουξ είναι, και να το βγάλεις απ’την μπρίζα δεν τρέχει τίποτα” … τρέχει … ναι μεν το ext μπορεί και διορθώνει τον εαυτό του καλύτερα από το ntfs, καλύτερα είναι να μην ασκούμε βία πάνω στους δίσκους μας.

Η συνολική αυτή λειτουργία για συντόμευση και περίληψη, προκύπτει στο να ξεκινήσει ένα πρόγραμμα που στην περίπτωση του s6 είναι το s6-svscan

  PID TTY          TIME CMD
    1 ?        00:00:00 s6-svscan

Το s6-svscan βρίσκει από την διαδικασία init ένα υποφάκελο που δημιουργήθηκε ζωντανά στην εκκίνηση /run/66/scandir και μέσα σε αυτό τρέχει ότι του δώσεις. Το runit είναι πολύ παρόμοιο σε αυτό το απλοϊκό στάδιο αλλά τρέχει το ίδιο σαν pid1 και αν μείνει μόνο του δεν μπορεί να ξεκινήσει τίποτα, ούτε shutdown μπορεί να κάνει. To s6-svscan μπορεί να σταματήσει μόνο με την μπρίζα και με το ίδιο του τον δαίμονα που λέγεται s6-shutdown, αλλά αν σταματήσεις όλα τα πρόσες και μείνει μόνο του ξαναξεκινάει το σύστημα κανονικότατα.

Υπάρχει κάπου στο σύστημα ένα σημείο που βρίσκονται αυτά που λέγονται servicefiles, ένα για κάθε σέρβις, πχ /etc/runit/runsvdir/default ή στο 66 το /usr/lib/66/service. Συνδέοντας (ln -s) κάποιο από αυτά στο /run/66/scandir ή στο /run/runit… το service manager τα ξεκινάει. Του runit απλά είναι μια γραμμη που ορίζει την εκτέλεση του προγράμματος. Του 66 είναι υπό την παρακάτω μορφή που συμπεριλαμβάνει το περιβάλον:

cat /usr/lib/66/service/dbus
[main]
@ type = longrun
@ description = “dbus system daemon”
@ user = ( root )
@ maxdeath = 3
@ notify = 4
@ options = ( log env )
@ timeout-up=3000

[start]
@ build = auto
@ execute = (
s6-ipcserver-socketbinder – {socket_dir}/{socket_name}
foreground { dbus-uuidgen --ensure }
execl-cmdline -s { dbus-daemon ${cmd_args} }
)

[stop]
@ build = auto
@ execute = ( s6-rmrf {socket_dir}/{socket_name} )

[logger]
@ build = auto
@ backup = 3
@ maxsize = 1000000
@ timestamp = iso

[environment]
cmd_args=!–system --print-pid=4 --nofork --nopidfile --address=unix:path=/run/dbus/system_bus_socket
socket_dir=!/run/dbus
socket_name=!system_bus_socket

Yπάρχει και μια μεγάλη αδυναμία σε θέμα ασφάλειας αν κάτι δεν πάει καλά με το boot. Ας πούμε έχουμε ένα ssd δίσκο μόνιμα στη μπρίζα και καταγεγραμμένο στο /etc/fstab και το σύστημα ξεκινάει. Αν κάποιος το τραβήξει απ’την πρίζα το runit ξαφνιάζεται με το λάθος και πάει σε emergency mode που αυτόματα είναι root, χωρίς passw. Το 66 πάει στο μοναδικό tty το 12. Στο 12 μόνο σαν user μπορείς να μπεις, όχι σαν root, κάποιος δηλαδή κακόβουλος δεν μπορεί να ανακαλύψει εύκολα και το username και το pass. To tty12 στο 66 είναι από τις βασικές λειτουργείες του boot. Πάντα δηλαδή υπάρχει το αποκούμπι για διάγνωση.

Όταν τελειώσει το boot ξεκινάει να βρει το ενεργό “δέντρο” και τα άλλα δέντρα που στο καθένα από αυτά είναι καθορισμένα διάφορα service/daemons. Το βασικό είναι να έχεις ένα tty1 παραδοσιακά. Στα live του obarun υπάρχει πάντα το βασικό tree root. Σε περίπτωση που το μηχάνημα είναι server και έρχεστε σε επικοινωνία μέσω ssh τι χρειάζονται όλα τα άλλα; Χρειάζεται network, το sshd, κλπ.

Η δημιουργία tree είναι απλή.
% sudo 66-tree -ncE root
Δημιουργεί ένα (n)ew tree το οποίο είναι ©urrent (σημαίνει ότι όταν ενεργοποιήσεις ένα service χωρίς να ορίσεις tree πηγαίνει σε αύτο) και (Ε)nabled - ενεργοποιημένο.
% sudo 66-enable tty@tty1 tty@tty2
ενεργοποιεί το tty1 (με βάση το template tty@) και tty2
% sudo 66-tree -n net
% sudo 66-enable -t net -S dhcpcd ntpd sshd
Φτιάχνει ένα tree το net, ενεργοποιεί τα dhcpcd, ntpd, sshd, και τα ξεκινάει (S)tart.
Αν δούμε τώρα τι τρέχει
% 66-intree
θα μας δείξει το tree boot και τα service του, το tree root και τα tty του, το tree net και τα service του, τα pid τους, την κατάσταση τους, και το log για το καθένα.

Το s6 δεν είναι απαραίτητο να έχει συγκεντρωτικό log service για κάθε είδους service κρατάει ειδικό log μέσω του εργαλείου s6-log. Για κάποια, σαν τα tty δεν χρειάζεται log, για κάποιο είναι χρήσιμα. Όλα είναι σε μορφή text και κάτω από το κλάδο /var/log/66/service_name

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

Γνωρίζετε τι κάνει το acpid, το dbus, το cupsd, και ένα σωρό διαόλοι που τρέχουν ακατάπαυστα σε ένα σύστημα σαν το ubuntu/mint/manjaro κλπ.; Πως τα ελέγχετε, πως κάνετε διάγνωση τι πήγε στραβά όταν το μόνο πράγμα που σας απομένει είναι ένα tty (και άν!); Το runit και ακόμα περισσότερο το 66 σας δίνει πλήρως τον έλεγχο και την διαμόρφωση του συστήματος και γρήγορη και εύκολη διάγνωση. Βέβαια αν δούμε το μοναδικό image/iso που παράγει επίσημα η arch και το ξεκινήσουμε, δεν τρέχει και πολλά πράγματα, είναι λιτό και σπαρτιάτικο. Απ’την στιγμή που κάνεις εγκατάσταση το openntp και το cups αυτά αυτόματα πέρνουν μπρος και δουλεύουν. κλπ κλπ. To systemd έχει αλυσιδοτά δεσμευμένα service και το ένα ξεκινάει το άλλο. Tου λες να σταματήσει κάτι και αυτόματα κάποιος άλλος δαίμονας το ξαναξεκινάει. Tρέχα γύρευε. Αν κάνει crash το Χ τρέχα γύρευε στην κυριολεξία να μάθεις τι πήγε στραβά και προκάλεσε το λάθος. Tα logs είναι σε περίεργη μορφή, όχι απλό τεξτ. Το systemd είναι σκουπιδιάρικο και σκουπιδοφάγος, ότι κι αν χαλάσει το ξαναξεκινάει χωρίς να δείνει σημασία τι τρέχει, γιατί κάτι σταμάτησε, και θεωρώντας ότι το σύστημα έχει απεριόριστους πόρους μπορεί να ξεκινάει ένα σπασμένο πρόγραμμα 30 φορές το λεπτό, να γράφει λογκ, και να το τρέχει έστω και για κλάσματα του δευτερολέπτου, ή μέχρι να γεμίσει ο δίσκος από άχρηστα log. Η χαρά του μαλάκα sys-admin δηλαδή. Σε κάποια στιγμή κλείνεις τα προγράμματα που τρέχεις όλη μέρα και κοιτάς το ram και έχει φλομώσει στο σκουπιδαριό, δεν έχεις πάρει χαμπάρι ότι κάτι τρέχει και που βα βρεις άκρη από το …!

Μια ωραία απεικόνιση του συστήματος σε κάθε στιγμή είναι το
% pstree -a

% sudo 66-intree root
% sudo 66-inservice -p14 dhcpcd

To πρώτο δίνει πληροφορίες για το tree root, το δεύτερο δίνει πληροφορίες για την κατάσταση του service dhcpcd και το -p14 του λέει να μας διαβάσει τις τελευταίες 14 γραμμές από το ειδικό log του dhcpcd.

3 Likes

Γιατί πιο πάνω γράφω % sudo 66-intree και όχι απλά % 66-intree, τι διαφορά έχει;
Τα περισσότερα συστήματα τρέχουν services/daemons σαν root μόνο, όχι σαν απλοί user. Το 66 μπορεί να φτιάχνει trees από services και σαν user. To ένα διαβάζει το s6-svscan από το /run/66/scandir/0 για τον user 0 που είναι ο root, το άλλο διαβάζει το /run/66/scandir/1000 ή όποιο άλλο νούμερο είναι κάποιος user του συστήματος. O καθένας δηλαδή μπορεί να τρέχει επιπλέον δικά του για το desktop του. Παράδειγμα πιο κάτω είναι το σύνηθες για περίπλοκα desktops του dbus σαν συγκεκριμένο user, ανεξάρτητο με το dbus του κύριου συστήματος, και με δικό του log.

/usr/lib/66/service/dbus-session@
[main]
@ type = longrun
@ description = "dbus session daemon for @I user"
@ user = ( user )
@ maxdeath = 3
@ notify = 4
@ options = ( log env )
@ timeout-up=3000

[start]
@ build = auto
@ execute = (
execl-subuidgid -o @I
s6-ipcserver-socketbinder -- ${socket_dir}/${socket_name}
execl-cmdline -s { dbus-daemon ${cmd_args} }
)

[stop]
@ build = auto
@ execute = (
execl-subuidgid -o @I
s6-rmrf ${socket_dir}/${socket_name}
)

[logger]
@ build = auto
@ backup = 3 
@ maxsize = 1000000
@ timestamp = iso

[environment]
cmd_args=!--session --print-pid=4 --nofork --nopidfile --address=unix:path=/run/user/${UID}/dbus
socket_dir=!/run/user/${UID}
socket_name=!dbus

το ανάλογο του runit τρέχει μόνο σαν root και είναι αυτό:

/etc/sv/dbus/run 
#!/bin/sh
[ ! -d /run/dbus ] && install -m755 -g 22 -o 22 -d /run/dbus
exec dbus-daemon --system --nofork --nopidfile

Για να λειτουργήσει ένα desktop σαν το Mate, το lxqt, kde, κλπ πρέπει να τρέχει το dbus, το elogind ή το consolekit ή το systemd που κάνει τα πάντα για όλους και για όλα σαν root και σαν user, σχεδόν ανεξέλεγκτα.
Κανείς άλλος δεν διαχωρίζει και δεν μπορεί να διαχειριστεί user services. Το 66 μόνο, νομίζω! Μαθαίνουμε και πάμε.

Προσωπικά δε χρεισιμοποιώ ούτε dbus, ούτε elogind, ούτε consolekit, ούτε networkmanager, ούτε pulseaudio, παρά μόνο το dhcpcd για νέτγουορκ, το ntpd για την ακρίβεια της ώρας, 1-2 tty, και το openbox ή εναλλακτικά i3, jwm, και όταν χρειάζομαι κάποια ειδική λειτουργία ενεργοποιώ το tree με τα συγκεκριμένα σέρβις, κάνω την δουλειά μου, και το απενεργοποιώ. Π.Χ. έχω ένα tree που έχει dbus και cupsd και το ονομάζω print.

% sudo 66-all print up
% sudo 66-all print down

μπορείς να γράψεις κι 2 σκριπτ printon printoff που να έχουν σε συντομία αυτά τα command.

Window Manager στο Obarun

Κατεβάζεις το servicefiles για το sddm, lxdm, lightdm και το τρέχεις σαν service, ίσως στο root tree.

% sudo pacman -S sddm-66serv
% sudo 66-enable -t root -F -S sddm

To σύστημα σας από εδώ και πέρα θα κάνει boot και θα πηγαίνει στο login screen του sddm όπου κάνετε login και επιλέγετε το desktop που θέλετε. Οπτικά δεν έχει διαφορά από το antergos (σχωρεμένο να’ναι) με sddm και kde-plasma με το obarun, αλλά η διαφορά τους κρύβεται κάτω απ’το καπό και στο πόσο ram και πόσο cpu καταναλώνουν, πως μπορείς να κάνεις διάγνωση όταν κάτι δεν λειτουργεί σωστά.

α για αυτο εχεις τοσο χαμηλη καταναλωση.
προκυπτουν αρκετες αποριες απο τα παραπανω παντως κυριως για το s6, αν καταφερω να τις ταξινομησω καποια στιγμη θα ρωτησω.

Αν συγκρίνεις το μέγεθος του κώδικα του runit του s6 και του systemd καταλαβαίνεις περισσότερα για την κατανάλωση :slight_smile: Κάτι σαν ποδήλατο, μοτοσυκλέτα, αεροπλανοφόρο (στην ίδια σειρά),

http://skarnet.org/software/s6/
http://smarden.org/runit/

Όλα αγγλικά προς το παρόν, αλλά υπάρχει μπόλικο υλικό για τους λάτρεις

Ο Αίνστάϊν είχε πει ότι ένα σύστημα πρέπει να σχεδιάζεται όσο πιο απλό γίνεται, ποτέ πιο απλό!! Hint hint :slight_smile:

λοιπον για πες μας λιγο περισσοτερα για αυτο αν θες…

Μπορείς αν θες να φτιάξεις ένα service file για το syslog-ng το socklog ή το metalog και να συγκεντρώνουν όλα τα logs σε ένα αρχείο όπως στα περισσότερα συστήματα (εκτός του systemd που έχει εσωτερικό το journald). Με βάση το s6-log κάθε σέρβις μπορεί να έχει δικό του log, για κάποια είναι ανόητο να έχουν log, όπως τα tty. Τα service-scripts του 66 εμπεριέχουν την λειτουργία αυτή, όταν ενεργοποιείς για παράδειγμα το dhcpcd αυτόματα στο /var/log/66 υπάρχει ένας υποφάκελος για το dhcpcd κι εκεί υπάρχει το log του.

H εντολή πληροφοριών για τα σέρβις 66-inservice με την παράμετρο -p και τον αριθμό γραμμών που ορίζεις σου τις τελευταίες γραμμές του log
ΠΧ

% sudo 66-inservice -c -g -p6 dbus
Name               : dbus
In tree            : print
Status             : enabled, up (pid 27874) 1 seconds, ready 1 seconds
Type               : longrun
Description        : dbus system daemon
Source             : /usr/lib/66/service/dbus
Live               : /run/66/tree/0/print/servicedirs/dbus
Depends on         : /
                     └─(27870,Enabled,longrun) dbus-log
Start script       : s6-ipcserver-socketbinder -- ${socket_dir}/${socket_name}
                     foreground { dbus-uuidgen --ensure }
                     execl-cmdline -s { dbus-daemon ${cmd_args} }
Stop script        :  s6-rmrf ${socket_dir}/${socket_name} 
Environment source : /etc/66/conf/dbus
Environment file   : 
                     cmd_args=!--system --print-pid=4 --nofork --nopidfile --address=unix:path=/run/dbus/system_bus_socket
                     socket_dir=!/run/dbus
                     socket_name=!system_bus_socket
Log name           : dbus-log
Log destination    : /var/log/66/dbus
Log file           :
2019-07-30 11:18:11.920452500  dbus-daemon[24155]: [system] Successfully activated service 'org.freedesktop.ColorManager'
2019-09-21 11:02:26.504289500  dbus-daemon[929]: [system] Reloaded configuration
2019-09-21 11:02:26.514486500  dbus-daemon[929]: [system] Reloaded configuration
2019-10-02 12:09:13.131884500  dbus-daemon[31680]: [system] Activating service name='org.freedesktop.ColorManager' requested by ':1.0' (uid=0 pid=31656 comm="cupsd -f ") (using servicehelper)
2019-10-02 12:09:13.276676500  dbus-daemon[31680]: [system] Successfully activated service 'org.freedesktop.ColorManager'

συνέχεια η πληροφορίες για το tree print που εμπεριέχει το dbus και το cupsd είναι αυτές:

% sudo 66-intree -c -g -d 20 print
Name        : print
Initialized : yes
Enabled     : no
Current     : no
Contents    : /
              ├─(27870,Enabled,longrun) dbus-log
              ├─(27874,Enabled,longrun) dbus
              │ └─(27870,Enabled,longrun) dbus-log
              ├─(27850,Enabled,classic) cupsd-log
              └─(27851,Enabled,classic) cupsd
                └─(27850,Enabled,classic) cupsd-log

initialized είναι επειδή επέλεξα να ενεργοποιήσω το tree
Enabled θα ήταν άν ήθελα γράφοντας % sudo 66-tree -E print και αυτό θα το έκανε να ξεκινήσει κάθε φορά που ξεκινάει το σύστημα,
Current: σημαίνει ότι άν ενεργοποιήσω οποιοδήποτε service θέλω που είναι ανενεργό θα ενταχθεί σε αυτό το tree αν δεν προσδιορίσω σε ποιό συγκεκριμένα να ενταχθεί.

Μην φοβίζουν όμως οι δυνατότητες, αν κάνεις εγκατάσταση plasma πχ και κάνεις boot όλα λειτουργούν όπως πρέπει. Πρέπει να θέλεις να ασχοληθείς και να τροποποιήσεις κάτι για να χρειαστούν οι ιδιαίτερες γνώσεις του 66/s6 . Aν δηλαδή δεν σου αρέσει το sddm και θέλεις να χρησιμοποιήσεις το lightdm θα πρέπει να ξέρεις να γράψεις την εντολή

% sudo 66-disable -t displaymanager -S sddm
% sudo 66-enable -t displaymanager -S lightdm

και μπάμ! Το σύστημα παύει να χρησιμοποιεί το sddm και από εδώ και πέρα χρησιμοποιεί το lightdm, δεδομένο ότι και τα δύο είναι εγκατεστημένα.
Απλό, δύσκολο, … ???
Αν για κάποιο λόγο κάτι δεν πάει καλά, κάνεις login και το DM δεν ανταποκρίνεται, ή έχει κολλήσει και δεν κάνει τίποτα Ctrl-Shift-F12 login σαν user, % sudo 66-inservice -p 20 lightdm και θα σου πει τι πρόβλημα αντιμετωπίζει.

α ok. Τωρα βλεπω με ποιο τροπο υλοποιει τη φιλοσοφια του unix το s6. Eπισης μου ελυσες και την επομενη απορια που ειχα (δηλαδη με ποιο τροπο καλεις τα srevice και daemons αφου δεν καλεις systemctl).
Mε τα προγραμματα που εχουν το systemd σαν εξαρτηση τι κανει το obarun και εσυ; πχ υπαρχει αντιστοιχο σκριπτακι σαν του antix;

ψιλοσχετικο, ψιλοασχετο το s6 θυμιζει κατα καποιον τροπο το ή μου φαινεται; (αυτο ειναι καπως ρητορικη ερωτηση για οποιον εχει υποψιν)

Το 5σ δε νομίζω ότι έχει σχέση, το daemontools έχει σχέση σαν έμπνευση, δεν μοιράζεται κώδικα. Η γενική λογική και το signaling που υιοθέτησαν είναι το κοινό σημείο.

Το systemd έχει κατηγορηθεί βασικά και γενικά ότι είναι κακογραμμένο σε σχέση με τον λόγο που γράφτηκε. Δηλαδή δημιουργήθηκε να κάνει μια δουλειά και στον δρόμο υιοθέτησε κι άλλες, κι άλλες, κι άλλες. Ζητάς βραστήρα για το ρύζι και αυτό σου φτιάχνει καφέ, στύβει χυμούς, ξεσκονίζει τον πάγκο, … κι εσύ ένα ρυζάκι ήθελες μόνο να φτιάξεις. Η συχνότερη συσχέτιση προγραμμάτων με το systemd είναι το logind που εμπεριέχει, να διαχειρίζεται ποιός και με τι δικαιώματα τρέχει τι και έχει σε τι πρόσβαση.
Κάποιες διανομές έχουν κόψει το logind μέσα απ’τον κώδικα του systemd και το ονομάζουν elogind, κι έτσι καλύπτουν μεγάλο φάσμα των αναγκών. Το obarun, και το antix, και το void, σε διαφορετικό βαθμό επέλεξαν να χρησιμοποιήσουν το ανεστημένο consolekit που του προστέθηκε ένα 2 στο τέλος για διαφοροποίηση (ck2) και ψάχνουν τον κώδικα του κάθε κοινού πακέτου για εξαρτίσεις σε logind και το μεταφέρουν με παρόμοια λειτουργία στο consolekit2. Το antix και το void πρόσθεσαν και το ίδιο το elogind στα rep/s αλλά δεν εξαρτύονται απο αυτό. Έτσι μπορείς να προσθέσεις προγράμματα από άλλες πηγές που έχουν αυτή την εξάρτιση χωρίς να χρειάζεται να τα κάνεις patch για ck2.

To obarun βράχος :slight_smile: NIET!! ck2 και πολύ σας πάει, αλλιώς τα κουβαδάκια και να πάτε στους “ρεφορμιστές”. To pacman με μιά πρόσθετη εντολή απαγορεύει και την εγκατάσταση και την χρήση των systemd/systemd-libs ή την διαμόρφωση libstystemd που παράγεται, Για ότι προκύψει στους χρήστες λόγω αλλαγών στο arch το πακέτο ξαναγράφεται για χρήση με s6 ή ck2.

Η λίστα των παρόμοιων πακέτων έχει μεγαλώσει αλλά ακόμα είναι μια 100στη περίπου, το arch δεν είναι debian/ubu/min να χώνει το systemd παντού. Πρέπει να χρειάζεται άμεσα. Το artix έχει φτάσει να χρησιμοποιεί με δικό του τρόπο σχεδόν τα μισά πακέτα του arch, σε δικά του repositories δηλαδή και η προοπτική είναι κάποτε να απεξαρτηθεί και να είναι ανεξάρτητο από το arch. Έχει elogind όπως το devuan, το mx, κλπ με την προοπτική ότι κάποτε θα κάνει ομαλή την μετάβαση στο wayland που λένε θα αντικαταστήσει το X. Αυτά να τα δείτε εσείς παιδιά μου, εγώ καλύτερα να μην τα προλάβω :slight_smile:

Αυξάνονται οι διανομές συνεχώς που υιοθετούν το musl αντί του glibc (C libraries). Το glibc είναι μια τεράστια βάση δεδομένων που στηρίζονται οι κώδικες των προγραμμάτων. Όσο περνούσαν τα χρόνια αντί να διορθώνουν τα λάθη που υπήρχαν εξαρχής, έφτιαχναν μπαλώματα. Έχει φτάσει η μαούνα να ζυγίζει 8 φορές περισσότερο και οι 7 είναι μπαλώματα. Το musl δημιουργήθηκε ώστε να μην υπάρχουν λάθη, αυστηρά να διορθώνεται από το μηδέν η σχεδίαση αν βρεθεί κάτι. Είναι μικρότερο και τα προγράμματα τρέχουν σφαίρα και είναι τα ίδια μικρότερα σε μέγεθος μετά το compiling. Αισθητή η διαφορά! Στο adelie έχω Χ, οpenbox, και κάποια βασικά προγράμματα, και το σύνολο δεν έχει μπορέσει να καταλάβει το 1GB χώρου στο δίσκο. Το βασικό arch/obarun χωρίς Χ είναι 1.6GB νομίζω.

Τι σημαντικό έχει το musl ? Με καμία δύναμη δεν πάει το systemd σε αυτό. Είναι τόσο μεγάλος και περίπλοκος ο κώδικας που θα ήταν σαν να ξαναγραφτεί απ’την αρχή και τμήμα του αν δεν κάνω λάθος είναι σε c++ όχι C. Ένας που τελευταία υιοθέτησε το 66 σε void όπως έκανε τα πακέτα compile στο glibc τα έκανε και στο musl, καμιά διαφορά. 100% portable, και για BSD και για άλλα unix. Σε κάποια στιγμή που το musl θα πλησιάζει την πληρότητα του glibc, άντε γειά systemd, στα σκουπίδια για πάντα! Η debian έχει αρχίσει και το σκέπτεται καθώς και επανεξετάζει και την ελευθερία init και ξανακοιτάει το αρχαίο το sysv να ξαναλειτουργεί με το debian, λένε, γιατί έχουν βαρεθεί το κράξιμο.

χαχα καλο. εγω λοιπον που χρησιμοποιω mx ειμαι σιγουρα ρεφορμιστης οπως φαινεται :slightly_smiling_face:

και ολα εχουν ξαναγραφτει με s6 ή ck2, ή απλως δεν μπορεις να τα χρησιμοποιησεις; και μια και το εφερε η κουβεντα με τα appimage αν θες, ολα ok;


το 6σ δεν εχει σχεση με υπολογιστες, εχει ομως να κανει με διαχειριση πορων και λειτουργιων για παραδειγμα.

[quote=“raik, post:12, topic:1233”]

αλλιώς τα κουβαδάκια και να πάτε στους “ρεφορμιστές”

χαχα καλο. εγω λοιπον που χρησιμοποιω mx ειμαι σιγουρα ρεφορμιστης οπως φαινεται :slightly_smiling_face:[/quote]

Μη με πιέζεις και ξεφύγω :slight_smile:
Η αλήθεια είναι ότι άν ένας χρήστης χρησιμοποιήσει το mx και δει ότι μια χαρά δουλεύει το μηχάνημα χωρίς το systemd για init, έχει γίνει ένα πρώτο βήμα. Καμμίά σχέση με τυχαία κόμματα περασμένης 4ετίας. 0 σχέση!

Για το s6 δεν υπάρχει κάποια συσχέτιση, ίσως λάθος που το ανέφερα, κάνει την δουλειά του και δε πα να τρέχεις ότι θες. Για τα service/daemons κλπ γράφονται επιπρόσθετα service files που τα ορίζουν που και πως τρέχουν. Δηλαδή θες να χρησιμοποιήσεις το wicd κάνεις εγκατάσταση το wicd-66serv το οποίο σαν dependency θα φέρει και το wicd από το arch. Εκτός δηλαδή από sw που τρέχουν σαν service/daemon τα άλλα δεν έχουν καμιά σχέση με το s6 και 66. Το wicd δεν ξέρει ποιός τα ξεκινάει, τα παρακολουθεί αν εξακολουθούν να λειτουργούν, κάνει log το output που βγάζουν και ποιός τα βάζει για νανάκια όταν δεν χρειάζονται, ή το systemd το κάνει ή το s6 δεν τα νοιάζει. Αν ξεκινήσεις το X και ανήξεις ένα τερμιναλ και τρέξεις το wicd μπορείς να ρίχνεις καμιά ματιά που και που αν βγάζει κάποιο output, χάνει την σύνδεση κλπ. Ίσως να είναι το ίδιο αποτέλεσμα. Σε κάποια χρειάζονται κάποιοι ειδικοί παράμετροι πρόσθετα από το πρόγραμμα. Σημαντικό για το 66 είναι η διαμόρφωση περιβάλλοντος μέσα στο οποίο τρέχουν.

1 Like

Πραγματικά δεν ξέρω πως έβγαλες αυτά τα συμπεράσματα. Κατ αρχάς το libc είναι μια βασική βιβλιοθήκη που θέλει κάθε πρόγραμμα C για να τρέξει. Επειδή η C είναι η γλώσσα υλοποίησης οτιδήποτε άλλου, πρακτικά κάθε πρόγραμμα που τρέχει απαιτεί να συνδεθεί με αυτή την βιβλιοθήκη.

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

Και βλέπουμε το glibc που έχουν όλες σχεδόν οι διανομές να είναι 7.9Μ έναντι των μόλις 185Κ της dietlibc. Άρα χρησιμοποιώντας την τελευταία θα έχουμε τεράστιο κέρδος σε μνήμη. Αν πχ τρέχω 100 προγράμματα το κέρδος μου θα είναι 100 * 1.7Μ σωστά; Λάθος!

Η βιβλιοθήκη libc είναι μια δυναμικά συνδεμένη βιβλιοθήκη.
Και μια δυναμικά συνδεμένη βιβλιοθήκη υπάρχει μόνο μια φορά στην μνήμη.

Το κέρδος θα είναι λοιπόν μόλις 7.7Μ κάτι που ακόμα και σε ένα μηχάνημα με ελάχιστη μνήμη είναι ένα ουσιαστικά αμελητέο ποσό. Πόση στην πραγματικότητα είναι η διαφορά; Θα το δούμε στο Dynamic Overhead που αν διαβάζω σωστά είναι το στατικό κομμάτι κάποιας βιβλιοθήκης. Και η διαφορά μετριέται σε KB!! Έχουμε πάψει να θεωρούμε σημαντικά τέτοια μεγέθη κάπου στα μέσα της δεκαετίας του 80 όταν περάσαμε στα 16 bit (Σήμερα δε έχουμε 64).

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

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

Αλλά έστω και έτσι ποιος ο λόγος που υπάρχει αυτή η τεράστια διαφορά;

Η διαφορά μεταξύ τους είναι στην χρήση που έχει φτιαχτεί κάθε μια βιβλιοθήκη. Κάποιες φορές θέλεις μια μικρή υλοποίηση της βιβλιοθήκης και θέλεις απλά μια ελάχιστη C/POSIX συμβατότητα. Ένα τυπικό τέτοιο παράδειγμα είναι μια διανομή βάσης για ειδικές εφαρμογές, όπως για παράδειγμα το Alpine Linux, ή στην κονσόλα ανάκτησης όταν το σύστημα τα φτύσει και δεν μπορεί να ξεκινήσει. Εκεί θέλεις μικρά προγράμματα με στατική σύνδεση και μια μικρή τέτοια βιβλιοθήκη είναι ότι πρέπει.

Και άλλες φορές έχεις ένα πλήρες σύστημα server ή desktop. Εκεί θέλεις πολλές δυνατότητες. Μια απλή βιβλιοθήκη θα κοιτάζει αν ο κωδικός του χρήστη είναι στο αρχείο /etc/shadow μια πλήρης λύση θα μπορεί να ρυθμιστεί να κοιτάζει σε μια βάση δεδομένων. Η μπορεί να αλληλεπιδρά με το σύστημα PAM και να σε αφήνει να συνδεθείς μόνο ώρες γραφείου. Αυτά λογικά θα έχουν επίδραση στον χώρο που καταλαμβάνουν, που όμως είναι όπως είδαμε εντελώς αδιάφορος. Στο σημαντικό στις ταχύτητες εκτέλεσης των εφαρμογών δεν υπάρχει καμία ιδιαίτερη διαφορά στην πραγματικότητα και αυτό μετράει.

Αλλά επειδή κάποιοι θέλουν να βλέπουν νούμερα. Στον ίδιο πίνακα θα δούμε πως σε ότι έχει σημασία το glibc έχει διπλάσια ταχύτητα από το musl. Για κάποιον ορισμό του τι είναι σημαντικό τέλος πάντων. Αλλά στην πράξη κάθε προγραμματιστής ξέρει πως μικρή σημασία έχει στην πράξη αυτό. Έστω ότι μια libc είναι δυο φορές ποιο γρήγορη από μια άλλη. Αυτό δεν θα κάνει ένα πρόγραμμα που την χρησιμοποιεί δυο φορές ποιο γρήγορο. Στην πράξη το πόσο ποιο γρήγορο θα είναι θα καθοριστεί από κάποιο νόμο που θα περιορίσει κατά πολύ το όφελος.