Ontwikkelaars krijgen experimentele build Asahi Linux werkend op M2-chips

De makers van Asahi Linux hebben een experimentele versie van de distributie uitgebracht die werkt op Apples M2-chip. Het gaat om een experimentele build die wel opstart, maar nog verre van goed werkt.

De makers van Asahi Linux schrijven in een blogpost dat de makers al relatief snel een port van het OS naar Apples M2-chip hebben kunnen maken. Op het moment werkt dat rudimentair: de distro boot met ondersteuning voor USB, NVMe, accustatus en wifi, maar er is ook nog veel dat niet goed werkt. Zo werkt het toetsenbord nog niet in U-Boot en Grub. Daarvoor hebben gebruikers dus een extern toetsenbord nodig. Inmiddels werken het toetsenbord en trackpad wel in de distro, waarmee het besturingssysteem al wel te gebruiken is.

De makers zeggen dat ze het besturingssysteem alleen nog hebben getest op een MacBook Pro 13". Ook zou er ondersteuning zijn voor de MacBook Air, maar dat hebben de makers nog niet getest. De ontwikkelaars zeggen dat de Linux-versie is gebaseerd op macOS 12.4. Het team achter Asahi wil daar geen langetermijnondersteuning voor geven en waarschuwt gebruikers dat ze op een later moment handmatig bootcomponenten naar macOS 13.0 moeten upgraden.

De installatie werkt volgens de makers alleen als gebruikers de expertmodus inschakelen in de Asahi Installer. Ze waarschuwen ook dat veel componenten waarschijnlijk nog niet werken.

Asahi Linux werkt al langer aan een Linux-versie voor Apples eigen socs. In maart bracht het bedrijf voor het eerst een alphabuild uit voor computers met de M1-chip. Daar ging veel werk aan vooraf, maar de makers zeggen dat toekomstige distro's een stuk makkelijker te porten zullen zijn naar nieuwe Apple-chips zoals de M2.

Reacties (89)

[CasperArkema]

Ik ben (meer dan) een beetje een leek op dit gebied. Kan iemand mij uitleggen wat er bijzonder is aan het draaien van een Linux build op deze chips?

[CAPSLOCK2000]

Het is alsof je als Nederlander zonder tolk naar China gaat en direct mee probeert te doen in het dagelijks leven en zware baan neemt. Niet alleen is de taal totaal anders, ook de cultuur, gewoontes, het eten, het bestek (stokjes), het weer, het hout (bamboe), helemaal alles is anders. Het minimale om te overleven doen is al een enorme stap. Je moet heel veel in een keer goed doen anders wordt het niks.

Daar staat tegenover dat Linux het OS met de grootste talenknobbel is. Linux heeft al op zo ontzettend veel verschillende soorten hardware gedraait dat het alles wel een keer eerder heeft gezien. Het kan schalen van klein naar groot en is min of meer vrij van aannames en constructies die afhankelijk zijn van een bepaald soort hardware.
We zijn daarom een beetje gewend aan nieuwsberichten over hoe iemand Linux werkend heeft gekregen op een nieuw of bijzonder stuk hardware. Er zijn gewoon handboeken hoe je zo iets aanpakt. Maar eigenlijk is het best wel een bijzondere prestatie, zeker voor een stel hobbyisten die geen toegang tot informatie kunnen kopen.

[Bulkzooi]

lol..

Het aparte hier is toch wel dat MacOS een fork is van GNU/Linux.

[O085105116N]

Nee. MacOS is gebaseerd op BSD en de mach kernel. Dat is zeker geen linux kernel zoals in het artikel wordt beschreven.

[Bulkzooi]

@YoMarK @O085105116N
Hoe is die (Free)BSD gecompileerd dan? En wat is het verschil tussen Linux en GNU/Linux? En hoe verhouden kernel, OS en distro zich technisch tot elkaar?

Of hebben we het over licenties? BSD vs. GPL?

Ik heb wel het e.e.a nagelezen maar het valt niet mee om eenduidig conclusies te trekken. Het ligt er ook aan op welk moment in tijd, want GPL v2 is niet hetzelfde als GPL v3.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[NanoSector]

Apple heeft hun eigen compiler, AppleClang, ik vermoed dat de macOS kernel daarmee gecompileerd wordt.

GNU/Linux is min of meer GNU+Linux, aangezien het aanduidt dat de kernel Linux is en de meeste belangrijke userspace componenten van het GNU project af komen (glibc als standard library bijvoorbeeld, gcc als compiler, …).

Een distro is een operating system waarin typisch een kernel zich bevindt samen met andere componenten. Je zou een distro een OS kunnen noemen maar de definitie van een OS is vaag in deze context (is het de kernel? Is het de terminal UI? Waaraan moet userspace voldoen?)

macOS is een distro van Darwin, met daarop een eigen Apple userspace (en vast nog duizenden componenten in de kernel). Darwin op zijn beurt heeft als hart de XNU kernel wat op zijn beurt weer bestaat uit componenten van BSD en Mach.

[Bulkzooi]

@NanoSector AppleClang is een taal. De compiler heet LLVM.

@sspiff Hoe wordt die kernel gecompileerd dan? En wat maakt het anders als je een OS compiled? Ik weet het verschil tussen een distro en een OS; flavour. De rest is hetzelfde. Is er een speciale BSD compiler dan die geen GCC of LLVM is?

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[NanoSector]

AppleClang is geen taal. C/C++ zijn een aantal van de ondersteunde programmeertalen, LLVM is een onderdeel waar de Clang & dus ook AppleClang compiler gebruik van kunnen maken.

Clang een compiler noemen is ook niet helemaal juist maar versimpelt het verhaal genoeg dat het op dit niveau irrelevant is. Maar om in details te treden:

https://en.m.wikipedia.org/wiki/Clang

“Clang is a compiler front end for the C, C++, Objective-C, and Objective-C++ programming languages,
…
Clang operates in tandem with the LLVM compiler back end“

Clang (& AppleClang) is dus een abstractie laag oftewel frontend over andere tools heen, waaronder dus LLVM. Het versimpelt het gebruik ervan.

[Bulkzooi]

ik zie Clang (& AppleClang) als software geschreven in C en gebruikt tijdens het compileren (evt. met GCC of LLVM) van Apple producten.

[NanoSector]

Clang kan best geschreven zijn in C, maar zo veel software is dat. Er is niks taal-achtigs aan Clang; het is een command line tool om het compileren van software net een stapje makkelijker te maken. Of ik snap niet wat je bedoelt.

Clang kan (vziw) geen GCC gebruiken; GCC is echt een alternatief voor de LLVM+Clang stack.

Je hebt hulpmiddelen in de vorm van build systemen als Make die hun eigen bestandsformaten kunnen inlezen, misschien dat je dat beter als 'taal' kunt zien. Apple gebruikt dit ook voor XNU, de Darwin kernel: https://github.com/apple-...ns/xnu/blob/main/Makefile

Hoe dit dan weer voor XNU in elkaar zit lijkt intens complex en ik heb geen tijd/zin om dit uit te gaan pluizen, maar onder water worden met dit soort systemen allerlei commando's aan elkaar geknoopt om een product te realiseren. Veelal bestaat dit 'aan elkaar knopen' uit de juiste flags/opties en de benodigde bestanden als parameters aan de compiler frontend (Clang/GCC) doorgeven. De compiler frontend gaat vervolgens nog wat lagen dieper om de geschreven code met elkaar in verband te zetten, om te zetten naar machine code en ondertussen de boel te optimaliseren, niet persé in die volgorde.

Jouw build environment definieert welke compiler er gebruikt moet worden. Zie ook de CMake (een ander build systeem) documentatie: https://gitlab.kitware.co...-use-a-different-compiler

Er is bij Apple vast ergens een buildbot die dit hele zooitje in elkaar knutselt en er een zogenaamd artifact van maakt, oftewel een bruikbaar product wat uit de bouwfase komt. Dit zal dan in de vorm van een executable zijn; bij macOS zit deze op /System/Library/Kernels/kernel, Linux distros zetten de images vaak in de /boot partitie. Deze kernel executable wordt vervolgens samengevoegd met de hele userspace die erbij hoort; hoe dit proces in zijn werk gaat ontgaat mij. Dat vormt de distro; de hele collectie aan software.

