Boycott systemd

[mrsaccess]

Είναι υπερβολικός. Ο λόγος που οι μεγάλες εταιρείες αποδέχονται το systemd είναι πως σιγά σιγά ο κλασσικός server εξαφανίζεται και πάμε σε setup με πολλά μηχανήματα, δυναμικό scaling κλπ. Δεν είναι τυχαίο πχ που το CoreOS επέλεξε και αυτό systemd.

[megahead13]

Είναι υπερβολικός. Ο λόγος που οι μεγάλες εταιρείες αποδέχονται το systemd είναι πως σιγά σιγά ο κλασσικός server εξαφανίζεται και πάμε σε setup με πολλά μηχανήματα, δυναμικό scaling κλπ. Δεν είναι τυχαίο πχ που το CoreOS επέλεξε και αυτό systemd.

1. Ποιoς είναι ο κλασσικός server;;
2. Setup με πολλά μηχανήματα και δυναμικό scaling; Clusters δηλαδή; Πού είναι το καινούργιο σε αυτό και πώς επηρεάζει το development ενός καινούργιου init συστήματος;;;
3. CoreOS;;; Εδώ μιλάμε για το Enterprise που ως επί το πλείστον τρέχει RHEL, SLES, Debian/Ubuntu

- - - Updated - - -

Απ' οτι γνωρίζω περα απο το επεισόδιο με τον Kay οχι.

Link γι' αυτό σε παρακαλώ;;

[mrsaccess]

1. Ποιoς είναι ο κλασσικός server;;
2. Setup με πολλά μηχανήματα και δυναμικό scaling; Clusters δηλαδή; Πού είναι το καινούργιο σε αυτό και πώς επηρεάζει το development ενός καινούργιου init συστήματος;;;
3. CoreOS;;; Εδώ μιλάμε για το Enterprise που ως επί το πλείστον τρέχει RHEL, SLES, Debian/Ubuntu

Το enterprise που αναφέρεις έχει περάσει σε systemd. Το CoreOS σε περίπτωση που δεν το έχεις μυριστεί ακόμη γίνεται τρομερά δημοφιλές. Στο Google compute Engine πχ είναι first class citizen.

[KernelPanic]

Link γι' αυτό σε παρακαλώ;;

Here you are : https://lkml.org/lkml/2014/4/2/420 enjoy...

- - - Updated - - -

Ο λόγος που οι μεγάλες εταιρείες αποδέχονται το systemd είναι...

Οτι πέρασε σαν default στην Redhat και Canonical οπου και οι περισσοτερες εταιρίες στηρίζουν προιοντα τους...

Όσο για το dynamic scalability πιστευω πως δεν χρειάζεται 1 τοσο bloat init system παρα μόνο 1 service awarennes προγραμμα (αν και υπάρχουν ήδη) καθώς και 1 αξιοπρεπεστατος loadblancer...

[megahead13]

Το enterprise που αναφέρεις έχει περάσει σε systemd. Το CoreOS σε περίπτωση που δεν το έχεις μυριστεί ακόμη γίνεται τρομερά δημοφιλές. Στο Google compute Engine πχ είναι first class citizen.

Καλά εντάξει. Πάνε δες τις αγγελίες για Sys Admin και τα requirements που έχουν και μετά τα ξαναλέμε για CoreOS. Νομίζεις ότι πάνε όλοι και τρέχουν να εγκαταστήσουν ότι τελευταίο βγαίνει; Έχεις ιδέα για τί IT infrastructures και για τί επενδύσεις μιλάμε;; Επίσης αν νομίζεις ότι Enterprise σημαίνει μόνο cloud computing με web servers, databases, κτλ τότε προφανώς κάτι δεν ξέρεις καλά. Τέλος απάντησε αν θες σε παρακαλώ το πως επηρεάζει το dynamic scalability την ανάπτυξη ενός init συστήματος.

Here you are : https://lkml.org/lkml/2014/4/2/420 enjoy...

Ευχαριστώ

Οτι πέρασε σαν default στην Redhat και Canonical οπου και οι περισσοτερες εταιρίες στηρίζουν προιοντα τους...

