Το νήμα του Gentoo, version 1.0

[Gentoo]

Καλή φάση, μπράβο τους. Θα το διαβάσω πιο προσεκτικά αργότερα.

Ήδη κάποιοι hardcore gentoo users γκρινιάζουν γιατί χαλάει την όλη φιλοσοφία της source διανομής, αλλά οκ.

Καλό είναι να υπάρχουν κι άλλες εναλλακτικές. Μπορείς να κάνεις και μίξη binary/source πακέτων έτσι κι αλλιώς.

Για 'μενα ο κύριος λόγος που μένω στη διανομή είναι το portage και η δυνατότητα να διαλέξεις πχ openrc αντί του systemd.

Δεν μένω για τα USE flags, ούτε για τα άπειρα compilation times

[GoofyX]

Επιτέλους. Καιρός ήταν.

[imitheos]

Για 'μενα ο κύριος λόγος που μένω στη διανομή είναι το portage και η δυνατότητα να διαλέξεις πχ openrc αντί του systemd.

Δεν μένω για τα USE flags, ούτε για τα άπειρα compilation times

Με παραξενεύει αυτό που λες. Είχα την πεποίθηση ότι αν μας ζητούνταν να περιγράψουμε με δύο λέξεις τα οφέλη του gentoo, όλοι θα απαντούσαμε "USE flags". Η δυνατότητα μη χρήσης systemd υπάρχει σε πολλές διανομές (πχ το debian υποστηρίζει ταυτόχρονα systemd, sysvinit, runit, ποιος ξέρει τι άλλο.). Για να μην παρεξηγηθώ, δεν προσπαθώ να αφορίσω την άποψή σου. Ο καθένας μας έχει διαφορετικές απαιτήσεις / ανάγκες / θέλω και είναι απολύτως αποδεκτό αυτό που λες.

Gentoo goes Binary!


Καλά νέα για τα ζόρικα πακέτα

Πολλοί τα χρησιμοποιούμε εδώ και καιρό και παίζουν γενικά απροβλήματιστα, έχετε όμως ύποψιν ότι μπορεί υπό συνθήκες να δημιουργηθούν προβλήματα. Τις προάλλες μου έτυχε να τρέξω ένα πρόγραμμα και να παίρνω undefined reference to τάδε symbol. Αν έχω καταλάβει καλά, η επιλογή των binary πακέτων γίνεται με βάση τα use flags ώστε να επιλέγεται το σωστό πακέτο. Αυτό γενικά λειτουργεί σωστά. Μπορεί όμως να γίνει το εξής:

Ας υποθέσουμε ότι τρέχεις emerge -g foo με το foo να χρειάζεται την liba, η οποία με την σειρά της χρειάζεται την libb. Τα binaries και του foo και της liba ταιριάζουν με τις USE flags που έχεις επιλέξει. Η libb όμως δεν ταιριάζει και έτσι πρέπει να χτιστεί τοπικά. Το binary όμως της liba χτίστηκε με μια libb που έχει υποστήριξη για το Ψ πράγμα που εσύ απενεργοποίησες. Έτσι κάνει reference symbols που δεν υπάρχουν στην βιβλιοθήκη σου. Για να λυθεί αυτό, πρέπει ή να αλλάξεις τα USE ώστε να μπει σαν binary και η libb ή να χτίσεις τοπικά και την liba.

[Gentoo]

Με παραξενεύει αυτό που λες. Είχα την πεποίθηση ότι αν μας ζητούνταν να περιγράψουμε με δύο λέξεις τα οφέλη του gentoo, όλοι θα απαντούσαμε "USE flags". Η δυνατότητα μη χρήσης systemd υπάρχει σε πολλές διανομές (πχ το debian υποστηρίζει ταυτόχρονα systemd, sysvinit, runit, ποιος ξέρει τι άλλο.). Για να μην παρεξηγηθώ, δεν προσπαθώ να αφορίσω την άποψή σου. Ο καθένας μας έχει διαφορετικές απαιτήσεις / ανάγκες / θέλω και είναι απολύτως αποδεκτό αυτό που λες.

