Antix και λοιπές "ελαφριές" διανομές "χωρίς systemd"

[asfodelus]

9 λεπτά πριν, nick0lis είπε

δεν χρειάζεται να φτιάξεις fstab βρίσκει το id του δίσκου, μάλλον από το bios;

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

Εχω γράψει σχετικά ένα μικρό σημείωμα  εδώ και εδώ, αν θέλεις περισσότερες τεχνικές πληροφορίες. Υπόψιν, τα κείμενα είναι ενός έτους παλιά, τότε που άρχισα να ψάχνω για τον αν δικαιολογείτε ο θόρυβος ενάντια στο systemd και να καταγράφω ότι έβρισκα. Σήμερα ίσως να τα έγραφα αλλιώς

Επεξ/σία 30 Μαΐου 2021 από asfodelus

[imitheos]

44 λεπτά πριν, asfodelus είπε

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

Εν μαίρη έχεις δίκιο, εν τάσο όμως όχι. Πολλές φορές γίνεται αυτό που λες, γκουχ γκουχ βλέπε debian και cdrkit, iceweasel ή όπως λεγόταν το fork του firefox, κτλ. Σε αυτή την περίπτωση όμως δεν έγινε έτσι. Έχω την εντύπωση ότι "έσπασαν" τον κώδικα και τον ονόμασαν elogind για το hurd ή το nix ή κάποιο άλλο που δεν μπορεί να έχει systemd. Καλώς ή κακώς, τα DEs χρησιμοποίησαν το login provider κομμάτι του systemd. Έτσι έπρεπε να ή να δημιουργηθεί ένας άλλος login provider που να "μιλάει" το ίδιο πρωτόκολλο για όσους δεν μπορούν να έχουν systemd ή να γίνει "fork" ο κώδικας σπάζοντάς τον.

Κατά τη γνώμη μου, αν γραφόταν από το μηδέν ένας νέος login provider θα ήταν ουσιαστικά αυτό που λες. Εκείνο το εγχείρημα θα ήταν για να λέμε ότι δεν έχουμε systemd. Εδώ το "fork" ήταν προτιμότερο γιατί δεν σπαταλήθηκαν ώρες και απλά παίρνουν ένα υποκατάλογο του systemd και τον πακετάρουν ξεχωριστά.

44 λεπτά πριν, asfodelus είπε

Β. Πως δεν έχει καθίσει κανένας σοβαρά να φτιάξει μια εναλλακτική και αξιόπιστη λύση που να παρέχει στους κατασκευαστές desktop environments τις υπηρεσίες που ζητάνε και απλά τα βρίζουν σαν πουλημένα

Αξιόπιστη δεν ξέρω αλλά πριν το logind είχαμε τα *kit τα οποία χρησιμοποιούνταν από τα DE οπότε δεν ισχύει αυτό που λες ότι δεν κάθονται να κάνουν κάτι εναλλακτικό και απλά βρίζουν. Ο systemd ενσωμάτωσε τον κώδικα (βελτιώνοντας τον δεν αντιλέγω) των παλαιών αυτών λύσεων. Πέρα από αυτό, ποιος σου λέει ότι δεν το έκανε κάποιος; Υπήρχαν εναλλακτικές των *kit αλλά κανένας "κατασκευαστής DE" δεν μπήκε στον κόπο να τις ενσωματώσει γιατί υπήρχαν τα *kit. Ο systemd ενσωματώθηκε λόγω πίεσης από redhat όχι επειδή οι devs των DE λάτρεψαν τις καταπληκτικές του λειτουργίες (για να μην παρεξηγηθώ δεν λέω ότι δεν είναι καλός)

44 λεπτά πριν, asfodelus είπε

Γ. Το ίδιο το systemd δεν είναι καθόλου μονολιθικό και απόδειξη για αυτό είναι το πόσο  εύκολα μπορεί να βγει απέξω το logind και το udev. Nομίζω μπορείς να το κάνεις απλά με compile flags χωρίς τίποτα άλλο. Έχω δει σε φορουμ του ArtiX να διαφημίζουν ακριβώς αυτό για ένα υποσύστημα, ως "απελευθέρωση", χωρίς καν να αλλάξουν μια γραμμή κώδικα...  😄😄

