Helios: die illumos-Distribution, die Oxide Rack antreibt

 (github.com/oxidecomputer)
1 Punkte von GN⁺ 2024-01-30 | 1 Kommentare | Auf WhatsApp teilen
  • Helios ist eine illumos-Distribution, die Oxide Rack antreibt; die Tools und Dokumentation in diesem Top-Level-Repository bündeln mehrere Software-Consolidations und steuern den Build der gesamten Distribution.
  • Die Distribution nutzt den stlouis-Branch von illumos-gate als Kern-OS und liefert überwiegend stock-illumos-Pakete mit zusätzlichen Komponenten für Oxide-Hardware sowie einigen Packaging-Anpassungen.
  • Nicht alle Komponenten-Repositories sind öffentlich; private Consolidations lassen sich mit OXIDE_STAFF=no gmake setup von Clone- und Build-Zielen ausschließen.
  • Eigene Package-Builds verwenden in einer aktuellen Helios-Umgebung rustup, gmake setup und das Rust-basierte helios-build; während der Entwicklung ist ein Quick Build möglich, der den Shadow Compiler und einige Prüfungen deaktiviert.
  • Build-Ergebnisse können in einer lokalen Boot Environment installiert, per pkg.depotd auf andere Testsysteme verteilt oder ohne Installation nur als konvertiertes Paket-Repository zur Prüfung erzeugt werden.

Rolle und Aufbau von Helios

  • Helios ist eine illumos-Distribution, die Oxide Rack antreibt.
  • Die gesamte Distribution besteht aus mehreren Software-Consolidations; die Tools und Dokumentation in diesem Top-Level-Repository steuern den Build.
  • Zu den öffentlichen Consolidations gehören:
  • Es gibt auch noch nicht veröffentlichte Consolidations:
    • amd-firmware: binäre Firmware-Blobs für AMD-CPUs, Veröffentlichung geplant
    • chelsio-t6-roms: Firmware-Blobs für Chelsio-T6-NICs, Veröffentlichung geplant
    • pilot: Low-Level-Control-Utility für Oxide-Systeme, Veröffentlichung geplant
    • dmar-report: Generator für DRAM-Margining-Berichte, Veröffentlichung geplant
  • Wer keinen Zugriff auf private Repositories der oxidecomputer-GitHub-Organisation hat, kann mit OXIDE_STAFF=no gmake setup das Klonen und Bauen noch nicht veröffentlichter Software überspringen.

Startumgebung und Ersteinrichtung

  • Das Verfahren richtet sich an Nutzer, die eigene OS-Pakete bauen und installieren wollen; wer Helios nur verwenden möchte, sollte den Ablauf zu vorgebauter Helios-Software in helios-engvm beachten.
  • Empfohlener Ausgangspunkt ist eine physische oder virtuelle Build-Maschine mit aktueller Helios-Installation.
    • Details zur Installation in virtuellen Maschinen stehen in helios-engvm.
    • Informationen zu Installationsmedien für physische x86-Systeme befinden sich im selben Repository.
  • Wenn die VM nach dem helios-engvm-Verfahren erstellt wurde, sollten die benötigten Pakete bereits installiert sein.
  • Wurde die Helios-Umgebung über den ISO-Installer oder auf anderem Weg erstellt, kann das Paket pkg:/developer/illumos-tools erforderlich sein.
    • Ob es installiert ist, lässt sich mit pkg list developer/illumos-tools prüfen.
    • Fehlt es, wird es mit pkg install installiert.
  • Es wird empfohlen, aktuelle Helios-Pakete zu verwenden; nach pkg update sind die ausgegebenen Hinweise zu prüfen.
    • Wenn die Aktualisierung meldet, dass eine neue Boot Environment erstellt wurde, diese per reboot aktivieren und danach fortfahren.
  • Rust und Cargo werden über rustup als offizielle Binaries des Rust-Projekts installiert.
    • In der offiziellen Installationsprozedur wird statt sh bash verwendet.
    • Ein Beispielbefehl ist curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash.

Repository-Klonen und helios-build

  • Auf einer Helios-Maschine wird das Repository geklont und anschließend gmake setup ausgeführt.
    • Unter tools/helios-build wird das Rust-basierte Tool helios-build gebaut.
    • Mehrere Repositories werden unter projects/ geklont.
  • Wer keinen Zugriff auf private Repositories der oxidecomputer-GitHub-Organisation hat, kann wie folgt nur öffentliche Repositories verwenden:
    • OXIDE_STAFF=no gmake setup
  • Das Tool helios-build kann beim ersten Build einige Zeit benötigen.
  • Die Ersteinrichtung klont die erwarteten Projekt-Repositories; spätere Aktionen wie Updates oder Branch-Wechsel werden jedoch nur für einige Repositories ausgeführt.
    • Welche Repositories automatisch aktualisiert werden, ist unter auto_update in config/projects.toml zu sehen.
    • Andere lokale Klone müssen wie normale Git-Repositories manuell per Branch-Wechsel und Pull verwaltet werden.