In productie start jouw computer de bootloader vanuit de firmware (BIOS via het inlezen van een MBR boot sector, (U)EFI via het inlezen van de bootloader executable vanuit de EFI System Partitionvia in de firmware ingebakken bestandssysteem ondersteuning, op x86 in ieder geval), op macOS staat deze op /System/Library/CoreServices/boot.efi. Deze bootloader weet vervolgens hoe deze kernel executable moet worden uitgevoerd en met welke opties. Vaak zit de functionaliteit voor dual-booten ook in deze executable (maar niet op macOS; op een Mac is de firmware daar zelf verantwoordelijk voor).

De kernel start op, initialiseert hardware en, in het geval van Linux en XNU, start vervolgens een beginproces oftewel PID 1. Op Linux distros is dit veelal (niet altijd) systemd, op Darwin/macOS is dit launchd. Dit proces is verantwoordelijk voor het opstarten van de rest van userspace, dus alle achtergrond processen, de GUI, etcetera.

Ik laat heel veel details achterwege nu en er is vast iemand die dit strakker of in meer detail kan uitleggen. Verheldert dit wat de verschillende componenten nu doen voor je?

[Reactie gewijzigd door NanoSector op 23 juli 2024 04:47]

[Bulkzooi]

Clang kan best geschreven zijn in C, maar zo veel software is dat. Er is niks taal-achtigs aan Clang; het is een command line tool om het compileren van software net een stapje makkelijker te maken. Of ik snap niet wat je bedoelt.

Clang kan (vziw) geen GCC gebruiken; GCC is echt een alternatief voor de LLVM+Clang stack.

Je zal toch een programmeertaal moeten gebruiken. Hoe denk jij die die prompt gaat flikkeren dan? Maar ik geloof dat inderdaad na een tijdje Clang in LLVM, ook GCC toolchain werd bereikt. Ik zie alleen het verschil tussen Clang & AppleClang niet zo goed.
En in 't algemeen, hoe denk jij dat een command line tool begrijpt wat een gebruiker typt?

Je hebt hulpmiddelen in de vorm van build systemen als Make die hun eigen bestandsformaten kunnen inlezen, misschien dat je dat beter als 'taal' kunt zien. Apple gebruikt dit ook voor XNU, de Darwin kernel: https://github.com/apple-...ns/xnu/blob/main/Makefile

Ken je Dos?
https://en.wikipedia.org/wiki/MS-DOS
In die tijd, was de style om software te maken veel anders, en handhaafde de lijst met afhankelijkheden, i.t.t. make. Sommige projecten zijn nog steeds op die manier ingericht en dergelijke strategien leggen momenteel geen windeieren. Ikzelf ben van mening dat programming paradigma's uit die periode toch wel de beste zijn.

Een goed stuk hieronder, met als toevoeging dat zo'n programmeertaal een station nodig heeft om op te schrijven en om het systeem uit te leveren aan de finale consument, de eind-gebruiker. Dat zijn de ontwikkelingen tussen bios & hypervisor, waar de verschillen tussen GPL v2 & v3 erg duidelijk zijn, qua software stack (en Open Source strategiën)

Hoe dit dan weer voor XNU in elkaar zit lijkt intens complex en ik heb geen tijd/zin om dit uit te gaan pluizen, maar onder water worden met dit soort systemen allerlei commando's aan elkaar geknoopt om een product te realiseren. Veelal bestaat dit 'aan elkaar knopen' uit de juiste flags/opties en de benodigde bestanden als parameters aan de compiler frontend (Clang/GCC) doorgeven. De compiler frontend gaat vervolgens nog wat lagen dieper om de geschreven code met elkaar in verband te zetten, om te zetten naar machine code en ondertussen de boel te optimaliseren, niet persé in die volgorde.

Jouw build environment definieert welke compiler er gebruikt moet worden. Zie ook de CMake (een ander build systeem) documentatie: https://gitlab.kitware.co...-use-a-different-compiler

Er is bij Apple vast ergens een buildbot die dit hele zooitje in elkaar knutselt en er een zogenaamd artifact van maakt, oftewel een bruikbaar product wat uit de bouwfase komt. Dit zal dan in de vorm van een executable zijn; bij macOS zit deze op /System/Library/Kernels/kernel, Linux distros zetten de images vaak in de /boot partitie. Deze kernel executable wordt vervolgens samengevoegd met de hele userspace die erbij hoort; hoe dit proces in zijn werk gaat ontgaat mij. Dat vormt de distro; de hele collectie aan software.

In productie start jouw computer de bootloader vanuit de firmware (BIOS via het inlezen van een MBR boot sector, (U)EFI via het inlezen van de bootloader executable vanuit de EFI System Partitionvia in de firmware ingebakken bestandssysteem ondersteuning, op x86 in ieder geval), op macOS staat deze op /System/Library/CoreServices/boot.efi. Deze bootloader weet vervolgens hoe deze kernel executable moet worden uitgevoerd en met welke opties. Vaak zit de functionaliteit voor dual-booten ook in deze executable (maar niet op macOS; op een Mac is de firmware daar zelf verantwoordelijk voor).

De kernel start op, initialiseert hardware en, in het geval van Linux en XNU, start vervolgens een beginproces oftewel PID 1. Op Linux distros is dit veelal (niet altijd) systemd, op Darwin/macOS is dit launchd. Dit proces is verantwoordelijk voor het opstarten van de rest van userspace, dus alle achtergrond processen, de GUI, etcetera.

Ik laat heel veel details achterwege nu en er is vast iemand die dit strakker of in meer detail kan uitleggen. Verheldert dit wat de verschillende componenten nu doen voor je?

Top!

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[NanoSector]

Je zal toch een programmeertaal moeten gebruiken. Hoe denk jij die die prompt gaat flikkeren dan?

Dat is de terminal-shell samen met een terminal-emulator, vaak bash, tegenwoordig op macOS standaard zsh, op Windows PowerShell. Jouw prompt die binnen jouw terminal-shell actief is vraagt de gebruiker voor input, onder water wordt dit geparset en dit resultaat wordt via een standaard system call bij het aanmaken van het proces aan het programma doorgegeven (de main() functie). Dat "parsen" kan je zien als de taal van jouw terminal-shell. Of dit technisch een programmeertaal of scripttaal is is een discussie voor een andere keer.

Feit blijft dat Clang op zichzelf geen taal implementeert.

En in 't algemeen, hoe denk jij dat een command line tool begrijpt wat een gebruiker typt?

Niet Er zijn hele software libraries en frameworks gewijd aan het interpreteren van argumenten. Een programma krijgt gewoon een lijstje met strings met de argumenten die zijn meegegeven tijdens het opstarten ervan, in de volgorde dat die zijn gegeven. Per programma verschilt de implementatie van het interpreteren hiervan. Op deze manier kan de gewenste actie van de gebruiker worden achterhaald.
Dit is niet zozeer een taal, het is meer een lijst met mogelijke knopjes en bijbehorende schakelaars. Het control panel van Clang ziet er anders uit dan het control panel van bijvoorbeeld launchctl.

Maar, om je toch tevreden te stellen; het is niet onmogelijk om iets wat lijkt op een taal te implementeren via dit systeem. Bijna niets (naast een hoop geklooi met escape characters ) staat je in de weg om al de argumenten te pakken en te interpreteren op zo'n manier dat je er echt iets functioneels mee kan maken. AWK is een van deze programma's die dit doet: https://en.wikipedia.org/wiki/AWK
Clang is echter niet op dit niveau maar meer op het niveau van een control panel zoals in beschreef.

Ik zie alleen het verschil tussen Clang & AppleClang niet zo goed.

AppleClang is een fork van Clang+LLVM vanuit Apple met verschillende ondersteuning voor een aantal features (en vast nog meer wijzigingen). Zie ook https://en.cppreference.com/w/cpp/compiler_support voor bijvoorbeeld de C++ features.
Deze versie wordt met Xcode geleverd en standaard gebruikt op & voor Apple platformen. Waarom ze deze fork hebben gemaakt weet ik niet, wellicht over onenigheid over de originele versie of "wij denken het beter te kunnen."

Een goed stuk hieronder, met als toevoeging dat zo'n programmeertaal een station nodig heeft om op te schrijven en om het systeem uit te leveren aan de finale consument, de eind-gebruiker. Dat zijn de ontwikkelingen tussen bios & hypervisor, waar de verschillen tussen GPL v2 & v3 erg duidelijk zijn, qua software stack (en Open Source strategiën)