Κοίτα, τα USE flags για μένα, περισσότερο μπέρδεμα μου προκαλούσαν (ιδίως τα πρώτα χρόνια που ξεκίνησα να χρησιμοποιώ gentoo) παρά ευελιξία.

Και στην πράξη, διαφορά στην απόδοση δεν ξέρω αν αντιλήφθηκα και ποτέ.

Αντιθέτως, το portage σαν pm μου προσφέρει απίστευτη ευελιξία στο τι πακέτα θέλω να έχω στο σύστημα (με το package.mask), στο να κάνω παράλληλο merging διαφορετικών πακέτων χωρίς τα εκνευριστηκά locks των άλλων pm και τέλος, στο να διαχειρίζομαι με χειρουργική ακρίβεια κάθε πτυχή των πακέτων του συστήματος, με καλαίσθητο περιβάλλον και με όλη την απαραίτητη πληροφορία μπορεί να χρειαστώ.

Επίσης τα gentoo specific tools όπως το equery, μου κάνει τη ζωή πιο εύκολη.

Σίγουρα και τα USE flags είναι καλοδεχούμενα, ωστόσο δεν είναι αυτός ο λόγος που μένω στο gentoo τόσα χρόνια. Ο λόγος είναι ξεκάθαρα ο portage και η ελευθερία στην επιλογή βασικών συστατικών του infrastructure. Α και το rolling release φυσικά και το μηδαμινό bloat.

Πολλοί τα χρησιμοποιούμε εδώ και καιρό και παίζουν γενικά απροβλήματιστα, έχετε όμως ύποψιν ότι μπορεί υπό συνθήκες να δημιουργηθούν προβλήματα. Τις προάλλες μου έτυχε να τρέξω ένα πρόγραμμα και να παίρνω undefined reference to τάδε symbol. Αν έχω καταλάβει καλά, η επιλογή των binary πακέτων γίνεται με βάση τα use flags ώστε να επιλέγεται το σωστό πακέτο. Αυτό γενικά λειτουργεί σωστά. Μπορεί όμως να γίνει το εξής:

Ας υποθέσουμε ότι τρέχεις emerge -g foo με το foo να χρειάζεται την liba, η οποία με την σειρά της χρειάζεται την libb. Τα binaries και του foo και της liba ταιριάζουν με τις USE flags που έχεις επιλέξει. Η libb όμως δεν ταιριάζει και έτσι πρέπει να χτιστεί τοπικά. Το binary όμως της liba χτίστηκε με μια libb που έχει υποστήριξη για το Ψ πράγμα που εσύ απενεργοποίησες. Έτσι κάνει reference symbols που δεν υπάρχουν στην βιβλιοθήκη σου. Για να λυθεί αυτό, πρέπει ή να αλλάξεις τα USE ώστε να μπει σαν binary και η libb ή να χτίσεις τοπικά και την liba.

Εγώ από binary packages κυρίως το qtwebengine, το rust (που υπάρχει ήδη σε bin στο tree) και άλλα σχετικά πακέτα. Αλλά και πάλι καμιά φορά τα χτίζω κι αυτά, απλώς πιο αραιά.

[tsigarid]

Ήδη κάποιοι hardcore gentoo users γκρινιάζουν γιατί χαλάει την όλη φιλοσοφία της source διανομής, αλλά οκ.

Καλό είναι να υπάρχουν κι άλλες εναλλακτικές. Μπορείς να κάνεις και μίξη binary/source πακέτων έτσι κι αλλιώς.

Για 'μενα ο κύριος λόγος που μένω στη διανομή είναι το portage και η δυνατότητα να διαλέξεις πχ openrc αντί του systemd.

Δεν μένω για τα USE flags, ούτε για τα άπειρα compilation times

Οι hardcore gentoo users μάλλον δεν συνειδητοποιούν ότι είναι επιλογή, όχι υποχρέωση. Το αναφέρει και στη σελίδα που έστειλες, με χιουμοριστικό μάλιστα τρόπο:

But hey, that’s not optimized for my CPU!

Tough luck. You can still compile packages yourself just as before!

Όσο για τα USE flags, εκπλήσσομαι που το διαβάζω, όπως και ο imitheos. Είναι το πιο δυνατό κομμάτι του portage κατά τη γνώμη μου.

[Gentoo]

Οι hardcore gentoo users μάλλον δεν συνειδητοποιούν ότι είναι επιλογή, όχι υποχρέωση. Το αναφέρει και στη σελίδα που έστειλες, με χιουμοριστικό μάλιστα τρόπο:

Σίγουρα.

Όσο για τα USE flags, εκπλήσσομαι που το διαβάζω, όπως και ο imitheos. Είναι το πιο δυνατό κομμάτι του portage κατά τη γνώμη μου.

Τί όφελος είχες με τα USE flags; Εγώ διαφορά στην ταχύτητα δεν είδα. Περισσότερη πολυπλοκότητα βλέπω με το να διαλέγω USE flags σε κάθε νέο πακέτο θέλω να βάλω, παρά ευελιξία.

[tsigarid]

Τί όφελος είχες με τα USE flags; Εγώ διαφορά στην ταχύτητα δεν είδα. Περισσότερη πολυπλοκότητα βλέπω με το να διαλέγω USE flags σε κάθε νέο πακέτο θέλω να βάλω, παρά ευελιξία.

Μείωση των dependencies, άρα και των εγκατεστημένων πακέτων και των conflicts.

[GoofyX]

Τί όφελος είχες με τα USE flags; Εγώ διαφορά στην ταχύτητα δεν είδα. Περισσότερη πολυπλοκότητα βλέπω με το να διαλέγω USE flags σε κάθε νέο πακέτο θέλω να βάλω, παρά ευελιξία.

Καλά μην φανταστείς ότι με μειωμένα flags η ταχύτητα εκτέλεσης θα εκτοξευόταν. Σίγουρα είναι πιο γρήγορα τα εκτελέσιμα (λόγω και των aggressive flags που μπορείς να βάλεις στα CFLAGS), αλλά οι διαφορές μάλλον δύσκολα εντοπίζονται στην αντίληψη του χρήστη. Απλά έχει μικρότερα binaries συνήθως με αποτέλεσμα μικρότερη απαίτηση σε μνήμη και γενικότερα πιο ελαφρύ σύστημα.

Το portage καλό είναι, αρκεί να κάνεις sync και ενημέρωση το σύστημα συχνά. Αν αφήσεις το σύστημα για μήνες χωρίς ενημέρωση το πιθανότερο είναι ότι στο επόμενο sync θα ματώσεις ενδεχομένως για να το φέρεις στην current κατάσταση, λόγω των blocks, κτλ. Το έχω πάθει κανά 2 φορές...

[Gentoo]

Μείωση των dependencies, άρα και των εγκατεστημένων πακέτων και των conflicts.

Αυτό ναι. Μου αρέσει. Αλλά τα conflicts και τα blocks μια χαρά υπάρχουν, ακόμη κι έτσι.

Ξέρεις τι; Πριν 15-20 χρόνια, αυτά είχαν ένα νόημα λόγω των περιορισμένων δυνατοτήτων σε αποθηκευτικό χώρο και σε επεξεργαστική ισχύ.

Πλέον δεν έχει τόσο νόημα αν θα έχεις 500 πακέτα λιγότερα/περισσότερα ή αν θα είναι super παραμετροποιημένο το πακέτο στον επεξεργαστή σου.

Οπότε ναι. Πλέον δεν με συγκινεί η φάση των USE flags. Κάποτε μπορεί και να μου είχε φανεί ενδιαφέρον (δεν θυμάμαι).

- - - Updated - - -

