ได้โปรดอย่าทำลายซอฟต์แวร์นี้ด้วย vibe coding

• ประเด็นนี้จบลงด้วยสถานะ Closed และเป็นโพสต์เชิงตั้งข้อกังวลที่ไม่มีขั้นตอนการทำซ้ำปัญหาหรือข้อเสนอการแก้ไขในเนื้อหา จึงไม่เห็น branch, PR หรือ milestone ที่เชื่อมโยงไว้
• ประเด็นตั้งต้นคือความกังวลว่าใน rsync มี การเปลี่ยนแปลงที่ AI เข้ามาเกี่ยวข้อง จนทำให้ความเสถียรสั่นคลอน โดยเนื้อหาหลักถูกโพสต์เป็นภาพเป็นหลักแทนคำอธิบายข้อความ
• ผู้ใช้รายหนึ่งรายงานว่าเพราะ log2ram ใช้ rsync ทำให้ เครื่องพิมพ์ 3D ทำงานที่ CPU 100% และบอกว่าเท่ากับ AI ได้ทำให้บั๊กนี้ไหลเข้าไปถึงหุ่นยนต์
• ผู้ใช้อีกรายมองว่า rsync เป็นเครื่องมือที่เสถียรซึ่งควรต้องการเพียง อัปเดตด้านความปลอดภัยและการแก้บั๊ก มากกว่าฟีเจอร์ใหม่หรือการเขียนใหม่ และในแพตช์รีลีสสองครั้งล่าสุดกลับเกิดปัญหาที่ไม่ควรไปเปลี่ยนพฤติกรรมเดิม
• ผู้ใช้ที่ใช้ rsync ในงาน DFIR อธิบายว่าเพียงแค่ข้อเท็จจริงที่ว่า AI มีส่วนในอัปเดตก็ทำให้ตามนโยบายองค์กรต้องถือเป็น “เครื่องมือ AI” และต้องมีการทบทวนเพิ่มเติม
• ฝั่งที่ไม่เห็นด้วยโต้ว่า issue tracker ไม่ใช่พื้นที่ระบายความไม่พอใจเพื่อเรียกกระแส และถ้าไม่มีบั๊กรายงานที่เฉพาะเจาะจงหรือขั้นตอนทำซ้ำ ก็ควรย้ายไปที่ Discussions หรือไม่ก็ fork เอง
• ความขัดแย้งหลักขยายตัวระหว่างจุดยืนแบบ “เป็นซอฟต์แวร์ฟรี ถ้าไม่ชอบก็ fork ไป” กับอีกจุดยืนที่มองว่า rsync เป็น เครื่องมือโครงสร้างพื้นฐานหลัก อยู่แล้ว จนการต้องมาถกเรื่องการ pin เวอร์ชันหรือ fork ในฝั่ง downstream นั้นเองคือสัญญาณของปัญหา
• ผู้ใช้บางคนพูดถึงการเขียนใหม่ด้วย Rust หรือการ fork แต่ผู้ใช้อีกรายชี้ว่าเหตุผลที่ rsync ได้รับความนิยมคือ ความเสถียรและการทำงานแบบเดิมไม่เปลี่ยน และการเขียนใหม่ควรเป็นอีกโปรเจกต์หนึ่งต่างหาก
• ฝ่ายที่สนับสนุนการใช้ AI ระบุว่าไม่ควรเหมารวมทุกการพูดถึง AI ว่าเป็น “vibe slop” และเรียกร้องให้ตรวจสอบ commit log ตั้งแต่เดือนมีนาคมด้วยตนเองเพื่อดูเหตุผลของการเปลี่ยนแปลง
• kaithar อธิบายว่างานช่วงหลังรวมถึงการแก้และเสริมความแข็งแกร่งให้กับ บั๊กและช่องโหว่ด้านความปลอดภัย เช่น การอ่านหน่วยความจำที่ยังไม่ถูกกำหนดค่า, overflow/underflow ของ wire protocol, timestamp แบบ 32 บิต และการปรับให้สอดคล้องกับมาตรฐาน C
• คอมเมนต์เดียวกันยังโต้ว่า หากตรึงอยู่กับรีลีสเก่าอย่าง 3.4.1 ก็อาจทำให้ค้างอยู่บนเวอร์ชันที่มี CVE หลายรายการ และ regression ก็อาจเกิดจาก edge case ที่การทดสอบพลาดไป
• สุดท้ายแล้ว issue นี้ไม่ได้ลงเอยด้วยการแก้บั๊กแบบเฉพาะเจาะจง แต่กลายเป็นข้อถกเถียงเรื่องจะรับมือกับ ความเชื่อถือได้ การตรวจสอบย้อนหลัง และธรรมาภิบาลของการพัฒนาแบบมี AI ช่วย อย่างไรในโครงสร้างพื้นฐานที่ต้องเสถียรระยะยาวอย่าง rsync

[GN⁺]

ความเห็นจาก Hacker News

