All Activity

Το 2025 στο TheLab είχε ένα καθαρό μοτίβο αλλαγών. Όχι επειδή η τεχνολογία “έτρεξε” πιο γρήγορα από άλλες χρονιές, αλλά επειδή ωρίμασαν ταυτόχρονα αρκετοί κύκλοι ζωής. Υπηρεσίες που θεωρούσαμε δεδομένες έκλεισαν ή άλλαξαν μορφή, λειτουργικά μπήκαν σε καθεστώς λήξης και παράτασης, και οι καθημερινές μας ροές, από κλήσεις και links μέχρι ενημερώσεις ασφαλείας, χρειάστηκαν σχέδιο, όχι απλώς “update”. Από το τέλος του Skype και το κλείσιμο του goo.gl, μέχρι το τέλος υποστήριξης των Windows 10 και την αναταραχή στις τιμές DRAM, η χρονιά έδειξε ότι οι πλατφόρμες κλείνουν κύκλους, και το κόστος μετάβασης πέφτει κυρίως στον τελικό χρήστη, σε χρόνο, χρήμα και ρίσκο. Στο δεύτερο μισό, η ασφάλεια και η εφοδιαστική αλυσίδα λογισμικού επέστρεψαν στο επίκεντρο με τρόπο καθαρά πρακτικό. Δεν μιλήσαμε τόσο για “θεωρητικά” σενάρια, αλλά για πραγματικές αστοχίες, όπως secrets σε δημόσια Docker images, που μετατρέπουν ένα απλό build λάθος σε ανοιχτή πόρτα. Την ίδια στιγμή, στο smart home, το Thread 1.4 έδωσε κάτι που έλειπε χρόνια, ένα βήμα προς λιγότερα παράλληλα δίκτυα και πιο συνεκτικό mesh, ώστε το «έξυπνο σπίτι» να συμπεριφέρεται περισσότερο σαν υποδομή και λιγότερο σαν πείραμα. Οι ειδήσεις που "στιγμάτισαν" το 2025 28 Φεβρουαρίου 2025: Η Microsoft ανακοίνωσε ότι το Skype τερματίζει στις 5 Μαΐου 2025. Το μήνυμα ήταν ξεκάθαρο, η εποχή των «standalone» κλήσεων κλείνει, και το κέντρο βάρους πάει σε Teams και σε οικοσυστήματα με λογαριασμούς, πολιτικές και ολοκλήρωση. 2 Απριλίου 2025: Η Nintendo έβαλε επίσημη σφραγίδα στο Switch 2, με κυκλοφορία 5 Ιουνίου 2025 και τιμή αναφοράς $450. Η είδηση δεν ήταν μόνο «νέα κονσόλα», αλλά και «νέα τιμολόγηση», το handheld gaming περνά οριστικά σε premium επίπεδα. 25 Ιουλίου 2025: Η Google έβαλε τελική ημερομηνία για το goo.gl, 25 Αυγούστου 2025. Αυτό που καίει εδώ δεν είναι η συντόμευση συνδέσμων, είναι η εξάρτηση από τρίτους σε κρίσιμες ροές (campaigns, documentation, παλιά posts, QR που δείχνουν σε shortlinks). Ό,τι δεν έχει δικό σου domain, είναι δανεικό. 8 Αυγούστου 2025: Η Microsoft ξεκαθάρισε το πλαίσιο Windows 10 ESU για καταναλωτές, $30 και, κρίσιμα, απαίτηση Microsoft Account. Στο ίδιο κάδρο μπήκε και το «τέλος υποστήριξης Windows 10» στις 14 Οκτωβρίου 2025, άρα το ESU είναι πρακτικά «αγορά χρόνου» για ένα ακόμη έτος security patches. 25 Σεπτεμβρίου 2025: Η ίδια ιστορία γύρισε ειδικά για Ευρώπη. Στην ΕΟΧ η Microsoft έδωσε δωρεάν ESU και χωρίς απαίτηση Windows Backup, έως 13 Οκτωβρίου 2026. Εδώ η λεπτομέρεια έχει σημασία, δεν είναι «δωρεάν γενικά», είναι «δωρεάν σε συγκεκριμένο ρυθμιστικό πλαίσιο», και αλλάζει τον υπολογισμό κόστους/ρίσκου για όσους μένουν σε Windows 10. 5 Νοεμβρίου 2025: Στο hardware η χρονιά σφραγίστηκε από DRAM ανατιμήσεις, με αναφορές έως +171% σε ένα έτος, και με προβλέψεις έντονης ανόδου σε contract και spot τιμές. Το πρακτικό συμπέρασμα είναι ότι η ζήτηση από AI και data centers «στραγγίζει» την καταναλωτική αγορά, και η RAM επιστρέφει ως παράγοντας που επιβάλλει συμβιβασμούς σε builds και αναβαθμίσεις. 9 Δεκεμβρίου 2025: Στην κατηγορία «εργαλεία που υπόσχονται πολλά», το NanoKVM βρέθηκε στο μικροσκόπιο με αναφορές για backdoor, «κρυφό» Wi-Fi και θέματα εμπιστοσύνης. Το μήνυμα για homelab είναι σκληρό αλλά χρήσιμο, το out-of-band management είναι ισχύς, άρα είναι και ιδανικός στόχος, ειδικά όταν μιλάμε για φθηνές, νέες πλατφόρμες. 12 Δεκεμβρίου 2025: Η ασφάλεια επέστρεψε με αριθμούς. Αναφέρθηκαν 10.456 δημόσια Docker Hub images με εκτεθειμένα secrets (tokens, keys), πολλές φορές σε «πακέτο» πολλαπλών διαπιστευτηρίων. Για teams και builders, αυτό είναι μάθημα διαδικασίας, όχι εργαλείου, scanning, σωστό secret handling, και υποχρεωτικό rotate όταν κάτι διαρρεύσει. 27 Δεκεμβρίου 2025: Στο smart home, το Thread 1.4 έφερε την πιο «γήινη» βελτίωση, τυποποίηση στο μοίρασμα διαπιστευτηρίων ώστε να μειωθούν τα παράλληλα Thread δίκτυα στο ίδιο σπίτι, και καλύτερη πορεία προς ένα κοινό mesh. Δεν είναι μαγικό ραβδί, αλλά είναι η πρώτη σοβαρή κίνηση που στοχεύει στο πραγματικό πρόβλημα της καθημερινής εμπειρίας. Τι κρατάμε για το 2026 Το 2025 έδειξε ότι «λήξεις υπηρεσιών» και «λήξεις υποστήριξης» θα πυκνώσουν, όχι θα αραιώσουν. Και αυτό αλλάζει τον τρόπο που πρέπει να σκεφτόμαστε ως χρήστες, ως builders, αλλά και ως sites που ζουν από περιεχόμενο, παραπομπές και διαχρονικά guides. Η σωστή στάση δεν είναι ο πανικός, είναι η προετοιμασία. Εξάρτηση μόνο όπου υπάρχει σχέδιο εξόδου, δικό σου domain όπου έχει αξία, exports που δοκιμάζονται στην πράξη, migration paths που δεν βασίζονται σε μία εταιρεία, και εναλλακτικά κανάλια όταν το “default” κλείνει. Παράλληλα, η πίεση από AI υποδομές δεν είναι αφηρημένη. Μεταφράζεται σε προτεραιοποίηση παραγωγής, σε διαθεσιμότητες, και σε τιμές, ειδικά σε μνήμη. Αυτό σημαίνει ότι οι αναβαθμίσεις του 2026, για πολλούς, θα είναι λιγότερο “τι θέλω” και περισσότερο “τι μπορώ να βρω σε λογικό κόστος”. Και στην ασφάλεια, το βασικό ρίσκο δεν είναι μόνο το σπάνιο, θεαματικό 0-day. Είναι τα καθημερινά λάθη διαδικασίας, secrets σε repositories και images, βιαστικά deployments, και ανεπαρκές rotation, που δίνουν πρόσβαση εκεί που δεν θα έπρεπε να υπάρχει. Όλοι μας από τη διαχειριστική ομάδα του TheLab.gr, σας ευχόμαστε ευτυχισμένο το νέο έτος, με υγεία και ευτυχία.

