Boycott systemd

[megahead13]

Πάμε ξανά, δεν μιλάμε για κάτι που θα γίνει. Μιλάμε για κάτι που έχει ήδη γίνει. Αν είσαι enterprise θέλεις να παίρνεις updates. Ε, πως να το κάνουμε που το RHEL 7 (με systemd) θα παίρνει για περισσότερα χρόνια updates από το RHEL 6; Μπορεί το Centos 7 να έχει systemd αλλά έχει και python 2.7, κάτι που δεν έχει το Centos 6. Αν βάλω χειροκίνητα την python 2.7 στο Centos 6 παράλληλα με την 2.6 (γιατί το yum του 6 χρειάζεται την 2.6) θα είμαι πιο ευάλωτος αφού δεν θα έχω αυτόματα update αλλά θα πρέπει να τα κάνω μόνος μου.

Αυτό που δεν καταλαβαίνεις και που σου λέει ο KernelPanic είναι ότι τις εταιρείες ΔΕΝ τις ενδιαφέρει να έχουν RHEL7 και την τελευταία έκδοση της Python (ή τα windoze server 2012 πχ). Τις εταιρείες τις ενδιαφέρει το uptime, η ασφάλεια και όλα να παίζουν με τις λιγότερο δυνατές εκπλήξεις. Πχ σε εμάς η κυρίως Linux πλατφόρμα είναι RHEL5.8. Ναι, RHEL 5.8!! Γιατί πρέπει να υποστηρίξουμε κυριολεκτικά 100αδες εφαρμογές που παίζουν απροβλημάτιστα και για τις οποίες πληρώνουμε χοντρά μαρούλια για άδειες χρήσης και συμβόλαια υποστήριξης. Δεν πρόκειται να περάσουμε σε RHEL6.x τουλάχιστον για 1.5 χρόνο ακόμα. Πρόσεξε τι είπα RHEL6.x όχι RHEL7 που λες εσύ. Σε κάποιες περιπτώσεις έχουμε συστήματα που τρέχουν ακόμα RHEL4.x (τα συστήματά μας δε βλέπουν Internet). Αντίστοιχα σε windoze έχουμε μέχρι server 2008, όχι νεώτερα. Μάντεψε γιατί. Άρα δεν έχει γίνει τίποτα όπως λες.

Από την άλλη στο λαπτόπι μου τρέχω openSUSE που έχει περάσει σε systemd (τα κλασσικά init scripts ακόμα υπάρχουν όμως). Στα φρύδια μου όμως. Είναι το λαπτόπι μου. Δεν είναι συστήματα εκατομμυρίων $$ που υποστηρίζουν τη λειτουργία μιας τεράστιας εταιρείας με τρελό revenue.

[KernelPanic]

Πάμε ξανά, δεν μιλάμε για κάτι που θα γίνει. Μιλάμε για κάτι που έχει ήδη γίνει. Αν είσαι enterprise θέλεις να παίρνεις updates. Ε, πως να το κάνουμε που το RHEL 7 (με systemd) θα παίρνει για περισσότερα χρόνια updates από το RHEL 6; Μπορεί το Centos 7 να έχει systemd αλλά έχει και python 2.7, κάτι που δεν έχει το Centos 6. Αν βάλω χειροκίνητα την python 2.7 στο Centos 6 παράλληλα με την 2.6 (γιατί το yum του 6 χρειάζεται την 2.6) θα είμαι πιο ευάλωτος αφού δεν θα έχω αυτόματα update αλλά θα πρέπει να τα κάνω μόνος μου.

Ναι χρειάζομαι τα updates και δεν λέω οτι θα το αποφύγω, αλλα πριν μπει σε critical servers θα το περάσω απο 1000 κυματα (ήδη το κάνω)...

Το systemd το επέλεξαν οι devs του Arch, του Debian, του Ubuntu κλπ. Δεν πιστεύω πως το επέλεξαν χωρίς να το σκεφτούν καλά ή επειδή είναι πληρωμένοι, άχρηστοι κλπ.

