Helios: ดิสทริบิวชัน illumos ที่ขับเคลื่อน Oxide Rack

 (github.com/oxidecomputer)
1 คะแนน โดย GN⁺ 2024-01-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Helios คือดิสทริบิวชัน illumos ที่ขับเคลื่อน Oxide Rack โดยเครื่องมือและเอกสารในรีโพซิทอรีระดับบนสุดนี้จะรวม software consolidation หลายชุดเข้าด้วยกันเพื่อจัดการการบิลด์ดิสทริบิวชันทั้งหมด
  • ดิสทริบิวชันนี้ใช้ illumos-gate สาขา stlouis เป็น OS แกนหลัก และส่วนใหญ่จัดเตรียมแพ็กเกจ stock illumos ที่เพิ่มองค์ประกอบสำหรับฮาร์ดแวร์ Oxide และการแปลงแพ็กเกจบางส่วน
  • รีโพซิทอรีองค์ประกอบทั้งหมดไม่ได้เปิดเผยต่อสาธารณะ และสามารถยกเว้น consolidation แบบปิดจาก เป้าหมายการโคลนและการบิลด์ ได้ด้วย OXIDE_STAFF=no gmake setup
  • การบิลด์แพ็กเกจเองใช้สภาพแวดล้อม Helios ล่าสุด, rustup, gmake setup และ helios-build ที่ใช้ Rust และระหว่างพัฒนาสามารถทำ quick build ที่ปิด shadow compiler และการตรวจสอบบางส่วนได้
  • ผลลัพธ์การบิลด์สามารถติดตั้งลงใน boot environment ภายในเครื่อง, แจกจ่ายไปยังระบบทดสอบอื่นด้วย pkg.depotd หรือสร้างเฉพาะรีโพซิทอรีแพ็กเกจที่แปลงแล้วเพื่อตรวจสอบโดยไม่ต้องติดตั้งได้

บทบาทและองค์ประกอบของ Helios

  • Helios คือดิสทริบิวชัน illumos ที่ขับเคลื่อน Oxide Rack
  • ดิสทริบิวชันทั้งหมดประกอบด้วย software consolidation หลายชุด โดยเครื่องมือและเอกสารในรีโพซิทอรีระดับบนสุดนี้เป็นตัวขับเคลื่อนการบิลด์
  • consolidation สาธารณะมีดังต่อไปนี้
    • boot-image-tools: เครื่องมือประกอบ boot image สำหรับฮาร์ดแวร์ Oxide
    • garbage-compactor: สคริปต์บิลด์สำหรับแพ็กเกจนอกเหนือจาก OS แกนหลัก
    • helios-omicron-brand: zone brand สำหรับคอมโพเนนต์ Omicron
    • helios-omnios-build: สคริปต์บิลด์สำหรับแพ็กเกจนอกเหนือจาก OS แกนหลัก
    • helios-omnios-extra: สคริปต์บิลด์สำหรับแพ็กเกจนอกเหนือจาก OS แกนหลัก
    • illumos-gate สาขา stlouis: ระบบปฏิบัติการแกนหลัก เช่น เคอร์เนลและ libc
    • phbl: Pico Host Boot Loader
    • pinprick: ยูทิลิตีบีบอัด ROM image
    • illumos/image-builder: เครื่องมือบิลด์ดิสก์อิมเมจ illumos ที่บูตได้
    • amd-host-image-builder: เครื่องมือสร้าง ROM image สำหรับ AMD CPU
  • ยังมี consolidation ที่ยังไม่เปิดเผยต่อสาธารณะด้วย
    • amd-firmware: binary blob เฟิร์มแวร์ AMD CPU มีแผนจะเปิดเผยในอนาคต
    • chelsio-t6-roms: blob เฟิร์มแวร์ Chelsio T6 NIC มีแผนจะเปิดเผยในอนาคต
    • pilot: ยูทิลิตีควบคุมระดับล่างของระบบ Oxide มีแผนจะเปิดเผยในอนาคต
    • dmar-report: ตัวสร้างรายงาน DRAM margining มีแผนจะเปิดเผยในอนาคต
  • หากไม่มีสิทธิ์เข้าถึงรีโพซิทอรีส่วนตัว สามารถข้ามการโคลนและการบิลด์ซอฟต์แวร์ที่ยังไม่เปิดเผยได้ด้วย OXIDE_STAFF=no gmake setup

สภาพแวดล้อมเริ่มต้นและการตั้งค่าเบื้องต้น

  • ขั้นตอนนี้สำหรับกรณีที่ต้องการบิลด์และติดตั้งแพ็กเกจ OS เอง หากเป้าหมายเป็นเพียงการใช้งาน Helios ให้ดูข้อมูลซอฟต์แวร์ Helios ที่บิลด์ไว้ล่วงหน้าใน helios-engvm
  • จุดเริ่มต้นที่แนะนำคือ เครื่องบิลด์แบบกายภาพหรือแบบเสมือน ที่ติดตั้ง Helios รุ่นล่าสุด
    • รายละเอียดการติดตั้งเครื่องเสมือนอยู่ใน helios-engvm
    • ข้อมูลสื่อการติดตั้งสำหรับระบบ x86 แบบกายภาพก็อยู่ในรีโพซิทอรีเดียวกัน
  • หากสร้าง VM ตามขั้นตอนของ helios-engvm แพ็กเกจที่จำเป็นควรถูกติดตั้งไว้แล้ว
  • หากสร้างสภาพแวดล้อม Helios ด้วยตัวติดตั้ง ISO หรือวิธีอื่น อาจต้องใช้แพ็กเกจ pkg:/developer/illumos-tools
    • ตรวจสอบว่าติดตั้งแล้วหรือไม่ด้วย pkg list developer/illumos-tools
    • หากขาดไป ให้ติดตั้งด้วย pkg install
  • ควรใช้แพ็กเกจ Helios ล่าสุด และต้องตรวจสอบคำแนะนำที่แสดงหลัง pkg update
    • หากแจ้งว่าอัปเดตได้สร้าง boot environment ใหม่ ให้เปิดใช้งานด้วย reboot แล้วจึงดำเนินการต่อ
  • ติดตั้ง Rust และ Cargo ด้วย rustup โดยใช้ไบนารีทางการของโปรเจกต์ Rust
    • ในขั้นตอนติดตั้งอย่างเป็นทางการ ให้ใช้ bash แทน sh
    • ตัวอย่างคำสั่งคือ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

