Chi osserva i sistemi digitali complessi sa che il vero valore non è nel dato statico, ma nella sua capacità di aggiornarsi. I sistemi predittivi moderni lavorano su flussi continui, assorbono informazioni, le ricalcolano e producono output che mutano costantemente. Lo sport, e in particolare il basket, è uno degli ambienti più adatti a questo tipo di elaborazione, perché combina eventi frequenti, variabili numerose e tempi estremamente compressi.

In questo contesto, parlare di numeri in tempo reale significa entrare nel cuore di un processo tecnologico che va ben oltre il risultato finale di una partita. È un tema che riguarda modelli matematici, infrastrutture software e capacità di adattamento istantaneo ai cambiamenti.

Il basket come ambiente ideale per i modelli dinamici

Dal punto di vista tecnico, il basket offre un terreno di prova ideale per i modelli predittivi. Ogni possesso genera informazioni: tiri tentati, percentuali, falli, cambi di quintetto, ritmo della partita. A differenza di altri sport, questi eventi sono numerosi e ravvicinati, consentendo aggiornamenti frequenti delle previsioni.

Un sistema che elabora dati sul basket non lavora su scenari ipotetici, ma su una sequenza continua di input che modificano le condizioni iniziali. Basta una serie di canestri consecutivi o un infortunio improvviso per alterare radicalmente l’equilibrio previsto.

Questo rende il basket particolarmente interessante per chi studia sistemi adattivi, in grado di ricalcolare parametri senza interrompere il flusso.

Dal dato grezzo all’informazione utilizzabile

Il passaggio critico non è la raccolta del dato, ma la sua trasformazione in informazione. I sistemi predittivi devono filtrare il rumore, pesare le variabili e aggiornare le stime in tempi compatibili con l’evento in corso. Questo implica una catena tecnologica fatta di acquisizione, normalizzazione, calcolo e distribuzione.

Ogni anello della catena introduce un potenziale punto di latenza. Ridurla significa ottimizzare algoritmi, infrastrutture di rete e capacità di calcolo. Nei contesti più avanzati, l’elaborazione avviene in parallelo, sfruttando architetture distribuite e sistemi di caching per evitare colli di bottiglia.

Il risultato è un output che appare “semplice” all’utente finale, ma che in realtà è il prodotto di una complessità elevata.

Quote come output di un sistema complesso

Uno degli output più visibili di questi processi è rappresentato dalle quote basket, che sintetizzano in un singolo valore una quantità significativa di informazioni. Dietro una quota non c’è una previsione statica, ma un sistema che reagisce continuamente agli eventi in corso e alle variazioni di contesto.

Dal punto di vista tecnico, la quota è una funzione che incorpora probabilità aggiornate, margini di sicurezza e correzioni in tempo reale. La sua variazione racconta più di quanto sembri: segnala cambiamenti di ritmo, squilibri emergenti, trend che si consolidano o si interrompono.

L’accesso a queste informazioni avviene attraverso piattaforme che devono garantire aggiornamenti costanti e affidabili che consentano di osservare concretamente come un sistema predittivo traduca il flusso di dati in valori aggiornati, offrendo un esempio pratico di applicazione di modelli dinamici.

Qui l’interesse non è l’uso finale, ma il meccanismo tecnologico che rende possibile l’aggiornamento continuo.

Latenza, affidabilità e fiducia nel sistema

In un sistema predittivo, pochi secondi fanno la differenza. La latenza non è solo un problema tecnico, ma un fattore che incide sull’affidabilità complessiva del modello. Un dato aggiornato in ritardo perde parte del suo valore informativo, soprattutto in un contesto rapido come il basket.

Per questo motivo, le piattaforme che lavorano su dati in tempo reale investono in infrastrutture ridondanti e sistemi di monitoraggio costante. L’obiettivo è mantenere coerenza tra ciò che accade sul campo e ciò che viene rappresentato digitalmente.

Dal punto di vista dell’utente esperto, la fiducia nel sistema nasce proprio da questa coerenza. Quando numeri e realtà divergono, il modello perde credibilità.

Predizione come processo continuo

