Apple geeft broncode van kernel macOS en iOS vrij

Apple heeft van de op XNU gebaseerde kernel zijn broncode vrijgegeven. Die kernel gebruikt Apple onder andere voor macOS en iOS, en is nu beschikbaar onder een zogenaamde Apple Public Source License, waardoor er nog wel de nodige restricties gelden voor ontwikkelaars.

Een speciale webpagina bevat alle broncode die Apple online heeft gezet, en daar heeft het bedrijf nu ook de XNU-kernel, die onderdeel is van het Darwin-besturingssysteem, geplaatst. Overigens kunnen ontwikkelaars voor de broncode ook op Github terecht. Wie gebruik wil maken van de Apple-software in eigen projecten, moet er wel rekening mee houden dat de broncode is vrijgegeven onder een Apple Public Source License 2.0. Die legt ontwikkelaars een aantal restricties op, die onder meer op Github zijn na te lezen.

Apple gebruikt de XNU-kernel voor Darwin, het besturingssysteem dat de basis vormt voor onder meer het besturingssysteem macOS; dat geldt zowel voor de recente versies, als oudere versies van de software. Ook het mobiele besturingssysteem iOS is gebaseerd op de XNU-kernel, en het watchOS voor Apples slimme horloges maakt er ook gebruik van.

Het is niet de eerste keer dat Apple delen van zijn broncode openbaar maakt. Vorig jaar bracht het de Darwin-broncode voor macOS 10.12 uit, en een jaar eerder werden delen van de broncode van El Capitan uitgebracht, dat toen nog onder de OS X-naamgeving viel.

Reacties (124)

[ThomasG]

De broncode van XNU is al sinds jaar en dag opensource en te downloaden via de website van Apple. Het enige nieuwe hierin lijkt te zijn dat het nu ook op GitHub staat.

[seapip]

Daarnaast blijkt de ARM/iOS specifieke code nu dus ook opensource gemaakt te zijn

[Reactie gewijzigd door seapip op 30 juli 2024 00:00]

[DCK]

Jup. Dat is een groot ding. XNU en Darwin zijn al jaren open source: er zijn zelfs verschillende niet al te succesvolle projecten geweest om Darwin te draaien met een moderne Unix-desktop.

Maar dat is alleen de broncode voor de desktop (dus PowerPC en amd64). in de tien jaar dat de iPhone bestaat heeft Apple nooit de broncode van de software vrijgegeven die voor voor arm en aarch64 was geschreven.. Het vrijgeven van de broncode is namelijk een 'liefdadigheid' van Apple trouwens: zowel de licentie van de software (meeste is BSD/MIT/Apache, geen GPL) verplicht het vrijgeven niet, en ze zijn daarnaast voor de interessantste stukken van de source copyrighthouder. Ze kunnen dus doen wat ze willen, maar mooi dat ze het gewoon vrijgeven.

[bouwfraude]

Darwin is al jaren lang te downloaden van Apple. Veel had je er niet aan. Ik heb er ooit wel eens naar gekeken maar om het überhaupt draaiende te krijgen was er meer voor nodig.

[gbraad]

Het is wel degelijk bruikbaar. Meerdere, zelfs zonder de ARM code, hebben het draaiend gekregen op mobiele telefoons en andere hardware https://github.com/darwin-on-arm/xnu (zoals de N900). maar voor vele blijft het ook een novelty, net als de Symbian kernel die ooit Open Source werd (en weer verdween).

[Verwijderd]

Dat het op GitHub staat is niet eens nieuw. Ik checkte zojuist de git-configuratie van mijn xnu directory, en de remote daarvan is GitHub, en dat is al zeker twee jaar zo.

[Q-collective]

Valt APFS hiermee ook onder de Apple Public Source License? Dat zou namelijk niet zo interessant zijn voor de Linux community (zie de mening van de FSF erover). Ik had juist gehoopt dat APFS de nieuwe ExFAT zou worden: een écht universeel filesystem. Iets wat de ZFS ook al niet werd vanwege de CDDL (ook niet compatibel met de GPL).

[Reactie gewijzigd door Q-collective op 30 juli 2024 00:00]

[wootah]

Er is toch btrfs? Helemaal Linux compatible en er is zelfs een Windows driver in de maak

[TheMaurice]

Dat is vrij optimistisch.. er zijn enkele serieuze problemen met btrfs die je je data kunnen kosten. Voor zover ik weet kan het niet met RAID 5 of 6, maar wel met RAID 0 en 1 gebruikt worden.

[Jerie]

Dat is vrij optimistisch.. er zijn enkele serieuze problemen met btrfs die je je data kunnen kosten

Je zult altijd backups moeten maken. Snapshots zijn geen backups. Met ZFS, APFS, HFS+, NTFS, Ext4FS, hardware raid kun je ook silent corruptie hebben.

Voor zover ik weet kan het niet met RAID 5 of 6, maar wel met RAID 0 en 1 gebruikt worden.

Volgens de website:

Basic RAID: RAID0, RAID1, and RAID10
Advanced RAID: RAID5 and RAID6 (incompat flag raid56)

