Asahi Linux 7.1 ilerleme raporu

 (asahilinux.org)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Linux 7.1 itibarıyla Asahi Linux tarafında M3 desteğinin genişletilmesi, macOS 27 beta uyumluluğu, AVD video çözme ve m1n1 1.6.0 değişiklikleri eşzamanlı olarak ilerliyor
  • macOS 27 Golden Gate geliştirici betasında Asahi önyükleme girdisi Startup Disk ve boot picker'dan kayboldu, ancak bölüm ve veriler yerinde kaldı; APFS boot flag ayarıyla geri yüklemek mümkün
  • SMC firmware değişikliği, pil yönetimi dönüş değerini değiştirerek belirli koşullarda acil kapanmaya yol açtı; downstream kernel ise 7.0.12'den itibaren her iki firmware ABI'sini de işliyor
  • M3 serisinde ses, CPU frekans geçişi, big.LITTLE zamanlama, SMC sensörleri, PCIe, WiFi, Bluetooth, NVMe, klavye ve trackpad Linux'ta çalışıyor; ancak henüz Asahi Installer desteği aşamasında değil
  • AVD, Apple firmware'i yerine kendi firmware'i ve V4L2 sürücüsüyle AVC donanımsal çözmeye doğru ilerledi; m1n1 1.6.0 ise stage 2 derlemelerinde Rust gerektirerek dağıtımlar üzerinde önemli etki yaratıyor

macOS 27'de kaybolan Asahi önyükleme girdisi

  • Mac'te güç düğmesine uzun basılarak açılan boot picker'da veya Startup Disk uygulamasında görünen Asahi girdisi, gerçek işletim sistemi bölümü değildir
  • Apple önyükleme araçları APFS container içindeki yalnızca “geçerli bir macOS kurulumu” ile çalıştığından, Asahi Installer 2.5GB APFS container oluşturup m1n1'i kernel gibi yerleştiren minimal bir macOS yapılandırması kullanır
  • Bu yöntem macOS 12'den macOS 26'ya kadar hiçbir değişiklik olmadan çalıştı; Apple ayrıca yalnızca gerçek XNU kernel yerine raw binary önyüklenirken görülen araç hatalarından bazılarını da düzeltti
  • macOS 27 Golden Gate geliştirici betasından sonra bazı kullanıcılar Startup Disk ve boot picker'da Asahi girdisinin kaybolması sorunuyla karşılaştı
    • diskutil incelemesine göre Asahi ile ilgili bölümler diskte kalmıştı ve veri kaybı yoktu
    • Aynı makinede macOS 26'nın önyükleme araçları kullanıldığında Asahi hâlâ önyüklenebiliyordu
  • macOS Installer yeniden başlatmadan önce APFS metadata ayarlıyor; ek inceleme sonucunda bu değerin, volume'ü önyüklenebilir olarak işaretleyen flag olduğu ortaya çıktı
    • macOS 27 öncesindeki önyükleme araçları bu flag'i yok sayıyordu
    • Asahi APFS container üzerinde flag elle ayarlanırsa macOS 27 boot picker'da yeniden görünür hâle geliyor
  • Yeni Asahi kurulumlarında Asahi Installer bu flag'i otomatik olarak ayarlıyor
  • Mevcut kurulumları düzeltmek için bir kurulum modu da eklendi
    • macOS 27 geliştirici betasını kurduktan sonra Asahi'ye erişilemiyorsa installer yeniden çalıştırılıp “Fix macOS 27 boot picker compatibility” seçeneği kullanılmalı
  • Sorunu Linux içinden düzelten bir program da yazıldı, ancak otomatik dağıtımdan önce daha fazla test verisine ihtiyaç var
    • Test etmek için macOS 27'ye yükseltmeden önce asahi-fix27 deposunu clone edip Linux'ta derleyip çalıştırmak gerekiyor
    • Sonrasında macOS içinde Asahi volume'ü önyükleme hedefi olarak seçilebiliyorsa çözüm işe yaramış demektir
    • Sonuçlar ve sorunlar Asahi community channels üzerinden paylaşılabilir

