Helios: la distribución illumos que impulsa Oxide Rack

 (github.com/oxidecomputer)
1 puntos por GN⁺ 2024-01-30 | 1 comentarios | Compartir por WhatsApp
  • Helios es la distribución illumos que impulsa Oxide Rack, y las herramientas y documentación de este repositorio de nivel superior agrupan varias consolidaciones de software para gestionar la compilación de toda la distribución
  • La distribución usa la rama stlouis de illumos-gate como sistema operativo base y ofrece principalmente paquetes de illumos stock con componentes adicionales para el hardware de Oxide y algunas transformaciones de empaquetado
  • No todos los repositorios de componentes están públicos, y las consolidaciones privadas pueden excluirse del clon y la compilación con OXIDE_STAFF=no gmake setup
  • La compilación de paquetes propios usa un entorno Helios reciente con rustup, gmake setup y helios-build basado en Rust; durante el desarrollo es posible hacer una quick build desactivando el shadow compiler y algunas verificaciones
  • Los resultados de la compilación pueden instalarse en un entorno de arranque local, publicarse a otros sistemas de prueba con pkg.depotd, o bien generar solo el repositorio de paquetes transformado para inspeccionarlo sin instalar

Rol y composición de Helios

  • Helios es una distribución illumos que impulsa Oxide Rack
  • La distribución completa está compuesta por varias consolidaciones de software, y las herramientas y la documentación de este repositorio de nivel superior dirigen la compilación
  • Las consolidaciones públicas incluyen lo siguiente
  • También hay consolidaciones que todavía no se han publicado
    • amd-firmware: blobs binarios de firmware para CPU AMD, se publicarán más adelante
    • chelsio-t6-roms: blobs de firmware para NIC Chelsio T6, se publicarán más adelante
    • pilot: utilidad de control de bajo nivel para sistemas Oxide, se publicará más adelante
    • dmar-report: generador de reportes de margining de DRAM, se publicará más adelante
  • Si no se tiene acceso a repositorios privados, se puede omitir el clon y la compilación del software aún no publicado con OXIDE_STAFF=no gmake setup

Entorno inicial y configuración básica

  • Este procedimiento es para quienes quieran compilar e instalar sus propios paquetes del sistema operativo; si solo se quiere usar Helios, el flujo es consultar la información del software Helios precompilado en helios-engvm
  • El punto de partida recomendado es una máquina de compilación física o virtual con la versión más reciente de Helios instalada
    • Los detalles de instalación para máquinas virtuales están en helios-engvm
    • La información sobre medios de instalación para sistemas físicos x86 también está en ese mismo repositorio
  • Si se creó la VM con el procedimiento de helios-engvm, los paquetes necesarios ya deberían estar instalados
  • Si el entorno Helios se creó con el instalador ISO u otro método, puede ser necesario el paquete pkg:/developer/illumos-tools
    • La instalación puede verificarse con pkg list developer/illumos-tools
    • Si falta, se instala con pkg install
  • Conviene usar los paquetes Helios más recientes y revisar las instrucciones que aparecen tras ejecutar pkg update
    • Si la actualización indica que creó un nuevo boot environment, hay que activarlo con reboot antes de continuar
  • Rust y Cargo se instalan desde los binarios oficiales del proyecto Rust usando rustup
    • En el procedimiento oficial de instalación se usa bash en lugar de sh
    • Un comando de ejemplo es curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

Clonado de repositorios y helios-build

  • En una máquina Helios, se clona el repositorio y luego se ejecuta gmake setup
    • Se compila la herramienta helios-build basada en Rust desde tools/helios-build
    • Varios repositorios se clonan dentro de projects/
  • Si no se tiene acceso a los repositorios privados de la organización de GitHub oxidecomputer, se puede hacer que solo use repositorios públicos de esta forma
    • OXIDE_STAFF=no gmake setup
  • La herramienta helios-build puede tardar en la primera compilación
  • La fase de configuración inicial clona los repositorios del proyecto esperados, pero operaciones posteriores como actualizaciones o cambios de rama solo se aplican a algunos repositorios
    • Qué repositorios se actualizan automáticamente puede verse en auto_update dentro de config/projects.toml
    • Los demás clones locales deben manejarse manualmente, como repositorios Git normales, para cambiar de rama y hacer pull

