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

Πλαίσιο του αιτήματος

Στις 19 Ιουλίου 2024, η SUSE δημοσίευσε μια ανοιχτή επιστολή στη λίστα αλληλογραφίας του openSUSE, εκφράζοντας την ανάγκη για rebrand. Η επιστολή επισημαίνει τρεις βασικούς λόγους:

1. Ασυνέπεια του Έργου: Ο κατακερματισμός των διανομών openSUSE, με εκδόσεις όπως το Tumbleweed, το Leap και το Slowroll, έχει δημιουργήσει σύγχυση και μια αντίληψη ασυνέπειας.
2. Ευθυγράμμιση με SLES: Η SUSE θέλει το openSUSE να ευθυγραμμιστεί πιο στενά με τον SUSE Linux Enterprise Server (SLES) για να εξασφαλίσει μεγαλύτερη συνέπεια και πιο απτά αποτελέσματα.
3. Σαφήνεια επωνυμίας: Αποφυγή της σύγχυσης μεταξύ των δύο διανομών για πιθανούς πελάτες, διασφαλίζοντας ότι η SUSE διατηρεί μια σαφή και ξεχωριστή ταυτότητα.

Συνέπειες του Rebranding

Το rebranding δεν αφορά μόνο το όνομα αλλά και το λογότυπο. Ο διάσημος χαμαιλέοντας, σύμβολο της SUSE, ενδέχεται να μην χρησιμοποιείται πλέον (ΣΗΜΕΙΩΣΗ: είχε γίνει διαγωνισμός με ψηφοφορία για αλλαγή λογοτύπου. Τα αποτελέσματα βρίσκονται στο wiki). Η τρέχουσα πρόταση περιλαμβάνει τη μετονομασία των υπαρχουσών διανομών καταργώντας το πρόθεμα "openSUSE", μετατρέποντας το "openSUSE Tumbleweed" σε απλά "Tumbleweed" και το "openSUSE Leap" σε "Leap".

Ανάλυση αιτήματος

Είτε το πιστεύετε είτε όχι, μια απροσδόκητη σύγκρουση έχει προκύψει στην κοινότητα του openSUSE με τον επί μακρόν υποστηρικτή της, την εταιρεία SUSE.

Στο επίκεντρο αυτής της σύγκρουσης βρίσκεται ένα αίτημα που έχει προκαλέσει όχι και τόσο ήσυχες αντιδράσεις σε ολόκληρη την κοινότητα ανοιχτού κώδικα: Η SUSE ζήτησε επίσημα από το openSUSE να διακόψει τη χρήση της επωνυμίας της.

Ο Richard Brown, βασικό πρόσωπο του openSUSE project, μοιράστηκε ιδέες στο πρόσφατο συνέδριο του project, για τις συζητήσεις που έχουν εκτυλιχθεί κεκλεισμένων των θυρών.

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

Ας το παραδεχτούμε: Το SUSE ήταν κάτι περισσότερο από ένα ομώνυμο για το openSUSE. Έχει παράσχει ενεργά πόρους και υποστήριξη πολύ πέρα από αυτό που θα χρειαζόταν συνήθως για τις επιχειρηματικές της δραστηριότητες.

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

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

Η πολιτική "Factory First", ακρογωνιαίος λίθος της συνέργειας μεταξύ SUSE και openSUSE, θα μπορούσε επίσης να εξεταστεί εξονυχιστικά, δίνοντας έμφαση στη σοβαρότητα της τρέχουσας κατάστασης.

Επιπλέον, στο συνέδριο openSUSE, οι συζητήσεις σχετικά με τη διακυβέρνηση στο πλαίσιο του έργου openSUSE τέθηκαν στο προσκήνιο. Η ανοιχτή επιστολή υπογραμμίζει ζητήματα διακυβέρνησης στο πλαίσιο του openSUSE project και την ανάγκη για νέους συντελεστές. Η SUSE τόνισε ότι η διατήρηση του status quo δεν είναι ρεαλιστική επιλογή. Αυτό απαιτεί μια αναδιάρθρωση του Διοικητικού συμβουλίου openSUSE για να κατευθύνει το έργο σε μια νέα κατεύθυνση.

Υπό το πρίσμα αυτού, τα ανώτερα στελέχη και οι κάτοχοι προϋπολογισμού από το SUSE εξέφρασαν ανοιχτά τις ανησυχίες τους, σηματοδοτώντας ότι είναι απαραίτητες αλλαγές για την αντιμετώπιση των υποκείμενων ζητημάτων με τη διακυβέρνηση του έργου.

Αυτή η δημόσια στάση από τη διοίκηση της SUSE υπογραμμίζει την προθυμία να υποστηρίξει το openSUSE, αλλά και την ετοιμότητα να ευθυγραμμίσει εκ νέου την εστίασή της εάν η κοινότητα αποτύχει να ενεργήσει σε αυτές τις ανησυχίες διακυβέρνησης.

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

Με άλλα λόγια, το openSUSE βρίσκεται σε ένα σταυροδρόμι. Το έργο μπορεί είτε να προσαρμοστεί στο εξελισσόμενο τοπίο, αγκαλιάζοντας την αλλαγή και αντιμετωπίζοντας τις εσωτερικές του προκλήσεις, είτε μπορεί να συνεχίσει σε μια πορεία που μπορεί να οδηγήσει στην απαρχαιότητά του.

Τα τελευταία χρόνια, το openSUSE έχει αποκτήσει μεγάλη δυναμική, αυξάνοντας ραγδαία τη βάση χρηστών του. Επιπλέον, αυτό που ήταν γνωστό ως Leap και Tumbleweed έχει επεκταθεί σε νέα ονόματα όπως Krypton, MicroOS, Aeon, Kalpa, Argon και Leap Micro.

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

Για αυτό, δεν χρειάζεται μαντικές ικανότητες για να πούμε ότι εάν η SUSE απέσυρε την υποστήριξή της, θα σήμαινε δραστική μείωση των τρεχουσών παραλλαγών του openSUSE, επανεξέταση των προτεραιοτήτων και των επιλογών και πιθανή πτώση για το project.

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

Ως εκ τούτου, μπορούμε να πούμε με βεβαιότητα ότι το ευγενικό αίτημα της SUSE θα ικανοποιηθεί και το έργο θα ξεκινήσει τη διαδικασία αλλαγής του ονόματός του και αναζήτησης νέου λογότυπου. Ναι, αυτό είναι σωστό, ο αγαπημένος χαριτωμένος χαμαιλέοντας είναι μέρος του rebranding.

