Ventoy permette oltre all'avvio delle classiche immagini ISO, IMG anche l'utilizzo di immagini denominate vtoy. Tali immagini sono costituite da un file vDisk di dimensioni fisse del tipo .vhd, .vdi o `.raw``.

Questa procedura crea, utilizzando Proxmox VE, una installazione Linux basata su vtoy, potete anche consultare la documentazione originale dove viene spiegato lo stesso procedimento utilizzando virtualbox.

Creazione di un vDisk vtoy​

Per prima cosa ci creiamo una cartella denominata vtoys per i nostri dischi in creazione. Ho scelto il persorso /zfs/vtoys, ma naturalmente dipende dalla vostra configurazione.

sudo mkdir /zfs/vtoys

Quindi mi vado a creare il nostro vDisk, in formato vhd:

sudo dd if=/dev/zero of=/zfs/vtoys/passero.vtoy bs=1G count=16

Apro Proxmox VE e creo una VM, ad esempio 102, la salvo. A questo punto, utilizzando l'interfaccia grafica di proxmox, rimuovo il disco fisso presente.

Successivamente edito il file di configurazione della macchina virtuale /etc/pve/qemu-server/102.conf ed aggiungo il nostro vdisk: scsi0: /zfs/vtoys/passero.vtoy, il risultato finale sarà simile a questo:

boot: order=scsi0;ide2;net0
cores: 1
cpu: x86-64-v2-AES
hotplug: disk,network,usb
ide2: none,media=cdrom
memory: 2048
meta: creation-qemu=8.0.2,ctime=1697609683
name: passero
net0: virtio=66:5D:89:D8:D3:1C,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: /zfs/vtoys/passero.vtoy
scsihw: virtio-scsi-single
smbios1: uuid=54c19e93-6059-47d1-b86b-1c4f35b32de1
sockets: 1
vga: qxl
vmgenid: 14db629c-0ab4-42e1-9454-b410f44fd73f

Nota che l'unica modifica fatta all'originale è la riga:

scsi0: /zfs/vtoys/passero.vtoy

Salvo il file e, nuovamente dall'interfaccia grafica di Proxmox, seleziono Option ed imposto l'avvio della VM dal nostro vDisk: scsi0: /zfs/vtoy/passero.vtoy.

Rendiamo la nostra VM compatibile con Ventoy​

Scarichiamo la ISO da https://github.com/ventoy/vtoyboot/releases e montiamola, quindi:

tar -xf /media/artisan/Vtoyboot/vtoyboot-1.0.30.tar.gz
cd vtoyboot-1.0.30
sudo ./vtoyboot.sh

vtoyboot modificherà l'initrd.img della nostra installazione, rendendo l'installazione compatibile con ventoy.

Copio il vDisk su una chiavetta Ventoy​

A questo punto possiamo copiare il nostro 'passero' su una unità esterna ed avviarlo tramite Ventoy.

Il vantaggio, rispetto ad una normale ISO live, è che abbiamo un sistema scrivibile sul quale potremo salvare le nostre sessioni di lavoro.

Creazione di una chiavetta/disco con Ventoy​

Personalmente utilizzo un piccolo disco ssd che, rispetto alle normali chiavette, mi consente una maggiore velocità e durata.

Le istruzioni per crearsi una chiavetta o un disco con Ventoy sono riportate il questo link.

Una volta creato e testato eggs per l'architettura ARM64, abbiamo il problema di provarlo su hardware reale.

Non essendo un esperto del caso, ho chiesto assistenza a chi conosce meglio, specificatamente al buon Jon West di BlissOS ed al "solito" Stefano Capitali di Manjaro, che mi ha poi re-indirizzato a Furkan che si occupa delle versioni ARM per Manjaro stesso.

Jon mi ha avvisato che, per quanto di sua conoscenza, i dispositivi ARM64 utilizzano soprattutto uboot come bootloader al posto di GRUB, Furkan mi ha allargato un po' di più la prospettiva spiegandomi che esistono diverse versioni di Manjaro ognuna per degli specifici dispositivi e che, non tutti i dispositivi ARM sono compatibili UEFI, ma alcuni si: dai grandi sistemi come Ampere, a sistemi anche molto piccoli il rockpro64 di pine64, o il rock64 di radxa, entrambi con il rockchip rk3399.

Ho continuato quindi a documentarmi e mi sono imbattuto in Raspberry Pi 4 UEFI Firmware Images, che - nello specifico - fa proprio il caso nostro in quanto consente di avviare RPI4 con UEFI e, sembra da USB come specificato nell'articolo ESXi on ARM - Installing ESXi on a Raspberry Pi in bibliografia.

Disponendo quindi di un abbastanza datato RPI4 - forse con 8 GB di RAM - mi sto accingendo a prepararmi al grande salto.

Installazione​

Scarica l'ultimo archivio dalla repository Releases.

Crea un SD card o un disco USB, con almeno una partizione formattata come FAT16 o FAT32

Nota: Avviando da USB o da ESP richiede un versione di PI EEPROM recente (così come una versione del firmware UEFI). Se state utilizzando l'ultima versione del firmware UEFI e trovate che il boot da USB o da ESP non si avvia, visitate https://github.com/raspberrypi/rpi-eeprom/releases per aggiornare la vostra EEPROM.

Estraete tutti i file dell'archivio nella partizione che avete creato precedentemente.

Notate che - a parte questo README.md, che potete rimuovere liberamente - non dovete cambiare assolutamente i nomi dei file e delle directory estratte.

Utilizzo​

Inserita la card SD accesa la vostra Raspberry Pi, dovreste vedere uno schermo multicolore (che indica che il bootloaded embedded sta leggendo i dati dalla partizione SB/USB) quindi, appare il logo Raspberry in bianco e nero una volta che il firmware UEFI è prondo.

A questo punto, potete premere il tasto ESC per entrare nel setup, F1 per lanciare la shell UEFI e - se fornito - avere un bootloader UEFI in `efi/bootaa64.efi`` che potete avviare (sarà il vostro default se non verrà intrapresa alcuna azione)