• การรุมถล่มกันแบบนี้แปลกประหลาดมาก และบางคนก็ดูเหมือนกำลังทำตัวไร้เหตุผลอยู่ ผมพอเข้าใจแรงจูงใจที่อยาก “ชนะ” ในการต่อสู้นี้อยู่บ้าง แต่แบบนี้ไม่ใช่เลย และมีแต่จะทำให้ดูเหมือนพวกคลั่งเท่านั้น
  ใช้เวลาแค่ 5 นาทีค้นหา regression ในหน้า issue แล้วไล่ดูผลลัพธ์ 17 รายการก็พอแล้ว
  ในตัวติดตามบั๊กที่ใช้ก่อนย้ายมา GitHub อาจมีมากกว่านี้อีกก็ได้
  พฤติกรรมแบบนี้โง่มาก และดูเหมือนผู้คนกำลังพยายามคว้าอะไรก็ได้มาใช้เพื่อทำให้ ความเกลียด AI ดูสมเหตุสมผล ราวกับลืมไปว่าก่อนยุค AI คนก็ทำพลาดกันอยู่แล้ว
  ถ้ามีหลักฐานว่า AI ทำให้จำนวน issue ที่ยังไม่ปิดของ rsync เพิ่มขึ้นอย่างมีนัยสำคัญ ก็อยากให้เอามาแสดง ผมยินดีเปลี่ยนความเห็น

  • ไม่ควรมองแค่ว่า “คนเกลียด AI ก็เลยคว้าอะไรก็ได้มาโจมตี” เท่านั้น ถ้าคนรู้สึกว่าสิ่งหนึ่งมีปัญหา พวกเขาก็ย่อมลงมือทำอะไรบางอย่าง
    มันอาจไม่ใช่สาเหตุโดยตรงของ commit นี้ แต่ก็อาจเป็นปฏิกิริยาต่อปัญหาสะสมอื่น ๆ และตัวมันเองก็ควรถูกนำมาพิจารณา
    ดูเหมือนผู้คนจะเหนื่อยกับการต้องฝืนกลืนวาทกรรมแบบ “AI คือสิ่งที่ดีที่สุดนับตั้งแต่ [อุปมาเชิงวัฒนธรรม]” และเลยพยายามคว้าทุกฟางเส้นสุดท้ายเพื่อต่อต้าน ซึ่งผมมองว่านั่นเป็นปฏิกิริยาที่ค่อนข้างปกติ
  • วิธีที่คนแห่กันมาด้วยภาพมีมนั้นแปลกมาก แต่ภาษาที่ใช้เองก็อยู่ในระดับที่ Tridgell คุ้นเคยดีจาก LKML อยู่แล้ว ดังนั้นนั่นไม่ใช่ประเด็นน่ากังวลหลัก
    ถ้าไม่มีใครบอกเลยว่าผู้ใช้ ไม่เชื่อถือ AI แล้วผู้ดูแลจะรู้ได้อย่างไร? rsync เคยเสถียรมาก แล้วผู้ใช้ควรย้ายไป Openrsync แบบเงียบ ๆ โดยไม่พูดอะไรเลยงั้นหรือ?
  • ถ้าเครื่องมือที่เคยเสถียรและได้รับความเชื่อถือมาก ๆ จู่ ๆ เริ่มถดถอยลง ผู้คนจะโกรธก็ถือว่าสมเหตุสมผลมาก มี issue ของ Linux Mint Timeshift ที่สรุป regression หลายรายการที่ยังเปิดอยู่ในหน้า issue ของ rsync และดูเหมือนว่าสิ่งเหล่านี้เพิ่งถูกนำเข้ามาหลังเริ่ม vibecoding เท่านั้น (https://github.com/linuxmint/timeshift/issues/548)
    ลิงก์หนึ่งในนั้นพาไปยังการรวบรวมบั๊กที่ใหญ่กว่าจากดิสโทรลูกต่าง ๆ (https://github.com/void-linux/void-packages/issues/60825)
    เมื่อดูจากชื่อเสียงของซอฟต์แวร์ที่ทำด้วย vibecoding ความโกรธก็สมเหตุสมผลมาก แม้แต่ผู้เชี่ยวชาญที่ผมชอบยังพูดเลยว่า “ถ้าจะไม่ให้มันสร้างบั๊ก คุณต้องจัดการมันด้วยวิธีที่เฉพาะมาก ๆ และบางทีควรใช้แค่กับเวอร์ชัน 0 สำหรับลองวาดโดเมนดูเท่านั้น”
    แต่ตอนนี้เครื่องมือ แกนหลักสำหรับแบ็กอัป ระดับมาตรฐานอุตสาหกรรมกลับถูกดึงพรมออกจากใต้เท้าผู้ใช้อย่างชัดเจนในวิธีที่ไม่ปลอดภัย เพราะผู้ดูแลอยาก “เพิ่มฟีเจอร์” เข้าไป
    ในเธรด Timeshift ยังมีข้อความว่า “หลังอัปเดต rsync การใช้ CPU ระหว่างแบ็กอัปรายวันหนักมากจนต้องหยุด timeshift ที่วนไม่รู้จบ”
    พูดอีกแบบคือ ผู้คนกำลังหงุดหงิดและโกรธเพราะเครื่องมือที่พวกเขาฝากแบ็กอัปและข้อมูลไว้ กำลังทำลายโครงสร้างพื้นฐานด้านแบ็กอัปทั้งหมดด้วย regression จำนวนมหาศาลและบั๊กใหม่ ๆ และสาเหตุก็คือนักพัฒนาหลักกำลังทำ vibecoding
    แม้แต่ผู้เชี่ยวชาญด้าน vibecoding อย่าง Simon Wilson ก็ยังระบุชัดว่านี่ทำได้ “เฉพาะเมื่อจัดการเครื่องมือด้วยวิธีบางอย่างเท่านั้น” ซึ่งก็แปลว่าผู้ดูแลคนนี้ไม่ได้ทำแบบนั้น หรือไม่ก็สิ่งที่พูดนั้นไม่เป็นความจริง
    ถ้าคุณอ่านเธรดนั้นจริง ๆ แทนที่จะเลื่อนผ่านเฉพาะส่วนที่สองคนเถียงกัน คุณจะเห็นว่ามีรายงานหลายรายการจากผู้ใช้ในสภาพแวดล้อมภาคอุตสาหกรรมและภาครัฐที่บอกว่าพวกเขาต้องนำทั้งกระบวนการกลับไปทำใหม่เพื่ออัปเดตซอฟต์แวร์นี้ เพราะซอฟต์แวร์กลายเป็นสิ่งที่เชื่อถือไม่ได้ในทันที ทำอันตรายต่อผู้ใช้โดยตรง และทำลายเหตุผลที่ซอฟต์แวร์นี้มีอยู่
    ถ้าผมฝาก แบ็กอัปมากกว่า 500GB ไว้กับซอฟต์แวร์นี้ ผมก็คงโกรธเหมือนกัน และคงสงสัยว่าจะมีปัญหาอีกกี่อย่างที่เล็ดรอดเข้าไป ซึ่งจะไม่ถูกพบจนกว่าบริษัทจะเจอกับการสูญเสียข้อมูลมูลค่า 10 ล้านดอลลาร์ เพราะไม่ได้ทดสอบแบ็กอัปอย่างสม่ำเสมอ
  • ฟังดูเหมือนอาการ AI avoidance syndrome
  • ตอนนี้ AI กลายเป็นประเด็นการเมืองแบบแบ่งขั้วไปแล้ว และผลลัพธ์ทั้งหมดที่ตามมาก็มาพร้อมกันหมด ถึงจุดนี้ก็แทบเหมือนกับการบ่นว่าพระอาทิตย์ขึ้นทางทิศตะวันออก :(

• ไม่เข้าใจจริงๆ
  มีซอฟต์แวร์ที่แข็งแกร่งซึ่งผู้คนและบริการจำนวนมากใช้งานอยู่ มันทำงานได้ดี ทำหน้าที่ของมัน และบางครั้งก็แค่ต้องมีอัปเดตแก้บั๊กเล็กน้อยเท่านั้น
  แล้วทำไมตรงนี้ถึงต้องมี AI?
  แถมก็ไม่เข้าใจอีกว่าทำไมคนถึงพูดว่า “ก็ fork ไปใช้เวอร์ชันก่อนหน้าเองสิ” ทั้งที่จริงมันควรตรงกันข้าม ควรทำ parallel fork แบบ younamethetool-ai แล้วอย่าไปแตะต้นฉบับ
  ตอนนี้ฉันต้อง fork เครื่องมือระบบทั้งหมดของตัวเองแล้วมาดูแลเองเลยหรือ?

• สำหรับคำถามว่า “ทำไมตรงนี้ถึงต้องมี AI” อย่างที่มีคนพูดไว้ในคอมเมนต์หลายอันใน issue นั้น คนที่จะตัดสินวิธีการทำงานของแพ็กเกจโอเพนซอร์สก็คือนักพัฒนาที่เข้ามามีส่วนร่วม
  การเข้าไปบ่นใน issue tracker ว่า AI กำลังทำลายซอฟต์แวร์โดยไม่มีหลักฐาน เป็นรูปแบบหนึ่งของการคุกคามผู้มีส่วนร่วมในโอเพนซอร์สที่ถูกพูดถึงบ่อยบน Hacker News [1]
  https://github.com/RsyncProject/rsync/issues/929#issuecommen...
  “issue tracker ไม่ใช่ที่สำหรับเก็บเกี่ยวโพสต์ไวรัลจากโซเชียลมีเดีย ถ้าจะทำก็รายงานบั๊กที่นำไปปฏิบัติได้ หรือไม่ก็ fork เอง การพรั่งพรูอารมณ์ใส่การตัดสินใจของนักพัฒนาไม่ได้ก่อให้เกิดประโยชน์”
  https://github.com/RsyncProject/rsync/issues/929#issuecommen...
  “@II-Paulus-II หยุดได้แล้ว คุณไม่รู้อะไรเลย คุณส่งมอบฟีเจอร์ด้วยมือตัวเองไป 0 อย่าง ไม่มีใครพึ่งพาโค้ดของคุณ คุณก็แค่คนคอยชี้นิ้วว่า ‘AI เขียนสิ่งนี้’ โดยหลบอยู่หลังความเหนือกว่าทางศีลธรรมจากการเขียนโปรเจ็กต์ของเล่นกับสคริปต์เองตั้งแต่ต้น คุณส่งมอบก็ไม่ได้ ปรับตัวก็ไม่ได้ และยังไม่รู้ด้วยว่า issue tracker ไม่ใช่ที่สำหรับท่าทีแบบนี้”
  [1] https://news.ycombinator.com/item?id=43077833

• เห็นด้วย 100% กับความรู้สึกที่ว่า “ได้โปรดอย่าทำลายเจ้าม้าศึกที่เสถียรและไว้ใจได้นี้”
  แม้จะยังไม่ได้อ่านละเอียด แต่ประโยคที่ว่า “ในรีลีสนี้มีการแก้ไข CVE 6 รายการ ทั้งหกรายการได้รับการจัดสรรโดย VulnCheck ในฐานะ CNA เวอร์ชันที่ได้รับผลกระทบในทุกกรณีคือ 3.4.2 และเก่ากว่า” ดูเป็นคำตอบที่ค่อนข้างหนักแน่นสำหรับคำถามว่า “ทำไม?”
  https://download.samba.org/pub/rsync/NEWS#3.4.3

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

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

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

• วิธีที่เปิด issue นั้นน่ารังเกียจจริง ๆ แต่ก็ยังไม่เข้าใจว่าทำไมถึงดูเหมือนผู้ดูแลปล่อย AI ใส่ rsync ทำไมถึงทำแบบนั้น? ในเมื่อได้ทั้งชื่อเสียงและความไว้วางใจมาแล้ว เป็นผู้นำในตลาดเฉพาะทางบางส่วน แทบไม่มีแรงกดดันจากตลาด คนก็ชอบเครื่องมือนี้ และมันก็ทำสิ่งที่ต้องทำได้อย่างแม่นยำดีอยู่แล้ว ทำไมถึงต้องลองของจุกจิกกึ่งทดลองพวกนี้ด้วย?
  มันเหมือนบทพูดสั้น ๆ ใน Matrix ที่ว่าจิตมนุษย์แบบดิบ ๆ ไม่อาจยอมรับสรวงสวรรค์ได้ คุณมีเครื่องมือที่สมบูรณ์แบบ ใช้มันแล้วชนะไปแล้ว แทบไม่มีอะไรมาทดแทนได้ในตลาดเฉพาะทางนี้ เชื่อถือได้ และในเชิงเปรียบเปรยก็กลายเป็นชื่อที่ใคร ๆ ก็รู้จักแล้ว การเอามันไปเสี่ยงหรือไปแตะต้องแบบนี้ไม่มีเหตุผลกับใครเลย และชวนงงมาก
  ถึงอย่างนั้น การทำแบบนั้นใน issue tracker อย่างเป็นทางการก็ยังเป็นพฤติกรรมที่น่ารังเกียจมากอยู่ดี ทั้งท่าทีแย่และดูไม่มีเจตนาดี

  • ถ้าเป็นเมื่อหลายปีก่อน ฉันคงออกมาปกป้องผู้ดูแลอย่างแข็งขัน เพราะการดูแลโปรเจกต์โอเพนซอร์สใด ๆ ก็ตามเป็นงานที่หนักและแทบไม่ได้รับคำขอบคุณอยู่แล้ว และถ้าเป็นโปรเจกต์ที่มั่นคงแล้วอย่าง rsync ก็ยิ่งเป็นเช่นนั้น
    แต่ตอนนี้ AI ดูไม่ใช่เรื่องบวกแบบล้วน ๆ ในที่ไหนเลย และฉันมองแรงต้านต่อการใช้ generative AI นี้ว่าเป็นการปรับทิศทางของสังคมไปในทางที่ดี
    มีบทความที่พูดถึงความพึงพอใจฉับพลันจากการใช้ LLM อยู่ และยิ่งได้ปฏิสัมพันธ์กับคนที่ใช้เครื่องมือนี้มากขึ้นเท่าไร ก็ยิ่งคิดว่านี่อาจเป็นปัญหาหลักจริง ๆ ชีววิทยาของเรารับมือมันไม่ไหว
    เราเห็นคนที่เดิมทีฉลาดมาก ๆ ทำเรื่องโง่จริง ๆ เพียงเพราะสล็อตแมชชีนบอกให้ทำ และยังถูกฝึกจนกลายเป็นคนไร้ทางสู้เมื่อสล็อตแมชชีนล้มเหลวอีกด้วย
    ฉันถูกมองเหมือนเป็นพวกลัดไดต์ที่มองไม่เห็นความก้าวหน้า แต่สิ่งที่เห็นคือเพื่อนร่วมงานสร้าง benchmark ไร้ความหมายแล้วแนบกราฟสวย ๆ ที่ทำด้วย AI มา
    จากนั้นก็ต้องเลือกระหว่างยิ้มแล้วทำเหมือนว่านั่นเป็นงานที่ดี หรือดุว่ามันไม่มีความหมายเพราะ benchmark กำลังทดสอบช่วงที่ถูกตรึงเป็นค่าคงที่ ไม่ว่าทางไหนก็กลายเป็นว่าปฏิบัติต่อพวกเขาเหมือนเด็ก 7 ขวบ ไม่ใช่เพื่อนร่วมงานที่ฉลาด
  • คำตอบของคำว่า “ทำไม?” คือทุกคน รวมถึงในฟอรัมนี้ด้วย ติด ความพึงพอใจฉับพลันของ LLM กันหมดแล้ว แค่ไล่อ่านผลลัพธ์คร่าว ๆ แล้วก็เชื่อด้วยความหยิ่งล้วน ๆ ว่ามันทำงานตรงกับที่ตัวเองคิด
  • ความเห็นนี้สรุปจากการดู issue อย่างเดียวหรือมีหลักฐานจริง? ลิงก์ GitHub นี้น่าสนใจอยู่ แต่แทบไม่มีบริบทเลยว่าดราม่านอกจาก “Claude” คืออะไร
    ไม่ว่าผู้ดูแล rsync จะอยู่ตรงไหนระหว่างผู้ดูแลที่สมบูรณ์แบบและมีความรับผิดชอบ กับเด็กที่ไร้ความสามารถ เราก็ยังไม่รู้ข้อเท็จจริง
  • เห็นด้วยว่ามันชวนไม่เข้าใจที่เอา AI มาใส่ rsync และก็เห็นด้วยด้วยว่าวิธีการแจ้ง issue นั้นน่ารังเกียจจริง ๆ
    แต่อยากเสี่ยงออกนอกประเด็นนิดหน่อยแล้วพูดความคิดนี้ขึ้นมา หากไม่นับว่าซอฟต์แวร์ที่โตเต็มที่อย่าง Rsync ไม่จำเป็นต้องมีความเคลื่อนไหวอย่างจำนวนบรรทัดโค้ดที่เปลี่ยนไป สมมติว่าผู้ดูแลกำลังบริหารโปรเจกต์ด้วยเจตนาที่ดีที่สุด
    ถ้าเรื่องนี้กำลังเกิดขึ้นในโอเพนซอร์ส แล้ว คุณภาพของซอฟต์แวร์ปิด จะอยู่ในสภาพไหน?
    การใช้ AI หรือก็คือปริมาณอินพุต ถูกนำไปใส่ในการประเมินพนักงานเหมือนเป็นตัวชี้วัดความสำเร็จ และผู้คนก็กำลังตื่นตระหนกเพราะภัยคุกคามจากการเลิกจ้างครั้งใหญ่ที่เกิดจาก AI
    น่าหวาดเสียวมาก
  • สิ่งที่ไม่เข้าใจจริง ๆ คือทั้งคุณทั้งฉันไม่รู้เลยว่าเขาใช้ Claude อย่างไร แต่กลับบอกว่าปล่อย AI ใส่ rsync
    https://github.com/RsyncProject/rsync/issues/929#issuecommen... แสดงให้เห็นเพียงว่ามันไม่ทำงานกับ Darwin รุ่นเก่าและ Linux < 5.6 อีกต่อไป ซึ่ง Linux 5.6 เป็นเวอร์ชันที่ถูกประกาศว่าจะเลิกใช้ตั้งแต่ปี 2020 แล้ว นอกจากนี้ก็มีบั๊กอื่นอีกเล็กน้อย
    จะไปคาดหวังว่าผู้ดูแลจะรองรับระบบเก่าและรู้ผลกระทบทั้งหมดของการเปลี่ยนแปลงได้ก็ไม่ได้ ไม่ว่าจะทำด้วย AI หรือทำด้วยมือก็ตาม

• อนึ่ง บั๊กนั้นเองถูกใส่เข้ามาใน 30656c5e ที่ Claude Code สร้างขึ้น และดูเหมือนน่าจะมีทั้งการรีวิวและการทดสอบโดยคนที่ไม่เหมาะสมร่วมอยู่ด้วย
  https://github.com/RsyncProject/rsync/commit/30656c5e
  มีคนใช้ AI เพื่อไล่ bisect rsync ช่วงหลังมานี้: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
  มีคนพยายามจะแก้ด้วย Claude Code เพิ่มเติม: https://github.com/RsyncProject/rsync/pull/930
  ทิกเก็ตที่เกี่ยวข้อง: https://github.com/RsyncProject/rsync/issues/915
  ขอแนะนำให้เพิ่ม regression test ใน commit ก่อนหน้า 30656c5e แล้ว rebase เดินหน้าต่อไปโดยยังคงฟังก์ชันการทำงานเดิมไว้

  • ถ้าอย่างนั้นข้อร้องเรียนตั้งต้นก็ดูเหมือนจะผิดไปเฉย ๆ
    นี่ไม่ใช่ “ฟีเจอร์ใหม่ที่ไม่มีใครต้องการ” Tridge กำลังแก้ ปัญหาด้านความปลอดภัย ที่เกี่ยวข้องกับรายงานบั๊กอยู่ ซึ่งก็เข้าใจได้ ทุกคนต่างโดนปัญหาความปลอดภัยเล่นงานกันอยู่ การแก้ไขมันไม่ใช่เรื่องเลือกได้
    จะบอกว่างานนี้สนุกก็คงไม่ได้ เพราะต้องย้อนกลับไปจัดการกับซอฟต์แวร์อายุ 10 ปี และเพราะอย่างนั้นจึงน่าประทับใจที่ tridge ยังพยายามอยู่
    ฉันเองก็มีความผิดที่ใช้ LLM เพื่อผ่านความยุ่งเหยิงแบบนี้ไปให้ได้ ฉันไม่รู้ว่า tridge ทำอะไรอยู่ แต่ฉันตรวจทุกบรรทัดของโค้ดที่ LLM พ่นออกมา ถึงอย่างนั้นความเสี่ยงที่บั๊กจะเล็ดรอดเข้ามาก็ยังสูงชัดเจน
    ฉันไม่ได้ดูโค้ดนั้นมานานแล้ว และก็ไม่คุ้นเคยกับมันเท่าเมื่อก่อน ดังนั้นการมีบั๊กรั่วเข้ามาจึงไม่ใช่เรื่องน่าแปลกใจมาก
    สิ่งที่แปลกในดราม่าครั้งนี้คือคนที่ร้องเรียนตั้งต้นดูจะปกป้องระบบแบ็กอัพของตัวเองอย่างมาก แต่ commit ของ tridge เพิ่งเกิดขึ้นเมื่อ 2 สัปดาห์ก่อนเท่านั้น เราก็รู้ว่า tridge เก่งมาก แต่เรื่องแบบนี้ไม่ควรถูกปฏิบัติเหมือนซอฟต์แวร์อัลฟาโดยธรรมชาติหรือ? เขาคิดอะไรอยู่กันแน่? คนนั้นอาจต้องเรียนรู้เพิ่มอีกนิดว่าเขาสร้างระบบที่เชื่อถือได้อย่างไร

• ถ้าเป็นเมื่อไม่กี่ปีก่อน บทความแนวนี้แทบจะไม่มีทางขึ้นหน้าแรกของ Hacker News เลย โดยไม่เกี่ยวกับว่าเนื้อหาถูกหรือผิด เพราะที่นี่ไม่ได้เต็มไปด้วยคนทั่วไปที่ไม่เข้าใจว่าพฤติกรรมแบบไหนเป็นสิ่งที่ยอมรับไม่ได้
  สิ่งที่พูดถึงตรงนี้คือ ภาษาที่รุนแรง ของ issue นั้น แต่ตอนนี้เรากลับถูกห้อมล้อมด้วยคนที่แยกแยะสิ่งพื้นฐานที่สุดยังไม่ได้

  • การเปิด issue ชื่อ “Please Do Not Vibe Fuck Up This Software” โดยอ้างอิงแค่ภาพแคปหน้าจอจากบริการคล้าย Twitter กับ “คนที่ไม่รู้ว่าเป็นใคร” ที่บอกว่าพบบั๊กนั้น ไม่เหมาะสมเลยแม้แต่น้อย
    นี่ไม่ใช่วิธีบอกผู้ดูแลโครงการว่าคุณไม่เห็นด้วยกับทิศทางของโครงการ issue นี้ไร้ประโยชน์โดยสิ้นเชิง ถ้าจะให้ดีกว่า อย่างน้อยก็ควรเป็นรายงานบั๊กว่า “พังเพราะ vibe coded”
    ประเด็นนี้แทงใจดำเลย ไม่มีรายงานบั๊กฉบับไหนพยายามแม้แต่จะบันทึก regression ของ --compare-dest= ที่ถูกอ้างถึง ลองกด Ctrl-F ดูก็ไม่เห็นมีใครพูดถึง “compare-dest” อีกเลย
    คนที่คอมเมนต์โกรธ AI แบบไร้ประโยชน์พวกนั้น น่าจะสั่งให้ Opus 4.8 รัน rsync 3.4.3 กับ 3.4.1 เพื่อบันทึก regression อย่างละเอียด แล้วหา commit ที่ทำให้พังด้วย git bisect เพื่อทำรายงานบั๊กที่เป็นมืออาชีพและมีประโยชน์กว่านี้ 1000 เท่าได้ด้วยซ้ำ
    ถ้าสังคมอยากให้คุณค่างานของมนุษย์มากกว่างานของ AI ก็ควรหลีกเลี่ยงพฤติกรรมโง่ ๆ ที่มีแต่มนุษย์เท่านั้นที่ทำได้
  • คำดูถูกอย่าง “normies” ก็พูดได้แบบเดียวกัน
    ที่มันขึ้นหน้าแรก อาจเป็นเพราะคนอื่น ๆ ก็รู้สึกคล้ายกันกับซอฟต์แวร์ที่พวกเขาใช้ทุกวันในงานสำคัญไม่ใช่หรือ?
    จริงอยู่ที่ GitHub issue เป็นงานจำเจและแทบไม่มีใครขอบคุณ แต่ในความเป็นจริง rsync เป็นรากฐานของ pipeline ที่อ่อนไหวจำนวนมาก
  • การเรียก issue นั้นว่า “รุนแรง” ฟังดูแปลกนิดหน่อย อ่านไปสักหน่อยก็ชัดแล้วว่ามันเป็นเรื่องใหญ่ และไม่มีใครที่เกี่ยวข้องมีความเหนือกว่าทางศีลธรรม
    ถ้าคุณเชื่อจริง ๆ ว่ามันนอกประเด็น การตอบสนองที่สุภาพก็คือปิด issue นั้น
    ผมยังไม่ค่อยเข้าใจว่าอะไรที่ว่า “ชัดเจน” นัก สำหรับผม “หยุดซะ คุณไม่รู้อะไรเลย คุณส่งมอบฟีเจอร์ด้วยมือมาแล้วศูนย์อย่าง และไม่มีใครพึ่งพาโค้ดของคุณ” ดูรุนแรงกว่า “please do not vibe fuckup this software” มาก
  • บางทีผมอาจกลายเป็นคนมองโลกในแง่ร้ายเกินไปแล้วก็ได้ คอมเมนต์ใน HN และ GitHub issue จำนวนมากขึ้นเรื่อย ๆ ให้ความรู้สึกเหมือน บอต ที่ถูกสร้างมาเพื่อยั่วให้คนอื่นโกรธ รวมถึงผู้ดูแลโครงการด้วย
  • ผมชอบที่คอมเมนต์นี้คลุมเครือพอที่จะใช้ได้กับทั้งสองฝ่าย :)

• ในเธรด issue นั้น มีใครอธิบาย issue จริง ๆ บ้างไหม? อย่างเช่นขั้นตอนการทำซ้ำ พฤติกรรมที่คาดหวังกับพฤติกรรมที่เกิดขึ้นจริง
  นี่ถูกโพสต์ลงในตัวติดตาม issue นะ “มีการพูดถึง Claude ใน commit message และมีใครสักคนบน Bluesky คิดว่าปัญหาที่ไม่ระบุชัดที่ตัวเองเจอเกี่ยวข้องกับ commit พวกนั้น” ไม่ใช่ issue ที่นำไปดำเนินการต่อได้
  ต่อให้ตัดประเด็นอื่นทั้งหมดทิ้ง ถ้าเป็นโครงการของผม ผมก็คงปิดและล็อกมันด้วยเหตุผลว่า “ข้อมูลสำหรับทำซ้ำไม่เพียงพอ” การถกเถียงทั่วไปเรื่อง AI, fork, และการระบายความโกรธมีที่ที่เหมาะสมกว่านี้

  • issue ที่แท้จริงน่าจะประมาณนี้
    ผู้ใช้ Linux < 5.6 ไม่สามารถ build จาก GitHub ได้ สำหรับผมมันดูเป็น regression เล็กน้อยมาก คนที่ใช้รุ่นบำรุงรักษาของ 5.6 ซึ่งส่วนใหญ่เป็นรุ่นความปลอดภัยแบบขยายเวลา น่าจะมีผู้ดูแลดิสโทรของตนตรวจพบบิลด์ล้มเหลวและแก้ได้ทันเวลา
    การทำ hardening ต่อการโจมตีแบบ path traversal ทำให้ผู้ใช้ที่ใช้ native rsync protocol โดยไม่มี chroot เกิดความล้มเหลว ซึ่งก็น่าขันดีเพราะ chroot = no ไม่ได้เป็นสิ่งที่แนะนำอย่างจริงจังอยู่แล้ว
    ถ้าคุณใช้ native rsync แบบอัตโนมัติ คุณอาจไม่ควรใช้เลยด้วยซ้ำ และผมอาจถึงขั้นแนะนำว่าอย่าใช้มันเลย CVE ที่ commit นั้นแก้ไขอยู่ก็ตรงกับกรณีใช้งานนี้พอดี
    https://www.cve.org/CVERecord?id=CVE-2026-29518
    มันต้องเป็น daemon + no chroot ด้วย “daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.”
    ดังนั้น workflow ที่ได้รับผลกระทบคือ workflow ที่เปราะบางที่สุดอยู่แล้ว แต่ผู้คนกลับกำลังแนะนำให้ย้อนเวอร์ชัน
    อีกอย่าง ถ้า regression test ควรจับสิ่งนี้ได้ ก็หมายความว่า test นั้นควรถูกเขียนไว้ก่อนหน้านี้แล้ว

• ดูเหมือนบางคนจะลืมไปว่าโปรเจ็กต์ FOSS เป็นอย่างไร
  “15. การปฏิเสธการรับประกัน
  เท่าที่กฎหมายที่เกี่ยวข้องอนุญาต โปรแกรมนี้ไม่มีการรับประกันใด ๆ เว้นแต่จะระบุเป็นลายลักษณ์อักษรไว้เป็นอย่างอื่น เจ้าของลิขสิทธิ์และ/หรือคู่สัญญาอื่นให้โปรแกรมนี้ ‘ตามสภาพที่เป็นอยู่’ โดยไม่มีการรับประกันใด ๆ ไม่ว่าโดยชัดแจ้งหรือโดยนัย ซึ่งรวมถึงแต่ไม่จำกัดเพียงการรับประกันโดยนัยเรื่องความสามารถในการซื้อขายหรือความเหมาะสมสำหรับวัตถุประสงค์เฉพาะ ความเสี่ยงทั้งหมดเกี่ยวกับคุณภาพและประสิทธิภาพของโปรแกรมตกอยู่กับคุณ หากโปรแกรมมีข้อบกพร่อง คุณเป็นผู้รับภาระค่าใช้จ่ายทั้งหมดของการบริการ ซ่อมแซม หรือแก้ไขที่จำเป็น”

  • และนี่คือ ข้อยกเว้นความรับผิดของผู้ใช้ OSS ด้วย
    ข้าพเจ้าขอสงวนสิทธิ์ในการบ่น พูดกระปอดกระแปด วิจารณ์ โกรธ หรือแสดงความคิดเห็นอื่นใดต่อทุกการตัดสินใจ commit patch การตลาด และการตัดสินใจอื่น ๆ ที่โครงการทำ ความคิดเห็นดังกล่าวไม่มีการรับประกันความเหมาะสมสำหรับวัตถุประสงค์ใด ๆ และไม่รวมถึงการรับประกันโดยนัยว่าเป็นสิ่งที่ถูกต้อง มีประโยชน์ หรือมีน้ำใจ หากความคิดเห็นของข้าพเจ้าถูกพบว่าไม่เป็นที่ต้องการ ท่านขอสงวนสิทธิ์ที่จะเอามันไปยัดไว้ในที่ที่แสงแดดส่องไม่ถึง
    คุณอาจจะพิมพ์ข้อยกเว้นความรับผิดนี้ไว้ใช้อ้างอิงเมื่อเจอคำวิจารณ์โปรเจ็กต์ FOSS ที่ไม่พึงประสงค์ก็ได้
    ผมไม่เข้าใจว่าทำไมผู้คนถึงไม่เข้าใจว่าท่าทีแบบ “พวกเขามีสิทธิ์ทำตามที่ต้องการ” มันใช้ได้ทั้งสองทาง ผู้ใช้ก็ทำในสิ่งที่ต้องการได้เหมือนกัน ถ้าไม่ชอบก็แสดงออกได้
  • ตามกฎหมายก็จริงที่ทำแบบนั้นได้ แต่ถ้าทำ คุณก็เป็นแค่คนแย่ ๆ คนหนึ่ง
    คอมเมนต์หนึ่งใน issue นั้นพูดไว้แบบนี้
    “การที่คุณแจกซุปฟรีให้คนไร้บ้าน ไม่ได้แปลว่าคุณควรฉี่ใส่มัน”
  • “ไม่มีการรับประกัน” ไม่ได้แปลว่า “ห้ามบ่น” ไม่อย่างนั้นก็คงไม่มีเหตุผลที่จะมีตัวติดตาม issue หรือส่วน discussion
    issue นั้นเละเทะไปแล้ว และประเด็นของคุณก็ถูกพูดไปแล้วในนั้น ทุกคนคงจัดการเรื่องนี้ได้ดีกว่านี้ แต่การยกถ้อยคำทางกฎหมายมาอ้างแบบท่องจำไม่ได้ช่วยแก้หรือทำให้อะไรดีขึ้น

• อ่านโพสต์ HN เรื่องนี้เป็นครั้งที่สามแล้ว ทุกครั้งก็มีแต่ทวีตเดิม ๆ หรือโพสต์นั้นจากพวก Mastodon/Bluesky อะไรทำนองนั้นถูกเอามาวนซ้ำ มีใครลอง ดีบัก ปัญหาจริง ๆ บ้างไหม?
  ต้นเหตุมาจากโค้ดที่สร้างแบบลวก ๆ หรือเป็นการแก้ไขด้านความปลอดภัยจริง ๆ ที่ดันทำพังโดยบังเอิญกันแน่? ในแบบที่มนุษย์ก็อาจทำพลาดแบบเดียวกันได้ด้วยน่ะ

  • มีลิสต์บางส่วนอยู่ที่ https://github.com/RsyncProject/rsync/issues/929#issuecommen...

• อาการฮิสทีเรียต้าน AI นี้เป็น moral panic แบบคลาสสิก

  1. ระบุอะไรสักอย่างว่า AI เป็นคนทำ
  2. โจมตีและกีดกันคนที่อาจเกี่ยวข้องกับการสร้างมัน
     เหมือน moral panic ทุกครั้ง ข้อ 1 จะจริงหรือไม่เป็นเรื่องรองไปเลย ประเด็นหลักคือการได้ความสะใจแทบจะในเชิงทางเพศจากข้อ 2
     ในกรณีนี้ ผมรู้อยู่ว่า rsync มีโค้ดที่ AI สร้างอยู่ เหมือนซอฟต์แวร์ที่มีประโยชน์ส่วนใหญ่ในทุกวันนี้นั่นแหละ แต่บนอินเทอร์เน็ตคุณจะเห็น การล่าแม่มด ทุกวัน และเหมือนการล่าแม่มดทุกครั้ง ความจริงของคำกล่าวหาแทบไม่สำคัญเลย ตัวฮิสทีเรียนั่นเองคือเป้าหมาย
  • การปฏิเสธไม่ยอมเข้าใจว่าในภาพกว้างกำลังเกิดอะไรขึ้น และในเธรดนี้กำลังเกิดอะไรขึ้น พร้อมทั้งส่งสัญญาณต่อไปว่าไม่จำเป็นต้องเข้าใจ เป็นเรื่องอันตราย
    ความโกรธที่เกิดขึ้นรอบ ๆ AI ไม่ได้มาจากการที่สาธารณะเข้าใจผิดหรือสื่อสารผิดพลาด แต่มาจาก ความเป็นจริงทางกายภาพ
    สิ่งนี้อย่างเดียวถูกใช้เป็นข้ออ้างสำหรับการปลดคนจำนวนมาก เหล่า CEO สายเทคก็พูดแทบทุกวันว่าต้องการแย่งงานของคนอื่นทั้งหมดด้วย และบริษัทยักษ์ใหญ่คลาวด์ก็กำลังดูดเอาออกซิเจนทั้งหมดในห้องไป แม้แต่วงการเกมก็ยังไม่รอด
    การมองสิ่งนี้ว่า “ก็แค่ moral panic ตามสูตร” ก็เหมือนเห็นทะเลกำลังร่นไปทางไหนแล้วดันวิ่งตรงเข้าไปทางนั้น
  • พอเห็นการคิดแบบหลวม ๆ อย่าง “ประเด็นหลักคือการได้ความสะใจแทบจะในเชิงทางเพศจากข้อ 2” ก็ยากจะรับคำตอบนี้อย่างจริงจัง
    อ่านต่อไปก็เห็นว่าคุณเองก็ใช้ภาษาปลุกอารมณ์อย่าง “การล่าแม่มด”, “ฮิสทีเรีย” เหมือนกัน
    นี่คือการล่าแม่มดจริง ๆ หรือ? แล้วคุณจะรู้ได้อย่างไรว่าคนอีกฝั่งของอินเทอร์เน็ตกำลังเข้าใกล้ความปลดปล่อยทางเพศ?
    คุณเองก็กำลังตอบสนองต่อภาษาทางอารมณ์และการคิดแบบหลวม ๆ ของคนอื่นด้วยวิธีแบบเดียวกันอยู่หรือเปล่า?

• ตั้งแต่เมื่อไร GitHub Issues กลายเป็นที่สำหรับโพสต์สกรีนช็อตของโพสต์จากแพลตฟอร์มอื่น?
  ผมเคยเห็นพฤติกรรมแบบนี้ก็แต่ในที่ที่เอาไว้โพสต์มีมหรือคอนเทนต์เอาฮา
  ไม่มีรายงานบั๊กที่นำไปลงมือทำได้หรือคำขอฟีเจอร์เลย ไม่มีแม้แต่เวอร์ชันข้อความ ไม่มีลิงก์ไปยังโพสต์ต้นฉบับด้วยซ้ำ
  คนที่โพสต์นี่คิดว่า GitHub Issues เป็นบัญชี Twitter ส่วนตัวของตัวเองหรือไง?

  • การโพสต์สกรีนช็อตเป็นวิธีที่ง่ายกว่าในการกันคำตอบอัตโนมัติจาก LLM เพราะส่วนใหญ่ใช้โมเดลข้อความที่ไม่มี vision ซึ่งต้นทุนถูกกว่า