ประสบการณ์ลองใช้ Alpine Linux ของผู้ใช้ BSD

 (rubenerd.com)
1 คะแนน โดย GN⁺ 2024-04-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้ใช้ที่คุ้นเคยกับเดสก์ท็อป BSD และใช้งาน chroot กับ jail อยู่บ่อยครั้ง ได้ลองทดสอบ Alpine Linux และมองว่าการออกแบบที่เน้นความปลอดภัย ความเรียบง่าย และประสิทธิภาพการใช้ทรัพยากรนั้นให้ความรู้สึกคุ้นเคยสำหรับผู้ใช้ BSD
  • ด้วยขนาดที่เล็กและการพึ่งพาแพ็กเกจอย่างจำกัด Alpine จึงถูกใช้อย่างกว้างขวางไม่เพียงเป็น อิมเมจฐานของคอนเทนเนอร์ แต่ยังรวมถึงระบบฝังตัว เราเตอร์ อุปกรณ์พกพา เซิร์ฟเวอร์ และเดสก์ท็อป
  • การติดตั้งทำในสภาพแวดล้อมแบบไลฟ์ โดยรัน setup-alpine เพื่อตั้งค่า พื้นฐาน อย่างคีย์แมป เครือข่าย ไทม์โซน SSH และ NTP ตามลำดับ
  • หลังบูตครั้งแรก จะเห็นการทำงานร่วมกันของ OpenRC, musl และ busybox โดยมีองค์ประกอบอย่าง /etc/rc.conf และ crond(8) ที่เชื่อมโยงกับประสบการณ์ rc แบบ BSD
  • หลังตรวจสอบการจัดการแพ็กเกจด้วย apk การตั้งค่าคลังแพ็กเกจ และความเป็นไปได้ในการติดตั้ง ZFS แล้ว ผู้เขียนประทับใจมากพอที่จะพิจารณาอย่างจริงจังให้เป็น ตัวเลือกดิสโทร Linux หลัก สำหรับงานทดสอบและเซิร์ฟเวอร์

ลักษณะของ Alpine ที่คุ้นเคยสำหรับผู้ใช้ BSD

  • Alpine Linux เป็น ดิสโทร Linux แบบอิสระ ไม่ใช่เชิงพาณิชย์ และใช้งานได้ทั่วไป สำหรับผู้ใช้ระดับสูงที่ให้ความสำคัญกับความปลอดภัย ความเรียบง่าย และประสิทธิภาพการใช้ทรัพยากร
  • ไบนารีใน user space ถูกคอมไพล์ด้วย PIE (Position Independent Executables) และ stack smashing protection โดยมุ่งลดโอกาสการใช้ประโยชน์จากช่องโหว่และซีโร่เดย์บางประเภท
  • Alpine เป็นโครงการที่เก่าแก่กว่าที่คาดไว้ โดย Natanael Copa เคยพูดถึงจุดเริ่มต้นของโครงการมาตั้งแต่ปี 2005
  • เช่นเดียวกับตระกูล BSD มันถูกใช้ทั้งในระบบฝังตัว เราเตอร์ อุปกรณ์พกพา รวมถึงเซิร์ฟเวอร์และเดสก์ท็อปทั่วไป
  • ด้วยขนาดเล็กและการพึ่งพาที่จำกัด จึงถูกใช้เป็น อิมเมจฐาน ของคอนเทนเนอร์ Linux อย่างแพร่หลาย และยังมีเครื่องมืออย่าง alpine-chroot-install สำหรับรันใน chroot(8) ได้อย่างง่ายดาย
    • จุดนี้น่าสนใจเป็นพิเศษสำหรับผู้ใช้ที่ใช้ NetBSD chroot(8) และ FreeBSD jail บ่อยครั้งในการทดสอบและการปรับใช้

