Lütfen bu yazılımı vibe coding ile mahvetmeyin

• Bu konu Closed durumunda kapandı; metinde yeniden üretim adımları ya da düzeltme önerisi içermeyen bir sorun itirazı olduğu için bağlantılı branch·PR·milestone görünmüyor
• İlk itiraz, rsync’e AI’nin dahil olduğu değişiklikler girmesiyle kararlılığın sarsıldığı endişesiydi; metin ise açıklama olmadan çoğunlukla görsellerle paylaşıldı
• Bir kullanıcı, log2ram’in rsync kullanması nedeniyle bir 3D yazıcının CPU’yu %100 kullandığını bildirdi ve AI’nin bu hatayı robota taşımış olduğunu söyledi
• Başka bir kullanıcıya göre rsync, yeni özellikler ya da yeniden yazım yerine yalnızca güvenlik güncellemeleri ve hata düzeltmeleri gerektiren kararlı bir araçtı; son iki patch sürümünde ise mevcut işlevlerin değiştirilmemesi gereken bir sorun yaşandı
• DFIR işlerinde rsync kullanan bir kullanıcı, yalnızca AI’nin güncellemelere dahil olması nedeniyle bunun kurum politikası gereği bir "AI aracı" sayıldığını ve ek inceleme gerektirdiğini anlattı
• Karşı tarafta ise issue tracker’ın viral şikayetlerin döküldüğü bir yer olmadığı, somut hata raporu ya da yeniden üretim adımları yoksa bunun Discussions bölümüne taşınması veya fork edilmesi gerektiği savunuldu
• Temel çatışma, “özgür yazılım; beğenmiyorsan fork et” yaklaşımı ile rsync’in zaten çekirdek altyapı aracı olduğu ve downstream tarafında pinning·fork tartışmasının kendisinin bir sorun sinyali sayılması gerektiği yaklaşımı arasında büyüdü
• Bazı kullanıcılar Rust ile yeniden yazımı ya da fork’u gündeme getirdi; buna karşı çıkanlar ise rsync’in sevilme nedeninin kararlılık ve olduğu gibi çalışması olduğunu, yeniden yazımın ayrı bir proje olduğunu vurguladı
• AI kullanımını savunan tarafta, AI’ye dair her sözün “vibe slop” diye yaftalanmaması gerektiği; bunun yerine marttan sonraki commit log’larının doğrudan denetlenerek değişikliklerin neden yapıldığının görülmesi istendi
• kaithar, son çalışmalarda başlatılmamış bellek okuması, wire protocol over/underflow, 32 bit zaman damgası sorunları ve C standardıyla ilgili uyarlamalar gibi hata·güvenlik açığı düzeltmeleri ve hardening bulunduğunu açıkladı
• Aynı yorumda, 3.4.1 gibi eski sürümlere sabitlenmenin birden çok CVE içeren bir sürümde kalmak anlamına gelebileceği, regresyonların ise testlerin kaçırdığı edge case’lerde ortaya çıkabileceği belirtildi
• Sonuç olarak konu, somut bir hata düzeltmesine varamadı ve rsync gibi uzun süreli, kararlı altyapılarda AI destekli geliştirmenin güven, denetim ve yönetişiminin nasıl ele alınacağına dair bir tartışma olarak kaldı

[GN⁺]

Hacker News görüşleri

