Linux ή Unix οεο?

[tritonas00]

Ναι αλλα γιατι systemd sucks δεν μας ειπες

 

Προσωπικα για μενα στο arch:

 

initscripts = bash = ζωαρα

απλωθηκε πολυ (logs, ο Χ πρεπει να ανοιγει στο ιδιο tty με αυτο που κανεις login κ.α)

[imitheos]

Ναι αλλα γιατι systemd sucks δεν μας ειπες

 

Προσωπικα για μενα στο arch:

 

initscripts = bash = ζωαρα

απλωθηκε πολυ (logs, ο Χ πρεπει να ανοιγει στο ιδιο tty με αυτο που κανεις login κ.α)

Γιατί αν εξαιρέσεις τα παχιά λόγια που λένε οι devs του, το μόνο που προσφέρει είναι γρηγορότερο boot. Δεν λέω ότι δεν πρέπει να υπάρχει πρόοδος και αλλαγή, αλλά το systemd δεν απέκτησε την απαιτούμενη critical mass που χρειάζεται για να δικαιολογήσει την ύπαρξή του. Αντικαθιστά προγράμματα που δουλεύουν τζάμι χρόνια και (θεωρητικά) έχουν αποπαρασιτωθεί πλήρως και που κάνουν μία δουλειά και την κάνουν καλά. Χωρίς να είμαι ο μέγιστος προγραμματιστής, βασική αρχή του προγραμματισμού είναι ότι όσο περισσότερος και πιο πολύπλοκος κώδικας υπάρχει τόσο πιο πολλά bugs υπάρχουν. Όταν σε ένα πρόγραμμα αντικαθιστάς sysvinit, udev, *kit, syslogd, κτλ σίγουρα θα έχεις bugs και σίγουρα θα είναι πιο δύσκολο το debugging. Εντωμεταξύ μας είχανε πρήξει για το πόσο καλό είναι το ConsoleKit, PolicyKit, κτλ και μόλις τα συνηθίσαμε τώρα ξαφνικά δεν είναι καλά και θα τα αντικαταστήσει το systemd.

 

Πραγματοποιεί αλλαγές μόνο στο όνομα της αλλαγής και όχι της προόδου. Ένα παράδειγμα που ανέφερα ήταν το ξεχωριστό /usr. Ανεξάρτητα από το αν είναι χρήσιμο να έχεις ξεχωριστό /usr ή όχι, τόσα χρόνια έπαιζε. Δεν ξέρω αν είχες παρακολουθήσει πριν κάποια χρόνια που μια αλλαγή στην glibc έσπασε το flash plugin. Είχε γίνει αλλαγή στην φορά αντιγραφής της memcpy με αποτέλεσμα να μην λειτουργεί σωστά το flash plugin. Το πρόβλημα ήταν του flash επειδή χρησιμοποιούσε memcpy εκεί που έπρεπε να χρησιμοποιήσει memmove και αυτό έλεγαν και οι glibc devs. Ο Torvalds τους είπε ότι τον χρήστη δεν τον νοιάζει ποιος έχει δίκιο και ότι ακόμη και δίκιο να έχεις ποτέ δεν σπας κάτι που έπαιζε μέχρι τώρα. Ο Lennart δεν έδωσε κανένα πειστικό επιχείρημα γιατί αρνούνται να πράξουν τη σωστή λύση και απλά προτείνουν "μη βάζετε ξεχωριστό /usr"

 

Άλλο παράδειγμα που θα βρεις πάρα πολύ κόσμο να έχει νευριάσει είναι τα binary logs. Καλώς ή κακώς θα βρεις κόσμο και εταιρίες που έστησαν ένα εκτυπωτή ακίδων που είχαν πεταμένο, του έβαλαν με μηχανογραφικό χαρτί και με μια απλή γραμμή καταχώρηση στο syslog.conf στέλνουν τα logs στην /dev/lp0. Ή θες να ψάξεις μια καταχώρηση στα logs. Επειδή είναι text, τρέχεις ένα grep και βρίσκεις αμέσως τι θέλεις χωρίς ειδικά προγράμματα και χαζομάρες.

 

