Helios: Distribusi illumos yang Menjalankan Oxide Rack

 (github.com/oxidecomputer)
1 poin oleh GN⁺ 2024-01-30 | 1 komentar | Bagikan ke WhatsApp
  • Helios adalah distribusi illumos yang menjalankan Oxide Rack; alat dan dokumentasi di repositori tingkat atas ini mengelola build distribusi lengkap dengan menggabungkan beberapa software consolidation
  • Distribusi ini menggunakan branch stlouis illumos-gate sebagai OS inti, dan terutama menyediakan paket stock illumos dengan tambahan untuk hardware Oxide serta beberapa transformasi packaging
  • Tidak semua repositori komponen bersifat publik; consolidation privat dapat dikecualikan dari target clone dan build dengan OXIDE_STAFF=no gmake setup
  • Build paket sendiri menggunakan rustup, gmake setup, dan helios-build berbasis Rust di lingkungan Helios terbaru; selama pengembangan, quick build dapat dilakukan dengan mematikan shadow compiler dan beberapa pemeriksaan
  • Hasil build dapat diinstal ke boot environment lokal, didistribusikan ke sistem uji lain melalui pkg.depotd, atau diperiksa dengan hanya membuat repositori paket hasil konversi tanpa instalasi

Peran dan Komposisi Helios

  • Helios adalah distribusi illumos yang menjalankan Oxide Rack
  • Distribusi lengkapnya terdiri dari beberapa software consolidation, dan alat serta dokumentasi di repositori tingkat atas ini memimpin proses build
  • Consolidation publik mencakup hal-hal berikut
  • Ada juga consolidation yang belum dipublikasikan
    • amd-firmware: blob biner firmware CPU AMD, direncanakan akan dipublikasikan
    • chelsio-t6-roms: blob firmware NIC Chelsio T6, direncanakan akan dipublikasikan
    • pilot: utilitas kontrol tingkat rendah untuk sistem Oxide, direncanakan akan dipublikasikan
    • dmar-report: generator laporan DRAM margining, direncanakan akan dipublikasikan
  • Jika tidak memiliki akses ke repositori privat, Anda dapat melewati clone dan build software yang belum dipublikasikan dengan OXIDE_STAFF=no gmake setup

Lingkungan Awal dan Konfigurasi Awal

  • Ini adalah prosedur untuk kasus ketika Anda ingin membangun dan menginstal paket OS sendiri; jika tujuannya hanya menggunakan Helios, alurnya adalah merujuk ke informasi software Helios yang sudah dibangun sebelumnya di helios-engvm
  • Titik awal yang direkomendasikan adalah mesin build fisik atau virtual dengan Helios terbaru terinstal
    • Detail instalasi mesin virtual ada di helios-engvm
    • Informasi media instalasi untuk sistem x86 fisik juga ada di repositori yang sama
  • Jika Anda membuat VM dengan prosedur helios-engvm, paket yang diperlukan seharusnya sudah terinstal
  • Jika Anda membuat lingkungan Helios dengan installer ISO atau cara lain, paket pkg:/developer/illumos-tools mungkin diperlukan
    • Periksa apakah sudah terinstal dengan pkg list developer/illumos-tools
    • Jika belum ada, instal dengan pkg install
  • Disarankan menggunakan paket Helios terbaru, dan setelah pkg update Anda harus memeriksa instruksi yang ditampilkan
    • Jika pembaruan memberi tahu bahwa boot environment baru telah dibuat, aktifkan dengan reboot lalu lanjutkan
  • Rust dan Cargo diinstal sebagai biner resmi proyek Rust melalui rustup
    • Dalam prosedur instalasi resmi, gunakan bash alih-alih sh
    • Contoh perintahnya adalah curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

Clone Repositori dan helios-build

  • Setelah meng-clone repositori di mesin Helios, jalankan gmake setup
    • Alat helios-build berbasis Rust akan dibangun di tools/helios-build
    • Beberapa repositori akan di-clone di bawah projects/
  • Jika tidak memiliki akses ke repositori privat organisasi GitHub oxidecomputer, Anda dapat menggunakan hanya repositori publik seperti berikut
    • OXIDE_STAFF=no gmake setup
  • Alat helios-build dapat memerlukan waktu pada build pertama
  • Tahap konfigurasi awal meng-clone repositori proyek yang diperkirakan, tetapi operasi selanjutnya seperti update atau pergantian branch hanya dilakukan pada sebagian repositori
    • Repositori mana yang menjadi target update otomatis dapat dilihat di auto_update dalam config/projects.toml
    • Clone lokal lainnya harus dikelola sendiri seperti repositori Git biasa untuk pergantian branch dan pull

