Boycott systemd

**mobinmob** · 29-05-16, 17:26

Αρχικό μήνυμα από karakou

Τετοια προβληματα προσπαθει να λυσει το systemd, not an easy task.

Αυτό είναι βασικό πρόβλημα του systemd (mission creep), δεν δέχομαι να χρησιμοποιείται σαν επιχείρημα.
Τουλάχιστον δεν περιμένουμε πλέον τα kdbus και systemd-consoled...

- - - Updated - - -

Από τα αποτελέσματα της αλλαγής στο systemd :
https://github.com/tmux/tmux/issues/428
https://lobste.rs/s/iyhczp/systemd_d...sks_tmux_other

**mrsaccess** · 29-05-16, 18:04

Αρχικό μήνυμα από karakou

Ολα αυτα τα user processes που ανεφερες δεν εχουν σκοπο υπαρξης με το περας του user session, για ποιο λογο να μεινουν;Θα κανει τι ssh forwarding κ θα θελει να τρεχει το gpg-agent; Ή μηπως θα τρεχει soundserver κ θα θελει το pulseaudio ανοιχτο; Αν ειναι τοσο σημαντικο κατι τετοιο μπορει ειτε να τα τρεχει σα system services ή να κανει τις ρυθμισεις που αναφερθηκαν, δε καταλαβαινω το ντορο που γινεται για το least surprise principle. Αντι να επιβραβευουμε τα programming/sysadmin best practices, εμεις επιμενουμε σε κατι που χαλαει τη ζαχαρένια μας. Λες κ εχει σπασει ολο το λειτουργικο με μια ρυθμιση ασφαλείας.

Όπα! Hold your horses!

Χρησιμοποιείς σαν επιχείρημα την ασφάλεια αλλά αν κάτσεις να σκεφτείς τα πιθανά σενάρια (πχ server-desktop, από που θα μπει στο εκάστοτε ο επιτιθέμενος, πιο scope τον ενδιαφέρει) θα καταλάβεις πως αυτό δεν επηρεάζει τον cracker που πάντα θα παίρνει αυτό που χρειάζεται, αλλά τον χρήστη. Με απλά λόγια είναι DRM και όχι ασφάλεια.

Μιλάς για best practices αλλά αν ξεπεράσεις το τσιτάτο και κάτσεις να σκεφτείς πάλι, θα καταλάβεις πως όσο bad (ή good) practice είναι να μην σκοτώνεις τις εφαρμογές του χρήστη αν κάνει logout, το ίδιο bad (ή good) practice είναι να τις σκοτώνεις. Ο υπολογιστής δεν είναι αυτοκίνητο όπου αν δεν υπάρχει οδηγός στο τιμόνι δεν λειτουργεί.

Τέλος σχετικά με το gpg-agent (ή τον ssh-agent) υπάρχει καλός λόγος που μένουν. Αν θέλεις για παράδειγμα τον ssh-agent στο tmux σου, τότε πρέπει να τον ξεκινήσεις πριν το tmux, ώστε τα variables του να είναι διαθέσιμα σε όλα τα tabs του tmux. Αλλιώς κάθε φορά που κάνεις νέο tab, θα πρέπει να τα βάζεις χειροκίνητα (αδύνατο στην πράξη).

**karakou** · 29-05-16, 18:16

Αρχικό μήνυμα από mobinmob

Αυτό είναι βασικό πρόβλημα του systemd (mission creep), δεν δέχομαι να χρησιμοποιείται σαν επιχείρημα.
Τουλάχιστον δεν περιμένουμε πλέον τα kdbus και systemd-consoled...

- - - Updated - - -

Από τα αποτελέσματα της αλλαγής στο systemd :
https://github.com/tmux/tmux/issues/428
https://lobste.rs/s/iyhczp/systemd_d...sks_tmux_other

Για το tmux σιγουρα θελει συζήτηση, διαβασα το git issue, εγω συμφωνω με το τυπο που λεει να μπει configure/compile time switch --with-pam και να γραψουν ενα πατσακι.

**mobinmob** · 30-05-16, 10:08

To tmux αν δεν κάνω λάθος δεν χρησιμοποιεί ούτε PAM, ούτε dbus. Δεν είναι το ζήτημα μόνο αν είναι εύκολο να γίνει, αλλά ότι θα πρέπει να υπάρχει πολύ καλός λόγος για να προσθέσεις εξαρτήσεις. Tο γεγονός ότι το systemd σπάει by default κάτι που λειτουργούσε χρόνια, δεν ξέρω αν είναι επαρκής λόγος. Το πιο πιθανό είναι να προσθέσουν στο documentation οδηγίες για χρήση του systemd-run ή του loginctl...
https://lists.fedoraproject.org/arch...A27ARRLIZUI37/
Η απάντηση του υπευθύνου στην σχετική συζήτηση στην ml του fedora.

- - - Updated - - -

Η αλλαγή της default συμπεριφοράς του systemd μάλλον έχει να κάνει με αλλαγές στο dbus:
https://github.com/systemd/systemd/issues/2900

**imitheos** · 30-05-16, 14:40

Πρέπει να μπει στο στοίχημα δελτίο με το τι θα χαλάσει ο systemd την επόμενη εβδομάδα και να στοιχηματίζει ο κόσμος.

**Mosfet** · 01-06-16, 23:05

Ξαναέβαλα slackware (μετά από αρκετά χρόνια) και θυμήθηκα τι ωραία και καλά είναι τα πράγματα, χωρίς το άθλιο systemd.

**mobinmob** · 02-06-16, 13:41

Θα μπορούσες να βάλεις και Mint (upstart), devuan (sysvinit), voidlinux (runit), Gentoo ή manjaro με openrc ή Guix (dmd) για κάτι χωρίς systemd