Για το logind (και σε κάποιο βαθμό και για το udev) ισχύει αλλά δεν είναι έτσι για όλα τα υποσυστήματα. Κάποια είναι απλά "interfaces" στον δαίμονα που του "μιλάνε" και κάνει αυτός την δουλειά οπότε δεν μπορούν όλα να βγουν έξω τόσο εύκολα. Συμφωνώ στο κομμάτι ότι να πάρεις τον κώδικα και να είναι αυτούσιος απλά με άλλο όνομα δεν είναι απελευθέρωση.

[Επισκέπτης]

Δύο μικρά σχόλια για τα θέματα που συζητούνται: αρχικά, όλες οι anti-systemd (δεν είναι απλά "non-systemd", ας μην κοροϊδευόμαστε) διανομές διαπνέονται από μια γενικότερη αναχρονιστική νοοτροπία, με αποτέλεσμα να υπάρχουν παραλείψεις και λάθη στον τρόπο που δομείται η διανομή, στα πακέτα που επιλέγονται και στο πώς αυτά συνδυάζονται μεταξύ τους κλπ. Γι' αυτό και εμφανίζουν προβλήματα όπως αυτά που αναφέρθηκαν πιο πάνω.

Βλέπω να παρουσιάζονται ως "νέες" διανομές που είναι λες και είμαστε πίσω στο 2010, ενώ το Linux έχει προχωρήσει τόσο πολύ μπροστά.

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

[asfodelus]

2 λεπτά πριν, imitheos είπε

Υπήρχαν εναλλακτικές των *kit αλλά κανένας "κατασκευαστής DE" δεν μπήκε στον κόπο να τις ενσωματώσει γιατί υπήρχαν τα *kit.

Που όμως είχαν σταματήσει να αναπτύσσονται, δεν είχαν καλή υποστήριξη για seat managment και καμία υποστήριξη για cgroups. Ελπίζω να μην γίνομαι κουραστικός με το self promotion, αλλά έχω μεταφέρει στα ελληνικά τα κύρια μέρη ενός κειμένου για "Μια σύγχρονη διαχείριση διεργασιών για την επιφάνεια εργασίας" που αξίζει πιστεύω να διαβαστεί και μπορεί να βρεθεί εδώ. Υπάρχει κάποιος που δεν θα ήθελε κάτι τέτοιο στον υπολογιστή του; Επίσης έχω γράψει αρκετά για τα cgroups που τα ακούμε αλλά πολλοί δεν έχουν καταλάβει τι είναι.

Στα αρνητικά είναι πως παίζουμε με api που είναι Linux Specific. Δηλαδή θα είναι όλο και ποιο δύσκολο για τα BSDs να ενσωματώσουν τα επόμενα γραφικά περιβάλλοντα και στην καλύτερη να τα τρέχουν με μειωμένες δυνατότητες. Προσωπικά δεν με ενδιαφέρει στο ελάχιστο, αλλά κατανοητός ο προβληματισμός.

[Επισκέπτης]

6 λεπτά πριν, imitheos είπε

Ο systemd ενσωματώθηκε λόγω πίεσης από redhat όχι επειδή οι devs των DE λάτρεψαν τις καταπληκτικές του λειτουργίες

Εδώ είσαι αδιάβαστος. Δε θα μιλήσω για άλλες διανομές αλλά θα σου πω για αυτήν που ξέρω και χρησιμοποιώ πολλά χρόνια και που σίγουρα "doesn't give a flying f*ck" για τη Red Hat ή την πίεση από οποιονδήποτε.

Ο άνθρωπος λοιπόν που συντηρούσε τα init scripts της διανομής έχει δώσει μια ολοκληρωμένη απάντηση εδώ. Διάβασέ τη σε παρακαλώ και κρίνε μόνος σου αν είναι επαρκώς τεκμηριωμένη και αν διαφαίνεται οποιαδήποτε πίεση.

