เขียน Unix clone ได้ในเวลาประมาณหนึ่งเดือน

 (drewdevault.com)
3 คะแนน โดย GN⁺ 2024-05-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bunnix เริ่มต้นเป็นโปรเจกต์ส่วนตัวเพื่อพักผ่อน โดยทดลองดูว่าจะสร้างระบบปฏิบัติการตระกูล Unix สำหรับ x86_64 ได้ไกลแค่ไหนภายในประมาณหนึ่งเดือน และใช้เวลาทำงานจริง 27 วัน
  • เคอร์เนลเขียนด้วย Hare เป็นหลัก และใช้คอมโพเนนต์ภาษา C ร่วมด้วย เช่น lwext4 สำหรับรองรับ ext4 และ libvterm สำหรับวิดีโอเทอร์มินัลของเคอร์เนล
  • รองรับทั้ง legacy boot และ EFI และทดสอบกับแล็ปท็อปจริงบางเครื่องแล้ว แต่เนื่องจาก ยังไม่รองรับ USB จึงต้องใช้คีย์บอร์ด PS/2 หรือการจำลอง PS/2 ของ BIOS
  • user space อาศัย ซอฟต์แวร์ third-party เป็นหลัก เช่น dash, Doom, gzip, less, mandoc, sbase, tcc, Vim 5.7 ส่วน libc เป็น musl libc ที่ปรับแก้ให้เหมาะกับ Bunnix
  • Bunnix ใช้งานได้แต่ยังมีบั๊กมากและยังเป็นระบบผู้ใช้คนเดียว โดยใกล้เคียงกับการทดลองที่นำไปสู่การปรับทำ Helios ใหม่และปรับปรุงการออกแบบเคอร์เนล มากกว่าจะเป็นโปรเจกต์สำหรับดูแลระยะยาว

ขอบเขตและการรัน Bunnix

  • Bunnix เป็นโปรเจกต์ ระบบปฏิบัติการตระกูล Unix สำหรับ x86_64 ที่เริ่มเมื่อวันที่ 21 เมษายน 2024
  • หากไม่นับวันที่ไม่ได้ลงมือทำจริง ใช้เวลาทั้งหมด 27 วัน
  • มี Bunnix 0.0.0 iso ให้รันได้โดยตรง
  • บน qemu สามารถบูต ISO ได้ด้วยคำสั่งต่อไปนี้
qemu-system-x86_64 -cdrom bunnix.iso -display sdl -serial stdio
  • สามารถเขียน ISO ลง USB stick แล้วบูตบนฮาร์ดแวร์จริงได้ด้วย
    • มีแนวโน้มว่าจะทำงานได้บนเครื่อง AMD64 ส่วนใหญ่
    • ทดสอบแล้วบน ThinkPad X220 และ Starlabs Starbook Mk IV
    • รองรับทั้ง legacy boot และ EFI
  • ข้อจำกัดด้านการรันที่ใหญ่ที่สุดคือ ยังไม่รองรับ USB
    • ต้องใช้คีย์บอร์ด PS/2 หรือการจำลอง PS/2 ของ BIOS
    • คีย์บอร์ดแล็ปท็อปส่วนใหญ่เชื่อมต่อแบบ PS/2
    • การจำลอง PS/2 สำหรับคีย์บอร์ด USB จะทำงานหรือไม่ขึ้นอยู่กับสภาพแวดล้อม
  • พอร์ต Doom มีข้อจำกัดด้าน key binding และการออกจากเกม
    • เคลื่อนที่ด้วย WASD
    • ยิงด้วย Shift ขวา
    • เปิดประตูด้วย Space
    • การออกจากเกมไม่ทำงาน จึงต้องรีบูตหลังเล่น

