Asahi Linux 7.1 प्रगति रिपोर्ट

 (asahilinux.org)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Linux 7.1 के अनुसार Asahi Linux में M3 सपोर्ट का विस्तार, macOS 27 beta compatibility, AVD video decoding, और m1n1 1.6.0 के बदलाव एक साथ आगे बढ़ रहे हैं
  • macOS 27 Golden Gate developer beta में Asahi boot entry Startup Disk और boot picker से गायब हो गई, लेकिन partition और data बने रहे, और APFS boot flag सेट करके इसे बहाल किया जा सकता है
  • SMC firmware बदलाव ने battery management return value बदल दी, जिससे कुछ स्थितियों में emergency shutdown ट्रिगर हुआ; downstream kernel 7.0.12 से दोनों firmware ABI संभाले जाते हैं
  • M3 सीरीज़ में audio, CPU frequency switching, big.LITTLE scheduling, SMC sensors, PCIe, WiFi, Bluetooth, NVMe, keyboard, और trackpad Linux में काम करते हैं, लेकिन अभी Asahi Installer support चरण तक नहीं पहुँचे हैं
  • AVD ने Apple firmware की जगह अपने firmware और V4L2 driver के साथ AVC hardware decoding की दिशा में प्रगति की है, और m1n1 1.6.0 अब stage 2 build के लिए Rust मांगता है, जिससे distributions पर बड़ा असर पड़ता है

macOS 27 में गायब हुई Asahi boot entry

  • Mac पर power button को लंबा दबाकर खुलने वाले boot picker या Startup Disk app में दिखने वाली Asahi entry वास्तव में operating system partition नहीं है
  • क्योंकि Apple boot tools APFS container के भीतर केवल “valid macOS installation” को ही संभालते हैं, Asahi Installer 2.5GB APFS container बनाता है और m1n1 को kernel की तरह रखकर एक न्यूनतम macOS configuration इस्तेमाल करता है
  • यह तरीका macOS 12 से macOS 26 तक बिना बदलाव के काम करता रहा, और Apple ने raw binary को boot करते समय दिखने वाले कुछ tool bugs भी ठीक किए, जहाँ वास्तविक XNU kernel मौजूद नहीं होता था
  • macOS 27 Golden Gate developer beta के बाद कुछ users को Startup Disk और boot picker में Asahi entry गायब होने की समस्या हुई
    • diskutil से जाँच करने पर Asahi से जुड़े partitions डिस्क पर मौजूद थे और data loss नहीं हुआ था
    • उसी मशीन पर macOS 26 के boot tools इस्तेमाल करने पर Asahi अब भी boot हो सकता था
  • macOS Installer reboot से पहले APFS metadata सेट करता है, और आगे की जाँच में पता चला कि यह value volume को bootable दिखाने वाला flag था
    • macOS 27 से पहले के boot tools इस flag को नज़रअंदाज़ करते थे
    • Asahi APFS container पर यह flag manually सेट करने पर वह macOS 27 boot picker में फिर से दिखने लगता है
  • नई Asahi installations में Asahi Installer यह flag अपने आप सेट करता है
  • मौजूदा installations को ठीक करने के लिए install mode भी जोड़ा गया है
    • अगर macOS 27 developer beta install करने के बाद Asahi तक पहुँच नहीं पा रहे हों, तो installer फिर से चलाएँ और “Fix macOS 27 boot picker compatibility” विकल्प इस्तेमाल करें
  • Linux में समस्या ठीक करने वाला एक प्रोग्राम भी बनाया गया है, लेकिन automatic rollout से पहले और ज़्यादा test data की ज़रूरत है
    • test करने के लिए macOS 27 में upgrade करने से पहले Linux पर asahi-fix27 repository clone करें, build करें और चलाएँ
    • इसके बाद अगर macOS में Asahi volume को boot target के रूप में चुना जा सकता है, तो यह काम कर गया
    • परिणाम और समस्याएँ Asahi community channels में साझा की जा सकती हैं