Build-Verfahren für illumos

  • Die Kern-OS-Komponenten von Helios stammen aus dem stlouis-Branch von illumos-gate.
  • Die in Helios enthaltenen Pakete sind überwiegend stock illumos, ergänzt um Oxide-Hardware-spezifische Komponenten und einige kleinere Packaging-Anpassungen.
  • helios-build stellt mehrere Wrapper bereit, die Build-Einstellungen verwalten und die illumos-Build-Tools aufrufen, um den illumos-Build zu vereinfachen.
  • Die Upstream-illumos-Dokumentation zu Building illumos behandelt die meisten Aufgaben, die von den Helios-Tools übernommen werden.
  • Während der Entwicklung kann mit folgendem Befehl ein Quick Build durchgeführt werden:
    • ./helios-build build-illumos -q
    • Der Quick Build deaktiviert den Shadow Compiler und einige Prüfungen, die für die finale Integration erforderlich sind.
  • Die Build-Zeit hängt von der CPU-Anzahl der Build-Maschine und der Leistung des lokalen Speichers ab.
  • Das vollständige Build-Log ist groß und kann zum Beispiel mit tail -F projects/illumos/log/nightly.log verfolgt werden.
  • Bei erfolgreichem Build entsteht unter projects/illumos/packages/i386 ein Paket-Repository, das anschließend auf verschiedene Arten konvertiert und installiert werden kann.

Installation und Verteilung gebauter Pakete

  • Installation auf der lokalen Build-Maschine

    • Neu gebaute Pakete lassen sich mit ./helios-build onu -t my-be-name auf der Build-Maschine installieren.
    • Dieser Befehl konvertiert und installiert die illumos-Pakete und erstellt eine neue Boot Environment mit dem per -t übergebenen Namen.
    • Die neue Boot Environment wird durch onu aktiviert; der Nutzer bootet neu, um in diese Umgebung zu wechseln.
    • Informationen zu Boot Environments stehen in beadm(8).
    • Beim Neustart sollte man möglichst an der Konsole sein, um Boot-Meldungen zu sehen und mit dem Boot Loader interagieren zu können.
    • Nach der Installation lässt sich mit pkg list -Hv system/kernel prüfen, dass das Paket system/kernel vom lokalen dateibasierten Publisher on-nightly und aus der Quick-Build-Version 3.0.999999 stammt.

  • Installation auf einer anderen Maschine über einen Paket-Repository-Server

    • Wenn es neben der Build-Maschine eine separate Testmaschine gibt, kann der Paket-Repository-Server pkg.depotd der Build-Maschine verwendet werden.
    • ./helios-build onu -D konvertiert die Pakete des jüngsten Builds und startet den Paketserver.
    • Im Beispiel wird unter 0.0.0.0:7891 bereitgestellt.
    • Der Server läuft weiter, bis er per Control-C oder auf andere Weise beendet wird.
    • Auf der Zielmaschine wird mit pkgrepo info -s http://genesis:7891 die Verbindung zur Build-Maschine geprüft.
    • Ein stock-Helios-System hat standardmäßig einen helios-Publisher, der das zentrale Repository https://pkg.oxide.computer/helios/3/dev/ verwendet.
    • Auf der Testmaschine wird der Publisher on-nightly hinzugefügt und als erstes Suchziel gesetzt; zugleich wird die Sticky-Regel des bestehenden helios-Publishers gelockert.
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • Je nach Situation muss vor dem Update möglicherweise das Meta-Paket entire entfernt werden.
    • Das kann insbesondere bei Zonen auf Basis der lipkg-Brand der Fall sein.
    • Das onu-Tool von stock illumos erledigt dies automatisch.
    • Mit pkg update -nv wird ein Dry Run ausgeführt, um zu prüfen, ob auf die Quick-Build-Pakete aktualisiert wird.
    • Im Beispiel werden 325 Pakete aktualisiert; außerdem sind das Erstellen und Aktivieren einer neuen Boot Environment sowie der Neuaufbau des Boot Archive erforderlich.
    • Die Version wechselt von der stock-Helios-Version auf Basis der Commit-Nummer des stlouis-Branches zur Quick-Build-Version 3.0.999999.
    • Das eigentliche Update erfolgt mit pkg update -v; bei Erfolg muss in die neue Boot Environment neu gestartet werden.
    • Nach dem Neustart bleiben die Publisher-Einstellungen erhalten.
    • Danach kann der Ablauf aus neuem Build, Neustart des Paketservers und pkg update -v auf der Testmaschine wiederholt werden.

  • Nur Pakete erzeugen, ohne Installation

    • ./helios-build onu -P konvertiert nur die Quick-Build-Ergebnispakete, ohne sie zu installieren.
    • Das konvertierte Paket-Repository entsteht unter tmp/onu/repo.redist.
    • Diese Methode ist nützlich, um den Inhalt des Build-Repositorys zu prüfen.
    • pkgrepo info -s tmp/onu/repo.redist
    • pkgrepo list -s tmp/onu/repo.redist
    • pkg contents -t file -s tmp/onu/repo.redist '*microcode*'
    • Paketdateien können auch aufbewahrt werden, um Outputs mehrerer Builds zu vergleichen, sie auf entfernte Systeme zu übertragen oder später zu installieren.