Btrfs wordt succesvol gebruikt in productie. Vooral in begin waren er nogal wat problemen, maar dat heeft elk filesystem. Het is alleen zo dat bijvoorbeeld APFS intern wordt ontwikkelt.

[Caelestis]

ZFS is juist zeer goed tegen dingen als bitrot dus wat je bedoelt met silent corruption is een beetje onduidelijk.

[Jerie]

Je zult regelmatig moeten scrubben, net zoals bij een hardware raid.

[Caelestis]

Ja het klopt zelfs met ZFS moet je gewoon standaard onderhoud uitvoeren net als je dat moet doen met BTRFS dus nog steeds is niet duidelijk wat je probeert te zeggen met silent corruption.

[Jerie]

Tja, zo heet het nou eenmaal als je data niet meer consistent is op 1 van je drives in een RAID (of RAIDZ of software RAID), het is niet mijn probleem dat je niet in een zoekmachine in kunt voeren: "btrfs silent corruption" of "zfs silent corruption" of "raid silent corruption".

Voorbeeld: http://changelog.complete...t-data-corruption-is-real

[Caelestis]

Ok dus jij denkt dat het problem met BTRFS wat maurice opnoemt niks anders is als silent corruption waar alle andere FS en raids last van hebben?
Dus je bent er niet mee bekend dat het raid5/6 parity data niet gechecksummed wordt met BTRFS waardoor het in bepaalde omstandigheden kan leiden tot een write hole en het hele systeem niet meer weet welke data goed is?

[Jerie]

Daar ben ik wel degelijk bekend mee: Jerie in 'nieuws: Apple geeft broncode van kernel macOS en iOS vrij'
wootah in 'nieuws: Apple geeft broncode van kernel macOS en iOS vrij'

Bovendien is het inmiddels opgelost: Superstoned in 'nieuws: Apple geeft broncode van kernel macOS en iOS vrij'

Wat ik zeg, is dat data corruptie zelfs bij Btrfs, ZFS, en hardware RAID op kunnen treden (en APFS kun je ook toevoegen aan het rijtje). Ongeacht of ze checksums op diverse niveaus gebruiken. Om dat tegen te gaan zul je al je data moeten scrubben (verifieren). Als je dat op zondag doet, en woensdag treed silent corruptie op, dan heb je nog steeds een probleem. RAID of snapshots zijn dan ook geen vervanging voor backups.

Read -> comprehend -> post.

[Caelestis]

Gelezen en ik kom tot de conclusie dat je werkelijk niks snapt van raids en filesytems.
Raid of snapshot zijn geen vervanging van backups dat klopt echter zitten backups meestal op een raid en het liefst met snapshots.
Het herhalen van een catch frase wat je ergens gelezen heb zonder te begrijpen waar het op doelt gaat echt werkelijk nergens over.
Hoe dat verder te maken heeft met parity checksums en write holes is mij echt een raadsel, dat catch frase doelt op het gebruik van meerdere opslag locaties en is niet iets wat je zegt om een fundamentele probleem van een FS te negeren.

En nee het BTRFS raid5/6 probleem is nog niet verholpen. Er zit duidelijke ontwikkeling in maar het probleem is nog steeds aanwezig.

[Jerie]

Backups zitten op een RAID? Backups bewaar je het liefst onsite en offsite. Onsite zodat je sneller aan de slag kunt, offsite ivm brand ed. Niet iedereen kan of doet dat, maar dat brengt de nodige risicos met zich mee. Backups bewaar je zeer zeker niet op hetzelfde systeem. Daar heb je niets aan bij bijvoorbeeld een hack.

De rest van je post zijn loze woorden en sneue beledigingen. Lees gewoon mijn posts terug, en leer begrijpend lezen.

[Caelestis]

Raids zij ontworpen in datacenters voor datacenters niet voor jouw pctje thuis of op het werk. Men heeft na 20 jaar ontwikkeling eindelijk op een betaalbare niveau enkele voordelen van datacenter opslag naar de eindgebruiker gebracht niet anders om.
De systeem beheerders en andere professionals die jouw als eind gebruiker proberen uit te leggen hoe "backups en raids" werken met leuzen als "Raids and Snapshots are not backups" gaan ervan uit dat je op zijn minst een beetje gevorderde kennis van zaken hebt om met je eigen hobby project aan de gang te gaan.
Het is overduidelijk dat jij behoorlijk wat gaten in je informatie hebt wat je veel terug ziet bij beginnende amateurs. Het geeft niet maar je doet er veel beter aan om je meer te verdiepen in het concept data opslag als je mee wil praten met mensen die er midden in zitten.
Ik dacht eerst dat ik inderdaad te intentie van je posts niet begreep vandaar dat ik opheldering vroeg. Helaas was het ter vergeefs en heb ik te maken met een egotje.

[Jerie]

Mijn posts over dit onderwerp zijn informatief en accuraat, net zoals die van wootah en Stuperstoned. Jouw posts voegen niets toe, en zijn zijn alleen maar persoonlijke aanvallen. Ik wens je veel sterkte om iets voor elkaar te krijgen mbh dergelijke communicatie.

