Το thread του Debian (v.4)

[tiffany]

Με μια πρόχειρη ανάγνωση τους τα χώνει διότι είναι πολύ γραφειοκρατες στο πακετάρισμα. Γράφει ότι θέλει σχεδόν 7 ώρες μέχρι να ανέβει ένα πακέτο στα αποθετήρια με αποτέλεσμα αν υπάρχει κάποιο θέμα να μη μπορεί να το λύσει άμεσα καθώς θα είναι στη δουλειά του.

[jim_p]

Ναι αλλα... εγω δεν κολλησα στις ποτε στο ποσες ωρες κανει ενα πακετο να ανεβει στο repo. Ισως να το εκανα μια φορα, τοτε που ο chromium ειχε προβλημα και δεν επαιζε κανενα extension και παρολο που ο πατσαρισμενος κωδικας για την νεα εκδοση ανεβαινε κανονικα, το πατσαρισμενο πακετο ανεβηκε μετα απο ~7 μερες.
Εγω γκρινιαζω, κυριως, για το οτι καποιοι δεν ενημερωνουν τα πακετα τους και πρεπει να περιμενουμε μηνες, τις περισσοτερες φορες, για μια ενημερωση που παιρνει ΛΕΠΤΑ να χτιστει και να ανεβει, πχ qbittorrent.

[Zus]

Αν μπαίνεις από κινητό και σου φαίνεται μεγάλο το μέγεθος του κειμένου, δεν είναι. Φταίει το responsivness. 5-6 λεπτά θα σου πάρει .

[imitheos]

Ναι αλλα... εγω δεν κολλησα στις ποτε στο ποσες ωρες κανει ενα πακετο να ανεβει στο repo. Ισως να το εκανα μια φορα, τοτε που ο chromium ειχε προβλημα και δεν επαιζε κανενα extension και παρολο που ο πατσαρισμενος κωδικας για την νεα εκδοση ανεβαινε κανονικα, το πατσαρισμενο πακετο ανεβηκε μετα απο ~7 μερες.
Εγω γκρινιαζω, κυριως, για το οτι καποιοι δεν ενημερωνουν τα πακετα τους και πρεπει να περιμενουμε μηνες, τις περισσοτερες φορες, για μια ενημερωση που παιρνει ΛΕΠΤΑ να χτιστει και να ανεβει, πχ qbittorrent.

Μήπως μερικές φορές οι maintainers τα ενημερώνουν αλλά είναι αυτό που λέει ότι αργεί λόγω γραφειοκρατίας;

In Debian, packages are nudged in the right direction by a document called the Debian Policy, or its programmatic embodiment, lintian.

While it is great to have a lint tool (for quick, local/offline feedback), it is even better to not require a lint tool at all. The team conducting the change (e.g. the C++ team introduces a new hardening flag for all packages) should be able to do their work transparent to me.

Instead, currently, all packages become lint-unclean, all maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in. This causes a lot of overhead and manually executed mechanical changes across packages.

Notably, the cost of each change is distributed onto the package maintainers in the Debian model. At work, we have found that the opposite works better: if the team behind the change is put in power to do the change for as many users as possible, they can be significantly more efficient at it, which reduces the total cost and time a lot. Of course, exceptions (e.g. a large project abusing a language feature) should still be taken care of by the respective owners, but the important bit is that the default should be the other way around.

Debian is lacking tooling for large changes: it is hard to programmatically deal with packages and repositories (see the section below). The closest to “sending out a change for review” is to open a bug report with an attached patch. I thought the workflow for accepting a change from a bug report was too complicated and started mergebot, but only Guido ever signaled interest in the project.

Culturally, reviews and reactions are slow. There are no deadlines. I literally sometimes get emails notifying me that a patch I sent out a few years ago (!!) is now merged. This turns projects from a small number of weeks into many years, which is a huge demotivator for me.

