Helios : la distribution illumos qui fait fonctionner l’Oxide Rack

 (github.com/oxidecomputer)
1 points par GN⁺ 2024-01-30 | 1 commentaires | Partager sur WhatsApp
  • Helios est la distribution illumos qui fait fonctionner l’Oxide Rack ; les outils et la documentation de ce dépôt de premier niveau pilotent la construction de la distribution complète en regroupant plusieurs consolidations logicielles
  • La distribution utilise la branche stlouis d’illumos-gate comme OS de base et fournit principalement des paquets illumos standard, auxquels s’ajoutent des éléments pour le matériel Oxide et quelques transformations de packaging
  • Tous les dépôts de configuration ne sont pas publics ; les consolidations privées peuvent être exclues des cibles de clonage et de build avec OXIDE_STAFF=no gmake setup
  • La construction de ses propres paquets s’effectue dans un environnement Helios récent avec rustup, gmake setup et l’outil helios-build basé sur Rust ; pendant le développement, un quick build est possible en désactivant le compilateur fantôme et certains contrôles
  • Les résultats de build peuvent être installés dans un environnement de démarrage local, distribués à d’autres systèmes de test via pkg.depotd, ou bien générés uniquement sous forme de dépôt de paquets transformés pour inspection, sans installation

Rôle et composition de Helios

  • Helios est la distribution illumos qui fait fonctionner l’Oxide Rack
  • La distribution complète se compose de plusieurs consolidations logicielles, et les outils et la documentation de ce dépôt de premier niveau pilotent le build
  • Les consolidations publiques incluent notamment :
  • Certaines consolidations ne sont pas encore publiques
    • amd-firmware : blobs binaires de firmware pour CPU AMD, publication prévue ultérieurement
    • chelsio-t6-roms : blobs de firmware pour NIC Chelsio T6, publication prévue ultérieurement
    • pilot : utilitaires de contrôle bas niveau des systèmes Oxide, publication prévue ultérieurement
    • dmar-report : générateur de rapports de DRAM margining, publication prévue ultérieurement
  • Si vous n’avez pas accès aux dépôts privés, OXIDE_STAFF=no gmake setup permet d’ignorer le clonage et le build des logiciels qui ne sont pas encore publics

Environnement de départ et configuration initiale

  • La procédure s’adresse aux personnes qui veulent construire et installer leurs propres paquets d’OS ; si l’objectif est seulement d’utiliser Helios, il faut se référer aux informations sur les logiciels Helios précompilés dans helios-engvm
  • Le point de départ recommandé est une machine de build physique ou virtuelle avec une version récente de Helios installée
    • Les détails d’installation en machine virtuelle se trouvent dans helios-engvm
    • Les informations sur les médias d’installation pour systèmes x86 physiques se trouvent dans le même dépôt
  • Si vous avez créé une VM avec la procédure helios-engvm, les paquets nécessaires devraient déjà être installés
  • Si vous avez créé un environnement Helios avec l’installateur ISO ou une autre méthode, le paquet pkg:/developer/illumos-tools peut être nécessaire
    • Vérifiez son installation avec pkg list developer/illumos-tools
    • S’il manque, installez-le avec pkg install
  • Il est conseillé d’utiliser les paquets Helios les plus récents et de vérifier les instructions affichées après pkg update
    • Si la mise à jour indique qu’elle a créé un nouveau boot environment, activez-le avec reboot avant de continuer
  • Rust et Cargo s’installent avec rustup, via les binaires officiels du projet Rust
    • Dans la procédure d’installation officielle, utilisez bash au lieu de sh
    • Exemple de commande : curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

Clonage du dépôt et helios-build

  • Sur une machine Helios, clonez le dépôt puis exécutez gmake setup
    • L’outil helios-build basé sur Rust est construit dans tools/helios-build
    • Plusieurs dépôts sont clonés sous projects/
  • Si vous n’avez pas accès aux dépôts privés de l’organisation GitHub oxidecomputer, vous pouvez n’utiliser que les dépôts publics ainsi :
    • OXIDE_STAFF=no gmake setup
  • Le premier build de l’outil helios-build peut prendre du temps
  • L’étape de configuration initiale clone les dépôts de projets attendus, mais les opérations ultérieures comme les mises à jour ou les changements de branche ne s’appliquent qu’à certains dépôts
    • Les dépôts mis à jour automatiquement sont indiqués dans auto_update dans config/projects.toml
    • Pour les autres clones locaux, les changements de branche et les pull doivent être gérés directement comme dans des dépôts Git ordinaires