Un errore comune è considerare la predizione come un atto puntuale. In realtà, nei sistemi moderni è un processo continuo. Ogni previsione è valida solo fino al prossimo evento rilevante. Questo richiede un’architettura flessibile, capace di ricalcolare senza interrompere il servizio.

Nel basket, questa dinamica è particolarmente evidente: una partita non segue un andamento lineare, ma è fatta di accelerazioni, pause, inversioni improvvise. I sistemi predittivi devono essere progettati per gestire questa instabilità strutturale.

Oltre lo sport, una logica applicabile

Sebbene il basket rappresenti un caso di studio efficace, le logiche alla base dei sistemi predittivi in tempo reale trovano applicazione in molti altri ambiti: mercati finanziari, gestione del traffico, monitoraggio energetico. Lo sport diventa così un laboratorio osservabile di dinamiche che altrove restano più opache.

Analizzare come funzionano questi sistemi attraverso esempi concreti aiuta a comprendere meglio una delle sfide centrali dell’informatica moderna: trasformare flussi instabili di dati in informazioni affidabili, senza fermare il mondo mentre i calcoli vengono aggiornati.

Ed è proprio in questa capacità di adattamento continuo che si misura l’evoluzione dei sistemi digitali contemporanei.

Ogni volta che un attacco informatico fa notizia, i titoli dei giornali riportano frasi allarmanti come “hacker che rubano dati” o “hacker che attaccano aziende e governi”. L’immaginario collettivo, plasmato da anni di film, serie TV
e narrazioni mediatiche, associa la figura dell’hacker a un individuo incappucciato, nascosto nell’ombra, intento a digitare frenetici codici su uno schermo pieno di numeri verdi in stile Matrix. Questa rappresentazione, sebbene affascinante, è una semplificazione fuorviante che non riflette la realtà. Gli hacker non sono tutti criminali informatici e, anzi, molti di loro lavorano per proteggere i nostri dati e migliorare la sicurezza digitale.

QUELLI CATTIVI

Un hacker è, prima di tutto, una persona curiosa e appassionata di tecnologia. Il suo obiettivo non è distruggere, danneggiare, bensì comprendere come funzionano i sistemi e spingerli al limite per migliorarne le prestazioni e la sicurezza. Gli hacker sono spesso esperti di informatica, crittografi a e sicurezza digitale, e il loro contributo è essenziale per il progresso tecnologico. Molti di loro lavorano per aziende, organizzazioni governative e istituzioni accademiche, con il compito di individuare falle nei sistemi prima che possano essere sfruttate da veri criminali informatici. Questi professionisti sono noti come “hacker etici” o “white hat”, specialisti di cybersecurity che mettono alla prova infrastrutture digitali per rafforzarne la protezione. Senza gli hacker, Internet sarebbe un ambiente più pericoloso. Sono loro a sviluppare protocolli di sicurezza, migliorare la crittografi a delle comunicazioni e creare difese contro virus e attacchi informatici. Grazie al loro lavoro, le transazioni online, i dati personali e le info sensibili possono essere protette da intrusioni indesiderate. Se oggi possiamo affidarci a connessioni sicure per operazioni bancarie, acquisti online e comunicazioni private, è in gran parte merito del loro impegno.

NEL WEB

Se gli hacker sono figure tecnicamente preparate che usano le loro competenze per il bene comune, chi sono allora i veri criminali informatici? La risposta è chiara: i cracker. I cracker, a differenza degli hacker, violano sistemi informatici per scopi malevoli. Il loro obiettivo non è la conoscenza, ma il profitto, la vendetta o il puro vandalismo. Alcuni rubano dati personali per venderli nel dark web, altri diffondono malware per infettare computer e reti aziendali, altri ancora utilizzano tecniche come il ransomware, criptando file e chiedendo un riscatto per ripristinarli.
Queste attività, purtroppo, causano danni enormi a privati, aziende e istituzioni pubbliche. Milioni di euro vengono persi ogni anno a causa di attacchi informatici, e il cybercrimine rappresenta oggi una delle minacce più gravi per l’economia globale. La distinzione tra hacker e cracker è dunque cruciale: gli hacker esplorano e proteggono, i cracker distruggono e sfruttano. Tuttavia, nei media questa differenza si è persa, e il termine “hacker” viene spesso usato in modo improprio per indicare chiunque compia reati informatici.