• Bu toplu yüklenme gerçekten tuhaf ve bazıları irrasyonel davranıyor gibi görünüyor. Bu kavgada “kazanmak” isteme motivasyonunu bir yere kadar anlayabiliyorum ama bu yöntem hiç doğru değil; sadece insanları fanatik gibi gösteriyor
  Sorun sayfasında regression diye aratıp 17 sonucu gözden geçirmek 5 dakikanı alır. GitHub’dan önce kullanılan takip sisteminde daha fazlası da olabilir
  Bu davranış çok aptalca ve insanlar sanki AI nefretini meşrulaştırmak için bulabildikleri her şeye sarılıyor. AI’dan önce de insanların hata yaptığını unutmuş gibiler
  Eğer AI’ın rsync’teki çözümlenmemiş sorunları anlamlı ölçüde artırdığına dair bir kanıt varsa görmek isterim. O zaman fikrimi memnuniyetle değiştiririm

  • Buna sadece “insanlar AI’dan nefret ettiği için bulabildikleri her şeye sarılıyor” diye bakmamak lazım. İnsanlar bir şeyde sorun olduğunu hissettiklerinde harekete geçer
    Bu commit’in doğrudan nedeni olmayabilir ama birikmiş başka sorunlara verilmiş bir tepki olabilir ve bu da başlı başına dikkate alınmalı
    İnsanlar “AI [kültürel benzetme]den beri başımıza gelen en iyi şey” türü anlatıları zorla yutmaktan bıkmış durumda ve karşı koymak için her dala sarılıyor gibi görünüyor; bence bu gayet normal bir tepki
  • Meme görselleriyle üşüşme biçimi tuhaf. Yine de kullanılan dilin kendisi Tridgell’in LKML’de görmeye alışık olduğu seviyede, o yüzden asıl kaygı bu değil
    Kullanıcıların AI’a güvenmediği yönündeki endişeyi kimse dile getirmezse bir bakımcı bunu nasıl anlayabilir? rsync çok kararlıydı. İnsanlar sessizce Openrsync’e geçip hiçbir şey söylememeli mi?
  • Çok kararlı ve güvenilir bir araç birden yokuş aşağı gitmeye başladıysa insanların öfkelenmesi bence tamamen meşru. Linux Mint Timeshift’ta rsync sorun sayfasında açık duran çeşitli regresyonları derleyen bir issue var ve bunların yalnızca vibecoding sonrasında ortaya çıktığı anlaşılıyor (https://github.com/linuxmint/timeshift/issues/548)
    İçindeki bağlantılardan biri, alt dağıtımlarda bildirilen hataları daha geniş ölçekte toplayan başka bir yere gidiyor (https://github.com/void-linux/void-packages/issues/60825)
    Vibecoding ile geliştirilen yazılımların itibarı düşünülünce öfke son derece makul. Hatta sevilen uzmanlar bile “hata üretmemesi için çok belirli bir şekilde ele alınması gerekir ve muhtemelen sadece alanı taslak hâlinde görmek için 0. sürümlerde kullanılmalı” diyor
    Ama burada sektör standardı olan bir yedekleme çekirdek aracı, bakımcının “biraz daha özellik ekleme” niyeti yüzünden, kullanıcıların ayağının altındaki halıyı açıkça güvenli olmayan bir şekilde çekip alıyor
    Timeshift başlığında ayrıca “rsync güncellemesinden sonra günlük yedekleme sırasında CPU kullanımı o kadar arttı ki timeshift’ın sonsuza kadar çalışmasını durdurmak zorunda kaldım” diyen bir yorum da var
    Başka bir deyişle insanlar, yedeklerini ve verilerini emanet ettikleri aracın çok sayıda regresyon ve yeni hatayla tüm yedekleme altyapılarını bozmasından dolayı hayal kırıklığına uğramış ve öfkeli; bunun sebebi de çekirdek geliştiricinin vibecoding yapması
    Simon Wilson gibi vibecoding’i savunan uzmanlar bile bunun yalnızca “araçlar belirli bir şekilde kullanıldığında” mümkün olduğunu açıkça söylüyor; o hâlde bu bakımcı ya bunu yapmıyor ya da söylenen şey doğru değil
    İlgili başlığı gerçekten okuyup sadece iki kişinin atıştığı kısımlara göz gezdirmekle yetinmezsen, sanayi ve kamu ortamlarındaki kullanıcıların bu yazılımı güncellemek için tüm süreçleri yeniden yürütmek zorunda kaldığını bildiren çok sayıda yorum var. Çünkü yazılım anında güvenilmez hâle geldi, kullanıcılara doğrudan zarar verdi ve bu yazılımın varlık nedenini çökertti
    Ben de bu yazılıma 500GB’tan fazla yedek emanet etmiş olsaydım öfkelenirdim ve bir şirket yedeklerini düzenli test etmediği için 10 milyon dolarlık veri kaybı yaşayana kadar ortaya çıkmayacak daha kaç sorun içeri sızdı diye merak ederdim
  • AI kaçınma davranışı sendromu gibi duruyor
  • AI zaten partizan bir siyasi mesele hâline geldi ve bunun bütün sonuçları da peşinden geldi. Bu noktada buna şikâyet etmek, güneşin doğudan doğmasına söylenmek gibi bir şey :(

• Gerçekten anlamıyorum
  Pek çok insanın ve hizmetin kullandığı sağlam bir yazılım var. İyi çalışıyor, görevini yapıyor ve ara sıra sadece küçük hata düzeltmesi güncellemelerine ihtiyaç duyuyor
  Burada neden yapay zekaya ihtiyaç var?
  Ayrıca insanların neden “fork'layıp önceki sürümü kullanın” dediğini de anlamıyorum. Aslında tam tersi olmalı. younamethetool-ai gibi paralel bir fork oluşturulmalı ve asıl kaynak elleşilmeden bırakılmalı
  Şimdi bütün sistem araçlarımı fork'layıp ben mi sürdürmek zorundayım?

  • “Burada neden yapay zekaya ihtiyaç var?” sorusuna gelince, çeşitli issue yorumlarında da söylendiği gibi, açık kaynak pakete katkı yapan geliştiriciler çalışma yöntemine karar verir
    Hiçbir kanıt olmadan issue tracker'da yapay zekanın yazılımı mahvettiğinden şikayet etmek, Hacker News'ta sıkça tartışılan bir açık kaynak katkıcısı tacizi biçimidir [1]
    https://github.com/RsyncProject/rsync/issues/929#issuecommen...
    “Issue tracker, viral sosyal medya gönderileri devşirilecek bir yer değildir. Uygulanabilir bir bug bildirin ya da kendiniz fork'layın. Geliştirici tercihleri hakkında öfke kusmak üretken değildir”
    https://github.com/RsyncProject/rsync/issues/929#issuecommen...
    “@II-Paulus-II dur. Hiçbir şey bilmiyorsun. Elle 0 özellik dağıttın. Koduna bağımlı olan tek bir kişi yok. En baştan oyuncak projeler ve script'ler yazıyor olmanın sözde ahlaki üstünlüğüne sığınan, ‘bunu AI yazdı’ diye parmak sallayan birisin sadece. Dağıtım yapamıyorsun, uyum sağlayamıyorsun ve issue tracker'ın bu tavrı sergileyeceğin yer olmadığını da bilmiyorsun”
    [1] https://news.ycombinator.com/item?id=43077833
  • “Bu istikrarlı ve güvenilir işçiyi lütfen bozmayın” duygusuna %100 katılıyorum
    Ayrıntılı okumadım ama “bu sürümde 6 CVE düzeltildi. Altısının da CNA atamasını VulnCheck yaptı. Etkilenen sürümler her durumda 3.4.2 ve öncesi” cümlesi, “neden?” sorusuna oldukça güçlü bir yanıt gibi görünüyor
    https://download.samba.org/pub/rsync/NEWS#3.4.3
  • Birçok açık kaynak geliştiricisinin katlanmak zorunda olduğu hak görme duygusu üzücü geliyor. Hobiniz olarak ücretsiz bir şey yapıyorsunuz ama sonra, hoşlarına gitmeyen bir şey yaptınız diye size bir kuruş bile ödememiş öfkeli kalabalıklarla uğraşmak zorunda kalıyorsunuz diye düşünün
    İlk tepkinizin doğal olarak onlara defolup gitmelerini söylemek istemek olacağını düşünüyorum
  • Buna karar verecek kişi bakımcı değil mi? AI ile daha fazla test yazmaya karar verirse öyle yapar. Kamuya borçlu olduğu bir şey de yok
    Eğer “kamu” projeyi devralıp sürdürmek istiyorsa fork'layabilir, ama bu pek teşekkür gören bir iş değildir
  • Bakımcı neden kendi deposunu bizzat fork'lamak zorunda olsun ki? Bu mantıksız. Eski depoyu o zaman kim sürdürecek?
    Ayrıca açık kaynak projede hangi araçların kullanılacağını değiştirmek için bir gerekçeye ihtiyaç yoktur ve bu gerekçeyi size borçlu da değildir

• O issue’nun açılış biçimi gerçekten rahatsız edici, ama bakımcıların rsync’in üstüne AI salmış gibi görünmesini anlamıyorum. Bunu neden yaptılar? Zaten itibar ve güven kazanmışken, belirli bir nişte liderken, piyasa baskısından uzakken, insanlar aracı severken ve tam yapması gereken işi iyi yapıyorken neden görece deneysel ıvır zıvırları denersin?
  Biraz, Matrix’te ilkel insan zihninin cenneti kabul edemediğine dair o kısa monolog gibi. Kusursuz aracı kullandın, kazandın, nişinde neredeyse vazgeçilmezsin, güvenilirsin ve mecazi olarak herkesin bildiği bir isim oldun. Bunu riske atmak ya da kurcalamak kimse açısından mantıklı değil ve gerçekten kafa karıştırıcı
  Yine de bunu resmî issue takipçisinde yapmak hâlâ gerçekten nahoş bir davranış. Tavır da kötü ve ortada iyi niyet de yok gibi görünüyor

  • Birkaç yıl önce olsaydı bakımcıları aktif biçimde savunurdum. Herhangi bir açık kaynak projeyi sürdürmek yorucu ve pek takdir görmeyen bir iş, rsync gibi yerleşik bir projede ise daha da öyle
    Ama şu an AI’ın hiçbir yerde net pozitif görünmediğini düşünüyorum ve üretken AI kullanımına yönelik bu tepkiyi kamunun iyi yönde bir düzeltmesi olarak görüyorum
    LLM kullanımının anlık tatmini hakkında yazılar var; bu araçları kullanan insanlarla ne kadar çok etkileşime girersem bunun gerçekten temel sorun olabileceğini o kadar düşünüyorum. Biyolojimiz bununla başa çıkamıyor
    Aslında çok zeki insanların, slot makinesi söyledi diye gerçekten aptalca şeyler yaptığını ve slot makinesi başarısız olduğunda da çaresiz kalacak şekilde eğitildiğini görüyorum
    Ben ilerlemeyi göremeyen bir Luddite muamelesi görüyorum, ama bir yandan iş arkadaşlarımın anlamsız benchmark’lar üretip üstüne AI ile yapılmış güzel grafikler koyduğunu izliyorum
    Sonra ya gülümseyip bunun iyi bir işmiş gibi davranmam ya da benchmark’ın sabite çakılı bir bölgeyi test ettiği için anlamsız olduğunu azarlamam gerekiyor. Her iki durumda da onlara zeki meslektaşlar gibi değil, 7 yaşındaki çocuklar gibi davranmış oluyorum
  • “Neden?” sorusunun cevabı, bu forum dâhil herkesin LLM’nin anlık tatminine bağımlı hâle gelmiş olması. Çıktıya göz gezdirip de kendi düşündüğün gibi çalıştığına inanmak düpedüz kibir
  • Bu görüş sadece issue’ya bakılarak mı verildi, yoksa elde gerçek kanıt var mı? Bu GitHub bağlantısı ilginç, ama “Claude” dışında olayın ne olduğuna dair neredeyse hiç bağlam yok
    rsync bakımcıları kusursuz ve sorumluluk sahibi bakımcılarla beceriksiz çocuklar arasındaki yelpazenin neresinde olursa olsun, gerçekte bilmiyoruz
  • rsync’in üstüne AI salındığını anlamlandıramamaya katılıyorum ve issue’nun açılış biçiminin gerçekten rahatsız edici olduğuna da katılıyorum
    Ama biraz konudan sapma riskini göze alarak şu düşünce geliyor aklıma. Rsync gibi olgun yazılımların değişen satır sayısı gibi hareketliliklere ihtiyaç duymadığı kısmını bir kenara bırakırsak, bakımcıların projeyi en iyi niyetle yönettiğini varsayalım
    Eğer bu olay açık kaynakta yaşanıyorsa, kapalı kaynak yazılım kalitesi ne durumda acaba?
    AI kullanımı, yani prompt sayıları başarı metriği gibi çalışan değerlendirmelerine giriyor ve insanlar AI kaynaklı kitlesel işten çıkarmalar tehdidiyle panik hâlinde
    Ürkütücü
  • Gerçekten anlamadığım şey, ne senin ne benim Claude’un nasıl kullanıldığını en ufak şekilde bilmemesine rağmen rsync’in üstüne AI salındığını söylemek
    https://github.com/RsyncProject/rsync/issues/929#issuecommen... bağlantısının gösterdiği şey, artık eski Darwin ve Linux < 5.6 üzerinde çalışmadığı; Linux 5.6 ise 2020’de kullanım ömrü sonuna yaklaşmış bir sürüm. Bunun dışında birkaç bug daha var
    Bir bakımcının eski sistemleri desteklemesini ve bir değişikliğin tüm etkilerini bilmesini bekleyemezsin. Bunu AI ile yapsın ya da elle, fark etmez

• Bu arada bug’ın kendisi Claude Code’un ürettiği 30656c5e içinde girmiş ve muhtemelen yetersiz birinin review ve testinden de geçmiş gibi görünüyor
  https://github.com/RsyncProject/rsync/commit/30656c5e
  Birinin AI kullanarak son rsync sürümlerinde bisect yapması: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
  Birinin daha fazla Claude Code ile düzeltmeye çalışma girişimi: https://github.com/RsyncProject/rsync/pull/930
  İlgili ticket: https://github.com/RsyncProject/rsync/issues/915
  30656c5e’den hemen önceki commit’e daha fazla regression test ekleyip işlevi koruyarak ileriye doğru rebase etmeyi öneririm

  • O zaman ilk şikâyet düpedüz yanlış gibi görünüyor
    Bu, “istenmeyen yeni özellik” değildi. Tridge, bug raporuyla ilişkili bir güvenlik sorununu düzeltiyordu. Buna sempati duyuyorum. Hepimiz güvenlik sorunlarından darbe yiyoruz. Bunu düzeltmek isteğe bağlı değil
    10 yıllık yazılıma dönüp bununla uğraşmanın eğlenceli olduğunu söyleyemem ve bu yüzden tridge’in emek veriyor olması bence etkileyici
    Ben de bu karmaşayı aşmak için LLM kullanma günahını işliyorum. tridge’in tam olarak ne yaptığını bilmiyorum ama ben LLM’in ürettiği kodun her satırını kontrol ediyorum. Yine de bug sızma riskinin açıkça yüksek olduğu doğru
    O koda uzun süredir bakmadım ve eskisi kadar da aşina değilim. Bu yüzden bug sızması çok da şaşırtıcı olmaz
    Bu patlamadaki tuhaf nokta, ilk şikâyeti yapan kişinin kendi yedekleme sistemini aşırı korumaya çalışıyor gibi görünmesi, ama tridge’in commit’inin daha sadece 2 hafta önce yapılmış olması. tridge’in çok iyi olduğunu biliyoruz, ama bunun yine de doğal olarak alfa yazılım gibi ele alınması gerekmez miydi? Ne düşünüyordu acaba? Belki onun da güvenilir sistem kurmayı biraz öğrenmesi gerekiyordur

• Birkaç yıl önce olsaydı, bu tür bir yazının Hacker News ana sayfasına çıkma olasılığı neredeyse sıfıra yakın olurdu. İçeriğin doğru ya da yanlış olmasından bağımsız olarak, burası hangi davranışların kabul edilemez olduğunu anlamayan sıradan insanlarla dolu değildi
  Burada kastedilen, meselenin şiddet içeren dili. Ama artık en bariz şeyleri bile ayırt edemeyen insanlarla çevriliyiz

  • Bir Twitter benzeri hizmetten alınmış tek bir ekran görüntüsüne ve hata bulduğunu söyleyen “kim olduğu belli olmayan birine” dayanarak “Please Do Not Vibe Fuck Up This Software” başlıklı bir issue açmak hiç uygun değil
    Bu, bakımcıya proje yönü konusunda aynı fikirde olmadığını söylemenin yolu değil. Bu issue tamamen işe yaramaz. Hiç değilse “vibe coded yüzünden bozulmuş” bir hata raporu daha iyi olurdu
    Asıl noktaya değinen buydu. Hiçbir hata raporu, iddia edilen --compare-dest= regresyonunu belgeleme girişiminde bile bulunmuyor. Ctrl-F yapsanız bile “compare-dest”ten tekrar bahseden kimse görünmüyor
    İşe yaramaz AI öfke yorumları yazan insanlar, Opus 4.8'e rsync 3.4.3 ile 3.4.1'i çalıştırıp regresyonu ayrıntılı biçimde belgeletmeyi, bozan commit'i git bisect ile buldurmayı ve 1000 kat daha profesyonel ve faydalı bir hata raporu hazırlatmayı da söyleyebilirdi
    Toplum insanların yaptığı işi AI'ın yaptığından daha değerli görsün istiyorlarsa, sadece insanların yapabildiği aptalca davranışlardan kaçınmak iyi olur
  • “normies” gibi küçümseyici ifadeler kullanmak için de aynı şey söylenebilir
    Ana sayfaya çıkmasının nedeni, başkalarının da her gün önemli işlerde kullandıkları bir yazılım hakkında benzer hisler taşıması olamaz mı?
    GitHub issue'larının sıradanlaştığı ve açıkça pek takdir edilmeyen bir iş olduğu doğru, ama gerçekçi olmak gerekirse rsync birçok hassas pipeline'ın temel taşı
  • O issue'yu “şiddet içeren” diye nitelemek tuhaf. Biraz okuyunca işin büyük boyutlu olduğu ve ilgili taraflardan hiçbirinin ahlaki üstünlüğe sahip olmadığı açıkça görülüyor
    Bunun gerçekten konu dışı olduğuna inanıyorsan, nazik tepki issue'yu kapatmaktır
    Neyin bu kadar açık olduğundan hâlâ pek emin değilim. Bana göre “dur. Hiçbir şey bilmiyorsun. Elinle sıfır özellik yayınladın. Koduna bağımlı olmuş tek bir kişi yok” ifadesi, “please do not vibe fuckup this software” sözünden çok daha şiddet içeren görünüyor
  • Belki de fazla kuşkucu oldum. HN ve GitHub issue yorumlarında giderek daha büyük bir kısmı, bakımcılar dâhil başkalarını öfkelendirmek için yazılmış botlar gibi geliyor
  • Bu yorumun her iki tarafa da uygulanabilecek kadar muğlak olması hoşuma gidiyor :)

• O issue başlığında biri gerçekten sorunu açıkladı mı? Yeniden üretim adımları, beklenen davranış ve fiilî davranış gibi şeylerden bahsediyorum
  Bu bir issue tracker'a gönderilmiş. “Commit mesajında Claude'dan bahsediliyor ve Bluesky'daki birisi yaşadığı belirsiz bir sorunun bu commit'lerle ilgili olduğunu düşünüyor” ifadesi, üzerinde işlem yapılabilir bir issue değil
  Tartışmanın geri kalanını bir kenara bırakırsak, benim projem olsaydı “yeniden üretim bilgisi yetersiz” diyerek kapatır ve kilitlerdim. AI, fork'lar ve öfke boşaltımı hakkındaki genel tartışmalar için daha iyi yerler var

  • Asıl issue kabaca şu gibi görünüyor
    Linux < 5.6 kullananlar GitHub'da build alamıyor. Bana oldukça küçük bir regresyon gibi görünüyor. 5.6'nın bakım sürümlerini, özellikle de genişletilmiş güvenlik sürümlerini kullananlar için dağıtım bakımcıları build hatasını fark edip zamanında düzeltebilir
    Dizin dolaşma saldırılarına karşı sertleştirmenin, chroot olmadan yerel rsync protokolü kullananlarda başarısızlığa yol açması söz konusu. İronik olan şu ki chroot = no zaten güçlü biçimde tavsiye edilmiyor
    Yerel rsync'yi otomatik bir şekilde kullanmamak, hatta hiç kullanmamak gerektiğini savunmak isteyebilirim. İlgili commit'in düzelttiği CVE tam da bu kullanım senaryosuna uygulanıyor
    https://www.cve.org/CVERecord?id=CVE-2026-29518
    Bunun için daemon + no chroot gerekiyor. “daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.”
    Dolayısıyla etkilenen iş akışı, en savunmasız iş akışı; ama insanlar sürümü geri çekmeyi öneriyor
    Ayrıca, eğer bir regresyon testi bunu yakalamalıydı deniyorsa, o testin önceden yazılmış olması gerekirdi

• Bazıları FOSS projeleri hakkında bazı şeyleri unutmuş gibi görünüyor
  “15. Garanti reddi
  Yürürlükteki hukuk izin verdiği ölçüde, bu program için hiçbir garanti yoktur. Yazılı olarak aksi belirtilmedikçe, telif hakkı sahipleri ve/veya diğer taraflar programı ‘olduğu gibi’ sağlar ve açık ya da zımni hiçbir garanti vermez. Buna ticari elverişlilik veya belirli bir amaca uygunluk konusundaki zımni garantiler de dâhildir, ancak bunlarla sınırlı değildir. Programın kalitesi ve performansıyla ilgili tüm risk size aittir. Programın kusurlu çıkması hâlinde gerekli tüm servis, onarım veya düzeltme masraflarını siz üstlenirsiniz”

  • Burada bir de OSS kullanıcı feragatnamesi var
    Ben, bir projenin aldığı her karar, commit, patch, pazarlama hamlesi ve diğer tüm kararlar hakkında şikâyet etme, söylenme, eleştirme, öfkelenme ya da başka şekilde yorum yapma hakkını saklı tutuyorum. Bu yorumlar herhangi bir amaca uygunluk garantisi vermez; doğru, yararlı ya da nazik olduklarına dair zımni bir garanti de içermez. Eğer yorumlarım istenmeyen bir şey çıkarsa, sen de onları zararsız bir yere tıkıştırma hakkını saklı tutarsın
    İstenmeyen FOSS proje eleştirileriyle karşılaştığınızda başvurmak üzere bu feragatnameyi çıktı alabilirsiniz
    İnsanların neden “istediklerini yapabilirler” tavrının iki yönlü olduğunu anlamadığını bilmiyorum. Kullanıcılar da istediklerini yapabilir. Hoşlarına gitmiyorsa bunu ifade edebilirler
  • Bunu yasal olarak yapabilirsin, doğru; ama yaparsan sadece kötü biri olursun
    Issue yorumlarından biri şöyle diyordu
    “Evsiz birine bedava çorba veriyorsun diye içine işeyebileceğin anlamına gelmez”
  • “Garanti yok”, “şikâyet yok” anlamına gelmez. Öyle olsaydı issue tracker'ların ve tartışma bölümlerinin var olmasının bir nedeni kalmazdı
    Söz konusu issue zaten raydan çıkmıştı ve senin argümanın da orada zaten dile getirilmişti. Herkes bunu daha iyi ele alabilirdi, ama yasal metni körü körüne alıntılamak meseleyi çözmüyor ya da iyileştirmiyor

• Bu konuda HN’de üçüncü kez bir yazı okuyorum. Her seferinde aynı tweet ya da Mastodon/Bluesky türü mecralarda her ne deniyorsa o gönderi tekrar tekrar dolaşıyor. Gerçekte sorunu debug eden oldu mu?
  Sebep özensizce üretilmiş kod muydu, yoksa gerçek bir güvenlik düzeltmesi tesadüfen bir şeyi mi bozdu? Yani insanların da aynı şekilde yapabileceği bir durum muydu?

  • Kısmi bir liste şurada var: https://github.com/RsyncProject/rsync/issues/929#issuecommen...

• Bu anti-AI histerisi tipik bir ahlaki panik

  1. Bir şeyi AI tarafından üretilmiş olarak teşhis et
  2. Üretiminde rolü olmuş olabilecek kişiyi hedef al ve dışla
     Bütün ahlaki paniklerde olduğu gibi, 1. maddenin doğru olup olmaması tamamen ikincil önemdedir. Asıl mesele 2. maddeden neredeyse cinsel bir rahatlama elde etmektir.
     Bu durumda rsync içinde AI üretimi kod olduğunu biliyorum. Bugünlerde faydalı yazılımların çoğunda olduğu gibi. Ama internette her gün bir cadı avı görüyoruz ve her cadı avında olduğu gibi suçlamanın doğru olup olmadığı pek önemli değil. Amaç histerinin kendisi.
  • Şu anda daha geniş ölçekte neler olduğunu ve bu başlıkta neler yaşandığını anlamayı reddetmek, sonra da bunu anlamamanın sorun olmadığı sinyalini vermeye devam etmek tehlikeli
    AI etrafında görülen öfke, halkın yanlış bilgilendirilmiş olması ya da mesajlaşmanın hatalı olmasıyla ilgili değil, fiziksel gerçeklikle ilgili bir mesele
    Bu tek şey kitlesel işten çıkarmalar için bahane olarak kullanılıyor, teknoloji CEO’ları neredeyse her gün diğer herkesin işini de ellerinden alacaklarını söylüyor ve büyük bulut şirketleri odadaki tüm oksijeni emiyor. Oyun sektörü bile güvende değildi
    Buna “sadece tipik bir ahlaki panik” diye bakmak, denizin hangi yöne çekildiğini görüp tam o yöne doğru koşmaya benziyor
  • “Asıl mesele 2. maddeden neredeyse cinsel bir rahatlama elde etmektir” gibi gevşek düşünceler görünce bu yanıtı ciddiye almak zorlaşıyor
    Biraz daha okuyunca kendisinin de “cadı avı”, “histeri” gibi duygusal ifadeler kullandığı görülüyor
    Bu gerçekten bir cadı avı mı? Ve internetin öte tarafındaki insanların cinsel bir rahatlamaya yaklaştığını gerçekten bilebilir misin?
    Başkalarının duygusal diliyle ve gevşek düşünceleriyle sen de aynı şekilde tepki vermiyor musun?

• GitHub issue’ları ne zamandan beri başka platformlardaki gönderilerin ekran görüntülerini koyma yeri oldu?
  Bu tür davranışı yalnızca meme ya da eğlence içeriklerinin paylaşıldığı yerlerde gördüm
  Burada uygulanabilir bir hata raporu ya da özellik isteği yok. Metin sürümü de yok. Orijinal gönderiye bağlantı bile yok
  Bunu paylaşan kişi GitHub Issues’u kendi kişisel Twitter hesabı sanmış olmalı?

  • Ekran görüntüsü yüklemek, otomatik LLM yanıtlarını engellemenin daha kolay bir yolu. Çünkü çoğu, maliyeti daha düşük olan görsel yeteneği olmayan metin modellerini kullanıyor