รายงานความคืบหน้า Asahi Linux 7.0

 (asahilinux.org)
1 คะแนน โดย GN⁺ 3 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การรองรับ Linux สำหรับ Apple Silicon มีความคืบหน้าไปพร้อมกันหลายด้าน ตั้งแต่ การทำงานอัตโนมัติของตัวติดตั้ง, การจัดการพลังงาน, เสียง, จอแสดงผล ไปจนถึงการเปิดใช้งาน M3
  • Asahi Installer ได้เปลี่ยนไปแยกอิมเมจแมนิเฟสต์ออกจากโค้ดเบส และนำการปล่อยใช้งานผ่าน GitHub workflow มาใช้ ทำให้อัปเดตได้บ่อยขึ้น โดยในเวอร์ชัน 0.8.0 ได้อัปเดต m1n1 stage 1, รองรับการติดตั้งบน Mac Pro และเพิ่มโหมดอัปเดตเฟิร์มแวร์
  • เฟิร์มแวร์คาลิเบรต ALS สามารถดึงมาจาก macOS และอัปเดตใหม่ได้ภายหลังการติดตั้งแล้ว ปัญหาเสียง Bluetooth สะดุดหายไปด้วยการรองรับคำสั่ง Broadcom coexistence และการรองรับ PMP ช่วยลดการใช้พลังงานขณะว่างบน M1 Pro ได้ราว 0.5W
  • การรองรับ VRR ยังไม่สามารถเปิดเผยสู่ userspace ได้อย่างถูกต้องเนื่องจากข้อจำกัดของ Apple DCP แต่เมื่อ pull request ถูกรวมแล้ว จะสามารถบังคับเปิดผ่านพารามิเตอร์ของเคอร์เนลโมดูลได้ และงาน upstream ของสแตกเสียงก็เพิ่มทั้ง API แบบทั่วไปสำหรับ bus keeper และการรองรับ sample rate เพิ่มเติมของ CS42L84
  • ขอบเขตการรองรับ M3 ขยายไปถึง PCIe, อุปกรณ์รับเข้า, RTC, reboot controller และ NVMe ขณะที่ Fedora Asahi Remix 44 ยังคงกำหนดออกรุ่นให้ตรงกับช่วง Fedora 44 พร้อมโฟลว์การติดตั้งใหม่บนพื้นฐาน Plasma

การทำงานอัตโนมัติของตัวติดตั้งและการอัปเดตเฟิร์มแวร์

  • Asahi Installer ที่แทบไม่ได้อัปเดตมาราว 2 ปี มีรอบการอัปเดตที่ยาวเพราะขั้นตอนรีลีสแบบแมนนวลและการพึ่งพาสิทธิ์ผู้ดูแล CDN รวมถึงการเปลี่ยนแปลงที่สะสมมากขึ้นหลังแท็กในเดือนมิถุนายน 2024
  • ในการติดตั้งแบบ UEFI-only จะติดตั้งเพียง m1n1 stage 1, Devicetree และ U-Boot เท่านั้น ดังนั้นหาก Devicetree ที่มากับตัวติดตั้งไม่ตรงกับสิ่งที่เคอร์เนลคาดไว้ ก็จะบูตไม่ขึ้นตั้งแต่แรก
    • ระหว่างงาน upstream มีการเปลี่ยน Devicetree binding ทำให้ความไม่ตรงกันสะสมเพิ่มขึ้น และใน kernel 6.18 ก็มีการเปลี่ยนแปลงเกี่ยวกับ Apple USB มาก จนไม่สามารถบูต live media ที่เป็น 6.18 ขึ้นไปได้
  • แมนิเฟสต์ของอิมเมจที่ติดตั้งได้ถูกแยกไปไว้ที่ asahi-installer-data เพื่อให้สามารถอัปเดตได้ อย่างอิสระจากโค้ดเบสของตัวติดตั้ง
  • การปล่อยใช้งาน asahi-installer ตอนนี้ถูกทำให้เป็นอัตโนมัติด้วย GitHub workflow
    • การ push ไปยังสาขา main จะถูก build และอัปโหลดไปยัง https://alx.sh/dev โดยอัตโนมัติ
    • การ push GitHub tag จะถูก deploy ไปยัง https://alx.sh โดยอัตโนมัติ
  • เวอร์ชันล่าสุด 0.8.0 ได้อัปเกรด m1n1 stage 1 ที่มากับชุดเป็น 1.5.2 และเพิ่มการรองรับการติดตั้งบน Mac Pro รวมถึงโหมดอัปเดตเฟิร์มแวร์