Cara Build illumos

  • Komponen OS inti Helios berasal dari branch stlouis illumos-gate
  • Paket yang termasuk dalam sistem Helios sebagian besar berupa stock illumos dengan tambahan untuk hardware Oxide dan beberapa transformasi packaging kecil
  • helios-build menyediakan sejumlah wrapper yang mengelola konfigurasi build dan memanggil alat build illumos agar build illumos lebih mudah
  • Dokumentasi upstream illumos Building illumos mencakup sebagian besar pekerjaan yang dilakukan oleh alat Helios sebagai pengganti
  • Selama pengembangan, quick build dapat dilakukan dengan perintah berikut
    • ./helios-build build-illumos -q
    • quick build menonaktifkan shadow compiler dan beberapa pemeriksaan yang diperlukan pada integrasi final
  • Waktu build bergantung pada jumlah CPU mesin build dan performa storage lokal
  • Log build lengkap berukuran besar; misalnya dapat dilihat dengan tail -F projects/illumos/log/nightly.log
  • Jika build berhasil, repositori paket akan dibuat di projects/illumos/packages/i386, lalu dapat dikonversi dan diinstal dengan beberapa cara

Instalasi dan Distribusi Paket yang Dibuild

  • Instalasi ke mesin build lokal

    • Paket yang baru dibuild dapat diinstal ke mesin build dengan ./helios-build onu -t my-be-name
    • Perintah ini mengonversi dan menginstal paket illumos, serta membuat Boot Environment baru dengan nama yang diberikan lewat -t
    • Boot environment baru diaktifkan oleh onu, dan pengguna masuk ke lingkungan tersebut setelah reboot
    • Untuk informasi boot environment, lihat beadm(8)
    • Saat reboot, sebaiknya berada di konsol agar dapat melihat pesan boot dan berinteraksi dengan boot loader
    • Setelah instalasi, pkg list -Hv system/kernel dapat memastikan bahwa paket system/kernel berasal dari publisher on-nightly berbasis file lokal dan versi quick build 3.0.999999

  • Instalasi ke mesin lain sebagai server repositori paket

    • Jika ada mesin uji terpisah dari mesin build, Anda dapat menggunakan server repositori paket pkg.depotd pada mesin build
    • ./helios-build onu -D mengonversi paket dari build terbaru dan memulai server paket
    • Dalam contoh, layanan berjalan di 0.0.0.0:7891
    • Server terus berjalan hingga Control-C atau metode penghentian lain
    • Di mesin target, periksa koneksi ke mesin build dengan pkgrepo info -s http://genesis:7891
    • Sistem stock Helios secara default memiliki satu publisher helios yang menggunakan repositori pusat https://pkg.oxide.computer/helios/3/dev/
    • Di mesin uji, tambahkan publisher on-nightly, atur sebagai target pencarian pertama, dan longgarkan aturan sticky pada publisher helios yang ada
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • Tergantung situasinya, paket meta entire mungkin perlu dihapus sebelum update
    • Ini terutama dapat berlaku jika ada zone berbasis brand lipkg
    • Alat onu stock illumos melakukan ini secara otomatis
    • Jalankan dry-run dengan pkg update -nv untuk memastikan update menuju paket quick build
    • Dalam contoh, 325 paket diperbarui, dan diperlukan pembuatan serta aktivasi boot environment baru, serta rebuild boot archive
    • Versi berubah dari versi stock Helios berbasis nomor commit branch stlouis menjadi versi quick build 3.0.999999
    • Update sebenarnya dilakukan dengan pkg update -v; jika berhasil, Anda harus reboot ke boot environment baru
    • Setelah reboot, konfigurasi publisher tetap bertahan
    • Setelah itu, Anda dapat mengulangi alur build baru, restart server paket, dan pkg update -v di mesin uji

  • Hanya membuat paket tanpa instalasi

    • ./helios-build onu -P hanya melakukan konversi paket hasil quick build tanpa menginstalnya
    • Repositori paket yang dikonversi dibuat di tmp/onu/repo.redist
    • Cara ini berguna untuk memeriksa isi repositori 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*'
    • File paket juga dapat disimpan untuk membandingkan output beberapa build, dikirim ke sistem remote, atau digunakan untuk instalasi berikutnya

