Helios: a distribuição illumos que executa o Oxide Rack

 (github.com/oxidecomputer)
1 pontos por GN⁺ 2024-01-30 | 1 comentários | Compartilhar no WhatsApp
  • Helios é uma distribuição illumos que executa o Oxide Rack, e as ferramentas e a documentação deste repositório de nível superior reúnem várias consolidações de software para gerenciar a build da distribuição completa
  • A distribuição usa a branch stlouis do illumos-gate como sistema operacional principal e fornece principalmente pacotes stock do illumos com componentes adicionais para o hardware da Oxide e algumas transformações de empacotamento
  • Nem todos os repositórios de componentes estão públicos, e as consolidações privadas podem ser excluídas do clone e da build com OXIDE_STAFF=no gmake setup
  • A build de pacotes próprios usa um ambiente Helios recente com rustup, gmake setup e o helios-build baseado em Rust, e durante o desenvolvimento é possível fazer uma quick build desativando o shadow compiler e algumas verificações
  • Os resultados da build podem ser instalados no ambiente de boot local, distribuídos para outros sistemas de teste com pkg.depotd ou inspecionados apenas como repositório de pacotes transformados sem instalação

Papel e composição do Helios

  • Helios é uma distribuição illumos que executa o Oxide Rack
  • A distribuição completa é composta por várias consolidações de software, e as ferramentas e a documentação deste repositório de nível superior conduzem a build
  • As consolidações públicas incluem:
  • Também há consolidações que ainda não foram publicadas:
    • amd-firmware: blobs binários de firmware para CPU AMD, com publicação futura prevista
    • chelsio-t6-roms: blobs de firmware para NIC Chelsio T6, com publicação futura prevista
    • pilot: utilitário de controle de baixo nível para sistemas Oxide, com publicação futura prevista
    • dmar-report: gerador de relatórios de DRAM margining, com publicação futura prevista
  • Se você não tiver acesso aos repositórios privados, pode pular o clone e a build do software ainda não publicado com OXIDE_STAFF=no gmake setup

Ambiente inicial e configuração

  • Este é o procedimento para quem pretende compilar e instalar seus próprios pacotes do sistema operacional; se o objetivo for apenas usar o Helios, o fluxo é consultar as informações do software Helios pré-compilado em helios-engvm
  • O ponto de partida recomendado é uma máquina física ou virtual de build com uma versão recente do Helios instalada
    • Os detalhes de instalação em máquina virtual estão em helios-engvm
    • As informações de mídia de instalação para sistemas físicos x86 também estão no mesmo repositório
  • Se você criou a VM usando o procedimento do helios-engvm, os pacotes necessários já devem estar instalados
  • Se você criou o ambiente Helios com o instalador ISO ou de outra forma, talvez precise do pacote pkg:/developer/illumos-tools
    • Verifique a instalação com pkg list developer/illumos-tools
    • Se estiver faltando, instale com pkg install
  • É recomendável usar os pacotes mais recentes do Helios e verificar as instruções mostradas após pkg update
    • Se o update informar que criou um novo boot environment, ative-o com reboot antes de prosseguir
  • Rust e Cargo são instalados a partir dos binários oficiais do projeto Rust com rustup
    • No procedimento oficial de instalação, use bash em vez de sh
    • Exemplo de comando: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

Clone de repositórios e helios-build

  • Na máquina Helios, faça o clone do repositório e execute gmake setup
    • A ferramenta helios-build, baseada em Rust, é compilada em tools/helios-build
    • Vários repositórios são clonados em projects/
  • Se você não tiver acesso aos repositórios privados da organização GitHub oxidecomputer, pode usar apenas os repositórios públicos assim:
    • OXIDE_STAFF=no gmake setup
  • A ferramenta helios-build pode levar algum tempo na primeira build
  • A etapa de configuração inicial clona os repositórios esperados do projeto, mas operações posteriores, como updates ou troca de branch, são feitas apenas em alguns deles
    • Você pode ver quais repositórios recebem update automático em auto_update de config/projects.toml
    • Os demais clones locais devem ter troca de branch e pull gerenciados manualmente, como qualquer repositório Git comum