Metodo​

Ho scritto questa parte ancora prima di provarla. L'ho fatto presso il negozio DNetware computer di Tor Sapienza a Roma, su un missile i9 per gamer in preparazione ed una chiavetta USB con adattatore per SD card.

Create an msdos partition table​

• sudo parted --script /dev/sdb mklabel msdos

Create, format, and label a 10M fat32 partition​

• sudo parted --script /dev/sdb mkpart primary fat32 0% 10M
• sudo mkfs.vfat /dev/sdb1
• sudo fatlabel /dev/sdb1 RPI-FW

Get the UEFI firmware onto the SD card​

• sudo mount /dev/sdb1 /mnt/
• Download from RPi4 UEFI Firmware
• sudo unzip Downloads/RPi4_UEFI_Firmware_v1.35.zip -d /mnt/
• sudo umount /mnt/

A questo punto la card SD può essere usata per avviare la RPi e vi troverete nel firmware UEFI.

Non resta che creare la chiavetta con la normale procedura descritta nella guida.

Funziona!​

Oggi, con l'aiuto dell'amico Walter di DNetware computer, finalmente ho avuto il "coraggio" di aprire il minicase del mio Raspberry ed effettuare la prova.

Abbiamo semplicemente formattato tutta la SD card con fat32 direttamente da uno dei computer Windows in costruzione, quindi - effettuato il download del firmware - il contenuto è stato decompresso nell'unica partizione creata: una SD è da 16GB. In effetti sarebbero bastati pochi Kb per il firmware.

A questo punto ho avviato il Raspberry che, correttamente, ha riconosciuto la chiavetta USB sulla quale avevo posto la ISO del sistema operativo e, con soddisfazione il piccolo s'è avviato.

Dopo un tentativo, non riuscito di installazione, ho effettuato nuovamente una ulteriore prova, Questa volta, però, il boot è stato effettuato da un disco SSD da 128 GB, sempre formattato con fat32, sul quale avevo installato ventoy. Anche in questo caso il disco è stato riconosciuto correttamente, ventoy ha creato la lista delle ISO disponibili e, selezionata egg-of-debian-bookworm-arm64 il sistema si è avviato correttamente.