DAL CYBERCRIMINE ALL’HACKTIVISMO

Non tutti gli hacker, però, rientrano nella categoria dei “white hat” o dei criminali informatici. Esiste anche un’altra categoria: gli hacktivisti, cioè coloro che usano le proprie competenze per scopi politici o sociali. Gli hacktivisti si muovono in una zona grigia dell’etica digitale. Non attaccano i sistemi per denaro, ma per diff ondere informazioni censurate, svelare scandali politici o combattere regimi oppressivi. Il gruppo Anonymous è uno degli esempi più noti: negli anni, hanno rivelato documenti riservati, smascherato corruzione e difeso la libertà di espressione. Alcuni li considerano eroi digitali, altri semplici criminali informatici. Indipendentemente dalle opinioni, il loro impatto sulla
società è innegabile.

DISTINZIONI NECESSARIE

Continuare a confondere hacker e cracker non è solo un errore linguistico, ma una distorsione che danneggia chi lavora nel settore della sicurezza informatica. Definire un esperto di cybersecurity un “criminale” significa alimentare un pregiudizio ingiusto e ignorare il valore del loro lavoro. Le aziende, i governi e gli utenti comuni devono comprendere questa distinzione per poter navigare nel mondo digitale con maggiore consapevolezza. La prossima volta che sentirete parlare di un attacco informatico, ponetevi una domanda: è stato un hacker o un cracker?

Leggi anche: “I gadget preferiti dagli hacker“

Il phishing continua a essere una delle minacce informatiche più diffuse e pericolose. Non servono virus sofisticati o attacchi degni di un film: spesso basta una finta pagina di login o un’e-mail ben scritta per convincere una persona a consegnare volontariamente le proprie password. È quanto emerge dal nuovo report di Check Point Research sulle tendenze del brand phishing nel quarto trimestre del 2025. Ma che cos’è il brand phishing? In parole semplici, è una truffa online in cui i criminali informatici si fingono aziende famose e affidabili – come Microsoft, Google o Amazon – per ingannare le vittime. L’utente crede di essere sul sito “giusto”, inserisce le proprie credenziali e, senza accorgersene, le consegna agli attaccanti.

I marchi presi di mira

Secondo il report, Microsoft è ancora una volta il marchio più imitato, coinvolto nel 22% di tutti i tentativi di phishing legati ai brand. Seguono Google (13%) e Amazon (9%), spinta soprattutto dal periodo di Black Friday e acquisti natalizi. Torna nella top 10 anche Facebook, segno che gli account social restano un obiettivo molto appetibile per i criminali.

Il motivo è semplice: le credenziali valgono oro. Una password Microsoft o Google, ad esempio, può aprire la porta alla posta elettronica, ai documenti salvati nel cloud, alle chat di lavoro e perfino ad altri servizi collegati. È un po’ come consegnare le chiavi di casa insieme a quelle dell’ufficio. Il settore più colpito resta quello tecnologico, seguito dai social network e dai servizi finanziari. I cybercriminali sanno che fingendosi piattaforme molto usate aumentano le probabilità di successo: più un servizio è familiare, meno l’utente tende a sospettare.

Il report racconta anche alcuni casi concreti. Uno dei più insidiosi riguarda Roblox, piattaforma amatissima dai più giovani. Gli attaccanti hanno creato un sito con un indirizzo quasi identico a quello originale (cambiando una sola lettera) e un gioco falso dall’aspetto realistico. Cliccando su “Gioca”, i bambini venivano portati a una pagina di login identica a quella ufficiale, dove le credenziali venivano rubate senza alcun segnale evidente.

Pagina fraudolenta del gioco Roblox

Pagina di accesso fraudolenta a Roblox

Un altro esempio è Netflix: una finta pagina di “recupero account” chiedeva e-mail e password, sfruttando la paura di perdere l’accesso al proprio abbonamento. Stessa tecnica anche per Facebook, con pagine tradotte in lingua locale per sembrare ancora più credibili.