Pekerjaan Perubahan dan Build Berulang

  • Pekerjaan perubahan sistem umumnya sebaiknya dimulai dari workspace build yang bersih setelah quick build
  • Untuk mengubah file sumber tertentu dan membangun ulang komponen, masuk terlebih dahulu ke lingkungan build dengan bldenv
    • ./helios-build bldenv -q
    • Shell interaktif baru akan dimulai dan PATH serta variabel lain akan diatur dengan benar
  • Masuk ke direktori komponen dan jalankan perintah seperti dmake -S -m serial install untuk membuild dan menginstal
    • Contohnya adalah membuild perintah id di cmd/id dan menginstalnya ke area proto
  • Cara targeted incremental edit-and-recompile seperti ini cocok untuk memastikan perubahan dapat dikompilasi dalam siklus singkat

  • Opsi paling benar tetapi lambat

    • Anda dapat membuild ulang seluruh OS
    • Proses ini adalah satu-satunya prosedur yang menjamin hasil benar sejauh memungkinkan
    • Jika muncul masalah yang tidak dapat dijelaskan dalam cara incremental, sebaiknya coba full build terlebih dahulu
    • Perintahnya adalah ./helios-build build-illumos -q

  • Opsi cepat tetapi tanpa jaminan

    • Jika biner di area proto telah diperbarui dengan dmake install, Anda dapat membuat ulang hanya paket dan menginstalnya tanpa full build
    • Di dalam bldenv, pindah ke $SRC/pkg dan jalankan dmake install
    • Setelah itu, mulai server repositori paket dengan paket yang diperbarui atau lakukan instalasi lokal

  • Opsi menangani file system secara langsung

    • Pada akhirnya, sistem operasi adalah kumpulan file di dalam file system, jadi cara di luar alat packaging juga memungkinkan
    • Anda dapat menjalankan biner yang dimodifikasi langsung di sistem build, atau menyalinnya ke sistem uji dengan scp atau rsync lalu menjalankannya
    • Ini mungkin tidak berfungsi jika biner memerlukan perubahan library atau kernel
    • Anda dapat membuat boot environment baru dan menyesuaikan file di dalamnya
    • Boot environment adalah file system ZFS terpisah yang dapat dimodifikasi, di-snapshot, di-clone, dan di-boot
    • beadm create, beadm mount, dan beadm activate dapat digunakan
    • Anda dapat membuat disk image atau ramdisk yang sepenuhnya baru dan mem-boot-nya lewat VM atau PXE
    • Alat pembuatan image khusus Helios ada di alat image helios-engvm
    • Alat ini dapat menyertakan paket quick build atau file tambahan arbitrer melalui modifikasi template image
    • Dasarnya adalah illumos/image-builder upstream

Arsip Image OS

  • Dalam proses build OS image untuk Oxide compute sled, sebuah image archive dibuat
  • Arsip ini mencakup boot ROM dan image ramdisk root file system
  • Arsip juga menyertakan metadata dalam file JSON, dan menggunakan format seperti omicron1 brand
  • Isi file adalah committed interface antara Helios dan bagian dari Omicron yang harus mengunduh dan menginstal OS image ke sistem fisik Oxide Rack
  • File minimum yang diperlukan untuk penggunaan Omicron mencakup hal berikut
    • oxide.json: file header metadata dengan minimal kunci v=1 dan kunci t=os untuk identifikasi OS image
    • image/rom: host boot ROM image 32MiB
    • image/zfs.img: image ramdisk host root file system dengan ukuran arbitrer
  • Mungkin ada file tambahan untuk tujuan engineering atau diagnostik
    • Contoh: kernel terkompresi unix.z untuk bldb atau nanobl-rs, boot archive terkompresi cpio.z
    • Array file ROM tambahan dengan suffix yang menunjukkan fungsi diagnostik berbeda
  • File tambahan bukan committed interface dan dapat berubah kapan saja di masa mendatang
  • Software yang menafsirkan image archive harus mengabaikan file yang tidak dikenali