La soddisfazione è enorme: eggs riesce a rimasterizzare buona parte delle distribuzioni Linux e su tre architetture di processore diverse: amd64, i386 ed adesso anche arm64.

L'utilità - al momento - è ancora poca, e manca infine l'installazione su Raspberry ed ARM in genere, ma ormai è questione di tempo e di test.

Ringrazio molto l'amico Walter, ed attendo notizie su eventuali repliche, vero Franco Conidi?

E' nato, è nato!

E così dopo una ulteriore avventura con Franco, lottando contro i Titani, con problemi di saturazione della memoria per lui, ed incapacità di capire come abilitare il boot sul sistema installato per me, il giorno 13 ottobre 2023, il primo uovo da Raspberry 4 si è schiuso: nato, è nato!

Downloads

Al momento sto creando immagini Debian bookworm ARM64, quindi, le trovate sulla pagina di penguins-eggs di sourceforge sotto Debian.

Per avviarle, naturalmente è necessario predisporre il Raspberry per il boot UEFI come indicato in precedenza.

Buon divertimento!

Bibliografia​

• Raspberry Pi 4 UEFI Firmware Images
• Raspberry Pi 4 UEFI Boot
• UEFI Secure Boot on the Raspberry Pi
• Pimox 7 Proxmox VE V7 for Raspberry Pi
• instalando-vmware-esxi-en-una-raspberry-pi

Ricordati di santificare le feste.

A Zagarolo in provincia di Roma la festa è una - oltre al patrono San Lorenzo - ed è la prima domenica di ottobre: la Sagra dell'uva!

Che c'entra questo in un articolo dove andremo a trattare come adattare la versione attuale di penguins-eggs a LMDE 6 i386?

Certo, potrebbe sembrare un mistero.

In realtà però è piuttosto semplice: sono originario di Zagarolo e le "radighe", radici per chi non è del paese, non si dimenticano mai.

Dalle prime versioni di penguins-eggs, utilizzo nodesource come repository per nodejs. Da molti anni però nodesource non rilascia più la versione i386. Per molto tempo, facendo i salti mortali, sono rimasto legato all'ultima versione disponibile per i386 - la versione node8 - poi ho abbandonato, passando direttamente a node16.

Con l'uscita di Linuxmint LMDE 6, mi è stato chiesto se era possibile rimasterizzare anche la versione i386 e così mi sono trovato a rimetterci le mani.

penguins-eggs v8.17.17

Pur disponendo di tutti i sorgenti della versione 8.17.17 la stessa NON può essere transpilata senza "pesanti" interventi.

Ho optato, quindi - per fare una prova - ad utilizzarla lo stesso ma andando a modificare direttamente i file transpilati ed installati.

Tutto sommato è riuscito abbastanza semplice. Dopo aver installato penguins-eggs v.8.17.17 sono andato a modificare dei file che si trovano in /usr/lib/penguins-eggs/lib/classes e cioè, /usr/lib/penguins-eggs/lib/classes/distros.js sostituito debbie con faye, e nella riga successiva ho sostituito buster con bookworm

In verità vi era pure qualche altra cosa, su ovary.ts credo, ma ho prodotto la ISO - sabato - ed ha comuque funzionato.

Semplificare l'esistenza​

Naturalmente allineare la versione i386 a quella amd64 sarebbe stato l'ideale per avere una sola versione e così - stamattina - ho ricominciato a provare.

Io utilizzo per creare il pacchetto deb, oclif che fa un po' tutto da solo ed è stato splendido, specialmente agli inizi.

Aprendo /usr/lib/penguins-eggs/bin ho visto che oclif pone l'eseguibile di node in questa posizione. Tale eseguibile è utilizzato per lanciare il pacchetto in luogo del canonico /usr/bin/node.

Ho provato allora a rifare il pacchetto eggs-v9.5.26 per i386, rimuovendo in DEBIAN/control i riferimenti ad amd64 e sostituendoli con i386, quindi aggiungendo nodejs alle dipendenze, per vedere cosa succede.

Niente, non succede niente.

Però, sostituendo all'eseguibile di node in /usr/lib/penguins-eggs/bin/node un link a /usr/bin/node installato con apt, il tutto torna a funzionare!