Forma de compilación de illumos

  • Los componentes del sistema operativo base de Helios provienen de la rama stlouis de illumos-gate
  • La mayoría de los paquetes incluidos en un sistema Helios son illumos stock con componentes adicionales para hardware de Oxide y algunas transformaciones menores de empaquetado
  • helios-build gestiona la configuración de compilación y ofrece varios wrappers que invocan las herramientas de compilación de illumos para facilitar el proceso
  • La documentación upstream de illumos, Building illumos, cubre gran parte de lo que las herramientas de Helios hacen automáticamente
  • Durante el desarrollo, se puede hacer una quick build con el siguiente comando
    • ./helios-build build-illumos -q
    • La quick build desactiva el shadow compiler y algunas verificaciones requeridas en la integración final
  • El tiempo de compilación depende del número de CPU de la máquina de compilación y del rendimiento del almacenamiento local
  • El log completo de compilación es grande; por ejemplo, puede verse con tail -F projects/illumos/log/nightly.log
  • Si la compilación tiene éxito, se crea un repositorio de paquetes en projects/illumos/packages/i386, que luego puede transformarse o instalarse de varias maneras

Instalación y distribución de los paquetes compilados

  • Instalar en la máquina de compilación local

    • Los paquetes recién compilados pueden instalarse en la máquina de compilación con ./helios-build onu -t my-be-name
    • Este comando transforma e instala los paquetes de illumos y crea un nuevo Boot Environment con el nombre pasado en -t
    • El nuevo boot environment queda activado por onu, y el usuario entra en él tras reiniciar
    • Para más información sobre boot environments, ver beadm(8)
    • Al reiniciar, conviene estar en la consola para ver los mensajes de arranque e interactuar con el boot loader si hace falta
    • Tras la instalación, pkg list -Hv system/kernel permite confirmar que el paquete system/kernel proviene del publisher local basado en archivos on-nightly y de la versión de quick build 3.0.999999

  • Instalar en otra máquina usando un servidor de repositorio de paquetes

    • Si se tiene una máquina de prueba separada de la de compilación, puede usarse el servidor de repositorio de paquetes pkg.depotd de la máquina de compilación
    • ./helios-build onu -D transforma los paquetes de la compilación más reciente e inicia el servidor de paquetes
    • En el ejemplo, el servicio se publica en 0.0.0.0:7891
    • El servidor sigue ejecutándose hasta que se detiene con Control-C u otro método
    • En la máquina de destino, se puede verificar la conectividad con la máquina de compilación usando pkgrepo info -s http://genesis:7891
    • Un sistema Helios stock tiene por defecto un solo publisher, helios, que usa el repositorio central https://pkg.oxide.computer/helios/3/dev/
    • En la máquina de prueba, se agrega el publisher on-nightly, se configura como primera opción de búsqueda y se relaja la regla sticky del publisher helios existente
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • Según el caso, puede ser necesario eliminar el metapaquete entire antes de actualizar
    • Esto puede aplicar especialmente si hay zonas basadas en la brand lipkg
    • La herramienta onu de illumos stock hace esto automáticamente
    • Con pkg update -nv se puede hacer una ejecución de prueba para confirmar que se actualizará a los paquetes de quick build
    • En el ejemplo, se actualizan 325 paquetes, y hace falta crear y activar un nuevo boot environment, además de reconstruir el boot archive
    • La versión cambia de la versión stock de Helios basada en el número de commit de la rama stlouis a la versión de quick build 3.0.999999
    • La actualización real se hace con pkg update -v, y si tiene éxito hay que reiniciar en el nuevo boot environment
    • Después del reinicio, la configuración de publishers permanece
    • A partir de ahí, se puede repetir el flujo de nueva compilación, reinicio del servidor de paquetes y pkg update -v en la máquina de prueba

  • Generar solo paquetes sin instalar

    • ./helios-build onu -P solo realiza la transformación del resultado de quick build sin instalarlo
    • El repositorio de paquetes transformado se crea en tmp/onu/repo.redist
    • Este método es útil para inspeccionar el contenido del repositorio generado
    • pkgrepo info -s tmp/onu/repo.redist
    • pkgrepo list -s tmp/onu/repo.redist
    • pkg contents -t file -s tmp/onu/repo.redist '*microcode*'
    • También se pueden conservar los archivos de paquetes para comparar salidas de varias compilaciones, transferirlos a sistemas remotos o usarlos para una instalación posterior

