costumes and wardrobes

This is a costume, a simple way to code our customizations starting from a naked system to a minimun KDE installation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# recipe: kde
# author: artisan
---
name: kde
description: minimal KDE installation
author: artisan
release: 0.0.3
distroId: Debian
codenameId: booksworm
releaseId: sid
applyTo: naked
sequence:
repositories:
sourcesList:
main: true
contrib: true
nonFree: false
sourcesListD:
- curl -fsSL "https://pieroproietti.github.io/penguins-eggs-ppa/KEY.gpg" | gpg --dearmor -o /usr/share/keyrings/penguins-eggs-ppa.gpg
- echo "deb [signed-by=/usr/share/keyrings/penguins-eggs-ppa.gpg] https://pieroproietti.github.io/penguins-eggs-ppa ./ " | tee /etc/apt/sources.list.d/penguins-eggs-ppa.list > /dev/null
update: true
full-upgrade: true
packages:
- kde-plasma-desktop
- plasma-nm
- ark
- kate
- kcalc
- kde-spectacle
- firefox-esr
- okular
debs: false
dirs: false
hostname: true

customizations:
scripts:
- null

reboot: true
...

eggs come with a new command: wardrobe.

You can prepare your costumes to dress your penguins, costumes are simple and automatic configuration. A costume consists just on a dir named after the costume and an file index.yml, as you can note, we have large spaces for others future addictions: debs, icons, themes and so on.

Inside wardrobe.d you will find same simple examples: xfce4 and KDE costumes.

Logic of costumes #

penguin-sailor

Logic for costumes is enought simple, we have a directory named after the costume and an index.yml.

In index.yml, we have:

sequence #

Here we define the sequence of that we will do. Example:

1
2
3
4
5
6
7
8
#
# We start here, step by step
#
sequence:
repositories:
sourcesList:
main: true
(...)

repository #

Here we define that will do with repositories, usually four tasks, the first sourcesList it’s to check that component must be present in /etc/apt/sources.list: main, contrib, non-free. The second sourcesListD, commands to adds other repositories to ```/etc/source.list.d’’’. The third task is mandatory update, the forth can be optional full-upgrade. Example:

1
2
3
4
5
6
7
8
#
# steps for repositories
#
repositories:
- sourcesList
- sourcesListD
- update
- full-upgrade

In the upper example I excluded step sourceListD, becouse actually I have same problems with my pubblic key.

sourcesList #

Here we define, that components we need. Example:

1
2
3
4
5
6
7
#
# components to be added to /etc/apt/sources.list
#
sourcesList:
main: true
contrib: true
nonFree: false

sourcesListD #

Here we define commands to add other repositories to /etc/apt/sources.list.d
example:

1
2
3
4
5
6
#
# add entries on /etc/apt/sources.list.d
#
sourcesListD:
- curl -fsSL "https://pieroproietti.github.io/penguins-eggs-ppa/KEY.gpg" | gpg --dearmor -o /usr/share/keyrings/penguins-eggs-ppa.gpg
- echo "deb [signed-by=/usr/share/keyrings/penguins-eggs-ppa.gpg] https://pieroproietti.github.io/penguins-eggs-ppa ./ " | tee /etc/apt/sources.list.d/penguins-eggs-ppa.list > /dev/null

packages #

As the name, here we define packages we need will be installed:

1
2
3
4
5
6
#
# packages to be installed
#
packages:
- kde-plasma-desktop
- plasma-nm

debs #

We define here a place, inside our recipe, containg all the custom debs we need. In this case the directory is named debs. You can choose others name, but I think can be better to name it in accord to the scope.

1
2
3
4
#
# local dir with deb files to be installed
#
debs: false

accessories #

We define others packages we want to let to the user to install or not. Like accessories to our costume.

1
2
3
4
5
6
7
8
9
10
#
# accessories for your dress
#
accessiories:
- ark
- kate
- kcalc
- kde-spectacle
- firefox-esr
- okular
1
2
hostname: true
reboot: true

your wardrobe #

It’s possible to create your own local wardrobe, and create personal costumes. In your costumes on your local wardrobe, you can add a place for debs, for your custom special debs you need.

Considerations #

penguin-grill

Costumes are not limited to the interfaces: Desktop Enviroment and so on. It’s possible to create a dress on a system to be server for xampp or others configurations. Again, you can make an xfce4 installation specialized for eggs developer and name it hen, You will add: xfce4, nodejs-16.x, git and code. Of course, you can dress your image with the specific firmware too, and so on.

This let me to create, simple and light naked system, and the entire work of customization can go on the side of passionate system integrators.

Suggestions are welcome #

penguin-pirate

It’s a new feathure, so - as usual - you can find problems, lacks and so on.

Suggestions and ideas are welcome: together we can see how your ideas can fit inside.

Feel free to open an issue on github - preferred - or to email me at: piero.proietti@gmail.com

Credits #

I want to thanks Jon West from waydroid, from his needs and our discussion come this idea, and pixabay.com, from where I still some fantastic free images!

eggs wardrobe list

eggs wardrobe wear --costume waydroid

access to a VM from egg-of-debian-bullseyes-pve

egg-of-debian-bullseye-pve #

Possiamo utilizzare la nostra immagine iso in molteplici situazioni:

  • sperimentare le possibilità della nostra iso creando all’interno di una installazione di Proxmox VE una VM abilitata per la virtualizzazione nested;
  • utilizzare egg-of-debian-bullseye-pve per avviare un server Proxmox e montare una VM dello stesso.
  • installazione Proxmox VE completa di Workstation;

Primi passi #

Per sperimentare, la possibilità più semplice è quella di creare una VM con processore host, allo scopo di permettere la virtualizzazione nested.

Andiamo quindi a creare la nostra macchina, non servirà neppure un volume di installazione, in quanto utilizzeremo la VM solo in modalità live.

Creazione di real-storage #

Una volta avviata la nostra live con proxmox, dovremo naturalmente create uno storage reale, dove avremo i dischi e le iso delle nostre macchine virtuali.

Per simulare la presenza di uno storage sulla nostra live, andremo a montare con sshfs lo storage della installazione ospitante, normalmente presente in ‘’’/var/lib/vz```