L'unica accortezza è appunto eseguire questa operazione dopo l'installazione.

Naturalmente, nei prossimi giorni, proverò ad automatizzare anche questo, includendo la creazione del link direttamente nello script di post-installazione.

Ma, per oggi direi che basta così e buona Sagra dell'uva a tutti!

How to get a colibri​

We are going to describe how to go from a minimal standard installation to a complete remasterable system using addaura scripts.

This procedure work on Arch rolling, Debian (buster, bullseye, bookworm), Devuan (chimaera and daedalus) and Ubuntu (bionic, focal and jammy).

Arch​

I started with latest version of archiso: archlinux-2023.09.01-x86_64.iso.

Then, used archinstall to get a minimal installation. On Disk configuration choose Use a best-effort default configuration layout, then btrfs or ext4, as you prefer.

Among the packages I added: git, lsb-release, others packages will be installed later by addaura.

At this point, we MUST configure network, I just choose the most basic: Copy ISO configuration to installation.

Finally select install and wait it finish. Archinstall will propose you to chroot to continue configuration, answer no and reboot.

Debian/Devuan/Ubuntu​

On Debian and Devuan we start with a common netinst, without install nothing except standard system utilies

When the installation finish, reboot the system.

After reboot, we now must install git and sudo. Log on your installed system, and:

• su
• apt install git sudo
• /usr/sbin/adduser artisan sudo

We can now logout, and we are ready to the next step.

The procedure its about the same on Devuan.

On Ubuntu, we install with the server edition, again without install nothing except the minimal base. Here, at the end of installation I use to remove package cloud-init we are not interested on.

After reboot, we need just to install git to be ready: sudo apt install git.

Get and run addaura (all)​

• git clone https://github.com/pieroproietti/addaura
• cd addaura
• sudo ./addaura.sh

That will happen​

eggs will be installed and configured properly for the chosen distribution.

Arch​

addaura.sh will install few packages bash-completion, dialog, man-db, nano, openssh and wget and will add AUR repository to pacman.conf.

Then will install penguins-eggs.

Debian/Devuan and Ubuntu​

addaura.sh will install new ppa for penguins-eggs, then will install eggs and its dependencies.

Get wardrobe and wear a costume (all)​

Once eggs was installed, I proceeded to load the wardrobe and "dress" the system with the colibri costume.

• eggs wardrobe get
• sudo eggs wardrobe wear colibri At this point after rebooting, I found myself in the colibri graphical system.

Installing calamares​

We can install calamares with the command: sudo eggs calamares --install.

Clean​

After that, we can clean cached packages with command: sudo eggs tools clean.

Remastering our custom system​

Well, we are ready to remaster the system, just a little reconfiguration and cleaning before:

• sudo eggs dad -d
• sudo eggs tools clean
• sudo eggs produce --max --addons adapt

That's all folks!

Videos

These videos were made simply using kazam on a window, live, no audio or editing, I would need help preparing something more professional.

• From archiso to colibri (Arch Linux)
• From netinstall to colibri (Debian)

Stamattina, dopo aver rilasciato penguins-eggs-v9.5.26-1 mi sono accorto di un grave errore: Arch rimasterizzato non riesce ad avviarsi!

Fino a ieri, tutto OK.

Rimasterizzando blendOS LXQT che utilizza gli stessi script per mkinitcpio: tutto bene.

Rimasterizzando Garuda plasma lite, aggiornato allo stesso giorno tutto OK.

Cercare di capire che cosa sta succedendo non sembrava alla mia portata.

Dopo un giorno di scervellamenti, mi sono reso conto che, avendo portato il codice per la compatibilità con archiso dalla classe distro.ts al file archiso.yaml in /etc/penguins-eggs/archiso.yaml, non avevo però inserito Arch come compatibile con se stesso!

Il risultato era che le derivate mi funzionavano, Arch no.

Stamattina di buzzo buono, mi sono messo quindi a rilasciare le nuove versioni di Arch: naked, colibri e plasma che sto includendo nel wardrobe con il nome albatros. Se seguite il link, lo trovate sotto costumes.