[Caelestis]

Yup wootah en superstoned hebben er wat verstand van maar als zij jouw posts lezen schieten ze hoogst waarschijnlijk in de lach net als ik.
Maar even over dat communicatie probleem van je. Ik bleef nogal beschaafd totdat jij aan kwam met je zoekmachine belediging dus een beetje zelf reflectie is wel op zijn plaats.

[Jerie]

Spreek voor jezelf. Niemand neemt het hier voor je op hoor

Bitrot kun je ook gebruiken als term (er zijn er nog enkelen), maar is een ruimer begrip. Bij een verouderd OS met verouderde dotfiles/homedirs, out of date software, enz. spreekt met ook wel van bitrot.

Het doet er verder ook niet toe. 5 seconden met DDG of Google en je had het uitgevogeld. Blijkbaar vraag jij liever om er vervolgens een theater van te maken om de aandacht af te leiden van je eigen falen.

[Jerie]

5 seconden de tijd nemen om Wikipedia of Google (wat ik standaard en ook in dit geval niet gebruik, maar OK) te gebruiken is niet een "Google warrior". Dat is iemand die zelfredzaam is ipv de hele tijd afhankelijk aan anderen lopen vragen. Dat mij dat aan jou stoort, bleek al uit mijn eerste post, en dat was ook de reden waarom je zo boos werd. Lees het nog maar 'ns terug.

[Caelestis]

Jij maakt het aanname dat je überhaupt een idee had waar maurice het over had en begint dan onzin uit te kramen over backups.
Ik weet wat het probleem is wat maurice aankaart en kon daarom even geen verband leggen met jouw stelling over silent corruption dus was ik benieuwd wat je ermee bedoelde. Helaas is er geen enkel google zoekopdracht wat jouw stupiditeit kan toelichten dus dat vlieger gaat niet op.

Daarna ga je nog veel verder het mist in met een gedachten gang dat je of een raid heb of je heb een backup maar allebei tegelijk kan niet terwijl dat het standaard praktijk is in elke datacenter op aarde.
Als je 1 data opslag opstelling gebruikt dan is raid inderdaad niet een oplossing om geen backup te hebben, echter als jij onsite en offsite backups bewaart zitten die offsite backups ALTIJD op een raid en het is ook zeer verstandig om een onsite backup op een raid te plaatsen.
Boos ben ik niet maar wel wat geïrriteerd met jouw egotje. Al had je ook maar enig vorm van zelf respect dan had je misschien wat kunnen leren van je fouten ipv net doen alsof je ergens verstand van heb.

[Jerie]

Helaas is er geen enkel google zoekopdracht wat jouw stupiditeit kan toelichten dus dat vlieger gaat niet op.

https://www.google.nl/sea...ce=hp&q=silent+corruption

Waarom blijf je er nou omheen brabbelen in slecht Nederlands? Gewoon de volgende keer even een zoekmachine gebruiken als je het niet begrijpt.

[Caelestis]

Ooooh noes nu heb je het gedaan je beledigd mijn nederlands!!! zucht....
Wil je doen geloven dat je een IQ heb wat hoger is als 80 zal je toch echt beter je best moeten doen. Als je zo graag door will gaan prima. Leg ons allemaal uit wat silent corruption te maken heeft met het BTRFS writehole bug. Nu is je kans verknal het niet met randdebielen reacties.

[Superstoned]

Wat Jerie bedoelt is dat met een FS wat geen checksums heeft (zoals ZFS en ook BTRFS dat wel hebben) je dataverlies kan krijgen wat door de RAID code niet wordt opgemerkt of gefixed. Als je hardware raid gebruikt met zfs en btrfs zullen ze het wel opmerken maar pas als de data gelezen word en ze zullen het niet op kunnen lossen. Kun je beter de ingebouwde RAID gebruiken, die dat wel kan.

De problemen met BTRFS RAID 5/6 zijn trouwens sinds kernel 4.12 gefixed, al zou ik nog een paar versies wachten voordat ik het in zet...

[MaxxMark]

De raid implementaties van/voor btrfs zijn inderdaad flawed en kunnen je je data kosten. Onder andere Netgear gebruikt btrfs in zijn nas vanwege de robuustheid/snelheid er van. Ze gebruiken echter op een ander niveau een alternatieve - niet btrfs - (software)raid oplossing. Op die manier kan je dus zowel btrfs als raid 5/6 functionaliteit gebruiken en niet de overige issues.

[sam_vde]

Helaas verlies je hiermee alle voordelen van btrfs wat het beschermen van data betreft.

Je hebt gewoon een klassieke RAID met alle nadelen die zfs en btrfs willen oplossen.

Anderzijds kan je wel btrfs dataset beheer en snapshots e.d. gebruiken. Dan zou ik persoonlijk toch lvm verkiezen.

[MaxxMark]

Dat is precies wat Netgear op zn nas-en doet. LVM voor z'n volumes en btrfs als filesystem

[wootah]

