Κατά την κυκλοφορία της Radeon RX 9070 GRE στις αρχές Ιουνίου 2026, το Phoronix χρησιμοποίησε ως βάση δοκιμών το Ubuntu 26.04 LTS με Linux 7.0 και Mesa 26.0 — το προεπιλεγμένο περιβάλλον του νέου LTS. Η επιλογή ήταν σκόπιμη: η κάρτα λειτουργούσε άψογα εκτός κουτιού, και από προηγούμενες δοκιμές RDNA4 ήταν ήδη γνωστό ότι οι νεότερες εκδόσεις kernel και Mesa δεν αποφέρουν σημαντικά κέρδη.

Μετά από αιτήματα αναγνωστών, ο Larabel επανέλαβε τις μετρήσεις με Linux 7.1 Git και Mesa 26.1.1, συμπεριλαμβάνοντας και τις δύο κάρτες — την RX 9070 GRE με 48 compute units RDNA4, 48 επιταχυντές ray tracing, 96 επιταχυντές AI και boost clock 2,79GHz, 12GB GDDR6 και TDP 220W, καθώς και την RX 9070 XT με 64 compute units, 128 επιταχυντές AI και boost clock 2,97GHz για την 304W κάρτα με 16GB βίντεο μνήμης.

Τι είναι η RX 9070 GRE και γιατί μετράει

Η Radeon RX 9070 GRE βασίζεται στο ίδιο 4nm Navi 48 silicon που βρίσκεται μέσα στις RX 9070 και RX 9070 XT. Η RX 9070 GRE διαθέτει 14% λιγότερα CUs σε σχέση με την RX 9070 και περίπου 25% λιγότερα σε σύγκριση με την RX 9070 XT. Η μνήμη διαμορφώνεται σε 12GB GDDR6 με 192-bit interface και εύρος ζώνης έως 432 GB/s, ενώ η κάρτα υποστηρίζει DisplayPort 2.1a, HDMI 2.1b και Linux x86-64.

Η AMD είχε παρουσιάσει την κάρτα πέρυσι ως αποκλειστικό μοντέλο για την Κίνα, και στο Computex 2026 της έδωσε παγκόσμια κυκλοφορία. Η RX 9070 GRE κυκλοφόρησε με τιμή περίπου 549 δολάρια ΗΠΑ. Η κάρτα λειτουργούσε άψογα εκτός κουτιού στο Ubuntu 26.04 με Linux 7.0 kernel και Mesa 26.0, καθώς η υποστήριξη RDNA4 στο Linux είναι πλέον σε πολύ ώριμο επίπεδο.

Μεθοδολογία δοκιμών

Στην αρχική κριτική της RX 9070 GRE, δοκιμάστηκε ευρύ φάσμα καρτών, από Arc B570 και RTX 5090 μέχρι RX 7900 XTX και RX 9060 XT, με Linux 7.0 και Mesa 26.0 του Ubuntu 26.04 LTS. Για τη νέα σύγκριση, το ίδιο σύστημα επαναδοκιμάστηκε αποκλειστικά με RX 9070 GRE και RX 9070 XT, αλλά τώρα με Linux 7.1 Git και Mesa 26.1.1. Τα παιχνίδια και δοκιμές που χρησιμοποιήθηκαν περιλαμβάνουν DiRT Rally 2.0, HITMAN 3, GravityMark (Vulkan και Vulkan Ray-Tracing), GPUScore: Breaking Limit, Quake II RTX, καθώς και Llama.cpp για φορτία εργασίας AI μέσω Vulkan.

Αποτελέσματα: ουσιαστικά καμία διαφορά

Σε παιχνίδια όπως DiRT Rally 2.0 (1440p Ultra, 4K High, 4K Ultra) και HITMAN 3 (1440p Ultra, 4K Ultra — frame time και FPS), οι μετρήσεις επιδόσεων μεταξύ Ubuntu 26.04 stock και Linux 7.1 + Mesa 26.1.1 κυμαίνονταν εντός του στατιστικού θορύβου. Στο GravityMark με Vulkan Ray-Tracing σε 1440p και 4K, καθώς και στο GPUScore: Breaking Limit χωρίς ray tracing, η εικόνα ήταν ίδια: η RX 9070 XT παρέμενε ταχύτερη και στα δύο περιβάλλοντα, χωρίς να υπάρχει ουσιαστική διαφορά στο σχετικό κενό επιδόσεων από τη νεότερη στοίβα λογισμικού.

Σε δοκιμές Llama.cpp με Vulkan backend (μοντέλο Llama-3.1-Tulu-3-8B-Q8_0), τα αποτελέσματα για text generation ευνοούσαν ελαφρώς το Linux 7.1 + Mesa 26.1.1, ενώ στο prompt processing το Ubuntu 26.04 stock ήταν ελαφρώς μπροστά — διαφορές που δεν υπερβαίνουν τα όρια της μεθοδολογικής αβεβαιότητας.

Ανησυχητική εξαίρεση: Breaking Limit με ray tracing σε 4K

Στο GPUScore: Breaking Limit με ενεργοποιημένο ray tracing σε ανάλυση 4K (3840×2160), η RX 9070 GRE εμφάνισε ελαφρώς χαμηλότερες επιδόσεις με Mesa 26.1 σε σύγκριση με το stock Ubuntu 26.04. Ο Larabel χαρακτήρισε αυτή την απόκλιση ως «πιθανή οπισθοδρόμηση» (possible regression) για τη συγκεκριμένη κάρτα στο ray tracing — όχι ως επιβεβαιωμένο σφάλμα, αλλά ως κάτι που αξίζει παρακολούθηση στις επόμενες εκδόσεις Mesa. Η RX 9070 XT δεν εμφάνισε το ίδιο φαινόμενο.

Τι σημαίνει για τους χρήστες Linux

Το συμπέρασμα είναι πρακτικά χρήσιμο: όποιος χρησιμοποιεί Ubuntu 26.04 LTS με τις προεπιλεγμένες εκδόσεις Linux 7.0 και Mesa 26.0 δεν χάνει τίποτα σε επιδόσεις παιχνιδιών έναντι του νεότερου Linux 7.1 και Mesa 26.1. Η RX 9070 GRE λειτουργεί επίσης με τη σταθερή στοίβα ROCm 7.2 για φορτία εργασίας υπολογιστικής επεξεργασίας. Για το gaming καθαρά, το LTS παρέχει ήδη την πλήρη εμπειρία χωρίς ανάγκη για χειροκίνητη αναβάθμιση του kernel.

Πηγές

• Phoronix — Linux 7.1 + Mesa 26.1 Performance With The Radeon RX 9070 GRE, RX 9070 XT
• Phoronix — AMD Radeon RX 9070 GRE Linux Performance Review
• Tom's Hardware — AMD Radeon RX 9070 GRE Goes Global
• igor'sLAB — AMD Launches the Radeon RX 9070 GRE Worldwide

Η AMD υπέβαλε τον αναμενόμενο κώδικα υποστήριξης HDMI 2.1 Fixed Rate Link (FRL) στο DRM-Next, θέτοντάς τον σε τροχιά ενσωμάτωσης στον πυρήνα Linux 7.2. Το σχετικό pull request στάλθηκε στις 4 Ιουνίου 2026 και αποτελεί την ουσιαστική υλοποίηση μηνών εργασίας που είχε ξεκινήσει επίσημα στα τέλη Απριλίου με Μάιο 2026.

Τι είναι το FRL και γιατί μετράει

Το HDMI FRL (Fixed Rate Link) είναι η τεχνολογία μετάδοσης που κάνει εφικτές τις κεντρικές δυνατότητες του HDMI 2.1. Χωρίς FRL, λειτουργίες όπως 4K στα 144Hz, 8K στα 60Hz, μεταβλητός ρυθμός ανανέωσης μέσω HDMI και ασυμπίεστος υψηλής ζώνης ήχος δεν μπορούν να παραδοθούν μέσω της σύνδεσης. Οι προηγούμενες εκδόσεις HDMI χρησιμοποιούσαν διαφορετικό σχήμα σηματοδότησης — το TMDS — το οποίο παραμένει κάτω από το απαιτούμενο εύρος ζώνης για αυτές τις σύγχρονες λειτουργίες οθόνης.

Με FRL, το HDMI 2.1 μπορεί να αυξήσει το εύρος ζώνης έως 48 Gbps με χρήση καλωδίου Ultra High Speed — αριθμός που καθιστά εφικτή στην πράξη τη μετάδοση σήματος 4K στα 120Hz, με ενεργό HDR και χωρίς συμβιβασμούς στις πληροφορίες χρώματος. Με αυτή την υποστήριξη επιτρέπονται αναλύσεις όπως 4K στα 120Hz και 5K στα 240Hz στις κάρτες Radeon με Linux.

Το ιστορικό της χρόνιας αναμονής

Για χρόνια, το HDMI Forum — ο οργανισμός που ελέγχει το πρότυπο HDMI — αρνιόταν να επιτρέψει στην AMD να υλοποιήσει ανοιχτού κώδικα υποστήριξη HDMI 2.1 στον οδηγό Linux. Το κεντρικό ζήτημα αφορούσε στη διανοητική ιδιοκτησία: το Forum απαιτούσε η AMD να διατηρεί εμπιστευτική συγκεκριμένη τεχνογνωσία HDMI, κάτι που ερχόταν σε άμεση αντίθεση με την φιλοσοφία ανοιχτού κώδικα του πυρήνα Linux.

Τον Φεβρουάριο του 2024, το HDMI Forum απέρριψε επίσημα παλαιότερη πρόταση της AMD για κυκλοφορία ανοιχτού οδηγού με υποστήριξη HDMI 2.1. Αποτέλεσμα ήταν οι κάτοχοι AMD GPU που χρησιμοποιούν HDMI σε σύγχρονες οθόνες και τηλεοράσεις να παραμένουν περιορισμένοι στις δυνατότητες παλαιότερων εκδόσεων HDMI. Υψηλοί ρυθμοί ανανέωσης, ευρύ γκάμα χρωμάτων σε πλήρη ανάλυση και μεταβλητός ρυθμός ανανέωσης μέσω HDMI απαιτούσαν είτε DisplayPort είτε γύρω από τον ιδιόκτητο οδηγό.

Η AMD είχε αναπτύξει τον κώδικα ήδη από το 2024, σύμφωνα με τον μηχανικό Harry Wentland. Ωστόσο, το HDMI Forum εμπόδιζε τη δημοσίευσή του, επικαλούμενο ανησυχίες σχετικά με την αποκάλυψη ιδιόκτητης διανοητικής ιδιοκτησίας σε ανοιχτού κώδικα περιβάλλοντα. Ο Siqueira είχε ετοιμάσει την αρχική υλοποίηση πριν από μερικά χρόνια, ενώ εργαζόταν στην AMD, αλλά δεν κατάφερε να την υποβάλει πριν αποχωρήσει από την εταιρεία.

Τι περιλαμβάνει το pull request του Linux 7.2

Το pull request που στάλθηκε στις 4 Ιουνίου προς το DRM-Next περιλαμβάνει την αρχική υποστήριξη HDMI 2.1 FRL, μαζί με μια σειρά από πρόσθετες αλλαγές στον οδηγό AMDGPU. Συγκεκριμένα, εισάγεται διόρθωση BT.2020 για DCE, αρχική υποστήριξη Display Core Next (DCN) 4.2.1 για επερχόμενο υλικό, καθώς και ενεργοποίηση νέων IP blocks. Για τους επερχόμενους επεξεργαστές της αρχιτεκτονικής RDNA 3.5, εισάγεται GFX 11.5.6 μαζί με SDMA 6.4, NBIO 7.11.5, IH 6.4, HDP 6.4, MMHUB 3.4.2, SMU 15.0.5, ATHUB 3.4.2 και VPE 2.2.

Απενεργοποιημένο εξ ορισμού: ο λόγος και η προσωρινή λύση

Η υποστήριξη FRL απενεργοποιείται εξ ορισμού έως ότου είναι έτοιμη η λειτουργία Variable Refresh Rate (VRR) μέσω HDMI. Χωρίς υποστήριξη VRR, ενδέχεται να αποτελέσει παλινδρόμηση για υπάρχοντες χρήστες με οθόνες FRL. Μόλις ολοκληρωθεί η υποστήριξη HDMI VRR, η λειτουργία θα ενεργοποιηθεί εξ ορισμού.

Όσοι επιθυμούν να ενεργοποιήσουν ήδη την υποστήριξη HDMI 2.1 FRL για υψηλότερους ρυθμούς ανανέωσης και αναλύσεις, θα πρέπει να εκκινήσουν τον πυρήνα Linux με την παράμετρο amdgpu.dc_feature_mask=0x400. Επίσης αξίζει να σημειωθεί ότι αυτές οι αρχικές αλλαγές δεν αποτελούν πλήρη υποστήριξη HDMI 2.1 — λειτουργίες όπως VRR και Display Stream Compression (DSC) εξακολουθούν να βρίσκονται υπό δοκιμή και θα υποβληθούν σε μεταγενέστερες σειρές αλλαγών.

Σημασία για τις διανομές του 2026

Το Linux 7.2 αναμένεται να εισέλθει στο παράθυρο ενσωμάτωσης (merge window) στα μέσα Ιουνίου 2026. Με βάση τον τυπικό κύκλο κυκλοφορίας του πυρήνα, η σταθερή έκδοση αναμένεται διαθέσιμη νωρίς το φθινόπωρο — ακριβώς εγκαίρως για διανομές του δεύτερου μισού του 2026 όπως το Ubuntu 26.10, το οποίο έχει ήδη ανακοινωθεί ότι θα βασιστεί στον Linux 7.2.

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

Πηγές

• Phoronix – AMD Submits Its Long-Awaited HDMI 2.1 FRL Support For Linux 7.2 AMDGPU
• Phoronix – AMDGPU HDMI 2.1 FRL To Be Initially Disabled-By-Default
• KitGuru – AMD submits HDMI 2.1 FRL patches for open-source Linux driver
• Linux Kernel Mailing List – AMDGPU Pull Request (DRM-Next)

Ο πυρήνας Linux ετοιμάζεται να αποσύρει οριστικά το AF_ALG, το socket interface που επιτρέπει στις εφαρμογές χώρου χρήστη να προσπελαύνουν απευθείας το κρυπτογραφικό υποσύστημα του πυρήνα. Η διαδικασία κατάργησης επιταχύνθηκε λόγω της «τεράστιας επιφάνειας επίθεσης» που αποκαλύπτεται ολοένα και πιο γρήγορα χάρη σε εργαλεία εύρεσης ευπαθειών βασισμένα σε AI, και με το Linux 7.2 το AF_ALG καταργείται πλήρως.

Τι είναι το AF_ALG και γιατί αποσύρεται τώρα

Το AF_ALG είναι το socket interface του πυρήνα Linux για κρυπτογραφικές λειτουργίες χώρου χρήστη· επιτρέπει σε εφαρμογές να εκτελούν συμμετρική κρυπτογράφηση, κατακερματισμό και πιστοποιημένη κρυπτογράφηση χωρίς να υλοποιούν οι ίδιες κρυπτογραφικές πρωτόγονες συναρτήσεις. Στην πράξη, ελάχιστα προγράμματα το χρησιμοποιούν άμεσα — ενώ οι βασικές υπηρεσίες του συστήματος όπως dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS και SSH δεν εξαρτώνται από το AF_ALG και δεν επηρεάζονται από την κατάργησή του.

Ο Eric Biggers, μηχανικός που υπογράφει το σχετικό patch στο «cryptodev» tree του πυρήνα, αιτιολογεί την κατάργηση με ξεκάθαρο τρόπο: «Το AF_ALG είναι σχεδόν εντελώς περιττό, και εκθέτει μια τεράστια επιφάνεια επίθεσης που δεν αντέχει στα σύγχρονα εργαλεία ανακάλυψης ευπαθειών». Η προσπάθεια που καταβάλλεται για τη συντήρησή του είναι δυσανάλογα μεγάλη σε σχέση με τα ελάχιστα προγράμματα που το χρησιμοποιούν, και εκείνα τα προγράμματα θα εξυπηρετούνταν καλύτερα από κώδικα στο χώρο χρήστη.

Copy Fail (CVE-2026-31431): Η ευπάθεια που έκλεισε τη συζήτηση

Το CVE-2026-31431, γνωστό ως «Copy Fail», είναι ευπάθεια στον πυρήνα Linux που επιτρέπει μη εξουσιοδοτημένη κλιμάκωση δικαιωμάτων. Αποκαλύφθηκε δημόσια στις 29 Απριλίου 2026 από την εταιρεία ασφαλείας Theori, ενώ η ιδιωτική γνωστοποίηση στην ομάδα ασφαλείας του πυρήνα έγινε πέντε εβδομάδες νωρίτερα.

Η ευπάθεια εντοπίστηκε σε περίπου μία ώρα μέσω διαδικασίας υποβοηθούμενης από AI. Πρόκειται για ντετερμινιστικό λογικό σφάλμα, που δεν εξαρτάται από συνθήκες αγώνα ή συγκεκριμένες μετατοπίσεις του πυρήνα — ένα μόνο Python script 732 bytes μπορεί να το εκμεταλλευτεί επιτυχώς χωρίς τροποποίηση σε διαφορετικές διανομές Linux.

Το σφάλμα εισήχθη το 2017 μέσω του commit 72548b093ee3, που μετέτρεψε τις λειτουργίες AEAD σε επεξεργασία in-place. Συνδυάζοντας μια λειτουργία AF_ALG socket με splice(), ένας τοπικός χρήστης χωρίς δικαιώματα μπορεί να εκτελέσει μια ελεγχόμενη εγγραφή 4 bytes σε αυθαίρετη σελίδα της κρυφής μνήμης σελίδων, στοχεύοντας ένα setuid binary όπως το /usr/bin/su για να αποκτήσει κέλυφος root.

Η ευπάθεια επηρεάζει εκατομμύρια συστήματα με κύριες διανομές όπως Ubuntu, Amazon Linux, Red Hat Enterprise Linux, Debian, SUSE και AlmaLinux. Τρωτά είναι πυρήνες Linux από την έκδοση 4.14 έως 7.0-rc, καθώς και όλες οι εκδόσεις 6.18.x πριν από την 6.18.22 και 6.19.x πριν από την 6.19.12.

Τι αφαιρείται στο Linux 7.2

Παράλληλα με την επίσημη κατάργηση, το Linux 7.2 προχωρά σε δύο συγκεκριμένες αφαιρέσεις λειτουργικότητας. Η υποστήριξη zero-copy του AF_ALG αφαιρείται λόγω των σχετικών ζητημάτων ασφαλείας. Επίσης, αφαιρείται η υποστήριξη κρυπτογράφησης εκτός CPU, δηλαδή η δυνατότητα ανάθεσης λειτουργιών σε εξωτερικούς hardware επιταχυντές μέσω AF_ALG, καθώς κρίθηκε υπερβολικά επικίνδυνη για χρήση μέσω του AF_ALG.

Στο patch που τεκμηριώνει αυτή την αλλαγή αναφέρεται ότι η αφαίρεση εξαλείφει ένα από τα βασικά πλεονεκτήματα του AF_ALG — τη χρήση εξωτερικών επιταχυντών — αλλά η χρήση τους συνεπαγόταν υπερβολική επιβάρυνση τόσο σε επιδόσεις όσο και σε επιφάνεια επίθεσης, χωρίς πραγματικό κέρδος σε κρίσιμα φορτία εργασίας. Αν κάποια μελλοντική χρήση επιταχυντή αποδειχθεί αναγκαία, θα πρέπει να αναπτυχθεί νέο API.

AI ως εργαλείο εντοπισμού ευπαθειών: νέα πραγματικότητα για τον πυρήνα

Η υπόθεση AF_ALG αναδεικνύει μια ευρύτερη τάση: τα εργαλεία AI επιταχύνουν δραματικά τον ρυθμό ανακάλυψης ευπαθειών στον πυρήνα Linux. Το Copy Fail ανακαλύφθηκε από τον Taeyang Lee της Theori με τη βοήθεια του AI-based εργαλείου στατικής ανάλυσης κώδικα Xint Code, κατά τη διάρκεια ανάλυσης του κρυπτογραφικού υποσυστήματος του πυρήνα. Ο Biggers επισημαίνει στο patch κατάργησης ότι τα LLM έχουν επιταχύνει τον ρυθμό εισροής νέων ευπαθειών σε μη βιώσιμο επίπεδο.

Το παράθυρο ενσωμάτωσης αλλαγών του Linux 7.2 αναμένεται να ανοίξει στα μέσα Ιουνίου, με πολλές αλλαγές — τόσο νέα χαρακτηριστικά πυρήνα όσο και περαιτέρω αντιμετώπιση των ευπαθειών που εντοπίζονται μέσω AI/LLM εργαλείων.

Πηγές

Η Valve κυκλοφόρησε την έκδοση beta του SteamOS 3.8.6 στις 29 Μαΐου 2026, φέρνοντας μια από τις πιο πολυαναμενόμενες λειτουργίες για χρήστες AMD GPU στο Linux: αρχική εγγενή υποστήριξη Variable Refresh Rate (VRR) μέσω HDMI. Η λειτουργία απευθύνεται σε συσκευές που διαθέτουν native HDMI έξοδο και αξιοποιεί δουλειά που βρίσκεται ακόμα σε εξέλιξη για την ενσωμάτωσή της στον mainline πυρήνα Linux μέσω του οδηγού AMDGPU.

Χρόνια μπλοκαρισμένο από το HDMI Forum

Ο οδηγός AMDGPU στο Linux στερούνταν υποστήριξης για HDMI 2.1 και νεότερα, παρά το γεγονός ότι η AMD ήθελε να την υλοποιήσει, καθώς το HDMI Forum την εμπόδιζε νομικά. Το βασικό ζήτημα ήταν η πνευματική ιδιοκτησία: το Forum απαιτούσε από την AMD να κρατήσει εμπιστευτικό συγκεκριμένο IP γύρω από το HDMI, κάτι που ερχόταν σε άμεση αντίθεση με τη φιλοσοφία του ανοιχτού κώδικα του πυρήνα Linux.

Σύμφωνα με τον μηχανικό Linux της AMD, Harry Wentland, η εταιρεία είχε αναπτύξει τον σχετικό κώδικα ήδη από το 2024, αλλά το HDMI Forum είχε εμποδίσει την κυκλοφορία του, επικαλούμενο ανησυχίες για την έκθεση ιδιόκτητης πνευματικής ιδιοκτησίας σε ανοιχτού κώδικα στοίβες. Η Valve φέρεται να διαδραμάτισε καθοριστικό ρόλο παρασκηνιακά για να ξεμπλοκάρει το αδιέξοδο, ωθούμενη από την ανάγκη για υποστήριξη σύγχρονου HDMI στις Linux-based πλατφόρμες της, όπως το Steam Deck.

Η AMD υπέβαλε τελικά σειρά από patches για τον πυρήνα Linux στον οδηγό AMDGPU που εισάγουν υποστήριξη για το Fixed Rate Link (FRL) του HDMI 2.1. Η κίνηση αυτή ακολούθησε χρόνια απόρριψης από το HDMI Forum. Η αρχική αυτή υποστήριξη επιτρέπει υψηλότερη απόδοση bandwidth για τις Radeon GPU στο Linux, με ανάλυση έως 4K στα 120Hz και 5K στα 240Hz.

Γιατί το HDMI VRR στο SteamOS έρχεται πριν τον πυρήνα

Η AMD απενεργοποίησε προσωρινά το FRL ως προεπιλογή στα patches του πυρήνα, λόγω της υποστήριξης VRR: η ενεργοποίηση FRL χωρίς VRR θεωρείται υποβάθμιση για χρήστες με FRL-capable οθόνες. Μόλις η υποστήριξη VRR ολοκληρωθεί, αναμένεται να ενεργοποιηθεί και το FRL ως προεπιλογή. Αυτό εξηγεί ακριβώς γιατί η Valve επέλεξε να ενσωματώσει το HDMI VRR προληπτικά στο SteamOS 3.8.6 Beta: τα patches βρίσκονται ακόμα υπό δημόσια αξιολόγηση και ενδέχεται να ενσωματωθούν στον πυρήνα Linux 7.2 το καλοκαίρι του 2026.

Για τους gamers, το πρότυπο HDMI 2.1 είναι ιδιαίτερα χρήσιμο καθώς αυξάνει σημαντικά το bandwidth, υποστηρίζοντας μορφές όπως 4K στα 120Hz ή 8K στα 60Hz. Το πρότυπο υποστηρίζει επίσης VRR και DSC, αλλά αυτά ενδέχεται να χρειαστούν περισσότερο χρόνο για να λειτουργήσουν πλήρως στο Linux.

Τι άλλο φέρνει το SteamOS 3.8.6 Beta

Πέραν της υποστήριξης HDMI VRR, η Valve συμπεριέλαβε στην έκδοση beta υποστήριξη χειριστηρίων για τις φορητές συσκευές gaming MSI Claw και OneXPlayer APEX / X1, καθώς και βελτιώσεις στην ήδη υπάρχουσα υποστήριξη άλλων handheld συσκευών. Η έκδοση περιλαμβάνει επίσης διάφορες διορθώσεις σφαλμάτων.

Η κίνηση αυτή ακολουθεί μια πάγια τακτική της Valve: να προχωράει μπροστά από τον mainline πυρήνα Linux ενσωματώνοντας δυνατότητες που βρίσκονται σε στάδιο ανάπτυξης, αξιοποιώντας τη στενή συνεργασία της με την AMD. Το SteamOS τροφοδοτεί το Steam Deck και τις μελλοντικές του συσκευές, οι οποίες χρησιμοποιούν εξ ολοκλήρου AMD silicon.

Πηγές

• Phoronix: SteamOS 3.8.6 Beta Released With Initial Native Support For AMD HDMI VRR
• Steam: SteamOS 3.8.6 Beta — Official Changelog
• WCCFTech: AMD Finally Cracks HDMI 2.1 On Linux After Years Of Forum Lockout
• KitGuru: AMD submits HDMI 2.1 FRL patches for open-source Linux driver

Το Vivado είναι το κύριο εργαλείο σχεδίασης της AMD για προγραμματισμό FPGA (Field Programmable Gate Arrays) — ειδικών τσιπ που μπορούν να «ξαναγραφτούν» μέσω λογισμικού ώστε να προσομοιώνουν σχεδόν οποιοδήποτε υλικό, καθιστώντας τα ανεκτίμητα για προσομοιώσεις και δοκιμές σχεδίασης. Η εταιρεία ανακοίνωσε νέο μοντέλο αδειοδότησης με κατηγορίες, που τίθεται σε ισχύ με την έκδοση 2026.1 — και η αλλαγή αυτή δεν έγινε καλά δεκτή.

Τι αλλάζει από την έκδοση 2026.1

Το Vivado Design Suite περνά σε νέο μοντέλο αδειοδότησης με κατηγορίες από την έκδοση 2026.1, με επίπεδα BASIC, CORE, PRO (ετήσια συνδρομή) και ENTERPRISE, GOLD (μόνιμη άδεια).

Προηγουμένως, το δωρεάν επίπεδο «Standard» υποστήριζε τόσο Windows όσο και Linux. Με το νέο μοντέλο, το δωρεάν επίπεδο «Basic» περιορίζεται αποκλειστικά σε Windows. Όποιος θέλει να χρησιμοποιεί το Vivado σε Linux θα πρέπει να αναβαθμιστεί στο επίπεδο «Core», που απαιτεί ετήσια συνδρομή $1.200 έως $1.800.

Για μόνιμη (perpetual) άδεια με Linux, το κόστος ξεκινά από $5.000. Αυτό δημιουργεί μια ασύμμετρη κατάσταση όπου προγραμματιστές που δουλεύουν με το ίδιο υλικό καλούνται να πληρώσουν αποκλειστικά λόγω της επιλογής λειτουργικού.

Η κατακραυγή στα φόρουμ

Η AMD παρουσίασε τις αλλαγές στη σελίδα λήψης ως κίνηση προς «πιο ευέλικτη αδειοδότηση», ενώ στη σελίδα επιλογών άδειας ενημέρωνε τους δωρεάν χρήστες ότι η μόνη αλλαγή ήταν μια απλή ετήσια ανανέωση άδειας — χωρίς να αναφέρει τον αποκλεισμό του Linux.

Όταν οι χρήστες απευθύνθηκαν στο φόρουμ υποστήριξης της AMD, ο εκπρόσωπος Anatoli Curran ξεκίνησε την απάντησή του προειδοποιώντας για «κακό λεξιλόγιο ή καταχρηστική συμπεριφορά απέναντι στην AMD», προτού αντιμετωπίσει οποιοδήποτε ουσιαστικό ζήτημα. Στη συνέχεια πρότεινε στους δυσαρεστημένους να παραμείνουν στην έκδοση 2025.2.

Η AMD ισχυρίστηκε ότι το 70% των χρηστών Vivado χρησιμοποιεί Windows, αποξενώνοντας έτσι τους ακαδημαϊκούς ερευνητές, φοιτητές μηχανικής και hobbyists ανοιχτού κώδικα που προτιμούν το Linux και βασίζονται σε δωρεάν εργαλεία. «Υποθέτω ότι κανείς που συμμετείχε σε αυτή την απόφαση δεν σκέφτηκε τα εκατομμύρια hobbyists και ερασιτέχνες που χρησιμοποιούμε το Vivado για τα έργα μας», έγραψε χαρακτηριστικά ένας χρήστης.

Άλλοι χρήστες ήδη συζητούν τη μετάβαση σε εναλλακτικές πλατφόρμες όπως η Lattice και η Altera λόγω αυτών των αλλαγών.

Τι συμβαίνει με τις παλαιότερες εκδόσεις

Σύμφωνα με την AMD, η έκδοση Vivado ML Standard 2025.2 θα υποστηρίζεται επίσημα έως την κυκλοφορία της 2026.3, μετά την οποία παύουν οι διορθώσεις σφαλμάτων. Ωστόσο, οι χρήστες μπορούν να συνεχίσουν να τη χρησιμοποιούν χωρίς χρονικό όριο, αν δεν επιθυμούν αναβάθμιση.

Η αλλαγή πλήττει ιδιαίτερα τους κατόχους πλακετών Zynq, οι οποίοι δεν θα μπορούν να δημιουργήσουν εικόνα Linux για αυτές χωρίς πληρωμένη άδεια. Για το άμεσο μέλλον, η παραμονή στην 2025.2 προτείνεται ως λύση — αλλά δεν είναι μόνιμη.

Γιατί η απόφαση κρίνεται στρατηγικό λάθος

Η AMD συντηρεί ήδη Linux υποστήριξη για τα πληρωμένα επίπεδα, άρα η υποδομή υπάρχει. Το πρόσθετο κόστος για δωρεάν Linux υποστήριξη θα ήταν οριακό. Φοιτητές, hobbyists υλικού και ακαδημαϊκοί ερευνητές που βασίστηκαν σε εγγενή ροή εργασίας Linux αφήνονται χωρίς επιλογές — και πρόκειται για άτομα που συχνά καταλήγουν σε μηχανικούς και διευθυντές αγορών με πραγματική επιρροή σε αποφάσεις υλικού.

Ο εκπρόσωπος της AMD στο φόρουμ ανέφερε ότι «συλλέγουν όλες τις απαντήσεις και τις διαβιβάζουν στην αρμόδια ομάδα», αφήνοντας ανοιχτό το ενδεχόμενο αναθεώρησης της πολιτικής.

Πηγές

• Tom's Hardware — AMD leaves Linux FPGA users in the lurch with controversial Vivado licensing update
• It's FOSS — AMD Pulls a Bait-and-Switch on Linux Users with Vivado Licensing Changes
• AMD — Vivado Licensing Options (επίσημη σελίδα)
• Slashdot — AMD (Xilinx) is Excluding Linux From the Free Tier For Its FPGA Dev Tool

Οκτώ χρόνια διαπραγματεύσεων, δύο δικαστήρια, και μια αλυσίδα αναβολών που θα κούραζε οποιονδήποτε. Τον Αύγουστο του 2026, η υπόθεση Software Freedom Conservancy εναντίον Vizio φτάνει επιτέλους σε αίθουσα δικαστηρίου με ένορκους — και αυτό που θα κριθεί αφορά άμεσα κάθε αγοραστή έξυπνης τηλεόρασης.

Οκτώ χρόνια από το πρώτο αίτημα ως τη δίκη

Η Vizio ενημερώθηκε για πρώτη φορά για την παραβίαση της GPLv2 τον Αύγουστο του 2018, όταν η SFC ζήτησε τον πηγαίο κώδικα του SmartCast OS. Η Vizio ανταποκρίθηκε τον Ιανουάριο του 2019 παρέχοντας αυτό που ισχυριζόταν ότι ήταν ο πλήρης κώδικας, αλλά η SFC διαπίστωσε ότι έλειπαν αρχεία και scripts απαραίτητα για να μεταγλωττιστεί το λογισμικό σε εκτελέσιμη μορφή. Μετά από περισσότερα από ένα χρόνο διπλωματικών προσπαθειών, η SFC διαπίστωσε ότι η Vizio όχι μόνο αρνούνταν να συμμορφωθεί, αλλά είχε σταματήσει να απαντά σε ερωτήματα εντελώς από τον Ιανουάριο του 2020.

Τον Οκτώβριο του 2021, η SFC μήνυσε τη Vizio σε πολιτειακό δικαστήριο της Καλιφόρνιας. Η αγωγή υποβλήθηκε με την ιδιότητα τρίτου δικαιούχου (third-party beneficiary) της άδειας GPLv2 — δηλαδή ως αγοραστής συσκευής Vizio που έχει δικαιώματα από τη σύμβαση μεταξύ Vizio και των προγραμματιστών του Linux.

Η Vizio κατασκευάζει τηλεοράσεις που ενσωματώνουν δύο διαφορετικές εκδόσεις του πυρήνα Linux (με τη μία να τρέχει ως guest της άλλης) καθώς και άλλο λογισμικό υπό GPL ή LGPL. Η αγωγή αναφέρει συνολικά 25 διαφορετικά τεμάχια ανοιχτού κώδικα. Εκτός από τον πυρήνα Linux, ο GPL'd και LGPL'd κώδικας στο SmartCast περιλαμβάνει U-Boot, bash, gawk, tar, Glibc και FFmpeg.

Νομικό precedent: η GPL ως σύμβαση, όχι μόνο πνευματικά δικαιώματα

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

Αυτό σημαίνει ότι η SFC συνεχίζει με αγωγή παραβίασης σύμβασης σε πολιτειακό δικαστήριο. Και αν η SFC επικρατήσει, η αγωγή αυτή θα μπορούσε να εξουσιοδοτήσει τους χρήστες Vizio — ως τρίτους δικαιούχους — να επιβάλλουν άδειες ανοιχτού κώδικα, όχι μόνο οι κάτοχοι πνευματικών δικαιωμάτων.

Η Vizio προσπάθησε να μεταφέρει την υπόθεση από το Superior Court στο ομοσπονδιακό δικαστήριο, ελπίζοντας να αποφύγει το ζήτημα της σύμβασης και να υπερασπιστεί τη θέση της αποκλειστικά με βάση το ομοσπονδιακό δίκαιο πνευματικής ιδιοκτησίας. Η ομοσπονδιακή δικαστής Josephine Staton τάχθηκε με την SFC και έστειλε την υπόθεση πίσω στο Superior Court, αποφαινόμενη ότι ο νόμος για πνευματικά δικαιώματα δεν «καταλύει» (preempt) τους ισχυρισμούς παραβίασης σύμβασης.

