BETA

Μια (ακόμα) νύξη για την ασφάλεια στο Linux

Εικόνα Soulrain

Ένα από τα πρώτα πράγματα για τα οποία γίνεται λόγος όταν αναφερόμαστε στις διανομές Linux, είναι το συγκριτικά υψηλότερο επίπεδο ασφάλειας που αυτές παρέχουν σε σχέση με κάποια άλλα λειτουργικά συστήματα. Ασφάλεια η οποία βασίζεται κατά κύριο λόγο στην τεχνική δόμηση του λειτουργικού και σε δεύτερο χρόνο στην όλη κουλτούρα ορθής χρήσης που καλλιεργείται από χρήστες και προγραμματιστές.

Δυστυχώς όμως, αρκετές φορές παρατηρείται το φαινόμενο η ύπαρξη της ασφάλειας να θεωρείται δεδομένο γεγονός και καθολικά ισχύον. Αυτό έχει ως αποτέλεσμα οι μεν προγραμματιστές να ακολουθούν ενίοτε κάκιστες πρακτικές, οι δε χρήστες να βρίσκονται εκτεθειμένοι σε πραγματικούς κινδύνους, που όμως αγνοούν την ύπαρξή τους. Ως γνωστόν, ο «μέσος χρήστης» δεν ασχολείται ιδιαίτερα και δε φροντίζει να ενημερώνεται αλλά κατ’ ουσίαν εμπιστεύεται τυφλά τους προγραμματιστές της διανομής που προτιμά, οι οποίοι με τη σειρά τους μπορεί να εντάσσονται στην παραπάνω κατηγορία.

Κι εδώ παρουσιάζεται ένα χαρακτηριστικό το οποίο είναι αστείο και συνάμα τραγικό. Οι διανομές Linux αποτελούνται από ανοιχτό κώδικα. Αυτό σημαίνει ότι είτε το επιδιώκουν ενεργά είτε όχι και τόσο, αργά ή γρήγορα τα πάντα έρχονται στο φως. Άρα, ακόμα κι αν σε κάποιο τομέα ακολουθείται κακή πρακτική ή υπάρχει απλά ανθρώπινη αμέλεια, αυτό δε θα παραμείνει κρυφό αλλά θα αναφερθεί και θα αναλυθεί σε βάθος. Δεν εννοούμε φυσικά τις ευπάθειες που εμφανίζονται κατά καιρούς, με ευρηματικές ονομασίες και πηχυαίους τίτλους σε χώρους επιεικώς άσχετους με οτιδήποτε έχει να κάνει με το Linux και την ανάπτυξή του. Εννοούμε την απλή διαδικασία όπου φιλικός προγραμματιστής Α, με καλές προθέσεις, αναφέρει με λεπτομέρειες και στοιχεία ότι ο προγραμματιστής Β ή η διανομή Γ ακολουθούν κακή πρακτική.

Θα περίμενε κάποιος, εφόσον εντοπίζεται το σφάλμα, να διορθώνεται άμεσα (σχετικά πάντα). Εντούτοις, αυτό δε συμβαίνει. Έχει αναφερθεί πολλάκις ότι δε συμβαίνει. Έχει αναφερθεί επίσης ότι έχουν υπάρξει/εξακολουθούν να υπάρχουν περιπτώσεις όπου το Linux -σπανίως ο πυρήνας και πολύ συχνότερα οι διανομές- είναι εξαιρετικά αργοκίνητο στην αποκατάσταση ευπαθειών. Έχει αναφερθεί ακόμα ότι τη μεγαλύτερη ροπή προς την εμφάνιση κακών πρακτικών ή την καθυστέρηση στην επανόρθωση της ασφάλειας την παρουσιάζουν «μικρές» διανομές που έχουν μικρό αριθμό συνεισφερόντων αλλά και ορισμένες από τις «μεγάλες» που προσανατολίζονται στη «φιλικότητα», όμως την επιτυγχάνουν(;) με προβληματικό τρόπο. Για τις πρώτες δε μπορούμε να πούμε και πολλά. Τα ονόματα των δεύτερων όμως είναι σχεδόν πάντα τα ίδια σε κάθε σχετική αναφορά αλλά μάλλον αγρόν αγοράζουν και το γενικότερο φαινόμενο δεν παύει να εμφανίζεται.

