Helios: Bản phân phối illumos vận hành Oxide Rack

 (github.com/oxidecomputer)
1 điểm bởi GN⁺ 2024-01-30 | 1 bình luận | Chia sẻ qua WhatsApp
  • Helios là bản phân phối illumos vận hành Oxide Rack; các công cụ và tài liệu trong kho cấp cao nhất này quản lý việc build toàn bộ bản phân phối bằng cách ghép nhiều software consolidation
  • Bản phân phối dùng nhánh stlouis của illumos-gate làm OS lõi, và chủ yếu cung cấp các gói stock illumos có thêm thành phần dành cho phần cứng Oxide cùng một số chuyển đổi đóng gói
  • Không phải mọi kho cấu thành đều công khai; các consolidation riêng tư có thể được loại khỏi đối tượng clone và build bằng OXIDE_STAFF=no gmake setup
  • Việc build gói riêng dùng rustup, gmake setup và công cụ helios-build dựa trên Rust trên môi trường Helios mới nhất; trong quá trình phát triển có thể dùng quick build tắt shadow compiler và một số kiểm tra
  • Kết quả build có thể được cài vào boot environment cục bộ, phân phối sang hệ thống thử nghiệm khác bằng pkg.depotd, hoặc chỉ tạo kho gói đã chuyển đổi để kiểm tra mà không cài đặt

Vai trò và cấu trúc của Helios

  • Helios là bản phân phối illumos vận hành Oxide Rack
  • Toàn bộ bản phân phối gồm nhiều software consolidation, và các công cụ cùng tài liệu trong kho cấp cao nhất này điều phối quá trình build
  • Các consolidation công khai bao gồm:
  • Cũng có các consolidation chưa được công khai
    • amd-firmware: blob nhị phân firmware CPU AMD, dự kiến công khai trong tương lai
    • chelsio-t6-roms: blob firmware NIC Chelsio T6, dự kiến công khai trong tương lai
    • pilot: tiện ích điều khiển cấp thấp cho hệ thống Oxide, dự kiến công khai trong tương lai
    • dmar-report: trình tạo báo cáo DRAM margining, dự kiến công khai trong tương lai
  • Nếu không có quyền truy cập các kho riêng tư của tổ chức, có thể bỏ qua việc clone và build phần mềm chưa công khai bằng OXIDE_STAFF=no gmake setup

Môi trường bắt đầu và thiết lập ban đầu

  • Đây là quy trình dành cho trường hợp muốn build và cài đặt các gói OS riêng; nếu chỉ nhằm sử dụng Helios thì luồng tham khảo thông tin phần mềm Helios đã build sẵn trong helios-engvm
  • Điểm khởi đầu được khuyến nghị là máy build vật lý hoặc ảo đã cài Helios mới nhất
    • Chi tiết cài đặt máy ảo có trong helios-engvm
    • Thông tin về media cài đặt cho hệ thống x86 vật lý cũng nằm trong cùng kho
  • Nếu đã tạo VM theo quy trình helios-engvm, các gói cần thiết lẽ ra đã được cài sẵn
  • Nếu tạo môi trường Helios bằng trình cài ISO hoặc cách khác, có thể cần gói pkg:/developer/illumos-tools
    • Kiểm tra đã cài hay chưa bằng pkg list developer/illumos-tools
    • Nếu thiếu thì cài bằng pkg install
  • Nên dùng các gói Helios mới nhất, và cần kiểm tra hướng dẫn được in ra sau pkg update
    • Nếu thông báo rằng bản cập nhật đã tạo boot environment mới, hãy kích hoạt bằng reboot rồi tiếp tục
  • Rust và Cargo được cài đặt bằng rustup từ binary chính thức của dự án Rust
    • Trong quy trình cài đặt chính thức, dùng bash thay vì sh
    • Lệnh ví dụ là curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

Clone kho và helios-build

  • Sau khi clone kho trên máy Helios, chạy gmake setup
    • Công cụ helios-build dựa trên Rust sẽ được build trong tools/helios-build
    • Nhiều kho sẽ được clone dưới projects/
  • Nếu không có quyền truy cập các kho riêng tư của tổ chức GitHub oxidecomputer, có thể chỉ dùng các kho công khai như sau
    • OXIDE_STAFF=no gmake setup
  • Công cụ helios-build có thể mất thời gian trong lần build đầu tiên
  • Bước thiết lập ban đầu clone các kho dự án dự kiến, nhưng các thao tác sau đó như cập nhật hoặc chuyển nhánh chỉ được thực hiện trên một số kho
    • Có thể xem kho nào là đối tượng tự động cập nhật trong auto_update của config/projects.toml
    • Với các clone cục bộ khác, cần tự quản lý việc chuyển nhánh và pull như kho Git thông thường