SMC firmware बदलाव और battery driver emergency shutdown

  • macOS 27 में SMC सहित global firmware इस्तेमाल करने वाले सभी peripheral firmware updates शामिल हैं
  • SMC battery management संभालता है, और Linux power supply driver SMC से communication करके charging status, voltage, discharge तक बचा समय, और battery health की जानकारी लेता है
  • यही driver battery life बढ़ाने के लिए SMC firmware interface के ज़रिए charge start/stop thresholds भी सेट करता है
  • macOS 27 के SMC firmware ने एक battery management interface को 32-bit integer return से 1-byte return में बदल दिया
  • इस बदलाव की वजह से Asahi driver कुछ स्थितियों में battery failure मान लेता था और system protection के लिए emergency shutdown शुरू कर देता था
  • downstream kernel में patch पहले ही लागू किया जा चुका है, और 7.0.12 से power supply driver दोनों firmware ABI संभालता है

developer beta install करने पर चेतावनी

  • macOS 27 में सामने आई ये दो समस्याएँ दिखाती हैं कि developer beta वास्तव में developer beta ही होता है
  • production machine पर developer beta install करना recommended नहीं है
  • अभी तक आई दोनों समस्याएँ सौभाग्य से छोटी थीं, लेकिन इसकी कोई गारंटी नहीं कि आगे आने वाली समस्याएँ भी छोटी ही होंगी
  • global firmware updates लगभग स्थायी होते हैं, और उन्हें वापस करने के लिए मशीन का DFU restore करना पड़ता है
  • Asahi पक्ष का मानना है कि चूँकि वे testing के लिए अलग sacrifice machines इस्तेमाल करते हैं, इसलिए users को अपने महंगे hardware और महत्वपूर्ण data को जोखिम में डालने की ज़रूरत नहीं होनी चाहिए

M3 सीरीज़ support में प्रगति

  • computer platform और IC design/verification महँगे और समय लेने वाले होते हैं, इसलिए बिना ज़रूरत पुराने designs को बदलना तर्कसंगत नहीं होता
  • Asahi project इस धारणा पर टिका था कि Apple platform और IC में लगातार breaking changes नहीं करेगा, और GPU जैसे बड़े SoC blocks को छोड़कर, जो हर generation में बदल सकते हैं, यह अनुमान काफी हद तक सही निकला

  • audio output

    • Apple Silicon laptops का audio कई ICs और SoC blocks का उपयोग करता है
    • audio ICs का de facto industry standard I2S है, जो audio data के लिए optimized I2C-based bus है
    • Apple का I2S controller और stable clock source Apple NCO, M1 के बाद से नहीं बदले हैं
    • Apple लगभग सभी Apple Silicon machines में वही speaker/headset amplifier chips इस्तेमाल करता है
    • M3 machines में speaker और headphone jack support जोड़ने के लिए ज़्यादातर काम छोटे Devicetree additions और asahi-audio, speakersafetyd configuration files तक सीमित था
    • M3 machines अब Asahi Linux में high-quality audio output support करती हैं

  • CPU frequency और big.LITTLE scheduling

    • M3 machines अब CPU frequency switching और उपयुक्त big.LITTLE task scheduling भी support करती हैं
    • Apple ने बेस M2 के बाद CPU frequency switching का तरीका नहीं बदला
    • M3, M3 Pro, M3 Max, M3 Ultra SoCs मौजूदा cpufreq driver में सिर्फ Devicetree बदलावों के साथ काम करते हैं
    • workloads को उनकी ज़रूरत के अनुसार efficiency cores या performance cores पर अधिक समझदारी से रखा जाता है, और CPU cores load के अनुसार clock speed बढ़ाते-घटाते हैं
    • इससे energy savings और performance improvement दोनों मिलते हैं

  • sensors और core devices

    • SMC firmware में machines के बीच बहुत कम अंतर है, इसलिए SMC hardware sensor support के लिए भी केवल कुछ Devicetree बदलावों की ज़रूरत पड़ी
    • M3 सीरीज़ machines में PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, और अन्य core SoC block drivers भी Linux में काम करते हैं
    • इस काम का बड़ा हिस्सा Yureka ने किया, जो M3 सीरीज़ machines पर m1n1 और Linux के साथ काम कर रहे हैं
    • M3 machines के लिए Asahi Installer support सक्षम करने के लिए अभी और काम बाकी है, लेकिन प्रगति तेज़ है