Πάμε λοιπόν να δούμε μια τέτοια αναφορά. Να τονιστεί εδώ ότι τα παρακάτω δεν αποτελούν προσωπική άποψη του γράφοντος αλλά είναι πραγματικά στοιχεία, όπως αυτά παρουσιάστηκαν. Αν τυχόν κάποιος γνωρίζει και μπορεί να επιβεβαιώσει ότι μία ή περισσότερες από τις αναφορές που θα ακολουθήσουν δεν έχει βάση, καλό θα ήταν να το αναφέρει. Μην ξεχνάτε ότι ουδείς αλάνθαστος.

Στα πλαίσια του φετινού GUADEC (GNOME Users And Developers European Conference/Ευρωπαϊκή Διάσκεψη Χρηστών Και Προγραμματιστών GNOME) υπήρξε μια μίνι ομιλία για το WebKit και τα προβλήματά του. Ομιλητής ήταν ο Michael Catanzaro, ένας από τους προγραμματιστές του GNOME που είναι επιφορτισμένοι με την ανάπτυξη του WebKitGTK+ και ο οποίος ήδη από το Φεβρουάριο του τρέχοντος έτους είχε προειδοποιήσει για την ολιγωρία των διανομών.

Τι είναι όμως το WebKit και γιατί είναι σημαντικό; Χωρίς να μπλέκουμε με τεχνικές ορολογίες και τα σχετικά, το WebKit είναι ένα συστατικό που βρίσκεται στην καρδιά πολλών προγραμμάτων περιήγησης ιστού, τόσο κλειστού όσο και ανοιχτού κώδικα. Πολύ απλοποιημένα, είναι αυτό το «κάτι» που είναι υπεύθυνο για το πώς θα εμφανίζεται το περιεχόμενο μιας ιστοσελίδας στην οθόνη μας. Είναι φυσικά έργο ανοιχτού κώδικα, με πλήθος συνεισφερόντων. Μαμά του είναι η «μισητή» Apple, η οποία παραμένει στις πρώτες θέσεις συνεισφοράς στην ανάπτυξή του, και δημιουργήθηκε από το forking του αντίστοιχου συστατικού KHTML που χρησιμοποιούσε το KDE (τα παλιά χρόνια). Όπως θα δούμε όμως, δεν αφορά μόνο τους περιηγητές αλλά βρίσκεται και σε πολλά άλλα προγράμματα τα οποία έχουν κάποια λειτουργία παρουσίασης διαδικτυακού περιεχομένου, γεγονός που του προσδίδει αυξημένη σημαντικότητα.

Προσαρμογές του απαντώνται από το macOS και το iOS μέχρι τα Windows, εμείς όμως θα σταθούμε στα παρακλάδια που χρησιμοποιούνται στο Linux και ιδιαίτερα στο WebKitGTK+. Για να μην υπάρξει παρεξήγηση, να αναφέρουμε ότι όλες οι προσαρμογές του WebKit προκύπτουν από το ίδιο βασικό «δέντρο», αλλά η κάθε ομάδα επιλέγει ανεξάρτητα πού και πότε θα κάνει διακλάδωση του κώδικα (ο όρος είναι branching, μην το μπερδέψετε με το forking). Δεν ελέγχει δηλαδή κάθε πτυχή της ανάπτυξής του η Apple, όπως μπορεί λανθασμένα να υποθέσει κάποιος και δεν υπάρχει «κλείδωμα».

