Flathub, LLM tabanlı gönderimlere izin vermiyor

• Flathub gönderi incelemelerinde LLM tabanlı düşük kaliteli gönderimlerin artması, gönüllü inceleyicilerin yükünü büyüttü ve politikanın netleştirilmesinin arka planını oluşturdu
• İstisnaların topluluk katılımı, sürüm döngüsü, CI ve kısa sürede üretilmiş düşük çabalı bir iş olmadığını gösteren izlere sahip projelere uygulanma olasılığı yüksek
• Mevcut geliştirme geçmişi ve proje sağlığı ölçütleri tek başına inceleme iş yükünü azaltmadı; yalnızca kuralların yorumlanması etrafındaki anlaşmazlıkları artırdı
• Yeni politika, LLM’i kısmen kullanan olgun FOSS uygulamalarını ya da mevcut tescilli uygulamaların tamamını yasaklamayı değil, düşük çabalı gönderimleri engellemeyi hedefliyor
• Bazıları Flatpak ekosisteminde dağıtım parçalanmasının yeniden doğmasından ve şirketlerin Flathub’dan kaçınmasından endişe ederken, tam yasak yerine ücret alınmasını öneriyor

---

Flathub’un LLM gönderim politikası değişikliği

• Flathub gönderi incelemelerinde LLM tabanlı düşük kaliteli gönderimlerin artması ve bunun gönüllü inceleyicilerin yükünü büyütmesi, politika değişikliğinin temel nedeni oldu
• Sjoerd Stendahl, Flathub PR listesinde çok sayıda “AI-slop” gönderimi bulunduğunu ve ölçek nedeniyle bu adımın daha iyi bir seçenek olabileceğini düşünüyor
• Bart Piotrowski, projede topluluk katılımı, sürüm döngüsü, CI ve kısa sürede üretilmiş düşük kaliteli bir çıktı olmadığını gösteren işaretler varsa istisna uygulanma ihtimalinin yüksek olduğunu söyledi
• Daha önce de yeterli geliştirme geçmişi ve genel proje sağlığı ölçütleriyle düşük kaliteli gönderimler engellenmeye çalışıldı, ancak inceleme iş yükü azalmadı ve yalnızca kuralların yorumlanması etrafında tartışmalar çıktı

İstisnalar ve olgunluk ölçütleri

• Nexi, düşük çabalı Flathub gönderimleri sorununun gerçek olduğunu, ancak AI tarafından üretilen veya AI destekli kodun tamamını toptan yasaklamanın aşırıya kaçtığını düşünüyor
• Firefox, VSCode ve Chromium gibi mevcut projeler bile istisnasız kaldırılma riski taşıyacaksa, düşük kaliteli gönderimleri ayıklamak için nesnel proje olgunluğu ölçütlerinin daha uygun olacağını öneriyor
• Bart Piotrowski, olgunluk ölçütlerinin fiilen zaten var olduğunu, ancak sonuçta inceleme yükünü azaltamadığını söyledi
• Nexi, istisna ölçütlerinin politikaya açıkça yansıtılabileceğini ve kod kalitesi fazla düşükse ek açıklama yapılmadan reddedilebileceğine dair bir not da eklenebileceğini düşünüyor
• Sjoerd Stendahl, yeni politikanın olgun ve iyi bakımı yapılan projeler için istisna tanıdığını, LLM’i kısmen kullanan doğrulanmış FOSS uygulamalarını ya da mevcut tescilli uygulamaların tümünü yasaklayan bir politika olmadığını düşünüyor

Ekosistem etkisi ve dağıtım kanalı kaygıları