Mwa, valt allemaal wel mee, het enige wat je niet moet gebruiken is raid56 inderdaad, de rest is wel stable met uitzondering van een paar speciale gevallen
Sowieso, als je iets zoekt over btrfs zie je snel negatieve dingen, die ondertussen al zijn opgelost, de ontwikkeling gaat snel.

[UPPERKEES]

btrfs is nog niet klaar, ik ben ook benieuwd of dat ooit het geval zal worden. Red Hat heeft zich teruggetrokken uit de ontwikkeling, alleen SUSE trekt de kar nog volgens mij. De performance is ook nog steeds niet beter dan EXT4.

[wootah]

Suse is de grootste, klopt.
Verder is het grootste gedeelte van btrfs gewoon stabiel, alleen raid5 en raid6 zijn niet goed geïmplementeerd maar daar werken ze nog aan.
Desalniettemin ga ik niet meer terug naar wat anders dan btrfs
Performance is ook gewoon goed, alleen bepaalde usecases zoals virtual machine images en databases werken (nog) niet goed met COW.

[Superstoned]

Met het fixen van RAID 5/6 zijn ze nu onderhand wel klaar, zie https://btrfs.wiki.kernel.org/index.php/Changelog al zou ik persoonlijk nog 1 of 2 releases wachten voor ik het gebruikte. Ik zit nu op 4.13 en ik wacht tot 4.15, dan ga ik het aanzetten op mijn server. Met een backup ;-)

[johnkeates]

Je kan altijd nog vooruit gaan naar ZFS.

[Jerie]

RedHat heeft nooit veel bijgedragen aan de ontwikkeling van Btrfs. Suse doet tegenwoordig meer dan RedHat qua Linux ontwikkeling.

[UPPERKEES]

Dat klopt niet Red Hat is veruit de grootste. btrfs is nog altijd een technology preview met dikke letters dat je het beter niet voor productie kan gebruiken. Als de ontwikkelaars niet zeker zijn van hun product dan ben ik dat ook niet

[Jerie]

Ik zag laatst een bron die heel iets anders voorstelde, en die was uit 2017, maar ik geloof dat dat niet enkel kernel was maar FOSS in het algemeen. Het is ook maar net hoe je telt.

Hoezo zijn de ontwikkelaars niet zeker van hun product?

Je kunt het prima in productie gebruiken. Het is maar net waar voor je het inzet.

[Reactie gewijzigd door Jerie op 30 juli 2024 00:00]

[UPPERKEES]

Je kan pas een berekening maken van 2017 als het jaar afgelopen is Als je de bron kan vinden ben ik hier erg benieuwd naar

[Jerie]

Gevonden: https://www.suse.com/communities/blog/butter-bei-die-fische/ de bron is dus Suse zelf.

Was gepost in dit HN draadje WinBtrfs – A Windows driver for the next-generation Linux filesystem Btrfs

[UPPERKEES]

> Suse doet tegenwoordig meer dan RedHat qua Linux ontwikkeling.
Daarom zei ik dat je ongelijk had en een link gaf dat Red Hat de grootste is van de distro's wat betreft Linux ontwikkeling. Je geeft nu een link van de ontwikkeling bijdrage in de zin van slechts btrfs. Daar hadden we het niet over

PS: #1 contributor moet je ook wel met een vleugje zout nemen, hun eigen grafiek laat zien dat Oracle het meeste heeft bijgedragen.

[Reactie gewijzigd door UPPERKEES op 30 juli 2024 00:00]

[veltnet]

PS: #1 contributor moet je ook wel met een vleugje zout nemen, hun eigen grafiek laat zien dat Oracle het meeste heeft bijgedragen.

Niet Oracle, maar de bedrijven die Oracle heeft overgenomen voordat ze door Oracle zijn overgenomen
(o.a. Sun, MySQL,...)

[Jerie]

Je hebt gelijk, ik heb het in die quote slecht verwoord, en ik wist me ook niet meer te herinneren waar de statistiek precies over ging. Dat had ik beter kunnen doen, en is bovendien ook niet netjes van mij.

Waar ik echter op reageerde was jouw quote:

Red Hat heeft zich teruggetrokken uit de ontwikkeling, alleen SUSE trekt de kar nog volgens mij.

Dat is nogal relatief. SUSE trok al jaren de kar, en trekt die nog steeds.

Stel ik heb iets, en definieer het ook als iets. Ik haal vervolgens het iets weg. Vervolgens heb ik niets. Dat klinkt dan indrukwekkend. Het iets is weg! Maar als ik vervolgens laat zien dat het iets slechts 0,0001 was dan weet jij dat het nooit veel voorstelde. Da's een heel ander perspectief.

Qua contributor zal het mij wordt wezen wie dat was in 2010. Dat waren andere tijden. Vergeet niet dat Oracle zoals veltnet ook al schreef allerlei bedrijven heeft overgenomen. Oracle is een kutbedrijf. Als je psychopaat wilt definieren in het bedrijfsleven, kijk dan naar Oracle.

[Superstoned]

