Meta’da özel XR OS geliştirilmesine karşı John Carmack’ın itirazı

• John Carmack, Meta’nın özel XR OS geliştirmesine karşı olduğunu ifade etti
• Kendi işletim sistemini geliştirmenin karmaşıklığı ve riskleri artıracağını vurguladı
• Mevcut platformlardan yararlanmanın geliştirme verimliliği ve kaynakların en iyi kullanımı açısından daha etkili olduğunu savundu
• Carmack, pazarda hızlı inovasyon ve değişimlere yanıt verebilmek için standart OS tabanlı bir strateji önerdi
• Gereksiz teknik ayrışma ve parçalanmadan kaçınma gereğini vurguladı

---

John Carmack’ın Meta’nın özel XR OS’una karşı argümanları

Arka plan

• John Carmack’ın, Meta’nın kendi özel XR (genişletilmiş gerçeklik) OS’unu geliştirme planına olumsuz baktığı biliniyor
• XR OS, AR/VR gibi genişletilmiş gerçeklik cihazlarında çalışan işletim sistemini ifade eder

Temel argümanların özeti

• Carmack, hâlihazırda pazarda bulunan platformlar (Android, Windows vb.) üzerinde geliştirme yapılması durumunda geliştirme hızı ve inovasyonun daha da artacağını belirtti
• Özel bir OS geliştirmek; artan karmaşıklık, bug oluşma riski ve uzun vadeli bakım yükü gibi çeşitli sorunları beraberinde getirir
• Kendi platformunu kurmaya kaynak ayrıldığında, mevcut ekosistemlerin sunduğu standartlaşmış araçlar ve teknolojilerden yararlanma avantajı feda edilmiş olur
• Yeni teknolojilere ve kullanıcı taleplerindeki değişimlere daha hızlı yanıt verebilmek için mevcut OS’lardan aktif biçimde yararlanma stratejisinin etkili olduğu savunuldu
• Özel bir OS, hem geliştiriciler hem de tüketiciler için uyumluluk sorunları ve öğrenme maliyeti doğurabilir

Sonuç

• Carmack, uzun vadede teknoloji ve hizmetlerde parçalanmayı önlemek ve ölçeklenebilirlik ile kullanılabilirliği en üst düzeye çıkarmak için, özel XR OS geliştirmek yerine mevcut platformlardan yararlanma stratejisini tercih ediyor

[GN⁺]

Hacker News görüşleri

• Meta'da çalışmanın sorunu şu: eğer başarılı olursam, dünyayı daha kötü bir yer haline getirmeye yardım etmiş oluyorum… gerçek kahramanların para ve verimlilik harcayan insanlar olduğunu düşünüyorum<br>Yetenekliyseniz kariyerinizi başka bir yerde inşa etmenizi öneririm
  • Bir yazılım mühendisinin insanlığa hizmet etmesinin en iyi yollarından biri, Meta veya TikTok gibi şirketlere girip mümkün olduğunca uzun süre iş yapamıyormuş gibi davranmaktır
  • Ben Facebook ve ilişkili servisleri engelleyeceğim, ama zstd kullanacağım<br>Dünya siyah-beyaz bir mantıkla işlemiyor
  • Bu fazla basit bir bakış açısı Meta'nın ana işi hakkında ne düşünürseniz düşünün, şirket sosyal medyayla pek ilgisi olmayan çeşitli açık kaynak projelerinde, VR'da, veri merkezi teknolojilerinde ve diğer Ar-Ge alanlarında çalışmaları için çok sayıda mühendisi istihdam ediyor İlgi duyduğu alanda araştırma yapıp maaş almak için bundan daha kötü yollar da var bence
  • Bu biraz karamsar bir görüş ama bugüne kadarki verilerle buna itiraz etmek kolay değil
  • Ama aslında bu bütün büyük şirketler, hatta tüm halka açık şirketler için geçerli değil mi? Kurucuların başlangıçta başka hedefleri olmuş olabilir, ama zaman geçtikçe sonunda tek hedef kâr oluyor ve genelde kâr, kötü işlere odaklandıkça çok daha fazla artıyor Bu sistematik bir sorun
