🇪🇺 Anche la Commissione UE usa Element come alternativa sovrana a Microsoft Teams!

La Commissione Europea ha infatti adottato Element, basato su Matrix, come alternativa a Teams. Una scelta interessante nel percorso verso una maggiore sovranità digitale europea, anche se a quanto pare non tutti i dipendenti l'hanno accolta con entusiasmo. 😅

👉 Leggi l'articolo di DDay https://www.dday.it/redazione/58966/la-commissione-ue-ha-unalternativa-sovrana-a-teams-che-pero-non-piace-ai-dipendenti

Se ancora non utilizzate Element e Matrix, è un buon momento per provarli: Element X è migliorato parecchio e l'esperienza d'uso è decisamente più matura.

💬 Ecco alcuni canali Matrix da seguire:

🔹 Devol

https://matrix.to/#/#devol:mozilla.org

🔹 Mastodon & Fediverso

https://matrix.to/#/#mastodon:mozilla.org

🔹 FediLUG – Linux User Group del Fediverso

https://matrix.to/#/#fedilug:fedimedia.it

🔹 Supporto Element / Matrix

https://matrix.to/#/#supporto-matrix:fedimedia.it

@internet@diggita.com

#matrix #element #UE #EU #ElementX #CommissioneEuropea #teams #MicrosoftTeams #CommissioneEU #sovranitàdigitale #sovranitàdigitaleeuropea #devol #fedilug #mastodon #fediverso #linux

#ClingSTUN #Linux #Backdoor Abuses Public STUN Infrastructure
https://securityaffairs.com/200450/uncategorized/clingstun-linux-backdoor-abuses-public-stun-infrastructure.html
#securityaffairs #hacking #malware

Non sai come gestire i tuoi #Progetti ?
Vorresti una soluzione #FOSS e #Privacy #Oriented che ti consenta tenere a mente tutti i tuoi task da portare a termine e collaborare con il tuo team?

Da oggi Puoi!
Come???

Scoprilo nel mio ultimo video ⏩ https://youtu.be/tm7JZThpHhQ?is=vEYqzfTC2YZwocXZ

#linux #opensource #freesoftware #app

@gnulinuxitalia@feddit.it

Non sai come gestire i tuoi #Progetti ?
Vorresti una soluzione #FOSS e #Privacy #Oriented che ti consenta tenere a mente tutti i tuoi task da portare a termine e collaborare con il tuo team?

Da oggi Puoi!
Come???

Scoprilo nel mio ultimo video ⏩ https://youtu.be/tm7JZThpHhQ?is=vEYqzfTC2YZwocXZ

#linux #opensource #freesoftware #app

@lealternative@feddit.it

Kagi abbandona lo sviluppo di Orion per Linux e Windows: il browser diventa open source
#kagi #Orion #browser #webkit #linux #windows
Kagi annuncia lo stop allo sviluppo diretto di Orion per Linux e Windows per concentrarsi su macOS e iOS. Il codice sorgente verrà rilasciato open source alla community.

https://www.marcosbox.com/2026/10/04/kagi-abbandona-lo-sviluppo-di-orion-per-linux-e-windows-il-browser-diventa-open-source/

@opensource@diggita.com

RE: https://mastodon.nl/@doeidag/117381563797810892

Bij deze doe ik een voorzet van toffe tech die ik recent veel ben gaan gebruiken.

LocalSend is een app waarmee je makkelijk bestanden kan delen. Een opensource Airdrop.

Van #Apple telefoon naar #Linux laptop en #Android Telefoon naar #Windows desktop. Het maakt allemaal niks uit. Je kan alles delen.

#LocalSend is een superhandige app om bestanden tussen alle verschillende besturingssystemen lokaal te delen. Aanrader!

https://localsend.org/

#DoeiDag #Tips #DiDay #Didit #OpenSource #Tech

Volete scoprire cosa c'è dietro Raccoon?
Lo abbiamo svelato con l'intervista interessantissima ad @akesiseli@poliversity.it , che ringrazio infinitamente per avermela concessa!

Se ve la foste persa potete recuperarla al link ⏩ https://youtube.com/live/ZqjXbGZvHXw?feature=share

#linux #fediverso #foss

@gnulinuxitalia@feddit.it