Méthode de build d’illumos

  • Les composants de l’OS de base de Helios proviennent de la branche stlouis d’illumos-gate
  • Les paquets inclus dans un système Helios sont pour l’essentiel des paquets illumos standard, complétés par des éléments pour le matériel Oxide et quelques légères transformations de packaging
  • helios-build facilite le build d’illumos en gérant la configuration de build et en fournissant plusieurs wrappers qui appellent les outils de build illumos
  • La documentation amont Building illumos couvre la plupart des tâches que les outils Helios exécutent à votre place
  • Pendant le développement, vous pouvez effectuer un quick build avec la commande suivante
    • ./helios-build build-illumos -q
    • Le quick build désactive le compilateur fantôme et certains contrôles exigés lors de l’intégration finale
  • La durée de build dépend du nombre de CPU de la machine de build et des performances du stockage local
  • Les journaux de build complets sont volumineux ; vous pouvez par exemple les consulter avec tail -F projects/illumos/log/nightly.log
  • Si le build réussit, un dépôt de paquets est créé dans projects/illumos/packages/i386, puis peut être transformé et installé de différentes manières

Installation et distribution des paquets construits

  • Installation sur la machine de build locale

    • Les paquets nouvellement construits peuvent être installés sur la machine de build avec ./helios-build onu -t my-be-name
    • Cette commande transforme et installe les paquets illumos, puis crée un nouveau Boot Environment portant le nom passé avec -t
    • Le nouveau boot environment est activé par onu, puis l’utilisateur redémarre pour entrer dans cet environnement
    • Pour plus d’informations sur les boot environments, consultez beadm(8)
    • Lors du redémarrage, il est préférable d’être sur la console afin de voir les messages de démarrage et de pouvoir interagir avec le boot loader
    • Après l’installation, pkg list -Hv system/kernel permet de vérifier que le paquet system/kernel provient du publisher local basé sur fichiers on-nightly et de la version quick build 3.0.999999

  • Installation sur une autre machine via un serveur de dépôt de paquets

    • Si vous disposez d’une machine de test distincte de la machine de build, vous pouvez utiliser le serveur de dépôt de paquets pkg.depotd de la machine de build
    • ./helios-build onu -D transforme les paquets du build le plus récent et démarre le serveur de paquets
    • Dans l’exemple, le service écoute sur 0.0.0.0:7891
    • Le serveur continue de fonctionner jusqu’à un Control-C ou un autre mode d’arrêt
    • Sur la machine cible, vérifiez l’accès à la machine de build avec pkgrepo info -s http://genesis:7891
    • Un système Helios standard possède par défaut un seul publisher helios, qui utilise le dépôt central https://pkg.oxide.computer/helios/3/dev/
    • Sur la machine de test, ajoutez le publisher on-nightly, définissez-le comme première source de recherche et assouplissez la règle sticky du publisher helios existant
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • Selon le contexte, il peut être nécessaire de supprimer le méta-paquet entire avant la mise à jour
    • Cela peut être particulièrement vrai s’il existe des zones basées sur la brand lipkg
    • L’outil onu d’illumos standard effectue cette opération automatiquement
    • Exécutez un dry-run avec pkg update -nv pour vérifier que la mise à jour se fera vers les paquets du quick build
    • Dans l’exemple, 325 paquets sont mis à jour, et la création puis l’activation d’un nouveau boot environment ainsi que la reconstruction de la boot archive sont nécessaires
    • La version passe de la version Helios standard basée sur le numéro de commit de la branche stlouis à la version quick build 3.0.999999
    • La mise à jour réelle s’effectue avec pkg update -v ; si elle réussit, il faut redémarrer sur le nouveau boot environment
    • Après redémarrage, la configuration des publishers persiste
    • Vous pouvez ensuite répéter le flux : nouveau build, redémarrage du serveur de paquets, puis pkg update -v sur la machine de test

  • Générer uniquement les paquets, sans installation

    • ./helios-build onu -P effectue uniquement la transformation des paquets issus du quick build, sans les installer
    • Le dépôt de paquets transformés est créé dans tmp/onu/repo.redist
    • Cette méthode est utile pour inspecter le contenu du dépôt de build
    • pkgrepo info -s tmp/onu/repo.redist
    • pkgrepo list -s tmp/onu/repo.redist
    • pkg contents -t file -s tmp/onu/repo.redist '*microcode*'
    • Vous pouvez aussi conserver les fichiers de paquets pour comparer les sorties de plusieurs builds, les transférer vers un système distant ou les installer ultérieurement