Δεν λέω ότι στο τέλος δεν θα λειτουργήσει. Όπως και τα *Kit ωρίμασαν και τώρα ξεχάσαμε ότι υπάρχουν καν, έτσι θα γίνει και με τον systemd. Οι end-users δεν τους νοιάζει καν τι είναι και ίσως να μην έχουν ακούσει καν τα ονόματα systemd, sysvinit και οι admins σε 2-3 χρόνια θα τον συνηθίσουμε και ίσως να λέμε ότι είναι 10 φορές καλύτερος από το sysvinit και μπράβο που έγινε η αλλαγή. Το θέμα είναι ότι ο Lennart μας φορτώνει τα χόμπυ του έτσι επειδή του κ...λωσε χωρίς να έχει επιχειρήματα και χωρίς να δέχεται καμμία πρόταση για την πορεία. Πάντα έχει μια ειρωνεία και ένα αστείο για να αποφύγει την απάντηση (πχ αυτά που έλεγε για τα BSD)

 

Δες για παράδειγμα Εδώ που συγκρίνει τα διάφορα init systems. Αναφέρει ότι το systemd υποστηρίζει τα κέρατά του αλλά από την άλλη λέει ότι χρειάζεται μόλις τρεις dependencies. Ναι μεν μπορεί να γίνει compile μόνο με αυτές τις τρεις αλλά για να υποστηρίξει όλα αυτά που λέει θα χρειαστεί να ενεργοποιηθούν οι ένα κάρο προαιρετικές εξαρτήσεις. Παραπλανά επίτηδες τον κόσμο για να προωθήσει τα project του. Όπως είχα γράψει παλαιότερα, αυτά που λέει είναι σαν τις διαφημίσεις των αυτοκινήτων που σου λένε "μέχρι 250 άλογα, από 9000 ευρώ". Ή θα δώσεις 9000 ευρώ (τρεις εξαρτήσεις) αλλά θα πάρεις 50 άλογα ή θα έχεις 250 άλογα (πολλά features) αλλά θα τα σκάσεις. Και το επιχείρημα που είπε ότι ο χρήστης μπορεί να καθορίσει πόσο bloat θα βάλει ούτε αυτό ισχύει. Αν εξαιρέσεις την περίπτωση του Gentoo και των άλλων source-based διανομών, όλοι οι υπόλοιποι χρήστες θα φορτωθούν την επιλογή του maintainer της διανομής (που για να καλύψει τις ανάγκες της πλειοψηφίας θα είναι ένα bloated πακέτο με πολλές εξαρτήσεις).

 

Ίσως να μην σε έπεισα αλλά βαρέθηκα να γράψω άλλα Κατά καιρούς έχουν γραφτεί από άτομα πιο γνώστες από εμένα πολλά σωστά επιχειρήματα κατά του systemd

[mad-proffessor]

Παρακολουθω με ενδιαφέρον τη συζήτηση. Μια εξήγηση που ίσως μπορεί να δοθει για το systemd και την εξάπλωση του σε πολλές δομές και api του συστήματος είναι ότι έχουν στόχο τη κατάκτηση του desktop. Γρηγορότεροι χρόνοι boot, κεντρικότερος έλεγχος υπηρεσιών. Ένα command line tool για όλες τις δουλειες. Βέβαια αυτό έχει το κόστος οτι όλοι πρέπει να ξαναμάθουν πραγματα απο την αρχή και σε κανένα δεν αρέσει ένα σύστημα που δουλέυει να πρέπει να το ξαναμάθεις ή να σου χαλάει κάποιες φορές. Μια λύση ενδιάμεση που θα μπορούσε να δοθει είναι server λειτουργικά να παραμείνουν για πάντα στο sysvinit και τα desktop να περάσουν σε systemd με δυνατότητα να γίνεται 'downgrade' σε sysvinit ή να σε ρωτάει ο installer τι θες να επιλέξεις απο τα δύο. Είναι πάντως λίγο ανορθόδοξο άτομα που έχουν συνηθισει και μάθει το λίνουξ για χρόνια καθε λίγο να χρείαζονται να ξαναανακαλύπτουν πως θα πρέπει να διαχειρίζονται το σύστημα τους.