Αναφέρθηκε ακόμη ένα περιστατικό υπερθέρμανσης σε 16-pin (12V-2x6) connector, αυτή τη φορά σε Sapphire Nitro+ RX 9070 XT. Με βάση τις μέχρι τώρα δημόσιες αναφορές, το νέο συμβάν περιγράφεται ως πιθανότατα το πέμπτο για RX 9070 XT με αντίστοιχο μοτίβο ζημιάς. Η συζήτηση επικεντρώνεται στην αξιοπιστία της σύνδεσης, στους adapters, και στο κατά πόσο ο τύπος βύσματος είναι επαρκώς ανεκτικός σε μη ιδανική εφαρμογή. Ένα ακόμη περιστατικό με καμένο 16-pin power connector ήρθε στη δημοσιότητα, αυτή τη φορά όχι σε κάρτα της Nvidia. Χρήστης ανέφερε ότι εντόπισε τη Sapphire Nitro+ RX 9070 XT με εμφανή ίχνη υπερθέρμανσης στον connector, κάτι που ενισχύει την εικόνα ότι τα προβλήματα αξιοπιστίας γύρω από το 12V-2x6 δεν περιορίζονται αποκλειστικά σε συγκεκριμένες υλοποιήσεις ή σε μία μόνο οικογένεια GPU. Πέμπτο περιστατικό για την RX 9070 XT Ο χρήστης u/divinethreshold στο Reddit ανέφερε ότι το σύστημά του άρχισε να εμφανίζει τυχαία crashes, με ελάχιστη σταθερότητα. Αφού έλεγξε τα υπόλοιπα εξαρτήματα χωρίς να εντοπίσει την αιτία, προχώρησε σε έλεγχο της κάρτας γραφικών. Κατά την αποσύνδεση του καλωδίου τροφοδοσίας, διαπίστωσε σαφή σημάδια καψίματος στην πάνω σειρά του 16-pin connector. Με βάση τις μέχρι τώρα δημόσιες αναφορές, το περιστατικό αυτό περιγράφεται ως πιθανότατα το πέμπτο για RX 9070 XT που παρουσιάζει ζημιά σχετιζόμενη με 12V-2x6. Στα προηγούμενα περιστατικά έχει αναφερθεί το ίδιο μοτίβο: η πάνω σειρά των pins εμφανίζει αλλοίωση ή καψίματα, ενώ η κάτω σειρά παραμένει εμφανώς λιγότερο επηρεασμένη. Τα προηγούμενα περιστατικά Πρώτο: ASRock Taichi RX 9070 XT τον Αύγουστο. Δεύτερο: Sapphire Nitro+ RX 9070 XT τον Οκτώβριο. Τρίτο και Τέταρτο: δύο ακόμη Sapphire Nitro+ RX 9070 XT τον Νοέμβριο. Πέμπτο: το νέο περιστατικό με Sapphire Nitro+ RX 9070 XT. Τι πήγε στραβά; Σε αντίθεση με περιπτώσεις όπου τα διαθέσιμα στοιχεία είναι περιορισμένα, εδώ η εικόνα της ζημιάς οδηγεί σε μια σχετικά συγκεκριμένη υπόθεση: ότι η κάτω σειρά pins δεν εξασφάλισε καλή επαφή με το θηλυκό βύσμα (female plug) της κάρτας. Σε ένα τέτοιο σενάριο, μεγαλύτερο μέρος του ηλεκτρικού φορτίου καταλήγει να περνά από τις επαφές που παραμένουν σε καλύτερη επαφή, αυξάνοντας την πιθανότητα υπερθέρμανσης στην πάνω σειρά. Παρότι η RX 9070 XT είναι κάρτα με TGP περίπου 304W, σημαντικά χαμηλότερο από τα 600W που αναφέρεται ότι μπορεί να υποστηρίξει ο 12V-2x6, ένα φορτίο που μοιράζεται πρακτικά σε λιγότερες επαφές από όσες προβλέπει ο σχεδιασμός μπορεί να οδηγήσει σε θερμική καταπόνηση και, τελικά, σε κάψιμο. Το ζήτημα του σχεδιασμού στη Sapphire Η Sapphire έχει επιλέξει μια λύση που δίνει έμφαση στην αισθητική, τοποθετώντας τον connector πιο μέσα στο σώμα της κάρτας. Αυτό, στην πράξη, μπορεί να απαιτεί πιο απότομο λυγισμό τύπου L στο καλώδιο, κάτι που αυξάνει τον κίνδυνο μη ιδανικής εφαρμογής, ειδικά αν ο διαθέσιμος χώρος στο κουτί είναι περιορισμένος. Επιπλέον, η Sapphire παρέχει μπλε adapter 16-pin σε 8-pin για χρήση με παλαιότερα τροφοδοτικά. Στο σχετικό σκεπτικό, αυτό αντιμετωπίζεται ως αύξηση των σημείων επαφής και, κατά συνέπεια, των πιθανών σημείων αστοχίας, καθώς μια σύνδεση 16-pin σε κάθε πλευρά μετατρέπεται σε πολλαπλές επιμέρους επαφές στο σύνολο της διαδρομής, με περισσότερες ενδιάμεσες συνδέσεις και περισσότερες πιθανότητες ατελούς εφαρμογής. Λάθος χρήστη ή θέμα σχεδίασης; Η συνηθισμένη εξήγηση σε αντίστοιχα περιστατικά είναι το «λάθος χρήστη», δηλαδή ότι το καλώδιο δεν έχει κουμπώσει πλήρως ή ότι υπάρχει ανεπιθύμητος λυγισμός κοντά στο βύσμα. Ωστόσο, με βάση τις περιπτώσεις που έχουν δημοσιοποιηθεί μέχρι τώρα, δεν έχει προκύψει ένα συνεπές, κοινό μοτίβο που να λειτουργεί ως σταθερός δευτερεύων παράγοντας σε όλες τις αναφορές. Έχουν αναφερθεί περιστατικά όπου χρήστες χρησιμοποιούν σύγχρονα ATX 3.1 τροφοδοτικά με native 16-pin καλώδια, εξασφαλίζουν σφιχτή σύνδεση χωρίς έντονο λύγισμα, και δεν εφαρμόζουν overclocking στην κάρτα, και παρ’ όλα αυτά καταλήγουν με εμφανή θερμική ζημιά στον connector. Η θέση της κοινότητας Η επικρατέστερη άποψη σε επίπεδο συζήτησης κοινότητας είναι ότι ο 16-pin connector ενδέχεται να έχει εγγενές σχεδιαστικό μειονέκτημα ως προς την ανοχή σε μη ιδανική εφαρμογή, ακόμη και μετά την αναθεώρησή του. Με βάση αυτή τη λογική, δεν θα έπρεπε να απαιτείται υπερβολική προσοχή ή μια σχεδόν «τελετουργική» διαδικασία εγκατάστασης για να αποφευχθεί μια αστοχία. Ορισμένοι σχολιαστές προχωρούν και σε πιο σκληρές διατυπώσεις, υποστηρίζοντας ότι σε άλλες κατηγορίες προϊόντων η συχνότητα τέτοιων αποτυχιών θα οδηγούσε ευκολότερα σε ανάκληση. Το γεγονός ότι αναφορές εμφανίζονται τόσο σε κάρτες Nvidia (RTX 4090, RTX 5090) όσο και σε AMD (RX 9070 XT) χρησιμοποιείται ως επιχείρημα ότι το επίκεντρο είναι ο ίδιος ο τύπος βύσματος και όχι αποκλειστικά η υλοποίηση του κάθε κατασκευαστή. Τι ακολουθεί; Ο χρήστης ανέφερε ότι θα προχωρήσει σε RMA. Το πρακτικό ερώτημα από εδώ και πέρα είναι αν οι κατασκευαστές θα αναθεωρήσουν επιλογές όπως η θέση του connector, ή αν θα υπάρξει πιο επιθετική ενημέρωση και καθοδήγηση εγκατάστασης, ώστε να μειωθεί ο κίνδυνος ατελούς εφαρμογής. Μέχρι τότε, για όσους έχουν Sapphire Nitro+ RX 9070 XT, ή γενικότερα οποιαδήποτε κάρτα με 16-pin, συνιστάται να: Επιβεβαιώνουν ότι το καλώδιο έχει τοποθετηθεί πλήρως και έχει κουμπώσει σωστά. Αποφεύγουν έντονους λυγισμούς πολύ κοντά στο βύσμα. Ελέγχουν περιοδικά για σημάδια θερμότητας ή αποχρωματισμού. Αν χρησιμοποιούνται adapters, να δίνεται ακόμη μεγαλύτερη προσοχή, καθώς αυξάνονται τα σημεία επαφής και άρα τα πιθανά σημεία αστοχίας. Το ζήτημα με τον 12V-2x6 παραμένει ανοιχτό, και η πίεση για πιο ανθεκτικές λύσεις θα ενταθεί όσο οι αναφορές συνεχίζονται, ειδικά όταν μεταφράζονται σε πραγματικές ζημιές εξοπλισμού για τελικούς χρήστες. Πηγές Tom’s Hardware, “Another 16-pin GPU power connector gets scorched, but this time it's not an RTX 5090”. Link Reddit (r/radeon), “Sapphire 9070XT Nitro+ 12V HPWR FAIL” (u/divinethreshold). Link Wccftech, “Third Sapphire RX 9070 XT Nitro+ Suffers From Burnt 16-pin Connector”. Link

Το 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, και το πόσο συνεπές θα είναι το όφελος ανά αρχιτεκτονική, θα φανεί καθώς θα αυξάνονται οι δοκιμές και, εφόσον προχωρήσει, καθώς θα ωριμάζει η υλοποίηση. Προς το παρόν, πάντως, τα διαθέσιμα στοιχεία δείχνουν ότι πρόκειται για προσθήκη με ουσιαστικό τεχνικό ενδιαφέρον. Πηγές Phoronix: Updated Intel Patches For Cache Aware Scheduling Net A 44% Win For AMD EPYC LWN.net: Cache aware scheduling (τεχνική ανάλυση και αποσπάσματα αποτελεσμάτων) Phoronix: Cache Aware Scheduling v2 (LKML review κύκλος) Phoronix: Intel's Cache Aware Scheduling Presentation At LPC 2025 YouTube: Cache Aware Scheduling (παρουσίαση LPC)

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