Perché la maggior parte degli script bash “funziona sulla mia macchina” e poi fallisce in produzioneChiunque amministri sistemi #Linux ha almeno uno script #bash scritto in dieci minuti per risolvere un problema urgente, che poi è finito silenziosamente in produzione tramite un cron job. Il problema è che uno script funzionale non è automaticamente uno script affidabile: la differenza si vede quando lo script gira senza terminale, senza nessuno che guarda l’output, magari in concorrenza con un’altra esecuzione dello stesso job.

In questo articolo ripassiamo rapidamente le basi della scrittura di script bash, ma ci concentriamo soprattutto su ciò che separa uno script “da developer” da uno pronto per l’automazione in un ambiente sistemistico reale: gestione degli errori, logging, locking e debugging.

Le fondamenta, in breveUno script bash è un file di testo con una sequenza di comandi che la shell esegue in ordine. La prima riga, lo shebang, indica al #kernel quale interprete usare:

#!/usr/bin/env bash
echo "Hello, world"Usare /usr/bin/env bash invece di /bin/bash hardcoded rende lo script più portabile su sistemi dove bash non risiede nel path standard (tipico su alcune distribuzioni minimali o #container). Reso eseguibile con chmod +x script.sh, lo script si lancia con ./script.sh.

Variabili e quotingUna convenzione diffusa negli ambienti Linux è usare il maiuscolo per variabili globali/di configurazione e il minuscolo per variabili locali, evitando di sovrascrivere variabili di sistema come PATH, HOME o USER. La regola più importante, spesso ignorata, è: quotare sempre le variabili.

SITE="miosito.it"
DATE=$(date +%Y-%m-%d)
echo "Backup di $SITE il $DATE"Senza le virgolette, un valore contenente spazi o caratteri speciali può spezzare la logica dello script in modi difficili da diagnosticare, specialmente con percorsi di file.

Argomenti e parametri posizionaliif [ $# -lt 1 ]; then
echo "Uso: $0 "
exit 1
fi
FILE="$1"Per script più complessi, destinati a essere invocati con flag (-v, --dry-run), conviene usare getopts per le opzioni brevi, che gestisce automaticamente la validazione e i messaggi di errore standard, evitando il parsing manuale di $@ con cicli while annidati e propensi a bug.

Dove gli script “da sviluppatore” falliscono in produzione1. Modalità strict e i suoi limiti realiLa pratica più citata è attivare la modalità rigorosa in testa allo script:

set -euo pipefail-e: esce immediatamente se un comando termina con stato diverso da zero

-u: tratta le variabili non definite come errore

-o pipefail: propaga il fallimento anche a metà di una pipeline, non solo sull’ultimo comando

È una buona base, ma va usata sapendo dove non funziona: set -e viene ignorato all’interno delle condizioni di if, nelle catene &&/|| e in certi contesti di funzione. Inoltre pipefail può creare falsi positivi con comandi come grep (che esce con stato diverso da zero se non trova corrispondenze) o head (che chiude il descrittore a monte, generando l’exit code 141 su SIGPIPE). Se il vostro script fa comando | grep pattern dentro uno script in pipefail, uno “zero risultati” legittimo può far abortire l’intero job: va gestito esplicitamente, ad esempio con grep pattern || true quando l’assenza di match è un esito accettabile.

2. Logging: se gira da cron, nessuno vede lo stdoutUno script lanciato da terminale che scrive con echo è inutile quando lo stesso script gira da cron: l’output, se non rediretto, o finisce in una mail di sistema che nessuno #legge, o si perde. La soluzione minima è una funzione di logging centralizzata:

LOGFILE="/var/log/watchdog.log"

log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOGFILE"
}

log "Script avviato"Questo pattern, combinato con local per le variabili interne alle funzioni (evitando l’inquinamento dello scope globale), è alla base di quasi ogni script di automazione che vale la pena mettere in cron.

3. Evitare esecuzioni concorrenti con flockUn errore classico: un job schedulato ogni minuto che, in caso di rallentamento (I/O lento, rete, dipendenza esterna), parte una seconda volta prima che la prima istanza sia terminata. Il modo standard per evitarlo su Linux è flock, che #usa un file descriptor come lock a livello di kernel:

#!/usr/bin/env bash
set -euo pipefail

LOCK_FILE="/run/lock/$(basename "$0").lock"
exec 200>"$LOCK_FILE"

if ! flock -n 200; then
echo "Esecuzione precedente ancora attiva, salto questo ciclo" >&2
exit 0
fi

echo "Lock acquisito, avvio il job reale"

... logica dello script ...Il flag -n rende l’acquisizione non bloccante: se un’altra istanza detiene già il lock, lo script esce subito invece di accodarsi. Se preferite attendere fino a un certo timeout invece di saltare il ciclo, -w 30 attende fino a 30 secondi prima di arrendersi. È preferibile salvare il lock file sotto /run/lock piuttosto che /tmp, che su molte distribuzioni viene ripulito periodicamente anche mentre un processo è in esecuzione. In alternativa, il locking si può applicare direttamente dal crontab senza toccare lo script:

*/1 * * * * /usr/bin/flock -n /run/lock/sync.lock /usr/local/bin/sync.sh4. Un watchdog completo, con logica di retryMettendo insieme logging, controllo di stato e gestione #dell’errore, un caso d’uso ricorrente per un sistemista è un watchdog che verifica un servizio #systemd e tenta un riavvio in caso di failure:

#!/usr/bin/env bash
set -euo pipefail

SERVICE="nginx"
LOGFILE="/var/log/watchdog.log"

log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOGFILE"
}