SMC firmware değişikliği ve pil sürücüsünde acil kapanma

  • macOS 27, SMC dahil global firmware kullanan tüm çevre birimlerinin firmware güncellemelerini içeriyor
  • SMC pil yönetiminden sorumlu; Linux power supply sürücüsü de şarj durumu, voltaj, boşalmaya kalan süre ve pil sağlığı bilgisini almak için SMC ile haberleşiyor
  • Aynı sürücü, pil ömrünü uzatmak için SMC firmware arayüzü üzerinden şarj başlatma ve durdurma eşiklerini de ayarlıyor
  • macOS 27'nin SMC firmware'i, pil yönetimi arayüzlerinden birini 32 bit tam sayı dönüşünden 1 bayt dönüşe çevirdi
  • Bu değişiklik nedeniyle Asahi sürücüsü belirli koşullarda bunu pil arızası olarak yorumlayıp sistemi korumak için acil kapanma başlatıyordu
  • Patch downstream kernel'e zaten uygulandı; 7.0.12'den itibaren power supply sürücüsü her iki firmware ABI'sini de işliyor

Geliştirici betası kurulumu için uyarı

  • macOS 27'de görülen bu iki sorun, geliştirici betasının gerçekten geliştirici betası olduğunu gösteriyor
  • Geliştirici betasının production makinelere kurulması önerilmiyor
  • Şimdiye kadar ortaya çıkan iki sorun şans eseri küçük kaldı, ancak bundan sonra çıkacak tüm sorunların da küçük olacağı garanti değil
  • global firmware güncellemeleri fiilen kalıcıdır; geri almak için makineye DFU restore uygulanması gerekir
  • Asahi tarafı test için feda edilebilecek makineler kullandığından, kullanıcıların pahalı donanımını ve önemli verilerini riske atmasına gerek olmadığı düşünülüyor

M3 serisi desteğinde ilerleme

  • Bilgisayar platformları ile IC tasarımı/doğrulaması yüksek maliyetli ve zaman alıcı olduğundan, gereksiz eski tasarım değişiklikleri yapmak mantıklı değildir
  • Asahi projesi, Apple'ın platform ve IC tarafında sürekli bozucu değişiklikler yapmayacağı varsayımına dayanıyordu; GPU gibi nesilden nesile değişmesi daha olası büyük SoC blokları dışında bu varsayım büyük ölçüde doğru çıktı

  • Ses çıkışı

    • Apple Silicon dizüstülerde ses, birden fazla IC ve SoC bloğu kullanır
    • Ses IC'lerinde fiili sektör standardı, ses verisine optimize edilmiş I2C tabanlı bir bus olan I2S'dir
    • Apple'ın I2S denetleyicisi ve kararlı saat kaynağı Apple NCO, M1'den beri değişmedi
    • Apple, neredeyse tüm Apple Silicon makinelerde aynı hoparlör ve kulaklık amplifikatörü çiplerini kullanıyor
    • M3 makinelerine hoparlör ve kulaklık jakı desteği eklemek için gereken işler çoğunlukla küçük Devicetree eklemeleri ile asahi-audio ve speakersafetyd yapılandırma dosyalarından ibaretti
    • M3 makineleri Asahi Linux'ta yüksek kaliteli ses çıkışını destekliyor

  • CPU frekansı ve big.LITTLE zamanlama

    • M3 makineleri artık CPU frekans geçişini ve uygun big.LITTLE iş zamanlamasını da destekliyor
    • Apple, temel M2'den beri CPU frekans geçiş yöntemini değiştirmedi
    • M3, M3 Pro, M3 Max ve M3 Ultra SoC'leri mevcut cpufreq sürücüsünde yalnızca Devicetree değişiklikleriyle çalışıyor
    • İşler gereksinimlerine göre verimlilik çekirdeklerine veya performans çekirdeklerine daha akıllıca yerleştiriliyor; CPU çekirdekleri de yüke göre saat hızını artırıp düşürüyor
    • Bu değişiklik hem enerji tasarrufu hem de performans artışı sağlıyor

  • Sensörler ve temel aygıtlar

    • SMC firmware'i makineler arasında çok farklı olmadığından, SMC donanım sensörü desteği de yalnızca birkaç Devicetree değişikliği gerektirdi
    • M3 serisi makinelerde PCIe, WiFi, Bluetooth, NVMe, klavye, trackpad ve diğer temel SoC blok sürücüleri de Linux'ta çalışıyor
    • Bu çalışmanın önemli bir kısmı, M3 serisi makinelerde m1n1 ve Linux üzerinde çalışan Yureka tarafından yapıldı
    • Asahi Installer desteğini M3 makinelerde etkinleştirmek için hâlâ daha fazla çalışma gerekiyor, ancak ilerleme hızlı