[imitheos]

3 λεπτά πριν, Soulrain είπε

Εδώ είσαι αδιάβαστος. Δε θα μιλήσω για άλλες διανομές αλλά θα σου πω για αυτήν που ξέρω και χρησιμοποιώ πολλά χρόνια και που σίγουρα "doesn't give a flying f*ck" για τη Red Hat ή την πίεση από οποιονδήποτε.

Ο άνθρωπος λοιπόν που συντηρούσε τα init scripts της διανομής έχει δώσει μια ολοκληρωμένη απάντηση εδώ. Διάβασέ τη σε παρακαλώ και κρίνε μόνος σου αν είναι επαρκώς τεκμηριωμένη και αν διαφαίνεται οποιαδήποτε πίεση.

Ίσως δεν το διατύπωσα σωστά αλλά δεν μιλούσα για τα init scripts των διανομών. Μιλούσαμε για τα DE και το logind κομμάτι του systemd για αυτό έγραψα "οι devs των DE".

Όσον αφορά το Arch, δεν είναι και τόσο καλό επιχείρημα αυτό που θα πω, αλλά το γεγονός ότι ο systemd κυριαρχούσε (λόγω περάσματός του σε fedora, opensuse, κτλ) δεν επηρρέασε καθόλου την επιλογή του dev; Δεν θεωρείς καθόλου πιθανό να έπαιρνε ένα από τα άλλα init systems που λέει ότι έλυναν πολλά από τα προβλήματα και να βοηθούσε στο να λυθούν και τα λίγα που δεν είχαν λυθεί;

[Επισκέπτης]

5 λεπτά πριν, imitheos είπε

το γεγονός ότι ο systemd κυριαρχούσε (λόγω περάσματός του σε fedora, opensuse, κτλ) δεν επηρρέασε καθόλου την επιλογή του dev; Δεν θεωρείς καθόλου πιθανό να έπαιρνε ένα από τα άλλα init systems που λέει ότι έλυναν πολλά από τα προβλήματα και να βοηθούσε στο να λυθούν και τα λίγα που δεν είχαν λυθεί;

Το Arch ξεκίνησε να ενσωματώνει το systemd το 2012, αρκετά πριν αυτό "κυριαρχήσει" (η χρήση του από δύο διανομές δεν είναι "κυριαρχία", προφανώς). Δεν είμαι απόλυτα βέβαιος αλλά νομίζω ότι είχε πλήρη υποστήριξη για το systemd πριν από το openSUSE.

Ως προς το κομμάτι της επιρροής γενικότερα, μπορώ να σου πω με βεβαιότητα ότι οι αποφάσεις στο Arch λαμβάνονται με κύριο γνώμονα την τεχνική αρτιότητα και τη δυνατότητα υποστήριξης από τη διανομή. Δεν τους απασχολεί τι κάνει ποιος, τι ζητάει κάποιος άλλος και αν οι ίδιοι πάνε κόντρα σε όλους. "Φημίζονται" άλλωστε για αυτό.

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

[asfodelus]

28 λεπτά πριν, imitheos είπε

Όσον αφορά το Arch, δεν είναι και τόσο καλό επιχείρημα αυτό που θα πω, αλλά το γεγονός ότι ο systemd κυριαρχούσε (λόγω περάσματός του σε fedora, opensuse, κτλ) δεν επηρρέασε καθόλου την επιλογή του dev;

Σε ένα μικρό η μεγάλο βαθμό αυτό ισχύει για οπουδήποτε νέα τεχνολογία. Δημιουργείτε μια νέα λύση που είναι καλύτερη (αλλά ποτέ τέλεια) από μια προϋπάρχουσα, κρατάει μια ικανοποιητική συμβατότητα προς τα πίσω, και βοηθάει τον προγραμματιστή στις υπάρχουσες εργασίες ενώ δίνει δυνατότητα να κάνει επιπλέον πράγματα. Και σιγά σιγά το ένα project μετά το άλλο το χρησιμοποιούν ως εξάρτηση. Η μόνη διαφορά είναι πως σε άλλες τεχνολογίες (ας πούμε πχ το cups) δεν δημιουργήθηκε κανένα anti-cups κίνημα.