if ! systemctl is-active --quiet "$SERVICE"; then
log "$SERVICE risulta down. Tento il riavvio."
systemctl restart "$SERVICE"
if systemctl is-active --quiet "$SERVICE"; then
log "$SERVICE riavviato correttamente."
else
log "$SERVICE non è ripartito: serve intervento manuale."
exit 1
fi
fiNotate l’uso di exit 1 nel caso di fallimento definitivo: se questo script è invocato da un sistema di monitoraggio esterno (Nagios, Zabbix, un semplice controllo su exit code), un codice di uscita diverso da zero è ciò che permette di trasformare un log dimenticato in un alert reale.

Debug: strumenti che risparmiano orebash -n script.sh — verifica solo la sintassi, senza eseguire nulla

bash -x script.sh — traccia ogni comando con le variabili espanse, utile per capire cosa succede realmente riga per riga

set -x / set +x — attiva/disattiva il tracing solo su una porzione dello script

shellcheck script.sh — #analisi statica che individua variabili non quotate, condizioni malformate e pipe inutili che bash -n non può rilevare; è disponibile nei repository di tutte le principali distribuzioni ed è ormai lo standard de facto prima di qualsiasi merge in un repository di script di automazione

ConclusioneLe basi della sintassi bash si imparano in un pomeriggio; la differenza tra uno script giocattolo e uno adatto alla produzione sta tutta negli aspetti che spesso vengono aggiunti solo dopo il primo incidente in produzione: modalità strict usata consapevolmente, logging pensato per l’esecuzione non interattiva, locking per evitare sovrapposizioni, e una pipeline minima di verifica (shellcheck più test manuale con bash -x) prima di schedulare qualsiasi cosa su cron o systemd timer. Vale la pena trattare gli script di automazione con lo stesso rigore riservato al codice applicativo: revisione, versionamento e, quando possibile, un minimo di test automatizzati.

Fonte originale: Linux Bash Scripting: Writing Your First Script, LinuxBlog.io.

Il 29 settembre 2026 Microsoft ha reso generalmente disponibili i #container #WSL, portando su #Windows la possibilità di eseguire container #Linux nativi senza installare #Docker Desktop. La funzionalità arriva con wslc.exe, un nuovo strumento a riga di comando integrato direttamente nel Windows Subsystem for Linux (WSL 3.0.1), e segna un passo importante per chi lavora quotidianamente con container su macchine Windows: sviluppatori .NET, team #DevOps e sistemisti che gestiscono ambienti ibridi.

In questo articolo vediamo cosa cambia rispetto a Docker Desktop, come installare e usare wslc, quali sono i controlli enterprise disponibili tramite #Intune e #Defender for Endpoint, e quali limiti bisogna conoscere prima di adottarlo in produzione.