Änderungen und wiederholte Builds

  • Systemänderungen sollten in der Regel von einem sauberen Build-Workspace nach einem Quick Build aus begonnen werden.
  • Um eine bestimmte Quelldatei zu ändern und eine Komponente erneut zu bauen, wechselt man zunächst mit bldenv in die Build-Umgebung.
    • ./helios-build bldenv -q
    • Eine neue interaktive Shell startet, in der PATH und andere Variablen korrekt gesetzt sind.
  • Im Verzeichnis der Komponente können Befehle wie dmake -S -m serial install zum Bauen und Installieren ausgeführt werden.
    • Das Beispiel baut im Verzeichnis cmd/id den Befehl id und installiert ihn in den Proto-Bereich.
  • Diese gezielte inkrementelle Edit-and-Recompile-Methode eignet sich für kurze Zyklen, um zu prüfen, ob Änderungen kompilieren.

  • Korrekteste, aber langsamere Option

    • Das gesamte OS kann erneut gebaut werden.
    • Dieses Verfahren ist die einzige Prozedur, die im Rahmen des Möglichen korrekte Ergebnisse gewährleistet.
    • Wenn bei inkrementellen Methoden unerklärliche Probleme auftreten, sollte zuerst ein Full Build versucht werden.
    • Der Befehl lautet ./helios-build build-illumos -q.

  • Schnelle Option ohne Garantien

    • Wenn Binärdateien im Proto-Bereich per dmake install aktualisiert wurden, können nur die Pakete neu erzeugt und installiert werden, ohne den vollständigen Build auszuführen.
    • Innerhalb von bldenv wird nach $SRC/pkg gewechselt und dmake install ausgeführt.
    • Anschließend wird entweder der Paket-Repository-Server mit den aktualisierten Paketen gestartet oder die lokale Installation durchgeführt.

  • Option mit direktem Zugriff auf das Dateisystem

    • Ein Betriebssystem besteht letztlich aus Dateien im Dateisystem; daher sind auch Wege außerhalb der Packaging-Tools möglich.
    • Geänderte Binärdateien können direkt auf dem Build-System ausgeführt oder per scp oder rsync auf ein Testsystem kopiert und dort ausgeführt werden.
    • Benötigt die Binärdatei Änderungen an Bibliotheken oder am Kernel, funktioniert das möglicherweise nicht.
    • Es kann eine neue Boot Environment erstellt und die darin enthaltenen Dateien angepasst werden.
    • Eine Boot Environment ist ein separates ZFS-Dateisystem, das geändert, snapshotiert, geklont und gebootet werden kann.
    • beadm create, beadm mount und beadm activate können verwendet werden.
    • Es kann ein komplett neues Disk-Image oder eine Ramdisk erstellt und per VM oder PXE gebootet werden.
    • Helios-spezifische Image-Erstellungstools befinden sich in den Image-Tools von helios-engvm.
    • Diese Tools können Quick-Build-Pakete oder beliebige zusätzliche Dateien über Änderungen an Image-Templates einbinden.
    • Grundlage ist der Upstream-illumos/image-builder.

