Εντυπώσεις από τη FOSSCOMM 2011

Από το καράβι της επιστροφής από τη FOSSCOMM 2011, θα ήθελα να μοιραστώ τις εντυπώσεις μου από πιθανότατα το σημαντικότερο γεγονός σε επίπεδο Free Software κοινοτήτων στην ελλάδα.

Ως εκδήλωση, η FOSSCOMM περιλαμβάνει booths κοινοτήτων και εταιρειών που ασχολούνται με το ελεύθερο λογισμικό (και μπορούν να επιδοθούν σε "marketing"/"advocacy" και ενημέρωση για τις δραστηριότητες και τα προϊόντα τους), καθώς και παρουσιάσεις και workshop από developers και μέλη της γενικότερης κοινότητας του ΕΛΛΑΚ που θέλουν να μοιραστούν τις εμπειρίες τους με τους υπόλοιπους.

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


"OpenSUSE Medical" - Από τους Ρουσινόπουλο Αθανάσιο και Ηλία

Η παρουσίαση αυτή αναφερόταν κυρίως σε γιατρούς και συμπεριλάμβανε κυρίως προγράμματα διαχείρισης "φακέλου ασθενή" όπως π.χ., το OpenEMR. Το πιο ενδιαφέρον από αυτή την παρουσίαση για μη-γιατρούς, ήταν η ιδέα της ανάπτυξης ενός προϊόντος (software + hardware) για τη διαρκή μέτρηση (π.χ., σε καθημερινή βάση) της ινσουλίνης ενός ασθενούς που πάσχει από διαβήτη. Σημαντικές δυνατότητες που προτάθηκαν είναι η υποστήριξη της οπτικοποίησης της σειράς των μετρήσεων (ίσως και με δυνατότητα συσχέτισης ορισμένων "σημείων ενδιαφέροντος" του διαγράμματος που θα παράγει η οπτικοποίηση με γεγονότα της ζωής του ασθενή (π.χ., "έφαγα ένα μήλο") ) της αποθήκευσης των αποτελεσμάτων στον Η/Υ του χρήστη (persistence) και πιθανώς και η αποστολή των αποτελεσμάτων στο γιατρό του ασθενή.


"Complex Systems: Open Source Tools & Algorithms"

Από τους υποψήφιους διδάκτορες Κωνσταντίνο Παρούση και Μιλτιάδη Στάμο, του Πανεπιστημίου Πελοποννήσου (IIRC), οι οποίοι φαίνεται να ασχολούνται με μοντέλα κυρίως τύπου Barabasi [1] για ανάπτυξη scale-free γράφων και τις εφαρμογές αυτών. Για την έρευνά τους χρησιμοποιούν από ότι φαίνεται τη γλώσσα python για "one time programs", το networkx πακέτο της python για διαχείριση γράφων, αλλά πρόσφατα και το PyCUDA για να αξιοποιήσουν τις θεαματικές δυνατότητες πολυεπεξεργασίας των σύγχρονων καρτών NVIDIA
στους αλγορίθμους τους.

Κατά την άποψή μου, στους υπολογισμούς έρευνα αυτού του είδους πολύ χρήσιμο μπορεί να αποδειχθεί και το sage (ένα project που φιλοδοξεί να είναι ο open-source, python-based αντικαταστάτης των matlab, mathematica κλπ)

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

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

Btw, αν είστε ακαδημαϊκός και δεν έρχεστε στη FOSSCOMM χάνετε πιστεύω μια πολύ καλή ευκαιρία "cross-polination" αφού σε τέτοιες εκδηλώσεις έρχονται έλληνες ακαδημαϊκοί από εξαιρετικά διαφοροποιημένους ερευνητικούς τομείς ...

A new Java Bytecode Viewer - Από την Νικολέτα Τρύφωνα.

