Το “αρκετές” προφανώς δεν είναι αρκετά 
ακριβές. Δεν χρειάζεται να αφορά το 100% των πακέτων για να είναι κανόνας 
Debian: https://isdebianreproducibleyet.com/
Arch: https://reproducible.archlinux.org/
Στις 2 παραπάνω (και λογικά σε αρκετά από τα παράγωγά τους) η πλειοψηφία των πακέτων είναι reproducible (σε amd64).
Δουλειά έχει γίνει σε fedora, opensuse, voidlinux κ.α.
Πάντως, το χαρακτηριστικό αυτό, που εξαρτάται (και) από το πως χτίζονται τα πακέτα, κάλλιστα θα μπορεί να υπάρχει σε κάτι cross-distro.
Απο την στιγμή που θα φτιαχτούν τα build scripts για ένα πακέτο, αυτό πλέον είναι εύκολο να περάσει και σε άλλες διανομές. Για κάποια λίγα πακέτα αυτό είναι από δύσκολο έως αδύνατο εκ φύσεως.
Ίσως, αλλά -τουλάχιστον- για τις διανομές εκείνες που δε χρησιμοποιούν το netinstall ως βασικό τρόπο εγκατάστασης (ή δεν έχουν τέτοια δυνατότητα), αν το επίσημο .iso δεν είναι reproducible, εγώ προσωπικά δε μπορώ να πω ότι είναι κανόνας. Επίσης, τίποτα δεν εγγυάται (ακόμα;) ότι ένα πακέτο με reproducible έκδοση 1.0 θα είναι reproducible και στην 1.1.
Όχι απαραίτητα. Αν και μπορούν να υπάρξουν μερικοί κοινοί παράγοντες, η αναπαραγωγιμότητα εξαρτάται άμεσα από και προσδιορίζεται σύμφωνα με το build environment και αυτό δεν είναι (ενδεχομένως, δε μπορεί να είναι) standard. Αν συγκλίνουν οι διανομές, ίσως να συμβεί.
1 «Μου αρέσει»
Όταν είχε ξεκινήσει το Debian σε κάποιο Debconf είχε μια αναλυτική παρουσίαση για τα προβλήματα και πως μπορείς να προετοιμάσεις ένα πακέτο. Πρέπει να κάνεις κάποιες αλλαγές στo autoconf, makefile, cmakelists ή οτιδήποτε άλλο χρησιμοποιεί κάθε έργο.
Οι αλλαγές αυτές συνήθως είναι απλές. Για παράδειγμα θα πρέπει να αναφέρεις τις εξαρτήσεις αναλυτικά ώστε να γίνει το linking με γνωστή σειρά αντί να χρησιμοποιείς κάτι σαν ‘*.c’. Αλλαγές που εύκολα περνάνε στον αρχικό πηγαίο κώδικα. Οπότε μια φορά θα πρέπει να γίνει αυτό και επωφελούνται όλες οι διανομές. Το building environment είναι σημαντικό και κάθε διανομή θα βγάλει διαφορετικό πακέτο μιας και οι βιβλιοθήκες δεν θα είναι ίδιες, αλλά είναι εύκολο. Το infrastructure όμως (μηχανές και άνθρωποι) δεν είναι το ίδιο εύκολο να στηθεί, ειδικά για ποιο μικρές διανομές.
Δυστυχώς έχω χάσει το βίντεο της παρουσίασης και ξεχνάω τις λεπτομέριες.
Εμένα μου παίζει σωστά με το deb.
Επίσης το flatpak είναι παλαιότερο του deb.
Τέλος:
Σοβαρά; 2,1 GB για viber??? Σόρι δεν θα πάρω. Δεν είναι ακόμα “τσάμπα” ο χώρος στον SSD.
2 «Μου αρέσει»
Το Reproducible Buildιng είναι και ένα σοβαρό θέμα εμπιστοσύνης.
Για μένα ένας τρόπος σημαντικός είναι η επιβεβαίωση να μπορούν να κάνουν οι τελικοί χρήστες, δημιουργώντας απ την πηγή και λαμβάνοντας ένα παρόμοιο αποτέλεσμα.
Ιστορικά το Unix δε το είχε δει ως πρόβλημα.
Ένα παράδειγμα. Κάθε πακέτο Slackware είναι ένα αρχείο tar, και κάθε αρχείο tar περιέχει τα λεγόμενα time-stamps και επομένως δύο πακέτα θα είναι πάντα διαφορετικά, εκτός εάν τα time-stamps είναι ψεύτικα.
Υπάρχουν και άλλες, πολλές πηγές όπως πχ τεκμηριώνονται απ’ το πρόγραμμα αναπαραγωγιμότητας του Debian… https://wiki.debian.org/ReproducibleBuilds/Howto
Ναι, προς το παρόν δεν υπάρχουν διανομές που μπορούν να αναπαραχθούν 100%.
Εγώ επιμένω στο θέμα εμπιστοσύνης και γι αυτό όταν τρέχοντας πχ Slackware βρήκα δυο λόγους που με ικανοποίησαν και εμπιστεύτηκα.
1.Τα δυαδικά του Slackware κατασκευάζονται και υπογράφονται από έναν άνθρωπο σε ένα μέρος. Ακόμα και όσο να φανεί αστείο, εγώ δεν μπορώ να φανταστώ τον Patrick Volkerding να πουλάει.
2.Εδώ, ότι και αν παρθεί απ το Slackbuilds το χτίζει ο χρήστης οπότε μπορεί να εμπιστευτεί τον εαυτό του
Υπό την έννοια αυτή λύνεται το πρόβλημα εμπιστοσύνης αλλά όχι το πρόβλημα reproducibility, απλά θεωρώ πως το κάνει πλέον άσχετο.
Φίλες και φίλοι χρησιμοποίησα τη διανομή Slackware για ευνόητους λόγους και γιατί με εξυπηρετεί μέχρι αυτή τη στιγμή που γράφω περισσότερο από οποιαδήποτε άλλη διανομή.
@anon54176929, χαίρομαι που σε ξανά διαβάζω!
3 «Μου αρέσει»
Ας υποθέσουμε πως κάποιος επεμβαίνει στον υπολογιστή του Patrick Volkerding και αλλάζει μια στατική βιβλιοθήκη. Η αλλάζει τον compiler του. Τότε θα παράγεις πακέτα που θα έχουν ενδιαφέρουσες άλλες παράλληλες λειτουργίες.
Η εμπιστοσύνη στον Patrick Volkerding δεν αρκεί.
Να κάνω και μια μικρή διόρθωση. Ιστορικά το UNIX το πρόβλημα το είχε δει από πολύ νωρίς και είχε επισημάνει το πρόβλημα. Απλά δεν μπορούσε να βρει μια αξιόπιστη λύση. Σήμερα βρέθηκε μια σχετικά ικανοποιητική λύση στο πρόβλημα με τα reproducible builds. Και λέω μερική γιατί πλέον μικρή εμπιστοσύνη έχω στον ίδιο τον επεξεργαστή. Αλλά μπορείς να κάνεις ένα reproducible build με cross compile σε μια άλλη αρχιτεκτονική όπως πχ να φτιάξεις τα πακέτα σε ένα ARM.
Παραθέτω ένα πολύ γνωστό paper του ίδιου του Ken Thomson απο το μακρινό 1984.
Αξίζει να διαβαστεί. Το είχε γράψει όταν είχε βραβευτεί από την ACM (Κάτι ισοδύναμο με το βραβείο Nobel για την πληροφορική). Είμαι σχεδόν σίγουρος πως έχω διαβάσει παλαιότερο paper του ίδιου (ή μήπως ήταν του Niklaus Wirth ; )
2 «Μου αρέσει»
Αυτό που εννοώ με το “αναπαραγώγιμο” είναι ότι υπάρχει μια γνωστή συνταγή που μπορεί να χρησιμοποιηθεί ξανά. Η πρόθεση είναι ότι κάθε φορά που δημιουργείτε ένα πακέτο από ένα σενάριο, θα έχει ο χρήστης το ίδιο αποτέλεσμα - αλλά δεν πρόκειται απαραίτητα να συμβεί: η έξοδος του πακέτου μπορεί να μην είναι η ίδια αν το δημιουργήσε σε σχέση με το όταν χτίστηκε από τον Patrick.
Ο λόγος είναι ότι το περιβάλλον - το λειτουργικό σύστημα - αλλάζει (αναβαθμίσεις πακέτων, καταργήσεις, προσθήκες) και αν δεν δημιουργήσει όλα τα πακέτα με την ίδια ακριβώς σειρά όπως έκανε ο Πάτρικ, τότε το πακέτο του χρήστη μπορεί ή όχι να συνδέεται με μια βιβλιοθήκη - ανάλογα με το εάν είχε εγκατασταθεί ή όχι εκείνη τη στιγμή, ή ίσως κάποια τεκμηρίωση μπορεί να μην κατασκευαστεί επειδή το εργαλείο για τη δημιουργία δεν μπορούσε να καταλάβει μια νεότερη μορφή τεκμηρίωσης.
Για μένα, καμία υπόθεση δεν μπορεί να λάβει στίγμα εμπιστοσύνης όπως και το ότι δεν άλλαξε κάτι το Unix ιστορικά απλά επισήμανε αυτό που δεν είναι αλλαγή. Όταν μάλλον η εμπιστοσύνη δεν χωράει σε μέτρα και σταθμά. Δεν υπάρχει για μένα τουλάχιστον λίγη ή μετρίως έως αρκετή εμπιστοσύνη!
Νομίζω, και χωρίς καμία υπόνοια υποτίμησης, πως θέλεις αρκετό διάβασμα τόσο στο θεωρητικό όσο και στο πρακτικό κομμάτι. Για παράδειγμα μίλησα για στατικές βιβλιοθήκες, κομμάτια κώδικα που αποτελούν τμήματα του προγράμματος και δεν έχουν κάποια σχέση με τις δυναμικές βιβλιοθήκες στις οποίες αναφέρεσαι. Σε κάθε πρόγραμμα που γίνετε μεταγλώττιση θα υπάρχει τουλάχιστον μια τέτοια βιβλιοθήκη. Σε ένα τυπικό πρόγραμμα σε C είναι το κομμάτι που μιλάει το πρόγραμμα με το λειτουργικό, ανοίγει το τερματικό κλπ. Είναι ένα απλό copy για να κάνω όποιο πρόγραμμα μεταγλωττίσεις στην μηχανή σου να κάνει οτιδήποτε άλλο θέλω.
Μπορείς να είσαι υποψιασμένος και να το κοιτάξεις, αλλά επίσης σου έχω αλλάξει τον Linker ώστε να βάλει επιπλέον κώδικα. Μπορείς όμως να κοιτάξεις αν αυτός έχει αλλάξει, αλλά έχω τροποποιήσει επίσης το λειτουργικό (ή ακόμα και τον επεξεργαστή) ώστε να σου δίνει τα σωστά νούμερα. Και αυτό που λέει η δημοσίευση του 1984, κάτι που ισχύει ακόμα, είναι πως δεν μπορείς να κάνεις απολύτως τίποτα που να σε κάνει 100.00% σίγουρο ότι τα πάντα είναι εντάξει.
Γνωριζόμαστε; χεχεχε!
Είναι αλήθεια πως το νήμα έχει παρεκτραπεί, αλλά έτσι συνήθως γίνετε και στις συζητήσεις στο καφενείο. Σκέφτηκα να διαχωρίσω τα νήματα, αλλά έχουν μπλεχτεί αρκετά μεταξύ τους. Ήδη μετέφερα κάποια κομμάτια σε ένα άλλο νήμα.
Αλλά η συζήτηση είναι καλή και όλοι μαθαίνουμε πράγματα που δεν ξέραμε, οπότε δεν πειράζει. Ίσως μετά κάποιος άλλος να τα διαχωρίσει
3 «Μου αρέσει»
Ναι, εξήγησα τι γίνεται σε απάντηση που μεταφέρθηκε σε άλλο νήμα Το ίδιο το flatpak του viber δεν είναι τεράστιο, είναι οι εξαρτήσεις του. Αν εγκαθιστάς μόνο αυτό, τότε φέρνεις άλλη μια διανομή σχεδόν μαζί του. Αν χρησιμοποιείς περισσότερα, οι εξαρτήσεις “μοιράζονται”.
Το flatpak με ID: com.viber.Viber είναι 35.1 ΜΒ και έχει σαν runtime το org.freedesktop.Platform/x86_64/19.08 που είναι… 694,8 MB.
2 «Μου αρέσει»
Bγήκαν οι πρώτες επίσημες οδηγίες για τον πώς μπορείς να εγκαταστήσεις το snapd και το Chromium.
https://linuxmint-user-guide.readthedocs.io/en/latest/index.html
Είναι κομμάτια ενός καινούργιου βιβλίου που ετοιμάζει η ομάδα του Mint.
Μου φαίνεται λίγο κοροϊδία όλο αυτό. Βγάζουν ανακοινώσεις κατά των snaps, ακολουθούν με τεχνική υλοποίηση μπλοκαρίσματός τους, συνεχίζουν με έναν “οδηγό” όπου αναφέρουν ξανά την αρνητική κριτική αλλά στο τέλος “εντάξει, εμείς είμαστε αντίθετοι αλλά αν θέλετε, ορίστε πώς να έχετε snaps για να μη φύγετε από τη διανομή μας”.
Γνωρίζοντας την πορεία του Mint ανά τα χρόνια και τις κατά καιρούς αντιθέσεις του με το Ubuntu και την Canonical, θεωρώ ότι θα έπρεπε εδώ και καιρό να έχουν ξεκινήσει προσπάθειες αυτονόμησης. Όχι πειραματικό rebase σε Debian και χαζά.
Έχεις άποψη και ενστάσεις κύριε; Put your money where your mouth is, κάνε όλη τη δουλειά μόνος σου και φτιάξε το σύστημα ακριβώς όπως το θέλεις. Αλλιώς θα ακολουθείς πάντα τις αποφάσεις άλλων, θα κάνεις κοπτοραπτική όπου διαφωνείς και θα καταλήγεις να βγάζεις “οδηγούς” που λένε στους χρήστες σου πως να κάνουν αυτά με τα οποία είσαι αντίθετος (και τότε ποια η σημασία της αντίθεσής σου;)
Για τα πρακτικά, λογισμικό που
we can’t audit, which contains software nobody can patch. If we can’t fix or modify software[…]
όπως αναφέρουν, δεν είναι “open source or not” αλλά εξ ορισμού δε μπορεί να λέγεται open source. Ίσως είναι “open core” ή “source-available” αλλά open source σίγουρα δεν είναι.
2 «Μου αρέσει»
Εμένα πάλι δεν μου φαίνεται καθόλου κοροϊδία… Οι άνθρωποι διαφωνούν (και πολύ καλά κάνουν, κατά τη γνώμη μου), αλλά δεν θέλουν ντε και σώνει να επιβάλλουν τη γνώμη τους. To default το κάνουν όπως θέλουν αυτοί αλλά “επιτρέπουν” την εγκατάσταση snap και μάλιστα εξηγούν το πώς.
Διαφωνώ επίσης με τη λογική “Έχεις άποψη και ενστάσεις κύριε; … κάνε όλη τη δουλειά μόνος σου και φτιάξε το σύστημα ακριβώς όπως το θέλεις”. Ο καθένας έχει το δικαίωμα της γνώμης του (προφανώς) επί παντώς επιστητού. Η ομάδα του mint προφανώς δεν έχει τους ανθρώπινους πόρους να συντηρεί εξ ολοκλήρου ένα distro, μια χαρά (και με το παραπάνω) τα καταφέρνουν να “γυαλίζουν” μία καλή βάση και να εξελίσσουν ένα DE.
Αν και οφείλω να ομολογήσω ότι θα προτιμούσα χίλιες φορές να βασίζονταν όχι σε ubuntu αλλά σε debian (και μάλιστα το testing, όπως ήταν παλιότερα το LMDE). ;-)
3 «Μου αρέσει»
Δεν είναι επιβολή γνώμης το να δημιουργείς κάτι σύμφωνα με ορισμένες αρχές, αξίες, κανόνες κλπ. (αν έχεις), όπως δεν ήταν επιβολή γνώμης η μη χρήση του Unity, η δημιουργία του Cinnamon και των xapps και άλλα τόσα.
Αν όμως «λυγίζεις» τις αρχές σου κάθε τόσο και αναιρείς στην πράξη αυτά που λες, τότε δε σημαίνουν απολύτως τίποτα. Όπως δε σημαίνει απολύτως τίποτα το να κάνεις φασαρία για μια απόφαση της μητρικής διανομής, να τη μπλοκάρεις στο δικό σου παράγωγο και κατόπιν, βλέποντας τις αντιδράσεις ίσως, ουσιαστικά να δίνεις μόνος σου το workaround για το μπλοκάρισμα που έκανες. Είναι, επιεικώς, αστείο.
Θεωρώ ότι θα ήταν πιο έντιμο το να εκφράσουν την αντίθεσή τους χωρίς φασαρία, να ενημερώσουν τους χρήστες τους για τα snaps ουδέτερα, χωρίς να τα χρωματίζουν αρνητικά, και να τους δώσουν την επιλογή by default. Αυτό το «φωνάζω ότι το Χ είναι κακό αλλά σε αφήνω να το χρησιμοποιήσεις» το κάνουν και άλλες διανομές και δεν είναι ωραίο.
Φυσικά και η ομάδα του Mint έχει τους ανθρώπινους πόρους για να συντηρήσει εξ ολοκλήρου μια διανομή. Υπάρχουν άλλες, αυτόνομες, διανομές με πολύ μικρότερες ομάδες και τα καταφέρνουν μια χαρά. Στη συγκεκριμένη περίπτωση, δε θα χρειαζόταν καν μια διανομή from scratch. Μπορούν να παίρνουν τα πακέτα του Debian και να τα κάνουν rebuild σύμφωνα με τα δικά τους κριτήρια, όπως ακριβώς κάνει το Ubuntu. Αλλά δεν το κάνουν, παίρνουν τα πακέτα μιας διανομής που γνωρίζουν ότι έχει άλλους στόχους, άλλη πρακτική και άλλη κατεύθυνση και κάθε τόσο φωνάζουν για αυτό. Είναι κρίμα γιατί έτσι χαλάνε την εικόνα τους.
2 «Μου αρέσει»
H γνώμη σου είναι δικιά σου και τη σέβομαι απόλυτα όσο κι αν διαφωνώ μαζί της.
Δεν μου αρέσουν όμως οι λέξεις “έντιμο” και “δεν είναι ωραίο” που χρησιμοποιείς. Δεν βλέπω καμία απολύτως ατιμία εγώ - απεναντίας θα έλεγα ότι είναι ευθείς και ντόμπροι και δεν κρύβονται πίσω από το δάχτυλό τους. Νισάφι με τις “ευγένειες” και την “κορρεκτίλα” - λέωγώ!
Σε ό,τι αφορά στο “«φωνάζω ότι το Χ είναι κακό αλλά σε αφήνω να το χρησιμοποιήσεις» το κάνουν και άλλες διανομές και δεν είναι ωραίο”, πάλι θα διαφωνήσω κάθετα και οριζόντια! Οι διανομές δεν είναι παιδονόμοι, ειδικά όταν ξέρουμε ότι ορισμένα πράγματα ΔΕΝ μπορούν να τα επιβάλουν ντε και σώνει (πώς θα μπορούσε το mint να αποκλείσει 100% τη δυνατότητα εγκατάστασης snapd στο mint??).
Απλά πράματα: οι άνθρωποι διαφωνούν με την πρακτική του ubuntu, το λένε και το εξηγούν ευθαρσώς και αναλυτικά, το σχετικό θέμα το υλοποιούν διαφορετικά στη δική τους διανομή ενώ δίνουν τη δυνατότητα (και εξηγούν το πώς) σε όποιον θέλει να το κάνει the ubuntu way. Ντόμπρο, ευθύ και πολύ πολύ ωραίο.
Και στην τελική, οποιανού δεν του αρέσει, μπορεί να πάρει τα κουβαδάκια του και να πάει στη δίπλα παραλία. Μην ντύνουμε όμως τις διαφωνίες μας με εντιμότητες και ατιμίες, ειδικά όταν δεν υπάρχουν.
By the way, το mint είναι θρυλικό για το πόσο polished είναι. Αντιλαμβάνομαι ότι το βάρος τους είναι ακριβώς εκεί και γι αυτό το λόγο παίρνουν μία έτοιμη βάση, εξοικονομώντας πόρους. Προφανώς και θα μπορούσαν να συντηρήσουν μία διανομή - οι προτεραιότητές τους όμως αντιλαμβάνομαι ότι είναι άλλες.
Τα δύο μου σέντσια… 
3 «Μου αρέσει»