การโคลนรีโพซิทอรีและ helios-build

  • บนเครื่อง Helios ให้โคลนรีโพซิทอรีแล้วรัน gmake setup
    • เครื่องมือ helios-build ที่ใช้ Rust จะถูกบิลด์ใน tools/helios-build
    • รีโพซิทอรีหลายรายการจะถูกโคลนไว้ใต้ projects/
  • หากไม่มีสิทธิ์เข้าถึงรีโพซิทอรีส่วนตัวขององค์กร GitHub oxidecomputer สามารถใช้เฉพาะรีโพซิทอรีสาธารณะได้ดังนี้
    • OXIDE_STAFF=no gmake setup
  • เครื่องมือ helios-build อาจใช้เวลานานในการบิลด์ครั้งแรก
  • ขั้นตอนตั้งค่าเบื้องต้นจะโคลนรีโพซิทอรีโปรเจกต์ที่คาดไว้ แต่การดำเนินการภายหลัง เช่น การอัปเดตหรือการสลับสาขา จะทำกับบางรีโพซิทอรีเท่านั้น
    • รีโพซิทอรีใดเป็นเป้าหมายของการอัปเดตอัตโนมัติ ตรวจสอบได้ที่ auto_update ใน config/projects.toml
    • โคลนภายในเครื่องอื่น ๆ ต้องจัดการการสลับสาขาและ pull เองเหมือนรีโพซิทอรี Git ทั่วไป

วิธีบิลด์ illumos

  • คอมโพเนนต์ OS แกนหลักของ Helios มาจาก สาขา stlouis ของ illumos-gate
  • แพ็กเกจที่รวมอยู่ในระบบ Helios ส่วนใหญ่เป็น stock illumos ที่เพิ่มองค์ประกอบสำหรับฮาร์ดแวร์ Oxide และการแปลงแพ็กเกจเล็กน้อยบางส่วน
  • helios-build มี wrapper หลายตัวที่จัดการการตั้งค่าบิลด์และเรียกเครื่องมือบิลด์ของ illumos เพื่อให้บิลด์ illumos ได้ง่ายขึ้น
  • เอกสาร upstream illumos เรื่อง Building illumos ครอบคลุมงานส่วนใหญ่ที่เครื่องมือ Helios ทำแทน
  • ระหว่างพัฒนา สามารถทำ quick build ด้วยคำสั่งต่อไปนี้
    • ./helios-build build-illumos -q
    • quick build จะปิด shadow compiler และการตรวจสอบบางส่วนที่การรวมขั้นสุดท้ายต้องการ
  • เวลาในการบิลด์ขึ้นอยู่กับจำนวน CPU ของเครื่องบิลด์และประสิทธิภาพของสตอเรจภายในเครื่อง
  • ล็อกการบิลด์ทั้งหมดมีขนาดใหญ่ ตัวอย่างเช่นดูได้ด้วย tail -F projects/illumos/log/nightly.log
  • หากบิลด์สำเร็จ จะมีรีโพซิทอรีแพ็กเกจที่ projects/illumos/packages/i386 และหลังจากนั้นสามารถแปลงและติดตั้งได้หลายวิธี

การติดตั้งและแจกจ่ายแพ็กเกจที่บิลด์แล้ว

  • ติดตั้งลงในเครื่องบิลด์ภายในเครื่อง

    • แพ็กเกจที่บิลด์ใหม่สามารถติดตั้งลงในเครื่องบิลด์ได้ด้วย ./helios-build onu -t my-be-name
    • คำสั่งนี้จะแปลงและติดตั้งแพ็กเกจ illumos และสร้าง Boot Environment ใหม่ด้วยชื่อที่ส่งผ่าน -t
    • boot environment ใหม่จะถูกเปิดใช้งานโดย onu และผู้ใช้ต้องรีบูตเพื่อเข้าสู่สภาพแวดล้อมนั้น
    • ดูข้อมูล boot environment ได้ที่ beadm(8)
    • ตอนรีบูต ควรอยู่ที่คอนโซลเพื่อดูข้อความบูตและโต้ตอบกับ boot loader ได้
    • หลังติดตั้ง สามารถยืนยันได้จาก pkg list -Hv system/kernel ว่าแพ็กเกจ system/kernel มาจาก publisher on-nightly แบบไฟล์ในเครื่อง และเวอร์ชัน quick build 3.0.999999

  • ติดตั้งไปยังเครื่องอื่นผ่านเซิร์ฟเวอร์รีโพซิทอรีแพ็กเกจ

    • หากมีเครื่องทดสอบแยกจากเครื่องบิลด์ สามารถใช้เซิร์ฟเวอร์รีโพซิทอรีแพ็กเกจ pkg.depotd ของเครื่องบิลด์ได้
    • ./helios-build onu -D จะแปลงแพ็กเกจจากบิลด์ล่าสุดและเริ่มแพ็กเกจเซิร์ฟเวอร์
    • ในตัวอย่างจะให้บริการที่ 0.0.0.0:7891
    • เซิร์ฟเวอร์จะทำงานต่อไปจนกว่าจะกด Control-C หรือปิดด้วยวิธีอื่น
    • บนเครื่องเป้าหมาย ตรวจสอบการเชื่อมต่อกับเครื่องบิลด์ด้วย pkgrepo info -s http://genesis:7891
    • ระบบ stock Helios โดยปกติมี publisher ชื่อ helios เพียงตัวเดียวที่ใช้รีโพซิทอรีส่วนกลาง https://pkg.oxide.computer/helios/3/dev/
    • บนเครื่องทดสอบ ให้เพิ่ม publisher on-nightly และตั้งเป็นเป้าหมายค้นหาก่อน พร้อมผ่อนกฎ sticky ของ publisher helios เดิม
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • อาจต้องลบเมตาแพ็กเกจ entire ก่อนอัปเดต ขึ้นอยู่กับสถานการณ์
    • โดยเฉพาะกรณีที่มี zone ที่ใช้ brand lipkg
    • เครื่องมือ onu ของ stock illumos จะทำสิ่งนี้โดยอัตโนมัติ
    • รัน dry-run ด้วย pkg update -nv เพื่อตรวจสอบว่าจะอัปเดตเป็นแพ็กเกจ quick build หรือไม่
    • ในตัวอย่างมีการอัปเดต 325 แพ็กเกจ และต้องสร้างและเปิดใช้งาน boot environment ใหม่ รวมถึงบิลด์ boot archive ใหม่
    • เวอร์ชันจะเปลี่ยนจากเวอร์ชัน stock Helios ที่อิงเลข commit ของสาขา stlouis เป็นเวอร์ชัน quick build 3.0.999999
    • ทำการอัปเดตจริงด้วย pkg update -v และหากสำเร็จ ต้องรีบูตเข้าสู่ boot environment ใหม่
    • หลังรีบูต การตั้งค่า publisher จะยังคงอยู่
    • หลังจากนั้นสามารถทำซ้ำวงจรบิลด์ใหม่ รีสตาร์ทแพ็กเกจเซิร์ฟเวอร์ และ pkg update -v บนเครื่องทดสอบได้

  • สร้างเฉพาะแพ็กเกจโดยไม่ติดตั้ง

    • ./helios-build onu -P จะแปลงเฉพาะแพ็กเกจผลลัพธ์จาก quick build โดยไม่ติดตั้ง
    • รีโพซิทอรีแพ็กเกจที่แปลงแล้วจะถูกสร้างที่ tmp/onu/repo.redist
    • วิธีนี้มีประโยชน์เมื่อตรวจสอบเนื้อหาของรีโพซิทอรีบิลด์
    • pkgrepo info -s tmp/onu/repo.redist
    • pkgrepo list -s tmp/onu/repo.redist
    • pkg contents -t file -s tmp/onu/repo.redist '*microcode*'
    • ยังสามารถเก็บไฟล์แพ็กเกจไว้เพื่อเปรียบเทียบเอาต์พุตจากหลายบิลด์ ส่งไปยังระบบระยะไกล หรือใช้ติดตั้งในภายหลังได้

