Πολύ ωραία ανάλυση Παντελή! Τώρα για το πόσο εύκολο ή δύσκολο είναι να φτιαχτεί ένας display server εναλλακτικός του Xorg, ισχύουν μεν τα όσα αναφέρεις που διευκολύνουν την κατάσταση, αλλά δεν βλέπω σύντομα κάποια αξιόπιστη λύση που να μπορεί να αντικαταστήσει τον Χ στη γενική περίπτωση κρατώντας και τη συμβατότητα με τις υπάρχουσες εφαρμογές - πελάτες. Εκτός και αν τις πετάξουμε και πάμε σε νέες web/thin-client based γραμμένες για αυτό το νέο server... Πράγμα που επίσης βλέπω δύσκολο να γίνει στα επόμενα 1-2 χρόνια ας πούμε.
Εξάλλου την ιδέα application server και thin clients την έχουμε δοκιμάσει και στο πρόσφατο παρελθόν και με τον Χ server (LTSP, X -query, Χ forwarding). Και σε ορισμένες περιπτώσεις έχει δουλέψει αρκετά καλά. Μάλιστα ο Χ Server έχει από την αρχή πρόβλεψη για λειτουργία μέσω δικτύου, λειτουργίες και πρωτόκολλα που απ' ότι βλέπω δεν πρόκειται να συμπεριληφθούν στους νέους display servers μια και απορρίπτονται ως απαρχαιωμένα. Αμφιβάλλω για το πόσο έτοιμοι είμαστε για ένα web os που όλα θα είναι γραμμένα σε HTML και JavaScript και θα τρέχουν μέσα από τον browser... Συμφωνώ ότι τελικά, κάποια στιγμή εκεί θα πάμε λογικά, αλλά έχω την αίσθηση ότι το κλασσικό desktop τουλάχιστο ως εργαλείο παραγωγικότητας θα μας συντροφεύει για αρκετά χρόνια ακόμα. 2013/10/3 Pantelis Koukousoulas <pkt...@gmail.com>: > FWIW: > > 2013/10/3 Konstantinos Togias <ktog...@gmail.com>: >> Για την κατάσταση του XMir μπορείτε να διαβάσετε εδώ: >> http://mjg59.dreamwidth.org/28032.html > > Εντάξει, τέτοιου τύπου προβλήματα είναι όντως αναμενόμενα λόγω του ότι > οι developers είναι λίγοι (και σε αυτό εν μέρει φταίει η Canonical που δεν > εμπνέει ιδιαίτερα πια για να ασχοληθεί κανείς, βλ CLA, projects που > αναπτύσσονται under closed doors για να κάνουν περισσότερη marketing > εντύπωση κλπ. Αυτές οι στρατηγικές μπορεί να είναι καλές για την > Canonical ως επιχείρηση και ενίοτε και για τους "end users", αλλά > σίγουρα δεν εμπνέουν κανένα σοβαρό εξωτερικό παίκτη > να συνεισφέρει κώδικα στο Mir/XMir και αυτό φαίνεται > εκ του αποτελέσματος). > > Γεγονός επίσης είναι ως σύνοψη της διαμάχης μεταξύ των στρατοπέδων > Mir και Wayland: > > -> Mir: developers που ξέρουν καλά από agile / test-oriented development > κλπ. > > -> Wayland: developers που ξέρουν πολύ καλά το free software > graphics stack. > > Από εκεί και πέρα: > >> Δεν είναι απλό να φτιάξεις έναν γενικού σκοπού Display Server ειδικά >> όταν δουλεύεις μόνος σου... Δεν είναι τυχαίο ότι όλες οι διανομές >> χρησιμοποιούν το X, ένα project που μετρά εμπειρία 20 και πλέον >> χρόνων, [...] > > Αυτό δεν είναι 100% ακριβές όμως πλέον. Σίγουρα αν η Canonical > επιχειρούσε να φτιάξει μια εναλλακτική στο X.org πριν από 10 > χρόνια και χωρίς έμπειρους "core" developers στη σύνθεση της > ομάδας, θα γελούσανε και οι πέτρες και θα τους είχανε πάει για > τρελοκομείο δεμένους κατευθείαν. > > Τώρα όμως το σκηνικό έχει αλλάξει αρκετά. Πολύ μεγάλο (το > μεγαλύτερο;) κομμάτι των υπηρεσιών του X server έχει πλέον > περάσει αλλού ήδη, χωρίς οι περισσότεροι "απλοί χρήστες" > (end-users) να το πάρουν χαμπάρι ιδιαίτερα. > > Π.χ.,: > > -> Server-side rendering: Πλέον καμία από τις ενδιαφέρουσες > εφαρμογές δεν το χρησιμοποιεί, όλες κάνουν το rendering > στον client και στέλνουν τα τελειωμένα bitmaps στον > X server για το compositing. > > -> Input device hotplugging / lifecycle: πλέον γίνεται μέσω > udev και evdev. > > -> Memory management μεταξύ RAM και GPU RAM: έχει περάσει > στον kernel (βλ KMS) και κατά συνέπεια και οι graphics drivers > πλέον δεν υπάρχει κανένας σοβαρός λόγος να είναι μέσα στο > codebase του display server. > > -> PCI access (κάποτε ο X έγραφε στους PCI registers κατευθείαν): > έχει περάσει στον kernel και τη libpciaccess. > > -> VGA arbitration: και αυτό έχει περάσει στον kernel > > -> Fonts: έχει πάει πλέον σε client side με fontconfig / freetype κλπ > > -> Printing (μη γελάτε, βλ Xprint): έχει πάει σε άλλο service (cups) > > και αντίστοιχα για άλλες υπηρεσίες. > > Το κύριο που έχει μείνει που βολεύει ως υπηρεσία είναι το compositing > (το οποίο ο X.org ΔΕΝ παρέχει και αντίθετα κάνει ping-pong με ένα > εξωτερικό compositor για να δουλέψει όπως το compiz) και το πολύ > πολύ σημαντικό και δύσκολο: ο χειρισμός των input events και η > αντιστοίχισή τους σε παράθυρα, μετατροπή των συντεταγμένων > και αποστολή στις αντίστοιχες διεργασίες, το οποίο για να δουλέψει > ιδανικά χρειάζεται συνεργασία με τον compositor άρα κι εδώ > η δουλειά του X.org δεν είναι και η καλύτερη. > > Αυτά είναι ουσιαστικά που θέλουν να παρέχουν ο wayland και ο > Mir και αν δεις το μέγεθός τους είναι πολύ πολύ μικρότερο από > αυτό που είχε ειδικά στην αρχή ο x.org (θυμάστε τι τέρας ήταν > στην αρχή που ήταν ακόμα monolithic;). > > Οπότε δεν είναι θέμα μόνο και μόνο οι mobile πλατφόρμες που > εμπνέουν την αλλαγή του Display server, όπως και να 'χει > η αρχιτεκτονική του X είναι πλέον σε μεγάλο βαθμό ξεπερασμένη > στα Linux συστήματα και αργά ή γρήγορα θα άλλαζε. > > Το συμπέρασμα είναι ότι για το Mir ουσιαστικά η canonical κάνει > reuse όλα τα έτοιμα που της παρέχουν οι παραδοσιακοί contributors > των γραφικών (KMS, evdev κλπ) και για τα λίγα που έχουν μείνει > αρκεί να κάνει σε μεγάλο βαθμό copy-paste τον κώδικα του wayland > ως προς το input και απλά: > > * αλλάζει ορισμένα διακοσμητικά (google protocol buffers αντί για > in-house protocol format του wayland) > > * αλλάζει λίγο τη "φιλοσοφία του rendering" (δηλαδή το ποιος > κάνει allocate τους buffers), βασισμένη πιστεύω σε ένα τεχνικό > fallacy αφού αυτά που θέλουν να κάνουν τελικά μια χαρά τα > κάνει και ο wayland. > > * κοτζάρει και ένα agile / test-oriented / QA development > methodology > > * κοτζάρει και ένα CLA από πάνω για να έχει τον έλεγχο. > > > Οπότε, τα τελικό συμπεράσματα (προσωπικά μιλώντας πάντα) είναι: > > * ότι δεν είναι καθόλου αδύνατον με αυτά τα δεδομένα (ακόμα και > ως τη 14.04 ή τη 14.10) η Canonical να παρουσιάσει ένα Mir που > να δουλεύει και ένα XMir που να μην είναι και τόσο χάλια. > > * ότι η Canonical προσπαθεί να γίνει σαν το Android δηλαδή να > φτιάξει ένα Display server μόνο για το Unity, γι αυτό φαίνεται > και να πηγαίνει σχετικά γρήγορα. Το πρόβλημα δεν είναι το > hardware (αυτό πλέον έχει πάει στον kernel) αλλά το software > (οι πρώην X clients) που τους "κρατούσε πίσω" ως τώρα > > * Με βάση αυτά φυσικά κανένα άλλο γραφικό περιβάλλον δεν > πιστεύω να νοιαστεί για το Mir / XMir και λογικό είναι. > > Παράλληλα, το βλέπω από εμένα, το ίδιο το παραδοσιακό > desktop (γνωστό και σαν "fat client" ή "rich client") πιστεύω > ότι πεθαίνει σιγά-σιγά, πιστεύω ότι πάμε σε webtops, οικιακούς > servers / appliances και mobile πλατφόρμες. > > Οπότε ο ανταγωνισμός θα είναι πια σε επίπεδο "core OS": > > * Ubuntu: upstart/Mir/Unity > > * GnomeOS: systemd/wayland/GnomeShell > > * Mer: systemd/wayland/qt με διάφορα shells από πάνω > όπως jolla και plasma > > * FirefoxOS: android + Firefox > > * Android > > κλπ κλπ, τόσο για το desktop όσο και για mobile. > > Επίσης το ίδιο γίνεται σιγά σιγά και στο επίπεδο των server > και των appliances βλ. π.χ., Nitix και CoreOS. > > Και αντίστοιχα η συνεργασία θα είναι σε ό,τι είναι "παραπάνω" > (π.χ., κοινά apps και services) και ό,τι είναι "παρακάτω" > (π.χ., kernel, core libraries) στο γενικό stack. > > Είναι πολύ ενδιαφέρουσες εξελίξεις και προσωπικά αν δεν > είχαμε την κρίση και τα προβλήματα εδώ στην Ελλάδα θα > ήμουν ιδιαίτερα ενθουσιασμένος για το μέλλον του Linux > και του Ελεύθερου Λογισμικού, με το θάνατο του desktop > πάμε πια για "παγκόσμια κυριαρχία", χεχε :) > > Χαιρετισμούς, > Παντελής -- Konstantinos Togias M.Sc. in Mathematics of Computers and Decision Making -- Ubuntu-gr mailing list Ubuntu-gr@lists.ubuntu.com If you do not want to receive any more messages from the ubuntu-gr mailing list, please follow this link and choose unsubscribe: https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr
