Ειδήσεις: Ειδήσειςhttps://www.thelab.gr/news/linux/?d=1Ειδήσεις: ΕιδήσειςelΤο λογισμικό της τηλεόρασής σου παρακολουθεί τι βλέπεις — αυτή η δίκη μπορεί να το αλλάξειhttps://www.thelab.gr/news/linux/%CF%84%CE%BF-%CE%BB%CE%BF%CE%B3%CE%B9%CF%83%CE%BC%CE%B9%CE%BA%CF%8C-%CF%84%CE%B7%CF%82-%CF%84%CE%B7%CE%BB%CE%B5%CF%8C%CF%81%CE%B1%CF%83%CE%AE%CF%82-%CF%83%CE%BF%CF%85-%CF%80%CE%B1%CF%81%CE%B1%CE%BA%CE%BF%CE%BB%CE%BF%CF%85%CE%B8%CE%B5%CE%AF-%CF%84%CE%B9-%CE%B2%CE%BB%CE%AD%CF%80%CE%B5%CE%B9%CF%82-%E2%80%94-%CE%B1%CF%85%CF%84%CE%AE-%CE%B7-%CE%B4%CE%AF%CE%BA%CE%B7-%CE%BC%CF%80%CE%BF%CF%81%CE%B5%CE%AF-%CE%BD%CE%B1-%CF%84%CE%BF-%CE%B1%CE%BB%CE%BB%CE%AC%CE%BE%CE%B5%CE%B9-r11734/

  • Η Software Freedom Conservancy (SFC) μηνύει τη Vizio από το 2021 απαιτώντας τον πλήρη πηγαίο κώδικα του SmartCast OS, που βασίζεται σε Linux — χωρίς να ζητά χρηματική αποζημίωση.
  • Η δίκη με ένορκους έχει οριστεί για τις 10 Αυγούστου 2026 στην Καλιφόρνια, μετά από σειρά αναβολών από το 2021.
  • Ακόμη και αν η αγωγή στοχεύει μόνο τη Vizio, το αποτέλεσμα μπορεί να επηρεάσει και άλλα Linux-based TV λειτουργικά, όπως το LG webOS, το Samsung Tizen και το Roku OS.

Οκτώ χρόνια διαπραγματεύσεων, δύο δικαστήρια, και μια αλυσίδα αναβολών που θα κούραζε οποιονδήποτε. Τον Αύγουστο του 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.

Πηγές

]]>11734Fri, 22 May 2026 08:05:16 +0000Terminal Pride: Το κάλεσμα του Ars Technica για τα πιο tricked-out shells σαςhttps://www.thelab.gr/news/linux/terminal-pride-%CF%84%CE%BF-%CE%BA%CE%AC%CE%BB%CE%B5%CF%83%CE%BC%CE%B1-%CF%84%CE%BF%CF%85-ars-technica-%CE%B3%CE%B9%CE%B1-%CF%84%CE%B1-%CF%80%CE%B9%CE%BF-tricked-out-shells-%CF%83%CE%B1%CF%82-r11635/

  • Το Ars Technica καλεί τους αναγνώστες να μοιραστούν τα customized terminals και shells τους — αφορμή για μια κουβέντα για το γιατί το CLI παραμένει το πιο ισχυρό εργαλείο του developer.
  • Τα πιο δημοφιλή setups συνδυάζουν zsh ή fish με frameworks όπως το Oh My Zsh ή το Starship, ένα cross-shell prompt γραμμένο σε Rust.
  • Η προσαρμογή του terminal δεν είναι αισθητική — μειώνει το cognitive load, επιταχύνει τη ροή εργασίας και κάνει ορατό context (git branch, k8s, runtimes) με μια ματιά.

Ο 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. Αν έχεις και εσύ κάτι να δείξεις, η συζήτηση είναι ανοιχτή.

Πηγές

]]>11635Thu, 07 May 2026 08:01:49 +0000PS5 σε Linux PC: Ο security researcher Andy Nguyen έδωσε δωρεάν στο κοινό τον loaderhttps://www.thelab.gr/news/linux/ps5-%CF%83%CE%B5-linux-pc-%CE%BF-security-researcher-andy-nguyen-%CE%AD%CE%B4%CF%89%CF%83%CE%B5-%CE%B4%CF%89%CF%81%CE%B5%CE%AC%CE%BD-%CF%83%CF%84%CE%BF-%CE%BA%CE%BF%CE%B9%CE%BD%CF%8C-%CF%84%CE%BF%CE%BD-loader-r11618/

  • Ο security engineer Andy Nguyen (γνωστός ως TheFlow) κυκλοφόρησε δωρεάν στο GitHub έναν πλήρη Linux loader για PS5 Phat consoles με firmware 3.xx και 4.xx.
  • Το σύστημα εκμεταλλεύεται ένα patched hypervisor vulnerability, εκθέτει τους 8 Zen 2 CPU cores και την RDNA 2 GPU του PS5 απευθείας στο Linux, με υποστήριξη 4K/60Hz εξόδου.
  • Πρόκειται για soft-mod — δεν τροποποιεί το εσωτερικό SSD και το exploit πρέπει να εκτελείται εκ νέου σε κάθε εκκίνηση Linux.

Ο 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.

Πηγές

]]>11618Mon, 04 May 2026 14:22:06 +0000Το Linux εξετάζει την κατάργηση παλιών drivers δικτύου λόγω πλημμύρας ψεύτικων αναφορών σφαλμάτων από AIhttps://www.thelab.gr/news/linux/%CF%84%CE%BF-linux-%CE%B5%CE%BE%CE%B5%CF%84%CE%AC%CE%B6%CE%B5%CE%B9-%CF%84%CE%B7%CE%BD-%CE%BA%CE%B1%CF%84%CE%AC%CF%81%CE%B3%CE%B7%CF%83%CE%B7-%CF%80%CE%B1%CE%BB%CE%B9%CF%8E%CE%BD-drivers-%CE%B4%CE%B9%CE%BA%CF%84%CF%8D%CE%BF%CF%85-%CE%BB%CF%8C%CE%B3%CF%89-%CF%80%CE%BB%CE%B7%CE%BC%CE%BC%CF%8D%CF%81%CE%B1%CF%82-%CF%88%CE%B5%CF%8D%CF%84%CE%B9%CE%BA%CF%89%CE%BD-%CE%B1%CE%BD%CE%B1%CF%86%CE%BF%CF%81%CF%8E%CE%BD-%CF%83%CF%86%CE%B1%CE%BB%CE%BC%CE%AC%CF%84%CF%89%CE%BD-%CE%B1%CF%80%CF%8C-ai-r11551/

  • Ο developer Andrew Lunn υπέβαλε patch series για αφαίρεση παλαιών ISA και PCMCIA network drivers από τον πυρήνα του Linux.
  • Η κύρια αιτία είναι η έκρηξη AI-generated bug reports και fuzzing που δημιουργούν τεράστιο φόρτο συντήρησης για drivers που ουσιαστικά δεν έχουν χρήστες.
  • Το Linux είναι ιστορικά γνωστό για την υποστήριξη παλιού hardware, αλλά η νέα πραγματικότητα του AI αναγκάζει σε επανεξέταση αυτής της πολιτικής.

Η κοινότητα ανάπτυξης του 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 — και αυτό είναι κάτι που η κοινότητα θα πρέπει να αντιμετωπίσει συστηματικά στο μέλλον.

Πηγές

]]>11551Wed, 22 Apr 2026 17:01:38 +0000Αυτοδιαδιδόμενο malware δηλητηριάζει open source λογισμικό και σβήνει δεδομένα σε ιρανικά συστήματαhttps://www.thelab.gr/news/linux/%CE%B1%CF%85%CF%84%CE%BF%CE%B4%CE%B9%CE%B1%CE%B4%CE%B9%CE%B4%CF%8C%CE%BC%CE%B5%CE%BD%CE%BF-malware-%CE%B4%CE%B7%CE%BB%CE%B7%CF%84%CE%B7%CF%81%CE%B9%CE%AC%CE%B6%CE%B5%CE%B9-open-source-%CE%BB%CE%BF%CE%B3%CE%B9%CF%83%CE%BC%CE%B9%CE%BA%CF%8C-%CE%BA%CE%B1%CE%B9-%CF%83%CE%B2%CE%AE%CE%BD%CE%B5%CE%B9-%CE%B4%CE%B5%CE%B4%CE%BF%CE%BC%CE%AD%CE%BD%CE%B1-%CF%83%CE%B5-%CE%B9%CF%81%CE%B1%CE%BD%CE%B9%CE%BA%CE%AC-%CF%83%CF%85%CF%83%CF%84%CE%AE%CE%BC%CE%B1%CF%84%CE%B1-r11463/

  • Το TeamPCP εκμεταλλεύτηκε την ατελή ανάκληση credentials της Aqua Security για να μολύνει πάνω από 66 npm packages με το αυτοδιαδιδόμενο worm CanisterWorm, το οποίο χρησιμοποιεί ICP blockchain canister ως C2 υποδομή.
  • Μεταγενέστερη έκδοση του CanisterWorm περιέχει το wiper Kamikaze, το οποίο, σύμφωνα με ερευνητές, στοχεύει αποκλειστικά μηχανές με timezone ή locale που αντιστοιχεί στο Ιράν.
  • Η αρχική παραβίαση ξεκίνησε από misconfigured GitHub Actions workflow στο Trivy τον Φεβρουάριο, ενώ η Aqua Security επιβεβαίωσε ότι η παρουσία του επιτιθέμενου στην υποδομή της δεν έχει ακόμη πλήρως εξαλειφθεί.

Η ομάδα TeamPCP εκτόξευσε τις τελευταίες εβδομάδες του Μαρτίου 2026 ένα πολυεπίπεδο supply chain attack που ξεκίνησε από τον δημοφιλή open source vulnerability scanner Trivy της Aqua Security και κατέληξε στη διασπορά ενός αυτοδιαδιδόμενου worm στο npm registry, με ενσωματωμένο wiper που στοχεύει συστήματα στο Ιράν. Το worm, το οποίο η Aikido Security ονόμασε CanisterWorm, εντοπίστηκε στις 20 Μαρτίου 2026 και αποτελεί, σύμφωνα με ερευνητές, άμεση συνέχεια της παραβίασης του Trivy που είχε προηγηθεί.

Από το Trivy στο npm: η αλυσίδα της παραβίασης

Η επιθετική αλυσίδα ξεκίνησε στα τέλη Φεβρουαρίου, όταν το TeamPCP εκμεταλλεύτηκε ένα misconfiguration στο GitHub Actions component του Trivy και έκλεψε ένα privileged access token από την Aqua Security. Παρόλο που η εταιρεία προσπάθησε να αντικαταστήσει τα credentials, η διαδικασία ήταν ατελής. Πιο συγκεκριμένα, ένα bot που αναγνωρίστηκε ως hackerbot-claw εκμεταλλεύτηκε ένα misconfigured pull_request_target workflow στο GitHub Actions του Trivy για να κλέψει ένα Personal Access Token (PAT). Η ομάδα παρακολουθείται επίσης υπό τα ονόματα DeadCatx3, PCPcat, ShellForce και CipherForce.

Με το κλεμμένο token, ο επιτιθέμενος force-pushed malicious commits σε 75 από τα 76 version tags του aquasecurity/trivy-action και σε 7 tags του aquasecurity/setup-trivy, αντικαθιστώντας ουσιαστικά το νόμιμο scanner με ένα credential harvester σε χιλιάδες CI/CD pipelines. Οι malicious εκδόσεις εκτελούσαν ένα εργαλείο που περιγραφόταν ως "TeamPCP Cloud stealer", το οποίο αντλούσε μνήμη από τη διεργασία Runner.Worker, συλλέγοντας SSH keys, cloud credentials και Kubernetes secrets, κρυπτογραφώντας τα δεδομένα με AES-256 και RSA-4096, και εξάγοντάς τα σε remote server. Κρίσιμη λεπτομέρεια: το malware εκτελούνταν πριν από τη νόμιμη λογική σάρωσης του Trivy, οπότε τα compromised workflows φαίνονταν να ολοκληρώνονται κανονικά ενώ σιωπηλά εξάγονταν δεδομένα.

Η επίθεση Trivy και η εκστρατεία CanisterWorm εκτελέστηκαν μέσα σε παράθυρο 24 ωρών, και τα npm tokens που συλλέχθηκαν από την παραβίαση του Trivy τροφοδότησαν άμεσα το πρώτο κύμα μολύνσεων. Σύμφωνα με την εταιρεία ασφάλειας Socket, η supply chain επίθεση του CanisterWorm επεκτάθηκε σε 141 malicious package artifacts που καλύπτουν πάνω από 66 μοναδικά packages. Η εκστρατεία παρακολουθείται υπό το CVE-2026-33634 με CVSS score 9.4.

CanisterWorm: αυτοδιάδοση μέσω npm και blockchain C2

Το CanisterWorm είναι σχεδιασμένο αποκλειστικά για Linux συστήματα. Μόλις εγκατασταθεί, εγκαθιδρύει ένα persistent backdoor που επιβιώνει μετά από reboot χρησιμοποιώντας systemd, και συνδέεται σε command-and-control server χτισμένο στο Internet Computer Protocol (ICP), ένα decentralized blockchain network. Επειδή το ICP δεν έχει ενιαίο host ή provider, η C2 υποδομή δεν μπορεί να κατεβεί μέσω συμβατικού takedown request, κάνοντας το CanisterWorm το πρώτο δημοσίως τεκμηριωμένο npm worm που χρησιμοποιεί αυτή την τεχνική.

Ο τρόπος διάδοσης είναι αλυσιδωτός: κάθε developer ή CI pipeline που εγκαθιστά ένα μολυσμένο package και έχει προσβάσιμο npm token γίνεται εν αγνοία του vector διάδοσης. Τα packages του μολύνονται, οι downstream χρήστες τα εγκαθιστούν, και αν κάποιος από αυτούς έχει tokens, ο κύκλος επαναλαμβάνεται. Ερευνητές παρατήρησαν το worm να στοχεύει 28 packages σε λιγότερο από 60 δευτερόλεπτα. Ο κώδικας του CanisterWorm εκτιμάται από ερευνητές ότι αναπτύχθηκε γρήγορα με AI βοήθεια, δεν είναι obfuscated, και η λογική είναι γραμμένη ρητά και αναγνώσιμα. Ο επιτιθέμενος έδωσε προτεραιότητα στην ταχύτητα ανάπτυξης και διάδοσης έναντι της απόκρυψης.

Το wiper Kamikaze και οι ιρανικοί στόχοι

Σε σημαντική κλιμάκωση, μεταγενέστερες εκδόσεις του CanisterWorm περιέλαβαν ένα νέο payload με το όνομα "Kamikaze", ένα data wiper που στοχεύει αποκλειστικά μηχανές στο Ιράν. Σύμφωνα με ερευνητές της Aikido, το malware είναι χτισμένο για να καταστρέψει οποιαδήποτε μηχανή αντιστοιχεί στο timezone και locale του Ιράν. Αν πληρούνται και οι δύο συνθήκες, το script αναπτύσσει ένα DaemonSet με το όνομα "host-provisioner-iran" στο "kube-system", το οποίο χρησιμοποιεί privileged containers και προσαρτά το host root filesystem. Κάθε pod τρέχει ένα Alpine container με το όνομα "kamikaze" που διαγράφει όλους τους top-level φακέλους του host filesystem και στη συνέχεια αναγκάζει το σύστημα σε reboot.

Σε μηχανές με Ιράν που δεν εκτελούν Kubernetes, το worm εκτελεί απευθείας "rm -rf / --no-preserve-root". Η τελευταία έκδοση του CanisterWorm έχει εξελιχθεί πέρα από τη στήριξη στο Kubernetes για διάδοση: περιλαμβάνει πλέον αυτόνομες δυνατότητες lateral movement μέσω κλοπής SSH keys και εκμετάλλευσης Docker APIs. Το script αναλύει ενεργά authentication logs για να εξάγει ενεργές IP διευθύνσεις και usernames από επιτυχημένες συνδέσεις, και χρησιμοποιεί τα ανακαλυφθέντα private SSH keys για να διαδοθεί σε γειτονικές μηχανές.

Η συνεχιζόμενη παρουσία στην υποδομή της Aqua Security

Παράλληλα, το TeamPCP παραβίασε και τους 44 internal repositories του GitHub organization "aquasec-com" της Aqua Security, μετονομάζοντάς τους με πρόθεμα "tpcp-docs-" και εκθέτοντάς τους δημόσια. Το "aquasec-com" account είναι διαφορετικό από το "aquasecurity" organization που φιλοξενεί το Trivy. Οι αποθετήρια περιλαμβάνουν source code για το Tracee, εσωτερικά Trivy forks, CI/CD pipelines, Kubernetes operators και team knowledge bases. Σύμφωνα με ανάλυση, όλα τα repositories τροποποιήθηκαν σε scripted burst 2 λεπτών, μεταξύ 20:31:07 UTC και 20:32:26 UTC στις 22 Μαρτίου 2026.

Επιπλέον, ο επιτιθέμενος δημοσίευσε malicious Docker images για το Trivy (tags 0.69.5 και 0.69.6) στο Docker Hub περίπου στις 16:00 UTC στις 22 Μαρτίου, ενώ και οι δύο ενέργειες επιβεβαιώνουν ότι ο επιτιθέμενος είχε επαναποκτήσει πρόσβαση στην υποδομή της Aqua Security μετά την αρχική προσπάθεια containment. Σε επίσημη ενημέρωση στις 23 Μαρτίου 2026, η Aqua Security ανέφερε ότι η έρευνά της "επικεντρώνεται ενεργά στην επαλήθευση ότι όλα τα access paths έχουν εντοπιστεί και πλήρως κλειστεί", προσθέτοντας ότι δεν υπάρχει ένδειξη ότι τα commercial products της επηρεάστηκαν. Σύμφωνα με αναφορές ως τις 25 Μαρτίου, το TeamPCP είχε στραφεί από κλοπή credentials σε ενεργό εκβιασμό, διαθέτοντας περίπου 300 GB συμπιεσμένων κλεμμένων credentials και φέρεται να συνεργάζεται με την ομάδα εκβιασμού LAPSUS$ για να στοχεύσει εταιρείες πολλών δισεκατομμυρίων δολαρίων.

Το κίνητρο και οι συστάσεις ασφαλείας

Σε προφίλ της ομάδας που δημοσιεύτηκε τον Ιανουάριο, η εταιρεία Flare ανέφερε ότι το TeamPCP εκμεταλλεύεται εκτεθειμένα control planes αντί για endpoints, στοχεύοντας κυρίως cloud υποδομές, με το Azure να αντιπροσωπεύει το 61% και το AWS το 36% των παραβιασμένων servers. "Η ισχύς του TeamPCP δεν προέρχεται από novel exploits ή πρωτότυπο malware, αλλά από τη large-scale αυτοματοποίηση και ενσωμάτωση γνωστών τεχνικών επίθεσης", σύμφωνα με την Flare. Το κίνητρο για το wiper component παραμένει αδιευκρίνιστο: "Υπάρχει πιθανότητα αυτό με το Ιράν να είναι απλώς ο τρόπος τους να τραβήξουν την προσοχή", δήλωσε ο Eriksen. Παράλληλα, ο Eriksen επισήμανε ότι δεν υπάρχει αξιόπιστος τρόπος να επιβεβαιωθεί αν το wiper κατάφερε πράγματι να καταστρέψει δεδομένα σε συστήματα θυμάτων, και ότι το malicious payload ήταν ενεργό μόνο για σύντομο χρονικό διάστημα.

Οργανισμοί που χρησιμοποίησαν Trivy για vulnerability scanning στα pipelines τους κατά το διάστημα 19-21 Μαρτίου 2026 πρέπει να θεωρήσουν ως πιθανώς compromised οποιαδήποτε tokens ήταν παρόντα σε αυτά τα environments. Προς ελαχιστοποίηση του κινδύνου, ερευνητές προτείνουν να αναζητηθούν ύποπτες υπηρεσίες με τα ονόματα pgmon ή pgmonitor στα Kubernetes clusters, καθώς το malware τα χρησιμοποιεί για κάλυψη. Τόσο η Aikido όσο και η Socket έχουν δημοσιεύσει πλήρεις λίστες Indicators of Compromise (IOCs) για όσους θέλουν να ελέγξουν αν έχουν επηρεαστεί.

Πηγές

]]>11463Fri, 10 Apr 2026 14:54:00 +0000Ανοικτό λογισμικό, ελλιπής στήριξη, γιατί οι maintainers πιέζονται όλο και περισσότεροhttps://www.thelab.gr/news/linux/%CE%B1%CE%BD%CE%BF%CE%B9%CE%BA%CF%84%CF%8C-%CE%BB%CE%BF%CE%B3%CE%B9%CF%83%CE%BC%CE%B9%CE%BA%CF%8C-%CE%B5%CE%BB%CE%BB%CE%B9%CF%80%CE%AE%CF%82-%CF%83%CF%84%CE%AE%CF%81%CE%B9%CE%BE%CE%B7-%CE%B3%CE%B9%CE%B1%CF%84%CE%AF-%CE%BF%CE%B9-maintainers-%CF%80%CE%B9%CE%AD%CE%B6%CE%BF%CE%BD%CF%84%CE%B1%CE%B9-%CF%8C%CE%BB%CE%BF-%CE%BA%CE%B1%CE%B9-%CF%80%CE%B5%CF%81%CE%B9%CF%83%CF%83%CF%8C%CF%84%CE%B5%CF%81%CE%BF-r11393/

  • Νέα χρηματοδότηση 12,5 εκατ. δολαρίων προς το Linux Foundation στοχεύει να βοηθήσει τους συντηρητές ανοικτού λογισμικού να διαχειριστούν τον αυξανόμενο όγκο αυτοματοποιημένων αναφορών ασφαλείας.
  • Το πρόβλημα δεν περιορίζεται στο «AI slop». Σύμφωνα με το Tidelift, το 60% των συντηρητών δεν αμείβεται και το ίδιο ποσοστό έχει εγκαταλείψει ή έχει σκεφτεί σοβαρά να εγκαταλείψει τη συντήρηση έργων.
  • Το ανοικτό λογισμικό παραμένει κρίσιμη υποδομή για το εμπορικό λογισμικό, αλλά η νέα χρηματοδότηση αφορά κυρίως την ασφάλεια και όχι τη συνολική οικονομική στήριξη των συντηρητών.

Στις 17 Μαρτίου 2026, το Linux Foundation ανακοίνωσε νέα χρηματοδότηση 12,5 εκατ. δολαρίων από επτά οργανισμούς τεχνολογίας, Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft και OpenAI. Τα χρήματα θα περάσουν μέσω των Alpha-Omega και OpenSSF και προορίζονται για ενίσχυση της ασφάλειας έργων ανοικτού λογισμικού που δέχονται αυξανόμενο όγκο αυτοματοποιημένων αναφορών ευπαθειών.

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

Έξι στους δέκα συντηρητές δεν πληρώνονται

Σύμφωνα με το 2024 Tidelift Maintainer Impact Report, το 60% των συντηρητών ανοικτού λογισμικού δηλώνει ότι εργάζεται ως απλήρωτος ερασιτέχνης. Το ίδιο ποσοστό αναφέρει ότι έχει είτε εγκαταλείψει είτε σκεφτεί σοβαρά να εγκαταλείψει τη συντήρηση κάποιου έργου.

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

Οι αυτοματοποιημένες αναφορές ασφαλείας αυξάνουν τον φόρτο

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

Η περίπτωση του curl είναι το πιο καθαρό παράδειγμα. Ο Daniel Stenberg ανακοίνωσε τον Ιανουάριο του 2026 ότι το έργο σταματά το πρόγραμμα bug bounty, επειδή η αξιολόγηση υποβολών χαμηλής ποιότητας είχε γίνει δυσανάλογα χρονοβόρα. Όπως έγραψε, μέσα σε μία μόνο εβδομάδα έφτασαν επτά αναφορές χωρίς να επιβεβαιωθεί καμία πραγματική ευπάθεια.

Σχετικό υλικό του OpenSSF, που χρησιμοποιείται στη συζήτηση για το πρόβλημα, παραπέμπει επίσης στο curl και σημειώνει ότι περίπου το 5% των υποβολών αντιστοιχούσε σε γνήσιες ευπάθειες. Το υπόλοιπο ήταν κυρίως θόρυβος, συχνά με ενδείξεις κειμένου παραγόμενου από εργαλεία τεχνητής νοημοσύνης.

Το εμπορικό λογισμικό εξαρτάται μαζικά από ανοικτό κώδικα

Η έκθεση OSSRA 2025 της Black Duck δείχνει πόσο βαθιά έχει ενσωματωθεί ο ανοικτός κώδικας στο εμπορικό λογισμικό. Το 97% των ελεγμένων εμπορικών codebases περιείχε συστατικά ανοικτού κώδικα. Το ίδιο υλικό αναφέρει ότι το 91% των εφαρμογών που ελέγχθηκαν περιείχε παρωχημένα στοιχεία ανοικτού λογισμικού, δηλαδή όχι την πιο πρόσφατη διαθέσιμη έκδοσή τους.

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

Η πίεση φαίνεται και στις δημόσιες υποδομές

Το ίδιο μοτίβο εμφανίζεται και στις κοινές υποδομές του οικοσυστήματος. Σύμφωνα με τον Brian Fox της Sonatype, όπως ανέφερε το The Register, το 82% της κατανάλωσης του Maven Central προέρχεται από λιγότερο από το 1% των διευθύνσεων IP, ενώ περίπου το 80% της κίνησης συνδέεται με τους τρεις μεγάλους hyperscalers.

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

Τι καλύπτει η νέα χρηματοδότηση και τι μένει έξω

Η δωρεά των 12,5 εκατ. δολαρίων είναι σημαντική, αλλά έχει σαφώς οριοθετημένο στόχο. Η ανακοίνωση του Linux Foundation αφορά κυρίως την ασφάλεια ανοικτού λογισμικού και τη διαχείριση του αυξημένου όγκου αναφορών ευπαθειών. Δεν παρουσιάζεται ως γενική απάντηση στο ζήτημα της αμοιβής των συντηρητών ή της μακροχρόνιας οικονομικής στήριξής τους.

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

Πηγές

]]>11393Mon, 30 Mar 2026 12:57:48 +0000Δημιουργήθηκε το Open Gaming Collective για πιο ενοποιημένη εμπειρία gaming στο Linuxhttps://www.thelab.gr/news/linux/%CE%B4%CE%B7%CE%BC%CE%B9%CE%BF%CF%85%CF%81%CE%B3%CE%AE%CE%B8%CE%B7%CE%BA%CE%B5-%CF%84%CE%BF-open-gaming-collective-%CE%B3%CE%B9%CE%B1-%CF%80%CE%B9%CE%BF-%CE%B5%CE%BD%CE%BF%CF%80%CE%BF%CE%B9%CE%B7%CE%BC%CE%AD%CE%BD%CE%B7-%CE%B5%CE%BC%CF%80%CE%B5%CE%B9%CF%81%CE%AF%CE%B1-gaming-%CF%83%CF%84%CE%BF-linux-r11259/

  • Η Universal Blue (πίσω από το Bazzite) ανακοίνωσε στις 28 Ιανουαρίου 2026 τη δημιουργία του Open Gaming Collective (OGC), με στόχο λιγότερο κατακερματισμό στο Linux gaming.
  • Το OGC στοχεύει να κεντροποιήσει δουλειά σε kernel patches, εργαλεία input και κρίσιμα πακέτα όπως το gamescope, με φιλοσοφία “upstream first”.
  • Το Bazzite θα υιοθετήσει τον OGC kernel και θα αντικαταστήσει το HHD (Handheld Daemon) με το InputPlumber, ενώ λειτουργίες όπως RGB και έλεγχος ανεμιστήρων αναμένεται να ενσωματωθούν στη διεπαφή του Steam.

Η 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 για περισσότερους χρήστες και συσκευές.

Πηγές

]]>11259Fri, 30 Jan 2026 16:10:57 +0000Οι αλλαγές στη Mesa υπόσχονται έως 260% boost σε Intel Arc “Alchemist” στο Linux, αλλά σε πολύ συγκεκριμένο σενάριοhttps://www.thelab.gr/news/linux/%CE%BF%CE%B9-%CE%B1%CE%BB%CE%BB%CE%B1%CE%B3%CE%AD%CF%82-%CF%83%CF%84%CE%B7-mesa-%CF%85%CF%80%CF%8C%CF%83%CF%87%CE%BF%CE%BD%CF%84%CE%B1%CE%B9-%CE%AD%CF%89%CF%82-260-boost-%CF%83%CE%B5-intel-arc-%E2%80%9Calchemist%E2%80%9D-%CF%83%CF%84%CE%BF-linux-%CE%B1%CE%BB%CE%BB%CE%AC-%CF%83%CE%B5-%CF%80%CE%BF%CE%BB%CF%8D-%CF%83%CF%85%CE%B3%CE%BA%CE%B5%CE%BA%CF%81%CE%B9%CE%BC%CE%AD%CE%BD%CE%BF-%CF%83%CE%B5%CE%BD%CE%AC%CF%81%CE%B9%CE%BF-r11254/

  • Σειρά 18 patches έγινε merge στο Mesa, με στόχο διόρθωση graphics corruption σε Intel DG2 (Arc Alchemist) και iGPU σε Meteor Lake.
  • Σε ένα συγκεκριμένο game trace του NBA 2K23 (DX11, 4K, ultra) αναφέρεται “έως 260%” βελτίωση, χωρίς προς το παρόν ευρύτερο benchmark set.
  • Οι αλλαγές στοχεύουν το Mesa 26.1, άρα πρακτικά μιλάμε για Mesa git και μελλοντικό release, όχι κάτι που έχει ήδη περάσει καθολικά στις σταθερές διανομές.

Μια σειρά 18 patches από τον Intel open source graphics driver engineer Francisco Jerez έγινε merge στο Mesa, με στόχο να αντιμετωπιστεί επίμονο graphics corruption που επηρέαζε τόσο DG2 (Intel Arc “Alchemist”) όσο και iGPU σε Meteor Lake. Η δουλειά επικεντρώνεται στον χειρισμό του HiZ_CCS auxiliary compression όταν γίνεται sampling από resolved depth surfaces, ένα σημείο που συνδεόταν με artifacts και λάθη rendering στις συγκεκριμένες πλατφόρμες.

Πέρα από τη διόρθωση σταθερότητας και ορθότητας, το ενδιαφέρον είναι ότι η ίδια σειρά αλλαγών μπορεί να φέρει σημαντική αύξηση απόδοσης σε συγκεκριμένο μοτίβο φόρτου. Στο σχετικό merge request σημειώνεται ότι, μετά τη μετάβαση σε partial resolves για HiZ-CCS surfaces, μπορούν να ωφεληθούν workloads που κάνουν συχνό sampling από non-WT depth surfaces (συχνά MSAA).

Η πιο “κραυγαλέα” ένδειξη που αναφέρεται μέχρι στιγμής είναι ένα trace του NBA 2K23, “Nba2K23-trace-dx11-2160p-ultra”, όπου καταγράφεται “έως 260%” uplift σε Gfx12.5 parts. Παρότι το νούμερο είναι εντυπωσιακό, τα διαθέσιμα δεδομένα είναι περιορισμένα και δεν συνοδεύονται από πλήρες benchmark suite, άρα δεν είναι ασφαλές να γενικευτεί ως συνολικό boost σε όλο το φάσμα παιχνιδιών ή τίτλων.

Σε επίπεδο διαθεσιμότητας, οι αλλαγές έγιναν merge με στόχευση τη σειρά Mesa 26.1, της οποίας το επίσημο release calendar δίνει branchpoint στις 15 Απριλίου 2026. Αυτό σημαίνει ότι βραχυπρόθεσμα θα τις δουν κυρίως όσοι τρέχουν Mesa git ή πολύ φρέσκα builds, ενώ μένει να φανεί αν θα γίνει και backport στη Mesa 26.0, ειδικά λόγω του corruption fix.

Πηγές

]]>11254Wed, 28 Jan 2026 15:47:00 +0000Linux Kernel: Επιτέλους έρχεται τεχνολογία που τα Windows έχουν εδώ και χρόνιαhttps://www.thelab.gr/news/linux/linux-kernel-%CE%B5%CF%80%CE%B9%CF%84%CE%AD%CE%BB%CE%BF%CF%85%CF%82-%CE%AD%CF%81%CF%87%CE%B5%CF%84%CE%B1%CE%B9-%CF%84%CE%B5%CF%87%CE%BD%CE%BF%CE%BB%CE%BF%CE%B3%CE%AF%CE%B1-%CF%80%CE%BF%CF%85-%CF%84%CE%B1-windows-%CE%AD%CF%87%CE%BF%CF%85%CE%BD-%CE%B5%CE%B4%CF%8E-%CE%BA%CE%B1%CE%B9-%CF%87%CF%81%CF%8C%CE%BD%CE%B9%CE%B1-r11181/

Το Linux ετοιμάζεται να κλείσει ένα σημαντικό κενό απόδοσης σε σχέση με άλλα desktop λειτουργικά. Μια νέα σειρά patches για τον kernel εισάγει το «Cache-Aware Scheduling», μια προσέγγιση scheduling που αξιοποιεί τη γνώση της τοπολογίας της τελευταίου επιπέδου cache (LLC, συνήθως L3) ώστε να μειώνει τις άσκοπες μετακινήσεις δεδομένων και να βελτιώνει τη locality. Σε ορισμένα σενάρια, οι αναφερόμενες βελτιώσεις φτάνουν μέχρι και 44% (ως μείωση χρόνου εκτέλεσης).

Τι είναι το Cache-Aware Scheduling και γιατί έχει σημασία

Το Cache-Aware Scheduling είναι μια τεχνική που επιτρέπει στο λειτουργικό να λαμβάνει υπόψη τη διάταξη της cache του επεξεργαστή και να κατανέμει εργασίες με τρόπο που αυξάνει τα cache hits και μειώνει τα cache misses. Στα Windows, ο scheduler εδώ και χρόνια αξιοποιεί πληροφορίες τοπολογίας (π.χ. NUMA, ομάδες πυρήνων, hints από firmware και drivers) για να βελτιώνει την τοποθέτηση εργασιών. Η νέα προσέγγιση στο Linux στοχεύει να δώσει αντίστοιχο πλεονέκτημα ειδικά σε συστήματα με πολλαπλά LLC domains.

Χαρακτηριστικό παράδειγμα “topology-aware” συμπεριφοράς στον χώρο των Windows είναι οι υβριδικές αρχιτεκτονικές και οι νεότερες πλατφόρμες, όπου το λειτουργικό, σε συνεργασία με μηχανισμούς του κατασκευαστή (π.χ. drivers), μπορεί να προτιμά συγκεκριμένους πυρήνες ή CCDs για συγκεκριμένα workloads. Σε επεξεργαστές AMD Ryzen X3D, για παράδειγμα, το ζητούμενο είναι να ευνοούνται τα workloads που ωφελούνται από μεγαλύτερη L3 (3D V-Cache) εκεί που υπάρχει το πλεονέκτημα.

Το πρόβλημα που έπρεπε να λυθεί στο Linux

Στα σύγχρονα συστήματα με πολλούς πυρήνες, κάθε ομάδα πυρήνων μοιράζεται συνήθως μια κοινή cache τελευταίου επιπέδου (Last Level Cache, LLC), κατά κανόνα την L3. Όταν threads της ίδιας εφαρμογής, που μοιράζονται δεδομένα, εκτελούνται σε διαφορετικά LLC domains, εμφανίζεται το φαινόμενο του «cache bouncing». Τα δεδομένα μετακινούνται συχνά μεταξύ διαφορετικών caches, αυξάνοντας καθυστερήσεις και σπαταλώντας bandwidth και κύκλους CPU.

Σε πλατφόρμες με πολλαπλά LLC domains (π.χ. multi-socket servers, chiplet αρχιτεκτονικές, ή επεξεργαστές με σαφή διαχωρισμό L3 ανά cluster), η «σωστή» τοποθέτηση εργασιών μπορεί να κάνει αισθητή διαφορά. Το Linux, σε ορισμένες περιπτώσεις, έχανε απόδοση επειδή ο scheduler δεν είχε έναν τόσο στοχευμένο μηχανισμό ομαδοποίησης tasks με βάση το κοινό working set.

Η λύση που προτείνεται για το Linux

Η νέα υλοποίηση βασίζεται σε πρόταση του Peter Zijlstra και αναπτύσσεται από τους Tim Chen και Chen Yu (Intel). Εισάγει έναν μηχανισμό που στοχεύει να κρατά threads που μοιράζονται δεδομένα στο ίδιο LLC domain, ώστε να μεγιστοποιούνται τα cache hits και να ελαχιστοποιούνται τα cache misses και το bouncing.

Στην πράξη, ο μηχανισμός:

  • Αναγνωρίζει ποια threads ανήκουν στην ίδια διεργασία και είναι πιθανό να μοιράζονται δεδομένα.
  • Προσπαθεί να τα τοποθετήσει στο ίδιο LLC domain, όταν αυτό είναι εφικτό και ωφέλιμο.
  • Παρακολουθεί χρήση μνήμης και αριθμό ενεργών threads, ώστε να αποφεύγεται η υπερφόρτωση ενός cache domain.
  • Εστιάζει κυρίως στην L3 (LLC). Η επέκταση της λογικής «πέρα από την LLC», προς τη DRAM ή καθαρά NUMA πολιτικές, δεν εμφανίζεται να δίνει αντίστοιχα οφέλη με τον ίδιο τρόπο σε αυτή τη φάση.

Ρυθμίσεις για προχωρημένους

Η λειτουργία εκθέτει παραμέτρους στο /sys/kernel/debug/sched/ (debugfs, άρα κυρίως για δοκιμές και tuning). Ενδεικτικά:

llc_aggr_tolerance: Η πιο κρίσιμη ρύθμιση, καθορίζει πόσο επιθετικά θα γίνεται η «συγκέντρωση» εργασιών. Με τιμή 0 η λειτουργία απενεργοποιείται. Με τιμή 100, η συγκέντρωση γίνεται πολύ πιο επιθετικά, ακόμη και όταν το αποτύπωμα μνήμης ή ο αριθμός threads είναι μεγάλος.

llc_overload_pct και llc_imb_pct: Όρια προστασίας ώστε να αποφεύγεται η υπερφόρτωση ενός LLC domain και να διατηρείται ισορροπία φορτίου.

llc_epoch_period: Καθορίζει τη συχνότητα παρακολούθησης/επανεκτίμησης (αναφέρεται προεπιλογή 10 ms).

Εντυπωσιακά αποτελέσματα στις μετρήσεις

Οι μετρήσεις που συνοδεύουν τη σειρά patches δείχνουν ότι η προσθήκη cache-aware λογικής μπορεί να φέρει ουσιαστικά οφέλη, ειδικά σε συστήματα με σαφώς διαχωρισμένα LLC domains και σε workloads με κοινό working set.

Intel Sapphire Rapids (2 sockets, 30 cores ανά socket):

  • Σε hackbench (threads-pipe), αναφέρονται βελτιώσεις που σε επιλεγμένες διαμορφώσεις φτάνουν περίπου 30% ή και υψηλότερα σε 1-group σενάρια.
  • Σε schbench, σε αρκετές διαμορφώσεις εμφανίζεται αισθητή βελτίωση σε wakeup latency (π.χ. τάξης ~30% και άνω σε συγκεκριμένα thread counts), αν και δεν είναι όλα τα metrics μονοσήμαντα θετικά σε κάθε περίπτωση.

AMD EPYC Genoa:

  • Σε ChaCha20-xiangshan, με πιο επιθετικές ρυθμίσεις, αναφέρεται μείωση χρόνου εκτέλεσης έως περίπου 44%. Συγκεκριμένα, ο χρόνος εμφανίζεται να πέφτει από 50.868 ms σε 28.349 ms (δηλαδή περίπου από 50,9 δευτερόλεπτα σε 28,3 δευτερόλεπτα).

AMD EPYC Milan:

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

Τεχνικές λεπτομέρειες

Το patch set περιγράφεται ως σειρά 19 patches και, μεταξύ άλλων, εισάγει χαρτογράφηση LLC index ανά CPU, ανάθεση «preferred LLC ID» σε επίπεδο διεργασίας, παρακολούθηση LLC-preferred tasks ανά runqueue, μετρητές για τα tasks που «προτιμούν» κάθε LLC σε ένα sched group, καθώς και έναν νέο τύπο migration, το migrate_llc_task, για cache-aware balancing.

Προοπτικές

Αυτή εμφανίζεται ως πέμπτη εκδοχή των patches, μετά από προηγούμενους RFC κύκλους. Οι συντάκτες αναφέρουν ότι έχουν ενσωματώσει σχόλια, έχουν διορθώσει bugs, και έχουν βελτιώσει τον κώδικα. Παρ’ όλα αυτά, η ενσωμάτωση στο mainline εξαρτάται από τη διαδικασία review και τις αποφάσεις των maintainers.

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

Συμπέρασμα

Το Cache-Aware Scheduling είναι μια σημαντική εξέλιξη για το Linux scheduling σε συστήματα με πολλαπλά LLC domains. Παρότι η γενική ιδέα της topology-aware τοποθέτησης εργασιών δεν είναι καινούργια στον χώρο των λειτουργικών, η συγκεκριμένη υλοποίηση στο Linux στοχεύει να μειώσει με πρακτικό τρόπο το cache bouncing και να βελτιώσει την απόδοση σε workloads που είναι ευαίσθητα στη locality.

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

Πηγές

]]>11181Wed, 31 Dec 2025 15:58:11 +0000Τέλος εποχής για τις NVIDIA Pascal στο Linux: Χάος για τους χρήστες Archhttps://www.thelab.gr/news/linux/%CF%84%CE%AD%CE%BB%CE%BF%CF%82-%CE%B5%CF%80%CE%BF%CF%87%CE%AE%CF%82-%CE%B3%CE%B9%CE%B1-%CF%84%CE%B9%CF%82-nvidia-pascal-%CF%83%CF%84%CE%BF-linux-%CF%87%CE%AC%CE%BF%CF%82-%CE%B3%CE%B9%CE%B1-%CF%84%CE%BF%CF%85%CF%82-%CF%87%CF%81%CE%AE%CF%83%CF%84%CE%B5%CF%82-arch-r11174/

  • Το Arch Linux περνά στη σειρά NVIDIA 590 και αλλάζει τα βασικά πακέτα σε nvidia-open (open kernel modules), που αφορούν Turing και νεότερες GPUs.
  • Για Pascal (GTX 10xx), Maxwell (GTX 9xx) και παλαιότερες γενιές, το upgrade μπορεί να «σπάσει» το γραφικό περιβάλλον, επειδή ο driver 590 δεν τις υποστηρίζει.
  • Η πρακτική λύση είναι ο legacy κλάδος 580 μέσω AUR (nvidia-580xx-dkms και αντίστοιχα utils), με τη NVIDIA να μιλά για security-only updates έως τον Οκτώβριο 2028.

 

Το Arch Linux ανακοίνωσε ότι, με τη μετάβαση στον οδηγό NVIDIA 590, ο οδηγός γραφικών δεν υποστηρίζει πλέον Pascal (GeForce GTX 10xx) και γενικά «Pascal και παλαιότερες γενιές». Παράλληλα, τα βασικά πακέτα του Arch αλλάζουν πορεία, το κλασικό nvidia αντικαθίσταται από nvidia-open, το nvidia-dkms από nvidia-open-dkms και το nvidia-lts από nvidia-lts-open. Πρόκειται για αλλαγή που ευθυγραμμίζεται με τη λογική rolling-release του Arch, αλλά έχει άμεσο αντίκτυπο σε όσους κρατούν ακόμα GTX 10xx ή GTX 9xx σε καθημερινά συστήματα.

 

Στην πράξη, η αναβάθμιση μπορεί να γίνει «αθόρυβα» για όσους έχουν Turing (RTX 20xx και GTX 16xx, π.χ. GTX 1650) και νεότερες κάρτες, γιατί περνούν αυτόματα στα open kernel modules. Για Pascal, Maxwell και παλαιότερες γενιές, όμως, ο οδηγός 590 δεν μπορεί να φορτώσει kernel module για τη GPU, κάτι που μετά το reboot μπορεί να αφήσει το σύστημα χωρίς λειτουργικό γραφικό περιβάλλον. Το αποτέλεσμα συχνά είναι να καταλήγει ο χρήστης σε κονσόλα (TTY), μέχρι να γίνει αλλαγή driver.

Η μετάβαση σε nvidia-open δεν σημαίνει «πλήρως open driver» με την έννοια του Nouveau. Το Arch υιοθετεί τα open-source kernel modules της NVIDIA, που έχουν σχεδιαστεί για νεότερες αρχιτεκτονικές, ενώ το υπόλοιπο driver stack παραμένει στην πράξη το γνωστό οικοσύστημα της NVIDIA. Αυτό είναι και ο λόγος που η αλλαγή δεν προσφέρει “σωσίβιο” στις Pascal κάρτες, απλώς απλοποιεί τη γραμμή υποστήριξης από τη στιγμή που ο 590 κλάδος αφορά πλέον Turing και μετά.

Για τους κατόχους GTX 10xx και GTX 9xx, η λύση είναι ο legacy κλάδος 580. Στο Arch αυτό μεταφράζεται σε μετάβαση σε AUR πακέτα, με πυρήνα το nvidia-580xx-dkms. Πρακτικά, δεν αρκεί μόνο το DKMS module, χρειάζονται και τα αντίστοιχα user-space πακέτα (nvidia-580xx-utils), και για Steam ή γενικότερα 32-bit runtimes συνήθως απαιτείται και το lib32-nvidia-580xx-utils ώστε να μην «σπάσουν» εξαρτήσεις τύπου lib32-vulkan-driver που χρησιμοποιεί το Steam.

Σε βάθος χρόνου, ο συμβιβασμός είναι καθαρός. Η NVIDIA έχει ανακοινώσει ότι Maxwell, Pascal και Volta μπαίνουν σε καθεστώς security-only ενημερώσεων (χωρίς νέα features και optimizations), με παράθυρο έως τον Οκτώβριο 2028. Αυτό καλύπτει το θέμα της ασφάλειας, αλλά δεν λύνει το διαχρονικό ρίσκο στις rolling διανομές: ένας legacy DKMS οδηγός μπορεί να χρειάζεται τροποποιήσεις καθώς ο kernel προχωρά, και η συντήρηση γίνεται όλο και πιο “community-driven”.

Για όσους θέλουν να συνεχίσουν σε Arch χωρίς εκπλήξεις, οι πιο πρακτικές επιλογές είναι τρεις: χρήση LTS kernel για πιο σταθερό API, συνειδητή παρακολούθηση των αλλαγών σε NVIDIA πακέτα πριν από μεγάλα upgrades, ή μετάβαση σε πιο συντηρητική διανομή όπου ο 580 κλάδος να παραμείνει στην ίδια έκδοση για μεγαλύτερο διάστημα. Το εναλλακτικό, προφανές σενάριο είναι αναβάθμιση GPU, όχι επειδή οι Pascal κάρτες «πέθαναν», αλλά επειδή η καθημερινή συντήρηση σε bleeding-edge περιβάλλον θα γίνεται σταδιακά πιο απαιτητική.

Τι να κάνετε αν μετά το update χαθεί το γραφικό περιβάλλον

  1. Μπείτε σε TTY (π.χ. Ctrl+Alt+F2), συνδεθείτε, ή μπείτε απομακρυσμένα μέσω SSH αν είναι ενεργό.
  2. Αφαιρέστε τα πακέτα nvidia-open (ή ό,τι αντικατέστησε τα nvidia/nvidia-dkms/nvidia-lts στο σύστημά σας).
  3. Περάστε τον legacy κλάδο 580 από AUR (nvidia-580xx-dkms, nvidia-580xx-utils, και για Steam συνήθως lib32-nvidia-580xx-utils), έπειτα κάντε reboot.

Πηγές

]]>11174Sun, 28 Dec 2025 17:53:09 +0000Ο Linux πυρήνας προχωρά στην ενεργοποίηση των «Microsoft C extensions» στο 6.19https://www.thelab.gr/news/linux/%CE%BF-linux-%CF%80%CF%85%CF%81%CE%AE%CE%BD%CE%B1%CF%82-%CF%80%CF%81%CE%BF%CF%87%CF%89%CF%81%CE%AC-%CF%83%CF%84%CE%B7%CE%BD-%CE%B5%CE%BD%CE%B5%CF%81%CE%B3%CE%BF%CF%80%CE%BF%CE%AF%CE%B7%CF%83%CE%B7-%CF%84%CF%89%CE%BD-%C2%ABmicrosoft-c-extensions%C2%BB-%CF%83%CF%84%CE%BF-619-r11063/

Η συζήτηση για τις επεκτάσεις C της Microsoft επιστρέφει δυναμικά στον πυρήνα Linux. Αυτήν τη φορά, δύο τροποποιήσεις κώδικα στο δέντρο ανάπτυξης kbuild-next ενεργοποιούν καθολικά την παράμετρο μεταγλώττισης -fms-extensions. Ο στόχος είναι να ενταχθούν στο «παράθυρο συγχώνευσης» του Linux 6.19 τον Δεκέμβριο του 2025, εφόσον δεν υπάρξουν ενστάσεις. Η αλλαγή θα ισχύει για GCC (GNU Compiler Collection) και LLVM/Clang (εναλλακτικοί μεταγλωττιστές) σε όλη τη διαδικασία μεταγλώττισης του πυρήνα.

 

Τι αλλάζει πρακτικά. Η επιλογή -fms-extensions, που εδώ και χρόνια υποστηρίζεται από GCC/Clang, επιτρέπει ορισμένες μη τυποποιημένες συντακτικές δυνατότητες συμβατές με τον μεταγλωττιστή MSVC (Microsoft Visual C++). Παραδείγματα είναι τα «ανώνυμα» struct/union με απευθείας πρόσβαση στα μέλη τους και επιμέρους ιδιαιτερότητες αρχικοποιήσεων. Αυτά μειώνουν τις λύσεις παράκαμψης και, σε ορισμένα σημεία, οδηγούν σε πιο καθαρό και συνοπτικό κώδικα.

 