AVD video çözme ve özel firmware

  • Apple Silicon platformundaki karmaşık donanımların büyük bölümü, karmaşık firmware blob'ları kullanıyor
  • Birçok firmware, Apple'ın kernel ile çeşitli donanım blokları arasında büyük ölçüde standartlaştırılmış arayüz sunmak için kullandığı RTOS benzeri bir framework olan RTKit tabanlıdır
  • DCP ve AOP gibi bazı bloklar RTKit temelini kullanırken bunun üstüne EPIC adlı ek bir soyutlama katmanı koyuyor
  • Broadcom WiFi/Bluetooth yongasetlerinde olduğu gibi, Apple'ın doğrudan kontrol etmediği üçüncü taraf firmware kullanan durumlar da var
  • Apple Video Decoder yani AVD, ne RTKit ne de EPIC kullanan, ayrı yapıda bir firmware kullanıyor

  • AVD yapısı ve mevcut yöntemin sorunu

    • AVD donanımı, AVC(H.264), HEVC(H.265), VP9 ve yeni SoC'lerde AV1 video karelerini çözen sabit işlevli donanım birimlerini denetleyen bir ARM Cortex-M3'e oldukça benziyor
    • Cortex-M3, XNU'nun video verisini göstermesini sağlayan bir arayüz sunuyor ve gerçek çözücü donanımı yapılandıran firmware blob'unu çalıştırıyor
    • Apple, AVD firmware'ini ve yapılandırma verilerini AVD kext içinde birlikte barındırıyor
    • Her SoC biraz farklı AVD varyantı kullandığından, Asahi Installer'ın kext içindeki firmware veri ofseti değişikliklerini sürekli takip edip güncellemesi gereken lojistik bir sorun ortaya çıkıyor

  • Özel firmware yaklaşımı

    • XNU'nun yüklediği AVD firmware'i Cortex-M3 üzerinde doğrulanmıyor
    • Sinyal geldiğinde reset vector'den çalışmaya başladığı için, içeride hangi kod varsa onu yürütüyor
    • Firmware'in görevi temelde video çözücü donanımı soyutlamak olduğundan, her donanım bloğu için yalnızca interrupt handler kurulursa Linux sürücüsü tarafından doğrudan programlanabiliyor
    • Standart Cortex-M3 kodu olduğu için AVD firmware'i emülatörde çalıştırılabiliyor
    • QEMU tek adımlı yürütme ile bus ve register işlemlerini incelemeyi destekliyor
    • Jamie, R ve Eileen önceki ortak çalışmalarıyla AVC ve VP9 çözücüleri için gerekli komut ve veri biçimlerini reverse engineering ile ortaya çıkardı
    • XNU kext'i her AVD revision için kendine özgü tunable değerler de uyguluyor
    • Bu değerlerin tam olarak ne yaptığı tamamen net değil
    • Uygulama daha çok XNU'daki MMIO write işlemlerinin yeniden oynatılmasına benziyor
    • Her AVD revision'ı, tunable kümesini ve bunların hangi revision'a uygulandığını takip etmek gerekiyor
    • Bunu upstream Linux kernel sürücüsünde tatmin edici şekilde sürdürmek zor olduğundan, bu kısmı da firmware içinde tutmak daha uygun görünüyor

  • V4L2 AVC sürücüsü

    • Yeni katkıcı sofus, interrupt handler kuran ve her varyantın tunable değerlerini uygulayan temel bir custom AVD firmware oluşturdu
    • Bunun üzerine AVC donanımı için çalışan bir V4L2 sürücüsü yazdı
    • Donanım, 10 bit AVC kodlu videoyu 4K'ya kadar çözebiliyor
    • V4L2 Request API uygulayan yazılımlarla iyi çalışıyor
    • Firmware'i basit ve durumsuz tutup video verisi ayrıştırma ile çözücü programlamasını userspace ve kernel'e bırakmak, gelecekte VA-API veya Vulkan Video gibi başka video hızlandırma API'lerine destek vermeyi de kolaylaştırıyor
    • Kullanıcılara AVD desteği sunmak için hâlâ yapılacak işler var
    • AVD, VP9, HEVC ve bazı SoC'lerde AV1'i de destekliyor, ancak bunlar henüz uygulanmadı
    • Bazı aygıtlara özgü quirks'lerin de test edilip sürücüye eklenmesi gerekiyor
    • Dağıtıma uygun bir şekle çok uzak olmayan bir zaman dilimi hedefleniyor