Como a build do illumos funciona

  • Os componentes principais do sistema operacional no Helios vêm da branch stlouis do illumos-gate
  • A maior parte dos pacotes incluídos em um sistema Helios é basicamente stock illumos com componentes adicionais para hardware da Oxide e algumas pequenas transformações de empacotamento
  • O helios-build fornece vários wrappers que gerenciam a configuração da build e chamam as ferramentas de build do illumos para simplificar o processo
  • A documentação upstream Building illumos cobre grande parte do que as ferramentas do Helios fazem automaticamente
  • Durante o desenvolvimento, é possível fazer uma quick build com o comando abaixo:
    • ./helios-build build-illumos -q
    • A quick build desativa o shadow compiler e algumas verificações exigidas na integração final
  • O tempo de build varia conforme a quantidade de CPUs da máquina de build e o desempenho do armazenamento local
  • O log completo da build é grande; por exemplo, pode ser acompanhado com tail -F projects/illumos/log/nightly.log
  • Se a build for bem-sucedida, um repositório de pacotes será criado em projects/illumos/packages/i386, e depois poderá ser transformado e instalado de várias formas

Instalação e distribuição dos pacotes compilados

  • Instalação na máquina local de build

    • Os pacotes recém-compilados podem ser instalados na máquina de build com ./helios-build onu -t my-be-name
    • Esse comando transforma e instala os pacotes do illumos e cria um novo Boot Environment com o nome passado em -t
    • O novo boot environment é ativado pelo onu, e o usuário entra nele após reiniciar
    • Consulte beadm(8) para informações sobre boot environments
    • Ao reiniciar, é recomendável estar no console para observar as mensagens de boot e poder interagir com o boot loader
    • Após a instalação, pkg list -Hv system/kernel permite verificar que o pacote system/kernel veio do publisher local baseado em arquivo on-nightly e da versão de quick build 3.0.999999

  • Instalação em outra máquina via servidor de repositório de pacotes

    • Se houver uma máquina de teste separada da máquina de build, é possível usar o servidor de repositório pkg.depotd da máquina de build
    • ./helios-build onu -D transforma os pacotes da build mais recente e inicia o servidor de pacotes
    • No exemplo, o serviço é oferecido em 0.0.0.0:7891
    • O servidor continua em execução até receber Control-C ou outro encerramento
    • Na máquina de destino, verifique a conectividade com a máquina de build usando pkgrepo info -s http://genesis:7891
    • Um sistema Helios stock tem por padrão um único publisher helios usando o repositório central https://pkg.oxide.computer/helios/3/dev/
    • Na máquina de teste, adicione o publisher on-nightly, defina-o como primeira origem de busca e afrouxe a regra sticky do publisher helios
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • Dependendo da situação, pode ser necessário remover o metapacote entire antes do update
    • Isso pode ser especialmente necessário quando existirem zones baseadas na brand lipkg
    • A ferramenta onu do illumos stock faz isso automaticamente
    • Execute pkg update -nv como dry-run para verificar se o update será feito para os pacotes de quick build
    • No exemplo, 325 pacotes são atualizados, e será necessário criar e ativar um novo boot environment, além de reconstruir o boot archive
    • A versão muda da versão stock do Helios baseada no número de commit da branch stlouis para a versão de quick build 3.0.999999
    • O update real é feito com pkg update -v, e, se der certo, será preciso reiniciar no novo boot environment
    • Após reiniciar, a configuração dos publishers permanece
    • Depois disso, é possível repetir o fluxo de nova build, reinício do servidor de pacotes e pkg update -v na máquina de teste

  • Gerar apenas pacotes sem instalar

    • ./helios-build onu -P apenas transforma o resultado da quick build sem instalá-lo
    • O repositório de pacotes transformado é criado em tmp/onu/repo.redist
    • Esse método é útil para inspecionar o conteúdo do repositório 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*'
    • Também é possível preservar os arquivos de pacote para comparar saídas de várias builds, transferi-los para sistemas remotos ou usá-los em uma instalação posterior