Καλά μην φανταστείς ότι με μειωμένα flags η ταχύτητα εκτέλεσης θα εκτοξευόταν. Σίγουρα είναι πιο γρήγορα τα εκτελέσιμα (λόγω και των aggressive flags που μπορείς να βάλεις στα CFLAGS), αλλά οι διαφορές μάλλον δύσκολα εντοπίζονται στην αντίληψη του χρήστη. Απλά έχει μικρότερα binaries συνήθως με αποτέλεσμα μικρότερη απαίτηση σε μνήμη και γενικότερα πιο ελαφρύ σύστημα.

Το portage καλό είναι, αρκεί να κάνεις sync και ενημέρωση το σύστημα συχνά. Αν αφήσεις το σύστημα για μήνες χωρίς ενημέρωση το πιθανότερο είναι ότι στο επόμενο sync θα ματώσεις ενδεχομένως για να το φέρεις στην current κατάσταση, λόγω των blocks, κτλ. Το έχω πάθει κανά 2 φορές...

Για το πρώτο που λες, συμφωνώ, αλλά όπως είπα και στον tsigarid, πλέον έχει ψιλοχαθεί το νόημα αυτής της παραμετροποίησης.

Για το δεύτερο σκέλος που λες, εξαρτάται. Μπορεί να σου τύχει, μπορεί και όχι.

Προσωπικά έχω φτιάξει ένα script (το είχα ξαναναφέρει παλιότερα) με το οποίο χτίζω "με το στανιό" τα πακέτα, παρακάμπτοντας το οποιοδήποτε block και αφότου χτιστούν όσα πακέτα μπορέσουν να χτιστούν, μετά στρώνει η φάση με τα dependencies και χτίζονται και τα υπόλοιπα κανονικά.

Δοκιμασμένο εδώ και χρόνια και σε περιπτώσεις που είχα να αναβαθμίσω κανα 6μηνο (είχαν φτάσει κοντά 500 πακέτα για χτίσιμο).

[NicM1]

15 ημέρες στο ~amd64 δεν έχει εμφανιστεί κάνενα προβλημα στις εξαρτήσεις, οι ενημερώσεις μου φαίνονται σχεδόν τριπλάσιες.

[GoofyX]

15 ημέρες στο ~amd64 δεν έχει εμφανιστεί κάνενα προβλημα στις εξαρτήσεις, οι ενημερώσεις μου φαίνονται σχεδόν τριπλάσιες.

Με μπέρδεψες λίγο... Σε τι αναφέρεσαι;

[Gentoo]

Με μπέρδεψες λίγο... Σε τι αναφέρεσαι;

Είχε πει πιο πάνω ότι θα περάσει σε unstable branch. Και μας ενημερώνει για την κατάσταση

[NicM1]

Με μπέρδεψες λίγο... Σε τι αναφέρεσαι;

Πειραματίζομαι στο unstable branch.

[GoofyX]

Κουτσομπολιά:

2024-01-05-usr-initramfs
Title Separate /usr now requires an initramfs
Author Eli Schwartz <eschwartz93@gmail.com>
Posted 2024-01-05
Revision 1

Systems which have /usr and / on separate filesystems have always required a
dedicated initramfs to bring up both partitions. Systems where both /usr and /
are on the same filesystem may use an initramfs if they wish, or choose not
to.

Historically, Gentoo has tried to make the separate filesystems use case work
anyway. Despite all our efforts, it is broken and continues to get more broken
under various configurations. The only workable solution is to support
separate /usr but only when an initramfs is present. For more details on why
this is broken, see:

- https://bugs.gentoo.org/868306#c10
- https://bugs.gentoo.org/902829
- http://freedesktop.org/wiki/Software...-usr-is-broken
- https://bugs.gentoo.org/915379
- https://github.com/trofi/nix-guix-ge...8b64d6b5282907
- https://github.com/trofi/nix-guix-ge...806b1a379b5d06
- https://bugs.gentoo.org/825078

In 2013, Gentoo policy determined that separate /usr without an initramfs was
officially no longer supported:

- https://projects.gentoo.org/qa/polic...em.html#pg0202
- https://gitweb.gentoo.org/data/gento...3c79e0554819d0

11 years later, the support is being withdrawn. On 2024-02-05, we plan to
begin work on decommissioning existing workarounds and will not accept any
more.