Pagina fraudolenta di Netflix

Pagina Facebook (Meta) fraudolenta

La forza del phishing sta proprio qui: grafica curata, indirizzi Web simili a quelli reali e messaggi che fanno leva su urgenza, paura o curiosità. Per difendersi non servono competenze tecniche avanzate, ma attenzione: controllare sempre l’indirizzo del sito, diffidare di link ricevuti via e-mail o messaggio e, soprattutto, non inserire mai le proprie password partendo da un link. Un piccolo gesto che può evitare grandi problemi.

Leggi anche: “L’IA attira sempre più i piccoli“

*Illustrazione progettata da Checkpoint

Sicuramente le distribuzioni Linux pronte all’uso sono comode. Installate Ubuntu, Fedora o Debian e avete subito a
disposizione un sistema completo. Ma questa comodità porta con sé vincoli e compromessi: pacchetti scelti da altri, servizi attivi di default, librerie che non userete mai… Con Linux From Scratch (LFS) il paradigma si ribalta. Qui siete voi a decidere tutto: dal compilatore al gestore di init, dal kernel alle librerie utente. Non c’è software imposto e nessun pacchetto superfluo. Questo vi permette di ottenere un sistema più snello, cucito sulle vostre esigenze. Non solo: eliminando i livelli di astrazione tipici delle distro generaliste, avrete un controllo totale sulla superficie d’attacco e anche sulla manutenzione. Se vi interessa un server che faccia solo quello che volete, senza processi nascosti, o un ambiente desktop minimale che non sprechi risorse, LFS è la strada più diretta.

Preparare il terreno di lavoro

Il primo passo è predisporre l’ambiente. LFS non si installa “sopra” come una normale distro: si costruisce da zero all’interno di uno spazio dedicato. Potete usare un vecchio PC, un server secondario o una macchina virtuale: l’importante è avere una partizione vuota o un disco dedicato. Il progetto consiglia di partire da una distro Linux funzionante che faccia da “host”, ossia l’ambiente in cui compilerete i sorgenti. Qui installerete i pacchetti indispensabili: compilatore GCC, binutils, make, bash, tar e altri strumenti di base. Il metodo LFS si articola in due fasi. Nella prima create una toolchain temporanea: compilatore, linker e librerie essenziali isolati dal sistema host. Questo garantisce che i pacchetti successivi vengano costruiti in un ambiente controllato, senza dipendere da configurazioni esterne. Una volta pronta la toolchain, entrate in un chroot nella nuova partizione: da qui in avanti lavorerete come se foste già dentro la vostra futura distro. Ogni pacchetto viene scaricato dai sorgenti ufficiali, verificato con checksum, scompattato, configurato, compilato e installato in sequenza. Non è un’operazione rapida: LFS introduce il concetto di SBU (Standard Build Unit), cioè il tempo impiegato a compilare binutils sul vostro hardware. Ogni altro pacchetto viene stimato in multipli di quell’unità: alcuni richiedono pochi minuti, altri ore intere. In questa fase scegliete già l’impronta del sistema: se sarà un server ridotto all’osso o la base per un desktop più ampio.

Il progetto Linux From Scratch mette a disposizione non solo le istruzioni per costruire una distro da zero, ma anche guide complementari per estenderla (BLFS), automatizzarla (ALFS) o adattarla a scenari particolari. Un ecosistema che permette di creare un vero sistema operativo personalizzato

Compilare i componenti di base

Arrivati all’interno del chroot dedicato, dovete compilare uno a uno i pacchetti fondamentali del sistema. Ogni installazione segue una sequenza tipica: scaricare i sorgenti, scompattarli, configurare, compilare e installare. Per esempio, per Bash farete:

tar -xf bash-5.2.tar.gz
cd bash-5.2
./configure –prefix=/usr –without-bash-malloc
make
make install

Questo schema ritorna con quasi tutti i pacchetti, anche se ogni progetto introduce opzioni specifiche. LFS vi guida passo dopo passo, indicando quali parametri usare per evitare dipendenze indesiderate e assicurare la coerenza
del sistema. Non è un lavoro meccanico: compilare glibc, per esempio, richiede particolare attenzione, perché è la libreria standard su cui si basano praticamente tutti gli altri programmi.