โครงสร้างเคอร์เนลและฟีเจอร์ที่รองรับ

  • เคอร์เนล Bunnix เขียนด้วย Hare เป็นส่วนใหญ่ และใช้คอมโพเนนต์ C บางส่วนร่วมด้วย
    • ใช้ lwext4 สำหรับรองรับไฟล์ซิสเต็ม ext4
    • ใช้ libvterm สำหรับวิดีโอเทอร์มินัลของเคอร์เนล
  • ไดรเวอร์ที่รองรับเน้นขอบเขตที่จำเป็นต่อฮาร์ดแวร์พื้นฐานและการบูตจากสตอเรจ
    • PCI legacy
    • อุปกรณ์บล็อก AHCI
    • ตารางพาร์ทิชัน GPT และ MBR
    • คีย์บอร์ด PS/2
    • พอร์ตอนุกรมของแพลตฟอร์ม
    • นาฬิกา CMOS
    • เฟรมบัฟเฟอร์ที่ bootloader ตั้งค่าไว้
    • ไฟล์ซิสเต็ม ext4 และ memfs
  • ยังรวมฟีเจอร์เคอร์เนลพื้นฐานที่จำเป็นสำหรับระบบตระกูล Unix

    • ไฟล์ซิสเต็มเสมือนและอุปกรณ์

      • มี /dev พร้อมอุปกรณ์บล็อก, อุปกรณ์เทียม null, zero, full, /dev/kbd, /dev/fb0, serial และ video TTY, รวมถึง controlling terminal /dev/tty
      • มี terminal emulator ที่ค่อนข้างสมบูรณ์และรองรับ termios ในระดับหนึ่ง

    • system call และโมเดลผู้ใช้

      • รองรับ system call ประมาณ 40 รายการ เช่น clock_gettime, poll, openat, fork, exec, pipe, dup, dup2, ioctl
      • ปัจจุบัน Bunnix เป็น ระบบผู้ใช้คนเดียว
      • ไม่บังคับใช้ Unix file mode และ ownership
      • อยู่ในสภาพที่หากทำต่ออีกไม่กี่วันก็น่าจะทำให้เป็นระบบหลายผู้ใช้ได้

Bootloader และ user space

  • Bunnix มี bootloader สองตัว
    • bootloader สำหรับ legacy boot เข้ากันได้กับ multiboot และเขียนด้วย Hare
    • bootloader สำหรับ EFI เขียนด้วย C
  • bootloader ทั้งสองโหลดเคอร์เนลเป็นไฟล์ ELF และ initramfs เมื่อจำเป็น
    • bootloader EFI รวม zlib ไว้เพื่อคลายบีบอัด initramfs
    • bootloader ที่เข้ากันได้กับ multiboot จะจัดการการคลายบีบอัดแทน
  • user space ส่วนใหญ่ประกอบจาก ซอร์ส third-party
    • Colossal Cave Adventure advent
    • dash /bin/sh
    • Doom
    • gzip
    • less
    • lok /bin/awk
    • lolcat
    • mandoc
    • sbase core utils
    • tcc C compiler
    • Vim 5.7
  • libc สืบทอดมาจาก musl libc และมีการแก้ไขหลายอย่างให้ตรงกับความต้องการของ Bunnix
  • ไลบรารี curses อิงจาก netbsd-curses
  • ระบบทำงานได้ แต่มีบั๊กจำนวนมากและบางส่วนถูกทำขึ้นอย่างเร่งด่วน จึงควรเตรียมรับมือกับการ crash

ปัจจัยที่ทำให้ทำได้เร็วและจุดยาก

  • โค้ด Bunnix บางส่วนมาจากโปรเจกต์ก่อนหน้า Helios
    • รวมโค้ดเคอร์เนลบางส่วนเกี่ยวกับการตั้งค่า CPU ทั่วไป เช่น GDT, IDT
    • ไดรเวอร์บางตัว เช่น AHCI ก็ถูกปรับให้เข้ากับระบบ Bunnix
    • มองว่าหากไม่มีประสบการณ์จาก Helios คงยากที่จะทำ Bunnix ได้เร็วขนาดนี้
  • การผสาน การรองรับ ext4 และ virtual terminal ยากเป็นพิเศษ
    • นำ dependency ภายนอกอย่าง lwext4 และ libvterm เข้ามาใช้
    • ชั้นไฟล์ซิสเต็มถูกเขียนใหม่หลายครั้ง และตอนนี้ก็ยังมีบั๊กอยู่
    • เพื่อให้ใช้งานการออกแบบไฟล์ซิสเต็มแบบ Unix ได้ถูกต้อง รวมถึง openat และการจัดการ inode จึงต้องเจาะลึกภายใน lwext4 มากขึ้น
  • ยังได้ประสบการณ์ในการลิงก์ซอร์ส Hare, assembly และ C ร่วมกันภายในโปรเจกต์ Hare
    • โดยรวมทำงานได้ดี แต่มีความไม่สะดวกในส่วนของการสร้างกลไกรวม ABI
    • เกิดความต้องการให้แปลง C header เป็นโมดูล forward declaration ของ Hare ได้อัตโนมัติ
    • งานที่เกี่ยวข้องมีอยู่บางส่วนใน hare-c แต่ยังต้องทำเพิ่ม
  • การตั้งเป้าพอร์ต Vim ทำให้ การทำเทอร์มินัล ยากขึ้น
    • libvterm เป็นไลบรารี state machine สำหรับเทอร์มินัลที่ดี แต่เอกสารยังไม่เพียงพอ
    • ต้องปรับจูนรายละเอียดเล็ก ๆ จำนวนมากเพื่อผสานให้ถูกต้อง
    • ยังใช้เวลาไปกับ การปรับแต่งประสิทธิภาพ เพื่อให้ทำงานได้ลื่นไหล
  • scheduler เป็นส่วนที่ทิ้งโค้ดจาก Helios ไปมากและเขียนใหม่
    • ทั้ง Helios และ Bunnix ต่างเป็นระบบ CPU เดียว
    • Bunnix ต่างจาก Helios ตรงที่อนุญาตให้ context switch ภายในเคอร์เนลได้
    • การสลับงานแบบ preemptive ก็เข้าและออกผ่านเคอร์เนลเช่นกัน
    • โครงสร้างนี้ต้องใช้ kernel stack หลายชุดและวิธีสลับงานที่ต่างออกไป
    • เมื่อมี scheduler ที่แข็งแรงพอ งานแบบ blocking เช่น การอ่านดิสก์หรือ pipe(2) ก็สามารถทำได้ง่ายด้วย wait queue
  • การทำ signal จำเป็นเพื่อให้เข้ากันได้กับ Unix
    • Helios ไม่ได้ตั้งเป้าเป็น Unix จึงทำงานได้โดยไม่มี signal
    • ใน Bunnix ปรับให้ SIGCHLD ทำงานได้ถูกต้องเป็นหลักเพื่อพอร์ต dash
    • implementation ของ signal ขั้นสุดท้ายยังอยู่ในระดับพื้นฐานมาก