• Çeşitli düşük seviyeli yazılımlar, BSP'ler, hatta neredeyse tüm bir işletim sistemi yaptım; bugünlerde doğrudan OS yazmamamızın asıl sebebi silikon üreticileri Eskiden sürücüleri kendimiz yazabilelim diye ayrıntılı teknik doküman verirlerdi, şimdi ise belirsiz açıklamalar ve düşük kaliteli Linux sürücüleri fırlatıp geçiyorlar Bir kısmı tembellik, ama esas mesele karmaşıklığın artmış olması Modern donanım o kadar karmaşık ki her şeyi belgelemek bile uzun sürüyor; sürücüyü sıfırdan yazmak ise daha da uzun sürüyor
  • Intel hâlâ düzgün dokümantasyon veriyor Yüksek hızlı NIC'ler için çok ayrıntılı belgeler açık durumda ve örneğin e810 100Gb Ethernet kartı için resmi 2750 sayfalık datasheet ile sürücüyü sıfırdan yazabilirsiniz Diğer üreticiler ise ya (1) sizi görmezden geliyor, ya (2) NDA istiyor, ya da (3) sadece kötü Linux/FreeBSD sürücü belgeleri gösteriyor NVMe SSD gibi diğer donanımlarda durum nasıl bilmiyorum
  • Ben de yakın zamanda hobi amaçlı bir OS'te "soft reboot" düğmesini desteklemeye çalışırken gerçekten çok zorlandım ve sonunda vazgeçtim (GCP'de yeniden başlatma süresini hızlandırmak için) OS Dev Wiki yönergelerini, Linux ve FreeBSD kaynaklarını bile okudum ama hiçbir ilerleme kaydedemedim Bu, Windows ya da Linux'un yeniden başlatırken kullandığı bir özellik Birkaç günümü çöpe attıktan sonra sonunda bıraktım OS geliştiricileri gerçekten farklı bir kumaştan çıkıyor ve genelde ekonomik baskı altında yaşamıyor gibi görünüyor
  • İnsanlar sık sık “modern donanım belgelemek için fazla karmaşık” diyor ama bence bu tamamen bahane Takıma yeni çalışan eğitmeniz, test sürecini yönetmeniz de gerekiyor; yani işler karmaşıksa aslında daha ayrıntılı dokümantasyon yapmanız gerekir Dolayısıyla silikon üreticilerinin mazereti bana ikna edici gelmiyor
  • Bugünlerde ciddi ciddi kendi OS'inizi yapmak istiyorsanız, ya donanım üzerinde çok güçlü bir kontrolünüz olmalı ya da OS'in içine bir servant Linux instance gömmekten başka yol yok gibi Windows'un sürücüleri var ama sanki bug gibi; Linux'ta ise bedava bug'lı sürücüler var Eğer OS'inizin Linux hypervisor üzerinde istemci olarak çalışmaya devam etmesi sizin için uygunsa, bu bir yol olabilir; değilse donanım destek özelliklerini tek tek kendi OS'inize taşımaktan başka çare yok. Tabii bunun hızı, Linux'ta ortaya çıkan yeni bağımlılıklardan daha hızlı olmalı…
  • Belirli türde işletim sistemleri için, Linux'un donanım desteğinin çoğunu port edilmiş LKL(https://github.com/lkl/linux) ile ve donanıma erişim için birkaç hook ekleyerek kolayca almak mümkün diye düşünüyorum Elbette çekirdek platform/chipset kodunu ayrıca yazmanız gerekir, ama diğer I/O aygıtlarının büyük kısmı kapsanır Klasik monolitik kernel yerine kullanıcı modunda sürücü destekleyen bir yapıda daha iyi çalışır gibi duruyor