Μια πραγματικά πολύ ενδιαφέρουσα "ηρωική" προσπάθεια από το Πανεπιστήμιο του Ιονίου, για την κατασκευή ενός decompiler που θα δουλεύει με το σύνολο των δυνατοτήτων της java όπως π.χ., nested classes. Ο κώδικας μάλιστα του εργαλείου είναι ελεύθερα διαθέσιμος (!) στη διεύθυνση http://jbvd.sf.net

Το decompiling είναι ένας ιδιαίτερα ελκυστικός χώρος έρευνας δεδομένης της "ενδελεχούς περιέργειας" κάθε προγραμματιστή :P Το πιο σημαντικό χαρακτηριστικό πιστεύω του jbvd είναι ότι από ότι ειπώθηκε φαίνεται να είναι γραμμένο για "partial decompiling", δηλαδή μόνο της class που μας ενδιαφέρει και των εξαρτήσεών της. Πιστεύω αυτό μπορεί να βρει εφαρμογή στη διαδεδομένη τεχνική του "partial decompiling" closed-source βιβλιοθηκών ώστε να καλυφθούν τα τυχόν κενά της τεκμηρίωσης του πώς πρέπει κάποιος να τις καλεί σωστά, καθώς και για security εφαρμογές πιθανώς. Αντίθετα με το decompiling από κώδικα μηχανής σε π.χ., C που είναι θεωρητικά undecidable (i.e., αποδεδειγμένα δεν υπάρχει αλγόριθμος που να το λύνει σε πεπερασμένο χρόνο, στη γενική περίπτωση), το decompiling από jvm bytecodes πίσω σε Java είναι σε μεγάλο βαθμό θεωρητικά δυνατόν (ο λόγος είναι ότι το jvm είναι stack-based και όχι von-neumann αρχιτεκτονική). Πιστεύω ότι η Nicole μπορεί να βοηθηθεί στο έργο της διαβάζοντας περισσότερη από την ήδη υπάρχουσα δουλειά στον τομέα, όπως π.χ., τη δουλειά του McGill University πάνω στο Dava decompiler, καθώς και το διδακτορικό της Cristina Cifuentes και τα papers του Boomerang Decompiling (το high-level κομμάτι τους, για decompiling ξεκινώντας από μία ενδιάμεση μορφή σε SSA format.)

Η δική μου παρουσίαση

είχε ένα αρκετά εξειδικευμένο θέμα: με αφορμή την υλοποίηση της υποστήριξης για ADSL modems στο NetworkManager, παρουσιάστηκαν hints για το πώς μπορεί κάποιος να υποστηρίξει στον NM ένα νέο τύπο δικτυακής συσκευής καθώς και γενικότερα "system development" hints, όπως π.χ., την ανάγκη για γρήγορη απόκριση στα σχόλια των reviewers, την ανάγκη για χρήση των εργαλείων της διανομής του προγραμματιστή ώστε να μπορεί να ενααλλάσσει το κομμάτι του συστήματός του που αναπτύσσει μεταξύ της δικής του έκδοσης και τις έκδοσης που παρέχεται με τη διανομή του εύκολα και με ασφάλεια, καθώς και την τεχνική της εσκεμμένης δημοσίευσης μιας κακής λύσης για ένα πρόβλημα η οποία μπορεί (υπο συγκεκριμμένες προϋποθέσεις) να προκαλέσει τη δημιουργία της σωστής λύσης από αυτούς που πραγματικά ξέρουν πώς να την αναπύξουν ...


Την παρουσίαση του Μανώλη Κιαγιά σχετικά με τη δημιουργία "custom DVD" με FreeBSD λειτουργικό.

Η απορία που μου γεννήθηκε από την παρουσίαση είναι το κατά πόσο υπάρχει κάτι αντίστοιχο του mingw/wine ή του scratchbox, αλλά για cross-compile προγραμμάτων για FreeBSD μέσα από το Linux. Αυτό π.χ., ίσως έδινε τη δυνατότητα να γίνεται το compile σε μεγάλα / δυνατά EC2 instances ή στα ήδη υπάρχοντα Linux συστήματα ορισμένων developers που ενδιαφέρονται να υποστηρίξουν το FreeBSD. Μόλις βρω χρόνο, θα το ψάξω περισσότερο ...


