Helios: Oxide Rack'i çalıştıran illumos dağıtımı

 (github.com/oxidecomputer)
1 puan yazan GN⁺ 2024-01-30 | 1 yorum | WhatsApp'ta paylaş
  • Helios, Oxide Rack'i çalıştıran bir illumos dağıtımıdır ve bu en üst depo içindeki araçlar ile belgeler, birden fazla yazılım consolidation'ını bir araya getirerek tüm dağıtım derlemesini yönetir
  • Dağıtım, çekirdek işletim sistemi olarak illumos-gate stlouis branch'ini kullanır; buna Oxide donanımı için ek bileşenler ve bazı paketleme dönüşümleri eklenmiş stock illumos paketleri ağırlıktadır
  • Tüm bileşen depoları açık değildir; özel consolidation'lar OXIDE_STAFF=no gmake setup ile clone ve build hedeflerinden hariç tutulabilir
  • Kendi paket derlemeleri, güncel bir Helios ortamında rustup, gmake setup ve Rust tabanlı helios-build ile yapılır; geliştirme sırasında shadow compiler ve bazı kontrolleri kapatan bir quick build mümkündür
  • Derleme çıktısı yerel boot environment'a kurulabilir, pkg.depotd ile başka test sistemlerine dağıtılabilir ya da kurulum olmadan yalnızca dönüştürülmüş paket deposu oluşturulup incelenebilir

Helios'un rolü ve yapısı

  • Helios, Oxide Rack'i çalıştıran bir illumos dağıtımıdır
  • Tüm dağıtım birden fazla yazılım consolidation'ından oluşur ve bu en üst depo içindeki araçlar ile belgeler derlemeyi yönlendirir
  • Açık consolidation'lar şunları içerir
  • Henüz açılmamış consolidation'lar da vardır
    • amd-firmware: AMD CPU firmware binary blob'ları, ileride açılacak
    • chelsio-t6-roms: Chelsio T6 NIC firmware blob'ları, ileride açılacak
    • pilot: Oxide sistemleri için düşük seviyeli kontrol aracı, ileride açılacak
    • dmar-report: DRAM margining rapor oluşturucusu, ileride açılacak
  • Özel depolara erişiminiz yoksa OXIDE_STAFF=no gmake setup ile henüz açılmamış yazılımların clone ve build adımlarını atlayabilirsiniz

Başlangıç ortamı ve ilk kurulum

  • Bu süreç, kendi OS paketlerini derleyip kurmak isteyenler içindir; yalnızca Helios kullanmak istiyorsanız helios-engvm içindeki önceden derlenmiş Helios yazılımı bilgilerine bakılan akış izlenir
  • Önerilen başlangıç noktası, üzerinde güncel Helios kurulu olan fiziksel veya sanal bir build makinesidir
    • Sanal makine kurulum ayrıntıları helios-engvm deposunda yer alır
    • Fiziksel x86 sistemler için kurulum medyası bilgisi de aynı depodadır
  • helios-engvm adımlarıyla bir VM oluşturduysanız gerekli paketler zaten kurulu olmalıdır
  • ISO yükleyici veya başka bir yöntemle Helios ortamı oluşturduysanız pkg:/developer/illumos-tools paketine ihtiyaç duyabilirsiniz
    • Kurulu olup olmadığı pkg list developer/illumos-tools ile kontrol edilir
    • Eksikse pkg install ile kurulur
  • Güncel Helios paketlerini kullanmanız önerilir; pkg update sonrasında çıkan yönergeleri kontrol etmelisiniz
    • Güncelleme yeni bir boot environment oluşturduğunu söylüyorsa, devam etmeden önce reboot ile bunu etkinleştirin
  • Rust ve Cargo, Rust projesinin resmi binary'leri rustup ile kurularak edinilir
    • Resmi kurulum adımlarında sh yerine bash kullanılır
    • Örnek komut: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

Depoyu clone etme ve helios-build

  • Helios makinesinde depo clone edildikten sonra gmake setup çalıştırılır
    • Rust tabanlı helios-build aracı tools/helios-build içinde derlenir
    • Birden fazla depo projects/ altına clone edilir
  • oxidecomputer GitHub organizasyonundaki özel depolara erişiminiz yoksa yalnızca açık depoları şu şekilde kullanabilirsiniz
    • OXIDE_STAFF=no gmake setup
  • helios-build aracının ilk derlemesi zaman alabilir
  • İlk kurulum aşaması beklenen proje depolarını clone eder, ancak daha sonraki güncelleme veya branch değiştirme gibi işlemler yalnızca bazı depolarda yapılır
    • Hangi depoların otomatik güncellendiği config/projects.toml içindeki auto_update alanından görülebilir
    • Diğer yerel clone'lar için branch değiştirme ve pull işlemlerini normal Git depolarında olduğu gibi sizin yönetmeniz gerekir