• Dmitry Mantis, bu politikanın Flatpak’ın çözmeye çalıştığı Linux dağıtım parçalanmasını yeniden yaratabileceğinden endişe ediyor
• Slack ve Spotify gibi tescilli uygulamaların Flathub’da sandbox biçiminde sunulmasının bir avantaj olduğunu, kapalı kaynak kodun nasıl yazıldığının bilinmemesi nedeniyle bunun aksine bir avantaj sağlayıp sağlamadığını sorguluyor
• Yeni ve tanınmayan bir geliştiricinin tescilli uygulamasının, bu politika olmasa bile Flathub’da hemen yayımlanmamasının daha iyi olacağı yönünde karşı görüşler de var
• Yalnızca AppImage kullanan bazı uygulamaların resmi Flatpak desteği vermeye başlaması olumlu görülse de, bu tür bir politika sonrasında şirketlerin Flathub’a girmekten kaçınabileceği endişesi bulunuyor
• AI tabanlı gönderimlere, inceleme maliyetini karşılayacak bir ücret uygulanmasının tam yasaktan daha iyi olacağı da öneriliyor
• Bu durum, belli bir kullanıcı seviyesine ulaşmadan önce başka yerlerde dağıtım yapmaları gerektiği yönünde bir sinyal olabilir; test veya dokümantasyon otomasyonunun bir bölümünde LLM kullanan, iyi bakılan uygulamalar başka dağıtım yollarında yerleşirse Flathub’a geçme motivasyonları azalabilir

LLM araçlarına dair zıt değerlendirmeler

• Thomas Fuchs, LLM sorununun teknolojinin kendisinden çok insanlar ve pazarlama ile ilgili olduğunu düşünüyor
• LLM şirketlerinin LLM’leri sihir ya da kişisel iş kölesi gibi pazarladığını ve kullanıcıların da bu iddialara olduğu gibi inandığını eleştiriyor
• Deneyimli kullanıcılar güçlü ve zayıf yönlerini bilip dar kullanım alanlarında kullandığında bunun harika bir araç olabileceğini, ancak sektörün bunu “yanan bir elektrikli testereyi jonglörlük için bedava dağıtır gibi” agresif biçimde pazarladığını söylüyor
• Wolkensteine, LLM’lerin tamamen işe yaramaz olduğunu düşünmese de çoğu durumda faydalı olmadığını ve etik olarak desteklemek isteyeceği biçimde üretilmiş faydalı bir modelin henüz bulunmadığını savunuyor
• Cihaz üstü modellerin yazım denetimi ya da telefon klavyesi otomatik düzeltmesindeki kelime tahminine yardımcı olabileceğini, ancak hatasız yapabildikleri işlerin çoğunun insanların da kolayca yapıp öğrenebileceği şeyler olduğunu düşünüyor
• Ember, bu tür potansiyel kullanım alanlarının da üretken AI öncesi araçlarla mümkün olduğunu ve nadir durumlarda belirli verilerle eğitilmiş özelleşmiş ML’nin daha iyi olabileceğini düşünüyor
• Kroc Camen, kod hırsızlığı, içkin önyargılar ve çevresel etki nedeniyle LLM’lerin hiçbir yerde geçerli bir kullanım alanı olmadığını savunuyor

Topluluk kültürü ve tartışmanın kutuplaşması

• trisweb, LLM ile üretilen kod ve onu kullananlar etrafında oluşan kültürün, açık kaynak topluluklarını ayakta tutmak için gereken nazik ve işbirlikçi yaklaşımla çoğu zaman uyuşmadığını düşünüyor
• ragectl, yeni uygulamalar için bir soğuma süresi benzeri anlayışın gerekli olabileceğini; birkaç sürüm ve ikinci bir insan katkıcısı ortaya çıkana kadar riskin yüksek olabileceğini söylüyor
• Sjoerd Stendahl, cadı avına dönüşmemesi gerektiğini, ancak büyük teknoloji şirketlerinin agresif LLM dayatmasının insanlardaki tepkiyi büyüttüğünü düşünüyor
• Bazı işverenlerin işten çıkarma tehdidiyle birlikte işte LLM kullanımını zorladığını; arama gibi basit işlevlerin bile bozulduğunu ve “Agentic future” söylemine rağmen birçok ürünün insan emeğini andıran artıklar haline geldiğini ifade ediyor
• razze, arama veya chatbot’larda LLM kullanımı ile kodda kullanımı aynı mesele olmadığını; kodun kanıtlanabilir olduğunu ve ödünleşimlerin daha açık görüldüğünü, bu yüzden ayrı değerlendirilmesi gerektiğini düşünüyor
• Zeeshan Ali Khan, LLM karşıtı kesimin saldırganlığını eleştirdi; Bart Piotrowski ise hem LLM yanlısı hem LLM karşıtı tarafta güçlü bir kutuplaşma olduğunu ve “vibecoder”ların da eleştirilince mağdur gibi davrandığını söyledi