Ο συντηρητής Rasmus Villemoes εισηγείται να ενεργοποιηθεί η ρύθμιση σε όλο το δέντρο του πυρήνα, ώστε τυχόν χρήσεις των συγκεκριμένων δυνατοτήτων να μη χρειάζονται εξαιρέσεις ανά υποκατάλογο. Στη σχετική τεκμηρίωση παρατίθενται περιπτώσεις από παλαιότερες συζητήσεις όπου οι MS επεκτάσεις έδιναν πιο κομψή λύση. Από προηγούμενες δημόσιες τοποθετήσεις προκύπτει ότι ο Linus Torvalds δεν είναι αρνητικός σε μια τέτοια κατεύθυνση για το 6.19.

 

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

 

Επίσης, δεν απαιτείται μεταγλώττιση του πυρήνα με εργαλεία της Microsoft ούτε αλλάζει το toolchain του Linux. Η μεταβολή αφορά αποκλειστικά το σύνολο των αποδεκτών συντακτικών επιλογών στους ήδη χρησιμοποιούμενους μεταγλωττιστές. Συνοδευτικό patch φροντίζει η ρύθμιση να ισχύει και για αρχιτεκτονικές που ορίζουν δικά τους CFLAGS, ώστε να αποφευχθούν γκρίζες ζώνες συμβατότητας μέσα στο ίδιο σύστημα build.

 

Ρίσκα και όρια. Η αυξημένη ανοχή σε μη τυποποιημένες κατασκευές χρειάζεται πειθαρχία, για να μην επιβαρυνθούν η φορητότητα και τα εργαλεία ανάλυσης κώδικα σε βάθος χρόνου. Το αποτέλεσμα θα κριθεί από τη συνετή χρήση των επεκτάσεων και την προσήλωση στο υπάρχον coding style του πυρήνα. Αν υπάρξουν σοβαρές αντιρρήσεις από maintainers ή από τον ίδιο τον Torvalds, θα φανούν πριν την τελική ενσωμάτωση. Συνολικά, δεν πρόκειται για «στροφή» προς τον MSVC, αλλά για πρακτική αποδοχή δυνατοτήτων που υποστηρίζουν ήδη οι GCC/Clang, με στόχο ευανάγνωστο και συντηρήσιμο κώδικα σε επιλεγμένα σημεία.

]]>11063Tue, 11 Nov 2025 15:20:15 +0000Zorin OS 18: «μεγαλύτερη κυκλοφορία» εν μέσω λήξης υποστήριξης Windows 10 — 100.000 λήψεις σε 2 ημέρεςhttps://www.thelab.gr/news/linux/zorin-os-18-%C2%AB%CE%BC%CE%B5%CE%B3%CE%B1%CE%BB%CF%8D%CF%84%CE%B5%CF%81%CE%B7-%CE%BA%CF%85%CE%BA%CE%BB%CE%BF%CF%86%CE%BF%CF%81%CE%AF%CE%B1%C2%BB-%CE%B5%CE%BD-%CE%BC%CE%AD%CF%83%CF%89-%CE%BB%CE%AE%CE%BE%CE%B7%CF%82-%CF%85%CF%80%CE%BF%CF%83%CF%84%CE%AE%CF%81%CE%B9%CE%BE%CE%B7%CF%82-windows-10-%E2%80%94-100000-%CE%BB%CE%AE%CF%88%CE%B5%CE%B9%CF%82-%CF%83%CE%B5-2-%CE%B7%CE%BC%CE%AD%CF%81%CE%B5%CF%82/

Στις 14 Οκτωβρίου 2025 έληξε η κανονική υποστήριξη (End of Life, EOL) των Windows 10, με τη Microsoft να παραδίδει το τελευταίο update και να προτείνει μετάβαση σε Windows 11 ή ένταξη στο πρόγραμμα Εκτεταμένων Ενημερώσεων Ασφαλείας (Extended Security Updates, ESU) έως τον Οκτώβριο του 2026. Την ίδια ημέρα, η ιρλανδική Zorin ανακοίνωσε το Zorin OS 18 και, σύμφωνα με τους δημιουργούς, πέτυχε «τη μεγαλύτερη κυκλοφορία στην ιστορία της»: πάνω από 100.000 λήψεις σε λίγο πάνω από 48 ώρες, εκ των οποίων άνω του 72% προήλθε από Windows.

 

Το timing δεν είναι τυχαίο. Μεγάλο μέρος του εγκατεστημένου στόλου υπολογιστών με Windows 10 δεν πληροί τις απαιτήσεις των Windows 11 (π.χ. TPM 2.0, υποστηριζόμενοι επεξεργαστές), αφήνοντας εκατομμύρια συστήματα χωρίς δωρεάν ενημερώσεις. Η Zorin επικαλείται ανάλυση της Canalys για έως 240 εκατ. υπολογιστές που κινδυνεύουν να «μείνουν πίσω», κάτι που τροφοδοτεί ενδιαφέρον για εναλλακτικές λύσεις όπως ένα φιλικό Linux desktop.

 

Ως διανομή (distribution) εστιασμένη στη μετάβαση από Windows, το Zorin OS 18 φέρνει νέα πλακίδωση παραθύρων (tiling) με έτοιμες διατάξεις, ενσωμάτωση δικτυακών εφαρμογών (web apps) ώστε ιστότοποι όπως Microsoft 365/Teams και Google Docs να «τρέχουν» σαν κανονικές εφαρμογές, υποστήριξη αρχείων OneDrive μέσα από τους «Online Accounts», καθώς και βελτιωμένο Windows App Support με νεότερα πακέτα WINE. Η Zorin υπόσχεται ακόμη υποστήριξη ασφάλειας και ενημερώσεων έως «τουλάχιστον τον Ιούνιο του 2029», στοιχείο που ενδιαφέρει ιδιαίτερα όσους «κολλούν» στην αναβάθμιση σε Windows 11.

 

Σημασία για την αγορά: για οικιακούς και εταιρικούς χρήστες που δεν θέλουν/μπορούν να αντικαταστήσουν hardware, μια «έτοιμη» διανομή Linux με έμφαση στη συμβατότητα εφαρμογών και γνώριμη διεπαφή μειώνει το κόστος μετάβασης και παρατείνει τη διάρκεια ζωής εξοπλισμού. Παράλληλα, το ESU των Windows 10 προσφέρει μια «ανάσα» ενός έτους, αλλά με ορίζοντα λήξης, καθιστώντας πιο επίκαιρη την αξιολόγηση εναλλακτικών.

 

Τι δεν ξέρουμε ακόμη: τα 100.000 downloads δεν ισοδυναμούν με ισάριθμες εγκαταστάσεις ή μόνιμη μεταστροφή χρηστών. Θα χρειαστούν εβδομάδες για να φανεί αν το αρχικό «κύμα» θα μεταφραστεί σε ενεργούς χρήστες και αν άλλες διανομές θα δουν αντίστοιχα άλματα. Πάντως, η συγκυρία EOL των Windows 10 με το λανσάρισμα του Zorin OS 18 προσφέρει ένα ενδεικτικό «τεστ αντοχής» για τη βιωσιμότητα των desktop Linux επιλογών στο mainstream.

]]>11009Sun, 19 Oct 2025 10:04:12 +0000