1
2
mkdir /real-storage
sshfs root@192.168.61.2:/var/lib/vz /real-storage

Vediamo cosa contiene il nostro storage:

1
dump  images  private  snippets  template

Non ci resta che montare questo real-storage sulla nostra live, attraverso l’interfaccia di Proxmox-VE.

Selezioniamo data center, quindi “Storage” e clicchiamo su Add. Andremo ad aggiungere lo storage come directory.

add-real-storage

Abbiamo visto che il nostro “real storage” contiene dump images private snippets template per cui nel nostro storage configuriamo:

Disk Imange, ISO image, tralasciando il resto.

add-real-storage

Queste sono le nostre immagini delle VM dell’ospite
add-real-storage

E quest’altre le varie immagini iso presenti sull’host
add-real-storage

Creare una VM sulla live utilizzando lo storage-real #

A questo punto non ci resta che copiare la configurazione della macchina che ci interessa, dall’installazione reale alla nostra home:

1
scp root@192.168.61.2:/etc/pve/qemu-server/300.conf .

ed otterremo il seguente file di configurazione:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 2
efidisk0: local:300/vm-300-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: local:iso/archlinux-2022.02.01-x86_64.iso,media=cdrom
memory: 8192
meta: creation-qemu=6.1.1,ctime=1644734076
name: kisslinux
net0: virtio=96:2F:E5:8A:35:3D,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: local:300/vm-300-disk-1.qcow2,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=81f92f87-08cd-4e1b-bc0a-bc4f16d2f409
sockets: 2
vga: qxl
vmgenid: fa898e0a-1d56-4e1c-bbda-1aa489d5dae4

andiamo a sostituire, allo storage local lo storage real-storage, come nell’esempio seguente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 2
efidisk0: real-storage:300/vm-300-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: real-storage:iso/archlinux-2022.02.01-x86_64.iso,media=cdrom
memory: 8192
meta: creation-qemu=6.1.1,ctime=1644734076
name: kisslinux
net0: virtio=96:2F:E5:8A:35:3D,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: real-storage:300/vm-300-disk-1.qcow2,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=81f92f87-08cd-4e1b-bc0a-bc4f16d2f409
sockets: 2
vga: qxl
vmgenid: fa898e0a-1d56-4e1c-bbda-1aa489d5dae4