Perché WSL containers e non “solo” Docker DesktopFino ad oggi, eseguire container Linux su Windows significava quasi sempre installare Docker Desktop, che a sua volta si appoggia su una VM WSL2 per fornire il kernel Linux. Con i container WSL, Microsoft sposta il motore dei container direttamente dentro l’infrastruttura WSL, eliminando uno strato intermedio: niente demone Docker separato da gestire, niente licenza Docker Desktop da considerare per le aziende con più di 250 dipendenti o oltre 10 milioni di dollari di fatturato (requisito che per molte realtà italiane ha reso Docker Desktop un costo da giustificare).

Il risultato dichiarato da Microsoft è un accesso ai file Windows fino a 2 volte più veloce rispetto alle soluzioni basate su virtiofs tradizionale, grazie a un nuovo modello di rete chiamato internamente “Consommé mode”, che instrada il traffico della VM attraverso un processo Windows eseguito con i permessi dell’utente della sessione, migliorando la compatibilità con VPN aziendali e firewall perimetrali — uno scenario molto comune nelle reti enterprise italiane dove Docker Desktop spesso va in conflitto con client VPN come Cisco AnyConnect o Fortinet.

Installazione e primi comandiNon serve installare nulla di separato: wslc.exe è incluso a partire da WSL 3.0.1. Basta aggiornare WSL dal prompt dei comandi o da PowerShell:

wsl --update
wsl --versionIl comando wsl --version deve riportare almeno la 3.x (oppure 2.9.3+ per chi è rimasto sul canale di anteprima). Fatto questo, si può avviare subito un primo container di prova:

wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"Per un caso d’uso più realistico, ecco come avviare un web server Nginx in background con il port forwarding verso l’host Windows:

wslc run -it --rm -d -p 8080:80 --name web nginx
curl localhost:8080La gestione del ciclo di vita dei container ricalca la sintassi Docker, cosa che rende la curva di apprendimento quasi nulla per chi già conosce Docker CLI:

wslc container ps
wslc container stop web
wslc container restart web
wslc container cp web:/var/log/nginx/access.log .
wslc system info
wslc eventsCon la GA sono arrivati anche comandi per la gestione della rete, utili quando si orchestrano più container che devono comunicare tra loro:

wslc network create mynet
wslc network connect mynet web
wslc network disconnect mynet webPer le immagini, sono supportati i flag più comuni per operazioni di pull/push ed ispezione:

wslc pull --all-tags myregistry/myimage
wslc image list --all --digests
wslc image inspect --size myregistry/myimageArchitettura: cosa succede sotto il cofanoDal punto di vista architetturale, Microsoft ha separato le responsabilità in due processi distinti:

wslservice.exe crea la macchina virtuale WSL ma non ne mantiene la proprietà operativa dei container;

wslcsession.exe, eseguito a livello utente, gestisce effettivamente i container, il mounting dei volumi e il binding delle porte.

Questa separazione mantiene isolate le operazioni privilegiate dal resto, un dettaglio che conta per chi deve valutare la postura di sicurezza dell’ambiente. Ogni sessione utente ha il proprio disco virtuale dedicato, salvato in %AppData%\Local\wslc\sessions, che contiene immagini, container, reti e volumi di quella sessione. I path Windows vengono montati tramite virtiofs, mentre i filesystem nativi Linux usano volumi basati su VHD per prestazioni migliori.

Supporto GPU e integrazione .NETPer chi sviluppa su Windows con carichi di lavoro che richiedono accelerazione hardware (training di modelli, inferenza locale, elaborazione video), l’accesso alla GPU è esposto tramite il nuovo pacchetto NuGet Microsoft.WSL.Containers, che oltre alla GPU espone anche stdin/stdout, mount di file e configurazione di rete direttamente da codice C#. È un’ottima notizia per i team .NET che vogliono orchestrare container Linux senza uscire dal proprio stack di sviluppo abituale, magari dentro una pipeline di test o un tool interno scritto in C#.

Da notare che il supporto per la projection C++/WinRT è ancora in anteprima e soggetto a breaking change, mentre l’API per sviluppatori C# risulta più stabile e pronta per un uso quotidiano.

Controlli enterprise: Intune e Defender for EndpointPer i reparti IT che devono governare l’adozione di questa tecnologia in azienda, Microsoft ha introdotto due leve di controllo tramite Intune:

