Mitchell Hashimoto röportajı: Ghostty, Zig, açık kaynak bakımı

 (alexalejandre.com)
10 puan yazan GN⁺ 5 시간 전 | 4 yorum | WhatsApp'ta paylaş
  • Mitchell Hashimoto, Vagrant, Terraform ve Vault’tan sonra Ghostty ve Vouch’u geliştirirken terminal, Zig, açık kaynak bakımı ve ürün kalitesi konusundaki ölçütlerini ortaya koyuyor
  • Ghostty; GPU programlama, masaüstü/tek düğümlü sistem programlama ve Zig öğrenmeye yönelik kişisel bir proje olarak başladı; hızlı, zengin özellikli, yerel ve çapraz platform bir terminal hedefiyle gelişti
  • Terminal, tarayıcı gibi tüm özellikleri içine almaktansa metin tabanlı uygulamaların birleştirilebilirliğini, otomasyonu ve net bir güvenlik modelini öne çıkarmalı; PTY’nin yapısız bayt akışı ise bir sınır olarak kalıyor
  • Açık kaynak bakımcılarının kullanıcılara karşı bir yükümlülüğü yoktur; ancak iyi yazılım yapmak için tek tek istekleri aynen almak yerine birden çok sorunu tek bir tutarlı özellik ile çözmek gerektiğini düşünüyor
  • Zig’deki büyük değişiklikler aşağı akış projeleri için yük oluştursa da API ve derleme araçlarının kalitesini artırıyor; yapay zekanın büyük ölçekli değişikliklerdeki yinelemeli işleri azaltarak geriye dönük uyumluluk yükünü hafifletebileceğini değerlendiriyor

Ghostty neden başladı

  • Mitchell Hashimoto, Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint ürünlerini yaptıktan sonra şu anda Ghostty ve Vouch üzerinde çalışıyor
  • Ghostty, yaklaşık 15 yıl boyunca CLI uygulamaları geliştirmiş olmasına rağmen terminal emülatörünün nasıl çalıştığını doğru dürüst anlamadığı yönündeki farkındalıktan doğdu
  • Hashicorp’tan ayrıldıktan sonra yeniden ele almak istediği üç alan vardı
    • Yapay zeka öncesi bağlamda GPU programlama
    • Dağıtık sistemlerden farklı olarak masaüstü/tek düğümlü sistem programlama
    • Zig kullanımı
  • İlk hedefi vim ve derleyiciyi çalıştırmak, Ghostty’nin kendi kendini derleyebilmesini sağlamak ve sonra projeyi bir kenara atmaktı
  • Terminal ekosistemini daha yakından inceledikçe hızlı, zengin özellikli ve yerel çapraz platform araçların eksik olduğuna karar verdi
  • Discord’daki arkadaşlarıyla paylaştıktan sonra her gün kullananlar ortaya çıktı; Ghostty Discord’u da aslında arkadaş grubu sohbetinin özel bir alana dönüştürülmüş hâliydi
  • Kamusal bilinirliğin aşırı ilgi yaratabileceğini düşündüğü için uzun süre kapalı beta olarak yürüttü

