Sabato 24 ottobre torna il Linux Day a Prato!

Linux Day 2026 a Prato: la tecnologia torna nelle mani delle persone

Sabato 24 ottobre, dalle ore 10, al Prisma Prato, torna il Linux Day: incontri, approfondimenti e confronto per scoprire un mondo digitale più libero, aperto e accessibile a tutti.

La giornata, gratuita e aperta a tutti, è pensata per appassionati di informatica, professionisti, studenti e curiosi che vogliono conoscere più da vicino Linux, il software libero e la cultura open source.

Il programma prevede due percorsi paralleli di incontri, con interventi dedicati a temi di grande attualità: dalla privacy alla cybersecurity, dalla sovranità digitale al self-hosting, dall’hardware aperto all’intelligenza artificiale. Non mancheranno dimostrazioni pratiche, esperienze di sviluppo e occasioni di confronto con chi ogni giorno contribuisce alla crescita delle tecnologie libere.

Il Linux Day non è soltanto un appuntamento per esperti e sviluppatori, ma anche un’opportunità per comprendere come le scelte tecnologiche influenzino la vita quotidiana, i diritti digitali e la nostra autonomia. Il software libero promuove infatti la possibilità di utilizzare, studiare, modificare e condividere i programmi, favorendo la collaborazione e la diffusione della conoscenza.

L’edizione pratese nasce dalla collaborazione tra i Linux User Group del territorio e le comunità che promuovono il software libero in Toscana, insieme ad associazioni, realtà locali e al Comune di Prato, con l’obiettivo di diffondere la cultura digitale e valorizzare la partecipazione dal basso.

Il programma completo, i dettagli sugli interventi e tutte le informazioni per partecipare sono disponibili sul sito ufficiale day.linux.prato.it

Linux Day 2026 – Aperta la Call for Papers

Sabato 24 ottobre torna il Linux Day, la principale conferenza comunitaria italiana dedicata al software libero, alla cultura aperta e alla condivisione. L’evento comprenderà una giornata gratuita di talk, laboratori e comunità attorno a Linux, al software libero e alla cultura open.

Come l’anno scorso, anche quest’anno il GOLEM organizzerà il Linux Day nella città di Prato, insieme a LuccaLUG, GULLi e ovviamente PLUG.

La call for papers è aperta fino al 15 settembre: il Linux Day è fatto dalle persone che lo raccontano. Hai un progetto, un’idea o un’esperienza da condividere? Manda la tua proposta.

You need to load the kernel first (parte 2)

Dopo anni di modalità BIOS Legacy ho effettuato il passaggio a UEFI per sfruttarne alcune delle sue caratteristiche.
Andrà quindi reinstallato grub in modalità EFI, ma per ~~mia paranoia~~ maggiore sicurezza ho aggiunto anche altre due alternative “salva” boot:

refind: un Bootloader che può caricare kernel o EFI stub presenti nella partizione EFI di boot. Rinominandolo come /EFI/BOOT/bootx64.efi il sistema lo caricherà di default quando non trova altre immagini disponibili

EFI stub realizzata con Buildroot contenente kernel + ramdisk con varie utility di rescue. In meno di 30MB si riesce ad avere un sistema con driver ethernet, wifi, busybox completo, RAID, BTRFS…

Occorre fare attenzione ad alcune cose: l’immagine Buildroot va creata in modo che l’initrd sia linkata nel kernel creando così un solo file all-inclusive.
# make menuconfig
Filesystem images —>
seleziona initial RAM filesystem linked into the kernel (cpio)

Nel kernel va abilitato il supporto all’EFI stub affinché l’immagine creata sia in formato .efi e dato che UEFI funziona via framebuffer anche questo va abilitato altrimenti lo schermo rimarrà fisso al logo del bootloader.
# make linux-menuconfig
Processor type and features —>
EFI runtime service support —>
EFI stub supportDevice Drivers —>
Graphics support —>
Frame buffer Devices —>
Support for frame buffer devices —>
EFI-based Framebuffer Support

You need to load the kernel first (parte 1)

Avete presente quella sensazione di sconforto che si prova quando, dopo un aggiornamento, il sistema si blocca su una misera shell di ripristino privandoci del nostro rassicurante login grafico? Incasinare l’avvio di Linux è un’eventualità piuttosto probabile: sovrascrittura del MBR, aggiornamenti di kernel e bootloader, apt-get dist-upgrade… In questi casi spesso non resta che dover recuperare un LiveCD, chrootarsi o addirittura reinstallare tutto.
Cosa si può fare per prevenirlo?

Svariati anni fa, ai tempi in cui “la mia vita fin lì, entrava tutta dentro uno Iomega ZIP”, nel tentativo compilare un nuovo kernel per una RedHat riuscii nell’impresa di cancellare tutti i file vmlinuz-* in /boot ad eccezione del mio. Risultato? Sistema bloccato perché mancavano i driver per montare il filesystem. Da allora tengo sempre almeno due kernel funzionanti e testati in /boot.

Per i successivi 22 anni ho dormito sogni tranquilli, tra snapshots di btrfs e kernel di scorta, finché dopo un aggiornamento di grub su Archlinux mi sono ritrovato con un sistema non avviabile. Tutto risolvibile con un LiveCD, arch-chroot e grub-install… ma è stato fastidioso e nel prossimo articolo vedremo qualche accorgimento per salvarci ~~le chiappe~~ il boot anche nei casi più disperati.