m1n1 1.6.0 sürümü

  • m1n1 1.6.0 etiketlendi; dağıtımlar açısından etkisi büyük bir sürüm
  • Bu sürüm, stage 2 derlemesinde ilk kez Rust gerektiriyor
  • Daha önce Rust yalnızca chainloading desteği eklenerek derleme yapıldığında kullanılıyordu
  • stage 1 m1n1, Apple önyükleme araçlarında XNU kernel'in yerini alıyor ve yalnızca EFI System Partition'ı mount edip oradan stage 2 m1n1'i chainload etmek için kullanılıyor
  • GPU ilklendirmesinin m1n1'e taşınmasına karar verilince, kernel sürücüsünün Apple donanım ilklendirme verilerindeki kayan noktalı değerlerle uğraşmasına gerek kalmadı ve Devicetree binding de önemli ölçüde sadeleşti
  • Gelecekte Linux Kernel Mailing List'e gönderilecek GPU sürücüsü sürümü, bu ilklendirmenin m1n1 tarafından yapıldığı varsayımına dayanacak
  • Apple Device Tree ayrıştırma kodu da Rust'a taşındı ve m1n1'in neredeyse tüm diğer bölümlerinde kullanılıyor

  • Derleme ve hedef

    • m1n1 fiilen firmware olduğu için no_std Rust kullanıyor ve hedef olarak aarch64-none-softfloat seçiliyor
    • Gereksiz bağımlılık çekmemek için make komutuna BUILDSTD=1 verilerek tam bir softfloat toolchain kurmadan core ve alloc derlenebiliyor

  • M3, M4, A18 Pro hazırlığı

    • 1.6.0, M3 serisi desteği için çeşitli iyileştirmeler de içeriyor
    • SPMI denetleyici desteği
    • PCIe ilklendirme desteği
    • kisd üzerinden SoC donanım UART'ının DebugUSB ile doğrudan tünellenmesi desteği
    • DebugUSB UART tünelleme, Central Scrutiniser ile neredeyse aynı işlevi sunabiliyor
    • Bu işin önemli bir kısmı da Yureka'nın katkısı
    • M4 ve A18 Pro, yani MacBook Neo desteği için temel çalışmalar da sürüyor
    • Apple'ın non-macOS boot mode'unu daha iyi işliyor
    • Apple Device Tree içindeki yeni power domain metadata desteği ekleniyor