บทเรียนด้านการออกแบบที่ต่อยอดไปสู่ Helios

  • Bunnix เป็น monolithic kernel ส่วน Helios เป็นการออกแบบ microkernel ที่ไม่ใช่ Unix
  • ในไฟล์ซิสเต็ม ได้เห็นความสำคัญของ caching
    • Helios แยก implementation ของไฟล์ซิสเต็มไว้ในหลายไดรเวอร์และโปรเซสแยกต่างหาก
    • แม้เพียงเพื่อ track object ที่ยังมีชีวิตอยู่ caching ในชั้นไฟล์ซิสเต็มก็สำคัญ
    • เมื่อปรับทำ Helios ใหม่ จึงมีงานจำนวนมากในการ refactor หรือเขียนโค้ดไฟล์ซิสเต็มใหม่
  • แนวทางการเข้าถึงไดรเวอร์เรียบง่ายกว่าโดยธรรมชาติใน monolithic kernel
    • อย่างไรก็ตาม ยังไม่ได้พอใจเต็มที่กับการใส่หลายสิ่งไว้ใน ring 0
    • มีช่องทางที่จะนำองค์ประกอบของ control flow จากการออกแบบแบบ monolithic บางส่วนไปสะท้อนใน scheduler ของ Helios
  • ในการจัดการหน่วยความจำ bitmap allocator ทำงานได้ดีกว่าที่คาด
    • ใน Helios เคยพยายามหลีกเลี่ยง bitmap allocator และการจัดการหน่วยความจำเป็นจุดที่ยุ่งยากมาก
    • Bunnix ใช้ bitmap allocator แบบง่ายกับหน้าหน่วยความจำทั่วไปทั้งหมดของระบบ
    • overhead ไม่มากอย่างที่กังวล และทำงานได้ดีมาก
  • มองว่าการสร้าง Bunnix ภายใน 30 วันคงเป็นไปไม่ได้ด้วยการออกแบบแบบ microkernel
    • monolithic kernel ทำให้ implementation ง่ายกว่ามาก
    • ข้อดีของการออกแบบแบบ microkernel ก็น่าสนใจเช่นกัน และคำตอบที่ดีกว่าอาจเป็น hybrid kernel

