มีแผนนำ Rust เป็นดีเพนเดนซีบังคับมาใช้ใน Debian APT ตั้งแต่เดือนพฤษภาคม 2026

 (lists.debian.org)
3 คะแนน โดย GN⁺ 2025-11-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีแผนจะรวม โค้ดและดีเพนเดนซีที่อิง Rust เข้าใน ตัวจัดการแพ็กเกจ APT ของ Debian ตั้งแต่หลังเดือนพฤษภาคม 2026
  • ในระยะแรก ขอบเขตการรวมจะครอบคลุม คอมไพเลอร์ Rust, ไลบรารีมาตรฐาน, และ ระบบนิเวศ Sequoia
  • ตัวพาร์เซอร์ไฟล์ .deb, .ar, .tar และ โค้ดตรวจสอบลายเซ็น HTTP เป็นพื้นที่หลักที่จะได้รับการปรับปรุงด้าน ความปลอดภัยของหน่วยความจำ และ การเสริมความเข้มแข็งของยูนิตเทสต์
  • พอร์ตที่ยังไม่มี Rust toolchain จำเป็นต้อง สร้างสภาพแวดล้อม Rust ภายใน 6 เดือน หรือไม่เช่นนั้นอาจถูก ยุติการสนับสนุน (sunset)
  • นี่เป็นมาตรการเพื่อผลักดันให้ทั้งโครงการ เปลี่ยนผ่านไปสู่เครื่องมือและเทคโนโลยีสมัยใหม่ โดยไม่ถูกฉุดรั้งด้วยข้อจำกัดด้านความเข้ากันได้กับฮาร์ดแวร์รุ่นเก่า

แผนนำโค้ด Rust เข้าสู่ APT

  • มีแผนจะนำ โค้ด Rust และฮาร์ดดีเพนเดนซี (hard dependency) เข้าสู่ APT หลังเดือนพฤษภาคม 2026
    • ช่วงเวลานำมาใช้อยู่หลังเดือนพฤษภาคม 2026 และจะยังไม่บังคับใช้ก่อนหน้านั้น
  • ขอบเขตการรวมในระยะแรกจำกัดอยู่ที่ คอมไพเลอร์ Rust, ไลบรารีมาตรฐาน, และ ระบบนิเวศ Sequoia

เป้าหมายเพื่อยกระดับคุณภาพโค้ดและความปลอดภัย

  • โค้ดสำหรับพาร์สไฟล์ .deb, .ar, .tar และ โค้ดตรวจสอบลายเซ็น HTTP เป็นเป้าหมายหลักของการนำ Rust มาใช้
    • มีการระบุว่าพื้นที่นี้จะได้รับประโยชน์อย่างมากจาก ภาษาโปรแกรมที่ปลอดภัยด้านหน่วยความจำ และ ระบบยูนิตเทสต์ที่เข้มแข็งขึ้น

ข้อกำหนดสำหรับผู้ดูแลพอร์ต

  • พอร์ตที่ยังไม่มี Rust toolchain ต้อง จัดเตรียมสภาพแวดล้อม Rust ภายใน 6 เดือน
    • มิฉะนั้นพอร์ตนั้นอาจถูก ยุติการสนับสนุน (sunset)

ทิศทางของโครงการ

  • เน้นย้ำว่าโครงการ Debian ควรพัฒนาต่อไปโดยอาศัย เครื่องมือและเทคโนโลยีสมัยใหม่
    • มีการระบุว่าไม่ควรปล่อยให้ความก้าวหน้าล่าช้าเพียงเพื่อพยายามรองรับฮาร์ดแวร์รุ่นเก่าหรือ อุปกรณ์เรโทรคอมพิวติ้ง