Cambios y compilaciones iterativas

  • Al hacer cambios en el sistema, por lo general conviene empezar desde un workspace de compilación limpio después de una quick build
  • Para modificar archivos fuente específicos y recompilar componentes, primero se entra al entorno de compilación con bldenv
    • ./helios-build bldenv -q
    • Se inicia un nuevo shell interactivo con PATH y otras variables correctamente configuradas
  • Luego se puede ir al directorio del componente y compilar e instalar con comandos como dmake -S -m serial install
    • El ejemplo compila el comando id desde cmd/id y lo instala en el área proto
  • Este enfoque incremental y dirigido de editar y recompilar sirve para confirmar en ciclos cortos que los cambios compilan

  • La opción más correcta, pero más lenta

    • Se puede volver a compilar todo el sistema operativo
    • Este proceso es el único que garantiza el resultado correcto en la medida de lo posible
    • Si aparecen problemas inexplicables con métodos incrementales, conviene probar primero una compilación completa
    • El comando es ./helios-build build-illumos -q

  • La opción rápida, pero sin garantías

    • Si dmake install actualizó binarios en el área proto, se pueden regenerar e instalar paquetes sin volver a compilar todo
    • Dentro de bldenv, se va a $SRC/pkg y se ejecuta dmake install
    • Después se puede iniciar un servidor de repositorio de paquetes con los paquetes actualizados o hacer una instalación local

  • La opción de trabajar directamente con el sistema de archivos

    • Al final, el sistema operativo son archivos dentro de un sistema de archivos, así que también son posibles enfoques fuera de las herramientas de empaquetado
    • Se puede ejecutar el binario modificado directamente en el sistema de compilación o copiarlo al sistema de prueba con scp o rsync para ejecutarlo allí
    • Si el binario necesita cambios en bibliotecas o en el kernel, puede que no funcione
    • También se puede crear un nuevo boot environment y ajustar los archivos dentro de él
    • Un boot environment es un sistema de archivos ZFS independiente que puede modificarse, tomarse en snapshot, clonarse y arrancarse
    • Se pueden usar beadm create, beadm mount y beadm activate
    • También se puede crear una imagen de disco o ramdisk completamente nueva y arrancarla por VM o PXE
    • Las herramientas específicas de Helios para generar imágenes están en las herramientas de imagen de helios-engvm
    • Estas herramientas pueden incluir paquetes de quick build o archivos adicionales arbitrarios mediante modificaciones en las plantillas de imagen
    • La base es illumos/image-builder upstream

Archivo de imagen del SO

  • En el proceso de construir imágenes del sistema operativo para compute sleds de Oxide, se genera un archivo de imagen
  • Este archivo contiene la ROM de arranque y la imagen ramdisk del sistema de archivos raíz
  • También incluye metadatos en un archivo JSON y usa el mismo formato que omicron1 brand
  • El contenido de los archivos es una interfaz comprometida entre Helios y partes de Omicron, que debe descargar e instalar imágenes del sistema operativo en los sistemas físicos de Oxide Rack
  • Los archivos necesarios para que Omicron lo use incluyen, como mínimo, lo siguiente
    • oxide.json: archivo de encabezado de metadatos con al menos la clave v=1 y la clave t=os para identificar una imagen del sistema operativo
    • image/rom: imagen ROM de arranque del host de 32MiB
    • image/zfs.img: imagen ramdisk del sistema de archivos raíz del host, de tamaño arbitrario
  • Puede haber archivos adicionales con fines de ingeniería o diagnóstico
    • Por ejemplo: kernel comprimido unix.z para bldb o nanobl-rs, boot archive comprimido cpio.z
    • Un arreglo de archivos ROM adicionales con sufijos que representan distintas funciones de diagnóstico
  • Los archivos adicionales no forman parte de la interfaz comprometida y pueden cambiar en cualquier momento en el futuro
  • El software que interprete el archivo de imagen debe ignorar los archivos que no reconozca