Η καρδία του systemd είναι μια σειρά απο api που μπορεί να τα υλοποιήσει όποιος θέλει. Αλλά ολα τα anti-systemd μένουν κολλημένα στο παρεθόν και σε μηχανήματα χρέπια. Αν είχαν στραφεί στο μέλλον, στην υποστήριξη αυτών που παρέχει ο πυρήνας, θα ήταν μια καλή εναλλακτική που να δικαιολογεί ένα technical  debt. Αλλά δεν είναι, απλά δεν υπάρχει ανταγωνισμός. Και δεν λέω πως αυτό είναι καλό πράγμα.

Ας πουμε για το daemontools, που θα φέρει ίσως κάποιος σαν αντιπαράδειγμα για να πει πως το systemd δεν έφερε κάτι καινούργιο και πως δεν είναι μονόδρομος. Υπάρχει 19 χρόνια σαν τεχνολογία. Γιατί δεν τα κατάφερε; Γιατί σου είπε πως ο τρόπος που γράφεις ένα daemon είναι λάθος, αυτό που γράφουν όλα τα βιβλία είναι λάθος.  Και θα έπρεπε να αλλάξεις τον κώδικα κάθε υπηρεσίας. Τι έκανε το systemd; Πήρε τα θετικά αυτής της προσέγγισης, αλλά δεν την επέβαλε. Φρόντισε να υπάρχει ένα ομαλό μονοπάτι μετάβασης. Και κέρδισε.

Για ποιο λόγο να μην το χρησιμοποιήσει μια διανομή όταν η μη χρήση του οδηγεί σε μειωμένη ποιότητα χρήσης; Αν κάποιο εναλλακτικό init system υπερτερεί σε κάποια σημεία με χαρά να τα ακούσω. Όταν ξεκίνησα να το ψάχνω στο πρόγραμμα ήταν τον επόμενο μήνα να κάνω το ίδιο σε εναλλακτικά συστήματα. Δεν το έκανα, γιατί δεν βρήκα απολύτως κανένα λόγο, κανένα τεχνικό πλεονέκτημα, τίποτα απολύτως. Με κανένα τρόπο δεν λέω πως είναι τέλειο, τίποτα δεν είναι, πως έχει την καλύτερη σχεδίαση που μπορεί να υπάρξει ή το τελειότερο TUI. Τα directives θα μπορούσαν να είχα σχεδιαστεί καλύτερα για παράδειγμα (και αυτό μπορεί να λεχθεί και για το git).   Απλά είναι το καλύτερο από τα υπάρχοντα αυτή την στιγμή, και θα χαρώ αν ακούσω κάποιο πλεονέκτημα ενός εναλλακτικού συστήματος για την τυπική χρήση σε desktop και servers. Τα containers/embedded είναι μια άλλη περίπτωση.

Επεξ/σία 30 Μαΐου 2021 από asfodelus

[rhtoras]

2 ώρες πριν, mphxths είπε

υπολοιπα σοβαρα DEs (gnome,kde) εχουν αμεση πλεον εξαρτηση με το systemd

...

[mphxths]

Παιδια , καλως τα δεχτηκαμε.... 

[asfodelus]

Ότι κουβεντιάσαμε κουβεντιάσαμε. Ήρθε η ώρα για να ακουστούν τα σοβαρά επιχειρήματα 😂😂

 

 

Επεξ/σία 30 Μαΐου 2021 από asfodelus

[patclo]