illumos derleme yaklaşımı

  • Helios'un çekirdek OS bileşenleri illumos-gate'in stlouis branch sürümünden gelir
  • Helios sistemine dahil edilen paketlerin çoğu, stock illumos üzerine Oxide donanımı için ek bileşenler ve bazı küçük paketleme dönüşümleri eklenmiş halidir
  • helios-build, illumos derlemesini kolaylaştırmak için build ayarlarını yönetir ve illumos build araçlarını çağıran çeşitli wrapper'lar sağlar
  • Yukarı akış illumos belgelerindeki Building illumos, Helios araçlarının sizin yerinize yaptığı işlerin çoğunu kapsar
  • Geliştirme sırasında aşağıdaki komutla quick build yapılabilir
    • ./helios-build build-illumos -q
    • quick build, son entegrasyonda gereken shadow compiler'ı ve bazı kontrolleri devre dışı bırakır
  • Derleme süresi, build makinesindeki CPU sayısına ve yerel depolama performansına göre değişir
  • Tam build log'u büyüktür; örneğin tail -F projects/illumos/log/nightly.log ile izlenebilir
  • Derleme başarılı olursa projects/illumos/packages/i386 altında bir paket deposu oluşur ve bu daha sonra çeşitli şekillerde dönüştürülüp kurulabilir

Derlenen paketleri kurma ve dağıtma

  • Yerel build makinesine kurulum

    • Yeni derlenen paketler ./helios-build onu -t my-be-name ile build makinesine kurulabilir
    • Bu komut illumos paketlerini dönüştürüp kurar ve -t ile verilen adla yeni bir Boot Environment oluşturur
    • Yeni boot environment onu tarafından etkinleştirilir ve kullanıcı yeniden başlatarak bu ortama geçer
    • Boot environment bilgileri için beadm(8) sayfasına bakın
    • Yeniden başlatma sırasında boot mesajlarını görmek ve gerekirse boot loader ile etkileşime girmek için konsol başında olmanız tavsiye edilir
    • Kurulumdan sonra pkg list -Hv system/kernel çıktısında system/kernel paketinin yerel dosya tabanlı on-nightly publisher'ından ve quick build sürümü 3.0.999999'dan geldiği görülebilir

  • Başka bir makineye paket deposu sunucusu olarak kurulum

    • Build makinesi dışında ayrı bir test makineniz varsa, build makinesindeki pkg.depotd paket deposu sunucusunu kullanabilirsiniz
    • ./helios-build onu -D, son derlemenin paketlerini dönüştürür ve paket sunucusunu başlatır
    • Örnekte hizmet 0.0.0.0:7891 üzerinde verilir
    • Sunucu Control-C veya başka bir sonlandırma yöntemi kullanılana kadar çalışmaya devam eder
    • Hedef makinede pkgrepo info -s http://genesis:7891 ile build makinesine erişim doğrulanır
    • Stock Helios sisteminde varsayılan olarak merkezi depo https://pkg.oxide.computer/helios/3/dev/ kullanan tek bir helios publisher bulunur
    • Test makinesinde on-nightly publisher'ı eklenir, aramada öncelikli yapılır ve mevcut helios publisher'ının sticky kuralı gevşetilir
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • Duruma göre güncelleme öncesinde entire meta paketinin kaldırılması gerekebilir
    • Bu özellikle lipkg brand tabanlı zone'lar varsa geçerli olabilir
    • Stock illumos içindeki onu aracı bunu otomatik yapar
    • pkg update -nv ile bir dry-run yaparak quick build paketlerine güncelleneceğini doğrulayın
    • Örnekte 325 paket güncellenir ve yeni bir boot environment oluşturulması, etkinleştirilmesi ve boot archive'ın yeniden derlenmesi gerekir
    • Sürüm, stlouis branch commit numarasına dayalı stock Helios sürümünden 3.0.999999 quick build sürümüne değişir
    • Asıl güncelleme pkg update -v ile yapılır; başarılı olursa yeni boot environment'a yeniden başlatılmalıdır
    • Yeniden başlatmadan sonra publisher ayarları kalıcı olur
    • Sonrasında yeni build, paket sunucusunu yeniden başlatma ve test makinesinde pkg update -v akışı tekrar edilebilir

  • Kurulum yapmadan yalnızca paket üretme

    • ./helios-build onu -P, quick build sonucu oluşan paketleri kurmadan yalnızca dönüştürür
    • Dönüştürülmüş paket deposu tmp/onu/repo.redist içinde oluşturulur
    • Bu yöntem, build deposunun içeriğini incelemek için kullanışlıdır
    • pkgrepo info -s tmp/onu/repo.redist
    • pkgrepo list -s tmp/onu/repo.redist
    • pkg contents -t file -s tmp/onu/repo.redist '*microcode*'
    • Paket dosyaları saklanarak birden fazla build çıktısı karşılaştırılabilir, uzak sistemlere aktarılabilir veya daha sonra kurulum için kullanılabilir

