Turso ยุติโปรแกรมบั๊กบาวน์ตี

 (turso.tech)
2 คะแนน โดย GN⁺ 2026-05-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Turso ดำเนินโครงการบั๊กบาวน์ตีที่จ่าย 1,000 ดอลลาร์ สำหรับบั๊กที่พิสูจน์ได้ว่านำไปสู่ความเสียหายของข้อมูลมาเกือบ 1 ปี ก่อนจะยุติโครงการ
  • เมื่อมีเงินรางวัลเข้ามา ก็มี PR คุณภาพต่ำที่สร้างด้วย AI หลั่งไหลเข้ามาจำนวนมาก ทำให้ผู้ดูแลต้องใช้เวลาหลายวันไปกับการปิด PR เหล่านี้
  • ช่วงแรกมีผู้ได้รับรางวัล 5 คน และบางส่วนของผลงานนำไปสู่การปรับปรุงซิมูเลเตอร์และการค้นพบบั๊กใน SQLite มากกว่า 10 รายการ
  • Turso ใช้ ระบบรับรอง เพื่อปิด PR ที่น่าสงสัยโดยอัตโนมัติ แต่บอตก็ยังคงเปิด issue ขอให้ตรวจสอบด้วยตนเองและส่ง PR ที่คล้ายเดิมกลับมาอีก
  • เพื่อคงการมีส่วนร่วมแบบเปิดไว้ Turso เลือก ตัดแรงจูงใจทางการเงิน แทนที่จะปิดระบบ

ทำไม Turso ถึงหยุดบั๊กบาวน์ตี

  • Turso จ่าย 1,000 ดอลลาร์สำหรับบั๊กที่พิสูจน์ได้ว่าอาจนำไปสู่ข้อมูลเสียหาย มาเกือบ 1 ปี แต่ตอนนี้ยุติโครงการแล้ว
  • หลังมีรางวัลเป็นตัวเงิน รีโพซิทอรีของ Turso ก็เต็มไปด้วย PR คุณภาพต่ำที่สร้างโดย AI จนผู้ดูแลต้องใช้เวลาหลายวันไปกับการปิด PR เหล่านี้เป็นส่วนใหญ่
  • Turso ต้องการคงสถานะเป็นโครงการที่เปิดรับการมีส่วนร่วม แต่เห็นว่าโครงสร้างที่จ่ายเงินสำหรับบั๊กบางประเภททำให้การดูแลการมีส่วนร่วมแบบเปิดแทบเป็นไปไม่ได้
  • การตัดสินใจครั้งนี้ถูกเปิดเผยพร้อมกับการยอมรับว่าเราทุกคนต้องเรียนรู้ร่วมกันว่าจะวางธรรมาภิบาลโอเพ่นซอร์สอย่างไรในยุคใหม่