Licentie technisch is er natuurlijk veel te zeggen en ook macOS moet aan GPLv3 voldoen en de componenten die ze gebruiken en/of aanpassen beschikbaar maken, Apple heeft hiervoor een heel open source platform online staan. https://opensource.apple.com/

Dit "station" wat je noemt zullen workstations zijn bij Apple. In principe maakt het niet uit wat dit is, als de gewenste code er maar op gecompileerd kan worden. Bij wijze van spreken hebben ze AppleClang op Linux draaien en maken & bouwen ze XNU daarop. Sterker nog, ik verwacht dat zo'n situatie sowieso het geval is voor buildbots binnen het bedrijf, aangezien macOS niet goed geschikt is voor server doeleinden. Of ze hebben een eigen build van macOS draaien voor dit specifieke scenario.

Ik snap niet goed waar een hypervisor in dit verhaal geplaatst moet worden; dat is voor virtuele machines. En al helemaal niet wat dit te maken heeft met GPLv2 of v3. Apple's Hypervisor.framework (https://developer.apple.com/documentation/hypervisor) is compleet closed-source, misschien dat de code in XNU hiervoor open is.

[Bulkzooi]

[...]

Dat is de terminal-shell samen met een terminal-emulator, vaak bash, tegenwoordig op macOS standaard zsh, op Windows PowerShell. Jouw prompt die binnen jouw terminal-shell actief is vraagt de gebruiker voor input, onder water wordt dit geparset en dit resultaat wordt via een standaard system call bij het aanmaken van het proces aan het programma doorgegeven (de main() functie). Dat "parsen" kan je zien als de taal van jouw terminal-shell. Of dit technisch een programmeertaal of scripttaal is is een discussie voor een andere keer.

Feit blijft dat Clang op zichzelf geen taal implementeert.
[...]

Niet Er zijn hele software libraries en frameworks gewijd aan het interpreteren van argumenten. Een programma krijgt gewoon een lijstje met strings met de argumenten die zijn meegegeven tijdens het opstarten ervan, in de volgorde dat die zijn gegeven. Per programma verschilt de implementatie van het interpreteren hiervan. Op deze manier kan de gewenste actie van de gebruiker worden achterhaald.
Dit is niet zozeer een taal, het is meer een lijst met mogelijke knopjes en bijbehorende schakelaars. Het control panel van Clang ziet er anders uit dan het control panel van bijvoorbeeld launchctl.

Maar, om je toch tevreden te stellen; het is niet onmogelijk om iets wat lijkt op een taal te implementeren via dit systeem. Bijna niets (naast een hoop geklooi met escape characters ) staat je in de weg om al de argumenten te pakken en te interpreteren op zo'n manier dat je er echt iets functioneels mee kan maken. AWK is een van deze programma's die dit doet: https://en.wikipedia.org/wiki/AWK
Clang is echter niet op dit niveau maar meer op het niveau van een control panel zoals in beschreef.

[...]
AppleClang is een fork van Clang+LLVM vanuit Apple met verschillende ondersteuning voor een aantal features (en vast nog meer wijzigingen). Zie ook https://en.cppreference.com/w/cpp/compiler_support voor bijvoorbeeld de C++ features.
Deze versie wordt met Xcode geleverd en standaard gebruikt op & voor Apple platformen. Waarom ze deze fork hebben gemaakt weet ik niet, wellicht over onenigheid over de originele versie of "wij denken het beter te kunnen."
[...]

Apple heeft natuurlijk een geweldig slimme strategie gevolgd en ik zie ze als grootste winnaar, met de M1/M2 chip, van de laatste battle in ICT. Samen met TSMC een gouden combinatie.

Licentie technisch is er natuurlijk veel te zeggen en ook macOS moet aan GPLv3 voldoen en de componenten die ze gebruiken en/of aanpassen beschikbaar maken, Apple heeft hiervoor een heel open source platform online staan. https://opensource.apple.com/
[...]
Ik snap niet goed waar een hypervisor in dit verhaal geplaatst moet worden; dat is voor virtuele machines. En al helemaal niet wat dit te maken heeft met GPLv2 of v3.

in user-space.

In GNU/Linux is dit wel van belang, maar da's zogezegd meer filosofisch van aard. En de GPLv2 vs. v3 discussie (zoals die in het verleden eindeloos gevoerd is) is qua tijdlijn van belang. Het gevalletje MacOS betreft meer privacy en de BSD licentie, met ook de academisch wereld en de MIT-licentie. Dat vereist een iets afwachtendere benadering.

Apple's Hypervisor.framework (https://developer.apple.com/documentation/hypervisor) is compleet closed-source, misschien dat de code in XNU hiervoor open is.

dat zijn api's.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[NanoSector]

Apple heeft natuurlijk een geweldig slimme strategie gevolgd en ik zie ze als grootste winnaar, met de M1/M2 chip, van de laatste battle in ICT.

Ik weet nu niet of je sarcastisch bent. Maar wat ik noem zijn geen Apple-specifieke dingen, dit geldt voor UNIX in het algemeen. Vast ook voor Windows maar ik heb totaal geen idee wat voor rotzooi Microsoft allemaal klaarmaakt tegenwoordig

in user-space. In GNU/Linux wel van belang. En de GPLv2 vs. v3 discussie (zoals die in het verleden eindeloos gevoerd is) is qua tijdlijn van belang.