Allow WSL containers access: un interruttore on/off per abilitare o disabilitare completamente la funzionalità sui dispositivi gestiti;

WSL containers registry allow list: permette di restringere il pull delle immagini solo ai registry approvati, un controllo fondamentale per evitare che gli utenti scarichino immagini da fonti non verificate.

Sul fronte della sicurezza runtime, il plugin WSL di Microsoft Defender for Endpoint è stato esteso per coprire anche i container, mostrando attività di processo, file e rete collegate all’host Windows. È importante sottolineare che si tratta di visibilità e capacità di indagine, non di un meccanismo di enforcement in tempo reale: Defender segnala e documenta, ma la prevenzione attiva resta affidata alle policy Intune.

I limiti da conoscere prima di migrarePrima di sostituire Docker Desktop in produzione, vale la pena considerare alcuni limiti ancora presenti alla GA:

Nessun supporto Compose: è la funzionalità più richiesta dalla community e il lavoro è iniziato, ma Microsoft non ha ancora comunicato una data di rilascio. Chi ha workflow multi-servizio basati su docker compose up dovrà continuare a usare strumenti alternativi o avviare manualmente i singoli container;

Compatibilità “quasi” totale: test di terze parti riportano buona compatibilità con i comandi Docker esistenti, ma non totale — vale la pena testare gli script di automazione esistenti prima di un rollout su larga scala;

API C++/WinRT instabile: chi sviluppa tooling nativo in C++ dovrà aspettarsi possibili breaking change nelle prossime release.

Conclusione: chi dovrebbe provarlo subitoPer sviluppatori singoli e piccoli team che non dipendono da Docker Compose, i container WSL rappresentano già oggi un’alternativa solida, gratuita e integrata nativamente in Windows, con un vantaggio prestazionale concreto sull’I/O dei file. Per i team che si affidano a Compose nei workflow quotidiani, conviene affiancare wslc agli strumenti attuali e monitorare l’evoluzione del supporto. Per i reparti IT enterprise, il consiglio è di testare i controlli di governance (Intune e Defender) in un gruppo pilota prima di abilitare la funzionalità su larga scala, verificando in particolare il comportamento con le VPN aziendali e i registry Docker privati già in uso.

Fonte: 4sysops.com e WindowsForum

#opensource #poorman #linux

volete un "secondo" monitor?
avete dei vecchi device android?

https://github.com/blackout314/TethrLink

forkato - sistemato - esteso

il repo originale

https://github.com/princesavsaviya/TethrLink

ha gia presenti le 2 mie PR che:

• fixano android <10
• aggiungono pills x cambiare risoluzione lato client

necessita

• android 5+ (non ho potuto testare su 5)
• wayland + gnome

Kagi abbandona il browser Orion per Linux e Windows e ne pubblicherà il codice.

Il piccolo team del browser basato su WebKit lavorerà solo alle versioni per macOS e iOS. Le altre due passano alla comunità: @kagihq@mastodon.social ha contattato alcune fondazioni e promette i dettagli entro un mese.

La beta per Linux continua a funzionare, ma non riceverà più aggiornamenti e Kagi stessa sconsiglia di usarla come browser principale.

https://blog.kagi.com/update-orion-linux-windows

#Orion #Browser #Linux

I usually don't really find anything I do something I should be proud of because I'm a dumb little lizard but the amount of progress I've managed to do to Union QStyle in a month (well, three weeks, because Akademy) is very pleasing to me.

In both images:

On left, Union QStyle about month ago.

On right: Union QStyle now.

There are still minor issues but those will get polished. Some of them are just wrong CSS that are way easier to fix now than writing a whole C++ theme.

I wrote a QStyle theme from scratch pretty much (with a lot of help from others in the community) and well. It's been a ride. Not over yet, there's still edge cases to hunt, but for 6.8 release for people to tinker and play with, it should be pretty good.

I hope you all will like tinkering with Union and making crazy themes. I'm looking forward to seeing all of that.

I think I'll allow myself to be a bit proud.

#KDE #Union #Linux #KDEPlasma

MPZ Player: il ritorno della musica locale (senza fronzoli e senza database infiniti)
#OpenSource, #Linux, #MusicPlayer, #SoftwareLibero, #Music @computer@diggita.com @opensource@diggita.com