Δεν νομίζω να ανέφερα κάτι για τους dev που αναφέρεις τον μόνο που ανεφερα ειναι ο LP που η συπεριφορά του κατα την άποψη μου είναι απαράδεκτη...

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

Μαζί σου...

[megahead13]

Ένα binary format που προορίζεται για logging και η λύση όταν γίνεται corrupted (όχι σπάνια) από τους devs είναι αυτή, δεν το θέλω σε σύστημα που κάνω δουλειά. Ευτυχώς μπορείς να κατευθύνεις τα logs αλλού.

Τελικά δηλαδή ενώ το systemd πάει να τα κάνει όλα, μάλλον θα καταλήξουμε να χρησιμοποιούμε ότι ξέρουμε τόσα χρόνια

Γι' αυτό έχουμε το virtualenv Σοβαρά τώρα, δεν θα βρεις άνθρωπο που να δεσμεύεται αποκλειστικά από το τι δίνει η διανομή για python και ruby.

Έτσι ακριβώς! GNU modules κανείς;;

[KernelPanic]

megahead13 Ωχ δικός μας εισαι κι εσυ...

[megahead13]

Ω ναι!

[KernelPanic]

Ένα binary format που προορίζεται για logging και η λύση όταν γίνεται corrupted (όχι σπάνια) από τους devs είναι αυτή, δεν το θέλω σε σύστημα που κάνω δουλειά. Ευτυχώς μπορείς να κατευθύνεις τα logs αλλού.

Ειδικα αν έχεις να κάνεις και με compliance η ανακατευθυνση είναι μονόδρομος...

[mrsaccess]

Αυτό που δεν καταλαβαίνεις και που σου λέει ο KernelPanic είναι ότι τις εταιρείες ΔΕΝ τις ενδιαφέρει να έχουν RHEL7 και την τελευταία έκδοση της Python (ή τα windoze server 2012 πχ). Τις εταιρείες τις ενδιαφέρει το uptime, η ασφάλεια και όλα να παίζουν με τις λιγότερο δυνατές εκπλήξεις. Πχ σε εμάς η κυρίως Linux πλατφόρμα είναι RHEL5.8. Ναι, RHEL 5.8!! Γιατί πρέπει να υποστηρίξουμε κυριολεκτικά 100αδες εφαρμογές που παίζουν απροβλημάτιστα και για τις οποίες πληρώνουμε χοντρά μαρούλια για άδειες χρήσης και συμβόλαια υποστήριξης. Δεν πρόκειται να περάσουμε σε RHEL6.x τουλάχιστον για 1.5 χρόνο ακόμα. Πρόσεξε τι είπα RHEL6.x όχι RHEL7 που λες εσύ. Σε κάποιες περιπτώσεις έχουμε συστήματα που τρέχουν ακόμα RHEL4.x (τα συστήματά μας δε βλέπουν Internet). Αντίστοιχα σε windoze έχουμε μέχρι server 2008, όχι νεώτερα. Μάντεψε γιατί. Άρα δεν έχει γίνει τίποτα όπως λες.

Από την άλλη στο λαπτόπι μου τρέχω openSUSE που έχει περάσει σε systemd (τα κλασσικά init scripts ακόμα υπάρχουν όμως). Στα φρύδια μου όμως. Είναι το λαπτόπι μου. Δεν είναι συστήματα εκατομμυρίων $$ που υποστηρίζουν τη λειτουργία μιας τεράστιας εταιρείας με τρελό revenue.

Sorry, ως αντεπιχείρημα του systemd μου λες πως η εταιρεία σου σε αναγκάζει να δουλεύεις σε διανομές 9 και 7 ετών αντίστοιχα (RHEL 4 και 5); Αυτό δεν είναι επιχείρημα κατά του systemd αλλά αιτία να καταφύγεις στο δικαστήριο της Χάγης για προσβολή της ανθρώπινης αξιοπρέπειας. Ελπίζω να μην σας μαστιγώνουν κιόλας.