BTRFS wordt al jaren door tienduizenden SUSE klanten gebruikt, het is geen probleem zolang je hun versie gebruikt: alles wat nog niet stabiel wordt geacht is uitgeschakeld. Zoals RAID 5/6 ;-)

[RoestVrijStaal]

BTRFS is weer GPL gelicenseerd, wat het oninteressant maakt als daily driver voor Windows en MacOSX.

[Jerie]

BTRFS is weer GPL gelicenseerd, wat het oninteressant maakt als daily driver voor Windows en MacOSX.

Eh, nee? Fuse, Dokan, etc.

[johnkeates]

Right, want Fuse en Dokan zijn zo stabiel en snel, en je kan er zo lekker vanaf opstarten.

[Verwijderd]

Is dat niet dat file system dat niet goed werkt met Docker? Mounten gaat dan enorm traag. Want dan mag het van mij op MacOs blijven.

[MiesvanderLippe]

Nog niet. Voor de rest is het echt een enorm netjes filesystem en zou de wereld er goed aan doen er meer gebruik van te maken.

[PPie]

Is dat niet dat file system dat niet goed werkt met Docker? Mounten gaat dan enorm traag. Want dan mag het van mij op MacOs blijven.

Ben je er zeker van dat het geen Docker probleem is?

[Verwijderd]

Jazeker hoor, zoek maar eens op slow Docker mounts Apple.

[PPie]

Gedaan:
Op https://superuser.com/que...mance-in-docker-container staat deze post:

The issue is vboxsf, not docker. Spent days playing with this. vboxsf is incredibly incredibly slow. NFS is faster, depends what you're wanting to do though.

Dus wellicht toch niet macOS?

[Verwijderd]

Nee dit is niet wat ik bedoelde het ging volgens mij echt om APFS. Zal straks eens zoeken.

[DCK]

Jammer voor de Linux community ja. De situatie is hetzelfde als met ZFS - een nieuw geavanceerd bestandsysteem dat in de praktijk open source is, maar niet open source op de juiste manier om in de Linux-kernel te worden opgenomen. Zucht.

Maar aangezien APFS wel compatible is met de licentie van de FreeBSD-kernel, zou APFS wel onderdeel kunnen worden van FreeBSD (en daarvan afgeleide NAS-distributies als FreeNAS). Dat is nu ook de reden dat FreeBSD nog steeds meer dan relevant is voor file storage oplossingen: een solide platform waarmee je heel eenvoudig ZFS kunt gebruiken.

Overigens is het zo dat ZFS inmiddels ook prima bruikbaar is op Linux. Dat komt omdat er een weg omheen is. Vanwege niet met elkaar werkende vrije softwarelicensies kun je geen Linux kernels distribueren waar ZFS (of APFS) is ingebakken, maar een eindgebruiker kan zelf wel op zijn eigen machine ZFS (of APFS) kernelmodules compileren en die gebruiken. En dus zie je nu dat ZFS op Linux goed bruikbaar is (het zit bijvoorbeeld standaard in Ubuntu nu), en dat zal als er een Linux-port van APFS komt ook dezelfde kant op gaan.

[sam_vde]

Helaas ja. Technologie zoals dkms heeft de technische beslommeringen al lang opgelost. Er komen wel meer drivers niet mee met de kernel. En eigenlijk heeft nog nooit een rechter zich over de compatibiliteit van de licenties uitgesproken (mijn aanvoelen is dat organisaties als de FSF dit ook vermijden).

[Superstoned]

Ja, ze vermijden het een beetje omdat de rechter wel eens iets lelijks zou kunnen besluiten. Persoonlijk zou ik het liever maar eens aangaan maar goed.

[Maurits van Baerle]

Open Source of niet, veel belangrijker is de vraag of Apple er een Open Standard van maakt.

Tenzij er bepaalde patenten zijn die niet in Apples bezit zijn (zoals destijds met iMessage) is het zeker denkbaar dat Apple het een Open Standard maakt. Het zit in ieder geval in de planning om de specificatie openbaar te maken.

Zodra ze dat doen zal ondersteuning in andere OS-en niet ver weg zijn, daar heb je geen open source voor nodig.

[Iblies]

Vraag me af of dit soort code wel zo interessant is.


Android begon ook grotendeels open-source,
vervolgens is er met een heel grote community heel veel praktische apps gemaakt die zijn gekopieerd door Google-Android.

Vandaag de dag bestaan er praktisch geen custom-rond meer,
het is bijna onmogelijk geworden om een up-to-date custom rom te maken conform google's eisen.

[Sandor_Clegane]

In de basis heb je er weinig aan, de window manager en alles wat het OSX en IOS maakt zijn er niet bij. Darwin was ook altijd al vrij beschikbaar, waarom je die dan zou kiezen over een gewone Linux installatie, ik heb werkelijk geen idee. Voor de fun denk ik.

Het lijkt me meer iets van: "We geven terug aan de community". Maar is een beetje een loos gebaar.

[Zenety]