Και αφού έγιναν οι απαραίτητες συστάσεις, ας προχωρήσουμε στα περαιτέρω. Πριν από καναδυό χρόνια, ανακαλύφθηκε πληθώρα ευπαθειών στο WebKit. Δεν ήταν βέβαια όλες υψίστης σημασίας και κρισιμότητας, ήταν όμως πάρα πολλές (κατά πολύ περισσότερες από 100). Ο αριθμός φαντάζει τρομακτικός, ιδιαίτερα όταν μιλάμε για έργο ανοιχτού κώδικα και μάλιστα τόσο σημαντικό. Η ιστορία όμως τελικά δεν είχε δράκο, οι ευπάθειες επιδιορθώθηκαν τόσο καλά που το WebKit πέρασε σε νέο API (WebKit2), η προειδοποίηση που αναφέραμε δεν πέρασε απαρατήρητη και πλέον όλα βαίνουν καλώς.

Το πιστέψατε; Κακώς. Αυτό που συνέβη ήταν ότι οι περισσότερες διανομές εξακολούθησαν να σφυρίζουν αδιάφορα. Κι έτσι φτάσαμε στα μέσα Αυγούστου, μισό χρόνο μετά από εκείνη την ανάρτηση, και το GUADEC, όπου ο άνωθεν προγραμματιστής αναγκάστηκε να επαναλάβει τα ίδια πράγματα ακριβώς.

Παρακάτω μπορείτε να παρακολουθήσετε τη σχετική ομιλία. Δεν υπάρχουν υπότιτλοι αλλά μη σκάτε γιατί θα τα πούμε στη συνέχεια. Διαβάστε εδώ την περίληψη του βίντεο, για να μπείτε στο κλίμα:

Οι μεγάλες διανομές Linux έχουν ένα πρόβλημα με την ασφάλεια του WebKit. Ενώ οι μεγάλοι περιηγητές προωθούν αυτόματες ενημερώσεις ασφάλειας σε τακτική βάση ούτως ώστε οι χρήστες να μη χρειάζεται να ανησυχούν για τις ενημερώσεις, οι χρήστες Linux εξαρτώνται από τις διανομές τους για τη διάθεση των ενημερώσεων. Αρκετά περισσότερες από 100 ευπάθειες που θα μπορούσαν να επιτρέψουν την απομακρυσμένη εκτέλεση κώδικα επιδιορθώθηκαν στο WebKit τον περασμένο χρόνο, κι έτσι το να φτάσουν οι ενημερώσεις στους χρήστες είναι κρίσιμο. Αυτή η ομιλία εξετάζει την αποσύνδεση μεταξύ του πώς το έργο WebKit χειρίζεται τα θέματα ασφάλειας στο upstream και του πώς διαφορετικές μεγάλες διανομές χειρίζονται (ή δε χειρίζονται) τα θέματα ασφάλειας, δείχνει ότι τα προβλήματα ασφάλειας του WebKit έχουν εκτεταμένες επιπτώσεις ακόμα και σε χρήστες που δε χρησιμοποιούν έναν περιηγητή βασισμένο στο WebKit, και κάνει λόγο για τις επιπτώσεις στην ασφάλεια από το διαχωρισμό μεταξύ του αρχικού WebKit API και του WebKit2.

 

Για να είναι το θέμα πιο εύκολο στην κατανόηση από όλους, δε θα αναφέρω όλα όσα ειπώθηκαν αλλά θα σταθώ περισσότερο στα περιεχόμενα των καρτών που παρουσιάστηκαν. Επαναλαμβάνω ότι δε θα εισάγω πουθενά τις προσωπικές μου απόψεις, γιατί ο σκοπός δεν είναι να προωθήσω κάποια συγκεκριμένη διανομή ή να ψέξω κάποια άλλη -όπως συμβαίνει κατά κόρον στο Linux- αλλά η ενημέρωση των αναγνωστών.

Και ξεκινάμε:

Ασφάλεια περιηγητή σε 45 δευτερόλεπτα

  ● Εδώ αναφέρονται κάποια είδη ευπαθειών που μπορεί να παρουσιάσουν οι περιηγητές, το τελικό αποτέλεσμα που μπορεί να έχει η εκμετάλλευσή τους (απόκτηση ελέγχου του συστήματος από τον επιτιθέμενο) αλλά και τρόποι μετρίασης τους με τη χρήση sandbox ή με προγραμματισμό σε «ασφαλή» γλώσσα όπως η Rust (σ.σ. σε περίπτωση που δεν το έχετε παρατηρήσει, όταν πρόκειται για την ασφάλεια, χρησιμοποιούνται πολύ συχνά οι λέξεις μετριάζω/μετρίαση -mitigate/mitigation στα Αγγλικά. Αυτό γιατί θεωρείται δεδομένο ότι δε μπορεί να υπάρξει απόλυτη ασφάλεια ποτέ και πουθενά και ότι αναπόφευκτα, κάποια στιγμή θα βρεθούμε εκτεθειμένοι. Οπότε γίνεται λόγος για μετρίαση/ελάττωση των συνεπειών και όχι τόσο για πρόληψη).

Προσαρμογές του WebKit

  ● Αυτή είναι μια λίστα με τις διαθέσιμες προσαρμογές του WebKit για διάφορα λειτουργικά. Να σημειωθεί ότι το Chromium πλέον χρησιμοποιεί fork (διακλάδωση του αρχικού κώδικα όπου προστίθενται ή αφαιρούνται στοιχεία σε ανεξάρτητη ανάπτυξη) του WebKit, ενώ το QtWebKit υπάρχει σε περιηγητές και άλλες εφαρμογές που βασίζονται στο Qt, χρησιμοποιούνταν παλιότερα και από το τέως KDE/νυν Plasma αλλά όχι πια γιατί έχουν περάσει και εκείνοι σε fork του, και πλέον η ανάπτυξή του έχει σταματήσει. Σημαντικότατο επίσης: όπως αναφέρεται, οι μόνες προσαρμογές του WebKit που είναι (μέχρι τη χρονική στιγμή της συγκεκριμένης ομιλίας) πλήρως επιδιορθωμένες στο μέγιστο δυνατό βαθμό, είναι εκείνες που χρησιμοποιούνται από τα λειτουργικά της Apple. Τροφή για σκέψη.

WebKitGTK+

  ● Εδώ βλέπουμε πού χρησιμοποιείται το WebKitGTK+, δηλαδή σε οτιδήποτε περιέχει το WebKit αλλά δεν είναι βασισμένο στο Qt. Βλέπουμε επίσης και κάποιες ενδεικτικές εφαρμογές. Βλέπουμε τέλος ότι για όλα αυτά, μέχρι πρόσφατα δεν εκδίδονταν συμβουλευτικά ασφάλειας (όπως ας πούμε λίστες που περιέχουν τους κωδικούς αριθμούς CVE -Common Vulnerabilities and Exposures/Κοινές Ευπάθειες και Εκθέσεις) από το έργο WebKit(GTK+). Αυτό το τελευταίο σημαίνει ότι, αν παρουσιαζόταν κάποια ευπάθεια, δεν υπήρχε σαφής και αποτελεσματικός τρόπος για να ενημερωθούν οι διανομές ώστε να πράξουν τα δέοντα. Δεν ισχύει όμως πια γιατί δημοσιεύονται κανονικά οι σχετικές λίστες.