Τον Δεκέμβριο του 2023, το Superior Court της Orange County απέρριψε την αίτηση της Vizio για Summary Judgment, επιτρέποντας στην υπόθεση να προχωρήσει. Το δικαστήριο έκρινε ότι η SFC έχει νομιμοποίηση (standing) να εκδικάσει την υπόθεση.

Αναβολές και προσωρινές αποφάσεις πριν την κύρια δίκη

Στις 8 Ιανουαρίου 2026, λίγο πριν ξεκινήσει η ακρόαση για τις προδικαστικές κινήσεις, η δικαστής Sandy Leal εξέδωσε εντολή που ανέβαλε την ακρόαση και αφαίρεσε ουσιαστικά τη δίκη από το ημερολόγιό της — ενώ η εκκίνησή της είχε οριστεί για τις 12 Ιανουαρίου 2026. Η επαναπρογραμματισμένη ακρόαση ορίστηκε για τις 26 Ιανουαρίου 2026, αλλά στις 08:15 εκείνης της ημέρας οι δικηγόροι ενημερώθηκαν από τον γραμματέα του δικαστηρίου ότι η ακρόαση αναβλήθηκε εκ νέου.

Τον Δεκέμβριο του 2025, η δικαστής Sandy N. Leal εξέδωσε προσωρινή απόφαση (tentative ruling) που υποστηρίζει τον ισχυρισμό της SFC ότι η Vizio έχει υποχρέωση να παρέχει στη SFC τον πλήρη πηγαίο κώδικα που καλύπτεται από άδειες ανοιχτού κώδικα για τηλεόραση που αγόρασε. Η προσωρινή απόφαση δεν είναι οριστική, αλλά αναγνωρίζει ότι συνάφθηκε άμεση σύμβαση μεταξύ SFC και Vizio, όταν ο διαχειριστής συστημάτων της SFC, Paul Visscher, ζήτησε τον πηγαίο κώδικα για τηλεόραση που είχε αγοράσει η SFC.

Τι διακυβεύεται — και γιατί αφορά κάθε αγοραστή έξυπνης τηλεόρασης

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

Η αγωγή στοχεύει ειδικά τη Vizio, αλλά η επίδρασή της θα μπορούσε να επεκταθεί και σε άλλα Linux-based λειτουργικά έξυπνων τηλεοράσεων, όπως το LG webOS, το Samsung Tizen και το Roku OS.

Η αγωγή δεν ζητά χρηματική αποζημίωση. Ζητά μόνο πρόσβαση στις τεχνικές πληροφορίες που οι άδειες copyleft πάντα απαιτούσαν. Αν η Vizio δεν συμμορφωνόταν με την GPL, θα είχε τη δυνατότητα να απενεργοποιήσει τηλεορά­σεις χρηστών ανά πάσα στιγμή μέσω της σύνδεσής τους στο διαδίκτυο, χωρίς γνώση ή συναίνεση. Εφόσον η Vizio συμμορφωθεί, εθελοντές και τρίτες οντότητες θα μπορούσαν να χρησιμοποιήσουν τον GPL κώδικα ως βάση για εναλλακτικό λογισμικό αντί του SmartCast.

«Αναμένουμε όλες οι εταιρείες που διανέμουν Linux και άλλο λογισμικό χρησιμοποιώντας συμφωνίες δικαιώματος επισκευής (right-to-repair) όπως η GPL στα προϊόντα τους να συμμορφώνονται με αυτές τις συμφωνίες», δήλωσε ο Denver Gingerich, διευθυντής συμμόρφωσης της SFC.

Πότε αναμένεται απόφαση

Η μακροχρόνια αγωγή για το Linux-based λογισμικό έξυπνης τηλεόρασης της Vizio οδεύει προς δίκη τον Αύγουστο, με την SFC να επικαλείται τους κανόνες GPL που υποχρεώνουν τη Vizio να δημοσιοποιήσει τον πλήρη πηγαίο κώδικα. Η SFC αναμένει απόφαση εντός τριών έως έξι μηνών από την ολοκλήρωση της δίκης, η οποία έχει προγραμματιστεί για τις 10 Αυγούστου 2026.

Η Vizio και η μητρική της Walmart δεν ανταποκρίθηκαν σε αιτήματα για σχόλιο από την Ars Technica.

Πηγές

• Ars Technica — Inside the fight to force Vizio to share Linux-based source code for its TV's OS (20 Μαΐου 2026)
• Software Freedom Conservancy — SFC v. Vizio Inc. (επίσημη σελίδα υπόθεσης)
• SFC Blog — Delays in Vizio Trial (26 Ιανουαρίου 2026)
• The Register — Judge may force Vizio to share source code under GPL (5 Δεκεμβρίου 2025)
• LWN.net — SFC v. VIZIO: who can enforce the GPL? (Ιανουάριος 2026)

Ο Lee Hutchinson του Ars Technica έκανε αυτές τις μέρες ένα απλό αλλά provocative κάλεσμα στην κοινότητά του: δείξτε μας το terminal σας. Η ανταπόκριση — με εκατοντάδες σχόλια — αποκαλύπτει κάτι που κάθε Linux user ξέρει καλά: το command line δεν είναι legacy. Είναι ενεργό battleground παραγωγικότητας και προσωπικής έκφρασης.

Γιατί το CLI κέρδισε — παρά τις προβλέψεις

Στις αρχές της δεκαετίας του '90, το graphical interface φαινόταν να έχει καταδικάσει το command line σε αχρηστία. Τελικά δεν έγινε αυτό. Το terminal παρέμεινε ο μόνος χώρος όπου ο χρήστης μπορεί να εκφραστεί με ακρίβεια — χωρίς να χρειάζεται να «δείξει» στον υπολογιστή τι θέλει, αλλά να του πει ακριβώς τι να κάνει. Αυτή η διαφορά ανάμεσα σε gesture και εντολή εξηγεί γιατί οι developers, sysadmins και power users εξακολουθούν να περνούν το μεγαλύτερο μέρος της μέρας τους σε ένα μαύρο παράθυρο με monospace γραμματοσειρά.

Zsh, Fish και το ερώτημα του σωστού shell

Στη σημερινή συζήτηση κυριαρχούν δύο shells εκτός Bash: το zsh και το fish. Το zsh προσφέρει εκτεταμένη δυνατότητα customization, ισχυρές scripting ικανότητες και ένα πλούσιο οικοσύστημα plugins και themes — κυρίως μέσω του framework Oh My Zsh. Έχει τεράστια, καθιερωμένη κοινότητα, ενώ το Oh My Zsh μόνο μετράει πάνω από 170.000 stars στο GitHub.

Από την άλλη, το fish έρχεται με syntax highlighting, auto-suggestions και ένα καινοτόμο web-based configuration interface — όλα χωρίς να χρειαστεί εγκατάσταση ούτε ενός plugin. Είναι σχεδιασμένο για ταχύτητα και έχει γενικά γρηγορότερους χρόνους εκκίνησης από ένα βαριά configured zsh, καθώς τα built-in χαρακτηριστικά του δεν επιβραδύνουν την απόδοση όπως τα πολλαπλά plugins του zsh.

Το zsh είναι πλέον το default shell σε macOS 10.15 (Catalina) και νεότερα. Σε Windows 10/11, η προτεινόμενη λύση είναι WSL/WSL2 με Ubuntu και zsh εγκατεστημένο εκεί.