• John'un söyledikleri, gerçekten birilerinin inşa etmesini istediğim sistemi tam olarak tarif ediyor “Tamamen farklı bir bilgisayar yapmak istiyorsanız, mevcut çözümlerin çekim kuyusundan kurtulmak için fiilen münzevi keşişlerden oluşan bir mühendis topluluğuna ihtiyacınız var” Bir düşünce deneyi olarak:
• Aylık yaşam maliyetinin 200 dolar olduğu bir yer seçmek
• Yaşaması güzel bir kasaba kurmak (temiz hava, sağlıklı gıda, iyi okullar vb.) — zengin bir sponsor için bile fazla yük olmayacak şekilde
• Yazılımı ve interneti neredeyse hiç olmayan çok sayıda bilgisayar sağlamak
• Tamamen yeni bir bilişim modelini sıfırdan geliştirmeye çalışmak Anahtar şey sabır. Bu onlarca yıl sürecek
  • Bu fikir aşırı ilginç Böylesine düşük yaşam maliyetinin olduğu yerler nereler gerçekten merak ediyorum Ama asıl merak ettiğim şu: neden şu anda hemen uygulanamayacak bir problemi çözmeye çalışalım? CPU gibi donanımdan mı başlamak gerekir? Eskiden Intel'de çalışmış bir mühendisin dediği şeyi hatırlıyorum — modern ISA'ları, CPU uArch'larını, GPU'ları vb. tamamen öğrenip baştan inşa etmek ancak hepsini bizzat deneyimleyip bolca sürtünme yaşadıktan sonra, emekliliğe yaklaşırken mümkün olabilir
  • 10 yıldan uzun süredir kendi OS'imi yapıyorum; gerçekten bir şey ortaya çıkarmak istiyorsanız bu yapılacak iş değil Tabii eğlenceli. Bazen düşünüyorum: bir gün muazzam bir geliştirici ordusu katılsa ne kadar büyüyebilirdi. (Ama tabii para kazandırmaz)
  • Açıkçası bu müthiş bir bilimkurgu konsepti gibi
• Meta'da işletim sistemi tarafında Microsoft'tan gelmiş çok kişi var ve bu insanlar baştan beri OS yapmaya ilgi duyuyordu Ama Meta'da XR işlerine verildiler ve doğal olarak özel bir OS yapmak istediler
• John Carmack'ın Meta'da yaptıklarından sonra onu artık ciddiye almak zor SerenityOS tek başına, Windows veya Linux'tan daha kullanışlı ve daha tutarlı bir sistem yapmanın gayet mümkün olduğunu gösterdi Net bir vizyon, icra gücü ve adanmışlık; “üst düzey mühendis” istihdam etmekten ya da “yüksek kaliteli kod”dan daha önemli — bunlar varsa iyi kod ve iyi insanlar zaten peşinden geliyor Meta'da bunun imkânsız olmasının ve Linux'un bugün bu halde olmasının nedeni de bu Gerçek engel sonuçta sürücüler. Referans: Thirty-Million line problemi — caseymuratori.com blogu
• Oculus satın alımından sonra burada çalışırken XROS, çekirdek teknoloji ekipleri için gerçekten zahmetli ve dikkat dağıtıcı bir unsurdu Çözülmesi gereken sorunlar zaten pek çok teknoloji yığınında dağ gibiydi; XROS fikri ise Oculus'un FB'ye tamamen entegre olmasından sonra ortaya çıktı Bana göre FB içindeki bazı ekipler (veya kişiler) ARVR trendine atlamak istiyordu Carmack tamamen haklıydı ve yeniden yapılanmadan sonra etkisinin giderek azaldığını, bunun kötü sonuçlarını bizzat gördüm
  • XROS ekibinin büyük kısmı FB merkezinden değil, sektörden kıdemli olarak işe alındı (çoğu E5/E6 seviyesi) FB SWE'leri teknik olarak uygun değildi; aralarında bootcamp çıkışlı olanlar da vardı ama başarılı olamadılar ve kısa sürede başka yerlere geçtiler
  • Oculus açık kaynak topluluğunu mahvetmelerine ve topluluğun para toplayarak desteklediği projeyi bir Meta zincirine daha dönüştürüp kullanıcı verilerini toplamasına öfkeliyim Yine de maaş çeklerinin dolgun olduğunu umuyorum