WebKit2: Το Μεγάλο Σπάσιμο του API

  ● Εδώ μαθαίνουμε ότι ο λόγος που άλλαξε το API ήταν διότι απαιτούνταν τόσες πολλές αλλαγές και επιδιορθώσεις που ουσιαστικά επρόκειτο για νέο δημιούργημα.

  ● Ποιες εκδόσεις του WebKit(GTK+) θεωρούνται ασφαλείς; Εδώ υπάρχει ένα μπέρδεμα. Όσο το δυνατόν πιο ασφαλές είναι το WebKit2 και μάλιστα δόθηκε προθεσμία σχεδόν δύο χρόνων στις διανομές για να μεταβούν σε αυτό. Δυστυχώς όμως, οι περισσότερες από αυτές δεν το έχουν πράξει μέχρι και σήμερα αλλά εξακολουθούν να διατηρούν το προβληματικό WebKit1 για λόγους συμβατότητας. Μάλιστα, ανάγκασαν τους προγραμματιστές του να κάνουν backport (προσαρμογή από μεταγενέστερη έκδοση σε προγενέστερη) κάποιες από τις επιδιορθώσεις ενώ η ανάπτυξη του είχε ήδη σταματήσει. Όλο αυτό πρακτικά σημαίνει ότι η διανομή σας χρησιμοποιεί ακόμα το επισφαλές WebKit1, απλά με λίγα «μανταρίσματα». Για να ελέγξετε, οι «μανταρισμένες» -αλλά όχι εντελώς ασφαλείς- εκδόσεις του WebKit1 έχουν αριθμό έκδοσης μεγαλύτερο του 2.4.0 (παρατηρήστε όμως στην κάρτα ότι ακόμα και η έκδοση 2.4.9 έχει προβλήματα). Προσοχή: το αρχικό 2 στον αριθμό έκδοσης δε δηλώνει το ασφαλές WebKit2 αλλά το πακέτο συμβατότητας του WebKit1. Το WebKit2 θα πρέπει να δηλώνεται με κάποιον άλλο τρόπο, π.χ. webkit2gtk, και συνήθως έχει αριθμό έκδοσης ίσο ή μεγαλύτερο του 2.6.

Προτεινόμενες διανομές για το WebKit

  ● Τις βλέπετε και τα συμπεράσματα δικά σας. Όπως λέει ο Michael, κάθε διανομή που δεν αναφέρεται σε αυτή την κάρτα, δεν τα πάει και τόσο καλά στο θέμα.

openSUSE

  ● Το Tumbleweed είναι εντάξει, όχι όμως και το Leap. Αναφέρεται επίσης ότι, ενώ οι περισσότερες διανομές δεν ενημερώνουν καθόλου το WebKit, το openSUSE το έπραξε για το Leap αλλά μόνο μέχρι κάποια «μανταρισμένη» έκδοση και μετά τα παράτησε.

RHEL, SLED

  ● Κοινώς, οι εταιρικές εκδόσεις της Red Hat και της SUSE. Εταιρικές, άρα ακόμα πιο ασφαλείς, σωστά; Όχι. Ιδιαίτερα εξαιτίας του τρόπου ανάπτυξής τους, δε διαθέτουν αποτελεσματική μέθοδο ώστε να λαμβάνουν τις σχετικές ενημερώσεις εν ευθέτω χρόνω, ακόμα κι αν το ήθελαν. Κάνουν το καλύτερο δυνατό που μπορούν από πλευράς τους αλλά δεν επαρκεί (ο αξιότιμος κύριος προγραμματιστής το λέει, όχι εγώ).

Ubuntu

  ● Μόνο η υπό ανάπτυξη έκδοση 16.10 είναι πλήρως ενημερωμένη για το WebKit. Όπως αναφέρεται, γνωρίζουν για τα προβλήματα και τις επιδιορθώσεις τους και μάλιστα έχουν «ταγκάρει» την πιο πρόσφατη έκδοση του WebKit2 για ενσωμάτωση από το 16.10 και πέρα, όμως δεν έχουν κάνει διαθέσιμες τις ενημερώσεις και στις ήδη ενεργές εκδόσεις, μεταξύ των οποίων είναι και οι LTS.