ALS และการดึงเฟิร์มแวร์

  • ในสภาพแวดล้อม True Tone ของ Apple จำเป็นต้องวัดไม่ใช่แค่ความสว่างรอบข้าง แต่รวมถึงคุณลักษณะของสีแสงด้วย จึงทำให้การประมวลผลข้อมูล ALS และความแม่นยำของการคาลิเบรตมีความสำคัญมากขึ้น
  • แม้ตัวไดรเวอร์ AOP และ ALS จะทำงานได้แล้ว แต่หากไม่มี ข้อมูลคาลิเบรต ความแม่นยำของข้อมูล ALS ดิบที่ AOP ส่งออกมาก็จะต่ำ
    • ข้อมูลคาลิเบรตนี้เป็น binary blob ที่ต้องอัปโหลดเข้า AOP ตอนรันไทม์ และไม่สามารถนำไปแจกจ่ายต่อได้ จึงต้องดึงมาจาก macOS ตอนติดตั้ง
  • Asahi Installer จะรวบรวมเฟิร์มแวร์ที่ Linux ต้องใช้แล้วเก็บไว้ใน EFI System Partition จากนั้นโมดูล Dracut จะเมานต์สิ่งนี้เป็นไดเรกทอรีย่อยใต้ /lib/firmware/ เพื่อให้ไดรเวอร์ค้นหาเจอ
  • เพื่อป้องกันปัญหาที่ต้องใช้เฟิร์มแวร์เพิ่มหลังติดตั้งไปแล้ว ตัวติดตั้งจึงเปลี่ยนมารองรับ การอัปเดต vendor firmware package อัตโนมัติ
    • ตั้งแต่ ALS เป็นต้นไป ผู้ใช้สามารถบูตเข้า macOS หรือ macOS Recovery แล้วรันตัวติดตั้งอีกครั้ง จากนั้นทำตามพรอมป์ต์เพื่ออัปเดตเฟิร์มแวร์ที่จำเป็นได้
  • สำหรับการรองรับ ALS และการอัปเกรดเฟิร์มแวร์ในภายหลัง จำเป็นต้องใช้ Asahi kernel 6.19 ขึ้นไป และ iio-sensor-proxy

การจัดการพลังงานและ PMP

  • การใช้พลังงานขณะว่างยังเป็นปัญหาต่อเนื่อง โดยเฉพาะบน SoC ตระกูล Pro/Max/Ultra และการจัดการพลังงานของแพลตฟอร์มนี้ก็มีโครงสร้างซับซ้อนที่ PMGR และ PMP ทำงานเกี่ยวพันกัน
  • PMGR มีหน้าที่เปิดและปิดโดเมนพลังงานของ SoC ส่วน PMP จะรับและประมวลผล รายงานสถานะพลังงาน ที่ส่งผ่าน shared memory ระหว่างบล็อกต่าง ๆ ของ SoC กับแอปพลิเคชันคอร์
    • หาก PMP ไม่ถูกบูต มันจะไม่สามารถอ่านรายงานเหล่านี้ได้ และฟังก์ชันการจัดการพลังงานบางอย่างก็จะไม่ทำงานด้วย
  • ไดรเวอร์รองรับ PMP ที่สร้างโดย chaos_princess ทำให้ PMP รับรายงานจากบล็อกของ SoC และ PMGR ได้ และสามารถลดการใช้พลังงานขณะว่างบน MacBook Pro 14 นิ้ว M1 Pro ได้ ราว 0.5W
    • คิดเป็นการลดพลังงานขณะว่างประมาณ 20%
  • แม้จะยังต้องมีงานเพิ่มเพื่อให้ไปถึงระดับเวลา idle/suspend แบบ macOS แต่การเปลี่ยนแปลงครั้งนี้ก็ถือว่าเป็นก้าวใหญ่
  • M1 รุ่นพื้นฐานใช้ PMP รุ่นเก่า ที่ไม่เข้ากันกับรุ่นหลัง ๆ และ dd-dreams กำลังดำเนินงานรองรับส่วนนี้อยู่
  • PMP ยังไม่ได้รับการทดสอบบนอุปกรณ์ที่รองรับทั้งหมด และยังไม่มีแผนเปิดใช้เป็นค่าเริ่มต้นก่อนจะถูกรวมเข้า upstream
    • ผู้ใช้ที่สามารถแก้ไข Devicetree ได้ สามารถเปิดใช้งานโดยกำหนด APPLE_USE_PMP ใน DTS ของอุปกรณ์