https://webappsmagazine.blogspot.com/2026/10/mpz-player-il-ritorno-della-musica.html

Time for the Sepender edition of our regularly scheduled Pook-Emu Bee Links.

Subway Stories1 | These salvaged relics in a Brooklyn subway station are the ghostly remains of old New York buildings (Ephemeral New York. Sep. 28, 2026.)

I wouldn’t call this being restored to their former glory, but it’s something.

2 | MTA axes G train shutdowns planned for December after outcry from small businesses (Kirstyn Brendlen for Brooklyn Paper. Sep. 28, 2026.)

Fun fact for non-New Yorkers: The G train is the only non-shuttle line that runs directly between Brooklyn and Queens without going through Manhattan in between. It is also an oft-troubled line in the repair space.

Tech Replacements3 | Fedora Discussion Raises The Idea Of Replacing LibreOffice With Collabora Office (Michael Larabel for Phoronix. Sep. 24, 2026.)

That is a stupid idea. Fedora should not do that. LibreOffice is a good default office suite (if one wants to ship a default office suite).

4 | US sanctions force The Netherlands off Microsoft and toward alternative NixOS-based software ecosystem — trial programs running now, first release expected at end of 2027 (Oliver Hansen for Tom’s Hardware. Sep. 28, 2026.)

U.S. sanctions of the ICC did not “force” the government of the Netherlands to do anything, as the first paragraph of the article itself notes. But since I use Linux instead of Windows myself, it will be interesting to see to what extent governments can make the switch work.

Military Conflicts5 | Iran publishes propaganda letter urging US voters to punish Trump in midterm elections (Ronny Reyes for the New York Post. Sep. 29, 2026.)

I could state the obvious that I am not taking voting advice from the Islamic Revolutionary Guard. But let us go with a less obvious angle. 26 pages? Does the IRGC really expect me to read 26 pages? Moreover, are they aware that 1 USD is now worth more than 2.5 million Iranian Rial? If for no other reason than preserving tokens I would recommend they keep future communications to me to a strict 500 word limit. Thank you.

6 | Captured Hamas Spy Chief Helps Israel Take Out Three Senior Terror Commanders (Vijeta Uniyal for Legal Insurrection. Sep. 29, 2026.)

Hamas is finally showing the kind of cooperation that can lead to peace in the Middle East. Inspiring.

7 | Ukraine’s former defense minister launches ‘Manhattan Project’ for killer robots (Katie Livingstone for Defense News. Sep. 30, 2026.)

The problem with Giant Death Robots is that by the time you reach the end of the tech tree, you probably already made it to Alpha Centauri or won a domination victory, no? I don’t see how he is addressing that. Shallow. (Link for readers who never played Civilization.)

Video Games8 | Danganronpa 2×2 hands-on impressions: Witnessing the exact moment Slayhem Mode takes the familiar killing game off the rails (Dorde P for Automation West. Sep. 30, 2026.)

I was mildly curious how they were going to re-do the Danganronpa 2 scenario. This sounds plausible. I may talk myself into this one but TBD. (They had better not kill Chiaki off early, however.)

9 | After Years Of Hard Work, One Of The Most Ambitious Super Mario Kart SNES Hacks Of All Time Finally Has A Release Date (Jack Yarwood for Time Extension. Sep. 30, 2026.)

Interesting. I’m curious what the new courses are.

Salve Feelers!
Pronti per la prima LIVE della Stagione???
A farmi compagnia Sabato 3 Ottobre alle 18.00 ci sarà @akesiseli@poliversity.it , sviluppatore di Raccoon e grande professionista del Settore, che ci parlerà di FOSS e tanto altro!

#SaveTheDate ci vediamo sabato, Live alle 18 sul mio Canale YouTube!

@gnulinuxitalia@feddit.it
#linux #foss #gnu #gnulinux

La vicenda di autistici/inventati mi ha fatto scattare una molla toccando i miei valori.
Ho preso alla lettera il loro invito di aprire 10 100 1000 server mail ,web, blog ...
In questi giorni ho reso pubblico un mio progetto https://mochela.it