• 2002–2004 civarında Microsoft'ta, birkaç OS geliştiricisinin Bill Gates'in Think Week'i için hackathon tarzında yazdığı bir iç makale okumuştum .NET temeli üzerinde çalışan, GC ve bellek yönetimini de kendi içinde barındıran tamamen yeni bir işletim sistemiydi; çeşitli donanımlarda açılabiliyor ve ilginç özellikler sunuyordu Tasarımı gereği Windows ile açıkça sıfır uyumluluğa sahipti; muhtemelen başarısız olmasının nedeni de buydu Birkaç OS uzmanının yaklaşık bir ay odaklanarak ortaya çıkardığı bir şeydi ve gerçekten çok eğlenceliydi
  • Singularity miydi? Wikipedia açıklaması<br>Microsoft Research resmi sayfası
  • Sanırım Midori projesiydi Aslında Microsoft Research içinde yıllarca süren ve 100'den fazla kişinin çalıştığı büyük bir projeydi ZDNet'in Midori projesi haberi
• John Carmack'ın, XROS ekip yöneticisini “takım üyelerinin duygularını incitiyor” diye HR'a şikâyet ettiği söyleniyordu Aslında Carmack'ın kamusal iletişiminde bana hep profesyonel ve nazik biri gibi geldi Ben de benzer bir HR'nin silah olarak kullanılması deneyimi yaşadım; böyle şeyler şirket kültürünü donduruyor — bir kez birinin söylediklerinizden hoşlanmadığı için sizi HR'a şikâyet edebileceğini düşündüğünüzde, sonrasında herkes konuşurken aşırı dikkatli oluyor
  • Carmack ayrılmadan önceki iç yazılarını takip ediyordum; kaynak israfı konusunda son derece katıydı ve el takibi özelliği sık sık bozulduğunda bunu metriklerle işaret ediyordu Mesajı hep şuydu: “Apple donanımı kontrol ettiği için, geleceğin anahtarı artık verimli yazılım” ve Meta'nın savrukluğu da sonuçta kurum içi güç savaşlarından kaynaklanıyordu
  • Lucovsky, gerçekten sıfırdan bir OS yapmakta ısrar etti ama sahadaki ürün ekiplerinin müşterilere gerçekten bir şey teslim etmek zorunda olduğu gerçeğini göremedi; bu yüzden kenara itildi Arkasında bıraktığı toksisite (kendisi ciddiyetinin farkında değildi) de etkili oldu Benzer davranışlar Google'da da tekrarlandı; orada da sonunda kenara itildi ve resmiyette kendi isteğiyle ayrılmış gibi kapatıldı Twitter referansı 1 Twitter referansı 2
  • John, yüz yüze görüşmelerde gerçekten çok doğrudan ve keskin olabiliyor İnanmadığı işlerde aşırı eleştirel olabiliyor ve böyle anlarda güç dengesi nedeniyle ona karşı çıkmak da zor oluyor
  • O dönemde Meta'nın iç ortamı biraz tuhaftı PSC (performans değerlendirmesi) önemliydi; Carmack gibi efsanevi bir figürün benim projem için “kaynak israfı” demesi, değerlendirmede doğrudan büyük darbe anlamına geliyordu “Etki”, Facebook'ta “bu şirkete ne kadar faydalı” olduğunu ölçen önemli bir eksendi
  • Google'da da benzer bir sahne gördüm Distinguished engineer, junior bir mühendise önce yumuşak, sonra gayet net biçimde “bu kötü bir fikir, bırak” dedi ve sonrasında HR devreye girdi Böyle durumlarda, artık zaman ve emek harcamak istemediğim için bazı sorunları olduğu gibi bıraktığım da oldu