[imitheos]

Τουλάχιστον για μένα, δεν είναι τόσο ότι θα πρέπει να ξανά-μάθεις νέα πράγματα αλλά ότι αφαιρούνται "ελευθερίες" που είχες τόσο καιρό. Παλαιότερα είχες την ελευθερία να κάνεις ό,τι θέλεις στο σύστημά σου. Δεν σου αρέσει το vixie cron ? Βάλε το dcron και πάει λέγοντας. Και τώρα μπορείς να το κάνεις ως ένα βαθμό αλλά όσο περνάει ο καιρός είσαι αναγκασμένος να φορτωθείς και παραπάνω πράγματα. Όταν βγήκε το ConsoleKit, αναγκαστικά έπρεπε να το φορτωθείς ή να μην τρέχεις KDE. Δεν είναι θέμα χωρητικότητας στο δίσκο ή επεξεργαστικής ισχύος. Το πιο μικρό netbook μπορεί να σηκώσει 500 ConsoleKit. Απλά θέλω να έχω την ελευθερία να επιλέγω ό,τι software θέλω εγώ χωρίς να μου το επιβάλλει κάποιος αλλιώς θα έτρεχα windows με ενσωματωμένο Internet Explorer.

[javavall]

Απλά θέλω να έχω την ελευθερία να επιλέγω ό,τι software θέλω εγώ χωρίς να μου το επιβάλλει κάποιος αλλιώς θα έτρεχα windows με ενσωματωμένο Internet Explorer.

 

Κάπως έτσι ξεκίνησε και ο Linus. Δεν ήθελε να περιορίζεται από το τότε Minix οπότε έφτιαξε δικό του λειτουργικό. 

 

Hello everybody out there using minix

- I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)  for 386(486) AT clones.

[mobinmob]

Γιατί αν εξαιρέσεις τα παχιά λόγια που λένε οι devs του, το μόνο που προσφέρει είναι γρηγορότερο boot. 

Σχετικά με την ταχύτητα του systemd...

Όλα, μα όλα τα συστήματα που προσπάθησαν να αντικαταστήσουν το κλασσικό init ή να το επιταχύνουν χρησιμοποιούν 2 τεχνικές: Η μία είναι να παραλληλίζουν όσο περισσότερο μπορούν τις διεργασίες που γίνονται και η δεύτερη να προσπαθούν είτε να μειώσουν το πόσο shell scripting απαιτείται είτε να το επιταχύνουν (χρησιμοποιώντας buildins αντί για εξωτερικές εντολές, γράφοντας “πιο έξυπνα” τα scipts, μειώνοντας το μέγεθός τους και χρησιμοποιώντας πιο ελαφριά shells από το bash, όπως το dash).

Το launchd για παράδειγμα (όπως και το einit) από φεύγει όσο μπορεί την χρήση shell χρησιμοποιώντας xml, το systemd χρησιμοποιεί για τον ίδιο λόγο ini files, ενώ το OpenRC αντικατέστησε μεγάλο μέρος του -γραμμένου σε bash- rc system του gentoo με προγράμματα σε C...

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