Starship: το cross-shell prompt που κερδίζει έδαφος

Ένα από τα πιο συζητημένα εργαλεία τελευταία είναι το Starship. Πρόκειται για ένα minimal, blazing-fast και εξαιρετικά customizable prompt για οποιοδήποτε shell. Γραμμένο σε Rust, το Starship είναι σημαντικά ταχύτερο από τα παραδοσιακά shell themes, με ελάχιστο startup time και zero noticeable delay στο άνοιγμα νέων terminal sessions.

Σε αντίθεση με το Oh My Zsh ή το Fisher, το Starship δεν είναι δεμένο με ένα συγκεκριμένο shell — λειτουργεί με Bash, Zsh, Fish, Elvish, Ion και ακόμα και PowerShell, υποστηρίζοντας segment rendering, Git status, runtime version display και command timing με ελάχιστο overhead. Το declarative configuration model του (αρχείο starship.toml) το κάνει ιδανικό για ομάδες που θέλουν συνεπές prompt σε Mac, WSL, Docker κ.ά.

Nerd Fonts και το αισθητικό κομμάτι

Ένα customized terminal χωρίς κατάλληλη γραμματοσειρά είναι μισή δουλειά. Τα Nerd Fonts παίρνουν δημοφιλείς programming fonts και προσθέτουν extra glyphs και icons για καλύτερη υποστήριξη στα shell tools. Πριν από κάθε εγκατάσταση του Starship, προτείνεται η εγκατάσταση ενός Nerd Font στο terminal — αυτά τα fonts παρέχουν τα special symbols και icons που κάνουν το Starship να φαίνεται εντυπωσιακό.

Customization ως εργαλείο παραγωγικότητας

Πέρα από την αισθητική, η κοινότητα είναι σαφής: το να προσαρμόζεις το shell σου δεν είναι ματαιοδοξία — είναι μείωση cognitive load. Διαβάζεις complex Git status με μια ματιά, ψάχνεις στο command history σαν να ψάχνεις στη μνήμη σου, και στήνεις ολόκληρα environments με ένα alias.

Τα plugins δεν είναι απλώς add-ons — ορίζουν την «προσωπικότητα» του shell. Η εμπειρία σου στο terminal — το syntax highlighting, το tab completion, το visual context του Git repo — προέρχεται εξ ολοκλήρου από αυτά.

Το κάλεσμα του Ars Technica έχει μαζέψει ήδη δεκάδες screenshots από setups που κυμαίνονται από λιτά vanilla bash configs έως πολύχρωμα zsh environments με Powerlevel10k, tmux panes και custom color schemes όπως το Gruvbox. Αν έχεις και εσύ κάτι να δείξεις, η συζήτηση είναι ανοιχτή.

Πηγές

• Ars Technica — Ars Asks: Share your shell and show us your tricked-out terminals!
• Starship — Cross-Shell Prompt (starship.rs)
• Medium — Zsh vs Fish: The Ultimate Shell Showdown for 2025
• AN4T — Linux Shell Customization 2025: Ultimate Guide

Ο Andy Nguyen, γνωστός στην κοινότητα ως TheFlow, κυκλοφόρησε στις 30 Απριλίου 2026 τον ps5-linux loader στο GitHub. Το project επιτρέπει σε PS5 Phat consoles με firmware 3.xx ή 4.xx να εκκινήσουν Ubuntu Linux, μετατρέποντας την κονσόλα σε πλήρες Linux gaming PC. Ο Nguyen είχε πρωτοπαρουσιάσει τη λειτουργία τον Μάρτιο με ένα βίντεο που έδειχνε το GTA V Enhanced να τρέχει με ray tracing.

Τι περιλαμβάνει το release

Σύμφωνα με τα αποθετήρια και τις αναφορές, το package περιλαμβάνει: Linux payload που εκμεταλλεύεται ένα patched hypervisor vulnerability, build script που παράγει bootable Ubuntu 24.04/26.04 image, εργαλεία για εγκατάσταση σε M.2 SSD (για firmware 4.xx), καθώς και fan και CPU/GPU boost control utility. Για την εκτέλεση απαιτείται USB drive τουλάχιστον 64GB, USB Ethernet ή WLAN adapter, καθώς και πληκτρολόγιο και ποντίκι. Το DualSense controller λειτουργεί μόνο μέσω Bluetooth dongle.

Hardware που αξιοποιείται

Μόλις εκκινηθεί το Linux, το PS5 εκθέτει πλήρως τον υλικό του: 8 Zen 2 CPU cores (16 threads) στα έως 3,5 GHz, RDNA 2 GPU στα έως 2,23 GHz, και HDMI έξοδο 4K/60Hz. Ο Nguyen σημειώνει ότι η υψηλότερη ανανέωση (πάνω από 60Hz) είναι στα σχέδια για μελλοντική έκδοση, μαζί με λειτουργία rest mode που θα επιτρέπει στο PS5 να επαναφορτώνει αυτόματα το Linux μετά από standby.

Πρώιμα tests έδειξαν το GTA V Enhanced να τρέχει στα 60fps σε 1440p με ray tracing και dynamic VRAM ενεργό. Ο Nguyen ισχυρίζεται ότι το Linux τρέχει «εκπληκτικά καλά» στη συσκευή και ξεκλειδώνει το «πλήρες hardware δυναμικό» της.

Περιορισμοί και συμβατότητα

Το ps5-linux είναι soft-mod: δεν εγκαθίσταται μόνιμα, δεν τροποποιεί το εσωτερικό SSD και το exploit πρέπει να επανεκτελείται κάθε φορά που ο χρήστης θέλει να εκκινήσει Linux. Μετά από reboot, η κονσόλα επιστρέφει κανονικά σε PS5 mode. Υποστηρίζονται μόνο τα PS5 Phat models με firmware 3.00, 3.10, 3.20, 3.21, 4.00, 4.02, 4.03, 4.50 ή 4.51. Το firmware 5.xx έχει αντιμετωπίσει εν μέρει το vulnerability — εκεί το Linux θα έτρεχε εντός του hypervisor VM με περιορισμένες δυνατότητες.

Υπάρχουν επίσης γνωστά προβλήματα με ορισμένες οθόνες σε ανάλυση 1440p και 4K μέσω HDMI, ενώ το Linux δεν διαθέτει ακόμη drivers για αρκετά hardware στοιχεία του PS5 — power management και standby δεν λειτουργούν προς το παρόν.

Προσδοκία για ProsperoOS vs Linux

Ο Nguyen ξεκαθάρισε ότι το PS5 δεν «τρέχει ήδη Linux»: «Χρησιμοποιεί ProsperoOS, το οποίο είναι μια βαριά τροποποιημένη έκδοση του FreeBSD 11», έγραψε. Το project αποσκοπεί σε αυτό που η Sony έκανε με το OtherOS στο PS3 πριν το αφαιρέσει το 2010 — πλέον ανεπίσημα και με community-driven τρόπο. Ο Nguyen αναφέρει contributors τους c0w, resulknad, flatz, και τις ομάδες fail0verflow και ps5-payload-dev.

Πηγές

• Cybernews — PS5 hacked to run Linux, Steam games, and any other code
• Tom's Hardware — PS5 Linux loader goes public
• Engadget — Modder releases loader to turn the PS5 into a Linux system
• Hackaday — Running Linux on the PS5 with a hypervisor exploit
• VideoCardz — PS5 Linux project released