Per ora è un cluster di server mail .. In futuro vorrei impacchettare il tutto e renderlo disponibile x configurare nuovi server in modo molto piu semplice con Ansible.

#keepinternetfree #AutisticiInventati #linux #stalwart #foss #lealternative

Canonical ha annunciato un cambio radicale nel ciclo di rilascio del #kernel #Ubuntu: dalle attuali cadenze separate — quattro settimane per gli aggiornamenti “regolari” e due settimane per quelli di sicurezza — si passa a un ciclo unico di Stable #Release Update (SRU) di due settimane, sovrapposto, che si traduce in un nuovo build del kernel disponibile ogni singola settimana. La motivazione, spiegata direttamente da Canonical, non è la solita ricerca di agilità #DevOps: è la necessità di reggere il ritmo di un flusso di #CVE che sta crescendo in modo esponenziale a causa della scoperta di bug assistita dall’intelligenza artificiale.

Per chi amministra flotte Ubuntu in produzione — LTS in primis, ma anche release interim — questo è un cambiamento che tocca direttamente il processo di #patch management, i cicli di test di regressione interni e la pianificazione delle finestre di manutenzione. Vale la pena capire cosa cambia concretamente e perché.

Il problema: l’IA ha trasformato la caccia ai bug in una linea di produzioneNel blog ufficiale, Canonical descrive con chiarezza la causa del cambiamento: “large language models (LLM) e agenti IA specializzati hanno trasformato la scoperta di bug da un processo manuale e dispendioso in termini di tempo a un motore altamente automatizzato”. In pratica, strumenti basati su modelli linguistici vengono oggi usati su larga scala per analizzare il codice sorgente del kernel #Linux alla ricerca di pattern potenzialmente vulnerabili, con una velocità e una copertura che nessun team di revisione umano potrebbe eguagliare.

Questo si somma a un cambiamento organizzativo avvenuto a monte: la community del kernel Linux è diventata una CVE Numbering Authority (CNA), il che significa che assegna direttamente identificatori CVE a migliaia di bug che in precedenza non venivano nemmeno tracciati come vulnerabilità formali. Il criterio adottato a monte è volutamente ampio: quasi ogni tipo di bug che può influenzare un sistema in esecuzione viene potenzialmente classificato come vulnerabilità di sicurezza, anche quando l’impatto pratico di sfruttabilità è minimo o nullo.

Il risultato combinato di questi due fattori — scoperta automatizzata su scala industriale e classificazione CVE estremamente inclusiva — è un flusso di identificatori CVE relativi al kernel che è semplicemente esploso rispetto a quanto i cicli di rilascio tradizionali erano progettati per gestire.

Come cambia il ciclo di rilascioIl vecchio modello prevedeva due binari separati e asincroni: un ciclo “feature” di quattro settimane per gli aggiornamenti generali del kernel e un ciclo di sicurezza dedicato di due settimane per le patch critiche. Questa separazione creava inevitabilmente colli di bottiglia quando il volume di CVE da processare superava la capacità del ciclo breve.

Il nuovo modello unifica tutto in cicli SRU di due settimane, ma sovrapposti: un nuovo ciclo inizia ogni settimana, invece che ogni due. La struttura interna di ciascun ciclo si articola così:

Settimana 1 — Preparazione: build del kernel e smoke test per verificarne la funzionalità di base. Entro la fine della settimana, i pacchetti vengono pubblicati nel pocket -proposed del repository Ubuntu.

Settimana 2 — Certificazione: test estesi sull’hardware certificato Ubuntu, verifica dell’integrazione con il resto della distribuzione e test di regressione approfonditi. Al termine, il kernel passa dai repository -proposed ai repository stabili.

Poiché i cicli si sovrappongono con partenza scaglionata di una settimana, il risultato netto per l’utente finale è la disponibilità di un nuovo kernel stabile ogni settimana, anziché ogni due o quattro come in precedenza.

Due velocità per due esigenze diverseUn aspetto interessante per chi gestisce infrastrutture di produzione è che il nuovo schema offre implicitamente due percorsi:

Il percorso “veloce”: seguire il pocket -proposed, disponibile già dalla fine della prima settimana del ciclo. Questo dà accesso alle correzioni con una settimana di anticipo, ma sposta sull’organizzazione l’onere del test di certificazione che normalmente svolge Canonical — un compromesso ragionevole per ambienti con forte esposizione a exploit noti e capacità interna di validazione rapida.