ที่มาของการเริ่มโครงการ

  • Turso กำลัง นำ SQLite มาสร้างใหม่ ซึ่ง SQLite ได้ชื่อว่าเป็นหนึ่งในซอฟต์แวร์ที่เชื่อถือได้มากที่สุดในโลก จึงต้องมีมาตรฐานด้านความน่าเชื่อถือที่สูงมากเช่นกัน
  • Turso ใช้ระบบทดสอบหลายรูปแบบเพื่อให้ได้หรือเกินระดับความน่าเชื่อถือของ SQLite
    • deterministic simulator แบบเนทีฟ
    • fuzzer หลายตัว
    • oracle-based differential testing engine ที่เปรียบเทียบกับ SQLite
    • ตัวจำลองภาวะพร้อมกัน
    • การรันอย่างกว้างขวางบน Antithesis
  • อย่างไรก็ดี โครงสร้างพื้นฐานการทดสอบก็ยังเป็นซอฟต์แวร์ จึงไม่สมบูรณ์แบบ และจับบั๊กได้เฉพาะในชุดการผสมที่ตัวสร้างสร้างขึ้นจริงเท่านั้น
  • ตัวอย่างเช่น ถ้า fuzzer ไม่สร้างดัชนี ก็ยากที่จะพบบั๊กที่เกี่ยวกับ ดัชนี ต่อให้จะกดดันส่วนอื่นของระบบอย่างหนักก็ตาม
  • Turso เคยพบบั๊กที่ แสดงอาการเฉพาะเมื่อฐานข้อมูลมีขนาดเกิน 1GB แต่เพราะมีการฉีดความล้มเหลวอย่างเข้มข้นในทุกการรัน ทำให้ฐานข้อมูลไม่โตถึงขนาดนั้นและบั๊กจึงเล็ดรอดจากซิมูเลเตอร์ไปได้
  • ข้อดีของการทดสอบอัตโนมัติคือ แม้บั๊กจะเล็ดรอดไปครั้งหนึ่ง แต่หากปรับปรุงตัวสร้างการทดสอบ ก็สามารถกำจัด บั๊กได้ทั้งหมวดหมู่
  • บั๊กบาวน์ตีเป็นกลไกที่แสดงความมั่นใจของ Turso ต่อระเบียบวิธีการทดสอบของตน ขณะเดียวกันก็ใช้เป็นรางวัลหากมีใครพบจุดที่ซิมูเลเตอร์ครอบคลุมได้ไม่ดี
  • แผนเดิมคือจะจ่าย 1,000 ดอลลาร์สำหรับบั๊กข้อมูลเสียหายจนกว่าจะเปิดตัว Turso 1.0 และหลังจาก 1.0 แล้วจะค่อย ๆ เพิ่มทั้งจำนวนรางวัลและขอบเขตของสิ่งที่ครอบคลุม

ผลลัพธ์ก่อนที่งานส่งคุณภาพต่ำจาก AI จะเพิ่มขึ้น

  • ช่วงแรกของโครงการมีผู้ได้รับรางวัลรวม 5 คน และบุคคลเหล่านี้มีส่วนช่วยโครงการอย่างมีนัยสำคัญ
  • Alperen เป็นหนึ่งในผู้มีส่วนร่วมหลักของซิมูเลเตอร์ Turso และรู้ว่าจุดไหนยังปรับปรุงได้
  • Mikael ใช้ LLM อย่างสร้างสรรค์เพื่อหาจุดที่ซิมูเลเตอร์ไปไม่ถึง และต่อมาก็เข้าร่วมงานกับ Turso
  • Pavan Nambi ผสานซิมูเลเตอร์เข้ากับเทคนิคเชิงรูปแบบ จนพบบั๊กไม่เพียงใน Turso แต่ยังรวมถึง บั๊กมากกว่า 10 รายการ ใน SQLite เองด้วย

ภาระด้านการปฏิบัติการที่เกิดจากงานส่งที่สร้างด้วย AI

  • มาตรฐานงานส่งที่ Turso ต้องการไม่ใช่แค่การชี้ว่ามีบั๊ก แต่คือ การขยายซิมูเลเตอร์เพื่อพิสูจน์บั๊กข้อมูลเสียหาย
  • เงื่อนไขนี้ทำให้ PR แย่ ๆ ที่หวังเงินรางวัลมีไม่มาก และบั๊กข้อมูลเสียหายจริงก็ไม่ได้มีมากนัก
  • ต่อมามีงานส่งจำนวนมากที่สั่งให้ LLM ไปหาบั๊กใน Turso แล้วรับรางวัล
  • เมื่อได้รับคำสั่งเช่นนั้น LLM ก็สร้างผลลัพธ์บางอย่างออกมาได้เสมอ แต่คำถามคือผลลัพธ์นั้นใช้ได้จริงหรือไม่