OS-Image-Archiv

  • Beim Bauen von OS-Images für Oxide Compute Sleds wird ein Image-Archiv erzeugt.
  • Dieses Archiv enthält das Boot-ROM und das Ramdisk-Image des Root File System.
  • Es enthält außerdem Metadaten in JSON-Dateien und verwendet ein Format wie die omicron1-Brand.
  • Der Dateiinhalt ist ein committed interface zwischen Helios und Teilen von Omicron, die OS-Images auf physische Systeme des Oxide Rack herunterladen und installieren müssen.
  • Die für die Nutzung durch Omicron erforderlichen Dateien umfassen mindestens:
    • oxide.json: Metadaten-Headerdatei mit mindestens dem Schlüssel v=1 und dem Schlüssel t=os zur Identifikation des OS-Images
    • image/rom: 32-MiB-Host-Boot-ROM-Image
    • image/zfs.img: Host-Root-File-System-Ramdisk-Image beliebiger Größe
  • Es kann zusätzliche Dateien für Engineering- oder Diagnosezwecke geben.
    • Beispiele: ein komprimierter Kernel unix.z für bldb oder nanobl-rs, ein komprimiertes Boot Archive cpio.z
    • ein Array zusätzlicher ROM-Dateien mit Suffixen, die unterschiedliche Diagnosefunktionen anzeigen
  • Zusätzliche Dateien sind kein committed interface und können sich künftig jederzeit ändern.
  • Software, die Image-Archive interpretiert, sollte nicht erkannte Dateien ignorieren.

Lizenz

  • Das Copyright liegt bei 2026 Oxide Computer Company.
  • Soweit nicht anders angegeben, sind alle Komponenten unter der Mozilla Public License Version 2.0 lizenziert.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-30