Ευτυχώς όταν απομακρύνεσαι από παραδοσιακές εταιρείες και πας προς τις εταιρείες τεχνολογίας/πληροφορίας παίζεις με πιο ενδιαφέροντα πράγματα. Για παράδειγμα μιλάς για uptime αλλά οι σύγχρονες εταιρείες παίζουν με την λογική του chaos monkey του netflix. Η Google έχει γυρίσει τεράστιο μέρος των cluster apps της σε docker (κάτι που ο kernel του RHEL 5 δεν μπορεί καν να τρέξει).

Πάντως όπως μου τα περιγράφεις ετοιμάσου· το 2017/8 λογικά η εταιρεία σου θα πληρώνει την Redhat για να έχεις εσύ systemd. Οι υπόλοιποι μπορεί να είμαστε τυχεροί και να έχουμε ήδη μεταβεί σε κάτι καλύτερο.

Δεν νομίζω να ανέφερα κάτι για τους dev που αναφέρεις τον μόνο που ανεφερα ειναι ο LP που η συπεριφορά του κατα την άποψη μου είναι απαράδεκτη...

Όχι, δεν ανέφερες κάτι για τους dev. Απλώς σου υπενθυμίζω πως δεν πήγε ο LP με ένα λοστάρι στο σπίτι του αρχι-arch-dev και του είπε βάλε systemd ή θα σου σπάσω τα πόδια.

[Ronin]

Το systemd το επέλεξαν οι devs του Arch, του Debian, του Ubuntu κλπ. Δεν πιστεύω πως το επέλεξαν χωρίς να το σκεφτούν καλά ή επειδή είναι πληρωμένοι, άχρηστοι κλπ. Ο καθένας μας που φωνάζει πως ξέρει καλύτερα θα μπορούσε να είναι μέσα στις επιτροπές αποφάσεων (από devs/admins αποτελούνται) αλλά δεν ήμασταν για ένα περίεργο λόγο. Το σημαντικό πλέον είναι να εργαστούμε όλοι μαζί για να γίνει καλύτερο και κυρίως να υπάρξει εναλλακτική υλοποίηση.

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

[mobinmob]

Sorry, ως αντεπιχείρημα του systemd μου λες πως η εταιρεία σου σε αναγκάζει να δουλεύεις σε διανομές 9 και 7 ετών αντίστοιχα (RHEL 4 και 5);

Πίστεψέ το, δεν είναι τόσο σπάνια τακτική και δεν συμβαίνει μόνο με Redhatοειδή

- - - Updated - - -

Ειδικα αν έχεις να κάνεις και με compliance η ανακατευθυνση είναι μονόδρομος...

Εδώ υπάρχει κόσμος που ανακατευθύνει το Event Log των windows σε syslog (και αυτό με την σειρά του αποθηκεύει σε κάποια sql db)...

[megahead13]

Sorry, ως αντεπιχείρημα του systemd μου λες πως η εταιρεία σου σε αναγκάζει να δουλεύεις σε διανομές 9 και 7 ετών αντίστοιχα (RHEL 4 και 5); Αυτό δεν είναι επιχείρημα κατά του systemd αλλά αιτία να καταφύγεις στο δικαστήριο της Χάγης για προσβολή της ανθρώπινης αξιοπρέπειας. Ελπίζω να μην σας μαστιγώνουν κιόλας.

Ας κάνω μια ακόμα προσπάθεια μπας και δεήσεις να καταλάβεις. Η εταιρεία μου δε με αναγκάζει να δουλεύω με διανομές 9 και 7 ετών. Οι vendors όμως τους οποίους χρυσοπληρώνουμε για να χρησιμοποιούμε τις εφαρμογές τους ώστε να βγάζουμε το τελικό προϊόν στην ώρα του και να στεκόμαστε στην παγκόσμια αγορά απέναντι στον ανταγωνισμό λένε ότι αυτές και αυτές τις πλατφόρμες υποστηρίζουμε. Αν σας αρέσει. Διαφορετικά βάλτε σούπα ντούπα RHEL7 με systemd και rolling release Debian Unstable, Gentoo και Arch.