ข้อมูลอื่น ๆ

  • ผู้ส่งคือ Julian Andres Klode นักพัฒนาแกนหลักของ Debian และ Ubuntu
  • อีเมลดังกล่าวถูกโพสต์ในเมลลิงลิสต์นักพัฒนา Debian debian-devel
  • มีไฟล์แนบเป็น ลายเซ็น PGP (signature.asc)
  • ไม่มีการกล่าวถึงรายละเอียดทางเทคนิคเพิ่มเติมหรือการเปลี่ยนแปลงกำหนดการ

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

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

 
GN⁺ 2025-11-02
ความคิดเห็นจาก Hacker News

  • ดูเหมือนว่าในที่สุดก็ถึงเวลาแล้ว การยังคงเก็บ โค้ดสำหรับพาร์สข้อมูลที่ไม่น่าเชื่อถือ ไว้ใน C เป็นหนี้ทางเทคนิคที่ยิ่งนานยิ่งสะสม
    Rust ไม่ได้เขียนยากกว่า C มากนัก และถ้าจะสร้าง C ขึ้นมาใหม่โดยสะท้อนความรู้ปัจจุบันด้านการออกแบบภาษาและ ความปลอดภัยของโค้ด ก็คงออกมาเป็นภาษาแบบนี้
    ถ้ายอมทิ้งการรองรับ 32-bit x86 ได้ด้วยเหตุผลเชิงปฏิบัติ สถาปัตยกรรมพวกนี้ก็ควรเช่นกัน ถ้าอยากคงไว้จริง ๆ ก็ควรต้องทำ backend ของ Rust toolchain เอง

    • ตอนนี้ภาษาที่อนุญาตให้ใช้กับแอปพลิเคชันหลักในระบบพื้นฐานมีประมาณ C, C++, Shell(bash), Perl, Python เท่านั้น Python ถูกเพิ่มเข้ามาเมื่อราว 20 ปีก่อน และ Rust เป็นภาษาแรกที่เข้าใกล้พอจะมาแทนบทบาทของ C ได้
      Go ก็ใกล้เคียงอยู่บ้าง แต่ไม่เคยถูกพูดถึงในระดับที่จะนำไปใช้กับระบบแกนหลักอย่าง systemd สงสัยเหมือนกันว่าตอนเพิ่ม C++, Python, Perl ในอดีตจะมีการถกเถียงแบบนี้หรือไม่
    • มีคนบอกว่า “ตัวพาร์ส .deb, .ar, .tar และโค้ดยืนยันลายเซ็น HTTP จะได้ประโยชน์จากภาษาแบบ memory-safe” แต่ก็ยังสงสัยว่าการเอาโค้ดที่นิ่งมาราว 30 ปีมาเขียนใหม่ด้วยภาษาใหม่จะให้ประโยชน์เชิงรูปธรรมอะไร
      การทิ้ง โค้ดที่ผ่านศึกจริงมาแล้ว แล้วสร้างปัญหาความเข้ากันได้และบั๊กชุดใหม่ขึ้นมามันคุ้มจริงหรือ
    • ถ้าจะจัดการปัญหาความปลอดภัยของโค้ด C เก่า ๆ แบบที่ใช้งานได้จริงกว่า ก็มี โครงการ Fil-C ซึ่งทำให้ C กลายเป็นเหมือน ภาษาแบบ managed ได้ในทางปฏิบัติ จึงลดความจำเป็นในการเขียนใหม่
    • นี่ไม่ใช่แค่เรื่อง memory safety อย่างเดียว แต่เป็นเรื่อง ชุมชน C ที่มีอายุมากขึ้น จนหาคนมาดูแลรักษายาก ทีมของเราก็กำลังย้ายโค้ด C/C++ ทั้งหมดไปภาษาอื่น นักพัฒนา C/C++ ส่วนใหญ่อายุราว 40+ และไม่ค่อยอยากย้ายงาน
    • เห็นด้วยได้ยากกับคำกล่าวที่ว่า Rust คือการสร้าง C ใหม่ให้ทันสมัย เช่น โค้ดวิดเจ็ตนาฬิกาของเดสก์ท็อป COSMIC อ่านยากกว่าโค้ด C ที่มีความซับซ้อนใกล้เคียงกันมากอย่าง GNU coreutils เสียอีก

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

    • เหตุผลของการเขียนใหม่แบบนี้มักได้ยินอยู่สองข้อ
      ข้อแรก แทบไม่มีผู้ร่วมพัฒนาใหม่คนไหนอยากแตะ codebase C/C++ เก่า ๆ ถ้าย้ายไป Rust จะช่วยให้ ดึงนักพัฒนาใหม่เข้ามา ได้ง่ายขึ้น
      ข้อสอง ความน่าเชื่อถือพิสูจน์ได้จากการใช้งานบ่อย แต่ ความปลอดภัยพิสูจน์ได้ก็ต่อเมื่อถูกโจมตี จึงยากจะบอกว่าโค้ดเก่าได้ผ่านทุก attack vector แล้ว ดังนั้นเหตุผลเรื่องการเสริมความปลอดภัยเชิงรุกจึงมีน้ำหนัก
    • uutils/coreutils ใช้ไลเซนส์ MIT ส่วน GNU coreutils ใช้ GPL จึงมี ความต่างด้านไลเซนส์ ซึ่งอาจเป็นจุดสำคัญสำหรับบริษัท
    • ยังไงก็ต้องมีคนเรียนรู้ ดังนั้นการ เขียนโปรเจ็กต์ใหม่เพื่อฝึกฝน โดยเลือกงานที่เรียบง่ายและทดสอบง่ายก็ถือว่าโอเค เพียงแต่ผลลัพธ์จะมาแทนของเดิมได้ไหมเป็นอีกเรื่องหนึ่ง

  • ตามเมลเธรดของ Debian ตอนนี้ Rust เป็นสิ่งจำเป็นอยู่แล้วในสถาปัตยกรรมส่วนใหญ่ของ Debian release
    ในเมลที่เกี่ยวข้อง มีการระบุว่าเหลือข้อยกเว้นแค่ alpha, hppa, m68k, sh4 เท่านั้น เลยสงสัยว่าอนาคตของสถาปัตยกรรมเหล่านี้จะเป็นอย่างไร

    • สงสัยจริง ๆ ว่ายังมีคนใช้เครื่องเก่าแบบนี้อยู่ไหม ส่วนใหญ่เป็นฮาร์ดแวร์ที่อายุเกิน 20 ปีแล้ว
      Rust มี Tier 3 target สำหรับ m68k แต่ตัวอื่นไม่มี เลยอยากรู้ว่ามีการใช้งานจริงแบบไหน
    • ตาม Debian Supported Architectures แพลตฟอร์มเหล่านี้อยู่ในสถานะไม่เป็นทางการ
      แปลกดีที่ 32-bit x86 กับ MIPS หายไปแล้ว แต่พวกนี้ยังอยู่ ส่วนตัวก็มีความรู้สึก nostalgic อยู่บ้าง แต่ไม่ค่อยรู้ว่าถูกใช้ที่ไหนจริง
    • m68k มี LLVM port อยู่แล้ว จึงสามารถทำ Rust implementation ได้ ส่วน LLVM backend สำหรับ alpha, hppa, sh4 ก็ยังมีคุณค่าเป็น สื่ออ้างอิงเพื่อการศึกษา
      ในอดีต LLVM เคยมี backend สำหรับ DEC Alpha แต่ก็นานมากแล้ว
    • ในมุมของ Ubuntu สถาปัตยกรรมเหล่านี้ ไม่มีมูลค่าทางการค้า
    • มันล้าสมัยเต็มทีแล้ว แค่หยุดอยู่ที่เวอร์ชันสุดท้ายที่รองรับ หรือทำดิสโทรของตัวเองก็ได้ การเพิ่ม Rust support ให้ตอนนี้ไม่สมจริง

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

    • นี่คือการตัดสินใจอย่างเป็นทางการของ Debian ที่เพิ่ม dependency ของ Rust ไม่ใช่การถูกแฟน Rust จากภายนอกบังคับ
      แน่นอนว่าก็มีพวกสุดโต่งที่ชอบพูดว่า “เขียนใหม่ด้วย Rust ซะ” แต่กรณีนี้ไม่ใช่แบบนั้น
    • ripgrep ก็เป็นตัวอย่างตรง ๆ ของสิ่งนั้น ถูกสร้างขึ้นใหม่และคนก็ชอบใช้กันจริง

  • ใช้ Rust standard library น่ะไม่เป็นไร แต่ไม่อยากดึง แพ็กเกจ cargo 500 ตัว เข้ามาเพื่อ build ตัวพาร์ส deb ที่เรียบง่าย

  • อาจสมเหตุสมผลกว่าถ้าจะรอให้ Rust-for-GCC port เสถียรก่อน
    ฝั่ง kernel เองก็ตั้งใจว่าจะยังไม่ทำให้ Rust เป็นข้อบังคับจนกว่าจะรองรับ GCC ได้
    ถ้ามีหลาย implementation ภาษาก็น่าจะมีความไม่นิ่งน้อยลง
    แต่ถ้าตัดการรองรับสถาปัตยกรรมตอนนี้ พอภายหลังมี Rust toolchain ขึ้นมาแล้ว ขั้นตอนการกลับเข้ามารองรับอีกครั้งอาจซับซ้อน

    • จริง ๆ แล้วสถาปัตยกรรมเหล่านี้ก็ถูกกันออกจาก Debian มานานเกิน 10 ปีแล้ว การเปลี่ยนแปลงครั้งนี้ไม่ได้ทำให้เพิ่งหลุดใหม่
    • ไม่มีการรองรับอย่างเป็นทางการ และอยู่ในระดับที่คนดูแลทำกันในเวลาว่าง ถ้าไม่มีบริษัทมารับช่วงดูแลระยะยาวก็คงกลับมายาก
    • GCCRS ตอนนี้ยัง build แม้แต่ libcore ไม่ได้ และอยู่แค่ระดับ Rust 1.50 ดูแล้ว คงต้องใช้เวลาอีกหลายปีกว่าจะเป็นคอมไพเลอร์สำหรับใช้งานทั่วไป
      ที่อาจเสถียรก่อนกลับเป็น rustc_codegen_gcc
    • พอร์ตเหล่านี้ไม่ได้รวมอยู่ใน Debian release ทางการ และแจกจ่ายผ่าน ช่องทาง unstable เท่านั้น

  • ขอเตือนว่าผู้เขียนเมลถกเถียงเรื่อง Rust ของ Debian คือ ผู้ดูแลแพ็กเกจ keepassxc และเคยมีเธรดพูดถึงการใช้ถ้อยคำแข็งกร้าวต่อทั้งนักพัฒนา upstream และผู้ใช้มาก่อน

    • ผมก็เห็นเมลนั้นแล้วไปเช็กทันที แล้วก็นึกถึงเธรดเก่าเลยขำออกมา
    • เอาจริง ๆ ภาษาที่เขาใช้แม้จะห้วน แต่ ตรงไปตรงมา ไม่ได้ถึงขั้นดูหมิ่น มองว่าเป็นดราม่าที่เกินเหตุ
    • ตัวโพสต์บน HN เองก็ไม่ได้ก้าวร้าว แต่ดูเหมือนบางคนจะรับแรงเกินไป
    • วัฒนธรรมแบบนี้มีอยู่ทั่วไปในโลกซอฟต์แวร์เสรี เหมือนมีแนวโน้มจะไล่ตาม ภาพผู้ใช้ในอุดมคติ มากกว่าผู้ใช้จริง ซึ่งเห็นมาตั้งแต่ยุค GNOME 3 และ Mozilla แล้ว

  • น่าสนใจดีที่ได้เห็นคนหนึ่งค่อย ๆ เปลี่ยนความเห็นของตัวเอง ลิงก์คำพูดก่อนหน้า

    • การยอมเปลี่ยนความคิดเมื่อเวลาผ่านไปเป็นท่าทีที่น่าชื่นชม
    • การนำ Rust เข้ามาใน APT ก็อาจเป็น การตัดสินใจเชิงการบริหาร แบบเดียวกับการเปลี่ยน coreutils

  • คิดว่า Rust ก็เป็นแค่ กระแส(hype) อย่างหนึ่ง ในโลก embedded นั้น C ก็ยังเป็นราชาอยู่
    เอาจริงไม่เคยเห็นคนรอบตัวใช้หรือแม้แต่พิจารณา Rust เลย

    • จะสรุปจากแค่ว่า “รอบตัวผมไม่มี” ก็ดูเกินไป นักพัฒนา embedded ที่ใช้ Rust ก็มีไม่น้อย
    • ภายใน AWS มีบริการแกนหลักอย่าง EC2, IAM, DynamoDB, S3 ที่เขียนด้วย Rust
      มันช่วยคง ประสิทธิภาพและความประหยัดหน่วยความจำ พร้อมกับเพิ่มความเร็วในการพัฒนา
      ข้อเสียอย่างเดียวคือขนาดไบนารี สำหรับผมอนาคตของ Rust ชัดเจนไปแล้ว
    • Rust แข็งแรงมากในงาน embedded เช่นกัน แต่การรองรับจากผู้ผลิตยังน้อย จึงมี ภาระงานเริ่มต้นเฉพาะฮาร์ดแวร์ สูง
      ถึงอย่างนั้นเสน่ห์ของมันไม่ได้มีแค่ memory safety แต่รวมถึง คุณภาพของภาษาและ toolchain โดยรวม
    • avr-rust, esp-rs, cortex-m กำลังค่อย ๆ เปลี่ยน ecosystem ของ embedded เช่นกัน
    • Microsoft, Google และที่อื่น ๆ ก็มีการพูดถึง Rust และนำไปใช้จริงในผลิตภัณฑ์แล้ว

  • คิดว่าสภาพแวดล้อมแบบ polyglot มีแต่จะสร้างปัญหาเพิ่ม
    ต้องมีทั้ง Python, Node, Go, Rust พร้อม toolchain และ package manager คนละชุด ทำให้ซับซ้อน
    พอแก้ buffer overflow ด้วย Node ก็กลับได้ supply chain attack เพิ่มแทน
    สู้เริ่มใหม่ไปเลยดีกว่า และถ้าอยากใช้ Rust แบบเต็มตัวก็ควรไปช่วย Redox OS มากกว่า

    • ในโลกจริงแต่ละภาษาก็มีข้อดีข้อเสียเฉพาะตัว และ Debian ในฐานะ ระบบปฏิบัติการเชิงปฏิบัติ ก็ควรรองรับหลายภาษา
      การเขียนทุกอย่างใหม่ด้วยภาษาเดียวไม่สมจริง และการไปผลัก Redox ก็อาจยิ่งไม่มีประสิทธิภาพ
      Rust เป็นภาษาที่พิสูจน์ตัวเองมาแล้วพอสมควร และในฐานะ ภาษาคอมไพล์ที่มีโอกาสทำระบบพังเวลาปรับแก้น้อยกว่า C ก็มีคุณค่า
      การทิ้งสถาปัตยกรรมเก่า ๆ ก็ไม่ใช่เรื่องเกินเลย
    • สำหรับโปรเจ็กต์ใหญ่แบบ Debian การเพิ่มทางเลือกถือว่าสมเหตุสมผล การเพิ่ม Rust เข้ามาเป็น การตัดสินใจที่เข้าใจได้เพียงพอ
      จะเอาภาษาไหนออกหรือเพิ่มภาษาไหนก็ควรเป็นเรื่องที่ผู้ดูแล Debian ตัดสินใจ
    • Linux นั้นยอมแพ้ต่อ สงครามกับความซับซ้อน ไปตั้งแต่หลายสิบปีก่อนแล้ว