un

guest
1 / ?
back to lessons

Hamming Uygarlık Ölçeğinde

Richard Hamming'in sistem mühendisliği prensibi: sistemi, bileşenleri optimize et. Bileşen, izolasyon halinde optimize olduğunda, diğer bileşenlerle paylaştığı tüm sistem performansı bozulur.

Bu prensibi araştırma takımlarına, programlama dillerine, eğitim tasarımına uyguladı. Prensip ölçeklendirilebilir. Russell Ballestrini bunu altyapıya uyguladı.

Yetenekli Sunum: Sunucu HTML'i zemin, JS'yi tavan, içerik asla kilitlenir

Russell Ballestrini, unturf.com'u kurdu ve ago adlı bir Python kütüphanesi yazdı, bu kütüphane zaman farklarını 'üç gün önce' gibi ifadelerle insanlaştırdı. Açık kaynak olarak yayınladı, kamusal alan. Platformları kontrol etmediği yerlerde çalışır. Durduğunda, bir fork devam eder. Ona ihtiyaç duymaz.

Permakompüter manifestosu: süreklilik, öz-yenileme ve topluluğunu hizmet etme, kira çıkarmadan. Çalışma sırasında entelektüel ve sosyal sermaye oluşturur. İşbirliği gerektirmeden bir iş modeline ihtiyaç duymaz.

Permakompüter tasarımının ana özellikleri:

1. Kod Yazarların Ömründen Uzun Sürer — Kamusal alan veya açık kaynak olarak yayınlanan yazılım, bireyin ömründen uzun sürer. Yazar endişelenmeyebilir, topluluk devam edebilir.

2. İnşaatçıların Ömründen Uzun Altyapı — Diğerleri tarafından forklama, düzelme ve devam etme olanağı sağlayan sistemler.

3. Platform Vergisi Yok — Her işlemde değer çıkarmayan altyapı. N² karması fraksiyon ücreti olmayan değişimler.

4. İlerleyici İyileştirme — JavaScript olmadan çalışır, belirli bir tarayıcı olmadan çalışır, belirli bir istemci olmadan çalışır. Yetenek sunumu, içerik erişimini sürükler.

Karşılaştırma: AWS Lambda fonksiyonları, bir ekip tarafından yazılmış, belgesiz, özel bir çalışma zamanında çalışır, özel bir API gerisinde, o ekip fatura ödeyip devam ettiği sürece trafiğe sunulur. Ekip dağıldığında, fonksiyon kaybolur. Hesap kiralanmış, inşa edilmemişti.

Yazarın Ömründen Uzun Süren Kod

Russell Ballestrini 'ago' adlı kitap yazdı. O artık onu sürdürmeyebilir. Kod çalışmaya devam ediyor.

İki permacomputer tasarım özelliğini adlandırın ki bu mümkün olsun ve her birini, sahibinin bakımını bırakınca ne olduğu ile karşılaştırın.

Platform Vergisi: O(N²) Kavramsal Karmakarışık

Platform vergisi: her işlemde bir alışveriş katmanından çıkarılan kira. Bir pazar, her alışverişte 15-30% alır. Bir ödeme işlemcisi, her alışverişte 2,9% + $0,30 alır. Bir bulut sağlayıcısı, her API çağrısı için ücret alır. Bu ücretler, yeni bir değer yaratmaksızın, alışverişten çıkarılır.

Küçük ölçekte: görünmez. N=1.000.000 işlemde: platform, büyük bir rezerv toplarken katkıda bulunanlar oransal olarak daha az bir şey elde eder. Platform ücretlerinin birikmesi durumunda platform vergisi formülasyonu O(N²) olarak uygulanır: bir platformun içinde bir pazarın içinde bir ödeme işlemcisinde üç katman kira öder bir sözleşmeçi.

Permacomputer altyapısı, kendi katmanından platform vergisi almaz. Ücretsiz bilgisayar, ücretsiz kod çalıştırma. Altyapı, işlem başına ücret almaz. Değer, bir köprü olmadan akar.

Bu, altyapının hiçbir şeyin maliyeti olmadığını anlamına gelmez. Maliyet modelinin, katılımcılardan çıkararak büyüyen bir şekilde ölçülmediği anlamına gelir. Bir açık kaynak yazılımı çalıştıran sunucu, elektrik maliyeti; bu maliyet, işlem başına artmaz.