AVD video decoding और custom firmware

  • Apple Silicon platform का अधिकांश जटिल hardware जटिल firmware blob का इस्तेमाल करता है
  • बहुत सा firmware RTKit पर आधारित है, जो Apple द्वारा kernel और कई hardware blocks के बीच अपेक्षाकृत standard interface देने के लिए इस्तेमाल किया जाने वाला RTOS-जैसा framework है
  • DCP और AOP जैसे कुछ blocks RTKit पर आधारित होते हुए EPIC नाम की एक अतिरिक्त abstraction भी रखते हैं
  • Broadcom WiFi/Bluetooth chipset जैसे मामले भी हैं, जहाँ Apple सीधे नियंत्रित न किए गए third-party firmware का उपयोग करता है
  • Apple Video Decoder, यानी AVD, RTKit या EPIC नहीं बल्कि एक अलग architecture वाला firmware इस्तेमाल करता है

  • AVD architecture और पुराने तरीके की समस्या

    • AVD hardware ARM Cortex-M3 के काफ़ी करीब है, जो AVC(H.264), HEVC(H.265), VP9, और नए SoCs में AV1 video frames decode करने वाली fixed-function hardware units को नियंत्रित करता है
    • Cortex-M3 एक interface देता है जिससे XNU video data की ओर इशारा कर सके, और फिर वह firmware blob चलाता है जो वास्तविक decoder hardware को configure करता है
    • Apple AVD firmware और configuration data को AVD kext के भीतर साथ में रखता है
    • क्योंकि हर SoC थोड़ा अलग AVD variant इस्तेमाल करता है, Asahi Installer को kext के भीतर firmware data offsets में बदलाव को लगातार track और update करना पड़ता है, जिससे logistics की समस्या पैदा होती है

  • custom firmware approach

    • XNU द्वारा load किया गया AVD firmware Cortex-M3 पर verify नहीं होता
    • signal मिलते ही यह reset vector से execute होता है, इसलिए अंदर जो भी code हो, वह चल जाता है
    • firmware का काम मूल रूप से video decoder hardware को abstract करना है, इसलिए अगर हर hardware block के interrupt handlers install कर दिए जाएँ, तो Linux driver सीधे programming कर सकता है
    • क्योंकि यह standard Cortex-M3 code है, AVD firmware emulator में चलाया जा सकता है
    • QEMU single-step execution और bus/register operations की जाँच का support देता है
    • Jamie, R, और Eileen ने पहले के सहयोग में AVC और VP9 decoders के लिए ज़रूरी commands और data formats का reverse engineering किया था
    • XNU kext हर AVD revision के लिए अलग tunables भी लागू करता है
    • ये values वास्तव में क्या करती हैं, यह पूरी तरह स्पष्ट नहीं है
    • इनका लागू होना XNU के MMIO write replay के काफ़ी करीब है
    • हर AVD revision, tunable set, और target revision को track करना पड़ता है
    • इसे upstream Linux kernel driver में संतोषजनक ढंग से maintain करना कठिन है, इसलिए यह हिस्सा भी firmware में रखना अधिक उचित है

  • V4L2 AVC driver

    • नए contributor sofus ने एक बुनियादी custom AVD firmware बनाया है, जो interrupt handlers install करता है और हर variant के tunables लागू करता है
    • इसी आधार पर AVC hardware के लिए काम करने वाला V4L2 driver लिखा गया है
    • hardware 10-bit AVC encoded video को 4K तक decode कर सकता है
    • यह V4L2 Request API लागू करने वाले software के साथ अच्छी तरह काम करता है
    • अगर firmware को सरल और stateless रखा जाए, और userspace व kernel video data parsing तथा decoder programming संभालें, तो आगे VA-API या Vulkan Video जैसे दूसरे video acceleration APIs का support जोड़ना भी आसान होगा
    • users को AVD support देने के लिए अभी काम बाकी है
    • AVD VP9, HEVC, और कुछ SoCs पर AV1 भी support करता है, लेकिन यह अभी implement नहीं हुआ है
    • कुछ devices के quirks की testing करके उन्हें driver में जोड़ना भी बाकी है
    • distributable form बहुत दूर नहीं, बल्कि अपेक्षाकृत निकट भविष्य का लक्ष्य है