La "ricompensa" - probabilmente casuale - è che mi sono accorto pocanzi che le stelle di gradimento hanno fatto un botto, passando da 280 a 297 in un solo giorno.

Speriamo continui!

Se qualche grafico è in linea e vuole collaborare, cerco uno sfondo con un albatros che vola su uno sfondo abbastanza scuro - problemi di vista.

Le nuove versioni le trovate qua.

Buona domenica a tutti.

Tra i vari follower del gruppo Telegram, ve ne è uno particolare, un ragazzo canadese che ormai mi accompagna da qualche anno.

Lo conobbi quattro o cinque anni fa, ricordo una notte in cui mi svegliò verso l'una di notte - ora italiana - perchè lui stava provando a fare le uova con la sua mega distribuzione.

La faccenda - fortunatamente si concluse con successo ed ebbi l'occasione di provare la distro creata che conteneva tutto il possibile di KDE e, probabilmente di più.

Pensai: questo o è un genio o un matto, o sia l'uno che l'altro.

Ad ogni modo ci aveva messo dei suo e la "distro" resistette qualche tempo sul mio portatile, prima che - sia pure con rimpianto per non averla capita appieno - fu rimpiazzata da altri esperimenti.

Personalmente vado a periodi: ho preferito KDE a tutte le altre sino all'uscita - assai attesa in verità - della versione 4, che però non ebbe lo stesso successo almeno presso di me.

Da allora mi innamorai di cinnamon, trovando tedioso gnome, brutti XFCE, LXDE, LXQT e varie.

Ad un certo punto, sempre grazie a Linuxmint capii che XFCE non era poi così brutto, ma toccava riconfigurarlo e presi a preferirlo per le macchine virtuali - soprattutto per la leggerezza - mentre sul mio desktop principale regna ancora cinnamon.

L'uscita di wayland ha complicato ancora le cose: se uno ne ha la necessità non ci resta che rivolgerci a gnome o KDE.

Tra i due, inutile nasconderlo preferisco KDE ed ho quindi pensato: ho fatto una marea di rimasterizzazioni solo per testare eggs, perchè non cercare di farne una componendo un sistema che, nella mia mente, potrà sostituire Windows sul computer dei miei nipoti?

Le difficoltà e le soluzioni

Ho cercato per facilitarmi il lavoro una traccia da seguire ed ho trovato questo ottimo howto arch-plasma-install che ho provveduto immediatamente a forkare.

L'ho seguito ed il risultato mi è sembrato subito buono, alla fine ho dato una pulita al sistema ed ho fatto la iso.

Maledizione, con gli ultimi aggiornamenti sono ricominciati i problemi con calamares!

Calamares per eggs

Fino a qualche tempo fa usavo calamares da aur ed andava benissimo, poi si è rotto ed ho dovuto trovare altro.

In qualche modo, misi insieme una versione di calamares per eggs, denominata per l'appunto calamares eggs, ma vatti a ricordare che cosa ho fatto.

L'unica cosa che mi sono segnato è il fatto di essere partito dalla repository Arco Linux di Erik Dubois.

Un po' poco: se non avessi fatto niente tanto valeva usarla così com'era!

Allora ho provato semplicemente a ricompilare arco-calamares-git per vedere che succede.

La versione Arco Linux va benissimo com'è, un peccato non sia in aur, ma posso vedere come automatizzarne il download per eggs.

Sembra, quindi, che non ho scritto altro semplicemente perchè altro non ho fatto!

Conclusioni (per ora)

Per quanto "arronzata", la iso è uscita fuori. Ci sarebbe da lavorarci attorno ed affinarla, ma va già bene così per "stomaci forti".

E d'altra parte, non è l'opera di uno scultore, piuttosto quella di un maniscalco, di un costruttore di scalpelli.

Si noti pure l'utilizzo di un tema - per così dire "rubato" - a KDE neon.

Se volete farvi un giro, trovate egg-of-arch-plasma_amd64_2023-09-19_1414.iso sulla pagina Arch.

So far eggs is only compatible with grub, but other bootloaders will need to be included, I noticed on archinstall the possibility of installing:

• systemd-boot
• grub
• efistub
• limine

systemd-boot, is an easy-to-configure UEFI boot manager. It provides a textual menu to select the boot entry and an editor for the kernel command line. It is included with systemd.

Eggs can be installed, it does not manage systemd-boot but the installations will be done with grub.

grub

GNU GRUB is a Multiboot boot loader. It was derived from GRUB, the GRand Unified Bootloader, which was originally designed and implemented by Erich Stefan Boleyn.

efistub

The Linux kernel supports EFISTUB booting which allows EFI firmware to load the kernel as an EFI executable.

Eggs can be installed, it does not manage efistub but the installations will be done with grub.

limine

Limine is an advanced, portable, multiprotocol bootloader that supports Linux, multiboot1 and 2, the native Limine boot protocol, and more.

Eggs can be installed, it does not manage limine but the installations will be done with grub.

Ho iniziato le denos' eggs come un esperimento per capire se cliffy potesse essere utilizzata per rifare eggs. L'esperimento sembrerebbe riuscito.

Praticamente ho reimplementatao in deno con cliffy l'intero sistema di menu di penguins'eggs, inclusi gli argomenti, i flag e l'help.

La procedura al momento non fa assolutamente nulla, ma sicuramente ho dimostrato che non c'è uno specifico problema oclif.

Non ho ancora ben chiaro quali potranno essere i prossimi passi: potrei partire dalla classe settings e replicare la configurazione di eggs.

Al momento mi sembra uno sforzo difficile, quindi ho provveduto a vedere se era possibile "limare" da qualche parte ed, in effetti, ho ridotto di qualche funzione non più utilizzata il codice di penguins'eggs stesso.

Ad ogni modo, potete seguire la repository di denos'eggs, farvi un fork e darmi una mano!

Credits: MasterJames

Quando ho cominciato eggs ho utilizzato javascript con nodejs per creare un programma CLI.

La ragione risiedeva nella difficoltà trovata ad effettuare manutenzione su script bash, dalla mancata conoscenza di python e dal fatto che javascript era molto diffuso e di moda.

Dopo i primi approcci, sono passato ad utilizzare oclif per tutta la struttura. oclif permette di gestire tutto insieme dal README.md ai vari comandi, il parse degli argomenti, etc.

Con oclif e con l'esplosione di typescript sono passato a quest'ultimo che trovo più semplice da gestire rispetto a javascript ed utile sia per rintracciare gli errori in fase di transplilazione che per un maggiore aiuto disponibile sull'editor.

Successivamente, sempre attraverso oclif sono riuscito a creare i primi pacchetti debian, quindi, in una enfasi di novità ho trovato il modo di utilizzare ink per ottenere una interfaccia TUI più pulita e basata su react.

Il programma cresceva e si dilungava il tempo di compilazione, così decisi di cominciare ad utilizzare pnpm al posto di npm. L'operazione non si mostrò affatto indolore, oclif non era compatibile con pnpm e decisi di fare un fork di oclif denominato oclif-phpm attualmente allineato alla versione di oclif v3.4.3.

Ho provato a chiedere l'inclusione del supporto per pnpm in oclif, sembra non ve ne sia l'opportunità e, naturalmente, oclif - un progetto importante - va avanti e rilascia continuamente nuove versioni, ed ho difficoltà con il mio fork a seguirle.

La stessa cosa sta pure succedendo con ink, eggs riesce a lavorare con la versione 3.x ma non con la nuova versione 4.x.

L'ideale sarebbe uno strumento come oclif, che consenta di gestire il tutto compatibile con ink o similari che consentano di utilizzare React in una CLI.

Al momento tutto questo non esiste.

Potrebbe essere anche una opportunità pensare di scrivere qualcosa del genere utilizzando deno o bun.

Consultando tra le issue di ink, sembra che vi sia una certa compatibilità tra ink e deno.

Mentre una alternativa ad oclif potrebbe essere cliffy.

Ma c'è tanto mare da attraversare!

Credits: MasterJames

Penguins' eggs ha sette anni, il tempo del mio ritiro dal lavoro attivo.