Modifications et builds itératifs

  • Pour travailler sur des modifications système, il est généralement préférable de partir d’un espace de travail de build propre après un quick build
  • Pour modifier un fichier source précis et reconstruire un composant, entrez d’abord dans l’environnement de build avec bldenv
    • ./helios-build bldenv -q
    • Un nouveau shell interactif démarre, avec PATH et les autres variables correctement configurés
  • Déplacez-vous dans le répertoire du composant et exécutez une commande comme dmake -S -m serial install pour construire et installer
    • L’exemple construit la commande id dans cmd/id et l’installe dans la zone proto
  • Cette méthode d’édition et recompilation incrémentale ciblée convient pour vérifier sur des cycles courts que les changements compilent

  • L’option la plus correcte, mais lente

    • Vous pouvez reconstruire tout l’OS
    • C’est la seule procédure qui garantit, dans la mesure du possible, un résultat correct
    • Si vous rencontrez un problème inexpliqué avec une méthode incrémentale, il est recommandé de tenter d’abord un full build
    • La commande est ./helios-build build-illumos -q

  • L’option rapide, sans garantie

    • Si vous avez mis à jour les binaires de la zone proto avec dmake install, vous pouvez regénérer seulement les paquets et les installer, sans build complet
    • Depuis bldenv, allez dans $SRC/pkg et exécutez dmake install
    • Lancez ensuite le serveur de dépôt de paquets avec les paquets mis à jour, ou procédez à une installation locale

  • L’option qui manipule directement le système de fichiers

    • Un système d’exploitation étant au final constitué de fichiers dans un système de fichiers, d’autres méthodes que les outils de packaging sont possibles
    • Vous pouvez exécuter directement le binaire modifié sur le système de build, ou le copier vers un système de test avec scp ou rsync puis l’exécuter
    • Cela peut ne pas fonctionner si le binaire nécessite des changements de bibliothèque ou de noyau
    • Vous pouvez créer un nouveau boot environment et ajuster les fichiers qu’il contient
    • Un boot environment est un système de fichiers ZFS distinct qui peut être modifié, snapshoté, cloné et démarré
    • Vous pouvez utiliser beadm create, beadm mount et beadm activate
    • Vous pouvez créer une toute nouvelle image disque ou un ramdisk, puis démarrer une VM ou via PXE
    • Les outils de génération d’images propres à Helios se trouvent dans les outils image de helios-engvm
    • Ces outils peuvent inclure les paquets de quick build ou des fichiers additionnels arbitraires en modifiant le modèle d’image
    • Ils s’appuient sur l’outil amont illumos/image-builder

Archive d’image OS

  • Le processus de build des images OS pour les compute sleds Oxide génère une archive d’image
  • Cette archive contient la boot ROM et l’image ramdisk du système de fichiers racine
  • Elle contient aussi des métadonnées sous forme de fichier JSON et utilise le même format que omicron1 brand
  • Le contenu des fichiers constitue une interface engagée entre Helios et les parties d’Omicron qui doivent télécharger et installer les images OS sur les systèmes physiques de l’Oxide Rack
  • Les fichiers nécessaires à l’utilisation par Omicron incluent au minimum :
    • oxide.json : fichier d’en-tête de métadonnées contenant au minimum la clé v=1 et la clé t=os pour identifier l’image OS
    • image/rom : image de host boot ROM de 32 Mio
    • image/zfs.img : image ramdisk du système de fichiers racine de l’hôte, de taille arbitraire
  • Des fichiers supplémentaires à des fins d’ingénierie ou de diagnostic peuvent être présents
    • Par exemple : noyau compressé unix.z pour bldb ou nanobl-rs, boot archive compressée cpio.z
    • Tableau de fichiers ROM supplémentaires dont les suffixes indiquent différentes fonctions de diagnostic
  • Les fichiers supplémentaires ne font pas partie de l’interface engagée et peuvent changer à tout moment à l’avenir
  • Les logiciels qui interprètent l’archive d’image doivent ignorer les fichiers qu’ils ne reconnaissent pas