m1n1 1.6.0 release

  • m1n1 1.6.0 tag किया जा चुका है, और distribution के नज़रिए से यह बड़ा प्रभाव डालने वाला release है
  • इस version में पहली बार stage 2 build के लिए Rust अनिवार्य है
  • पहले Rust केवल chainloading support शामिल करके build करने पर इस्तेमाल होता था
  • stage 1 m1n1 Apple boot tools में XNU kernel की जगह लेता है, और केवल EFI System Partition को mount करके वहाँ से stage 2 m1n1 को chainload करने के लिए उपयोग होता है
  • GPU initialization को m1n1 में ले जाने से kernel driver को Apple hardware initialization data में मौजूद floating-point values संभालने की ज़रूरत नहीं रही, और Devicetree bindings भी काफी सरल हो गईं
  • भविष्य में Linux Kernel Mailing List को भेजे जाने वाले GPU driver versions इस धारणा पर निर्भर करेंगे कि m1n1 यह initialization करता है
  • Apple Device Tree parsing code को भी Rust में port किया गया है, और m1n1 के लगभग हर दूसरे हिस्से में इसका उपयोग होता है

  • build और target

    • m1n1 वस्तुतः firmware है, इसलिए यह no_std Rust का उपयोग करता है और aarch64-none-softfloat को target करता है
    • अनावश्यक dependencies खींचने से बचने के लिए make को BUILDSTD=1 के साथ चलाया जा सकता है, ताकि पूरा softfloat toolchain install किए बिना core और alloc build किए जा सकें

  • M3, M4, A18 Pro की तैयारी

    • 1.6.0 में M3 सीरीज़ support के लिए कई improvements भी शामिल हैं
    • SPMI controller support
    • PCIe initialization support
    • kisd के जरिए SoC hardware UART की DebugUSB direct tunneling support
    • DebugUSB UART tunneling लगभग Central Scrutiniser जैसी क्षमता दे सकती है
    • इस काम का बड़ा हिस्सा भी Yureka का योगदान है
    • M4 और A18 Pro, यानी MacBook Neo support के लिए groundwork भी चल रहा है
    • Apple के non-macOS boot mode को अब बेहतर तरीके से संभाला जाता है
    • Apple Device Tree में मौजूद नए power domain metadata का support जोड़ा गया है

