CA FAIT DU BRUIT, les serveurs rackables sont conçus pour un environnement sans humains, truffés de ventilateurs qui n'ont aucune retenue en terme de vrombissements et sifflements. C'est impossible de les laisser allumés plusieurs heures dans la pièce où tu travailles (à moins que tu ne travailles qu'avec du heavy metal dans le casque).
Je ne savais pas qu'avec -M on pouvait passer les args à l'importeur, du coup je l'avais zappé, mais bon sang c'est bien sûr !
Je ne connaissais pas l'alias de push en $t[@t]=, j'adopte (pour les oneliners…). Et le += qui force un contexte scalaire ET promet une valeur indéfinie en 0 en mode non-strict, c'est bien recherché :).
J'évite $#t qui a un facteur brainfuck très élevé (le rapport gain de compression vs. perte de lisibilité me semble très défavorable), mais évidemment c'est valide et plus court.
merci beaucoup pour ces journaux et votre travail sur le boot.
En ces temps où il est déjà difficile d'expliquer et responsabiliser des dev(ops) qui piochent n'importe quelle image cloud ou Docker et ne se posent aucune question de sécurité et de chaîne de confiance, aller jusqu'au boot et expliquer qu'il faudrait aussi s'inquiéter du firmware n°1 est une tâche super ardue… Ca me semble pourtant en effet essentiel.
Je vois aussi d'autres avantages : par ex. concernant Meltdown, les maj de microcodes restent étroitement liées aux constructeurs et à leurs BIOS (je peux les faire moi-même depuis Linux, mais le vendeur peut me garantir la couverture de test pour un hard particulier). Avec un LinuxBios je pourrais court-circuiter le vendeur et faire mes tests beaucoup plus facilement…
Et oui, le temps de boot des serveurs c'est un sujet, chez Dell on en arrive à des POSTs délirant de 2 à 3min pour le moindre serveur. Quand on debug un automate ou une panne ça rend le processus extrêmement inefficace. Quand on veut minimiser un downtime sur un service non redondé ou cloudé (et il en reste des tonnes dans la nature), c'est souvent ce qui plombe le SLA. Et objectivement on sait que c'est un indécent par rapport aux réels besoins que la physique impose (stabilisation des alims, allumage en cascade des éléments, etc). Tout POST > 10s devrait pouvoir être considéré comme un défaut de construction :(.
Note historique : j'ai bossé au début des années 2000 sur des Cobalt/Raq (projet Sun) qui utilisaient Linux comme firmware, et c'était tellement bien conçu et ouvert que je pouvais moi-même recompiler des Linux/firmwares sans soucis (sans être dév kernel). Le support Cobalt/Raq était d'ailleurs mainstream dans Linux (au moins pour les 2.2 et 2.4). J'ai ainsi maintenu des firmwares de ces Raq pendant plus de 5 ans après la fin de vie de ces produits. Ces machines étaient triviales à administrer à distance, provisionner, debugger. Elles postaient en 1 à 2s (!). Tous les autres équipements (serveurs, routeurs) me semblent d'une hostilité incroyable depuis cette expérience.
Sur vos questions sur le contexte de boot idéal, je ne sais pas trop ce qu'il pourrait être mais j'ai une bonne idée sur ce qu'il ne pourrait pas être :
oublier tout ce qui est vidéo/VGA; ou plus exactement le laisser hors-scope, ceux qui veulent aller de ce côté le feront s'ils le souhaitent
oublier les interfaces pseudo-vidéo à la ncurses : souvent inutilisables via des consoles séries, n'ont en général pas la moindre notion de termcap, sont inscriptables, etc; pareil, devrait être hors-scope, si des gens veulent faire ça, qu'ils n'embêtent pas les autres avec ça
oublier les firmwares pluggables avec chacun leur propre vision du monde (et interface, et idiomes, etc), mais ça je crois que c'est déjà fait vu que c'est dans le design de NERF :)
oublier IPMI dont l'intention est bonne mais dont le protocole est ridicule (personne ne l'implémente correctement, du moins de façon interopérable, et je parie qu'il est truffé de trous de sécu)
Dans le cahier des charges, il me vient à l'esprit :
être trivial à prendre en main par un opérateur; le fait que ce soit une forme de shell autodocumenté semble assez attendue
faciliter l'automatisation; sans aller jusqu'à vouloir définir une API, ce qui serait trop rigide et trop de travail. Ca peut très bien marcher en laissant les acteurs se synchroniser sur des formats 'machine readable' des commandes usuelles, le pragmatisme faisant souvent des merveilles; en tout cas les admins sont rompus à assurer la glue avec ce genre d'outils et n'auraient aucune objection a maintenir un jeu d'automate par vendeur (rien que pouvoir le faire serait une avancée énorme, regardez la complexité et la fragilité de FAI)
avoir des opinions fortes pour limiter la configurabilité et faire disparaître plein de problèmes de déploiement et de développement; par ex. les Cobalt/Raq avaient un port série en 115200n8, c'était comme ça et pas autrement (et, malins, un second port série pour un usage libre, rendant tout le monde content). Evacuation de moults questions et inconnues, s'il n'y a pas de raison que ça soit configurable, alors ça ne doit pas l'être.
s'il doit y avoir de l'auth, utiliser/imposer SSH; la hostkey pourrait être générée pour chaque build et signée par le builder (sur un site public), ce qui permettrait de vérifier trivialement qu'on s'adresse bien à la première connection au firmware fourni par le tiers prévu
d'un autre côté je dois dire que j'utilise des LAN dédiés pour l'ILO et si je pouvais juste avoir des telnets triviaux, ce serait aussi simple; mais SSH est tellement universel, trivial, et surtout beaucoup plus utilisable que telnet (notion de canal, pty oui/non, keepalive, tunnel, etc) que je ne vois aucune excuse de s'en passer
Et c'est peut être hors sujet, mais si on pouvait obliger la présence d'un support Flash librement utilisable d'environ 512 MB, ça ne coûterait quasiment rien à l'intégrateur, et ça pourrait révolutionner le déploiement de pas mal de serveurs où l'OS est très simple (hyperviseur, filers, routeurs soft, loadbalancers soft, etc.) quand on veut être plus résilient qu'une infra de netboot (qui de plus est pénible à maintenir et scaler).
Promouvoir la concurrence entre le propriétaire et le libre dans les appels d'offres ? Vous croyez qu'il se passe quoi actuellement ? Que RedHat a attendu Attali pour se prendre sa part dans la jungle (alors massivement propriétaire) des Unix ? Et l'assemblée pour virer ses Windows ? (ça c'est un troll!)
On est en déjà à lobbyer pour barrer la route au propriétaire au niveau des appels d'offres publics, sa proposition est même un recul dans ce contexte politique. Sa propositon est peu éclairée (il est bien plus fûté, démocrate et humaniste que ça) et se contente de faire remarquer un phénomène qui se passe de ses recommandations. Bof.
La modération de Neimad me semble de mise, Roberto s'extase un peu vite.
J'ai passé 1 mois en octobre 2003 à faire le tour de l'Argentine (en touriste). J'ai du tester une bonne 30aine de cybercafés, des Andes à l'Atlantique, de la Bolivie et le Brésil à la Terre de feu... Tous étaient systématiquement sous windoze+IE (souvent de pathétiques win98), et tout le monde chattait avec MSN. Je me souviens juste avoir aperçu une affiche annonçant la réunion d'un LUG (à Salta)...
J'ai été épaté par l'Argentine: il y a minimum un cyber par rue (voire une 10aine par paté à Buenos Aires, les fameux 'Telefonico'), c'est blindé de jeunes argentin(e)s, mais il n'y a(vait) pas de traces de logiciel libre.
Pour la fin de l'article, je suis d'accord, le pays et ses habitants sont merveilleux :).
> comment _le code_ de ce projet va-t-il s'articuler avec toutes les autres initiatives de ce genre ?
Il y a des cas où les forks sont bénéfiques, où du moins ne font pas nécessairement souffrir les projets existants.
SourceForge, Savannah, GForge et maintenant Savane ont chacun leur but, leur raison d'être et leurs motivations. Savane est un fork de Savannah pour plusieurs raisons, comme par exemple une prise en compte de la sécurité radicalement différente. Il reste toujours des portions communes, des techniques communes et des gens communs.
Avec la maturité, peut être que quelques projets refusionneront s'ils atteignent une superbe architecture modulaire qui sait accueillir toutes leurs différences. Mais pour le moment chacun à ce qu'il veut pour fonctionner comme il l'entend, et c'est bien ainsi :)
Tout projet libre n'ayant pas de dépendance obligatoire sur une solution propriétaire sera accepté. Par exemple, si ton programme en Java peut tourner sur une JVM libre (Kaffe), c'est OK. Les dépendances optionnelles sur du propriétaire sont acceptées (portage vers windoze, etc).
Je me suis fait doubler par Master-dik de 20 petites minutes ...
Je suis l'auteur du portage original de Scol pour GNU/Linux (closed source, qui date de 99), et je suis bien placé pour savoir qu'il n'a pas été maintenu. J'ai (très) activement participé aux débats avant le choix de la licence du 'Scol ouvert', qui date de 2 mois au passage, et j'ai signalé mon inquiétude face à la licence qui mélange droit d'auteur et droit des marques, et surtout le brevet logiciel lié à DMS et déposé à l'OBE.
J'ai également prodigué de nombreux conseils pour adapter Scol au modèle de développement communautaire, mes mails sont restés lettre morte. Il n'existe bien sûr pas d'archive malgré mes réclamations. Je me suis retiré du mouvement pour éviter des fâcheries politiques avec des gens que j'estime par ailleurs.
En résumé : pas de logiciel libre, de l'Open Source très partiel, du code incomplet, pas de client GNU/Linux, un esprit communautaire à peine embrionaire, et du brevet logiciel. Que demande le peuple ?
# Serveur rack : pas pour le bureau
Posté par zerodeux (site web personnel) . En réponse au journal Intel = 14 nm, AMD = 7 nm, ARM = 7 nm… et mon serveur ?. Évalué à 3.
CA FAIT DU BRUIT, les serveurs rackables sont conçus pour un environnement sans humains, truffés de ventilateurs qui n'ont aucune retenue en terme de vrombissements et sifflements. C'est impossible de les laisser allumés plusieurs heures dans la pièce où tu travailles (à moins que tu ne travailles qu'avec du heavy metal dans le casque).
[^] # Re: NSI
Posté par zerodeux (site web personnel) . En réponse à la dépêche Apprentissage de la programmation dans les lycées (SNT/NSI) — la création d’exercices. Évalué à 2.
Un bouquin réalisé par des chercheurs d'un labo publique, diffusé sous licence propriétaire et par un biais lucratif, je tique.
Un lien Amazon, je tique.
Tic-tic.
[^] # Re: Et la version code golfé en brainfuck?
Posté par zerodeux (site web personnel) . En réponse au journal TapTempo en une ligne. Évalué à 1.
Ah oui, c'est quasi l'univers dual du one-liner Perl …
[^] # Re: .
Posté par zerodeux (site web personnel) . En réponse au journal TapTempo en une ligne. Évalué à 0.
Si je dis ruby-esque ça te va ? :)
[^] # Re: Suggestions
Posté par zerodeux (site web personnel) . En réponse au journal TapTempo en une ligne. Évalué à 2.
Belle optim' !
Je ne savais pas qu'avec -M on pouvait passer les args à l'importeur, du coup je l'avais zappé, mais bon sang c'est bien sûr !
Je ne connaissais pas l'alias de push en
$t[@t]=, j'adopte (pour les oneliners…). Et le+=qui force un contexte scalaire ET promet une valeur indéfinie en 0 en mode non-strict, c'est bien recherché :).J'évite
$#tqui a un facteur brainfuck très élevé (le rapport gain de compression vs. perte de lisibilité me semble très défavorable), mais évidemment c'est valide et plus court.# Suggestions/expérience sur le boot de serveur
Posté par zerodeux (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). Évalué à 3.
Bonjour,
merci beaucoup pour ces journaux et votre travail sur le boot.
En ces temps où il est déjà difficile d'expliquer et responsabiliser des dev(ops) qui piochent n'importe quelle image cloud ou Docker et ne se posent aucune question de sécurité et de chaîne de confiance, aller jusqu'au boot et expliquer qu'il faudrait aussi s'inquiéter du firmware n°1 est une tâche super ardue… Ca me semble pourtant en effet essentiel.
Je vois aussi d'autres avantages : par ex. concernant Meltdown, les maj de microcodes restent étroitement liées aux constructeurs et à leurs BIOS (je peux les faire moi-même depuis Linux, mais le vendeur peut me garantir la couverture de test pour un hard particulier). Avec un LinuxBios je pourrais court-circuiter le vendeur et faire mes tests beaucoup plus facilement…
Et oui, le temps de boot des serveurs c'est un sujet, chez Dell on en arrive à des POSTs délirant de 2 à 3min pour le moindre serveur. Quand on debug un automate ou une panne ça rend le processus extrêmement inefficace. Quand on veut minimiser un downtime sur un service non redondé ou cloudé (et il en reste des tonnes dans la nature), c'est souvent ce qui plombe le SLA. Et objectivement on sait que c'est un indécent par rapport aux réels besoins que la physique impose (stabilisation des alims, allumage en cascade des éléments, etc). Tout POST > 10s devrait pouvoir être considéré comme un défaut de construction :(.
Note historique : j'ai bossé au début des années 2000 sur des Cobalt/Raq (projet Sun) qui utilisaient Linux comme firmware, et c'était tellement bien conçu et ouvert que je pouvais moi-même recompiler des Linux/firmwares sans soucis (sans être dév kernel). Le support Cobalt/Raq était d'ailleurs mainstream dans Linux (au moins pour les 2.2 et 2.4). J'ai ainsi maintenu des firmwares de ces Raq pendant plus de 5 ans après la fin de vie de ces produits. Ces machines étaient triviales à administrer à distance, provisionner, debugger. Elles postaient en 1 à 2s (!). Tous les autres équipements (serveurs, routeurs) me semblent d'une hostilité incroyable depuis cette expérience.
Sur vos questions sur le contexte de boot idéal, je ne sais pas trop ce qu'il pourrait être mais j'ai une bonne idée sur ce qu'il ne pourrait pas être :
Dans le cahier des charges, il me vient à l'esprit :
Et c'est peut être hors sujet, mais si on pouvait obliger la présence d'un support Flash librement utilisable d'environ 512 MB, ça ne coûterait quasiment rien à l'intégrateur, et ça pourrait révolutionner le déploiement de pas mal de serveurs où l'OS est très simple (hyperviseur, filers, routeurs soft, loadbalancers soft, etc.) quand on veut être plus résilient qu'une infra de netboot (qui de plus est pénible à maintenir et scaler).
[^] # Quel progrès ?
Posté par zerodeux (site web personnel) . En réponse au journal Le libre présent dans le rapport Attali. Évalué à 6.
On est en déjà à lobbyer pour barrer la route au propriétaire au niveau des appels d'offres publics, sa proposition est même un recul dans ce contexte politique. Sa propositon est peu éclairée (il est bien plus fûté, démocrate et humaniste que ça) et se contente de faire remarquer un phénomène qui se passe de ses recommandations. Bof.
[^] # Re: Naif
Posté par zerodeux (site web personnel) . En réponse à la dépêche Voyage dans un pays libéré. Évalué à 1.
J'ai passé 1 mois en octobre 2003 à faire le tour de l'Argentine (en touriste). J'ai du tester une bonne 30aine de cybercafés, des Andes à l'Atlantique, de la Bolivie et le Brésil à la Terre de feu... Tous étaient systématiquement sous windoze+IE (souvent de pathétiques win98), et tout le monde chattait avec MSN. Je me souviens juste avoir aperçu une affiche annonçant la réunion d'un LUG (à Salta)...
J'ai été épaté par l'Argentine: il y a minimum un cyber par rue (voire une 10aine par paté à Buenos Aires, les fameux 'Telefonico'), c'est blindé de jeunes argentin(e)s, mais il n'y a(vait) pas de traces de logiciel libre.
Pour la fin de l'article, je suis d'accord, le pays et ses habitants sont merveilleux :).
[^] # Re: Gna! pour l'hébergement de développement libre
Posté par zerodeux (site web personnel) . En réponse à la dépêche Gna! pour l'hébergement de développement libre. Évalué à 1.
Il y a des cas où les forks sont bénéfiques, où du moins ne font pas nécessairement souffrir les projets existants.
SourceForge, Savannah, GForge et maintenant Savane ont chacun leur but, leur raison d'être et leurs motivations. Savane est un fork de Savannah pour plusieurs raisons, comme par exemple une prise en compte de la sécurité radicalement différente. Il reste toujours des portions communes, des techniques communes et des gens communs.
Avec la maturité, peut être que quelques projets refusionneront s'ils atteignent une superbe architecture modulaire qui sait accueillir toutes leurs différences. Mais pour le moment chacun à ce qu'il veut pour fonctionner comme il l'entend, et c'est bien ainsi :)
[^] # Re: Gna! pour l'hébergement de développement libre
Posté par zerodeux (site web personnel) . En réponse à la dépêche Gna! pour l'hébergement de développement libre. Évalué à 1.
[^] # Re: Oui mais
Posté par zerodeux (site web personnel) . En réponse à la dépêche La technologie de monde virtuel 3D Scol passe en open-source. Évalué à 10.
Je suis l'auteur du portage original de Scol pour GNU/Linux (closed source, qui date de 99), et je suis bien placé pour savoir qu'il n'a pas été maintenu. J'ai (très) activement participé aux débats avant le choix de la licence du 'Scol ouvert', qui date de 2 mois au passage, et j'ai signalé mon inquiétude face à la licence qui mélange droit d'auteur et droit des marques, et surtout le brevet logiciel lié à DMS et déposé à l'OBE.
J'ai également prodigué de nombreux conseils pour adapter Scol au modèle de développement communautaire, mes mails sont restés lettre morte. Il n'existe bien sûr pas d'archive malgré mes réclamations. Je me suis retiré du mouvement pour éviter des fâcheries politiques avec des gens que j'estime par ailleurs.
En résumé : pas de logiciel libre, de l'Open Source très partiel, du code incomplet, pas de client GNU/Linux, un esprit communautaire à peine embrionaire, et du brevet logiciel. Que demande le peuple ?
Vincent Caron