Licence

  • Le copyright appartient à Oxide Computer Company, 2026
  • Sauf indication contraire, tous les composants sont sous licence Mozilla Public License Version 2.0

À lire aussi

1 commentaires

 
GN⁺ 2024-01-30
Avis sur Hacker News

  • Je suis content que ce soit rendu public, et je compte le déployer en local pour en apprendre autant que possible
    Oxide est presque l’entreprise de rêve, à la fois pour sa stack technique et pour les personnes qui y travaillent

    • Après avoir parcouru la page d’accueil pendant une vingtaine de secondes, je me suis dit : « une intégration verticale pour acheter des serveurs on-premise ? Avec un système d’exploitation custom en plus ? Pourquoi payer un premium pour ça ? »
      Mais assez vite, ma réflexion a continué jusqu’à : « au fond, qu’est-ce qu’un système d’exploitation serveur est censé faire ? Il suffit de lancer des machines virtuelles, non ? On n’a pas forcément besoin de Linux, il suffit de pouvoir lancer des machines virtuelles Linux, non ? »
    • J’ai hâte de voir comment ça se compare à SmartOS
      J’ai pas mal investi dans SmartOS pour mon infrastructure personnelle, mais depuis l’acquisition de Joyent, son avenir m’inquiétait
      J’aimerais travailler dans une organisation assez grande pour utiliser du matériel Oxide. Ce serait formidable de ne plus avoir à bricoler avec des empilements de compatibilité façon faux IBM PC AT, des BMC et iDRAC bancals, ou des contrôleurs RAID matériels
    • Oxide est quasiment la seule entreprise où j’aimerais vraiment travailler
      Vu de l’extérieur, ça donne une impression proche de Sun, et c’est exactement le genre d’entreprise dont j’ai toujours rêvé
      Cela dit, avec une famille à charge, la structure de rémunération n’est pas tenable pour moi. Peut-être que je pourrai réaliser ce rêve quand mon enfant aura terminé l’université et que je n’aurai plus besoin de revenus aussi élevés

  • Quelqu’un peut m’expliquer ce qu’Oxide propose comme si j’avais 5 ans ? Même en regardant le site web, je ne comprends pas vraiment
    Je ne sais pas si c’est du matériel + logiciel qu’on achète pour l’utiliser on-premise, une PaaS, ou encore un autre fournisseur cloud

    • On dirait que tu te fais downvoter parce qu’il y a déjà un gros fil sur le sujet, mais ça me semble un peu injuste
      Pour aller droit au but : oui. C’est du matériel + logiciel qu’on achète pour l’utiliser on-premise
      Ce qui le distingue de la plupart des produits de cloud on-premise existants, c’est qu’il s’agit d’un fournisseur unique qui a conçu le matériel et le logiciel pour bien fonctionner ensemble. Ils rendent le logiciel open source autant que possible, d’où des annonces comme celle-ci
      La plupart des produits assemblent des offres de plusieurs fournisseurs et vendent, en pratique, de l’intégration. Oxide considère que cette approche crée de nombreux problèmes, et que son produit les résout
      Autre point : il n’y a que deux SKU. Demi-rack et rack complet seulement ; on n’achète pas à l’unité 1U, mais par rack
      Concevoir tout le rack comme une unité cohérente permet de faire des choses impossibles dans un format 1U. Il y a une blague récurrente comme quoi ils parlent toujours de ventilateurs, mais c’est vrai. Comme ils utilisent des sleds plus grands que les 1U traditionnels, ils peuvent employer de plus gros ventilateurs, qui tournent à plus faible régime et économisent de l’énergie
      C’est un choix de conception volontaire, mais il a aussi des effets secondaires. Grâce au faible régime, les serveurs sont beaucoup plus silencieux. Parmi les premiers prospects, certains ont même demandé pendant une démo : « c’est bien allumé ? »
      Le silence n’est sans doute pas la seule raison d’acheter des serveurs, mais c’est un exemple intéressant de ce qui arrive quand on repense le produit dans son ensemble plutôt que comme un simple travail d’intégration
    • C’est une solution de calcul et de stockage entièrement intégrée pour l’on-premise, qui provisionne les ressources via des API façon cloud, avec en plus un engagement envers l’open source

  • Je sais que les gens d’Oxide viennent de chez Sun, mais y a-t-il un véritable avantage technique, du point de vue de la proposition de valeur commerciale, à avoir choisi autre chose que Linux ?
    Je sais qu’illumos est techniquement supérieur à Linux sur certains points, mais je ne sais pas si cela compte vraiment pour les clients qui achètent ce produit.
    J’ai l’impression que cela ouvre une question compliquée : est-ce qu’on ne risque pas de vendre moins de machines à cause d’une idéologie ou d’un héritage ?
    Pour quelqu’un qui exploite des workloads de conteneurs Linux, le fait que ce soit fondamentalement non-Linux n’est pas une raison d’acheter, mais plutôt une raison d’hésiter. Je sais qu’on peut exécuter des binaires Linux sans modification.

    • Le produit ne dit pas quelque chose du genre : « au fait, il y a illumos à l’intérieur, et c’est pour cela que vous devriez acheter ce rack ».
      Ce n’est pas un détail du produit visible par le client, et la plupart ne sauront probablement même pas que c’est le cas.
      Ce qui importe aux clients, c’est que le rack soit efficace, fiable et adapté à leurs besoins. Ici, le choix d’illumos plutôt que Linux a été fait pour fournir cette valeur efficacement.
      Cela ne veut évidemment pas dire qu’il serait impossible de construire un produit similaire sur Linux ; nous avons simplement jugé qu’illumos convenait mieux à l’objectif.
      Cette décision a été prise avec l’équipe sous forme de RFD[1] ; il porte le numéro #26, mais il n’est pas public actuellement. Les options sérieusement étudiées étaient KVM côté Linux et bhyve côté illumos, et le document est assez long.
      Au final, il fallait choisir une voie, et nous avons choisi celle-ci. Même si je ne développe pas directement cette partie, jusqu’ici rien ne nous a donné de raison de penser que cela ait constitué un obstacle ; au contraire, il est bien possible que ce soit le bon choix.
      Je suis curieux de savoir pourquoi le fait que ce soit non-Linux serait une raison de ne pas acheter. Ce serait bien d’avoir plus d’explications. Ah, j’ai vu le commentaire ci-dessous : https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios n’est qu’un détail d’implémentation du rack, et ce n’est pas un élément visible par l’utilisateur ou les applications, contrairement à Hubris[0]. Les utilisateurs du rack provisionnent des machines virtuelles.
      La raison pour laquelle nous avons utilisé un dérivé d’illumos plutôt qu’autre chose a été un peu abordée dans le Q&A[1] au moment de la livraison du premier rack, et nous l’expliquerons de nouveau dans la discussion enregistrée[2] prévue plus tard aujourd’hui.
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • Dans l’embarqué ou les appliances, Linux peut facilement devenir un cauchemar.
      Les ingénieurs plateforme passent leurs journées à corriger des problèmes de noyau récent, de pilotes et de bibliothèques de base, et les applications réelles finissent par dépendre de tout cela.
      Ou alors on suit la voie de 99 % des fournisseurs IoT : ne jamais mettre à jour l’OS de base, et prier pour qu’aucun exploit actif ne le cible.
      C’est pourquoi beaucoup d’entreprises de taille moyenne ont beaucoup souffert du problème CentOS. Sans payer pour exploiter une installation RHEL complète, elles pouvaient rester sur une plateforme relativement stable tout en recevant des mises à jour de sécurité.
      Tous les dix ans environ, il fallait réexaminer toutes les dépendances, mais c’était beaucoup plus simple que de suivre un cycle de mises à jour d’un ou deux ans. Pour certains systèmes, la seule phase de validation prend plus de six mois, donc ce cycle est trop court.
      C’est presque un problème propre à Linux, et des alternatives comme les *BSD fournissent l’essentiel de ce qu’apporte Linux, tout en générant beaucoup moins de casse permanente.
    • Avoir du choix est sain, et on a même l’impression que l’univers se rétablit un peu après le rachat de Sun par Oracle.
      Il est difficile d’imaginer de meilleures personnes pour réunir le système Oxide en un tout cohérent.
      Aujourd’hui je suis ingénieur et je travaille uniquement avec Linux, mais l’époque où il existait un autre Unix solide capable d’exécuter des workloads à forte valeur me manque.
      Si l’on compare openvswitch sous Linux aux fonctionnalités Crossbow SDN de Solaris, je choisirais Crossbow à chaque fois.
      Cela ne veut pas dire que Linux est mauvais, mais les outils partent chacun dans leur direction, créent de la complexité, puis il faut réabstraire tout cela avec des outils encore plus complexes ; il manque cruellement une cohésion de niveau « plan directeur ».
    • Les clients exécutent par-dessus des systèmes d’exploitation virtualisés.
      Ce n’est pas très différent d’Azure Host OS, Bottlerocket ou Flatcar.
      Ce qui compte, c’est qu’ils connaissent toute la stack, qu’ils possèdent eux-mêmes une partie du code du noyau depuis l’époque de Sun, et qu’ils puissent l’ouvrir aux clients qui veulent accéder aux sources pour des évaluations de sécurité.

  • Je ne connais pas bien illumos, alors je suis allé voir la page web, et tout au début il est écrit « illumos is a Unix operating system »
    illumos est-il un vrai Unix comme macOS, ou bien un système d’exploitation de type Unix comme GNU/Linux ?

    • C’est un vrai Unix. L’explication de Wikipedia est plutôt bonne : https://en.wikipedia.org/wiki/Illumos
      Il est basé sur OpenSolaris, lui-même basé sur System V Release 4 (SVR4) et Berkeley Software Distribution (BSD). Illumos se compose du noyau, des pilotes de périphériques, des bibliothèques système et de logiciels utilitaires pour l’administration système. Ce cœur sert de base à plusieurs distributions Illumos open source, un peu comme le noyau Linux sert de base aux différentes distributions Linux.
    • Personne n’a payé pour passer les tests de certification Unix Branding de l’Open Group
      https://www.opengroup.org/openbrand/register/
      Il ne peut donc pas utiliser la marque UNIX™
      Mais à l’intérieur, il contient le noyau Unix d’AT&T et le code source de l’espace utilisateur
      PDP-11 Unix System III : https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/ut...
      IllumOS : https://github.com/illumos/illumos-gate/blob/b8169dedfa435c0...
    • Juridiquement, NetBSD non plus n’est pas un vrai Unix. Cette marque ne signifie pas ce que les gens pensent généralement
    • C’était un fork open source de Solaris sur lequel Ian Murdock travaillait chez Sun sous le nom Project Indiana, et il descend d’UNIX SVR4
    • C’est un vrai Unix. À ma connaissance, il appartient à la famille Solaris

  • Ce n’est pas que je ne soutienne pas Oxide, mais le produit est encore tellement de niche et à un stade si précoce qu’il est difficile d’imaginer de vraies entreprises en acheter avant un moment
    Ils n’ont expédié leur premier rack à leur premier client qu’à la fin de l’été dernier, et ce client était l’Idaho National Laboratory
    À ce stade, les seuls endroits capables de tenter un pari pareil semblent être, en pratique, des laboratoires nationaux

    • Deux clients ont été mentionnés lors de l’annonce d’octobre dernier : https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Les clients d’Oxide incluent l’Idaho National Laboratory et une organisation mondiale de services financiers. Des installations supplémentaires chez des entreprises du Fortune 1000 devraient être finalisées dans les prochains mois
    • Tous les produits au tout début de leur existence ressemblent à ça
      Si vous prévoyez de les lancer autrement, vous avez condamné l’entreprise avant même le lancement. Quelques-unes survivent avec de la chance, mais c’est aussi ce qui contribue à la statistique selon laquelle 9 startups sur 10 échouent
      Il faut se concentrer extrêmement fortement sur les premiers clients pour franchir le gouffre, et le marché grand public vient ensuite
    • J’aimerais qu’ils sortent un jour un produit de homelab plus petit et moins cher
      Les gens pourraient apprendre dessus, ou des startups pourraient l’essayer, ce qui pourrait plus tard se traduire par des ventes de racks ou des recrutements
    • Je travaille dans une entreprise tech récemment entrée en Bourse, et nous avons sérieusement envisagé Oxide lorsque nous évaluions l’on-premise
      La proposition passe même auprès des gens qui pensent encore « de l’on-premise… beurk »
      Cela semble offrir une expérience de type cloud sur son propre matériel
      Si seulement c’était aussi bon marché que Dell
    • Notre entreprise l’a aussi étudié, et nous avons été très impressionnés par le produit
      Le seul problème, c’est qu’il est conçu pour du calcul généraliste, alors que nous avions vraiment besoin d’options de processeurs plus rapides

  • J’aime beaucoup le fait que la documentation paraisse claire et intuitive. Personnellement, je pense que la documentation a historiquement été un domaine dans lequel la communauté illumos a eu des difficultés
    Voir parler de consolidations dans la nouvelle publication du code source me fait chaud au cœur. Cela dit, sauf si j’ai fortement mal compris l’organisation du dépôt, cela semble s’éloigner du paradigme traditionnel du gate
    J’ai quelques questions, surtout liées aux outils. Pourquoi gmake ? Il semble qu’il faudra de toute façon dmake plus tard
    Les instructions disent explicitement d’exécuter rustup avec bash : est-ce un défaut upstream, ou bien le sh local n’est-il pas entièrement compatible POSIX ?
    Comment se fait le développement en interne ? Les gens d’Oxide utilisent-ils des stations de travail illumos, ou développent-ils tous dans des machines virtuelles / via SSH sur des serveurs ?
    Pourquoi la MPL ? Pour la compatibilité avec la GPL ?

    • Je ne travaille pas directement sur helios, donc je ne peux pas répondre à tout, mais je peux répondre à une partie
      Sur la question de savoir si les gens d’Oxide utilisent des stations de travail illumos, ou développent dans des VM ou via SSH sur des serveurs, j’ai écrit ceci ici : https://news.ycombinator.com/item?id=39181727
      Cela dit, certaines personnes utilisent effectivement illumos sur leur station de travail
      À propos de la MPL, c’est ici : https://news.ycombinator.com/item?id=39181844
      Dans ce commentaire, je n’ai pas approfondi le « pourquoi », mais je vois cela comme un bon compromis dans l’espace des possibilités. C’est plus copyleft que BSD, mais moins restrictif que la GPL
    • À ma connaissance, c’est un problème upstream
      Comme la plupart des projets open source, il y a là aussi des Linuxismes/Bashismes
    • Pour des raisons historiques, dmake est utilisé pour construire le cœur du système d’exploitation, mais lorsqu’on crée de nouveaux Makefile dans d’autres consolidations, on a tendance à recommander GNU make (gmake)
      Il est largement disponible, utilisable aussi sur d’autres plateformes, et dispose de fonctionnalités plus modernes

  • C’est très bien que le logiciel soit open source, mais pourra-t-on le déployer et l’utiliser sur d’autres matériels ?
    Si, pour une raison ou une autre, une entreprise ne peut plus acheter de racks Oxide, devra-t-elle repartir de zéro pour son infrastructure, ou pourra-t-elle continuer à l’étendre autour du matériel Oxide ?

    • Il est peu probable qu’il soit immédiatement utile en dehors de notre matériel, mais sa fonction principale est de déployer des machines virtuelles.
      Si vous décidez de ne plus utiliser les racks Oxide que vous avez achetés, il suffit de déplacer les machines virtuelles vers l’infrastructure que vous aurez choisie ensuite.

  • Je suis vraiment curieux de savoir quels workloads des entreprises voudraient faire tourner sur un Unix personnalisé qui ne soit ni Linux, ni Mac, ni BSD.
    Je me réjouis de voir émerger une diversité de systèmes d’exploitation plus mature, mais je ne vois pas bien qui seraient les utilisateurs finaux ni quels besoins ils auraient.

    • Le compute provisionné sur un rack Oxide, ce sont des machines virtuelles. Nous avons porté bhyve depuis FreeBSD et ajouté la migration à chaud.
      Si le besoin se présentait, je pense qu’on pourrait aussi démarrer Windows Server.
      La raison pour laquelle nous utilisons Illumos tient aussi au fait que beaucoup de personnes viennent de Sun, Joyent, etc., donc il y a naturellement un biais dans ce sens.
      Mais il y a aussi une raison assez convaincante : ce n’est pas un PC x86 compatible IBM. Il n’y a ni BIOS, ni UEFI, ni BMC traditionnel, et tout en utilisant du x86 moderne, il semble qu’ils aient supprimé autant que possible les firmwares propriétaires et les blobs binaires.
      Chaque sled dispose d’un processeur de service et d’une racine de confiance matérielle, qui démarre directement le CPU, charge les blobs d’entraînement AMD, puis démarre le système d’exploitation.
      Il serait difficile de faire remonter de tels changements dans Linux ou BSD pour un ordinateur qu’eux seuls possèdent pour l’instant. Au final, il faudrait maintenir son propre fork downstream, et comme personne d’autre ne serait responsable de la robustesse de l’OS, il est plus logique d’utiliser le système d’exploitation qu’ils soutiennent et développent depuis des années.
    • Ce n’est pas un détail visible par l’utilisateur dans le produit.
      Les clients exécutent des machines virtuelles sur le rack ; ils ne compilent pas leurs applications pour illumos.
      Ils feront tourner, dans ces machines virtuelles, le système d’exploitation dont ils ont besoin pour atteindre leurs objectifs.
    • ZFS est natif sur illumos, et ses fonctionnalités équivalentes à la conteneurisation, entre autres, sont plutôt excellentes.
      Si l’on peut recruter suffisamment de monde, l’argument selon lequel tous les serveurs d’un cloud n’ont pas forcément besoin d’utiliser le même système d’exploitation est assez convaincant.
    • Vous ne saurez probablement même pas que ce n’est pas Linux.
      Vous n’exécutez pas votre code sur ce système d’exploitation, mais sur les machines virtuelles qu’il fournit.

  • Je me demande comment vous avez découvert Oxide au départ.
    Je suis tombé par hasard sur leur podcast, et pour moi c’est un marketing incroyable. Ils font tout sauf vendre directement le produit.
    Ce serait peut-être bien d’ajouter un court pitch à la fin de chaque épisode.
    Ils racontent des choses du genre « on a vraiment galéré à faire faire quelque chose au compilateur », puis dérivent vers des anecdotes du passé.
    J’espère quand même qu’ils continueront à en parler, et je leur souhaite de réussir.

    • On The Metal, leur podcast d’origine, était tristement célèbre pour répéter beaucoup trop souvent deux ou trois autopromotions préenregistrées, au point qu’un fan a proposé d’enregistrer lui-même une publicité pour qu’ils la diffusent.
      En revanche, Oxide and Friends tient moins du podcast traditionnel que de l’enregistrement d’un « space » en direct ou d’un appel de groupe, commencé sur Twitter et désormais organisé sur Discord.
      À mon avis, c’est un format qui se consomme mieux en y participant en direct qu’en l’écoutant seulement comme podcast. Quand on l’écoute en direct, on comprend beaucoup mieux l’ambiance de l’enregistrement.
      https://oxide.computer/podcasts/oxide-and-friends
    • Je suivais @jessfraz sur Twitter à l’époque, donc je l’ai découvert là quand Oxide a été annoncé pour la première fois.
    • Je l’ai découvert quand Pentagram a dévoilé le branding lors de la première annonce d’Oxide.

  • J’attendais ça depuis l’annonce de leur rack serveur.
    Si Oxide faisait faillite, personne ne voudrait se retrouver avec du matériel transformé en presse-papiers.

    • Pour être clair, ce « problème du presse-papiers » est très important pour nous aussi.
      Il faut garder à l’esprit que la MPL ne tient pas compte du fait qu’une copie soit publiquement disponible sur GitHub ou non.
      Je ne suis pas avocat, mais indépendamment du fait que des non-clients puissent consulter le code, il existe des obligations au titre de la MPL envers les clients.