Terminal ne kadar genişlemeli

  • Hashimoto, terminali sorgusuz sualsiz dev bir uygulama platformuna dönüştürme yönelimine karşı çıkıyor
  • Terminal, tarayıcı ya da geçmişteki Java runtime gibi video ve mikrofona erişimi, duyarlı yerleşimleri bile kapsayabilir; ancak tarayıcıların, masaüstünün ve metin tabanlı sabit genişlikli ızgara uygulamaların her birinin iyi olduğu işler farklıdır
  • Metin tabanlı uygulamalar hızlı uygulanabilir ve etkileşimi kolaydır; güvenlik modeli de net olmalıdır
  • Terminal tabanlı uygulamaların gücü birleştirilebilirliktedir
    • TUI’lerde bu özellik daha zayıftır, ancak çoğu CLI aracı stdin/stdout’un ötesinde bir fonksiyon gibi kullanılabilen mekanizmalara sahiptir
    • UNIX’in “bir işi iyi yap” felsefesi bunun uç örneğidir
    • Neovim ve yapay zeka araçları giderek daha fazla komut satırı bayrağı sunuyor
  • Daha iyi terminal uygulamaları, daha iyi otomasyon ve betiklenebilirlik anlamına gelir
  • PTY’nin bant içi sinyalleri, yani escape sequence’ler içeren yapısız bayt akışı büyük bir sorun olmaya devam ediyor
  • Nushell ekosistemi bunu ayrı bir katmanda düzeltmeye çalışsa da Hashimoto daha köklü bir iyileştirme gerektiğini düşünüyor
  • Microsoft ekosisteminden hoşlanmayan çok kişi olsa da PowerShell’in yapılandırılmış veri açısından pek çok şeyi doğru yaptığını değerlendiriyor

Legacy olmayan terminal API fikri

  • Hashimoto yeni bir terminal API’si düşünürken tarayıcı, Emacs, Apple, Microsoft, Android ve oyun konsolları gibi büyük uygulama platformlarının framework’lerini referans alıyor
  • Web’in DOM ve JS API’leri, Apple’ın AppKit, Cocoa ve SwiftUI’ı, Windows’un Win32 ve WinUI’ı, Linux’un GTK ve Qt’si gibi birikmiş örneklerin önce incelenmesi gerektiğini düşünüyor
  • Yalnızca clipboard erişimi bile, tarihsel terminal protokollerinde metin merkezliyken masaüstü çok uzun süredir görüntüleri ve farklı MIME türlerini ele aldığı için her platformun clipboard belgelerine bakmayı gerektirir
  • Ghostty’ye henüz özel protokol eklemedi

  • n-screen API

    • Mevcut terminallerde genellikle iki ekran vardır: main screen ve alt screen
    • main screen daha çok shell ve scrollback’e, alternate screen ise Neovim’e ve çoğu TUI’ye yakındır
    • Bu yapı iki moddan birini açıp kapatma şeklindedir; genellikle tüm ekranı kaplar ve scrollback kaybedilir
    • Hashimoto, arka planda sınırsız sayıda ekran oluşturup doldurmayı sağlayan bir n-screen API tasarlıyor
    • Her ekran için farklı ızgara boyutları belirlenip üst üste bindirilebilir; terminal emülatörü satır kaydırma, seçim ve fare olayı yönlendirmesini işleyebilir
    • Belirli bir ekran bağımsız pencere olarak işaretlenirse terminal emülatörü onu ızgaranın dışında da render edebilir
    • Örnek olarak Neovim sekmelerinin yerel pencere sekmeleri gibi aynı anda açılabildiği bir biçimi verdi

  • Düğme protokolü

    • Mevcut fare protokolünde yalnızca kullanıcı mevcut ekrandaki ızgara hücresine tıkladığında olay alınabilir
    • Scrollback’e girmiş geçmiş öğelerinde tıklama olayı alınamaz
    • Terminal şu an hyperlink protokolü olan OSC 8’i destekliyor
    • Hashimoto, OSC 8’e benzer şekilde tıklanınca programa belirlenmiş bir mesaj gönderen bir düğme protokolü tasarlıyor
    • Örneğin open_profile ID’sine sahip bir düğme, kullanıcı geçmişe doğru scroll etse bile kayıtlı kalabilir
    • Bu özellik scrollback’i olan main screen uygulamalarını etkiler; Claude Code gibi main screen uygulamalarında dosya açma ya da uygulama içi linklerin geçmişe girdikten sonra çalışmaması sorunuyla bağlantılıdır