Αν έβαλες 14.1 τα πακέτα είναι δυστυχώς αρκετά παλιά...

- - - Updated - - -

https://www.reddit.com/r/archlinux/c...brace_systemd/

**Mosfet** · 02-06-16, 18:33

Current έβαλα (εάν και όπου να ναι, θα βγει η 14.2).

Από τις άλλες distros που ανέφερες, το Mint είναι ετοιματζίδικη διανομή, στο gentoo πρέπει να μεταγλωττίσεις το σύμπαν (πράγμα που βαριέμαι), ενώ τις υπόλοιπες δεν τις έχω ακούσει καν.

Συνεπώς το slack (παλιά και γνώριμη λύση

), μου φάνηκε ως η πιο ορθολογική επιλογή...

**imitheos** · 02-06-16, 20:42

Όπα, προστέθηκε στο φόρουμ ακόμη ένας με slack μετά τον ludist και εμένα. Σιγά σιγά θα κατακλύσουμε το φόρουμ :evil laughter:

**mrsaccess** · 02-06-16, 21:47

Αρχικό μήνυμα από mobinmob

https://www.reddit.com/r/archlinux/c...brace_systemd/

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

**mobinmob** · 02-06-16, 22:50

Το πρόβλημα με την απάντηση στο reddit είναι ότι κάποια από αυτά που αναφέρει είχαν λυθεί σε άλλα rc/init systems (κάτι που επισημαίνει στην απάντηση χωρίς λεπτομέρειες) και κάποια δεν είναι καν σοβαρά προβλήματα. Στο openrc για παράδειγμα τα περισσότερα προβλήματα που αναφέρει δεν υπάρχουν (για να μην αναφέρω άλλα, όπως το... εξωτικό runit

).
Αυτό όμως που με εκπλήσσει είναι το πρώτο περί δυναμικού hardware. Κατ' αρχήν στην εκκίνηση ενός συστήματος δύσκολα θα έχεις συσκευές που θα εμφανίζονται και θα εξαφανίζονται. Αν το πρόβλημα είναι ότι περιμένεις στην έναρξη του udev, τότε υπάρχουν λύσεις, αλλά και πάλι πόσο είναι αυτή η καθυστέρηση; Αν μιλάμε για hw events κατά τη διάρκεια της λειτουργίας του συστήματος, θα ήθελα γνωρίσω στους ενδιαφερόμενους την εξωγήινη τεχνολογία που ονομάζεται udev rules.

Είναι αλήθεια πως το systemd προσφέρει ένα κοινό interface/abstraction για λειτουργίες που μπορούσαν να γίνουν με διαφορετικά εργαλεία, αλλά δεν νομίζω πως η προσσέγγισή του είναι η καλύτερη δυνατή - ούτε και ο τρόπος που "επιβάλλεται" η διάδοσή του.

- - - Updated - - -

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

**dpdt1** · 07-06-16, 11:13

αντι να φτιαξει το gnome τα bugs που δε κλεινουν τα processes στο logout, θέλει το systemd να αλλαξουν ολα τα υπόλοιπα που δουλέυουν μια χαρά τόσο καιρό...

και αλλα λινκ για γέλιο απο έναν systemd hater : https://lists.debian.org/debian-user.../msg00184.html ,
gnu/systemd και τα μυαλα στο μιξερ

- - - Updated - - -

https://lists.dns-oarc.net/pipermail...ne/014964.html

**imitheos** · 07-06-16, 14:47

Αρχικό μήνυμα από dpdt1

και αλλα λινκ για γέλιο απο έναν systemd hater : https://lists.debian.org/debian-user.../msg00184.html ,
gnu/systemd και τα μυαλα στο μιξερ

Μπήκα να δω για πλάκα το link και στο 3ο-4ο μήνυμα διάβασα το https://bugs.debian.org/cgi-bin/bugr...cgi?bug=725422 (το bug είναι παλιό φυσικά αλλά η ίδια συμπεριφορά ισχύει και στο master όπως έχει σήμερα https://github.com/systemd/systemd/b...fault.conf#L14).

Αν δηλαδή η διανομή δεν μπει στον κόπο να το αλλάξει (ίσως να το αλλάζουν όλες οι διανομές που δίνουν systemd, δεν το έχω ψάξει), τότε η μεταβλητή sysrq θα έχει τιμή 16 δηλαδή θα παίζει μόνο το sync και έτσι δεν μπορείς να τρέξεις reisub αν κολλήσει το σύστημα ή ό,τι άλλο θέλεις να τρέξεις.

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

**mezger** · 07-06-16, 18:09

Αρχικό μήνυμα από dpdt1

και αλλα λινκ για γέλιο απο έναν systemd hater : https://lists.debian.org/debian-user.../msg00184.html ,
gnu/systemd και τα μυαλα στο μιξερ

Wow, πραγματικά wow. Φαίνεται κλασική περίπτωση "You're holding it wrong", νομίζω όμως ότι αγγίζουν το Dead Parrot level.

**megahead13** · 07-06-16, 18:41

Αρχικό μήνυμα από dpdt1

αντι να φτιαξει το gnome τα bugs που δε κλεινουν τα processes στο logout, θέλει το systemd να αλλαξουν ολα τα υπόλοιπα που δουλέυουν μια χαρά τόσο καιρό...

και αλλα λινκ για γέλιο απο έναν systemd hater : https://lists.debian.org/debian-user.../msg00184.html ,
gnu/systemd και τα μυαλα στο μιξερ

- - - Updated - - -

https://lists.dns-oarc.net/pipermail...ne/014964.html

Θέμα: Boycott systemd

Tags για αυτό το Θέμα

Bookmarks

Bookmarks

Δικαιώματα - Επιλογές