Değişiklik yapma ve yinelemeli derleme

  • Sistem üzerinde değişiklik yapmaya genelde quick build sonrasındaki temiz bir build workspace içinde başlamak en iyisidir
  • Belirli kaynak dosyalarını değiştirip bir bileşeni yeniden derlemek için önce bldenv ile build ortamına girilir
    • ./helios-build bldenv -q
    • Yeni bir etkileşimli shell açılır ve PATH ile diğer değişkenler doğru şekilde ayarlanır
  • Bileşen dizinine gidip dmake -S -m serial install gibi komutlarla derleme ve kurulum yapılabilir
    • Örnekte cmd/id içinde id komutu derlenip proto alanına kurulur
  • Bu hedefli artımlı düzenleme ve yeniden derleme yöntemi, kısa döngülerle değişikliğin derlenip derlenmediğini kontrol etmek için uygundur

  • En doğru ama yavaş seçenek

    • Tüm OS yeniden derlenebilir
    • Bu süreç, mümkün olan ölçüde doğru sonuç veren tek prosedürdür
    • Artımlı yöntemlerde açıklanamayan sorunlar çıkarsa önce full build denemek iyi bir fikirdir
    • Komut: ./helios-build build-illumos -q

  • Garantisi olmayan ama hızlı seçenek

    • dmake install ile proto alanındaki binary'leri güncellediyseniz, full build yapmadan yalnızca paketleri yeniden üretip kurabilirsiniz
    • bldenv içindeyken $SRC/pkg dizinine gidip dmake install çalıştırın
    • Ardından güncellenmiş paketlerle paket deposu sunucusunu başlatabilir veya yerel kurulum yapabilirsiniz

  • Dosya sistemini doğrudan kullanma seçeneği

    • İşletim sistemi sonuçta dosya sistemi içindeki dosyalardan oluşur; bu yüzden paketleme araçları dışındaki yöntemler de mümkündür
    • Değiştirdiğiniz binary'leri doğrudan build sisteminde çalıştırabilir ya da scp, rsync ile test sistemine kopyalayıp orada çalıştırabilirsiniz
    • Binary'nin kütüphane veya kernel değişikliklerine ihtiyaç duyması halinde bu işe yaramayabilir
    • Yeni bir boot environment oluşturup içindeki dosyaları düzenleyebilirsiniz
    • Boot environment; değiştirilebilen, snapshot alınabilen, clone edilebilen ve boot edilebilen ayrı bir ZFS dosya sistemidir
    • beadm create, beadm mount, beadm activate kullanılabilir
    • Tamamen yeni bir disk image veya ramdisk oluşturup bunu VM ya da PXE ile boot edebilirsiniz
    • Helios'a özgü image üretim araçları helios-engvm image tools içinde yer alır
    • Bu araçlar, quick build paketlerini veya ek dosyaları image template değişiklikleriyle dahil edebilir
    • Temelinde yukarı akış illumos/image-builder bulunur

OS image archive

  • Oxide compute sled'leri için OS image oluşturma sürecinde bir image archive üretilir
  • Bu archive, boot ROM ve root file system ramdisk image'larını içerir
  • Ayrıca bir JSON dosyasında metadata bulunur ve omicron1 brand ile aynı formatı kullanır
  • Dosya içeriği, Helios ile Oxide Rack'teki fiziksel sistemlere OS image indirip kurması gereken Omicron bileşenleri arasındaki committed interface'tir
  • Omicron kullanımı için gerekli dosyalar en azından şunları içerir
    • oxide.json: En az v=1 anahtarına ve OS image kimliği için t=os anahtarına sahip metadata header dosyası
    • image/rom: 32MiB host boot ROM image'ı
    • image/zfs.img: İsteğe bağlı boyutta host root file system ramdisk image'ı
  • Mühendislik veya tanılama amaçlı ek dosyalar bulunabilir
    • Örnek: bldb veya nanobl-rs için unix.z sıkıştırılmış kernel, cpio.z sıkıştırılmış boot archive
    • Farklı tanılama işlevlerini gösteren suffix'lere sahip ek ROM dosyası dizileri
  • Ek dosyalar committed interface değildir ve ileride herhangi bir zamanda değişebilir
  • Image archive'ı yorumlayan yazılımlar, tanımadığı dosyaları yok saymalıdır