Αντιδράσεις της κοινότητας

Η κοινότητα του openSUSE έχει αντιδράσει με διάφορους τρόπους στο αίτημα SUSE. Ορισμένοι βλέπουν το rebranding ως απαραίτητο βήμα για την αποφυγή σύγχυσης και τη βελτίωση της σαφήνειας του έργου. Άλλοι το θεωρούν προδοσία των αρχών του ανοιχτού κώδικα και προσπάθεια της SUSE να αποστασιοποιηθεί από το έργο. Μια ανησυχία που εγείρεται είναι η πιθανή αντίληψη ότι η SUSE ακολουθεί το παράδειγμα της Red Hat με το CentOS. Αυτή η αντίληψη θα μπορούσε να επηρεάσει αρνητικά την εικόνα της SUSE στην κοινότητα ανοιχτού κώδικα.

Συμπέρασμα

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

Σε κάθε περίπτωση, θα παρακολουθούμε στενά την κατάσταση και, όπως πάντα, ενημερωνόμαστε καθώς εξελίσσεται. Για περισσότερες πληροφορίες, επισκεφθείτε το μήνυμα της λίστας αλληλογραφίας openSUSE σχετικά με το θέμα. Η επακόλουθη μάλλον ενδιαφέρουσα συζήτηση είναι διαθέσιμη εδώ.

Τέλος, μπορείτε να δείτε την παρουσίαση στο τελευταίο συνέδριο που προκάλεσε κύματα αντιδράσεων.