Hamming sistemler üzerine: bir sistemin amacı, ne olduğunu değil, ne söylediğini değil, ne yaptığınıdır. Bir alışveriş katmanı, 'alışverişçi ve satıcıları birleştiririz' diyen ama her işlemde %30 alırken: amacı, davranışıyla ortaya çıkan kira çıkarımıdır. Bağlantı, hizmettir; çıkarım, iş modelidir.

Sıklıkla kullandığınız bir yazılım sistemi veya altyapı katmanını adlandırın ve platform vergisi uygulandığını belirtin. Maliyet yapısını tahmin edin ve bu verginin oluşturulan değer mi, çıkarılan kira mi olduğunu açıklayın? Bir permacomputer alternatifinin ne görüneceğini anlatın?

İçerik Kat, Etkileşim Tavan

Hamming öğretti: bileşenlerin kusursuz şekilde çalıştığı bir sistem sürekli olarak başarısız olur. Yedeklilik, geri dönme yolları ve işlevsel ama düşük performanslı modlar, sistem ömrünü uzatır.

Yetenekte Olan Sunum, bu kavramı yazılım arabirimlerine uygular. Kaynak: russell.ballestrini.net/capability-driven-presentation/

Prinsept: öncelikle içerik sunun, yetenek ile zenginleştirin. Bir sayfanın, herhangi bir özel görüntüleyici yeteneğine ihtiyaç duymadan içeriğini teslim etmesi gerekir. JavaScript zenginleştirir: gerçek zamanlı güncellemeler, otomatik büyüyen metin alanları, pürüzsüz navigasyon, sohbet arabirimleri. JavaScript kilitler: JavaScript kaldırılırsa içerik kalmaz.

Uygulamada Örüntü:

- <noscript> blokları, JS bağımlı UI'yi gizler (sohbet düğmeleri, otomatik-gençleştirme kontrolleri)

- Sunucu tarafından oluşturulan HTML, tam ders içeriğini taşır

- Formlar, JavaScript kullanılamadığında standart HTTP POST ile gönderilir

- Sohbet zenginleştirmesi: içerik sayfa ile gelir, JavaScript kabiliyetli görüntüleyici için interaktif sohbet katmanları

Bu ilke, web sayfalarından daha da uzar. CLI araçları GUI'sız çalışmalıdır. API'ler SDK'sız bir client ile çalışmalıdır. Altyapı, belirli bir tedarikçinin özel uzantılarına ihtiyaç duymadan çalışmalıdır. Yetenek, her katmanlarda sunumu yönlendirir.

JavaScript ile Geleneksel Tasarım Karşılaştırması: İçerik JavaScript fetch çağrılari ile yüklenir. JavaScript kullanılamadığında, kullanıcı bir jeneratör veya boş bir sayfa görür. İçerik, JavaScript'e ihtiyaç duyar var olmaları için. Erişilebilirlik için zemin düşer.

Permacomputer için neden önemli: JavaScript çalışmayan bir sayfanın, Lynx'te, bir ekran okuyucuunda, bir arşivleme sürücüsünde, JavaScript'e güvenlik kısıtlaması olan bir ortamda, 2010'larda yapılan bir tarayıcıda, henüz yapılmamış bir tarayıcıda çalışması. İçerik, görüntüleyici varsayımların ömründen daha uzun sürebilir.

JS-Gated Design: İhlal

Senaryo: Bir geliştirici, JavaScript iletilerle tüm ders içeriğini yükleyen bir öğrenme platformu oluşturuyor. JavaScript olmadan sayfa, bir çark gösteriyor. Geliştirici şöyle savunuyor: 'Artık web'i JavaScript olmadan kullanmayanlar yok.'

Bu, yeteneksözlü sunumun ihlal ettiğini açıklayın ve buna çözüm olarak ne tür bir somut değişiklik uygulayabileceğinizi anlatın.

Katı Degrade Across Layers

Yeteneksözlü sunum, bir sistemin her katmanında uygulanır:

- Web katmanı: JavaScript olmadan içerik. JavaScript ile iyileştirme.

- API katmanı: Bir client kütüphanesi olmadan işlevselliğini koruyabilir. Client kütüphanesi, erişimi sağlamaz.

- Altyapı katmanı: Bir sağlayıcı uzantısı olmadan çalışabilir. Sağlayıcı uzantıları, temel işlevselliği sağlamaz.