แก้ปัญหาเสียง Bluetooth สะดุด

  • Bluetooth และ WiFi ใช้ย่าน 2.4GHz เดียวกัน จึงเกิดการรบกวนกันได้ง่าย และการเชื่อมต่อที่ต้องการความหน่วงต่ำและความต่อเนื่องอย่างสตรีมเสียงก็ต้องการลำดับความสำคัญที่สูงกว่า
  • การตั้งค่า coexistence ของ Broadcom ถูกจัดการผ่าน คำสั่งขยายเฉพาะผู้ผลิต ของ Bluetooth HCI แต่ Linux kernel upstream ยังไม่รองรับ ทำให้เกิดการสูญเสียแพ็กเก็ตเสียงระหว่างการสแกน Bluetooth
    • หาก KDE Connect กระตุ้นให้เกิดการสแกน Bluetooth ก็อาจทำให้เกิดเสียง drop ได้
  • chaos_princess ได้เพิ่มการรองรับคำสั่งนี้ในสแตก Bluetooth ของเคอร์เนล และ BlueZ จะทำเครื่องหมายทุกสตรีมเสียงเป็น high priority จึงทำให้มีการทริกเกอร์คำสั่งที่จำเป็นระหว่างการสตรีมโดยอัตโนมัติ
  • ผลลัพธ์คือปัญหา Bluetooth audio dropout จะไม่เกิดขึ้นอีกต่อไป

DCP และ VRR

  • อินเทอร์เฟซเฟิร์มแวร์ของ DCP มีขนาดใหญ่มากและไม่เสถียรในแต่ละเวอร์ชัน และที่ผ่านมา หลังรองรับจอแสดงผลพื้นฐานแล้ว งานฮาร์ดแวร์ด้านอื่นถูกให้ความสำคัญก่อน ทำให้ฟีเจอร์อย่าง VRR ยังถูกทิ้งค้างไว้
  • การรองรับ VRR ต้องมีทั้งการแลกเปลี่ยนแพ็กเก็ตพิเศษระหว่าง display controller กับจอแสดงผล, การปรับ vertical blanking ตามจังหวะการแสดงเฟรม, การประกาศความสามารถ VRR ของจอแสดงผล และการเชื่อมต่อกับ KMS
  • ระหว่างการไล่ตรวจพบว่า พารามิเตอร์ DCP ที่เคยตั้งเป็น 0 ตอนจ่ายไฟให้จอภายนอก จะสลับระหว่าง 0x300000 กับ 0x0 เมื่อเปิด/ปิด VRR
    • จอทดสอบมีอัตรารีเฟรชต่ำสุดที่ 48Hz และในรูปแบบ fixed-point ของ DCP ค่า 48 คือ 0x300000
    • พารามิเตอร์นี้ไม่ใช่สำหรับลำดับการจ่ายไฟ แต่เป็น ตัวสลับค่ารีเฟรชต่ำสุดของ VRR และหากใส่ 0 ก่อน modeset ก็จะทำให้ VRR ถูกปิด
  • จอภายใน ProMotion ของ MacBook Pro ก็เปิดใช้งานด้วยวิธีเดียวกัน แต่เนื่องจากพาเนลภายในไม่ประกาศ EDID/DisplayID ไดรเวอร์ Linux จึงต้องตรวจว่าจอเป็น LCD ภายในหรือไม่ แล้ว ตั้งค่าคุณสมบัติที่จำเป็นแบบคงที่
  • VESA DisplayPort Adaptive Sync และ KMS API ไม่อนุญาตให้การสลับสถานะ VRR ต้องใช้ modeset แต่ Apple DCP ไม่สามารถหลีกเลี่ยงสิ่งนี้ได้
    • ด้วยข้อจำกัดนี้ จึงยังไม่สามารถเปิดเผย VRR ให้ userspace ได้อย่างถูกต้อง และ KWin ก็จะเพิกเฉยต่ออินเทอร์เฟซแบบนั้น
  • ตอนนี้เมื่อ pull request ถูกรวมแล้ว จะสามารถเปิด การบังคับใช้ VRR ผ่านพารามิเตอร์เคอร์เนลโมดูล appledrm.force_vrr ได้
    • หากจอรองรับ VRR, DCP จะใช้งาน VRR โดยไม่แจ้ง KMS หรือ compositor
    • ทดสอบกับ KWin แล้วทำงานได้ดี แต่ประสบการณ์บน compositor อื่นอาจต่างกัน
  • ฝั่ง HDMI ไม่ได้ห้าม modeset ระหว่างการสลับ VRR และ display controller อื่นอย่าง Intel ก็ทำงานคล้ายกัน
    • ใน upstream ยังมีการถกเถียงกันระหว่างแนวทางเปิดโหมด VRR ไว้ตลอดเวลา กับแนวทางยอมให้มี modeset ระหว่างการสลับ และเมื่อได้ข้อสรุปแล้วก็มีแผนจะเปิดเผย VRR ในรูปแบบที่เป็นไปตามคาด