Ευτυχώς όταν απομακρύνεσαι από παραδοσιακές εταιρείες και πας προς τις εταιρείες τεχνολογίας/πληροφορίας παίζεις με πιο ενδιαφέροντα πράγματα. Για παράδειγμα μιλάς για uptime αλλά οι σύγχρονες εταιρείες παίζουν με την λογική του chaos monkey του netflix. Η Google έχει γυρίσει τεράστιο μέρος των cluster apps της σε docker (κάτι που ο kernel του RHEL 5 δεν μπορεί καν να τρέξει).

Έχεις κολλήσει με το τι κάνουν οι εταιρείες τύπου Google που προσφέρουν cloud services λες και δεν υπάρχει τίποτε άλλο στον κόσμο. Μήπως όλοι εμείς στο Enterprise IT να πετάξουμε ότι υποδομή έχουμε σε Cisco, Juniper, Brocade, HP, F5, κτλ και να κάνουμε routing με FreeBSD όπως το Netflix και το London Internet Exchange;; Μήπως να πετάξουμε και τα VMware, Citrix, KVM, HyperV, κτλ και να κάνουμε virtualisation με CoreOS και Docker;;; Α, επίσης κι εμείς εταιρεία τεχνολογίας είμαστε με ~10000 κόσμο παγκοσμίως

Πάντως όπως μου τα περιγράφεις ετοιμάσου· το 2017/8 λογικά η εταιρεία σου θα πληρώνει την Redhat για να έχεις εσύ systemd. Οι υπόλοιποι μπορεί να είμαστε τυχεροί και να έχουμε ήδη μεταβεί σε κάτι καλύτερο.

Έτσι είναι αφού έτσι νομίζεις. Κάτι παραπάνω θα ξέρεις.

Πίστεψέ το, δεν είναι τόσο σπάνια τακτική και δεν συμβαίνει μόνο με Redhatοειδή

Εδώ γνωστός μου παλιά καραβάνα στην πληροφορική μέχρι που συνταξιοδοτήθηκε έβγαζε ως contractor τρελά λεφτά από ασφαλιστικές εταιρείες και τραπεζικούς ομίλους υποστηρίζοντας δεινόσαυρους που έτρεχαν Cobol!!! Για το λόγου το αληθές εδώ μια παρόμοια ιστορία από τον τραπεζικό τομέα:

http://www.euro2day.gr/thebanker/art...kon-deals.html

Τα εμπόδια που αντιμετώπισε η A&M στην προσπάθειά της να ξετυλίξει το κουβάρι των πληροφοριακών συστημάτων της Lehman και οι μέθοδοι που χρησιμοποιήθηκαν για να υπερκεραστούν τα προβλήματα αυτά, είναι συνήθη σε περιπτώσεις τραπεζικών εξαγορών, λέει ο συνάδελφος της κ. Cairns, Jeffrey Donaldson, επικεφαλής του τμήματος IT της εταιρίας.

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

Οι υπάλληλοι που είναι εξοικειωμένοι με γλώσσες προγραμματισμού γίνονται σταδιακά όλο και σπανιότεροι. Σύμφωνα με έρευνα που πραγματοποίησε το περιοδικό Computerworld, το 59% των in house προγραμματιστών που γνωρίζουν την γλώσσα προγραμματισμού Common Business- Oriented (Cobol) είναι ήδη 45 ετών ή μεγαλύτεροι σε σύγκριση με το μόλις 5% που έχουν ηλικία μικρότερη από τα 35.

Ορισμένα μάλιστα συστήματα χρονολογούνται από τη δεκαετία του 1950 και είναι «γραμμένα» σε χαμηλού επιπέδου γλώσσα προγραμματισμού- κάτι που μπορεί να αποτελέσει πονοκέφαλο για τον νέο ιδιοκτήτη μιας τράπεζας. Εταιρίες όπως η Micro Focus προσφέρουν λογισμικό αλλά και κατευθυντήριες γραμμές σε πελάτες που αναβαθμίζουν παλιά συστήματα σε πιο εξελιγμένα. Η περικοπή του κόστους που σχετίζεται με εξειδικευμένες υπηρεσίες μπορεί συχνά μακροπρόθεσμα να αποδειχθεί όχι και τόσο σοφή κίνηση.