การเปลี่ยนแปลงและการบิลด์ซ้ำ

  • โดยทั่วไปควรเริ่มงานเปลี่ยนแปลงระบบจาก เวิร์กสเปซบิลด์ที่สะอาด หลัง quick build
  • หากต้องการแก้ไขไฟล์ซอร์สเฉพาะและบิลด์คอมโพเนนต์ใหม่ ให้เข้าสู่สภาพแวดล้อมบิลด์ด้วย bldenv ก่อน
    • ./helios-build bldenv -q
    • เชลล์แบบโต้ตอบใหม่จะเริ่มขึ้น และ PATH กับตัวแปรอื่น ๆ จะถูกตั้งค่าอย่างถูกต้อง
  • ย้ายไปยังไดเรกทอรีคอมโพเนนต์แล้วใช้คำสั่งอย่าง dmake -S -m serial install เพื่อบิลด์และติดตั้งได้
    • ตัวอย่างคือบิลด์คำสั่ง id ใน cmd/id แล้วติดตั้งลงในพื้นที่ proto
  • วิธี targeted incremental edit-and-recompile แบบนี้เหมาะสำหรับตรวจสอบในรอบสั้น ๆ ว่าการเปลี่ยนแปลงคอมไพล์ได้หรือไม่

  • ตัวเลือกที่ถูกต้องที่สุดแต่ช้าที่สุด

    • สามารถบิลด์ OS ทั้งหมดใหม่ได้
    • กระบวนการนี้เป็นขั้นตอนเดียวที่รับประกันผลลัพธ์ที่ถูกต้องเท่าที่เป็นไปได้
    • หากเกิดปัญหาที่อธิบายไม่ได้จากวิธี incremental ควรลอง full build ก่อน
    • คำสั่งคือ ./helios-build build-illumos -q

  • ตัวเลือกที่เร็วแต่ไม่มีการรับประกัน

    • หากอัปเดตไบนารีในพื้นที่ proto ด้วย dmake install แล้ว สามารถสร้างแพ็กเกจใหม่อย่างเดียวและติดตั้งได้โดยไม่ต้องบิลด์ทั้งหมด
    • ภายใน bldenv ให้ย้ายไปที่ $SRC/pkg แล้วรัน dmake install
    • หลังจากนั้นเริ่มเซิร์ฟเวอร์รีโพซิทอรีแพ็กเกจด้วยแพ็กเกจที่อัปเดตแล้ว หรือดำเนินการติดตั้งภายในเครื่อง

  • ตัวเลือกที่จัดการไฟล์ซิสเต็มโดยตรง

    • สุดท้ายแล้วระบบปฏิบัติการก็คือไฟล์ต่าง ๆ ในไฟล์ซิสเต็ม ดังนั้นวิธีนอกเหนือจากเครื่องมือแพ็กเกจก็เป็นไปได้
    • สามารถรันไบนารีที่แก้ไขแล้วบนระบบบิลด์โดยตรง หรือคัดลอกไปยังระบบทดสอบด้วย scp, rsync แล้วรันได้
    • หากไบนารีต้องพึ่งการเปลี่ยนแปลงของไลบรารีหรือเคอร์เนล อาจไม่ทำงาน
    • สามารถสร้าง boot environment ใหม่แล้วปรับไฟล์ข้างในได้
    • boot environment คือไฟล์ซิสเต็ม ZFS แยกต่างหากที่แก้ไข snapshot clone และบูตได้
    • สามารถใช้ beadm create, beadm mount, beadm activate ได้
    • สามารถสร้างดิสก์อิมเมจหรือ ramdisk ใหม่ทั้งหมดแล้วบูตด้วย VM หรือ PXE ได้
    • เครื่องมือสร้างอิมเมจเฉพาะ Helios อยู่ใน เครื่องมือ image ของ helios-engvm
    • เครื่องมือเหล่านี้สามารถรวมแพ็กเกจ quick build หรือไฟล์เพิ่มเติมใด ๆ เข้าไปได้ผ่านการแก้ไขเทมเพลตอิมเมจ
    • พื้นฐานคือ upstream illumos/image-builder