Debian

  ● Το απόλυτο μηδέν στις ενημερώσεις ασφάλειας (του WebKit) για τη Stable έκδοση. Ακόμα και τα σχετικά backports για την έκδοση αυτή, δεν περιλαμβάνουν εντελώς ασφαλή πακέτα και έχουν μείνει στο Μάρτιο, ήτοι 6 μήνες πίσω από τη συγκεκριμένη ομιλία. Αν θέλετε κάλυψη, από Testing και πάνω.

  ● Ακολουθεί η επίσημη πολιτική του Debian σχετικά με τις ενημερώσεις του WebKit, την οποία ο Michael συνοψίζει στο “είναι πολύ δύσκολο για εμάς το να ενημερώσουμε το WebKit και γι’ αυτό δεν το κάνουμε”. Λίγο πιο αναλυτικά, στην πολιτική -η οποία συμπεριλαμβάνεται στις σημειώσεις κάθε νέας έκδοσης- αναγράφεται ότι η ανάπτυξη στο upstream είναι αρκετά γρήγορη για τα δεδομένα του Debian, με αποτέλεσμα να αλλάζουν οι βιβλιοθήκες και να μη μπορεί να ακολουθήσει (κάτι το οποίο ίσχυε όταν εκδόθηκε το Debian 8 αλλά πλέον οι του WebKit προσπαθούν να είναι πιο «συντηρητικοί» στην αναβάθμιση των σχετικών βιβλιοθηκών ώστε να καλύψουν και τις πιο αργοκίνητες διανομές) και ότι περιηγητές που βασίζονται σε λιγότερο ασφαλείς εκδόσεις του WebKit εμπεριέχονται μεν στη διανομή αλλά δεν καλύπτονται από υποστήριξη ασφάλειας. Συνιστάται η χρήση του Iceweasel (πλέον Firefox) και του Chromium.

Γιατί δεν αναβαθμίζουν;

  ● Είναι κολλημένοι (εννοεί λόγω παλαιότητας) στο WebKit1 (RHEL, SLED, παλιότερες εκδόσεις Debian/Ubuntu)

  ● Φοβούνται τις αστάθειες (νεότερο Debian, Ubuntu)

  ● Δε δίνουν σημασία (όλοι οι άλλοι -πλην προφανώς των διανομών που αναφέρθηκαν νωρίτερα ως προτεινόμενες)

Γιατί να μη «μπαλώνουμε» το downstream;

(σ.σ. επειδή οι συγκεκριμένοι όροι δεν έχουν καλή απόδοση στα Ελληνικά, ως «upstream» λογίζεται οτιδήποτε έχει να κάνει με τον πρώτο βαθμό ανάπτυξης του λογισμικού, δηλαδή τη δημιουργία ενός προγράμματος και την παράδοσή του από το δημιουργό, ενώ ως «downstream» αναφέρονται τα μετέπειτα στάδια, όπως η μεταφορά, το πακετάρισμα και η συντήρηση αυτού του προγράμματος από τις διανομές. Φανταστείτε την όλη διαδικασία σαν ένα ρυάκι που κυλά από ψηλά και ρέει προς τα κάτω, εξ ου και up-stream/down-stream).

  ● Είναι εξαιρετικά μη πρακτικό

  ● Απαιτεί εξειδικευμένες γνώσεις για την αντιμετώπιση των συγκρούσεων (εννοεί την ασυμβατότητα με άλλα στοιχεία του συστήματος)

  ● Πώς θα αποφασίσεις ποια «μπαλώματα» θα πάρεις αν δεν ακολουθείς το upstream;

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