Je kan custom roms toch helemaal niet toepassen hier? Dit zal nooit gebeuren voor een iPhone. Het enige wat dit geeft is dat app ontwikkelaars misschien slimmer om kunnen gaan met bepaalde calls in het OS omdat ze kunnen zien hoe het precies verloopt. En natuurlijk hoopt Apple dat dit gaat helpen met bepaalde bug bounty's zodat meer mensen hun bugs submitten.

Het klopt inderdaad dat er minder verschillende custom roms zijn dat toen android begon. Dit ligt ook aan de makers van de telefoons. Voor de pixels/nexussen worden nog altijd veel custom roms gemaakt en worden ook nog goed geupdate. Ben blij dat ik nog 8.0 kan draaien op mijn Nexus 6.

[South_Styler]

De code is zeer interessant die Apple vrij geeft. Door een groot deel van de code online beschikbaar te stellen kan worden gezocht naar eventuele bugs door de community. Daarnaast kunnen zwakheden binnen het systeem opgespoord worden.

[oef!]

Grote kans dat het terug gaat komen. Als fabrikanten Treble goed implementeren dan kunnen je straks zoveel roms bakken als je hartje begeert.

[The Zep Man]

Kan dit bijvoorbeeld Hackintosh projecten helpen op de lange termijn?

[Reactie gewijzigd door The Zep Man op 30 juli 2024 00:00]

[Soldaatje]

Of een custom rom als Lineage OS voor iPhone?

[Aaargh!]

Je gaat tegen dezelfde problemen aanlopen als bij custom Android ROM's: er zijn geen drivers voor de hardware. De meeste Android telefoons draaien op antieke versies van de het Linux kernel omdat de fabrikant van de SoC alleen voor die kernel versie binary drivers aanbied en geen of niet genoeg documentatie bied om zelf drivers te kunnen schrijven. Wat dat betreft is de iPhone met deze release meer open-source dan Android.

[teacup]

Op zich wel een interessante opmerking die je maakt. Om even zeker te zijn dat ik haar goed begrijp. Apple maakt inmiddels gebruik van onder eigen vlag ontwikkelde SoC's. Dit zorgt dat ze ook de driverondersteuning hiervoor in eigen hand heeft. Resultaat: up to date driver ondersteuning voor de eigen hardware.

[downtime]

Niet echt. Ook als Apple hardware inkoopt kunnen ze zelf drivers ontwikkelen. Kwestie van onderhandelen over overdracht van documentatie en NDA’s tekenen.
Het probleem met Linux is juist dat het open source is. NDA’s en open source zijn nu eenmaal niet te verenigen.

[teacup]

Maar is de grootste probleem NDA dan die van de SoC zelf niet? Misschien dat camerahardware ook nog iets kan zijn, maar we weten allemaal hoe Qualcomm opereert verwacht ik, als je dit kan passeren?

[Ayporos]

betwijfel het. Lijkt me dat een camerahardware fabrikant het geen drol boeit wat voor software er gebruikt wordt om haar modules aan te sturen, zolang ze maar modules verkopen.
Een cameradriver geeft niet inherent hardwarematige 'geheimen' weg over de module, iig niet meer dan een willekeurige bedrijfsspion zou kunnen vergaren door gewoonweg een van die modules te kopen en te demonteren.

[Ralph Smeets]

Meer dan vijf jaar geleden was het al een trend dat je camera module niet te verkopen was als je niet een totaal pakketje verkocht. Daar hoorde niet alleen de driver bij, zelfs een basic en het liefst zelfs geavanceerde app moest erbij. En allemaal closed source natuurlijk.

[Aaargh!]

Ja maar mijn punt was dat als je dit op niet-Apple hardware wilt draaien, b.v. omdat je iOS wilt porten naar je Android telefoon, dat dat hiermee niet mogelijk is. Het probleem is namelijk dat je geen drivers hebt voor XNU, en de drivers die gebruikt worden voor Android/Linux zijn closed-source dus die kan je niet porten. Verder wil de fabrikant vaak de documentatie van hun hardware niet vrijgeven dus zelf drivers schrijven zit er ook niet in.

Dit probleem heb je ook bij Android custom ROM's waar vaak een antieke Linux kernel bij zit omdat dat de enige versie is waar drivers voor zijn, alleen is het in dit geval nog een stapje erger want zelfs die optie heb je niet.

[teacup]

Nee, voor hackintosch achtige experimenten maakt Apple zich hiermee dus niet meer gevoelig. Andersom denkende begrijp ik dus wel dat het makkelijker wordt om Android op Apple hardware werkende te krijgen. Maakt Apple zich hiermee niet kwetsbaar? Of lopen we bij een dergelijk experiment toch nog tegen een te kort aan documentatie vanuit Apple aan?

[Goldwing1973]

Ik denk eerder dat je tegen een driver probleem aan loopt.
Je hebt nodig, drivers voor beeldscherm(touch), audio, video, modem en het allerbelangrijkste, de CPU.
En Apple zal die echt niet voor Android schrijven.

[swhnld]

Wat dat betreft is de iPhone met deze release meer open-source dan Android.

Hoezo, de Android kernel is open source en nu is de de iOS kernel ook open source zoals ik het artikel lees. Kernel staat toch los van de drivers?