Destekçiler ve katkıcılar

  • Asahi Linux, GitHub Sponsors ve Open Collective destekçilerine teşekkür ediyor
  • Bu destekler sayesinde tamamlanmamış M1/M2 özellikleri, M3/M4/A18 Pro desteği ve yeni katkıcıların desteklenmesi sürdürülebiliyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • “Ses IC’leri için fiilî sektör standardı, ses verisi için optimize edilmiş I²C tabanlı bir veri yolu olan I²S” ifadesi doğru değil. I²S’nin I²C ile ilgisi yoktur
    Çoğu I²S çipinde bir I²C arayüzü bulunur; çünkü I²S yalnızca ham ses verisini taşır, ses seviyesi kontrolü veya saat ayarı gibi ek sinyaller içermez
    Ama bu ayrı bir arayüzdür ve I²C yerine SPI da olabilir. Aslında SPI, I²S’ye I²C’den daha yakındır

    • Doğru, I²S SPI’a çok daha yakındır
      İkisinin de benzer bir adlandırma düzenini izlemesinin nedeni, ikisini de Philips Semiconductor’ın (şimdiki NXP) geliştirmiş olmasıdır
    • I²S şaşırtıcı derecede basit bir tasarımdır. Protokol el sıkışması yoktur; yalnızca ham PCM akar
      Gönderici ve alıcının iki yönde farklı örnek bit derinlikleri kullanması durumunda bile uyumluluk sorunu çıkmayacak şekilde tasarlanmış olmasını seviyorum
      https://web.archive.org/web/20070102004400/http://www.nxp.co...

  • Motive olmuş az sayıda insanın bu sorunları çözebilmesi gerçekten hayranlık uyandırıcı

    • Pek çok sorun hiç çözülmüş değil. Örneğin Apple Silicon’ın PSCI güç yönetimi arayüzü hâlâ bir muamma
      Diğer Linux device tree’lerinde PSCI kodu var, ancak Apple’ın bunu nasıl uyguladığını kimse bilmiyor. Bu yüzden Asahi kullanıcıları neredeyse 5 yıldır pilin sürekli boşalmasını engelleyen hack’lere bel bağlamış durumda ve bildiğim kadarıyla hâlâ umut vadeden bir çözüm yok
      Tersine mühendisliğin aydınlık ve karanlık tarafı bu. Bu cihazlar için yerel Vulkan 1.2 sürücüsünün ortaya çıkması harika, ama oraya gelmek yıllar sürdü. Apple Silicon’ın çıkışının üzerinden 7 yıl geçmişken bile çözülmemiş sorunlar var ve en yeni donanımların çoğu genel olarak desteklenmiyor. Sonuçta Linux kullanıcılarının hep söylediği derse geri dönüyoruz: kapalı kaynak sürücüler pek iyi değil

  • XNU’nun yüklediği firmware’i CM3’ün doğrulamaması ve sinyal geldiğinde gerçek içeriği ne olursa olsun reset vector’den çalıştırmaya başlaması kısmı özellikle endişe verici
    Kapalı ve sürekli değişen bir hedefe karşı özel firmware yazma başarısı kelimelerle anlatılamayacak kadar büyük; ancak Apple’ın üçüncü taraf işletim sistemlerini bilerek bozmamaya devam etmesini ummaktan bağımsız olarak, firmware blob’larına veya çalışma zamanında donanımı programlamak için verilen verilere donanım imzası getirme ihtimali düşük görünmüyor. Apple açısından bu makul bir güvenlik kaygısı olabilir. Yine de bu kumarın başarılı olmasını umuyorum

  • Bunun sonsuza dek Fedora “remix” olarak kalıp kalmayacağını merak ediyorum. Bir gün upstream destek gelip Debian tabanlı dağıtımlar çalıştırmamızı sağlar mı?
    RPM tabanlı bir dağıtımı en son kullanışımın üzerinden neredeyse 20 yıl geçmiş gibi

    • Yamaları upstream’e gönderiyorlar, dolayısıyla eninde sonunda gerekli sürücüler upstream Linux’a girecek
      Elbette kernel fork’u da açık kaynak olduğu için Debian aarch64 root’unu alıp Asahi kernel’ini kendiniz derlemenizi veya Fedora derlemesini alıp bu cihazlarda Debian’ı kendiniz yapılandırmanızı engelleyen bir şey yok. Sadece biraz uğraş gerektiriyor
      Ubuntu sizin için uygunsa Ubuntu Asahi de var: https://ubuntuasahi.org/
      Arayınca şu wiki belgesi de çıkıyor: https://wiki.debian.org/InstallingDebianOn/Apple/M1
    • Benim zevkim tam tersi olduğu için bu yorum bana komik geldi. Ben RPM tabanlı dağıtımları tercih ediyorum ve neredeyse her yerde ağırlıklı olarak Fedora kullanıyorum. M1 Ultra Mac Studio’da da Fedora Asahi Remix kullanıyorum; bulut instance’larının yalnızca bazılarında ara sıra Ubuntu ve Debian kullanıyorum
      Bu yüzden zaten alıştığınız belirli bir dağıtımı kullanmaya devam etmek istemeyi anlıyorum. Daha az iş çıkıyor ve yapıdaki ince farkları daha az hatırlamak gerekiyor. Yine de mecburen yeni bir dağıtım kullanmam gerektiğinde, örneğin Asahi ilk başta yalnızca Arch Linux ARM için çıktığında olduğu gibi, oradan edindiğim küçük öğrenmeden hiç pişman olmadım
    • Arch hâlâ kullanılabiliyor ve Ubuntu Asahi de var
      Tüm dağıtımların daha kolay port edilebilmesi için tam da bu nedenle upstream çalışmasına yoğun biçimde emek veriliyor
      https://ubuntuasahi.org/
    • Bananas Team, Apple Silicon üzerinde standart Debian’ı çalıştırmaya yönelik çalışma yapıyor ve resmî olmayan bir depo ekleyerek şu anda kurmanın bir yolu da var: https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
      Henüz kendim kurmayı denemedim
    • linux-asahi Void Linux’ta da kullanılabiliyor
      https://voidlinux.org/download/#arm%20platforms
      Dağıtım içindeki normal bir Linux paketi: https://github.com/void-linux/void-packages/tree/master/srcp...

  • M3 desteğinin iyi ilerlediğini görmek güzel
    M3 desteği ekleme çalışmalarına başlanacağı ilk kez şubatta belirtilmişti
    “Oldukça uzun süredir m1n1’de M3 serisi cihazlar için temel destek vardı. Eksik olanlar, her cihaz için ayrı device tree’ler ve M2’den farklılaşan M3’e özgü donanım özellikleri ile değişiklikleri desteklemek için Linux kernel sürücüsü yamalarıydı. Mevcut yama seti daha yönetilebilir hale geldiğinde bu işi somutlaştırma niyeti hep vardı”
    https://asahilinux.org/2026/02/progress-report-6-19/

  • AVD sürücüsü üzerinde çalışılıyor olması heyecan verici

  • M1 ve üzeri Mac’lerde ffmpeg ya da VLC kullanınca AVD kullanılıyor mu?

  • Asahi çalışır bir alternatif olabilir, ancak bu kadar finansman ve küçük ekip ölçeğiyle geliştirme hızının kaçınılmaz olarak çok yavaş olduğu görülüyor
    Yazıda söylendiği gibi hâlihazırda oturtulmuş temel çalışmalar ve bunların sonuçları var, ama sonuçta her yıl yeni çipler, sayısız mikrodenetleyici ve GPU değişiklikleri içeren yeni Mac’ler çıkıyor; bunlara yetişmek imkânsız. Asahi ekibinin de M1 ve M2 modellerine daha fazla odaklanmasının nedeni bu
    Yine de bugüne kadar ikisinde de boşta güç yönetimi ve Alt-DP uygulaması sorunları kalmış durumda; bu yüzden birçok kişi geçiş yapamıyor. Bu sorunlar cilalandığında cihazların değeri de ciddi ölçüde düşmüş olacak
    Az sayıda insanın bu kadarını başarması bir mucize, ancak geniş medya haberlerine rağmen sonunda ekibin tutkusu ve motivasyonu azalmış gibi görünüyor; M1 Air’in bile tamamlanamayacağı izlenimi var

    • “Geliştirme hızı kaçınılmaz olarak çok yavaş” demekten ziyade, yeni liderlik ekibi geldiğinde en yeni donanım desteğini eklemek yerine mevcut çalışmaları upstream’e taşımaya öncelik vereceklerini açıklamıştı
      Değişiklikleri kernel’e upstream etmek zaman aldı
      Şimdi Şubat ayında M3 çalışmasına başladıklarını duyurdular ve ilerleme de iyi görünüyor
      “Yukarıdakilere ek olarak, M3 serisi cihazlarda PCIe, WiFi, Bluetooth, NVMe, klavye, trackpad ve diğer temel SoC blok sürücüleri de Linux’ta çalışıyor. Bu işin büyük kısmını Yureka üstlendi; kendisi bir süredir M3 serisi cihazlarda hem m1n1 hem de Linux üzerinde çok aktif biçimde hack’leme yapıyor. Asahi Installer’da bu cihazları desteklemeye başlamak için hâlâ gidilecek yol var, ama ilerleme hızlı; takipte kalın!”
      Bu, kıyametten çok yetenekli insanların titiz bir iş çıkarmasına daha yakın
    • Birkaç yılda bir tek bir modeli hedefleyip düzgün çalışır hâle getirebiliyorlarsa, hiç alternatif olmamasından çok daha iyi
      M1 desteği bugünlerde epey kullanılabilir durumda ve çalışmanın en azından bir kısmı gelecekteki cihazlara da taşınacak gibi görünüyor. Her şey güllük gülistanlık değil, ama başarısızlığı baştan belli bir proje de değil

  • Apple’ın küçük bir ekibe fon sağlayıp belgelerin ve sürücülerin bir kısmını açık kaynak olarak yayımlaması ve Asahi’ye yardım etmesi gerçekten harika olurdu
    Elbette bunu yapmayacağını biliyorum, ama hayal kurabiliriz. Apple için çerez parası olurdu; böyle yaparsa kendi donanımını Silicon Valley mühendislerinin fiilî standardı olarak daha da sağlamlaştırırdı

  • Son dönemde Asahi’de büyük dil modellerinden ne kadar yararlanıldığını merak ediyorum. Tersine mühendislik için gerçekten güçlü bir araç; bununla ilgili bir yazı yazdılar mı?

  • Bu projenin geliştirme/CI sürecinin nasıl göründüğünü merak ediyorum
    Sonuçta her seferinde derlemeyi belirli bir donanıma elle yüklemek mi gerekiyor, yoksa belli ölçüde otomasyonun mümkün olduğu aşamalar var mı?

    • m1n1 burada epey ilginç işler yapıyor: https://asahilinux.org/docs/sw/tethered-boot/
      Gerçek donanım ile kernel arasına çok ince bir katman koyuyor; donanım G/Ç davranışını etkilemeden kernel yüklemeyi ve hata ayıklamayı uzaktan kontrol edip otomatikleştirmeyi mümkün kılıyor