- การบำรุงรักษา rsync กำลังเผชิญทั้งการพุ่งขึ้นของรายงานด้านความปลอดภัยและข้อถกเถียงเรื่องการใช้ AI จนทำให้จำเป็นต้องมีการทดสอบ, code coverage, CI หลายแพลตฟอร์ม, การสแกนความปลอดภัย และการทำ defense in depth มากขึ้น
- ชุดทดสอบ Python ใหม่เข้ามาแทนโครงสร้างเดิมที่เป็นเชลล์สคริปต์ แต่การออกแบบและแผนการตรวจสอบยังเป็นหน้าที่ของผู้ดูแล โดย Claude, Codex และ Gemini ถูกใช้เพื่อช่วยงานที่ทำซ้ำๆ
- รีลีส 3.4.3 เป็นรีลีสที่ให้ความสำคัญกับการแก้ไขด้านความปลอดภัยก่อน แต่ก็เกิด regression กับบางกรณีใช้งานที่ถูกต้องแต่ค่อนข้างเฉพาะ ซึ่งทั้งการทดสอบเดิมและการทดสอบด้วยมือไม่พบ
- แม้ pytest จะถูกใช้อย่างแพร่หลายในโปรเจ็กต์อื่น แต่สำหรับความต้องการเฉพาะของชุดทดสอบ rsync มันไม่เหมาะ จึงเลือกออกแบบแนวทางแยกต่างหาก และมองว่า LLM ต้องใช้อย่างระมัดระวังแต่ก็เป็นเครื่องมือที่มีประโยชน์
- ทิศทางถัดไปกำลังตัดสินใจระหว่าง 3.4.4 ที่จะบรรเทา regression กับ 3.5.0 ที่จะมีการเปลี่ยนแปลงด้านความปลอดภัยครั้งใหญ่ โดย openrsync กำลังล้มเหลว 85 จาก 98 การทดสอบในชุดทดสอบใหม่
รายงานความปลอดภัยที่พุ่งขึ้นและการเสริมการป้องกัน
- ผู้ดูแล rsync กำลังเผชิญสถานการณ์ที่รายงานด้านความปลอดภัยถาโถมเข้ามา เช่นเดียวกับนักพัฒนาแพ็กเกจโอเพนซอร์สรายอื่นในช่วงหลัง โดยหลายรายงานเป็นสิ่งที่สร้างด้วย AI แต่ก็ยังมีบางส่วนที่เป็นการวิเคราะห์ด้วยมืออย่างรอบคอบและมีคุณภาพสูง
- เมื่อรายงานเพิ่มขึ้นมาก rsync จึงจำเป็นต้องมีชุดทดสอบที่เข้มงวดยิ่งขึ้น, การวิเคราะห์ code coverage, การทดสอบ CI บนแพลตฟอร์มที่มากขึ้น, การสแกนหาประเด็นด้านความปลอดภัยโดยเจตนา และเทคนิค defense in depth
- ผู้ดูแลเกษียณแล้วและอยากออกเรือมากขึ้น แต่เพราะปริมาณงานที่จำเป็นต้องทำ เขาจึงใช้เครื่องมือ AI หลายตัวและไม่ได้รู้สึกเสียใจกับการตัดสินใจนั้น
ชุดทดสอบ Python และงานช่วยโดย AI
- ชุดทดสอบ rsync เดิมที่อิงกับเชลล์สคริปต์ถูกเขียนใหม่ด้วย Python โดยโครงสร้างหลักยังคงเป็นแบบที่ผู้ดูแลรับผิดชอบการออกแบบแกนกลางและแผนการตรวจสอบด้วยตนเอง
- Claude ถูกใช้กับงานที่ทำซ้ำๆ ส่วน Codex และ Gemini ถูกใช้เพื่อตรวจทานข้ามกัน ไม่ใช่วิธีแบบสั่งว่า “แปลงชุดทดสอบเป็น Python” แล้วปล่อยให้ทำทั้งหมด
- ผู้ดูแลตรวจทานทุกส่วนด้วยตนเอง ใช้เวลา CI ไปมากเพื่อปรับให้เข้าที่ และหลังจากนั้นก็ย้ายไปใช้การทดสอบส่วนใหญ่บน VM ภายในหลายเครื่องเพื่อลดเวลารอ CI
- ข้อความ
co-authored by claude ในประวัติ commit เป็นเพียงผลลัพธ์ที่สะท้อนงานวิศวกรรมซอฟต์แวร์ทั้งหมดเพียงบางส่วนเท่านั้น
ข้อถกเถียงเรื่อง LLM, การเลือก pytest และ regression ใน 3.4.3
- การรู้ว่า LLM ทำงานอย่างไรไม่ได้ทำให้มันกลายเป็นเครื่องมือที่ไร้ประโยชน์ มันควรถูกใช้อย่างระมัดระวัง แต่ในสภาพแวดล้อมปัจจุบันของวิศวกรรมซอฟต์แวร์และการบำรุงรักษาความปลอดภัยไอที มันยังมีประโยชน์
- rsync 3.4.3 เป็นรีลีสที่ตั้งใจเอนเอียงไปทางการแก้ปัญหาความปลอดภัยก่อน และในกระบวนการนั้นก็ทำให้บางกรณีใช้งานที่ถูกต้องแต่เฉพาะทางได้รับผลกระทบจากการเปลี่ยนแปลง
- กรณีใช้งานที่ได้รับผลกระทบเหล่านี้ไม่อยู่ในชุดทดสอบ rsync เดิมหรือการทดสอบด้วยมือ และกำลังทยอยจัดการ regression ที่ถูกรายงานผ่าน issue และ PR ใน GitHub repository
- แม้ pytest จะถูกใช้งานมากในโปรเจ็กต์อื่น แต่มีงานบางอย่างที่จำเป็นต่อชุดทดสอบ rsync ซึ่งมองว่าทำได้ยากมากด้วย pytest จึงเลือกออกแบบแนวทางทดสอบแยกต่างหาก
รีลีสถัดไปและการขยายการทดสอบด้านความปลอดภัย
- รายงานด้านความปลอดภัยยังคงเข้ามาอย่างต่อเนื่อง และตอนนี้กำลังมีงานเกี่ยวกับ CVE หลายรายการ
- มีนักพัฒนาคนอื่นที่มีทั้งความสามารถด้านการพัฒนาระบบและความรู้ด้านความปลอดภัยเข้าร่วมแล้ว โดยบางคนเป็นผู้ที่ถูกมองเห็นเด่นชัดขึ้นจากกระแสความเดือดดาลล่าสุด
- ตัวเลือกลำดับถัดไปอยู่ระหว่าง 3.4.4 ที่จะช่วยบรรเทา regression บางส่วน กับ 3.5.0 ที่มีการเปลี่ยนแปลงขนาดใหญ่กว่ามาก โดย 3.5 จะยกระดับมาตรฐานความปลอดภัยของ rsync อย่างมาก แต่ก็เป็นรีลีสที่มีขนาดการเปลี่ยนแปลงสูง
- การจะนำชุดการเปลี่ยนแปลงขนาดใหญ่ไปใช้ได้อย่างรวดเร็วกับซอฟต์แวร์อย่าง rsync จำเป็นต้องมีชุดทดสอบที่ครอบคลุม และการเขียนชุดทดสอบใหม่ครั้งนี้ก็เกิดจากความจำเป็นดังกล่าว
- รีลีส 3.5 จะมีการเพิ่มชุดทดสอบที่เกี่ยวข้องกับประเด็นด้านความปลอดภัยเข้าไปอีก
การเปรียบเทียบกับ openrsync และคำขอให้ช่วยรีวิวโค้ด
- ต่อกระแสที่จะนำ openrsync ไปแพ็กเกจสำหรับบางแพลตฟอร์ม มีความเห็นว่าสามารถลองนำชุดทดสอบ rsync ใหม่ไปใช้กับ openrsync ได้
- ตัวอย่างการรันมีคำสั่งดังนี้
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- ขณะนี้ openrsync ล้มเหลว 85 จาก 98 การทดสอบ โดยความล้มเหลวจำนวนมากมาจากฟีเจอร์ที่ openrsync ไม่มี แต่ก็ยังไม่ถือว่าเป็นผลลัพธ์ที่ดี
- แทนที่จะระบายความเดือดดาลเพิ่มขึ้น มีการขอให้ผู้คนช่วยตรวจโค้ดที่เปิดเผยอยู่จริงๆ และวิจารณ์อย่างสร้างสรรค์
1 ความคิดเห็น
ความคิดเห็นจาก Lobste.rs
เมื่อดูจากข้อความอ้างอิง ผู้เขียนดูเหมือนเป็นคนที่อยากออกเรือ แต่ก็รู้สึกถึงแรงกดดันจากการดูแลโปรเจ็กต์ และเหมือนมองว่า LLM เป็นทางออกที่ทำให้ทำทั้งสองอย่างได้
จะเกษียณและออกไปสนุกกับการล่องเรือจนไม่ได้แก้บั๊กก็ไม่เป็นไร และการไม่แก้บั๊กในโปรเจ็กต์โอเพนซอร์สก็ไม่เป็นไรเช่นกัน แค่บอกให้ชัดเจนและโปร่งใสต่อสาธารณะก็พอ อย่างที่พูดกันมาตั้งแต่ก่อนว่า “ยินดีรับแพตช์” ก็เพียงพอแล้ว โดยเฉพาะถ้ามีบริษัทที่ทรัพยากรพร้อมมากพึ่งพาโปรเจ็กต์นั้นอยู่ ก็ยิ่งควรเป็นแบบนั้น
อยากให้มีผู้ดูแลและนักพัฒนาอีกมากที่ได้เพลิดเพลินกับการเกษียณและการล่องเรือ โดยไม่ต้องถูกกดดันว่าต้องพึ่ง “ความช่วยเหลือ” จาก LLM เพื่อมาดูแลงานโอเพนซอร์ส ถึงอย่างนั้น ถ้าเขาอยากทดลองใช้ LLM กับโปรเจ็กต์ rsync นั่นก็เป็นสิทธิ์ของเขาอยู่ดี แม้ว่าคนอื่น ๆ รวมถึงฉันจะไม่เห็นด้วยก็ตาม
ไม่ว่าจะด้วยเหตุผลอะไร คนที่คอยก่อกวนผู้พัฒนาโอเพนซอร์สดูเหมือนจะลืมไปว่าซอฟต์แวร์โอเพนซอร์สฟรีไม่ใช่สินค้า แต่เป็นของขวัญ
คนภายนอกที่แค่มองดูอยู่ ถ้าไม่ชอบก็ fork ไปได้เลย Andrew จะทำงานกับโปรเจ็กต์นั้นในแบบที่เขาต้องการก็ได้ และคำวิจารณ์หรือความเห็นของพวกเราก็ไม่ใช่สิ่งจำเป็นเสมอไป
ส่วนที่ยังพอมีความหวังคือ ในระยะยาวอาจมีคนอื่นเข้ามารับช่วงดูแล rsync ก็ได้ Tridge เองก็เคยส่งต่อให้ผู้ดูแลคนใหม่มาก่อนแล้ว
ฉันเคยฟังงานพูดคุยเกี่ยวกับกรณีที่ OpenJS Foundation ให้ทั้งเงินทุนและการสนับสนุนช่วงเปลี่ยนผ่านแก่บางโปรเจ็กต์ เพื่อย้ายจากระบบผู้ดูแลคนเดียวไปเป็นการดูแลแบบทีม แล้วก็เขียนบทความลง LWN ซึ่งมีกำหนดเผยแพร่วันนี้ โปรเจ็กต์อย่าง rsync ต้องการการสนับสนุนแบบนี้มากกว่านี้อีกมาก
ประเด็นความปลอดภัยมีแรงกดดันสูง เป็นเรื่องที่ถูกจับตามองมาก และบ่อยครั้งก็ห่างไกลจากแก่นของโปรเจ็กต์ที่ผู้ดูแลรู้สึกสนุกด้วย
งานดูแลมีความรับผิดชอบมากมายและไม่ใช่ทุกอย่างจะสนุก แต่ฉันรู้สึกขอบคุณเมื่อผู้ดูแลฟรี/โอเพนซอร์สยอมทำงานแบบนั้นให้ด้วย ดูเหมือนจะมีคนที่ทำเช่นนี้ไม่มากนัก
อาจเป็นได้ว่าหากไม่มีความช่วยเหลือจาก LLM ต้นทุนในการบรรลุเป้าหมายบางอย่างสูงเกินไป แต่เมื่อมี LLM ช่วยก็กลายเป็นต้นทุนที่สมเหตุสมผล
หากมองในแง่บวก นี่คือการที่ผู้ดูแลโอเพนซอร์สซึ่งพยายามรักษาสมดุลชีวิตกับงานที่ดี สามารถใช้ LLM เพื่อลดภาระงานและไปถึงเป้าหมายที่ต้องการได้ง่ายขึ้น
ส่วนที่ยกมาอ้างเป็นเพียงบางส่วนของบทนำเท่านั้น และบทความนี้ชัดเจนว่าเขียนขึ้นอย่างรอบคอบและมีบริบทละเอียดอ่อน ไม่ใช่บทความพื้น ๆ เกี่ยวกับการดูแลโอเพนซอร์ส
ที่แปลกกว่านั้นคือยังละบริบทก่อนหน้าข้อความอ้างอิงไปด้วย เนื้อหาคือเมื่อรายงานปัญหาเพิ่มขึ้นอย่างรวดเร็ว rsync ก็จำเป็นต้องยกระดับแนวป้องกันอย่างมาก ต้องมี test suite ที่เข้มงวดยิ่งขึ้น การวิเคราะห์ code coverage, การทดสอบ CI บนแพลตฟอร์มที่มากขึ้น, การค้นหาปัญหาด้านความปลอดภัย และการเพิ่มเทคนิค defense in depth
ในกรณีนี้ผู้เขียนเกษียณแล้ว แต่ในโปรเจ็กต์โอเพนซอร์สอื่น คนที่ยังมีงานประจำหรือภาระอื่นก็อาจถูกกระแสภาระงานที่เพิ่มขึ้นแบบเดียวกันพัดเข้าใส่ได้ พูดตรง ๆ ฉันงงที่คอมเมนต์นี้ได้คะแนนนิยมสูงขนาดนั้น และมันไม่ได้ให้ความรู้สึกเหมือนเขียนด้วยเจตนาดีเลย อย่างมากก็แค่ดีกว่าคอมเมนต์ที่วิ่งเข้ามาตอบจากการเห็นแค่หัวข้อเพียงนิดเดียวเท่านั้น เป็นปฏิกิริยาที่ดูขาดความใส่ใจมาก
ฉันไม่ได้จะหาข้ออ้างหรือเห็นชอบกับการคุกคามใด ๆ แต่คำปกป้องนี้ยังขาดเหตุผลบางอย่างไป
คำอธิบายคือผู้เขียนออกแบบสำหรับ vibe coding, ตรวจทานโค้ดผลลัพธ์, มีทักษะทั้งด้านโค้ดและแชตบอต, จัดการ vibe coding อย่างระมัดระวัง และพยายามรักษาสมดุลระหว่างความปลอดภัยกับการถดถอยของฟังก์ชัน ฟังดูสมเหตุสมผล แต่ในความเป็นจริงก็มีregressionเกิดขึ้น และผู้เขียนเองก็ยังไปไม่ถึงสาเหตุว่าทำไม
เขาบอกว่า “เครื่องมือ AI เก่งงานง่าย ๆ เลยให้มันทำงานแบบนั้น” แต่จริง ๆ ไม่ใช่เลย แชตบอตนั้นเขียนงานได้ไม่ดี นี่แหละคือประเด็นสำคัญ แต่ดูเหมือนผู้เขียนจะยังไม่รับรู้ด้วยซ้ำ
ถ้ายืนยันได้ว่าช่วงหลังตัวเลขเพิ่มขึ้นจริงก็คงดี เพราะ regression เองก็ไม่ใช่เรื่องหายาก และอาจเป็นไปได้ว่าผู้คนแค่กำลังมองหาข้ออ้างมาโจมตี Andrew
ผู้เขียนยอมรับว่ามี regression ในบางกรณีการใช้งานของรีลีส rsync 3.4.3 และอธิบายว่าในรีลีสนั้นเขาตั้งใจให้น้ำหนักกับการแก้ประเด็นด้านความปลอดภัยมากกว่า ทำให้บางกรณีการใช้งานที่ถูกต้องแต่ค่อนข้างเฉพาะเจาะจงได้รับผลกระทบจากการเปลี่ยนแปลง
กรณีเหล่านั้นไม่อยู่ใน test suite เดิมของ rsync หรือการทดสอบแบบแมนนวลที่เขาทำเอง และตอนนี้เขากำลังจัดการ regression เหล่านั้นอยู่ พร้อมขอบคุณคนที่รายงานเข้ามาเป็น issue หรือ PR ใน GitHub repository หากกรณีการใช้งานของคุณได้รับผลกระทบ เขาก็ขออภัย และบอกด้วยว่าหากคุณยอมรับความเสี่ยงด้านความปลอดภัยได้ ก็สามารถใช้รีลีสก่อนหน้าได้
ช่วงครึ่งปีมานี้ได้ยินซ้ำแล้วซ้ำเล่าว่า “โลกของวิศวกรรมซอฟต์แวร์เปลี่ยนไปอย่างมากในช่วงไม่กี่เดือนที่ผ่านมา” และ “โลกของการดูแลรักษาซอฟต์แวร์ท่ามกลางความปลอดภัยไอทีและการถาโถมของรายงานได้เปลี่ยนไปโดยสิ้นเชิงในช่วงไม่กี่สัปดาห์ที่ผ่านมา” จนเริ่มเอือม
ถ้าต้นเหตุของการ ถาโถมของรายงาน นี้คือ LLM การไปหา LLM มาเป็นทางแก้ก็ให้ความรู้สึกว่าเป็นทิศทางที่ผิดอย่างน่าเหลือเชื่อ
ถึงอย่างนั้น เรื่องที่ว่าการต้องดูแลอะไรสักอย่างที่กำลังฮิตอยู่ตอนนี้คงเป็นเรื่องสยองนั้นเชื่อได้ทันที บางทีสำหรับเขา ทางเลือกที่ดีที่สุดอาจเป็นการถอยออกมาแล้วใช้ชีวิตเกษียณจริง ๆ มากกว่าจะพยายามเค้นเวลาใช้งานคอมพิวต์ที่มีอยู่อย่างจำกัดให้หนักขึ้น
ถ้ามันเป็นเครื่องมือที่มีประโยชน์ได้สักครึ่งหนึ่งของที่คนพูดกันจริง ผมคิดว่าประโยชน์ของมันคงพิสูจน์ตัวเองได้
แต่เรื่องที่คนอย่าง Tridgell พูดก็ยังมีค่าพอให้ฟัง และ “น้ำท่วม” ของรายงานความปลอดภัยก็ควรถูกมองอย่างจริงจัง ไม่ว่าใครหรืออะไรจะเป็นคนพบ ประเด็นความปลอดภัยก็คือประเด็นความปลอดภัย เพราะงั้นบทความนี้เลยให้ความรู้สึกต่างจากการบุกโจมตีที่น่าเบื่อตามปกติ
ท้ายที่สุดเราอาจเข้าสู่วงจรขาลงที่พึ่งพา LLM มากขึ้นเรื่อย ๆ
แล้วทำไมถึงเป็นทิศทางที่ผิด? หมายความว่าถ้าไม่มีใครใช้ LLM เลยจะดีกว่าหรือ?
การพัฒนาแบบมี LLM ช่วยไม่จำเป็นต้องให้ผลลัพธ์เป็น “ขยะ” เสมอไป
ขอบคุณที่เขียนและแชร์บทความนี้ โดยเฉพาะส่วนที่กำลังชั่งใจว่าจะออก 3.4.4 เพื่อบรรเทา regression บางส่วน หรือจะไปที่ 3.5.0 ซึ่งมีการเปลี่ยนแปลงใหญ่กว่ามากนั้นสะดุดตา
ถ้าผู้เขียนกำลังอ่านอยู่ สำหรับกรณีนี้ 3.4.4 ดูเป็นแนวทางที่ถูกต้อง ในเมื่อรีลีสก่อนหน้ามี regression การกระโดดไป 3.5.0 ที่ใหญ่กว่าทันทีคงทำให้หลายคนมองว่าบุ่มบ่าม ถ้าทำให้ผู้คนเข้าใจความแตกต่างได้ง่ายขึ้น ความกังวลก็น่าจะลดลง
ส่วนที่บอกว่าเคยตั้งใจจะทำงานกับโครงสร้างหลักของ test suite ใหม่บน master แบบเปิดเผยก่อน แต่พอเห็นว่านั่นกลับก่อให้เกิดความโกรธ ก็เลยคิดว่าบางทีมันอาจเป็นความคิดที่ไม่ดีนั้น ผมไม่คิดว่าการลดความโปร่งใสลงจะช่วยให้การรับรู้และปฏิกิริยาดีขึ้น อย่างมากก็คงแค่เลื่อนแรงต้านที่หนักกว่าออกไปเท่านั้น
คำพูดที่ให้เอา test suite ใหม่ของ rsync ไปลองรันกับ openrsync นั้นไม่ยุติธรรม samba rsync เป็นโปรโตคอล 32 ส่วน openrsync เป็น โปรโตคอล 27 และก็ไม่ได้อ้างว่าฟีเจอร์ครบถ้วนด้วย
ทั้ง Medium และ Cloudflare นี่เป็นคู่ผสมที่เลวร้ายและไม่ควรมาอยู่ด้วยกัน
https://archive.is/qbyVA
การดูแลโอเพนซอร์สเป็นงานที่แทบไม่ได้รับคำขอบคุณ Tridge พยายามจัดการ หนี้ทางเทคนิค ของ test suite และตอบสนองอย่างรับผิดชอบต่อกระแส CVE ที่ LLM ตรวจพบ แต่ดูเหมือนจะโดนกฎของ Hyrum เล่นงาน แผน 3.4.4 เป็นตัวเลือกที่แย่น้อยกว่า และสุดท้ายก็คงต้องเดินหน้าต่อไป
ประเด็นนี้ทำให้รู้สึกลังเลได้ทั้งสองด้าน ด้านหนึ่งก็คิดว่าความปลอดภัยจะรับประกันได้ก็ต่อเมื่อมนุษย์เป็นคนเขียนโค้ดเอง
เพราะระหว่างเขียนโค้ดเราจะคิดไปกับโค้ดนั้น และจับข้อผิดพลาดได้ตั้งแต่เนิ่น ๆ สำหรับฉัน ตอนเขียนเองทำได้ดีกว่าตอนรีวิวโค้ดมาก เพราะตอนรีวิวฉันไม่ได้พิจารณาทุกบรรทัดอย่างรอบคอบ หลายอย่างเลยหลุดผ่านไปเฉย ๆ
แต่อีกด้านหนึ่ง นอกเหนือจากข้อเท็จจริงพื้นฐานที่ว่าการคุกคามเป็นสิ่งที่ยอมรับไม่ได้ Andrew ก็มีสิทธิ์จะดูแลโปรเจกต์ของตัวเองในเวลาส่วนตัวตามแบบที่เขาต้องการ ถ้าเขาอยากใช้ LLM ฉันอาจไม่เห็นด้วย แต่ก็เป็นโปรเจกต์ของเขาและเป็นดุลยพินิจของเขา ถ้าไม่ชอบ ฉันก็ควรย้ายแบ็กอัปของฉันไป restic หรือ borgbackup หรือไม่ก็ฟอร์ก rsync
เพื่อความชัดเจน ฉันไม่ได้คัดค้าน vibe coding โดยตัวมันเอง ที่บริษัทฉันแทบถูกบังคับให้ใช้ครึ่งหนึ่งอยู่แล้ว และมันก็ใช้ได้พอประมาณกับงานส่วนใหญ่ทุกวันนี้ของฉัน ซึ่งเป็นการเขียน glue code ที่น่าเบื่อและไม่ได้ใหม่อะไรนัก แค่ฉันไม่ใช้มันในเวลาส่วนตัว
rsyncเองก็ไม่ใช่วิธีที่เหมาะที่สุดนักเพราะมันไม่ได้ช่วยเรื่องกู้คืนเมื่อเนื้อหาไฟล์เสียหาย เครื่องมืออย่าง restic ดีกว่ามาก และยังเก็บไฟล์เวอร์ชันก่อนหน้าไว้เพื่อรับมือกรณีแบบนี้ด้วย จริง ๆ แล้วมันยังติดตามการลบได้ด้วย จึงรู้ได้ว่าไฟล์ไหนไม่เกี่ยวข้องแล้ว
ฉันมีประสบการณ์ด้านความปลอดภัยของแอปพลิเคชัน เลือก exploit บางอย่างได้ และอาจจับได้ตอนรีวิว แต่ก็ยังทำได้ไม่ดีเท่ากับ LLM ชั้นนำตอนนี้ที่วนลูปแนว “หากรณีป่วย ๆ ให้มากกว่านี้”
ฉันเคยเจอปัญหาในซอฟต์แวร์ที่คนใช้กันมาก ทั้งในโค้ดของฉันเอง ไลบรารีที่ใช้ และ implementation ทางเลือก โดยแทบไม่ต้องพยายามมาก เวลาและความดื้อรั้นที่มนุษย์มีให้ทุ่มลงไปนั้นเทียบกันไม่ได้เลย
ทั้งองค์กรยังมีซอฟต์แวร์ความปลอดภัยที่ติดตั้งครอบคลุมเพื่อป้องกัน ตรวจจับ และตอบสนองต่อปัญหา ในแต่ละส่วนย่อมมีช่องโหว่และยังมีงานให้ทำเพิ่มเสมอ องค์กรอาจเลือกยอมรับการปรับปรุงท่าทีด้านความปลอดภัย แม้รู้ว่าไม่อาจสมบูรณ์แบบ ได้ดีกว่าการไม่มีการปรับปรุงเลย และ trade-off ที่ LLM มอบให้ก็เป็นส่วนหนึ่งของสิ่งนั้น
จุดแลกเปลี่ยนนี้ขึ้นกับบริบท แต่ก็น้อยครั้งมากที่จะลงเอยว่า “โค้ดทุกบรรทัดต้องเขียนด้วยมือ”
ใช้ได้กับเซิร์ฟเวอร์อย่าง rsync ด้วย ตามที่ผู้เขียนบอก มันอาจต้องการการรีแฟกเตอร์ครั้งใหญ่เพื่อให้แข็งแรงและทนทานขึ้น ถ้าการใช้ LLM รีแฟกเตอร์ไปสู่การแยกสิทธิ์ช่วยให้ได้ โค้ดฐานความเชื่อถือ ที่เล็กลง ก็อาจยอมรับบั๊กบางส่วนที่อยู่นอกขอบเขตนั้นได้
ฉันไม่รู้บริบทเฉพาะของ rsync แต่เชื่อว่าภายใต้ทรัพยากรอันจำกัดที่โปรเจกต์แบบนี้มักมี ผู้ดูแลกำลังตัดสินใจที่ดีที่สุดต่อโปรเจกต์และผู้ใช้แล้ว
ข้อดีคือ rclone รองรับการทำงานขนาน จึงใช้แบนด์วิดท์เครือข่ายที่มีอยู่ได้มีประสิทธิภาพกว่ามาก
สิ่งนี้ให้ขอบบนของปัญหาที่เป็นไปได้
ส่วนขอบล่างคือบั๊กและช่องโหว่ที่ผมหาเจอ คนอื่นหาเจอ หรืออย่างอื่น เช่น LLM หาเจอ
สถานการณ์ที่มนุษย์รีวิวโค้ด C ที่ตัวเองเขียน เช่น rsync นั้น ยากจะเรียกว่าอยู่ในจุดที่ดีในสเปกตรัมนี้ได้ และผมไม่ได้ตั้งใจจะตำหนิ Andrew เลยแม้แต่น้อย
ผมเห็นใจผู้ดูแลที่เกษียณแล้วและอยากออกเรือ แต่ไม่คิดว่าบริบทนั้นเปลี่ยนอะไรในระดับพื้นฐาน
Tridgell ไม่ได้ติดหนี้ว่าเขาต้องทำงานใด ๆ ให้เรา และเขาก็มีอิสระจะเกษียณไปล่องเรือ ถ้าเขาอยากทำแบบนั้นก็ขอให้เป็นไปด้วยดี ผมเข้าใจความรู้สึกรับผิดชอบนั้น แต่ถ้าอ่านระหว่างบรรทัดให้ดี ดูเหมือนเขาจะรู้สึกว่ามันเป็นภาระอยู่บ้าง
แต่ rsync เป็นซอฟต์แวร์สำคัญ และผมคิดว่าคนที่อาสาดูแลมันก็ควรรักษามาตรฐานคุณภาพระดับหนึ่งไว้ ถ้างานของผู้ดูแลไม่ถึงมาตรฐานนั้น ก็ถือว่าเป็นความผิดพลาด แน่นอนว่านั่นไม่ได้แปลว่าเขาสมควรถูกคุกคาม การบอกว่าบางอย่างเป็นความผิดพลาด ไม่ได้หมายความว่าคนที่ทำผิดพลาดนั้นเป็นคนไม่ดี หรือเราไม่มีความเห็นใจเขา
ดังนั้นคำถามคือ งานที่เครื่องมือเขียนโค้ดด้วย AI ทำออกมานั้นถึงมาตรฐานไหม มาตรฐานที่ว่าก็คือประมาณว่า “งานที่มีคุณภาพระดับนี้ ยังดีกว่าไม่มีงานนี้เลยหรือไม่” ถ้ามันทำให้ซอฟต์แวร์ดีขึ้นก็ควรทำต่อ ถ้าทำให้แย่ลงก็ควรหยุด ผมไม่ได้อ้างว่านี่เป็นนิยามที่ชาญฉลาด แต่คิดว่าเป็นนิยามที่ถูกต้อง
เราไม่มีสิทธิ์เรียกร้องให้ Tridgell ทำงานเพิ่ม แต่ก็ยังมีพื้นที่จะพูดได้ว่า “สิ่งนี้ทำให้ผู้ใช้แย่ลง” ถ้ามันเป็นความจริง
พูดตรง ๆ ผมยังไม่ได้สรุปความคิดเรื่องนี้อย่างสมบูรณ์ มี regression เกิดขึ้น และ Tridgell อธิบายว่ามันเป็นกรณีขอบ แต่ถ้าไม่มีบริบทเพิ่ม ผมก็ไม่รู้จะชั่งน้ำหนักผลกระทบของ regression ในกรณีขอบนั้นกับคุณค่าของการแก้ปัญหาด้านความปลอดภัยที่อาจมีได้อย่างไร
บางคนอาจนึกถึงคำว่า “WITHOUT ANY WARRANTY” แต่เงื่อนไขนั้นไม่เกี่ยวในที่นี้ มันเป็นการปฏิเสธความรับผิดทางกฎหมาย ไม่ใช่การปฏิเสธความภาคภูมิใจในฝีมือหรือข้อเรียกร้องเชิงไม่เป็นกฎหมายว่าควรทำให้ดีที่สุด คอมเมนต์นี้ก็ให้มาแบบ “WITHOUT ANY WARRANTY” เช่นกัน แต่ถ้าผมทำพลาด ผมก็ย่อมถูกวิจารณ์ได้อยู่ดี
ไม่ใช่ว่าผู้เขียนทำให้มันเป็น ซอฟต์แวร์สำคัญ หากคุณหรือใครก็ตามเลือกใช้มัน ความรับผิดชอบก็อยู่ที่ผู้ใช้ ถ้าซอฟต์แวร์ไม่ทำงานตามที่คาดหวัง ก็ฟอร์กมันหรือหาตัวแทนได้ สิ่งที่ทำไม่ได้คือไปบังคับให้คนคนนั้นขยับตามจังหวะของคุณ
สำหรับคนที่พลาดข่าว regression เดิมไป นี่คือบริบท: https://github.com/RsyncProject/rsync/issues/929
รายงาน issue เป็นสกรีนช็อตของ mastodon post และหลังจากนั้นก็มีคอมเมนต์โต้เถียงต่อเนื่องเกิน 300 รายการแล้ว
ไม่ต้องอธิบาย แค่ทำเหมือนที่เคยทำมาก็พอ คนที่ไม่ชอบก็จะยังคงไม่ชอบต่อไป
ผู้คนเริ่มไม่ชอบมาตั้งแต่ตอนที่เลิกเขียนแอสเซมบลีแล้ว และก็จะไม่หยุดในอนาคต