Cách build illumos

  • Các thành phần OS lõi của Helios đến từ nhánh stlouis của illumos-gate
  • Phần lớn gói đưa vào hệ thống Helios là stock illumos có thêm thành phần cho phần cứng Oxide và một số chuyển đổi đóng gói nhỏ
  • helios-build cung cấp nhiều wrapper để quản lý cấu hình build và gọi các công cụ build illumos nhằm làm cho việc build illumos dễ hơn
  • Tài liệu upstream illumos Building illumos bao quát phần lớn công việc mà công cụ Helios thực hiện thay
  • Trong quá trình phát triển có thể thực hiện quick build bằng lệnh sau
    • ./helios-build build-illumos -q
    • quick build vô hiệu hóa shadow compiler và một số kiểm tra cần thiết cho tích hợp cuối cùng
  • Thời gian build phụ thuộc vào số CPU của máy build và hiệu năng lưu trữ cục bộ
  • Log build đầy đủ rất lớn, có thể xem chẳng hạn bằng tail -F projects/illumos/log/nightly.log
  • Nếu build thành công, kho gói sẽ được tạo tại projects/illumos/packages/i386, sau đó có thể chuyển đổi và cài đặt theo nhiều cách

Cài đặt và phân phối các gói đã build

  • Cài đặt trên máy build cục bộ

    • Các gói mới build có thể được cài trên máy build bằng ./helios-build onu -t my-be-name
    • Lệnh này chuyển đổi và cài đặt các gói illumos, đồng thời tạo Boot Environment mới với tên được truyền qua -t
    • Boot environment mới được onu kích hoạt, và người dùng reboot để vào môi trường đó
    • Tham khảo beadm(8) để biết thông tin về boot environment
    • Khi reboot, nên ở tại console để có thể xem thông báo boot và tương tác với boot loader
    • Sau khi cài, có thể xác nhận trong pkg list -Hv system/kernel rằng gói system/kernel đến từ publisher on-nightly dựa trên file cục bộ và phiên bản quick build 3.0.999999

  • Cài đặt sang máy khác thông qua máy chủ kho gói

    • Nếu có máy thử nghiệm riêng với máy build, có thể dùng máy chủ kho gói pkg.depotd trên máy build
    • ./helios-build onu -D chuyển đổi các gói của bản build gần nhất và khởi động máy chủ gói
    • Trong ví dụ, dịch vụ chạy tại 0.0.0.0:7891
    • Máy chủ tiếp tục chạy cho đến khi Control-C hoặc cách kết thúc khác
    • Trên máy đích, kiểm tra kết nối tới máy build bằng pkgrepo info -s http://genesis:7891
    • Hệ thống stock Helios mặc định có một publisher helios dùng kho trung tâm https://pkg.oxide.computer/helios/3/dev/
    • Trên máy thử nghiệm, thêm publisher on-nightly và đặt làm mục tiêu tìm kiếm ưu tiên, đồng thời nới lỏng quy tắc sticky của publisher helios hiện có
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • Tùy tình huống, có thể cần gỡ meta package entire trước khi cập nhật
    • Điều này có thể đặc biệt đúng nếu có zone dựa trên brand lipkg
    • Công cụ onu của stock illumos tự động thực hiện việc này
    • Chạy dry-run bằng pkg update -nv để xác nhận hệ thống sẽ cập nhật sang các gói quick build
    • Trong ví dụ, 325 gói được cập nhật, và cần tạo cũng như kích hoạt boot environment mới, đồng thời build lại boot archive
    • Phiên bản chuyển từ phiên bản stock Helios dựa trên số commit của nhánh stlouis sang phiên bản quick build 3.0.999999
    • Cập nhật thực tế bằng pkg update -v; nếu thành công, cần reboot vào boot environment mới
    • Sau khi reboot, cấu hình publisher vẫn được giữ lại
    • Sau đó có thể lặp lại luồng build mới, khởi động lại máy chủ gói, và pkg update -v trên máy thử nghiệm

  • Chỉ tạo gói mà không cài đặt

    • ./helios-build onu -P chỉ thực hiện chuyển đổi gói kết quả quick build mà không cài đặt
    • Kho gói đã chuyển đổi được tạo tại tmp/onu/repo.redist
    • Cách này hữu ích khi kiểm tra nội dung của kho 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*'
    • Cũng có thể giữ các file gói để so sánh đầu ra của nhiều bản build, truyền sang hệ thống từ xa, hoặc cài đặt về sau