Een hypervisor is gedeeld over meerdere componenten; een stukje in de kernel (KVM in Linux, hv_support in XNU), een stuk in userspace (qemu bijvoorbeeld en dus Apple's Hypervisor.framework / Virtualization framework). Beide kunnen andere licenties hebben en toch met elkaar overweg.

Nog steeds snap ik de relevantie niet voor jouw vraagstuk en ook niet voor Asahi; we hebben het hier niet over VMs of tijdlijnen en de originele vraag was wat het verschil tussen GNU/Linux en Linux is met componenten eromheen. Sowieso heb ik niet veel kennis van licenties en de geschiedenis erachter.

dat zijn api's.

Correct, in principe is alles waar we het hier over hebben een API. Een kernel is in principe ook een "API" om een userspace op te bouwen met behulp van system calls.

[Bulkzooi]

[...]

Ik weet nu niet of je sarcastisch bent. Maar wat ik noem zijn geen Apple-specifieke dingen, dit geldt voor UNIX in het algemeen. Vast ook voor Windows maar ik heb totaal geen idee wat voor rotzooi Microsoft allemaal klaarmaakt tegenwoordig

Nee, da's absoluut niet sarcastisch en de contributie van de Amerikaanse overheid aan de ontwikkeling van de computer, vooral de personal home computer vanaf Unix, daar mag de Nederlandse overheid een puntje aan zuigen. Wat dat betreft heeft de Nederlandse overheid, o.a. met Brein, zich schandalig gedragen t.o.v. open source software.

[...]
API
[...]

Correct, in principe is alles waar we het hier over hebben een API. Een kernel is in principe ook een "API" om een userspace op te bouwen met behulp van system calls.

Hier tussen zit nog een hele wereld; je zou daar best een portal in C++ mee kunnen bouwen.

Een hypervisor is gedeeld over meerdere componenten; een stukje in de kernel (KVM in Linux, hv_support in XNU), een stuk in userspace (qemu bijvoorbeeld en dus Apple's Hypervisor.framework / Virtualization framework). Beide kunnen andere licenties hebben en toch met elkaar overweg
https://apple.stackexchange.com/a/443652

Dat stukje in Userspace heet vaak een driver maar kan ook library of .dll ergens op het systeem zijn. Dynamic Linking is al vaker besproken.
https://en.wikipedia.org/wiki/Dynamic_linker

Persoonlijk vindt ik QEMU een non-oplossing, en op GNU/Linux was/is dat brakke
systemd vaak ook nog eens de default. Totale miss-management van Open Source Code als je het mij vraagt. Ook init is niet blame-free.

de originele vraag was wat het verschil tussen GNU/Linux en Linux is met componenten eromheen

Mijn opmerking werd getriggered door het woord talenknobel in relatie tot Linux. Jij haakte in op het moment dat de thread door was ontwikkelt, via freeBSD, naar compilers en licenties. Het onderwerp van die opmerking betrof MacOS van Apple.

Edit:
Nou ik mijn comment gedigisteerd heb, blijkt dat ik wellicht een nuance moet aanbrengen: Van Vendor locked Eco-Prison to privacy Walhalla is natuurlijk geen sinecure.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[sspiff]

Los van licenties, want dat is iets puur wettelijk:

• De Mach kernel is een open source microkernel die sinds midden jaren 90 door de academische wereld ontwikkeld en onderhouden wordt. Deze is aangepast soor Apple om de basis van MacOS te vormen.
• Een kernel op zich kan erg weinig. Linux is ook een kernel, die vaak gecombineerd wordt met een hoop programma's en libraries om nuttige dingen voor een gebruiker te doen. Die programma's en bibliotheken noemt men samen vaak het "userland".
• Het stukje dat Apple van FreeBSD heeft overgenomen zijn een aantal basisprogramma's en bibliotheken. Deze zijn functioneel compatibel met de manier van werken van die Linux en veel andere Unix varianten gebruiken. Het gaat om fundamentele bouwstenen zoals bibliotheken die toestaan om onder meer andere programma's op te starten, en een hele hoop command line programma's voor systeembeheer.

[Bulkzooi]

Los van licenties, want dat is iets puur wettelijk:

Dat kan niet; na de koop moet je bij ingebruikname de licentie-voorwaarden accepteren. Dit is mn. contract-recht.

• De Mach kernel is een open source microkernel die sinds midden jaren 90 door de academische wereld ontwikkeld en onderhouden wordt. Deze is aangepast soor Apple om de basis van MacOS te vormen.
• Een kernel op zich kan erg weinig. Linux is ook een kernel, die vaak gecombineerd wordt met een hoop programma's en libraries om nuttige dingen voor een gebruiker te doen. Die programma's en bibliotheken noemt men samen vaak het "userland".
• Het stukje dat Apple van FreeBSD heeft overgenomen zijn een aantal basisprogramma's en bibliotheken. Deze zijn functioneel compatibel met de manier van werken van die Linux en veel andere Unix varianten gebruiken. Het gaat om fundamentele bouwstenen zoals bibliotheken die toestaan om onder meer andere programma's op te starten, en een hele hoop command line programma's voor systeembeheer.

Een OS is software die communiceert met hardware.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[Skender]

BSD was oorspronkelijk een reeks tools voor op een UNIX systeem (de vi editor, de C shell,...). Maar je had een commerciële UNIX licentie nodig van Bell Labs om BSD te kunnen gebruiken (jaren '70). In latere versies van BSD werd de commerciële UNIX code vervangen door eigen alternatieven (eind jaren '80). Een UNIX licentie was dan niet langer nodig. MacOS is afgeleid van die versies van BSD.

Los van BSD, was (en is) er het GNU project met als doel een "vrije" versie van UNIX te bouwen (begin jaren '80). Net als BSD begonnen ze met allerlei tools (een editor, een compiler, een shell,...) die ze in eerste instantie binnen een andere UNIX draaiden, om dan op termijn een volledig eigen UNIX te hebben, met een eigen kernel (die is er intussen ook).

Begin jaren '90 wou Linus Torvalds UNIX draaien op zijn PC. BSD ondersteunde op dat moment nog geen Intel processoren, en de GNU kernel was nog niet af. Linus schreef zijn eigen kernel (Linux) en draaide daar de GNU tools op. Dat is wat we vandaag kennen als Linux, of als GNU/Linux. Maar MacOS heeft daar niet veel mee te maken

[r_j]

Op zich merkwaardig want ik werkte in de 80er jaren met Unix V5 op een IbM compaible PC (met 16 bit 80286 processor). Dit was bij AT&T en het was natuurlijk geen officieel vrijgegeven distributie maar het was gewoon een kwestie van compileren.

[Bulkzooi]

ze verkochten denk ik, een computer met software, de IBM compatible PC (met 16 bit 80286 processor) waarbij klanten hun eigen software konden compileren. (overigens heb ik ze ook allemaal gehad voordat Intel met Pentium kwam, dus de Olivetti xt (met GW-Basic), Acer 286, de 386 & 486)

Je hebt denk ik wel de essentie te pakken; verschillende producten, setups, platformen werden verkocht aan verschillende type klanten uit verschillende landen. En het productaanbod veranderde over de tijd heen, alsmede de algemene "gebruikersrechten" voor de klant. De specifieke scenario's (lees: grote klanten) was allemaal maatwerk.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[Skender]

Het zit begin jaren '90 allemaal heel kort op elkaar. De eerste BSD versie zonder AT&T code, was in juni 1991. De eerste BSD voor PC was 386BSD met eerste release in maart 1992. De eerste Linux release was september 1991

[Bulkzooi]

Ja, de ontwikkeling van de markt voor home & personal computer was/is reuze-interessant! Van 8-bit naar 32-bit was een ultra-snelle sprint.

Mijn vader was proto-adopter , ook in de periode van juni 1991 tot maart 1992 en we hadden reeds een Olivetti XT en een 286 vóór die tijd; iedereen zat op koper maar wij op satelliet. Allemaal met DOS en GW-basic. Ik weet nog precies toen ik mijn 16 kleuren EGA monitor van 12 honderd piekermannen kreeg. Daarna heb ik een eeuwigheid gedaan met een Targa VGA beeldbuis monitor van 21 kilo of zo

Ook de impact van het software gedeelte, met DOS, mag je niet onderschatten. Mijn favo OS is toch gewoon een Single-Disk floppy met een custom DOS 5.x erop, met wat essential tools. Eigenlijk vindt ik zelfs de DOS 3.x en 4.x series al goed genoeg. Maar als een brain aangeleerd is om in Unix-style (bureaucratisch) zaken (academisch) te organiseren (open, readable), dan kunnen voorkeuren gaan variëren.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[n0np3r50n]

Nou BSD heeft misschien netwerk componenten beïnvloed maar Mac os is gewoon NextStep en Mach is geen BSD kernel.

[Skender]

Het is een combinatie van beiden dacht ik, waarbij de kernel van NextStep komt, en de command line tools hoofdzakelijk van BSD

[blorf]

Het is redelijk compatible. Ik heb een keer een FreeBSD live-stick in een Mac mini gestoken. Die startte door tot de CLI met geen grote hardwareproblemen. Verder niks geprobeerd, de toetsenbord-layout klopte niet., maar dat is waarschijnlijk wel te regelen.

[Masterrikkie]

Dat is op een Intel chipset, dit is op een M chip

[YoMarK]

Dat is niet zo, eerder (Free)BSD, maar je moet het er maar eens op nalezen.

[Loy]

Nee, zeker niet. MacOS is gebaseerd op BSD. Linux is van scratch begonnen door Linus Thorvalds. Beiden zijn UNIX-achtig en POSIX-compliant en dus zijn er veel APIs zeer vergelijkbaar en zijn er wat vandezelfde tools beschikbaar op de commandline van beiden.

[Bulkzooi]

als je de Basic hack van Bill Gates en zijn omschrijving van de GPL v2 licentie als virus erbij neemt, bij UNIX-achtig en POSIX-compliant, dan heb je de core en de essence van de Amerikaanse bigtech aardig te pakken.

Richard Stallman verteld hier al jááren over, onder andere dat Linux geen GNU/Linux is. Beveiliging is ofc een after-thought in Open Source onwikkelmethodieken, maar niet voor overheden en academici. Sterker nog, da's de hele fundering van de philosophie van de GPL licentie (een redistribute-hack op copyright, ten tijden dat copyright voornamelijk een civiele aangelegenheid was) en van Free Software Movement at large; geboren uit frustraties omtrent printer-drivers.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[rob12424]

Nee,

Apple is Unix (Darwin) based. POSIX compatible en heel ver weg gebaseerd op de Mach microkernel kernel. En Nexstep als Gui in de verte. En X

Linux is een Unix cloon van een totaal andere Unix variant. (Plan 9 ) En ook POSIX compatible.

Linux/Unix draait op xserver/X11 (X= daar wel van afgeleid) En als Gui GNOME KDE of wat anders.

Maar ik denk dat je in de war bent met Debian. Want dat draait op zowel de Linux als de Unix kernel.

https://www.debian.org/ports/kfreebsd-gnu/

De GNU tools zijn overigens in tegenstelling tot wat veel mensen denken niet ontwikkeld voor Linux. Ze zijn ontwikkeld voor GNU Hurd en dat systeem was al in ontwikkeling voor Linux en is nog steeds in de ontwikkelfase. Maar Linux kon ze wel gebruiken en daarom is het GNU/Linux.

https://www.debian.org/ports/hurd/

Daarnaast is de Mach/Darwin Kernel van MacOS Hybride ingericht en die van Linux Monolithische.

Zie ook: https://en.m.wikipedia.org/wiki/Unix-like

[Bulkzooi]

ik geloof dat de Unix philosophy ook geïnterpreteerd wordt als to oursource everything
https://en.wikipedia.org/wiki/Unix_philosophy

Die GNU tools is een buigbaar begrip en het GNU Hurd systeem is nooit uitgeleverd volgens mij. GNU GCC is een concretere benaming
https://gcc.gnu.org/

En idd, X11 is erg belangrijk voor in de huidige 4e wave Linux Desktop's. Dus die compositor komt van Unix? Het lijkt mij logisch dat de (graphische) relatie met Apple o.a. in de BSD licentie schuilt.
https://www.freebsd.org/internal/software-license/

En aangezien Userspace rekbaar is maar zeker ook verder reikt dan een POSIX compatible kernel, is validatie dan ook één van de speerpunten in bv. zo'n FIPS programme
https://www.nist.gov/itl/fips-general-information

Wat betreft
https://www.debian.org/ports/kfreebsd-gnu/
Debian GNU/kFreeBSD is een port die bestaat uit het GNU userland en de GNU C-bibliotheek, bovenop de kernel van FreeBSD, met daarbij de gebruikelijke pakketten van Debian.

Debian GNU/kFreeBSD is geen officieel ondersteunde architectuur. Ze werd met Debian 6.0 (Squeeze) en 7.0 (Wheezy) uitgebracht als een technology preview en de eerste niet-Linux port. Sinds Debian 8 (Jessie) behoort ze echter niet langer tot de officiële releases.

Ikzelf ben niet echt super bekent met Debian, maar Mark Shuttleworth van Ubuntu ken ik wel vanwege zijn rants. Maar blijkbaar was Debian GNU/kFreeBSD een architectuur die ondersteund werd als officiële ports van Debian 6/7.x. Is er iets bijzonders aan deze zgn. Debian GNU/kFreeBSD port, behalve dat het een architectuur genoemd wordt?

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[DeeD2k2]

Om software te draaien op hardware moet je weten hoe de software met de hardware moet communiceren. Hoewel Apple Silicon op ARM gebaseerd is, zijn de specifieke instructies niet openbaar. De ontwikkelaars hebben dus met behulp van reverse engineering zelf moeten uitzoeken hoe Linux met de M* chips en gerelateerde hardware moet praten…

[youridv1]

Volledig custom hardware en je kunt nul support verwachten vanuit Apple.

[Marve79]

Wel jammer. Denk dat Apple zichzelf hiermee wel benadeelt. Ik wil best een laptop met M2 cpu maar ik wil geen MacOS. Als Linux volledig supported zou zijn zou dat zeker interessant zijn. Dit soort hobbyprojects zijn leuk hoor maar totaal niet geschikt als daily driver. En niets staat Apple in de weg de boel te frustreren of zelfs te blokkeren.

Maarja Apple wil je natuurlijk volledig in hun ecosysteem hebben en niet alleen éénmalig een laptop aan je verkopen en vervolgens niets meer aan je verdienen. Dat is heel hun business model.

[youridv1]

De reden om apple te kopen is dan ook de combinatie hard en software. Als je geen MacOS wilt, is het ook beter om geen macbook te kopen. Ik snap dat je de laptop mooi vindt en dat een krachtige arm chip interessant is, maar het werkt alleen zo goed vanwege mac os.

Je kan wel zeggen "ik wil er linux op draaien" maar ook als deze speciale apple M distro ooit daily driver ready wordt, is alle software die je zou willen draaien die om wat meer performance vraagt nul komma nul geoptimaliseerd voor de apple m2 chip.

Koop gewoon een linux laptop, thinkpad, pinebook of starlabs machine

[Reactie gewijzigd door youridv1 op 23 juli 2024 04:47]

[Marve79]

Mwah als je bijv Gentoo zou kunnen installeren en die M2 ondersteuning biedt zou je alles kunnen optimizen. Als Apple tenminste de specs vrij zou geven.

[youridv1]

Daily driver en Gentoo in dezelfde zin zeggen vind ik nogal wat. Dat is echt mega onproductief en bovendien haal je jezelf dan een hoop ellende op de hals voor eigenlijk niets. Ja dan kun je een macbook draaien zonder macOS, vet cool (meen ik), maar is dat experiment je 1000+ euro waard?

Of ga je de laptop daadwerkelijk voor nuttige dingen willen gebruiken en neem je dus een tried and tested hardware configuratie met een "normale" distributie?

Ik snap dat tinkeren linux eigen is en dat we allemaal graag rare configuraties uittesten om te kijken wat bij ons past, maar een peperdure macbook kopen en de apple tax betalen om vervolgens geen speciaal voor die hardware ontworpen OS te draaien??

[Reactie gewijzigd door youridv1 op 23 juli 2024 04:47]

[PureTryOut]

Je klinkt alsof je nog nooit daadwerkelijk Gentoo als daily driver hebt gebruikt. Dat is namelijk prima te doen, je configureerd je systeem gewoon zodat het compilen niet alle resources van je computer opneemt en dan doe je dat op de achtergrond terwijl je andere dingen doet.
Natuurlijk zal het nooit zoals een binary distributie zijn, maar dat het hele systeem "mega onproductief" zou zijn is echt onzin. Het is gewoon niet voor iedereen, en dat is prima.

[youridv1]

Je klinkt alsof je nog nooit daadwerkelijk Gentoo als daily driver hebt gebruikt. Dat is namelijk prima te doen, je configureerd je systeem gewoon zodat het compilen niet alle resources van je computer opneemt en dan doe je dat op de achtergrond terwijl je andere dingen doet.

En toch heb ik dat wel een kans gegeven, ondanks je aanname. Voor die configuratie moet je wel een echte hobbyist zijn. Niet omdat het moeilijk is, gewoon de wiki lezen, maar omdat het relatief veel tijd kost voor eigenlijk nul benefit

Zeker niet iets om 1000 euro voor een mooie macbook aan uit te geven. De binaries die je van apple krijgt zijn al speciaal voor jouw processor gecompileerd, ze hebben immers maar 2 M chips momenteel.

[Reactie gewijzigd door youridv1 op 23 juli 2024 04:47]

[PureTryOut]

Natuurlijk is Gentoo als daily driver een hobby project. De performance verbeteringen die je er van krijgt ten opzichte van een binary distributie is marginaal tot het punt dat je het eigenlijk niet merkt.
Maar maakt het uit? Als iemand, als hobby, Gentoo op een Macbook wil draaien zie ik niet in waarom dat niet zou kunnen. Ik zou het niet doen, er is betere hardware voor dat bedrag te krijgen, maar ieder zijn ding.

[youridv1]

Ja nee dan zitten we op dezelfde golflengte, maar ik snap absoluut niet waarom apple ook maar een euro zou besteden om dit te supporten. Ze zijn niet van de hobby. Hun hele business model is gericht op "normale mensen" die iets meer geld budgetteren voor een soepelere ervaring dan windows

[Reactie gewijzigd door youridv1 op 23 juli 2024 04:47]

[PureTryOut]

Volgens mij besteden ze er ook geen enkele euro aan, Asahi Linux is puur vrijwilligers. Het enige wat Apple gedaan heeft om het te "ondersteunen" is de bootloader niet locken 😉

[youridv1]

Dat... was al duidelijk toch?

[Bulkzooi]

Om Gentoo (en ook KDE) nou als hobby project te kwalificeren is wel overdreven denigrerende kwalificatie van de 2 meest iconische GUI front-ends uit de historie van GNU/Linux & FOSS computing. Nu de 4th Wave Linux Desktop nu eindelijk een succes lijkt te worden en het ene na het andere Linux software-pakket een update krijgt naar deze nieuwe GNU GUI realiteit.

Bovendien, het vermindert je afhankelijkheid van Apple terwijl M2 wel een state-of-the-art chip is. Het blijft altijd een overweging, en RPM support kan daarbij een argument zijn.

Overigens, die config is vaak niet meer dan éénmalig instellen van een one-liner in een verder vrij statisch geheel. Serieus, eye-candy is echt niet alleen maar weggelegd voor een Aero Interface met een Ribbon-style header. Ook het Spartaanse onderhoud, toegekend aan de Linux desktop, is als tegen-argument achterhaald.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[PureTryOut]

KDE heb ik nooit een hobby project genoemd en zal ik ook zeker nooit doen. Ik ben officieel een KDE developer (vooral actief binnen Plasma Mobile en Plasma Bigscreen) en gebruik het al jaren als mijn desktop naar keuze.

Maar wat is er mis met een hobby project zijn? Dat is niet denigrerend bedoeld, hobby projecten zijn prima en kunnen immens groot en gecompliceerd zijn. Natuurlijk zullen er ook veel mensen zijn die serieuse use-cases hebben voor Gentoo, maar ik denk niet dat de meeste mensen die het gebruiken dat hebben. Dat is natuurlijk een aanname, zeker waar. Het was de jaren dat ik Gentoo draaide bij mij zeker een hobby project in ieder geval.

[thomas_n]

Als Apple de specs en drivers open zou maken, is er geen reden waarom Linux minder goed op een Macbook zou moeten draaien dan op een standaard Intel/AMD laptop. Die worden ook in de eerste plaats voor een ander OS (WIndows) ontwikkeld, maar Linux werkt er zonder problemen op.

Misschien is het inderdaad vooral software optimalisatie die M* Macbooks snel en zuinig maakt t.ov. de concurrentie, maar alleen met software-optimalisatie kom je er niet. De chips moeten ook daadwerkelijk behoorlijk snel en zuinig zijn. Ik zou wel benieuwd zijn hoe goed die onder Linux presteren, wanneer Apple wel meewerkt.

[youridv1]

Die worden ook in de eerste plaats voor een ander OS (WIndows) ontwikkeld, maar Linux werkt er zonder problemen op.

Uhhhhh. Power management op laptops op linux is zeer matig, zeker als je een nvidia videokaart hebt. Het werkt en alles doet het, in de meeste gevallen, maar of het probleemloos werkt? not really. Het werkt al zeker niet gegarandeerd probleemloos

[Reactie gewijzigd door youridv1 op 23 juli 2024 04:47]

[thomas_n]

Haha ja ok niets werkt zonder problemen natuurlijk (ook Windows en MacOS niet, trouwens ). Maar er is geen reden waarom dat op Apple hardware meer problemen zou moeten opleveren dan op andere laptops, als Apple net zo zou meewerken als andere hardware fabrikanten.

[Guus...]

De reviews die ik heb gezien van Linux op M1 onderschrijven niet wat je stelt. Batterijduur is lang, iets korter dan op MacOS maar niet extreem zoals je soms op Linux kan hebben. Ik zou er graag een willen hebben omdat er nog geen enkele laptopmaker een degelijke passief gekoelde laptop heeft gemaakt.

Maar zoals je zegt kan je er beter geen kopen. Apple werkt er niet aan mee dus er is een grote kans dat het altijd een manke optie blijft.

[wica]

Mijn grootste reden om voor een MacBook te gaan, is de kwaliteit en de lange accu duur.

Verder is OSX wel een stuk fijner werken dan windows, als je veel met Linux doet. Maar zodra de GPU goed ondersteund wordt, gaat hier gewoon linux op.

[youridv1]

Een groot deel van die lange accuduur is echt het OS dat zijn resources goed managet ben ik bang.

GPU ondersteuning... goeie. Ik zou even kijken hoe het met de open source nvidia drivers gaat voordat je al te warm loopt.

[TheVivaldi]

Een groot deel van die lange accuduur is echt het OS dat zijn resources goed managet ben ik bang.

Waarom zeggen reviewers van Asahi Linux op de M1 dan dat de accuduur op Asahi bijna net zo lang is? Allemaal slecht getest, zeker?

[youridv1]

accuduur tests zijn wel van nature flawed ja. Vaak gaan ze een of een handje vol programma’s draaien en dan kijken hoe lang de accu mee gaat tijdens die specifieke load. Met het snoozen van processen en dergelijke worden vaak geen objectieve tests gedaan

[TheVivaldi]

Dat waren geen accuduurtests, maar reviews van dagelijks gebruik.

[youridv1]

Ah, dus dat zijn geen objectieve tests, maar een inschatting van de gebruiker. Normaal gebruik, waardoor je foutmarge groter is dan hetgeen wat je probeert te meten omdat normaal gebruik nu eenmaal wisselvallig is.

De gebruiker waarvan bekend is dat hij 100% objectief kan zijn over het product. Die een reputatie heeft dat hij 100% eerlijk, betrouwbaar en reproduceerbaar test.

Als de test namelijk maar aan 1 van die 3 criteria niet voldoet, kun je er feitelijk helemaal niets op baseren. Die moet je alle drie hard kunnen maken. Is dat zo bij die reviews van je?

[Reactie gewijzigd door youridv1 op 23 juli 2024 04:47]

[bliss1]

Da's onzin natuurlijk. Apple's AS computers zijn geweldig. De meest efficiënte processors, geweldig keyboard/trackpad/scherm,stil. En linux draait goed op ARM. Probleem is dat er geen OS drivers zijn voor de graphics chip, thunderbolt, etc. Asahi moet dat zelf reverse engineeren.

[Xander2]

Je kan wel zeggen "ik wil er linux op draaien" maar ook als deze speciale apple M distro ooit daily driver ready wordt, is alle software die je zou willen draaien die om wat meer performance vraagt nul komma nul geoptimaliseerd voor de apple m2 chip.

Nou nou, dat valt wel mee, meeste optimalisatie zit in de kernel anders zaten we massaal in ASM/C te programmeren, had elke distro een cpu specifieke versie en was de switch van Apple naar ARM niet zo soepel verlopen.

Mee eens dat op dit moment niet praktisch is om een M2 voor linux aan te schaffen tenzij je mee wilt werken aan de Linux port.

[TheVivaldi]

Ja, optimaliseren voor een bepaalde cpu deed men in de vorige eeuw, maar daar moest en zou van worden afgestapt omdat dat niet handig was. Ik kan me dus niet voorstellen dat Apple ineens een stap terug in de tijd gedaan heeft. De meeste optimalisatie zal dus, zoals je zegt, in de kernel zitten.

[i-chat]

Koop gewoon een linux laptop, thinkpad, pinebook of starlabs machine -

gewoon even ter indicatie, hoeveel highend ARM based laptops ken jij met

> Met degelijke specs.
- een higend 8core ARM v8 v9? ontwerp,
- 8gb ram en 256 gb opslag,
- een redelijke IGP
>> OF op zijn minst iets van AMD (of intel) et vergelijkbare performance en TDP (een paar watt).

> met een Highend LCD of miniled scherm van >1440p en 500cdm2

in de prijsklasse 1000 <--> 2500 euro,

Ik geef toe dat zelfs met officiele documentatie het wel even duurt voordat we ubuntu stabiel en snel draaiend gaan zien om de m1 macs. maar er zijn op dit moment 0 laptops even snel / zuinig en goed in dat prijssegment. de beste en goedkoopste laptops die er in de buurt komen zijn de MSI creator en de asus zenbook pro X - maar die HALEN! het niet bij de zuinigheid van een macbook AIR.

bovendien is er nog zoiets als een - NA apple update periode. Apple biedt namelijk ongeveer 8 jaar software support op zijn laptops na aankoop daarna houdende updates en beveiligings patches op. wil je je laptop waar je zo extreem zuinig mee was langer gebruiken zou je kunnen uitwijken naar een ander OS ... mits het tegen die tijd goed werkend gekregen is.

ubuntu op mijn daily driver is zeker niet iets dat ik direct zou verwerpen, al hoop ik dat MS en ADOBE eindelijk eens met snap-packages van hun pakketten komen met iets van proton ofzo...

[youridv1]

gewoon even ter indicatie, hoeveel highend ARM based laptops ken jij met

Retorische vraag, want het antwoord is natuurlijk nul. Op dit moment een high end ARM laptop willen is geen optie, die zijn er niet. Dat betekent niet dat je een macbook met closed source hardware moet willen draaien van een fabrikant die niet mee wil werken aan alternatieve OS'en.

Als je je zo druk maakt om de update periode van 8 jaar, is een apple device niet voor jou. Zo simpel is het. Alternatieve routes gaan zoeken voor je oude device is een hobby iets. Niet iets om je aankoop op te baseren. Je moet er bij het uitgeven van geld altijd zo pessimistisch mogelijk in staan, dan bespaar je nog eens wat. Na de support periode voorbij is, werkt er niets meer tot het tegendeel bewezen is. Dat je daarna een oplossing vindt die redelijk werkt, is hartstikke leuk, maar je moet geen devices kopen in de hoop dat dit later kan. Zeker geen relatief jonge concepten zoals een ARM based macbook.

x86 kan de performance per watt nier bijhouden nee. De R7 6800U en i7 1260P zijn volgensmij de CPU's die nog enigzins vergelijkbare getallen kunnen produceren.

Dat er geen betere opties zijn, wil niet zeggen dat de M chip macbooks een viable optie zijn. Ik bedoel dan ook, koop het beste alternatief voor jou dat wel bestaat en ga niet zeuren dat ze niet zo goed zijn als een niet bestaand, hypothetisch concept

[asing]

Iedere fabrikant van hard en software wil je in hun eco systeem hebben. Denk aan Google met de Pixel telefoons met Android, Microsoft met hun Surface spullen en Windows.

En iedere keer heb je van die enthousiastelingen die gaan proberen om er iets anders op te installeren. Veelal Linux. En ja, de M2 is een ARM gebaseerde chip en Linux kent ARM versies. Maar daarmee is eigenlijk alles gezegd. De rest is proberen en nog eens proberen.

[SirLenncelot]

Dit heeft volgens mij heel weinig met hun businessmodel te maken, de groep die Linux zou willen draaien op een MacBook zal voor hun echt te verwaarlozen zijn. Bovendien denk ik niet dat die groep zich nu wel in hun ecosysteem onderdompelt.

Het zal deels security zijn en deels gewoon resources die ze niet vrij willen maken. Documentatie onderhouden, support leveren, issues oplossen kost uiteindelijk allemaal geld. En allemaal investering waar je weinig aan verdient.

[hooibergje]

Denk dat dat wel meevalt. Apple draait op mafketels die meer dan duizend euro aan een mobieltje uitgeven.
Een paar Linux enthousiastelingen maken geen verschil.

[i-chat]

en samsung tegenwordig ook, en zelfs One+ moet eraan geloven, if anything is apple mede door zijn iphone SE juist goedkoper geworden de laatste jaren. de SE is ongeveer even duur als een highend Samsung A (midrange) telefoon.

[PrimusIP]

Het is de hele Apple bedrijfsfilosofie waar ze een product op de markt brengen waarop de hardware en software met elkaar geïntegreerd zijn. Andersom is MacOS niet gemaakt om op een niet-mac pc te zetten. Het sterke ervan is dat het ook enorm op elkaar geoptimaliseerd is. Ik denk dat zelfs als Apple zou stoppen het tegen te werken, het erg moeilijk wordt om die optimalisatie te evenaren.
Het is ook een sterk sellingpoint waarom mensen een Mac kopen.

[ikweethetbeter]

Wel jammer. Denk dat Apple zichzelf hiermee wel benadeelt.

Ik denk het niet. Apple maakt Apple hardware en Apple besturingssystemen. De meeste Apple gebruikers kunnen daarmee leven.

Ik wil best een laptop met M2 cpu maar ik wil geen MacOS. Als Linux volledig supported zou zijn zou dat zeker interessant zijn.

Voor Intel Macs is er BootCamp. Misschien komt dat ook voor Mx Macs als MS een volwassen versie van Windows voor ARM heeft. Support op Linux hoef je nooit te verwachten, anders dan mogelijk een set drivers voor de hardware in de toekomst. Al denk ik dat dat beperkt blijft tot Windows.

Dit soort hobbyprojects zijn leuk hoor maar totaal niet geschikt als daily driver. En niets staat Apple in de weg de boel te frustreren of zelfs te blokkeren.

Een OS op Apple hardware moet op de juiste manier gesigned zijn. Ik denk dat, totdat er bv BootCamp is, je alleen virtueel andere OS-en kunt draaien.

Maarja Apple wil je natuurlijk volledig in hun ecosysteem hebben en niet alleen éénmalig een laptop aan je verkopen en vervolgens niets meer aan je verdienen. Dat is heel hun business model.

Niets weerhoudt je om eenmalig een Mac te kopen, alleen maar gratis software of software van derden te gebruiken, en tot het einde der tijden gratis 5GB iCloud opslag te gebruiken. Met andere woorden: jouw statement is onzin.

Maar natuurlijk wil Apple tevreden gebruikers, die vaker hard- en software kopen. MS wil ook meer verkopen, en Google werkt ook niet voor het goede doel. Wat is eigenlijk jouw punt?

[Coolstart]

Nul support?

https://www.techradar.com...ful-trick-for-linux-users

Apple geeft Linux VM’s toegang tot Rosetta 2. Zodat een ARM linux VM ook x86 apps kan draaien.

Het klopt wel dat Apple Linux niet native ondersteund zoals ze dat met Windows wel deden. Geen idee waarom niet. Mogelijk een te kleine markt.

Btw, het feit dat W11 ARM niet draait op een mac heeft te maken met restricties van Microsoft. Op X86 had Apple bootcamp ontwikkeld zodat je Windows kon draaien met Support van Apple zelf. Spijtig genoeg is dat nu niet meer het geval. Dat kan enkel nog via een VM.

[Reactie gewijzigd door Coolstart op 23 juli 2024 04:47]

[youridv1]

Ik zie niet in hoe het aanbieden van een VM die x86 support heeft ook maar iets te maken heeft met het ontwikkelen van een eigen os voor apple silicon. Tenzij jouw definitie van een OS is dat je een verkapte virtual machine met rosetta 2 draait als daily driver...

[thomas_n]

Daar hebben ze in dit geval weinig aan, omdat dit juist geen VM is, maar direct op de hardware moet draaien.

Ik ben het wel met je eens dat nul support iets te kort door de bocht is. Apple heeft wel met opzet de bootloader open gelaten, zodat het in elk geval niet nodig is iets als een jailbreak of zo uit te voeren.

Dat is natuurlijk nog steeds heel weinig support in vergelijking met wat chipmakers als Intel en AMD (of de meeste ARM-chipmakers) doen om Linux te ondersteunen.

[kabelmannetje]

> Nul support?

Ja, Apple ondersteunt niet de ontwikkelaars in het porten van Linux naar M1/M2 architectuur.

[Iblies]

Heel veel ARM soc’s zijn eigen browsels 🙂

Het grote verschil is dat bij andere producenten ze de basis blueprint van ARM gebruiken en dat de producent ook nog eens in grote lijnen de bijbehorende drivers gebruikt.


Apple gebruikt al heel lang afwijkende instructie-sets, drivers zijn in-house ontwikkeld,

en onder het motto veiligheid mag je er niet aankomen en dat wordt bewust “beveiligd”. En dat doet Apple zo goed dat dergelijke groepen constant achter de feiten aanlopen. De wijzigen per apple-soc zijn dusdanig voldoende dat je niet zomaar even kunt porten.

[kabelmannetje]

Omdat deze chipset plus omringende protocollen, een zo goed als black box zijn voor de developers.

[mekkieboek]

Als je (heel) veel geduld hebt en een beetje kunt meelezen met C code en met Pythoncode (voor de hacktools) hebt, kun je meekijken tijdens hacksessies aan Asahi Linux. Ontwikkelaar Hector Martin heeft een youtubekanaal (marcan) met live coverage: https://www.youtube.com/c/marcan42/videos

Er is ook een 'zuster' kanaal (Asahi Lina) waarin aan de GPU driver wordt gewerkt. Maar daar moet je nog veeeel meer geduld voor hebben vanwege het onconventionele format van dat kanaal (je bent gewaarschuwd ): https://www.youtube.com/c/AsahiLina/videos

[CasperArkema]

Als ik een keer een dagje aan tijd over heb..
Nee, dank- ik zal proberen in snippers een beetje mee te kijken met hoe ze dit doen, in het ergste geval leer ik er iets van

[sspiff]

Ik vraag me af of Lina Asahi een alter ego is van Alyssa Rosenzweig (de lead developer van een aantal Linux graphics drivers, onder meer die voor de Apple M1).

Lina is duidelijk een pseudoniem, en lijkt vooral reverse engineering voor haar rekening te nemen, iets wat typisch voor juridische redenen onafhankelijk moet gebeuren van de ontwikkeling van alternatieve implementaties van drivers of libriaries.

https://mobile.twitter.co...tatus/1536163679464464384
https://gitlab.freedeskto...sa/-/merge_requests/15940

[i-chat]

even duidelijkheid scheppen voordat mensen hier vreemde dingen van gaan denken! F

Het gaat er hierbij om dat je
A: geen broncode van anderen mag jatten,
- op het moment dat je echter systemen gaat hacken om erachter te komen hoe dingen werken kom je onvermeidelijk in aanraking met stukken gedecompileerde-broncode en de technieken die worden gebruikt om uiteindelijk iets met die hardware gedaan te krijgen.

Omdat het voor mensen onmogelijk is om dingen NIET te doen. (denk niet aan een gele aap met een banaan in z'n bips), kun je van zo'n hacker niet verwachten dat hij niet onbewust alsnog stukjes code die hij heeft gezien op dezelfde manier implementeert en daarmee dus copyrights en patenten kan schenden.

Om dit tegen te gaan worden er doorgaans 2 groepen samen gesteld.
1: de groep ik uitzoek hoe het werkt en dit in een boekwerk documenteert.
2: de groep die aan de hand van dit boek een implementatie bouwt die compatible zou moeten zijn met de hardware.

zo voorkom je dat mensen per ongeluk code implementeren die ze niet mogen gebruiken.

[Bulkzooi]

..
Het gaat er hierbij om dat je
A: geen broncode van anderen mag jatten,
..
Om dit tegen te gaan worden er doorgaans 2 groepen samen gesteld.
1: de groep ik uitzoek hoe het werkt en dit in een boekwerk documenteert.
2: de groep die aan de hand van dit boek een implementatie bouwt die compatible zou moeten zijn met de hardware.

zo voorkom je dat mensen per ongeluk code implementeren die ze niet mogen gebruiken.

In Frankrijk wordt reverse-engineering beschouwd als een zaak van Nationale Veiligheid. Dus er zal wel een Update policy uitgerold worden op Quatorze Julliet

In dat daglicht is de C compiler van Fabrice Bellard ook interessant. Heb je trouwens enig idee hoe stringent requirements en conformance suites van Microsoft en Apple voor hun compliance certificaat voor toelating tot hun Appstores zijn? Die lopen mijlenver voor op de overheid.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[mekkieboek]

Lina Asahi is een alter ego van Hector Marcan zelf. Het is een deep-fake-ish prank zeg maar. De stem klinkt anders maar dat gebeurt via een of andere deep-fake audiotool. Het kan niet missen, 'ze' gebruikt precies dezelfde stopwoordjes, in precies hetzelfde tempo en met precies dezelfde stemvariatie. En de animatie wordt live gegenereerd met eye-tracking om het een beetje echt te houden.

Over het waarom, geen idee. Omdat het kan, misschien?
Ik zal het in ieder geval niet volgen want de achtergrondtune is een vage non-stop loop van C64 videogame muziek en daar word je na een kwartier al redelijk simpel van, laat staan na 5 uur

[sspiff]

Ik kom gewoon horendol van het stemmetje. Ik zou anders met plezier zo'n stream volgen, hoewel ik daar momenteel geen tijd voor heb.

Het onderwerp uit perfect aan met mijn interesses.

[johnbetonschaar]

Over het waarom, geen idee. Omdat het kan, misschien

Asahi Lina is begonnen als een 1 april grap. Omdat er zo veel mensen op positief op reageerden en de Twitter en het YT kanaal begonnen te volgen is de bedenker (idd volgens mij Hector Marcan, hoewel die net doet alsof hij het niet is) er mee door gegaan.

[Bulkzooi]

Als je (heel) veel geduld hebt en een beetje kunt meelezen met C code en met Pythoncode (voor de hacktools) hebt, kun je meekijken tijdens hacksessies aan Asahi Linux. Ontwikkelaar Hector Martin heeft een youtubekanaal (marcan) met live coverage: https://www.youtube.com/c/marcan42/videos

Er is ook een 'zuster' kanaal (Asahi Lina) waarin aan de GPU driver wordt gewerkt. Maar daar moet je nog veeeel meer geduld voor hebben vanwege het onconventionele format van dat kanaal (je bent gewaarschuwd ): https://www.youtube.com/c/AsahiLina/videos

Lina is duidelijk een pseudoniem, en lijkt vooral reverse engineering voor haar rekening te nemen, iets wat typisch voor juridische redenen onafhankelijk moet gebeuren van de ontwikkeling van alternatieve implementaties van drivers of libriaries.
Ik vraag me af of Lina Asahi een alter ego is van Alyssa Rosenzweig (de lead developer van een aantal Linux graphics drivers, onder meer die voor de Apple M1).

https://mobile.twitter.co...tatus/1536163679464464384
https://gitlab.freedeskto...sa/-/merge_requests/15940

Asahi Lina is begonnen als een 1 april grap. Omdat er zo veel mensen op positief op reageerden en de Twitter en het YT kanaal begonnen te volgen is de bedenker (idd volgens mij Hector Marcan, hoewel die net doet alsof hij het niet is) er mee door gegaan.

Het pseudoniem Lina kan dus makkelijk, is zelfs aannemelijk, meerdere identiteiten hebben. Maar ik ga er vanuit dat deze devs veel zaken relatief bekijken.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 04:47]

[nklaver234]

Omdat het kan. Wat is het nut van allerlei truukjes die je op TikTok ziet. Is een mooie oefening en mogelijkheid voor ontwikkelaars om hun kunnen te tonen.

En voor als hardware niet meer ondersteund wordt door Apple en geen (beveiligings)updates meer krijgt toch een manier om langer (veilig) de hardware te blijven gebruiken. Echter zijn die M2's zo nieuw dat je je daar de komende 5 tot 7 jaar niet druk om hoeft te maken ;-).

[jj71]

Gek eigenlijk dat het verschil tussen de M1 en de M2 zo groot is dat het alsnog een hoop werk is om het werkend te krijgen op de M2 (terwijl ze het op de M1 al werkend hadden).

Je zou zeggen dat de M2 een verbeterde versie is van de M1, waarvoor grotendeels dezelfde drivers kunnen worden gebruikt, zeker voor eenvoudige randapparaten zoals het toetsenbord.

[johnbetonschaar]

De eerste bring-up van de M2 kostte nog geen 24 uur, dat vind ik nou niet erg lang. Een deel van die tijd zat hem ook niet eens in de hardware verschillen, maar in bugs in hun eigen boot loader, die op de M1 niet naar boven waren gekomen. Het grootste hardware verschil wat blijkbaar lastig was is dat de manier waarop het keyboard en de trackpad werken, daar heeft Apple wijzigingen in aangebracht, de trackpad gebruikt nu een SPI interface en een nieuwe extra controller met eigen firmware, en het toetsenbord interfaced nu blijkbaar via de trackpad. Dit was schijnbaar niet eenvoudig te reverse engineeren en is ook de reden dat het toetsenbord niet werkt voordat de Linux kernel is geladen (in de boot loader dus).

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 04:47]

[Bulkzooi]

De eerste bring-up van de M2 kostte nog geen 24 uur, dat vind ik nou niet erg lang. Een deel van die tijd zat hem ook niet eens in de hardware verschillen, maar in bugs in hun eigen boot loader, die op de M1 niet naar boven waren gekomen.

Het grootste hardware verschil wat blijkbaar lastig was is dat de manier waarop het keyboard en de trackpad werken, daar heeft Apple wijzigingen in aangebracht, de trackpad gebruikt nu een SPI interface en een nieuwe extra controller met eigen firmware, en het toetsenbord interfaced nu blijkbaar via de trackpad.

Dit was schijnbaar niet eenvoudig te reverse engineeren en is ook de reden dat het toetsenbord niet werkt voordat de Linux kernel is geladen (in de boot loader dus).

Ja, als je weet wat je doet gaat de eerste port vrij snel. Vanaf daar wordt het debuggen, met gdb bijvoorbeeld. Maar de Mac kernel kan pas vervangen worden als de boot loader bedient kan worden; vanaf deze M2 chip dus via de SPI interface, to utilize the user input. Maar de syscalls zijn niet echt verandert.

[Roel911]

Het is juist mooi dat je de keuze krijgt welk besturingssysteem je gaat gebruiken. Zoveel mensen, zoveel wensen.