Il percorso “standard”: attendere il completamento del ciclo di due settimane e ricevere kernel pienamente testati e certificati sull’hardware supportato da Canonical, la scelta più sensata per la maggior parte degli ambienti di produzione che non hanno un processo di staging in grado di assorbire release settimanali non completamente validate.

Cosa succede mentre si aspetta la patch: workaround entro 24-48 oreUn elemento pratico rilevante per chi fa incident response e vulnerability management: Canonical si impegna a fornire workaround o raccomandazioni di hardening entro 24-48 ore dalla divulgazione pubblica di una vulnerabilità, anche quando la patch definitiva richiede più tempo per completare il ciclo di certificazione. Questo riduce la finestra di esposizione reale, permettendo ai team di sicurezza di portare i sistemi in uno stato “difendibile” (mitigazione temporanea, disabilitazione di moduli non essenziali, regole di firewall aggiuntive) senza dover attendere il rilascio completo del kernel patchato.

È un approccio che ricalca, concettualmente, quanto già fanno da tempo fornitori come Red Hat con gli advisory di mitigazione temporanea, ma applicato qui specificamente al contesto del kernel Ubuntu e giustificato esplicitamente dal volume di CVE indotto dall’IA.

Implicazioni pratiche per i team di sistemisticaPer chi gestisce Ubuntu Server, container base image derivate da Ubuntu o flotte cloud su Azure/AWS/GCP basate su Ubuntu LTS, questo cambiamento ha alcune conseguenze operative concrete da pianificare:

Finestre di manutenzione più frequenti: se finora la pianificazione delle patch del kernel seguiva un ritmo mensile o bisettimanale, ora bisogna prevedere un flusso settimanale, anche se non ogni release richiederà necessariamente un riavvio immediato in produzione.

Revisione della strategia di live patching: chi utilizza Ubuntu Pro con Livepatch per applicare patch del kernel senza riavvio dovrebbe verificare come la nuova cadenza si integra con il servizio, dato che un flusso più fitto di CVE potenzialmente livepatchabili può cambiare la frequenza con cui Livepatch interviene.

Triage dei CVE più selettivo: con un CNA a monte che classifica come vulnerabilità anche bug dall’impatto pratico marginale, diventa ancora più importante per i team di sicurezza avere un processo di triage basato su sfruttabilità reale ed exposure, invece di rincorrere ogni singolo identificativo CVE con la stessa priorità.

Automazione del patch testing: con release settimanali, i team che ancora validano manualmente ogni kernel prima del rollout in produzione dovrebbero considerare l’automazione dei test di regressione per non trasformare la nuova cadenza in un collo di bottiglia interno.

ConclusioneIl passaggio di Ubuntu a un ciclo di rilascio del kernel settimanale è un segnale che va oltre la singola distribuzione: è una risposta diretta a come l’IA sta cambiando la superficie di vulnerabilità nota del software open source, generando un volume di scoperte che i processi tradizionali di patch management, pensati per un ritmo pre-IA, faticano a sostenere. Per i team di sistemistica, il messaggio pratico è chiaro: automatizzare dove possibile il testing dei kernel, affinare i criteri di triage dei CVE in base al rischio reale e verificare fin da ora come la nuova cadenza settimanale si inserisce nei propri processi di change management, prima che diventi lo standard anche per altre distribuzioni enterprise.

Fonte: Canonical Blog e 4sysops

PaintFE: editor di immagini open source ultra-veloce che sfida Photoshop
#OpenSource #SoftwareLibero #GraphicDesign #Rust #Tech #Fotoritocco #Privacy #Linux #AlternativeSoftware @computer@diggita.com @opensource@diggita.com

https://webappsmagazine.blogspot.com/2026/09/paintfe-editor-di-immagini-open-source.html

EShot: uno strumento all-in-one per screenshot e produttività su Linux e Windows
#Screenshot #Produttività #Linux #Windows #opensource #Tool #Tech
@computer@diggita.com @opensource@diggita.com

https://webappsmagazine.blogspot.com/2026/09/eshot-uno-strumento-all-in-one-per.html