«Σε πολλές περιπτώσεις, όταν η εξαγοράζουσα τράπεζα ρωτά πώς δουλεύει ένα συγκεκριμένο σύστημα, η απάντηση είναι ότι το πρόσωπο που το έγραψε έφυγε από την τράπεζα πριν από 25 χρόνια και ‘από τότε δεν το έχουμε αγγίξει’», λέει ο David Parker, επικεφαλής της Accenture, της διεθνούς εταιρίας παροχής συμβουλευτικών υπηρεσιών σε θέματα τεχνολογίας και όχι μόνο. Στην καλύτερη περίπτωση, κάτι τέτοιο θα επιμηκύνει το χρόνο που χρειάζεται για να ολοκληρωθεί η μετατροπή των συστημάτων. Ωστόσο, προσθέτει, πολύ λίγες τράπεζες καταφέρνουν να σταματήσουν εντελώς τη λειτουργία των υπαρχόντων συστημάτων σε μια οντότητα που εξαγόρασαν. «Σε πολλές περιπτώσεις, απλώς δεν καταλαβαίνουν τις διαφορετικές διαδικασίες γιατί αυτό που συμβαίνει δεν είναι κάπου καταγεγραμμένο και είναι εξαιρετικά οδυνηρό και ριψοκίνδυνο να σταματήσει κανείς τη λειτουργία του».

Τα απαρχαιωμένα συστήματα δεν είναι η μόνη ανεπιθύμητη κληρονομιά για την εξαγοράζουσα τράπεζα. Το πιθανότερο είναι πως μια τράπεζα θα έχει ήδη προϋπάρχουσες δεσμεύσεις με συγκεκριμένους vendors και service providers, σε πεδία που αφορούν από τις άδειες λογισμικού έως τις outsourcing αναθέσεις.

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

Στο θέμα μας σχετικά με το systemd. Όπως αναφέρθηκε ήδη είναι τρομερά ενοχλητικό που προσπαθούν να επιβάλλουν πράγματα με το στανιό. Δυστυχώς εγώ βλέπω ότι τα τελευταία χρόνια η έννοια της κοινότητας στο ανοιχτό λογισμικό έχει πάει περίπατο. Κι εντάξει εταιρείες όπως η Redhat που στήνουν συστήματα εκατομμυρίων δολαρίων σε χρηματιστήρια, κτλ στα τέτοια τους η κοινότητα πλέον. Όμως ο ελιτισμός ορισμένων προγραμματιστών είτε αφορά εταιρικό επίπεδο είτε project όπως το KDE και το Gnome είναι απίστευτα εκνευριστικός! Και όχι δεν είναι απάντηση το εξυπνακίστικο «γράψε κι εσύ κώδικα» ή «εσύ που ήσουν;», Καλά κάνει ο Linus και τα χώνει σε τέτοιες ντίβες κι ας γκρινιάζουν κάποιοι για την έλλειψη σαβουάρ βίβρ. Ακόμα και στη διπλωματική απάντηση που έδωσε για το systemd είπε ότι τον ενοχλεί που οι devs του αγνοούν επιδεικτικά τα bug reports. Θεωρώ ότι πάμε πολύ στραβά...

[mrsaccess]

Ας κάνω μια ακόμα προσπάθεια μπας και δεήσεις να καταλάβεις. Η εταιρεία μου δε με αναγκάζει να δουλεύω με διανομές 9 και 7 ετών. Οι vendors όμως τους οποίους χρυσοπληρώνουμε για να χρησιμοποιούμε τις εφαρμογές τους ώστε να βγάζουμε το τελικό προϊόν στην ώρα του και να στεκόμαστε στην παγκόσμια αγορά απέναντι στον ανταγωνισμό λένε ότι αυτές και αυτές τις πλατφόρμες υποστηρίζουμε. Αν σας αρέσει. Διαφορετικά βάλτε σούπα ντούπα RHEL7 με systemd και rolling release Debian Unstable, Gentoo και Arch.