[Aaargh!]

Kernel staat toch los van de drivers?

Nee, drivers zijn onderdeel v/h kernel. Tenminste, normaliter wel. Het probleem is dat fabrikanten van SoC's vaak alleen binary drivers leveren voor hun hardware die alleen met 1 specifieke kernel versie werken en omdat het closed-source is niet kan worden opgenomen in de mainline kernel.

[Reactie gewijzigd door Aaargh! op 30 juli 2024 00:00]

[mikesmit]

Als je dat graag wilt koop je toch geen iPhone?

[Cartman!]

Waarom niet? Apple heeft mooie hardware die met andere software misschien voor sommigen beter tot z'n recht kan komen dan met iOS.

[DirtyBird]

Zoals bijvoorbeeld het feit dat Iphones altijd nog in een 4,7" versie komen, terwijl dit bij Android dun gezaaid is. Ik kan me best voorstellen dat hier vraag naar is ja.

[Verwijderd]

Ja met een behuizing die dan vervolgens groter is dan de concurrentie met 5"scherm. That makes sense.

[Verwijderd]

Ik vind het niet echt sense maken. Mooie hardware vind je bij de concurrentie ook. En dan heb je tenminste nog in alle prijsklassen een leuk aanbod.
Dus als je dat wil dan koop je idd geen iPhone.

[nelizmastr]

Alleen is Android dan niet het antwoord, gezien het minder geoptimaliseerd is en minder goede resource management kent.

[mikesmit]

Buiten dat ik niet kapot ben van de werking van Android vind ik het gewoon raar dat er besproken word om een costum Android rom te zetten op een iPhone. Er zijn legios aan prachtige Android apparaten op de markt die minder kosten dan een iPhone. En dan komen we op het punt van accuduur... iPhones hebben kleine accu’s die onder iOS zich aardig kunnen meten met Android telefoons met grote(re) accu’s. Ergens in de Android telefoon ontwikkeling worden dus accu optimalisatie fouten gemaakt. Als je het dus voor elkaar krijgt om lineageOS op je iPhone te krijgen kan je telefoon dus om de 4 uur aan de lader.

Vele tweakers vinden het prachtig om te knutselen aan hun telefoon, daar is niks mis mee, ieder zijn eigen hobbies. Maar om dan andere te veroordelen die daar geen zin in hebben?

[robvanwijk]

Even heel kort samengevat:

The Zep Man: "[Kan dit Hackintosh projecten helpen?]"
Soldaatje: "[Of een custom rom als Lineage OS voor iPhone?]"
mikesmit: "[Dan koop je toch geen iPhone?]"
pven: ..
mikesmit: "Vele tweakers vinden het prachtig om te knutselen aan hun telefoon, daar is niks mis mee, ieder zijn eigen hobbies. Maar om dan andere te veroordelen die daar geen zin in hebben?"

Wat ik me dan afvraag, waar komt die "anderen ertoe veroordelen" vandaan? Dat dingen als Hackintosh en Lineage bestaan (en mogelijk baat hebben bij het publiceren van deze sources) betekent toch op geen enkele manier dat mensen die er geen zin in hebben daar last van hebben? Niemand in deze thread stelt toch voor om het mainstream te maken (proberen op een groot aantal Apple-apparaten te installeren / mensen die de nadelen niet overzien aanmoedigen om het te installeren)?

@Reactie:
Ah, op die manier. Ik las het als "nep-nerd (dat je niet inziet waarom andere mensen dat zouden willen doen)"; klinkt alsof jij het opvatte in de trant van "nep-nerd (dat je dat zelf niet doet)".

[Reactie gewijzigd door robvanwijk op 30 juli 2024 00:00]

[mikesmit]

Wat ik me dan afvraag, waar komt die "anderen ertoe veroordelen" vandaan?

Zie de reactie van pven. Waar ik oorspronkelijk op reageer (het stukje wat je weglaat uit je “korte” samenvatting)

[mikesmit]

Ik vatte het inderdaad op als een belediging omdat ik niet loop te kutten met me telefoon. Als ik een beetje de activiteiten van pven bekijk denk ik ook dat hij het bedoelde als belediging.

Maar no worries, iedereen vat dingen wel eens anders op

[Shark.Bait]

Ergens in de Android telefoon ontwikkeling worden dus accu optimalisatie fouten gemaakt.

Ik denk dat fabrikanten van android toestellen zo weinig mogelijk geld besteden aan het optimaliseren van android op hun hardware. En dat android zelf ook te generiek geschreven is.

[hottestbrain]

De kunst van hackintosh is nu net met een ongewijzigde kernel de boel draaiend krijgen. Voor mij tenminste. Wat wel kan helpen is dat nu aan AMD support gewerkt kan worden door de community bijvoorbeeld.

[BvanBart]

Is dit nu geen risico? Bedoel... zo heeft de NSA en andere overheidsinstituten toch vrij spel?

[mae-t.net]

Dat hadden ze al lang. Nu hebben anderen ook een kans om eventuele fouten te vinden.