Με μεγάλη χαρά σας παρουσιάζω τη τεκμηρίωση με τίτλο "Χτίζοντας μια Κοινότητα Ελεύθερου Λογισμικού" (https://iosifidis.github.io/fosscommunities/). Στην τεκμηρίωση αυτή, περιγράφονται αναλυτικά οι τρόποι με τους οποίους μπορεί κάποιος να δημιουργήσει μια κοινότητα Ελεύθερου Λογισμικού και πώς να την λειτουργήσει αποτελεσματικά.

Η τεκμηρίωση αυτή αποτελεί το αποτέλεσμα γνώσεων και εμπειριών που αποκτήθηκαν από την ενασχόλησή μου με το Ελεύθερο Λογισμικό και τις κοινότητες ΕΛΛΑΚ από το 2006. Περιλαμβάνει πρακτικές συμβουλές, στρατηγικές και βέλτιστες πρακτικές που μπορούν να βοηθήσουν τόσο νέους όσο και έμπειρους χρήστες να οικοδομήσουν και να διαχειριστούν βιώσιμες και ενεργές κοινότητες.

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

Η νέα τεκμηρίωση είναι διαθέσιμη για όλους και ευελπιστώ ότι θα αποτελέσει ένα χρήσιμο εργαλείο για όσους επιθυμούν να συμβάλλουν στην ανάπτυξη και την υποστήριξη του Ελεύθερου Λογισμικού. Διαβάστε την και ξεκινήστε να χτίζετε τη δική σας κοινότητα σήμερα!

Για περισσότερες πληροφορίες μπορείτε να ανατρέξετε στην τεκμηρίωση https://iosifidis.github.io/fosscommunities/.

Τι είναι;

Η Slowroll είναι μια νέα διανομή από το 2023 που βασίζεται στο Tumbleweed, αλλά "κυλάει" πιο αργά. Με μεγάλες ενημερώσεις κάθε έναν ή δύο μήνες, και συνεχείς διορθώσεις σφαλμάτων και διορθώσεις ασφαλείας καθώς εμφανίζονται.

Εγκατάσταση - Χρήση

Για αρχική εγκατάσταση, μπορείτε να χρησιμοποιήσετε το DVD iso από τη διεύθυνση http://download.opensuse.org/slowroll/iso/ αλλά να αφήσετε τα διαδικτυακά αποθετήρια απενεργοποιημένα (έτσι δεν τραβάει νεότερα πακέτα Tumbleweed από online repos). Μπορείτε επίσης να μεταβείτε απευθείας από οποιαδήποτε κυκλοφορία Leap ή Tumbleweed στο Slowroll αντικαθιστώντας τα αποθετήρια.

Μετά την εγκατάσταση από DVD, πρέπει να αντικαταστήσετε το Tumbleweed με τα αποθετήρια Slowroll. Το ίδιο ισχύει όταν αλλάζετε από το Leap ή ένα παλαιότερο στιγμιότυπο του Tumbleweed στο Slowroll.

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

Το Packman μπορεί να λειτουργεί, αλλά μπορεί επίσης να χαλάει το σύστημα περιστασιακά. Υπάρχει ένα ειδικό αποθετήριο packman για το Slowroll:

Όπως το Tumbleweed, χρησιμοποιήστε το zypper dup για αναβάθμιση.

Πηγές

Reddit
Forums.o.o
Mailing-list
Wiki
Bugzilla TBD

Ανάπτυξη

Ο bmwiedemann έκανε το σχεδιασμό και το script .

Η ανάπτυξη γίνεται στο https://build.opensuse.org/project/show/openSUSE:Slowroll με τη χρήση του https://github.com/bmwiedemann/slowroll-tools

Τα μη δοκιμασμένα πακέτα μπαίνουν στη διεύθυνση https://build.opensuse.org/project/show/openSUSE:Slowroll:Staging πρώτα και ελέγχονται από το openQA (TBD)

Οι περισσότερες ενημερώσεις θα πρέπει να υποβάλλονται στο Factory και θα μετεγκατασταθούν αυτόματα στο Slowroll μετά την αποδοχή. Φροντίστε να αναφέρετε σχετικές επιδιορθώσεις CVE και αναφορές boo# σε αρχεία .changes για να επιταχύνετε τη μετεγκατάσταση. Οι άμεσες υποβολές θα πρέπει να χρειάζονται μόνο για backport επειγουσών επιδιορθώσεων που απαιτούν ενημερωμένα βασικά πακέτα στο Factory (τα οποία είναι πολύ επικίνδυνα για γρήγορη ενημέρωση)

Όσοι με γνωρίζουν, επιμένω συνέχεια στους προγραμματιστές να γράψουν σχόλια στον κώδικά τους αλλά και να γράφουν τεκμηρίωση γενικότερα.
Πιστεύω ότι υπάρχουν δύο κύριοι λόγοι που οι προγραμματιστές δεν γράφουν τεκμηρίωση. Τα εργαλεία παίζουν το ρόλο τους, αλλά είναι άλλοι λόγοι.

Το γράψιμο είναι δύσκολο

Οι "μηχανικοί λογισμικού" δεν γράφουν γιατί η σαφής γραφή είναι πολύ, ΠΟΛΥ δύσκολη.

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

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

Αυτός είναι ο λόγος για τον οποίο πολλοί άνθρωποι διαφωνούν σχετικά με την αξία των σχολίων στον κώδικα και τα πλεονεκτήματα της αυτο-τεκμηρίωσης κώδικα (ό,τι κι αν σημαίνει αυτό). Ο Kevlin Henney λέει ότι "το να ζητάμε σχόλια γύρω από περίπλοκο κώδικα είναι μάταιο, επειδή περιμένουμε από τους ίδιους ανθρώπους που δεν μπορούσαν να εκφραστούν καθαρά στον κώδικα να εκφραστούν καθαρά και κατανοητά με κείμενο (Αγγλικά)".

Η μη τεκμηρίωση δεν εμποδίζει την κυκλοφορία

Εάν ένας προγραμματιστής δεν γράψει τεκμηρίωση, η δουλειά του εξακολουθεί να έχει ολοκληρωθεί. Το να μην γράψει τεκμηρίωση δεν εμποδίζει την κυκλοφορία του προγράμματος (τουλάχιστον όχι αμέσως). Η ζημιά που προκαλείται από τη μη τεκμηρίωση τεχνικών αποφάσεων είναι σωρευτική. Όπως το τεχνικό χρέος, δεν προκαλεί ζημιά εδώ και τώρα.

Όπως ειπώθηκε και παραπάνω, η συγγραφή είναι πρωτίστως θέμα σκέψης και ανάλυσης. Στα περισσότερα μέρη, η συγγραφή κώδικα μπορεί να γίνει εύκολα. Ένας αποδιοργανωμένος σωρός κλάσεων και μεθόδων στον κώδικα μπορεί να λειτουργήσει - ένας σωρός λέξεων και παραγράφων δεν θα λειτουργήσει. Η γραφή ΠΡΕΠΕΙ να είναι σαφής εάν πρόκειται να είναι χρήσιμη. Ο κώδικας θα γίνει αποδεκτός (σε κάποιο βαθμό) αρκεί να κάνει τη δουλειά του. Και δεδομένου ότι οι περισσότεροι οργανισμοί επικεντρώνονται μόνο στην κυκλοφορία του προϊόντος, αυτό που δεν εμποδίζει την κυκλοφορία αγνοείται.

Οι δοκιμές (unit tests) αντιμετωπίζουν παρόμοιο πρόβλημα σε πολλές ομάδες. Για να ελέγξουμε τον κώδικα πρέπει να τον κατανοήσουμε (που απαιτεί περισσότερη προσπάθεια από τη σύνταξη του) και η απουσία δοκιμών δεν εμποδίζει την κυκλοφορία. Επομένως, συνήθως δεν υπάρχουν δοκιμές σε κώδικα.

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

Τι γίνεται με τα εργαλεία

Δεν υπάρχει αμφιβολία ότι το σύνολο εργαλείων που χρησιμοποιούνται συνήθως για την τεκμηρίωση λογισμικού σήμερα είναι θλιβερά ανεπαρκή. Δεν σκεφτόμαστε τα έγγραφα ένα-ένα. Σκεφτόμαστε με όρους ιδεών και στόχων συγκεντρώνοντας πολλές έννοιες ταυτόχρονα. Το έγγραφο που προκύπτει είναι μόνο μια εκδήλωση της διαδικασίας σκέψης. Χρειαζόμαστε εργαλεία που μπορούν να μας βοηθήσουν να συγκεντρώνουμε ιδέες διαχρονικά για να λύσουμε το πρόβλημα. Τα Έγγραφα Google, το Confluence, το Markdown είναι όλα κακά εργαλεία για αυτόν τον τύπο γραφής.

Ωστόσο, μια νέα γενιά εργαλείων όπως το Notion και το Roam αντιμετωπίζουν αυτό το πρόβλημα της αξιοποίησης των εργαλείων. Ας ελπίσουμε ότι αυτά θα λειτουργήσουν όπως προβλέπεται και θα βοηθήσουν στη σκέψη που οδηγεί στη συγγραφή.

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

Πώς να δημιουργείτε λοιπόν τεκμηρίωση

Το λογισμικό γραφής μας δίδαξε ένα πράγμα. Αν θέλετε πραγματικά οι χρήστες σας να κάνουν κάτι, τότε αυτό θα πρέπει να είναι ένα βήμα που τους εμποδίζει στο ταξίδι τους με το προϊόν σας. Με τον ίδιο τρόπο, η προσαρμογή τεκμηρίωσης σε γραπτό κώδικα δεν πρόκειται ποτέ να λειτουργήσει. Ακόμα χειρότερα, είναι άχρηστη. Η συγγραφή έχει να κάνει με την κριτική σκέψη. Σκοπός της είναι να εξηγήσετε τη διαδικασία σκέψης και την πρόθεσή σας στον εαυτό σας και στο ακροατήριό σας (π.χ. την ομάδα σας). Η διαδικασία σκέψης είναι το σημείο όπου η τεκμηρίωση/συγγραφή προσθέτει αξία, όχι ως στατική καταγραφή ήδη υλοποιημένου κώδικα.

Οι υποστηρικτές του προγραμματισμού mob/pair και των XP συχνά υποτιμούν την τεκμηρίωση. Αλλά αν δεν υιοθετηθούν αυτές οι τεχνικές, η πρακτική της συγγραφής και της αναθεώρησης των τεχνικών εγγράφων είναι ο μόνος τρόπος με τον οποίο οι ομάδες οικοδομούν μια συλλογική κατανόηση αυτού που προσπαθούν να οικοδομήσουν. Αυτή η κοινή οικοδόμηση του κόσμου είναι που καθιστά αυτή τη διαδικασία κρίσιμη για τη μακροπρόθεσμη υγεία της ομάδας και της βάσης κώδικα.

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

• Γράψτε τεκμηρίωση πριν τον κώδικα. Εκτός αν η αλλαγή είναι ασήμαντη, κάθε προγραμματιστής γράφει ένα σημείωμα για το τι πρόκειται να κάνει και το περνάει από την υπόλοιπη ομάδα. Στο τέλος της συζήτησης, η πραγματική συγγραφή κώδικα θα πρέπει να γίνει ασήμαντη.
• Γράψτε απλά. Μην περιπλέκετε το κείμενο, τουλάχιστον μέχρι να γίνει συνήθεια. Τα διαγράμματα, οι φανταχτερές ενότητες κ.λπ. μπορούν να περιμένουν. Γράψτε πολύ απλά για το τι σκεφτήκατε, τι κάνετε και γιατί. Ακόμη και αν το έγγραφο μπορεί να χρησιμεύσει ως βασικός δείκτης για την υπόλοιπη ομάδα τώρα και στο μέλλον, είναι εξαιρετικά πολύτιμο.
• Τεκμηριώστε την απόφαση με τις εναλλακτικές τους - Αντί να τεκμηριώνετε λεπτομερώς την πραγματική υλοποίηση (η οποία μπορεί να αλλάξει με την πάροδο του χρόνου), επικεντρωθείτε στην τεκμηρίωση των επιλογών και του λόγου για τον οποίο έγιναν. Αυτό είναι κάτι που ο κώδικας δεν μπορεί ποτέ να εξηγήσει και ως εκ τούτου η καταγραφή του τον κάνει πολυτιμότερο. Οι λεπτομέρειες μπορούν να τεκμηριωθούν με βάση τον χρόνο που είστε διατεθειμένοι να επενδύσετε.
• Κάντε την αναζητήσιμη - Καμία ποσότητα τεκμηρίωσης δεν θα έχει καμία χρησιμότητα εάν οι χρήστες δεν μπορούν να την βρουν. Χρησιμοποιήστε εργαλεία που υποστηρίζουν την αναζήτηση κειμένου. Αυτός είναι ένας από τους λόγους για τους οποίους δεν μου αρέσουν τα Έγγραφα Google για τεκμηρίωση. Είναι εξαιρετικό για τη συγγραφή, αλλά απλά απαίσιο για τη συνεργασία και την ανακάλυψη της πληροφορίας.
• Παρακολουθήστε τις αλλαγές. Ορισμένοι οργανισμοί χρησιμοποιούν τον έλεγχο εκδόσεων (version control όπως πχ github) για να παρακολουθούν τις αλλαγές στο σχεδιασμό του συστήματος με την πάροδο του χρόνου. Αυτό είναι υπέροχο. Αλλά αν δεν έχετε φτάσει ακόμα εκεί, κρατήστε ένα έγγραφο ανά χαρακτηριστικό και συνεχίστε να βάζετε σε αυτό ενημερώσεις με ημερομηνία, ώστε η εξέλιξη να μπορεί να παρακολουθείται σε ένα μέρος με ελάχιστη ταλαιπωρία.

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

Το Open Build Service (OBS) είναι μια πλατφόρμα ανοικτού κώδικα που παρέχει ένα πλήρες σύστημα αυτοματοποιημένης δημιουργίας πακέτων λογισμικού από τον πηγαίο κώδικα. Αρχικά αναπτύχθηκε από την εταιρεία SUSE, αλλά τώρα είναι διαθέσιμο ως ένα ελεύθερο λογισμικό υπό την άδεια GPL.

Το Open Build Service παρέχει ένα ολοκληρωμένο περιβάλλον για την κατασκευή πακέτων λογισμικού για πολλές διανομές Linux, όπως το openSUSE, το Fedora, το Debian, το Ubuntu και πολλές άλλες. Επιπλέον, υποστηρίζει τη δημιουργία πακέτων για αρχιτεκτονικές διαφορετικές από το x86, όπως ARM και PowerPC. Με το OBS, οι προγραμματιστές μπορούν να ανεβάζουν τον κώδικά τους, να ορίζουν τις απαιτούμενες εξαρτήσεις και να δημιουργούν αυτόματα πακέτα λογισμικού για πολλές πλατφόρμες και διανομές.

Τα πλεονεκτήματα του Open Build Service είναι πολλά. Πρώτον, παρέχει μια ενοποιημένη πλατφόρμα για τη δημιουργία πακέτων λογισμικού για πολλαπλές διανομές, εξοικονομώντας χρόνο και πόρους στους προγραμματιστές. Δεύτερον, προσφέρει αυτοματοποιημένες διαδικασίες για τη δημιουργία και την ενημέρωση των πακέτων, προσφέροντας ένα σταθερό και επαναληπτικό περιβάλλον. Τέλος, παρέχει ευέλικτες δυνατότητες προσαρμογής και διαμόρφωσης, επιτρέποντας στους χρήστες να προσαρμόσουν τις διαδικασίες κατασκευής και να προσθέσουν πρόσθετες λειτουργίες ανάλογα με τις ανάγκες τους.

Παρά τα πλεονεκτήματα του Open Build Service, υπάρχουν και μειονεκτήματα που πρέπει να ληφθούν υπόψη. Πρώτον, η εκμάθηση και η εξοικείωση με το σύστημα μπορεί να απαιτήσει χρόνο και προσπάθεια, ειδικά για νέους χρήστες. Δεύτερον, η συντήρηση και η διαχείριση των υποδομών του OBS μπορεί να απαιτήσει επιπλέον πόρους και επιδεξιότητες. Αυτό μπορεί να το παρέχει το openSUSE στην ιστοσελίδα https://build.opensuse.org/.

Χρήστες του Open Build Service

Όσον αφορά στους χρήστες του Open Build Service, αυτοί κυμαίνονται από ανεξάρτητους προγραμματιστές μέχρι μεγάλες επιχειρήσεις. Οι προγραμματιστές μπορούν να αξιοποιήσουν το OBS για να διευκολύνουν τη διαδικασία της κατασκευής, της δοκιμής και της διανομής του λογισμικού τους σε πολλές πλατφόρμες και διανομές. Από την άλλη πλευρά, οι μεγάλες επιχειρήσεις μπορούν να αξιοποιήσουν το OBS για τη δημιουργία ενός ενοποιημένου κέντρου κατασκευής λογισμικού, που επιτρέπει τον έλεγχο και τη διαχείριση των πακέτων σε διάφορες διανομές και πλατφόρμες.

Όσον αφορά στον τρόπο χρήσης του Open Build Service, οι χρήστες μπορούν να ανεβάζουν τον κώδικα τους στο σύστημα στην ιστοσελίδα https://build.opensuse.org/ και να ορίζουν τις απαιτούμενες εξαρτήσεις για την κατασκευή του πακέτου. Στη συνέχεια, μπορούν να εκκινήσουν τη διαδικασία κατασκευής, η οποία περιλαμβάνει τη συγκέντρωση και τη σύνθεση των απαιτούμενων στοιχείων για την παραγωγή του τελικού πακέτου με τη χρήση ενός αρχείο spec. Οι χρήστες μπορούν να διαμορφώσουν τις διαδικασίες κατασκευής, να προσθέσουν πρόσθετες ενέργειες και να διαχειριστούν τις εξαρτήσεις τους. Τέλος, το OBS παρέχει διάφορα εργαλεία και δυνατότητες για την αυτοματοποίηση της διαδικασίας κατασκευής, τη διαχείριση των πακέτων και την ενημέρωση του λογισμικού.

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

Το openQA είναι ένα εργαλείο αυτοματοποιημένου ελέγχου ποιότητας λογισμικού (QA), που χρησιμοποιείται για τον έλεγχο της λειτουργικότητας, της απόδοσης και της αξιοπιστίας μιας εφαρμογής. Βασίζεται στην αυτοματοποίηση των διαδικασιών ελέγχου, χρησιμοποιώντας τεχνικές δοκιμής για να ελέγξει το λογισμικό και να εντοπίσει πιθανά σφάλματα ή ασυνέπειες.

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

Το openQA χρησιμοποιείται από μια ποικιλία οργανισμών και κοινοτήτων που αναπτύσσουν λογισμικό. Παραδείγματα οργανισμών που χρησιμοποιούν το openQA περιλαμβάνουν την openSUSE, τόσο για την διανομή όσο και άλλως προγραμμάτων και εργαλείων, και το Fedora QA. Και οι δύο οργανισμοί χρησιμοποιούν το openQA για να ελέγξουν την ποιότητα των νέων εκδόσεων του λογισμικού τους πριν από την κυκλοφορία τους, εντοπίζοντας πιθανά σφάλματα και διασφαλίζοντας την ομαλή λειτουργία του συστήματος.

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

Ένα παράδειγμα χρήσης του openQA είναι η διαδικασία έλεγχου της νέας έκδοσης μιας διανομής Linux, όπως η openSUSE. Το openQA εκτελεί αυτοματοποιημένα δοκιμαστικά σενάρια σε διάφορα συστήματα, μοντέλα και περιβάλλοντα για να δοκιμάσει τη λειτουργικότητα και τη σταθερότητα της διανομής. Εάν το openQA ανιχνεύσει οποιαδήποτε σφάλματα, αποτυχίες ή ασυνέπειες, θα δημιουργήσει αναφορές για να επισημάνει τα προβλήματα προς τους προγραμματιστές, οι οποίοι θα αναλάβουν τη διόρθωση και την επανεξέταση του κώδικα. Αυτός είναι ο λόγος που η openSUSE Tubleweed καταφέρνει να εισάγει πρώτη (αν όχι πρώτη, τότε από τις πρώτες διανομές), τις τελευταίες εκδόσεις των προγραμμάτων, των GUI κλπ.

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

Στην εποχή του containerization και των cloud-native εφαρμογών, η αποτελεσματική διαχείριση της ανάπτυξης λογισμικού είναι ζωτικής σημασίας για τη διατήρηση της σταθερότητας, της ασφάλειας και της επεκτασιμότητας. Το openSUSE MicroOS, ένα καινοτόμο λειτουργικό σύστημα που βασίζεται στα θεμέλια του openSUSE, προσφέρει μια εξορθολογισμένη και βελτιστοποιημένη πλατφόρμα για φόρτο εργασίας που βασίζεται σε containers. Σχεδιασμένο για να απλοποιεί την ανάπτυξη και τη λειτουργία εφαρμογών που βασίζονται σε containers, το openSUSE MicroOS συνδυάζει τις καλύτερες πτυχές της αξιοπιστίας του openSUSE και του μοντέλου ατομικών ενημερώσεων που πρωτοπορεί το CoreOS. Αυτό το άρθρο διερευνά τα βασικά χαρακτηριστικά και τα οφέλη του openSUSE MicroOS και πώς δίνει τη δυνατότητα στους προγραμματιστές και τους διαχειριστές συστημάτων να αγκαλιάσουν το μέλλον του containerization.

Αποδοτικές ατομικές ενημερώσεις

Το openSUSE MicroOS διακρίνεται για το μοντέλο ατομικών ενημερώσεων, εξασφαλίζοντας συνεκτικές και αξιόπιστες ενημερώσεις χωρίς να διαταράσσονται οι εφαρμογές που εκτελούνται. Χρησιμοποιώντας τη λειτουργία transactional updates, το λειτουργικό σύστημα εφαρμόζει αυτόματα τις ενημερώσεις ως ενιαία μονάδα, εξαλείφοντας τις πολυπλοκότητες που σχετίζονται με τους παραδοσιακούς μηχανισμούς ενημέρωσης. Η προσέγγιση αυτή μειώνει σημαντικά τον κίνδυνο αποτυχιών του συστήματος που προκαλούνται από μερικές ενημερώσεις και απλοποιεί τη διαδικασία επαναφοράς σε περίπτωση τυχόν προβλημάτων.

Αμετάβλητο σύστημα αρχείων

Στην καρδιά του openSUSE MicroOS βρίσκεται ένα αμετάβλητο σύστημα αρχείων root μόνο για ανάγνωση. Με την υιοθέτηση ενός αμετάβλητου σχεδιασμού, το λειτουργικό σύστημα διασφαλίζει ότι τα βασικά στοιχεία του συστήματος παραμένουν αναλλοίωτα, ενισχύοντας τη σταθερότητα και την ασφάλεια. Οποιεσδήποτε τροποποιήσεις ή εγκαταστάσεις αποθηκεύονται σε container και αποθηκεύονται σε ξεχωριστά στιγμιότυπα με δυνατότητα εγγραφής, τα οποία μπορούν εύκολα να απορριφθούν ή να ανακληθούν αν χρειαστεί. Αυτή η προσέγγιση επιτρέπει επίσης καλύτερη αναπαραγωγιμότητα και εγγυάται ότι το σύστημα παραμένει σε γνωστή και προβλέψιμη κατάσταση.

Εστίαση σε container

Το openSUSE MicroOS έχει σχεδιαστεί με μια νοοτροπία που είναι πρώτα από τα container. Ενσωματώνεται καλά με τεχνολογίες container όπως το Docker και το Kubernetes, παρέχοντας μια απρόσκοπτη εμπειρία για προγραμματιστές και διαχειριστές. Με το βελτιστοποιημένο σύστημα του host, το openSUSE MicroOS προσφέρει ελάχιστο αποτύπωμα, μειώνοντας την επιφάνεια επίθεσης και βελτιστοποιώντας τη χρήση των πόρων. Επιπλέον, η ενσωμάτωσή του με πλατφόρμες ενορχήστρωσης container επιτρέπει την αποτελεσματική κλιμάκωση, εξισορρόπηση φορτίου και διαχείριση εφαρμογών με container.

Ενισχυμένη ασφάλεια και απομόνωση

Η ασφάλεια αποτελεί πρωταρχικό μέλημα στα σύγχρονα υπολογιστικά περιβάλλοντα. Το openSUSE MicroOS ενσωματώνει διάφορα χαρακτηριστικά για να διασφαλίσει ισχυρή ασφάλεια και απομόνωση για τα φορτία εργασίας που βασίζονται σε container. Χρησιμοποιώντας τεχνολογίες όπως το SELinux και το AppArmor, το λειτουργικό σύστημα επιβάλλει αυστηρούς ελέγχους πρόσβασης και απομονώνει τα container, αποτρέποντας τη μη εξουσιοδοτημένη πρόσβαση και μειώνοντας τον αντίκτυπο των πιθανών ευπαθειών. Επιπλέον, το μοντέλο ατομικής ενημέρωσης διασφαλίζει την άμεση εφαρμογή των επιδιορθώσεων ασφαλείας, ελαχιστοποιώντας το παράθυρο έκθεσης σε γνωστές ευπάθειες.

Ευκολία διαχείρισης

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

Κατεβάστε το openSUSE MicroOS

Το openSUSE MicroOS είναι διαθέσιμο για δωρεάν λήψη από τον ιστότοπο του openSUSE. Μπορείτε να κατεβάσετε το openSUSE MicroOS για μια ποικιλία αρχιτεκτονικών, συμπεριλαμβανομένων των x86_64, ARMv6, ARMv7 και ARMv8.

Συμπέρασμα

Το openSUSE MicroOS είναι ένα εξαιρετικό λειτουργικό σύστημα που φέρνει στο προσκήνιο τη δύναμη των container. Με το μοντέλο ατομικής ενημέρωσης, το αμετάβλητο σύστημα αρχείων, τη σχεδίαση που εστιάζεται σε container, τις βελτιωμένες δυνατότητες ασφαλείας και τα απλοποιημένα εργαλεία διαχείρισης, το openSUSE MicroOS παρέχει μια στέρεη βάση για την αποτελεσματική και ασφαλή εκτέλεση φόρτου εργασίας με container. Είτε είστε προγραμματιστής που αναζητά ένα σταθερό και βελτιστοποιημένο περιβάλλον είτε διαχειριστής συστήματος που αναζητά βελτιωμένες δυνατότητες διαχείρισης, το openSUSE MicroOS είναι μια συναρπαστική επιλογή που συνδυάζει τα δυνατά σημεία του openSUSE με τα πλεονεκτήματα των σύγχρονων τεχνολογιών container.

Θα βρείτε ερωτήσεις και απαντήσεις σχετικά με το Micro OS στο formum του openSUSE.

Βίντεο

Δείτε κάποια βίντεο σχετικά με το Micro OS.

Αυτό είναι εμπνευσμένο θέμα που το έχω αγαπήσει ιδιαίτερα.

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

Νομίζω ότι είναι απαραίτητο να υπενθυμίσουμε στους εαυτούς μας ότι δεν είμαστε ρομπότ. Χρειαζόμαστε ελεύθερο χρόνο κάθε τόσο και πρέπει να ισορροπήσουμε σωστά τη ζωή μας. Θα πρέπει να ζείτε τη ζωή σας. Δεν πρέπει να ξοδεύετε κάθε στιγμή που ξυπνάτε στο project που δουλεύετε, διότι δεν είναι υγιές. Μπορείτε να ξοδέψετε ένα μεγάλο μέρος του χρόνου σας σε projects που σας ευχαριστούν.

Το πιο σημαντικό πράγμα είναι να λέτε συχνά ΟΧΙ. Αυτό είναι και δικό μου λάθος. Μπορείτε να πειτε ΟΧΙ δεν μπορώ όταν κάποιος σας ρωτά "Μπορείς να κάνεις αυτό;". Βέβαια μπορείτε να πείτε και ΝΑΙ μερικές φορές. Μην τα ισοπεδώνουμε.

Υπάρχουν άλλα σημαντικά πράγματα.

• Ένα από τα πιο σημαντικά πράγματα είναι ο ύπνος. Να κοιμάστε πολλές ώρες. Να ξεκουραστείτε.
• Επίσης σημαντικές είναι οι φιλίες. Μπορείτε να έχετε φιλίες. Φιλίες εντός του project είτε εκτός. Θα σας κάνουν να αισθανθείτε περίφημα.
• Υιοθετήστε έναν έναν υγιεινό τρόπο ζωής και ίσως μερικές φορές σκεφτείτε τη δική σας κατάσταση του μυαλού. Πώς αισθάνεστε και πώς σας κάνει να νιώθετε το project που συνεισφέρετε. Ίσως επειδή ίσως σας αγχώνουν, είναι καλό να καταλάβετε γιατί αγχώνεστε και έτσι κάνετε σωστά την ερώτηση στον εαυτό σας.

Να έχετε υπόψη σας ότι τα projects ανοικτού λογισμικού αποτελούν μια εθελοντική προσπάθεια. Δεν βγάζετε κάτι από αυτό, σωστά; Οπότε θα πρέπει να έχετε στο νού σας να πάρετε κάτι από αυτό. Ίσως είναι απόλαυση, ίσως είναι απλώς η αίσθηση της κοινότητας, η αίσθηση της φιλίας που βιώνουμε. Αυτό που σίγουρα δεν θέλετε να έχετε είναι να χάσετε τον ύπνο σας. Γι' αυτό αν υπάρχει ένα ιδιαίτερα δύσκολο πρόβλημα που αντιμετωπίζετε στην καθημερινή σας δουλειά στο project σας, απλώς ρωτήστε κάποιον άλλο. Πάρτε τη γνώμη κάποιου άλλου. Μην χάσετε τον ύπνο σας. Ο ύπνος είναι πολύ σημαντικός. Φυσικά μερικές φορές μπορεί απλώς να χρειαστεί να αποστασιοποιηθείτε από τα πράγματα.

Ορίστε μερικές συμβουλές, μερικές πολύ γενικές συμβουλές:

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

Αυτό είναι εμπνευσμένο θέμα που το έχω αγαπήσει ιδιαίτερα.

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

Νομίζω ότι είναι απαραίτητο να υπενθυμίσουμε στους εαυτούς μας ότι δεν είμαστε ρομπότ. Χρειαζόμαστε ελεύθερο χρόνο κάθε τόσο και πρέπει να ισορροπήσουμε σωστά τη ζωή μας. Θα πρέπει να ζείτε τη ζωή σας. Δεν πρέπει να ξοδεύετε κάθε στιγμή που ξυπνάτε στο project που δουλεύετε, διότι δεν είναι υγιές. Μπορείτε να ξοδέψετε ένα μεγάλο μέρος του χρόνου σας σε projects που σας ευχαριστούν.

Το πιο σημαντικό πράγμα είναι να λέτε συχνά ΟΧΙ. Αυτό είναι και δικό μου λάθος. Μπορείτε να πειτε ΟΧΙ δεν μπορώ όταν κάποιος σας ρωτά "Μπορείς να κάνεις αυτό;". Βέβαια μπορείτε να πείτε και ΝΑΙ μερικές φορές. Μην τα ισοπεδώνουμε.

Υπάρχουν άλλα σημαντικά πράγματα.

• Ένα από τα πιο σημαντικά πράγματα είναι ο ύπνος. Να κοιμάστε πολλές ώρες. Να ξεκουραστείτε.
• Επίσης σημαντικές είναι οι φιλίες. Μπορείτε να έχετε φιλίες. Φιλίες εντός του project είτε εκτός. Θα σας κάνουν να αισθανθείτε περίφημα.
• Υιοθετήστε έναν έναν υγιεινό τρόπο ζωής και ίσως μερικές φορές σκεφτείτε τη δική σας κατάσταση του μυαλού. Πώς αισθάνεστε και πώς σας κάνει να νιώθετε το project που συνεισφέρετε. Ίσως επειδή ίσως σας αγχώνουν, είναι καλό να καταλάβετε γιατί αγχώνεστε και έτσι κάνετε σωστά την ερώτηση στον εαυτό σας.

Να έχετε υπόψη σας ότι τα projects ανοικτού λογισμικού αποτελούν μια εθελοντική προσπάθεια. Δεν βγάζετε κάτι από αυτό, σωστά; Οπότε θα πρέπει να έχετε στο νού σας να πάρετε κάτι από αυτό. Ίσως είναι απόλαυση, ίσως είναι απλώς η αίσθηση της κοινότητας, η αίσθηση της φιλίας που βιώνουμε. Αυτό που σίγουρα δεν θέλετε να έχετε είναι να χάσετε τον ύπνο σας. Γι' αυτό αν υπάρχει ένα ιδιαίτερα δύσκολο πρόβλημα που αντιμετωπίζετε στην καθημερινή σας δουλειά στο project σας, απλώς ρωτήστε κάποιον άλλο. Πάρτε τη γνώμη κάποιου άλλου. Μην χάσετε τον ύπνο σας. Ο ύπνος είναι πολύ σημαντικός. Φυσικά μερικές φορές μπορεί απλώς να χρειαστεί να αποστασιοποιηθείτε από τα πράγματα.

Ορίστε μερικές συμβουλές, μερικές πολύ γενικές συμβουλές:

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

ΕΠΙΛΟΓΗ ΓΡΑΦΙΚΟΥ ΠΕΡΙΒΑΛΛΟΝΤΟΣ

Κατά την μετάβασή σας από Windows σε Linux, θα επιλέξετε ποια διανομή σας βολεύει περισσότερο (από πλευράς εργαλείων για την δουλειά που θέλετε τον υπολογιστή) και στη συνέχεια επιλέγετε ποιο γραφικό περιβάλλον σας αρέσει περισσότερο. Προσωπικά χρησιμοποιώ GNOME και έχω μάθει τις περισσότερες ρυθμίσεις του. Δεν συστήνω άλλο γραφικό περιβάλλον σε νέους χρήστες, γιατί γνωρίζω ότι θα μου τηλεφωνήσουν για κάποια ρύθμιση και είμαι σίγουρος ότι μπορώ να τους βοηθήσω.

Τελευταία χρησιμοποιώ για εκπαιδευτικούς σκοπούς κάποιους υπολογιστές με όχι και τόσο προηγμένες δυνατότητες. Μιλάμε για 1GB μνήμη, για 4GB μνήμη. Έχω εγκατεστημένο ένα θεωρητικά απλό γραφικό περιβάλλον, αλλά έχω εγκαταστήσει και τον διαχειριστή παραθύρων i3wm. Με βόλεψε αρκετά και πλέον δεν μου είναι δύσκολο να το χρησιμοποιήσω και σε πιο δυνατούς υπολογιστές. Οπότε ξεκίνησα την εγκατάσταση και την ρύθιση. Βρήκα κάποια έτοιμα αρχεία ρυθμίσεων και προσάρμοσα έτσι όπως με βολεύουν. Θα τα μοιραστώ μαζί σας εδώ.

ΕΓΚΑΤΑΣΤΑΣΗ

Η εγκατάσταση είναι πολύ απλή. Υπάρχει στο wiki στο openSUSE. Γίνεται με μια απλή εντολή:

Επειδή θα χρειαστούμε και κάποια εργαλεία (θα αναφέρω παρακάτω) καλύτερα να τα εγκαταστήσετε με τη μία, με την εντολή:

Έτοιμο...

ΡΥΘΜΙΣΕΙΣ

Το παιχνίδι θα παιχτεί στις ρυθμίσεις. Στο τέλος θα σας έχω link με τις δικές μου ρυθμίσεις. Εδώ θα δούμε 2-3 πραγματάκια. Όλα θα ρυθμιστούν στο αρχείο .config/i3/config.

ΠΛΗΚΤΡΟ MOD

Πλήκτρο mod είναι αυτό που χρησιμοποιείται για διάφορες λειτουργίες (όπως να ανοίξετε ένα πρόγραμμα). Εγώ χρησιμοποιώ το πλήκτρο Windows (ή super key), επειδή θα χρησιμοποιήσω το alt για αλλαγή γλώσσας. Το πλήκτρο ρυθμίζεται κατά την πρώτη εκκίνηση του i3wm αλλά μπορείτε να το αλλάξετε και μετά. Εγώ έχω αυτά στην κορυφή του αρχείου config.

ΔΙΚΤΥΟ

Το δίκτυο είναι μεγάλο μανίκι. Στο netbook χρησιμοποιώ το wicd-curses. Στο openSUSE χρησιμοποιώ το nm-applet (στην φωτογραφία είναι αυτό που βλέπετε κάτω δεξιά). Γενικά υπάρχει τρόπος σύνδεσης στο ασύρματο δίκτυο μέσω τερματικού, αλλά δυσκολεύει πολλούς (και εμένα). Οπότε έψαξα ένα πιο εύκολο τρόπο. Το συγκεκριμένο applet έγινε εγκατάσταση με το πακέτο NetworkManager-applet. Πρόσθεσα στο τέλος του αρχείου config τις γραμμές.


Εάν είστε λίγο πιο hardcore τύποι, μπορείτε να συνδεθείτε με τη βοήθεια του YaST. Όμως καλύτερα να ανοίξετε ένα τερματικό (mod+enter) και να γράψετε την εντολή:


Βλέπετε ότι η οθόνη είναι μεν στο τερματικό αλλά μπορείτε να χρησιμοποιήσετε τα βελάκια. Εάν επιλέξετε το ενεργοποιήστε μια σύνδεση, θα μπορείτε να επιλέξετε το ασύρματο δίκτυο που επιθυμείτε...

ΕΝΑΛΛΑΓΗ ΓΛΩΣΣΑΣ

Όπως είπα παραπάνω, άφησα το πλήκτρο alt για να κάνω την αλλαγή της γλώσσας. Πρόσθεσα στο τέλος του αρχείου config την εντολή:

Μια άλλη εναλλακτική είναι να προσθέστε την παρακάτω γραμμή.

Στο αρχείο /etc/locale.conf είχα τα παρακάτω:

Ίσως να χρειάζεται να είναι διαφορετικό. Αν δεν σας αλλάζει η γλώσσα, θα πρεπει να πειράξετε αυτό το αρχείο.

ΠΡΟΣΘΗΚΗ WALLPAPER

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

Μια εναλλακτική, είναι να φτιάξετε ένα κατάλογο Wallpapers μέσα στον κατάλογο Pitures και να βάλετε όλα τα αρχεία που σας αρέσουν. Στη συνέχεια προσθέστε την παρακάτω γραμμή στο τέλος του αρχείου config και κάθε φορά που ανοίγει ο υπολογιστής, θα εμφανίζεται διαφορετική φωτογραφία στο background.

ΗΧΟΣ

Η αυξομοίωση του ήχου είναι ένα πρόβλημα. Πρόσθεσα τα παρακάτω:

Ουσιαστικά πατώντας το mod και το κόμμα, μειώνεται ο ήχος ενώ με το mod και την τελεία, αυξάνεται ο ήχος.

ΛΗΨΗ ΣΤΙΓΜΙΟΤΥΠΟΥ ΟΘΟΝΗΣ

Δοκίμασα πολλές λύσεις. Κάποιες δούλεψαν, κάποιες όχι. Θα γράψω πρώτα αυτή που χρησιμοποιώ και μετά τις υπόλοιπες. Σχεδόν για όλες τις λύσεις, χρειάζεται να έχετε εγκατεστημένα τα προγράμματα maim, xclip, byzanz.

Κάπου ενδιάμεσα στο αρχείο config πρόσθεσα τις παρακάτω γραμμές.

Τελειώσαμε με το αρχείο config. Απλά για reference, σας αφήνω από την ιστοσελίδα του project, την χρήση του πληκτρολογίου.



Επίσης μπορείτε να κατεβάσετε και το αρχείο pdf με όλες τις λειτουργίες των συνδυασμών των πλήκτρων.

ΡΥΘΜΙΣΕΙΣ ΑΡΧΕΙΟΥ .i3status.conf

Αυτο είναι ένα αρχείο που θα το αποθηκεύσετε στο home. Ουσιαστικά θα κάνει την ρύθμιση με τις πληροφορίες που θέλετε να φαίνεται στην κάτω μπάρα.
Βλέπουμε στην παραπάνω μπάρα, εμφανίζονται με την σειρά:

1. Ένταση ηχείων
2. Κατανάλωση μνήμης
3. Φόρτωση διεργασιών (αριθμός των διεργασιών έτοιμων προς εκτέλεση για τα τελευταία 1 λεπτό, 5 λεπτά, 15 λεπτά)
4. Ελεύθερος αποθηκευτικός χώρος στο /home
5. Ασύρματο δίκτυο (IP, ποιότητα, ταχύτητα)
6. Ενσύρματο δίκτυο (IP, ποιότητα, ταχύτητα)
7. Ημερομηνία και ώρα
8. nm-applet (για σύνδεση στο ασύρματο με την χρήση ποντικιού)

Δείτε μερικές φωτογραφίες:





Όλα τα αρχεία βρίσκονται εδώ:

• Αποθήκευση του config στον φάκελο .config/i3/
• Αποθήκευση του αρχείου .i3status.conf στον φάκελο του χρήστη (~)

Είχα γράψει παλιά ένα άρθρο:
Διαχειριστής παραθύρων i3. Ότι πιο γρήγορο έχω χρησιμοποιήσει...στο openSUSE

Περιέχει παλιές ρυθμίσεις. Αυτό είναι ανανεωμένο με τελευταίες πληροφορίες.