Lisensi

  • Hak cipta dimiliki oleh 2026 Oxide Computer Company
  • Kecuali dinyatakan lain, semua komponen dilisensikan di bawah Mozilla Public License Version 2.0

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-30
Komentar Hacker News

  • Senang ini dirilis ke publik, dan saya berencana menerapkannya secara lokal untuk belajar sebanyak mungkin
    Oxide terasa hampir seperti perusahaan impian, baik dari sisi stack teknologinya maupun orang-orang yang bekerja di sana

    • Setelah melihat sekilas halaman utamanya sekitar 20 detik, kesannya “apakah ini integrasi vertikal untuk membeli server on-premises? Sampai sistem operasi kustom juga? Kenapa harus membayar premium?”
      Namun tak lama kemudian pikiran saya berlanjut ke “memangnya apa yang dilakukan sistem operasi server? Bukankah cukup menjalankan mesin virtual saja? Yang dibutuhkan bukan harus Linux, melainkan bisa menjalankan mesin virtual Linux, bukan?”
    • Saya penasaran bagaimana perbandingannya dengan SmartOS
      Saya sudah cukup banyak berinvestasi pada SmartOS di infrastruktur pribadi, tetapi setelah akuisisi Joyent, saya khawatir soal masa depannya
      Andai saja saya bekerja di organisasi yang cukup besar untuk memakai perangkat Oxide. Rasanya akan luar biasa kalau tidak perlu lagi mengutak-atik konstruksi kompatibilitas ala IBM PC AT palsu, BMC dan iDRAC yang berantakan, serta kontroler RAID hardware
    • Oxide mungkin satu-satunya perusahaan yang benar-benar ingin saya masuki
      Dari luar, rasanya mirip Sun, dan perusahaan seperti itulah yang selalu saya impikan
      Namun sebagai orang yang harus menafkahi keluarga, struktur gajinya tidak memungkinkan. Mungkin setelah anak saya lulus kuliah dan saya tidak lagi perlu penghasilan besar, barulah mimpi itu bisa terwujud

  • Bisa jelaskan seperti kepada anak 5 tahun, apa yang sebenarnya ditawarkan Oxide? Setelah melihat situs webnya pun saya belum mendapat gambaran
    Saya tidak tahu apakah ini hardware+software yang dibeli lalu dipakai on-premises, PaaS, atau penyedia cloud lain

    • Sepertinya Anda mendapat downvote karena sudah ada thread besar terkait ini, tetapi itu terasa agak tidak adil
      Singkatnya, ya. Ini adalah hardware+software yang dibeli lalu dipakai on-premises
      Pembeda dari sebagian besar produk cloud on-premises yang ada adalah bahwa ini satu vendor yang merancang hardware dan software agar bekerja dengan baik bersama. Software-nya dibuat seopen-source mungkin, dan karena itulah pengumuman seperti ini muncul
      Kebanyakan produk menggabungkan produk dari beberapa vendor dan pada praktiknya menjual integrasi. Oxide melihat pendekatan seperti itu menimbulkan berbagai masalah, dan produk mereka menyelesaikan masalah tersebut
      Hal lainnya adalah SKU-nya hanya ada dua. Hanya ada half rack dan full rack, jadi belinya per rack, bukan per unit 1U
      Jika seluruh rack dirancang sebagai satu unit yang kohesif, Anda bisa melakukan hal-hal yang mustahil dalam form factor 1U. Ada lelucon bahwa mereka selalu membahas kipas, dan itu benar. Karena memakai sled yang lebih besar daripada 1U tradisional, mereka bisa menggunakan kipas yang lebih besar, menjalankannya pada RPM rendah, dan menghemat daya
      Itu adalah pilihan desain yang disengaja, tetapi ada juga efek sampingnya. Berkat RPM rendah, server menjadi jauh lebih senyap. Bahkan ada calon pelanggan awal yang saat demo bertanya, “ini benar-benar menyala?”
      Orang tentu tidak membeli server hanya karena senyap, tetapi ini contoh menarik dari hal yang muncul ketika produk dipikirkan ulang secara menyeluruh, bukan sekadar pekerjaan integrasi
    • Ini adalah solusi komputasi dan penyimpanan yang sepenuhnya terintegrasi untuk on-premises, menyediakan resource melalui API bergaya cloud, sekaligus disertai komitmen terhadap open source

  • Saya tahu orang-orang Oxide berasal dari Sun, tetapi apakah ada keuntungan teknis nyata dari memilih sesuatu yang bukan Linux dalam hal proposisi nilai bisnis?
    Saya tahu ada bagian-bagian illumos yang secara teknis lebih baik daripada Linux, tetapi saya tidak tahu apakah itu benar-benar penting bagi pelanggan yang membelinya
    Rasanya seperti membuka masalah rumit yang, karena ideologi atau tradisi, bisa menghambat penjualan lebih banyak komputer
    Dari sudut pandang mengoperasikan workload kontainer Linux, fakta bahwa ini pada dasarnya bukan Linux bukanlah alasan untuk membeli, melainkan alasan untuk ragu membeli. Saya tahu ini bisa menjalankan binary Linux tanpa modifikasi

    • Dalam produk, pendekatannya bukan seperti mengatakan “sekadar info, di dalamnya ada illumos, jadi Anda harus membeli rack ini”
      Itu bukan detail produk yang terlihat oleh pelanggan, dan kemungkinan besar kebanyakan bahkan tidak akan tahu fakta tersebut
      Yang dipedulikan pelanggan adalah apakah rack itu efisien, stabil, dan sesuai kebutuhan mereka. Di sini, memilih illumos alih-alih Linux adalah pilihan untuk memberikan nilai tersebut secara efektif
      Tentu bukan berarti produk serupa tidak bisa dibuat di atas Linux; kami menilai illumos lebih sesuai dengan tujuan kami
      Keputusan ini kami ambil bersama tim dalam bentuk RFD[1], dan meski nomornya #26, saat ini dokumennya belum dipublikasikan. Opsi yang kami pertimbangkan serius adalah KVM di Linux dan bhyve di illumos, dan dokumennya cukup panjang
      Pada akhirnya kami harus memilih satu jalur, dan kami memilih jalur ini. Meski saya tidak mengembangkan bagian ini secara langsung, sejauh ini tidak ada alasan untuk menganggapnya sebagai penghalang; justru kemungkinan besar ini pilihan yang tepat
      Saya penasaran mengapa fakta bahwa ini bukan Linux menjadi alasan untuk menolak pembelian. Akan bagus jika Anda bisa menjelaskan lebih lanjut. Ah, saya sudah melihat komentar di bawah: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios hanyalah detail implementasi rack, dan bukan elemen yang terlihat oleh pengguna atau aplikasi, seperti Hubris[0]. Pengguna rack melakukan provisioning mesin virtual
      Mengapa kami memakai turunan illumos dan bukan yang lain sedikit dibahas dalam Q&A[1] saat kami mengirim rack pertama, dan akan kami jelaskan lagi dalam diskusi rekaman[2] nanti hari ini
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • Di ranah embedded atau appliance, Linux mudah berubah menjadi mimpi buruk
      Para platform engineer menghabiskan hari mereka memperbaiki masalah kernel terbaru, driver, dan library inti, sementara aplikasi sebenarnya kemudian bergantung di atasnya
      Atau mereka memilih jalan seperti 99% vendor IoT: tidak pernah memperbarui sistem operasi dasar, lalu berdoa semoga tidak ada exploit aktif yang menargetkannya
      Itulah sebabnya banyak perusahaan menengah sangat terpukul oleh masalah CentOS. Tanpa harus membayar dan menjalankan instalasi RHEL penuh, mereka bisa tetap berada di platform yang relatif stabil sambil menerima pembaruan keamanan
      Kira-kira setiap 10 tahun mereka tetap harus meninjau ulang semua dependensi, tetapi itu jauh lebih mudah daripada mengikuti siklus pembaruan 1–2 tahun. Untuk sebagian sistem, periode validasinya saja lebih dari 6 bulan, sehingga siklus itu terlalu pendek
      Ini hampir merupakan masalah khusus Linux, dan alternatif seperti *BSD menyediakan sebagian besar hal yang diberikan Linux, tetapi dengan jauh lebih sedikit kerusakan berkelanjutan semacam ini
    • Adanya pilihan itu sehat, dan bahkan terasa seperti semesta sedikit pulih setelah Oracle membeli Sun
      Sulit membayangkan orang-orang yang lebih baik daripada tim ini untuk menyatukan sistem Oxide
      Saat ini saya engineer yang bekerja hanya dengan Linux, tetapi saya merindukan masa ketika ada satu lagi Unix yang kuat untuk menjalankan workload bernilai tinggi
      Jika membandingkan openvswitch di Linux dengan fitur Crossbow SDN di Solaris, saya akan memilih Crossbow kapan pun
      Bukan berarti Linux itu salah, tetapi tool-toolnya berjalan di jalurnya masing-masing dan menciptakan kompleksitas, lalu harus diabstraksikan lagi dengan tool yang lebih kompleks di atasnya; kohesi setingkat “master plan” sangat kurang
    • Pelanggan menjalankan sistem operasi tervirtualisasi di atas ini
      Tidak terlalu berbeda dari Azure Host OS, Bottlerocket, atau Flatcar
      Yang penting adalah mereka memahami seluruh stack, sebagian kode kernel sudah mereka miliki sejak masa Sun, dan bagi pelanggan yang menginginkan akses source karena penilaian keamanan, mereka bisa membukanya

  • Karena saya tidak begitu mengenal illumos, saya melihat halaman webnya dan di bagian paling awal tertulis “illumos is a Unix operating system”
    Apakah illumos benar-benar Unix seperti macOS, atau sistem operasi turunan Unix seperti GNU/Linux?

    • Benar-benar Unix. Penjelasan Wikipedia cukup bagus: https://en.wikipedia.org/wiki/Illumos
      Berbasis OpenSolaris, dan OpenSolaris berbasis System V Release 4(SVR4) serta Berkeley Software Distribution(BSD). Illumos terdiri dari kernel, driver perangkat, pustaka sistem, dan perangkat lunak utilitas untuk administrasi sistem. Core ini menjadi dasar bagi berbagai distribusi Illumos open source, mirip seperti kernel Linux menjadi dasar bagi berbagai distribusi Linux
    • Tidak ada yang membayar untuk menjalani uji sertifikasi Unix Branding dari Open Group
      https://www.opengroup.org/openbrand/register/
      Jadi merek dagang UNIX™ tidak bisa dipakai
      Namun di dalamnya ada kernel AT&T Unix dan source userspace
      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...
    • Secara hukum, NetBSD juga bukan Unix sungguhan. Brand itu tidak punya makna seperti yang dibayangkan orang-orang
    • Itu adalah cabang open source Solaris yang dikerjakan Ian Murdock di Sun dengan nama Project Indiana, dan diturunkan dari UNIX SVR4
    • Benar-benar Unix. Sejauh yang saya tahu, masih satu garis dengan Solaris

  • Bukannya saya tidak mendukung Oxide, tetapi produknya masih terlalu niche dan tahap awal, jadi sulit membayangkan perusahaan sungguhan akan membelinya untuk sementara waktu
    Mereka baru mengirim rack pertama ke pelanggan pertama pada akhir musim panas lalu, dan pelanggan itu pun Idaho National Laboratory
    Tempat yang bisa mengambil taruhan seperti ini sekarang tampaknya praktis hanya lembaga riset nasional

    • Saat pengumuman Oktober tahun lalu, ada dua pelanggan yang disebutkan: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Pelanggan Oxide mencakup Idaho National Laboratory dan sebuah organisasi layanan keuangan global. Instalasi tambahan untuk perusahaan Fortune 1000 juga dijadwalkan selesai dalam beberapa bulan mendatang
    • Semua produk pada masa awal keberadaannya memang seperti ini
      Kalau Anda berencana meluncurkannya dengan cara lain, berarti Anda sudah merusak perusahaan bahkan sebelum peluncuran. Ada segelintir yang beruntung dan bertahan, tetapi itulah yang berkontribusi pada statistik bahwa 9 dari 10 startup gagal
      Anda harus sangat fokus pada kelompok pelanggan pertama untuk menyeberangi chasm, baru setelah itu masuk ke pasar massal
    • Saya berharap suatu saat mereka juga merilis produk homelab yang lebih kecil dan murah
      Orang-orang bisa belajar atau startup bisa mencobanya, lalu nantinya berujung pada penjualan rack atau perekrutan
    • Saya bekerja di perusahaan teknologi yang baru-baru ini go public, dan saat mengevaluasi on-premises kami serius mempertimbangkan Oxide
      Tawaran itu juga bisa diterima oleh orang-orang yang masih berpikir “on-premises... ih”
      Kelihatannya mereka memberikan pengalaman seperti cloud di atas hardware milik sendiri
      Andai saja harganya semurah Dell
    • Perusahaan kami juga mengevaluasinya dan sangat terkesan dengan produknya
      Satu-satunya masalah adalah produk itu dibuat untuk komputasi serbaguna, sementara kami benar-benar membutuhkan opsi prosesor yang lebih cepat

  • Saya sangat suka dokumentasinya terlihat jelas dan intuitif. Secara pribadi, menurut saya dokumentasi adalah area yang secara historis menjadi kesulitan bagi komunitas illumos
    Melihat pembahasan consolidations di rilis source baru ini memberi rasa hangat. Namun, kecuali saya salah besar memahami susunan repositorinya, ini tampaknya mengarah berbeda dari paradigma gate tradisional
    Ada beberapa pertanyaan, terutama terkait tooling. Mengapa gmake? Nantinya dmake sepertinya tetap akan dibutuhkan juga
    Di panduan, rustup secara eksplisit dijalankan dengan bash; apakah ini defect upstream, atau sh lokal tidak sepenuhnya kompatibel POSIX?
    Bagaimana pengembangan internal dilakukan? Apakah orang-orang Oxide memakai workstation illumos, atau semuanya mengembangkan di virtual machine atau SSH ke server?
    Mengapa MPL? Karena kompatibilitas GPL?

    • Saya tidak bekerja langsung di helios, jadi tidak bisa menjawab semuanya, tetapi beberapa bisa saya jawab
      Soal apakah orang-orang Oxide memakai workstation illumos, atau mengembangkan lewat virtual machine atau SSH server, saya menulisnya di sini: https://news.ycombinator.com/item?id=39181727
      Namun memang ada juga orang yang benar-benar memakai illumos di workstation
      Soal MPL ada di sini: https://news.ycombinator.com/item?id=39181844
      Di komentar itu saya tidak membahas “mengapa” secara mendalam, tetapi menurut saya itu kompromi yang baik dalam ruang kemungkinan. Lebih copyleft daripada BSD, tetapi tidak seketat GPL
    • Setahu saya itu masalah upstream
      Seperti kebanyakan proyek open source, di sana juga ada Linuxism/Bashism
    • Karena alasan historis, dmake dipakai saat membangun sistem operasi inti, tetapi saat membuat Makefile baru di consolidation lain, biasanya GNU make(gmake) lebih disarankan
      Ia tersedia luas, bisa digunakan di platform lain, dan memiliki fitur yang lebih modern

  • Bagus bahwa perangkat lunaknya open source, tetapi apakah bisa dideploy dan digunakan di perangkat keras lain?
    Jika karena alasan apa pun perusahaan tidak lagi bisa membeli rack Oxide, apakah infrastrukturnya harus dimulai ulang dari nol, atau masih bisa terus dikembangkan dengan berpusat pada perangkat keras Oxide?

    • Kemungkinan langsung berguna di luar perangkat keras kami tidak terlalu besar, tetapi fungsi utamanya adalah deployment mesin virtual
      Jika memutuskan untuk tidak lagi memakai rack Oxide yang sudah dibeli, cukup pindahkan mesin virtual ke infrastruktur penerus yang dipilih

  • Saya benar-benar penasaran workload apa yang ingin dijalankan perusahaan di Unix kustom yang bukan Linux/Mac/BSD
    Saya mendukung munculnya keragaman sistem operasi yang lebih matang, tetapi belum terbayang siapa pengguna akhirnya dan kebutuhan seperti apa yang mereka miliki

    • Compute yang diprovision di rack Oxide adalah mesin virtual. Kami mem-port bhyve dari FreeBSD dan juga menambahkan live migration
      Kalau memang sangat perlu, sepertinya Windows Server juga bisa di-boot
      Alasan memakai Illumos memang sebagian karena ada bias alami, karena banyak orang berasal dari Sun, Joyent, dan sebagainya
      Namun ada juga alasan yang cukup meyakinkan: ini bukan komputer pribadi x86 kompatibel IBM. Tidak ada BIOS, tidak ada UEFI, tidak ada BMC tradisional, dan meski memakai x86 modern, tampaknya firmware proprietary dan binary blob disingkirkan sebanyak mungkin
      Setiap sled memiliki service processor dan hardware root of trust, yang langsung mem-boot CPU, memuat AMD training blob, lalu mem-boot sistem operasi
      Akan sulit meng-upstream perubahan seperti itu ke Linux atau BSD untuk komputer yang saat ini hanya mereka miliki. Pada akhirnya mereka harus memelihara fork downstream sendiri, dan tidak ada pihak lain yang akan bertanggung jawab atas ketangguhan sistem operasi, jadi masuk akal untuk memakai sistem operasi yang sudah mereka dukung dan kembangkan selama bertahun-tahun
    • Ini bukan detail produk yang terlihat oleh pengguna
      Pelanggan menjalankan mesin virtual di rack, bukan membangun aplikasi untuk illumos
      Mereka akan menjalankan sistem operasi apa pun yang diperlukan di dalam mesin virtual itu untuk mencapai tujuan mereka
    • ZFS bersifat native di illumos, dan fitur-fitur seperti yang setara dengan containerization juga cukup bagus
      Jika bisa merekrut cukup banyak orang, argumen bahwa server-server di cloud tidak harus memakai sistem operasi yang sama juga cukup meyakinkan
    • Mereka bahkan mungkin tidak akan tahu bahwa ini bukan Linux
      Anda tidak menjalankan kode di atas sistem operasi ini, melainkan di atas mesin virtual yang disediakan oleh sistem operasi ini

  • Penasaran bagaimana orang pertama kali tahu tentang Oxide
    Saya kebetulan sampai ke podcast mereka, dan bagi saya rasanya seperti marketing yang sangat kuat. Mereka melakukan semuanya kecuali menjual produk secara langsung
    Mungkin bagus juga kalau di akhir tiap episode ada pitch singkat
    Ceritanya sering dimulai dari “sulit sekali membuat compiler melakukan sesuatu”, lalu mengalir ke cerita lama
    Meski begitu, saya berharap mereka terus bercerita, dan semoga sukses

    • On The Metal, yang awalnya adalah podcast, terkenal karena terlalu sering mengulang 2–3 promosi diri yang sudah direkam sebelumnya, sampai-sampai seorang penggemar merekam iklan sendiri dan meminta mereka memutarnya
      Sebaliknya, Oxide and Friends lebih seperti rekaman “space” live atau group call yang dimulai di Twitter dan sekarang berlangsung di Discord, daripada podcast tradisional
      Menurut saya format ini paling pas dinikmati dengan ikut secara live, bukan hanya didengarkan sebagai podcast. Kalau mendengarkan live, suasana rekamannya akan jauh lebih mudah dipahami
      https://oxide.computer/podcasts/oxide-and-friends
    • Dulu saya mengikuti @jessfraz di Twitter, jadi saya tahu dari sana ketika Oxide pertama kali diumumkan
    • Saya tahu ketika Oxide pertama kali diumumkan dan Pentagram memublikasikan branding-nya

  • Saya sudah menantikan ini sejak mereka mengumumkan rack server
    Kalau Oxide bangkrut, tidak ada yang mau peralatannya berubah menjadi pemberat kertas

    • Untuk memperjelas, “masalah pemberat kertas” itu juga sangat penting bagi kami
      Perlu diingat bahwa MPL tidak mempersoalkan apakah salinannya tersedia secara publik di GitHub atau tidak
      Saya bukan pengacara, tetapi terlepas dari apakah non-pelanggan bisa melihat kodenya, ada kewajiban berdasarkan MPL terhadap pelanggan