Την συγκεκριμενη διανομη (σε 32bit) την εβαλα σε ενα νετμπουκ του 2009 νομιζω, που ειχε τον πρωτο πρωτο ατομ που ειχε βγει γιατι δεν ηθελα να το πεταξω και γιατι δεν νομιζω να ετρεχε και κατι αλλο.  Ειμαι τελειως ασχετος απο λινουξ αλλα δεν βρηκα καμια δυσκολια να το σεταρω. 

[snowflake99]

14 ώρες πριν, RTW4ever είπε

μια που το Σαββατοκύριακο αυτό είχα χρόνο για χάσιμο.

Ένα Half Life παίζει ο κόσμος... 😛

[jcd313]

 

Ρε παιδιά, αν είναι δυνατόν να αξιολογούμε το systemd συγκρίνοντας την ευκολία εγκατάστασης/ χρήση μνήμης/ backlight control/ younameit δύο διαφορετικών διανομών (έστω και οι δύο debian based)!

Ας αξιολογήσουμε τις δυνατότητες που προσφέρει/δεν προσφέρε, ή την ευκολία να γράψεις custom unit files σε σχέση με τις εναλλακτικές, σε desktop user και/ή business περιβάλλοντα! Ας αξιολογήσουμε έστω το journalctl όταν κάτι δεν παίζει! Όχι όμως αυτό το πράγμα.

 

Σε κάθε περίπτωση, το δίφραγκό μου:

Χρησιμοποιώ Arch από το '13 οπότε μάλλον είμαι στο systemd πολύ καιρό για να είμαι αντικειμενικός -και δεν κάνω χρήση πολλών από τις δυνατότητες που έχει το systemd- όμως η άποψή μου είναι:

1. Systemd = core functonality, δηλαδή init system + service management + logging system. Τα πρόσθετα είναι optional.
2. Το core είναι μάλλον καλύτερο από τις εναλλακτικές. Έχει πολλές δυνατότητες χωρίς να είναι πολύ δύσκολο στη χρήση (θέλει διάβασμα φυσικά).
3. Διαφωνώ με το οικοσύστημα που χτίζεται γύρω του, με ένα σωρό features που -κατά τη γνώμη μου- δε σχετίζονται και δε χρειάζεται να σχετίζονται. Παράδειγμα τα modules logind, homed, boot, timesyncd, networkd. Δε θα με πείραζε να έφτιαχναν οι ίδιοι devs (Lennart και σία) άλλα σχετικά προγράμματα για να καλύψουν τις σχετικές ανάγκες, όμως η λογική του "οικοσυστήματος" που τελικά οδηγεί σε interdependecies, με βρίσκει αντίθετο. Ένας από τους λόγους που προτιμώ το linux είναι η modular λογική με  προγράμματα που κάνει το καθένα συγκεκριμένα πράγματα.
4. Δέχομαι και σέβομαι όμως οτι τα περισσότερα modules για το systemd είναι optional και υπάρχουν εναλλακτικές. Και σε περίπτωση που οι εναλλακτικές δεν είναι αρκετά καλές, δικαίως επικρατεί το systemd υποθέτω.

Επεξ/σία 31 Μαΐου 2021 από jcd313

[jemadux]

η εμπειρία μου με το artix και με openrc .. 
λοιπον δεν εχω προβλήμα με την διανομή ..

μια χαρα δουλεύει οταν μπορείς να βάλεις το illum για το backlight και σε openrc  και σε systemd γιατί με τον dwm δεν δουλεύει οπως πρέπει . στο  

παρακάτω .. στο arch έχω βάλει το dunst ως notifications (βασικά χρησιμοποιώ το larbs ) οποτε στο artix πρέπει να κάνω μια χειροκινήτη ρύθμιση

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

εφόσον έχω 16 G  ram δεν με απασχολεί πλέον η  μνήμη που μπορεί να καταλανώσει το systemd . 

ενα ακομα προβλήμα είναι το gnupg που θελω να ειναι αυτομάτα ξεκλειδώτο  . 

δηλαδή ρυθμίσεις που είναι αυτοματοποιημένες για το arch και για το artix πρεπει να βάλεις χεράκι ..