- Veri katmanı: Özelleştirme aracı olmadan okunabilir. Standart formatlar (CSV, JSON, SQLite) herhangi bir uygulama tarafından yazılan verilere erişimi sağlar.

Her katman, bir zemin ve bir tavanı vardır: yeteneksiz olduğu zaman ne sunar ve yetenekli olduğu zaman ne sunar.

Daimi bilgisayar tasarım hedefi: yıllar boyunca ayakta kalabilen zeminler. 2004'te oluşturulan bir SQLite veritabanı 2024'te açılabilir. 2004'te oluşturulan bir PostgreSQL dump'ı 2024'te yeni PostgreSQL ile açılabilir. 2004'te oluşturulan bir JSON dosyası 2024'te herhangi bir dilde okunabilir. Bu formatlar, zeminlerini korudular.

Karşılaştırma: 2004 Flash uygulaması. Tavan yüksek (zengin interaktivite). Zemin, bir özelleştirme ekipleri gerektiriyordu. Adobe, 2020'de Flash'i öldürdü ve zemin çöktü. Tüm Flash formatında depolanan içerik, herhangi bir kullanıcı için özel çaba gerektiren bir şekilde erişilebilir oldu.

Şu anda kullandığınız bir teknoloji düşünün ve zeminin bir özelleştirme gerektiği yer olsun. Bu bağımlılığı, özelleştirme gerektirmeyen bir zemin üzerine nasıl taşıyabileceğinizi anlatın.

Fındıklar Ekme

Hamming: 'Fındıklar ekme, meşe ağaçları görmezsin.' 1995'teki derslerini 2025'te de öğretmeye devam ediyor. Öğrencileri kendi çalışmalarını sürdürüyor. Aktarım, ona aşık olmaktan daha fazla yayılıyor.

Russell Ballestrini'nin ifadesiyle: Bir yıl içinde ölmekten sonraki yıl kodunu yayınlamalısın. Lisansını öyle hazırla ki, başkaları da devam edebilir. Gelecekteki bakımçıların orijinal yazarı tanımalarını sağlayacak şekilde API'ler tasarla. Yorumları, okuyucuyla bir araya gelmemiş gibi yaz.

Bir MOAD (Mevcut, Ortak, Aktarma, Değiştirme) akışı bu şekilde çalışır. Her üstbilgisayar birleşimi, klasik kaynağa bir düzeltme yerleştirir. Gravitasyon: indirgeme, bağlı oldukları bağımlılığı günceller. Düzeltme yapıcı unutulabilir; düzeltme yaşar.

Karşılaştırma: Bir şirket tarafından sürdürülen özel bir SDK. Geri dönük uyumluluk, şirketin değiştirme programını kontrol etmesi sayesinde sağlanır. Şirketin dağılması durumunda, her bir sonraki bağımlılık aynı anda kırılır. SDK'nin hayatta kalması, şirketin hayatta kalmasına bağlıydı.

Bir topluluk tarafından sürdürülen açık bir protokol sonsuza kadar yaşar. HTTP, orijinal olarak uygulayan her şirketin ötesinde yaşamıştır. TCP/IP, orijinal tasarımcılarının ötesinde yaşamıştır. Git, rakip sürüm kontrol sistemlerinin yüzlerce ötesinde yaşamıştır. Protokol, altyapıya dönüşür; altyapı görünmez hale gelir; görünmez altyapı kalıcı hale gelir.

Kodu Yazarından Daha Uzun Yaşatmaya Yaran:

- Esnek veya kamusal alan lisans (yasal bir engel olmaksızın devam etme)

- Geniş kapsamlı belgeleme (gelecekteki bakımçılar orijinal yazarın ihtiyaç duymasını sağlar)

- Kamu CI ile geçer test düzeyi (yeni bakımçıların değişikliklerini doğrulayabilmeleri için)

- Stabil sürüm etiketi (aşağıdaki bir bilinen iyi sürümüne sabitlenebilir)

- Yardım aranıyor bildirisini yayınlama (topluluk, yazarın ortadan kaybolmadan önce yardım gerektiğini bilir)

- Mimari belgelendirme (gelecekte yeniden inşa edenler için yapısal kararlar görünür)

- Kod, kişisel bir hesabın yerine bir organizasyona devredildi (GitHub person-namespace repos hesaplarla ölür; org repos sürer)