งาน upstream ของสแตกเสียงและการขยาย sample rate

  • งาน upstream ของสแตกเสียงทั้งหมดกำลังดำเนินต่อเนื่อง โดยไดรเวอร์ที่เกี่ยวกับช่องหูฟังและแอมป์ลำโพงของ Cirrus Logic และ Texas Instruments, อุปกรณ์ต่อพ่วง I2S และการเปลี่ยนแปลง Apple DMA controller ได้ถูกรวมเข้าไปแล้ว
  • การป้องกันลำโพงของแพลตฟอร์มนี้ทำงานโดยให้แอมป์ TI ส่งค่าแรงดันและกระแสผ่าน I2S กลับเข้า SoC แล้วนำไปคำนวณอุณหภูมิของวอยซ์คอยล์ร่วมกับ Thiele/Small Parameters ของลำโพง
    • บน macOS เป็นหน้าที่ของ CoreAudio และบน Linux เป็นหน้าที่ของ speakersafetyd
  • ในโครงสร้างที่ขา data transmit ของหลายแอมป์ถูกต่ออนุกรม และเส้นสัญญาณซ้าย/ขวาถูก OR รวมกัน เมื่อฝั่งหนึ่งกำลังส่ง อีกฝั่งต้องรับประกันค่า logic low จึงจำเป็นต้องมีการตั้งค่า bus keeper
  • เดิมที bus keeper ถูกจัดการผ่านไดรเวอร์ชิปแอมป์และ Devicetree binding แบบเฉพาะ แต่ใน upstream มันจำกัดเกินไป จึงถูกเปลี่ยนเป็น API แบบทั่วไป
    • ตอนนี้ ASoC component ใด ๆ ก็สามารถประกาศว่ามี bus keeper ที่ตั้งค่าได้ และ platform driver ก็สามารถใช้การตั้งค่าที่จำเป็นตอนรันไทม์ได้
    • patchset นี้ถูกรวมใน Linux 7.1
  • การรองรับชิปรุ่นดัดแปลงเฉพาะของ Apple ก็ยังขยายต่อไป
    • แอมป์ลำโพง TI เพิ่มการรองรับรุ่นดัดแปลงของ Apple เข้าในไดรเวอร์ upstream ของ TAS2764 และ TAS2770 ได้ค่อนข้างตรงไปตรงมา
    • CS42L84 แตกต่างจาก CS42L42 มาก จึงต้องใช้ไดรเวอร์ Linux แยกต่างหาก และได้ถูกรวมเข้า upstream แล้ว
  • หากอิงเพียงการแกะรอย macOS ก็จะมีข้อจำกัดว่ารองรับเฉพาะฟังก์ชันที่ macOS ใช้ และ CS42L84 เองก็เริ่มต้นมาด้วยการรองรับเพียง 48kHz และ 96kHz
    • ข้อจำกัดนี้ทำให้ PipeWire ต้อง resample สตรีมอื่น ๆ ส่งผลให้ใช้ CPU และแบตเตอรี่มากขึ้น รวมทั้งคุณภาพเสียงลดลง
  • เมื่อนำค่า sample rate มาตรฐานอื่นจาก datasheet ของ CS42L42 มาใช้กับไดรเวอร์ CS42L84 ก็พบว่ารองรับฮาร์ดแวร์ที่ 44.1, 88.2, 176.4, 192kHz ได้ทั้งขาเข้าและขาออกของช่องหูฟัง
    • แพตช์ดังกล่าวถูกส่งเข้า upstream แล้วและถูกรวมใน Linux 7.1 รวมถึงถูก backport มายัง Asahi kernel 6.19.9 ด้วย