Τις παρουσιάσεις των ανθρώπων της πολυεθνικής εταιρείας "Zenika"

(με παραρτήματα στη Γαλλία και την ελλάδα μεταξύ άλλων) σχετικά με το Spring 3.0 και το scaling μίας εφαρμογής που βασίζεται σε Spring, OpenJDK, Apache Tomcat και Debian 6, σε 1 δισεκατομμύριο εγγεγραμμένους χρήστες (με περίπου 100 χιλιάδες από αυτούς να είναι ενεργοί ταυτόχρονα κάθε χρονική στιγμή).

Όπως κάνουν αρκετοί που ασχολούνται με τέτοια projects (π.χ., το Amazon), ο άνθρωπος της Zenika όρισε ένα SLA για τον ανώτατο χρόνο απόκρισης ανά χρήστη (350ms). Εντύπωση μου έκανε το γεγονός ότι μερικές φορές αναγκάζονται να "παραβιάζουν" αυτό το SLA λόγω εν μέρει του garbage collector της Java. Αναρωτιέμαι αν θα έπρεπε να γραφτεί επιτέλους ένας εναλλακτικός garbage collector ο οποίος θα λειτουργεί "πιο incrementally", θυσιάζοντας μέρος της απόδοσης στο non-garbage collection mode, προκειμένου να προσφέρει εγγυήσεις ως προς τον ανώτατο χρόνο λειτουργίας του για το garbage collection, ανεξάρτητο σε μεγάλο βαθμό από το συνολικό μέγεθος του heap που διαχειρίζεται το JVM ...

Συμφωνώ απόλυτα με το τελικό συμπέρασμα του ομιλητή ό,τι για να υλοποιήσεις μία πραγματικά scallable web εφαρμογή είναι πολύ σημαντικό να έχεις τη δυνατότητα παρέμβασης σε όλα τα επίπεδα του "stack" σου, από το "bare metal" μέχρι τον κώδικα της εφαρμογής (για να μην πω και το browser των χρηστών σου :P) πράγμα που κάνει τη χρήση open-source components σχεδόν μονόδρομο ...

Την παρουσίαση του googler Γιώργου Κεραμίδα σχετικά με το "Automated Testing Framework"

που έχει αναπτύξει. Οι σχετικές απορίες μου/σχόλια από την εμπειρία μου στο testing του πυρήνα του Linux έχουν ως εξής:

* Ανάγκη για σταθερό, "universal" output format με δυνατότητες για conversion σε οτιδήποτε. Ο λόγος είναι γιατί θα θέλαμε όσο είναι δυνατόν να αποφύγουμε να ξανατρέξουμε τα tests (κάτι που μπορεί να είναι μη πρακτικό λόγω μεγάλου χρόνου εκτέλεσης ή λόγω του ότι αν δοκιμάσουμε χρόνια αργότερα μπορεί να μην υπάρχει πια καν το σχετικό hardware).

* Δυνατότητα για εκτέλεση σε cluster.

* Μια γενικευμένη δυνατότητα για ένα test να ορίσει τα χαρακτηριστικά του "περιβάλλοντος" στο οποίο θα τρέξει (π.χ., want_root_access, want_the_harddisk_to_fail_after_5_minutes κλπ κλπ)