Έχεις κολλήσει με το τι κάνουν οι εταιρείες τύπου Google που προσφέρουν cloud services λες και δεν υπάρχει τίποτε άλλο στον κόσμο. Μήπως όλοι εμείς στο Enterprise IT να πετάξουμε ότι υποδομή έχουμε σε Cisco, Juniper, Brocade, HP, F5, κτλ και να κάνουμε routing με FreeBSD όπως το Netflix και το London Internet Exchange;; Μήπως να πετάξουμε και τα VMware, Citrix, KVM, HyperV, κτλ και να κάνουμε virtualisation με CoreOS και Docker;;; Α, επίσης κι εμείς εταιρεία τεχνολογίας είμαστε με ~10000 κόσμο παγκοσμίως

Συνεχίζεις να δίνεις παραδείγματα που δεν είναι εναντίον του systemd. Επί της ουσίας μου λες πως κάνετε ό,τι σας πει ο εκάστοτε vendor. Ε, στα επόμενα χρόνια θα σας πει systemd.
Δες τριγύρω, από μνήμης μόνο θυμάμαι πρόσφατες ανακοινώσεις από IBM, Xen, VMware, HP για το πως αγκαλιάζουν το docker για παράδειγμα.

Στο θέμα μας σχετικά με το systemd. Όπως αναφέρθηκε ήδη είναι τρομερά ενοχλητικό που προσπαθούν να επιβάλλουν πράγματα με το στανιό. Δυστυχώς εγώ βλέπω ότι τα τελευταία χρόνια η έννοια της κοινότητας στο ανοιχτό λογισμικό έχει πάει περίπατο. Κι εντάξει εταιρείες όπως η Redhat που στήνουν συστήματα εκατομμυρίων δολαρίων σε χρηματιστήρια, κτλ στα τέτοια τους η κοινότητα πλέον. Όμως ο ελιτισμός ορισμένων προγραμματιστών είτε αφορά εταιρικό επίπεδο είτε project όπως το KDE και το Gnome είναι απίστευτα εκνευριστικός! Και όχι δεν είναι απάντηση το εξυπνακίστικο «γράψε κι εσύ κώδικα» ή «εσύ που ήσουν;», Καλά κάνει ο Linus και τα χώνει σε τέτοιες ντίβες κι ας γκρινιάζουν κάποιοι για την έλλειψη σαβουάρ βίβρ. Ακόμα και στη διπλωματική απάντηση που έδωσε για το systemd είπε ότι τον ενοχλεί που οι devs του αγνοούν επιδεικτικά τα bug reports. Θεωρώ ότι πάμε πολύ στραβά...

Με το στανιό σου επιβάλλει και ο vendor το RHEL 5 αλλά αυτό δεν σε ενοχλεί. Έχετε 10000 εργαζόμενους στην εταιρεία που εργάζεσαι και βγάζετε χρήματα από το Linux stack. Πόσες γραμμές κώδικα δώσατε φέτος στον kernel; Πόσες γραμμές ανεβάσατε στο github; Έχετε συνδρομή στο Linux Foundation; Κάπως πρέπει να συμμετέχεις στο οικοσύστημα για να είσαι μέρος των αποφάσεων. Η εταιρεία σου υποθέτω πως συμμετέχει πληρώνοντας την Redhat. Ε λοιπόν ο εκπρόσωπός σας, η Redhat, όχι απλώς υποστηρίζει το systemd αλλά είναι αυτή που το ανέπτυξε. Είναι φαύλος κύκλος.

Στο systemd υπάρχουν συμπεριφορές που δεν μου αρέσουν καθόλου αλλά το επέλεξαν τόσοι developers διανομών. Αυτούς εμπιστεύομαι. Γιατί να επιλέξουν οι devs του Debian και του Arch ένα init/daemon system με προβληματικό upstream; Δεν υπάρχει λογική. Σε εμάς πάντα φτάνουν τα πιο προκλητικά νέα και bugs, είτε μιλάμε για το systemd, είτε μιλάμε για το linux kernel, είτε για το KDE. Οι developers όμως των διανομών αναγκάζονται και βλέπουν τα πάντα και για αυτό έχουν μια πραγματική εικόνα.