Η κοινότητα ανάπτυξης του Linux kernel αντιμετωπίζει ένα νέο και απρόσμενο πρόβλημα: την έκρηξη αυτοματοποιημένων αναφορών σφαλμάτων που παράγονται από εργαλεία τεχνητής νοημοσύνης. Το φαινόμενο αυτό έχει αρχίσει να επηρεάζει άμεσα τις αποφάσεις σχετικά με το ποιοι παλαιοί drivers θα συνεχίσουν να υποστηρίζονται στον πυρήνα.

Από ISA και PCMCIA σε... αχρηστία

Ο γνωστός kernel developer Andrew Lunn υπέβαλε πρόσφατα μια σειρά από patches με σκοπό την αφαίρεση αρκετών παλαιών network drivers εποχής ISA και PCMCIA από τον Linux kernel. Πρόκειται για drivers που αφορούν hardware κυριολεκτικά δεκαετιών, το οποίο στην πράξη δεν χρησιμοποιείται πλέον από κανέναν σε σύγχρονο σύστημα με upstream kernel.

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

Το πρόβλημα: AI bug reports χωρίς νόημα

Η ουσία του ζητήματος έγκειται στο εξής: εργαλεία fuzzing και AI-driven ανίχνευσης σφαλμάτων εντοπίζουν πιθανά προβλήματα σε κώδικα παλαιών drivers και δημιουργούν αυτόματα αναφορές προς τους maintainers του kernel. Το πρόβλημα είναι ότι οι drivers αυτοί αφορούν hardware για το οποίο πιθανότατα δεν υπάρχει κανένας πραγματικός χρήστης — κάνοντας αυτές τις αναφορές ουσιαστικά άχρηστες, αλλά εξαιρετικά χρονοβόρες για να αντιμετωπιστούν.

Οι developers του Linux kernel βρίσκονται μπροστά σε δύο επιλογές: είτε να αγνοούν τις AI-driven αναφορές, είτε να αφαιρέσουν εντελώς τους παλιούς drivers ώστε να εξαλείψουν την πηγή του προβλήματος για hardware που κανείς δεν χρησιμοποιεί.

Το ευρύτερο πλαίσιο: «AI slop» στο open source

Το φαινόμενο αυτό δεν είναι καινούριο για την κοινότητα του Linux. Ο Greg Kroah-Hartman, από τους κορυφαίους maintainers του kernel, είχε αναφερθεί πρόσφατα στο λεγόμενο «AI slop» — δηλαδή αναφορές ασφαλείας προφανώς λανθασμένες ή χαμηλής ποιότητας που παράγονται από AI. Η επιβάρυνση από τέτοιες αναφορές είναι ιδιαίτερα αισθητή για drivers με μικρή ή μηδενική χρηστική βάση, όπου το κόστος συντήρησης ξεπερνά κατά πολύ οποιοδήποτε όφελος.

Αξίζει να σημειωθεί ότι παρόμοια προβλήματα έχουν αντιμετωπίσει και άλλα open source projects: το project cURL, για παράδειγμα, αναγκάστηκε να σταματήσει να πληρώνει bug bounties εξαιτίας της πλημμύρας AI-generated αναφορών.

Τι σημαίνει αυτό για τους χρήστες

Για την τεράστια πλειοψηφία των σύγχρονων χρηστών Linux, η αφαίρεση αυτών των drivers δεν θα έχει καμία πρακτική επίπτωση. Τα hardware ISA και PCMCIA ανήκουν σε μια άλλη εποχή της πληροφορικής. Ωστόσο, η εξέλιξη αυτή αποτελεί ένα σημαντικό σημείο καμπής: για πρώτη φορά, η παρουσία AI εργαλείων επηρεάζει άμεσα αποφάσεις για τη δομή και τη συντήρηση του Linux kernel — και αυτό είναι κάτι που η κοινότητα θα πρέπει να αντιμετωπίσει συστηματικά στο μέλλον.

Πηγές

• Tom's Hardware
• Phoronix
• The Register

Η Universal Blue, δημιουργός της gaming διανομής Bazzite, ανακοίνωσε τη δημιουργία του Open Gaming Collective (OGC), μιας συνεργατικής προσπάθειας που φέρνει κοντά βασικούς παίκτες του οικοσυστήματος. Σύμφωνα με το ίδιο το OGC, “ιδρυτικά μέλη” εμφανίζονται οι Universal Blue & Bazzite, ASUS Linux, ShadowBlip, PikaOS και Fyra Labs, ενώ ως στενοί συνεργάτες/βασικοί συνεισφέροντες αναφέρονται projects όπως ChimeraOS, Nobara και Playtron.

Στο ευρύτερο κάδρο των συμμετεχόντων αναφέρονται επίσης η Nobara, το ChimeraOS, το Playtron, η Fyra Labs (συχνά μαζί με το Ultramarine), το PikaOS, το ShadowBlip και το ASUS Linux, με κοινό στόχο να περιοριστεί ο κατακερματισμός που δημιουργείται όταν κάθε project συντηρεί ξεχωριστά patches και “ιδιότυπες” λύσεις υποστήριξης hardware.

Τι επιδιώκει να πετύχει το OGC

Αντί κάθε διανομή να αναπτύσσει μόνη της βελτιώσεις, patches και μηχανισμούς υποστήριξης συσκευών, το OGC στοχεύει να κάνει την πρόοδο “μεταφερόμενη” σε όλο το οικοσύστημα. Όπως έχει περιγραφεί από τον Kyle Gospodnetich (Bazzite), η λογική είναι να κεντροποιηθούν προσπάθειες σε κρίσιμα στρώματα, όπως διορθώσεις πυρήνα (kernel patches), εργαλεία input και βασικά gaming components όπως το gamescope (compositor που χρησιμοποιείται ευρέως σε gaming σενάρια, π.χ. τύπου Steam Deck).

Κομβικό σημείο είναι η φιλοσοφία “upstream first”. Πρακτικά, αυτό σημαίνει ότι ο κώδικας και οι βελτιώσεις που αναπτύσσονται στο πλαίσιο του OGC δεν προορίζονται να μείνουν ως μόνιμα, απομονωμένα patches, αλλά να καταλήγουν, όπου είναι εφικτό, για ενσωμάτωση στα upstream projects (π.χ. στον Linux kernel ή σε επίσημα repos σχετικών components), ώστε να έχουν μεγαλύτερη διάρκεια ζωής και να ωφελούν περισσότερους χρήστες και διανομές.

Αλλαγές στο Bazzite, OGC kernel και μετάβαση σε InputPlumber

Ένα από τα πρώτα χειροπιαστά παραδείγματα είναι το ίδιο το Bazzite. Η διανομή αναμένεται να υιοθετήσει τον κοινό OGC kernel και να αντικαταστήσει το HHD (Handheld Daemon) με το InputPlumber, ένα πιο σύγχρονο input framework που χρησιμοποιείται ήδη από SteamOS, ChimeraOS, Nobara και άλλα projects.

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

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

Πηγές

• Open Gaming Collective, “The Future of Linux Gaming” (OGC site)
• Universal Blue (Bazzite forum), “A brighter future for Bazzite”
• The Verge, “Linux gaming developers join forces to form the Open Gaming Collective”