Copiamo la configurazione su /etc/pve/qemu-server ed opla, la nostra macchina è apparsa.

Per renderla avviabile, dal momento che non abbiamo ancora creato un bridge per la rete, per semplicità rimuoveremo la stessa.

La nostra immagine sta facendo girare una VM del sistema ospitante!
proxmox-ve-lite-running-kisslinux

A che serve? Ancora non lo sò, ma è davvero carino e potente.

Per chi volesse sperimentare sull’argomento, è a disposizione una egg-of-debian-bullseye-pve con la quale è stato eseguito l’esperimento ed, aventualmente, sono disponibili anche immagini di VM.

backup users revisited

E’ da qualche tempo che sto pensando di rendere eggs utile per effettuare backup,

In effetti non sarebbe troppo difficile, eggs non effettua il salvataggio dei dati utente, per una decisione di progetto: impedire che dati privati vengano esposti in pubblico.

Pur tuttavia, un collega indiano, qualche tempo fa mi propose di utilizzare eggs per spostare delle macchine server da una serverfarm ad un’altra, in particolare dalla sede a Kerala a quella in Germania e viceversa.

Naturalmente i dati non dovrebbero essere esposti su internet, trattandosi anche di dati privati.

Immaginai che eggs, una volta finito il lavoro necessario alla costruzione di una iso, controllasse la dimensione dei dati da salvare dalle rispettive home degli utenti e server, quindi costruisse un volume LUKS di adeguate dimensioni, e ci copiasse questi dati. Infine copiasse nella iso il volume luks stesso.

In effetti già da qualche tempo, eggs ha questa “capacità”. La procedura però - poco testata - aveva dei problemi che, finalmente, sto cercando di risolvere: in primo luogo la stima dei dati, tra blocchi e dimensioni risultava a volte errata e, quindi, il backup veniva interrotto; inoltre, il backup avveniva solo sotto la directory /home, limitando quindi la possibilità di salvare dati dei server.

Immaginando unaa soluzione, abbiamo due casistiche differenti: creare una iso del nostro server con una configurazione di base e che, quindi contiene necessariamente anche le home dei servizi, ed un’altra nella quale abbiamo un server con dati reali e quindi privati, nella quale quindi, gli stessi devono essere presenti in modalità criptata.

Nel primo caso, server con una configurazione di base, creaimo la iso direttamente: nessun backup è necessario, in quanto i dati delle home dei servers vengono comunque copiati nella iso.

Per il secondo caso - backup - invece, dobbiamo:

Prima fase: analisi ed esclusione dei dati privati #

  • analizziamo /etc/password allo scopo di rilevare le varie home significative. C’è anche un nuovo comando in eggs che permette di farsi subito un’idea: eggs analyze
  • creiamo una lista di esclusione aggiuntive per le home degli utenti e servizi rilevati.

Seconda fase: creazione del filesystem.squashfs #

Procediamo normalmente per la creazione del filesystem.squashfs compresso, naturalmente utilizzeremo se del caso le nuove esclusioni per i dati privati.

Terza fase: backup dei dati #

  • dopo la costrunzione del filesystem.squash si torna ad analizzare /etc/passwd e decidere le dimensioni necessarie:
  • preparazione di un un file per il volume luks-eggs-backup
  • creazione e montaggio del volume luks-eggs-backup e copia delle home sia dei server che degli utenti nella cartella demoninata: ROOT del volume stesso;
  • salvataggio dei file: /etc/passwd, /etc/shadow ed /etc/groups nella root del volume luks;
  • chiusura e smontaggio del volume luks e copia del file risultante nella iso

A questo punto ho aggiunto un ulteriore comando ad eggs: eggs syncfrom.

Questo comando non fa altro che realizzare il processo inverso e, se chiamato da un sistema live, sostituisce nel sistema di destinazione dei file cruciali per il suo funzionamento e, cioè /etc/passwd, /etc/shadow ed /etc/groups, quindi, carica tutte le home salvate in precedenza.