ประสบการณ์การติดตั้ง

  • Alpine มีบิลด์หลายแบบ เช่น ARM, PPC64, x86 และ x86_64
  • ผู้เขียนบูตอิมเมจ Xen ISO บน VM แต่เป็นการเลือกที่อ่าน Dom0 ผิดเป็น DomU
    • Dom0 หมายถึง Xen hypervisor และไม่ใช่ guest
    • ถึงอย่างนั้นก็ยังบูตและติดตั้งต่อได้เหมือน ISO มาตรฐาน
  • การติดตั้งทำโดยล็อกอินด้วย root และรหัสผ่านว่างในสภาพแวดล้อมแบบไลฟ์ จากนั้นรัน setup-alpine
  • ระหว่างติดตั้ง จะตั้งค่ารายการพื้นฐานอย่าง คีย์แมป เครือข่าย ไทม์โซน และการยืนยันตัวตนของ root ทีละขั้น
  • สามารถใส่ SSH key ได้ตั้งแต่ช่วงเริ่มต้น
    • สิ่งนี้มีประโยชน์เมื่อจะปรับใช้ VM หรือกลุ่มเซิร์ฟเวอร์ด้วยเครื่องมือ orchestration ในภายหลัง
    • ยังช่วยได้ในสภาพแวดล้อมโฮสติ้งที่ไม่มี OOB console ให้
  • สามารถเลือก SSH server และ NTP client ได้ โดยผู้เขียนเลือก OpenSSH และ openntpd
  • กระบวนการติดตั้งตรวจพบได้อย่างถูกต้องว่ากำลังทำงานอยู่บน Xen
  • สามารถตั้งค่า LVM ได้เช่นกัน แต่ครั้งนี้เลือกโครงสร้างมาตรฐานที่ Alpine เรียกว่า sys partition
    • โครงสร้างนี้ใช้ ext4

โครงสร้างระบบที่เห็นหลังบูตครั้งแรก

  • หลังบูตครั้งแรก สามารถยืนยันได้จาก dmesg(1) ว่าระบบใช้ OpenRC
  • OpenRC เป็นระบบ init ที่มีความสามารถด้านการพกพา ขนาดเล็ก รวดเร็ว มีประสิทธิภาพ โปร่งใส และปลอดภัย
  • สำหรับผู้ใช้ที่คุ้นเคยกับการเขียนสคริปต์ rc แบบ BSD, OpenRC ให้ความรู้สึกคุ้นเคยมาก
    • องค์ประกอบอย่าง /etc/rc.conf และ crond(8) เชื่อมโยงกับประสบการณ์แบบ BSD โดยตรง
  • การมีดิสโทร Linux ที่ใช้ OpenRC อย่าง Devuan, Gentoo และ Alpine ทำให้ Linux กลับมารู้สึกสนุกอีกครั้ง
  • Alpine มาพร้อม musl และใช้ busybox ควบคู่กับ OpenRC
    • แม้ musl และ busybox จะมีขอบเขตจำกัดกว่า GCC และ GNU coreutils แต่ก็ช่วยให้ ระบบฐานมีขนาดเล็ก และลดพื้นผิวการโจมตี
  • ยังสามารถใช้ llvm ได้ด้วย
  • และยังมี MirBSD Korn shell ให้ติดตั้งเป็นแพ็กเกจ ซึ่งเป็นหนึ่งใน interactive shell ที่ผู้เขียนชอบ

การจัดการแพ็กเกจและคลังแพ็กเกจ

  • ตัวจัดการแพ็กเกจหลักของ Alpine คือ apk
  • ตามแนวทางที่พบได้ทั่วไปใน Linux, apk จะอัปเดตทั้งระบบฐานและแพ็กเกจไปพร้อมกัน โดยไม่แยกจากกัน
  • ผู้เขียนยังไม่ได้ตรวจสอบว่าสามารถรันเป็นสำเนาแบบไม่มีสิทธิ์เหมือนใน BSD ได้หรือไม่
  • ยังสามารถใช้ pkgsrc ได้ จึงยังมีทางเลือกอื่นอยู่
  • การตั้งค่าคลังแพ็กเกจอยู่ที่ /etc/apk/repositories
    • หากเอาคอมเมนต์ออกจาก URL ตัวที่สองที่ตัวติดตั้งใส่ไว้ ก็จะเปิดใช้งาน community repository ได้
    • Alpine ยังมีคลัง testing และสามารถเพิ่มคลังของตัวเองได้
  • การใช้งานนั้นเรียบง่าย แต่ด้วยความเคยชินเดิม ผู้เขียนก็เผลอพิมพ์ apt install แทน apk add อยู่บ้าง
  • เว็บอินเทอร์เฟซแพ็กเกจอย่างเป็นทางการอยู่ที่ pkgs.alpinelinux.org
  • คลังแพ็กเกจของ Alpine ยังดูได้จาก pkgs.org เช่นกัน