Όσο για το dynamic scalability πιστευω πως δεν χρειάζεται 1 τοσο bloat init system παρα μόνο 1 service awarennes προγραμμα (αν και υπάρχουν ήδη) καθώς και 1 αξιοπρεπεστατος loadblancer...

Έτσι ακριβώς!

[mobinmob]

Με τις μαλακίες που κάνουν θα βγάλουν όλη τη Unix/Linux βιβλιογραφία που διαβάζουμε τόσα χρόνια άχρηστη!! O Linus έχει τοποθετηθεί επί του συγκεκριμένου θέματος;;

Είπε κάποια πράγματα στο πρόσφατο debconf.
http://www.youtube.com/watch?v=5PmHRSeA2c8
Στο 18:40 περίπου.
To ζήτημα είναι τι θα γίνει με το kdbus και τον διάδοχο του kmscon - εννοείται πως θα είναι και αυτά (το userland του πρώτου) στο systemd project.

- - - Updated - - -

Τέλος απάντησε αν θες σε παρακαλώ το πως επηρεάζει το dynamic scalability την ανάπτυξη ενός init συστήματος.

Εδώ και αρκετό καιρό, δεδηλωμένος στόχος του systemd είναι να είναι απαραίτητο κομμάτι του λειτουργικού (κάποτε το έλεγε ο ίδιος ο Poettering coreos, πριν εμφανιστεί η ομώνυμη διανομή). Δεν είναι απλά init και με δεδομένο το πως έχει αναπτυχθεί δεν ξέρω αν ήταν αυτός μόνο ο αρχικός στόχος.

- - - Updated - - -

Δεν είναι τυχαίο πχ που το CoreOS επέλεξε και αυτό systemd.

Δεν επέλεξε systemd. Χτίστηκε γύρω από το systemd, υπάρχει διαφορά.

[mrsaccess]

Καλά εντάξει. Πάνε δες τις αγγελίες για Sys Admin και τα requirements που έχουν και μετά τα ξαναλέμε για CoreOS. Νομίζεις ότι πάνε όλοι και τρέχουν να εγκαταστήσουν ότι τελευταίο βγαίνει; Έχεις ιδέα για τί IT infrastructures και για τί επενδύσεις μιλάμε;; Επίσης αν νομίζεις ότι Enterprise σημαίνει μόνο cloud computing με web servers, databases, κτλ τότε προφανώς κάτι δεν ξέρεις καλά. Τέλος απάντησε αν θες σε παρακαλώ το πως επηρεάζει το dynamic scalability την ανάπτυξη ενός init συστήματος.

Ξαναγράφω γιατί μάλλον δεν το έχετε καταλάβει: το enterprise έχει ήδη αποδεχτεί το systemd. Το enterprise *καθορίζεται* από τις Redhat, Oracle, Canonical, Novel κλπ. Οι εταιρείες εκεί πληρώνουν για support.
Το επιχείρημά σας είναι πως δεν θα αποδεχτούν το systemd αυτοί που το έχουν ήδη αποδεχτεί. Ό,τι και να πεις εσύ ως admin, η εταιρεία σου θα πληρώσει αδρά την Redhat για ελάχιστες ώρες ενός consultant και θα κάνει ότι πει αυτός, δηλαδή χρησιμοποιείστε systemd.
Το Debian ήταν το τελευταίο οχυρό και έπεσε πανηγυρικά εκ των έσω.

Όσο αφορά το dynamic scalability και το init system σαφώς και είναι συνδεδεμένα. Αν πχ κάθε μέρα κάνεις spawn χιλιάδες VM, το αν θα ξεκινούν σε 10 sec ή σε 60 sec μπορεί να κάνει μεγάλη διαφορά στα κόστη σου. Επίσης δες πχ το dynamic configuration του CoreOS, όπου του περνάς στο boot ένα αρχείο yaml που περιέχει όσα systemd units επιθυμείς. Αντικειμενικά πολύ πιο εύκολο και γρήγορο από το να ξεκινάς το VM και μετά να πρέπει να το ρυθμίσεις με puppet/chef/ansible.