* Δυνατότητα δοκιμής μη ντετερμινιστικών χαρακτηριστικών. (Π.χ., locking tests). Η δοκιμή για αυτά είναι αρκετά δύσκολη, δεδομένου ότι στην απλή περίπτωση θα λάβουμε διαφορετικά αποτελέσματα σε διαφορετικά μηχανήματα (!). Η "state of the art" λύση σε αυτό το χώρο από ότι ξέρω είναι η υλοποίηση "verifiers" στον kernel βασισμένων σε τεχνικές "δυναμικής ανάλυσης". Π.χ., ένας τέτοιος verifier θα εξετάσει όλα τα πιθανά codepaths που προκύπτουν από ένα συγκεκριμμένο test scenario και θα αποφασίσει "may deadlock" (fail) ή "can't deadlock" (pass). Έτσι μπορούμε να κάνουμε αξιόπιστη δοκιμή που θα δίνει τα ίδια αποτελέσματα ανεξάρτητα μηχανήματος εφόσον βέβαια ο "βαθμός μη ντετερμινισμού" (αριθμός πιθανών paths) δεν είναι υπερβολικά μεγάλος.

Αυτή η προσέγγιση είναι και η μόνη ρεαλιστική που μπορώ να φανταστώ για δοκιμή για και "επιβεβαίωση" ή μη, security-related ιδιοτήτων όπως TOCTOU-style bugs.

Χαρακτηριστική περίπτωση "dynamic verifier" υλοποιημένου πάνω στο Linux ως module αποτελεί το lockdep, για locking rules checking.

Η μόνη απαίτηση που μπορώ να φανταστώ από το testing framework για να υποστηριχθεί το παραπάνω είναι να μπορεί κάποιος να δηλώσει ότι το test χρειάζεται ένα kernel με τον X verifier ενεργοποιημένο (στα πλαίσια που είπαμε παραπάνω, των "containers"/"environments").

* Δυνατότητα δοκιμής και για πιθανά performance regressions. Για να γίνει αυτό πιστεύω ότι χρειαζόμαστε ένα ξεχωριστό είδος "test". Χρειαζόμαστε τη δυνατότητα καταρχήν να ορίσουμε (suites από) benchmarks και το test καθεαυτό να είναι η ανάλυση των αποτελεσμάτων και να επιστρέφει "Fail" αν η ανάλυση δείξει στατιστικά σημαντική απόκλιση.

Το να επιστρέφει ένα test τόσο "Pass/Fail" όσο και χρόνο εκτέλεσης είναι πάντως μια επέκταση που ήδη αναπτύσσεται στο "Automated Testing Framework" σύμφωνα με τα λεγόμενα του κου Κεραμίδα. Συμφωνώ ότι σίγουρα είναι καλύτερα να αναφέρεις χρόνους εκτέλεσης για τα πάντα προληπτικά, παρά να ψάχνεις να τους εκτιμήσεις όταν είναι πια πολύ αργά.

Για τα performance regressions πάντως που έχω δει στην πράξη στο Linux τα πιο αποτελεσματικά benchmarks είναι ή εξειδικευμένα microbenchmarks που δοκιμάζουν ένα συγκεκριμμένο χαρακτηριστικό, ή ολόκληρα κανονικά δημοφιλή προγράμματα ώστε να υπάρχει μια πιο ρεαλιστική εικόνα για την συνολική απόδοση του συστήματος. Οπότε πιστεύω ότι αυτά πρέπει να υποστηρίζονται, ανεξάρτητα από το άν χρονομετρούνται και τα υπόλοιπα (απλούστερα) test ή όχι.

* Τέλος, το framework φαίνεται να στοχεύει κυρίως την ανεύρεση και έκθεση regressions. Τι γίνεται όταν έχουμε ένα σύστημα "στην ανάπτυξη" οπότε μας ενδιαφέρει και το κατά πόσο αποκλίνουμε από τους στόχους που έχουμε θέσει κάθε στιγμή και όχι μόνο το αν γενικά είμαστε καλύτερα; Νομίζω ότι το μόνο που χρειάζεται επιπλέον γι αυτή την περίπτωση είναι ένας τρόπος "αξιολόγησης" / "ranking" κάθε test failure ώστε να βοηθείται ο καθορισμός προτεραιοτήτων για την ομάδα ανάπτυξης. Ίσως υπάρχουν και τρόποι μερικής αυτοματοποίησης αυτής της δυνατότητας (π.χ., page rank με χρήση του αριθμού των reverse dependencies του κάθε κομματιού κώδικα που δοκιμάζεται και άλλα heuristics) αλλά αυτό είναι κάτι που δε χρειάζεται προφανώς να είναι κομμάτι του framework αλλά μπορεί να υλοποιηθεί "εξωτερικά".