ZFS และการประเมินในฐานะตัวเลือกสำหรับเซิร์ฟเวอร์

  • หลังติดตั้งแพ็กเกจบางส่วนแล้ว ก็สามารถจัดชุด “เครื่องมือจำเป็น” สำหรับโน้ตบุ๊กแบบคอนโซลล้วนที่เคยใช้งานได้
  • หนึ่งในแพ็กเกจที่น่าประหลาดใจที่สุดคือ ZFS
    • การติดตั้งและโหลดเคอร์เนลโมดูลทำได้ด้วยสองคำสั่ง
# apk add zfs zfs-lts


# modprobe zfs
  • การตั้งค่า root filesystem ให้เป็น ZFS อาจซับซ้อนกว่านี้
  • ผู้เขียนยังไม่ได้ตรวจสอบว่าการตั้งค่า ZFS จะทำงานอย่างไรหลังการอัปเกรด
  • แต่จากประสบการณ์เท่าที่มีจนถึงตอนนี้ ก็สร้างความประทับใจมากพอที่จะ พิจารณาเปลี่ยนมาใช้อย่างจริงจัง เป็นดิสโทร Linux หลักสำหรับงานทดสอบและเซิร์ฟเวอร์
  • จุดเด่นที่ยกมาคือการที่เห็นเพียงไม่กี่โปรเซสที่พอระบุได้ใน htop(1) และ lsof(1), การใช้ OpenRC, การจัดการแพ็กเกจที่ดูเรียบง่าย และการตั้งค่าที่ทำได้ง่าย
  • ผู้เขียนประเมินว่าหากมี “Occam’s Linux” ที่ทันสมัยและใช้งานได้จริง Alpine ก็น่าจะใกล้เคียงกับภาพนั้นมาก
  • หากต้องการความสามารถที่มากกว่า busybox ก็อาจลองใช้ uutils ได้ แต่สำหรับงานเซิร์ฟเวอร์ก็ดูเหมือนจะยังไม่จำเป็น

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

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

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

  • ถ้ามองจากมุมความปลอดภัย ทุกวันนี้ ไบนารีของ Linux ส่วนใหญ่คอมไพล์เป็น PIE
    ถ้าลองรัน checksec กับไบนารีใด ๆ บน Ubuntu ก็จะเห็นคุณสมบัติแบบนั้น และสามารถติดตั้ง checksec ได้ด้วย pip install pwntools
    ในทางกลับกัน เท่าที่ผมรู้ GLIBC มีการใช้งาน heap ที่เสริมความแข็งแกร่งที่สุด และมีมาตรการบรรเทาต่อการ free ซ้ำและการโจมตี heap แบบอื่น ๆ มากกว่า
    ดังนั้นในแง่นั้นอาจมองได้ว่า Alpine ปลอดภัยน้อยกว่าเพราะใช้ musl แต่การเป็นระบบที่เล็กและเข้าใจง่ายก็เป็นข้อดีจริง ๆ ด้านความปลอดภัย

    • ไม่ค่อยเข้าใจว่า “ระบบที่เล็กและเข้าใจง่าย” กลายเป็นเหตุผลที่เข้าข้าง glibc ได้อย่างไร ดูเหมือนจะตรงกันข้ามมากกว่าไม่ใช่หรือ
    • ผมรัน checksec กับทุกอย่างบนโหนด Alpine อยู่เสมอ และโปรเซสทั้งหมดก็ออกมาแบบนี้ เอาต์พุตเต็มยาวเลยขอละไว้ แต่ไม่เคยเห็นของที่ Alpine build แล้วขาดแฟล็กพวกนี้เลย
      COMMAND PID RELRO STACK CANARY NX/PaX PIE
      init 1 Full RELRO Canary found NX enabled PIE enabled
      [snip...]
      crond 422838 Full RELRO Canary found NX enabled PIE enabled
    • OpenBSD libc ก็น่าลองตรวจดูเหมือนกัน
    • จากมุมมองความปลอดภัยของ Linux ถ้าใครสักคนสามารถรันโค้ดบนระบบได้แม้แต่นิดเดียว ก็ถือว่าจบแล้ว Linux เต็มไปด้วยช่องโหว่ และเหตุผลที่มัลแวร์ไม่ได้เกลื่อนเหมือน Windows ก็เพราะมีคนใช้ Linux บนเดสก์ท็อปน้อย ผู้ทำมัลแวร์เลยไม่ได้เล็งเป็นเป้าหมายใหญ่
      พูดตรง ๆ ผมคิดว่า Windows และ macOS ยุคใหม่ต่างก็มี สถาปัตยกรรมความปลอดภัย ที่ดีกว่า

  • ผมเองก็เป็นสาย BSD และบังเอิญเพิ่งลองรัน Alpine ครั้งแรกในสัปดาห์นี้ เป็น VM บน bhyve
    แก่นสำคัญคือ BusyBox ถ้ายูทิลิตีใน /bin และ /sbin ไม่จำเป็นต้องเป็นไบนารีแยกอิสระแต่ละตัว user space ก็จะเล็กมากและบูตเร็วด้วย พอติดตั้ง Tmux กับ zsh ก็เพียงพอสำหรับงาน Unix ส่วนใหญ่แล้ว
    กว่าจะไปถึงสภาพแวดล้อมสุดท้ายได้ก็ต้องติดตั้งด้วย apk อยู่พอสมควร แต่โดยรวมแล้วนี่เป็นประสบการณ์ Linux ที่ดีที่สุดในรอบนาน ๆ อยากให้มี ZFS มาเป็นค่าเริ่มต้น และอยากให้การเชื่อมต่อ virtio ที่ปรับให้เข้ากับการรันบน ZFS ของ bhyve มีความชัดเจนกว่านี้

    • ใช้และ deploy FreeBSD มามากกว่า 20 ปีแล้ว พูดตรง ๆ ว่าการ SSH เข้าเครื่อง GNU/Linux นั้นรู้สึกไม่ค่อยอยากทำ มีความแตกต่างและความไม่สอดคล้องกันมากเกินไปจนระบบให้ความรู้สึกเหมือนยุ่งเหยิง ถึงขั้นรู้สึกว่าการเข้า Windows server ยัง “สมเหตุสมผล” มากกว่าเสียอีก
      ถึงอย่างนั้นก็ดีใจที่อาจมีดิสโทร Linux ที่ยังสติปกติอยู่บ้าง และถ้าจำเป็นต้องใช้เครื่อง Linux จะลองดู แต่เรื่องแบบนั้นค่อนข้างหายาก
    • อยากรู้ว่าคุณคาดหวังให้ ZFS “มีมาให้โดยค่าเริ่มต้น” ระดับไหน Alpine เป็นหนึ่งในไม่กี่ดิสโทรที่มี โมดูลเคอร์เนล ZFS แบบไบนารี ให้ ดังนั้นแทบจะติดตั้งได้ด้วยคำสั่ง apk ครั้งเดียว
      ในวิกิของ Alpine ก็มีเอกสารเกี่ยวกับการติดตั้ง root filesystem เป็น ZFS ที่ค่อนข้างดีด้วย: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • ZFS ทำงานบน Alpine ได้ดีมาก Alpine + ZFS เป็นคอนฟิกเซิร์ฟเวอร์หลักของผมมาหลายปีแล้ว

  • ถ้าเป็นผู้ใช้ BSD ก็น่าจะชอบ Void Linux ด้วย เป็นดิสโทรที่สร้างโดย xtraeme ซึ่งเป็นนักพัฒนา NetBSD มีทั้งเวอร์ชัน glibc และ musl และใช้ runit เป็นระบบ init
    ยังสามารถ build แพ็กเกจจากซอร์สด้วย xbps-src ได้ด้วย
    https://voidlinux.org/

    • หลังใช้ Arch อยู่ ผมหา ทางเลือกที่ไม่ใช้ SystemD แต่ให้ความรู้สึกคล้าย Arch แล้วก็ลงเอยที่ Void เหตุผลที่เลือก Void แทน Alpine คือรองรับ glibc ทำให้ใช้ไดรเวอร์ NVidia ได้ แน่นอนว่ารู้เรื่อง “โห่ NVidia” อยู่แล้ว
    • ชอบ Void มาก ระบบหลักของผมยังเป็น Arch เพราะมีตัวเลือกแพ็กเกจเยอะและความสะดวกของ systemd แต่ได้ลองติดตั้ง Void ให้ญาติและบนเครื่องของผมสามเครื่องแล้ว และมันยอดเยี่ยมมาก
      อย่างไรก็ตามควรทราบว่าผมลองแค่การติดตั้ง xfce ที่ปรับแต่งน้อยมากเท่านั้น คอนฟิกหลายผู้ใช้ที่ซับซ้อนอาจยุ่งยากกว่าเล็กน้อย เพราะ runit มีฟีเจอร์ที่มาพร้อมค่าเริ่มต้นน้อยกว่า systemd
    • เมื่อไม่กี่ปีก่อนเคยมีปัญหาเวลาใช้ Rust บน voidlinux+musl โชคดีที่ Void ติดตั้งใหม่เป็น glibc ได้ง่าย
    • Chimera ก็น่าจะใช้ได้เหมือนกัน user space ของเครื่องมือหลักส่วนใหญ่เป็นสาย FreeBSD จึงน่าจะคุ้นเคยพอสมควรสำหรับผู้ใช้ BSD
    • ยังมี CRUX ด้วย เป็นดิสโทรที่ถือว่าเป็นต้นแบบของ Archlinux

  • คิดว่าจะมีคนพูดถึงว่า หน้า man ที่พวก BSD ภูมิใจนั้นไม่ได้รวมมาให้โดยค่าเริ่มต้นใน Alpine นั่นเป็นหนึ่งในเหตุผลที่ผมไม่ใช้ Alpine บนโน้ตบุ๊กพกพา และตอนนี้ใช้ OpenBSD อยู่
    ผมพลาดตัวเลือกคอนฟิกอะไรบางอย่างที่ทำให้เอกสารถูกติดตั้งเสมอตอนรับแพ็กเกจใน Alpine หรือเปล่า? หรือมีทางเดียวคือต้องติดตั้งแพ็กเกจ -doc เองทุกครั้ง?

    • ถ้าต้องการเอกสารเสมอ ให้ติดตั้งเมตาแพ็กเกจ docs ได้เลย หลังจากนั้นมันจะดึงแพ็กเกจ *-doc ที่ตรงกับสิ่งที่ติดตั้งตามมาให้
    • ใช้ OpenBSD บนโน้ตบุ๊กแล้ว การรองรับฮาร์ดแวร์ เป็นอย่างไรบ้าง?

  • พูดตรง ๆ คือไม่เข้าใจเลยว่าทำไมผู้คนถึงรู้สึกว่าอะไรอย่าง OpenRC นั้นน่าสนใจ ผมมองว่าวิธีแบบอิงการเฝ้าติดตาม ไม่ว่าจะเป็นแบบไหน ก็ยังดีกว่าวิธีที่ปล่อย PID ออกมา บันทึกไว้ในไฟล์ PID แล้วหวังว่าอีก 3 สัปดาห์ให้หลังค่านั้นจะยังชี้ไปยังเดมอนที่รันอยู่
    แถมในบางกรณีก็ยังใช้ pgrep กับชื่อโปรเซสบางตัวเพื่อจัดการงานด้าน service management อีกด้วย ผมเห็นด้วยอยู่บ้างกับแนวคิดที่ว่าไม่ควรรีสตาร์ตทุกอย่างโดยอัตโนมัติเป็นค่าเริ่มต้น แต่ข้อดีที่กลุ่มนี้จะยกมาอ้างได้จริง ๆ ก็แทบมีแค่นั้น
    อีกอย่าง สุดท้ายของพวกนี้ก็พึ่งพา syslog อย่างมาก ซึ่งเป็นเทคโนโลยียุค 80 ชัด ๆ เครื่องมืออย่าง multilog หรือ svlogd อาจปรับปรุงให้แสดงมุมมองส่วนกลางที่เห็นลำดับเหตุการณ์ของหลายเครื่องมือได้ง่ายขึ้น แต่ฟีเจอร์ที่จัดกลุ่มล็อกด้วยหมวดหมู่คลุมเครือ และเปิดให้ใครก็ได้เขียนล็อกชื่ออะไรก็ได้ไว้ที่ไหนก็ได้ มันรู้สึกแปลก ๆ

    • อ้างอิงเพิ่มเติม Alpine พยายาม แทนที่ OpenRC มาหลายปีแล้ว แต่ยังหาทางเลือกที่เหมาะสมไม่ได้ และยังมีความพยายามที่จะเป็นดิสโทรที่ไม่ผูกกับระบบ init ใด ๆ ด้วย
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • ถึงอย่างนั้น ทางเลือกหลักก็คือ systemd ซึ่งถูกออกแบบมาในแบบที่ไม่ปลอดภัย และเปิดช่องให้เกิด CVE ใหม่ ๆ ที่น่าสนใจต่อไปเรื่อย ๆ
      มีหลายอย่างมากเกินไปอยู่ใน PID1 และเขียนด้วยภาษาที่ไม่ memory-safe ผมไม่เห็นเหตุผลทางเทคนิคว่าทำไมจะแยกเป็น PID1 แบบขั้นต่ำกับโปรแกรม setuid อีกไม่กี่ตัวไม่ได้
      สิ่งเดียวที่นึกออกคือจะทำให้รัน systemd ในคอนเทนเนอร์ Docker ได้ แต่ Red Hat/IBM น่าจะอยากให้ใช้เครื่องมือคอนเทนเนอร์ของตัวเองอย่าง systemd-nspawn มากกว่า จึงคงไม่ได้ต้องการเรื่องนั้นอย่างแรงนัก ด้วยโครงสร้างปัจจุบัน ผมคิดว่ามันแทบไม่มีทางสมเหตุสมผลจากมุมมองด้านความปลอดภัยได้เลย

  • Alpine มีข้อดีที่น่าสนุกอยู่ เมื่อผู้ใช้ Nix อวดเรื่อง การจัดการแพ็กเกจแบบประกาศสถานะ คุณก็แก้ /etc/apk/world โดยตรงแล้วรัน apk fix เพื่อโชว์ว่าทำแบบนั้นโดยไม่ต้องใช้ Nix ได้อย่างไร

    • โดยทั่วไปแนวทางของ Gentoo ดีกว่า แพ็กเกจที่ติดตั้งเองอยู่ที่ /var/lib/portage/world, ชุดที่เลือกไว้ที่ /var/lib/portage/world_sets, และนิยามของชุดไว้ที่ /etc/portage/sets/ ได้
      แบบนี้จะแบ่งแพ็กเกจตามหมวด ติดตั้งเฉพาะบางส่วนลงบนระบบที่ต้องการ และใส่คอมเมนต์ในไฟล์ได้ตามต้องการ สิ่งที่เทียบได้กับ apk fix คือ emerge -uDU @world && emerge -c ซึ่งก็ยุ่งยากกว่าเล็กน้อย
      Alpine ก็สร้างสิ่งที่คล้ายชุดได้ด้วย apk add -t setname pkg1 pkg2 pkg3 ซึ่งจะสร้างแพ็กเกจ dummy ที่ขึ้นกับแพ็กเกจที่เลือกไว้ โดยปกติผมจะสร้าง shell script ไว้ใน /etc/apk/sets/ เพื่อเลียนแบบความรู้สึกแบบ Gentoo แต่ก็ไม่ได้เหมือนกันเสมอไป
    • เวลาที่ Nix ใช้ประเมิน system flake ของผมนั้น พอ ๆ กับเวลาที่ติดตั้ง Alpine ใหม่ตั้งแต่ต้นได้เลย
    • ถึงจะเท่ก็จริง แต่ Nix/OS ทำอะไรได้มากกว่าการติดตั้งแพ็กเกจแบบประกาศสถานะมาก

  • จำได้ว่าเมื่อก่อนมีบทความเกี่ยวกับประสิทธิภาพตอนรัน Alpine บน Docker และแนะนำให้ใช้ Debian/Ubuntu
    บทความเกี่ยวกับ Alpine ที่ช้า:
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    บทความที่เป็นมิตรกับ Alpine:
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    สงสัยว่าเรื่องนี้ยังใช้ได้อยู่ไหมในตอนนี้

    • ข้อร้องเรียนเฉพาะเจาะจงจำนวนมากอย่างน้อยก็ได้รับการแก้ไขแล้ว ตามที่ลิงก์แรกด้านล่างสุดก็ยอมรับ ตอนนี้มี Python wheel ที่เข้ากันได้กับ Alpine แล้ว และปัญหา DNS ก็แก้ไปนานพอสมควรแล้ว
      ถึงอย่างนั้น ในแง่ประสิทธิภาพ การรัน benchmark เพื่อดูตัวเลขจริงก็น่าจะน่าสนใจ

  • musl ยังไม่รองรับ pthread_attr_setaffinity_np อยู่ไม่ใช่หรือ? ถ้าอย่างนั้นซอฟต์แวร์บางตัวก็รันไม่ได้ ตัวอย่างที่ใหญ่ที่สุดคือ PyTorch

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

  • จุดกึ่งกลางที่เหมาะสมที่ผมพบระหว่าง BSD กับ Linux คือ Slackware มันมีความเป็น Unix อย่างภาคภูมิ ไม่ซับซ้อน และยังมี ports tree ของตัวเองที่อุดมสมบูรณ์ผ่าน Slackbuilds ด้วย

    • Slackware เคยพยายามแข่งขันกับดิสโทรเดสก์ท็อป แต่ก็หลงทางเพราะไม่ได้ทุ่มเทจริงจัง
      เมื่อก่อนผมชอบเพราะเป็นดิสโทรขั้นต่ำที่ไม่กวนใจ และมองว่ามุ่งไปที่คนที่มีความรู้เทคนิคมากขึ้นเล็กน้อย
      แต่เวลาเจาะลึกปัญหา ชุมชนมักจะแสดงท่าทีเป็นปฏิปักษ์เพียงเพราะไม่ได้ติดตั้งแบบเต็ม เหตุผลคือการติดตั้งแบบเต็มเป็นวิธีที่แนะนำ และถ้าไม่ทำแบบนั้นก็จะเกิดปัญหา dependency โง่ ๆ อย่าง mplayer ใช้ไม่ได้เพราะไม่มี samba
      ผมคิดว่า Alpine เป็นการปรับปรุงจาก Slackware ในทุกด้าน
    • ผมนับถือคนที่ใช้ Slackware แต่ การไม่มี dependency management ดูจะยุ่งยากอยู่

  • Alpine Linux จริง ๆ แล้วไม่ใช่ GNU/Linux สินะ ไม่รู้มาก่อนเลย
    งั้นเป็น BusyBox/Linux เหรอ?

    • เรียกแค่ว่า Alpine Linux ก็พอ เท่าที่ผมรู้ BusyBox ไม่เกี่ยวข้องกับพฤติกรรมอวดตัวเองที่ RMS เผลอแสดงออกมาเป็นครั้งคราว ดังนั้นก็น่าจะโอเค