Trabalhando em mudanças e builds iterativas

  • Em geral, é melhor começar mudanças no sistema em um workspace de build limpo após uma quick build
  • Para alterar um arquivo-fonte específico e recompilar um componente, primeiro entre no ambiente de build com bldenv
    • ./helios-build bldenv -q
    • Um novo shell interativo é iniciado, com PATH e outras variáveis definidos corretamente
  • Vá até o diretório do componente e execute comandos como dmake -S -m serial install para compilar e instalar
    • O exemplo compila o comando id em cmd/id e o instala na área proto
  • Esse método incremental e direcionado de editar e recompilar é adequado para ciclos curtos de validação de compilação

  • A opção mais correta, porém mais lenta

    • É possível recompilar todo o sistema operacional
    • Esse é o único procedimento que garante o resultado correto dentro do possível
    • Se algum problema inexplicável surgir em métodos incrementais, é recomendável tentar primeiro uma full build
    • O comando é ./helios-build build-illumos -q

  • A opção rápida, mas sem garantias

    • Se você atualizou binários na área proto com dmake install, pode regenerar e instalar apenas os pacotes sem refazer a build completa
    • Dentro do bldenv, vá para $SRC/pkg e execute dmake install
    • Depois disso, inicie um servidor de repositório com os pacotes atualizados ou faça a instalação local

  • A opção de trabalhar diretamente no sistema de arquivos

    • No fim das contas, o sistema operacional é apenas um conjunto de arquivos no sistema de arquivos, então abordagens fora das ferramentas de empacotamento também são possíveis
    • Você pode executar o binário modificado diretamente no sistema de build ou copiá-lo para o sistema de teste com scp ou rsync e executá-lo lá
    • Isso pode não funcionar se o binário depender de mudanças em bibliotecas ou no kernel
    • Também é possível criar um novo boot environment e ajustar os arquivos dentro dele
    • Um boot environment é um sistema de arquivos ZFS separado que pode ser modificado, ter snapshot, ser clonado e inicializado
    • Você pode usar beadm create, beadm mount e beadm activate
    • Também é possível criar uma imagem de disco ou ramdisk totalmente nova e inicializá-la via VM ou PXE
    • As ferramentas específicas do Helios para geração de imagem estão nas ferramentas de imagem do helios-engvm
    • Essas ferramentas podem incluir pacotes de quick build ou arquivos adicionais arbitrários por meio da modificação de templates de imagem
    • A base é o upstream illumos/image-builder

Arquivo de imagem do sistema operacional

  • No processo de build de imagens do sistema operacional para os compute sleds da Oxide, é gerado um arquivo de imagem
  • Esse arquivo contém a ROM de boot e a imagem ramdisk do sistema de arquivos raiz
  • Também inclui metadados em um arquivo JSON, usando o mesmo formato de omicron1 brand
  • O conteúdo do arquivo é uma interface comprometida entre o Helios e partes do Omicron, que precisam baixar e instalar imagens do sistema operacional em sistemas físicos do Oxide Rack
  • Os arquivos mínimos necessários para uso pelo Omicron incluem:
    • oxide.json: arquivo de cabeçalho de metadados com pelo menos a chave v=1 e a chave t=os para identificar a imagem do sistema operacional
    • image/rom: imagem de ROM de boot do host com 32MiB
    • image/zfs.img: imagem ramdisk do sistema de arquivos raiz do host, de tamanho arbitrário
  • Pode haver arquivos adicionais para fins de engenharia ou diagnóstico
    • Ex.: kernel comprimido unix.z para bldb ou nanobl-rs, boot archive comprimido cpio.z
    • Um array de arquivos ROM adicionais com sufixos que representam diferentes funções de diagnóstico
  • Esses arquivos adicionais não fazem parte da interface comprometida e podem mudar a qualquer momento no futuro
  • Softwares que interpretam o arquivo de imagem devem ignorar arquivos que não reconheçam