อาร์ไคฟ์อิมเมจ OS

  • ระหว่างกระบวนการบิลด์อิมเมจ OS สำหรับ Oxide compute sled จะมีการสร้าง อาร์ไคฟ์อิมเมจ
  • อาร์ไคฟ์นี้ประกอบด้วย boot ROM และอิมเมจ ramdisk ของ root file system
  • ยังมีเมทาดาทาในไฟล์ JSON และใช้รูปแบบเดียวกับ omicron1 brand
  • เนื้อหาไฟล์เป็น committed interface ระหว่าง Helios กับส่วนหนึ่งของ Omicron ที่ต้องดาวน์โหลดและติดตั้งอิมเมจ OS ลงในระบบกายภาพของ Oxide Rack
  • ไฟล์ที่จำเป็นสำหรับการใช้งาน Omicron อย่างน้อยมีดังต่อไปนี้
    • oxide.json: ไฟล์ส่วนหัวเมทาดาทาที่มีคีย์อย่างน้อย v=1 และคีย์ t=os สำหรับระบุอิมเมจ OS
    • image/rom: อิมเมจ host boot ROM ขนาด 32MiB
    • image/zfs.img: อิมเมจ ramdisk ของ host root file system ขนาดตามต้องการ
  • อาจมีไฟล์เพิ่มเติมเพื่อวัตถุประสงค์ทางวิศวกรรมหรือการวินิจฉัย
    • เช่น เคอร์เนลบีบอัด unix.z สำหรับ bldb หรือ nanobl-rs, boot archive บีบอัด cpio.z
    • อาร์เรย์ไฟล์ ROM เพิ่มเติมที่มี suffix แสดงฟังก์ชันวินิจฉัยต่างกัน
  • ไฟล์เพิ่มเติมไม่ใช่ committed interface และอาจเปลี่ยนแปลงได้ทุกเมื่อในอนาคต
  • ซอฟต์แวร์ที่ตีความอาร์ไคฟ์อิมเมจควรละเว้นไฟล์ที่ไม่รู้จัก