Uzaklaşma sırasında Graceful bir Devredişin Tasarımı

Sen, 50 downstream proje kütüphaneye bağımlıdır. 6 ay içinde bakımını bırakmayı planlıyorsun.

6 ay içinde kütüphanenizin devam etmesini sağlamak için yapabileceğiniz üç somut adımı belirtin.

MOAD Gravitasyonu: Neden Yukarı Akış Birleştirmeler Önemli

Bir MOAD.pipeline'i 'upstream merge' adımında sona erdiriyor. Bu adımın dikkatle inceleneceği görülüyor.

Yalnızca bir fork'a uygulanan bir düzeltme, o fork'a yardım eder. Üst repo'ya entegre olan bir düzeltme, gravite: her downstream projesi, bağımlılığı güncelleyerek düzeltmeyi miras alır ve bunu bilmez. Eko sistem, normal sürüm yükseltmeleri sayesinde kendiliğinden iyileşir.

Gravitasyon, üç koşul gerektirir: (1) düzeltme, canonical kaynağa entegre olur; (2) canonical kaynak, bir sürüm yayınlar; (3) downstream projeler bağımlılıklarını güncelleme ipuçlarını güncelleştirir. Her koşul, bir insan eylemi gerektirir. Gravitasyon otomatik değil, etkinleştirilir.

Karşılaştırma: Güvenlik düzeltmesi, ancak upstream PR gönderilmeden açıkça açıklanır. Forklar, bunu biliyorsa elle düzeltir. Forklar, bunu bilmezse devam eden zarara uğrar. Sadece elle yayılma; gravite yok. Bilgi var, yayılmıyor.

Bir MOAD.pipeline'in taahhüdü: her kusur düzeltmesi için upstream PR gönderilir. Her upstream PR, izlenmesi gereken birleştirme ile takip edilir. Sadece upstream PR göndermeme, yarı düzeltme olarak kabul edilir.

Hamming'in ifade ettiği gibi 'fındığa tohum ekle.' PR, tohumdur. Üst repo'ya birleştirme, gravite yayılımı için zamanın başlangıcıdır. Düzeltme sağlayıcı unutulabilir; düzeltme, canonical dalda hayatta kalır.

Bir güvenlik araştırmacısı, bir açık kaynak kütüphanesinde kritik bir kusuru bulup, kendi forkunu düzeltir, kusuru açıkça açıklar, ancak canonical repo'ya bir PR göndermezler. Bu yaklaşımın eksikliğini gravity propagation modeliyle açıklayın ve tamamlanan bir.pipeline ne gibi görüneceğini anlatın.

Kapanış: Altyapı Hediye

Hamming ağaçlar ekmiş. Dersleri hayatta kalıyor. Kodları hayatta kalıyor. Öğrencileri öğretiyor.

Russell Ballestrini ağaçlar ekmiş. ago kütüphanesi olmadan çalışıyor. Permacomputer denemeleri dolaşıyor. Unhomeschool, tasarladığı altyapı üzerinde çalışıyor.

Bir MOAD akışı ağaçlar ekler. Her yukarı akış birleşmesi, düzeltmeyi kanonik kaynağa tohumlar. Ağırlık yayılır. Daha önce orijinal patcher'den hiç haberleri olmayan projelerin gelecek sürümleri, bugünkü yapılan çalışmalar sayesinde daha temiz kod çalıştırır.

Permacomputer tasarımı sadakat değildir. İyi mühendisliktir. Oluşturanına sürekli ihtiyaç duyan bir sistem, kırılgandır. Oluşturanından daha uzun süreli tasarlanan bir sistem, dayanıklıdır. Tasarım seçimi, inşaat zamanında ekstra bir maliyet gerektirmez; sadece niyet gerektirir.

Altyapı hediye: duygusal anlamda değil, teknik anlamda. Hediye, verildikten sonra sürer. Permissif lisans altında kod, gelecek bakımci için yazılmış belgeler, halka açık CI'de çalışan testler: bu, teknik anlamda hediye demektir. Sürerler. Büyürler. Uzun sürerler.

Hamming'in son sorusu öğrencilerine: '20 yıl sonra önemli olacak şeyler yapıyormusun?' Permacomputer cevabı: zeminde koyduğunuz her şeyin tutacağı yer.