Thay đổi và build lặp lại

  • Khi thay đổi hệ thống, thường nên bắt đầu từ workspace build sạch sau quick build
  • Để sửa một file nguồn cụ thể và build lại thành phần, trước tiên vào môi trường build bằng bldenv
    • ./helios-build bldenv -q
    • Một shell tương tác mới khởi động, và PATH cùng các biến khác được thiết lập đúng
  • Di chuyển đến thư mục thành phần và dùng lệnh như dmake -S -m serial install để build và cài đặt
    • Ví dụ build lệnh id trong cmd/id và cài vào khu vực proto
  • Cách targeted incremental edit-and-recompile như vậy phù hợp để kiểm tra trong chu kỳ ngắn rằng thay đổi có biên dịch được hay không

  • Lựa chọn đúng nhất nhưng chậm

    • Có thể build lại toàn bộ OS
    • Đây là quy trình duy nhất đảm bảo kết quả đúng trong phạm vi có thể
    • Nếu gặp vấn đề không giải thích được với phương pháp incremental, nên thử full build trước
    • Lệnh là ./helios-build build-illumos -q

  • Lựa chọn nhanh nhưng không bảo đảm

    • Nếu đã cập nhật binary trong khu vực proto bằng dmake install, có thể chỉ tạo lại gói và cài đặt mà không full build
    • Bên trong bldenv, chuyển đến $SRC/pkg và chạy dmake install
    • Sau đó khởi động máy chủ kho gói với các gói đã cập nhật hoặc tiến hành cài đặt cục bộ

  • Lựa chọn thao tác trực tiếp với hệ thống file

    • Suy cho cùng, hệ điều hành là các file trong hệ thống file, nên cũng có thể dùng cách ngoài công cụ đóng gói
    • Có thể chạy trực tiếp binary đã sửa trên hệ thống build, hoặc sao chép sang hệ thống thử nghiệm bằng scp, rsync rồi chạy
    • Nếu binary cần thay đổi thư viện hoặc kernel, cách này có thể không hoạt động
    • Có thể tạo boot environment mới và điều chỉnh file bên trong đó
    • Boot environment là hệ thống file ZFS riêng có thể chỉnh sửa, snapshot, clone và boot
    • Có thể dùng beadm create, beadm mount, beadm activate
    • Có thể tạo disk image hoặc ramdisk hoàn toàn mới rồi boot bằng VM hoặc PXE
    • Công cụ tạo image dành riêng cho Helios nằm trong công cụ image của helios-engvm
    • Các công cụ này có thể đưa gói quick build hoặc file bổ sung tùy ý vào image bằng cách sửa template image
    • Nền tảng là upstream illumos/image-builder

Image archive của OS

  • Trong quá trình build OS image cho compute sled của Oxide, image archive được tạo ra
  • Archive này chứa boot ROM và image ramdisk của root file system
  • Nó cũng chứa metadata trong file JSON và dùng định dạng giống omicron1 brand
  • Nội dung file là committed interface giữa Helios và một phần của Omicron, nơi cần tải xuống và cài đặt OS image lên hệ thống vật lý của Oxide Rack
  • Các file cần thiết để dùng Omicron tối thiểu bao gồm:
    • oxide.json: file header metadata có tối thiểu khóa v=1 và khóa t=os để nhận diện OS image
    • image/rom: host boot ROM image 32MiB
    • image/zfs.img: host root file system ramdisk image có kích thước tùy ý
  • Có thể có các file bổ sung cho mục đích kỹ thuật hoặc chẩn đoán
    • Ví dụ: kernel nén unix.z cho bldb hoặc nanobl-rs, boot archive nén cpio.z
    • Mảng file ROM bổ sung có suffix biểu thị các chức năng chẩn đoán khác nhau
  • Các file bổ sung không phải là committed interface và có thể thay đổi bất cứ lúc nào trong tương lai
  • Phần mềm diễn giải image archive phải bỏ qua các file không nhận diện được