ตัวอย่างงานส่งคุณภาพต่ำที่เด่นชัด

  • PR ที่ทำให้ส่วนหัวฐานข้อมูลเสียหายด้วยมือ

    • PR #6257 อัดไบต์ขยะเข้าไปในส่วนหัวฐานข้อมูลด้วยมือ แล้วอ้างว่าฐานข้อมูลเกิดความเสียหาย
    • แม้ผู้ดูแลจะชี้ว่านี่เป็นผลลัพธ์ที่แน่นอนอยู่แล้ว ผู้ส่งหรือบอตก็ยังโต้แย้งยืดยาวในสไตล์ LLM ต่อไป

  • งานส่งที่ใส่การเข้าถึง out-of-bound ลงในซอร์สโค้ดโดยตรง

    • อีกงานส่งหนึ่งเพิ่ม การเข้าถึงอาร์เรย์แบบ out-of-bound เข้าไปในซอร์สโค้ดด้วยมือเพื่อทำให้ฐานข้อมูลเสียหาย
    • issue ที่เกี่ยวข้อง: tursodatabase/turso#5508

  • PR ที่อ้างว่าการรัน SQL คือช่องโหว่

    • PR #4322 เต็มไปด้วยตาราง เครื่องหมายถูกสีเขียว และ em dash พร้อมอ้างว่าพบช่องโหว่ร้ายแรงที่อนุญาตให้รันคำสั่ง SQL ตามอำเภอใจ
    • Turso เห็นว่าการที่ฐานข้อมูล SQL อนุญาตให้รันคำสั่ง SQL นั้นไม่อาจถือเป็นช่องโหว่ได้ในตัวเอง

  • PR ที่เข้าใจฟีเจอร์ concurrent write ของ Turso ผิด

    • PR #6874 เปิดใช้ concurrent write ซึ่งเป็นหนึ่งในจุดต่างของ Turso แล้วแสดงให้เห็นว่า SQLite ไม่สามารถเปิดไฟล์ได้จนกว่าจะเปลี่ยน journal mode กลับไปเป็น WAL เพื่อปิด concurrent write
    • นี่เป็นผลลัพธ์ที่ระบบทำงานตามที่ออกแบบไว้

  • งานส่งที่ยากจะเข้าใจเจตนา

    • อีกงานส่งหนึ่ง เป็นเนื้อหาที่เข้าใจได้ยากว่าต้องการทำอะไร
    • ผู้ดูแล Mikael ประเมินว่าผู้ส่งน่าจะเห็นประกาศเงินรางวัลแล้วนำเครื่องมือสร้างด้วย AI มาเล็งที่ Turso

มาตรการสุดท้าย: ระบบรับรอง

  • Turso ออกแบบและพัฒนา ระบบรับรอง (vouching) เป็นความพยายามครั้งสุดท้ายเพื่อจัดระเบียบ
  • ระบบนี้จะปิดงานส่งโดยอัตโนมัติหากสงสัยว่ามาจากบอต และในช่วงหนึ่งก็พอได้ผลอยู่บ้าง
  • หลังจากนั้น บอตก็เริ่มเปิด issue เพื่อขอให้มีการตรวจสอบด้วยตนเอง โดยอ้างเหตุผลที่ PR ถูกปิด
  • หลายครั้งเมื่อปิด PR ไปแล้ว ก็มีการเปิด PR เดิมหรือใกล้เคียงเดิมอีกครั้งทันที ไม่ว่าจะโดยผู้ใช้คนเดิมหรือคนอื่น