• Google'da Flutter ekibi Fuchsia'yı yaparken oradaydım Gerçekten olağanüstü insanlardı (gördüğüm en iyi mühendislerden bazılarıydı), sayıları da yüzlerceydi ve proje çok büyüktü Teknik olarak son derece etkileyiciydi, ama en başından beri kimlerin bunu kullanacağına dair net bir cevabı kimse veremiyordu Sadece kernel'i yenileyip mevcut Linux'u değiştirmek gibi bir hedef olsaydı anlaşılabilirdi; ama onun yerine kernel'den UI'a, window manager'a kadar işletim sisteminin tüm katmanlarını sıfırdan yapmaya çalıştılar Sonunda Home Hub gibi yalnızca UI odaklı özel cihazları hedeflediler; ama orada bile mevcut ürünlere kıyasla neden böyle karmaşık bir OS değişimine ihtiyaç olduğunu gösteremediler Fuchsia'nın hâlâ devam ediyor olması bana hâlâ inanılmaz derecede mantıksız geliyor Google yeniden yapılanırken kritik ekiplerin kaynaklarını kesip böyle projelerde insan tutmaya devam etmiş olması ise daha da moral bozucu Açıkçası bunun neden hayatta tutulduğunu gerçekten anlamıyorum
  • Kısa vadeli sonuçlara bakarsanız savunması zor, ama uzun vadede yeni bir OS geliştirmek gayet makul olabilir Google gerçekten uzun vadeli yatırımlarla ilgilenen bir şirket ve projelerin dışarıya gerekçe sunması şart değil Bunu eleştiren taraf olmak bence daha tuhaf. Gerekliyse katılırsınız, değilse görmezden gelirsiniz Yeni bir uygulama ekosistemi yaratmak zaten başlıca hedef değildi; asıl zor olan, normalde varlığını doğal kabul ettiğiniz sayısız teknolojiyi baştan uygulamak zorunda olmanız Zor, ama imkânsız değil Seçeneklerin artması kötü olmaz — tarayıcı pazarında çeşitliliğin önemli olduğunu söyleyip OS pazarında tekeli normal görmek çelişkili olur; daha fazla OS, daha iyidir
  • Sanırım bazı cihazlar (Home Hub) başlangıç noktası olarak seçildi ve oradan deneyim/gelir kazanıp kademeli şekilde genişlemek amaçlandı Her şeyi tek seferde değiştirme iddiasıyla başlanmış olduğunu sanmıyorum
  • Ben Fuchsia'yı, birden fazla OS ve uygulama paketinin tam konteyner olarak çalıştığı yeni bir paradigma gibi anlamıştım Hayalimde, web'de de çalışabilen ve birden fazla makinede birlikte çalıştırılabilen geleceğin OS'i gibi bir şeydi Aynı makinede birden çok instance çalıştırıp her birini farklı kullanıcılara uyarlama fikri de heyecan vericiydi
  • Bana hep Fuchsia'nın, Google'ın harika kernel mühendislerini rakiplere kaptırmamak için sürdürdüğü bir tür yıpratma projesi olduğu hissi verdi
  • Home Hub'a Fuchsia'yı zorla geçirdiler; mevcut stack anında legacy oldu ve sonrasında takvim sürekli kaymasına rağmen hiçbir sonuç çıkmadı Kendi OS'ini yapmak havalı görünüyordu ama bütün proje, geri kalan ekiplerin işine zarar vermekten başka bir etki bırakmamış gibi geldi
• Günümüzde Linux kernel'i bypass edip doğrudan donanıma erişmek daha kolay hale geldi ve çok çekirdekli CPU'lar da artık yaygın Temel fikir, çekirdekleri izole edip thread'leri oralara atamak; ardından kernel bypass teknikleriyle donanımı doğrudan kontrol etmek. Çekirdekler arası iletişimi ring buffer ile kurarsanız, neredeyse donanıma özel optimize edilmiş performans elde ederken Linux kernel'inin yönetim/izleme/debug avantajlarından da yararlanabilirsiniz
  • Fiziksel belleğe doğrudan erişmek için /dev/mem'i mmap etmek gibi, kernel bypass her zaman mümkündür