Όταν κάποιος σου λέει γράψε κώδικα δεν το λέει για τον ίδιο τον κώδικα αλλά για το insight που σου δίνει. Ο developer ενός προγράμματος βλέπει χιλιάδες χρήστες με διαφορετικές ανάγκες, βλέπει χιλιάδες διαφορετικά configurations, γνωρίζει πως αυτό που ζητάς εσύ και νομίζεις πως είναι απλό επηρεάζει 100 διαφορετικά components ή έχει 50 προβλήματα που εσύ δεν μπορείς να καταλάβεις αν δεν μπεις στον χορό.

- - - Updated - - -

Πίστεψέ το, δεν είναι τόσο σπάνια τακτική και δεν συμβαίνει μόνο με Redhatοειδή

I know. Αναγκάζομαι και εγώ να δουλεύω με παλαιότερες τεχνολογίες κατά καιρούς αλλά το θεωρώ technology debt για την εταιρεία και όχι κάτι που δίνει αξιοπιστία. Η αξιοπιστία έρχεται μέσα από μια καλή ομάδα μηχανικών.

[megahead13]

1. Όπως ίσως καταλαβαίνεις δεν πρόκειται να πω σε ένα δημόσιο φόρουμ με τι ακριβώς ασχολείται η εταιρεία στην οποία εργάζομαι.
2. Τα επιχειρήματά μου όντως δεν έχουν να κάνουν με το systemd αυτό καθ' αυτό, αλλά με την εμμονή σου ότι όλοι πια είναι σαν τη Google και χρησιμοποιούν ότι τελευταίο βγαίνει και αν δεν το κάνουν είναι out-of-date και ευάλωτοι, κτλ, κτλ και ότι το systemd θα το βρούμε μπροστά μας. Ενώ η πραγματικότητα λέει ότι αυτό δεν είναι αλήθεια, ότι στο Enterprise υπάρχουν legacy συστήματα, κακώς, κάκιστα αλλά για διάφορους λόγους, πολλές φορές μη τεχνικούς, υπάρχουν. Όσον αφορά το αν το systemd ήρθε για να μείνει θα το δείξει η πορεία του χρόνου. Ακόμα και ο ίδιος ο Linus στο βίντεο που παρέθεσε ο mobinmob λέει "Is there much discussion left about it? I don't know. Maybe." Και το upstart ήρθε κι έφυγε κακήν κακώς.
3. Σε συνέχεια του 2, πολλές τεχνολογίες αγκαλιάστηκαν (αγκαλιάζονται κάθε χρόνο) από εταιρείες κολοσσούς και από προγραμματιστές, ξέμειναν όμως από βενζίνη στο δρόμο. Δε μου λέει κάτι αυτό ως επιχείρημα υπέρ του xyz systemd, docker, κτλ.

[imitheos]

Πείτε με παράξενο, πείτε με δεινόσαυρο αλλά προσωπικά εμένα δεν με ενδιαφέρει πόσο καλύτερο είναι το systemd και πόσα παραπάνω προσφέρει (που όπως έχουν αναφέρει πολλοί δεν προσφέρει και τόσα και μάλιστα σου αφαιρεί πράγματα που δούλευαν χρόνια όπως text logs).

Εμένα με νοιάζουν δύο πράγματα:

1) Να μην υπάρχει lock-in όπως πάει να γίνει τώρα. Να μπορώ δηλαδή να επιλέξω να μην το βάλω αν δεν θέλω. Ένα παράδειγμα που μπορώ να πω είναι ότι ακόμη χρησιμοποιώ xmms αντί για τα 15 νεότερα προγράμματα που κυκλοφορούν και έχουν άπειρα features. Το xmms μου κάνει τη δουλειά που θέλω οπότε βαριέμαι να αλλάξω. Μπορώ όμως ανά πάσα στιγμή να πάω σε κάτι νεότερο αν θέλω χωρίς να με εμποδίζει κανείς.