- - - Updated - - -

Είπε κάποια πράγματα στο πρόσφατο debconf.
http://www.youtube.com/watch?v=5PmHRSeA2c8
Στο 18:40 περίπου.

Nice. Ήθελα να το ποστάρω κι εγώ αυτό το βίντεο.

[mobinmob]

Όσο αφορά το dynamic scalability και το init system σαφώς και είναι συνδεδεμένα. Αν πχ κάθε μέρα κάνεις spawn χιλιάδες VM, το αν θα ξεκινούν σε 10 sec ή σε 60 sec μπορεί να κάνει μεγάλη διαφορά στα κόστη σου. Επίσης δες πχ το dynamic configuration του CoreOS, όπου του περνάς στο boot ένα αρχείο yaml που περιέχει όσα systemd units επιθυμείς. Αντικειμενικά πολύ πιο εύκολο και γρήγορο από το να ξεκινάς το VM και μετά να πρέπει να το ρυθμίσεις με puppet/chef/ansible.

To ζήτημα είναι ότι σε τέτοια περιβάλλοντα χρησιμοποιούν ήδη puppet/chef κ.τ.λ. Και είχαν (και συνεχίζουν να έχουν) ήδη συστήματα για να παρακολουθούν/επανεκκινούν/κάνουν reliable logging (σ)τους daemons τα οποία ελέγχουν με puppet/chef, δεν περίμεναν το systemd :P
Ναι, έχει πλεονεκτήματα σε κάποιους τομείς το systemd, το πόσο σημαντικά είναι έχει να κάνει με το τι ακριβώς κάνεις...

[megahead13]

Είπε κάποια πράγματα στο πρόσφατο debconf.
http://www.youtube.com/watch?v=5PmHRSeA2c8
Στο 18:40 περίπου.

Διπλωματική κάπως η απάντηση ή εμένα μου φάνηκε;;

Όσο αφορά το dynamic scalability και το init system σαφώς και είναι συνδεδεμένα. Αν πχ κάθε μέρα κάνεις spawn χιλιάδες VM, το αν θα ξεκινούν σε 10 sec ή σε 60 sec μπορεί να κάνει μεγάλη διαφορά στα κόστη σου. Επίσης δες πχ το dynamic configuration του CoreOS, όπου του περνάς στο boot ένα αρχείο yaml που περιέχει όσα systemd units επιθυμείς. Αντικειμενικά πολύ πιο εύκολο και γρήγορο από το να ξεκινάς το VM και μετά να πρέπει να το ρυθμίσεις με puppet/chef/ansible.

Πριν να φτάσουμε στο init, υπάρχουν άλλοι παράγοντες απείρως πιο σημαντικοί για το πόσο γρήγορα θα ξεκινούν τα VM μου και πόσο γρήγορα θα τρέχουν γενικότερα. Το τελευταίο που θα με απασχολήσει είναι το init από τη στιγμή μάλιστα που δεν έχω επιλογή να το αλλάξω.

To ζήτημα είναι ότι σε τέτοια περιβάλλοντα χρησιμοποιούν ήδη puppet/chef κ.τ.λ. Και είχαν (και συνεχίζουν να έχουν) ήδη συστήματα για να παρακολουθούν/επανεκκινούν/κάνουν reliable logging (σ)τους daemons τα οποία ελέγχουν με puppet/chef, δεν περίμεναν το systemd :P
Ναι, έχει πλεονεκτήματα σε κάποιους τομείς το systemd, το πόσο σημαντικά είναι έχει να κάνει με το τι ακριβώς κάνεις...

[mrsaccess]

To ζήτημα είναι ότι σε τέτοια περιβάλλοντα χρησιμοποιούν ήδη puppet/chef κ.τ.λ. Και είχαν (και συνεχίζουν να έχουν) ήδη συστήματα για να παρακολουθούν/επανεκκινούν/κάνουν reliable logging (σ)τους daemons τα οποία ελέγχουν με puppet/chef, δεν περίμεναν το systemd :P
Ναι, έχει πλεονεκτήματα σε κάποιους τομείς το systemd, το πόσο σημαντικά είναι έχει να κάνει με το τι ακριβώς κάνεις...