ขยายการรองรับ M3

  • ในต้นไม้เคอร์เนลของ Asahi ยังมีแพตช์เปิดใช้งานฮาร์ดแวร์เพิ่มเติมสำหรับ อุปกรณ์ M3 เข้ามาอย่างต่อเนื่อง
  • ขอบเขตที่รวมแล้วขยายไปถึง PCIe, คีย์บอร์ดและแทร็กแพดของ MacBook, RTC และ reboot controller ที่อิง SMC รวมถึง NVMe controller
  • จากผลงานของ Michael Reeves และ Alyssa Milburn ระดับการรองรับ Linux บน M3 ตอนนี้ขึ้นมาถึง ขั้นที่ใกล้เคียงกับ Asahi Linux alpha รุ่นแรกสำหรับ M1 แล้ว
  • การเปิดให้ติดตั้ง M3 ได้ทันทีผ่าน Asahi Installer ยังไม่พร้อมเต็มที่ และยังคงมีความคืบหน้าต่อเนื่อง

Fedora Asahi Remix 44

  • แม้ Fedora Asahi Remix 43 จะล่าช้า แต่ Fedora Asahi Remix 44 ยังยืนยันแผนออกรุ่นในวันที่ 28 เมษายน พร้อมกับ Fedora Linux 44 หรือภายในไม่กี่วันจากนั้น
  • การติดตั้งใหม่ที่อิง KDE Plasma จะใช้ประโยชน์จากความสามารถใหม่ของ Plasma 6.6
    • Plasma Setup จะมาแทนวิซาร์ดตั้งค่าที่อิง Calamares เดิม และมอบโฟลว์การสร้างบัญชีและตั้งค่าระบบแบบเนทีฟของ Plasma
    • Plasma Login Manager จะกลายเป็น greeter และ session manager ค่าเริ่มต้น แทนที่ SDDM
  • การเปลี่ยนแปลงนี้ใช้กับ การติดตั้งใหม่เท่านั้น และจะไม่เปลี่ยนการตั้งค่าของผู้ใช้ที่อัปเกรดมาจาก Fedora Asahi Remix รุ่นก่อนหน้า
  • Fedora Asahi Remix 44 จะยุติแพ็กเกจ Mesa และ virglrenderer แบบ vendored
    • ผู้ใช้ที่ยังไม่ได้สลับด้วยตนเอง จะถูกย้ายไปใช้แพ็กเกจ Mesa และ virglrenderer จากคลัง upstream ของ Fedora โดยอัตโนมัติ