Τα bold είναι δικά μου. Επίσης αναφέρει ότι χρησιμοποιούν πάρα πολλές υποδομές (οι οποίες μάλιστα σε μερικές περιπτώσεις είναι παλιές και παρωχημένες) το οποίο δυσκολεύει τους devs. Εγώ το είχα σχολιάσει παλαιότερα από την πλευρά του χρήστη όμως. Το debian είναι το μόνο που χρειάζεσαι 9 προγράμματα για βασικές λειτουργίες. Κάποιες δουλειές γίνονται με το apt, άλλες με το dpkg, άλλες με το apt-cache ενώς σε άλλες διανομές έχεις ένα εργαλείο για όλες τις δουλειές είτε θέλεις να εγκαταστήσεις, να δεις (reverse) dependencies, να βρεις ποιο αρχείο ανήκει σε πιο πακέτο, κτλ. Επίσης, το deb format είναι πιο περιττά πολύπλοκο και από το rpm ακόμη.

Δεν είναι φυσικά εύκολο να αλλάξεις διαδικασίες σε ένα project με 10K άτομα οπότε ψιλοκαταλαβαίνω και την γραφειοκρατία του debian αλλά γενικά καλά τα είπε ο Stapleberg (ο οποίος παρεμπιπτόντως δεν ήξερα ότι είναι debian dev, τον ήξερα λόγω του mod που είχε βγάλει για το πληκτρολόγιο kinesis advantage)

[tiffany]

Δε λέω ότι κόλλησες στο χρόνο. Αλλά ο τύπος ασχολείται και με άλλα πράγματα όπως όλοι μας. Αν λοιπόν ένα πακέτο θέλει 10 λεπτά να χτιστεί και ανέβει μετά από 7 ώρες ποτέ να το κατεβάσουν, να το δοκιμάσουν και να στείλουν πιθανό bug report. Τι πρέπει να κάνει; Να κάθεται σπίτι και αν ασχολείστε μόνο με debian; Δεν έχει άλλα ενδιαφέροντα; φίλους; σχέση;

Και σε επιβεβαιώνει με αυτό τον τρόπο. Έτσι θεωρώ. Το debian με ενεργά και τα 3 branches έχει 75.000 πακέτα. Χαμός στο ίσωμα για όποιον θέλει να φτιάξει κάτι.

[jim_p]

Θυμαται κανεις μια εντολη που παει καπως ετσι

wipe /dev/sdc

και σβηνει ολα τα partitions απο ενα σκληρο. Εχω ενα στικακι με chromium os και θελω να το φορμαρω, αλλα εχει 10+ partition και θα μου γινουν τσουρεκια να τα σβησω ενα ενα στο gparted.

[ifaigios]

Απλά σβήσε το 1ο megabyte του δίσκου ώστε να σβηστεί το partition table (όπου /dev/sdx αντικαθιστάς με τον δίσκο που θες να σβήσεις)

dd if=/dev/zero of=/dev/sdx bs=1M count=1 status=progress

[imitheos]

Απλά σβήσε το 1ο megabyte του δίσκου ώστε να σβηστεί το partition table (όπου /dev/sdx αντικαθιστάς με τον δίσκο που θες να σβήσεις)

dd if=/dev/zero of=/dev/sdx bs=1M count=1 status=progress

Σε stickάκι δεν είναι τόσο σύνηθες να έχει GPT (αν και έχω πετύχει κάποιες περιπτώσεις) αλλά να αναφέρω καθαρά εγκυκλοπαιδικά ότι σε περίπτωση που κάποιος σκληρός έχει GPT, το dd δεν προτείνεται γιατί δεν σβήνει το backup header στο τέλος του δίσκου οπότε δημιουργούνται διάφορα προβλήματα εκεί που δεν το περιμένεις.

Και το fdisk (με την λειτουργία o για MBR και g για GPT) και το gdisk (με την λειτουργία o) δίνουν την δυνατότητα να δημιουργηθεί από την αρχή ένας νέος πίνακας κατατμήσεων σβήνοντας έτσι με την μία όλες τις κατατμήσεις που μπορεί να έχει ο σκληρός.

[ifaigios]