Standart eksikliği ve açık kaynak bakımı

  • Hashimoto, PTY protokolünün tamamını Wayland ile değiştirmeye yönelik bir deneme yaptı ancak bundan vazgeçti
  • Terminalin, pencereleri ve pencere widget’larını yöneten bir windowing server gibi görülebileceğini; Wayland’in yerel masaüstü ve pencere render etme sorununu çözen iyi bir protokol olduğunu düşünüyor
  • Terminalin sorunlarından biri artık bir standartlaştırma kuruluşunun olmamasıdır
  • Eski spesifikasyonlar hâlâ mevcut, ancak son 20 yıldaki standartlaşma en popüler terminalin ne yaptığına göre şekillendi
  • Sonuç olarak pek çok özellik birbirine karıştı ve zevk sahibi bir vizyonu ileri taşıyan bir aktör olmadığını düşünüyor
  • İleride izlenecek yol kesinleşmiş değil; terminal olmayan yeni bir metin tabanlı uygulama alanı oluşturup legacy uygulamalar için bunun üstüne bir terminal çeviri katmanı koymak da mümkün olabilir

  • Kullanıcı talepleri ile büyük vizyon arasındaki denge

    • Hashimoto, açık kaynak bakımcılarının kullanıcılara karşı 0 yükümlülüğü olduğunu açıkça söyleyegeldi
    • Açık kaynak lisanslarının ilk satırı “as is, no warranty”dir; ona göre kullanıcılar ücretsiz yazılım aldıkları için talepte bulunma hakkına sahip değildir
    • Aynı zamanda iyi yazılım yapmak istediği için sorunları düzeltme ve yazılımı daha iyi hâle getirme sorumluluğu hissettiğini söylüyor
    • Bazı günler issue’lara bakıp başkalarının sorunlarını çözüyor; bazı günler ise issue, tartışma ve PR’lara bakmadan kendi istediği şeye odaklanıyor
    • Her gün yalnızca kullanıcı issue’larını ele alırsanız kararlı ama durağan bir yazılım olur; tüm PR’ları kabul ederseniz yazılım değişir ama vizyon kaybolur diye düşünüyor
    • Çoğu katkının belirli bir kişinin sorununu kaşımaktan ibaret olduğunu, hepsi kabul edilirse kodun dağ gibi yığılacağını söylüyor
    • Buna karşılık sorun derinlemesine anlaşılırsa birçok özellik isteği tek ve zarif bir sistemle aynı anda çözülebilir
    • Özellik tasarımı videosunda, 3-4 ayrı özellik isteğini kapatıp bunları ve başka bir özelliği aynı anda çözen bir örnek verdi

  • Özellik zenginliği ile şişkinliği ayırmak

    • Ghostty’de en çok istenen özelliklerden biri olan arama uygulanıp yayımlandı
    • Bazı kullanıcılar aramanın Ghostty’nin minimalizmini bozup onu şişirdiğini eleştirdi; Hashimoto ise Ghostty’yi zengin özellikli bir terminal olarak tanıttığını söyledi
    • Özellik zenginliği ile şişkinliği birbirinden ayırıyor
    • Arama özelliği disk alanı ve RAM yüklemesi kullanır, ancak kullanılmadığında hiçbir kod çalışmayacak şekilde tasarlanmıştır
    • Bu yüzden, kullanmayan kullanıcılar için çalışma zamanı maliyeti olmayan bir özellik olduğunu düşünüyor
    • Ghostty, kullanıcının ihtiyacına göre özelleştirilebilen, varsayılan hâliyle de çalışan, ihtiyaç duyulana ya da aranana kadar özellikleri gizleyen bir terminal olmayı hedefliyor
    • Özellik kaldırma bayraklarının korunması taleplerine karşı, bakımcının o bayrağı yönetmesiyle kullanıcının özelliği kaldıran bir fork’u sürdürmesinin aynı türden bir talep olduğunu düşünüyor