tar -xf glibc-2.39.tar.xz
cd glibc-2.39
mkdir build && cd build
../configure –prefix=/usr –disable-werror
make
make install

Una volta installato il kernel e configurato il bootloader (GRUB resta la scelta più comune, ma potete optare per syslinux se vi serve un ambiente molto leggero o per systemd-boot se usate systemd), il vostro sistema è già in grado di avviarsi.

Personalizzare la distribuzione

Con la base installata, entra in gioco la vera libertà: la personalizzazione. Il primo nodo riguarda l’init system, cioè il modo in cui il sistema si avvia e gestisce i servizi. LFS propone ancora SysVinit, storico e lineare: semplice da configurare, leggibile in ogni sua parte e facilmente modificabile. Ma non siete vincolati: potete decidere di integrare
systemd, con la sua gestione avanzata di log e dipendenze, oppure optare per alternative minimaliste come runit o s6, amate da chi costruisce server snelli o ambienti embedded. Cambiare init non è un dettaglio: influenza la struttura dell’intero sistema, il modo in cui i processi vengono monitorati e le possibilità di debugging. Il kernel è l’altro grande campo di personalizzazione. Con il comando make menuconfig potete entrare in un’interfaccia testuale che elenca centinaia di opzioni. Qui scegliete non solo quali moduli abilitare, ma anche se integrarli direttamente o mantenerli esterni.

Solo quello che vi serve

Immaginate di voler creare un router domestico: potrete abilitare solo il supporto Ethernet, Netfilter e le funzioni necessarie per il NAT, eliminando tutto ciò che riguarda audio, grafica o periferiche superflue. Per un server di posta
basterà un kernel con supporto ai filesystem usati e ai driver di rete. Una volta definito l’impianto di base, si passa ai servizi e alle librerie. Qui entra in gioco BLFS (Beyond Linux From Scratch), che vi accompagna nell’aggiunta di tutto ciò che non è strettamente necessario al boot ma che rende un sistema realmente utilizzabile nel quotidiano. Potete installare Xorg per avere un server grafico, scegliere un window manager leggerissimo come i3 o Openbox, oppure spingervi verso ambienti completi come KDE Plasma o GNOME, accettando però un aumento di complessità e dipendenze.
Ecco un esempio di compilazione manuale di Xorg:
tar -xf xorg-server-21.1.8.tar.xz
cd xorg-server-21.1.8
./configure –prefix=/usr –disable-static
make
make install

Per un desktop minimale, potete unire Xorg, un window manager e un browser leggero come Dillo o Midori, ottenendo un sistema reattivo anche su hardware datato.

Rete e sicurezza

Un altro livello di personalizzazione riguarda i servizi di rete. Non vi interessa avere cupsd per la stampa o avahi per il discovery automatico? Basta non compilarli. Vi serve invece un server SSH sicuro per gestire la macchina da remoto? Installate OpenSSH e configuratelo con chiavi pubbliche, evitando login via password. Volete usare la distro
come appliance per un singolo compito? Potete costruire un sistema che avvia direttamente un servizio specifico, per esempio un server Web con nginx o un container runtime, senza nemmeno caricare un desktop. LFS vi permette anche di decidere quali librerie supportare. Potete scegliere versioni minimali di libjpeg, libpng o zlib, riducendo la dimensione complessiva, oppure integrare stack completi per multimedia e sviluppo. In un ambiente server potete limitare le librerie grafiche, mentre in un desktop di lavoro potete installare GTK, Qt o entrambe, a seconda delle applicazioni che volete far girare. Non mancano le ottimizzazioni per la sicurezza: potete configurare OpenSSL
abilitando solo gli algoritmi che vi interessano, oppure integrare iptables/nftables direttamente nel kernel per avere un firewall nativo all’avvio.

Manutenzione e autonomia