[GN⁺]

Lobste.rs görüşleri

• "Yapay zeka tarafından üretilmiş ya da desteklenmiş kod, dokümantasyon veya diğer içerikleri içeren uygulamalara izin verilmiyor" ifadesi oldukça sert görünüyor
  Flathub, Linux masaüstü kullanıcılarının uygulama indirdiği son derece popüler bir yer ve kendisini "Linux için uygulama mağazası" olarak tanımlıyor; 1000'den fazla uygulama var
  Bu gerçekten o uygulamaların hiçbirinin yapay zeka destekli kod kullanmaması gerektiği anlamına mı geliyor? Bu gerçekçi mi? Zaten çok geç değil mi?

  • "Olgun ve iyi bakımı yapılan projeler için istisnalara izin verilebilir" ifadesine bakınca, amaç daha çok tamamen vibe coding ile yapılmış bir projeyi yükleyip sonra kaderine terk etmeyi engellemek gibi görünüyor
  • Hiçbir şey için geç kalınmış değil
    Zaten FlatHub'da bulunan bir proje bile vibe coding ile yapılmış olduğu ortaya çıkarsa kaldırılabilir ve bu aynı zamanda net bir mesaj da verir
  • Bu kuralın takdire bağlı olarak uygulanacağını düşünmek gerek
    Mevcut büyük uygulamalardan bazıları muhtemelen istisna sayılabilir ve böyle durumlarda bile kısıtlamalar uygulamanın kendi kodundan çok bağımsız flatpak paketleme kısmına daha fazla uygulanacak gibi duruyor

• Bu kadar sert bir yaklaşım %100 uygulanabilir olmayabilir, ama şirketlerin LLM benimsenmesini zorla dayattığı bir ortamda topluluğun gösterebileceği en küçük tepki için bile böyle güçlü bir duruş gerekli

• Son dönemdeki tedarik zinciri olaylarını düşününce, oldukça makul bir karar gibi geliyor

• Bir projenin LLM'leri yasaklamasına da, beyaz saçlı insanları ya da boyu tam 160 cm olan kişileri yasaklamasına da %100 destek veririm; istedikleri kuralları koymakta özgür olmalılar
  Bunun özgürlüğünü kısıtlamaktan yana değilim, ama paket yönetimi LLM yardımıyla büyük fayda görebilecek tipik, tekrarlayan bir iş
  Kendi kodunun saf sanat ya da zanaatkârlığın ürünü olduğunu düşünen insanları bir ölçüde anlayabiliyorum, ama en sıkıcı işleri otomatikleştirmeye neden izin vermeyelim?

  Arch Linux'un AUR'si daha yeni başlamışken yüzlerce paketi başarıyla bakımda tutan insanlar olduğunu hatırlıyorum
  Her zaman günceldi ve neredeyse hiç bozulmazdı; tabii ki bunu otomatik güncellemeyle yapıyorlardı
  Bugün aynı şey LLM desteğiyle yapılsa, neredeyse kesin olarak daha da sağlam hale gelebilir

  Belki de süreçten insanları yasaklamamız gerekir
  Tedarik zinciri saldırıları dışında insanlar ne katkı sağlıyor ki? Bir gün haklı mı haksız mı olduğumu kanıtlamak için bir LLM dağıtımı yapmam gerekecek sanırım
  Ama önce şu programlama dilini bitirmem lazım, komik gerçekten