[Ventieldopje]

Beter dat iedereen gratis toegang heeft dan dat een grote organisatie ongeoorloofd / tegen betaling toegang krijgt.

[Ludwig005]

Lijkt mij wel een intressante ontwikkeling. mac os wordt met de dag steeds meer open source. misschien kan dit wel helpen bij hackintosh projecten.

[RefriedNoodle]

Nou, "ontwikkeling"... Apple publiceert al sinds jaar en dag de source van (grote delen van) OS X. Ik zie eerlijk gezegd niet de nieuwswaarde van dit artikel. Mede omdat ik denk dat <1% van de tweakers de kennis of interesse heeft om ook daadwerkelijk iets met de source te doen.

[Gopher]

Ik denk dat er toch redelijk veel tweakers zijn die er iets mee kunnen. Die het daadwerkelijk gaan doen, misschien niet. Maar gebruik maken van wat andere tweakerts er mee gaan doen kan misschien interessant zijn.

Lijkt me interessant inderdaad voor de hackintosh wereld, hoewel ik echter nog niet naar de inhoud gekeken heb.

[Ludwig005]

maar binnenkort krijgen we dus ios custom roms als apple door blijft doen met het vrijgeven van die source.

[arjan1995]

Zouden we nu eindelijk weer sneller jailbreaks voor de iPhone / ipad krijgen? Omdat het nu makkelijker is om fouten in de kernel te vinden?

[xehexehex]

Zeker .

[Yzord]

Die vervolgens worden doorverkocht aan louche bedrijven die er software voor maken en verkopen aan NSA achtige bedrijven. Want sinds dat booming is, is er amper meer een jailbreak uitgekomen voor de community.

[theduke1989]

Voor de android of iOS discussies.

Android is misschien minder snel en open-source maar vermoed dat ze degelijk wel meer open-source zijn dan iOS.

Maar Android is net als Microsoft. Veel hardware ondersteuning nodig en ontwikkeling omdat ze op meer platforms draaien dan iOS. iOS dan versimpeld stukje schrijven omdat ze het misschien voor 2-5 devices moeten schrijven en meer niet. Waar ze bij Android denk wel meer dan 50 devices moeten schrijven ondersteuning etc.

Het dan ook een grotere uitdaging voor Android dan iOS.

[Siebelouis]

iOS is vanaf nu meer opensource dan android. Beide kernels zijn opensource, maar ook de drivers zijn bij
Apple opensource, bij android niet.

[theduke1989]

Drivers zijn degelijk wel open-source alleen komt Snapdragon daar laat mee. Een MTK soc ist niet open-source. Die laten vaak tot nooit een release van een driver achter

[DCK]

Onzin. De drivers van Qualcomm en het Snapdragonplatform zijn totaal niet open source. Ze leveren gecompilede blobs en zijn makkelijker om mee te werken voor custom roms, maar de broncode drivers van de wifi, modem, gpu en heel veel andere zaken is een groot geheim. Enige wat Qualcomm netjes doet is de closed source meuk en werkbare open source code net verpakt leveren, dát doen de andere fabrikanten niet.

Er wordt hier weer lekker verkeerd gemod op basis van wat mensen in comments roeptoeteren.

[Verwijderd]

Mooie is altijd dat je enorm veel mierenneukers op Github op dit soort projecten duiken. Zie vele Pull requesten met mieren neuk aanpassingen op README.md
Het is altijd hetzelfde, beetje interessant doen, check mij een pull request hebben op Apple's source code!

[RoestVrijStaal]

Ik zag die pull requests ook. Man man man.

Ik heb ook wel eens met neuroten te maken gehad die vonden dat alle comments met een hoofdletter en punt moeten eindigen of anders mocht het niet met de master gemerged worden.

Voor incorrecte, misleidende namen snap ik het nog wel, maar voor hoofdletters of zinsbouw....kom op zeg.

[Dinnesch]

Het komt misschien wat mierenneukerig over, maar het toestaan van slordigheden is volgens de Broken Window Theory een "slippery slope". Volgens deze theorie worden mensen door het zien en negeren van slordigheden uitgenodigd om ook slordiger te werken, niet alleen op het vlak van documentatie maar bijvoorbeeld ook op het vlak van testing of security.

En met tools als GitHub wordt het mergen van pull requests erg simpel voor maintainers, dus wat is erop tegen?

[Reactie gewijzigd door Dinnesch op 30 juli 2024 00:00]

[Ventieldopje]

Wat is er op tegen? Dat je een wildgroei aan PR’s krijgt waarbij iedereen wat anders doet. Het probleem ligt bij de afspraken die gemaakt worden en gechecked worden met linters en anders tools door middel van CI.

Van iedere PR kun je dan zien of de tests gehaald worden en de code dus voldoet aan je standaarden (onder andere).

[g4wx3]

kernels zijn niet magisch
je vind ze in varianten al realtime, micro, hybride, monolitisch/ modulair,
qnxu minix linux hurd nt kernel.

[Kura]

Ach, een microkernel erbij kan geen kwaad