Οι επιπλέον διαφορές του systemd είναι ότι α) προσπαθεί και καταφέρνει να παραλληλίσει και διεργασίες που θεωρούνταν ότι δεν παραλληλίζονται (fsck), χρησιμοποιεί τρικ (autofs για fs που δεν είναι ακόμα έτοιμα) και  αντί για να ασχοληθεί με τις εξαρτήσεις ή την σειρά που πρέπει να εκκινήσουν οι daemons/services απλά χρησιμοποιεί socket activation για να ξεκινήσουν όλοι μαζί (τουλάχιστον αυτό είναι το σχέδιο...). Προσθέστε σε αυτά την χρήση του readahead και έχετε όλους τους λόγους για την ταχύτητα του.

Το μεγάλο πλεονέκτημα που προβάλλεται (εκτός από την ταχύτητα) είναι το πόσο εύκολα και απλά μπορείς να έχει αξιόπιστο proccess supervision (δεν το λένε όμως έτσι) και resource limits. Αυτά γίνονται με την χρήση των cgroups.

Το δικό μου πρόβλημα με το systemd είναι ότι όλα όσα ευαγγελίζεται μπορούν να γίνουν με πιο απλούς τρόπους και -τα περισσότερα- δεν χρειάζεται να γίνουν από ένα binary που τρέχει σαν pid1. Τα daemontools του djb και οι απόγονοί τους δείχνουν τον δρόμο... Όσοι τρέχετε arch, ρίξτε μια ματιά στο ignite.

[imitheos]

Το Suspend2Ram και Suspend2Disk (το Hibernate που λέμε στο χωριό μ ) είχε πολλά προβλήματα παλιά και έχει ακόμη προβλήματα με περίεργες pci συσκευές που δεν υλοποιούν σωστά το πρότυπο αλλά γενικά παίζει και μπορεί να χρησιμοποιηθεί σε κάποιο laptop που ανοιγοκλείνει συχνά. Ένα σταθερό μηχάνημα πόσες φορές κλείνει ? Ακόμη και ένας απλός χρήστης που απλά σερφάρει στο διαδίκτυο και το κλείνει στο τέλος της ημέρας, πόσο πια αργεί να φορτώσει και θα γλυτώσει με το systemd ?

 

Τόσο σημαντικό είναι να γλυτώσουμε 3sec στην εκκίνηση ? Δεν έχει δουλέψει κανείς παλαιότερα (ή ακόμη και τώρα) servers με scsi ελεγκτές που θέλει 15sec μόνο για να κάνει POST ο ελεγκτής ?

 

Όντως με shell scripts υπάρχει το πρόβλημα ότι τρέχουν πολλά εξωτερικά προγράμματα και υπάρχει πολύ overhead λόγω forking/exec-ing αλλά έχουν το καλό ότι μπορείς εύκολα να αλλάξεις κάτι. Φαντάσου για κάθε αλλαγή να ήθελες ξανά compile. Μια πολύ εύκολη λύση για να συνδυαστεί η ταχύτητα της C και η μη-χρήση εξωτερικών προγραμμάτων χωρίς όμως να χαθεί η ευκολία των shell scripts θα ήταν να χρησιμοποιηθεί ZSH αντί για Bash. Το κάνουν ήδη κάμποσες διανομές και έχεις πάλι readable scripts που μπορείς εύκολα να αλλάξεις και χρειάζεσαι απείρως λιγότερα εξωτερικά προγράμματα γιατί το ZSH υλοποιεί εσωτερικά σε C και κάνει "export" σε shell script ένα κάρο λειτουργίες. Έχουν γραφτεί IRC servers και HTTP servers απευθείας σε ZSH χωρίς να χρησιμοποιούνται εξωτερικά προγράμματα. Εντάξει δέχομαι ότι η μετάβαση δεν είναι τόσο εύκολη όσο την κάνω να ακούγεται αλλά σίγουρα είναι πιο εύκολη από το γράψιμο από την αρχή του systemd.

[mobinmob]

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

Όσο για την λύση του zsh είναι ενδιαφέρουσα, αν και θα προτιμούσα την εκπληκτική execline .