Una volta completata la costruzione, vi trovate di fronte a un sistema unico, ma anche a una responsabilità: non esiste un package manager. Ogni aggiornamento richiede di scaricare i sorgenti aggiornati, ricompilare e reinstallare. Potete organizzare script di automazione, o usare progetti paralleli come ALFS (Automated LFS) per ridurre la fatica. La manutenzione è parte integrante dell’indipendenza. Significa monitorare le vulnerabilità dei pacchetti che avete scelto, aggiornare il kernel quando necessario e ricompilare le librerie critiche. Ma significa anche poter intervenire a livello profondo: personalizzare il kernel per ridurre la superficie d’attacco, eliminare demoni inutili, controllare ogni singolo file di configurazione. I limiti ci sono: LFS non è la strada migliore se cercate aggiornamenti rapidi o facilità d’uso. Per server dedicati, appliance, ambienti embedded o workstation offre, però, un controllo totale. In questi contesti, l’assenza di software imposto diventa un vantaggio. Nessuno può decidere per voi di introdurre systemd, Snap o servizi cloud nascosti: siete voi a governare tutto.

Leggi anche: “AxOS: una distro a prova di tracciamento”

*Illustrazione progettata da Freepik

Gli switch KVM sono dispositivi che si usano per controllare due o più server (o semplici desktop) con una sola tastiera, un solo mouse e un solo monitor. Il KVM che abbiamo provato per questo numero, JetKVM, è particolare: non è pensato per controllare più macchine presenti nella stessa stanza/rete locale, bensì tramite il protocollo IP
consente di gestire un server, o un PC, da remoto via Internet usando un altro computer. Ovunque ci troviamo, possiamo collegarci a una particolare pagina Web che ci mostra il desktop del sistema operativo in esecuzione sul computer da controllare.

Usare JetKVM è davvero facile (qui stiamo controllando una macchina Linux Mint), ma ciò non preclude l’accesso a tante opzioni per migliorare il collegamento, compresa la creazione di macro per velocizzare le operazioni e la regolazione della qualità video

Com’è fatto?

Nella scatolina che contiene JetKVM troviamo, oltre allo switch IP, un cavo HDMI/mini HDMI, un cavo USB-C/USB-A e un cavo splitter USB-C che permette di separare alimentazione e connessione dati se la macchina da controllare non fornisce alimentazione USB in standby. Bisogna collegare JetKVM e PC da controllare usando il cavo HDMI e quello USB-C/USB-A, poi si mette in rete il JetKVM connettendo un cavo di rete (non si può usare il Wi-Fi) e si è pronti al primo setup. JetKVM nella parte frontale integra un piccolo display che mostra l’indirizzo IP che gli è stato assegnato dal router. Lo inseriamo in un browser Web e ci ritroviamo in un’interfaccia Web che avvia la rapida
operazione di setup. Ci viene chiesto di impostare o meno una password per accedere al PC da controllare, dopodiché appare una schermata con alcuni pulsanti e, al centro in grande, lo schermo del computer da gestire. Possiamo quindi usarlo come se fossimo davanti a esso. Al momento stiamo comunque controllando un PC che abbiamo sotto mano, nella nostra rete locale. Per controllare server/PC da remoto entra in gioco il protocollo IP. Ipotizziamo di uscire di casa e di aver bisogno di modificare un’impostazione di un server. Digitando l’indirizzo https://app.jetkvm.com/ avremo accesso al nostro server. Per poterlo fare prima di uscire di casa è necessario la prima volta registrare il nostro JetKVM e il computer da controllare dall’interfaccia Web dello switch. Basta cliccare sul pulsante Settings, andare alla voce Access e qui cliccare sul pulsante Adopt KVM to Cloud account. Ci registriamo presso il servizio con la nostra email di Gmail (è supportato solo questo servizio) e poi aggiungiamo il computer da controllare. Insomma, è tutto davvero semplice. Il passaggio da Internet causa un po’ di ritardo nella trasmissione, ma è quasi impercettibile. L’interfaccia Web di JetKVM ci permette di far apparire una tastiera virtuale in caso di bisogno, di accedere anche al BIOS della macchina, di installare un nuovo sistema operativo e in Settings abbiamo tante opzioni per aggiustare la connessione e gestire la macchina remota. Gli utenti più esperti possono anche usare Tailscale per il controllo remoto, al posto del sistema cloud di JetKVM.

