Turso, hata ödül programını sonlandırdı
(turso.tech)- Turso, veri bozulmasına yol açtığı kanıtlanan hatalar için 1.000 dolar ödediği hata ödül programını yaklaşık bir yıl yürüttükten sonra sonlandırdı
- Ödül konulmasının ardından çok sayıda yapay zeka tarafından üretilmiş düşük kaliteli PR akışı oldu ve bakımcılar günlerce bunları kapatmakla uğraştı
- İlk dönemde 5 kişiye ödül verildi ve bazı katkılar simülatörün iyileştirilmesine ve SQLite'ta 10'dan fazla hatanın bulunmasına yol açtı
- Turso, şüpheli PR'ları otomatik kapatmak için bir kefalet sistemi kullandı ancak botlar manuel inceleme talepleri ve benzer PR'ların yeniden gönderilmesini sürdürdü
- Turso, açık katkıları korumak için sistemi kapatmak yerine maddi teşviki kaldırmayı seçti
Turso neden hata ödülünü durdurdu?
- Turso, yaklaşık bir yıl boyunca veri bozulmasına yol açabileceği kanıtlanan hatalar için 1.000 dolar ödüyordu, ancak artık programı sonlandırıyor
- Maddi ödül eklendikten sonra Turso deposuna çok sayıda yapay zeka üretimi düşük kaliteli PR geldi ve bakımcılar zamanlarının büyük kısmını günlerce bu PR'ları kapatmaya harcamak zorunda kaldı
- Turso açık katkılara dayalı bir proje olarak kalmak istiyor, ancak belirli hata türleri için para ödemenin açık katkı operasyonlarını neredeyse imkansız hale getirdiğini düşünüyor
- Bu karar, yeni çağda açık kaynak yönetişiminin nasıl kurulacağını birlikte öğrenmemiz gerektiği farkındalığıyla paylaşıldı
Program neden başlatılmıştı?
- Turso, dünyanın en güvenilir yazılımlarından biri olarak bilinen SQLite'ı yeniden uyguluyor ve bu nedenle aynı derecede yüksek güvenilirlik standartlarına ihtiyaç duyuyor
- Turso, SQLite düzeyinde güvenilirliği yakalamak veya aşmak için çeşitli test sistemleri işletiyor
- Yerel deterministik simülatör
- Birden fazla fuzzer
- SQLite ile karşılaştırma yapan oracle tabanlı diferansiyel test motoru
- Eşzamanlılık simülatörü
- Antithesis üzerinde kapsamlı çalıştırmalar
- Ancak test altyapısı da sonuçta yazılımdır ve kusursuz değildir; yalnızca üreticinin gerçekten oluşturduğu kombinasyonlar içindeki hataları yakalayabilir
- Örneğin bir fuzzer indeks oluşturmuyorsa, sistemin diğer bölümlerini ne kadar yoğun zorlarsa zorlasın indeksle ilgili hataları bulmak zor olur
- Turso, yalnızca veritabanı 1 GB'tan büyük olduğunda ortaya çıkan bir hata buldu; ancak her çalıştırmada agresif biçimde arıza enjekte edildiği için veritabanı o boyuta ulaşamıyor ve simülatörden kaçıyordu
- İlgili içerik: Uyumlu sistemler yazmanın macerası
- Otomatik testlerin avantajı, bir kez kaçan bir hata için test üreticisi geliştirildiğinde bütün bir hata kategorisinin ortadan kaldırılabilmesidir
- Hata ödülü, Turso'nun test metodolojisine olan güvenini gösterirken aynı zamanda simülatörün iyi kapsayamadığı alanları biri bulursa onu ödüllendirmek için tasarlanmıştı
- İlk plan, Turso 1.0 çıkana kadar veri bozulması hataları için 1.000 dolar ödemek, 1.0 sonrasında ise ödül miktarını ve kapsamını kademeli olarak artırmaktı
Yapay zeka kaynaklı düşük kaliteli gönderiler artmadan önceki etkisi
- Programın ilk döneminde toplam 5 kişi ödül aldı ve bunlar projeye anlamlı katkılar sundu
- Alperen, Turso simülatörünün temel katkıcılarından biriydi ve geliştirilebilecek noktaları biliyordu
- Mikael, LLM'leri yaratıcı şekilde kullanarak simülatörün ulaşamadığı noktaları buldu ve daha sonra Turso'ya işe alındı
- Pavan Nambi, simülatörü biçimsel yöntemlerle birleştirerek yalnızca Turso hatalarını değil, SQLite'ın kendisinde de 10'dan fazla hatayı ortaya çıkardı
Yapay zeka üretimi gönderilerin yarattığı operasyonel yük
- Turso'nun beklediği gönderi standardı, yalnızca bir hatayı işaret etmek değil, simülatörü genişleterek veri bozulması hatasını kanıtlamaktı
- Bu koşul sayesinde ödülü hedefleyen kötü niyetli PR'lar nadirdi ve gerçek veri bozulması hataları da çok fazla değildi
- Daha sonra LLM'lere Turso'da hata bulup ödül kazanmalarını söyleyen çok sayıda gönderi gelmeye başladı
- LLM'ler böyle bir talimat aldıklarında bir şekilde çıktı üretiyordu, ancak bu çıktının geçerli olup olmaması ayrı bir konuydu
Tipik düşük kaliteli gönderiler
-
Veritabanı başlığını elle bozan PR
- PR #6257, veritabanı başlığına elle anlamsız baytlar enjekte ettikten sonra veritabanının bozulduğunu iddia ediyordu
- Bakımcı bunun beklenen sonuç olduğunu belirttikten sonra bile, gönderici ya da bot LLM tarzı uzun itirazlar yazmayı sürdürdü
-
Kaynak koda doğrudan sınır dışı erişim ekleyen gönderi
- Başka bir gönderide, veritabanını bozmak için kaynak koda elle out-of-bound dizi erişimi eklendi
- İlgili konu: tursodatabase/turso#5508
-
SQL çalıştırmayı güvenlik açığı sayan PR
- PR #4322, tablolar, yeşil onay işaretleri ve em dash'lerle dolu bir biçimde yazılmıştı ve rastgele SQL ifadelerinin çalıştırılmasına izin veren kritik bir açık bulunduğunu iddia ediyordu
- Turso, bir SQL veritabanının SQL ifadeleri çalıştırmasına izin vermesini tek başına bir güvenlik açığı olarak görmüyor
-
Turso'nun eşzamanlı yazma özelliğini yanlış anlayan PR
- PR #6874, Turso'nun ayırt edici özelliklerinden biri olan eşzamanlı yazmayı etkinleştirdikten sonra, günlük modunu WAL'a geri çevirip eşzamanlı yazmayı devre dışı bırakana kadar SQLite'ın dosyayı açamadığını gösteriyordu
- Bu, sistemin tasarlandığı gibi çalışmasının sonucuydu
-
Niyetini anlamanın zor olduğu gönderi
- Başka bir gönderi, ne yapmaya çalıştığını anlamayı zorlaştırıyordu
- Bakımcı Mikael, göndericinin ödül duyurusunu görüp yapay zeka üretim araçlarını Turso'ya yönelttiğini düşündü
Son önlem: kefalet sistemi
- Turso, düzeni sağlamak için son bir girişim olarak kefalet (vouching) sistemi tasarlayıp uyguladı
- Bu sistem, gönderinin bottan geldiğinden şüphelenildiğinde otomatik olarak kapatılması esasına dayanıyordu ve bir süre kısmen işe yaradı
- Daha sonra botlar, PR'ın neden kapatıldığını sorun ederek manuel inceleme talep eden issue'lar açmaya başladı
- Bir PR kapatıldığında, aynı kullanıcının ya da başka bir kullanıcının kısa süre içinde aynı veya çok benzer bir PR'ı yeniden açtığı da defalarca görüldü
Açık katkılar ile maddi teşviklerin çatışması
- Düşük kaliteli gönderi üreten taraf bunları oluşturmak için yalnızca yaklaşık 1 dakika harcarken, Turso bunları okuyup anlamak ve yanıtlamak için saatler harcamak zorunda kalıyor
- Bu tür gönderiler pratikte sonsuza yakın bir hızda üretilebiliyor
- Otomatik geçit denetimi sistemleri kurulabilir, ancak göz ardı edilemeyecek bir maddi ödül olduğunda yapay zekanın tartışmayı sürdürme ve aynı PR'ı yeniden açma teşviki büyüyor
- Turso, açık kaynak katkıcı topluluğuna değer vermeye ve onu güçlendirmeye devam edecek, ancak şu an için açık bir sistemde hiçbir tür maddi teşvikin iyi çalışmadığını düşünüyor
- Seçenekler ya sistemi kapatmak ya da teşviki kaldırmak ve Turso şimdilik ikincisini seçiyor
1 yorum
Hacker News görüşleri
Darboğazın kod yazmakta değil, kodu okuyup anlamakta olduğunu gösteriyor
Eskiden de her takımda bir tane “üretken” mühendis olurdu; gerekip gerekmediğine bakmadan, içine büyük çaplı refactor’lar karışmış dev PR’lar açardı. Sinir ağlarının bu kadar çok kod üretebileceğini hayal bile etmediğimiz zamanlarda da durum buydu
Böyle bir “üretkenliğin” sonucu takımın hızını artırmak değil, neredeyse durma noktasına getirmek olurdu. Ya PR’ı dikkatle review etmek için tüm zamanı harcardınız ya da üstünkörü LGTM derdiniz ve sonra prod’da patlar, herkes yeniden tasarım tahtasına dönmek zorunda kalırdı. Üstelik o kişinin “üretkenliği” yüzünden proje yapısı o kadar hızlı değişirdi ki, neyin nerede olduğunu gerçekten bilen tek kişi o “çok zeki, yetenekli, üretken ve şirket hedeflerine sadık” kişi olurdu
“Neredeyse her yazılım geliştirme organizasyonunda, taktiksel programlamayı uç noktaya taşıyan en az bir geliştirici vardır. Buna taktiksel tornado denir. Taktiksel tornado, diğerlerinden çok daha hızlı kod çıkaran üretken bir programcıdır ama tamamen taktiksel bir şekilde çalışır. Hızlıca tek bir özellik çıkarmak gerektiğinde ondan hızlısı yoktur. Bazı organizasyonlarda yöneticiler taktiksel tornadoyu bir kahraman gibi görür. Ancak taktiksel tornado arkasında bir yıkım izi bırakır. Daha sonra o kodla çalışmak zorunda kalan mühendisler onu çoğu zaman kahraman olarak görmez. Genellikle diğer mühendisler, taktiksel tornado’nun bıraktığı dağınıklığı temizlemek zorunda kalır ve bu yüzden asıl kahraman olan o mühendisler, taktiksel tornado’dan daha yavaş ilerliyormuş gibi görünür.”
Üstelik AI tarafından üretilen kod arttıkça, o kodu gerçekten anlayan insan sayısı daha da azalacak
Yine de regresyon testleri ve linter’lar iyi durumdaysa ve kodun çalıştığını, berbat olmadığını biliyorsanız, review süreci harf harf doğruluğu didiklemekten çok genel ve üst seviye kaliteye bakmalı. Elbette review’nin kendisi yine de acı vericiydi
Doğal olarak kod yazmaktan çok kod okuyup anlamakla vakit geçirdim ve bazen yazdığım satır sayısı negatif olurdu; bununla da gurur duyardım
Artık AI sayesinde daha da az kod yazıyorum ve bu şekilde tatmin bulma hayalinden vazgeçtim. Kimin ürettiği fark etmeksizin, şüpheli kaynaktan gelen büyük miktarda kodu hızlıca anlayabilme becerisinin, özellikle de AI yardımıyla, emekli olana kadar değerli kalmasını umuyorum. Sizce?
Biz sadece makinenin çalıştıracağı kodu yazmıyoruz; insanların okuyacağı kodu da yazıyoruz. Kod review, debugging ve gelecekteki değişikliklerin hepsi, birinin yazdığı kodu okuyup anlamayı içerir. Ve yaptıklarından sorumlu tutulabilecek bir AI ortaya çıkana kadar bu anlayışı AI’a devredemeyiz
Botları cezbetmek için kullanılan honeypot repo olarak bu harika projeden bahsetmek için iyi bir zaman
https://github.com/UnsafeLabs/Bounty-Hunters
Buna karşılık gelen sıralama tablosu da burada
https://clankers-leaderboard.pages.dev
AI böyle depoları ve içlerindeki etkinlikleri öğrenirse ne olacağını merak ediyorum. Issue’lardaki bug report’lar gerçekten düzeltilebilir sorunlar mı, yoksa uydurulmuş saçmalıklar mı?
Yalnız yakında AI bot blocklist listelerine girme ihtimali yüksek
Programı kapatmak tamamen makul. Ama başka seçenekler de var. Gönderen kişinin küçük bir ücret ödeyip, gerçek bir bug bulunduğunda parasını geri alacağı bir sistem kurulabilir
Programın gerçekten ödeme yapıp yapmaması önemli değil. Tek bir report bile yanlış şekilde kapatılırsa o hikâye sonsuza kadar anlatılır
Böyle durumlarda bugün zaten zaman kaybediyorsunuz, yarın bir de para kaybetmiş olursunuz
Özellikle küçük bir şirkette, göndermeden önce şirketin nasıl tepki vereceğini bilemezsiniz
Gönderimden önce simülatör test suite’inin tamamını çalıştırmayı zorunlu kılamaz mısınız? Bu, gönderenin simülatörü bozmadığını doğrulayan iyi bir kontrol olur ve yan ürün olarak bir proof-of-work çıktısı da üretebilir gibi görünüyor. Mümkün mü, güvenlik tarafını çok bilmediğim için emin değilim
Bir yıldan uzun süredir TursoDB’nin tek bir dosyayı yüklemesini sağlamaya çalıştım ama başaramadım: https://github.com/ClickHouse/ClickBench/issues/336
Hacktoberfest hâlâ herkese tişört veriyor olsaydı bugün nasıl görünürdü merak ediyorum. Muhtemelen dünyada yeterli pamuk kalmazdı
Bunun önlenmesinin sorumluluğu tek tek maintainer’ların üzerinde olmamalı; bence GitHub ve GitLab bu tür hesapları PR açabilecek aşamaya bile gelmeden durdurmalı. Bu özünde spam
Yazıda ilk geçen PR’ı açan kullanıcıya bakın: https://github.com/Samuelsills. Böyle hesaplar popüler depolara PR açmaya yaklaşamamalı bile
Alanı çok bilmediğim için aptalca bir soru olabilir ama gönderilen simülatör değişikliğinin mevcut işlevleri bozmadığını doğrulamak için sonda simülatör testlerinin tamamını çalıştırmayı zorunlu kılmak, bir proof-of-work işlevi görebilir mi?
Bounty programı yerine bir tür doğru/yanlış tahmin piyasası kurmak nasıl olur
İnsanlar cevaba açıkça bahis oynar, report’un gerçekliğini kendi token’larını kullanarak doğrular ve sonra buna göre bahis alır. Çoğunluk yanlış derse operatör kazanır, çoğunluk gerçek derse operatör ödeme yapar
Şaka yapıyorum ama belki de yapmıyorumdur
Turso’yu prod ortamında kullanan var mı? SQLite uyumlu, Rust ile yeniden yazılmış bir implementasyon; çoklu yazıcı desteği gibi özellikler eklenmiş ve SQLite’ın aksine harici katkılara da açık
Her şey cargo ile çalıştığı ve SQLite’ı ayrıca getirmem gerekmediği için tam yığın bir Rust uygulamasında denemeyi düşünüyorum
Turso ayrıca oldukça cömert ücretsiz plana sahip bir database-as-a-service de sunuyor; benim kullanmamın ana nedeni de buydu
https://x.com/doodlestein/status/2052910351474209258
Aynı yöntemle karşılık verip, PR’ları önceden incelemesi için kendi AI botunuzu devreye alamaz mısınız?
“Bunu önlemek için otomasyon sistemleri kurabilirsiniz ama işin içinde göz ardı edilemeyecek düzeyde parasal değer olduğunda, AI’ların durmadan tartışıp aynı PR’ı yeniden açması için teşvik fazla güçlü oluyor”
Dışarıdan bakan biri için ilginç bir zor problem. Acaba bu bot isteklerinin ne kadarı arka uçlarında Turso kullanıyor?