ความขัดแย้งระหว่างการมีส่วนร่วมแบบเปิดกับแรงจูงใจทางการเงิน

  • ฝั่งที่สร้างงานส่งคุณภาพต่ำใช้เวลาเพียงประมาณ 1 นาทีในการสร้างงานส่ง แต่ Turso ต้องใช้เวลา หลายชั่วโมง ในการอ่าน ทำความเข้าใจ และตอบสนอง
  • งานส่งแบบนี้สามารถถูกสร้างได้ด้วยความเร็วที่แทบไม่จำกัด
  • แม้จะสร้างระบบคัดกรองอัตโนมัติได้ แต่เมื่อมีเงินรางวัลที่มองข้ามไม่ได้ AI ก็ยิ่งมีแรงจูงใจที่จะโต้เถียงต่อและเปิด PR เดิมซ้ำ
  • Turso ให้ความสำคัญกับชุมชนผู้มีส่วนร่วมโอเพ่นซอร์สและจะยังคงเสริมความแข็งแกร่งต่อไป แต่ในตอนนี้เห็นว่า แรงจูงใจทางการเงินทุกรูปแบบในระบบเปิดทำงานได้ไม่ดี
  • ตัวเลือกมีทั้งปิดระบบหรือเอาแรงจูงใจออก และ Turso เลือกอย่างหลังในตอนนี้

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

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

 
GN⁺ 2026-05-17
ความคิดเห็นจาก Hacker News

  • เรื่องคอขวดไม่ได้อยู่ที่ การเขียนโค้ด แต่อยู่ที่การอ่านและทำความเข้าใจโค้ด
    เมื่อก่อนก็มีแทบทุกทีมที่มีวิศวกร “สายผลิต” อยู่สักคน ชอบส่ง PR ก้อนมหึมาที่ปนการรีแฟกเตอร์ครั้งใหญ่เข้าไป ไม่ว่าจะจำเป็นหรือไม่ก็ตาม เรื่องแบบนี้มีมาตั้งแต่ก่อนยุคที่ใครจะจินตนาการได้ว่าโครงข่ายประสาทจะสร้างโค้ดได้มากขนาดนี้
    ผลของ “ประสิทธิภาพ” แบบนั้นไม่ใช่การทำให้ทีมเร็วขึ้น แต่เกือบจะทำให้หยุดนิ่งไปเลย ทีมต้องใช้เวลาหมดไปกับการรีวิว PR อย่างละเอียด หรือไม่ก็ LGTM แบบผ่านๆ แล้วสุดท้ายพังในโปรดักชันจนทุกคนต้องกลับไปที่กระดานออกแบบใหม่ แถมเพราะ “ประสิทธิภาพ” ของคนนั้น โครงสร้างโปรเจ็กต์ก็เปลี่ยนเร็วเกินไป จนคนที่รู้ชัดจริงๆ ว่าอะไรอยู่ตรงไหนเหลือแค่คนเดียว คือคนที่ “ฉลาดมาก มีพรสวรรค์ มีประสิทธิภาพ และภักดีต่อเป้าหมายบริษัท” คนนั้นเอง

    • นี่ทำให้นึกถึงกรณีของ tactical tornado ในหนังสือ A Philosophy of Software Design ของ John Ousterhout มีข้อความตอนหนึ่งว่า
      “แทบทุกองค์กรพัฒนาซอฟต์แวร์จะมีนักพัฒนาอย่างน้อยหนึ่งคนที่ผลักการเขียนโปรแกรมเชิงยุทธวิธีไปจนสุดทาง นั่นคือ tactical tornado คนแบบนี้เป็นโปรแกรมเมอร์สายผลิตที่เขียนโค้ดได้เร็วกว่าคนอื่นมาก แต่ทำงานแบบ tactical ล้วนๆ หากต้องทำฟีเจอร์ด่วนสักอย่าง ไม่มีใครเร็วกว่าเขา ในบางองค์กร ผู้บริหารปฏิบัติต่อ tactical tornado ราวกับเป็นฮีโร่ แต่ tactical tornado จะทิ้งร่องรอยแห่งการทำลายล้างไว้ วิศวกรที่ต้องมาทำงานกับโค้ดนั้นภายหลังมักไม่ได้มองเขาเป็นฮีโร่ ส่วนใหญ่แล้ววิศวกรคนอื่นต้องคอยเก็บกวาดความยุ่งเหยิงที่ tactical tornado ทิ้งไว้ และเพราะเหตุนั้นฮีโร่ตัวจริงเหล่านั้นจึงดูเหมือนทำงานช้ากว่า tactical tornado”
    • เห็นด้วย 100% กับประโยคที่ว่า “คอขวดไม่ได้อยู่ที่การเขียนโค้ด แต่อยู่ที่ การอ่านและทำความเข้าใจโค้ด”
      และยิ่ง AI สร้างโค้ดมากขึ้น ก็จะยิ่งมีคนที่เข้าใจโค้ดนั้นจริงๆ น้อยลง
    • มี PR หนึ่งที่ผมเกือบเป็นคนแบบนั้นเอง โดยอาศัย ไลบรารีและเครื่องมือภายนอก ที่เราใช้อยู่แล้วให้คุ้มขึ้น ผมลบโค้ดในโค้ดเบสไปได้มากกว่า 20% แต่ก็ต้องเปลี่ยนให้แทบทุกจุดไปใช้ฟังก์ชันจากไลบรารีแทนฟังก์ชันที่เราสร้างเอง
      ถึงอย่างนั้น ถ้ามี regression test และ linter ที่ดีพอจนมั่นใจได้ว่าโค้ดยังทำงานและไม่ได้แย่มาก การรีวิวก็ควรดูคุณภาพระดับสูงโดยรวม มากกว่าจะขุดความถูกต้องทีละตัวอักษร แน่นอนว่าการรีวิวก็ยังเจ็บปวดอยู่ดี
    • ตลอดอาชีพผมอยากทำ โปรเจ็กต์แบบ greenfield แต่ในความเป็นจริงกลับทำงานกับโค้ดเบสที่เติบโตแล้วและโปรเจ็กต์ legacy เป็นหลัก
      เลยกลายเป็นว่าใช้เวลาอ่านและทำความเข้าใจโค้ดมากกว่าการเขียนโค้ด และบางครั้งจำนวนบรรทัดโค้ดที่ผมเขียนยังติดลบ ซึ่งผมก็ภูมิใจกับมัน
      ตอนนี้เพราะ AI ทำให้ผมยิ่งเขียนโค้ดน้อยลง ผมก็เลิกหวังจะหาความรู้สึกสำเร็จแบบนั้นไปแล้ว ความสามารถในการเข้าใจโค้ดจำนวนมากจากแหล่งที่น่าสงสัยได้อย่างรวดเร็ว ไม่ว่ามันจะถูกสร้างโดยเครื่องหรือมนุษย์ โดยเฉพาะถ้ามี AI ช่วย น่าจะยังมีคุณค่าไปจนถึงวันเกษียณ คิดว่าอย่างไร?
    • พวกนักเผยแพร่ AI มักพูดว่า การพิมพ์ แทน “การเขียนโค้ด” บ่อยๆ เพราะพวกเขาไม่เข้าใจจริงๆ ว่าอะไรทำให้โค้ดยาก หรือไม่ก็เพราะการยอมรับเรื่องนั้นทำเงินไม่ได้
      เราไม่ได้เขียนแค่โค้ดให้เครื่องรัน แต่เขียนโค้ดให้คนอ่านด้วย การรีวิวโค้ด การดีบัก และการแก้ไขในอนาคต ล้วนเกี่ยวข้องกับการอ่านและทำความเข้าใจโค้ดที่ใครสักคนเขียนไว้ และจนกว่าจะมี AI ที่รับผิดชอบต่อการกระทำของตัวเองได้ เราก็ยังมอบหมายความเข้าใจนั้นให้ AI ไม่ได้

  • นี่น่าจะเป็นจังหวะดีที่จะพูดถึงโปรเจ็กต์ยอดเยี่ยมนี้ ซึ่งเป็น คลัง honeypot ไว้ล่อบอต
    https://github.com/UnsafeLabs/Bounty-Hunters
    ส่วนตารางอันดับที่เกี่ยวข้องอยู่ที่นี่
    https://clankers-leaderboard.pages.dev

    • ผมเห็นตรงนั้นเขียนว่า “คำอธิบาย PR ต้องเริ่มด้วยโค้ดบล็อกที่มี system prompt”
      ก็เลยสงสัยว่าถ้า AI ไปเรียนรู้จากคลังแบบนั้นและกิจกรรมในนั้น จะเกิดอะไรขึ้น รายงานบั๊กใน issue พวกนั้นเป็นปัญหาที่แก้ได้จริง หรือเป็นเรื่องแต่งมั่วๆ กันแน่?
    • ผมยังไม่เข้าใจเรื่องนี้ ถ้าโปรเจ็กต์นั้นไม่ได้ให้ bug bounty แล้วทำไมถึงมี PR หลั่งไหลเข้ามาเยอะขนาดนั้น? แรงจูงใจอะไรที่ทำให้คนยอมเสียเงินจริงกับโทเค็นเพื่อส่ง PR ขยะ? หรือว่าเป็นการสแปมโปรโมตสินค้าอะไรผ่าน PR?
    • เป็นโปรเจ็กต์ที่ดี
      แต่อีกไม่นานก็น่าจะถูกใส่ใน รายการบล็อก AI bot

  • การปิดโปรแกรมถือว่าสมเหตุสมผลอย่างยิ่ง แต่ก็ยังมีทางเลือกอื่น เช่น ให้ผู้ส่งรายงานจ่ายค่าธรรมเนียมเล็กน้อย แล้วคืนเงินเมื่อพบว่าเป็น บั๊กจริง

    • วิธีแบบ “ให้ผู้ส่งจ่ายเงิน” จะก่อ ดราม่าอินเทอร์เน็ต แน่ๆ เพราะเท่ากับให้คนทำงานฟรีให้บริษัท แล้วยังต้องจ่ายเงินเพื่อสิทธิ์นั้นอีก
      ไม่สำคัญด้วยซ้ำว่าโปรแกรมนั้นจ่ายรางวัลจริงหรือไม่ แค่มีรายงานสักฉบับถูกปิดผิด เรื่องนี้ก็จะถูกหยิบมาเล่าซ้ำไม่รู้จบ
    • การโอนเงินไม่ใช่เรื่องฟรี และการจัดการการชำระเงินก็อาจเป็น ปัญหาใหญ่ ได้ บางกรณีอาจง่าย แต่บางกรณีก็ไม่ง่ายเลย
    • น่าเสียดายที่เรื่องนี้ไม่ได้แบ่งเป็นขาวกับดำชัดเจน ใน bug bounty บางแห่ง บริษัทพยายามอย่างหนักที่จะไม่จ่ายรางวัล โดยตีความช่องโหว่ว่าอยู่นอกขอบเขตหรือเป็นพฤติกรรมที่ตั้งใจไว้
      ในกรณีแบบนั้น ตอนนี้ผู้ส่งก็เสียเวลาอยู่แล้ว และต่อไปก็อาจเสียเงินด้วย
      โดยเฉพาะกับบริษัทเล็กๆ ก่อนส่งรายงานไปก็ไม่มีทางรู้ได้เลยว่าบริษัทจะตอบสนองอย่างไร
    • วิธีนี้จะเพิ่ม ภาระงานธุรการ และยิ่งเพิ่มแรงจูงใจให้ผู้ส่งรายงานโต้เถียงไม่รู้จบว่าตัวเองถูก
    • ฟังดูเหมือน bug bounty ควร ขยาย simulator ให้ครอบคลุมประเภทบั๊กที่ผู้ใช้พบ
      อาจจะบังคับให้รันชุดทดสอบของ simulator ทั้งหมดก่อนส่งรายงานได้ไหม? มันน่าจะเป็นการตรวจสอบที่ดีว่าผู้ส่งไม่ได้ทำ simulator พัง และอาจได้ผลพลอยได้เป็นหลักฐานแบบ proof of work ด้วย แต่จะทำได้จริงไหมผมไม่ค่อยรู้ด้านความปลอดภัยเลยตอบไม่ได้

  • ผมพยายามมานานกว่าหนึ่งปีแล้วที่จะทำให้ TursoDB โหลดไฟล์เดี่ยวได้ แต่ไม่สำเร็จ: https://github.com/ClickHouse/ClickBench/issues/336

  • สงสัยว่าถ้า Hacktoberfest ยังแจกเสื้อยืดให้ทุกคนอยู่ ตอนนี้มันจะออกมาหน้าตาแบบไหน คงมี ฝ้าย ไม่พอใช้ทั้งโลก
    ผมคิดว่าภาระในการหยุดเรื่องนี้ไม่ควรตกกับเมนเทนเนอร์แต่ละคน และ GitHub กับ GitLab ควรหยุดบัญชีแบบนี้ตั้งแต่ก่อนจะไปถึงขั้นเปิด PR ได้ โดยแก่นแท้มันคือสแปม
    ลองดูผู้ใช้ที่สร้าง PR แรกที่บทความพูดถึง: https://github.com/Samuelsills บัญชีแบบนี้ไม่ควรได้เข้าใกล้การเปิด PR ในคลังยอดนิยมเลย

    • หมายความว่าบัญชีที่ไม่มีกิจกรรมเลยไม่ควรถูกปล่อยให้อยู่เฉยๆ แบบนั้นหรือ? หรือว่าอาจมีการใช้ อีกบัญชีหนึ่ง ร่วมกัน?

  • ผมไม่ค่อยรู้เรื่องสายนี้ อาจเป็นคำถามโง่ๆ แต่ถ้ากำหนดให้ตอนท้ายต้อง รันการทดสอบ simulator ทั้งหมด เพื่อยืนยันว่าการเปลี่ยนแปลงที่ส่งมาไม่ได้ทำให้ฟีเจอร์เดิมพัง แบบนั้นจะใช้เป็น proof of work ได้ไหม?

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

  • มีใครเคยใช้ Turso ใน โปรดักชัน ไหม? มันเป็น implementation ที่เข้ากันได้กับ SQLite ซึ่งเขียนใหม่ด้วย Rust มีฟีเจอร์เพิ่มอย่างรองรับหลายผู้เขียน และต่างจาก SQLite ตรงที่เปิดรับ contribution จากภายนอกด้วย
    ผมกำลังคิดจะลองใช้กับแอป Rust แบบฟูลสแต็ก เพราะทุกอย่างทำงานผ่าน cargo และไม่ต้องเอา SQLite มาต่างหาก

    • ถ้าจะใส่แทน SQLite ก็ถือว่าโอเค ตอนที่ผมลองเมื่อ 1–2 ปีก่อน เจอปัญหาเกี่ยวกับ libsql บน Windows พอสมควร แต่คิดว่าตอนนี้คงแก้ไปแล้ว
      Turso เองก็มีฐานข้อมูลแบบบริการพร้อม free plan ที่ใจกว้างมาก ซึ่งนั่นเป็นเหตุผลหลักที่ผมเคยใช้มัน
    • มีคนทำ implementation แบบหลายผู้เขียน เป็นโปรเจ็กต์ส่วนตัว รองรับโปรโตคอล sqlite3 และมีการล็อกที่ละเอียดกว่า
      https://x.com/doodlestein/status/2052910351474209258

  • ทำไมไม่สู้กลับด้วยวิธีเดียวกัน ปล่อย AI bot ของตัวเองออกมาเพื่อช่วยคัดกรอง PR ล่วงหน้า?

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

  • จากมุมมองคนนอก นี่เป็น ปัญหายาก ที่น่าสนใจ ในบรรดาคำขอจากบอตพวกนั้น จะมีสักกี่เอเจนต์ที่ใช้ Turso อยู่ในแบ็กเอนด์ของตัวเอง?