Μπορεί να βάλω αύριο systemd και να μου αρέσει κιόλας και να πω "τι βλάκας που ήμουν και δεν το έβαζα τόσο καιρό" αλλά θέλω να είμαι εγώ αυτός που θα το αποφασίσει. Υποτίθεται ότι το software (και ειδικά το free software) έχει ως κέντρο τον χρήστη (αν εξαιρέσεις το pidgin που οι devs του είναι βλαμένοι) και όχι τον developer.

2) Θέλω να έχω αξιόπιστο support ειδικά όταν μιλάμε για τόσο σημαντικό πρόγραμμα. Όταν σου λέει "το σενάριο χωρίς cgroups δεν μας ενδιαφέρει οπότε δεν το τεστάρουμε" και "αν υπάρχει corruption στο logging δεν έγινε και κάτι, πάμε παρακάτω" είναι αυτό συμπεριφορά ? Η Ανευθυνότητα σε όλο της το μεγαλείο.

Ελπίζω να γίνει ό,τι και με το git. Να τσατιστεί ο Linus και να γράψει ένα μίνι init το οποίο θα παίζει σωστά και θα είναι υπερ-γρήγορο και να λήξει το θέμα

[GoofyX]

Ελπίζω να γίνει ό,τι και με το git. Να τσατιστεί ο Linus και να γράψει ένα μίνι init το οποίο θα παίζει σωστά και θα είναι υπερ-γρήγορο και να λήξει το θέμα

Φαντάζεσαι;

[megahead13]

Πείτε με παράξενο, πείτε με δεινόσαυρο αλλά προσωπικά εμένα δεν με ενδιαφέρει πόσο καλύτερο είναι το systemd και πόσα παραπάνω προσφέρει (που όπως έχουν αναφέρει πολλοί δεν προσφέρει και τόσα και μάλιστα σου αφαιρεί πράγματα που δούλευαν χρόνια όπως text logs).

Εμένα με νοιάζουν δύο πράγματα:

1) Να μην υπάρχει lock-in όπως πάει να γίνει τώρα. Να μπορώ δηλαδή να επιλέξω να μην το βάλω αν δεν θέλω. Ένα παράδειγμα που μπορώ να πω είναι ότι ακόμη χρησιμοποιώ xmms αντί για τα 15 νεότερα προγράμματα που κυκλοφορούν και έχουν άπειρα features. Το xmms μου κάνει τη δουλειά που θέλω οπότε βαριέμαι να αλλάξω. Μπορώ όμως ανά πάσα στιγμή να πάω σε κάτι νεότερο αν θέλω χωρίς να με εμποδίζει κανείς.

Μπορεί να βάλω αύριο systemd και να μου αρέσει κιόλας και να πω "τι βλάκας που ήμουν και δεν το έβαζα τόσο καιρό" αλλά θέλω να είμαι εγώ αυτός που θα το αποφασίσει. Υποτίθεται ότι το software (και ειδικά το free software) έχει ως κέντρο τον χρήστη (αν εξαιρέσεις το pidgin που οι devs του είναι βλαμένοι) και όχι τον developer.

2) Θέλω να έχω αξιόπιστο support ειδικά όταν μιλάμε για τόσο σημαντικό πρόγραμμα. Όταν σου λέει "το σενάριο χωρίς cgroups δεν μας ενδιαφέρει οπότε δεν το τεστάρουμε" και "αν υπάρχει corruption στο logging δεν έγινε και κάτι, πάμε παρακάτω" είναι αυτό συμπεριφορά ? Η Ανευθυνότητα σε όλο της το μεγαλείο.

Ελπίζω να γίνει ό,τι και με το git. Να τσατιστεί ο Linus και να γράψει ένα μίνι init το οποίο θα παίζει σωστά και θα είναι υπερ-γρήγορο και να λήξει το θέμα

Α να μπράβο!!! +1000 Ειδικά στο τελευταίο! Έχουμε βαρεθεί την κάθε ψωνάρα στο χώρο του ανοιχτού λογισμικού που το παίζει η απόλυτη ντίβα!