การสนับสนุนและโครงสร้างพื้นฐาน

  • โครงการยังคงเปิดรับการสนับสนุนผ่าน OpenCollective และ GitHub Sponsors
  • Bunny ให้การสนับสนุนโครงการด้วย CDN และบริการโฮสติ้งฟรี มาตั้งแต่ช่วงเริ่มต้น

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

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

 
GN⁺ 3 일 전
ความคิดเห็นบน Hacker News

  • เดิมที CS42L84 ถูกตั้งค่าให้ใช้แค่ 48/96 kHz บน macOS แต่พอนำค่าสำหรับ sample rate อื่นจาก datasheet ของ CS42L42 มาใส่ในไดรเวอร์ ก็พบว่ามันทำงานได้ตามปกติ
    แพตช์ที่รองรับ 44.1/88.2/176.4/192 kHz สำหรับอินพุต/เอาต์พุตที่ช่องหูฟังได้ถูกรวมเข้า upstream แล้ว, ถูกรวมใน 7.1 และยังถูก backport ไปยัง Asahi kernel 6.19.9 ทำให้ใช้งานได้ทันที
    การไล่แกะชิปและทำ reverse engineering น่าประทับใจมาก

    • จุดที่น่าทึ่งที่สุดคือ ถ้ารองรับแค่ 48/96 kHz PipeWire จะต้อง resample ทำให้ใช้ CPU และแบตเตอรี่มากขึ้น
      Apple เป็นบริษัทที่หมกมุ่นกับประสิทธิภาพพลังงาน แต่ก็ชวนสงสัยว่าทำไมยังปล่อยไว้แบบนี้
    • การที่ตอนนี้เล่น CD/FLAC แบบ 44.1 kHz bit-perfect ได้ ดูเป็นฟีเจอร์ใหญ่มากจริง ๆ

  • งานเขียนเชิงเทคนิคและผลงานของทีม Asahi น่าทึ่งมากจริง ๆ แต่ก็ยังน่ากังวลอยู่นิดหน่อยที่สิ่งนี้ยังคงเป็น โปรเจกต์แยกต่างหาก แทนที่จะอยู่ในรูปแบบที่ยั่งยืนภายใน kernel mainline หรือดิสโทรกระแสหลักอย่าง Ubuntu, Debian, Fedora
    โปรเจกต์ reverse engineering มักไปถึง 80% แล้วให้ผลลัพธ์ที่มีประโยชน์ได้ไม่ยาก แต่การจะไปถึง ความสมบูรณ์ระดับ 95% ที่ขัดเกลาพอสำหรับผู้ใช้ทั่วไป มักต้องใช้แรงงานจุกจิกและหนักหน่วงเพิ่มอีกเกือบเท่าเดิม

    • Asahi เองก็กำลัง upstreaming ไปในทิศทางนั้นอย่างมาก
      เหตุผลใหญ่ที่ความคืบหน้าช้าลงช่วงหลัง ก็เพราะโฟกัสกับการลดจำนวน diff และงานจำนวนมากก็เข้า mainline kernel ไปแล้ว
      Asahi ยังทำหน้าที่เป็นพื้นที่สำหรับทดลองฟีเจอร์ใหม่ด้วย
    • ยังมีอุปสรรคเพิ่มเติมตรงที่ ARM Mac เองก็เป็นเป้าหมายที่ขยับตลอดเวลา
      Apple ไม่มีความตั้งใจจะให้ความเสถียรหรือการรองรับเพื่อ Asahi Linux เลย และก็ไม่มีเหตุผลต้องรักษาความเข้ากันได้ระยะยาวแบบอุตสาหกรรมพีซี ดังนั้นต่อให้ในอนาคตมีการเปลี่ยนแปลงที่ทำให้ Asahi ลำบากขึ้น ก็คงไม่ใส่ใจนัก
    • ข้อดีของ Linux คือมันเป็น ซอฟต์แวร์เสรี จึงไม่ต้องผูกกับผู้ถือหุ้นหรือความทำกำไร
      ฉันใช้ Asahi เป็น OS หลักบน M1 MacBook Air และค่อนข้างพอใจ แม้จะมีข้อเสียดายอย่างแบตเตอรี่ลด 1% ต่อชั่วโมงระหว่าง sleep แต่ในสภาพตอนนี้ก็ยังดีกว่าไม่มีเลยเพียงเพราะยังไม่สมบูรณ์ 100%
      และก็ไม่ค่อยรู้สึกว่ามันจำเป็นต้องถูกขัดเกลาให้สมบูรณ์แบบสำหรับตลาดมวลชนขนาดนั้น
    • การพัฒนา mainline kernel ปกติก็เป็นแบบที่ทุกคนทำงานบน fork ของตัวเองก่อน แล้วค่อยส่งแพตช์ขึ้น upstream
      ที่ Asahi ดูพิเศษก็เพราะมีฮาร์ดแวร์แปลกและเฉพาะทางเยอะ เลยต้องใช้ไดรเวอร์เฉพาะจำนวนมาก ไม่ได้มีใครพัฒนาบน tree ของ Linus โดยตรงอยู่แล้ว
    • งานบรรยายที่ 39c3 https://youtu.be/3OAiOfCcYFM ก็ดีเหมือนกัน
      สุดท้ายแล้วเป้าหมายคือทำให้ Linux รองรับ Apple Silicon แบบเนทีฟ

  • หวังว่าโปรเจกต์นี้จะรักษาโมเมนตัมต่อไปได้
    ชุดผสม ฮาร์ดแวร์ Apple + Linux ให้ความรู้สึกเหมือนเป็น OS ที่พังน้อยที่สุดบนฮาร์ดแวร์ที่ดีที่สุด ขณะที่ macOS ดูสับสนขึ้นเรื่อย ๆ จากบั๊กและการเปลี่ยนแปลงกลับไปกลับมาในแต่ละเวอร์ชัน

    • ถ้าลองใช้ Framework กับ Fedora อาจเปลี่ยนความคิดก็ได้
      ประสบการณ์ลื่นไหลมาก และ Framework 13 Pro ที่กำลังจะออกก็มีความคาดหวังว่าแบตเตอรี่กับแทร็กแพดจะระดับ macOS หรือแบตเตอรี่อาจดีกว่าด้วยซ้ำ
    • ฉันใช้มาครบทั้งสาม OS หลักแล้ว และรู้สึกว่า macOS มีบั๊กน้อยที่สุด และใช้งานได้ลื่นที่สุด
      Linux มักจบลงที่ต้องทำแพตช์แปลก ๆ เพราะปัญหาออดิโอหรือความเข้ากันได้ของหน้าจอ ส่วน Windows ก็มีปัญหาแบตเตอรี่หนัก
      หลายคนที่ชอบปรับแต่ง Linux ดูเหมือนสุดท้ายก็ต้องการ ประสบการณ์แบบ Mac ที่ปรับแต่งได้มากกว่าอยู่ดี
    • โดยรวมก็จริง แต่ ecosystem รอบ ๆ MLX แข็งแรงและเกาะกลุ่มกันมาก
      ถึง disk I/O จะไม่ดีนักและ OS ก็มีบั๊ก แต่อย่างน้อย ML ก็ยังคอมไพล์และรันได้บน OS รุ่นล่าสุด
      ตรงกันข้าม rocm เหมือนจะเกือบเสร็จอยู่เสมอ แต่สุดท้ายกลับต้องใช้แพ็กเกจที่ build ไว้ล่วงหน้าหรือ Ubuntu ที่เก่ากว่าสองปี เลยน่าหงุดหงิด
      https://github.com/ROCm/TheRock/issues/3477
    • ช่วงหลังได้ลองใช้ MacBook Air ทำงาน และก็เห็นด้วยได้ยากกับคำว่า ฮาร์ดแวร์ระดับดีที่สุด
      แค่จ่ายเพิ่ม 5 ยูโรก็น่าจะหาแป้นพิมพ์ที่ดีกว่านี้ได้แล้ว

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

    • เหตุผลจริงอาจเรียบง่ายกว่านั้น
      Apple มีกำไรจากฮาร์ดแวร์สูง ดังนั้นแค่ขาย MacBook ให้ผู้ใช้ Linux ก็ทำกำไรได้ แต่ทันทีที่ยอมรับการ รองรับ Linux อย่างเป็นทางการ มันก็จะกลายเป็นภาระด้านการซัพพอร์ตทันที
      ทุก kernel panic จะกลายเป็นการเดินเข้าร้าน Genius Bar และทุกบั๊กไดรเวอร์ก็จะมีคนเรียกหา @AppleSupport ดังนั้นการปล่อยให้เป็นสถานะไม่เป็นทางการแบบตอนนี้ อาจเป็นสถานการณ์ที่ดีที่สุดสำหรับ Apple เพราะขายฮาร์ดแวร์ได้แต่ไม่ต้องรับภาระซัพพอร์ต
    • แทบไม่มีผลประโยชน์ทางการเงิน และทุกครั้งที่ฮาร์ดแวร์เปลี่ยนก็จะมีภาระต้องจัดทำเอกสารสำหรับ Linux เพิ่ม
      อีกทั้งกลุ่มผู้ใช้ก็เล็ก แต่กลับเป็นกลุ่มที่เสียงดังและวิจารณ์เก่งที่สุด ซึ่งคงไม่ดึงดูด Apple นัก
    • การขีดเส้นว่า เราไม่เล่นเกมนี้ ไปเลย อาจง่ายกว่าการถูกด่าว่าเปิดบางส่วนหรือทำลายความเข้ากันได้ของอินเทอร์เฟซที่ไม่เปิดเผย
      ภายในองค์กรเองก็คงหลีกเลี่ยงการต้องถกเถียงเรื่องที่ไม่เกี่ยวกับลำดับความสำคัญได้ด้วย
    • รู้สึกว่านี่แทบจะเชื่อมกับเรื่อง right to repair เลย
      แล็ปท็อปประกอบด้วยชิ้นส่วนฮาร์ดแวร์หลายอย่างและไดรเวอร์ที่ทำให้มันทำงาน เลยชวนให้ถามว่า สิ่งที่ฉันซื้อมาคือแพ็กเกจที่ฮาร์ดแวร์กับไดรเวอร์แยกจากกันไม่ได้ หรือฉันควรมีสิทธิ์ได้คู่มือเพื่อซ่อมหรือกู้คืนอีกฝั่งเองเมื่ออีกฝั่งหนึ่งพัง
      Apple อาจอ้างได้ว่าไดรเวอร์ไม่สึกหรอเหมือนเฟืองหรือมอเตอร์ แต่ก็ไม่ได้แปลว่าสิทธิในการรู้ว่ามันทำงานอย่างไรควรหายไปด้วย
      ถ้าวันหนึ่งมีคดีทดสอบที่ /System/Trackpad.kext โดนยานอวกาศยิงหายไป แล้วต้องเขียนไดรเวอร์เองจนไปขอเอกสารในศาล ก็คงไม่ใช่เรื่องน่าแปลกนัก
    • ฟังดูมีเหตุผล
      การที่ Apple รองรับสิ่งนี้น่าจะเป็นเรื่องง่าย และ ความนิยมเชิงบวก ที่ได้จากชุมชนก็น่าจะมากพอสมควร

  • สงสัยว่าถ้ามีสปิน Asahi Remix ที่โฟกัสกับ ประสบการณ์เริ่มต้นแบบ Mac จะมีคนสนใจไหม
    เช่น ใช้ cmd เป็นปุ่ม modifier หลัก พร้อมตั้งค่าคีย์ลัด ธีม และ gesture แบบ Mac มาให้เป็นค่าเริ่มต้น
    จะไปปรับดิสโทรไหนเองก็ได้ก็จริง แต่ค่าเริ่มต้นที่คัดสรรมาอย่างดีมีคุณค่าอีกแบบ

    • การใช้ cmd เป็น “ปุ่ม modifier หลัก” ยังดูคลุมเครือ
      ในสภาพแวดล้อม X/Wayland ทั่วไป ทุกอย่างฝั่งฟังก์ชันของ DE ก็ยึด Cmd อยู่แล้ว ส่วนในระดับแอปก็ยึด Ctrl เป็นหลัก ถ้าเปลี่ยนจะเกิดส่วนทับซ้อนเยอะมาก
    • ฉันทำให้ KDE ออกมาคล้ายแบบนั้นได้ค่อนข้างสำเร็จ
      ให้ Claude Code ช่วยทำ มันค้นเว็บแล้วสร้างไฟล์ตั้งค่าให้เลย
    • คีย์แมปแบบยึด Cmd เป็นหลัก นี่แทบจะเป็นศึกที่แพ้ไปแล้ว
      ฉันลองมาหลายรอบ สุดท้ายก็ยอมรับชีวิตแบบ Ctrl และขาย MacBook เครื่องสุดท้ายไปแล้ว

  • ชวนสงสัยว่าอะไรจะทำให้ฝันเรื่อง MacBook Pro + Linux ในฐานะเครื่องพัฒนาที่สมบูรณ์แบบ กลายเป็นจริงก่อนกัน ระหว่างฮาร์ดแวร์กับซอฟต์แวร์
    ต้องรอดูว่า Asahi จะไปถึงก่อนในฝั่งซอฟต์แวร์ หรือ Framework จะไปถึงก่อนในฝั่งฮาร์ดแวร์

  • ถ้ามีชุด MacBook Neo + Asahi ออกมา ก็น่าจะทรงพลังมากจริง ๆ

  • ยินดีที่เห็นว่า การรองรับ M3 กำลังคืบหน้าอย่างมั่นคง พร้อมกับการสะสาง upstream backlog และปรับปรุง tooling
    แพตช์รองรับ PCIe, คีย์บอร์ดและแทร็กแพดของ MacBook, RTC แบบอิง SMC และ reboot controller, รวมถึง NVMe controller กำลังเข้า Asahi kernel tree และทำให้ระดับการรองรับ Linux บน M3 ขยับขึ้นมาใกล้เคียงกับ Asahi Linux alpha รุ่นแรกสำหรับ M1 แล้ว

    • ด้วยความเร็วระดับนี้ อาจต้องรอถึงตอน M6 ออก กว่าจะพอใช้งานได้จริงก็ได้

  • การที่รายงานโปรเจกต์แบบนี้ยังมี ทางออกใหม่ ๆ โผล่มาเรื่อย ๆ และชี้ได้แม่นยำว่าผู้ใช้จริงเจอความไม่สะดวกตรงไหน แสดงให้เห็นว่าทีม Asahi มีความชำนาญมากจริง ๆ
    ทำให้อยากกลับไปใช้ Asahi แบบเต็มตัวอีกครั้งในไม่ช้า

  • ข่าวว่า M3 ใกล้ระดับ alpha นั้นยอดเยี่ยมมาก และยังทำให้คาดหวังกับ M4 ต่อได้
    ตรงกันข้าม แทบไม่คาดหวังเลยว่า Apple จะไปทำอะไรกับ macOS อีกในปีนี้หรือปีหน้า