สถานะโปรเจกต์และรายการปรับปรุงที่เหลือ

  • Bunnix ใกล้เคียงกับ art project ที่แทบสมบูรณ์แล้ว มากกว่าจะเป็นสิ่งที่จะทุ่มเวลาเพิ่มจำนวนมากต่อจากนี้
    • อาจทำต่อครั้งละไม่กี่วันเป็นบางครั้ง
    • การปรับปรุงจากชุมชนสามารถส่ง patch ได้ทาง public inbox
  • งานพัฒนา OS หลังจากนี้คือกลับไปทำ Helios โดยอาศัยบทเรียนจาก Bunnix เพื่อออกแบบส่วนสำคัญใหม่
  • รายการ candidate สำหรับลำดับความสำคัญในการปรับปรุงมีดังนี้
    • directory cache สำหรับไฟล์ซิสเต็มและการปรับปรุง caching โดยรวม
    • แก้บั๊ก ext4
    • procfs และ top
    • file mmap
    • signal เพิ่มเติม เช่น SIGSEGV
    • รองรับหลายผู้ใช้
    • อุปกรณ์บล็อก NVMe
    • อุปกรณ์บล็อก IDE
    • รองรับ ATAPI และ ISO 9660
    • รองรับ Intel HD audio
    • network stack
    • Hare toolchain ในระบบพื้นฐาน
    • self-hosting

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

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

 
GN⁺ 2024-05-25
ความคิดเห็นจาก Hacker News

  • เจ๋งมาก ทำให้นึกถึงเรื่องที่ว่าเดิมที Unix เองก็ถูกสร้างขึ้นในช่วงไม่กี่สัปดาห์ที่ตระกูล Ritchie ไปพักร้อนที่แคลิฟอร์เนียเพื่อไปเยี่ยมพ่อตาแม่ยาย
    ที่มาคือ UNIX: A History and a Memoir ของ Brian W. Kernighan

    • แต่ประเด็นสำคัญคือก่อนจะเขียน Unix ก็มีการทำงานกับ Multics กันมานานแล้ว ถ้าจำไม่ผิด Unix ค่อนข้างจะเป็นเวอร์ชันที่ “ทำให้ง่ายลง” ของสิ่งนั้น มากกว่าจะโผล่มาจากความว่างเปล่าแบบฉับพลัน
    • น่าจะหมายถึง Ken Thompson มากกว่า ขี้เกียจไปหาอินเทอร์วิวใน YouTube มายืนยัน แต่จำได้ว่าเขาเคยเล่าหลายครั้งทำนองว่า ตอนนั้นมีไดรเวอร์ดิสก์กับโปรแกรมบางตัวและองค์ประกอบอื่น ๆ อยู่แล้ว และตอนที่ภรรยาออกเดินทาง เขาก็คิดว่าน่าจะใช้ช่วงว่างนั้นเติมส่วนที่ขาดจนกลายเป็นระบบปฏิบัติการเต็มรูปแบบได้
    • ถ้าพูดถึงตัว Unix เอง คงต้องบอกว่าใช้เวลานานอยู่ ถ้านับ V7 เป็น “Unix ที่สมบูรณ์จริง ๆ” ก็ต้องใช้เวลาหลายปี และเวอร์ชันแรก ๆ ก็มีแค่ระบบไฟล์ เป็นต้น
    • เท่าที่รู้ เรื่องที่เล่ากันคือมี โปรแกรม 3 ตัว ที่ยังขาดอยู่ และหนึ่งในนั้นคือตัวแก้ไขข้อความ
      ตอนนี้ความจำเริ่มเลือนแล้ว คงต้องไปตรวจดูอีกที
    • น่าจะสับสนระหว่าง Dennis Ritchie กับ Ken Thompson

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

    • ถ้ายังไม่เคยอ่าน ผมคงเริ่มจาก Advanced Programming in the Unix Environment ของ Stevens
      https://www.amazon.com/Advanced-Programming-UNIX-Environment...
      เป็นหนังสือที่ว่าด้วย Unix API ใน user space รวมถึงสัญญาณและโปรเซส
      ถ้าอยากรู้ว่าจะเริ่มตรงไหนดีสำหรับการอิมพลีเมนต์สัญญาณภายในเคอร์เนล ผมก็ไม่ค่อยแน่ใจเหมือนกัน แต่คงนึกถึง https://pdos.csail.mit.edu/6.828/2012/xv6.html
      การได้อ่านหนังสือที่อธิบายว่า Unix ทำงานอย่างไรอย่างชัดเจนและเป็นระบบ พร้อม ตัวอย่างที่พึ่งพาตัวเองได้ เป็นอะไรที่สดใหม่มาก ถ้าไม่รู้ C ก็อาจเป็นอุปสรรคได้ แต่เวลาอ่านบล็อกโพสต์ก็เหมือนกัน
      ผมไม่คิดว่าข้อมูลระดับเดียวกันนี้จะมีอยู่ครบถ้วนที่ไหนสักแห่งบนเว็บ ในบล็อกของผมเองก็มีเกร็ด Unix ที่คนยังอ่านกันอยู่เยอะ แต่ก็ไม่ถึงระดับเดียวกัน
      สำหรับการทำความเข้าใจสัญญาณของ Unix ผมมองว่านี่เป็นหนึ่งในหัวข้อที่การใช้บล็อกโพสต์, Google หรือ LLM นั้นไม่มีประสิทธิภาพมาก แม้จะซื้อมือสองก็ยังเรียกได้ไม่เต็มปากว่า “ถูก” แต่เป็นหนังสือที่ราคายังสูงเพราะข้อมูลมีคุณค่า และสำหรับโปรแกรมเมอร์ที่ทำงานจริงก็ยังถือว่าราคาไม่แพงนัก
    • สัญญาณอยู่ตรงจุดตัดระหว่าง asynchronous I/O/system calls กับ inter-process communication ซึ่งทั้งความเป็น asynchronous และ IPC ก็เป็นจุดอ่อนของการออกแบบ Unix มาตั้งแต่เดิม และไม่ใช่องค์ประกอบที่มีอยู่ตั้งแต่แรก
      สัญญาณคือความพยายามที่ค่อนข้างฝืนในการแปะ asynchronous IPC เข้าไปในดีไซน์ จึงเปราะบางต่อ race condition เช่น ถ้าระหว่างจัดการสัญญาณแล้วมีสัญญาณเข้ามาอีกจะเกิดอะไรขึ้น หรือถ้าโปรเซสกำลังอยู่ใน system call ตอนมีสัญญาณเข้ามาจะจัดการอย่างไร ต้องตัดสินใจว่าจะหน่วงไว้, เข้าคิวไว้ หรือดึงออกจาก system call
      ถ้า system call ทั้งหมดเป็น asynchronous ด้านนี้ก็จะถูกแก้ไป ตามหลักการออกแบบที่ระบบปฏิบัติการสมัยใหม่หลายตัวใช้กัน และถ้ามีระบบอย่างช่องทางที่เชื่อถือได้สำหรับ IPC ก็จะสามารถทำ asynchronous inter-process communication หรือแม้แต่ remote procedure call ที่ซับซ้อนกว่าสัญญาณได้ด้วย
    • คนที่ไม่ชอบสัญญาณของ Unix น่าจะเพราะมันแบกแนวคิดที่ต่างกันมากเกินไป
      SIGSTOP/SIGCONT/SIGKILL จริง ๆ แล้วไม่ได้เป็นการ “ส่งสัญญาณ” ให้โปรเซสมากเท่าไร แต่เป็นการควบคุมโปรเซส เช่น หยุดชั่วคราว, ทำงานต่อ, และจบการทำงาน
      ข้อความ asynchronous แบบง่าย ๆ อย่าง SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU ก็ถูกนำไปใช้พร่ำเพรื่อ เช่น ใช้สั่งให้อ่านคอนฟิกใหม่ และเกิดทางอ้อมแบบแฮ็ก ๆ อย่าง nohup เพื่อรองรับการ daemonize ขณะที่ gunicorn ก็ใช้สองตัวหลังสำหรับการขยายและย่อขนาดแบบไดนามิก ในหมวดนี้ยังมีตัวที่เฉพาะทางจนน่าแปลกอย่าง SIGWINCH ด้วย
      แล้วยังมีพวกอย่าง SIGILL, SIGSEGV, SIGFPE ที่ใช้แทนคำสั่งไม่ถูกต้อง, การละเมิด segmentation, และข้อยกเว้น floating-point อีกด้วย รวมถึงอย่าง SIGSYS ที่ก็ยังไม่ชัดด้วยซ้ำว่าควรทำให้เป็น asynchronous ตั้งแต่แรกหรือไม่
      วิธีอื่นก็มี trade-off เหมือนกัน Windows มี event, SEH, รูทีนจัดการ CTRL+C/CTRL+BREAK/การยุติการทำงาน, IOCP, callback ฯลฯ ส่วน notes ของ Plan 9 เป็นสตริง จึงมีข้อดีที่ส่งข้อมูลตามอำเภอใจไปยังโปรเซสอื่นได้ แต่การใช้กลไกเดียวกันนี้กับการควบคุมโปรเซสก็มีข้อเสียแบบเดียวกับ *nix และในมุมหนึ่งก็แค่เปลี่ยนจากตัวเลขเป็นสตริงเท่านั้น
    • บทความ “signalfd is useless” ดีมาก: https://ldpreload.com/blog/signalfd-is-useless
      พูดถึงปัญหาของสัญญาณใน Unix และอธิบายด้วยว่าทำไม signalfd ซึ่ง Linux สร้างขึ้นมาเพื่อแก้ปัญหานี้จึงทำงานได้ไม่ดีนัก
    • ตอนเขียนแอปพลิเคชันแบบ portable ความแตกต่างของ การจัดการสัญญาณระหว่าง BSD กับ SYSV เป็นปัญหา
      https://pubs.opengroup.org/onlinepubs/009604499/functions/bs...
      อีกจุดสำคัญคือโค้ดใน signal handler ต้อง reentrant ด้วย “โดยทั่วไปแล้ว ฟังก์ชันที่ไม่เป็น reentrant จะไม่ปลอดภัยสำหรับการเรียกใช้ภายใน signal handler”
      https://man7.org/linux/man-pages/man7/signal-safety.7.html

  • ฉันเคยสนใจ Hare แต่พอเห็นหัวข้อ FAQ นี้แล้วรู้สึกว่าเป็นนโยบายที่ทำลายตัวเองมาก: https://harelang.org/documentation/faq.html#will-hare-suppor...
    โดยหลักการแล้วฉันสนับสนุนให้นักพัฒนาใช้ไลเซนส์ที่ต้องการ เลือกระบบปฏิบัติการเป้าหมายที่ต้องการ และเขียนโค้ดที่ต้องการ
    แต่นั่นไม่ได้ทำให้นโยบายนี้กลายเป็นความคิดที่ดีแต่อย่างใด แม้แต่ FSF ซึ่งมักถูกมองว่าเป็นกลุ่มที่ยึดถือหลักการของปรัชญาซอฟต์แวร์เสรีอย่างสุดโต่งที่สุด ก็ยังรองรับทั้ง Windows และ POSIX ได้ จะบ่นพลางเรียกมันว่า Woe32 ก็ได้ แต่ Stallman ก็อธิบายไว้อย่างค่อนข้างน่าเชื่อว่าการทำให้โครงการซอฟต์แวร์เสรีทำงานได้บนระบบผูกขาดนั้นช่วยการต่อสู้เพื่อโลกที่ไร้ซอฟต์แวร์ผูกขาดได้มากกว่า
    โค้ดไลบรารีถูกให้ไลเซนส์แบบ MPL ดังนั้นการใช้ Hare อย่างเดียวไม่ได้ผูกคุณเข้ากับไลเซนส์ใดไลเซนส์หนึ่ง แต่ก็อดสงสัยไม่ได้ว่าอายุขัยของภาษาที่มีท่าทีต่อผู้ใช้เดสก์ท็อปกว่า 95% ว่า “ไม่รองรับ อย่ามาถามในฟอรัม อย่ามาที่นี่” จะเป็นอย่างไร
    น่าแดกดันที่ถ้าค้นหา “harelang repo” บน Google ผลลัพธ์แรกคือพอร์ต macOS ที่ไม่เป็นทางการ และที่เก็บบน SourceHut ตัวจริงกลับไม่ขึ้นมาในหน้าแรก
    ภาษานั้นมีแต่จะโตแบบลูกหิมะหรือไม่ก็หายไป ตอนนี้ฉันกำลังเขียนความเห็นนี้บน Mac แต่ถ้าอยากก็ไปใช้เครื่อง Linux ตอนนี้เลยก็ได้ แล้วทำไมฉันต้องเรียนภาษาที่บังคับ การทดสอบความบริสุทธิ์ กับนักพัฒนาในระดับที่แม้แต่ FSF ก็ยังไม่ทำ? โอเพนซอร์สและซอฟต์แวร์เสรีจำนวนมากถูกเขียนบน Mac และมีมากกว่าที่คนคิดที่ถูกเขียนบน Windows
    สำหรับฉัน สิ่งที่ทำให้ Hare ต่างจาก Odin หรือ Zig ก็คือท่าทีเรื่องความบริสุทธิ์และการกีดกันนี่เอง ขอให้แฮ็กอย่างสนุกและประสบความสำเร็จ แต่สำหรับอย่างหลังฉันมองในแง่ร้าย

    • ด้านหนึ่งก็พอเคารพได้ที่ผู้เขียนยืนหยัดกับสิ่งที่ต้องการทำและไม่ได้ตอบรับทุกคำขอ
      แต่อีกด้านหนึ่ง ใน FAQ ก็ไม่ได้มีแค่จุดนั้นที่ทำให้เลิกคิ้ว
      “ไม่มี package manager และสนับสนุนการนำโค้ดกลับมาใช้น้อยลงในฐานะคุณค่าร่วม”
      “qbe สร้างโค้ดที่ช้ากว่า LLVM และประสิทธิภาพอยู่ราว 25~75% ของโค้ดที่ LLVM สร้างซึ่งเทียบเคียงกันได้”
      “ใน Hare ใช้ multithreading ได้ไหม? น่าจะไม่”
      “งั้นฉันต้องเขียน hash table เองเหรอ? ใช่ hash table เป็นโครงสร้างข้อมูลพื้นฐานที่โปรแกรม Hare จำนวนมากต้องเขียนเองตั้งแต่ต้น”
      อย่างน้อยในตอนนี้มันไม่ใช่ภาษาที่ออกแบบมาโดยมุ่งหวังการยอมรับในวงกว้างอย่างชัดเจน ซึ่งก็ไม่เป็นไร และอย่างน้อยพวกเขาก็พูดตรง ๆ เรื่องนั้น
    • ฉันไม่เห็นด้วยกับคำว่า “บังคับ” ถ้าใครสักคนกำลังทำอะไรบางอย่างให้ฟรี ๆ ตราบใดที่ไม่ได้ทำด้วยเจตนาร้าย เขาก็ไม่ได้มีหน้าที่ต้องทำมันในแบบใดแบบหนึ่ง
      คุณมีเสรีภาพที่จะออกความเห็น แต่เมื่อผู้พัฒนาวางแนวทางไว้ชัดแล้ว ฉันมองว่าคำวิจารณ์แบบนี้ไม่ค่อยสร้างสรรค์
    • ดูเหมือนว่าคุณกับฝั่ง Hare จะมี นิยามของความสำเร็จ ต่างกัน คำว่า “ภาษามีแต่จะโตแบบลูกหิมะหรือไม่ก็หายไป” ก็ฟังดูเป็นการลดทอนภาษาจำนวนมากที่ค่อย ๆ เดินหน้ามาได้หลายสิบปีแม้ไม่ได้ดังระดับร็อกสตาร์
      ไม่ใช่ว่าทุกวงดนตรีจะต้องติดชาร์ต Billboard ถึงจะคุ้มค่าที่จะฟัง
    • ความหมายคือจะไม่รองรับ Windows หรือ macOS อย่างเป็นทางการ ถ้าใครต้องการ ก็ให้โครงการอื่นลองพอร์ตเองไม่ได้หรือ? การบอกอย่างตรงไปตรงมาถึง ระดับการรองรับ ที่ตั้งใจไว้ก็ดูเป็นเรื่องดี
      การรองรับระบบปฏิบัติการที่นักพัฒนาเองไม่ได้ใช้นั้นเป็นภาระใหญ่
    • คำว่า “ภาษามีแต่จะโตแบบลูกหิมะหรือไม่ก็หายไป” ไม่เป็นความจริงและเป็นมุมมองที่ไร้เดียงสา
      มีภาษาหลายตัวทีเดียวที่แม้จะไม่ได้รับความนิยมในภาพรวมมากนัก แต่กลับรุ่งเรืองในตลาดเฉพาะที่มั่นคงและมีบทบาทสำคัญ

  • น่าประทับใจมาก เจ๋งมาก และให้แรงบันดาลใจมาก ตัวอย่างประเภท “สร้างของน่าทึ่งภายใน X วัน” แบบนี้ต้องอาศัย ประสบการณ์และพรสวรรค์ ที่สั่งสมมาหลายปี

    • ถ้าเทียบกับทุกวันนี้ ฉันเพิ่งใช้เวลาเกือบหนึ่งสัปดาห์เพื่อเปลี่ยนข้อความบนปุ่มเดียวที่มีสตริง internationalization
      ต้องเอาข้อความภาษาอังกฤษเข้า catalog, อัปเดตการทดสอบหลายตัว, รันการทดสอบบนระบบโลคัล, เอาการเปลี่ยนแปลงขึ้น staging cluster, แก้การทดสอบที่พังแบบไม่คาดคิด, ขึ้น production, ขอให้ทีมแปลช่วยแปลเป็นหลายภาษา, และยังต้องอัปเดตเอกสารด้วย
    • เขายังเป็นผู้สร้าง KnightOS ที่เขียนด้วย Z80 assembly ล้วน ๆ ตั้งแต่เมื่อกว่า 12 ปีก่อนด้วย
      https://www.ticalc.org/archives/files/fileinfo/463/46387.htm...
    • Drew ฉลาดและตารางเวลาก็กระชั้นมาก แต่ฉันคิดว่าถ้ามองแบบยกย่องเขาอย่างเดียวก็มองผิดประเด็นไป การสร้าง UNIX clone นั้นส่วนใหญ่เป็นโปรเจกต์ระดับปริญญาตรีที่พบได้ทั่วไปในมหาวิทยาลัย
      สิ่งที่ต้องใช้ในการต่อยอดให้มันสมบูรณ์ไม่ใช่อัจฉริยภาพพิเศษ แต่คือความอึดและความสม่ำเสมอ
    • อีกอย่าง ยังมี Helios ซึ่งเป็นการทำเคอร์เนลก่อนหน้านี้อยู่แล้ว และให้โค้ดระดับล่างสุดมาพอสมควร ไม่ได้จะลดทอนความสำเร็จนะ แต่ DD ก็พูดค่อนข้างเปิดเผยว่า ความเร็วของโปรเจกต์นี้ส่วนใหญ่ขึ้นอยู่กับการที่สร้าง Helios มาก่อนแล้วนำโค้ดนั้นกลับมาใช้
    • เพราะมี Helios อยู่แล้ว จึงเหมือนแค่เอาชิ้นส่วนไม่กี่ส่วนที่ยังขาดมารวมเข้าไป

  • การได้เห็นอัปเดตที่โพสต์แทบทุกวันบน Mastodon นั้นยอดเยี่ยมจริง ๆ ได้เห็นคนที่มีทักษะค่อย ๆ ประกอบ ซอฟต์แวร์ที่ซับซ้อน ขึ้นมาทีละน้อย

  • โค้ดอยู่ที่นี่: https://git.sr.ht/~sircmpwn/bunnix/tree/master
    ใช้ไลเซนส์ GPLv3

  • user space ส่วนใหญ่เป็นการประกอบมาจากซอร์สของบุคคลที่สาม
    ตอนแรกฉันตกใจที่พอกด ISO แล้วขึ้นว่าเป็น ดาวน์โหลด 60MB แต่ก็เข้าใจเหตุผลแล้ว
    ถ้าเทียบกัน Linux 0.01 เป็นดาวน์โหลดขนาด 71KB แต่มีแค่ซอร์สเคอร์เนลเท่านั้น

  • Hare ดูเหมือนจะเป็นภาษาที่น่าสนใจ
    แต่ในยุคมัลติคอร์แบบนี้ ข้อจำกัดด้านล่างน่าจะเป็นอุปสรรคต่อการนำไปใช้
    ตาม FAQ https://harelang.org/documentation/faq.html เมื่อถามว่าสามารถใช้มัลติเธรดใน Hare ได้หรือไม่ ก็ตอบว่า “น่าจะไม่”
    สำหรับการทำ I/O multiplexing แนะนำให้ใช้ event loop และเมื่อจำเป็นต้องใช้ทรัพยากร CPU แบบขนาน ก็แนะนำให้ใช้หลายโปรเซสพร้อม shared memory
    พูดอย่างเคร่งครัดแล้ว ในโปรแกรม Hare สามารถสร้างเธรดได้ โดยลิงก์กับ libc เพื่อใช้ pthreads หรือเรียกใช้ system call clone(2) โดยตรงก็ได้ ระบบปฏิบัติการที่พัฒนาด้วย Hare อย่าง Helios ก็มักจะรองรับมัลติเธรด
    แต่ standard library ฝั่ง upstream ไม่ได้รับประกัน reentrancy ดังนั้นจึงต้องรับผิดชอบเองทั้งหมดเพื่อไม่ให้พลาดทำร้ายตัวเอง

    • “ถ้าต้องใช้ทรัพยากร CPU แบบขนาน ก็ใช้หลายโปรเซสพร้อม shared memory” นั้นจริง ๆ แล้วทรงพลังไม่น้อย
      ส่วนตัวผมชอบแนวทางนี้สำหรับการใช้งานส่วนใหญ่ เพราะมันจำกัดความเป็นไปได้ของ data race ให้อยู่แค่ในพื้นที่ shared memory เท่านั้น ในมุมของ data race มันให้ความรู้สึกเหมือน “unsafe block” ของหน่วยความจำ
    • ถ้า standard library ฝั่ง upstream ไม่รับประกัน reentrancy ก็ไม่ได้ตัดแค่มัลติเธรดเท่านั้น แต่ยัง ตัดการใช้งานภายใน interrupt ด้วย สำหรับ “ภาษาเขียนโปรแกรมระบบ” ผมคิดว่านี่เป็นข้อจำกัดที่ค่อนข้างใหญ่
    • อยากให้มี closure

  • เนื้อหานี้มาจาก “Linux System Call Table – Chromiumos” https://www.chromium.org/chromium-os/developer-library/refer... https://news.ycombinator.com/item?id=33395777
    google/syzkalleR
    Fuschia / Zircon system call: https://fuchsia.dev/fuchsia-src/reference/syscalls

    • มี system call ที่เพิ่งเพิ่มเข้ามาใหม่ในปีนี้ด้วย: mseal()
      “Memory Sealing ‘Mseal’ System Call Merged for Linux 6.10”
      https://news.ycombinator.com/context?id=40474551