Licencia

  • Copyright 2026 Oxide Computer Company
  • Salvo que se indique lo contrario, todos los componentes están licenciados bajo Mozilla Public License Version 2.0

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-30
Comentarios de Hacker News

  • Me alegra que esto se haya hecho público, y pienso desplegarlo localmente para aprender todo lo posible
    Oxide está muy cerca de ser la empresa soñada, tanto por su stack tecnológico como por la gente que trabaja ahí

    • Revisé la página principal unos 20 segundos y mi reacción fue algo como: “¿Esto es integración vertical para comprar servidores on-premise? ¿Hasta con sistema operativo personalizado? ¿Por qué pagaría esa prima?”
      Pero enseguida mi pensamiento siguió hacia “¿Y al final qué hace realmente el sistema operativo del servidor? ¿No basta con levantar máquinas virtuales? ¿No será que no hace falta Linux como tal, sino solo poder correr máquinas virtuales Linux?”
    • Tengo curiosidad por ver cómo se compara con SmartOS
      He invertido bastante en SmartOS para mi infraestructura personal, pero desde la adquisición de Joyent me ha preocupado su futuro
      Ojalá trabajara en una organización lo bastante grande como para usar hardware de Oxide. Sería increíble no tener que lidiar con esa falsa estructura de compatibilidad estilo IBM PC AT, BMCs e iDRACs medio improvisados, y controladores RAID por hardware
    • Oxide es de verdad casi la única empresa en la que me gustaría trabajar
      Desde fuera se siente parecida a Sun, y justo esa es la clase de empresa con la que siempre he soñado
      Pero teniendo que mantener a mi familia, su estructura salarial no me da. Tal vez cuando mi hijo termine la universidad y ya no necesite un ingreso tan alto, pueda cumplir ese sueño

  • ¿Alguien puede explicarme qué ofrece Oxide como si yo tuviera 5 años? No me queda claro ni viendo el sitio web
    No sé si es hardware+software para comprar y usar on-premise, si es un PaaS, o si es otro proveedor de nube

    • Parece que me están dando downvotes porque ya había un hilo grande sobre esto, pero eso me parece un poco injusto
      La respuesta corta es que sí: es hardware+software que compras para usar on-premise
      La diferencia frente a la mayoría de los productos de nube on-premise ya existentes es que es un solo proveedor que diseñó el hardware y el software para que funcionen bien juntos. Además, están haciendo el software lo más open source posible, y por eso salen anuncios como este
      La mayoría de los productos juntan piezas de varios proveedores y en la práctica venden la integración. Oxide cree que ese enfoque genera varios problemas, y que su producto los resuelve
      Otra diferencia es que solo tienen dos SKUs: medio rack y rack completo; no compras por unidades de 1U, sino por rack
      Si diseñas el rack completo como una sola unidad cohesionada, puedes hacer cosas que no son posibles en el formato 1U. Hacen mucho el chiste de hablar de ventiladores, pero es cierto. Como usan sleds más grandes que un 1U tradicional, pueden usar ventiladores más grandes y hacerlos girar a menos RPM, lo que ahorra energía
      Es una decisión de diseño intencional, pero también tiene efectos secundarios. Gracias a las RPM más bajas, los servidores son mucho más silenciosos. De hecho, algunos clientes potenciales al principio preguntaban durante las demos: “¿Seguro que esto está encendido?”
      Uno no compra servidores solo porque sean silenciosos, pero es un ejemplo interesante de lo que pasa cuando replanteas el producto como un todo y no como un simple trabajo de integración
    • Es una solución totalmente integrada de cómputo y almacenamiento para on-premise, con aprovisionamiento de recursos mediante APIs estilo nube, y además con un compromiso con el open source

  • Sé que la gente de Oxide viene de Sun, pero ¿hay realmente una ventaja técnica, en términos de propuesta de valor de negocio, en haber elegido algo que no sea Linux?
    Sé que hay aspectos en los que illumos es técnicamente mejor que Linux, pero no estoy seguro de que eso realmente le importe al cliente que va a comprar esto
    Me pregunto si no estarán abriendo un problema complejo donde, por ideología o tradición, terminan dificultando vender más computadoras
    Desde la perspectiva de alguien que opera cargas de trabajo de contenedores Linux, el hecho de que esto sea fundamentalmente no Linux no es una razón para comprarlo, sino una razón para dudar de la compra. Sé que los binarios de Linux pueden ejecutarse sin modificaciones

    • No es que en el producto digamos “por cierto, por dentro lleva illumos, y por eso debes comprar este rack”
      No es un detalle del producto visible para el cliente, y probablemente la mayoría ni siquiera lo sepa
      Lo que le importa al cliente es si el rack es eficiente, estable y se ajusta a sus necesidades. Elegir illumos en lugar de Linux fue una decisión para ofrecer ese valor de forma efectiva
      Por supuesto, eso no significa que no se pudiera construir un producto similar sobre Linux; nosotros concluimos que illumos era más adecuado para el propósito
      Tomamos esta decisión con el equipo en forma de un RFD[1], con el número #26, aunque por ahora no es público. Las opciones evaluadas seriamente fueron KVM de Linux y bhyve de illumos, y es un documento bastante largo
      Al final había que elegir un camino, y nosotros elegimos este. Yo no desarrollo esta parte directamente, pero hasta ahora no he visto razones para pensar que haya sido un obstáculo; más bien parece que probablemente fue la decisión correcta
      Me da curiosidad por qué el hecho de que no sea Linux sería una razón para oponerse a la compra. Agradecería más explicación. Ah, ya vi el comentario de abajo: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios es solo un detalle de implementación del rack y, como Hubris[0], no es algo visible para el usuario o la aplicación. Los usuarios del rack aprovisionan máquinas virtuales
      Por qué se usó un derivado de illumos y no otra cosa se trató un poco en la sesión de preguntas y respuestas[1] de cuando enviamos el primer rack, y planeamos explicarlo de nuevo en la discusión grabada[2] que haremos más tarde hoy
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • En el mundo embebido o de appliances, Linux puede convertirse fácilmente en una pesadilla
      Los ingenieros de plataforma se pasan el día corrigiendo problemas del kernel más reciente, los drivers y las bibliotecas principales, y la aplicación real termina dependiendo de todo eso
      O bien se toma el camino del 99% de los vendors de IoT: nunca actualizar el sistema operativo base y rezar para que no haya exploits activos apuntándole
      Por eso muchas empresas medianas sufrieron tanto con el problema de CentOS. Les permitía quedarse en una plataforma relativamente estable y seguir recibiendo actualizaciones de seguridad, sin tener que pagar ni operar una instalación completa de RHEL
      Había que revisar todas las dependencias cada 10 años más o menos, pero eso era mucho más fácil que seguir un ciclo de actualizaciones de 1 o 2 años. En algunos sistemas, solo el período de validación supera los 6 meses, así que ese ciclo es demasiado corto
      Esto es casi un problema exclusivo de Linux, y alternativas como *BSD ofrecen la mayor parte de lo que da Linux, pero con mucha menos ruptura constante
    • Que existan opciones es algo saludable, e incluso da la sensación de que el universo se está recuperando un poco después de que Oracle compró Sun
      Cuesta imaginar gente mejor que este equipo para integrar los sistemas de Oxide en un todo coherente
      Ahora trabajo como ingeniero usando solo Linux, pero extraño la época en la que había otro Unix fuerte capaz de ejecutar cargas de trabajo de alto valor
      Si comparo openvswitch de Linux con las capacidades de Crossbow SDN de Solaris, elegiría Crossbow cualquier día
      No significa que Linux esté mal, pero hay una enorme falta de cohesión a nivel de “plan maestro”: las herramientas van cada una por su lado, generan complejidad, y luego hay que volver a abstraer esa complejidad con herramientas todavía más complejas
    • Los clientes ejecutan encima de esto sistemas operativos virtualizados
      No es muy distinto de Azure Host OS, Bottlerocket o Flatcar
      Es importante que conocen toda la pila, que parte del código del kernel la conservan desde la época de Sun, y que pueden revelarla a clientes que quieran acceso al código por motivos de evaluación de seguridad

  • Como no conozco bien illumos, fui a ver la página web y lo primero que dice es “illumos is a Unix operating system”.
    ¿illumos es un Unix real como macOS, o es un sistema operativo tipo Unix como GNU/Linux?

    • Sí, es un Unix real. La explicación de Wikipedia es bastante buena: https://en.wikipedia.org/wiki/Illumos
      Está basado en OpenSolaris, y OpenSolaris a su vez se basa en System V Release 4 (SVR4) y Berkeley Software Distribution (BSD). Illumos está compuesto por el kernel, controladores de dispositivos, bibliotecas del sistema y software utilitario para la administración del sistema. Este núcleo sirve como base para varias distribuciones open source de Illumos, de forma parecida a como el kernel de Linux sirve de base para varias distribuciones Linux
    • Nadie ha pagado para pasar la certificación de Unix Branding de The Open Group
      https://www.opengroup.org/openbrand/register/
      Así que no puede usar la marca registrada UNIX™
      Pero por dentro sí tiene código fuente del kernel y del espacio de usuario de 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...
    • Legalmente, NetBSD tampoco es un Unix real. Esa marca no significa lo que la gente cree
    • Era una bifurcación open source de Solaris en la que Ian Murdock trabajó en Sun bajo el nombre de Project Indiana, y desciende de UNIX SVR4
    • Sí, es un Unix real. Según entiendo, pertenece a la familia Solaris

  • No es que no apoye a Oxide, pero el producto sigue siendo demasiado de nicho y demasiado temprano como para imaginar que empresas reales vayan a comprar esto por un buen tiempo.
    Apenas a finales del verano pasado enviaron el primer rack a su primer cliente, y ese cliente fue Idaho National Laboratory.
    En este momento, los únicos que de verdad pueden darse un riesgo así parecen ser básicamente instituciones nacionales de investigación

    • En el anuncio de octubre del año pasado se mencionaron dos clientes: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Entre los clientes de Oxide están Idaho National Laboratory y una organización global de servicios financieros. También está previsto completar instalaciones adicionales en empresas Fortune 1000 en los próximos meses
    • Todos los productos al inicio de su existencia se ven así.
      Si planeas lanzarlo de otra manera, prácticamente estás quebrando la empresa antes de salir. Unos pocos sobreviven por suerte, pero eso es justamente lo que alimenta la estadística de que 9 de cada 10 startups fracasan
      Tienes que enfocarte extremadamente en tu primer grupo de clientes para cruzar el abismo, y después viene el mercado masivo
    • Ojalá algún día también saquen un producto de homelab más pequeño y más barato.
      La gente podría aprender con eso o probarlo en startups, y luego eso podría traducirse en ventas de racks o contrataciones más adelante
    • Trabajo en una empresa tecnológica que salió a bolsa recientemente, y consideramos seriamente a Oxide al evaluar opciones on-premises.
      La propuesta funciona incluso para quienes todavía piensan “on-premises… guácala”.
      Parece ofrecer una experiencia tipo cloud sobre tu propio hardware.
      Ojalá fuera tan barato como Dell
    • Mi empresa también lo evaluó y nos impresionó muchísimo el producto.
      El único problema es que está hecho para cómputo de propósito general, y nosotros de verdad necesitábamos opciones de procesador más rápidas

  • Me gusta mucho que la documentación se vea clara e intuitiva. Personalmente, creo que la documentación ha sido históricamente un área difícil para la comunidad de illumos.
    Ver que en la nueva publicación del código fuente se habla de consolidations da una sensación reconfortante. Aunque, si no entendí muy mal la estructura del repositorio, parece ir en una dirección distinta al paradigma tradicional de gate.
    Tengo algunas preguntas, principalmente sobre herramientas. ¿Por qué gmake? Parece que tarde o temprano igual se va a necesitar dmake.
    La guía indica explícitamente ejecutar rustup con bash; ¿es un defecto de upstream o es que el sh local no es totalmente compatible con POSIX?
    ¿Cómo hacen el desarrollo interno? ¿La gente de Oxide usa estaciones de trabajo con illumos, o todos desarrollan en máquinas virtuales o entrando por SSH a servidores?
    ¿Por qué MPL? ¿Es por compatibilidad con GPL?

    • No trabajo directamente en helios, así que no puedo responder todo, pero sí algunas cosas.
      Sobre si la gente de Oxide usa estaciones de trabajo con illumos o desarrolla en máquinas virtuales o por SSH a servidores, escribí sobre eso aquí: https://news.ycombinator.com/item?id=39181727
      Pero sí hay personas que realmente usan illumos en estaciones de trabajo
      Sobre MPL, está aquí: https://news.ycombinator.com/item?id=39181844
      En ese comentario no profundicé mucho en el “por qué”, pero me parece un buen punto intermedio dentro del espacio de posibilidades. Es más copyleft que BSD, pero menos restrictiva que GPL
    • Hasta donde sé, eso es un problema de upstream.
      Como en la mayoría de los proyectos open source, ahí también hay Linuxisms/Bashisms
    • Por razones históricas, para compilar el sistema operativo base se usa dmake, pero cuando se crean Makefiles nuevos en otras consolidations normalmente se recomienda GNU make (gmake).
      Está ampliamente disponible, funciona en otras plataformas y tiene funciones más modernas

  • Está muy bien que el software sea open source, pero ¿se puede desplegar y usar en otro hardware?
    Si por cualquier motivo la empresa ya no pudiera comprar racks de Oxide, ¿habría que reiniciar toda la infraestructura desde cero, o se podría seguir expandiéndola en torno al hardware de Oxide?

    • No es muy probable que sea útil de inmediato fuera de nuestro hardware, pero la función principal es desplegar máquinas virtuales
      Si decides dejar de usar el rack de Oxide que compraste, simplemente mueves las máquinas virtuales a la infraestructura que elijas como reemplazo

  • De verdad me intriga qué tipo de cargas de trabajo querrían ejecutar las empresas en un Unix personalizado que no sea Linux/Mac/BSD
    Apoyo que exista una diversidad de sistemas operativos más madura, pero no me queda claro quién sería el usuario final ni qué necesidades tendría

    • El cómputo que se aprovisiona en un rack de Oxide son máquinas virtuales. Portaron bhyve desde FreeBSD y también añadieron migración en vivo
      Si la necesidad aprieta, probablemente también podría arrancar Windows Server
      También es cierto que eligieron Illumos en parte por una inclinación natural, ya que mucha gente viene de Sun, Joyent y lugares similares
      Pero también hay razones bastante convincentes para ello: esto no es una PC personal x86 compatible con IBM. No hay BIOS, ni UEFI, ni un BMC tradicional, y parece que usan x86 moderno eliminando la mayor cantidad posible de firmware propietario y blobs binarios
      Cada sled tiene un procesador de servicio y una raíz de confianza de hardware, y eso es lo que arranca directamente la CPU, carga el blob de entrenamiento de AMD y luego inicia el sistema operativo
      Sería difícil upstreamear esos cambios a Linux o BSD para una computadora que por ahora solo tienen ellos. Al final tendrían que mantener su propio fork downstream y, como tampoco habría otra parte responsable de la solidez del sistema operativo, concluyen que tiene más sentido usar un sistema operativo que ya llevan años soportando y desarrollando
    • Esto no es un detalle visible para el usuario en el producto
      El cliente ejecuta máquinas virtuales en el rack; no compila aplicaciones para illumos
      Dentro de esas máquinas virtuales correrá cualquier sistema operativo que necesite para cumplir su objetivo
    • ZFS es nativo en illumos, y también son bastante buenas sus capacidades equivalentes a la contenerización
      Si puedes contratar suficiente personal, también es convincente el argumento de que los servidores de una nube no necesariamente tienen que usar todos el mismo sistema operativo
    • Ni siquiera te darías cuenta de que esto no es Linux
      No ejecutas tu código sobre este sistema operativo, sino sobre las máquinas virtuales que este sistema operativo proporciona

  • Me da curiosidad cómo fue que conocieron Oxide por primera vez
    Yo llegué a ellos por casualidad a través de su pódcast, y para mí se siente como una estrategia de marketing enorme. Hacen de todo excepto venderte directamente el producto
    Incluso podría funcionar bien meter un pitch corto al final de cada episodio
    Van contando algo como “nos costó muchísimo hacer que el compilador hiciera cierta cosa” y luego se desvían hacia historias del pasado
    Aun así, ojalá sigan haciéndolo y les vaya bien

    • On The Metal, que era su pódcast original, se hizo famoso por repetir en exceso 2 o 3 autopromociones pregrabadas, hasta el punto de que fans llegaron a pedir grabar ellos mismos los anuncios
      En cambio, Oxide and Friends se parece menos a un pódcast tradicional y más a la grabación de un “space” en vivo o de una llamada grupal que empezó en Twitter y ahora se hace en Discord
      Me parece un formato que se disfruta mejor participando en vivo que escuchándolo solo como pódcast. Si entras en vivo, entiendes mucho mejor la vibra de la grabación
      https://oxide.computer/podcasts/oxide-and-friends
    • Antes seguía a @jessfraz en Twitter, así que me enteré por ahí cuando anunciaron Oxide por primera vez
    • Me enteré cuando Pentagram mostró el branding al momento del anuncio inicial de Oxide

  • Llevo esperando esto desde que anunciaron el rack de servidores
    Si Oxide llegara a quebrar, nadie querría hardware convertido en un pisapapeles

    • Para ser claros, ese “problema del pisapapeles” también es muy importante para nosotros
      Vale la pena recordar que la MPL no distingue si una copia está publicada públicamente en GitHub o no
      No soy abogado, pero frente a los clientes sí existen obligaciones bajo la MPL, independientemente de que personas que no sean clientes puedan ver el código o no