Giấy phép

  • Bản quyền thuộc về Oxide Computer Company năm 2026
  • Trừ khi có ghi chú riêng, mọi thành phần được cấp phép theo Mozilla Public License Version 2.0

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-30
Các ý kiến trên Hacker News

  • Rất vui vì cái này đã được công khai, và tôi định triển khai cục bộ để học được nhiều nhất có thể
    Oxide gần như là công ty trong mơ, cả về stack công nghệ lẫn những con người làm việc ở đó

    • Sau khi lướt qua trang chủ khoảng 20 giây, tôi có cảm giác kiểu “Đây là tích hợp dọc để mua máy chủ on-premises à? Đến cả hệ điều hành tùy chỉnh nữa? Sao phải trả thêm mức premium làm gì?”
      Nhưng ngay sau đó tôi nghĩ tiếp: “Dù sao hệ điều hành máy chủ thì làm gì chứ? Chỉ cần chạy máy ảo là được, không phải sao? Có nhất thiết phải là Linux đâu, chỉ cần chạy được máy ảo Linux là được mà, đúng không?”
    • Tôi rất mong xem nó sẽ thế nào khi so với SmartOS
      Tôi đã đầu tư khá nhiều vào SmartOS trong hạ tầng cá nhân, nhưng sau thương vụ Joyent bị mua lại thì tôi khá lo về tương lai của nó
      Ước gì tôi làm ở một tổ chức đủ lớn để dùng thiết bị Oxide. Nếu không phải loay hoay với những cấu trúc tương thích kiểu IBM PC AT giả tạo, BMC và iDRAC cẩu thả, hay các bộ điều khiển RAID phần cứng thì chắc sẽ tuyệt lắm
    • Oxide gần như là công ty duy nhất mà tôi thật sự muốn làm việc
      Nhìn từ bên ngoài thì có cảm giác giống Sun, và đó chính là kiểu công ty mà tôi hằng mơ ước
      Tuy nhiên, với vị thế phải nuôi gia đình, cấu trúc lương của họ khiến tôi không kham nổi. Có lẽ khi con tôi tốt nghiệp đại học và tôi không còn cần thu nhập lớn nữa, lúc đó tôi mới có thể thực hiện giấc mơ này

  • Có ai có thể giải thích như cho trẻ 5 tuổi rằng Oxide cung cấp cái gì không? Tôi xem website mà vẫn không hình dung được
    Không rõ đây là phần cứng + phần mềm mua về dùng on-premises, là PaaS, hay lại là một nhà cung cấp cloud khác

    • Có vẻ bạn bị downvote vì đã có một thread lớn liên quan rồi, nhưng như vậy hơi không công bằng
      Nói kết luận trước thì đúng. Đây là phần cứng + phần mềm mua về dùng on-premises
      Điểm khác biệt so với phần lớn sản phẩm cloud on-premises hiện có là họ là một nhà cung cấp duy nhất thiết kế cả phần cứng lẫn phần mềm để hoạt động tốt cùng nhau. Phần mềm được làm open source nhiều nhất có thể, vì thế mới có những công bố như thế này
      Phần lớn sản phẩm khác là gom sản phẩm của nhiều nhà cung cấp rồi về thực chất là bán phần tích hợp. Oxide cho rằng cách đó sinh ra nhiều vấn đề, và sản phẩm của họ giải quyết các vấn đề ấy
      Một điểm nữa là chỉ có hai SKU: nửa rack và nguyên rack; không mua theo đơn vị 1U mà mua theo đơn vị rack
      Khi thiết kế cả rack như một đơn vị gắn kết, họ có thể làm những việc không thể làm trong form factor 1U. Có câu đùa rằng họ lúc nào cũng nói về quạt, nhưng đúng là vậy. Vì dùng các sled lớn hơn 1U truyền thống, họ có thể dùng quạt lớn hơn và chạy ở RPM thấp hơn, nhờ đó tiết kiệm điện
      Đây là một lựa chọn thiết kế có chủ đích, nhưng cũng có tác dụng phụ. Nhờ RPM thấp, máy chủ yên tĩnh hơn nhiều. Thậm chí có khách hàng tiềm năng ban đầu trong lúc demo đã hỏi: “Cái này đang bật thật à?”
      Chắc không ai mua máy chủ chỉ vì nó yên tĩnh, nhưng đây là một ví dụ thú vị về điều xảy ra khi nghĩ lại toàn bộ sản phẩm như một chỉnh thể, thay vì chỉ làm công việc tích hợp đơn thuần
    • Đây là một giải pháp compute và storage được tích hợp hoàn chỉnh cho on-premises, cho phép provision tài nguyên bằng API kiểu cloud, đồng thời đi kèm cam kết với open source

  • Tôi biết những người ở Oxide xuất thân từ Sun, nhưng việc chọn thứ không phải Linux có lợi thế kỹ thuật thực sự nào xét theo đề xuất giá trị kinh doanh không?
    Tôi biết illumos có những điểm tốt hơn Linux về mặt kỹ thuật, nhưng không rõ điều đó có thực sự quan trọng với khách hàng mua sản phẩm này không
    Có phải họ đang mở ra một vấn đề phức tạp, khiến khó bán được nhiều máy tính hơn vì lý tưởng hay truyền thống không?
    Với góc nhìn của người vận hành workload container Linux, việc thứ này về cơ bản là không phải Linux không phải là lý do để mua, mà là lý do để do dự khi mua. Tôi biết nó có thể chạy các binary Linux mà không cần sửa đổi

    • Sản phẩm không nói kiểu “nhân tiện, bên trong có illumos, và vì thế bạn nên mua rack này”
      Đây không phải là chi tiết sản phẩm lộ ra với khách hàng, và rất có thể phần lớn khách hàng thậm chí còn không biết điều đó
      Điều khách hàng quan tâm là rack có hiệu quả, ổn định và phù hợp với nhu cầu của họ hay không. Ở đây, việc chọn illumos thay vì Linux là lựa chọn nhằm cung cấp giá trị đó một cách hiệu quả
      Tất nhiên điều đó không có nghĩa là không thể xây một sản phẩm tương tự trên Linux; chúng tôi chỉ đánh giá rằng illumos phù hợp hơn với mục đích
      Quyết định này được đưa ra cùng với đội ngũ dưới dạng RFD[1], và dù mang số #26, hiện nó chưa được công khai. Các phương án được xem xét nghiêm túc là KVM của Linux và bhyve của illumos, và đó là một tài liệu khá dài
      Cuối cùng phải chọn một con đường, và chúng tôi đã chọn con đường này. Dù tôi không trực tiếp phát triển phần này, đến nay không có lý do gì để xem nó là trở ngại; ngược lại, nhiều khả năng đó là lựa chọn đúng
      Tôi tò mò vì sao việc không phải Linux lại trở thành lý do phản đối mua hàng. Sẽ rất tốt nếu bạn giải thích thêm. À, tôi đã thấy bình luận bên dưới: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios chỉ là chi tiết triển khai của rack, giống Hubris[0], không phải thành phần hiện ra với người dùng hay ứng dụng. Người dùng rack sẽ cấp phát máy ảo
      Vì sao họ dùng một nhánh phái sinh từ illumos thay vì thứ khác đã được đề cập phần nào trong Q&A[1] khi xuất xưởng rack đầu tiên, và dự kiến sẽ được giải thích lại trong buổi thảo luận ghi hình[2] sau hôm nay
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • Trong lĩnh vực embedded hay appliance, Linux rất dễ trở thành ác mộng
      Các kỹ sư nền tảng phải dành cả ngày sửa vấn đề ở kernel mới nhất, driver và các thư viện cốt lõi, rồi ứng dụng thực tế lại phụ thuộc lên trên đó
      Hoặc họ đi theo con đường như 99% nhà cung cấp IoT: không bao giờ cập nhật hệ điều hành nền, và cầu mong không có exploit đang hoạt động nào nhắm vào nó
      Vì vậy nhiều công ty tầm trung đã khổ sở với vấn đề CentOS. Bởi họ có thể ở trên một nền tảng tương đối ổn định và nhận cập nhật bảo mật mà không cần trả phí để vận hành một bản cài RHEL đầy đủ
      Khoảng 10 năm một lần vẫn phải xem lại toàn bộ phụ thuộc, nhưng dễ hơn rất nhiều so với việc chạy theo chu kỳ cập nhật 1–2 năm. Có những hệ thống chỉ riêng thời gian kiểm chứng đã hơn 6 tháng, nên chu kỳ đó là quá ngắn
      Đây gần như là vấn đề riêng của Linux, còn các lựa chọn thay thế như *BSD cung cấp phần lớn những gì Linux đem lại nhưng ít bị vỡ liên tục như vậy hơn nhiều
    • Việc có thêm lựa chọn là điều lành mạnh, và thậm chí có cảm giác như vũ trụ đã hồi phục phần nào sau khi Oracle mua Sun
      Khó có thể hình dung nhóm người nào phù hợp hơn để kết nối các hệ thống Oxide lại với nhau
      Hiện tôi là kỹ sư chỉ làm việc với Linux, nhưng tôi vẫn nhớ thời từng có thêm một Unix mạnh mẽ khác để chạy các workload giá trị cao
      Nếu so sánh openvswitch của Linux với tính năng Crossbow SDN của Solaris, tôi sẽ chọn Crossbow bất cứ lúc nào
      Không phải Linux là sai, nhưng các công cụ cứ đi theo đường riêng và tạo ra độ phức tạp, rồi lại phải trừu tượng hóa bằng các công cụ còn phức tạp hơn ở phía trên, nên nó thiếu trầm trọng sự gắn kết ở mức “kế hoạch tổng thể”
    • Khách hàng chạy hệ điều hành được ảo hóa trên nền này
      Nó không khác nhiều so với Azure Host OS, Bottlerocket, Flatcar
      Điều quan trọng là họ biết toàn bộ stack, một phần mã kernel họ đã nắm từ thời Sun, và có thể công khai cho những khách hàng muốn truy cập mã nguồn vì đánh giá bảo mật

  • Tôi không rành illumos nên vào xem trang web thì ngay đầu có ghi “illumos is a Unix operating system”
    illumos có phải là Unix thật sự như macOS không, hay là hệ điều hành kiểu Unix như GNU/Linux?

    • Là Unix thật sự. Phần mô tả trên Wikipedia khá tốt: https://en.wikipedia.org/wiki/Illumos
      Nó dựa trên OpenSolaris, còn OpenSolaris dựa trên System V Release 4(SVR4) và Berkeley Software Distribution(BSD). Illumos gồm kernel, driver thiết bị, thư viện hệ thống và phần mềm tiện ích để quản trị hệ thống. Phần lõi này trở thành nền tảng cho nhiều bản phân phối Illumos mã nguồn mở, tương tự như kernel Linux là nền tảng cho nhiều bản phân phối Linux
    • Chưa ai trả tiền để vượt qua bài kiểm thử chứng nhận Unix Branding của Open Group
      https://www.opengroup.org/openbrand/register/
      Vì vậy không thể dùng nhãn hiệu UNIX™
      Nhưng bên trong có kernel AT&T Unix và mã nguồn user space
      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...
    • Về mặt pháp lý thì NetBSD cũng không phải Unix thật sự. Thương hiệu đó không mang đúng ý nghĩa mà mọi người thường nghĩ
    • Đây là một nhánh mã nguồn mở của Solaris mà Ian Murdock ở Sun từng làm với tên Project Indiana, và có nguồn gốc từ UNIX SVR4
    • Là Unix thật sự. Theo tôi biết thì thuộc dòng Solaris

  • Không phải tôi không ủng hộ Oxide, nhưng sản phẩm hiện vẫn quá ngách và ở giai đoạn quá sớm, nên khó hình dung các doanh nghiệp thực sự sẽ mua nó trong một thời gian nữa
    Mãi đến cuối hè năm ngoái họ mới xuất xưởng rack đầu tiên cho khách hàng đầu tiên, mà khách hàng đó cũng là Idaho National Laboratory
    Có vẻ hiện tại nơi có thể đặt cược kiểu này thực tế chỉ là các viện nghiên cứu quốc gia

    • Khi công bố hồi tháng 10 năm ngoái có nhắc đến hai khách hàng: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Khách hàng của Oxide bao gồm Idaho National Laboratory và một tổ chức dịch vụ tài chính toàn cầu. Các triển khai bổ sung cho doanh nghiệp Fortune 1000 cũng dự kiến hoàn tất trong vài tháng tới
    • Mọi sản phẩm ở giai đoạn đầu tồn tại đều trông như vậy cả
      Nếu định ra mắt theo cách khác thì coi như đã làm hỏng công ty ngay từ trước khi ra mắt. Một số ít may mắn vẫn sống sót, nhưng chính điều đó góp phần vào thống kê 9 trên 10 startup thất bại
      Phải tập trung cực độ vào nhóm khách hàng đầu tiên để vượt qua vực thẳm, rồi sau đó mới đến thị trường đại chúng
    • Hy vọng một ngày nào đó họ cũng ra sản phẩm homelab nhỏ hơn và rẻ hơn
      Mọi người có thể học hoặc startup có thể dùng thử, rồi về sau dẫn tới bán rack hoặc tuyển dụng
    • Tôi làm ở một công ty công nghệ mới niêm yết gần đây, và khi đánh giá on-premise chúng tôi đã nghiêm túc cân nhắc Oxide
      Đề xuất này vẫn thuyết phục được cả những người nghĩ “on-premise cơ à… ừm”
      Có vẻ nó mang lại trải nghiệm giống cloud trên chính phần cứng của bạn
      Giá mà nó chỉ cần rẻ như Dell thì tốt
    • Công ty chúng tôi cũng đã xem xét, và sản phẩm gây ấn tượng rất mạnh
      Vấn đề duy nhất là nó được thiết kế cho compute đa dụng, trong khi chúng tôi thật sự cần tùy chọn bộ xử lý nhanh hơn

  • Tôi rất thích việc tài liệu trông rõ ràng và trực quan. Cá nhân tôi cho rằng tài liệu là lĩnh vực mà cộng đồng illumos trước đây gặp khó khăn
    Thấy nhắc đến consolidations trong bản phát hành mã nguồn mới khiến tôi thấy ấm lòng. Tuy nhiên, nếu tôi không hiểu sai lớn về cách tổ chức repository, thì có vẻ nó đi theo hướng khác với mô hình gate truyền thống
    Tôi có vài câu hỏi, chủ yếu liên quan đến công cụ. Vì sao là gmake? Dù sao về sau có vẻ cũng sẽ cần dmake
    Trong hướng dẫn có ghi rõ chạy rustup bằng bash; đó là lỗi upstream hay sh cục bộ không hoàn toàn tương thích POSIX?
    Phát triển nội bộ được thực hiện như thế nào? Người ở Oxide dùng workstation chạy illumos, hay tất cả đều phát triển trong máy ảo hoặc SSH vào server?
    Vì sao là MPL? Có phải vì tương thích GPL không?

    • Tôi không trực tiếp làm trên helios nên không thể trả lời hết, nhưng có thể trả lời một phần
      Về việc người ở Oxide có dùng workstation illumos hay phát triển qua máy ảo/SSH vào server hay không, tôi đã viết ở đây: https://news.ycombinator.com/item?id=39181727
      Dù vậy thực tế cũng có người dùng illumos trên workstation
      Về MPL thì ở đây: https://news.ycombinator.com/item?id=39181844
      Trong bình luận đó tôi không nói sâu về “vì sao”, nhưng tôi xem đó là một thỏa hiệp tốt trong không gian các khả năng. Nó copyleft hơn BSD, nhưng ít hạn chế hơn GPL
    • Tôi hiểu đó là vấn đề upstream
      Giống như hầu hết dự án mã nguồn mở, ở đó cũng có Linuxism/Bashism
    • Vì lý do lịch sử, khi build hệ điều hành lõi thì dùng dmake, nhưng khi tạo Makefile mới trong consolidation khác thì thường khuyên dùng GNU make(gmake)
      Nó phổ biến, dùng được trên các nền tảng khác, và có các tính năng hiện đại hơn

  • Phần mềm là mã nguồn mở thì rất tuyệt, nhưng liệu có thể triển khai và dùng trên phần cứng khác không?
    Nếu vì lý do nào đó công ty không thể mua thêm rack Oxide nữa, họ phải xây lại hạ tầng từ đầu, hay vẫn có thể tiếp tục mở rộng quanh phần cứng Oxide?

    • Khả năng nó hữu ích ngay bên ngoài phần cứng của chúng tôi là không cao, nhưng chức năng chính là triển khai máy ảo.
      Nếu quyết định không dùng rack Oxide đã mua nữa, chỉ cần chuyển các máy ảo sang hạ tầng kế tiếp mà bạn chọn.

  • Tôi thật sự tò mò các công ty sẽ muốn chạy workload nào trên một Unix tùy biến không phải Linux/Mac/BSD.
    Tôi ủng hộ việc có thêm sự đa dạng hệ điều hành trưởng thành hơn, nhưng không hình dung được người dùng cuối là ai và họ sẽ có nhu cầu gì.

    • Tài nguyên compute được provision trên rack Oxide là các máy ảo. Họ đã port bhyve từ FreeBSD và cũng bổ sung live migration.
      Nếu thật sự cần, có lẽ cũng có thể boot Windows Server.
      Lý do dùng Illumos một phần đúng là vì có nhiều người đến từ Sun, Joyent, nên có thiên hướng tự nhiên.
      Nhưng cũng có lý do khá thuyết phục rằng đây không phải là máy tính cá nhân x86 tương thích IBM. Không có BIOS, không có UEFI, không có BMC truyền thống; có vẻ họ dùng x86 hiện đại nhưng loại bỏ tối đa firmware độc quyền và binary blob.
      Mỗi sled có một service processor và hardware root of trust; thành phần này trực tiếp boot CPU, nạp AMD training blob, rồi boot hệ điều hành.
      Sẽ rất khó upstream những thay đổi như vậy vào Linux hay BSD cho một loại máy tính hiện tại chỉ họ có. Cuối cùng vẫn phải duy trì một fork downstream riêng, và cũng không có bên nào khác chịu trách nhiệm về độ vững chắc của hệ điều hành, nên dùng hệ điều hành mà họ đã hỗ trợ và phát triển nhiều năm là lựa chọn hợp lý hơn.
    • Đây không phải là chi tiết người dùng nhìn thấy trong sản phẩm.
      Khách hàng chạy máy ảo trên rack, chứ không build ứng dụng cho illumos.
      Họ sẽ chạy bất kỳ hệ điều hành nào cần thiết bên trong máy ảo đó để đạt mục tiêu của mình.
    • ZFS là native trên illumos, và các chức năng tương đương container hóa cũng khá tốt.
      Nếu có thể tuyển đủ nhân sự, lập luận rằng các máy chủ trong cloud không nhất thiết phải cùng một hệ điều hành cũng khá thuyết phục.
    • Có lẽ bạn cũng sẽ không biết rằng đây không phải Linux.
      Bạn không chạy code trên hệ điều hành này, mà chạy code trên các máy ảo do hệ điều hành này cung cấp.

  • Tôi tò mò mọi người lần đầu biết đến Oxide như thế nào.
    Tôi tình cờ nghe podcast của họ, và với tôi nó giống marketing cực kỳ hiệu quả. Họ làm mọi thứ trừ việc bán sản phẩm trực tiếp.
    Có lẽ thêm một đoạn pitch ngắn ở cuối mỗi tập cũng hay.
    Kiểu như đang kể “chúng tôi đã rất vất vả để khiến compiler làm một việc gì đó”, rồi lạc sang chuyện ngày xưa.
    Dù vậy tôi vẫn mong họ tiếp tục kể, và chúc họ thành công.

    • On The Metal, podcast ban đầu, nổi tiếng vì lặp đi lặp lại quá mức 2–3 đoạn tự quảng bá thu sẵn, đến mức fan còn tự thu quảng cáo và đề nghị họ phát.
      Ngược lại, Oxide and Friends không hẳn là podcast truyền thống, mà giống bản ghi một “space” trực tiếp hoặc cuộc gọi nhóm hơn; ban đầu diễn ra trên Twitter, nay diễn ra trên Discord.
      Tôi nghĩ định dạng này phù hợp nhất khi tham gia trực tiếp hơn là chỉ nghe như podcast. Khi nghe trực tiếp, bạn sẽ hiểu không khí của bản ghi tốt hơn nhiều.
      https://oxide.computer/podcasts/oxide-and-friends
    • Trước đây tôi theo dõi @jessfraz trên Twitter, nên khi Oxide lần đầu được công bố, tôi biết đến họ từ đó.
    • Tôi biết đến Oxide khi Pentagram công bố branding lúc Oxide lần đầu được giới thiệu.

  • Tôi đã mong chờ điều này từ khi họ công bố rack máy chủ.
    Vì nếu Oxide phá sản thì sẽ không ai muốn những thiết bị trở thành cục chặn giấy.

    • Nói rõ hơn, “vấn đề cục chặn giấy” đó cũng rất quan trọng với chúng tôi.
      Cần nhớ rằng MPL không xét đến việc một bản sao có được đăng công khai trên GitHub hay không.
      Tôi không phải luật sư, nhưng theo MPL, vẫn có nghĩa vụ đối với khách hàng bất kể người không phải khách hàng có thể xem mã hay không.