Questo mi ha consentito una maggiore disponibilità di tempo e di potermi dedicare a questo progetto. La passione, la testardaggine hanno fatto il resto.

Penguin's eggs si inserisce in un settore con molti illustri precedenti, dal primo remastersys, passando per refracta-snapshot, systemback, mx-snapshot ed altri.

Sono programmi che oltre ad un grande sforzo iniziale necessitano di un continuo aggiornamento, d'altra parte consentono lo "sfizio" di farsi - o illudersi di farsi - la propria versione del sistema operativo.

Mettiamola così, io penso che siano strumenti per una customizzazione verticale di Linux, al punto da farlo diventare un vestito sartoriale, passando dal pret a porter a prodotto di massa.

Ogni singolo individuo, ma più facilmente delle organizzazioni possono avere la propria versione: derivata certo! Ma chi era quello che parlava di nani che salivano sulle spalle di giganti per vedere meglio? Non è detto, quindi, che salire sulle spalle di giganti sia una cosa da poco.

Inoltre, ma non mi dilungo, forse è da rivedere il concetto di stesso distribuzione originale: alla fine è un quasi ossimoro.

Alla fin fine TUTTE le distribuzioni sono derivate - includono difatti il codice ed il lavoro dei vari pacchetti che appunto "distribuiscono", aggiungendo ed integrandolo come un sistema completo.

Lo sò, rischio di essere mandato al diavolo. D'altra parte alla non tenera età di sessantadue anni, qualche sassolino bisogna pure toglierselo.

Il sassolino, nel mio caso è l'idea che - non da solo - rimugino da anni è che l'evoluzione dei sistemi ripercorra un po' quella degli esseri viventi e non necessariamente solo quella dei sistemi operativi.

Chi è più o meno della mia età, ma anche più giovane ricorderà i tempi delle videocassette VHS, non certo le migliori, ma le più diffuse.

Diciamo che Darwin aveva ragione anche riguardo le videocassette. Lui avrebbe più "penna" per illustrarlo - anche se al posto di un comodo editor aveva solo una penna d'oca ed il calamaio.

Però se uno parte da queste affermazioni:

• Le specie sono dotate di una grande fertilità e producono numerosi discendenti che possono raggiungere lo stadio adulto.

• Le popolazioni rimangono grosso modo delle stesse dimensioni, con modeste fluttuazioni.

• Le risorse di cibo sono limitate, ma relativamente costanti per la maggior parte del tempo. Da queste prime tre osservazioni è possibile dedurre che verosimilmente in ogni ambiente ci sarà tra gli individui una lotta per la sopravvivenza.
• Con la riproduzione sessuale generalmente non vengono prodotti due individui identici. La variazione è abbondante.
• Gran parte di questa variazione è ereditabile.

Ci si rende conto che trovare o ricreare un sistema del genere è, paradossalmente piuttosto facile, ed anche piuttosto comune.

Come dicevo, sicuramente VHS non era il sistema migliore, ma anche intel 8080 avrebbe dovuto soccombere di fronte allo splendido Zilog Z80, etc.

Un sistema riproduttivo è importante

Se le cose stanno così, eggs ed ogni sistema di riproduzione - con varianza - è importante. Mentre grandi sistemi anche straordinariamente diffusi - ma senza varianza - sono destinati a soccombere.

E qua bisogna essere ciechi, se con un Linux o un Darwin che vi gira in tasca, un altro nel vostro router di famiglie, probabilmente anche in auto e chissà quanti che utilizzate in rete ma venite ancora a sbomballarci il cazzo che avete Windows o peggio sopportate Apple.

E' sbagliato proprio il concetto: la scelta del software chiuso e non modificabile è un suicidio.

Ci potranno essere dei gemelli omozigoti, un certo grado di parentela fra simili, ma senza riproduzione con varianza tutto è destinato alla fine. Windows ed Apple non sono altro che alberi di banane clonati: una volta mangiavamo le Gros Michel ora le Cavendish, in futuro magari ci adatteremo alle Goldfinger o ne troveremo migliori.

E qua ci vorrebbe una vera bibliografia, ma possiamo espanderla:

• Tutte le banane sono cloni: una storia di varietà, malattie ed estinzioni