Σε stickάκι δεν είναι τόσο σύνηθες να έχει GPT (αν και έχω πετύχει κάποιες περιπτώσεις) αλλά να αναφέρω καθαρά εγκυκλοπαιδικά ότι σε περίπτωση που κάποιος σκληρός έχει GPT, το dd δεν προτείνεται γιατί δεν σβήνει το backup header στο τέλος του δίσκου οπότε δημιουργούνται διάφορα προβλήματα εκεί που δεν το περιμένεις.

Και το fdisk (με την λειτουργία o για MBR και g για GPT) και το gdisk (με την λειτουργία o) δίνουν την δυνατότητα να δημιουργηθεί από την αρχή ένας νέος πίνακας κατατμήσεων σβήνοντας έτσι με την μία όλες τις κατατμήσεις που μπορεί να έχει ο σκληρός.

Σωστός. Επίσης στο gparted με Device -> Create Partition Table γίνεται αυτό που θέλει ο jim_p

[jim_p]

Η εντολη τελικα ειναι

wipefs --all /dev/sdx

αλλα μαλλον δεν εκανε δουλεια, γιατι οταν ξαναπηγα να περασω το img στο στικακι με το rufus, σταματησε στο 5% και το εκοψα. Μετα ξαναμπηκα αναγκαστηκα στο gparted, εσβησα τα παντα, εκανα και create partition table για να ειμαι σιγουρος και το rufus συνεχισε κανονικα.

[megahead13]

Ένας από τους maintainers του debian (Michael Stapelbergs) αποχωρεί και εξηγεί τους λόγους.
Πάνω κάτω αναφέρει πολλά πράγματα για τα οποία γκρινιάζει ο jim_p τόσο καιρό...

Oι Ubuntu devs άραγε έχουν αντίστοιχα προβλήματα στην ανάπτυξη του Ubuntu λόγω της δομής του Debian;;

[tiffany]

Oι Ubuntu devs άραγε έχουν αντίστοιχα προβλήματα στην ανάπτυξη του Ubuntu λόγω της δομής του Debian;;

Εχω μια αμυδρή εντύπωση πως έχει πάψει εδώ και χρόνια να είναι debian based. Δηλαδή δεν είναι RHEL - CENTOS. Αλλά κάτι πιο ελεύθερο.

[megahead13]

Εχω μια αμυδρή εντύπωση πως έχει πάψει εδώ και χρόνια να είναι debian based. Δηλαδή δεν είναι RHEL - CENTOS. Αλλά κάτι πιο ελεύθερο.

Δε νομίζω:

https://www.ubuntu.com/community/debian

Απ' όσο θυμάμαι πάντα βασιζόταν στο Debian Testing. Εκτός κι αν αυτό έχει σταματήσει πια και oi Ubuntu devs είναι πιο ευέλικτοι όσον αφορά την έκδοση κάθε πακέτου που θα βάλουν σε κάθε νέο release της διανομής.

[jim_p]

Το ubuntu ειναι κατα 90+% debian. Ελαχιστα πακετα τα χτιζουν διαφορετικα. Και οσες μεγαλες αλλαγες γινονται στο debian, πχ η μεταβαση σε systemd πριν 3-4 χρονια, τις ακολουθουν χωρις δευτερη κουβεντα.

[tiffany]

Γι' αυτό έβαλα τη σχέση RHEL - CentOS. Αυτά τα 2 είναι 100% ίδια. Μόνο κάποια copyrighted κομμάτια λείπουν. Το CentOS παίρνει τα SRPM και απλά τα χτίζει.

Από την άλλη το Ubuntu νομίζω πως παίρνει μεν τη βάση αλλά η τελική διανομή είναι εντελώς άλλο πράγμα. Δε νομίζω να καθίσει κανένας να χτίσει terminal Nethack game. Αυτό θα το πάρουν έτοιμο. Αλλά τα υπόλοιπα σημαντικά τα φτιάχνουν μόνοι τους. Άλλωστε είναι τόσο μεγάλοι που έχουν και δικά τους άτομα στα FOSS projects.