SSH için yerel grafiksel kabuk

 (probablymarcus.com)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Sunucular ve uç cihazlar yalnızca terminal sunmak yerine tarayıcı tabanlı grafiksel bir kabuk sağladığında, başka cihazlardan uzak uygulamaları daha doğal şekilde kullanmak mümkün olur
  • Bu kabuk, bir uygulama ana ekranı ve uygulamalar arası URL sorgulama API’si sağlayarak dosyaları veya kaynakları uygun uygulamaya aktaran akışlar oluşturabilir
  • Uygulamalar arayüzlerini küçük HTTP sunucuları üzerinden sunar; ancak bunlar herkese açık genel web sunucuları değil, çoğunlukla SSH veya yerel erişimi varsayan özel sunucular olarak çalışır
  • Şifreleme her uygulama tarafından ayrı ayrı uygulanmak yerine SSH katmanına bırakılabilir; böylece her uygulama sunucusu az bağımlılığa sahip, basit bir yapıyı koruyabilir
  • Lewis bunun için Outer Loop’u bir SSH tarayıcısı olarak geliştirdi ve açık kaynak Outer Shell’i yayımladı; hem HTML uygulamalarını hem de yerel outerframe uygulamalarını hedefliyor

SSH üzerinde çalışan grafiksel kabuk

  • Web tarayıcısı, bir cihazın, yani sunucunun, başka bir cihaz olan istemciye deneyim sunduğu akışı zaten iyi yerleşmiş bir örnek olarak sunar
  • Aynı yaklaşım sunuculara ve uç cihazlara uygulandığında, uzak ortamlarda terminal tabanlı uygulamalar yerine grafiksel uygulamalar kullanılabilir
  • Kabuk, uygulamalar için bir ana ekran sağlar; her uygulama da küçük bir HTTP sunucusu üzerinden web kullanıcı arayüzü servis eder
  • Kabuk API’si, uygulamaların birbirlerinin URL’lerini bulmasını sağlayarak uygulamalar arası bağlantılar oluşturur
    • Örneğin bir uygulama kendisini metin düzenleyici olarak kaydederse, başka bir uygulamada bir metin dosyasına çift tıklanarak dosya o düzenleyici uygulamada açılabilir
  • Uygulama, mevcut HTML tabanlı bir web uygulaması da olabilir, yerel bir outerframe uygulaması da olabilir