Licença

  • Copyright 2026 Oxide Computer Company
  • Salvo indicação em contrário, todos os componentes são licenciados sob a Mozilla Public License Version 2.0

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-30
Opiniões no Hacker News

  • Fico feliz que isso tenha sido publicado, e pretendo implantar localmente para aprender o máximo possível
    A Oxide é praticamente uma empresa dos sonhos, tanto pela stack tecnológica quanto pelas pessoas que trabalham lá

    • Depois de passar uns 20 segundos olhando a página inicial, fiquei com a impressão de “isso é integração vertical para compra de servidores on-premises? Até um sistema operacional customizado? Por que pagar um prêmio por isso?”
      Mas logo o pensamento foi para “afinal, o que um sistema operacional de servidor faz? Não basta subir máquinas virtuais? Não é que eu precise necessariamente de Linux; eu só preciso conseguir rodar máquinas virtuais Linux, certo?”
    • Estou curioso para ver como isso se compara ao SmartOS
      Investi bastante em SmartOS na minha infraestrutura pessoal, mas depois da aquisição da Joyent fiquei preocupado com o futuro
      Eu gostaria de trabalhar em uma organização grande o suficiente para usar equipamentos da Oxide. Seria incrível não ter que ficar mexendo em estruturas de compatibilidade falsas no estilo IBM PC AT, BMCs e iDRACs mal-ajambrados, controladoras RAID de hardware e coisas assim
    • A Oxide é praticamente a única empresa em que eu realmente gostaria de trabalhar
      Vista de fora, ela passa uma sensação parecida com a Sun, e é exatamente esse tipo de empresa com que sempre sonhei
      Mas, como alguém que precisa sustentar a família, a estrutura de remuneração não é viável para mim. Talvez, quando meu filho se formar na faculdade e eu não precisar mais de uma renda alta, eu consiga realizar esse sonho

  • Alguém consegue me explicar como se eu tivesse 5 anos o que a Oxide oferece? Olhando o site, não dá para entender
    Não sei se é hardware+software para comprar e usar on-premises, se é PaaS ou se é mais um provedor de nuvem

    • Parece que você está levando downvote porque já existe uma thread grande relacionada, mas isso me parece meio injusto
      Em resumo: sim. É hardware+software que você compra e usa on-premises
      O diferencial em relação à maioria dos produtos de nuvem on-premises existentes é que se trata de um único fornecedor que projetou o hardware e o software para funcionarem bem juntos. Eles estão tentando tornar o software o mais open source possível, e é por isso que anúncios como este aparecem
      A maioria dos produtos junta itens de vários fornecedores e, na prática, vende integração. A Oxide entende que essa abordagem gera vários problemas, e que seu produto resolve esses problemas
      Outro ponto é que existem apenas dois SKUs: meio rack e rack completo. Você não compra em unidades de 1U, compra por rack
      Projetar o rack inteiro como uma unidade coesa permite fazer coisas impossíveis no formato 1U. Há uma piada de que eles sempre falam de ventoinhas, e é verdade. Como usam sleds maiores que o 1U tradicional, podem usar ventoinhas maiores e fazê-las girar em RPM mais baixo, economizando energia
      Foi uma escolha de design intencional, mas também tem efeitos colaterais. Graças ao RPM mais baixo, os servidores são muito mais silenciosos. Entre os primeiros clientes em potencial, houve até quem perguntasse durante uma demonstração: “isso está mesmo ligado?”
      Ninguém compra servidores só por serem silenciosos, mas é um exemplo interessante do que acontece quando você repensa o produto como um todo, em vez de tratá-lo como um simples trabalho de integração
    • É uma solução de computação e armazenamento totalmente integrada para uso on-premises, que provisiona recursos por meio de APIs no estilo de nuvem e vem acompanhada de um compromisso com open source

  • Sei que o pessoal da Oxide veio da Sun, mas há alguma vantagem técnica real, em termos de proposta de valor de negócio, em terem escolhido algo que não fosse Linux?
    Sei em quais pontos o illumos é tecnicamente melhor que o Linux, mas não sei se isso realmente importa para o cliente que compra isso
    Fico pensando se não estão abrindo um problema complexo que os impede de vender mais computadores por ideologia ou tradição
    Do ponto de vista de quem opera workloads em contêineres Linux, o fato de isso ser fundamentalmente não Linux não é um motivo para comprar, mas sim um motivo para hesitar na compra. Sei que é possível executar binários Linux sem modificação

    • No produto, não é como se dissessem “a propósito, há illumos por dentro, e por isso você deve comprar este rack”
      Não é um detalhe do produto exposto ao cliente, e é bem provável que a maioria nem saiba disso
      O que importa para o cliente é se o rack é eficiente, confiável e adequado às suas necessidades. A escolha do illumos em vez do Linux aqui foi feita para entregar esse valor de forma eficaz
      Claro, isso não significa que não seria possível criar um produto semelhante sobre Linux; nós julgamos que illumos era mais adequado ao propósito
      Tomamos essa decisão com a equipe na forma de um RFD[1]; ele tem o número #26, mas atualmente não está público. As opções consideradas seriamente foram o KVM do Linux e o bhyve do illumos, e é um documento bem longo
      No fim, era preciso escolher um caminho, e escolhemos este. Eu não desenvolvo diretamente essa parte, mas até agora não houve motivo para vê-la como um obstáculo; pelo contrário, é bem possível que tenha sido a escolha certa
      Fico curioso sobre por que o fato de ser não Linux seria um motivo contra a compra. Seria bom se você pudesse explicar melhor. Ah, vi o comentário abaixo: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios é apenas um detalhe de implementação do rack e, assim como o Hubris[0], não é algo visível para usuários ou aplicações. Usuários do rack provisionam máquinas virtuais
      O motivo de termos usado um derivado do illumos, e não outra coisa, foi tratado um pouco no Q&A[1] de quando enviamos o primeiro rack, e também pretendemos explicar novamente na discussão gravada[2] que faremos mais tarde hoje
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • Em áreas de embarcados ou appliances, o Linux pode facilmente virar um pesadelo
      Engenheiros de plataforma passam o dia corrigindo problemas de kernel recente, drivers e bibliotecas essenciais, e a aplicação real acaba dependendo disso tudo
      Ou então seguem o caminho de 99% dos fornecedores de IoT: nunca atualizam o sistema operacional de base e rezam para que não haja exploits ativos mirando nele
      Foi por isso que muitas empresas de médio porte sofreram bastante com a questão do CentOS. Porque podiam permanecer em uma plataforma relativamente estável e receber atualizações de segurança sem pagar para operar uma instalação completa do RHEL
      A cada cerca de 10 anos era preciso rever todas as dependências, mas isso era muito mais fácil do que acompanhar um ciclo de atualizações de 1 a 2 anos. Em alguns sistemas, só o período de validação passa de 6 meses, então esse ciclo é curto demais
      Esse é um problema quase exclusivo do Linux, e alternativas como *BSD oferecem a maior parte do que o Linux oferece, mas com muito menos quebras contínuas
    • É saudável haver escolhas, e dá até a sensação de que o universo está se recuperando um pouco depois que a Oracle comprou a Sun
      É difícil imaginar pessoas melhores para formar a equipe que integraria os sistemas da Oxide
      Hoje sou um engenheiro que trabalha só com Linux, mas sinto falta da época em que havia outro Unix forte capaz de rodar workloads de alto valor
      Comparando o openvswitch do Linux com os recursos de Crossbow SDN do Solaris, eu escolheria o Crossbow sempre
      Não quero dizer que o Linux esteja errado, mas as ferramentas seguem seus próprios caminhos e criam complexidade, que depois precisa ser abstraída novamente por ferramentas ainda mais complexas; falta muito uma coesão no nível de um “plano mestre”
    • Os clientes executam sistemas operacionais virtualizados sobre isso
      Não é muito diferente de Azure Host OS, Bottlerocket ou Flatcar
      O importante é que eles conhecem a pilha inteira, parte do código do kernel está com eles desde a época da Sun, e podem disponibilizá-lo para clientes que querem acesso ao código-fonte por causa de avaliações de segurança

  • Como eu não conhecia bem o illumos, olhei a página web e logo no começo dizia “illumos is a Unix operating system”
    O illumos é um Unix de verdade, como o macOS, ou é um sistema operacional do tipo Unix, como o GNU/Linux?

    • É um Unix de verdade. A explicação da Wikipedia é bem boa: https://en.wikipedia.org/wiki/Illumos
      Ele é baseado no OpenSolaris, e o OpenSolaris é baseado no System V Release 4(SVR4) e no Berkeley Software Distribution(BSD). O Illumos é composto por kernel, drivers de dispositivos, bibliotecas de sistema e software utilitário para administração do sistema. Esse núcleo serve de base para várias distribuições Illumos de código aberto, de modo parecido com o kernel Linux servindo de base para várias distribuições Linux
    • Ninguém pagou para passar nos testes de certificação Unix Branding do Open Group
      https://www.opengroup.org/openbrand/register/
      Por isso não dá para usar a marca UNIX™
      Mas, por dentro, há código-fonte do kernel e do espaço de usuário do 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, o NetBSD também não é um Unix de verdade. Essa marca não tem o significado que as pessoas imaginam
    • Era um fork open source do Solaris em que Ian Murdock trabalhou na Sun com o nome Project Indiana, e descende do UNIX SVR4
    • É um Unix de verdade. Pelo que sei, é da linhagem Solaris

  • Não é que eu não torça pela Oxide, mas o produto ainda é nichado demais e está em fase inicial demais para eu imaginar empresas reais comprando isso por um bom tempo
    Só no fim do verão passado eles enviaram o primeiro rack ao primeiro cliente, e esse cliente também era o Idaho National Laboratory
    No momento, parece que praticamente só instituições nacionais de pesquisa podem fazer uma aposta dessas

    • No anúncio de outubro do ano passado, dois clientes foram mencionados: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Os clientes da Oxide incluem o Idaho National Laboratory e uma organização global de serviços financeiros. Instalações adicionais em empresas da Fortune 1000 devem ser concluídas nos próximos meses
    • Todo produto no começo de sua existência é assim
      Se você planeja lançar de outro jeito, já condenou a empresa antes mesmo do lançamento. Alguns poucos sobrevivem por sorte, mas isso contribui para a estatística de que 9 em cada 10 startups fracassam
      É preciso ter um foco extremo no primeiro grupo de clientes para atravessar o abismo; depois vem o mercado de massa
    • Espero que um dia lancem também um produto para homelab menor e mais barato
      As pessoas poderiam aprender ou startups poderiam experimentar, levando depois a vendas de racks ou contratações
    • Trabalho em uma empresa de tecnologia que abriu capital recentemente, e consideramos seriamente a Oxide ao avaliar on-premises
      A proposta funciona até para quem ainda pensa “on-premises… aff”
      Parece oferecer uma experiência parecida com a de nuvem no seu próprio hardware
      Teria sido ótimo se fosse tão barato quanto a Dell
    • Nossa empresa também avaliou, e ficamos muito impressionados com o produto
      O único problema é que ele foi feito para computação de uso geral, e nós realmente precisávamos de opções de processadores mais rápidos

  • Gosto muito de como a documentação parece clara e intuitiva. Pessoalmente, acho que documentação foi uma área em que a comunidade illumos historicamente teve dificuldades
    Ver a menção a consolidations na nova release do código-fonte me deu uma sensação boa. Mas, a menos que eu tenha entendido muito errado a organização dos repositórios, parece seguir uma direção diferente do paradigma tradicional de gate
    Tenho algumas perguntas, principalmente relacionadas a ferramentas. Por que gmake? Parece que dmake também será necessário de qualquer forma depois
    As instruções dizem explicitamente para executar o rustup com bash; isso é uma falha upstream ou o sh local não é totalmente compatível com POSIX?
    Como é o desenvolvimento interno? O pessoal da Oxide usa workstations com illumos, ou todos desenvolvem em máquinas virtuais ou via SSH em servidores?
    Por que MPL? Por causa da compatibilidade com GPL?

    • Não trabalho diretamente no helios, então não consigo responder tudo, mas posso responder parte
      Sobre se o pessoal da Oxide usa workstations com illumos ou desenvolve em VMs/por SSH em servidores, escrevi aqui: https://news.ycombinator.com/item?id=39181727
      Dito isso, há pessoas que de fato usam illumos em workstations
      Sobre MPL, está aqui: https://news.ycombinator.com/item?id=39181844
      Naquele comentário eu não falei a fundo sobre o “porquê”, mas vejo como um bom meio-termo no espaço de possibilidades. É mais copyleft que BSD, mas menos restritiva que GPL
    • Pelo que sei, isso é um problema upstream
      Como na maioria dos projetos open source, ali também há Linuxism/Bashism
    • Por razões históricas, usamos dmake para compilar o sistema operacional central, mas ao criar novos Makefiles em outras consolidation, a tendência é recomendar GNU make(gmake)
      Ele é amplamente disponível, funciona também em outras plataformas e tem recursos mais modernos

  • É ótimo que o software seja open source, mas será que dá para implantá-lo e usá-lo em outro hardware?
    Se, por qualquer motivo, a empresa não puder mais comprar racks da Oxide, ela precisa recomeçar a infraestrutura do zero, ou consegue continuar expandindo em torno do hardware da Oxide?

    • Fora do nosso hardware, é pouco provável que ele seja imediatamente útil, mas a função principal é a implantação de máquinas virtuais.
      Se você decidir não usar mais o rack da Oxide que comprou, basta mover as máquinas virtuais para a infraestrutura que escolher em seguida.

  • Tenho muita curiosidade sobre que workloads as empresas gostariam de rodar em um Unix customizado que não é Linux/Mac/BSD.
    Torço para que surja uma diversidade de sistemas operacionais mais madura, mas não consigo imaginar quem seriam os usuários finais e que necessidades teriam.

    • A computação provisionada em um rack da Oxide é feita em máquinas virtuais. Eles portaram o bhyve do FreeBSD e também adicionaram live migration.
      Se houvesse necessidade, imagino que até Windows Server poderia ser inicializado.
      O motivo de usarem Illumos é, em parte, que há muita gente vinda da Sun, da Joyent etc., então existe mesmo um viés natural.
      Mas também há um motivo bastante convincente: isto não é um computador pessoal x86 compatível com IBM. Não há BIOS, nem UEFI, nem BMC tradicional; embora use x86 moderno, parece que eles removeram o máximo possível de firmware proprietário e blobs binários.
      Cada sled tem um processador de serviço e uma raiz de confiança em hardware, que inicializa diretamente a CPU, carrega o blob de treinamento da AMD e depois inicializa o sistema operacional.
      Seria difícil fazer upstream dessas mudanças para Linux ou BSD para um computador que, no momento, só eles têm. No fim, teriam que manter um fork downstream próprio e, como também não haveria outra parte responsável pela robustez do sistema operacional, a conclusão foi que seria melhor usar um sistema operacional que eles vêm apoiando e desenvolvendo há anos.
    • Isso não é um detalhe visível para o usuário no produto.
      O cliente executa máquinas virtuais no rack, não compila aplicações para illumos.
      Dentro dessas máquinas virtuais, ele roda qualquer sistema operacional necessário para atingir seus objetivos.
    • ZFS é nativo no illumos, e os recursos equivalentes a conteinerização também são bem bons.
      Se for possível contratar gente suficiente, também é convincente o argumento de que os servidores de uma nuvem não precisam necessariamente usar todos o mesmo sistema operacional.
    • Você provavelmente nem ficaria sabendo que isto não é Linux.
      Você não executa seu código em cima desse sistema operacional; executa seu código em cima das máquinas virtuais fornecidas por ele.

  • Fico curioso para saber como as pessoas conheceram a Oxide pela primeira vez.
    Eu acabei chegando ao podcast deles por acaso e, para mim, parece um marketing enorme. Eles fazem tudo, exceto vender o produto diretamente.
    Talvez fosse bom colocar um pitch curto no fim de cada episódio.
    Eles começam falando algo como “foi muito difícil fazer o compilador fazer tal coisa” e acabam entrando em histórias antigas.
    Mesmo assim, espero que continuem contando essas histórias e torço para que dê certo.

    • O On The Metal, que era o podcast original, era famoso por repetir demais 2 ou 3 autopromoções pré-gravadas, a ponto de um fã gravar anúncios por conta própria e pedir para eles colocarem no ar.
      Já o Oxide and Friends é menos um podcast tradicional e mais uma gravação de um “space” ao vivo ou chamada em grupo que começou no Twitter e hoje acontece no Discord.
      Acho que é um formato melhor consumido ao vivo do que apenas como podcast. Ao ouvir ao vivo, você entende muito melhor o clima da gravação.
      https://oxide.computer/podcasts/oxide-and-friends
    • Eu seguia a @jessfraz no Twitter, então soube por lá quando a Oxide foi anunciada pela primeira vez.
    • Conheci a Oxide quando a Pentagram revelou o branding na ocasião do primeiro anúncio da empresa.

  • Eu esperava por isso desde que anunciaram o rack de servidores.
    Se a Oxide quebrar, ninguém vai querer equipamentos que virem peso de papel.

    • Para deixar claro, esse “problema do peso de papel” também é muito importante para nós.
      É preciso lembrar que a MPL não depende de uma cópia estar publicada no GitHub ou não.
      Não sou advogado, mas, independentemente de não clientes poderem ler o código, há obrigações sob a MPL em relação aos clientes.