Açık kaynağın hakları, Zig’deki değişim, API kalitesi

  • Hashimoto, kişisel fork’ların ve sürdürülen fork’ların çok daha fazla olması gerektiğine inanıyor
  • Girişim sermayesi destekli açık kaynağın; web sitesi, ücretli destek ekibi, Slack/Discord desteği olan iyi cilalanmış projeler bekleyen bir nesil yarattığını düşünüyor
  • Ancak açık kaynağın özü ürün garantisi değil, özgürlük ve haklardır
    • İstediğin gibi kullanma
    • Değiştirme
    • Fork etme
  • Kararlılık ya da bakım yükümlülüğü bu haklara dahil değildir
  • Güvenlik açığı içeren bir commit’in sorumluluğunun yalnızca bakımcıya yüklenemeyeceğini; kullanıcının da o commit’i incelememiş olma sorumluluğu bulunduğunu söylüyor
  • Daha güçlü garantiler ve birini suçlama hakkı isteniyorsa yazılıma ödeme yapıp satıcı-müşteri ilişkisi kurulması gerektiği görüşünde
  • Kişisel projelerde, kendisinin yaşamadığı hataları düzelten PR’ları da merge etmeyebilir
    • Çünkü merge etmek, o kodu sonsuza dek sürdürme sözü vermektir

  • Zig’e yaklaşımı

    • Hashimoto, Zig’i seçerken neyi göze aldığını biliyordu; derleyici patch’leri yaparken topluluğu, kültürü ve felsefeyi anladı
    • Henüz başlamamış I/O değişikliğinin Zig’deki en zor işlerden biri olacağını öngörüyor
    • Zig’in popülerliği artsa da Andrew gerekli gördüğü değişikliklerden geri adım atmıyor; Hashimoto aşağı akış kullanıcısı olarak bunu olumlu görüyor
    • Zig 0.15, writer interface’ini değiştirerek çıktı üreten neredeyse tüm kodu etkiledi, ancak API’nin kendisinin çok daha iyi hâle geldiğini değerlendiriyor
    • Zig, derleme araçlarına odaklanıyor ve derleme hızını artırmak için dil özelliklerini kaldırdığı da oldu
    • lib-ghostty’nin tüm terminali anında derlenebiliyor, ancak Andrew’un o milisaniyelik süreleri bile fazla yavaş gördüğünü söylüyor
    • Zig 1.0’a bir gün ulaşılacak, ancak bunun için hâlâ birkaç yıl olduğunu düşünüyor
    • Yapay zeka, dil değişikliklerinin aşağı akışta yarattığı acıyı azaltabilir
    • Farklı bağlamlarda değişikliğin nasıl yapılacağını gösterdikten sonra geri kalanını uygulatınca, büyük diff’in yaklaşık %90’ının otomatik işlendiğini söylüyor
    • A durumundan B durumuna nasıl gidileceği açıklanabiliyorsa, bunun geriye dönük uyumluluğun anlamının azalacağı bir geleceğe işaret ettiğini düşünüyor
    • Zig’in güçlü yapay zeka karşıtı politikasıyla ironik olsa da yapay zekanın değişikliklerin aşağı akış kullanıcılarına verdiği acıyı hafiflettiğini düşünüyor

  • Kütüphane ve API tasarımı

    • İyi kütüphane tasarımı için en somut yöntem, farklı topluluklardan pek çok kütüphaneyi doğrudan kullanmaktır
    • Gerçek işte kullanılmayacak programlama dillerini öğrenir gibi farklı ekosistemlerin kütüphanelerini kullanmak bakış açısını genişletir
    • Üniversite yıllarında Prolog, Haskell, Clojure ve Java ile oyuncak ürünler yaparken her ekosistemin build sistemi, kullanılabilirliği, kütüphaneleri, web framework’leri, web sunucuları ve uygulama sunucularını öğrendi
    • Her ekosistemin kültürünün, kütüphane ve framework’lerin sorumluluk ayrımına ve API biçimlerine sindiğini düşünüyor
    • Java’da uzun süredir kullanılan builder pattern’i Ruby’de denemiş ve iyi bulmuş olmasını kavram aktarımına örnek olarak verdi
    • Docker’ın dağıtım ve runtime tarafındaki birçok unsurun geliştirme akışına karıştığını gördüğünü; Vagrant’ta ise geliştirmeye doğrudan odaklanan isimleri, CLI’ı ve yapılandırmayı bilinçli olarak kullandığını söylüyor

  • Araç geliştiricisinin ikilemi ve teknoloji yığını

    • Hashimoto, hayatı boyunca araç geliştiricisi olduğunu ve araç geliştiricisinin ikilemine inandığını söylüyor
    • Bir sorunu çok iyi anlayıp ideal aracı yaparsınız; ancak araç popülerleşince gerçek kullanıcı olmaktan çıkıp zemini kaybetmiş bir araç geliştiricisine dönüşme sorunu tekrar edebilir
    • Terminalin kendisini her gün kullanıyor, ancak TUI geliştirmesini yeterince yapmıyor; bu yüzden birden fazla e-posta/IRC istemcisini sürdüren ve spesifikasyon da yazmış rockorager gibi bakımcılara dayanıyor
    • Mevcut teknoloji yığını konusunda tutumu “fena değil” düzeyinde
    • Frontend, TypeScript ve React tip topluluğunda iyi yanlar olsa da değişim çok fazla, karmaşıklık yüksek ve soyutlama katmanları net değil diye düşünüyor
    • HTTP/1’den HTTP/2 ve HTTP/3’e geçiş gibi, birçok alanda karmaşıklığın doğrusal olmayan şekilde arttığını söylüyor
    • Sektörün fazla hızlı hareket ederek daha basit olabilecek şeyleri karmaşıklaştırdığını; yapay zeka ve ilgili araçların bunu hızlandırdığını düşünüyor