Uygulama biçimi ve yayımlanan projeler

  • Uygulama HTTP sunucusu genellikle ağdaki diğer cihazlardan erişilemeyen özel bir sunucu olarak çalışır
    • Kullanıcı bunu SSH üzerinden ya da yerel olarak kullanır
    • Mevcut web tabanlı sunucu araçlarının çoğundan farklı olarak, localhost portlarından ziyade çoğunlukla Unix domain socket dosyaları kullanılır
    • Unix domain socket dosyaları portlara benzer, ancak dosya sisteminde bulunur ve açık kullanıcı izinlerine sahiptir
  • Her HTTP sunucusunun şifrelemeyi doğrudan ele alması gerekmez
    • Şifreleme SSH katmanında ele alınır
    • Bu sayede her uygulama sunucusu bağımlılıklar olmadan çok basit olabilir
  • Outer Loop bu tür bir grafiksel kabuk için SSH tarayıcısı olarak geliştirildi
  • Açık kaynak Outer Shell yayımlandı
  • İlgili dokümantasyon üç koldan sunuluyor
    • Outer Loop: tarayıcının çalışma biçimi
    • Outer Shell: Outer Shell API’si ve uygulama ekleme yöntemi
    • Outerframe: yerel uygulamaların çalışma biçimi
  • Tarayıcıda Unix socket bağlantısı gibi özellikler çok niş özellikler olarak görülüyordu; ancak SSH ve sudo farkındalığı gibi özelliklerle birleştiğinde yeni teknik olanaklar doğuyor
  • Jupyter ve Tensorboard gibi tekil sunucu tipi web uygulamaları ortaya çıktı; ancak her biri tek seferlik güvenlik protokolleri kullandığından, bunları “doğru” şekilde iletmek için ortak bir yöntem yerleşmedi
  • Yapay zekanın kod yazımına yardımcı olabilir hale gelmesiyle, her uygulamanın hedef platforma özel bir kod tabanına sahip olması pratik hale geldi; okuma ve hafif uygulamalar için HTML, iş amaçlı uygulamalar içinse platforma uyarlanmış yerel uygulamalar kullanan yapı, doğal bir web mimarisi olarak öneriliyor

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Hacker News yorumları

  • Bu fikri küçümseyen çok tepki olması epey sinir bozucu. HN okurlarının büyük kısmı hâlâ TUI üstünlüğü anlayışına saplanmış durumda ve GUI’ye pek ilgi göstermiyor gibi görünüyor
    İki nokta önemli. TUI, GUI’den özünde daha üstün değil ve SSH, bir aktarım katmanı olarak pty iletiminin, yani yalnızca TUI görüntüleme katmanının değil, GUI görüntüleme katmanının da desteklenmesini sağlamalı
    Aslında bu iki şey 30 yıl önce UNIX’te zaten hayata geçirilmişti; X protokolü ve ssh -X diye bir çözüm de vardı. Ama X kazanamadı ve uzak makineye ssh -X ile bağlanıp gnome-control-center çalıştırınca ayar penceresinin açılıp uzak bilgisayarı yapılandırabildiğiniz bir gelecek hiç gelmedi. Çalıştığını düşünüyorsanız kendiniz deneyin; deneyim berbat
    Yine de bu ihtiyaç hep vardı ve Jupyter Notebook gibi uygulamalar web sunucusu biçiminde geliştirilmeye başlandı. Web’in belge biçimi, stil sistemi ve istemci betik dili; sayısız kusuruna rağmen etkileşimli uygulamaların görüntüleme katmanı olarak kullanılabilir hâle geldi ve zaten uzak belgelerden doğduğu için ağ şeffaflığı da içine gömülü
    Electron uygulamalarına bakınca, HTML/CSS/JS yığınının masaüstü uygulamalarda da baskın konuma geldiğini kabul edip bunu SSH üzerinden uzak uygulama görüntüleme katmanı olarak kullanmak doğal görünüyor. Bu proje de o akımın bir parçası gibi
    Electron uygulamaları da X gibi bir görüntü sunucusu ve istemciye ayrılıyor; bunlara sırasıyla “renderer process” ve “main process” deniyor ve IPC ile haberleşiyorlar. Teoride uygun bir IPC taşıma mekanizması varsa main process ile renderer process’i farklı makinelerde çalıştırmak da mümkün olabilir; bu da bu fikirden çok farklı görünmüyor

    • Thinlinc, NoMachine, X2Go gibi şeyler de var ve hepsi SSH’yi ana backend olarak kullanıyor. Oldukça yaygın bir fikir
    • ssh -X, kullanılan toolkit’e ve mesafe/gecikmeye bağlı olarak iyi çalışır. Örneğin Gtk, rendering pipeline’ı nedeniyle iyi değil
      Mesafe ve gecikme yeterince büyüdüğünde, bunun kullanıcıya nasıl görüneceğini düşünmek gerekir. Çünkü kullanılan ortam ne olursa olsun fiziksel sınırlar aşılamaz. Uzak grafik erişimi vaat eden her araç, gecikmeyi hesaba katarak tasarlanmalı. Vim’in gecikmede de iyi çalışmasının nedeni, pratikte komutları kuyruğa alıp göndermesi
    • X forwarding gibi, Wayland’ı SSH üzerinde kullanabilirsiniz; buna waypipe deniyor. Yani o gelecek tamamen ölmüş değil
    • Şahsen ssh -X ile uzak makinede gnome-control-center açıp sunucu yapılandırılan bir geleceğin gelmemesine seviniyorum. Sunucuyu GUI ile yapılandırmak iğrenç bir yöntem ve umarım sadece Windows dünyasında kalır
    • İlk yorumun her zaman diğer yorumcuları suçlayıp onların düşüncelerini küçümsemesi de ayrıca sinir bozucu

  • Bu, geçmişte de çok gördüğümüz türden, kendine problem arayan bir çözüm gibi görünüyor. Aşağıdaki alıntı bu girişime iyi uyuyor gibi
    “Unix’i anlamayan insanlar, onu kötü biçimde yeniden icat etmeye mahkûmdur.” ~Henry Spencer

    • Bir programcı işe aldık, ona Linux dizüstü verdik ve birkaç ayar yapmasını istedik; birkaç saat sonra PuTTY’yi nereden indirebileceğini sordu. O an mülakatta büyük bir şeyi gözden kaçırdığımızı fark ettim
    • Öyle değil. Artık daha fazla insan Linux kullandığı için 40 yıl önce verilmiş kullanıcı deneyimi kararları daha çok sorgulanıyor
      Geliştiricilere yönelik makinelerin neredeyse hepsinde SSH sunucusu kurulu ve erişilebilir durumda
      Neden SSH terminali 1960’lardan kalma sadece metin gösteren bir çöp gibi görünmek zorunda? Neden SSH üzerinden aktarılabilecek en iyi hedef TUI olmak zorunda? Neden terminalde 4K film izleyemiyor ya da pinch zoom ile web’de gezinemiyoruz?
    • Biraz sert bir değerlendirme gibi duruyor. Gerçekte bir kullanılabilirlik boşluğu var ve bu proje de ona dokunmayı deneyen bir girişim
      Linux dizinlerini SSH üzerinden yerel UI bileşenleri olarak görme fikri mesela fena görünmüyor
      Ama bazı kısımlar da sshfs mount’u gibi zaten başka yollarla çözülmüş problemlere benziyor
    • “Unix’i anlamayan insanlar” kısmı aslında burada asıl temel sorun gibi geliyor
      Yıllar önce programlanabilir termostatlar hakkında bir yazı okumuştum. Çok derin yapılandırmaya izin verecek kadar güçlülerdi ama çoğu insan için kullanımları korkunçtu. Ana fikir şuna yakındı: “İnsanlar sizin anlaşılmaz sisteminizi öğrenmek istemiyor; o sistemin vaat ettiği faydayı istiyor.” İyi bir UI, bu boşluğu en aza indirmeyi bilmelidir
    • Bu, UNIX’ten çok Plan 9’a daha yakın görünüyor. UNIX’i fazla kutsamaya gerek yok

  • Grafik uygulamaların frontend ve backend’ini ayırma fikri güzel. Ama yeni saymak zor; belki benim kaçırdığım bir şey vardır
    X11Forwarding yes ya da html5 web app bilmiyor gibi görünüyor
    Tarayıcının Unix soketine bağlanması gibi özellikler, aşırı niş sayıldıkları için reddedilegeldi
    Bunun uygulanmama nedeni güvenlikti. En azından ham Unix soketleri için böyle; WebSocket ya da HTTP ile sınırlı başka portlar ise mümkün

    • Güvenlik hakkında kısaca yanıt vermek gerekirse, çeşitli Mozilla forumlarında gördüğüm tartışmalar kabaca şöyleydi
      Tarayıcının herhangi bir sokete bağlanmasına izin verilemez. Birçok soket açıkça tarayıcı bağlantısı istemez ya da tarayıcının bağlanabileceği gerçeğinin farkında bile değildir
      Bu yüzden bir tür izin listesi eklemek gerekir ve o noktada da bu kadar niş bir özellik için iş fazla karmaşık hâle gelir
      Yani asıl mesele niş olmasıydı diye düşünüyorum
      Bu arada Outer Loop bir izin listesi ekliyor: https://outerloop.sh/unix-domain-sockets/

  • Burada Outer Shell’in nasıl çalıştığını anlamaya çalışıyorum. Web sitesinde motivasyonu şöyle açıklıyorlar
    Jupyter veya TensorBoard gibi uygulamalar uzak bir sunucuda çalışıyorsa genelde standart web tarayıcısında görünmez. Çünkü bu uygulamaları tüm internete açık bırakmak çok risklidir. Bunun yerine sunucunun yerel portlarında çalışırlar ve benim bilgisayarım bunlara doğrudan erişemez
    Geleneksel olarak bunlara erişmek için yeni bir terminal açıp ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &, ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com & gibi komutlar çalıştırmak gerekiyordu deniyor
    Bu doğru mu? Genelde böyle SSH yönlendirmelerini yalnızca prototipleme sırasında kullanıp, dağıtıma geçtiğinde myjupyternotebook.com gibi bir site kurup başkalarının erişememesi için kimlik doğrulama eklemez misiniz? HTTP temel kimlik doğrulaması da o kadar büyük bir mesele değil
    HTTP yerine SSH üzerinden erişime açmak istiyorsanız, bunu VPN ya da tünel arkasına koymak gibi başka seçenekler de var
    Outer Loop çok havalı ama neden gerekli olduğunu pek anlamıyorum. Bir şeyi kaçırıyor olmalıyım; neden yapıldığını anlamama yardımcı olursanız sevinirim

    • Sunucu, SSH vb. kullanan insanlar arasında farklı kümeler var gibi görünüyor
      Ben daha çok derin öğrenme deneyleri, GPU çekirdek optimizasyonu ve robot geliştirme gibi kullanım alanlarına yakınım. Robot da hareket eden bir sunucudan ibaret ve bu gibi durumlarda açıkça uzak bilgisayar kullanıyoruz
      Bu kümedeki insanlara bu aracın önerilen akıştan daha sezgisel gelmesi muhtemel. Ama belki de kendi düşüncelerimi yansıtıyorumdur
      Bana bunun var olabilecek temel şeylerden biri gibi geldiğini söyleyebilirim. Bir tür uzak öncelikli grafik işletim sistemi hissi veriyor
    • Kullanıcı tek kişiyse ve o da kendisiyse, ayrıca hizmete yalnızca masaüstü işletim sisteminden erişilecekse, bunun ters proxy ve TLS sertifikaları ile uğraşma zahmetini azalttığı düşünülebilir
    • SSH ile çok sayıda port yönlendiriyorsanız, SSH’nin bir SOCKS5 proxy başlatmasını sağlama seçeneğini de düşünebilirsiniz
      ssh -D 4711 -q -C -N user@host
      Bu durumda localhost:4711, tarayıcınızda belirtebileceğiniz bir SOCKS5 proxy olur
      Elbette WireGuard VPN daha iyidir. Her şeyden önce SSH, tek bir TCP bağlantısı üzerinde çoklama yaptığı için, bir paket kaybolursa yeniden iletilene kadar tüm yönlendirilmiş trafik head-of-line blocking yaşar
    • HTTP temel kimlik doğrulaması güvenli değildir
    • SSH port yönlendirmesini en çok kullandığım durum, ağın bir yapılandırma hatası yüzünden bozulduğu zaman kurtarma yapmaktır

  • Yazarın Cockpit’i hiç duymamış gibi göründüğünü düşünüyorum
    “Yok” ya da “yeni” denilen şeylerin hepsi 10 yılı aşkın süredir Cockpit’te vardı. Soket tabanlı web sunucusu bağlantıları, sunucu uygulamalarında arka uç-ön uç ayrımı, hatta kabuk erişimi içeren bir sunucu konsolu fikri bile buna dahil
    “Bunun hâlâ olmaması garip değil mi?” sorusuna hayır derim. Çünkü bu zaten uzun zamandır var

    • “Nazik olun. Laf sokmayın. Sorguya çekmeyin, merakla sohbet edin. Alaycılığı silin.”
      İçtenlikle,
      HN yönerge polisi :-)
      https://news.ycombinator.com/newsguidelines.html
    • Yanılmıyorsam Cockpit bir web UI ve yerel kod çalıştırmıyor. Bu önemli bir fark
    • Ben de Cockpit’i hiç duymadım. O ne?

  • Güzel yazı. Kendi araştırmam için bunu yer imlerine ekleyeceğim
    Terminalimdeki “clickity clackity” işlevi [0] yerel makineye bağlı, bu yüzden uzaktaki bir sisteme geçtiğim anda grafik tarafı kayboluyor
    Bu durum çevrimdışı tekrar oynatma [1] sayesinde yavaş yavaş değişiyor. Yerel GUI ile TUI’nin birlikte çalışıp geri sarma gibi özelliklerin önünü açması şeklinde. Ama hâlâ gidilecek çok yol var ve başkalarının bunu düzgün biçimde denediğini görmek güzel. Terminal ciddi biçimde ihmal edilmiş bir alan
    [0] https://terminal.click
    [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

  • Terminale alışkın insanlar, üniversitede bunu öğrenmemiş biri için SSH’nin ne kadar düşmanca olduğunu unutuyor
    Bu, VPS yöneten küçük bir ekibin platform mühendisi işe almadan giriş engelini düşürmesine yardımcı olursa başarılı sayılır. Yalnız anahtarları ve jump host’ları nasıl ele aldıklarını merak ediyorum

  • Harika. Kesinlikle doğru yöne gidiyor
    Ön uç ile arka uç arasındaki ayrım katmanı, mümkün olan en küçük “parça”dan kesilmelidir
    Burada laf sokan pek çok kişi, gecikmeyi ve ek yükü bizzat “hissederse” bunu anlayacaktır. Veriyi tek tek kullanım durumlarına uygun şekilde dikkatle bölmek konusunda yeterince düşünülmemiş
    Dahası, demoda “ayarları sık sık değiştirerek yük oluşturduğu” söylenen top uygulamasında, istemci tarafında daha fazla render işleminin JIT yapılması gerektiğini düşünüyorum. Böylece Pi ile istemci arasında gidip gelen bilgi ps çıktısının sıkıştırılmış delta’sı kadar azaltılabilirdi

  • Bu yapılmamalı. Tarayıcıya genel soket izinleri verilmemesinin arkasında hem eski ve çok sağlam güvenlik gerekçeleri hem de web kontrol düzlemi izolasyonu ile ilgili çok sayıda neden var
    Mekanik olarak en yakın benzetme, 3 tekerlekli ATV’lerin neden kötü bir fikir olduğudur

    • Şu koşullarda bunun makul olduğunu düşünüyorum
      Soketler varsayılan olarak engellenmeli ve yalnızca sunucu tarafında açıkça izin listesine eklendikten sonra açılabilmeli
      Gerçek bir sudo farkındalığı olmalı; böylece sudo parolası olmadan root soketlerine erişilememeli. Bunun önemli olmasının nedeni, aksi halde insanları kullanıcı erişimine açık soketler üzerinde root arka uçları çalıştırmaya teşvik etmesidir
      Ayrıntılar burada: https://outerloop.sh/security/