Voilà qu'aujourd'hui, sur la ML d'OpenBSD, quelqu'un cherche à faire baisser la taille d'OpenBSD tout en gardant les fonctionnalités (réseaux) dont il a besoin. C'est trivial sous Linux, mais avec le poisson qui pique, c'est une autre affaire. Comme toujours sur cette mailing list, le pauvre se fait gentiment éconduire ; florilège :

I'd suggest spending the additional ~$2 for the 1GB flash and not to mess with anything!

Lastly if you do build a little shrip frankensystem, asking for help here isn't going to get a lotof sympathy.  You'll be on your own.

If you have to ask, you shouldn't be doing it.  Why would you possibly  need to get smaller than the baseXX, etcXX and manXX sets?  These easily  fit on a few hundered MB.  What modern flash disk won't fit this?

Ah ces barbus, ils sont formidables, et toujours au fait de ce qui se passe dans la vraie vie de tous les jours. Soit le monde de l'embarqué, où il n'est guère décent de proposer une distribution de 512Mo qui embarque les pages man autant que le fabuleux répertoire /usr/share/misc/, qui pour 7,2Mo propose la liste complète des aéroports dans le monde (fichier airports), ou les codes postaux aux États-Unis (zipcodes) ; bon, je suis méchant, il faut garder à tout prix terminfo.db (3,0Mo), mais on peut bazarder termcap.db (2,7Mo).

Il existe deux projets qui se proposent cependant de passer outre la religion inflexible du "touche à rien" (un autre concept de la geek-attitude) : flashdist et soekris (il y eut aussi flashboot). Mais voilà : basées sur des scripts qui copient les fichiers nécessaires à la nouvelle distribution réduite depuis le système de fichier de la distribution courante vers un répertoire donné (avant de l'intégrer dans un master), leur méthode est clairement de type top-down. Pour du bottom-up, c'est-à-dire de la compilation des sources pour obtenir le firmware (ou le master, à savoir le firmware plus le bootloader et d'autres partoches qui servent à stocker par exemple de gros fichiers, ce qui en soit justifie de réduire la taille de la distrib' -- qui pèse plus de 250Mo quand on ne met que le package "base", celui qui contient tellement peu de choses réellement utiles qu'on est rapidement embêté), j'ai bien peur que ce soit une autre paire de manches.

5.2 - Why do I need to compile the system from source?
Actually, you very possibly do not.
Some reasons why NOT to build from source:
     * Compiling your own system as a way of upgrading it is not supported.
     * You will NOT get better system performance by compiling your own system.
     * Changing compiler options is more likely to break your system than to improve it.

Et c'est sans compter le système de mise à jour assez rudimentaire (euphémisme) du firmware proposé par nos deux solutions :

You now need to take the image file and write it to your compact flash device using dd. Make sure you are using the correct device otherwise you can blow away your hard-disk or other devices.
 dd if=image_cf of=/dev/??? bs=1k

(pour faire bref : tu démontes ton serveur, tu enlèves la compact flash, tu la branches dans ton adaptateur universel, et après tu ne te trompes surtout pas de device où copier comme un gros cochon, sinon tu risques de flinguer des trucs pas bons, style ton disque dur -- c'est super industriel comme procédé, je me vois bien proposer ça à un client)

Oh, il y a des recettes pour faire ça dans son garage, mais pour des applications industrielles, ça reste assez vague. "Homemade Embedded BSD Systems" et "Embedded OpenBSD" sont dans le genre de bonnes intros, mais on est loin du compte.

Ou alors, il y a Linagora. Et en plus, vous ne serez même pas mal accueilli (et on s'étonne que je n'aie jamais laissé de messages sur cette ML...). Et en plus, le firmware peut être mis à jour à chaud, et on peut revenir en arrière en un clin d'oeil. Et en plus... Ah ah, il faut garder des surprises !  :)