Naturalmente, potrebbe essere conveniente inviare i dati da un posto ad un altro in due differenti file, ovvero, da una parte la normale iso contenente la configurazione di base e dall’altra il volume di backup.

Dovremmo, quindi, andare ad utilizzare il comando syncfrom su una macchina installata e fornire come parametro il percorso per il volume luck-eggs-backup precedentemente salvato. Naturalmente in tal caso NON potremo sostituire i file /etc/passwd, /etc/shadow ed /etc/groups, quindi la macchina accetterà soltanto i dati presenti sulle home di servizi ed utenti.

Il sistema, dovrebbe, comunque funzionare, presentare le stesse configurazioni di base ma andrebbe a sostituire le home precedenti con i nuovi dati. In teoria, questo dovrebbe fornire un aggiornamento ed allineamento con il sistema salvato.

A questo punto è nato anche un ulteriore comando: eggs syncto che, senza creare la iso del sistema, crea solamente il volume di backup.

reflections

It’s amazing how after so much effort to create a unique remastering tool, it turns out well.

I’ve just released the eggs 9.0.10 version, the first one running on Debian both in standard and UEFI BIOS mode.

Well, just after publishing it, I restored a VM with manjaro xfce - the last version - give the folloging commands:

  • sudo pamac upgrade
  • sudo pamac install base-devel
  • git clone https://github.com/pieroproietti/penguins-eggs
  • cd penguins-eggs
  • makepkg -sri
  • sudo eggs calamares --install
  • sudo eggs config
  • sudo eggs dad -d
  • sudo eggs produce --fast

After that I exported the resulting iso in my host and put it in another VM enabled with UEFI.

That’s the results:

manjaro-uefi-booting

disperato erotico stomp

Sono due giorni che sto combattendo con UEFI. Ho sempre cordialmente odiato UEFI, purtroppo mi ci tocca convivere!

Per di più utilizzando e - non potendo fare altrimenti delle VM - vengono aggiunti anche i problemi della virtualizzazione.

In effetti, l’anno scorso dopo un duro rincorrere i codici del buon refracta-snapshot-base di fsmithred di cui potete vedere questa intervista del 2019. Refracta, in qualche modo ha fatto la Storia - visto che da questa base si sono sviluppati almeno altri tre progetti: l’installer di Devuan dello stesso autore, quello di MX-linux mx-remaster ed il mio penguins-eggs.

Leggendo, sforzandomi di capire la logica, e ritraducendo il tutto in un misto di typescript e comandi di terminale - più gestibile per i miei gusti - ero riuscito a farlo funzionare.

Non uso molto UEFI però, normalmente sulla stazione di lavoro composta da Proxmox VE sul quale ho installato una interfaccia grafica cinnamon ed i strumenti di sviluppo, le macchine nascono con BIOS standardd e l’UEFI ha rappresentato sempre - come dire - una inutile “rottura”. Così non mi sono accorto di quando era successo il “fattaccio”.

Sono andato a tentoni, cercando di ritrovare una immagine funzionante, ma ne faccio e ne cancello così tante che non c’è stato verso.

In effetti avevo anche un problema sulla virtualizzazione, o meglio qualche cambio della stessa, di cui non mi ero reso conto.

Tutti i nodi vengono al pettine #

Avendo però attualmente un collega, che sta sviluppando una distribuzione con interfaccia Android, l’esigenza di utilizzare un notebook Microsoft, ci siamo trovati di fronte al problema,

Non mi capacitavo del perchè era sempre rimasto alla versione 8.17.x di eggs. Mi riferiva di avere problemi con la versione corrente, ma non avevo compreso che il problema era proprio la sua necessità del funzionamento UEFI, a me le nuove versioni andavano, a lui no. Io d’altra parte ero impossibilitato dal compremdere, in UEFI semplicemente non mi funzionavano ne’ le versioni della serie 8.x, ne quelle della 9.x e quindi, non conoscevo quando s’era rotto il codice.

In effetti era successa una cosa diversa: l’emulazione di Proxmox andava riconfigurata, si può avviare con UEFI ma sono disabilitando il secure boot.