(Παρεμπιπτόντως, σήμερα ήταν η πρώτη φορά που είδα κατά πρόσωπο ένα google recruiter, αν και μη developer ο ίδιος, φάνηκε να καταλαβαίνει τις παραπάνω παρατηρήσεις αρκετά εύκολα :) )


* "Μεταφορά του πυρήνα του Linux σε custom Hardware" από τον κο Κορκακάκη

Πολύ ενδιαφέρουσα παρουσίαση με πολλές σχετικές με hardware όσο και Linux-specific πληροφορίες. Ένα πράγμα που μου έκανε εντύπωση ήταν ότι όταν πρότεινα και τη χρήση του qemu ώστε να διευκολυνθεί η ανάπτυξη (και κυρίως η αποσφαλμάτωση) του software "παράλληλα" με την πρόοδο στην παραγωγή του hardware, η απάντηση που πήρα ήταν στο στυλ "αστειεύεσαι; στον qemu θα έπρεπε υλοποιήσεις όλη την αρχιτεκτονική, ο qemu δεν είναι για rapid prototyping". Προσωπικά διαφωνώ, με τη δύναμη που μου δίνει η ασχετοσύνη μου σε αυτά τα θέματα :P

Πιστεύω ότι από τη στιγμή που οι μικροεπεξεργαστές που οι περισσότεροι hardwareάδες αναπτύσσουν για τα SoC τους είναι παραλλαγές των ήδη υπάρχοντων αρχιτεκτονικών (X86, ARM, MIPS, PowerPC ...) οι οποίες ήδη υποστηρίζονται από τον qemu, η υλοποίηση του emulation ενός νέου SoC δεν θα απαιτεί και τόσο πολύ κώδικα ώστε το όφελος να είναι μικρότερο του κόστους, αλλά αυτό μάλλον θα πρέπει να αποδειχθεί στην πράξη ...

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

Π.χ., έμαθα από την κοινότητα του "hackerspace" της Πάτρας ότι στεγάζονται σε χώρο που τελεί υπό κατάληψη (!) το υπόγειο του οποίου τους παραχωρήθηκε από το δήμο. Γιατί όχι κάτι αντίστοιχο και στα Χανιά στο χώρο της "Rosa Nera" ?
Ενδιαφέρον ...

Από την άλλη, το μεγαλύτερο αρνητικό της φετινής FOSSCOMM ήταν η απουσία πολλών διακεκριμμένων developers, admins κλπ. Λίγο οι οικονομικοί λόγοι, λίγο η "εντατικοποίηση" της δουλειάς λόγω κρίσης, λίγο η πεποίθηση ότι ίσως δε θα
βγει τίποτα χρήσιμο από μία εκδήλωση στην οποία κάθε ένας μιλάει για τα δικά του communities / projects? Ποιός ξέρει, το σίγουρο είναι ότι χάθηκαν πιστεύω αρκετές ευκαιρίες γνωριμίας και συνεργασίας που μπορεί να απέβαιναν πολύ χρήσιμες σε όλους ...

Περισσότερα σε επόμενα post ...

[1] Albert R., Barabási A.-L. (2002). "Statistical mechanics of complex networks". Rev. Mod. Phys. 74: 47–97. Bibcode 2002RvMP...74...47A. doi:10.1103/RevModPhys.74.47