Οι ευπάθειες είναι κάτι κακό αλλά κρατήστε τα πράγματα σε προοπτική

  ● Οι ευπάθειες δεν είναι (απαραίτητα και) εκμεταλλεύσιμες

  ● Παραμένετε ακόμα σχετικά ασφαλείς έναντι μη-στοχευμένων επιθέσεων αν χρησιμοποιείτε GNU/Linux

  ● Να σας απασχολούν περισσότερο οι επιθέσεις man-in-the-middle: οι εφαρμογές με WebKit1 κάνουν σπάνια κατάλληλη επαλήθευση πιστοποιητικών (π.χ. Midori, Xombrero, Raspberry Pi browser, Banshee, Shotwell)

Αναφέρω εδώ τη φράση που χρησιμοποίησε ο Michael κλείνοντας, και δεν είναι ο μόνος που έχει πει κάτι ανάλογο:

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

Αν κάνετε μια βόλτα στο διαδίκτυο, μπορείτε να βρείτε παρόμοιες αναφορές από «ταπεινούς» προγραμματιστές με πολυετή προσφορά στο Linux μέχρι και τον καραφλό γίγαντα Greg Kroah-Hartman. Σχεδόν όλες τους εμπεριέχουν μια φράση αντίστοιχη αυτής: “Υπήρχε ένα πρόβλημα στο συστατικό τάδε, επιδιορθώθηκε, έχουν περάσει μήνες ή και χρόνια από τότε κι ακόμα η διανομή δείνα διατηρεί μια παλιότερη και μη διορθωμένη έκδοση”. Για λόγους, ας το πούμε, δεοντολογίας, επιτρέψτε μου να επιμείνω προσωπικά να μην αναφέρομαι ονομαστικά σε διανομές. Έτσι κι αλλιώς, το έχουν κάνει τόσοι άλλοι με βαρύνουσα σημασία.

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

Για το λόγο αυτό, θα σας παρακαλέσω να μη στέκεστε καθόλου στο πώς πλασάρεται η κάθε διανομή. Μπορεί να μην είναι εμπορικά προϊόντα, δεν απουσιάζουν όμως από ορισμένες τα διαφημιστικά τρικ που στόχο έχουν την προσέλκυση χρηστών. Να θυμάστε επίσης ότι ναι μεν ακολουθείται άλλο μοντέλο ανάπτυξης και αυτό καθιστά το Linux, αλλά και το open source εν γένει, συγκριτικά ασφαλέστερο, αλλά αυτό δε σημαίνει ότι σε σημεία του δεν υπάρχουν ξεχειλωμένες κουμπότρυπες. Η ύπαρξη κάποιου προβλήματος, ακόμα και κρίσιμου, δεν είναι κάτι κακό ή ντροπιαστικό. Άλλωστε, ακόμα και οι τρύπες στην ασφάλεια ουσιαστικά δεν είναι κάτι παραπάνω από bugs, δηλαδή σφάλματα στον προγραμματισμό. Κακό είναι να αποφεύγουμε να μιλήσουμε για το πρόβλημα, να προσπαθούμε να το κρύψουμε και κατά συνέπεια να μη μαθαίνουμε από τα λάθη μας.

«Εκεί έξω» υπάρχουν όλα. Στοιχεία, αποδείξεις, ονόματα, ανίκανοι προγραμματιστές που είναι πρώτη μούρη, ικανότατοι που βρίσκονται στο περιθώριο, διανομές με «όνομα» αλλά χωρίς ουσία και άλλα πολλά. Ερευνήστε, ενημερωθείτε, επιβραβεύστε την πραγματικά καλή δουλειά και επικρίνετε την κακή. Η επίκριση, όταν έχει βάση, διόλου δε βλάπτει. Αντίθετα, δυναμώνει, βοηθάει στη βελτίωση ή ακόμα και στο ξεσκαρτάρισμα. Για το καλό του Linux, του ΕΛ/ΛΑΚ και όλων μας.

  • Σχόλια

1 Comments:

  1. Εικόνα Pragma_linux
    Pragma_linux (χωρίς επαλήθευση)Σεπ 09, 2016 23:03 ΜΜ

    Ωραίο άρθρο! Ευχαριστώ Soulrain

Scroll to Top