Βρε όλα γίνονται με 100 διαφορετικούς τρόπους. Για αυτό έγραψα νωρίτερα πως και τα init scripts δεν είναι περίπατος. Αυτό όμως που είναι της μόδας είναι τα devops και όσο οι admin μπλέκουν με τους developers οι απαιτήσεις και οι server αλλάζουν.

Δεν μου αρέσει το systemd όπως έγραψα στην αρχή του νήματος αλλά θεωρώ πως έχει πολλά καλά και δείχνει μια κατεύθυνση που πρέπει να πάρουμε. Ένα από τα πιο σωστά imo επιχειρήματα του systemd είναι πως το Linux και το GNU δεν είναι πλέον απλά *nix ή POSIX. Έχουν δικές τους δυνατότητες που ξεπερνούν κατά πολύ αυτές των προκατόχων τους. Πρέπει να τις εκμεταλλευτούμε. Το πραγματικό επιχείρημα πίσω από το να μην γίνουμε Microsoft είναι το όποιος δεν καταλαβαίνει το UNIX είναι καταδικασμένος να το ξανα-ανακαλύψει. Αυτό είναι ένα πραγματικό ρίσκο που πρέπει να πάρουμε. Το Ubuntu για παράδειγμα πήρε ένα ρίσκο με το upstart και τελικά γύρισε σε systemd. Μπορεί του χρόνου να ξαναγυρίσει σε sys-v-init.

[GoofyX]

Ένα από τα πιο σωστά imo επιχειρήματα του systemd είναι πως το Linux και το GNU δεν είναι πλέον απλά *nix ή POSIX. Έχουν δικές τους δυνατότητες που ξεπερνούν κατά πολύ αυτές των προκατόχων τους. Πρέπει να τις εκμεταλλευτούμε. Το πραγματικό επιχείρημα πίσω από το να μην γίνουμε Microsoft είναι το όποιος δεν καταλαβαίνει το UNIX είναι καταδικασμένος να το ξανα-ανακαλύψει. Αυτό είναι ένα πραγματικό ρίσκο που πρέπει να πάρουμε. Το Ubuntu για παράδειγμα πήρε ένα ρίσκο με το upstart και τελικά γύρισε σε systemd. Μπορεί του χρόνου να ξαναγυρίσει σε sys-v-init.

Ένα από τα χαρακτηριστικά του Linux που βοήθησε στην εξάπλωσή του ήταν το Unix-οειδές του πράματος. Δηλαδή οι εφαρμογές σε Unix ήταν εύκολα πλέον portable σε Linux. Ναι, σίγουρα πλέον το Linux είναι κάτι παραπάνω από ένα Unix clone, αλλά αν αρχίσει να πηγαίνει προς εντελώς άλλη κατεύθυνση, δεν το βλέπω και πολύ σόι...

Αυτό που με εξοργίζει με τέτοιες προσπάθειες είναι ότι θέλουν να το επιβάλουν με το στανιό και ότι το δικό τους είναι το καλύτερο.

[mobinmob]

Βρε όλα γίνονται με 100 διαφορετικούς τρόπους. Για αυτό έγραψα νωρίτερα πως και τα init scripts δεν είναι περίπατος. Αυτό όμως που είναι της μόδας είναι τα devops και όσο οι admin μπλέκουν με τους developers οι απαιτήσεις και οι server αλλάζουν.

Μεταξύ αυτών των τρόπων και κάποιοι απλούστατοι που δεν απαιτούν ένα νέο τιτανοτεράστιο init και λειτουργούν αξιόπιστα εδώ και χρόνια :P

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

