Asterinas - Yeni bir Linux uyumlu çekirdek projesi

 (lwn.net)
8 puan yazan GN⁺ 2025-06-23 | 2 yorum | WhatsApp'ta paylaş
  • Rust ile yazılmış Linux ABI uyumlu bir çekirdek; “framekernel” mimarisini uygulayarak monolitik çekirdek ile mikrokernelin avantajlarını birleştirmeyi hedefliyor
  • Tüm unsafe kodu sınırlı kütüphaneler içinde kapsülleyip kalan çekirdek servislerinin güvenli Rust soyutlamalarıyla geliştirilmesini sağlayacak şekilde tasarlanarak, bellek güvenliği ile basit paylaşımlı bellek yapısını aynı anda elde etmeyi amaçlıyor
  • RedLeaf, Tock, Rust for Linux gibi mevcut Rust OS projelerinden farkı; donanım izolasyonu desteği, genel amaçlı kullanım, Linux uyumlu ABI ve kullanıcı alanında farklı dillerin çalıştırılması
  • TCB'yi (güvenilir hesaplama tabanı) küçültme ve resmi doğrulama (Verus kullanımı) hedefi, Intel TDX gibi güvenilir yürütme ortamı donanımı desteği ve ayrıca OSTD/OSDK gibi OS geliştirme çerçeveleri sunması
  • Hâlâ erken geliştirme aşamasında; x86/RISC-V desteği ve 206 sistem çağrısı uygulanmış durumda, Docker/konteyner/bulut ortamlarına odaklanıyor ancak X11/Xfce gibi masaüstü genişlemelerini de deniyor

What's Asterinas?

  • Asterinas, Rust ile geliştirilen yeni bir Linux ABI uyumlu çekirdek projesidir
  • “Framekernel” mimarisi, unsafe Rust kodunu (bellek açısından güvensiz bölümleri) framework kütüphaneleriyle sınırlayıp güvenli API'lerle sarmalar; kalan tüm çekirdek servisleri ise güvenli Rust ile geliştirilecek şekilde tasarlanır
  • Monolitik çekirdeğin basit/yüksek performanslı yapısı ile mikrokernelin düşük TCB (güvenilir hesaplama tabanı)/güvenlik özelliklerini aynı anda hedefler
  • Çekirdek içindeki servisler aynı adres alanı içinde ayrıştırılmış şekilde çalışır ve her servis yalnızca core kütüphaneler tarafından kendisine verilen kaynakları kullanabilir

Framekernel mimarisinin açıklaması

  • Framekernel kavramı ilk kez "Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation" makalesinde önerildi
  • Monolitik çekirdek, tüm kodu tek bir çekirdek modu adres alanında barındıran yapıdır; mikrokernel ise çekirdek alanını yalnızca asgari TCB'ye ayırır ve işlevlerin çoğunu kullanıcı modu servislerine devreder
  • Framekernel, Rust'ın 'unsafe' özelliği gerektiren kodu kütüphaneler içinde kapsüller ve kalan çekirdek servislerini bellek güvenli Rust soyutlamalarıyla geliştirmeyi amaçlar
  • Her servis çekirdek adres alanı içinde çalışır, ancak yalnızca kütüphanelerin açıkça sunduğu kaynaklara erişecek şekilde sınırlandırılır
  • TCB küçük tutulduğunda resmi doğrulama (matematiksel ispat) daha uygulanabilir hâle gelir ve sistemin genel güvenilirliği ile kararlılığı artırılabilir
  • Paylaşımlı bellek temelli (monolitik çekirdek gibi yüksek performanslı) olup aynı zamanda iç ayrıcalık ayrımı/güvenlik (mikrokernelin avantajları) sağlayan bir yaklaşımdır