sponsors और contributors

  • Asahi Linux, GitHub Sponsors और Open Collective के supporters का आभार व्यक्त करता है
  • इन्हीं sponsors की वजह से अधूरे M1·M2 features, M3·M4·A18 Pro support, और नए contributors के समर्थन का काम जारी रखा जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की रायें

  • “ऑडियो IC के लिए वास्तविक industry standard I²C-आधारित बस I²S है, जो ऑडियो डेटा के लिए optimized है” कहना सही नहीं है। I²S का I²C से कोई संबंध नहीं है
    ज़्यादातर I²S चिप्स में I²C interface लगा होता है, लेकिन वजह यह है कि I²S सिर्फ raw audio data ढोता है और उसमें volume control या clock settings जैसे अतिरिक्त signals नहीं होते
    लेकिन वह एक अलग interface है, और I²C की जगह SPI भी हो सकता है। असल में I²C की तुलना में SPI, I²S के ज़्यादा करीब है

    • सही है, I²S, SPI के कहीं ज़्यादा करीब है
      दोनों के समान naming scheme अपनाने की वजह यह है कि Philips Semiconductor (अब NXP) ने दोनों बनाए थे
    • I²S हैरान कर देने वाला simple design है। protocol handshake नहीं है, बस raw PCM बहता रहता है
      मुझे यह बात पसंद है कि इसे ऐसे design किया गया है कि transmitter और receiver अलग-अलग sample bit depth को दोनों दिशाओं में इस्तेमाल करें, तब भी compatibility problem न हो
      https://web.archive.org/web/20070102004400/http://www.nxp.co...

  • यह सचमुच अद्भुत है कि motivate हुए कुछ लोग ऐसे issues सुलझा लेते हैं

    • कई issues बिल्कुल भी solve नहीं हुए हैं। उदाहरण के लिए Apple Silicon का PSCI power management interface अब भी mystery है
      दूसरे Linux devicetrees में PSCI code है, लेकिन Apple ने इसे कैसे implement किया है, यह किसी को नहीं पता। इसलिए Asahi users लगभग 5 साल से battery लगातार drain न हो, इसके लिए hacks पर निर्भर रहे हैं, और जहां तक मुझे पता है अब तक कोई promising solution भी नहीं है
      यही reverse engineering का उजला और अंधेरा पक्ष है। इन devices के लिए native Vulkan 1.2 driver आना बढ़िया है, लेकिन वहां तक पहुंचने में कई साल लगे। Apple Silicon release हुए 7 साल हो चुके हैं, फिर भी unresolved issues बचे हैं, और latest hardware का ज़्यादातर हिस्सा overall supported नहीं है। आखिर में Linux users जो सबक हमेशा कहते आए हैं, उसी निष्कर्ष पर लौटते हैं: proprietary drivers अच्छे नहीं होते

  • यह हिस्सा खास तौर पर चिंताजनक है कि XNU द्वारा load किए गए firmware को CM3 verify नहीं करता, और signal आने पर actual content चाहे जो भी हो, reset vector से execution शुरू कर देता है
    proprietary और लगातार बदलते target के सामने custom firmware लिखने की उपलब्धि शब्दों में बयां नहीं की जा सकती, लेकिन Apple जानबूझकर third-party operating systems को तोड़े नहीं—इस उम्मीद से अलग, firmware blobs या runtime पर hardware programming को दी जाने वाली data में hardware signing लाने की संभावना कम नहीं लगती। Apple के नज़रिए से यह reasonable security concern हो सकता है। फिर भी उम्मीद है कि यह दांव सफल हो

  • सोच रहा हूं कि क्या यह हमेशा Fedora “remix” ही बना रहेगा। क्या कभी upstream support आएगा ताकि Debian-based distribution चलाया जा सके?
    मुझे लगता है पिछली बार RPM-based distribution इस्तेमाल किए लगभग 20 साल हो गए

    • patches upstream भेजे जा रहे हैं, इसलिए आखिरकार upstream Linux में जरूरी drivers आ जाएंगे
      बेशक kernel fork भी open source है, इसलिए Debian aarch64 root लेकर Asahi kernel खुद build करने या Fedora build लेकर इस device पर Debian खुद configure करने से कोई रोक नहीं है। बस थोड़ा manual काम है
      अगर Ubuntu ठीक है तो Ubuntu Asahi भी है: https://ubuntuasahi.org/
      search करने पर यह wiki document भी मिला: https://wiki.debian.org/InstallingDebianOn/Apple/M1
    • मेरी पसंद उलटी है, इसलिए यह comment मुझे मजेदार लगा। मैं RPM-based distributions पसंद करता हूं और लगभग हर जगह मुख्य रूप से Fedora इस्तेमाल करता हूं। M1 Ultra Mac Studio पर भी Fedora Asahi Remix इस्तेमाल करता हूं, और सिर्फ कुछ cloud instances पर कभी-कभी Ubuntu और Debian इस्तेमाल करता हूं
      इसलिए किसी खास distribution को, जिससे आप पहले से familiar हैं, लगातार इस्तेमाल करना चाहने की भावना समझ में आती है। काम कम होता है और structure के subtle differences कम याद रखने पड़ते हैं। फिर भी जब मजबूरी में कोई नया distribution इस्तेमाल करना पड़ा, जैसे जब Asahi शुरू में सिर्फ Arch Linux ARM के लिए आया था, तो उससे मिली छोटी learning पर मुझे कभी पछतावा नहीं हुआ
    • Arch अब भी इस्तेमाल किया जा सकता है और Ubuntu Asahi भी है
      सभी distributions को आसानी से port किया जा सके, इसी वजह से upstream काम पर काफी मेहनत की जा रही है
      https://ubuntuasahi.org/
    • Bananas Team Apple Silicon पर standard Debian चलाने पर काम कर रही है, और unofficial repository जोड़कर अभी install करने का तरीका भी है: https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
      अभी खुद install करके नहीं देखा है
    • linux-asahi Void Linux में भी उपलब्ध है
      https://voidlinux.org/download/#arm%20platforms
      यह distribution के अंदर एक सामान्य Linux package है: https://github.com/void-linux/void-packages/tree/master/srcp...

  • M3 support की अच्छी प्रगति देखकर अच्छा लग रहा है
    M3 support जोड़ने का काम शुरू करने का पहली बार जिक्र फरवरी में हुआ था
    “काफी समय से m1n1 में M3 series devices के लिए basic support मौजूद था। जो चीजें missing थीं, वे थीं हर device के लिए devicetree और Linux kernel driver patches, ताकि M2 से अलग M3-specific hardware characteristics और changes support किए जा सकें। मौजूदा patchset ज़्यादा manageable हो जाए तो इस काम को shape देने का इरादा हमेशा से था”
    https://asahilinux.org/2026/02/progress-report-6-19/

  • यह जानकर उत्साह है कि AVD driver पर काम हो रहा है

  • M1 या उससे नए Mac पर ffmpeg या VLC इस्तेमाल करने पर क्या AVD इस्तेमाल होता है?

  • Asahi एक व्यवहार्य विकल्प बन सकता है, लेकिन इतने फंड और इतनी छोटी टीम के साथ development की गति बहुत धीमी होना लाज़मी लगता है
    लेख में जैसा कहा गया है, पहले से रखी गई बुनियादी groundwork है और उसके नतीजे भी हैं, लेकिन आखिरकार हर साल नए chips और ढेरों microcontrollers, GPU बदलावों वाले नए Mac आते हैं, इसलिए बराबरी करना असंभव है। इसलिए Asahi टीम भी M1 और M2 models पर ज़्यादा ध्यान दे रही है
    फिर भी अब तक दोनों में idle power management और Alt-DP implementation की समस्याएँ बची हुई हैं, जिसकी वजह से बहुत से लोग switch नहीं कर पा रहे। जब तक यह समस्या polish होगी, तब तक devices की value भी काफी गिर चुकी होगी
    इतने कम लोगों ने इतना कुछ कर दिखाया, यह चमत्कार है, लेकिन व्यापक media coverage के बावजूद आखिरकार लगता है कि टीम का जुनून और motivation कम हो गया है, और M1 Air तक पूरा नहीं हो पाएगा ऐसा दिखता है

    • “development की गति बहुत धीमी होना लाज़मी है” के बजाय, नए leadership team के आने पर उन्होंने घोषणा की थी कि वे latest hardware support जोड़ने से पहले मौजूदा काम को upstream करने को प्राथमिकता देंगे
      changes को kernel में upstream करने में समय लगा
      अब उन्होंने फरवरी में M3 पर काम शुरू करने की घोषणा की, और progress भी अच्छी दिख रही है
      “ऊपर की बातों के अलावा, M3 series devices पर PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad और अन्य core SoC block drivers भी Linux में काम करते हैं। इस काम का अधिकांश हिस्सा Yureka ने संभाला, और वह कुछ समय से M3 series devices पर m1n1 और Linux दोनों को बहुत सक्रिय रूप से hack कर रही हैं। Asahi Installer में इन devices को support करना शुरू करने के लिए अभी लंबा रास्ता बाकी है, लेकिन progress तेज़ है, इसलिए नज़र बनाए रखें!”
      यह विनाश से ज़्यादा प्रतिभाशाली लोगों द्वारा बारीकी से काम पूरा करने जैसा है
    • अगर वे हर कुछ सालों में सिर्फ एक model को target करके उसे ठीक से काम करने लायक बना सकें, तो यह कोई विकल्प न होने से कहीं बेहतर है
      M1 support आजकल काफी usable है, और काम का कम-से-कम कुछ हिस्सा future devices तक भी carry over होगा। सब कुछ गुलाबी नहीं है, लेकिन यह कोई ऐसा project भी नहीं है जिसकी failure तय हो

  • काश Apple एक छोटी team को fund करके documentation और drivers के कुछ हिस्से open source में release करे और Asahi की मदद करे
    बेशक पता है कि वे ऐसा नहीं करेंगे, लेकिन सपना तो देख सकते हैं। Apple के लिए यह pocket change होगा, और ऐसा करने से उनका hardware Silicon Valley engineers का de facto standard और भी मजबूत हो जाएगा

    • Apple का अपना Hypervisor framework उस बात के काफी करीब है, इसलिए मैं UTM app से Fedora और Arch Linux builds चलाता हूँ। इसे emulation नहीं, बल्कि Apple Silicon virtualization इस्तेमाल करने के लिए set किया है, और UTM उस framework के ऊपर एक wrapper है
      यह इतना बढ़िया है कि कुछ साल पहले इसने मुझसे Asahi हटवाकर फिर से format करवा दिया था
      https://developer.apple.com/documentation/hypervisor
      https://docs.getutm.app/installation/macos/

  • जिज्ञासा है कि हाल में Asahi ने large language models का कितना उपयोग किया है। reverse engineering के लिए यह सच में powerful tool है; क्या उन्होंने इस बारे में कभी लिखा है?

  • जिज्ञासा है कि इस project का development/CI process कैसा दिखता है
    आखिर हर बार किसी specific hardware पर build को manually load करना पड़ता है, या कोई ऐसा stage है जहाँ कुछ हद तक automation संभव है?

    • m1n1 यहाँ काफी दिलचस्प काम करता है: https://asahilinux.org/docs/sw/tethered-boot/
      यह real hardware और kernel के बीच एक बहुत पतली layer रखता है, लेकिन hardware I/O behavior को प्रभावित किए बिना kernel loading और debugging को remotely control और automate करने देता है