Lisans

  • Telif hakkı 2026 Oxide Computer Company'ye aittir
  • Aksi belirtilmedikçe tüm bileşenler Mozilla Public License Version 2.0 ile lisanslanmıştır

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-30
Hacker News yorumları

  • Bunun kamuya açılmasına sevindim; yerelde dağıtıp mümkün olduğunca çok şey öğrenmeyi düşünüyorum
    Oxide, hem teknoloji yığını hem de birlikte çalıştığı insanlar açısından neredeyse hayalimdeki şirket gibi

    • Ana sayfaya 20 saniye kadar göz atınca “şirket içi sunucu satın almak için dikey entegrasyon mu? Özel işletim sistemi bile mi? Neden özellikle prim ödeyeyim ki?” gibi hissettim
      Ama kısa süre sonra düşünce şuna kadar ilerledi: “Sunucu işletim sistemi zaten ne yapıyor ki? Sadece sanal makine çalıştırması gerekmiyor mu? Mutlaka Linux gerekmez; Linux sanal makineleri çalıştırabilmesi yeterli değil mi?”
    • SmartOS ile karşılaştırınca nasıl olacağını merak ediyorum
      Kişisel altyapımda SmartOS’a epey yatırım yaptım ama Joyent’in satın alınmasından sonra geleceği konusunda endişeliydim
      Oxide ekipmanı kullanacak kadar büyük bir organizasyonda çalışıyor olmayı isterdim. Sahte IBM PC AT tarzı uyumluluk iskeletleriyle, derme çatma BMC ve iDRAC’larla, donanım RAID denetleyicileriyle uğraşmak zorunda kalmamak inanılmaz iyi olurdu
    • Oxide, gerçekten çalışmak isteyeceğim neredeyse tek şirket
      Dışarıdan bakınca Sun’a benziyor ve tam da böyle bir şirketin hayalini kuruyordum
      Ancak ailesini geçindirmesi gereken biri olarak maaş yapısı açısından bunu karşılayamam. Çocuğum üniversiteden mezun olup artık büyük bir gelire ihtiyaç kalmadığında, belki o zaman bu hayali gerçekleştirebilirim

  • Oxide’ın ne sunduğunu 5 yaşındaki birine anlatır gibi açıklayabilir misiniz? Web sitesine bakınca da kafamda oturmuyor
    Satın alıp şirket içinde kullandığınız donanım+yazılım mı, PaaS mi, yoksa başka bir bulut sağlayıcısı mı bilmiyorum

    • Zaten bununla ilgili büyük bir başlık olduğu için eksi oy alıyor gibisiniz ama bu biraz haksız görünüyor
      Kısa cevap: evet. Satın alıp şirket içinde kullandığınız donanım+yazılım
      Mevcut şirket içi bulut ürünlerinin çoğundan farkı, donanım ve yazılımı birlikte iyi çalışacak şekilde tasarlayan tek bir tedarikçi olması. Yazılımı mümkün olduğunca açık kaynak yapıyorlar; bu tür duyuruların çıkmasının nedeni de bu
      Ürünlerin çoğu, birden fazla tedarikçinin ürünlerini bir araya getirip aslında entegrasyon satıyor. Oxide, bu yaklaşımın birçok sorun doğurduğunu ve kendi ürününün bu sorunları çözdüğünü düşünüyor
      Bir diğer nokta da yalnızca iki SKU olması. Sadece yarım rack ve tam rack var; 1U birimler halinde değil, rack düzeyinde satın alıyorsunuz
      Tüm rack’i tek, bütünleşik bir birim olarak tasarladığınızda 1U form faktöründe mümkün olmayan şeyler yapabiliyorsunuz. Sürekli fanlardan bahsettiklerine dair bir şaka var ama bu doğru. Geleneksel 1U’dan daha büyük sled’ler kullandıkları için daha büyük fanlar kullanabiliyorlar ve daha düşük RPM’de döndürebildiklerinden güç tasarrufu sağlıyorlar
      Bu bilinçli bir tasarım tercihi ama yan etkileri de var. Düşük RPM sayesinde sunucular çok daha sessiz. İlk potansiyel müşterilerden bazıları demo sırasında “Bu gerçekten açık mı?” diye soracak kadar
      Sunucu satın alma nedeniniz yalnızca sessizlik olmayabilir, ama ürünü basit bir entegrasyon işi olarak değil, bir bütün olarak yeniden düşündüğünüzde ortaya çıkan ilginç bir örnek
    • Şirket içi kullanım için tamamen entegre bir compute·storage çözümü; kaynakları bulut tarzı API’lerle provision ediyor ve açık kaynağa yönelik bir taahhütle birlikte geliyor

  • Oxide çalışanlarının Sun kökenli olduğunu biliyorum, ama Linux olmayan bir şeyi seçmenin iş değeri önerisi açısından gerçek bir teknik avantajı var mı?
    illumos’un Linux’tan teknik olarak daha iyi olduğu yerleri biliyorum, ama bunu satın alan müşteri için bunun gerçekten önemli olup olmadığından emin değilim.
    İdeoloji ya da gelenek yüzünden daha fazla bilgisayar satmayı engelleyebilecek karmaşık bir sorunun kapısını aralamıyorlar mı diye düşünüyorum.
    Linux container iş yükleri işleten biri olarak, bunun temelde Linux dışı olması satın alma nedeni değil, satın almadan çekinme nedeni olur. Linux binary’lerini değiştirmeden çalıştırabildiğini biliyorum.

    • Üründe “bu arada içinde illumos var, bu yüzden bu rack’i satın almalısınız” deniyor gibi bir durum yok.
      Bu, müşteriye görünen bir ürün ayrıntısı değil; çoğu kişi muhtemelen bunun farkında bile olmayacak.
      Müşterinin önemsediği şey rack’in verimli, güvenilir ve ihtiyaçlarına uygun olup olmadığı. Burada Linux yerine illumos’u seçmek, bu değeri etkili biçimde sunmak için yapılmış bir tercih.
      Elbette benzer bir ürünün Linux üzerinde yapılamayacağı anlamına gelmiyor; biz illumos’un amaca daha uygun olduğuna karar verdik.
      Bu kararı ekiple birlikte RFD[1] biçiminde aldık; numarası #26, ancak şu anda herkese açık değil. Ciddi olarak değerlendirdiğimiz seçenekler Linux’un KVM’i ile illumos’un bhyve’ıydı ve oldukça uzun bir belge.
      Sonunda bir yol seçmek zorundaydık ve biz bu yolu seçtik. Bu kısmı doğrudan ben geliştirmiyorum, ancak şimdiye kadar bunun bir engel olduğuna dair bir neden görmedik; aksine doğru tercih olma ihtimali yüksek.
      Linux dışı olmasının neden satın almaya karşı bir gerekçe olduğunu merak ediyorum. Biraz daha açıklarsanız iyi olur. Ah, aşağıdaki yorumu gördüm: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios yalnızca rack’in bir uygulama ayrıntısı; Hubris[0] gibi kullanıcıların ya da uygulamaların gördüğü bir unsur değil. Rack kullanıcıları sanal makineler provision eder.
      Neden başka bir şey değil de illumos türevi kullandığımızı, ilk rack’i sevk ettiğimizde yaptığımız Q&A’de[1] biraz ele aldık; bugün daha sonra yapılacak kayıtlı tartışmada[2] da yeniden açıklayacağız.
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • Gömülü sistemler ya da appliance alanında Linux kolayca kâbusa dönüşebilir.
      Platform mühendisleri günlerini en yeni kernel, sürücü ve temel kütüphane sorunlarını düzeltmekle geçirir; gerçek uygulama da bunların üzerine bağımlı hale gelir.
      Ya da IoT satıcılarının %99’u gibi temel işletim sistemini asla güncellemez, onu hedef alan aktif exploit’ler olmamasını umarsınız.
      Bu yüzden orta ölçekli şirketler CentOS meselesi yüzünden çok sıkıntı yaşadı. Tam bir RHEL kurulumu işletmek için para ödemeden, nispeten kararlı bir platformda kalıp güvenlik güncellemeleri alabiliyorlardı.
      Yaklaşık her 10 yılda bir tüm bağımlılıkları yeniden gözden geçirmek gerekiyordu, ama bu 1-2 yıllık güncelleme döngülerini takip etmekten çok daha kolaydı. Bazı sistemlerde yalnızca doğrulama süresi 6 aydan fazla sürdüğü için bu döngü çok kısa kalıyor.
      Bu neredeyse Linux’a özgü bir sorun; *BSD gibi alternatifler Linux’un sunduğu şeylerin çoğunu sağlarken bu sürekli kırılmaları çok daha az yaşatıyor.
    • Seçeneklerin ortaya çıkması sağlıklı bir şey; Oracle Sun’ı satın aldıktan sonra evren biraz toparlanıyor gibi bile hissettiriyor.
      Oxide sistemini bir araya getirecek ekip olarak bundan daha iyi insanları hayal etmek zor.
      Şu anda yalnızca Linux ile çalışan bir mühendisim, ama yüksek değerli iş yüklerini çalıştırabilecek bir başka güçlü Unix’in olduğu günleri özlüyorum.
      Linux’taki openvswitch ile Solaris’in Crossbow SDN özelliklerini karşılaştırırsam her seferinde Crossbow’u seçerim.
      Linux’un yanlış olduğu anlamına gelmiyor, ancak araçlar kendi yollarına giderek karmaşıklık yaratıyor ve bunun üstünü yeniden daha karmaşık araçlarla soyutlamak gerekiyor; bu yüzden “master plan” düzeyinde bütünlük ciddi biçimde eksik.
    • Müşteriler bunun üzerinde sanallaştırılmış işletim sistemi çalıştırıyor.
      Azure Host OS, Bottlerocket, Flatcar gibi şeylerden pek farklı değil.
      Önemli olan, tüm stack’i biliyor olmaları, kernel kodunun bir kısmına Sun döneminden beri sahip olmaları ve güvenlik değerlendirmeleri nedeniyle kaynak erişimi isteyen müşterilere bunu açabilmeleri.

  • illumos’u pek bilmediğim için web sayfasına baktım; en başta “illumos is a Unix operating system” yazıyor
    illumos, macOS gibi gerçek bir Unix mi, yoksa GNU/Linux gibi Unix türevi bir işletim sistemi mi?

    • Gerçek Unix. Wikipedia açıklaması oldukça iyi: https://en.wikipedia.org/wiki/Illumos
      OpenSolaris tabanlı; OpenSolaris de System V Release 4(SVR4) ve Berkeley Software Distribution(BSD) tabanlı. Illumos; çekirdek, aygıt sürücüleri, sistem kütüphaneleri ve sistem yönetimi için yardımcı yazılımlardan oluşur. Bu çekirdek, Linux çekirdeğinin çeşitli Linux dağıtımlarına temel olması gibi, çeşitli açık kaynak Illumos dağıtımlarının temelini oluşturur
    • Kimse Open Group’un Unix Branding sertifikasyon testlerinden geçirmek için para ödemedi
      https://www.opengroup.org/openbrand/register/
      Bu yüzden UNIX™ markasını kullanamıyor
      Ama içinde AT&T Unix çekirdeği ve kullanıcı alanı kaynakları var
      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...
    • Hukuken NetBSD de gerçek Unix değil. O markanın insanların düşündüğü anlamı taşıdığı söylenemez
    • Sun’da Ian Murdock’ın Project Indiana adıyla üzerinde çalıştığı, Solaris’in açık kaynak bir dalıydı ve UNIX SVR4’ten geliyor
    • Gerçek Unix. Solaris ailesinden diye biliyorum

  • Oxide’ı desteklemiyor değilim ama ürün hâlâ çok niş ve erken aşamada; gerçek şirketlerin bir süre bunu satın alacağını hayal etmek zor
    İlk rack’i ilk müşterilerine ancak geçen yaz sonunda gönderdiler; o müşteri de Idaho National Laboratory
    Şu anda böyle bir kumarı oynayabilecek yerler fiilen ulusal araştırma kurumları gibi görünüyor

    • Geçen yıl ekim ayındaki duyuruda iki müşteriden söz edilmişti: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Oxide müşterileri arasında Idaho National Laboratory ve küresel bir finansal hizmetler kuruluşu yer alıyor. Fortune 1000 şirketlerine ek kurulumların da önümüzdeki aylarda tamamlanması bekleniyor
    • Varlığının erken dönemindeki her ürün zaten böyle görünür
      Farklı bir şekilde piyasaya çıkmayı planlıyorsan, daha çıkmadan şirketi batırmışsın demektir. Şans eseri hayatta kalan az sayıda örnek vardır ama bu da 10 startup’tan 9’unun başarısız olduğu istatistiğine katkıda bulunur
      İlk müşteri grubuna aşırı odaklanıp uçurumu geçmek gerekir; sonrası kitlesel pazardır
    • Umarım bir gün daha küçük ve ucuz bir homelab ürünü de çıkarırlar
      İnsanlar öğrenirken ya da startup’lar denerken, ileride rack satışlarına veya işe alıma dönüşebilir
    • Yakın zamanda halka açılmış bir teknoloji şirketinde çalışıyorum; on-prem’i değerlendirirken Oxide’ı ciddi şekilde düşündük
      Hâlâ “on-prem mi… ıyy” diye düşünen insanlara bile öneri işe yarıyor
      Kendi donanımınız üzerinde bulut benzeri bir deneyim sunuyor gibi görünüyor
      Keşke Dell kadar ucuz olsaydı
    • Bizim şirket de değerlendirdi ve üründen çok etkilendi
      Tek sorun, genel amaçlı compute için yapılmış olmasıydı; bizim gerçekten daha hızlı işlemci seçeneklerine ihtiyacımız vardı

  • Dokümantasyonun net ve sezgisel görünmesi gerçekten hoşuma gidiyor. Kişisel olarak illumos topluluğunun tarihsel olarak zorlandığı alanın dokümantasyon olduğunu düşünüyorum
    Yeni kaynak sürümünde consolidations anlatısını görmek içimi ısıtıyor. Ancak depo düzenini büyük ölçüde yanlış anlamıyorsam, geleneksel gate paradigmasından farklı bir yöne gidiyor gibi görünüyor
    Birkaç sorum var, çoğu araçlarla ilgili. Neden gmake? Sonradan dmake de zaten gerekecek gibi görünüyor
    Kılavuzda rustup’ın bash ile açıkça çalıştırılması söylenmiş; bu upstream bir kusur mu, yoksa yerel sh POSIX ile tam uyumlu değil mi?
    İç geliştirme nasıl yapılıyor? Oxide çalışanları illumos workstation mı kullanıyor, yoksa herkes sanal makinelerde mi geliştiriyor ya da sunuculara SSH ile mi giriyor?
    Neden MPL? GPL uyumluluğu yüzünden mi?

    • helios üzerinde doğrudan çalışmadığım için hepsini yanıtlayamam ama bazılarını yanıtlayabilirim
      Oxide çalışanlarının illumos workstation kullanıp kullanmadığı, sanal makine ya da sunucu SSH ile geliştirip geliştirmediği konusunda şurada yazmıştım: https://news.ycombinator.com/item?id=39181727
      Bununla birlikte illumos’u workstation’da gerçekten kullananlar da var
      MPL hakkında şurada var: https://news.ycombinator.com/item?id=39181844
      O yorumda “neden” kısmına derinlemesine girmedim ama olasılıklar alanında iyi bir denge olduğunu düşünüyorum. BSD’den daha copyleft, ama GPL’den daha az kısıtlayıcı
    • Bildiğim kadarıyla bu upstream bir sorun
      Çoğu açık kaynak proje gibi orada da Linuxism/Bashism var
    • Tarihsel nedenlerle çekirdek işletim sistemini derlerken dmake kullanılıyor, ama başka bir consolidation içinde yeni Makefile oluştururken genellikle GNU make(gmake) öneriliyor
      Yaygın olarak bulunabiliyor, başka platformlarda da kullanılabiliyor ve daha modern özellikleri var

  • Yazılımın açık kaynak olması harika, ama başka donanımlara dağıtılıp kullanılabilir mi?
    Şirket herhangi bir nedenle artık Oxide rack satın alamaz hâle gelirse altyapıya sıfırdan mı başlamak gerekir, yoksa Oxide donanımı etrafında genişlemeye devam edilebilir mi?

    • Kendi donanımımız dışında hemen faydalı olma olasılığı yüksek değil, ama temel işlevi sanal makine dağıtımıdır.
      Satın aldığınız Oxide rack'i artık kullanmamaya karar verirseniz sanal makineleri daha sonra seçtiğiniz altyapıya taşımanız yeterli.

  • Şirketlerin Linux/Mac/BSD olmayan özel bir Unix üzerinde ne tür iş yükleri çalıştırmak isteyeceğini gerçekten merak ediyorum.
    Daha olgun bir işletim sistemi çeşitliliği oluşmasını destekliyorum, ama son kullanıcının kim olacağını ve ne tür ihtiyaçları olacağını kestiremiyorum.

    • Oxide rack üzerinde sağlanan compute kaynakları sanal makinelerdir. FreeBSD'den bhyve'yi port ettiler ve canlı geçiş de eklediler.
      Mecbur kalınırsa Windows Server'ı da boot edebileceklerini düşünüyorum.
      Illumos kullanmalarının nedeni, Sun, Joyent vb. yerlerden gelen çok kişi olduğu için doğal bir eğilimlerinin olması; bu da doğru.
      Ama bunun IBM uyumlu x86 kişisel bilgisayar olmaması için de oldukça ikna edici bir gerekçe var. BIOS yok, UEFI yok, geleneksel BMC yok; modern x86 kullanırken de kapalı kaynak firmware'i ve ikili blob'ları mümkün olduğunca ortadan kaldırmış gibi görünüyorlar.
      Her sled'de bir servis işlemcisi ve donanımsal güven kökü var; bu doğrudan CPU'yu boot ediyor, AMD training blob'unu yüklüyor ve ardından işletim sistemini başlatıyor.
      Şu anda yalnızca kendilerinin sahip olduğu bir bilgisayar için bu tür değişiklikleri Linux'a veya BSD'ye upstream etmek zor olacaktır. Sonuçta kendi downstream fork'larını sürdürmeleri gerekecek; işletim sisteminin sağlamlığından sorumlu olacak başka bir taraf da olmadığından, yıllardır destekleyip geliştirdikleri işletim sistemini kullanmanın daha iyi olduğuna karar vermişler.
    • Bu, üründe kullanıcıya görünen bir ayrıntı değil.
      Müşteri rack üzerinde sanal makine çalıştırır; uygulamaları illumos için build etmez.
      Hedeflerine ulaşmak için hangi işletim sistemi gerekiyorsa onu o sanal makinenin içinde çalıştırır.
    • ZFS illumos'ta native'dir; containerization'a karşılık gelen özellikleri vb. de oldukça iyidir.
      Yeterli sayıda insan işe alabiliyorlarsa, buluttaki sunucuların mutlaka aynı işletim sistemini kullanması gerekmediği argümanı da ikna edici.
    • Bunun Linux olmadığını bilmeniz bile gerekmeyebilir.
      Kodunuzu bu işletim sistemi üzerinde değil, bu işletim sisteminin sağladığı sanal makineler üzerinde çalıştırırsınız.

  • Oxide'ı ilk nasıl öğrendiğinizi merak ediyorum.
    Ben bir şekilde podcast'lerine denk geldim; bana müthiş bir pazarlama gibi geliyor. Ürünü doğrudan satmak dışında her şeyi yapıyorlar.
    Her bölümün sonuna kısa bir satış konuşması eklemek de iyi olabilir.
    “Derleyicinin bir şey yapmasını sağlamakta gerçekten zorlandık” gibi şeylerden bahsedip sonra eski hikâyelere dalıyorlar.
    Yine de anlatmaya devam etmelerini istiyorum ve başarılı olmalarını umuyorum.

    • Aslen bir podcast olan On The Metal, önceden kaydedilmiş 2-3 kendini tanıtan reklamı aşırı tekrar etmesiyle kötü bir üne sahipti; hatta bir hayran reklamı kendisi kaydedip yayınlamalarını isteyecek noktaya gelmişti.
      Buna karşılık Oxide and Friends, geleneksel bir podcast'ten ziyade, Twitter'da başlayıp şimdi Discord'da yapılan canlı “space” veya grup görüşmesi kaydına daha yakın.
      Bence yalnızca podcast olarak dinlemekten çok, canlı katılındığında en iyi tüketilen bir format. Canlı dinleyince kayıtların havasını çok daha iyi anlıyorsunuz.
      https://oxide.computer/podcasts/oxide-and-friends
    • Eskiden Twitter'da @jessfraz'i takip ediyordum; Oxide ilk duyurulduğunda oradan öğrendim.
    • Oxide ilk duyurulduğunda Pentagram'ın markalamayı yayımladığını görerek öğrendim.

  • Sunucu rack'ini duyurdukları zamandan beri bunu bekliyordum.
    Oxide batarsa kimse kâğıt ağırlığına dönüşen ekipmanı istemezdi.

    • Açık konuşmak gerekirse, o “kâğıt ağırlığı sorunu” bizim için de çok önemli.
      MPL'nin, bir kopyanın GitHub'da herkese açık olarak bulunup bulunmadığıyla ilgilenmediğini hatırlamak gerekir.
      Avukat değilim, ama müşteri olmayanların kodu görüp görememesinden bağımsız olarak müşterilere karşı MPL kapsamında yükümlülükler var.