Meinungen auf Hacker News

  • Schön, dass das veröffentlicht wurde; ich will es lokal deployen und so viel wie möglich daraus lernen.
    Oxide ist, sowohl was den Tech-Stack als auch die Menschen dort angeht, fast so etwas wie ein Traumunternehmen.

    • Nachdem ich die Homepage etwa 20 Sekunden überflogen hatte, dachte ich: „Ist das vertikale Integration für den Kauf von On-Premises-Servern? Sogar mit eigenem Betriebssystem? Warum sollte man dafür einen Aufpreis zahlen?“
      Kurz darauf ging der Gedanke aber weiter: „Was macht ein Server-Betriebssystem überhaupt? Reicht es nicht, einfach virtuelle Maschinen zu starten? Braucht man wirklich Linux, oder reicht es, Linux-VMs ausführen zu können?“
    • Ich bin gespannt, wie es im Vergleich zu SmartOS abschneidet.
      In meiner privaten Infrastruktur habe ich ziemlich viel in SmartOS investiert, aber nach der Übernahme von Joyent machte ich mir Sorgen um die Zukunft.
      Ich wünschte, ich würde in einer Organisation arbeiten, die groß genug ist, um Oxide-Hardware einzusetzen. Es wäre großartig, nicht mehr an Pseudo-IBM-PC-AT-Kompatibilitätskonstrukten, holprigen BMCs und iDRACs oder Hardware-RAID-Controllern herumfummeln zu müssen.
    • Oxide ist wirklich fast das einzige Unternehmen, bei dem ich gern arbeiten würde.
      Von außen wirkt es ähnlich wie Sun, und genau von so einem Unternehmen habe ich immer geträumt.
      Allerdings kann ich mir das mit Familie, für die ich sorgen muss, wegen der Gehaltsstruktur nicht leisten. Vielleicht kann ich mir diesen Traum erfüllen, wenn mein Kind mit dem Studium fertig ist und ich kein so hohes Einkommen mehr brauche.

  • Kann mir jemand erklären, was Oxide anbietet, als wäre ich fünf? Auf der Website bekomme ich kein Gefühl dafür.
    Ich weiß nicht, ob es Hardware+Software ist, die man kauft und on-premises betreibt, ob es PaaS ist oder ein weiterer Cloud-Anbieter.

    • Es scheint Downvotes zu geben, weil es dazu schon einen großen Thread gibt, aber das wirkt etwas unfair.
      Kurz gesagt: Ja. Es ist Hardware+Software, die man kauft und on-premises betreibt.
      Der Unterschied zu den meisten bestehenden On-Premises-Cloud-Produkten besteht darin, dass es ein einzelner Anbieter ist, der Hardware und Software so entwickelt, dass sie gut zusammen funktionieren. Die Software soll, soweit möglich, Open Source sein, deshalb gibt es auch solche Ankündigungen.
      Die meisten Produkte bündeln Komponenten mehrerer Anbieter und verkaufen im Grunde Integration. Oxide ist der Ansicht, dass dieser Ansatz mehrere Probleme verursacht und dass das eigene Produkt diese löst.
      Ein weiterer Punkt ist, dass es nur zwei SKUs gibt: Half Rack und Full Rack. Man kauft nicht in 1U-Einheiten, sondern rackweise.
      Wenn man ein ganzes Rack als eine zusammenhängende Einheit entwirft, kann man Dinge tun, die im 1U-Formfaktor nicht möglich sind. Es gibt den Scherz, dass sie ständig über Lüfter reden, aber es stimmt. Weil sie größere Sleds als traditionelle 1U-Server verwenden, können sie größere Lüfter einsetzen und diese mit niedrigerer Drehzahl laufen lassen, was Strom spart.
      Das ist eine bewusste Designentscheidung, hat aber auch Nebeneffekte. Dank der niedrigen Drehzahl sind die Server deutlich leiser. Unter den frühen potenziellen Kunden gab es sogar jemanden, der während einer Demo fragte: „Ist das Ding wirklich eingeschaltet?“
      Man kauft Server zwar nicht nur wegen der Lautstärke, aber es ist ein interessantes Beispiel dafür, was entsteht, wenn man das Produkt nicht einfach als Integrationsarbeit, sondern als Ganzes neu denkt.
    • Es ist eine vollständig integrierte Compute- und Storage-Lösung für On-Premises, bei der Ressourcen über Cloud-artige APIs provisioniert werden, zusammen mit einem Bekenntnis zu Open Source.

  • Ich weiß, dass die Leute bei Oxide von Sun kommen, aber gibt es aus Sicht des geschäftlichen Wertversprechens einen echten technischen Vorteil darin, sich für etwas anderes als Linux zu entscheiden?
    Ich weiß, in welchen Punkten illumos Linux technisch überlegen ist, aber ich bin mir nicht sicher, ob das für die Kunden, die das kaufen, tatsächlich wichtig ist.
    Ich frage mich, ob man damit nicht ein kompliziertes Fass aufmacht, das einen aus ideologischen oder traditionellen Gründen daran hindert, mehr Computer zu verkaufen.
    Aus Sicht von jemandem, der Linux-Container-Workloads betreibt, ist die Tatsache, dass das hier im Kern nicht Linux ist, kein Kaufgrund, sondern eher ein Grund, beim Kauf zu zögern. Ich weiß, dass es Linux-Binaries unverändert ausführen kann.

    • Beim Produkt sagen wir nicht sinngemäß: „Übrigens, innen läuft illumos, und deshalb sollten Sie dieses Rack kaufen.“
      Das ist kein Produktdetail, das dem Kunden gegenüber sichtbar ist, und die meisten werden vermutlich nicht einmal davon wissen.
      Was Kunden interessiert, ist, ob das Rack effizient und stabil ist und zu ihren Anforderungen passt. Dass hier illumos statt Linux gewählt wurde, war eine Entscheidung, um diesen Nutzen effektiv bereitzustellen.
      Natürlich heißt das nicht, dass man ein ähnliches Produkt nicht auf Linux aufbauen könnte; wir sind nur zu dem Schluss gekommen, dass illumos für den Zweck besser passt.
      Diese Entscheidung haben wir im Team in Form eines RFD[1] getroffen; es trägt zwar die Nummer #26, ist derzeit aber nicht öffentlich. Die ernsthaft geprüften Optionen waren KVM unter Linux und bhyve unter illumos, und es ist ein ziemlich langes Dokument.
      Am Ende mussten wir uns für einen Weg entscheiden, und wir haben diesen gewählt. Ich entwickle diesen Teil nicht selbst, aber bisher gibt es keinen Grund zu glauben, dass er ein Hindernis gewesen wäre; im Gegenteil, es dürfte eher die richtige Wahl gewesen sein.
      Mich würde interessieren, warum der Nicht-Linux-Aspekt ein Kaufhindernis sein sollte. Eine nähere Erklärung wäre hilfreich. Ah, ich habe den Kommentar weiter unten gesehen: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios ist lediglich ein Implementierungsdetail des Racks und, ähnlich wie Hubris[0], nichts, was für Nutzer oder Anwendungen sichtbar wäre. Rack-Nutzer provisionieren virtuelle Maschinen.
      Warum wir ein illumos-Derivat statt etwas anderem verwendet haben, wurde in der Q&A[1] zur Auslieferung des ersten Racks ein wenig behandelt, und wir werden es auch in der aufgezeichneten Diskussion[2], die später heute stattfindet, noch einmal erklären.
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • Im Embedded- oder Appliance-Bereich wird Linux schnell zum Albtraum.
      Plattform-Engineers verbringen ihre Tage damit, Probleme mit aktuellen Kerneln, Treibern und zentralen Libraries zu beheben, und die eigentliche Anwendung hängt dann davon ab.
      Oder man geht den Weg von 99 % der IoT-Anbieter: das Basissystem nie aktualisieren und hoffen, dass es keine aktiven Exploits gibt, die genau darauf abzielen.
      Deshalb haben viele mittelständische Unternehmen dem CentOS-Problem hinterhergetrauert. Denn ohne für eine vollständige RHEL-Installation zahlen zu müssen, konnten sie auf einer relativ stabilen Plattform bleiben und trotzdem Sicherheitsupdates erhalten.
      Etwa alle zehn Jahre musste man zwar alle Abhängigkeiten neu bewerten, aber das ist viel einfacher, als einem Update-Zyklus von ein bis zwei Jahren zu folgen. Bei manchen Systemen dauert allein die Validierung mehr als sechs Monate, dafür ist dieser Zyklus zu kurz.
      Das ist fast schon ein Linux-spezifisches Problem; Alternativen wie *BSD bieten das meiste von dem, was Linux bietet, verursachen aber deutlich weniger dieser ständigen Brüche.
    • Dass es Wahlmöglichkeiten gibt, ist gesund, und es fühlt sich fast so an, als würde sich das Universum nach Oracles Kauf von Sun ein Stück weit erholen.
      Es ist schwer, sich bessere Leute vorzustellen, um die Oxide-Systeme zusammenzuführen.
      Heute bin ich ein Engineer, der nur mit Linux arbeitet, aber ich vermisse die Zeit, als es noch ein weiteres starkes Unix gab, auf dem man hochwertige Workloads betreiben konnte.
      Wenn man Linux’ openvswitch mit den Crossbow-SDN-Funktionen von Solaris vergleicht, würde ich jederzeit Crossbow wählen.
      Das heißt nicht, dass Linux falsch wäre, aber die Tools gehen jeweils ihren eigenen Weg und erzeugen Komplexität, die man dann mit noch komplexeren Tools wieder abstrahieren muss; es fehlt deutlich an Kohärenz auf der Ebene eines „Masterplans“.
    • Kunden führen darauf virtualisierte Betriebssysteme aus.
      Das unterscheidet sich nicht wesentlich von Dingen wie Azure Host OS, Bottlerocket oder Flatcar.
      Wichtig ist, dass sie den gesamten Stack kennen, Teile des Kernel-Codes seit Sun-Zeiten selbst besitzen und ihn Kunden, die wegen Sicherheitsbewertungen Zugriff auf den Source Code wünschen, offenlegen können.

  • Ich kenne mich mit illumos nicht gut aus und habe mir die Webseite angesehen; gleich am Anfang steht dort: „illumos is a Unix operating system“.
    Ist illumos wie macOS ein echtes Unix, oder eher ein Unix-artiges Betriebssystem wie GNU/Linux?

    • Es ist echtes Unix. Die Wikipedia-Erklärung ist ziemlich gut: https://en.wikipedia.org/wiki/Illumos
      Es basiert auf OpenSolaris, und OpenSolaris basiert auf System V Release 4 (SVR4) und der Berkeley Software Distribution (BSD). Illumos besteht aus dem Kernel, Gerätetreibern, Systembibliotheken und Utility-Software für die Systemverwaltung. Dieser Kern bildet die Grundlage für mehrere Open-Source-Illumos-Distributionen, ähnlich wie der Linux-Kernel die Grundlage für verschiedene Linux-Distributionen bildet.
    • Niemand hat dafür bezahlt, die Unix-Branding-Zertifizierungstests der Open Group zu bestehen.
      https://www.opengroup.org/openbrand/register/
      Deshalb darf die Marke UNIX™ nicht verwendet werden.
      Im Inneren stecken aber Kernel- und Userspace-Quellen von AT&T Unix.
      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...
    • Rechtlich gesehen ist auch NetBSD kein echtes Unix. Diese Marke bedeutet nicht das, was die Leute darunter verstehen.
    • Es war ein Open-Source-Fork von Solaris, an dem Ian Murdock bei Sun unter dem Namen Project Indiana gearbeitet hat, und stammt von UNIX SVR4 ab.
    • Es ist echtes Unix. Soweit ich weiß, gehört es zur Solaris-Familie.

  • Ich will Oxide nicht schlechtreden, aber das Produkt ist noch so nischenhaft und in einem so frühen Stadium, dass ich mir kaum vorstellen kann, dass echte Unternehmen es in nächster Zeit kaufen werden.
    Erst Ende letzten Sommers haben sie das erste Rack an den ersten Kunden ausgeliefert, und dieser Kunde war das Idaho National Laboratory.
    Im Moment wirken staatliche Forschungseinrichtungen im Grunde wie die einzigen Orte, die so eine Wette eingehen können.

    • Bei der Ankündigung im vergangenen Oktober wurden zwei Kunden genannt: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Zu den Oxide-Kunden gehören das Idaho National Laboratory und eine globale Finanzdienstleistungsorganisation. Weitere Installationen bei Fortune-1000-Unternehmen sollen in den kommenden Monaten abgeschlossen werden.
    • So sehen alle Produkte ganz am Anfang ihrer Existenz aus.
      Wenn man plant, auf andere Weise zu launchen, hat man das Unternehmen schon vor dem Launch ruiniert. Einige wenige überleben mit Glück, aber genau das trägt zu der Statistik bei, dass 9 von 10 Startups scheitern.
      Man muss sich extrem auf die ersten Kundengruppen konzentrieren, um den Chasm zu überwinden; danach kommt der Massenmarkt.
    • Ich hoffe, dass sie irgendwann auch ein kleineres und günstigeres Homelab-Produkt herausbringen.
      Leute könnten damit lernen oder Startups es ausprobieren, was später zu Rack-Verkäufen oder Einstellungen führen könnte.
    • Ich arbeite bei einem kürzlich börsennotierten Technologieunternehmen, und wir haben Oxide ernsthaft in Betracht gezogen, als wir On-Premises evaluiert haben.
      Das Angebot zieht sogar bei Leuten, die immer noch denken: „On-Premises … igitt“.
      Es scheint eine Cloud-ähnliche Erfahrung auf eigener Hardware zu bieten.
      Wenn es nur so günstig wie Dell gewesen wäre.
    • Unser Unternehmen hat es ebenfalls geprüft, und das Produkt hat uns sehr beeindruckt.
      Das einzige Problem war, dass es für General-Purpose-Compute gebaut ist, während wir wirklich Optionen mit schnelleren Prozessoren gebraucht hätten.

  • Mir gefällt wirklich, dass die Dokumentation klar und intuitiv wirkt. Persönlich denke ich, dass Dokumentation historisch ein Bereich war, mit dem die illumos-Community zu kämpfen hatte.
    In einem neuen Source-Release von consolidations zu lesen, fühlt sich schön vertraut an. Allerdings scheint es, sofern ich die Repository-Struktur nicht grob missverstehe, in eine andere Richtung zu gehen als das traditionelle Gate-Paradigma.
    Ich habe ein paar Fragen, vor allem zu den Tools. Warum gmake? dmake scheint später ohnehin nötig zu sein.
    In der Anleitung wird ausdrücklich gesagt, dass rustup mit bash ausgeführt werden soll; ist das ein Upstream-Defekt, oder ist das lokale sh nicht vollständig POSIX-kompatibel?
    Wie läuft die interne Entwicklung ab? Verwenden die Oxide-Leute illumos-Workstations, oder entwickeln alle in virtuellen Maschinen beziehungsweise per SSH auf Servern?
    Warum MPL? Wegen GPL-Kompatibilität?

    • Ich arbeite nicht direkt an helios und kann daher nicht alles beantworten, aber ein paar Dinge schon.
      Dazu, ob Oxide-Leute illumos-Workstations verwenden oder in VMs bzw. per SSH auf Servern entwickeln, habe ich hier etwas geschrieben: https://news.ycombinator.com/item?id=39181727
      Es gibt allerdings tatsächlich Leute, die illumos auf Workstations nutzen.
      Zur MPL steht hier etwas: https://news.ycombinator.com/item?id=39181844
      In diesem Kommentar bin ich auf das „Warum“ nicht ausführlich eingegangen, aber ich sehe sie als guten Kompromiss im Möglichkeitsraum: stärker copyleft-orientiert als BSD, aber weniger restriktiv als die GPL.
    • Soweit ich weiß, ist das ein Upstream-Problem.
      Wie die meisten Open-Source-Projekte gibt es auch dort Linuxisms/Bashisms.
    • Aus historischen Gründen wird beim Build des Kernbetriebssystems dmake verwendet, aber wenn man in einer anderen consolidation neue Makefiles erstellt, empfiehlt man eher GNU make (gmake).
      Es ist breit verfügbar, funktioniert auch auf anderen Plattformen und hat modernere Funktionen.

  • Dass die Software Open Source ist, ist großartig, aber kann man sie auf anderer Hardware deployen und nutzen?
    Wenn ein Unternehmen aus irgendeinem Grund keine Oxide-Racks mehr kaufen kann: Muss es seine Infrastruktur von Grund auf neu aufbauen, oder kann es weiter rund um Oxide-Hardware skalieren?

    • Die Wahrscheinlichkeit, dass sie außerhalb unserer Hardware unmittelbar nützlich ist, ist nicht besonders hoch; die Hauptfunktion ist aber das Bereitstellen virtueller Maschinen.
      Wenn man sich entscheidet, ein gekauftes Oxide-Rack nicht mehr zu nutzen, kann man die virtuellen Maschinen auf die anschließend gewählte Infrastruktur verschieben.

  • Ich bin wirklich neugierig, welche Workloads Unternehmen auf einem Custom Unix ausführen wollen, das nicht Linux/Mac/BSD ist.
    Ich begrüße es, wenn eine ausgereiftere Betriebssystemvielfalt entsteht, aber ich habe kein Gefühl dafür, wer die Endnutzer sind und welche Anforderungen sie haben.

    • Die Compute-Ressourcen, die auf einem Oxide-Rack provisioniert werden, sind virtuelle Maschinen. Wir haben bhyve von FreeBSD portiert und auch Live-Migration hinzugefügt.
      Wenn es nötig ist, dürfte sich wohl auch Windows Server booten lassen.
      Dass Illumos verwendet wird, liegt auch daran, dass viele Leute von Sun, Joyent usw. kommen und es daher eine natürliche Voreingenommenheit gibt.
      Aber es gibt auch einen ziemlich überzeugenden Grund: Das ist kein IBM-kompatibler x86-PC. Es gibt kein BIOS, kein UEFI und kein traditionelles BMC; trotz moderner x86-Hardware scheint man proprietäre Firmware und binäre Blobs so weit wie möglich entfernt zu haben.
      Jeder Sled hat einen Service-Prozessor und eine Hardware Root of Trust; diese booten die CPU direkt, laden den AMD-Training-Blob und starten danach das Betriebssystem.
      Solche Änderungen für einen Computer, den derzeit nur sie haben, in Linux oder BSD upstream zu bekommen, wäre wohl schwierig. Am Ende müsste man einen eigenen Downstream-Fork pflegen, und wenn es ohnehin niemanden sonst gibt, der Verantwortung für die Robustheit des Betriebssystems übernimmt, ist die Entscheidung naheliegend, das Betriebssystem zu nutzen, das man seit Jahren unterstützt und weiterentwickelt.
    • Das ist kein Detail, das Nutzer im Produkt sehen.
      Kunden führen virtuelle Maschinen auf dem Rack aus, sie bauen keine Anwendungen für illumos.
      In diesen virtuellen Maschinen läuft dann das Betriebssystem, das sie zum Erreichen ihrer Ziele brauchen.
    • ZFS ist in illumos nativ, und auch die Funktionen, die Containerisierung entsprechen, sind ziemlich gut.
      Wenn man genug Leute einstellen kann, ist auch das Argument überzeugend, dass die Server einer Cloud nicht zwingend alle dasselbe Betriebssystem haben müssen.
    • Man wird vermutlich nicht einmal merken, dass es nicht Linux ist.
      Man führt seinen Code nicht auf diesem Betriebssystem aus, sondern auf virtuellen Maschinen, die dieses Betriebssystem bereitstellt.

  • Ich frage mich, wie ihr ursprünglich auf Oxide aufmerksam geworden seid.
    Ich bin irgendwie bei ihrem Podcast gelandet, und für mich wirkt das wie enormes Marketing. Sie machen alles, außer das Produkt direkt zu verkaufen.
    Ein kurzer Pitch am Ende jeder Episode könnte auch gut sein.
    Sie erzählen etwa: „Es war wirklich schwierig, den Compiler dazu zu bringen, etwas zu tun“, und schweifen dann in alte Geschichten ab.
    Trotzdem hoffe ich, dass sie weiter erzählen, und wünsche ihnen Erfolg.

    • On The Metal, der ursprüngliche Podcast, war berüchtigt dafür, zwei oder drei vorab aufgezeichnete Eigenwerbungen übermäßig oft zu wiederholen, so sehr, dass ein Fan sogar eigene Werbespots aufnahm und darum bat, sie abzuspielen.
      Oxide and Friends dagegen ist weniger ein klassischer Podcast als vielmehr die Aufnahme eines Live-„Spaces“ oder Gruppenanrufs, der auf Twitter begann und heute auf Discord stattfindet.
      Meiner Meinung nach funktioniert das Format am besten, wenn man live teilnimmt, statt es nur als Podcast zu hören. Wenn man live dabei ist, versteht man die Stimmung der Aufnahme viel besser.
      https://oxide.computer/podcasts/oxide-and-friends
    • Ich folgte früher @jessfraz auf Twitter und habe so davon erfahren, als Oxide erstmals angekündigt wurde.
    • Ich habe davon erfahren, als Pentagram beim ersten Launch von Oxide das Branding vorgestellt hat.

  • Darauf habe ich mich gefreut, seit sie das Server-Rack angekündigt haben.
    Wenn Oxide scheitert, will schließlich niemand Geräte haben, die zu Briefbeschwerern geworden sind.

    • Um es klar zu sagen: Dieses „Briefbeschwerer-Problem“ ist auch für uns sehr wichtig.
      Man sollte im Hinterkopf behalten, dass es bei der MPL nicht darauf ankommt, ob eine Kopie öffentlich auf GitHub liegt.
      Ich bin kein Anwalt, aber gegenüber Kunden bestehen nach der MPL Verpflichtungen, unabhängig davon, ob Nichtkunden den Code einsehen können.