Σεβαστή η άποψή σου, αλλά δεν μιλούσαμε γενικά για reproducibility αλλά για reproducible packages. Σε αυτά αναφέρθηκα, για αυτά έδωσα παραδείγματα. Πράγματι, θα ήταν ενδιαφέρον και θετικό να υπάρχει και αυτή η δυνατότητα για τα images, αλλά κατά τη γνώμη μου δεν προσφέρει και πολλά.
Ακόμα και για τα πακέτα, υπάρχει ζήτημα το τι θα είναι reproducible. Ότι είναι compiled μέσα σε αυτό; Το tar/ar; Το τελικό συμπιεσμένο πακέτο; Προφανώς μας ενδιαφέρει το περιεχόμενο, αλλά τα ερωτήματα δεν είναι υποθετικά ;) Στο arch π.χ. αρνήθηκαν να χρησιμοποιήσουν multithreaded xz compression γιατί σε edge cases το τελικό πακέτο δεν ήταν reproducible. Επέλεξαν να πάνε σε zstd και αυτό αφού βεβαιώθηκαν ότι δεν συνέβαινε κάτι τέτοιο.
Το flatpack πρακτικά είναι σχεδόν μια διανομή παράλληλα στην κύρια που έχεις. Αν το χρησιμοποιείς για ένα μόνο πακέτο, ο χώρος που καταλαμβάνει φαίνεται (και είναι) τεράστιος. Αν τα χρησιμοποιείς για περισσότερα, αρκετές εξαρτήσεις εγκαθίστανται μια φορά και “μοιράζονται” ανάμεσα στα προγράμματα.
Μα γι’ αυτό ανέφερα το .iso και η αναπαραγωγιμότητα πέρα από τα binaries θα είναι, θεωρώ, η φυσική εξέλιξη. Στην περίπτωση των διανομών, ποιο το νόημα να έχεις αναπαραγώγιμα επιμέρους πακέτα αν το .iso και το γενικότερο σύστημα εγκατάστασης του λειτουργικού δεν είναι και αυτό αναπαραγώγιμο; Όσον αφορά το Arch, κινούνται ήδη προς αυτήν την κατεύθυνση.
Μέχρι στιγμής η αναπαραγωγιμότητα στοχεύει στα binaries αλλά και στα τελικά συμπιεσμένα πακέτα. Τέτοια περιέχουν τα αποθετήρια και σε πακέτα αναφέρονται οι διανομές. To zstd (δημιουργία του Facebook, τι ειρωνεία) όμως επιλέχθηκε από το Arch όχι μόνο για την αναπαραγωγιμότητα αλλά και για την -κατά πολύ- μεγαλύτερη ταχύτητα συμπίεσης και αποσυμπίεσης έναντι του xz. Δε θα το επέλεγαν αν είχε χειρότερη απόδοση.
Η δυνατότητα να έχεις reproducible isos θα είναι θετική εξέλιξη. Απλά δεν πιστεύω πως προσφέρει αρκετά, όσα τουλάχιστον για ίδια τα πακέτα ;)
Ο λόγος που πολλές διανομές (προς το παρόν ξέρω για arch, fedora και voidlinux, λογικά είναι και άλλες) πηγαίνουν σε zstd είναι όντως η ταχύτητα, κυρίως στην αποσυμπίεση. Κατά τη γνώμη μου είναι λάθος κίνηση, αλλά αυτό είναι αδιάφορο (και άσχετο με το θέμα). Δεν θα μπορούσε να γίνει αυτή η κίνηση για το arch αν το τελικό αποτέλεσμα δεν ήταν reproducible -δες το comment του (τωρινού) arch project leader που ζητά επιβεβαίωση.
Για το xz:
The current method is xz -c -z - which is single-threaded and rather slow, so we are looking to replace it with something faster.
Multithreaded xz has come up in the past, and was quickly dismissed due to edge cases that would end up with packages being unreproducible on different machines - namely, xz -T0 – the method that automatically determines the amount of threads – produces different results when the amount of cores in a system is == 1: taskset -c 1 xz -c -z - -T0 < test > test.xz && sha256sum test.xz
fe95a1af78304ae4be508e071f6697296e52b625fba95fca5622757779633d90 test.xz
taskset -c 1,2 xz -c -z - -T0 < test > test.xz && sha256sum test.xz
3b2c520eda654de19c5fc02ea1d850e142ae24e1246edcce82e90bd690d18f99 test.xz
$ taskset -c 1,2,3 xz -c -z - -T0 < test > test.xz && sha256sum test.xz
3b2c520eda654de19c5fc02ea1d850e142ae24e1246edcce82e90bd690d18f99 test.xz
Εφόσον βασικό πλεονέκτημα της αναπαραγωγιμότητας αποτελεί η προστασία από backdoors και τα σχετικά, αν τα μεμονωμένα πακέτα στα αποθετήρια είναι αναπαραγώγιμα αλλά το τελικό .iso δεν είναι, εν μέρει χάνεται αυτό το πλεονέκτημα. Τουλάχιστον για τις διανομές εκείνες που εγκαθιστούν τα περιεχόμενα του .iso. Με αυτό το σκεπτικό το ανέφερα.
Προφανώς, αφού κατευθύνονται προς την αναπαραγωγιμότητα, δε θα επέλεγαν μέθοδο συμπίεσης πακέτων η οποία δε θα μπορούσε να την πετύχει. Απλά, η αναπαραγωγιμότητα δεν ήταν το μοναδικό ή το κύριο κριτήριο επιλογής. Αυτό εννοούσα παραπάνω.
Tα αποτελέσματα διαφέρουν μόνο μεταξύ t=1 και t ne 1
Aν κάνεις xz t2 ή τ12 το αποτέλεσμα είναι ακριβέστατα το ίδιο. Δηλαδή το πρόβλημα είναι μόνο γι αυτούς που θα κάνουν compression με 1 μόνο thread.
Mε την τιμή των refurbished pc για core2 ή amd 2+ να είναι στα 50eu μιλάμε πια για μια πάρα πολύ μικρή μειοψηφία που κάνει build με 1 core/1thread.
Στα δικά μου τέστ για να πλησιάσει το βαθμό compression το zstd το xz (δεν το φτάνει ποτέ) η ταχύτητα του έχει πέσει στο μισό του xz και το RAM έχει πάει στον ουρανό, όταν χρησιμοποιούνται όλα τα core. Σέβομαι τις υποχωρήσεις από μια διανομή να λειτουργούν όλα σε όλα τα pc, ακόμα και σε 64bit atom, αλλά χρειάζεται ένα σκασμό RAM αυτός ο σεβασμός με το zstd.
Άντε και η google, η oracle, η HP, έχουν προσφέρει αρκετό κώδικα ανοικτό και “ελεύθερο” ή ημι-ελεύθερο, αλλά η Facebook, η αρχι-ρουφιάνα, να εισχωρεί σε ένα χώρο εντελώς αντιφατικό με την ύπαρξή της; Πρέπει να τα άρπαξαν γερά οι devs, για να κάνουν τέτοια βήματα. Με τη fedora/centos είναι αναμενόμενο, αλλά από το arch και σε λίγο και το void …!!
(είμαστε εντελώς εκτός θέματος και αυτό θα είναι το τελευταίο σχόλιό μου στο παρόν νήμα)
Συγκεκριμένα για το Arch, ουδόλως τους απασχολεί με πόσα threads και cores θα κάνει συμπίεση ο εκάστοτε χρήστης και ποιες παραμέτρους θα χρησιμοποιήσει. Τους ενδιαφέρει όμως να έχουν την καλύτερη δυνατή απόδοση που μπορούν να επιτύχουν με τη δική τους υποδομή (παράλληλα με τις εκατοντάδες άλλες διεργασίες που πραγματοποιεί αυτή) για τα πακέτα των επίσημων αποθετηρίων, η οποία απόδοση επιβάλλεται να καλύπτει τους σκοπούς και τις ανάγκες της διανομής και, φυσικά, την αναπαραγωγιμότητα.
Γι’ αυτό, άλλωστε, έκαναν τις δοκιμές τους, τα αποτελέσματα των οποίων είναι δημόσια διαθέσιμα, και κατέληξαν στην παράμετρο -18. Το ίδιο ισχύει και για την ερώτηση που απευθύνεται στο Facebook
Επιπλέον, θα αναφέρω για άλλη μια φορά ότι αυτό που για εμάς είναι «φτηνό», για χιλιάδες άλλους ανθρώπους δεν είναι το ίδιο.
Η Facebook είναι μόνο μία από τις ιδιωτικές εταιρείες που συνεισφέρουν ανοιχτό κώδικα (όπου τις συμφέρει, θα πω εγώ) και αυτό δεν είναι αντιφατικό για την ύπαρξή τους (αφού τις συμφέρει), δεν απαγορεύεται, δεν είναι καν ηθικά μεμπτό —όσο ο σχετικός κώδικας παραμένει ανοιχτός και πληροί τους όρους της αντίστοιχης άδειας που τον συνοδεύει.
Οι δύο τελευταίες προτάσεις της ανάρτησής σου είναι «ιδεολογικά» προερχόμενη συνωμοσιολογία χαμηλού επιπέδου και άνευ της παραμικρής απόδειξης, που δε θα έπρεπε καν να υφίσταται στο ΕΛ/ΛΑΚ.
Έγραψα συγκεκριμένα “σεβαστό” αλλά η πρόθεση και η πράξη δεν κολλάνε στην περίπτωση.
Η συγκεκριμένη διανομή ήταν από τις πρώτες που σχεδόν ακαριαία διέκοψαν την υποστήριξη 32bit (και πάλι είχαν δικαιολογία και δημοσιευμένα επιχειρήματα … της …ς). Άρα μιλάμε για εξειδικευμένο σεβασμό σε αυτούς που έχουν 1core 64bit. Mε την επιβολή του zstd πρέπει να έχεις και RAM πολλαπλάσια της αξίας του ίδιου του μηχανήματος (τρέχα βρες RAM για μηχάνημα 15ετών). Ο όγκος των πακέτων αυξήθηκε, άρα και ο συνολικός όγκος των mirror αυξήθηκε. Χεστήκανε! Ο χρόνος για να κατεβάσεις τα μεγαλύτερα πακέτα αυξήθηκε, μια και μιλάμε για σεβασμό σε αυτούς που δεν έχουν Τ3 σύνδεση στην παράγκα τους.
Το stable kernel του arch είναι το 5.7-2 και το lts είναι 5.4-46, σεβασμός στα παλαιά μηχανήματα και τους μη-εχοντες, δεν το λες. Τι kernel έχετε στα mint/ubuntu/debian? Νομίζω μόνο στο sid του debian θα βρεις το 5.4
Στο void συγκριτικά θα βρεις το 4.4 4.9 4.14 και 4.19 αλλά έχουν και το 5.6
Για 80% των πακέτων η διαφορά ταχύτητας για την οποία ισχυρίζονται ότι υπερέχει το zstd είναι κλάσματα του δευτερολέπτου. Άντε σε κανένα κέρνελ/μπράουζερ/παιχνίδι να υπερβεί το δευτερόλεπτο.
Φαίνεται να είναι στην -20, φαντάζομαι γιατί αυτό παράγει πακέτα με μέγεθος πιο κοντά στο default του xz. Λογικό…
Συμφωνώ, αλλά αυτό σε iso που έχει φτιαχτεί με ήδη με reproducible packages (στην συντριπτική τους πλειοψηφία αν μιλάμε για debian π.χ.), είναι signed από τους devs και έχει υποστεί αρκετούς ελέγχους πριν δοθεί στην κυκλοφορία, παρέχει πολύ λίγα. Είναι θετικό όπως κάθε νέο μέτρο ασφάλειας βέβαια.
Για την αποκατάσταση των ανακριβειών που αναφέρθηκαν, επειδή διαβάζουν και άνθρωποι που δε γνωρίζουν σχετικά:
«Σχεδόν ακαριαία» με περιθώριο 10 μηνών από την ανακοίνωση μέχρι την έναρξη της υλοποίησής της και άλλους 9 μήνες περιόδου deprecation, κατά τους οποίους παρέχονταν κανονικά ενημερώσεις για τα 32bit συστήματα. Και ενώ ενθάρρυναν και στηρίζουν επίσημα το έργο Arch Linux 32, με συμμετοχή ακόμα και δικών τους προγραμματιστών σε διάφορα στάδια.
Σου επέβαλε κανένας να χρησιμοποιήσεις τη συγκεκριμένη διανομή; Σου υποσχέθηκε ότι μια σύγχρονη τεχνολογία όπως το zstd θα δουλεύει απρόσκοπτα σε μηχάνημα 15, 25, 35 ή όσων ετών επιθυμείς εσύ; Υπονοήθηκε κάπου ότι οι αποφάσεις του Arch αφορούν τους τελικούς χρήστες, τους χιλιάδες πιθανούς συνδυασμούς hardware και τους -επίσης χιλιάδες- πιθανούς τρόπους χρήσης αυτών; Μήπως αφαιρέθηκε η δυνατότητα να χτίσεις ολόκληρη τη διανομή μόνος σου με το ABS και διαφορετική μέθοδο συμπίεσης; Παρεμποδίστηκε με κάποιον τρόπο το forking;
Η δική μου αναφορά στο «φτηνό» δεν είχε απολύτως καμία σχέση με τις επιλογές του Arch αλλά αφορούσε τη λανθασμένη λογική του να θεωρείς ότι €50 είναι μαρουλόφυλλα για σχεδόν ολόκληρο τον κόσμο.
Όμως, ποιοι είστε εσείς που «μιλάτε για σεβασμό»; Εκπροσωπείτε το Arch; Η διανομή Arch Linux και οι προγραμματιστές της ουδέποτε ανέφεραν ή άφησαν να εννοηθεί ότι αποστολή τους είναι ο «σεβασμός», ειδικότερα προς τις παράλογες απαιτήσεις κάθε άγνωστου χρήστη που δε συνεισφέρει. Η διανομή αποσκοπεί στην κάλυψη των αναγκών όσων συνεισφέρουν σε αυτήν. Αναγράφεται ξεκάθαρα στο ταμπελάκι. Το Arch, όπως και άλλες διανομές, αποφάσισαν να μην αναλώσουν εργατοώρες σε παρωχημένες τεχνολογίες δεκαετιών. Να σου ζητήσουν συγγνώμη που δεν περίμεναν τουλάχιστον άλλα 10 χρόνια μέχρι να προσαρμοστείς εσύ;
Από πού ακριβώς προκύπτει η απαίτηση από τις διανομές για «σεβασμό» στα παλαιά μηχανήματα, τους δεινόσαυρους της τεχνολογίας και όποιον άλλον παραλογισμό; Προτίθεσαι να αναλάβεις τη συντήρηση του «legacy» κώδικα και να επιλύσεις τα ίδια προβλήματα που αντιμετωπίζει επί δεκαετίες ένα άλλο λειτουργικό, για μηδενικό όφελος προς εσένα και την εξέλιξη της τεχνολογίας;
Ε, τότε οι διαφορές ολόκληρων λεπτών θα αφορούν το υπόλοιπο 20%, σύμφωνα με τα στοιχεία που δε μας παρουσίασες. Επιπλέον, γνωρίζεις ότι ένα πακέτο δε χτίζεται μόνο μία φορά κάθε 5 χρόνια αλλά αυτό μπορεί να συμβαίνει σχεδόν καθημερινά και δεκάδες φορές ανά πακέτο, ειδικά στην περίπτωση των κυλιόμενων εκδοσεων; Τυγχάνει, επίσης, να γνωρίζεις ότι υπάρχουν στοιχεία λογισμικού που δε μπορούν να χτιστούν παρά μόνο με έναν πυρήνα ή thread, ακόμα κι αν έχεις 256 διαθέσιμους πυρήνες και multithreading;
Σε γενικότερο πλαίσιο και με απόλυτα φιλική διάθεση, σου λέω ότι ούτε εσύ ούτε εγώ ούτε κανένας άλλος δεν έχει το παραμικρό δικαίωμα να πει σε ανθρώπους που προσφέρουν εθελοντικά τη δουλειά τους σε αυτόν, και χωρίς αντάλλαγμα, πώς θα αποφασίζουν και τι θα υλοποιούν με τον κόπο και τους πόρους τους.
Αν έχεις την ικανότητα, φτιάξε και συντήρησε μια διανομή που να καλύπτει απόλυτα τις προσωπικές σου ανάγκες. Αν όχι, μπορείς να συνεισφέρεις όπως μπορείς σε κάποια που υπάρχει ήδη και σε καλύπτει. Αν πάλι, για οποιονδήποτε λόγο, δε μπορούν να ισχύσουν τα παραπάνω για εσένα, βρες μια διανομή που πλησιάζει σε αυτά που χρειάζεσαι και χρησιμοποίησέ τη.
Άποψη μπορείς να έχεις, όπως έχεις και επιλογές. Δε μπορείς όμως να έχεις απαιτήσεις, να διασπείρεις ανακρίβειες και συνωμοσιολογία, και να αμαυρώνεις την εικόνα και τη δουλειά άλλων ανθρώπων επειδή δε συμφωνείς με τις επιλογές τους, τους αντιπαθείς ή ό,τι άλλο.
Ζητάω συγγνώμη για τη συμβολή μου στον εκτροχιασμό του νήματος και θα απευθυνθώ σε όσους και όσες τύχει να διαβάσουν αυτήν την ανάρτηση με το παρακάτω απόσπασμα:
Επειδή κάποιος ανοίγει τον κώδικα σε κάτι, αυτό δε συνεπάγεται ότι οφείλει στον κόσμο μια αλλαγή στην κατάσταση, την εστίαση και την προσπάθειά του, π.χ. από εφευρέτη σε διαχειριστή κοινότητας.
Ως χρήστης κάποιου στοιχείου ανοιχτού κώδικα δε δικαιούσαι εκ τούτου τίποτα απολύτως. Δε δικαιούσαι να συνεισφέρεις. Δε δικαιούσαι χαρακτηριστικά. Δε δικαιούσαι την προσοχή άλλων. Δε δικαιούσαι να προσδίδεται αξία στα παράπονά σου. Δε δικαιούσαι αυτήν την εξήγηση.
Απο την στιγμή που τολμάς να δημοσιεύεις εσύ κάτι, λες ότι έχεις το δικαίωμα να το κάνεις, άλλο τόσο έχει δικαίωμα και ο καθένας να ασκήσει κριτική. Αν έχεις αυτιά και η κριτική ακολουθείται από λογικά επιχειρήματα θα έπρεπε να είναι ευπρόσδεκτη και εποικοδομητική.
Το ίδιο ισχύει και για το Μιντ και τις επιλογές του όπως και για το Arch. Kαι μιλάμε για τους dev της κλειστής ομάδας που αποφασίζει για την πορεία της διανομής. Ξέρεις όμως τόσα πολλά για το arch αλλά δεν ξέρεις από που χρηματοδοτείται; Τι άσχετα είναι αυτά για την δωρεάν προσφορά κώδικα στον ελεύθερο χρόνο του καθένα; Ο λόγος που όλοι αυτοί που συμβάλουν στο έργο δεν είναι στον κλειστό κύκλο και δεν αποφασίζουν, είναι γιατί το τυρί δεν είναι για όλους, είναι για τους λίγους.
Άρα συνολικά η δική σου κριτική είναι όσο γελοία είναι η κάθε απόπειρα υπεράσπισης του Facebook και του κάθε μισθωμένου προάγει την κυριαρχία του.
Στοιχεία υπάρχουν αναλυτικότατα για την επίδοση τόσο του zstd όσο και του xz, ακόμα και αυτά που παρουσίασε ο “υπερασπιστής” της χρήσης του στο arch εις βάρος του είναι. Τα κριτήρια που επέλεξαν την χρήση του δεν είναι καθόλου βασισμένα στα ίδια τους τα δεδομένα. Αν τα πακέτα ήταν κάμποσα Τerrabyte θα μπορούσε να πει κανείς ότι είναι βάσιμη η επιλογή, γιατί ο χρόνος είναι χρήμα!
Ακόμα και τα ubuntu όταν βγάζουν μια διανομή δεσμεύονται να την στηρίζουν για ένα χρονικό διάστημα χρόνων. Στο arch υπάρχουν ακόμα χρήστες που δεν πήραν χαμπάρι την αλλαγή.
Δεν είναι και τόσο άσχετη η συζήτηση με τους λόγους και τον τρόπο που το mint ξαφνικά έκοψε τα snaps.
Aν ισχυουν τα ποσοστα που αναφερετε, τοτε μιλαμε ξεκαθαρα για περιπτωση οπου ισχυει ο κανονας του παρέτο → Pareto principle - Wikipedia που εχει εφαρμογη και στην πληροφορικη, οπως θα δειτε αν διαβασετε το λινκ. Επομενως αν ειναι ετσι ή περιπου ετσι τα ποσοστα, ειναι λογικο να συμβαινει αυτο. Αρα πρωτον παρακαλω επιβεβαιωστε τα ποσοστα αν ειναι εφικτο. Δευτερον, μην τσακωνεστε για το μηκος των φτερων των αγγελων και αφηστε παρακαλω τα «εσυ ετσι και εγω αλλιως» για το facebook ή οπου αλλου γινεται αυτο. Εδω προσπαθουμε να τα αποφυγουμε αυτα. Ευχαριστω a priori…
Η συζήτηση για τα κίνητρα της αλητείας έχει μεταφερθεί σε άλλο thread.
Για το τεχνικό κομμάτι είναι απλό να χρησιμοποιήσεις ένα τέρμιναλ και να κάνεις compress /uncompress κάποιο συγκεκριμένο archive (πάρε το /usr/lib πχ) με τις παραλλαγές του xz και του zstd να αντιληφθείς από πρώτο χέρι την διαφορά.
Αλλά δεν είναι τα πάντα υπό αξιολόγηση με απόλυτα τεχνικά κριτήρια, για τον ίδιο λόγο που απορρίπτουμε την Ολλανδική μυζήθρα και το κινέζικο μποζολέ! Μπορεί και να είναι καλύτερα. Αλλά μπορείς να μιλάς για zstd χωρίς να αναφέρεις τον μεγάλο εχθρό της ανθρωπότητας facebook-nsa? Πόσο κολλημένος και απολίτικος τεχνοκράτης μπορεί να είσαι;
Θεωρώ την υιοθέτηση του zstd για τα πακέτα των διανομών περίεργη επιλογή. Να ξεκαθαρίσω ότι δεν έχω κάποιο πρόβλημα με τον αλγόριθμό, ούτε το παραπάνω είναι κριτική σε συγκεκριμένη διανομή. Άλλωστε η διανομή που χρησιμοποιώ το εκμεταλλεύεται για package metadata και πακέτα.
Υπάρχει όμως ένα ζήτημα. Το zstd δεν σχεδιάστηκε τόσο ή κυρίως για να πετυχαίνει εξαιρετικά υψηλή συμπίεση σε δεδομένα, όπως ο lzma/lzma2, όσο για να ανταγωνιστεί τα DEFLATE/gzip στον τομέα που αφορούσε την facebook - http compression, όπως τα brotli και zopfli της google.
Σε αυτή την αρχική του λοιπόν χρήση, το zstd πρόσφερε σχετικά μικρή συμπίεση - παρόμοια ή καλύτερη με τον ανταγωνισμό- αλλά με σημαντικά μεγαλύτερη ταχύτητα συμπίεσης και αποσυμπίεσης. Σε αυτόν τον τομέα είναι εξαιρετικό και βρίσκει τον δρόμο του σε άλλες εφαρμογές - filesystem compression σε zfs και btrfs π.χ. όπου οι ανταγωνιστές είναι gzip και lz4.
Στα πακέτα των διανομών δεν υπάρχουν ακριβώς οι ίδιες απαιτήσεις.
Για να μην διογκωθούν τα μεγέθη των πακέτων, οι ρυθμίσεις που χρησιμοποιούνται απαιτούν πολύ μεγαλύτερη χρήση μνήμης κατά την συμπίεση και το τελικό προϊόν είναι (λίγο) μεγαλύτερο σε μέγεθος από το xz. Οπότε έχεις μεγαλύτερες απαιτήσεις σε ram για τους build servers, μεγαλύτερες απαιτήσεις σε χώρο από τους mirrors και μεγαλύτερο όγκο δεδομένων για λήψη από κάθε κάθε τελικό χρήση. Έχεις βέβαια εξαιρετικά μεγαλύτερη ταχύτητα αποσυμπίεσης, που επηρεάζει την εγκατάσταση. Είναι όμως αυτό ένα optimisation που έχει νόημα; Πόσες φορές σε μια εγκατάσταση προγράμματος το bottleneck είναι η ταχύτητα αποσυμπίεσης και όχι η ταχύτητα του δικτύου - η λήψη δηλ. των πακέτων;
Προφανώς τα παραπάνω δεν τα αγνοούν οι άνθρωποι που πήραν τις αποφάσεις για την υιοθέτηση του zstd στα πακέτα των διανομών. Δεν μπορώ όμως να μην επισημάνω πως για πολλές διανομές, το κύριο πρόβλημα που θα είχαν να αντιμετωπίσουν και να υπολογίσουν θα ήταν η χρήση μνήμης κατά το build, αφού οι mirrors τους παρέχονται σε μεγάλο βαθμό δωρεάν (…) και για τους χρήστες η επιβάρυνση σε όγκο δεδομένων για μια τυπική αναβάθμιση δεν θα ήταν αρκετά μεγάλη σε σχέση με το xz για να δημιουργήσει προβλήματα ή αντιδράσεις…
Κάθε διανομή αποφασίζει (ελπίζω) σύμφωνα με τα δικά της κριτήρια, τις δυνατότητές της και αυτά που θέλει να επιτύχει*. Μπορεί εδώ να κατέληξαν στο ίδιο λογισμικό αλλά αυτό δε σημαίνει ότι περπάτησαν τον ίδιο δρόμο ή ότι θα το χρησιμοποιούν με τον ίδιο τρόπο.
Στην περίπτωση του Arch, παραθέτω (μεταφρασμένο) το σχετικό απόσπασμα από την ανακοίνωση:
Η επανασυμπίεση όλων των πακέτων σε zstd με τις επιλογές μας αποφέρει συνολική αύξηση ~0,8% στο μέγεθος όλων των πακέτων μας συνδυαστικά, αλλά ο χρόνος αποσυμπίεσης για όλα τα πακέτα σημείωσε επιτάχυνση ~1300%.
Δεν έχω κανέναν λόγο να αμφισβητήσω το παραπάνω αποτέλεσμα και σίγουρα δε θα ήταν τέτοιος το να κάνω προσωπικές δοκιμές με 10-20 πακέτα και να έχω διαφορετικό αποτέλεσμα. Δεν έχω τη δυνατότητα να αναπαραγάγω την υποδομή και το use case του Arch (ή άλλης διανομής), συνεπώς δεν υφίσταται σύγκριση.
Βεβαίως, είμαι ορθάνοιχτος (ελπίζω να είναι και οι διανομές) σε στοιχεία που να δείχνουν ότι για τον συγκεκριμένο συνδυασμό αναγκών, υποδομής και τρόπου χρήσης κατά περίπτωση υπάρχει μια προτιμότερη λύση. Μπορεί όντως να υπάρχει και απλά να μην τη γνωρίζουν ή να μην έτυχε να τη δοκιμάσουν.
Όσο όμως παραμένει το παραπάνω αποτέλεσμα και δε διαψεύδεται, τουλάχιστον στην περίπτωση της συγκεκριμένης διανομής, θεωρώ ότι το αναφερόμενο κόστος του ~0.8% αύξησης στο συνολικό μέγεθος των πακέτων είναι αμελητέο έναντι του ~1300% επιτάχυνσης της αποσυμπίεσης. Αυτό με βάση τα κριτήρια που έθεσε η συγκεκριμένη διανομή.
Τώρα, μπορεί κάποιος να θεωρεί ότι τα παραπάνω ή κάποια άλλα κριτήρια που έθεσαν οι διανομές δεν είναι αρκετά ή ότι θα έπρεπε να είναι διαφορετικά. Δεν έχει, λοιπόν, παρά να επικοινωνήσει απευθείας με αυτές και να μάθει αν η επιλογή τους έχει νόημα. Απλά θα τονίσω ότι κάτι μπορεί να έχει νόημα για εμάς αλλά όχι για κάποιους άλλους και αντίστροφα.
Τέλος, ενδέχεται η παραπάνω επιλογή να επιβαρύνει τον τελικό χρήστη. Ξανά για την περίπτωση του Arch, θα αναφέρω ότι οι προγραμματιστές του δε λαμβάνουν αποφάσεις με γνώμονα τη δυνητική επίπτωση στον τελικό χρήστη -εκτός, φυσικά, αν αυτή δεν είναι δυνητική αλλά προφανής- αλλά με (επί το πλείστον) τεχνικά κριτήρια που ικανοποιούν τις δικές τους ανάγκες.
Μπορεί και εδώ να πει κάποιος ότι δε συμφωνεί με αυτήν την πρακτική ή ότι είναι μια κακή πρακτική. Είναι όμως η πρακτική που ακολουθεί η συγκεκριμένη διανομή και δεν το κάνει κρυφά. Αν τον ενδιαφέρει τόσο η συγκεκριμένη διανομή, έχει τη δυνατότητα να επιδιώξει μέσα από γνωστές διαδικασίες να γίνει μέλος της ομάδας ανάπτυξης και, αν επιτύχει το consensus, να της αλλάξει πρακτική.
Στην προαναφερθείσα ανακοίνωση (04/01/2020) αναφέρεται ότι δεν έχουν εντοπίσει ακόμα ζητήματα από την πλευρά των χρηστών. Σήμερα είμαστε 5 μήνες αργότερα και εγώ δεν έχω υπόψη μου κάποιον ικανό αριθμό υπαρκτών δυσεπίλυτων προβλημάτων που προέκυψαν από τη χρήση του zstd ώστε να κρίνεται κακή η συγκεκριμένη επιλογή. Αν κάποιος άλλος γνωρίζει, ευχαρίστως να το συζητήσουμε και να ενημερώσουμε και τις διανομές.
*Σε ορισμένα θέματα κάποιες διανομές ή μεμονωμένοι προγραμματιστές τους συνεργάζονται και ανταλλάσουν απόψεις. Αυτό είναι όμορφο.
Κατ’ αρχήν δεν τίθεται θέμα διάψευσης. Όντως το zstd είναι τρομακτικά γρηγορότερο από το xz στην αποσυμπίεση! Όμως δεν τίθεται και ζήτημα προτιμότερης λύσης. Το arch επέλεξε να κάνει πρώτη προτεραιότητα την ταχύτητα αποσυμπίεσης, οπότε το zstd ήταν η απολύτως λογική επιλογή αντί του xz. Νομίζω (για τους λόγους που έχω αναφέρει) ότι είναι ο λάθος τομέας για να κάνεις βελτιστοποίηση της διαδικασίας. Προφανώς, αν η επιλογή βασίζεται κυρίως σε αυτή την παράμετρο, το zstd δεν έχει αντίπαλο ;)
Α, και κάτι που ξέχασα! Οι διανομές προφανώς και ΔΕΝ είναι ιδιαίτερα ανοιχτές σε feedback από την στιγμή που έχουν υλοποιήσει μια τόσο εκτεταμένη αλλαγή.
Δεκτά όλα τα παραπάνω και σε ευχαριστώ για τον διάλογο. Όμως, τι σε κάνει να πιστεύεις ότι είναι ο μοναδικός τομέας για τη βελτιστοποίηση του οποίου ενδιαφέρονται; Ο pacman, για παράδειγμα, έχει προσαρμοστεί και παλιότερα ώστε να γίνει ακόμα πιο αποδοτικός στις λειτουργίες του.
Από εκεί και πέρα, κάθε διανομή έχει διαφορετικές διαδικασίες και είναι πολύ πιθανό κάτι που μπορεί να βελτιστοποιηθεί σε μία να μη μπορεί να βελτιστοποιηθεί σε άλλη. Ας πάρουμε, αν δεν έχεις αντίρρηση, ως παράδειγμα το αυξημένο μέγεθος των πακέτων και του όγκου δεδομένων προς λήψη που ανέφερες και ας κάνουμε μια σύγκριση μεταξύ Debian και Arch.
Γνωρίζουμε ότι το Debian κάνει split τα πακέτα σε package και package-devel, ενώ το Arch δεν το κάνει. Συνεπώς, το μέγεθος των πακέτων στο Arch ήταν μεγαλύτερο και πριν από το zstd, άρα δεν υπάρχει δραματική αλλαγή.
Γνωρίζουμε, επίσης, ότι το Arch είναι rolling release ενώ το Debian όχι. Αυτό σημαίνει ότι το Debian θα επιβαρύνει σοβαρά το δίκτυο του χρήστη «μια κι έξω» κάθε όσα χρόνια κάνει τις μεγάλες αλλαγές του, ενώ το Arch θα το κάνει λιγότερο σοβαρά ενδεχομένως αλλά για συνολικά μεγαλύτερη διάρκεια. Γενικότερα, οι rolling release διανομές που έχουν συχνότητα παρόμοια με του Arch (γιατί το «rolling release» από μόνο του δεν προσδιορίζει τη συχνότητα αναβαθμίσεων) δεν είναι καλές λύσεις για όποιον έχει χαμηλή ταχύτητα δικτύου, ογκοχρέωση ή άλλα σχετικά. Οπότε, ούτε εδώ υπάρχει δραματική αλλαγή για το Arch.
Επιπλέον, το Debian θα μπορούσε, ενδεχομένως, να υλοποιήσει τα delta updates και να έχει όφελος. Το Arch δε μπορεί να το κάνει (και το έχει απορρίψει) γιατί δεν έχει πρακτικό όφελος για τη διαδικασία που ακολουθεί.
Με βάση τα παραπάνω, προκύπτει ότι η διαδικασία του Debian επιδέχεται βελτιστοποιήσεις που η αντίστοιχη διαδικασία του Arch δεν επιδέχεται ή, αντίστροφα, ότι το Arch δε μπορεί να κάνει βελτιστοποιήσεις σε σημεία που το Debian μπορεί. Αν, λοιπόν, υιοθετήσουν και οι δύο διανομές το zstd και το χρησιμοποιήσουν με τον ίδιο τρόπο, η επιλογή αυτή θα είναι σωστή για το Arch και λανθασμένη για το Debian. Αυτό όμως θα ισχύει αποκλειστικά για τα προαναφερθέντα και όχι καθολικά για τη διαδικασία της μίας ή της άλλης διανομής.
Μπορούμε να συζητήσουμε και άλλες περιπτώσεις που επιδέχονται ή δεν επιδέχονται βελτιστοποιήσεις και, γιατί όχι, να τις προτείνουμε στις διανομές -αν δεν έχουν προταθεί ήδη- και να μάθουμε αν είναι εφικτή η υλοποίησή τους και ποιο θα ήταν το πραγματικό όφελος.
Τέλος, αν παρουσίαζε κάποιος μια εναλλακτική η οποία θα είχε αποδεδειγμένα μεγαλύτερο όφελος έναντι μικρότερου κόστους για τα συγκεκριμένα κριτήρια κάποιας διανομής και παράλληλα θα μπορούσε να υλοποιηθεί από αυτή σε λογικά πλαίσια (ή, ακόμα καλύτερα, θα ήταν πρόθυμος να την υλοποιήσει ο ίδιος), θεωρώ προσωπικά ότι θα ήταν τουλάχιστον παράλογη η απόρριψή της από την πλευρά της διανομής.
Δεν ισχυρίστηκα κάτι τέτοιο γενικά (arch is for ricers δλδ :P ) … Η προτεραιότητα ήταν για την συγκεκριμένη απόφαση υιοθέτησης του zstd.
Η σύγκριση με το debian είναι λίγο προβληματική. Βλέπεις το Debian έχει και rolling release κομμάτι, τα πακέτα για το οποίο γίνονται mirrored κανονικά και χρησιμοποιείται και εκτός της ανάπτυξης της επόμενης stable. Επίσης έχει και κάμποσες αρχιτεκτονικές. Αύξηση του όγκου των repos κατά 0.8% σε arch και debian μεταφράζεται σε εντελώς διαφορετικά μεγέθη. Από την άλλη, η διανομή που χρησιμοποιώ επίσης υποστηρίζει επίσημα αρκετές αρχιτεκτονικές και επέλεξε να πάει σε zstd.
Τα delta packages (υπάρχει debdelta εδώ και χρόνια, δεν ξέρω αν το συνεχίζουν) είναι μια άλλη ισσοροπία από αυτή που επιτυγχάνεται με το zstd. Στο τελευταίο θέλεις την ταχύτητα και θυσιάζεις λίγο (ποσοστιαία) χώρο και όγκο δεδομένων που μεταφέρονται. Στα deltas θυσιάζεις την ταχύτητα και τον χώρο σε servers/mirrors αλλά κερδίζεις (πολύ) σε όγκο δεδομένων που μεταφέρονται. Η μόνη εμπειρία που έχω με delta packages είναι σε fedora παλιότερα με το yum-presto plugin. Και ναι, σε μια σχετικά αργή σύνδεση υπάρχει τρομακτική διαφορά. H fedora μπορεί να μην είναι rolling, αλλά όσο την χρησιμοποιούσα είχα πολύ “φρέσκα” πακέτα.
Έχεις σίγουρα δίκαιο ότι διαφορετικές διανομές μπορεί να έχουν διαφορετικές λύσεις, γιατί έχουν διαφορετικές ανάγκες. Στην περίπτωση όμως κάποιων low-level επιλογών, εξυπηρετεί τις διανομές να έχουν κοινές επιλογές. Πιστεύω πως το zstd θα είναι μία από αυτές στο μέλλον, άσχετα με το ότι πρέπει να γίνει ο υπολογισμός που έχω περιγράψει και δεν με ικανοποιεί.
Παράλογη ίσως. Ωστόσο αρκετές διανομές είναι επιφυλακτικές σε μεγάλες αλλαγές σε βασικά εργαλεία τους - από μία άποψη καλά κάνουν. Σε τέτοιο βαθμό που δεν θα μου έκανε εντύπωση να μην υιοθετηθεί μια τέτοια πρόταση. Ειδικά στο θέμα του αλγορίθμου συμπίεσης, δεν έχουμε συχνά μεγάλες αλλαγές. Αν θυμάμαι καλά, η πρώτη προσπάθεια για υιοθέτηση πακέτων με συμπίεση xz έγινε για slackware με τα tukaani pkgtools (2007). Ε, άργησε να υιοθετηθεί σε διανομές (2-3 χρόνια), παρά το γεγονός ότι δεν υπήρχε καμία αντίρρηση για την υπεροχή του σε ποσοστό συμπίεσης σε σχέση με gzip και bzip2. Με το zstd είναι η πρώτη φορά που θυμάμαι μετάβαση σε μορφή συμπίεσης λιγότερο αποδοτική σε μέγεθος αρχείου αλλά πιο αποδοτική σε ταχύτητα! Συνέβαινε παλιότερα να επιλέγει μια διανομή gzip αντί για bzip2 για ταχύτητα αλλά δεν θυμάμαι μετάβαση σε αυτό. Για μένα είναι περίεργη προτεραιότητα.
Ναι, το Debian έχει και rolling release εκδοχή αλλά α) δεν είναι η βασική εκδοχή της διανομής και β) δεν είναι πάντοτε rolling. Αναφέρομαι στο Sid. Η testing εκδοχή, δε, δεν ήταν ποτέ πλήρως rolling. Αυτό το αναφέρω γενικότερα, γιατί υπάρχουν πολλοί που θεωρούν ότι είναι όντως rolling (δεν υφίσταται rolling release με ενδιάμεσα freezes). Συνεπώς, στη σύγκριση που έκανα αναφερόμουν στις βασικές εκδοχές των δύο διανομών.
Αυτό που προσπαθώ να πω όμως είναι ότι, τουλάχιστον από την πλευρά μου, δε γνωρίζω επακριβώς ποιες είναι οι ανάγκες της κάθε διανομής και τι δοκιμές κάνει ώστε να καταλήξει στην όποια απόφαση. Άρα δε μπορώ να κρίνω.
Το μόνο που γνωρίζω στην περίπτωση του Arch είναι ότι οι προγραμματιστές αποφασίζουν έπειτα από συνδυασμό τεχνικών στοιχείων αλλά και φόρτου εργασίας. Δηλαδή, αν για παράδειγμα στο συγκεκριμένο θέμα γνωρίζουν ότι υπάρχει κάποια πιο αποδοτική λύση αλλά η υλοποίησή της χρειάζεται πιο εκτεταμένες αλλαγές από το zstd, δε θα την επιλέξουν.
Όσο για τα delta updates, έχουν όντως τεράστια διαφορά για τον τελικό χρήστη αλλά, αν θυμάμαι καλά, επιβαρύνουν περισσότερο την υποδομή της διανομής.