Ieri, preso dal panico che l’amico dovesse rinunciare alla collaborazione in ragione del fatto che non riuscivo ad assicurargli l’avvio UEFI, ho cominciato ad indagare.

Il primo passo è stato richiedere allo stesso una “ultima” iso funzionante.

Con sorpresa, l’ultima iso funzionante era proprio quella che mi aveva appena condiviso.

Quindi, una volta segnato il punto è cominciata la caccia!

Per prima cosa ho provato con una chiavetta USB e, finalmente scopro che in effetti l’immagine che mi era stata inviata funziona in UEFI dalla chiavetta USB. Era solo dall virtualizzatore che non riuscivo ad avviarla.

Una volta assicuratomi di questo e, dopo la meritata dormita notturna, fresco al risveglio ho cercato di capuire che problemi avessi su Proxmox dove la stessa immagine non veniva avviata.

Dopo una oretta di bestemmie varie, ho compreso che il problema risiedeva nella configurazione interna delle VM UEFI, ho fatto i seguenti passi:

Avvio la macchina virtuale, precedentemente configurata con BIOS: OMVF (UEFI) e la avvio premendo il tast ESC.
uefi-ovmf

e vado a selezionare il: Device manager:
uefi-device-manager

A questo punto, scelgo: secure boot configuration
uefi-secure-boot-configuration

Mi trovo la seguente schermata, nella quale come si può vedere, lo stato corrente di Secure Boot è enabled.
uefi-seture-boot-state-enabled

Non ci resta che modificare lo stato e disabilitarlo:
uefi-current-state

Adesso le nostre immagini potranno essere avviate con UEFI.

Mi resta ancora da capire, perchè le distro originali Debian/Ubuntu/etc funzionano comunque. anche con il Current Secure Boot State enable, ma questo ce lo portiamo appreso per una prossima fase. Si accettano però suggerimenti.

Inizio della comparazione del codice 8.17.x con la versione 9.0.x #

La versione 9.0.x ha subito diverse riscritture rispetto alla versione originale e, tornare indietro, è discretamente impossibile. Per cui mi sno concentrato sulle differenze tra le due versioni, comparando i file cruciali per il boot UEFI: grub.template e grub.theme.cfg con quelli dell’altra versione.

Mi sono subito accorto che, addirittura, manco li avevo aggiornati, erano ancora con i vecchi parametri che, nella versione 9.x, ho dovuto riunire in un unico paramtro kernel_paremeters per gestire meglio le varie famiglie di linux.

Il processo è durato almeno due ore buone, perchè l’unico modo che conosco per controllare grub è quello di generare una nuova iso e testarla. Ho scoperto oggi grub-emu, un emutatore di grub discretamente funzionante, ma alla fine non l’ho trovato pratico.

Sistemato, con alterne fortune il template di grub ed il codice per il suo riempimento ho notato di avere comunque errori.

La macchina si avvia, ma va in grub rescue. Però immettendo:

1
2
3
set root=(cd0)
set prefix=(cd0)/boot/grub
normal

e dando invio. Pur senza caricare il tema - nel quale ho poi scoperto altri problemi - esegue correttamente il boot in UEFI.

A domani per il definitivo bugfix ed il completamento dell’articolo.

Se qualcuno vuole darci una occhiata, questi sono i file di configurazione:

mentre il codice che compone i kernel_parameter si trova in ovary.ts, nella fuzione makeEfi() dalla linea 1335

Conclusioni #

Con la versione eggs-9.0.10 possiamo finalmente dire: la stagione di caccia è finita!

Le ragioni del non funzionamento erano molteplici:

  • problematiche di configurazione delle VM utilizzate che mi hanno impedito di rendermi conto immediatamente del problema;
  • problematiche legate alla difficoltà di creare degli splash compatibili con grub;
  • questa istruzione, in makeEfi() di ovary.ts
1
2
// make a tarred "memdisk" to embed in the grub image
await exec(`tar -cvf ${memdiskDir}/memdisk ${memdiskDir}/boot`, echo)

che si portava dietro tutto il path di memdiskDir, ed stata così modificata:

1
2
3
4
5
6
7
8
// make a tarred "memdisk" to embed in the grub image
/**
* NOTE: it's CRUCIAL to chdir before tar!!!
*/
const currentDir = process.cwd()
process.chdir(memdiskDir)
await exec(`tar -cvf memdisk boot`, echo)
process.chdir(currentDir)