İlkeler, kültür, kalite, öğrenme

  • Hashicorp ilkeler belgesi de Ghostty geliştirme tarzı da Hashimoto’nun kişisel yansıması olduğu için bunları her gün uygulamak kolaydı
  • Kendi kişiliğinizden farklı ilkeler koyarsanız, bunun yeni yıl kararları gibi gerçek davranışa dönüşmesinin zor olduğunu düşünüyor
  • Ghostty, çapraz platform çekirdeğe ve yerel GUI’ye birlikte önem veriyor
    • Çekirdek çapraz platform
    • GUI’de ise çapraz platformda ısrar etmiyor, platforma özgü yerel yaklaşımları tercih ediyor
  • Açık kaynak projeleri ve internetin farklı kabilelerin toplamı olması gerektiğini düşünüyor
  • Programlama dillerinin herkesin istediği özelliklere sahip en küçük ortak kat biçimindeki varlıklara dönüşmesinden hoşlanmıyor; kısıtların yaratıcılık ve kültür oluşturduğunu söylüyor
  • Rust’ın dilini ve felsefesini sevdiğini, ancak Rust kültürünü sevmediğini söyledi; bunun Rust topluluğundaki insanların kötü olduğu anlamına gelmediğini de ayırıyor
  • Zig’in teknoloji, topluluk yönetimi, fonlama, PR, blog yazıları ve konuşma tarzına kadar belirgin ve kutuplaştırıcı tutumları var; Hashimoto bu tuhaflığa saygı duyduğu için finansal destek vermeyi ve kullanmayı sürdürüyor
  • Kaliteli biçimde hızlı yayımlamak için belirli bir müşteri sorununu değil, kullanıcının o soruna nasıl ulaştığı bağlamı ve yukarı akış sorunlarını da anlamak gerekir
  • Bunu şirket ölçeğinde nasıl çözeceğini bilmediğini, ancak kendisinin yaptığı yazılımın büyük bir kullanıcısı olarak karar verdiğini söylüyor
  • Yapay zeka, demo veya yön kontrolü için kaba biçimde kullanılabilir; ancak yayımlanacak kod okunup anlaşıldıktan sonra kaliteli biçimde çıkarılmalıdır
  • C öğrenme meselesinde, dilin kendisinden çok bilgisayarın nasıl çalıştığını anlamak daha önemlidir
    • CPU scheduling, bellek, cache hiyerarşisi, dosya sistemi, disk ve dosya erişimi anlaşılmalıdır
    • C, Zig, Rust gibi syscall katmanının hemen üzerinde çalışıldığında neler olduğunu anlamak daha kolaydır
    • Python, JavaScript ve Ruby’nin dosya açma API’leri birçok ayrıntıyı soyutlar
    • Standart kütüphane fonksiyonları da doğal karşılanmamalı; bunlar da birilerinin yazdığı kod olduğu için doğrudan okunup nasıl çalıştığı kurcalanmalıdır diye tavsiye ediyor

