Κάθε μέρα οι υπολογιστές μας αποτελούν ένα πιο σημαντικό μέρος της ζωής μας, αν έχει κάποιο πρόβλημα επηρεάζει τη διάθεσή μας, το χιούμορ μας. Σίγουρα, οι χρήστες των Windows είναι πιο επιρρεπείς σε κρίσεις πανικού, παρά σε ιούς (ζωντανό linux!), τι γίνεται εάν ανασυγκροτήσετε τον σκληρό δίσκο, τι γίνεται αν κάνετε αναζήτηση και εγκατάσταση του Clean Master για υπολογιστή (Αν και εδώ στο Linux πρέπει να καθαρίσουμε το σύστημα, το BleachBit είναι μια από τις προτιμώμενες εναλλακτικές λύσεις). Πρόσφατα οι χρήστες Linux έχουν (μερικούς) έναν συγκεκριμένο πονοκέφαλο που ονομάζεται: systemd
Έχω διαβάσει ένα ενδιαφέρον άρθρο systemd, που φαίνεται να είναι η τάση για πολύ καιρό.
ΣύστημαD, κάτι που φαίνεται σαν (και θα χρησιμοποιήσω τα λόγια ενός φίλου), ένα δαχτυλίδι για να τα κυριαρχήσουν όλα … Σε άλλους απλά δεν έρχεται ή φεύγει, αρκεί ο υπολογιστής να λειτουργεί καλά, δεν έχει σημασία αν το init κάνει X ή Y πράγματα, ή εάν χρησιμοποιείται το systemd. Σε αυτόν που γράφει, λοιπόν ... ας πούμε ότι προτιμώ το init, το βρίσκω απλούστερο 🙂
Αφήνω το άρθρο εδώ:
Πριν ξεκινήσω, πρέπει να πω ότι δεν μου αρέσει η απόφαση να αλλάξω τα πράγματα στο Debian, αλλά σε καμία περίπτωση δεν σκοπεύω να εγκαταλείψω την αγαπημένη μου σπείρα. Απλώς το προσπαθώ, αν πρόκειται να συζητήσουμε ένα θέμα, τουλάχιστον το κάνουμε όσο το δυνατόν πιο προετοιμασμένο, παρόλο που δεν θεωρώ τον εαυτό μου υπέρ του συστήματος. Για να επιτύχω την απομυθοποίηση του συστήματοςd θα βασιστώ σε έναν ιστότοπο όπου οι προγραμματιστές δίνουν την άποψή τους που ήρθε στα χέρια μου από έναν συνάδελφο που φαίνεται να είναι pro-systemd παρόλο που δεν είναι χρήστης του Debian. Με αυτό είπε, νομίζω ότι μπορώ να προχωρήσω στην προσπάθεια απομυθοποίησης όσων λέγονται για το systemd.
Το systemd είναι δυαδικό
Ίσως αυτή είναι μια από τις πτυχές που μας σοκάρει περισσότερο, αν όλα βασίζονται σε δυαδικά, πώς παρακολουθούμε τα πράγματα που συνήθως κάνουμε μέσω των αρχείων καταγραφής; Δεν έχω ιδέα πώς γεννήθηκε αυτός ο μύθος, αλλά δεν είναι απολύτως αλήθεια.
Το systemd διαμορφώνεται σχεδόν αποκλειστικά μέσω αρχείων απλού κειμένου. Ορισμένες ρυθμίσεις που μπορούν επίσης να τροποποιηθούν με τη γραμμή εντολών του πυρήνα και μέσω μεταβλητών περιβάλλοντος. Δεν υπάρχει τίποτα δυαδικό στη διαμόρφωσή σας (ούτε καν XML). Απλό, απλό και εύκολο στην ανάγνωση αρχείο κειμένου.
Αυτό το πράγμα είναι μονολιθικό και ελέγχει τα πάντα
Πριν φτάσω στον παραπάνω ιστότοπο, ομολογώ ότι σκέφτηκα έτσι τον εαυτό μου, αλλά αφού διάβασα αυτά που λένε οι προγραμματιστές της, η γνώμη μου άλλαξε κάτι ...
Εάν δημιουργήσετε το systemd με όλες τις επιλογές διαμόρφωσης ενεργοποιημένες θα δημιουργήσετε 69 μεμονωμένα δυαδικά αρχεία. Αυτά τα δυαδικά αρχεία εξυπηρετούν διαφορετικές εργασίες και διαχωρίζονται προσεκτικά για διάφορους λόγους. Για παράδειγμα, το systemd έχει σχεδιαστεί με γνώμονα την ασφάλεια, επομένως οι περισσότεροι δαίμονες λειτουργούν με λιγότερα δικαιώματα (χρησιμοποιώντας δυνατότητες πυρήνα, για παράδειγμα) και είναι υπεύθυνοι για πολύ συγκεκριμένες εργασίες, για την ελαχιστοποίηση του αποτυπώματος τους. ασφάλεια και επιπτώσεις. Επίσης, οι παράλληλες ρυθμίσεις συστήματος εκκινούν περισσότερο από οποιαδήποτε προηγούμενη λύση. Αυτή η "παράλληλη" δημιουργείται με εκτέλεση διάφορες διαδικασίες παράλληλα. Επομένως, φαίνεται ότι το systemd είναι πολύ καλά διαιρεμένο σε πολλά δυαδικά αρχεία και ως εκ τούτου διαδικασίες. Στην πραγματικότητα, πολλά από αυτά τα δυαδικά αρχεία διασπώνται τόσο καλά ώστε είναι πολύ χρήσιμα εκτός του συστήματοςd.
Ένα πακέτο που περιελάμβανε 69 μεμονωμένα δυαδικά αρχεία ήταν δύσκολο να κληθεί μονολιθικός. Αυτό που διαφέρει από τις προηγούμενες λύσεις, ωστόσο, είναι ότι στέλνουμε περισσότερα συστατικά σε ένα απλό tarball και τα διατηρούμε αλυσοδεμένα σε ένα μοναδικό αποθετήριο με έναν ενοποιημένο κύκλο κυκλοφορίας.
Αυτό δεν μοιάζει με το Unix
Υπάρχει σίγουρα κάποια αλήθεια σε αυτό. Τα αρχεία πηγής systemd δεν περιέχουν ούτε μία γραμμή κώδικα από τις αρχικές γραμμές UNIX. Ωστόσο, η έμπνευση προέρχεται από το UNIX και έτσι υπάρχει πολύ UNIX στο systemd. Ένα παράδειγμα θα ήταν η ιδέα του UNIX "όλα είναι ένα αρχείο" που αντικατοπτρίζεται στο ότι στο σύστημα και όλες οι υπηρεσίες εκτίθενται κατά το χρόνο εκτέλεσης σε ένα σύστημα αρχείων πυρήνα, το ομάδες. Έτσι, ένα από τα αρχικά χαρακτηριστικά του UNIX ήταν η υποστήριξη πολλαπλών θέσεων, με βάση την ενσωματωμένη υποστήριξη τερματικού. Με το systemd φέραμε και πάλι υποστήριξη πολλαπλών θέσεων, αλλά αυτή τη φορά με πλήρη υποστήριξη για το σημερινό υλικό, που καλύπτει γραφικά, ποντίκια, ήχο, κάμερες και πολλά άλλα. Στην πραγματικότητα, ο σχεδιασμός του συστήματοςd ως μια σειρά ολοκληρωμένων εργαλείων που ο καθένας έχει τους ατομικούς του σκοπούς, αλλά όταν χρησιμοποιείται μαζί είναι περισσότερο από το άθροισμα των τμημάτων, το οποίο είναι λίγο πολύ ο πυρήνας της φιλοσοφίας του UNIX. Έτσι ο τρόπος χειρισμού του έργου μας (δηλαδή η διατήρηση του περισσότερου πυρήνα του λειτουργικού συστήματος σε ένα αποθετήριο git) είναι πολύ πιο κοντά στο μοντέλο BSD (το οποίο είναι ένα πραγματικό UNIX, σε αντίθεση με το Linux) για να ολοκληρώσετε τα πράγματα (όπου το μεγαλύτερο μέρος του βασικού λειτουργικού συστήματος διατηρείται σε ένα μοναδικό αποθετήριο CVS / SVN) που δεν συνέβαινε ποτέ στο Linux.
Τελικά, το ζήτημα αν κάτι είναι UNIX ή όχι έχει ελάχιστη σημασία. Όντας τεχνικά άριστο, είναι σχεδόν μοναδικό για το UNIX. Για εμάς, το UNIX είναι μια σημαντική επιρροή (στην πραγματικότητα, η μεγαλύτερη), αλλά έχουμε και άλλες επιρροές. Ως εκ τούτου, σε ορισμένες περιοχές το σύστημα θα είναι πολύ UNIX, και σε άλλους λίγο λιγότερο.
Αυτό είναι πολύ περίπλοκο ...
Υπάρχει σίγουρα κάποια αλήθεια σε αυτό. Οι σύγχρονοι υπολογιστές είναι πολύπλοκα ζώα και το λειτουργικό σύστημα που τρέχει σε αυτούς προφανώς θα είναι επίσης, οπότε πρέπει να είναι περίπλοκοι. Ωστόσο, το systemd δεν είναι σίγουρα πιο περίπλοκο από τις προηγούμενες υλοποιήσεις των ίδιων στοιχείων. Είναι απλούστερο και έχει λιγότερους πλεονασμούς. Από την άλλη πλευρά, η δημιουργία ενός απλού λειτουργικού συστήματος που βασίζεται σε σύστημα θα περιλαμβάνει πολύ λιγότερα πακέτα από τις παραδοσιακές χρήσεις Linux. Λιγότερα πακέτα διευκολύνουν την κατασκευή του συστήματός σας, απαλλάσσει τις αλληλεξαρτήσεις και πολλές από τις διαφορετικές συμπεριφορές όλων των σχετικών στοιχείων.
Αυτό δεν θα με επιτρέψει να χρησιμοποιήσω σενάρια shell
Αυτό είναι εντελώς αναληθές. Απλά Δεν τα χρησιμοποιούμε για τη διαδικασία εκκίνησης, επειδή πιστεύουμε ότι δεν είναι το καλύτερο εργαλείο για αυτόν τον συγκεκριμένο σκοπό, αλλά αυτό δεν σημαίνει ότι το systemd δεν ήταν συμβατό με αυτά. Μπορείτε εύκολα να εκτελέσετε τα σενάρια κελύφους ως υπηρεσίες συστήματος ή δαίμονες, μπορείτε να εκτελέσετε σενάρια γραμμένα κάθε γλώσσα ως υπηρεσίες systemd δεδομένου ότι το systemd δεν ενδιαφέρεται λιγότερο για το τι μπορεί να εκτελεστεί. Από την άλλη πλευρά, χρησιμοποιούμε σε μεγάλο βαθμό σενάρια κελύφους για δικούς μας σκοπούς, για εγκατάσταση, κατασκευή, δοκιμή συστήματος. Και μπορείτε να επικολλήσετε τα σενάρια στη διαδικασία πρώιμης εκκίνησης, χρησιμοποιούνται για κανονικές υπηρεσίες, μπορούν να εκτελεστούν στην τελευταία στάση, ουσιαστικά δεν υπάρχουν όρια.
Σε αυτό το σημείο υποθέτω ότι ορισμένες από τις βασικές πεποιθήσεις μπορεί να έχουν διευκρινιστεί, παρόλο που δεν αισθάνεστε σαν υποστηρικτής της αλλαγής και έχοντας τις αμφιβολίες μου για το «ένας δαίμονας για τον έλεγχο όλων"Νομίζω ότι στο τέλος κανείς δεν θα τολμήσει να πει ότι τουλάχιστον δεν λειτουργεί, γνωρίζω ακόμη και μερικούς χρήστες που το παρατηρούν ότι με το σύστημα" ο υπολογιστής λειτουργεί πιο γρήγορα "αλλά αυτοί θα ήταν άλλα πράγματα που θα μπορούσαν να συζητηθούν. Προς το παρόν, μένει μόνο να σας προσκαλέσω να συζητήσετε εδώ τις απόψεις που έχετε σχετικά με τον διαχειριστή εκκίνησης που έχουν υιοθετήσει πολλές διανομές, αν και τώρα οι μεγαλύτερες αντιδράσεις παρατηρούνται στην κοινότητα του Debian, η οποία έχει γεννηθεί ακόμη και ένα νέο πιρούνι με Ολα αυτά. Είτε σας αρέσει είτε όχι, είναι ζήτημα για όλους, από την πλευρά μου θέλω απλώς να κάνω το κομμάτι μου στο απομυθοποιητικό σύστημα, το οποίο τελικά θα είναι παρόν στην Jessie, την επόμενη σταθερή έκδοση του Debian.
Είδα το άρθρο στο GUTL (το οποίο με τη σειρά του προήλθε από Από τον Άμπρεο)
Systemd ρεύμα;
Είμαι ένας από αυτούς που δεν διαβάζουν πολλά νέα όταν κάτι δημιουργεί τόσες αντιπαραθέσεις, προτιμώ να μείνω με περισσότερες τεχνικές λεπτομέρειες. Είναι αυτό…. μερικές φορές νιώθω ότι ορισμένα θέματα σταματούν να είναι απλώς μια τεχνική συζήτηση ή συζήτηση και γίνονται σαν ένα από αυτά τα κουτσομπολιά διασημοτήτων 🙁
Πρώτα μια ανοιχτή σειρά από έναν χρήστη στο σύστημα systemd VS νοημοσύνη, τότε ο Linus Torvalds το λέει αυτό Το systemd δεν είναι τόσο κακό πώς το ζωγραφίζουνκαι για κάποιο λόγο εάν έχει), ένα πιρούνι που ονομάζεται άχρηστο … Χωρίς σχόλια… και τέλος Devuan.
Δεν θα πω αν είναι τόσο κακό όσο λένε, λιγότερο κακό ή χειρότερο. Το σύστημα λειτουργεί για μένα χωρίς προβλήματα, ωστόσο για προσωπική προτίμηση θα προτιμούσα το init, γιατί ο τρόπος οργάνωσης διαφόρων πραγμάτων (όπως τα logs για παράδειγμα) μου αρέσει καλύτερα, αλλά hey, αν το systemd αποκαλείται ιππόδρομος και πρέπει να αντικαταστήσει να αρχίσει (Θα ήταν το μουλάρι πακέτων, που κάνει τα πάντα εκτός από αργό;) Λοιπόν, φίλε, εφ 'όσον η αλλαγή δεν είναι εξαιρετικά απότομη, οι χρήστες μπορούν να προσαρμοστούν χωρίς πολύ πρόβλημα και το σύστημα λειτουργεί καλύτερα (ναι, καλύτερα, δεν είναι αρκετό για μένα!), Καλώς καλωσορίστε 😀
Πολύ καλό άρθρο, έχω πάει με το Linux Mint 17.1 Rebecca με το systemd για λίγες μέρες και αισθάνομαι πολύ πιο ρευστό από ό, τι σε προηγούμενες εκδόσεις, δεν το γνωρίζω πολύ γιατί είμαι ένας κοινός χρήστης που μαθαίνει για αυτό, αλλά θα το γνωρίζω, αυτό είναι το πρώτο άρθρο που διάβασα ότι δεν μιλάει παράσιτα του συστήματοςD.
Για κάτι, θα είναι ο πρώτος που διαβάζετε που δεν μιλάει παράσιτα γι 'αυτόν και από την άλλη πλευρά, πείτε μου, χρησιμοποιείτε το Νομισματοκοπείο σας ως διακομιστής; Θέλω να πω, δεν θα σας ενοχλούσε εάν έχει ένα σφάλμα από καιρό σε καιρό, όχι; και γι 'αυτό δεν σας ενοχλεί, δεν σας αρέσει, αλλά ούτε και το σύστημα σας βιδώνει. Όταν έχετε σφάλματα και εξαιτίας αυτού έχετε σοβαρά προβλήματα σε σοβαρά περιβάλλοντα, θα σας ενοχλήσει.
Φίλε, κάποια διανομή με βάση το Debian Stable που προτείνεις; Θα μπορούσα να χρησιμοποιήσω το Debian, αλλά πρέπει να διαμορφώσετε πολλά πράγματα μόλις εγκατασταθούν, κωδικοποιητές κ.λπ. ... Ποιο προτείνεις; ευχαριστώ.
Και πώς καταφέρατε να εισαγάγετε το systemd στο Linux Mint; Ήθελα να προσπαθήσω να το βάλω, αλλά δεν ξέρω αν υπάρχει κάτι επιπλέον που πρέπει να κάνουμε (σε αυτό, θεωρητικά, το Ubuntu ήδη φέρνει), αν έχετε κάποιον οδηγό για το θέμα ή κάτι που μπορείτε να με μεταβιβάσετε, θα το εκτιμούσα πάρα πολύ
Πολύ καλό άρθρο. Ας δούμε αν τα Ταλιμπάν αντι-ΣύστημαD το διάβασαν (αλλά το αμφιβάλλω)
Σε κάθε περίπτωση, σε ένα χρόνο από τώρα θα τους δω να χρησιμοποιούν SystemD και θα αρνηθούν αυτά που είπαν πριν από ένα χρόνο. Έτσι είναι. Ανθεκτικό στην αλλαγή; Σίγουρα ναι.
Με θεωρείς Ταλιμπάν που δεν θέλω να δεχτώ το Systemd, τότε σε θεωρώ Ταλιμπάν που δεν θέλεις να δεχτείς ότι δεν θέλω να δεχτεί το Systemd. Είμαστε στο χέρι 😉
Ωστόσο, όπως λέει στο τέλος των άρθρων σας:
«elav: Προσωπικό Ιστολόγιο / Twitter / G+ / Χρήστης ArchLinux. Επιστήμονας πληροφορικής, λάτρης της μουσικής, blogger και web designer. Διαχειριστής και Ιδρυτής του DesdeLinux.καθαρά. »
Δηλαδή, χρησιμοποιείτε μία από τις πρώτες διανομές που υιοθέτησε το SystemD.
αφορά
Εντάξει, παιδί μου.
Χωρίς λόγια !!!!, συνεχίστε να παίζετε, ότι η ζωή είναι ρόδινη.
Για σχόλια όπως το δικό σας, αγαπητέ Giskard, γι 'αυτό αποποιείται το SystemD και τι σημαίνει.
Και αν μετά από 20 χρόνια χρησιμοποιώ και δουλεύω με και για Linux, είμαι Ταλιμπάν. Λοιπόν, ας είναι.
Σε ένα χρόνο μιλάμε. Και elav, δεν σας ανέφερα. Σκοτώσατε τον εαυτό σας ως Chacumbele.
Ας δούμε, οι άνθρωποι διαβάζουν και ΜΗΝ διαβάζουν. Υπάρχουν ή δεν υπάρχουν Ταλιμπάν εναντίον του SystemD; Υπάρχουν! Και υπάρχουν άλλοι από την άλλη πλευρά, εκείνοι που το υπερασπίζονται δόντι και καρφί σαν να ήταν πανάκεια. Ποιοι είναι όλοι αυτοί; Οχι! Καθόλου! Υπάρχουν εκείνοι που συμπαθούν το ένα ή το άλλο και βλέπουν το καλό και το κακό τόσο των δικών τους όσο και των άλλων. Με αυτούς μπορείτε να μιλήσετε χωρίς πρόβλημα. Αλλά δεν θα αρνηθούν ότι υπάρχουν Ταλιμπάν. Και από πλευρά σε πλευρά. Και αν κάποιος τσίμπησε από αυτό χωρίς να καταλάβει ότι δεν θα μπορούσαν να είναι Ταλιμπάν, τότε ξεκουράζομαι την υπόθεσή μου επειδή τα στοιχεία τους κάνουν ένοχους.
Αν μιλήσω σε κάποιον για το SystemD και εξαρχής ότι το άτομο δεν τον καλεί με το όνομά του, αλλά το Systemshit ή κάτι παρόμοιο, θα ήθελα ειλικρινά να μου πουν εάν είναι δυνατόν να συνομιλήσω με ένα τέτοιο άτομο που αρχικά αποκλείει τον αντίπαλο. Δεν μπορεί.
Τέλος πάντων, πρέπει να διαβάσετε. Ας δούμε, αν έρθω να πω "υπάρχουν κάποιοι eschejfhduf (εφευρεθεί η λέξη) που χτυπούν τα παιδιά όταν εγκαταλείπουν το σχολείο" και μερικοί έρχονται για να υπερασπιστούν το "eschejfhduf" δεν είναι να πιστεύουμε ότι είναι και οι ίδιοι;
Λοιπόν, εάν κάποιος εκεί έξω (όχι οι Ταλιμπάν, παρακαλώ, και όχι ο eschejfhduf) θέλει να μιλήσει για τα πλεονεκτήματα και τα μειονεκτήματα του init και του SystemD (που και τα δύο έχουν καλό και κακό) θα χαρούμε να είμαι κοντά.
Χαιρετισμούς.
Τα Ταλιμπάν κατά του συστήματος; και πες μου, τι είσαι; οι pro-systemd Ταλιμπάν;, Από την άλλη πλευρά, γιατί υποθέτετε ότι δεν πρόκειται να διαβάσουμε αλλά να σχολιάσουμε άμεσα;, ποιοι είναι οι κλειστοί ταλιμπάν που δεν παραδέχονται συζήτηση και μιλούν σαν LP :: «Είναι το καλύτερο, πιστέψτε με, Ξέρω τι κάνω ". ;
Διάβασα ολόκληρο το άρθρο και μπορώ να σας πω:
Το Systemd βασίζεται σε δυαδικό: True
Η απομυθοποίηση: Λάθος
Το LP αντιπροσωπεύει λανθασμένα αυτό που λέγεται, δηλαδή ότι ο πυρήνας του συστήματος είναι δυαδικός, πολλοί, πάρα πολλοί για να κρεμάσετε από το PID1, αλληλοσυνδεόμενοι, τόσο πολύ που σας καλώ να δείτε το #devuan πώς κοστίζει ο καθαρισμός, για παράδειγμα, logind systemd και τα υπόλοιπα πακέτα στο Debian, δεδομένου του πώς συνδέεται η καταγραφή που αντικαθιστά το PAM με το σύστημα.
Η διαμόρφωση είναι συνοπτική και δεν επιτρέπει ΟΛΑ όσα δεν θα ήθελα, όπως, να απενεργοποιήσω το περιοδικό, καθώς δεν μπορείτε ούτε να σκοτώσετε το PID, ούτε να το σταματήσετε ή οτιδήποτε άλλο, αυτό είναι modularity; Με το sysvinit τουλάχιστον, θα μπορούσατε να σκοτώσετε τα πάντα μέχρι να μείνετε μόνο με init , ίδια αρχή.
===========
"Αυτό το πράγμα είναι μονολιθικό και ελέγχει τα πάντα."
Είναι, πέραν του γεγονότος ότι είναι 2 ή 69 δυαδικά αρχεία, αλληλοσυνδέονται μεταξύ τους με το dbus και, επομένως, με ολόκληρο το λειτουργικό σύστημα, χωρίς να τους επιτρέπεται να μην σχετίζονται εύκολα, η σαφέστερη περίπτωση είναι ημερολόγιο, ότι δεν μπορείτε επίσης να την απενεργοποιήσετε, η έναρξη των δαιμόνων ή των υπηρεσιών γίνεται μέσω "μονάδων" που είναι αρχεία κειμένου, αλλά τίποτα περισσότερο από αυτό, αναλύονται από το systemd και το voila, χωρίς τροποποιήσεις ή hacks σε υπηρεσίες πέρα από αυτό που έχει δημιουργηθεί.
=======
"Δεν μοιάζει με UNIX"
Θα το απαντήσω εν συντομία. Δεν συμμορφώνεται με το LSB, ούτε με το POSIX και σήμερα ένας προγραμματιστής fedora που βοηθά στο #devuan, είπε: «Είναι αλήθεια ότι δεν είναι, δεν έχει σημασία, αυτό που έχει σημασία είναι ότι μπορεί να τρέξει πράγματα που είναι POSIX, τα υπόλοιπα, σίγουρα Δεν ενδιαφέρομαι για το λειτουργικό σύστημα ή οτιδήποτε άλλο, εφόσον λειτουργεί και έχει καλές δυνατότητες ». Και γιατί πρέπει να είναι UNIX ή UNIX-όπως: Κάντε ένα πράγμα και κάντε το καλά, κάτι που δεν κάνει το systemd.
===========
«Ωστόσο, το systemd δεν είναι σίγουρα πιο περίπλοκο από τις προηγούμενες υλοποιήσεις των ίδιων στοιχείων. Είναι απλούστερο και έχει λιγότερη απόλυση »
Λιγότερος πλεονασμός; Σας ζητούν να εγκαταστήσετε ΑΛΛΟ syslog για απλό κείμενο και το ζήτησαν για απομακρυσμένη καταγραφή προτού υπάρξει systemd-journald-remote, δηλαδή, το έβαλαν σε παραγωγή χωρίς να μπορούν να κάνουν απομακρυσμένη καταγραφή χωρίς να εξαρτώνται από το rsyslog, κάτι βασικό όπως το κεντρική σύνδεση. Ακόμα κι έτσι, δεν έχει τη δυνατότητα, ένα απλό boolean να υποδείξει εάν θέλουμε την έξοδο σε δυαδικό ή σε απλό κείμενο και επίσης, εάν επρόκειτο να χρησιμοποιήσει δυαδικό, γιατί όχι κάτι γνωστό ως berkeley DB έτσι ώστε να μπορεί να διαβαστεί από οποιοδήποτε σύστημα UNIX ή Linux;
Απλό;, πραγματικά; ρίξτε μια ματιά στο πόσο απλό είναι: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Κοιτάξτε τον αριθμό γραμμών κώδικα και αρχείων.
=========================
"Αυτό δεν θα με αφήσει να χρησιμοποιήσω σενάρια shell"
Αυτό είναι ψευδές, αλλά και πάλι παρερμηνεύεται, δεν επικρίνεται για το ότι δεν επιτρέπει τη χρήση σεναρίου bash, αλλά για τη μη χρήση τους για την εκκίνηση υπηρεσιών, επομένως δεν είναι τροποποιήσιμο, πειραματισμένο και ευέλικτο όπως το upstart ή το sysvinit. Και από το hackable, εννοώ ότι είναι κουρασμένος.
============================
Εξακολουθείτε να πιστεύετε ότι:
1.- Δεν έχω κανένα λόγο
2.- Δεν διάβασα τίποτα και είμαι Ταλιμπάν;
Αναρωτιέμαι ... πρέπει πραγματικά να εμπιστευτώ αυτά που λέει ο Lennart; Εάν κάποιος ουδέτερος μου πει ότι μπορώ να λάβω υπόψη ορισμένα πράγματα, αλλά αυτό μου φαίνεται το ίδιο, καθώς η Red Hat δημοσιεύει κάτι για να υπερασπιστεί το Systemd
Ουάου, μέχρι που κάποιος εδώ λέει κάτι λογικό και όχι μόνο φόβο και παραπληροφόρηση.
Το άρθρο είναι η ισπανική μετάφραση αυτού που έγραψε ο Lennart.
Χωρίς προσβολή, αλλά η μετάφραση φαίνεται να έχει γίνει από την έκδοση beta του Μεταφραστή Google… 🙁 Δυσκολεύομαι να καταλάβω μερικές παραγράφους. ούτως ή άλλως οι πληροφορίες εκτιμώνται.
@ Charlie-Brown, είναι επειδή ο Lennart δεν ξέρει πώς να εκφραστεί στα Αγγλικά πολύ καλά. Έτσι είναι άσχημο κατανοείται διαβάζοντας το πρωτότυπο.
Οι λόγοι που δίνονται είναι έγκυροι, ωστόσο, πιστεύω ότι ορισμένοι μπορεί να δημιουργήσουν περισσότερες ερωτήσεις. Σε κάθε περίπτωση, η πρότασή μου σε όσους έχουν την ευκαιρία: μεταβείτε στην αρχική πηγή των πληροφοριών http://0pointer.net/blog/projects/the-biggest-myths.html (δυστυχώς για ορισμένους, είναι στα Αγγλικά) που είναι πολύ πιο ολοκληρωμένο και φτάνει μέχρι να τεκμηριώσει έως και 30 λόγους για τους οποίους η χρήση του SistemD θεωρείται ευνοϊκή.
Αυτό το άρθρο που αναφέρετε γράφτηκε από τον δημιουργό του Systemd. Προφανώς, κανένας καλύτερος από αυτόν να υπερασπιστεί το έργο του, ωστόσο, σας καλώ να παρακολουθήσετε αυτό το βίντεο http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html και θα μου πουν τα συμπεράσματά τους σχετικά με αυτό. Δεν λέω περισσότερα.
elav το θέμα των ημερολογίων ημερολογίου που είναι δυαδικό είναι ένα από τα πιο επικριτικά σημεία, ακόμη και ο ίδιος ο Linus το έθεσε, όταν σε μια έκθεση όπου παραδέχτηκε ότι το systemd δεν ήταν τόσο κακό. Επίσης ο ίδιος ο linus εξήγησε ότι μπορείτε να δημιουργήσετε ένα σενάριο για να πάρετε τα δεδομένα του περιοδικού και να τα βάλετε σε απλό κείμενο.
Επίσης, το systemd σάς επιτρέπει να διαμορφώσετε το μέγεθος του δυαδικού ημερολογίου, μειώνοντας τον κίνδυνο πιθανής αποτυχίας.
Στην πραγματικότητα, η τέχνη που αναφέρετε είναι πολύ αβέβαιη, καθώς δεν έχει υπαινιγμό αντικειμενικότητας, και με κάνει ακόμη να αναρωτιέμαι αν το σφάλμα που δείχνει είναι πραγματικό ή είναι πλαστό (σκατά το ιδιόκτητο λογισμικό έτσι ώστε να δίνει το σφάλμα).
όλα τα προγράμματα έχουν κάποια σφάλματα, αλλά φαίνεται ότι πάντοτε θα ψάχνουν για το πέμπτο πόδι της γάτας για να βρουν κάτι λάθος με το systemd.
Για παράδειγμα: στο debian αποφασίστηκε ότι το systemd θα είναι το προεπιλεγμένο init, αλλά δεν εμποδίζει τη χρήση sysvinit ή openrc ή upstart και θα μου πείτε καλά ναι, αλλά δεν μπορείτε να αφαιρέσετε εντελώς το systemd και η απάντησή μου θα ήταν ότι είναι το ίδιο όπως συνέβη στο debian wheezy όπου μπορείτε να εκτελέσετε openrc, systemd ή upstart αλλά κάτω από το sysvinit
PS: Δεν θέλω να φανταστώ πόσο τρελοί θα έχουν με το kdbus και την ενσωμάτωσή του με το systemd σε επίπεδο πυρήνα linux http://kroah.com/log/blog/2014/01/15/kdbus-details/
Εάν μπορεί να είναι. Επιπλέον, σκοπεύω να αποχωρήσω επίσημα από τις συζητήσεις σχετικά με το Systemd. Ό, τι πρέπει να συμβεί 🙂
@rolo η αποτυχία τεκμηριώνεται, του έχουν παρουσιαστεί πολλές αναφορές σφαλμάτων, του παρουσιάζουν ένα βίντεο και τώρα λένε ότι είναι απατεώνες. Εάν θέλετε να είστε σίγουροι, ακολουθήστε τα βήματα και δείτε τι συμβαίνει. Τώρα εδώ είναι περισσότερες πληροφορίες για το θέμα, εφευρέθηκαν σφάλματα; Δεν νομιζω.
https://bugzilla.redhat.com/show_bug.cgi?id=958321
https://bugzilla.redhat.com/show_bug.cgi?id=1054929
https://bugzilla.redhat.com/show_bug.cgi?id=1055570
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=74280
https://bugs.archlinux.org/task/32191
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 (Ο Lennart και οι υπέροχες εξηγήσεις του)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
Αυτό που αναφέρει το βίντεο είναι σίγουρα περίεργο. Ως προγραμματιστής μας λένε πάντα ότι μια λεπτομέρεια δεν πρέπει να επηρεάζει ολόκληρο το σύστημα / πρόγραμμα, για παράδειγμα, εάν ένα επιλεγμένο ερώτημα στη βάση δεδομένων αποτύχει, γιατί πρέπει να διακοπεί ολόκληρο το πρόγραμμα; Είναι το ίδιο με το SystemD, εάν αποτύχει επειδή άλλοι αποτυγχάνουν, δεν ξέρω πόσο καλά είναι. Προφανώς, υπάρχουν περιπτώσεις στις οποίες μια αστοχία είναι πρακτικά μια αποτυχία του συστήματος, αλλά όσο πιο εσωτερικά είναι απομονωμένες οι ιδιότητες του προγράμματος, τόσο καλύτερο θα είναι το προϊόν.
Τώρα, η επίθεση λογισμικού από την αδύναμη πλευρά του δεν είναι καινούργια, είναι μάλλον μια πολύ συνηθισμένη πρακτική και ότι στην πραγματικότητα πρέπει να γίνεται με κάθε πρόγραμμα, οπότε βλέποντας το SystemD να πέφτει στο περιοδικό, είναι μια έγκυρη απόδειξη ότι το SystemD Δεν είναι αυτό που λέγεται ή οδηγείται να πιστέψει.
Όσο περισσότερα πράγματα εξαρτώνται από το SystemD, τόσο χειρότερα θα γίνουν. Εάν πριν από την τοποθέτηση μιας συσκευής δεν κατέρρευσε το σύστημα, τώρα τα πράγματα μπορεί να μην φαίνονται τόσο καλά.
Το SystemD δεν είναι κακό, δεν το μισώ, αλλά δεν είναι αυτό που πολλοί θα ήθελαν να πιστέψετε. Έχει πλεονεκτήματα, αλλά τίποτα που η Upstart δεν είχε ή δεν θα μπορούσε, φυσικά, να εμπλέκεται η Canonical και κανείς δεν ήθελε να προσέξει πια.
Χαιρετισμούς.
αλλά σε αυτό το βίντεο σε καμία στιγμή ξέρω ότι το σύστημα διακόπτεται. αυτό που κάνει ο τύπος είναι να τροποποιήσει το δυαδικό στοιχείο των πληροφοριών του ημερολογίου για να δημιουργήσει το σφάλμα, αλλά το θέμα είναι ότι κάθε φορά που μπαίνει στο σύστημαd.
Από ό, τι καταλαβαίνω, αν περιορίσετε το μέγεθος του δυαδικού ημερολογίου, όταν φτάσει στο όριο δημιουργεί άλλο και ούτω καθεξής. μειώνοντας την πιθανότητα αλλοίωσης όλων των δεδομένων.
Ας είμαστε ξεκάθαροι ... Ποιος θα σκεφτόταν να τροποποιήσει και το αρχείο καταγραφής; XD
@Jorgicio 4 Δεκεμβρίου 2014 6:03 μ.μ.
Ας είμαστε ξεκάθαροι ... Ποιος θα σκεφτόταν να τροποποιήσει και το αρχείο καταγραφής; XD
Αν το είπατε με ειρωνικό τρόπο ... εντάξει, κατάλαβα :)), αλλά αν πραγματικά ρωτήσατε, δίνω την άποψή μου.
Για μένα είναι σαφές ότι δεν είναι σφάλμα, είναι χαρακτηριστικό !! Η ιδέα είναι ότι εάν υπάρχει κλιμάκωση των προνομίων σε μια απομακρυσμένη πρόσβαση, θα ήταν πολύ εύκολο για όσους συμφωνούν να διαγράψουν το αρχείο καταγραφής απλώς επεξεργάζοντάς το για να το καταστρέψουν και για το systemd να το διαγράψει ως κατεστραμμένο και έτσι να απαλλαγούμε από τον εντοπισμό σε αυτήν την απομακρυσμένη πρόσβαση.
Πες μου παρανοϊκό, αλλά δεν έχω άλλο τρόπο σκέψης ... δεν είναι σφάλμα, είναι χαρακτηριστικό και γι 'αυτό δεν δέχονται να διορθώσουν αυτό το σφάλμα.
uff τώρα όλα τα linux blogs κάνουν 200 άρθρα σχετικά με το systemd στο σημείο που γνωρίζω ήδη σχεδόν όλα τα επιχειρήματα κατά και για το xD.
και σιγά-σιγά έχω πειστεί από μερικά από τα επιχειρήματα κατά του συστήματος και μεταξύ αυτών που έχω δει (αν υπάρχει κάτι λάθος, διορθώστε με)
Είδα ακόμη ένα άρθρο σχετικά με τον τρόπο κατάρρευσης ολόκληρου του συστήματος κατά την επεξεργασία ενός δυαδικού αρχείου καταγραφής και ότι δεν παρέχει πληροφορίες ότι το αρχείο είναι κατεστραμμένο.
η έλλειψη σαφήνειας στα αρχεία καταγραφής
μια ομάδα ανάπτυξης που συχνά αγνοεί τις αναφορές σφαλμάτων
Το να είσαι τόσο μεγάλο και να συμπεριλαμβάνεις τόσα πολλά πράγματα μέσα σε ένα init κάνει το σύστημα πολύ πιο ασταθές και αν προσθέσουμε σφάλματα όπως αυτό που αναφέρθηκε παραπάνω, δημιουργεί ένα σύστημα χωρίς τη σταθερότητα που χαρακτηρίζει τόσο πολύ το linux.
Λέγεται αρθρωτό αλλά τμήματα αυτού δεν μπορούν να λειτουργήσουν χωρίς άλλα μέρη του ίδιου συστήματος
μια εξέλιξη που μακροπρόθεσμα δημιουργεί εξαρτήσεις κατά τον προγραμματισμό, καθιστώντας λογισμικό όπως το gnome σχεδόν φορητό σε συστήματα χωρίς σύστημα.
Αντικαθιστά τμήματα (networkd, logind κ.λπ.) που λειτουργούσαν και λαμβάνουν συντήρηση εδώ και χρόνια και τα αλλάζουν για νέα χωρίς καμία ανάγκη που τείνουν να έχουν πολλά περισσότερα σφάλματα.
Από τη στιγμή που χρησιμοποιώ διανομές με βάση το Arch (Manjaro, Bridge Linux, Antergos) που προφανώς χρησιμοποιούν το systemd, πρέπει να πω ότι δεν έχω παράπονα σχετικά με τη χρήση και το χειρισμό του. Η εκκίνηση των υπηρεσιών είναι εύκολη - ακόμη περισσότερο στο Bridge, όπου το Bluetooth ή το modemmanager είναι απενεργοποιημένα από προεπιλογή. Εκτός από ένα σφάλμα που σχετίζεται με το hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Δεν είχα πολλά προβλήματα. Προφανώς δεν νομίζω ότι είναι η γνώμη όλων, αλλά προσωπικά δεν έχω παράπονα 🙂
Δεν μου αρέσει η ιδέα ότι μια εταιρεία (Red Hat) που κατηγορείται ότι συνεργάζεται με την NSA (πίσω πόρτες και έλεγχος των ΗΠΑ) δημιουργεί ένα σύστημα με το οποίο ελέγχονται τα πάντα. Ένα δαχτυλίδι για τον έλεγχο όλων, για δέσμευση στο σκοτάδι, εάν είναι απαραίτητο ..
Από την άλλη πλευρά, πρέπει να παραδεχτώ ότι το intel IRIS PRO 5200 λειτουργεί καλύτερα για μένα και σχεδόν ποτέ, αν όχι πια, το σύστημα γραφικών μου σπάει όταν ξεκινώ το openSUSE 13.1. Και ναι, όλα είναι καλύτερα, ξεκινά και κλείνει πολύ πιο γρήγορα. Πώς με έχει ωφελήσει ένας απλός χρήστης.
Επισημαίνω το σημαντικό μέρος
Εάν κάποιος σας κατηγορήσει ότι πουλάτε ναρκωτικά, είστε αυτόματα έμπορος ναρκωτικών;
@ juanfgs
Διακινητής ναρκωτικών όχι .... συνεργός ναι.
Θεέ ... Θα σε προσβάλω, αλλά τα δικά σου λόγια το κάνουν για σένα.
Απλώς διευκρινίστε ότι το systemd είναι γραμμένο και έτσι πρέπει να γίνει.
Ορθογραφία
Ναι, είναι γραμμένο systemd, όχι σύστημα D ή System D ή ακόμα και SystemD. Και δεν είναι ούτε το σύστημα δ. Γιατί; Επειδή είναι ένας δαίμονας συστήματος, και κάτω από το Unix / Linux αυτοί βρίσκονται σε πεζά γράμματα, και επιτίθενται με πεζά d. Και αφού το systemd διαχειρίζεται το σύστημα, ονομάζεται systemd. Είναι τόσο απλό. Αλλά και πάλι, αν όλα αυτά φαίνονται πολύ απλά για εσάς, καλέστε το (αλλά μην το ξαναγράψετε!) Σύστημα Πέντε Εκατό αφού το D είναι ο ρωμαϊκός αριθμός για 500 (αυτό διευκρινίζει επίσης τη σχέση με το Σύστημα V, σωστά;). Η μόνη κατάσταση όπου το βρίσκουμε εντάξει να χρησιμοποιήσουμε ένα κεφαλαίο γράμμα στο όνομα (αλλά δεν μου αρέσει επίσης) είναι εάν ξεκινήσετε μια πρόταση με το systemd. Στις υψηλές διακοπές μπορείτε επίσης να το γράψετε sÿstëmd. Αλλά και πάλι, το Système D δεν είναι αποδεκτή ορθογραφία και κάτι εντελώς διαφορετικό (αν και κάπως κατάλληλο).
http://freedesktop.org/wiki/Software/systemd/
Εδω επισης? Το βάλατε αυτό στο GUTL .. αλλά ο άνθρωπος, όλοι λένε Linux και όχι GNU / Linux, έτσι με το SystemD το ίδιο.
Σας λέω ότι δεν είναι απαραίτητο να χρησιμοποιήσετε το σύστημα καταγραφής ή το cron που παρέχει το σύστημαD, μπορείτε να ακολουθήσετε το syslog-ng και το cronie για αυτό ή άλλες εναλλακτικές λύσεις
Χρησιμοποιώ το systemD στο ArchLinux από τότε που ήμουν στο aur και φαίνεται πιο εύκολο να το χειριστώ από το debian και το redhat παράγωγο τρόπο, έχει πολλές εντολές κονσόλας που σας σώζουν από την επεξεργασία των αρχείων κειμένου και απλοποιώ τη συγκέντρωση των σεναρίων διαμόρφωση εγκατάστασης (θυμηθείτε ότι στην αψίδα όλα έχουν εγκατασταθεί από κονσόλα)
Και τουλάχιστον το σύστημα ξεκινά γρήγορα, στην αψίδα θα μπορούσατε να ξεκινήσετε τις υπηρεσίες παράλληλα κατά την εκκίνηση του συστήματος, αλλά είναι επικίνδυνο
Αυτό που μου φαίνεται λάθος σχετικά με το ζήτημα είναι ότι οι περισσότεροι λαμβάνουν μέρος, ή είστε pro-systemd ή anti-systemd, και νομίζω ότι έχει τα καλά και τα κακά του πράγματα, είμαι χρήστης και άρχισα να παίζω λίγο με το systemd, πραγματικά Τα καλά πράγματα είναι, η εκκίνηση είναι ταχύτερη και λιγότερο περίπλοκη από την υπόλοιπη αρχή, αν και το τεύχος του περιοδικού με ενοχλεί πολύ.
Καταλαβαίνω ότι αυτοί που μπορούν πραγματικά να πουν εάν είναι καλός ή κακός είναι οι sysadmins ή οι ειδικοί στο θέμα, αλλά μου φαίνεται ότι το systemd αναστάτωσε πριν από λίγο καιρό σταμάτησε να είναι κάτι τεχνικό και έγινε κάτι πιο «show-stop», από την πλευρά μου είμαι λίγο εναντίον αλλά δεν θεωρώ τον εαυτό μου αντι ή υπέρ
@KZKG_Gaara
Βλέπω ότι μεγάλο μέρος αυτού που σχολιάζετε εδώ είναι το ίδιο με το Lennart που δημοσίευσε στο blog του, πιο συγκεκριμένα σε αυτήν την ανάρτηση: http://0pointer.de/blog/projects/the-biggest-myths.html.
Φυσικά, η ανάρτηση είχε κάποιες "διευκρινίσεις" και άφησε στην άκρη ορισμένο τεχνικό περιεχόμενο, προκειμένου να είναι εύκολο να αφομοιώσει πληροφορίες για όσους πρόκειται να το διαβάσουν, αλλά θα είμαστε σοβαροί και ειλικρινείς, ακόμη και αν η αλήθεια πονάει: Το systemd έχει πολλά από τα πράγματα που ο Lennart αρνείται ότι δεν το κάνει αυτό, και πολλά άλλα στην πραγματικότητα. Και με αυτή την έννοια εξηγώ εν μέρει.
1.- Ο Lennart λέει ότι δεν έχει φούσκωμα και ότι δεν έχει υψηλό σύνδρομο NIH (Σύνδρομο που δεν Εφευρέθηκε εδώ). Εάν ναι, παρακαλώ κάποιος να μου εξηγήσει: Γιατί ένα init πρέπει να έχει έλεγχο δικτύου (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), logs (journald), coredumps (systemd -coredump), εντοπισμός σφαλμάτων (systemd-coredump και journald), acpi (logind), κλιμάκωση προνομίων (logind), έλεγχος του ntp (systemd-timesyncd), έλεγχος του dev (το systemd πήρε όλες τις λειτουργίες του udev), έλεγχος του / dev / random (τυχαία γεννήτρια αριθμών) και τον πιο πρόσφατο έλεγχο του TTY (systemd-consoled); Δεν δημιουργήθηκαν πολλά εργαλεία για τέτοιους σκοπούς που το systemd προσθέτει τώρα τα δικά του μερικά με αποκλειστική πρόσβαση (Περιοχή ημερολογίου); Ποια λογική και αποδεκτή εξήγηση μου δίνετε για να μπορέσει ένας init να σπάσει το πρόγραμμα εντοπισμού σφαλμάτων και το cmdline; Προσθέστε σε αυτόν τον έλεγχο του kdbus, το επόμενο IPC που θα ενσωματωθεί στον πυρήνα. Σίγουρα θα μου πουν εδώ: «Αλλά μπορείτε να εγκαταστήσετε ένα άλλο εργαλείο για να ελέγξετε όλα αυτά». Και αν είναι αλήθεια, αλλά, πολλά από αυτά τα εργαλεία λαμβάνουν μόνο μια ροή δεδομένων που ρίχνονται από το systemd, όπως στην περίπτωση του syslog και του rsyslog, τα οποία συνδέονται με ένα data / stream που παρέχει το jurnal έτσι ώστε άλλα εργαλεία να μπορούν να δουν τι οδηγείτε, στο τέλος, αυτό σημαίνει ότι έχετε δύο εργαλεία που κάνουν το ίδιο πράγμα, και ένα από αυτά είναι ένα κουτί με πανίδα. (Παρακαλώ μην μου πείτε ότι ο κώδικας μπορεί να ελεγχθεί, γιατί καλώ κάποιον να "καπνίσει" τον κωδικό περιοδικού και το πλαίσιο του με το systemd και άλλα σχετικά εργαλεία)
2.- Η Lennart μας λέει επίσης ότι το systemd προσφέρει υποστήριξη για σενάρια SysV και LSB. Αυτό είναι "μισή αλήθεια" και "λευκό ψέμα", γιατί η αλήθεια είναι ότι το systemd-214 δεν προσφέρει υποστήριξη για σενάρια bash, SysV ή LSB και αυτό σχετίζεται με τις σημειώσεις έκδοσης για αυτήν την έκδοση.
3.- Τι σύστημα δεν είναι φορητό; Είναι ένα άλλο ζήτημα. Στο BSD δεν λειτουργεί καλά, στο BSD δεν υπάρχουν Cgroups μεταξύ άλλων εργαλείων που πρέπει να εκτελεστεί από το systemd. Αλλά είναι για λόγους σχεδιασμού συστήματος, όχι επειδή δεν είναι φορητό. Έως ότου ο πυρήνας BSD πληροί το ελάχιστο για να τον υποστηρίξει, το systemd δεν θα λειτουργήσει σε αυτήν την πλατφόρμα και αυτό δεν είναι λάθος κανενός, μόνο ότι το BSD δεν ενδιαφέρεται και ούτε ο Lennart. Είναι τόσο απλό. Τώρα, η υποστήριξη για άλλες βιβλιοθήκες C είναι ένα άλλο πράγμα, γνωστά είναι τα προβλήματα glibc (απλώς δημιουργήστε έναν πυρήνα με το χέρι για να δείτε τον αριθμό των επιλογών και λύσεων που έχουν γίνει για να αποφευχθούν αυτές οι λεπτομέρειες, ειδικά για το glibc 2.3, 2.5 και 2.11, μεταξύ άλλων ελαττωμάτων που το glibc έχει περάσει όλα αυτά τα χρόνια) αλλά δεν τελειώνει εκεί δεν τελειώνει, ο ίδιος ο Lennart είπε ότι έχει προτιμήσει να δημιουργήσει τη δική του βιβλιοθήκη libc, γιατί για την ομάδα του που είναι πολύ πιο γρήγορη Κάτι τέτοιο, από την ανάγνωση κώδικα που έχει ήδη δημιουργηθεί (και τεκμηριώνεται παρεμπιπτόντως), αλλά δεν σταματά εκεί, σκοπεύουν να αφαιρέσουν το glibc και να χρησιμοποιήσουν το libc τους όχι μόνο για το systemd, αλλά και για το Fedora, καθιστώντας το πρότυπο για την κατασκευή όλων των πακέτων τους. NIH Πού; Φαίνεται ότι ο καλός παλιός Lennart του αρέσει να συρθεί και να είναι μεγάλος.
4.- Αυτό το systemd δεν είναι μονολιθικό επειδή χωρίζεται σε 69 δυαδικά αρχεία. Ναι, αυτό είναι συζητήσιμο. Το systemd έχει 69 δυαδικά αρχεία, τα οποία εκτελούν διαφορετικές εργασίες, αλλά αυτά τα δυαδικά αρχεία μεταβιβάζουν τις πληροφορίες εργασίας τους στο systemd, οπότε αν αποτύχει, οι πιθανότητες διακοπής του συστήματος αυξάνονται αρκετά δραματικά. Αυτό είναι καλά τεκμηριωμένο, οι αναφορές σφαλμάτων αφθονούν με προβλήματα όπως αυτά και ακόμη και απλούστερα προβλήματα, ανόητα απλά. Το systemd μπορεί να χωριστεί σε εκατοντάδες δυαδικά αρχεία, αλλά όσο ο πυρήνας σας είναι υπό έλεγχο, ο κίνδυνος διακοπής συνεχίζεται και αυξάνεται και αν δεν με πιστεύετε, διαβάστε τις αναφορές σφαλμάτων και διασκεδάστε.
Σημειώστε ότι εδώ δεν έχω σχολιάσει κάτι που το systemd είναι σκουπίδια, έχω κάνει μόνο "τεχνικά" σχόλια (προφανώς μιλώντας για τεχνικά πράγματα γίνεται πολύ περίπλοκο) και έγκυρο, υποστηριζόμενο από πληροφορίες εύκολα προσβάσιμες στο Διαδίκτυο. Τώρα: Τι Linux χρειάζεται ένα τυπικό init; Ναι, σίγουρα θα ήταν κάτι πολύτιμο για την κοινότητα. Τι σύστημα είναι η λύση; Όχι, αν και είναι κοντά, έχει σίγουρα πολλά θετικά, αλλά η ιογενής εξάπλωσή του και ο αριθμός των πραγμάτων που αυξάνει τον κίνδυνο για το τι μπορεί να πάει στραβά και να καταλήξει να βλάψει την κοινότητα.
PS: Αφήνω υλικό όπου μπορείτε να επιβεβαιώσετε αυτό που λέω, να το διαβάσετε θα είναι αρκετά ενδεικτικό και βλέπω ότι δεν συμπεριλαμβάνω ιστολόγια ή κάτι τέτοιο, καθαρή προσωπική και βασισμένη κριτική. Χαιρετισμοί.
http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
http://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
https://bugzilla.redhat.com/show_bug.cgi?id=1057883 (@elav ίσως νιώθετε ότι ταυτίζεστε)
https://code.google.com/p/d-bus/source/browse/kdbus.txt
https://github.com/gregkh/kdbus
http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html
Αμήν αδερφέ .. αμήν ..
Ακόμα δεν βλέπω βάσιμους λόγους να μην υιοθετήσω το systemd. Απλώς ερμηνεύετε αυτό που βλέπετε με φόβο, με αποτέλεσμα υπερβολές. Ούτε σαφή και καλά καθορισμένα πλεονεκτήματα ούτε μειονεκτήματα.
Επιπλέον, αυτή η ενσωμάτωση επιτρέπει την τυποποίηση για την οποία μιλήσατε ακόμη και. Όχι μόνο το Red Hat λειτουργεί σε systemd, αλλά και διαφορετικές εταιρείες και εθελοντές από άλλες διανομές.
Νομίζω ότι το σφάλμα είναι ότι η λειτουργία του systemd δεν έχει μελετηθεί σωστά.
Βλέπω βάσιμους λόγους στην ανάλυση του Yukiteru. Παρατηρήστε ότι αντί για φόβο βλέπω αυστηρότητα, ακρίβεια και σαφήνεια. Πρέπει να είναι ένα θέμα γιατρού.
Δεν είναι φόβος (δεν φοβάμαι ένα κομμάτι κώδικα) και ούτε είναι υπερβολές (ό, τι έχω πει εδώ είναι τεκμηριωμένο και έχω περάσει πολλές πληροφορίες που το επιβεβαιώνουν, πληροφορίες που παρεμπιπτόντως βγαίνουν από τις λίστες και από το μυαλό / φωνή Το χειρόγραφο του Lennart, και όχι από τα σχόλια ενός blogger), είναι η ΠΡΑΓΜΑΤΙΚΟΤΗΤΑ.
Το systemd κάνει όλα αυτά και πολύ περισσότερα, και αυτό είναι κάτι που κάνει (μια διαφορετική ιδέα από το να φοβάσαι) γιατί σίγουρα παίρνει αποδόσεις και κάνει πράγματα που αυτή τη στιγμή μπορούν να γίνουν με άλλα μέσα και ότι παρεμπιπτόντως λειτουργούν καλύτερα και είναι πιο σταθερά. Το systemd μοιάζει πολύ με Windows και αυτό δεν μπορεί να κρυφτεί, απλώς ξέρετε τι κάνουν οι userinit.exe, svchost.exe, smss.exe και άλλες εξαρτήσεις και συγκρίνετέ τα με το systemd, η ομοιότητα είναι τόσο μεγάλη που είναι κακή ιδέα. Τώρα, σίγουρα το systemd μπορεί να έχει καλύτερη ποιότητα από το αντίστοιχο των Windows (ή μπορεί να συμβεί το αντίθετο, κανείς δεν ξέρει πραγματικά, εκτός εάν προγραμματίζετε για τη Microsoft), αλλά δεν μπορείτε να με κατηγορήσετε υπερβολικά και φοβερά όταν διαβάζετε τον ίδιο τον Lennart Σε μια λίστα, μιλώντας για τη δημιουργία μιας εντελώς νέας βιβλιοθήκης C, επειδή έχει βαρεθεί με το Glibc, και για να napa, ρίξτε τη μικρή και ασήμαντη συμβουλή, ότι αυτό το libc μπορεί να χρησιμοποιηθεί για την κατασκευή όλων των πακέτων Fedora. Και αν νομίζετε ότι είναι ψέμα και ότι υπερβάλλω, θα σας αφήσω το μήνυμα σε αυτόν τον σύνδεσμο: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (στα Αγγλικά)
Τώρα πες μου αν είναι υπερβολικό να πω μπροστά σε όλα αυτά τα πράγματα, ότι όταν ο Linus αποφασίσει ότι CONFIG_VT όπως είναι, πρέπει να βγει από τον πυρήνα (κατάσταση που υπάρχει εδώ και πολύ καιρό) και να το μεταβιβάσει στον χώρο του χρήστη, μην συμβεί ένα τρελό πράγμα όπως για να είναι μια ισχυρή εξάρτηση από το systemd-consoled για σχεδόν οποιαδήποτε εγκατάσταση Linux (κάτι πρέπει να χειριστεί VTs, δεν νομίζετε;), που δεν θα έδινε διαφορετικά διανομές εκτός του συστήματος για να επιβάλει έναν διακόπτη. Αν νομίζετε ότι αυτό είναι τέντωμα, επιτρέψτε μου να σας πω ότι δεν έχετε ιδέα τι μπορεί να κάνει και κάνει ο Lennart, καθώς οι τελευταίες του αλλαγές επηρεάζουν την ανάπτυξη του πιρουνιού udev, Gentoo eudev και θα συνεχίσει να το κάνει με τις απειλές του από κάτω από τον πίνακα (για να παραπονεθείτε αργότερα όπως έκανε στο Google+)
@xiep Δεν μπορώ να συμφωνήσω περισσότερο με το σχόλιό σας.
Che Yukiteru, η μακρά δήλωσή σας παραλείπει το γεγονός ότι το email που συνδέσατε με το libc είναι αστείο του ανόητου του Απριλίου, κοιτάξτε την υποσημείωση και δείτε την ημερομηνία (31 Μαρτίου, πιθανώς την 1η Απριλίου στη ζώνη ώρας του Lennart)
Εξασκηθείτε στα αγγλικά σας γιατί είναι υδαρή και θέτει υπό αμφισβήτηση όλη την «έρευνά σας».
@juanfgs φαίνεται ότι είναι ο μόνος που διαβάζει, τουλάχιστον σας επικροτώ για αυτό, αλλά πρέπει να διαβάσετε κάτι πολύ σημαντικό που είναι στο σχόλιό μου, δεν έχει σημασία να το βάλω εδώ:
»NIH Πού; Φαίνεται ότι ο καλός παλιός Lennart του αρέσει να κάνει συρτή και μεγάλη. "
Δεν νομίζω ότι το έγραψε για έναν αθώο λόγο, γνώριζε το γεγονός ότι ήταν ένα άλλο αστείο του Lennart για την Ημέρα των ανόητων του Απριλίου (κακή διάθεση), καθώς και το πάθος του για τη μετατροπή /, / κλπ και οτιδήποτε άλλο σε / Linux. 🙂
PS: Ευχαριστώ αλλά δεν χρειάζεται να εξασκήσω τα Αγγλικά μου, χρησιμοποιώ τη γλώσσα από τότε που ήμουν 6 ετών
aaahh και όλα τα άλλα είναι αλήθεια, επαληθεύστε το 🙂
Αυτό είναι εντελώς συγκλονιστικό, λέτε ότι βασίζεστε σε γεγονότα, αλλά στην πραγματικότητα ακολουθείτε την ένδειξη ότι ο τύπος είναι κακός και θέλει να αναλάβει τον κόσμο και στρίβετε τα γεγονότα για να αντανακλά την ομιλία σας. Αυτό με ενοχλεί πολύ για τους ανθρώπους κατά του συστήματος, δεν λερώνουν λέξεις όταν πρόκειται για περιστροφή γεγονότων και λέγοντας μισές αλήθειες, γεμάτες φυσικά με τη γνώμη τους.
Ο «κανόνας μου» σε αυτές τις περιπτώσεις είναι απλώς η ακόλουθη λογική ανάλυση, ξεκινώντας από την υπόθεση ότι
- Είμαι προγραμματιστής ιστού / εφαρμογές για επιτραπέζιους υπολογιστές ή cli
- Δεν έχω γράψει ποτέ ένα σύστημα init.
- Δεν είμαι συντηρητής μιας διανομής.
ελέγξτε εάν ο συνομιλητής έχει:
- δημιούργησε ένα σύστημα init
- είναι ενεργός συντηρητής του συστήματος init μιας διανομής
και η πραγματικότητα είναι ότι οι περισσότεροι από το anti-systemd αποτυγχάνουν σε αυτό το τεστ, ωστόσο είναι λίγοι άνθρωποι που για κάποιο λόγο ΓΝΩΡΙΖΟΥΝ ΠΕΡΙΣΣΟΤΕΡΑ από τους ανθρώπους πίσω: Debian, Fedora, Archlinux, ο πυρήνας Linux, ολόκληρο το έργο GNOME, μάλλον το έργο KDE, καθώς δεν έχουν διαμαρτυρηθεί για το systemd, το SUSE και για πολλά ακόμη.
Ακόμα κι έτσι, η δηλητηριώδης και βιτριώδης ομιλία του το μόνο πράγμα που επιτυγχάνει είναι να δημιουργήσει διχόνοια, προβλήματα και άλλα. Αυτό είναι το σημείο που δεν μπορώ να περιμένω να αλλάξουν επιτέλους στο BSD καθώς απειλούν από το Xorg, το NetworkManager, το PulseAudio και δεν ξέρω αν οφείλεται σε καθαρή τεχνική άγνοια ή επειδή δεν θα διαμαρτύρονταν για αυτό.
@juanfgs, σας λέω ειδικά για αυτό:
«Και η πραγματικότητα είναι ότι οι περισσότεροι από το anti-systemd δεν περνούν αυτό το τεστ, ωστόσο είναι λίγοι άνθρωποι που για κάποιο λόγο ΓΝΩΡΙΖΟΥΝ ΠΕΡΙΣΣΟΤΕΡΑ από τους ανθρώπους πίσω: Debian, Fedora, Archlinux, ο πυρήνας Linux, ολόκληρο το έργο GNOME Πιθανώς το έργο KDE επίσης, καθώς δεν έχουν διαμαρτυρηθεί για το systemd, το SUSE και το μεγάλο κλπ.
Ακόμα κι έτσι, η δηλητηριώδης και βιτριώδης ομιλία του το μόνο πράγμα που επιτυγχάνει είναι να δημιουργήσει διχόνοια, προβλήματα και άλλα. Αυτό είναι το σημείο που δεν μπορώ να περιμένω να αλλάξουν επιτέλους στο BSD, καθώς απειλούν από το Xorg, το NetworkManager, το PulseAudio και δεν ξέρω αν οφείλεται σε καθαρή τεχνική άγνοια ή επειδή δεν θα διαμαρτύρονταν για αυτό. "
ΛΟΓΑΡΙΑΣΜΟΙ σε εσάς, όλοι μας το anti-systemd είναι δηλητηριώδες και βιτριώδες που το μόνο πράγμα που επιτυγχάνουμε είναι η διαίρεση, τα προβλήματα και ούτω καθεξής. Επιτρέψτε μου να σας πω ότι αυτή είναι η μεγαλύτερη οργή που κατάφερα να διαβάσω εδώ. Δεν ξέρω γιατί το pro-systemd ενοχλεί, όταν αποκαλυφθούν τα δομικά προβλήματα ενός συστήματος, τα οποία προφανώς θα τους επηρεάσουν κάποια στιγμή, γιατί δεν μπορεί να έχει συμβεί τίποτα τώρα, αλλά σε κάποιο σημείο, θα το κάνουν. θα το κάνει, και στη συνέχεια κάποιο αντι-σύστημα θα τους υπενθυμίζει τις λέξεις που έλεγαν πολλές φορές και κανείς δεν τους σταμάτησε, και ίσως κάποιος άλλος αντι-συστήματος θα τους έδινε ένα χέρι.
Προσωπικά, δεν μου αρέσει το systemd, αλλά αυτό δεν σημαίνει ότι δεν χρησιμοποιώ το init, πρέπει να το κάνω, γιατί ακριβώς στη δουλειά μου αν πρέπει να αγγίξω ένα μηχάνημα με αυτό το init, πρέπει να γνωρίζω πώς να χειρίζομαι το. Επίσης, προσωπικά, το έχω χρησιμοποιήσει και εγώ από τότε που ήρθα στο Archlinux και μάλιστα στο Debian και στο Gentoo, οπότε μην μου πείτε ότι η όρασή μου είναι προκατειλημμένη επειδή δεν χρησιμοποιώ το systemd, το έχω χρησιμοποιήσει και ξέρω πόσο κουτό είναι. , και αν πρέπει να βοηθήσω κάποιον εδώ στο φόρουμ DesdeLinux ή στη λίστα IRC ή στη λίστα του Debian (η οποία είναι η διανομή όπου ήμουν η μεγαλύτερη και τη χρησιμοποιώ ακόμα στη δουλειά μου) θα το κάνω ευχαρίστως, γιατί ακριβώς αν υπάρχει κάτι που μου αρέσει στην κοινότητα του Linux, είναι ότι παρά η διαφορά είναι πάντα βοήθεια.
Τώρα για μετάβαση στο BSD, είναι δυνατό, αλλά θα το κάνω μόνο εάν το systemd γίνει τόσο μολυσματικό που δεν μου επιτρέπει να χρησιμοποιήσω άλλη επιλογή, εν τω μεταξύ παραμένω στο Linux, απενεργοποιώντας όλη αυτή την τρέλα, συμπεριλαμβανομένων πολλών από τα πράγματα των ομάδων .
!=
Και πάλι στρίβετε τις λέξεις για να ταιριάζει στην ομιλία σας. Είστε πολύ καλό υλικό για έναν πολιτικό / δημοσιογράφο.
Διευκρινίζω, το πρόβλημά μου δεν είναι ότι αναφέρουν τεχνικά προβλήματα του Systemd, το θέμα είναι ότι πολλές φορές φορτώνουν την ομιλία τους με ψέματα, δηλαδή:
Ότι εάν το systemd πρόκειται να σας αναγκάσει να χρησιμοποιήσετε έναν διακομιστή microhttpd (ο οποίος είναι μια προαιρετική μονάδα ΔΕΝ εγκαθίσταται από προεπιλογή), ότι εάν το systemd είναι ένα μόνο δυαδικό, αυτό το systemd πρόκειται να κλείσει επειδή το lennart πληρώνεται από τη microsoft, ότι τα δυαδικά αρχεία καταγραφής Είναι υποχρεωτικά. Κανείς δεν θέλει systemd και η υιοθέτησή του γίνεται από πολιτικό λόμπι.
Αυτό είναι σοκ, τα ψέματα. Αν ήταν μια λογική συζήτηση, θα άξιζε τον κόπο, αλλά είναι μόνο το καλό FUD.
Ότι δεν σας αρέσει φαίνεται τέλειο για μένα, δεν μου αρέσουν πολλά λογισμικά, ακόμη και γλώσσες προγραμματισμού, διανομές και άλλα, αλλά δεν εφευρίσκω πράγματα γι 'αυτό ούτε διαβάζω καθυστερημένα αυτό που θέλω να διαβάσω και φορτώνοντας τις δηλώσεις μου με προσωπικά συναισθήματα για να καταστρέψω την εικόνα ανθρώπων που το αναπτύσσουν.
@juanfgs συγγνώμη, αλλά δεν είμαι αυτός που αποκαλεί μια συγκεκριμένη ομάδα ανθρώπων "δηλητηριώδη και βιτριώδη" απλώς και μόνο επειδή δεν τους αρέσει ένα λογισμικό.
Και πάλι, στρίβοντας προτάσεις για να παραμείνει θύμα.
@juanfgs και πάλι σας λέω, ότι είπατε, ελέγξτε τα λόγια σας, δεν παρουσιάζω εσφαλμένα τα λόγια σας, μόλις έφτιαξα ένα αντίγραφο / επικόλληση των λέξεων σας στο σχόλιο 59.
Παραθέτω το κείμενο του σχολικού μου καπό, αυτό που πρέπει να διαβάσετε ξανά είναι εσείς επειδή δεν θέλετε να καταλάβετε ή δεν ξέρετε πώς να συζητήσετε. Παίρνετε τα πράγματα εκτός πλαισίου και τα ερμηνεύετε καθώς σας τραγουδούν. Επομένως, εάν θέλετε να επιλέξετε να ζήσετε σε έναν κόσμο όπου αισθάνεστε προσβλητικοί επειδή αμφισβητούνται τα επιχειρήματά σας, η Lennart, η Red Hat και η Microsoft σας διώκουν, είναι επειδή επιλέγετε να το πιστέψετε.
Σύντομα εδώ γιατί συνειδητοποιώ ότι δεν είστε λογικό άτομο επειδή δεν θέλετε να καταλάβετε, θέλετε να ερμηνεύσετε τα πράγματα όπως θεωρείτε κατάλληλα.
Αν θέλετε να προσβληθείτε, προσβληθείτε, αλλά είναι δικό σας πρόβλημα, όχι ο υπόλοιπος κόσμος.
@juanfgs Δεν με ενοχλεί τα σχόλιά σας, πραγματικά δεν βλέπω κανένα λόγο, υποστηρίζουμε, οι πολιτισμένοι άνθρωποι διαφωνούν χωρίς να χρειάζεται να ενοχλούνται γι 'αυτό (αυτό νομίζω).
Τώρα, αν θέλετε να επισημάνετε, να προκαταλάβετε (ή ό, τι θέλετε να το ονομάσετε) άτομα για τις ομιλίες ή τις ενέργειές τους (ίσως πρέπει να διαβάσετε το σχόλιό μου # 64 και να μετρήσετε το εύρος αυτού), αυτό είναι το πρόβλημά σας, περιορίστε τον εαυτό σας σε αυτά δράσεις απέναντι στον εαυτό σου και άφησε τους άλλους από αυτήν την τσάντα.
Χαιρετισμούς.
"Το μεγαλύτερο μέρος του anti-systemd", "σχεδόν όλα", "all", "μέρος του anti-systemd" ... παρεκκλίνουμε, Mariano, αποκλίνουμε. Στην παρούσα υπόθεση: Δεν βλέπω πουθενά ότι ο Yukiteru έκανε μια συγκλονιστική ομιλία βασισμένη σε κακίες (αναφερόμενος στην ανάλυσή του με αυτόν τον τρόπο έχει κάτι στριμμένο), αντιθέτως, έχει αναπτύξει σταθερά επιχειρήματα σχετικά με τα μειονεκτήματα του systemd βασισμένο σε κατάλληλες ερωτήσεις και υλικό που λαμβάνεται από λίστες αλληλογραφίας και ίχνη σφαλμάτων (καθώς και με ευγενικό και πολιτισμένο τρόπο). Πιθανότατα για αυτόν τον λόγο ενοχλεί μερικούς και τον επιτίθενται στο πρώτο σχόλιο, για να τον δυσφημήσουν και να τον αποκλείσουν (αυτή τη φορά, με δηλητηριώδη τρόπο).
Αν δείτε ότι ο λόγος των περισσότερων αντι-συστηματικών είναι δηλητηριώδης και βιτριώδης, αυτό που βλέπω στη συζήτηση κάποιου pro-systemd (δεν ξέρω αν είναι πλειοψηφία ή μειονότητα) είναι υστερία και δίωξη εκείνων που, ακριβώς, κάνουν ισχυρά επιχειρήματα εν μέσω όλων των θορύβων. Το λέμε αυτό στη γη μου παρενοχλώντας διαφωνία.
Το systemd τα πάει καλά; Υπέροχα, μου φαίνεται υπέροχο, αλλά αφήστε όσους δεν πιστεύουν το ίδιο να εκφράσουν τις επιφυλάξεις τους (το λειτουργικό σύστημα μπορεί να μην λειτουργεί με τον ίδιο τρόπο).
αφορά
Ω, παρεμπιπτόντως, γιατί υπάρχει κάποιο σφάλμα συστήματοςd μέχρι να σπαταλήσει ολόκληρο το στοιχείο, αλλά άλλα όπως το GCC, το glibc ή ακόμα και ο πυρήνας δεν έχουν επικριθεί σε αυτό το σημείο για πολλά από τα σφάλματα τους;
Το είπατε μόνοι σας, το glibc παραδίδει προβλήματα εδώ και πολύ καιρό. Η Llvm έχει αποδειχθεί με την πάροδο του χρόνου ότι έχει πλεονεκτήματα έναντι του GCC. Και εδώ δεν βλέπω την ίδια κριτική.
Γιατί να μην κάνετε το ίδιο με άλλα έργα;
Είναι απλώς συλλογικός και παράλογος φόβος για μένα.
Το Glibc έχει τα σφάλματα που κανείς δεν μπορεί να τα κρύψει, υπάρχουν τεράστια σφάλματα Glibc που επηρεάζουν τον πυρήνα και εκατοντάδες εκτελέσιμα. Η διαφορά μεταξύ Glibc και systemd είναι ότι το πρώτο είναι μια βάση από την οποία ΧΙΛΙΑ ΧΡΗΣΕΩΝ έργων λογισμικού μπορούν να μετατραπούν σε δυαδικά αρχεία, ενώ το systemd είναι ένα init, του οποίου σκοπός είναι να είναι ένα σταθερό, αποδεδειγμένο και πρακτικά αλάθητο κομμάτι. Όχι μόνο αυτό, το Glibc πρέπει να προσαρμόζεται σε εκατοντάδες διαφορετικές αρχιτεκτονικές υλικού (CPU), σε διαφορετικές σημαίες βελτιστοποίησης και μοναδικά χαρακτηριστικά της CPU, σε διαφορετικές μορφές βελτιστοποίησης λογισμικού, μια πολύ πιο επίπονη και δύσκολη δουλειά από αυτή του systemd. Δεν βλέπω πραγματικά κανένα τρόπο να παρουσιάσω μια σύγκριση μεταξύ των δύο έργων στην ίδια κλίμακα.
Το ίδιο ισχύει και για το GCC, το GCC είναι ένας μεταγλωττιστής που παρεμπιπτόντως υποστηρίζει πολλές γλώσσες (13 συνολικά μετρούν τις ανεπίσημες) και έχει χαρακτηριστικά παρόμοια με το Glibc, υποστηρίζοντας πολλές αρχιτεκτονικές (70 αρχιτεκτονικές για την έκδοση 4.9), σημαίες δυαδικής βελτιστοποίησης , Σημαίες βελτιστοποίησης CPU και πολλές άλλες δυνατότητες. Τώρα βρίσκονται στο ίδιο επίπεδο δυσκολίας, ένας μεταγλωττιστής με ένα init. Η απάντηση είναι κάτι παραπάνω από προφανές, ξεκινώντας με αυτό το systemd είναι στο C και πολλοί από τους κωδικούς GCC βρίσκονται στο assembler ή πρέπει να χρησιμοποιήσετε το assembler για να δουλέψετε σε δυαδικό, κάτι λίγο «δύσκολο να το κάνετε».
Τι συμβαίνει με το GCC και το Glibc; Σαφή. Ακόμη και ο Linus τους έδωσε την επίθεσή του, αλλά στο GCC και στο Glibc έχουν κάτι θετικό που στο σύστημα είναι συχνά ξεχασμένα, και δηλαδή, αναφέρθηκε ένα σφάλμα, ένα σφάλμα, ένα σφάλμα διορθώθηκε.
- παρακαλώ κάποιος να μου εξηγήσει: Γιατί ένας init πρέπει να έχει τον έλεγχο:
δίκτυα (systemd-networkd),
dns (σύστημα-δικτυωμένο),
m-dns (systemd-networkd), l
ogs (περιοδικό),
coredumps (systemd-coredump),
σφάλματα (systemd-coredump και journald),
acpi (logind), κλιμάκωση προνομίων (logind),
ntp(systemd-timesyncd),
dev (systemd πήρε όλες τις λειτουργίες από udev),
de / dev / random (γεννήτρια τυχαίων αριθμών)
TTY (σύστημα-παρηγορημένο);
Ένα θέμα 100000 επαναλαμβανόμενο και επαναλαμβανόμενο, αυτό που πρέπει να πείτε είναι ότι το systemd μπορεί να λειτουργήσει χωρίς αυτά, στην πραγματικότητα στο debian δεν υπάρχουν καν τα μισά από αυτά που αναφέρετε
είναι επίσης μόνο ένα χαρακτηριστικό της ευρείας προσέγγισής του
lennart: Λοιπόν το systemd αναλύει αυτό που έχει να κάνει σε πολλά διαφορετικά στοιχεία (90+ δυαδικά αρχεία αυτές τις μέρες). Κάθε ένα τρέχει με τα λιγότερα δυνατά προνόμια.
Φαντάζομαι ότι αυτό δεν είναι πάρα πολύ διαφορετικό coreutils, το οποίο έχει επίσης μεγάλο αριθμό συστατικών σε ένα πακέτο. Και το coreutils είναι πιθανώς ένα από τα σημαντικότερα έργα που κάνουν το Linux να αισθάνεται σαν ένα λειτουργικό σύστημα τύπου UNIX, σωστά;
Αλλά ναι, το systemd είναι πιο περίπλοκο από το sysvinit, χωρίς αμφιβολία. Τα τελευταία 40 χρόνια υπολογισμού έχουν αλλάξει πολλά και πολλά από αυτά απαιτούν ένα συγκεκριμένο επίπεδο πολυπλοκότητας για να αντιμετωπιστούν… Υπάρχει πολύ λίγος τρόπος για να το αντιμετωπίσετε.
Επειδή δεν έχετε αυτό το συμβιβασμό με το freebsd, το οποίο κάνει ακριβώς το ίδιο πράγμα, αλλά με τα εργαλεία του και χωρίς να επιτρέπεται η χρήση άλλων, κάτι που δεν συμβαίνει με το systemd.
- Δεν δημιουργήθηκαν πολλά εργαλεία για τέτοιους σκοπούς που το systemd προσθέτει τώρα τα δικά του, μερικά με αποκλειστική πρόσβαση (περίπτωση ημερολογίου);
Δεν θα αρνηθώ ότι το θέμα του περιοδικού αποθηκεύει τις πληροφορίες σε δυαδικό είναι το πιο αδύναμο πράγμα που πρέπει να υπερασπιστεί, αλλά δεν είναι το τέλος του κόσμου, μπορούν να αποθηκευτούν σε απλό κείμενο
- Ποια λογική και αποδεκτή εξήγηση μου δίνεις ότι ένα init είναι σε θέση να σπάσει το πρόγραμμα εντοπισμού σφαλμάτων πυρήνα και cmdline;
Mmmmmmmmmmm …………………. σπάστε τον πυρήνα ……. 5000000 πράγματα μπορούν να σπάσουν τον πυρήνα
- Προσθέστε σε αυτόν τον έλεγχο του kdbus, το επόμενο IPC που θα ενσωματωθεί στον πυρήνα.
Σύμφωνα με τον lennart Αυτό έχει μια θετική σχέση για προγραμματιστές και το systemd θα φέρει εργαλεία για το άνοιγμα του dbus σε διαχειριστές, θα δώσει επίσης διασυνδέσεις περιοδικού και δικτύου bus
- Σίγουρα θα μου πουν εδώ: "Αλλά μπορείτε να εγκαταστήσετε ένα άλλο εργαλείο για να ελέγξετε όλα αυτά." Και αν είναι αλήθεια, αλλά, πολλά από αυτά τα εργαλεία λαμβάνουν μόνο μια ροή δεδομένων που ρίχνεται από το systemd, όπως στην περίπτωση του syslog και του rsyslog,… .. αυτό σημαίνει μόνο ότι έχετε δύο εργαλεία που κάνουν το ίδιο και ένα από αυτά είναι ένα Το κουτί της Πανδώρας. (Παρακαλώ μην μου πείτε ότι ο κώδικας μπορεί να ελεγχθεί, επειδή καλώ κάποιον να "καπνίσει" τον κωδικό περιοδικού και το πλαίσιο του με το systemd και άλλα σχετικά εργαλεία)
εδώ μπαίνουμε στη θεωρία συνωμοσίας !!!!! είναι κοκαλιάρικο ελεύθερο λογισμικό τίποτα δεν είναι κρυμμένο
3.- Τι σύστημα δεν είναι φορητό; Είναι ένα άλλο ζήτημα. Στο BSD δεν λειτουργεί καλά, στο BSD δεν υπάρχουν Cgroups μεταξύ άλλων εργαλείων που πρέπει να εκτελέσει το systemd. Αλλά είναι για λόγους σχεδιασμού συστήματος, όχι επειδή δεν είναι φορητό. Έως ότου ο πυρήνας BSD δεν πληροί το ελάχιστο για να τον υποστηρίξει, το systemd δεν θα λειτουργήσει σε αυτήν την πλατφόρμα και αυτό δεν είναι λάθος κανενός, μόνο ότι το BSD δεν έχει κανένα ενδιαφέρον ούτε ούτε ο Lennart.
Λοιπόν αυτό δεν είναι απολύτως σωστό, οι προγραμματιστές bsd κάνουν κάτι παρόμοιο με το systemd το οποίο τονίζει ο ίδιος ο Lennart στον λογαριασμό του g +
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4.- Αυτό το systemd δεν είναι μονολιθικό επειδή χωρίζεται σε 69 δυαδικά αρχεία. Ναι, αυτό είναι συζητήσιμο. Το systemd έχει 69 δυαδικά αρχεία, τα οποία εκτελούν διαφορετικές εργασίες, αλλά αυτά τα δυαδικά αρχεία μεταβιβάζουν τις πληροφορίες εργασίας τους στο systemd, οπότε αν αποτύχει, οι πιθανότητες διακοπής του συστήματος αυξάνονται αρκετά δραματικά. Αυτό είναι καλά τεκμηριωμένο, οι αναφορές σφαλμάτων αφθονούν με προβλήματα όπως αυτά και ακόμη και απλούστερα προβλήματα, ανόητα απλά. Το systemd μπορεί να χωριστεί σε εκατοντάδες δυαδικά αρχεία, αλλά όσο ο πυρήνας σας είναι υπό έλεγχο, ο κίνδυνος διακοπής συνεχίζεται και αυξάνεται και αν δεν με πιστεύετε, διαβάστε τις αναφορές σφαλμάτων και διασκεδάστε.
Εάν χρησιμοποιείτε το sysvinit και το TTY dev acpi ntp σπάει και το σύστημα σας σπάει επίσης, μην τρομάξετε.
Το Monolithic είναι freebsd και δεν λέτε τίποτα
@rolo
Τώρα αναφέρετέ με ποιες είναι οι διανομές που πήραν το systemd και δημιούργησαν αυτά τα 90 δυαδικά σε ξεχωριστά πακέτα, θα ήταν 91 πακέτα με το systemd.
Και κατά την εγκατάσταση του συστήματοςd δεν μου ζητά κανένα από αυτά τα 90 πακέτα ως εξαρτήσεις.
Σοβαρά, και πάλι επιμένω ... παρακαλώ δώστε μου τις επιλογές του -configure-help που θέλω να φτιάξω 91 πακέτα με το χέρι με το make.
Δεν υπάρχει χειρότερο τυφλό από αυτόν που δεν θέλει να δει ... αγόρια αυτό είναι νερό και λάδι, φαίνεται ότι εξακολουθούν να υπάρχουν πεισματάρικοι άνθρωποι που δεν βλέπουν την πραγματικότητα αυτού που είναι μετά.
@rolo Θέλω να εγκαταστήσετε το systemd και να καταργήσετε το journald, το systemd-udev και το coredump και να χρησιμοποιήσετε απευθείας επιλογές όπως το eudev και το syslog, για να δείτε αν μπορείτε.
Αυτό το σχόλιο δεν μπορούσε να με κάνει να γελάσω πιο σοβαρά, πεθαίνω. 😀
Σοβαρά, πηγαίνουν πραγματικά στο πρόβλημα της ανάγνωσης λίγο, αντί να κολλάνε με τη δέσμη στο μάτι.
Εκτός αυτού, κανείς δεν ξεχνά ότι οι Kay Sievers όχι μόνο έσπασαν τον cmdline του πυρήνα, αλλά ήθελαν να το κλείσουν, μετά από όλα «το generic is generic».
Με άλλα λόγια, σύμφωνα με εσάς, το γεγονός ότι δύο διεργασίες μεταβιβάζουν πληροφορίες τις κάνει τόσο συζευγμένες που το γεγονός ότι η μία αποτυγχάνει κάνει την άλλη έχει μεγάλη πιθανότητα αποτυχίας ... από ποια θεωρία ανάπτυξης λογισμικού το καταλάβατε; Συμφωνώ με το @pamp ότι μιλάτε από παράλογο και προκατειλημμένο φόβο.
Και το άλλο μεγάλο ερώτημά σας, γιατί το systemd πρέπει να ελέγχει τόσα πολλά πράγματα; Απλή απάντηση: επειδή με το sysvinit και όλα τα άλλα πλεονεκτήματα init που εισήχθησαν πρόσφατα στον πυρήνα Linux σπαταλούνται, αρκεί κανείς να μην τα χρησιμοποιήσει στο χώρο του χρήστη, είναι «τσαντισμένα» (όπως λέμε στην Κούβα ... καλά, σπατάλη) χωρίς κανέναν Τα χρησιμοποιώ και δίνουν πολύ καλά πλεονεκτήματα στην αποτελεσματική χρήση πόρων υλικού (CPU, RAM, I / O, κ.λπ.) συμπεριλαμβανομένων των ομάδων. Αυτό που κάνει το systemd είναι, ακριβώς, να θέσει αυτές τις καλές λειτουργίες τον πυρήνα Linux στην υπηρεσία του χρήστη, αλλά για αυτό πρέπει να είναι αυτός που ξεκινά αυτούς τους δαίμονες.
Νομίζω ότι διαβάσατε και αναλύσατε λανθασμένα (η ανάλυση είναι σημαντική) ή απλά δεν δώσατε ούτε στον εαυτό σας την ευκαιρία να το κάνετε. Ότι δύο διεργασίες μεταβίβασης πληροφοριών δεν είναι λόγος για διακοπή ενός συστήματος, ωστόσο, όταν έχετε δυαδικά αρχεία με δυναμική ενέργεια, όπως έλεγχος δικτύου, αρχεία καταγραφής ή coredump, διαβιβάζοντας πληροφορίες απευθείας στο init, τα πράγματα μπορεί να πάνε στραβά και θα πάνε στραβά, επειδή εάν Μερικά από τα δυαδικά αρχεία σπάνε, οι πιθανότητες να σπάσουν τα υπόλοιπα είναι πολύ υψηλότερες, και αυτό είναι αρκετά ρεαλιστικό, και έχει συμβεί, το διάλειμμα cmdline του πυρήνα πρόσφατα, τα προβλήματα acpi που είχαν οι Nvidia devs χάρη στο systemd-212 , όλα αυτά είναι ένα δείγμα αυτού που λέω.
@ Ντάριεμ
Εάν δεν μπορείτε να μεταγλωττίσετε καθένα από αυτά τα δυαδικά αρχεία σε μεμονωμένα πακέτα, το εξαναγκάζετε επειδή θέλετε να είναι εγκατεστημένο, πρέπει να τα εγκαταστήσετε όλα, όταν τα εγκαθιστάτε όλα αποδεικνύεται ότι πατάτε σε άλλα πακέτα που δεν μπορούν να εγκατασταθούν επειδή καταλαμβάνουν τα μέρη του systemd αυτά τα μέρη.
Τι νόημα έχει να χωρίσει ένα μεγάλο εκτελέσιμο σε αρκετά μικρότερα εκτελέσιμα εάν στο τέλος δεν έχετε πακέτο για κάθε ένα που σας επιτρέπει να τα εγκαταστήσετε ξεχωριστά.
Επιστρέφω για να κάνω το γενικό αίτημα σε όλους τους προχωρημένους χρήστες του συστήματος, για να μου πει πώς να συντάξω αυτές τις 90 λειτουργικές μονάδες και να δημιουργήσω 90 πακέτα που αν θέλω να τα εγκαταστήσω και διαφορετικά χρησιμοποιώ τα προγράμματα που έχω χρησιμοποιήσει.
Πολύ κακό γάλα όλα αυτά ... φαίνεται ότι οι άνθρωποι του συστήματος πιστεύουν ότι όλοι οι χρήστες του gnu / linux είναι ανόητοι.
Για το ρεκόρ, χρησιμοποιώ δοκιμές gentoo και πριν από λίγους μήνες είχα αλλάξει στο systemd και δεν μπορούσα με το περιοδικό, που με έκανε να επιστρέψω στο openrc γρηγορότερα από ό, τι χρειάστηκε για μετάβαση στο systemd.
Για να συνεχίσω να βλέπω πώς συμβαίνουν τα πράγματα με το systemd έχω το archlinux σε ένα σημειωματάριο που θα κυκλοφορήσει σύντομα στο gentoo….
@ anonymous, θέλω απλώς να δω πώς θα εξελιχθεί το ζήτημα TTY στο Linux. Όταν βγει ο κωδικός CONFIG_VT, υπέρ του διαχωρισμού του VT σε δύο καλά διαφοροποιημένα μέρη (kernelspace και userspace) θα χρειαζόμαστε κάποιο εργαλείο για τον έλεγχο του VT από το spacepace και εκεί το σύστημαd-consoled μπορεί να παίξει ως μια ισχυρή εξάρτηση που τραβά τα υπόλοιπα οι διανομές στην ανάγκη να πρέπει να εγκαταστήσετε τα στοιχεία του συστήματος, απλώς για να καταστεί δυνατή η λειτουργία του συστήματος Αυτό που λέω δεν είναι υπερβολή, είναι μια πολύ, πολύ μεγάλη πιθανότητα, και πραγματικά ανησυχητικό. Υπάρχουν και άλλα έργα, όπως το KMSCon, αλλά αν οι περισσότεροι επιτραπέζιοι υπολογιστές και διανομές προτιμούν το systemd, πράγματα όπως το KMSCon μπορούν να πεθάνουν γρηγορότερα από ό, τι πιστεύουν πολλοί άνθρωποι.
@Yukiteru 3 Δεκεμβρίου 2014 8:49 μ.μ.
Δεν το φοβάμαι, ο κ. Linus δεν πρόκειται να καταργήσει τις προεπιλεγμένες επιλογές από τη μία έκδοση στην άλλη, θα θέσει το νέο σύστημα ως ΝΕΟ και θα σας επιτρέψει να επιλέξετε μεταξύ του συνηθισμένου και του νέου.
Όσον αφορά το τμήμα χώρου χρήστη, μπορείτε να δημιουργήσετε ένα πακέτο που το κάνει αυτό ανεξάρτητα, εάν το κάνει το σύστημα, γιατί δεν θα μπορούσαν άλλα 50 περισσότερα; Επιπλέον, οι διαφορετικοί τρόποι να το κάνουν θα κάνουν τα διαφορετικά τερματικά διαφορετικούς τρόπους με όλα τα USE για ενεργοποίηση και απενεργοποίηση όπως έχουμε συνηθίσει.
Το ίδιο ισχύει και για το kdbus, που ο Linus το παραδέχεται στο 3.19 όπως λέει, δεν σημαίνει ότι κάποιος θα πρέπει να το έχει ενεργό ναι ή ναι.
Είμαι πολύ χαρούμενος με το openbox + compton, οι επιτραπέζιοι υπολογιστές για μένα μπορεί να εξαφανιστούν που δεν θα με επηρεάσουν στο ελάχιστο.
@ ανώνυμο το ερώτημα είναι ότι η κατάργηση του CONFIG_VT είναι κάτι που στο τέλος θα είναι συνολικό (από αυτό που έχω διαβάσει), δηλαδή, στον πυρήνα θα παραμείνουν μόνο τα πρωτόγονα, ενώ τα υπόλοιπα εργαλεία θα βρίσκονται στο χώρο χρήστη, αυτό δεν είναι κακό, Αντίθετα, θα αφαιρέσει πολύ παλιό κώδικα από τον πυρήνα, θα διευκολύνει τη συντήρηση και πολύ πιο διαμορφώσιμο (πλήρης υποστήριξη KMS / DRM για κονσόλα). Σίγουρα στην αρχή, θα υπάρχουν και τα δύο συστήματα, αλλά μακροπρόθεσμα (15-20 εκδόσεις) μπορεί να βγει από τον πυρήνα, ή ακόμα πιο γρήγορα, πολλά εργαλεία δεν υποστηρίζουν πλέον τέτοιο κώδικα υπέρ ενός νεότερου και καλύτερα υποστηριζόμενου κώδικα.
Τώρα, λέτε ότι αν το κάνει το systemd, γιατί 50 περισσότερα δεν μπορούν να το κάνουν (φαντάζομαι 50 ακόμη εφαρμογές). Λοιπόν, αν δούμε τις ισχυρές εξαρτήσεις του KMSCon (το παλαιότερο έργο με αυτήν την έννοια) είναι libudev (κώδικας που θα ενταχθεί σύντομα στο systemd, δεν θα υποστηρίζεται και θα έρχεται σε διένεξη με το systemd εάν λειτουργεί μόνο του), libdrm, libxkbcommon, libtsm και το ίδιο το σύστημα για να χειριστεί πολλαπλά καθίσματα, οπότε όταν το βλέπετε αυτό, συνειδητοποιείτε πώς τα πράγματα διαμορφώνονται παίρνοντας από μόνα τους πολλά απαραίτητα εργαλεία για να λειτουργήσει ένα λειτουργικό σύστημα GNU / Linux χωρίς προβλήματα.
@Yukiteru 3 Δεκεμβρίου 2014 9:46 μ.μ.
Εδώ στο gentoo libudev υπάρχει ένα εικονικό σημείο που δείχνει το sys-fs / eudev, οπότε τα άτομα gentoo θα φροντίσουν να τροποποιήσουν το eudev για να συμμορφωθούν με το API που υπαγορεύει το νέο σύστημα πυρήνα.
Νομίζω λοιπόν ότι διανομές εκτός από το systemd (hello devuan) θα χρησιμοποιήσουν εάν ή εάν Eudev.
Αυτό που συνέβη με το αρχικό udev πρόκειται να συμβεί, το systemd το κατέστρεψε, αλλά εδώ ο πυρήνας είναι αυτός που υπαγορεύεται από το API για διασύνδεση με τις κονσόλες χρησιμοποιώντας DRM / KMS…. Ήθελα ήδη να δω ένα urxvt χρησιμοποιώντας αυτό… hehe
Αυτό που δέχομαι είναι ότι όποιος χρησιμοποιεί το σύστημαd δεν θα έχει την επιλογή να αλλάξει τίποτα ... πλήρης και σκληρή επιβολή και όπως είπα προηγουμένως ... να κλάψω στο νεκροταφείο.
@ ανώνυμο σίγουρα αυτό που λέτε είναι η άλλη πιθανότητα, το eudev θα πάρει μεγαλύτερη δύναμη σε αυτό το θέμα και θα διατηρήσει τις επιλογές ανοιχτές για να επιλέξει διαφορετικά εργαλεία.
PS: Όπως λέτε, θα ήταν ενδιαφέρον να δούμε πώς οι VT παίρνουν τα πλεονεκτήματα του KMS / DRM μαζί με το fbdev 😀
Επαναλάβατε ακριβώς την ιδέα που σας επέκρινα, γιατί σε καμία περίπτωση δεν μίλησα για το σύστημα, μίλησα για επικοινωνία μεταξύ διεργασιών και επαναλαμβάνω ξανά, από πού το καταλαβαίνετε επειδή επικοινωνούν δύο διαδικασίες, ο θάνατος της μιας υποδηλώνει ότι η άλλη έχει ευρείες δυνατότητες Πεθαίνω? Εξηγήστε μου πώς δύο διαδικασίες, που βρίσκονται σε ξεχωριστούς χώρους μνήμης, μπορούν να επηρεάσουν αμοιβαία την εσωτερική συμπεριφορά του άλλου. Ας δούμε αν εξηγώ τον εαυτό μου, από την άποψη μιας από αυτές τις διεργασίες, έχει πρόσβαση μόνο σε έναν μηχανισμό IPC (ό, τι είναι αυτός που ορίστηκε για να επικοινωνήσει με τις διαδικασίες του συστήματος). Εάν ο προγραμματιστής ήταν τόσο κακός στο να μην συμπεριλάβει κώδικα που μπορεί να ασχοληθεί με απροσδόκητη είσοδο και έξοδο, αυτό είναι κάτι άλλο, αλλά δεν έχει καμία σχέση με μια διαδικασία που επηρεάζει τα εσωτερικά της άλλης. Εάν το systemd-networkd διακοπεί, δεν χρειάζεται να σκοτώσετε το journald ή το systemd, όπως και με το παλιό sysvinit το γεγονός ότι το inetd crash δεν πρέπει να το επηρεάσει, είναι ξεχωριστές διαδικασίες.
Ο @dariem εξήγησε με έναν απλό τρόπο για να δείτε αν έχετε την ιδέα:
Αυτό που λέτε είναι σίγουρα η συμπεριφορά που αναμένεται πάντα από αρθρωτά προγράμματα και διαδικασίες. Το Modularity υλοποιήθηκε για το σκοπό αυτό, αυτό του διαχωρισμού δύο διεργασιών και ότι καταλαμβάνουν τους δικούς τους χώρους μνήμης και ότι επικοινωνούν με κάποια μέσα (IPC, κ.λπ.), έτσι ώστε σε περίπτωση που κάτι πάει στραβά, τότε δεν συμβαίνει τίποτα κακό. και το σύστημα μπορεί να συνεχίσει να λειτουργεί χωρίς διακοπή. Μια θεωρία που σίγουρα είχε μεγάλη υποστήριξη λόγω της δυνατότητάς της και του τεράστιου περιθωρίου αξιοπιστίας που έχει δώσει στην τρέχουσα πληροφορική. Τώρα, αυτό δεν είναι πάντα αληθινό (η ζωή δεν είναι πάντα όμορφη) και νομίζω ότι σίγουρα έχετε πέσει θύμα αυτών των γεγονότων σε μια περίπτωση ή την άλλη (αυτό σίγουρα ισχύει για όλους ανεξάρτητα από το λειτουργικό σύστημα που χρησιμοποιείτε) και θα το δώσω μερικά παραδείγματα.
Το πρώτο πηγαίνει με το Xorg (που είναι μια αρθρωτή διαδικασία όπως το systemd), το οποίο μερικές φορές τρελαίνεται με ένα πρόγραμμα οδήγησης και απλώς συντρίβει και σας αφήνει χωρίς γραφικά, ενώ το υπόλοιπο σύστημα συνεχίζει να λειτουργεί όπως αναμενόταν (Ευλογημένη λειτουργικότητα 😀). Μέχρι στιγμής, η θεωρία μας ότι οι αρθρωτές διαδικασίες δεν χρειάζεται να σπάσουν το σύστημα λειτουργεί καλά. Αλλά (υπάρχει πάντα κάποια αλλά) μερικές φορές το Xorg δίνει κάτι περισσότερο από τρέλα και για κάποιο παράξενο λόγο (που μπορεί να κυμαίνεται από έλεγχο ποντικιού έως πρόγραμμα οδήγησης γραφικών) όχι μόνο το Xorg συντρίβεται, αλλά σας δίνει επίσης τα πιο όμορφα του πανικού του πυρήνα (και ενός γκράφιτι στην οθόνη όπως το Picasso) που μπορείτε να φανταστείτε και, στη συνέχεια, να συνειδητοποιήσετε ότι δεν έχει σημασία πόσο αρθρωτό είναι, εάν μια διαδικασία επικοινωνεί και ανταλλάσσει πληροφορίες / δεδομένα με άλλο και κάτι πάει στραβά ένα από αυτά, και για κάποιο λόγο, το σφάλμα δεν μπορεί να αντιμετωπιστεί σωστά, αυξάνεται η πιθανότητα να επηρεαστούν οι εν λόγω διαδικασίες, για το απλό γεγονός ότι τα δεδομένα είναι λανθασμένα ή απλά κατεστραμμένα και στη συνέχεια έρχονται η καταστροφή
Αν νομίζετε ότι αυτό δεν μπορεί να συμβεί, σας αφήνω μερικές αναφορές σφαλμάτων (το ένα είναι δικό μου στο Debian και έχει μερικές φωτογραφίες) για ένα παλιό σφάλμα που βρίσκεται στο Xorg, mesa, nouveau και στον οδηγό drm / kms του πυρήνα, επεξεργάζεται ότι παρά τρέχει ** ξεχωριστά και είναι αρθρωτό **, μαζί δεν ταιριάζουν πολύ καλά, τουλάχιστον όχι υπό αυτές τις συνθήκες.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619
Τώρα το άλλο παράδειγμα που θα σας δώσω με το systemd. Το παλιό μας Sysvinit είχε μια ιδιαιτερότητα ότι, παρά το ότι ήταν παλιό, ήταν πολύ αξιόπιστο, στο σημείο ότι εάν το / etc / fstab είχε μια καταχώριση διαμέρισης (δεν είναι σημαντική για το σύστημα, κατανοήστε a / mnt / Disk160GB) και είναι Δεν μπορούσε να τοποθετηθεί για κάποιο λόγο, το προσάρτημα απλώς παραλείφθηκε, σας έδωσε ένα προειδοποιητικό μήνυμα και συνεχίστηκε με τη διαδικασία εκκίνησης. Τώρα, το systemd είναι μια άλλη ιστορία, παρά την αρθρωτότητά του, εάν έχετε μια καταχώριση στο / etc / fstab και το systemd για κάποιο λόγο βλέπει ότι είναι αδύνατο να το τοποθετήσετε, δεν περιμένει μόνο το διαμέρισμα να είναι διαθέσιμο (η κανονική προγραμματισμένη συμπεριφορά) για τη συναρμολόγηση του, αλλά αν τελειώσει ο χρόνος, το σύστημά σας σταματά και δεν μπορείτε να κάνετε τίποτα περισσότερο από την είσοδο στη λειτουργία ανάκτησης και να αφαιρέσετε αυτήν τη γραμμή από το / etc / fstab, κάτι αποτυγχάνει πραγματικά. Αυτή η μικρή λεπτομέρεια δεν ήταν πια κατά τη διάρκεια της αυτόματης εκκίνησης και η όλη διαδικασία σταματά, στην αρχή (systemd-) η μικρή λεπτομέρεια ήταν άσχημη, επειδή η χωματερή μόλις εμφανίστηκε και έπρεπε να κάνετε επανεκκίνηση. Σας λέει κάποιος που πέρασε τις λεπτομέρειες.
Ένα άλλο παράδειγμα που μπορώ να δώσω είναι το coredumpd στο systemd. Το coredumpd από προεπιλογή μεταβιβάζει όλες τις πληροφορίες του στο ημερολόγιο για να μπορέσει ο τελευταίος να γράψει τις καταγεγραμμένες πληροφορίες στο δίσκο, μέχρι στιγμής καλό, χρησιμοποιούμε το modularity του systemd προς όφελός μας. Αλλά συμβαίνει μερικές φορές, όταν τα coredumps είναι πολύ μεγάλα, τόσο μεγάλα, που μπορούν να καταλάβουν αρκετά GB, και στη διαδικασία μετάδοσης πληροφοριών από το coredump στο περιοδικό και στη συνέχεια στο δίσκο, συμβαίνουν περίεργα πράγματα όπως ο Xorg σταματά να λειτουργεί και πανικού πυρήνα. Αυτό δεν συμβαίνει μόνο με το σύστημαd φυσικά, αλλά ο τρόπος με τον οποίο σχεδιάζεται αυξάνει τον παράγοντα αστοχίας και δημιουργεί άλλες δυσάρεστες λεπτομέρειες (μεταξύ αυτών αυξημένη κατανάλωση μνήμης, καταστροφή καταγραφής, ελλιπείς χωματερές), οι οποίοι έπρεπε να εργαστούν Με ένα coredump KDE, σίγουρα έχετε περάσει από αρκετά επεισόδια όπως αυτά και θα έχετε καταλάβει τη σημασία της επιλογής συγχρονισμού στο / etc / fstab για το διαμέρισμα dump και σίγουρα θα μισείτε το γεγονός ότι δεν μπορείτε να χρησιμοποιήσετε κάποια άλλη επιλογή για να χειριστείτε τα χωματερές, εάν έχετε εγκαταστήσει το systemd. Ένα παράδειγμα του τι μπορεί να συμβεί με το systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Τώρα, για να ολοκληρώσετε:
Δεν υποτίθεται ότι είναι αρθρωτά προγράμματα και διαδικασίες; Ναι, είναι αρθρωτά. Ο πυρήνας είναι το μόνο μονολιθικό πράγμα για το οποίο έχω μιλήσει εδώ, αλλά δέχεται επίσης μονάδες (LKM), οπότε θα ήταν ένα είδος υβριδικού πυρήνα αν και η βασική του μορφή σχεδιασμού δεν έχει σχεδιαστεί σε αυτόν τον τύπο δομής, και αυτό το καθιστά λίγο ασταθές υπό ορισμένες συνθήκες.
Αυτή η αρθρωτότητα δεν πρέπει να μου επιτρέπει να κάνω τις διαδικασίες και το σύστημά μου να μην καταρρέουν εάν κάτι πάει στραβά; Είναι αλήθεια ότι η αρθρωτότητα είναι ένα μέτρο που έχει σχεδιαστεί για να επιτυγχάνει υψηλό βαθμό σταθερότητας και αξιοπιστίας, αλλά δεν είναι 100% αλάθητο μέτρο, επειδή εάν κάτι μπορεί να πάει στραβά, θα πάει απλά στραβά, ανεξάρτητα από το πόσο αρθρωτό, αυτό είναι πραγματικότητα.
Τι σύστημα πρέπει να έχει ο έλεγχος όλων για να καταστήσει δυνατή τη χρήση ομαδοποίησης και άλλων επιλογών στον πυρήνα; Εντελώς ψευδές. Αυτό δεν είναι καθόλου απαραίτητο, το systemd θα μπορούσε να μείνει με μια διεπαφή για τον έλεγχο της εκκίνησης και της εκχώρησης των ομάδων στις διαδικασίες και τους δαίμονες που θα βρίσκονται στο σύστημα, χωρίς να χρειάζεται να αναλάβει τον αριθμό των υπηρεσιών που έχει τώρα και το καλύτερο παράδειγμα αυτού είναι: ότι το OpenRC είναι επίσης ικανό να χρησιμοποιεί cgroups και δεν είναι για το λόγο αυτό τόσο επεμβατικό για την εκτέλεση αυτής της εργασίας.
Τι είμαι προκατειλημμένος και φοβισμένος όταν μιλάω για το systemd; Δεν έχω ιδέα από πού προέρχεται, γιατί καθώς βλέπετε την απάντησή μου, δεν φοβάμαι, μιλάω μόνο για πτυχές που δεν μου αρέσουν για το systemd και ήδη, χωρίς να βασίζομαι σε απόψεις τρίτων.
Τέλος, λέτε ότι: "Εάν ο προγραμματιστής ήταν τόσο κακός που δεν συμπεριλάμβανε κώδικα που μπορεί να ασχοληθεί με απροσδόκητη είσοδο και έξοδο, αυτό είναι κάτι άλλο ..."
Σίγουρα να πω ότι ο προγραμματιστής επειδή δεν συμπεριλαμβάνει έναν κωδικό που χειρίζεται ΟΛΟΥΣ τους πιθανούς τρόπους με τους οποίους το πρόγραμμά του μπορεί να σπάσει λόγω κάποιας λανθασμένης καταχώρησης δεδομένων, είναι ΚΑΤΩ, μου φαίνεται μια οργή. Ανεξάρτητα από το πόσο καλός είναι ο προγραμματιστής, ένα άτομο δεν μπορεί να σχεδιάσει ένα αλάνθαστο και ασφαλές πρόγραμμα αστοχίας, θα υπάρξει ΠΑΝΤΑ μια αποτυχία, με τον οποίο ο ένας ή ο άλλος τρόπος θα φανεί, και όταν το κάνει, θα είναι χάρη σε μια τυχαία αποτυχία κατά τη διάρκεια του χρησιμοποιήστε, από έναν χάκερ ή ένα πρόγραμμα κράκερ που εκμεταλλεύεται μια ευπάθεια, από έναν έλεγχο κώδικα και έναν έλεγχο ή με οποιοδήποτε άλλο μέσο στο οποίο μπορεί να βασιστεί ο προγραμματιστής. Καλύτερα να μετρήσετε τις λέξεις πριν πείτε κάτι τέτοιο.
Χαιρετισμούς.
Το παράδειγμα που δίνετε για το Xorg είναι το λιγότερο κατάλληλο γιατί όλοι όσοι έχουν περάσει από τη μετάβαση στο KMS / DRM γνωρίζουν ότι το πρόβλημα προκαλείται από σφάλματα στις μονάδες πυρήνα για τον έλεγχο του KMS που παρέχονται από τους προγραμματιστές των προγραμμάτων οδήγησης Xorg. Ένα σφάλμα σε μια μονάδα KMS είναι το ίδιο με τον πυρήνα του πυρήνα, δεν έχει καμία σχέση με την επικοινωνία μεταξύ των διεργασιών, επειδή σε αυτήν την περίπτωση είναι ο Xorg πραγματοποιώντας μια κλήση συστήματος (syscall) έτσι ώστε ο πυρήνας να αλλάξει τη λειτουργία οθόνης, δηλαδή, υπάρχει μόνο μία διαδικασία (Xorg) που καλεί τον πυρήνα, δεν έχει καμία σχέση με αυτό που έχουμε να κάνουμε εδώ.
Η τρέχουσα συμπεριφορά του systemd όταν δεν βρίσκει το σημείο προσάρτησης είναι άσχετη ανεξάρτητα από το γεγονός ότι είναι μια λειτουργικότητα που μπορεί να μην αρέσει σε κάποιον, η οποία επιλύεται ζητώντας να υποστηρίξει την άλλη συμπεριφορά, ότι αγνοεί την αποτυχημένη προσάρτηση. Το coredump που προέκυψε στο παρελθόν θα μπορούσε να οφείλεται σε ανόμοια αίτια που θα μπορούσαν να θεωρηθούν μόνο, αλλά το γεγονός ότι η εκτέλεση δεν συνέχισε μπορεί να οφείλεται σε μια επιθυμητή συμπεριφορά, καθώς λέτε ότι έπρεπε να γίνει επανεκκίνηση, όχι ότι υπήρχε πανικός πυρήνα ή αυτόματη επανεκκίνηση. Καθώς δεν έχω περάσει, δεν μπορώ να δώσω γνώμη.
Όσον αφορά το πρόβλημα που θέσατε με το systemd-coredumpd και τη σύνδεση με την αναφορά σφαλμάτων, όλα δείχνουν ότι αυτό το πρόβλημα στο Arch Linux οφείλεται στη συμπίεση που ενεργοποίησαν το systemd όταν το συνέταξαν για αυτήν τη διανομή. Φαίνεται περισσότερο σαν πρόβλημα με τον αλγόριθμο συμπίεσης παρά με το ίδιο το systemd. Το λειτουργικό σύστημα δεν καταρρέει, αλλά ο αλγόριθμος συμπίεσης που χρησιμοποιείται για την αποθήκευση των coredumps φαίνεται να αδειάζει το σύστημα και αυτό είναι σφάλμα των προγραμματιστών Arch Linux που συνέταξαν το σύστημαd. Ωστόσο, το systemd έχει ρυθμίσεις για τον περιορισμό της κατανάλωσης πόρων και την ενεργοποίηση / απενεργοποίηση της σύλληψης όλων των coredumps που αναφέρονται από τον πυρήνα. Ίσως οι συντηρητές Arch του συστήματοςd και όσοι χρησιμοποιούν το KDE να τους ρίξουν μια ματιά.
Λέτε ότι το OpenRC χρησιμοποιεί επίσης cgroups χωρίς να είναι επεμβατικό. Το πρόβλημα είναι αυτό: πώς αναγνωρίζει το OpenRC το όνομα των εκτελέσιμων δαιμόνων για να γνωρίζει ακριβώς ποια κατανομή πόρων είναι η πιο κατάλληλη; Δεν είμαι σίγουρος αν αυτός είναι ένας από τους λόγους για τους οποίους το systemd φροντίζει τόσα πολλά πράγματα, δίνοντας στους εκτελεστές ένα γνωστό όνομα, αλλά υποψιάζομαι ότι το πράγμα πηγαίνει έτσι. Επιπλέον, εξαλείφει το βάρος της ύπαρξης παύλας στη μέση για την εκτέλεση καθεμιάς από αυτές τις υπηρεσίες, επικαλούμενος άμεσα τα εκτελέσιμα.
Δεν θα αρνηθώ ότι το systemd μπορεί να έχει πολλά σφάλματα, αλλά από εκεί για να τα αποδώσω όλα στον τρόπο που συλλαμβάνεται, δεν νομίζω. Στην περίπτωση του sysvinit, ήταν εξαιρετικά σταθερό, ένα ώριμο λογισμικό, το systemd μόλις ξεκινά.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Πώς έσπασαν μπάλες με το σύστημαD, xD Εάν το μισείς τόσο πολύ, δημιουργήστε τη δική σας διανομή, που είναι το Ελεύθερο λογισμικό για το é_é
Δεν πρόκειται για μίσος, για υπεράσπιση της κοινότητάς σας.
Παρεμπιπτόντως, εάν υπάρχουν διανομές Ανεξάρτητο "υπόγειο":
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
Σέβη
γιατί συγκρίνετε τα πάντα με τη microsoft που συμπεριφέρεται σαν windows .. εάν τα πράγματα λειτουργούν καλά και είναι για την ανάπτυξη και την εξέλιξη του linux ποιο είναι το πρόβλημα ... κάθε έργο στην αρχή μπορεί να έχει σφάλματα αλλαγών εάν τα προγράμματα λογισμικού κ.λπ. ήταν τέλεια, Είμαστε άνθρωποι, αλλά γι 'αυτό έχουμε λάθη.
ότι εάν το systemd αποτύχει, το σύστημα θα καταρρεύσει .. και εάν ο πυρήνας, xorg, grub αποτύχει .. υπάρχουν άνθρωποι που, ενημερώνοντας τον πυρήνα στον υπολογιστή ή το φορητό υπολογιστή τους, χάνουν το σύστημα ... τότε επειδή η επιμονή στην τελειότητα κάτι ...
λες και οποιοδήποτε σύστημα που βγήκε δεν είχε σφάλματα σφάλματα ή κάτι στην αρχή του ή ακόμη και στην ωριμότητά του έχει αποτυχίες
Το Systemd επιβλήθηκε ως στάνταρ με βρώμικο παιχνίδι, είναι μια υποχρεωτική εξάρτηση για πολλά πακέτα, επειδή πολλά προγράμματα απορροφήθηκαν από το systemd είτε επειδή τα συντήρησαν είτε επειδή τα εξάλειψαν αργά καθώς δεν ήταν πλέον σχετικά, επειδή το systemd παρείχε ήδη κάτι παρόμοιο.
Αυτό περιορίζει την ελευθερία επιλογής, δηλαδή οι διανομές δεν μπορούν να επιλέξουν να μην χρησιμοποιούν το systemd, μπορούν να προσπαθήσουν να αντισταθούν όπως το gentoo, αλλά αυτό είναι περισσότερο μια προσωρινή λύση στο systemd, το openrc είναι απλώς ένας διαχειριστής υπηρεσιών που υποστηρίζεται από το sysv για init και in distro initscripts, το systemd παρέχει περισσότερες λειτουργίες από το openrc και έχει νέες λειτουργίες κάθε μέρα. Το νέο λογισμικό υποστηρίζει το systemd και απαιτεί να υλοποιηθεί κάτι παρόμοιο που καταλήγει να κάνει τα άλλα inits πιο περίπλοκα και πιο παρόμοια με το systemd που είναι αυτό που δεν θέλετε.
Το Systemd κάνει πολλά πράγματα σε σύγκριση με το παλιό init που απλά διαβάζει μερικές γραμμές από το / etc / inittab και στη συνέχεια φορτώνει κάθε ένα από τα initscripts και τις διαμορφώσεις τους σύμφωνα με το runlevel. Η παλιά προσέγγιση ήταν πολύ πιο απλή και πιο ανεξάρτητη. Βρισκόμαστε σε ένα στάδιο μετάβασης προς μια νέα εποχή ομοιογένειας, δεν υπάρχει λύση, ο τρόπος που επικρατεί είναι ασταμάτητος.
Σε λίγα χρόνια ουσιαστικά δεν θα υπάρξει διαφορά μεταξύ της χρήσης του debian, του arch ή του fedora, η ταυτότητα κάθε διανομής θα χαθεί αν συνεχίσουμε έτσι και το systemd θα γίνεται όλο και πιο ενοχλητικό κάθε μέρα που θα γίνει ακόμη και μέρος του ονόματος συστήματος (systemd / gnu / linux)
LOL
Να κλαίω στην εκκλησία>: Δ
Τι λέει ο Don KZKG, σας αφήνω αυτό: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
Το πρόβλημα είναι ότι είστε Αργεντινοί (έτσι είμαι εγώ), αλλά ο τρόπος να εκφραστούν ότι οι περισσότεροι από τους χρήστες της Αργεντινής Linux που διάβασα είναι πραγματικά ανησυχητικός, αν και λέγεται επίσης ότι ο κόσμος του ελεύθερου λογισμικού προσελκύει ορισμένους ανθρώπους. Αυτό που σώζω είναι ότι δεν υποτίθεται ότι είστε Αργεντινοί, αλλά δυστυχώς δείχνει πρωταθλήματα.
uyyuyy .. αυτό το αγόρι έπεσε με βαρύ πυροβολικό ..
ισχυρό σχόλιο !!
Juju .. ..pochoclos .. xD
Από αυτό το άρθρο προκύπτει ότι το μόνο που κάνουν είναι να "επιβάλουν" ένα σύστημα. Δεν μπαίνω για να εκτιμήσω αν είναι καλύτερο (το οποίο δεν είναι) ή χειρότερο. Αυτό που λέω, επαναλαμβάνω, τονίζω και τονίζω, είναι ότι δεν θέλω πραγματικά να μου επιβληθεί τίποτα.
Φράσεις όπως: "Απλώς δεν τις χρησιμοποιούμε για τη διαδικασία εκκίνησης, επειδή πιστεύουμε ότι δεν είναι το καλύτερο εργαλείο για αυτόν τον συγκεκριμένο σκοπό."
Και ποιος θα μου πείτε αν θέλω να χρησιμοποιήσω αυτό ή αυτό το εργαλείο;
Εκεί ο καθένας. Απλώς δεν το χρησιμοποιώ, περίοδο και, ενώ δεν μπορώ, δεν θα το χρησιμοποιήσω.
Υπογεγραμμένο. Οι Ταλιμπάν.
(Είναι ότι με διασκεδάζει ο κλόουν)
συχνά πονοκέφαλος με αυτό το θέμα !!!! Χ_Χ
Διαχειρίζομαι διακομιστές με το Centos 6 και το 7 με το systemd δεν μου κόστισε τίποτα, μην κλαις, η ζωή συνεχίζεται.
Με συγχωρείτε, αλλά διαβάζω πολλά πράγματα που μου θυμίζουν τον κλασικό λόγο "διακομιστής windows - Certified Man VS linux server - OpenSource Man".
1ο - Θα δείτε, εάν επιβάλλετε ένα σφάλμα, είναι φυσιολογικό να αποτύχει. Κάθε ένα από τα βίντεο που έχω δει είναι αναγκαστικά λάθη. Είναι σαν να κάνω ένα πρόγραμμα που τροφοδοτεί λέξεις-κλειδιά στο αρχείο καταγραφής syslog και ταυτόχρονα προσπαθώ να εκτελέσω ένα σενάριο που βασίζεται σε grep για να εξαγάγω πληροφορίες από το αρχείο καταγραφής ... φυσικά πρόκειται να αποτύχει, το έχω προκαλέσει.
Είναι σαν να ρίχνεις ζάχαρη σε έναν πετρελαιοκινητήρα και να λένε "Κοιτάξτε ... η βενζίνη είναι καλύτερη !!!" ή όπως κάνουν τα Windows, γράψτε ένα αρχείο διαμόρφωσης λανθασμένο και παραπονεθείτε ότι ο δαίμονας δεν αρχίζει να λέει "με τα παράθυρα αυτό δεν συμβαίνει."
2ο - Αυτό το systemd ενσωματώνει πολλά πράγματα που μπορεί να μην χρησιμοποιείτε; Λοιπόν, ποιο είναι το πρόβλημα; Είναι ότι είναι το ίδιο κενό επιχείρημα που χρησιμοποιούν τα Windows εναντίον Linux ... "Γιατί θέλω ένα απλό κείμενο να θέσει χίλιες και μία επιλογές όταν δεν πρόκειται να τις χρησιμοποιήσετε;"
Ακούω ακόμα τα παιδιά της IBM με τα μονολιθικά τους προγράμματα να γαβγίζουν για το mysql χρόνια πριν, όταν διάβασα κάποια πράγματα. Ευχαριστώ και επικροτώ την ποικιλομορφία του GNU / Linux και της κοινότητάς του. Εάν μου δώσετε 50 τρόπους να κάνω κάτι, θα επιλέξω κάθε στιγμή αυτόν που λειτουργεί καλύτερα για μένα ή ταιριάζει σε αυτό που χρειάζομαι. Βλέπετε πραγματικά ένα πρόβλημα σε αυτό;
3ο - Από το επίπεδο των συνομιλιών, συμπεραίνω ότι έχετε επαρκές επίπεδο για να εργαστείτε με οποιαδήποτε διανομή ή να δημιουργήσετε τη δική σας και να τη διατηρήσετε εσείς. Γιατί θέλετε να βάλετε το systemd και να αφαιρέσετε τα πράγματα από αυτό; Δεν είναι ευκολότερο να συνεχίσετε με το init ή το openRC σας;
Στους ανθρώπους που με έχουν ζητήσει να τους διδάξω τα βασικά του linux, πάντα λέω το ίδιο πράγμα ... Το GNU / LINUX δεν είναι ΠΑΡΑΘΥΡΑ, μην προσπαθήσετε να κάνετε τα ίδια πράγματα ή να σκεφτείτε σαν να ήταν. Γιατί εξομοιώνετε ότι το σύστημαd είναι το ίδιο με το initd ή ότι λειτουργεί το ίδιο; Δεν είναι ευκολότερο να αφομοιώσετε τη λειτουργία του συστήματοςd και να χρησιμοποιήσετε τις δυνατότητές του, παρά να προσπαθήσετε να κάνετε λειτουργίες όπως το init ή το OpenRC; Είναι φυσιολογικό ότι δεν σας αρέσει.
4ο - Τι συμβαίνει με την πολυπλοκότητα; Σίγουρα θυμάσαι ακόμα όταν έδωσες γραμμικό προγραμματισμό και αυτό σίγουρα σε κάποιο σημείο είπες ... «Και γιατί θέλω να μάθω να δουλεύω σε αντικείμενα αν τώρα μπορώ να κάνω τα πάντα και αλλιώς με αφήνουν να χρησιμοποιώ;» … (Το facepalm μερικούς μήνες αργότερα είναι υπέροχο αν xD)
Ας είμαστε ξεκάθαροι. Το τρέχον init (και συμπεριλαμβάνω το systemd) έχει πολλές αδυναμίες που μπορούν να καλυφθούν μόνο με την προσθήκη πολυπλοκότητας. Δεν υπάρχει άλλο, αφού για να αναπτυχθεί ένα διασυνδεδεμένο σύστημα, πρέπει να αναπτυχθεί σε πολυπλοκότητα με τον κίνδυνο να έχει ένα αδύναμο μέρος, αλλά είναι καλύτερο από το να παραμείνει στάσιμο.
Χρειάζεται πολύς δρόμος και αν… το σύστημαd δεν είναι η λύση σε όλα. Αλλά ούτε μένει με το SysVinit.
PS: Παρατηρήστε την ειρωνεία ότι έχω χρησιμοποιήσει τον υπολογιστή του συναδέλφου μου "Κολλάω στον windows-server defender", ώστε να μπορεί να το διαβάσει παρεμπιπτόντως. XD
Ένα πράγμα, στους υπερασπιστές άλλων INIT που δίνουν τεχνικά δεδομένα και συνδέσμους… CHAPO !!! Μου αρέσει να βλέπω επιχειρήματα και δεδομένα σαν αυτό. Σημειώστε ότι τα δεδομένα πριν από τον Οκτώβριο του 2014 είναι απλώς ιστορικά.
Πολλά πράγματα που συζητήθηκαν έχουν ήδη διορθωθεί και πολλά testbeds που δημοσιεύθηκαν το 2013 έχουν ήδη ελεγχθεί.
@rolo
Εάν είναι αλήθεια, αν είδατε το βίντεο, το οποίο ΔΕΝ κάνατε, βλέπετε ότι το αρχείο καταγραφής είναι 8MB, τίποτα περισσότερο και ούτω καθεξής και όλα καταστρέφονται, παρεμπιπτόντως, μπορείτε να στείλετε την έξοδο του ημερολογίου στο syslog σε απλό κείμενο; Ναι, αλλά ακόμα κι αν αγγίξετε τα αρχεία καταγραφής που δημιουργήθηκαν από το journald, αυτό συμβαίνει, το σύστημα κρέμεται και, κατανοητά, ας δούμε, το ημερολόγιο κρέμεται στο PID1 μαζί με πράγματα τόσο περίπλοκα όσο το systemd, αποτυγχάνει, φαίνεται ότι δεν έχει κανένα μέρος του κώδικας που δεν επιτρέπει την επεξεργασία για κάτι διαφορετικό από το ίδιο ημερολόγιο PID, καθώς και δεν έχει τη δυνατότητα να συνεχίσει να γράφει πέρα από το αρχείο καταγραφής είναι κατεστραμμένο, πράγμα που δείχνει ότι εκτός από τη σκέψη σε λειτουργία παραθύρων, το LP είναι ένας κακός προγραμματιστής .
Μην μου πείτε ότι θα είναι μόνο σε centos, η πιο σταθερή έκδοση του distro που χρησιμοποιεί το systemd, ο κλώνος του RHEL7 και δεν αναφέρω ούτε σκοπεύω να αναφέρω το σφάλμα.
Η αλήθεια είναι ότι όσο περισσότερο διαβάζω τα σχόλια του pro systemd, συνειδητοποιώ ότι είναι πραγματικά σαν θρησκεία, ή είστε υπέρ ή είστε εχθρός, αλλά, από αυτές τις θρησκείες τύπου ISIS, αυτές του ισλαμικού κράτους, εντελώς εξτρεμιστικές, στην πραγματικότητα , Ξέρω από την εμπειρία, τους λάτρεις του συστήματος, το πιστεύουν, ή είστε μαζί τους ή είστε ο εχθρός. Αυτό προωθεί ο Lennart με την αλαζονεία του και παρακαλώ, μην με γαμήσεις με τον Linus να τον υποστηρίζει, το systemd δεν ήταν αυτό, ΔΕΝ ήταν, χρησιμοποίησα το systemd μόλις βγήκε στο Fedora 15 και ήταν απλά μια ταχύτερη init, δεν αντικατέστησε το Αρθρωτότητα GNU / Linux.
Εάν σκοτώσω το rsyslog, καταστρέψω τα αρχεία καταγραφής του ή το αντικαταστήσω με ένα σχέδιο, τίποτα άλλο, μόνο που τελειώνω το αρχείο καταγραφής, τίποτα δεν κρέμεται, το σύστημα δεν επηρεάζεται.
@Rafael Mardojai
Αυτό κάνει ο Devuan, αυτό έκανε το Void Linux και άλλοι που μένουν μακριά από το systemd.
@Yukiteru
Σίγουρα κανείς δεν σας διαβάζει, καθώς μου λένε Ταλιμπάν, δεν σας διαβάζουν επειδή χρησιμοποιείτε παράθυρα ή έχετε σχολιάσει από αυτό και επειδή πιστεύω ότι λίγοι από τους λάτρεις του συστήματος καταλαβαίνουν το τεχνικό μέρος αυτού που λέτε και εκεί έγκειται το πρόβλημα.
======
Η αλήθεια είναι ότι εξακολουθώ να πιστεύω ότι ένα άτομο που ήταν γνωστό το 2006 είχε δίκιο για κάτι:
"Δεν θέλω οι άνθρωποι να χρησιμοποιούν το Linux ή να το γνωρίζουν, αυτά τα παιδιά του Ubuntu έχουν τις μπάλες μου γεμάτες"
I- "Γιατί;"
"Όταν κάτι γίνεται γνωστό και στις μάζες, σπάει, ξεσπάει και υπάρχουν πολλά δείγματα από αυτό"
Εγώ "μου αρέσει ποια;"
"Κοίτα τι συνέβη στον Ντέμπιαν, τώρα έχει έναν ανόητο γιο που ονομάζεται Ubuntu και θυμάται ότι σε λίγα χρόνια θα έχουμε" hackers "και" geeks "που πιπιλίζουν το Ubuntu και δεν θα ξέρουν πώς να ξεχωρίζουν το Ext3 από το NTFS"
Κάτι ήταν σωστό…. Το systemd θριαμβεύει μεταξύ εκείνων που γνωρίζουν, όπως λέει ο Allan McRae, επειδή δεν ενδιαφέρεται για το πώς ξεκινάει το μηχάνημά του, γι 'αυτόν είναι, το κουμπί, η μαγεία και έχω μια προτροπή. Μεταξύ εκείνων που δεν ενδιαφέρονται περισσότερο από το να "δουλεύουν" με ωραίες λειτουργίες, συνολικά, για χρήση από διακομιστή LFS ή Gentoo ή BSD πραγματικά και μετά εκείνων που το λατρεύουν επειδή ενεργοποιεί τον υπολογιστή τους πιο γρήγορα με χρωματιστά φώτα, όμορφους ήχους και τυχερά παιχνίδια, αλλά δεν ξέρουν τι είναι το syscall.
Το @SynFlag αν δεν το διαβάσει είναι με απόφαση του εαυτού τους, καθώς για το λειτουργικό σύστημα που χρησιμοποιώ, αν βρίσκομαι στη δουλειά μου και σχολιάζω από υπολογιστή με Windows, είναι επειδή είναι το μόνο πράγμα που έχω στη διάθεσή μου, εκτός από τον διακομιστή που βρίσκεται στο Debian Wheezy και προφανώς από το διακομιστή δεν μπορώ να σχολιάσω εδώ.
Ακόμα και στο σπίτι αναγκάστηκα να χρησιμοποιήσω τον υπολογιστή της αδερφής μου επειδή ο υπολογιστής μου πέθανε (το MB και η πηγή τροφοδοσίας συνωμότησαν εναντίον μου) και ακόμη και όταν έχω χρόνο, τοποθετώ ένα LiveCD και χρησιμοποιώ το Sabayon (με το OpenRC ) να σχολιάσω εδώ, καθώς κάνω ακριβώς όπως γράφω αυτές τις λέξεις.
Τώρα, αν μου λένε ή νομίζουν ότι είμαι αντι-συστηματικός Ταλιμπάν, δεν με νοιάζει. Όπως είπα, έχω χρησιμοποιήσει το systemd και ξέρω ότι κουβαλάει, όχι μόνο αυτό, συνήθως διαβάζω τη λίστα systemd πολλά για να μάθω για πράγματα που έρχονται σε νέες εκδόσεις και επίσης για να γνωρίζω τις αλλαγές που γίνονται και τις συζητήσεις που πραγματοποιούνται εκεί. Τώρα αν κάποιος λάτρης του συστήματος καταλαβαίνει την τεχνική πτυχή αυτού που μιλάω και έβαλα τους συνδέσμους μου (οι σύνδεσμοι προς το σύστημαd git repo κυρίως) και ακόμη και τότε δεν μπορώ να δω την πραγματικότητα, αυτό μου επιτρέπει μόνο να σκεφτώ ότι το πουλάω τα μάτια και ο εξτρεμισμός με τον τρόπο που βλέπουν / σκέφτονται / αισθάνονται / αγαπούν / δοξάζουν / λατρεύουν / λατρεύουν το σύστημα και είναι τόσο σπουδαίο που δεν έχει σημασία αν ακόμη και ο ίδιος ο Λινός βγάζει το **** από το σύστημα, θα εξακολουθούν να είναι εδραιωμένοι τις ιδέες τους ότι είναι σωστές.
Γειά σου! Δεν είμαι πολύ ειδικός και θα ήθελα να μάθω τι είναι αυτό το "systemd" και γιατί μιλάμε τόσο πολύ, ποιο είναι το πρόβλημα και ποια εναλλακτική λύση υπάρχει; ευχαριστώ
Το σχόλιο SynFlag! Είμαι από τους "geeks", "geeks" και "pro linuxeros" στο ίδιο.
Και αυτό είναι το μέλλον που μας περιμένει. Ubuntu ακόμη και στη σούπα. Φορητοί υπολογιστές Linux για απλή πρόσβαση στο Steam και για να παίξετε το πιο πρόσφατο παιχνίδι. Και λεγεώνες μικρών geeks που δεν ξέρουν τι είναι το pod.
Postscript: Η έννοια του φόντου του systemd είναι χάλια.
τα κουμπιά adk και φόρουμ δεν είναι ορατά στην κύρια σελίδα
Έτσι, σύμφωνα με το @SynFlag τώρα ο καθένας που δεν είναι anti-systemd είναι ένας εξτρεμιστικός θρησκευτικός φανατικός n00b και η πληγή που καταστρέφει το GNU / Linux. Με μια τόσο στενή άποψη, δεν ξέρω αν αξίζει να συζητήσουμε για αυτό το θέμα. Καλύτερα να αφήσουμε το νερό να τρέξει και μακροπρόθεσμα αυτό που πρέπει να συμβεί θα συμβεί.
Είναι αλήθεια, έρχεται ένα σημείο που δεν μπορεί να συζητηθεί πια. Μόνο ο χρόνος θα μας πει εάν το sytemd θα είναι κάτι θετικό για τον κόσμο του ελεύθερου λογισμικού ή όχι.
Μου δίνει επίσης την ιδέα ότι εάν αυτή η διανομή που βασίζεται στο debian που δεν πρόκειται να χρησιμοποιήσει το systemd αποφέρει καρπούς, θα βοηθήσει στην ανακούφιση των πνευμάτων εκείνων που δεν θέλουν να μάθουν τίποτα για το systemd.
όπως όταν εμφανίστηκε το gnome 3 και δημιουργήθηκε μια τεράστια αντίσταση, έως ότου εμφανίστηκε η κανέλα και η ενότητα "πιρούνι" επιτρέποντας τη συνέχιση της χρήσης εφαρμογών gnome σε έναν επιτραπέζιο υπολογιστή με περισσότερες διαμορφώσεις και ένα σχέδιο με περισσότερη σκέψη για τον υπολογιστή και όχι τόσο για την αφή
Ίσως αυτό, ο Ρόλο (εμφάνιση του Ντουβάν), να είναι ένα σημείο συναίνεσης. Νομίζω ότι όλοι το χρειαζόμαστε για να περιλάβουμε ένα πολωτικό και συνομιλητικό περιβάλλον. Το Devuan θα είναι ένας χώρος για τη δημιουργία και τη συνέχεια ενός τρόπου δράσης και που θα βοηθήσει να ηρεμήσουν τα πνεύματα. Η διαδικασία που έχουμε ζήσει στο Debian ήταν επώδυνη, ωστόσο πρέπει να αντιμετωπίσουμε την κατάσταση, δεν υπάρχει άλλη επιλογή από το να αποδεχτούμε το χωρισμό. Αυτό καταλήγει να μοιάζει με διαζύγια. Αυτό το πιρούνι μπορεί να είναι ένα αντίγραφο μιας συνθήκης ειρήνης και ενός μέρους αυτής. Υπήρχαν, φυσικά, εναλλακτικές λύσεις, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, τώρα Manjaro (για να αναφέρουμε μερικά) ... αλλά η σκηνή "deb" απαιτούσε μια εναλλακτική χωρίς systemd. Φαίνεται σαφές ότι κανείς δεν πρόκειται να πείσει κανέναν, τα επιχειρήματα είναι στο τραπέζι και δεν υπάρχει συναίνεση (παρά το γεγονός ότι το systemd έχει καλές ιδέες και οι κίνδυνοι που συνεπάγεται αυτό το λογισμικό είναι προφανείς). Είναι καιρός να διασκεδάσετε και να αποκτήσετε ελευθερία για τον χρήστη (επειδή πρόκειται για Ελεύθερο Λογισμικό, σωστά;).
Ένας παράγοντας που επηρεάζει τη διαδικασία ήταν η αίσθηση «απογοήτευσης» εκ μέρους ορισμένων από εμάς που εμπιστευόμαστε το Debian. Γι 'αυτό το Devuan παρουσιάζεται ως πιρούνι και όχι παράγωγο. Υπάρχει ένταση επειδή δεν αρέσει σε αυτό που συνέβη κανείς. ούτε το pro-systemd (εξ ου και ορισμένες έξαλλες επιθέσεις που προσπαθούν να δυσφημίσουν) ούτε το anti-systemd (που επέλεξαν το πιρούνι). Στο περιβάλλον είναι το "πόσο ταλέντο μπορούμε να χάσουμε;", τόσο από τη μία όσο και από την άλλη.
Όλοι οι χρήστες του Debian βλέπουν τη διανομή με έναν συγκεκριμένο τρόπο (αυτό μπορεί να εφαρμοστεί και σε άλλες διανομές). Υπάρχουν εκείνοι που θαυμάζουν την τεχνική του ποιότητα, άλλοι το κοινωνικό της συμβόλαιο, η επιρροή του στον κόσμο του Linux, ο σεβασμός που έχει συγκεντρώσει όλα αυτά τα χρόνια, η σταθερότητά του σε κρίσιμα περιβάλλοντα παραγωγής ... Σε ορισμένους χρήστες αυτή η αντίληψη έχει αλλάξει, με απογοήτευση. Απογοήτευση, απογοήτευση, καλέστε το ό, τι θέλετε. Από εκεί μέχρι το διαχωρισμό υπάρχει μόνο ένα μικρό βήμα.
Το διαζύγιο Debian είναι παρόμοιο με αυτό που συνέβη με το NetBSD και το OpenBSD. Αν και ο χρόνος θα πει. Βλέπω πολλές προσδοκίες στο πιρούνι και αυτό με κάνει να πιστεύω ότι δεν θα είναι μια φευγαλέα και στείρα διανομή. Μόλις σήμερα υπήρχε ένα μέλος της ομάδας gnome που σχολίασε τη λίστα αλληλογραφίας του Devuan (παρόλο που το έκανε τόσο αδέξια), αυτό, κατά τη γνώμη μου, υποδηλώνει ότι ο Devuan δημιουργεί ενδιαφέρον και θέλει, κατά κάποιον τρόπο, τον διάλογο .
Τέλος πάντων, καλό Σαββατοκύριακο.
@rolo
Για να πω ότι το βίντεο μπορεί να παραπλανηθεί ή ότι το λογισμικό είναι απόλυτη πλάνη και προσβολή, στη ζωή μου PU ** εξαπάτησα κάτι για να δημιουργήσω έναν μύθο, ποτέ, υπερηφανεύομαι ότι έχω δει αυτή την αποτυχία με τα μέσα μου, όχι από τα κόλπα μου. Όλοι πηγαίνουν στο **** παρά στο ***** και δεν πρόκειται να βάλω περισσότερα στις συνομιλίες του συστήματος, διότι είναι εντελώς στο κάλαμο, κανείς δεν θέλει να καταλάβει τίποτα και είναι όλα σαν ένα υποβιβασμό, το οποίο, μισώ, γιατί τα πάντα είναι από δόγμα της πίστης. Να είστε ευχαριστημένοι με το systemd.
Η βία του @SynFlag βρίσκεται ψέματα
Αυτό που δείχνει αυτό το βίντεο είναι το ψέμα του ισχυρισμού ότι εάν μία από τις λειτουργικές μονάδες systemd έχει καταστραφεί, προκαλεί σφάλμα του systemd, καθώς προφανώς, από αυτό που δείχνει το βίντεό σας που δεν συνέβη, xddddd και παρεμπιπτόντως Το περιοδικό λειτουργεί ως root, επομένως, εάν ένα τρίτο μέρος εισέλθει και καταργήσει κακόβουλα το δυαδικό ημερολόγιο ημερολογίου, δεν θα ανησυχώ για το systemd αλλά για την ασφάλεια του υπολογιστή σας. xdddddd. Τέλος, για το θέμα του βίντεο, επαναλάβετε αυτό που φαίνεται να επεξεργάζεστε με nano το αρχείο /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal και όταν κάνετε επανεκκίνηση διαπιστώνετε ότι υπάρχει ένα νέο system.journal και ένα σύστημα @@ 24f02f5b2b16758 @@ 820f6bb751 περιοδικό που είναι το κατεστραμμένο δυαδικό.
Δηλαδή, το περιοδικό συνειδητοποιεί ότι το αρχείο είναι κατεστραμμένο, οπότε δεν το μετονομάζει και δημιουργεί ξανά ένα νέο, δεν βλέπω ποιο είναι το πρόβλημα σε αυτό ;, Το ίδιο σαν να διαγράφεται το αρχείο system.journal, το περιοδικό το επιστρέφει στο δημιουργώ.
Αναρωτιέμαι τι θα συνέβαινε αν κατέστρεψα ένα αρχείο καταγραφής απλού κειμένου με έναν δεκαεξαδικό επεξεργαστή, σίγουρα έως ότου συνειδητοποιήσει ότι το αρχείο ήταν κατεστραμμένο όλα τα δεδομένα θα καταστραφούν Oo
Ας μιλήσουμε λίγο για το περιοδικό, το οποίο είναι μια από τις πιο κοινές κριτικές του systemd.
Το περιοδικό είναι ένα πολύ σημαντικό συστατικό του systemd, το οποίο συλλαμβάνει μηνύματα Syslog, μηνύματα καταγραφής πυρήνα, μνήμη RAM και αρχικά μηνύματα εκκίνησης, καθώς και μηνύματα γραμμένα στο STDOUT / TDERR και καθιστά όλες αυτές τις πληροφορίες διαθέσιμες στον χρήστη.
Αλλά το πιο σημαντικό, το περιοδικό μπορεί να χρησιμοποιηθεί παράλληλα ή σε αντικατάσταση ενός παραδοσιακού δαίμονα syslog, όπως το rsyslog ή το syslog-ng, επομένως ένα προσεκτικό sysadmin μπορεί να έχει rsyslog ή syslog-ng ως δεύτερο εργαλείο αναζήτησης, εκτός από τη μετατροπή εγγραφών ημερολογίου σε απλό κείμενο σε περίπτωση που το δυαδικό λογισμικό καταστραφεί
Ένα άλλο σημαντικό γεγονός σχετικά με το ημερολόγιο είναι ότι εάν δεν δημιουργηθεί ο φάκελος / var / log / journal, οι πληροφορίες αποθηκεύονται μόνο προσωρινά, η οποία χάνεται με κάθε επανεκκίνηση.
για παράδειγμα, όταν μπήκα στο systemd in debian, η επιμονή του αρχείου καταγραφής δεν ήταν ενεργή, οπότε έπρεπε να δημιουργήσω χειροκίνητα το φάκελο ημερολογίου
http://0pointer.net/blog/projects/journalctl.html
Όσοι γνωρίζουν αγγλικά, δεν μπορούν να χάσουν τις συνομιλίες που πραγματοποιούνται μεταξύ των προγραμματιστών του devuan, του jaromil dimkr max2344 μεταξύ άλλων στο κανάλι Freenode IRC #devuan.
Διασκεδάζοντας διαβάζοντας τις έρευνες του κώδικα του συστήματος, καθώς τον έχουν διαδοθεί σκόπιμα για να μολύνουν (δημιουργούν περιττές εξαρτήσεις).
Το Systemd με ενοχλεί ... ευθεία ... είναι δύσκολο. Λίγη τεκμηρίωση ή το γαμημένο λεπτό τρέχει μόνο KDM ή gdm και σε ένα ελαφρύ σύστημα θέλω το slim lxdm να μην το υποστηρίζει ή να το μεταγλωττίζει… .. Σοβαρά ότι ακόμη και πριν… ήμουν ευχαριστημένος με αυτούς που έπρεπε. Η αλήθεια είναι ότι άρχισα να χρησιμοποιώ το openrc όπως λένε στο gentoo και βοήθησε…. Πολύ
@rolo
Είστε ασεβής και δυσμορφία στις ειδήσεις για να το πείτε αυτό. Είναι η χειρότερη προσβολή που μου λέτε ότι ψεύδω ή παραποιώ δεδομένα, με αηδίζει πραγματικά πώς για να υπερασπιστώ κάτι που επιτίθεται σε ανθρώπους που κάνουν σοβαρό PoC σαν κι εμένα. Το αρχείο καταγραφής είναι κατεστραμμένο, το σύστημα διακόπτεται, η επανεκκίνηση της υπηρεσίας δεν λειτουργεί, επομένως δεν υπάρχει άλλη επιλογή από το να επανεκκινήσετε το μηχάνημα, το οποίο δεν είναι το καλύτερο σε έναν διακομιστή που έχει παραβιαστεί, θα μου πείτε ότι εάν η ασφάλεια διακυβεύτηκε, το καλύτερο είναι να κάνετε επανεκκίνηση ή επανεγκατάσταση και είναι το μόνο πράγμα για το οποίο πρέπει να ανησυχώ καθώς το σύστημα λέει ότι δικαιολογεί τον εαυτό του και δεν κάνει μια καυτή ανάλυση του ΤΙ ΣΥΜΒΑΙΝΕΙ; να φτάσετε σε αυτό το σημείο; Προφανώς είστε ένα ακόμη προϊόν του νέου sysadmin εάν φτάσετε σε αυτό που δημιουργήθηκε χρησιμοποιώντας το Ubuntu και έχει την ασφάλεια ενός DOS 5.0 στον υπολογιστή σας, οπότε αυτό που λέτε το παίρνω ως από ποιον προέρχεται, με εκνευρίζει που αμφιβάλλετε επίσης Αυτός που παραποιεί είναι εσείς, απαντήσατε στο ίδιο λειτουργικό σύστημα με τις ενημερώσεις αυτής της ημέρας; Σίγουρα όχι, οπότε δοκιμάστε έναν άλλο ψεύτη. Τι έλλειψη χωρητικότητας έχετε, πηγαίνετε στη δουλειά ως οδηγός ταξί για περισσότερο από αυτό που αμφιβάλλω ότι θα σας δώσει, σταματήστε να παίζετε με linux και συνεχίστε να ψάχνετε
Ας δούμε περιστέρι (synflag), ο μπαμπάς θα σας δείξει πώς να κάνετε το περιοδικό να συνεχίσει να λειτουργεί αφού το αρχείο καταγραφής δυαδικού ημερολογίου μας είναι κατεστραμμένο για κάποιο λόγο, χωρίς να χρειάζεται να επανεκκινήσετε τον υπολογιστή.
Σε αυτό το παράδειγμα ξεκινάμε από μια βασική εγκατάσταση του debian 8 jessie.
Από προεπιλογή, το systemd-journal.service συνοδεύεται από τη συνάρτηση "storage = auto", επομένως για να υπάρχει συνεχής εγγραφή των αρχείων καταγραφής, είναι απαραίτητο να δημιουργηθεί το αρχείο στο / var / log / journal / sebelumnya.
# mkdir -p / var / log / περιοδικό /
Για να αρχίσει το ημερολόγιο να γράφει τα αρχεία καταγραφής, δεν χρειάζεται να κάνετε επανεκκίνηση του υπολογιστή, απλώς κάντε:
# systemctl επαναφόρτωση systemd-journal.service
o
# systemctl αναγκαστική επαναφόρτωση systemd-journal.service
### τώρα πρόκειται να προσομοιώσουμε ότι το δυαδικό αρχείο καταγραφής του περιοδικού είναι κατεστραμμένο ###
# cd / var / log / ημερολόγιο
# λς
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# nanosystem.journal
### τώρα τροποποιούμε κάποια γραμμή του αρχείου για να προσομοιώσουμε ότι είναι κατεστραμμένο
# περιοδικό
### όπως αναμενόταν τίποτα δεν συμβαίνει
#### πρέπει να γίνει επανεκκίνηση του υπολογιστή για να δημιουργήσει ένα νέο δυαδικό ημερολόγιο; ΟΧΙ
# systemctl αναγκαστική επαναφόρτωση systemd-journal.service
# λς
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
σύστημα.περιοδικό
# περιοδικό
### Όπως μπορούμε να δούμε, το περιοδικό δημιουργεί ένα νέο αρχείο δυαδικού αρχείου καταγραφής και μπορούμε πλέον να έχουμε πρόσβαση στις πληροφορίες ξανά χωρίς να χρειάζεται να επανεκκινήσετε τον υπολογιστή ανά πάσα στιγμή
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
συμπέρασμα: synflag ή ανίδεοι ή είστε αφηγητής
αφήστε το να σας διακοσμήσει πεπερασμένο
για πληκτρολόγηση σφάλματος και κατάχρηση αντιγραφής και επικόλλησης έγραψα το systemd-journal.service όταν στην πραγματικότητα η υπηρεσία ονομάζεται systemd-journald.service
Pichon ;, ... πόσο λάθος είσαι κοκαλιάρικος, σοβαρά .. Το ήξερα ήδη, αναφέρω το σφάλμα με κόκκινο καπέλο για να δεις τι είπαν, θα χτυπήσω την απάντηση, να δεις αν πιάσεις:
Εάν αφαιρέσετε το αρχείο εξόδου ή αντικαταστήσετε τμήματα του αρχείου, ο δαίμονας δεν μπορεί πραγματικά να κάνει τίποτα γι 'αυτό: εάν ένας εισβολέας έχει δικαιώματα τροποποίησης του αρχείου εξόδου, έχει ήδη κερδίσει. Ο δαίμονας θα μπορούσε να ελέγξει μερικά από αυτά τα πράγματα, αλλά αυτό θα ήταν μάλλον αναποτελεσματικό και δεν θα ήταν πραγματικά χρήσιμο για οτιδήποτε. Αν θέλετε, μπορείτε να ρυθμίσετε μια περιοδική κρυπτογραφική υπογραφή με το «journalctl –setup-keys». Δείτε τη σελίδα του ημερολογίου.
Το Journalctl εξαρτάται από το rsyslog, δεν γίνεται επανεκκίνηση σε περίπτωση σφάλματος στο αρχείο καταγραφής, το οποίο δεν χρειάζεται το rsyslog, συνολικά, πρέπει να χρησιμοποιήσετε το fordward για αποστολή στο rsyslog και έτσι γράφεται παρά τα πάντα και το ημερολόγιο ημερολογίου αναδημιουργείται , είναι σχεδιαστικό ελάττωμα του περιοδικού, αν δεν θέλετε να το δείτε, χτυπήστε με.
@rolo
Στο βίντεο (δεν ξέρω αν το κάνατε) Βλέπω ότι στο λεπτό 2:11 ls χρησιμοποιείται και όχι ls -l που θα επέτρεπε να δείτε το μέγεθος που είχε αρχικά το αρχείο system.journal, τότε το επεξεργαζόταν με nano και πρόσθεσαν Κενές γραμμές, επανεκκινήστε την υπηρεσία με το χέρι και στο λεπτό 3:15 κάνουν ξανά και όχι ls -l, τότε στο λεπτό 3:20 βλέπουν το αρχείο καταγραφής με το ημερολόγιο, αυτό δείχνει το τρέχον αρχείο καταγραφής που είναι εντάξει.
Ελάτε τώρα οι ερωτήσεις μου:
1 - επειδή χρησιμοποιείται ls και όχι ls -l, για να μπορείτε να δείτε το αρχικό μέγεθος που είχε το αρχείο καταγραφής πριν από την επεξεργασία
2 - τι συνέβη στο παλιό ημερολόγιο; πού το έβαλε το systemd στο κατεστραμμένο δυαδικό αρχείο καταγραφής;
3 - με ποια εντολή systemd μπορείτε να επιδιορθώσετε το κατεστραμμένο δυαδικό σας αρχείο καταγραφής ... το οποίο δεν πρέπει να διαγράψετε
αφορά
@Ανώνυμος
Ελάτε τώρα οι ερωτήσεις μου:
1 - επειδή χρησιμοποιείται ls και όχι ls -l, για να μπορείτε να δείτε το αρχικό μέγεθος που είχε το αρχείο καταγραφής πριν από την επεξεργασία
2 - τι συνέβη στο παλιό ημερολόγιο; πού το έβαλε το systemd στο κατεστραμμένο δυαδικό αρχείο καταγραφής;
3 - με ποια εντολή systemd μπορείτε να επιδιορθώσετε το κατεστραμμένο δυαδικό σας αρχείο καταγραφής ... το οποίο δεν πρέπει να διαγράψετε
1 την αλήθεια που δεν το σκέφτηκα, απλώς χρησιμοποιήστε ls για να δείτε ποια αρχεία ήταν στον κατάλογο, αλλά αν σας ενδιαφέρει μπορείτε να το αντιγράψετε, η διαδικασία είναι λεπτομερής και το έκανα στο virtualbox (η εγκατάσταση μιας βάσης debian είναι λίγο χάος)
2 το παλιό αρχείο καταγραφής παραμένει στον ίδιο κατάλογο, μόνο το systemd το μετονομάζει με μια σειρά από αριθμούς και γράμματα (φαίνεται στο βίντεο)
3 Σε κάθε περίπτωση, θα μπορούσατε να δοκιμάσετε να χρησιμοποιήσετε εφαρμογές τρίτων (κάποιο hex πρόγραμμα επεξεργασίας υποθέτω) γιατί εάν το systemd μπορούσε να επιδιορθώσει το κατεστραμμένο αρχείο, δεν θα το μετονομάσει ή θα δημιουργήσει ένα νέο. Σε κάθε περίπτωση, και όπως έχω ήδη αναφέρει σε άλλες περιπτώσεις σε αυτήν την ανάρτηση, ένα προσεκτικό sysadmin θα μπορούσε να χρησιμοποιήσει το rsyslog ή το syslog-ng ως δεύτερο εργαλείο ερωτήματος, εκτός από τη μετατροπή των εγγραφών περιοδικού σε απλό κείμενο σε περίπτωση που το δυαδικό λογισμικό καταστραφεί. .
Θέλω να πω, δεν είναι η ιδέα να πείσει κανέναν να χρησιμοποιήσει το systemd (θα ήθελα ακόμη και ότι στο πρόγραμμα εγκατάστασης του debian υπάρχει η δυνατότητα επιλογής του int). αλλά δεν πρόκειται να παραμείνω σιωπηλός όταν διαβάζω αδαείς ή υπέροχους που συνεχίζουν να επαναλαμβάνουν ψέματα για το systemd, καθώς υπάρχει ένα blog, όταν κάποιος βλέπει ότι αυτά τα λόγια δεν συμπίπτουν με την πραγματικότητα. και όπως είπε ο Αριστοτέλης, η μόνη αλήθεια είναι η πραγματικότητα 😉
@rolo
Έχω ξανακοιτάξει το βίντεο και ναι, ήταν εκεί, μόνο το αριθμητικό όνομα ήταν τόσο μεγάλο που το είδα, σκέφτηκα ότι ήταν ο κατάλογος….
Όσον αφορά την επιδιόρθωση του δυαδικού, ναι, είναι λογικό αυτό που λέτε ... αν μπορούσα να το επισκευάσω δεν θα δημιουργούσα νέο.
Τέλος, πιστεύω ότι δεν πρέπει να είναι δυαδικό έτσι ώστε να μην συμβεί και να μπορώ να το δω χωρίς ειδικά εργαλεία με το journalctl ... Ακόμα δεν καταλαβαίνω τι το οδήγησε να χρησιμοποιήσει δυαδική μορφή.
Χαιρετισμούς και ευχαριστώ που απαντήσατε
Ρόλο, αφιερωθείτε σε κάτι άλλο:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Το ήξερα χωρίς να το ξέρω…. Πώς θα παρατηρήσετε τη διαφορά μεταξύ ενός που δοκιμάζει πράγματα και ενός άλλου που κάνει μόνο βίντεο με κροτίδες
Έρχομαι να κλείσω το ocote de Rolo, το σφάλμα που εμφανίζεται στο PoC μου είχε αναφερθεί, οπότε, κλείστε το ocote pichon:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Ας δούμε υπέροχα:
1 Δηλώσατε ότι για να επιλύσει το πρόβλημα το περιοδικό ήταν απαραίτητο να επανεκκινήσετε τον υπολογιστή όπως στα παράθυρα ΣΥΝΟΛΙΚΑ ΛΑΘΟΣ
Σας έδειξα ότι ήταν ψέμα και στο βίντεο που κάνατε δεν χρησιμοποιείτε την εντολή systemctl force-reload systemd-journald.service γιατί αν το έχετε χρησιμοποιήσει, το επιχείρημά σας θα συντριβή (ή δεν γνωρίζετε την εντολή, η οποία θα έδειχνε ότι είστε ανίδεος, ή σκόπιμα δεν το χρησιμοποιούσατε, κάτι που θα έδειχνε ότι είστε αφηγητής)
2 Λέτε ότι υπάρχουν αναφορές σφαλμάτων, από τη μία πλευρά είναι εντελώς άσχετο, δεδομένου ότι συνήθως οι άνθρωποι αναφέρουν πολλές ανοησίες ως σφάλμα (για να καταλάβετε, δεν είναι κάθε αναφορά σφάλματος πραγματικό σφάλμα) ακόμη και μου δίνει την ιδέα ότι το αναφέρατε εσείς οι ίδιοι ίδιο. Και από την άλλη πλευρά, όλα τα προγράμματα έχουν σφάλματα (πόσα σφάλματα έχουν αναφερθεί έχει sysvinit (ένα πρόγραμμα ηλικίας περίπου 20 ετών)) και το καλό με την αναφορά είναι ότι βοηθά τους προγραμματιστές να ανακαλύψουν και να λύσουν προβλήματα (μερικά πιο γρήγορα, άλλα πιο αργά)
3 Λέτε ότι με το σφάλμα που δημιουργείτε στο ημερολόγιο, κατά την επανεκκίνηση του συστήματος και διακόπτεται, καθώς στο βίντεο μπορείτε να δείτε ότι πρέπει να κάνετε επανεκκίνηση του εικονικού πλαισίου. ΠΛΗΡΩΣ ΛΑΘΟΣ
Η αλήθεια είναι ότι το systemd δεν συντρίβεται καθώς το σύστημα ξεκινά τέλεια (αν δεν ξεκίνησε το systemd θα σας έδινε έναν πανικό πυρήνα και θα έπρεπε να μπείτε σε λειτουργία ανάκτησης)
Αυτό που συμβαίνει σε εσάς είναι ότι το σύστημα ελέγχεται όταν προσπαθείτε να επεξεργαστείτε ένα δυαδικό αρχείο με ένα πρόγραμμα επεξεργασίας κειμένου και οι παράγοντες μπορεί να είναι πολλοί, όπως η μνήμη που έχει εκχωρηθεί, η κατάσταση του λειτουργικού συστήματος (στο βίντεο το σύστημα χρειάζεται πολύ χρόνο για την εκκίνηση και απενεργοποιήστε αυτό που υποδηλώνει ότι δεν είναι καθαρή εγκατάσταση του 0 (το οποίο συνιστάται για αυτόν τον τύπο περίπτωσης)) κ.λπ. Μπορώ να σας πω μόνο ότι το δυαδικό που έχω επεξεργαστεί περίπου 10 ή 20 φορές και δεν ελέγχθηκε ποτέ. Αυτό δείχνει επίσης ότι είστε είτε αδαείς είτε αφηγητές.
4 Τώρα λέτε ότι το περιοδικό εξαρτάται από το rsyslog TOTALLY FALSE, το γεγονός είναι ότι οποιοσδήποτε μπορεί να το ελέγξει εγκαθιστώντας ή απεγκαθιστώντας το rsyslog και βλέποντας ότι το περιοδικό λειτουργεί τέλεια
Θα το εκτιμούσα πολύ αν αφήσετε αυτήν την ανθυγιεινή εμμονή με εμένα, δεν φταίω ότι είστε αδαείς ή υπέροχοι
Συμπέρασμα:
Δεν θέλετε να χρησιμοποιήσετε το systemd, νομίζω ότι είναι υπέροχο, τώρα δεν χρειάζεται να εξαπλώσετε τον τρόμο με ψέματα για να ακολουθήσετε τη σταυροφορία σας κατά του συστήματος. Έζησα και άφησα να ζήσω, ότι υπάρχει μια θέση για όλους στον κόσμο του ελεύθερου λογισμικού 😉
μια διευκρίνιση στο σημείο 3, κάποιος θα μου έλεγε ότι καθώς το systemd βρίσκεται στο pid1, μια συντριβή θα συνεπαγόταν αυτό το κράνος systemd. Δύο πράγματα, πρώτον εδώ αυτό που δηλώθηκε είναι ότι το systemd συνετρίβη λόγω της αποτυχίας του περιοδικού, αλλά στην πραγματικότητα υπάρχει έλεγχος για την εισαγωγή ενός δυαδικού (το οποίο χρησιμοποιείται σε πραγματικό χρόνο) με ένα πρόγραμμα επεξεργασίας κειμένου, διευκρινίζω επίσης ότι στο όλες οι δοκιμές που έκανα δεν έλεγξαν ποτέ την εικονική μηχανή. Δεύτερον, κανείς στο μυαλό του δεν μπορεί να ισχυριστεί ότι το linux δεν φέρει ετικέτα xddd,
Fabler;, κοκαλιάρικο, συγκρατήστε λίγο, μυρίζει τη γριά σας που λέει ότι ρίχνω το καουτσούκ όταν δεν το αγγίζω με ραβδί, επιστρέφω στο σεβασμό:
1.- Πρέπει να κάνετε επανεκκίνηση ή να αναγκάσετε την επανεκκίνηση της υπηρεσίας, η οποία δεν είναι ιδανική και στο CentOS 7 όταν δοκίμασα την επανεκκίνηση της υπηρεσίας δεν έκανε τίποτα, μην ξεχνάτε ότι είναι η έκδοση 208 και όχι η νέα 217 ή 216 του Fedora.
2.- Άσχετο και εκείνοι που αναφέρουν σφάλματα; ... είστε ηλίθιος, δεν σας απαντώ καν
3.- UNHAPPY, η έκδοση που δοκίμασα εκείνη την ημέρα του βίντεο, την οποία μπορείτε να δείτε, ολόκληρο το λειτουργικό σύστημα συντρίβεται, γιατί πιστεύετε ότι το ortho δυστυχισμένο ψέμα; Δεν είμαι ψέμα πίθηκος, πάμε να πάρω cindor pajero.
4.- Εξαρτάται από την αυτοαναγέννηση του εαυτού του, δεν το κάνει από μόνο του στην πραγματικότητα το πρότεινα στους προγραμματιστές devs ως χαρακτηριστικό, ότι αναγεννάται χωρίς να σταματά να καταγράφει εκτός εάν επανεκκινηθεί η υπηρεσία, το πήραν όπως είναι να προσθέσω, οπότε πιπιλίζω το πουλί μου και πες μου ευχαριστώ μπαμπά που συνεργάστηκες ενώ παρακολουθώ πορνό.
Chau skinny, κουράστηκα να μιλάω με πιθήκους, οπότε προτιμώ να πάω στο ζωολογικό κήπο, όταν βρίσκεστε στο επίπεδο του πρωκτού μου, συζητάμε.
@SynFlag Ζητώ συγνώμη, δεν ήξερα ότι ήσασταν άρρωστος, πραγματικά πίστευα ότι ήσασταν υπέροχος και ανίδεος, αλλά με αυτό που μόλις γράψα, συνειδητοποιώ ότι είστε πραγματικά παραληρητικοί.
τίποτα, ελπίζω να αποφοιτήσετε καλύτερα το φάρμακό σας και να επιστρέψετε στην πραγματικότητα, δύναμη! μπορείς!!!
Διαβάζω και διαβάζω και ξαναδιαβάζω, αλλά δεν καταλαβαίνω τίποτα, ξέρω μόνο ότι από τότε που το Xubuntu 14.04.1 κυκλοφόρησε μέχρι σήμερα, δεν είχα κανένα πρόβλημα με το σημειωματάριό μου ή με τον εκτυπωτή laser hp 1102 μου, δεν ξέρω τίποτα καθόλου, είμαι χρήστης και Δεν ξέρω αν το systemd είναι χειρότερο ή δεν είναι κατάλληλο για init, αλλά επαναλαμβάνω ότι δεν έχω κανένα πρόβλημα με το xubuntu. 🙂
Διαβάζω, διαβάζω και ξαναδιαβάζω και απλά ξέρω ότι ξαναζούμαι ένα παλιό θέμα. XD