Προφανώς και θα κοιτάξουν το συμφέρον τους το παραπάνω τρίο, σαν εταιρείες που είναι 
δεν νομίζω να διαφώνησε κάνεις σε αυτό, και μακάρι να μπούνε και άλλοι παίχτες να φέρουν και άλλα πράγματα στο λινουξ άμεσα η έμμεσα…Δεν νομίζω να χάλαγε κανέναν κάποια στιγμή να έβγαζε και η Adobe τις σουίτες της στο λινουξ η Microsoft το office κτλ, όπως δεν χάλασε κανέναν που έβγαλε η Valve το Steam
(για τα άλλα τα σεντόνια, τι είναι το λινουξ κτλ δεν μπορώ να κάτσω να απαντάω, έχουν χιλιο υποθει)
Tα snaps δεν δουλεύουν όντως χωρίς systemd, σε αντίθεση με τα flatpaks και ότι είναι σε appimage. To παλιότερο 0install δεν το ξέρει κανείς ε; 
Νομίζω αυτό που εμποδίζει την λειτουργία τους είναι ότι καλούν κατευθείαν το systemctl, ή τουλάχιστον αυτό είχα δει σαν λόγο πριν αρκετό καιρό…
Σε αρκετές διανομές τα reproducible builds είναι ο κανόνας τώρα, όχι στο μέλλον ;)
Δε θα το έλεγα. Ναι μεν ορισμένες έχουν προχωρήσει αρκετά στην υλοποίηση, δε γνωρίζω, δε, ούτε μία η οποία να περιέχει στα επίσημα αποθετήριά της 100% reproducible πακέτα και να διαθέτει το αντίστοιχο .iso.
Βέβαια, δε διαθέτω συμπαντική γνώση. Αλλά το «αρκετές» είναι too much για την ώρα, θεωρώ.
Το “αρκετές” προφανώς δεν είναι αρκετά 
ακριβές. Δεν χρειάζεται να αφορά το 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. Αν συγκλίνουν οι διανομές, ίσως να συμβεί.
Όταν είχε ξεκινήσει το Debian σε κάποιο Debconf είχε μια αναλυτική παρουσίαση για τα προβλήματα και πως μπορείς να προετοιμάσεις ένα πακέτο. Πρέπει να κάνεις κάποιες αλλαγές στo autoconf, makefile, cmakelists ή οτιδήποτε άλλο χρησιμοποιεί κάθε έργο.
Οι αλλαγές αυτές συνήθως είναι απλές. Για παράδειγμα θα πρέπει να αναφέρεις τις εξαρτήσεις αναλυτικά ώστε να γίνει το linking με γνωστή σειρά αντί να χρησιμοποιείς κάτι σαν ‘*.c’. Αλλαγές που εύκολα περνάνε στον αρχικό πηγαίο κώδικα. Οπότε μια φορά θα πρέπει να γίνει αυτό και επωφελούνται όλες οι διανομές. Το building environment είναι σημαντικό και κάθε διανομή θα βγάλει διαφορετικό πακέτο μιας και οι βιβλιοθήκες δεν θα είναι ίδιες, αλλά είναι εύκολο. Το infrastructure όμως (μηχανές και άνθρωποι) δεν είναι το ίδιο εύκολο να στηθεί, ειδικά για ποιο μικρές διανομές.
Δυστυχώς έχω χάσει το βίντεο της παρουσίασης και ξεχνάω τις λεπτομέριες.
Εμένα μου παίζει σωστά με το deb.
Επίσης το flatpak είναι παλαιότερο του deb.
Τέλος:
Σοβαρά; 2,1 GB για viber??? Σόρι δεν θα πάρω. Δεν είναι ακόμα “τσάμπα” ο χώρος στον SSD.
Το 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, χαίρομαι που σε ξανά διαβάζω!
Ας υποθέσουμε πως κάποιος επεμβαίνει στον υπολογιστή του Patrick Volkerding και αλλάζει μια στατική βιβλιοθήκη. Η αλλάζει τον compiler του. Τότε θα παράγεις πακέτα που θα έχουν ενδιαφέρουσες άλλες παράλληλες λειτουργίες.
Η εμπιστοσύνη στον Patrick Volkerding δεν αρκεί.
Να κάνω και μια μικρή διόρθωση. Ιστορικά το UNIX το πρόβλημα το είχε δει από πολύ νωρίς και είχε επισημάνει το πρόβλημα. Απλά δεν μπορούσε να βρει μια αξιόπιστη λύση. Σήμερα βρέθηκε μια σχετικά ικανοποιητική λύση στο πρόβλημα με τα reproducible builds. Και λέω μερική γιατί πλέον μικρή εμπιστοσύνη έχω στον ίδιο τον επεξεργαστή. Αλλά μπορείς να κάνεις ένα reproducible build με cross compile σε μια άλλη αρχιτεκτονική όπως πχ να φτιάξεις τα πακέτα σε ένα ARM.
Παραθέτω ένα πολύ γνωστό paper του ίδιου του Ken Thomson απο το μακρινό 1984.
Αξίζει να διαβαστεί. Το είχε γράψει όταν είχε βραβευτεί από την ACM (Κάτι ισοδύναμο με το βραβείο Nobel για την πληροφορική). Είμαι σχεδόν σίγουρος πως έχω διαβάσει παλαιότερο paper του ίδιου (ή μήπως ήταν του Niklaus Wirth ; )
Αυτό που εννοώ με το “αναπαραγώγιμο” είναι ότι υπάρχει μια γνωστή συνταγή που μπορεί να χρησιμοποιηθεί ξανά. Η πρόθεση είναι ότι κάθε φορά που δημιουργείτε ένα πακέτο από ένα σενάριο, θα έχει ο χρήστης το ίδιο αποτέλεσμα - αλλά δεν πρόκειται απαραίτητα να συμβεί: η έξοδος του πακέτου μπορεί να μην είναι η ίδια αν το δημιουργήσε σε σχέση με το όταν χτίστηκε από τον Patrick.
Ο λόγος είναι ότι το περιβάλλον - το λειτουργικό σύστημα - αλλάζει (αναβαθμίσεις πακέτων, καταργήσεις, προσθήκες) και αν δεν δημιουργήσει όλα τα πακέτα με την ίδια ακριβώς σειρά όπως έκανε ο Πάτρικ, τότε το πακέτο του χρήστη μπορεί ή όχι να συνδέεται με μια βιβλιοθήκη - ανάλογα με το εάν είχε εγκατασταθεί ή όχι εκείνη τη στιγμή, ή ίσως κάποια τεκμηρίωση μπορεί να μην κατασκευαστεί επειδή το εργαλείο για τη δημιουργία δεν μπορούσε να καταλάβει μια νεότερη μορφή τεκμηρίωσης.
Για μένα, καμία υπόθεση δεν μπορεί να λάβει στίγμα εμπιστοσύνης όπως και το ότι δεν άλλαξε κάτι το Unix ιστορικά απλά επισήμανε αυτό που δεν είναι αλλαγή. Όταν μάλλον η εμπιστοσύνη δεν χωράει σε μέτρα και σταθμά. Δεν υπάρχει για μένα τουλάχιστον λίγη ή μετρίως έως αρκετή εμπιστοσύνη!
Νομίζω, και χωρίς καμία υπόνοια υποτίμησης, πως θέλεις αρκετό διάβασμα τόσο στο θεωρητικό όσο και στο πρακτικό κομμάτι. Για παράδειγμα μίλησα για στατικές βιβλιοθήκες, κομμάτια κώδικα που αποτελούν τμήματα του προγράμματος και δεν έχουν κάποια σχέση με τις δυναμικές βιβλιοθήκες στις οποίες αναφέρεσαι. Σε κάθε πρόγραμμα που γίνετε μεταγλώττιση θα υπάρχει τουλάχιστον μια τέτοια βιβλιοθήκη. Σε ένα τυπικό πρόγραμμα σε C είναι το κομμάτι που μιλάει το πρόγραμμα με το λειτουργικό, ανοίγει το τερματικό κλπ. Είναι ένα απλό copy για να κάνω όποιο πρόγραμμα μεταγλωττίσεις στην μηχανή σου να κάνει οτιδήποτε άλλο θέλω.
Μπορείς να είσαι υποψιασμένος και να το κοιτάξεις, αλλά επίσης σου έχω αλλάξει τον Linker ώστε να βάλει επιπλέον κώδικα. Μπορείς όμως να κοιτάξεις αν αυτός έχει αλλάξει, αλλά έχω τροποποιήσει επίσης το λειτουργικό (ή ακόμα και τον επεξεργαστή) ώστε να σου δίνει τα σωστά νούμερα. Και αυτό που λέει η δημοσίευση του 1984, κάτι που ισχύει ακόμα, είναι πως δεν μπορείς να κάνεις απολύτως τίποτα που να σε κάνει 100.00% σίγουρο ότι τα πάντα είναι εντάξει.
Γνωριζόμαστε; χεχεχε!
Είναι αλήθεια πως το νήμα έχει παρεκτραπεί, αλλά έτσι συνήθως γίνετε και στις συζητήσεις στο καφενείο. Σκέφτηκα να διαχωρίσω τα νήματα, αλλά έχουν μπλεχτεί αρκετά μεταξύ τους. Ήδη μετέφερα κάποια κομμάτια σε ένα άλλο νήμα.
Αλλά η συζήτηση είναι καλή και όλοι μαθαίνουμε πράγματα που δεν ξέραμε, οπότε δεν πειράζει. Ίσως μετά κάποιος άλλος να τα διαχωρίσει
Ναι, εξήγησα τι γίνεται σε απάντηση που μεταφέρθηκε σε άλλο νήμα Το ίδιο το flatpak του viber δεν είναι τεράστιο, είναι οι εξαρτήσεις του. Αν εγκαθιστάς μόνο αυτό, τότε φέρνεις άλλη μια διανομή σχεδόν μαζί του. Αν χρησιμοποιείς περισσότερα, οι εξαρτήσεις “μοιράζονται”.
Το flatpak με ID: com.viber.Viber είναι 35.1 ΜΒ και έχει σαν runtime το org.freedesktop.Platform/x86_64/19.08 που είναι… 694,8 MB.
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 σίγουρα δεν είναι.