User Action Required
====================

If you have separate /usr and are not currently using an initramfs, you have
until 2024-02-05 to set up an initramfs. If you do not, then at some point on
or after this date, routine system upgrades will leave your system unbootable.

For details on setting up an initramfs, see:

https://wiki.gentoo.org/wiki/Initramfs/Guide

[imitheos]

Αναμενόμενο μια και όλες οι διανομές πήγαν σε merged-usr εδώ και καιρό. Μία διανομή μόνη της δεν θα μπορούσε να κάνει maintain patches συνέχεια.

Αυτό τότε ήταν ακόμη ένα παράδειγμα της αλαζονίας των systemd devs. Πήγανε και βάλανε κανόνες udev στο /usr (ή χτίστηκαν ώστε να χρειάζονται βιβλιοθήκες από το /usr) και μετά βγήκανε και είπανε ότι πρέπει να φύγει το ξεχωριστό /usr επειδή δεν γίνεται διαφορετικά, επειδή ένα ζωτικής σημασίας πρόγραμμα όπως είναι το udev, δεν λειτουργεί. α) Εσύ γ...μένε το έκανες να μην λειτουργεί με την βλακεία σου να πας να βάλεις εκεί τους κανόνες και β) ούτε καν αυτό δεν ίσχυε. οι κανόνες που δεν έπαιζαν ήταν στην πλειοψηφία τους για ddc επικοινωνία με το monitor, mtp, κτλ, δηλαδή κανόνες που θα μπορούσαν να τρέξουν αφού γίνει mount το /usr. Δεν ήταν κανόνες απαραίτητοι για την εκκίνηση. Όπως πάντα, ανήθικα ψέματα για να υποστηρίξουν το αφήγημά τους.

Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff.

Αν εξαιρέσεις τα lvm, multipath όλα τα υπόλοιπα χρειάζονται τόσο νωρίς κατά την εκκίνηση προτού γίνει mount το /usr;

You don't believe us? Well, here's a command line that reveals a few obvious cases of udev rules that will silently fail to work if /usr is split off and not pre-mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* -- and you find a lot more if you actually look for it. On my fresh Fedora 15 install that's 23 obvious cases.

# egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* |cut -d: -f1|sort -u
/lib/udev/rules.d/61-gdm.rules
/lib/udev/rules.d/69-cd-sensors.rules
/lib/udev/rules.d/71-seat.rules
/lib/udev/rules.d/78-sound-card.rules
/lib/udev/rules.d/80-pktsetup.rules
/lib/udev/rules.d/90-alsa-restore.rules
/lib/udev/rules.d/90-iocost.rules

Ομολογουμένως δεν έχω ένα πολύ-γεμάτο-από-πακέτα gentoo αλλά κανένα εκ των παραπάνω δεν μου φαίνεται ότι χρειάζεται να τρέξει νωρίς. Όποιος έχει ένα γεμάτο gentoo, ας το τρέξει και να μας πει τι παίρνει.

Ποιος ήταν ένας από τους κύριους maintainer της udev; Ο Kay Sievers. Τι γνώμη είχε ο Linus για τον Kay (για άλλο θέμα);

And by "their" you mean Kay Sievers.

Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to work around the
problems you cause.

Greg - just for your information, I will *not* be merging any code
from Kay into the kernel until this constant pattern is fixed.

This has been going on for *years*, and doesn't seem to be getting any
better. This is relevant to you because I have seen you talk about the
kdbus patches, and this is a heads-up that you need to keep them
separate from other work. Let distributions merge it as they need to
and maybe we can merge it once it has been proven to be stable by
whatever distro that was willing to play games with the developers.

But I'm not willing to merge something where the maintainer is known
to not care about bugs and regressions and then forces people in other
projects to fix their project. Because I am *not* willing to take
patches from people who don't clean up after their problems, and don't
admit that it's their problem to fix.

Kay - one more time: you caused the problem, you need to fix it. None
of this "I can do whatever I want, others have to clean up after me"
crap.