SPECIFICHE:

Sistema operativo: Linux 5.10 con Buildroot
CPU: RockChip RV1106G3, Cortex A7 1 GHz
RAM: 256 MB DDR3L
Storage: 16 GB eMMC
Schermo: 1,69″ IPS, 240×280 pixel, touch screen capacitivo
Porte: Ethernet RJ45 (100Mbps), USB-C 2.0, Mini HDMI, porta d’espansione RJ12

Leggi anche: “Test hardware: Fritz!Box 7690“

AxOS è una distribuzione indipendente basata su Arch, nata con l’obiettivo dichiarato di “migliorare” Linux intervenendo su estetica, performance e semplicità d’uso. L’installazione avviene tramite un sistema guidato chiamato Epsilon, che permette di configurare partizionamento, ambiente desktop, kernel, driver e pacchetti opzionali in pochi passaggi. Il processo è semplice e ben documentato. Potete scegliere fra quattro ambienti: Plasma, orientato alla completezza; Calla, leggerissimo e minimalista; Sleex, costruito su Hyprland con effetti grafici molto curati, widget e overlay personalizzati e, infine, Theom, una versione molto essenziale, basata su i3wm. Tutti condividono lo stesso tema grafico, con modalità scura e chiara selezionabili e una coerenza stilistica rara tra distribuzioni multi-desktop. I pacchetti sono gestiti con pacman ma anche tramite Epsilon (epsi), uno strumento sviluppato dal team che consente installazioni pulite e sicure, evitando duplicati e integrando la compatibilità con l’AUR. I componenti sono compilati con flag ottimizzati per le performance e la distribuzione supporta il kernel Zen come opzione.

L’edizione Plasma offre un’interfaccia ispirata ai desktop tradizionali e offre un ambiente solido, configurabile e immediato, con pieno supporto alle applicazioni Qt

Privacy senza compromessi

AxOS si distingue anche per un’impostazione radicale sul piano della privacy: nessuna telemetria, niente raccolta dati oltre al fatto che Bluetooth e rete sono disabilitati al primo avvio. Il filesystem Btrfs è configurato per creare snapshot automatici prima di fare gli aggiornamenti. Questo garantisce una sicurezza notevole senza sacrificare la natura rolling release del sistema. Anche se in generale il progetto è solido, non mancano alcune criticità: la distribuzione
non supporta Secure Boot, non è ottimizzata per l’uso in una macchina virtuale e richiede una certa competenza nei desktop più essenziali, in cui molte configurazioni si fanno da terminale o tramite file JSON. Sleex, pur ricco di  funzioni innovative, può risultare instabile in alcuni scenari. Inoltre, AxOS è disponibile solo per architettura x86‑64, senza supporto per ARM o 32 bit. Nel complesso è una buona distribuzione per utenti consapevoli che cercano una base solida, una gestione pulita e uno stile visivo moderno, con privacy e controllo dell’utente elevati.

L’ambiente Sleex punta sull’estetica e sull’interazione con effetti grafici, widget dinamici e un’interfaccia Hyprland altamente personalizzabile

Leggi anche: “Qbes: la distro Linux super-blindata“

Partiamo da una premessa e da una considerazione. La premessa: GiveWP è il plugin più utilizzato in assoluto per ricevere donazioni sul proprio blog WordPress. La considerazione: WordPress è scritto in PHP, che è ormai da parecchi anni, un linguaggio “ad oggetti”, o Object Oriented Programming (OOP). Ci sono centinaia di classi, tra il core e i vari plugin di una istanza di WP, quindi centinaia di tipologie diverse di oggetti. Come del resto è ovvio per ogni programma di una certa complessità. E spesso capita che due funzioni debbano passarsi degli oggetti, ad  esempio per verificare o memorizzare delle impostazioni. Per semplificare questa cosa, PHP prevede la serializzazione degli oggetti: in poche parole, un intero oggetto (con tutte le sue proprietà) può essere trasformato in una stringa. Quando è un semplice testo “leggibile” si può anche molto facilmente passare a un’altra funzione sotto forma di singolo argomento di tipo stringa, oppure memorizzare direttamente in un file o anche in un database. Chi ha provato a leggere la tabella wp_options si accorgerà che alcuni dei valori contengono quanto di seguito:

a:5:{i:0;s:35:”add-fromserver/
add-from-server.
php”;i:1;s:19:”jetpack/jetpack.
php”;i:2;s:27:”wp-super-cache/
wp-cache.php”;}

GiveWP è il più scaricato per siti che vogliono raccogliere donazioni, con oltre 100 mila download. FONTE

Questo testo è una serializzazione di un oggetto PHP che tiene traccia di tutti i plugin installati su WP. Quando WordPress core legge questo testo dal database può direttamente ricostruire l’apposito oggetto che gestisce i plugin. Similmente, anche i vari plugin possono a loro volta memorizzare informazioni nel database, e passarsele a vicenda.
Il grosso vantaggio di questo approccio è che, se bisogna prevedere lo spazio per memorizzare qualcosa di molto generico, basta definire un campo di tipo testo per tutte le occasioni. In altre parole: diversi plugin avranno un diverso numero di impostazioni personalizzate. Se si dovesse pensare di costruire una tabella per memorizzarle non si potrebbe realizzarne in anticipo una valida per tutti: se un plugin ha 3 opzioni è possibile definire 3 colonne, ma se poi si installa un plugin da 4 opzioni mancherà una colonna. E quindi è molto più semplice avere una sola colonna e mettere tutto lì dentro come testo. Inoltre, se il meccanismo di traduzione da oggetto a testo e viceversa è standardizzato, di fatto qualsiasi cosa può essere memorizzata nello stesso modo, non c’è bisogno di prevedere funzioni personalizzate. Il problema è che bisogna controllare molto bene la stringa di testo che si passa da una parte
all’altra: non si deve dimenticare che un oggetto PHP ha non soltanto delle proprietà ma anche dei metodi, quindi esegue del codice tramite il compilatore PHP. Se qualcuno riuscisse a manomettere la versione serializzata di un oggetto, quando la classe cerca di costruirlo, finirà per eseguire qualcosa che non era previsto e causare un malfunzionamento o dei veri e propri danni. Il pericolo aumenta quando la classe che definisce l’oggetto prevede anche dei metodi reimplementabili, come costruttore e distruttore: si tratta rispettivamente del metodo che viene lanciato alla creazione e alla distruzione di un oggetto della classe. Non sono obbligatori, ma solitamente si usano per inizializzare delle proprietà. Altri metodi presenti di default ma che possono essere reimplementati con funzioni custom sono _set e _get, che permettono rispettivamente di impostare o recuperare delle proprietà della classe. In GiveWP, la classe Give prevede proprio la funzione _get:

class Give
{
public function __get( $propertyName
)
{
return $this->container->
get( $propertyName );
}

Questa funzione dovrebbe limitarsi a restituire una proprietà sulla base del suo nome. Al momento di processare
il pagamento, però, l’utente specifica il proprio indirizzo di fatturazione che, proprio, GiveWP gestisce in questo modo:

namespace Give\PaymentGateways\
DataTransferObjects;
final class GiveInsertPayment-
Data
{
public $userInfo;
private function getLegacy-
BillingAddress()
{
$donorDonationBillingAddress
= $this->userInfo[‘address’];
$address = [
‘line1’ => $donor-
DonationBillingAddress->address1,
‘line2’ => $donor-
DonationBillingAddress->address2,
‘city’ => $donorDonationBillingAddress->
city,
‘state’ => $donor-
DonationBillingAddress->state,
‘zip’ => $donorDonationBillingAddress->
zip,
‘country’ => $donor-
DonationBillingAddress->country,
];
if (! $donorDonation-
BillingAddress->country) {
$address = false;
}
return $address;
}
}

L’indirizzo è ovviamente un campo inserito dall’utente, quindi andrebbe validato con attenzione, ma non è così. E se un malintenzionato riuscisse a impostare come $userInfo[‘address’] un riferimento a una istanza di un oggetto Give, questo verrebbe caricato come oggetto.

Trovi il codice a questo indirizzo