Mevcut Rust OS'ler ve framekernel ile karşılaştırma

  • RedLeaf: Rust tabanlı mikrokernel, donanım izolasyonu kullanmıyor
  • Asterinas: Genel amaçlı OS, donanım izolasyonu kullanıyor, Linux ABI uyumlu, farklı dillerde kullanıcı alanı çalıştırmayı destekliyor
  • Tock: Gömülü SoC hedefli; çekirdek (unsafe'e izin veren) ile capsule'ları (güvenli kod) ayıran yapıya sahip, donanım izolasyonu desteği yok
  • Rust for Linux projesi de çekirdek arayüzlerini güvenli soyutlamalarla sararak kernel driver'larının Rust ile güvenli biçimde yazılabilmesini amaçlar

Resmi doğrulama ve güvenlik

  • TCB'yi küçültmenin temel amacı, biçimsel doğrulamayı (formal verification) pratikte mümkün kılmaktır
  • Asterinas, seL4 gibi küçük ve doğrulanabilir bir TCB'yi Linux ABI uyumluluğu ve paylaşımlı bellek yapısıyla aynı anda hedefleyen tek örnektir
  • Güvenlik denetimi şirketi CertiK ile iş birliği yaparak Verus tabanlı biçimsel doğrulama çalışmaları yürütüyor
    • CertiK'in güvenlik değerlendirme raporu, projenin denetim noktalarını ve tespit edilen sorunları yayımlıyor

Kütüphaneler ve geliştirme araçları

  • Çekirdeğin yanı sıra OSTD (Rust OS framework'ü) ve OSDK (Cargo tabanlı geliştirme aracı) sunuluyor
  • OSTD'nin başlıca hedefleri:
    • OS geliştirmeye giriş engelini düşürmek ve yenilik için zemin hazırlamak
    • Rust işletim sistemlerinin bellek güvenliğini güçlendirmek ve düşük seviye API'leri soyutlamak
    • Rust OS projeleri arasında kod yeniden kullanımını teşvik etmek
    • Yeni kodun kullanıcı modunda test edilebilmesi (geliştirme verimliliğini artırır)
  • OSD ve OSTD tabanlı çekirdeklerin Linux uyumlu olması gerekmez; x86 donanım kontrolü, sanal bellek, çoklu işleme (SMP), zamanlayıcılar vb. için yüksek seviyeli ve bellek güvenli API'ler sağlar
  • Intel sponsorlar arasında yer alıyor; özellikle Trust Domain Extensions(TDX) ve sanal makine izolasyonu ile ilgili teknolojiler burada örtüşüyor

Geliştirme durumu ve başlıca sponsorlar

  • 2024 başında açık kaynak (MPL lisansı) olarak ilk kez yayımlandı; şu anda 45 katkıcı var, başlıca katkıcılar Çin'deki SUSTech, Pekin Üniversitesi, Fudan Üniversitesi doktora öğrencileri ve Ant Group
  • x86 ve RISC-V desteği, Linux sistem çağrılarından 206'sı uygulanmış durumda (toplam 368 içinden)
  • Henüz uygulama çalıştıramıyor; erken dağıtım geliştirme, konteyner (Docker) desteği ve Nix tabanlı dağıtım denemeleri hedefleniyor
  • Linux kernel modülü yüklemeyi desteklemiyor ve bunu kalıcı olarak ekleme planı da yok

Gelecek planları

  • Daha fazla CPU mimarisi ve donanım desteği ile bulut ortamlarında gerçek kullanım uygunluğu kısa vadeli öncelikler arasında
  • Linux virtio aygıt desteği tamamlandı; ana hedeflerden biri Çin bulut pazarı (Alibaba Cloud, Aliyun)
  • Güvenli ve küçültülmüş TCB'ye, Intel güvenilir hesaplama özellikleri desteğine sahip konteynerler için bir host OS geliştirmek temel amaç
  • Rust for Linux ile amaçlar benzer görünse de, Rust for Linux mevcut çekirdek içinde driver'ları Rust'a taşımakla sınırlıyken Asterinas tümüyle yeni bir çekirdek tasarımı ve TCB minimizasyonu peşinde
  • Şu anda X11, Xfce desteği gibi farklı yönlerde deneyler de yürütülüyor; OSTD'nin kendisi de genel OS geliştiricilerinin ilgisini çekme potansiyeline sahip

Rust for Linux'tan farkları

  • Rust for Linux: Mevcut Linux çekirdeğine yalnızca Rust ile güvenli sürücüler ekler; çekirdeğin tamamı hâlâ C tabanlıdır
  • Asterinas: Yeni bir çekirdeği sıfırdan Rust ile uygular; unsafe kullanımını sıkı biçimde sınırlar, resmi doğrulama hedefler ve bulut/konteyner ortamlarına odaklanır

Genel değerlendirme ve görünüm

  • Asterinas; bellek güvenliği, resmi doğrulama ve bulut ortamlarında pratiklik açısından yenilikçi bir yaklaşım deniyor
  • Henüz gerçek kullanım örnekleri veya geniş topluluk doğrulaması yok, ancak OS araştırmaları, bulut ve güvenlik alanlarında ilgi görüyor
  • OSTD framework'ü gibi bileşenler, gelecekte Rust OS geliştirme ekosisteminde kullanılma potansiyeli taşıyor

Asterinas ile ilgili LWN yorumlarında öne çıkan başlıkların özeti

  • Singularity OS ve dil tabanlı güvenlik sınırı tartışması
    • Asterinas'ın framekernel yaklaşımı Microsoft'un Singularity OS'ine benziyor, ancak Rust'ın borrow checker'ını kullanarak bellek güvenliğini artırıyor
    • Sistemi yalnızca dilin kendisinin (ör. Rust, Java, WASM/JS) sunduğu güvenlik sınırlarıyla koruma yaklaşımına karşı, "tam güven mümkün değildir; pratikte donanım/OS düzeyi sandbox ile birlikte kullanılır" eleştirisi ile, "hata önleme ve resmi doğrulama açısından avantajları vardır" görüşü karşı karşıya geliyor
    • WASM, JS ve Java için de güvenlik tartışmaları bulunsa da, gerçek hizmetlerde yalnızca dil sandbox'ına güvenilmiyor; donanım veya OS sandbox'ı ile birlikte kullanmak yaygın
  • İşletim sistemi geliştirme trendleri ve jeopolitik arka plan
    • Son yıllarda çeşitli yeni OS projeleri ortaya çıktı; OS yeniliği havası yayılıyor
    • Çin, ABD'nin teknoloji yaptırımları ve tedarik zinciri risklerine karşı Linux alternatif OS geliştirmesini hızlandırıyor
    • ABD yaptırımları, GPL ve açık kaynağın küresel yönetişimi tartışmaları ile Çin, Avrupa ve diğer bölgelerin bağımsız teknoloji ekosistemleri kurması gerektiğine dair siyasi tartışmalar yoğun biçimde sürüyor
    • Linux'u fork ederek sürdürmenin zorluğu, tamamen yeni bir çekirdek geliştirmenin güçlüğü, topluluk bilgisi/deneyimine bağımlılık ve dil engelleri de tartışma konuları arasında
  • Linux uyumluluğu/sistem çağrısı sayısı tartışması
    • "Linux uyumluluğunu sistem çağrısı sayısıyla ölçmek uygun değil" görüşü yaygın
    • Tek bir sistem çağrısı (ioctl gibi) çok sayıda ayrıntılı API'yi içerebildiği için, gerçek uyumluluk açısından kernel test suite'leri ve gerçek uygulamaları çalıştırmak daha önemli görülüyor
    • Linux'un ilk dönemlerde POSIX uyumluluğu için syscall'ları tek tek uygulayarak geliştiği hatırlatılıyor; ana syscall'ların %99'unu desteklemenin bile epey yazılımı çalıştırmaya yetebileceği yönünde daha pragmatik görüşler de var
  • Lisans ve Rust ekosistemi
    • Asterinas'ın MPL seçimi üzerine tartışmalar: Rust'ın crate ekosistemi ve modüler lisanslama yapısıyla MPL'in iyi uyum sağladığını düşünen olumlu görüşler var
    • GPL'in her zaman en iyi seçenek olmadığı, kurumsal sponsorluk varsa MPL gibi şirket dostu lisansların da tercih edilebileceği görüşü dile getiriliyor
  • Proje bağımlılıkları/güvenlik
    • Rust tabanlı bir OS'te çok sayıda harici crate kullanmanın ne kadar güvenli olduğu sorgulanıyor; cargo deny/vet gibi araçlarla tedarik zinciri güvenliği ve denetimin otomasyonu gerektiği belirtiliyor
    • Sadece lockfile'a bakarak bağımlılık yüzeyini anlamanın zor olduğu, Rust ekosistemine özgü transitif bağımlılıklar ve OS'e göre değişen bağımlılıkların da karmaşıklık yarattığı ifade ediliyor
  • Teknik ilham/benzer mimariler
    • Framekernel kavramının, 90'larda University of Washington'da geliştirilen SPIN OS mimarisiyle benzerlik taşıdığına dikkat çekiliyor
    • SPIN de güçlü modülerlik ile derleyici tarafından sağlanan arayüz/erişim kontrolünü vurguluyordu
  • Committer yapısı tartışması
    • 45 katkıcının çoğu commit'inin az sayıdaki doktora öğrencisi etrafında yoğunlaştığı belirtiliyor
    • Doktora öğrencileri öncülüğündeki katkıların gerçek committer olarak değerinin düşük olduğu yönündeki yanlış algıya itiraz edilerek, bunun araştırma odaklı yenilik projesi olarak da anlamlı olduğu savunuluyor
  • Siyaset/tarih tartışmaları ve konu dışı uyarıları
    • OS tartışması ABD, Avrupa ve Çin üzerine jeopolitik/siyasi/tarihsel polemiklere uzayınca editörler birkaç kez "konu dışı" uyarısı yaptı
    • Bazı kullanıcılar, açık kaynak ve FOSS ekosisteminin de değişen jeopolitik ortamdan etkilenebileceğini vurguluyor
  • Diğer
    • WASM güvenliği üzerine akademik makaleler paylaşılıyor
    • Çekirdek geliştirme durumuna yönelik olumlu ve eleştirel bakışlar bir arada bulunuyor

İlgili okumalar

2 yorum

 
eususu 2025-06-24

Böyle girişimler gerçekten çok iyi görünüyor.
Yakında ölmeyen bir çekirdek ortaya çıkar mı diye de düşünmeden edemiyorum.
 
GN⁺ 2025-06-23
Hacker News görüşleri

  • Bunun ilginç bir yaklaşım olduğunu düşünüyorum ve başarılı olmasını umuyorum. Ama yine de kuşkularım var. 90'ların sonu ya da 2000'lerin başında Linus'un bir TV röportajında rakipler hakkında söylediği bir şey hâlâ aklımda. Linus, "sürücü yazmaktan hoşlanan kimse yoktur, genç ve aç birileri çıkıp müthiş bir sürücü mühendisi olana kadar güvendeyiz" gibi bir şey söylemişti. O zaman bile sürücü arayüzünü kararsız tutmanın bir savunma mekanizması olduğunun farkındaydı. Aradan 25 yıl geçti; sanal donanım üzerinde çalışan çekirdekler artık çok yaygın, ama gerçek donanım üzerinde çalışıp soyutlamayı gerçekten başarmış, pratikte kullanılabilir işletim sistemi sayısı hâlâ çok az

    • "Sürücü arayüzünü kararsız tutmak bir savunma mekanizmasıdır" kısmına gelirsek, ileride genç ve aç sistem araştırmacıları ya da yapay zeka ortaya çıkıp, yapay zeka ajanlarının C ile yazılmış Linux sürücülerini güvenli Rust ile yazılmış Asterinas sürücülerine çevirmesi olası görünüyor. Bir başka gerçekçi yaklaşım da Linux çekirdeğinin kendisini bir tür yalıtılmış ortamın içine koyup yeniden kullanmak olurdu. Örneğin HongMeng çekirdeği, sürücüleri yeniden kullanmak için User-Mode Linux'tan yararlanıyor. Asterinas da benzer bir strateji uygulayabilir. Referans: https://www.usenix.org/conference/osdi24/presentation/chen-haibo

    • Linus'un gerçekten bir "savunma duvarı" isteyip istediğinden ya da bunu bilinçli olarak yapıp yapmadığından emin değilim. O bir teknoloji girişimi kurucusu değil, aslen sadece bir çekirdek hacker'ıydı ve hayatını garanti altına alacak imkânları zaten elde etmiş durumda. Çekirdek içindeki sürücü arayüzü kararsızlığını kasıtlı bir rekabet engelleme stratejisi olarak yorumlamak bana fazla zorlama geliyor

    • Geçmişte de SPIN OS (Modula 3), JX OS (Java), House OS (Haskell), Verve gibi örnekler vardı. Bunların hepsi çekirdek işlevlerini gerçekleştirmek için type-safe ve memory-safe diller kullandı. Genel olarak tehlikeli işlemleri denetlenmiş fonksiyon çağrılarının arkasına saklayan yapılar vardı; bazıları VM de kullanıyordu. Performans ya da benimsenme sorunlarını bir kenara bırakırsak, başlıca zayıf noktalar soyutlamadaki boşluklar, unsafe kodla etrafından dolaşma, derleyici/JIT yüzünden güvenlik modelinin çökmesi ve sıradan donanım kusurlarıydı (ör. uzay araçlarındaki kozmik ışınlar). Yine de bunlar unsafe dillerle yazılmış çekirdeklerden/uygulamalardan çok daha güvenliydi. Buradan daha ileri gitmek için unsafe kodun statik analizi, tüm unsafe fonksiyonların type-memory-safe arayüzlere uyduğunun garanti edilmesi, entegrasyon sırasında soyutlama güvenliğini koruyan derleyiciler ve bileşen bazlı doğrulanmış derleyiciler de kullanılabilir. Verimlilik araçlarının çoğu zaten var; tek eksik olan şey "tamamen güvenli biçimde soyutlanmış derleme" ve bu da şu anda araştırılıyor, ayrıca elle denetim de mümkün

    • Pratikte kullanılabilir işletim sistemi sayısının bu kadar az olmasının bir nedeni var. Donanım dünyası arayüz "standartlarıyla" dolu, ama gerçek donanımın bu standartlara gerçekten düzgün uyduğu durumlar çok nadir. Sürücünün türlü tuhaflıklara ve düzeltilemeyen kusurlara (errata) karşı kod yazması için gereken zaman harcanmadıkça, gerçek fiziksel donanımda performanslı ve iyi destekli bir şey sunmak gerçekten çok zor

    • Öte yandan benim kullandığım Linux sistemlerinin %98'i sanallaştırılmış ortamlarda çalışıyor. Masaüstü/laptop tarafında Virtualbox'ı tam ekran kullanıyorum ve Windows sürücülerine sadece gerçekten gerektiğinde ihtiyaç duyuyorum; Mac'te ise Docker.app tarafından yönetilen headless VM kullanıyorum. Şirketteki tüm üretim iş yükleri AWS VM'lerde. Evde kullandığım tek Linux donanımı da bir ev sunucusu ve onu da yakında eBay'den aldığım bir Mac mini VM ile değiştirmeyi planlıyorum. Eğer Linux ile uyumlu, daha güvenli ve performansı da benzer bir çekirdek çıkarsa, sürücü eksiği olsa bile bugünlerde alternatif seçmek daha kolay olur diye düşünüyorum

  • Son zamanlarda mikrokernellerin IPC performansı sorununu epey iyileştirdiğini duydum. Bunun pratikte ne kadar düzeldiğini tam hatırlamıyorum ama sanırım Mach'ın yarattığı sektör travması büyüktü. Proje sitesine bakınca yapı biraz ters gibi görünüyor: yalnızca Framework (ayrıcalıklı mod) Rust unsafe kullanabiliyor, Services (ayrıcalıksız) ise sadece güvenli Rust kullanıyor. Bu biraz tuhaf hissettiriyor; ayrıcalıksız kod unsafe ise, ayrıcalıksız olsa bile tehlikeli değil mi? Buna karşılık gerçekten doğrulanması gereken unsafe kodun bulunduğu tarafta sınırsız kullanım serbest mi? Ayrıca lisansa bakınca, Asterinas'ın ağırlıklı olarak Mozilla Public License (MPL) 2.0 kullandığı, bazı bileşenlerin ise daha izin verici lisanslara sahip olduğu yazıyor. Ne GPL ne de BSD; arada bir yerde gibi

    • "Ayrıcalıksız taraf unsafe olsa yine tehlikeli olurdu ve gerçekten doğrulanması gereken kodun ayrıcalıklı tarafta toplanması garip" sorusuna cevaben, bu yapıyı framekernel bağlamında düşünmek gerekiyor. Rust tabanlı framekernel'in tamamı çekirdek alanında çalışıyor, ama mantıksal olarak ayrıcalıklı OS framework'ü ve ayrıcalıksız OS servisleri olarak ikiye ayrılıyor. Ayrıcalıklı kısım hem safe hem de unsafe Rust çekirdek kodunu içeriyor; ayrıcalıksız kısım ise yalnızca safe Rust çekirdek kodunu içeriyor. Bu politikanın tamamı çekirdek kodu için geçerli. Framekernel'lerde kullanıcı programlarının dili konusunda bir kısıtlama yok

    • Bildiğim kadarıyla modern mikrokernellerin çoğu IPC performansını dramatik biçimde iyileştirdi. Örneğin seL4, IPC'yi çok agresif biçimde optimize ediyor; öyle ki IPC, Linux'taki tipik bir syscall'dan çok daha hızlı. Pek çok programın seL4 üzerinde aslında daha hızlı çalışması mümkün olabilir. Gerçek performans karşılaştırma verilerini merak ediyorum

    • Modern mikrokernellerin IPC sorununu iyileştirdiği doğru. Aslında daha temel sorun, modern donanımda monolitik çekirdekteki syscall'ların bile çok yavaş olması. Bu yüzden io_uring ya da virtio gibi arayüzler iyi performans veriyor; çünkü sistem ile uygulama (veya hipervizör ile misafir sistem) arasındaki istek ve yanıtları kuyruklar üzerinden işleyip adres alanı geçişlerinden kaçınıyorlar. Geleceğin işletim sistemlerinde yapı ne olursa olsun kuyruk temelli syscall mekanizması şart olacak. Bu yaklaşımı benimsediğinizde de işletim sistemini monolitik/mikroçekirdek/başka bir yapı diye ayırmanızın performans açısından büyük bir farkı kalmıyor

    • Framekernel'deki privileged/unprivileged ayrımı çekirdek/kullanıcı alanı anlamına gelmiyor. Tüm OS çekirdek ayrıcalık seviyesinde çalışıyor. Sadece mantıksal olarak çekirdek kütüphane kodu (unsafe kullanımına izin verilen, privileged) ile geri kalan çekirdek bileşen kodu (kütüphaneyi kullanan, unsafe doğrudan kullanamayan, unprivileged) ayrılıyor. Muhtemelen linter gibi statik kontrollerle zorlanıyor. Terimlerin bu şekilde üst üste kullanılması kafa karıştırmaya çok uygun

    • Ayrıcalıksız görevler de çekirdek çekirdeğiyle aynı bellek alanında çalıştığı için, çalışma zamanında güvensiz davranışları engellemenin bir yolu yok. Çalışma zamanında ayrıcalıkları gerçekten ayırmak için mikroçekirdek yapısı gerekir. Burada ayrıcalıklar çalışma zamanında değil, statik olarak; yani unsafe kodu yasaklayarak uygulanıyor

  • Çekirdeği küçük bir unsafe çekirdek ve büyük güvenli modüller olarak ayırma fikrinin yeni bir deneme olup olmadığını merak ediyorum. Mikrokernel'in donanım ek yükü yok, monolitik yapının güvenlik sorunlarından da kaçınıyor ve sistem dillerindeki safe/unsafe ayrımını iyi kullanıyor gibi göründüğü için bana çok ilginç ve umut verici geliyor

  • Drew DeVault'un Rust in Linux incelemesi aklıma geldi. HN tartışması da bağlantılı olabilir: https://news.ycombinator.com/item?id=41404733

  • Bunun gerçekten müthiş bir girişim olduğunu düşünüyorum; yazarın bu başlıkta olması da ayrıca etkileyici. Ne kadar kullanılabilir düzeyde olduğunu merak ediyorum, sınırlı bir ortamda bile olsa bir sunucu imajı derleyip denemek isterim

    • Asterinas hâlâ nispeten yeni bir çekirdek, bu yüzden genel amaçlı kullanım için düzeltilmesi gereken pek çok nokta var. Ama hedef gerçek anlamda verimli ve güvenilir üretim hizmetleri çalıştırmaksa, aradaki fark o kadar büyük değil ve 1 yıl içinde bu hedefe ulaşmak mümkün olabilir. Şu anda Linux namespace'leri, cgroups gibi temel özellikler uygulanıyor ve ilk Asterinas tabanlı dağıtım üzerinde çalışılıyor. İlk hedef, Confidential VM'ler için misafir işletim sistemi olarak Asterinas'ı kullanmak; bellek güvenliği ve küçük TCB sayesinde güvenlik tarafında Linux'a göre belirgin avantajları var

  • Mikrokernel IPC'sinin yavaş olduğu için popüler olmadığı açıklamasını görünce, teknik olarak çok güçlü insanların bile gerçek benimsenme nedenleri konusunda yanılıp süreci yanlış okuyabildiğini görmek beni rahatlattı

    • O halde tam olarak hangi noktada yanlış yorum yapıldığını açıklamak herkes için faydalı olurdu

  • Lisans MPL ise, bana kalırsa daha iyi lisanslar da var (GPLv3 gibi)

    • Belgelerde neden MPL seçildiği doğrudan açıklanıyor. Benim favori tercihim değil ama gerekçesi anlaşılabilir

  • Bence gerçekten iyi bir fikir. Zaten çok büyük bir yazılım ekosistemi var ve alternatif bir temel, teknik olmayan nedenlerle bile büyük avantajlar ve seçenekler sağlayabilir. Bana kFreeBSD ile GNU/Hurd'u hatırlatıyor

  • Bu tür çekirdeklere ne denmesi gerektiğini merak ediyorum. *nux?