Va bene, la rampa di lancio è stata approntata, si resta in attesa dell’arrivo dei missili e del conto alla rovescia.

Buon viaggio in UEFI a tutti!

finally we solved the last problems with gnome

Actually, it was a long story.

Before, to enable a link on the gnome desktop, it was enough to mark it with the right to run chmod a+x penguins-eggs.desktop, but since some time, it was necessary to use gio.

Either because I didnt use gnome much, or because I must be so confused that I didnt understand how this program works, until now gnome links always remained to be enabled.

Finally, the necessity to develop with eggs an important distribution made me look at the problem that can be said to be solved.

Ubuntu gnome

Is There Anybody Out There?

These are currently the 10 most clicked distros on distrowatch, to date we can already remaster
most of them!

  • MX Linux No
  • EndeavourOS No
  • Manjaro Yes
  • Mint Yes
  • Pop!_OS Yes
  • Ubuntu Yes
  • Debian Yes
  • Garuda No
  • elementary Yes
  • Fedora No

MX Linux has its own remastering tools. I tried eggs on it, but in the end there is already what you need: the combination of mx-snapsnot and mx-installaer, and work great!

On Garuda and Endeavour I have made some attempts. On Garuda the mkinitcpio configuration fail for me and on EndeavourOS - strange to say - I didn’t find Calamares. It should probably be extremely easy to make eggs compatible with both, but it needs the cooperation of some hackers from the respective distros.

But the best part will be to bring eggs in Fedora! Someone on line?

distrowatch

macaroni penguins illustrating eggs on manjaro

You have to know that appetite comes with eating, so surprised by how quickly eggs was adopted by manjaro, I tried my hand at cinematography.

I made two videos, in the first we’ll see the ease of installation of eggs in manjaro, its configuration and the production of an iso image.

The second video will show how to install the image obtained in another computer.

I hope I’ve managed, at least with sympathy!

If you want to continue torturing yourself, this is my channel.

ubuntu

macaroni penguins preparing new adventures...

We have just finished the release of eggs for manjaro linux, it has been a nice undertaking and a nice discovery, a system how to say: fast, updated and performing.

What opportunities for the future and growth of eggs? #

eggs as backup system #

A dear friend of mine suggested me to propose it as a backup tool, in fact - server side - it is already possible to create a complete backup of an installation and reinstall it.

What’s more, it is also possible to transfer a server for example from a node in India to one in Germany, without having to expose the data.

In fact the backup is done by eggs copying the ENTIRE system except the /home folder, then a LUKS volume is created with our pass phrase that will be required during the installation.

Without the knowledge of the pass phrase, you will be able to restore the system but not our data.

This security might not be necessary for a home backup, and you could add a flag to save a user’s home for personal use as well: carry the complete system on a flash drive and so on.

eggs as a tool for creating vertical deployments #

Although it started as a personal tool, eggs has grown in recent years and is already used by some Linux distributions derived from Debian, Devuan or Ubuntu.

With the inclusion of manjaro we have a tool that allows us to create our own custom version of the system in an extremely fast and professional way, on a myriad of derived distributions.

In the long run it is more constructive to use the original material and have the possibility to handle and adapt it to our needs than to take for example the tools of one and recreate your own. It’s simply faster!

The road to a school or corporate distro is paved and has been beaten since the days of systemback, now there are new possibilities and a better level.

eggs on other architectures arm64, armel #

With the transition from node 8.x to node 16.x, we had to give up the long-standing i386 compatibility. We could take the opportunity to test the arm64 and armel architectures, in this we are also helped by the fact that manjaro has its own development group on this architecture.

Conclusions #

I believe that this tool, the ability to “reproduce” the system may appeal to many and many may adopt it.

On the other hand, the concept of population diversification, reproduction and selection is not new and, according to observation of nature, quite powerful.

So it remains to be understood what the roads may be, but they are certainly open.

macaroni penguins

Yes, I think we found our wonderfull mascot: ironic, fat and - of course - italian. Not only, as eggs, inside contain mainly krill!