İlgili okumalar

4 yorum

 
unsure4000 2 시간 전

Benzer bir zamanda yayımlanmış ama havası çok farklı olduğu için ilginç olmuş hahaha
Bun’ın Rust ile yeniden yazılması hakkındaki düşüncelerim
 
ffdd270 1 시간 전

Hahahahahahahahahahahahahahahahahahaha
 
GN⁺ 5 시간 전
Lobste.rs görüşleri

  • Harika bir röportajdı ve en sevdiğim cümle şu oldu: “Tamamen katılmıyorum ama kendinden emin biçimde tuhaf olma haline gerçekten saygı duyuyorum”
    Keşke bu tavır daha yaygın olsa

  • Önceki örnekler ve terminalin evriminden söz edilecekse Arcan ve cat9’un da en azından anılması gerekir gibi geliyor
    https://arcan-fe.com/2022/04/…

  • “PowerShell yapılandırılmış veriyi iyi işler” kısmını okuyunca Jörg W Mittag’ın şu yanıtı aklıma geldi
    Türlü argümanlar kullandığınızda tüm ayrıştırmayı PowerShell yapıyor
    Neovim sekmelerinin aynı anda yerel pencere sekmeleri olarak açıldığını hayal etmek de gerçekten harika
    C, Zig, Rust gibi dillerde sistem çağrısı katmanının hemen üstünde çalışmak, neler olup bittiğini anlamaya çok yardımcı oluyor
    Makine ile programcı arasındaki soyutlamaları söküp temel katmana ulaşma süreci eğlenceli ve insanı problemin özüne daha çok yaklaştırıyor
    Standart kütüphaneler genelde taşınabilirliği hedeflediği için işletim sistemi özelliklerinin en küçük ortak paydasını içeriyor; oysa platformdan sonuna kadar yararlanabildiğinizde programlama çok daha keyifli oluyor
    Standart kütüphane fonksiyonlarının da sonuçta birilerinin yazdığı kodlar olduğunu, onları sorgusuz kabul etmeyip okumak gerektiğini savunan tavra büyük saygı duyuyorum
    Ghostty’nin sponsorluk programı hakkında da daha fazla şey duymak isterim. Görünüşe göre kâr amacı gütmeyen bir yapı altında tüzel kişilik kazanmış; ne kadar başarılı ve kendi kendine yetebilir olduğunu merak ediyorum

  • Windows’taki PowerShell, bu tanıma göre tamamen içsel olma avantajına sahip, ama .NET framework’ü üzerine kurulu olduğu için neredeyse tüm Windows API’lerine erişip birlikte çalışabildiğinden pratikte çok da kısıtlı değil
    UNIX tasarım gereği dışsal ve anladığım kadarıyla Nushell’in yapılandırılmış yanıtı da katı biçimde içsel olduğu için genişletilebilirliği düşük
    Oils, dışsal yapılandırılmış birlikte çalışabilirlik için json ya da kendi uzantısı json8’e oynuyor, ama ikisi de PowerShell’e kıyasla epey sınırlı hissettiriyor
    Acaba herkes stdout üzerinden sadece msgpack gibi bir şey göndermekte anlaşsa ve tüm terminalleri birer msgpack görüntüleyicisine dönüştürsek nasıl olur diye düşünüyorum. Belki de libc’ye pipe serileştirme/seri çözme eklenmesi için kampanya başlatmak gerekir
    Sadece terminal standartlaştırma kurumları ortadan kalkmış değil; kabuk dünyasında da üretim ölçeğinde neredeyse hiç yenilik olmadı
    Bash hâlâ Kornshell’de zaten bulunan özellikleri ekliyor, Unix kabuklarında kimsenin nasıl kaldıracağını bilmediği fazla sayıda tuzak var ve POSIX neredeyse hiç kıpırdamıyor
    Oils ya da Nushell’in büyük dağıtımlar tarafından benimsenip insanlara bu alandaki yeniliğin iyi bir şey olduğunu fark ettireceği hayaline hâlâ tutunuyorum
    Yine de kitty terminal alanında kesinlikle yolu açtı ve eşgüdüm eksik olsa da en azından yeniliğin yaşandığı aşamaya gelmiş gibiyiz

  • Mitchell’ın sakin biçimde olumlu ve olumsuz yargılarda bulunmasına büyük saygı duydum
    Harika bir terminal yapıyor ve terminal arayüzlerini seviyor, ama terminalin her şeyi yapması ya da işin aşırıya kaçması gerektiğine katılmıyor
    Programlama dillerini ve topluluklarını derinden önemsiyor, her dilin kendine özgü bir karakteri olmasını istiyor; ama dillerin sonuçta bir amaca hizmet eden araçlar olduğunu ve alttaki anlayışın daha önemli olduğunu da biliyor
    Rust topluluğunu kişisel olarak sevmediğini kabul ederken, farklı hisseden insanları küçümsemiyor
    İnterneti birçok kabilenin toplamı olarak görüyor ama kabileciliğe ya da “tek gerçek kabileyi” aramaya kapılmıyor; oldukça Zen’e benzer bir tavır bu ve etkileyici

  • Daha fazla kişisel kullanım / bakım amaçlı fork olması gerektiği fikrine katılıyorum, ama bunun nasıl teşvik edileceğini pek bilmiyorum
    Hak görme duygusu yelpazesinin daha alt tarafında olanlar, ücretli destek sözleşmeleri gibi kurumsal şeylerle ilgilenmeyip sadece sevdikleri paket yöneticisinden doğrudan kurabilme rahatlığını istiyor olabilir
    brew install ya da apt install düzeyinden klonlanmış depolar ve build araçlarıyla uğraşma aşamasına geçerken oluşan ilk sürtünmeyi bir şekilde azaltmak gerekiyor
    Daha hızlı derleyiciler yardımcı olabilir
    Öte yandan güvenliğe duyarlı yazılımlarda kullanıcıların çok fazla değişiklik yapmaması daha yararlı olabilir; yani bazen o sürtünmenin kendisi bir özelliktir

  • n-screen ile düğme spesifikasyonu arasında bir yerde duran bir şeye modern kullanıcı arayüzlerinde ihtiyaç olduğu fikrine güçlü biçimde katılıyorum
    Belki buna anlamsal katman demek yeterlidir
    Bu katman olursa ajan tipi araçlar, ana ekran araçları, erişilebilirlik, birleştirilebilir widget’lar ve kontroller gibi şeyler mümkün hale gelir
    Sonuçta n-screen ile düğmeler, ne kadar içerik ifade ettiğinizin sol ve sağ sınırları gibi görünüyor
    İdeal olarak bu anlamsal katmanın çoklu imleç, karakter bazlı satır kaydırma yerine kelime bazlı satır kaydırma, overlay’ler (z-index, hücre harmanlama vb.) gibi şeyleri de getirmesi gerekir