Δεν διαφωνώ ότι έχει θετικά στοιχεία, αλλά αυτό το "πρέπει" με τρομάζει, ειδικά όταν συνδυάζεται με εταιρική υποστήριξη και με μισό εκατομμύριο γραμμές C που φιλοδοξούν να αντικαταστήσουν σημαντικό μέρος του λειτουργικού... Το να έχουμε βασικά αρχεία ρυθμίσεων κοινά στις διανομές (π.χ. το crypttab δεν είχε 100% κοινή σύνταξη σ' όλες τις διανομές πριν το systemd) είναι αναμφίβολα θετικό. Το ίδιο και να έχουμε συγκεκριμένα dbus interfaces για κάποιες ρυθμίσεις.
Τώρα το να έχεις έναν ακόμη dhcp client, έναν ακόμα ntp client, ένα ακόμα εργαλείο για ρύθμιση δικτύου, ένα νέο σύστημα για logging (...) δεν ξέρω πόσο θετικό μπορεί να χαρακτηριστεί. Όπως και το να έχεις νέα χαρακτηριστικά του λειτουργικού με μοναδική υλοποίηση μέσα στο systemd project και "δεμένα" απ' ότι φαίνεται με το systemd init.

Το Ubuntu για παράδειγμα πήρε ένα ρίσκο με το upstart και τελικά γύρισε σε systemd. Μπορεί του χρόνου να ξαναγυρίσει σε sys-v-init.

Με τι κόστος άραγε...

[KernelPanic]

Αυτό είναι ένα πραγματικό ρίσκο που πρέπει να πάρουμε. Το Ubuntu για παράδειγμα πήρε ένα ρίσκο με το upstart και τελικά γύρισε σε systemd. Μπορεί του χρόνου να ξαναγυρίσει σε sys-v-init.

Σε Enterprise IT (και οχι μόνο) προσπαθείς να μειώσεις το ρίσκο και οχι να το αυξησεις. Παρε για παραδειγμα εταιρίες που το προιον τους στηρίζεται στο linux και ταυτοχρονα πρέπει να είναι οσο ποιο ασφαλές γίνεται και να τηρεί συγκεκριμμένες προδιαγραφές ασφαλείας. Ξέρεις πόσο μεγάλο effort χρειάζεται για να τεσταρεις ολα τα network services για vulnerabilities/security issues (γιατι o LP με το υφάκι που έχει αμφιβάλω αν εχει κάνει κατι τετοιο. Αυτος γράφει κωδικα και ολοι οι αλλοι να πανε να... ) κτλ κτλ??

Βάζοντας λοιπόν ακόμα 1 ntp , dhcp , δεν ξέρω τι άλλο θα βάλουν ολα σε 1 το ρίσκο αυξάνεται αρκετά...

Εγώ σαν απλος χρήστης ναι θέλω να δοκιμάσω οτι νεο υπάρχει για το laptop/desktop μου αλλα για την δουλεια δεν πάιρνεις ευκολα τετοιες αποφάσεις...

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

[mrsaccess]

@GoofyX

Δεν αλλάζει το portability του POSIX κώδικα. Αλλάζει το portability όταν κάποιος θέλει να χρησιμοποιήσει ειδικά χαρακτηριστικά του Linux, κάτι που ισχύει για όλα τα λειτουργικά.
Πάρε παράδειγμα τα bash scripts. Πάρα πολλά bash scripts δεν είναι συμβατά με άλλα συστήματα είτε γιατί χρησιμοποιούν δυνατότητες του bash είτε γιατί χρησιμοποιούν τις βασικές εφαρμογές (grep κλπ) με GNU options.

Κρίμα δεν είναι να έχουμε cgroups, btrfs κλπ στο Linux και να μην τα εκμεταλλευόμαστε; Όλοι οι άλλοι εκμεταλλεύονται τα δικά τους.

Μεταξύ αυτών των τρόπων και κάποιοι απλούστατοι που δεν απαιτούν ένα νέο τιτανοτεράστιο init και λειτουργούν αξιόπιστα εδώ και χρόνια :P

Οκ. Όταν έμαθα πως το systemd κάνει logging σε binary format έκανα —όπως και αρκετοί άλλοι— facepalm. Μια μέρα όμως που ήμουν σε κάποιο systemd distro και είδα πως με journalctl -u service βλέπω τα logs μιας συγκεκριμένης service με στάνταρντ timestamps, pids και καθαρό διαχωρισμό ανάμεσα σε reboots του μηχανήματος ή restarts της service σκέφτηκα «αυτό ήταν εύκολο και βολικό!».
Μπορεί να μου λες πως υπάρχουν απλούστατοι τρόποι αλλά επειδή έχω ρυθμίσει αρκετές φορές το syslog-ng, ξεχωριστά για κάθε εφαρμογή, έχω φάει ώρες να ψάχνω σε logs, έχω αναγκαστεί να κλείσω το logging στο syslog κάποιας εφαρμογής και να το γυρίσω σε αρχείο κλπ, θεωρώ πως είναι μια σημαντική βελτίωση το journald.

Ένα άλλο παράδειγμα είναι πως πράγματι έφαγα μερικές ώρες για να καταλάβω πως κάνει resolve τα service dependencies o systemd με τις ηλιθιότητες του after και του require ή τις ιδιαιτερότητες του oneshot και έβριζα. Η αλήθεια όμως είναι πως για τα ίδια πράγματα με init scripts κάποτε έφαγα περισσότερο χρόνο και το χειρότερο είναι πως από διανομή σε διανομή αλλάζουν.

Σε Enterprise IT (και οχι μόνο) προσπαθείς να μειώσεις το ρίσκο και οχι να το αυξησεις. Παρε για παραδειγμα εταιρίες που το προιον τους στηρίζεται στο linux και ταυτοχρονα πρέπει να είναι οσο ποιο ασφαλές γίνεται και να τηρεί συγκεκριμμένες προδιαγραφές ασφαλείας. Ξέρεις πόσο μεγάλο effort χρειάζεται για να τεσταρεις ολα τα network services για vulnerabilities/security issues (γιατι o LP με το υφάκι που έχει αμφιβάλω αν εχει κάνει κατι τετοιο. Αυτος γράφει κωδικα και ολοι οι αλλοι να πανε να... ) κτλ κτλ??

Πάμε ξανά, δεν μιλάμε για κάτι που θα γίνει. Μιλάμε για κάτι που έχει ήδη γίνει. Αν είσαι 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 αλλά θα πρέπει να τα κάνω μόνος μου.

_____

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

[mobinmob]

Βάζοντας λοιπόν ακόμα 1 ntp , dhcp , δεν ξέρω τι άλλο θα βάλουν ολα σε 1 το ρίσκο αυξάνεται αρκετά...

Εγώ σαν απλος χρήστης ναι θέλω να δοκιμάσω οτι νεο υπάρχει για το laptop/desktop μου αλλα για την δουλεια δεν πάιρνεις ευκολα τετοιες αποφάσεις...

Δεν νομίζω πως υπάρχει κάποιος που θα χρησιμοποιήσει αυτά τα extra εργαλεία του systemd για σοβαρή δουλειά, όπως ελπίζω ότι κανείς δεν θα χρησιμοποιεί σοβαρά το binary logging του journald (γι' αυτό και υπάρχει συνεργασία με syslog-ng και rsyslog).

- - - Updated - - -

@GoofyX
Κρίμα δεν είναι να έχουμε cgroups, btrfs κλπ στο Linux και να μην τα εκμεταλλευόμαστε; Όλοι οι άλλοι εκμεταλλεύονται τα δικά τους.

Ξέρεις, η libcg υπήρχε (μαζί με τα σχετικά utils) πριν το systemd και δούλευε μια χαρά...

Οκ. Όταν έμαθα πως το systemd κάνει logging σε binary format έκανα —όπως και αρκετοί άλλοι— facepalm.

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

Αν βάλω χειροκίνητα την python 2.7 στο Centos 6 παράλληλα με την 2.6 (γιατί το yum του 6 χρειάζεται την 2.6) θα είμαι πιο ευάλωτος αφού δεν θα έχω αυτόματα update αλλά θα πρέπει να τα κάνω μόνος μου.

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