ไลเซนส์

  • ลิขสิทธิ์เป็นของ Oxide Computer Company ปี 2026
  • หากไม่ได้ระบุไว้เป็นอย่างอื่น คอมโพเนนต์ทั้งหมดอยู่ภายใต้ Mozilla Public License Version 2.0

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-30
ความคิดเห็นบน Hacker News

  • ดีใจที่สิ่งนี้ถูกเปิดเผยออกมา และตั้งใจจะนำไปติดตั้งใช้งานแบบโลคัลเพื่อเรียนรู้ให้ได้มากที่สุด
    Oxide แทบจะเป็นบริษัทในฝัน ทั้งในแง่เทคโนโลยีสแต็กและผู้คนที่ทำงานร่วมกัน

    • ตอนแรกผมกวาดตาดูหน้าเว็บราว 20 วินาทีแล้วรู้สึกว่า “นี่คือ การบูรณาการแนวดิ่ง สำหรับการซื้อเซิร์ฟเวอร์แบบ on-premises เหรอ? ถึงขั้นมีระบบปฏิบัติการคัสตอมด้วย? ทำไมต้องยอมจ่ายแพงขึ้นด้วย?”
      แต่ไม่นานก็คิดต่อว่า “แล้วระบบปฏิบัติการของเซิร์ฟเวอร์จริง ๆ มันต้องทำอะไรนักหนา? แค่รัน VM ก็พอไม่ใช่เหรอ? ไม่จำเป็นต้องเป็น Linux โดยตรง ขอแค่รัน Linux VM ได้ก็พอไม่ใช่เหรอ”
    • อยากเห็นว่าจะเทียบกับ SmartOS แล้วเป็นอย่างไร
      ผมลงทุนกับ SmartOS ในโครงสร้างพื้นฐานส่วนตัวไปพอสมควร แต่หลังจาก Joyent ถูกซื้อกิจการก็เริ่มกังวลกับอนาคตของมัน
      อยากทำงานอยู่ในองค์กรที่ใหญ่พอจะใช้ฮาร์ดแวร์ของ Oxide ถ้าไม่ต้องมานั่งยุ่งกับโครงสร้างความเข้ากันได้ปลอม ๆ แบบ IBM PC AT, BMC และ iDRAC ที่ง่อนแง่น, หรือฮาร์ดแวร์ RAID controller ก็คงยอดเยี่ยมมาก
    • Oxide แทบจะเป็นบริษัทเดียวที่ผมอยากไปทำงานด้วยจริง ๆ
      มองจากภายนอกแล้วให้ความรู้สึกคล้าย Sun และนั่นแหละคือบริษัทแบบที่ผมเคยใฝ่ฝัน
      แต่ในฐานะคนที่ต้องเลี้ยงดูครอบครัว โครงสร้างเงินเดือนแบบนี้ทำให้รับไม่ไหว บางทีหลังจากลูกเรียนจบมหาวิทยาลัยและไม่ต้องการรายได้ก้อนใหญ่อีกแล้ว ตอนนั้นผมอาจได้สานฝันก็ได้

  • มีใครช่วยอธิบายให้เหมือนอธิบายกับเด็ก 5 ขวบได้ไหมว่า Oxide ให้บริการอะไร? ดูจากเว็บไซต์แล้วยังนึกภาพไม่ออก
    ไม่แน่ใจว่ามันคือ ฮาร์ดแวร์+ซอฟต์แวร์ ที่ซื้อไปใช้แบบ on-premises, เป็น PaaS, หรือเป็นผู้ให้บริการคลาวด์อีกราย

    • เหมือนจะโดนโหวตลบเพราะมีเธรดใหญ่อีกอันที่เกี่ยวกับเรื่องนี้อยู่แล้ว แต่ก็ดูไม่ค่อยยุติธรรมเท่าไร
      ตอบสั้น ๆ คือใช่ มันคือ ฮาร์ดแวร์+ซอฟต์แวร์ ที่ซื้อไปใช้แบบ on-premises
      จุดต่างจากผลิตภัณฑ์คลาวด์ on-premises ส่วนใหญ่ที่มีอยู่ คือเป็นผู้ขายรายเดียวที่ออกแบบฮาร์ดแวร์และซอฟต์แวร์ให้ทำงานร่วมกันได้ดี ซอฟต์แวร์ก็พยายามทำเป็นโอเพนซอร์สมากที่สุด จึงมีประกาศแบบนี้ออกมา
      ผลิตภัณฑ์ส่วนใหญ่มักเอาของจากหลายผู้ขายมารวมกัน แล้วขายสิ่งที่แทบจะเป็นงานอินทิเกรชันเสียมากกว่า Oxide มองว่าวิธีนั้นก่อปัญหาหลายอย่าง และผลิตภัณฑ์ของตัวเองช่วยแก้ปัญหาเหล่านั้นได้
      อีกอย่างคือมี SKU แค่สองแบบเท่านั้น คือ half rack กับ full rack ไม่ได้ขายเป็นหน่วย 1U แต่ขายเป็นทั้งแร็ก
      เมื่อออกแบบทั้งแร็กให้เป็นหน่วยเดียวที่สอดประสานกัน ก็สามารถทำสิ่งที่เป็นไปไม่ได้ในฟอร์มแฟกเตอร์ 1U ได้ มีมุกว่าพวกเขาชอบพูดเรื่องพัดลมตลอด ซึ่งก็เป็นเรื่องจริง เพราะใช้ sled ที่ใหญ่กว่า 1U แบบดั้งเดิม จึงใช้พัดลมที่ใหญ่กว่าได้ และหมุนที่ RPM ต่ำกว่าเพื่อประหยัดพลังงาน
      นี่เป็นการตัดสินใจด้านการออกแบบโดยตั้งใจ แต่ก็มีผลพลอยได้ด้วย ด้วยความที่ RPM ต่ำ เซิร์ฟเวอร์จึงเงียบกว่ามาก ถึงขั้นว่าลูกค้าเป้าหมายในช่วงแรกบางรายถามระหว่างเดโมว่า “นี่มันเปิดอยู่จริง ๆ ใช่ไหม?”
      แน่นอนว่าคนไม่ได้ซื้อเซิร์ฟเวอร์เพราะมันเงียบอย่างเดียว แต่ก็เป็นตัวอย่างที่น่าสนใจของสิ่งที่เกิดขึ้นเมื่อมองผลิตภัณฑ์ใหม่ทั้งระบบ แทนที่จะมองว่าเป็นแค่งานอินทิเกรชันธรรมดา
    • มันคือ โซลูชันคอมพิวต์และสตอเรจ แบบบูรณาการเต็มรูปแบบสำหรับ on-premises ที่จัดสรรทรัพยากรผ่าน API แบบคลาวด์ พร้อมกับคำมั่นสัญญาเรื่องโอเพนซอร์ส

  • รู้ว่าเหล่าคนของ Oxide มาจาก Sun แต่การเลือกสิ่งที่ไม่ใช่ Linux มีข้อได้เปรียบทางเทคนิคจริง ๆ ในแง่คุณค่าทางธุรกิจหรือไม่?
    รู้ว่า illumos มีบางด้านที่ดีกว่า Linux ในเชิงเทคนิค แต่ไม่แน่ใจว่าสิ่งนี้สำคัญกับลูกค้าที่จะซื้อจริงหรือเปล่า
    เลยสงสัยว่านี่จะเป็นการเปิดปัญหาซับซ้อนที่ทำให้ขายคอมพิวเตอร์ได้น้อยลงเพราะอุดมการณ์หรือธรรมเนียมหรือไม่
    ในมุมของคนที่ดูแลงานแบบ Linux container การที่สิ่งนี้เป็น non-Linux โดยพื้นฐานไม่ใช่เหตุผลให้ซื้อ แต่เป็นเหตุผลให้ลังเลที่จะซื้อ รู้ว่า Linux binary รันได้โดยไม่ต้องแก้ไข

    • มันไม่ใช่ผลิตภัณฑ์แบบที่บอกว่า “ข้างในใช้ illumos อยู่ และนั่นคือเหตุผลที่คุณควรซื้อแร็กนี้”
      มันไม่ใช่รายละเอียดของผลิตภัณฑ์ที่ลูกค้ามองเห็น และส่วนใหญ่ก็น่าจะไม่รู้ด้วยซ้ำว่ามันเป็นแบบนั้น
      สิ่งที่ลูกค้าสนใจคือแร็กมีประสิทธิภาพ เสถียร และตรงกับความต้องการหรือไม่ การเลือก illumos แทน Linux ตรงนี้คือการเลือกเพื่อส่งมอบคุณค่านั้นอย่างมีประสิทธิภาพ
      แน่นอนว่านี่ไม่ได้แปลว่าจะสร้างผลิตภัณฑ์ที่คล้ายกันบน Linux ไม่ได้ เพียงแต่เราตัดสินว่า illumos เหมาะกับเป้าหมายมากกว่า
      เราตัดสินใจเรื่องนี้ร่วมกับทีมในรูปแบบ RFD[1] หมายเลข #26 แต่ตอนนี้ยังไม่เปิดสาธารณะ ตัวเลือกที่พิจารณาอย่างจริงจังคือ KVM ของ Linux และ bhyve ของ illumos และเป็นเอกสารที่ค่อนข้างยาว
      สุดท้ายก็ต้องเลือกทางใดทางหนึ่ง และเราเลือกทางนี้ แม้ผมจะไม่ได้พัฒนาส่วนนี้โดยตรง แต่จนถึงตอนนี้ก็ไม่เห็นเหตุผลว่าจะเป็นอุปสรรค และมีแนวโน้มว่ามันเป็นทางเลือกที่เหมาะสม
      อยากรู้ว่าทำไมความเป็น non-Linux ถึงเป็นเหตุผลคัดค้านการซื้อ ถ้าอธิบายเพิ่มเติมได้จะดี อ้อ เห็นคอมเมนต์ข้างล่างแล้ว: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios เป็นเพียงรายละเอียดการติดตั้งใช้งานของแร็ก ไม่ใช่องค์ประกอบที่ผู้ใช้หรือแอปพลิเคชันมองเห็นได้แบบ Hubris[0] ผู้ใช้แร็กจะทำการ provision เครื่องเสมือน
      ว่าทำไมถึงใช้อนุพันธ์ของ illumos แทนอย่างอื่นนั้น มีพูดไว้เล็กน้อยใน Q&A[1] ตอนส่งมอบแร็กชุดแรก และเราก็จะอธิบายอีกครั้งในการเสวนาที่บันทึกไว้ซึ่งจะมีในภายหลังวันนี้[2]
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • ในโลก embedded หรือ appliance นั้น Linux มักกลายเป็นฝันร้ายได้ง่าย
      วิศวกรแพลตฟอร์มต้องใช้เวลาทั้งวันไปกับการแก้ปัญหา kernel ล่าสุด ไดรเวอร์ และไลบรารีหลัก ๆ แล้วสุดท้ายแอปพลิเคชันจริงก็ต้องมาพึ่งพาสิ่งเหล่านั้น
      หรือไม่ก็ไปทางเดียวกับ vendor IoT 99% คือไม่อัปเดตระบบปฏิบัติการพื้นฐานเลย และได้แต่หวังว่าจะไม่มี active exploit ที่เจาะสิ่งนั้นอยู่
      นี่จึงเป็นเหตุผลที่บริษัทขนาดกลางจำนวนมากร้องไห้กับปัญหา CentOS เพราะมันทำให้สามารถอยู่บนแพลตฟอร์มที่ค่อนข้างเสถียรพร้อมรับ security update ได้ โดยไม่ต้องจ่ายเพื่อดูแลการติดตั้ง RHEL แบบเต็มรูปแบบ
      ทุก ๆ ราว 10 ปีอาจต้องกลับมาทบทวน dependency ทั้งหมดใหม่ แต่ก็ยังง่ายกว่าการต้องตามรอบอัปเดตทุก 1-2 ปีมาก บางระบบใช้เวลาแค่ขั้นตอน validation ก็เกิน 6 เดือนแล้ว ทำให้รอบแบบนั้นสั้นเกินไป
      นี่แทบจะเป็นปัญหาเฉพาะของ Linux และทางเลือกอย่าง *BSD ก็มอบสิ่งที่ Linux ให้ได้แทบทั้งหมด แต่มีการพังแบบต่อเนื่องลักษณะนี้น้อยกว่ามาก
    • การมีทางเลือกถือเป็นเรื่องดีต่อระบบนิเวศ และถึงขั้นให้ความรู้สึกเหมือนจักรวาลฟื้นตัวขึ้นเล็กน้อยหลัง Oracle ซื้อ Sun
      นึกไม่ออกจริง ๆ ว่าจะมีใครเหมาะไปกว่าทีมนี้ในการผสานระบบของ Oxide เข้าด้วยกัน
      ตอนนี้ผมเป็นวิศวกรที่ทำงานกับ Linux อย่างเดียว แต่ก็คิดถึงยุคที่ยังมี Unix ที่แข็งแกร่งอีกตัวหนึ่งสำหรับรันงานมูลค่าสูง
      ถ้าให้เทียบ openvswitch บน Linux กับความสามารถ Crossbow SDN ของ Solaris ผมจะเลือก Crossbow ทุกครั้ง
      ไม่ได้หมายความว่า Linux ผิด เพียงแต่เครื่องมือต่าง ๆ เดินไปคนละทางจนเกิดความซับซ้อน แล้วต้องเอาเครื่องมือที่ซับซ้อนยิ่งกว่ามาครอบเพื่อทำ abstraction อีกที มันขาดความเป็นเอกภาพระดับ “master plan” อย่างมาก
    • ลูกค้าจะรัน ระบบปฏิบัติการแบบ virtualized อยู่บนสิ่งนี้
      มันไม่ได้ต่างจาก Azure Host OS, Bottlerocket, Flatcar มากนัก
      สิ่งสำคัญคือพวกเขารู้จักทั้งสแตก รู้ว่า kernel บางส่วนเป็นโค้ดที่พวกเขาถือครองมาตั้งแต่สมัย Sun และสามารถเปิดเผยให้ลูกค้าที่ต้องการเข้าถึงซอร์สเพื่อการประเมินด้านความปลอดภัยได้

  • ฉันไม่ค่อยรู้จัก illumos เลยไปดูหน้าเว็บ แล้วประโยคแรกเขียนว่า “illumos is a Unix operating system”
    illumos เป็น Unix จริงแบบ macOS หรือเป็นระบบปฏิบัติการตระกูล Unix แบบ GNU/Linux?

    • เป็น Unix จริง Wikipedia อธิบายไว้ค่อนข้างดี: https://en.wikipedia.org/wiki/Illumos
      มีพื้นฐานมาจาก OpenSolaris และ OpenSolaris ก็มีพื้นฐานมาจาก System V Release 4(SVR4) กับ Berkeley Software Distribution(BSD) ส่วน Illumos ประกอบด้วยเคอร์เนล ไดรเวอร์อุปกรณ์ ไลบรารีระบบ และซอฟต์แวร์ยูทิลิตีสำหรับการจัดการระบบ แกนกลางนี้ทำหน้าที่เป็นฐานให้กับดิสทริบิวชัน Illumos แบบโอเพนซอร์สหลายตัว คล้ายกับที่ Linux kernel เป็นฐานให้กับดิสทริบิวชัน Linux หลายตัว
    • ไม่มีใครจ่ายเงินเพื่อให้ผ่านการทดสอบรับรอง Unix Branding ของ Open Group
      https://www.opengroup.org/openbrand/register/
      ดังนั้นจึงใช้เครื่องหมายการค้า UNIX™ ไม่ได้
      แต่ภายในมีทั้งซอร์สของเคอร์เนลและยูสเซอร์สเปซจาก 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...
    • ในทางกฎหมายแล้ว NetBSD ก็ไม่ใช่ Unix จริงเหมือนกัน แบรนด์นั้นไม่ได้มีความหมายอย่างที่คนส่วนใหญ่คิด
    • มันเป็นฟอร์กโอเพนซอร์สของ Solaris ที่ Sun เคยให้ Ian Murdock ทำภายใต้ชื่อ Project Indiana และสืบสายมาจาก UNIX SVR4
    • เป็น Unix จริง เท่าที่รู้มันอยู่ในสาย Solaris

  • ไม่ใช่ว่าฉันไม่เอาใจช่วย Oxide แต่สินค้ายังเฉพาะกลุ่มมากและยังอยู่ช่วงเริ่มต้น เลยยากจะจินตนาการว่าบริษัททั่วไปจะซื้อของแบบนี้ในเร็ววัน
    พวกเขาเพิ่งส่งมอบแร็กแรกให้ลูกค้ารายแรกเมื่อปลายฤดูร้อนที่ผ่านมา และลูกค้ารายนั้นก็คือ Idaho National Laboratory
    ตอนนี้สถานที่ที่พอจะเดิมพันแบบนี้ได้จริง ๆ ดูเหมือนจะมีแค่ หน่วยงานวิจัยระดับชาติ

    • ตอนประกาศเมื่อเดือนตุลาคมปีที่แล้วมีการพูดถึงลูกค้า 2 ราย: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      ลูกค้าของ Oxide มีทั้ง Idaho National Laboratory และองค์กรบริการทางการเงินระดับโลกแห่งหนึ่ง และยังมีการติดตั้งเพิ่มเติมให้บริษัทใน Fortune 1000 ที่คาดว่าจะเสร็จในอีกไม่กี่เดือนถัดมา
    • สินค้าทุกอย่างในช่วงแรกเริ่มก็มีหน้าตาแบบนี้ทั้งนั้น
      ถ้าวางแผนจะออกสู่ตลาดด้วยวิธีอื่น คุณก็คงทำบริษัทพังก่อนเปิดตัวไปแล้ว มีบางรายที่รอดมาได้อย่างโชคดี แต่นั่นก็เป็นส่วนหนึ่งของสถิติที่ว่า 9 ใน 10 สตาร์ตอัปล้มเหลว
      คุณต้องโฟกัสที่ลูกค้ากลุ่มแรกอย่าง สุดขั้ว เพื่อข้าม chasm ให้ได้ แล้วค่อยไปสู่ตลาดแมส
    • หวังว่าสักวันจะมี ผลิตภัณฑ์สำหรับโฮมแล็บ ที่เล็กและถูกกว่านี้ออกมาด้วย
      คนจะได้ใช้เพื่อเรียนรู้หรือให้สตาร์ตอัปทดลองใช้ แล้วอาจต่อยอดไปสู่การขายแร็กหรือการจ้างงานในภายหลัง
    • ฉันทำงานอยู่ที่บริษัทเทคโนโลยีที่เพิ่งเข้าตลาดหลักทรัพย์ และเราเคยพิจารณา Oxide อย่างจริงจังตอนประเมินระบบ on-premises
      มันยังขายไอเดียนี้ให้กับคนที่ยังคิดว่า “on-premises เหรอ... ยี้” ได้อยู่
      ดูเหมือนมันจะมอบ ประสบการณ์แบบคลาวด์ บนฮาร์ดแวร์ของตัวเอง
      ถ้ามันถูกเท่า Dell ได้ก็คงดี
    • บริษัทเราก็เคยพิจารณา และประทับใจกับผลิตภัณฑ์มาก
      ปัญหาเดียวคือมันถูกออกแบบมาสำหรับงานคอมพิวต์ทั่วไป ขณะที่เราต้องการตัวเลือกโปรเซสเซอร์ที่เร็วกว่าอย่างมากจริง ๆ

  • ชอบมากที่เอกสารดูชัดเจนและเข้าใจง่าย ส่วนตัวคิดว่าด้านเอกสารเป็นจุดที่ชุมชน illumos มีปัญหามาโดยตลอดในเชิงประวัติศาสตร์
    พอเห็นคำว่า consolidations ในซอร์สรีลีสใหม่แล้วรู้สึกอบอุ่นดี แม้ถ้าฉันไม่ได้เข้าใจโครงสร้างรีโปผิดไปมากนัก มันก็ดูเหมือนจะเดินไปคนละทางกับ gate paradigm แบบดั้งเดิม
    มีคำถามอยู่สองสามข้อ ส่วนใหญ่เกี่ยวกับเครื่องมือ ทำไมถึงใช้ gmake? เพราะสุดท้ายก็ดูเหมือนจะยังต้องใช้ dmake อยู่ดี
    ในคู่มือระบุให้รัน rustup โดยเจาะจงเป็น bash นี่เป็นข้อบกพร่องจาก upstream หรือว่า sh ในเครื่องโลคัลไม่เข้ากันกับ POSIX แบบสมบูรณ์?
    แล้วการพัฒนาภายในทำกันอย่างไร? คนของ Oxide ใช้เวิร์กสเตชัน illumos กันหรือเปล่า หรือว่าพัฒนาทั้งหมดใน VM หรือ SSH เข้าเซิร์ฟเวอร์กัน?
    แล้วทำไมถึงเป็น MPL? เพราะความเข้ากันได้กับ GPL หรือ?

    • ฉันไม่ได้ทำงานกับ helios โดยตรง เลยตอบทั้งหมดไม่ได้ แต่ตอบได้บางส่วน
      เรื่องที่ว่าคนของ Oxide ใช้เวิร์กสเตชัน illumos หรือพัฒนาผ่าน VM หรือ SSH เข้าเซิร์ฟเวอร์กันนั้น เขียนไว้ที่นี่: https://news.ycombinator.com/item?id=39181727
      แต่ก็มีคนที่ใช้ illumos บนเวิร์กสเตชันจริง ๆ เหมือนกัน
      ส่วนเรื่อง MPL อยู่ที่นี่: https://news.ycombinator.com/item?id=39181844
      ในคอมเมนต์นั้นไม่ได้ลงลึกมากนักว่า “ทำไม” แต่ฉันมองว่ามันเป็นจุดประนีประนอมที่ดีในพื้นที่ความเป็นไปได้ คือ copyleft มากกว่า BSD แต่ก็มีข้อจำกัดน้อยกว่า GPL
    • เท่าที่รู้ นั่นเป็นปัญหาจาก upstream
      เหมือนกับโครงการโอเพนซอร์สส่วนใหญ่ ที่นั่นก็มี Linuxism/Bashism อยู่
    • ด้วยเหตุผลทางประวัติศาสตร์ การบิลด์ระบบปฏิบัติการแกนหลักจะใช้ dmake แต่เมื่อสร้าง Makefile ใหม่ใน consolidation อื่น ๆ ก็มักจะแนะนำให้ใช้ GNU make(gmake)
      เพราะหาใช้ได้แพร่หลาย ใช้ได้บนแพลตฟอร์มอื่นด้วย และมีฟีเจอร์ที่ทันสมัยกว่า

  • ซอฟต์แวร์เป็นโอเพนซอร์สนั้นยอดเยี่ยมก็จริง แต่จะนำไปแจกจ่ายและใช้งานบนฮาร์ดแวร์อื่นได้ไหม?
    หากไม่ว่าด้วยเหตุผลใด บริษัทไม่สามารถซื้อแร็กของ Oxide ได้อีกต่อไป จะต้องเริ่มต้นโครงสร้างพื้นฐานใหม่ตั้งแต่ศูนย์หรือไม่ หรือยังสามารถขยายต่อโดยมี ฮาร์ดแวร์ของ Oxide เป็นศูนย์กลางได้?

    • มีโอกาสไม่สูงนักที่จะใช้งานได้อย่างมีประโยชน์ทันทีนอกฮาร์ดแวร์ของเรา แต่หน้าที่หลักคือการดีพลอย virtual machine
      หากตัดสินใจว่าจะไม่ใช้แร็ก Oxide ที่ซื้อมาแล้วต่อ ก็เพียงย้าย virtual machine ไปยังโครงสร้างพื้นฐานตัวถัดไปที่เลือกใช้

  • สงสัยจริง ๆ ว่าบริษัทต่าง ๆ จะอยากรันเวิร์กโหลดแบบไหนบน Unix แบบคัสตอมที่ไม่ใช่ Linux/Mac/BSD
    ผมสนับสนุนให้มี ความหลากหลายของระบบปฏิบัติการ ที่เติบโตเต็มที่มากขึ้น แต่ยังนึกภาพไม่ออกว่าผู้ใช้ปลายทางคือใครและจะมีความต้องการแบบไหน

    • คอมพิวต์ที่โปรวิชันบนแร็ก Oxide คือ virtual machine เราพอร์ต bhyve มาจาก FreeBSD และเพิ่ม live migration เข้าไปด้วย
      ถ้าจำเป็นจริง ๆ ก็น่าจะบูต Windows Server ได้ด้วย
      เหตุผลที่ใช้ illumos ก็เป็นเพราะมีคนจาก Sun, Joyent และที่อื่น ๆ อยู่มาก จึงยอมรับได้ว่ามีอคติตามความคุ้นเคยอยู่บ้าง
      แต่ก็มีเหตุผลที่น่าเชื่อถือพอสมควรว่านี่ไม่ใช่เครื่องพีซีส่วนบุคคล x86 ที่เข้ากันได้กับ IBM: ไม่มี BIOS, ไม่มี UEFI, และไม่มี BMC แบบดั้งเดิม อีกทั้งแม้จะใช้ x86 รุ่นใหม่ ก็พยายามตัดเฟิร์มแวร์แบบ proprietary และ binary blob ออกให้มากที่สุด
      แต่ละเธรดมี service processor และ hardware root of trust ของตัวเอง ซึ่งจะบูต CPU โดยตรง โหลด AMD training blob แล้วจึงบูตระบบปฏิบัติการ
      การอัปสตรีมการเปลี่ยนแปลงแบบนั้นเข้า Linux หรือ BSD คงทำได้ยากสำหรับคอมพิวเตอร์ที่ตอนนี้มีแค่พวกเขาเองเท่านั้น สุดท้ายก็ต้องดูแล downstream fork ของตัวเองอยู่ดี และเมื่อไม่มีฝ่ายอื่นที่จะรับผิดชอบต่อความแข็งแกร่งของระบบปฏิบัติการ ก็เลยตัดสินใจว่าใช้ระบบปฏิบัติการที่ซัพพอร์ตและพัฒนามาหลายปีแล้วจะดีกว่า
    • นี่ไม่ใช่รายละเอียดที่ผู้ใช้จะมองเห็นจากตัวผลิตภัณฑ์
      ลูกค้าเพียงแค่รัน virtual machine บนแร็ก ไม่ได้คอมไพล์แอปพลิเคชันสำหรับ illumos
      พวกเขาก็แค่รันระบบปฏิบัติการใดก็ตามที่จำเป็นต่อการบรรลุเป้าหมายภายใน virtual machine นั้น
    • ZFS เป็นฟีเจอร์เนทีฟบน illumos และความสามารถที่เทียบได้กับการทำคอนเทนเนอร์ก็ยอดเยี่ยมไม่น้อย
      หากจ้างคนได้เพียงพอ ข้อโต้แย้งที่ว่าเซิร์ฟเวอร์ในคลาวด์ไม่จำเป็นต้องใช้ระบบปฏิบัติการเดียวกันทั้งหมดก็ฟังขึ้นเหมือนกัน
    • คุณอาจไม่มีทางรู้เลยด้วยซ้ำว่านี่ไม่ใช่ Linux
      คุณไม่ได้รันโค้ดบนระบบปฏิบัติการนี้ แต่รันโค้ดบน virtual machine ที่ระบบปฏิบัติการนี้จัดเตรียมไว้ให้

  • สงสัยว่าตอนแรกทุกคนไปรู้จัก Oxide กันได้อย่างไร
    ผมบังเอิญไปเจอพอดแคสต์ของพวกเขา และสำหรับผมมันให้ความรู้สึกเหมือนการตลาดอย่างมาก ทำทุกอย่างยกเว้นการขายของตรง ๆ
    การใส่ช่วงขายสั้น ๆ ไว้ท้ายแต่ละตอนก็น่าจะดี
    ประมาณว่าเล่าเรื่องอย่าง “ทำให้คอมไพเลอร์ยอมทำบางอย่างนี่ลำบากจริง ๆ” แล้วค่อยไหลไปเป็นเรื่องเก่า ๆ
    ยังไงก็หวังว่าจะเล่าต่อไปเรื่อย ๆ และขอให้ไปได้สวย

    • เดิมที On The Metal ซึ่งเป็นพอดแคสต์ เคยมีชื่อเสียเรื่องเล่นข้อความโปรโมตตัวเองที่อัดไว้ล่วงหน้า 2–3 ชิ้นซ้ำบ่อยเกินไป ถึงขั้นมีแฟน ๆ ขออัดโฆษณาให้เองแล้วเอาไปเปิด
      ในทางกลับกัน Oxide and Friends แทนที่จะเป็นพอดแคสต์แบบดั้งเดิม กลับใกล้เคียงกับการอัดเสียง “space” สดหรือกรุ๊ปคอลที่เริ่มจาก Twitter และตอนนี้ย้ายไปทำบน Discord มากกว่า
      ผมคิดว่ามันเป็นรูปแบบที่เหมาะกับการเสพแบบเข้าร่วมสดมากกว่าฟังเป็นพอดแคสต์อย่างเดียว ถ้าลองฟังสดดู จะเข้าใจบรรยากาศของเวอร์ชันบันทึกเสียงได้ดีกว่ามาก
      https://oxide.computer/podcasts/oxide-and-friends
    • เมื่อก่อนผมตาม @jessfraz บน Twitter อยู่ ก็เลยรู้จัก Oxide จากตรงนั้นตอนที่มีการประกาศครั้งแรก
    • รู้จักเพราะตอน Oxide เปิดตัวครั้งแรก Pentagram เปิดเผยงานแบรนดิ้งของพวกเขา

  • ผมรอคอยสิ่งนี้มาตั้งแต่ตอนประกาศแร็กเซิร์ฟเวอร์แล้ว
    เพราะถ้า Oxide ล้มไป ก็คงไม่มีใครอยากได้อุปกรณ์ที่กลายเป็น ที่ทับกระดาษ

    • เพื่อให้ชัดเจน ปัญหา “ที่ทับกระดาษ” นั้นสำคัญกับพวกเราอย่างมากเช่นกัน
      ควรจำไว้ว่า MPL ไม่ได้พิจารณาว่าสำเนาถูกอัปขึ้น GitHub แบบสาธารณะหรือไม่
      ผมไม่ใช่ทนาย แต่ไม่ว่าผู้ที่ไม่ใช่ลูกค้าจะเข้าดูโค้ดได้หรือไม่ ก็ยังมีภาระผูกพันตาม MPL ต่อลูกค้าอยู่ดี