Google verandert naam van microkernel Fuchsia OS in Zircon

Google heeft de naam van de microkernel voor zijn nieuwe mobiele besturingssysteem Fuchsia gewijzigd. De nieuwe naam is Zircon; eerder was dat Magenta. Fuchsia wordt van de grond af aan opgebouwd en is in tegenstelling tot Android niet gebaseerd op Linux.

De naam van het besturingssysteem zelf is niet veranderd, maar Phoronix merkte op dat de naam van de microkernel waarop Fuchsia OS is gebaseerd, is aangepast. Dat blijkt uit een bericht op Github. Ook heeft Google een pagina online gezet met code en documentatie over Zircon.

Voor de naamswijziging stond Zircon bekend als Magenta. Het is de microkernel die door Google is gemaakt als basis voor het nieuwe mobiele besturingssysteem met de codenaam Fuchsia. De kernel is vanaf de grond aan door Google ontworpen en niet gebaseerd op een bestaand systeem.

In mei verscheen een installatiebestand voor Android-smartphones, waarmee gebruikers de interface van Fuchsia kunnen uitproberen. Het ging om een statische mock-up en geen volledig werkende app. Het zou echter kunnen aantonen welke richting Google op wil gaan met de interface van het nieuwe besturingssysteem.

Vorig jaar bleek dat Google werkt aan een nieuw mobiel besturingssysteem. Concrete plannen over Fuchsia heeft het bedrijf zelf nooit bekendgemaakt. Mogelijk moet het op den duur Android opvolgen. Waarschijnlijk duurt het nog jaren voordat het besturingssysteem klaar is.

Reacties (75)

[beerse]

Een micro-kernel... Leeft Andrew Tanebaum nog? https://nl.wikipedia.org/wiki/Andrew_S._Tanenbaum. Daar waar Minix inspiratie was voor Linux zou de Amoeba kernel een (oer) voorbeeld voor deze microkernel kunnen zijn (https://nl.wikipedia.org/wiki/Amoeba_%28besturingssysteem%29).

Over een micro kernel: Wat ik daar van weet is dat deze kernel in tegenstelling tot de linux kernel, zo min mogelijk aan board heeft. Veel, zo niet alle device-drivers draaien in de applicatie laag en zijn dus als applicatie te vervangen.

Trek dat door naar een telefoon: Dan maakt het niet meer uit welk merk/type je hebt, als de micro-kernel maar draait. De drivers voor de camera, microfoon, speakers, telefoon, modem en dergelijke draaien allemaal als applicatie en zijn dus als applicatie te updaten.

[DCK]

De tradeoff van een microkernel is altijd geweest dat de extra laag van indirectie die erin zit van het switchen tussen verschillende drivers. Onderzoek heeft de performance-impact sterk verkleind, maar de impact zal nog steeds hoger zijn dan op een monolithische kernel. Let wel: dit was al een relatief klein probleem op computers uit begin jaren '90, waar zelfs Chinese telefoons van 50 euro van vandaag mijlen ver op vooruit lopen.

De modulariteit van een microkernel en verhoogde beveiligingsgaranties die een microkernel biedt waren traditioneel nooit een sterk tegenargument. Echter in een moderne wereld waarin telefoonupdates (onder andere) blijven hangen op drivers die allemaal in een enkel Linux-pakket, en waarin we allerlei onvertrouwde apps installeren op onze telefoons, is een microkernel relevanter dan ooit. Mooie zet van Google.

[Blonde Tux]

In potentie een zeer interessant concept. Als een driver er de brui aangeeft naait niet direct je hele systeem eruit.

Alleen een ding wat mij nog niet duidelijk is, is de potentiële latency die zich voor kan doen. Het lijkt me dat als je alle drivers via user space gaat laden je eerst de verstuurde data door een context switch moet laten gaan voor het bij de hardware uitkomt.

[2green]

Het laatste wat ik gezien had bij fuchsia is dat ze sowieso alles een eigen adapter krijgt met eigen controles / beperken zonder performance verlies. Kijk bijvoorbeeld naar het aantal system calls wat erg weinig is en dat ze afstappen van de aanpak zoals legacy systemen als linux doen qua mapping van virtual to physical adressen in de kernel. Zelfde functionaliteit zonder performance verlies in "user space" (denk bijvoorbeeld aan gpu zaken). Moeten een shitload een architecten een shitload een discussie over hebben gehad.

Maar het mooiste is nog dat het systeem lekker veilig lijkt te worden ipv die gatenkasen die we tegenwoordig hebben en bijna niet uitgehard zijn te krijgen, authenticatie op processen in het geheugen, etc.

Maar het grootste deel van wat ik zie is niet nieuw trouwens, volgens mij bestaat alles al in een of andere vorm ergens alleen nu samen in één kernel. Maar al een paar jaar niet meer met kernels bezig, dus mijn kennis is wat gedateerd.

[armageddon_2k1]

En gaan dus allemaal implementaties krijgen van verschillende suppliers, merken, fabrikanten en hobbyisten, waardoor veiligheidskritische functies allemaal backdoors, gaten en bugs bevatten. Topidee!
Het is wel sneller te patchen in ieder geval.

[DrSnuggles]

Google legt hiermee de verantwoordelijkheid voor dergelijke issues bij de fabrikanten. Dat hoeft geen probleem te zijn, mits die fabrikanten dat stokje overnemen.

[jctjepkema]

Probleem is als je nu kijkt naar updates van telefoon fabrikanten, ik niet het gevoel heb dat ze dat stokje echt willen overnemen..

[beerse]

Volgens mij proberen ze met de micro-kernel het stokje te breken en te verdelen naar de diverse leveranciers. Dan kunnen die zich niet meer achter elkaar verschuilen.

[Stoelpoot]

Hobbyisten drivers zijn inderdaad een gevaarlijk iets om je aan te branden. Verder mag je verwachten dat fabrikanten de gegevensveiligheid wel op orde hebben. En als ze dat niet hebben, zullen ze dat binnenkort mogen uitvechten met de GDPR.

[Verwijderd]

Wie zegt dat ze het elders neer gaan leggen?

Als ze het goed doen, doen ze het zelf en krijg je zoals jij zegt makkelijkere patches. Veel services draaien niet meer in kerbnel space, maar zijn userland processen. Dan kan je zelfs heel veel patchen zonder rebooten!

Bug in het audio subsysteem? Installeer een nieuw audio subsysteem, stop oud, start nieuw. Alles werkt? Verwijder oud subsysteem. Ondertussen is de telefoon niet uitgeweest!

Wel moeten al je applicaties dan om kunnen gaan met een tijdelijke onderbreking van een service, anders moet je mogelijk applicaties opnieuw starten. Maar een complete reboot zou niet meer nodig moeten zijn, tenzij de bug in de microkernel zelf zit en niet in de servers of devicedrivers.

[mard0]

Veel services draaien niet meer in kerbnel space, maar zijn userland processen. Dan kan je zelfs heel veel patchen zonder rebooten!

Bug in het audio subsysteem? Installeer een nieuw audio subsysteem, stop oud, start nieuw. Alles werkt? Verwijder oud subsysteem. Ondertussen is de telefoon niet uitgeweest!

Dat is nu al mogelijk door gebruik te maken van modules in de linux kernel

[Verwijderd]

Dat ligt eraan hoe je de kernel compileert, maar Linux is inderdaad een soort van hybrid systeem waarbij de modules gestart en gestopt kunnen worden als je ze als zodanig compileert, maar wel in kernel space draaien.

Er is echter een heel grote maar! Linus en co garanderen geen APIs voor kernel modules, je kan dus niet kernel 4.1 blijven draaien en steeds alleen de modules updaten. Op een gegeven moment zul je moeten herstarten omdat de API weer eens is verandert.

[Verwijderd]

Probleem met microkernels is altijd de performance geweest. Als je voor elke driver aanroep tig context switches moet doen dan komt dat de performance niet ten goede.

Op papier klinkt het geweldig, maar in de praktijk willen mensen toch voornamelijk performance. Dat zie je ook met de C programmeertaal. Het is zo onveilig als de pest, maar iedereen gaat voor dat laatste restje snelheid.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:38]

[beerse]

De taal C is een aardig voorbeeld; Die is helemaal niet onveilig. Het zijn de gebruikte libraries, modules en dergelijke die het onveilig maken.

Natuurlijk heb je gelijk als je zegt dat er helemaal geen controle in zit op types en het stuurt je ook niet in het verbeteren van je code. Maar aan de andere kant beperkt het je ook niet en forceert het je niet om ergens omheen te werken.

[wjvds]

Voor een programmeertaal wordt veiligheid over het algemeen gedefinieerd als de mogelijkheid om door bugs in je code geheugen aan te spreken wat je niet bedoeld had, zonder runtime of compile-time foutmeldingen. Het gelimiteerde type-checken in C is dus maar een klein deel van het probleem. Als jij gebruik maakt van de rauwe toegang tot pointers (in C eigenlijk niet aan te ontkomen) of arrays zonder wrappers die checken dat je indices kloppen kun je grote veiligheidsproblemen niet statisch uitsluiten.

Het zijn de gebruikte libraries, modules en dergelijke die het onveilig maken.

Hier overschat je ongetwijfeld je eigen programmeervaardigheden. Juist door gebruik te maken van bekende en goed gecontroleerde libraries en zo min mogelijk zelf te maken kan je de risico's van het programmeren in C beperken.

[brogamma]

Dat niet alleen. De structuur van een programma bepaalt ook of de software kwetsbaar is. Verpak jij als programmeur je Arrays en aanstuurmethodes in meerdere schillen, dan is het minder makkelijk om in het te hacken. Het nadeel is echter. In hoe meer schillen je het verpakt. De minder snel het is. C is al wel een oude programeertaal, maar de raw performance van C is nog steeds een van de snelste tot vandaag de dag. Persoonlijk denk ik dat google een manier heeft gevonden om alles te beveiligen maar alsnog klein te houden.

Persoonlijk snap ik de kritiek op een Microkernel wel. Het is lastig te maken en zorgt vaak voor meer problemen dan oplossingen. Maar Android is ook niet altijd de beste geweest(zeker niet qua beveiliging).
Google zal het gezeur wel een beetje zat zijn over de slechte beveiliging en een eigen weg in willen slaan voor de mobiele wereld. Waarin apple al jaren mee bezig is om alles gesloten te houden. Bedenkt google zich nu ook dat je beter maar een eigen product kan maken dan iets om te bouwen zodat het wel snel is maar ook net stabiel werkt.

[Zezura]

In C heb je toch echt Runtime type information. En je kan code net zo veilig schrijven als in elke andere taal.

Er is niets mis met C/C++
Bufferoverflow or unsafe typing
Kan met elke taal, want dit kan ook met C# vrij makkelijk.

[AJediIAm]

Ik meen me te herinneren dat de performance van microkernels in het verleden een probleem was. Misschien is dat tegenwoordig op te lossen omdat kernal de kernal runtime en user runtime over verschillende cores verdeeld kan worden waardoor de context switch niet meer nodig is. Weet iemand hoe dat zit?

[2green]

Performance is nog steeds een dingetje, maar daar zijn verschillende methoden voor (alhoewel het meer aanvoelt als workarounds).

Je moet het voordeel van een microkernel vooral zoeken in het lego aspect: Je voegt eraan toe wat je nodig hebt voor een specifiek doel. Kernel + banden = voertuig, kernel + vleugels is vliegtuig, kernel + drijvers = vaartuig.

Het wordt hopelijk sneller, maar dat komt niet direct door de gekozen architectuur, tenminste niet de microkernel variant dat ze inzetten.

[blorf]

Ik denk niet dat Google daar echt op zit te wachten. Dat zou volgens mij Android als OS versplinteren. Het niet-modulair zijn en het per toestel een andere variant hanteren zorgt er juist voor dat iedereen ze nodig heeft.

[H!GHGuY]

Ik ben het niet per se oneens, maar we vergeten allemaal dat de wereld sindsdien veranderd is. We hebben namelijk multi-core gekregen. Vergeet ook niet dat in Android er maar 1 applicatie in de voorgrond draait.

Deze 2 hebben als gevolg dat de scheduler van de micro-kernel die applicatie 1 volledige core kan geven en alle andere background services op de andere core(s). Als de applicatie een kernel-call doet dan pauzeer je die applicatie op z'n bestaande core in een energiezuinige stand zonder weg te schedulen, terwijl je op de andere core de juiste service wakker maakt. In de assumptie dat de kans reëel is dat dezelfde service meerdere keren na elkaar aangesproken wordt, kun je daar hetzelfde doen: je wacht met context switchen tot dit echt nodig is. Door de shared caches beperk je ook het performance verlies want de data is cache hot. Er is ook geen cache thrashing of lelijke delays door multi-processing.

Ik denk dat een micro-kernel voor een telefoon op deze manier wel degelijk zinnig kan zijn.

[azortje]

Dit klinkt heel vegelijkbaar met project Treble waarbij alles via een HAL aangesproken gaat worden en elke aosp kan draaien op een treblized telefoon.

[Mithrildor]

De code van Fuchsia was verspreid over een groot aantal repositories. Het team van Fuchsia wilde deze repo's samenvoegen tot een aantal lagen. Zircon is de onderste laag en bevat de kernel en een aantal low-level libraries. De andere lagen van Fuchsia zijn ook naar mineralen vernoemd.

[Reactie gewijzigd door Mithrildor op 23 juli 2024 22:38]

[dakathefox]

Op de één of andere manier (en niet omdat het Google is) heb ik altijd wel bewondering voor bedrijven die schoon schip durven te maken. Bedrijven die het oude vertrouwde los durven te laten en vervangen door iets wat - hopelijk - beter is. Ik zie dit veel liever als bedrijven die pak 'm beet 20 jaar voortborduren op oude code, met alle mogelijke veiligheidsrisico's van dien.

Daarentegen: of het slim is, is weer iets heel anders. Straks slaat het niet aan. Android heeft niet voor niets een marktaandeel van bijna 90%. Zo slecht is het dus ook weer niet lijkt me.

[Reactie gewijzigd door dakathefox op 23 juli 2024 22:38]

[freaky]

Ik zie dit veel liever als bedrijven die pak 'm beet 20 jaar voortborduren op oude code, met alle mogelijke veiligheidsrisico's van dien.

Echt een nonsense argument. Als het 20 jaar niet onderhouden code is, dan heb je *misschien* gelijk (ligt geheel aan de kwaliteit van de oude en nieuwe code). Als het in die 20 jaar wel onderhouden is (en dan laten we nieuwe functionaliteit er even buiten - die code is namelijk ook geen 20 jaar oud) is het hoogstwaarschijnlijk *VEEL* veiliger dan je nieuw ontwikkelde spul. Dat heeft nog geen 20 jaar exposure gehad namelijk.

Daarbij gaat het niet alleen om je kernel, alle tooling die er onder draait kun je ook zo'n beetje opnieuw ontwikkelen. Met name voor low-level apps (je installer, je partitioner, format tools, C libraries en bergen ander spul). Ook die code was al redelijk stabiel na 20 jaar - kun je ook over nieuw mee beginnen.

Ja het heeft absoluut voordelen om iets nieuws te schrijven, maar dat heeft meer te maken met het feit dat je design veel nieuwer kan zijn. Stellen dat het veiliger is alleen omdat het nieuwer is raakt echter kant noch wal.

[Reactie gewijzigd door freaky op 23 juli 2024 22:38]

[NiLSPACE]

Met het veiligheid argument ben ik het eens, nieuwer betekent niet automatisch veiliger. Het is echter wel mogelijk dat dingen veiliger worden door nieuwe technieken te gebruiken.

Neem bijvoorbeeld Servo, de nieuwe experimentele browser engine van Mozilla. Deze is geschreven in een nieuwe taal genaamd Rust waarmee bepaalde bugs gezien kunnen worden tijdens het compileren. Hierdoor kunnen fouten als data races, use-after-free en buffer overflows direct gezien worden simpelweg omdat het programma niet compileerd als er iets niet helemaal klopt. Laat zulk soort bugs nou net de meest voorkomende security exploits zijn in Firefox: https://www.mozilla.org/e...y/advisories/mfsa2017-18/

Echter betekent zo'n taal uiteraard niet dat het programma automatisch veilig is. Als de ontwikkelaar slechte keuzes maakt tijdens het schrijven van software heb je nog steeds een probleem. Daarom is het nog altijd belangrijk dat code goed gereviewd word voordat het in productie komt.

[Reactie gewijzigd door NiLSPACE op 23 juli 2024 22:38]

[dakathefox]

Ja het heeft absoluut voordelen om iets nieuws te schrijven, maar dat heeft meer te maken met het feit dat je design veel nieuwer kan zijn. Stellen dat het veiliger is alleen omdat het nieuwer is raakt echter kant noch wal.

Het gaat niet alleen om veiligheidsrisico's natuurlijk. Dat zou wel heel erg kortzichtig zijn.

Ik vergelijk het bouwen van software altijd met het bouwen van een huis. Je weet waar de oprit moet komen, je weet waar de zon opkomt en je weet hoeveel slaapkamers je nodig hebt. Je begint te bouwen en te bouwen totdat het klaar is. Plots blijkt dat je geen 3 maar 4 slaapkamers nodig hebt. Je nodigt een nieuwe aannemer uit voor het uitbouwen van een dakkapel. En ach, moeders de vrouw wil ook de auto onder een afdakje, dus die carport komt er ook. Dit keer een handige klusjesman, weer met een andere mening. Een bijkeuken blijkt ook wel handig te zijn en waarom niet direct twee openslaande deuren naar het terras erbij? Ondertussen veranderen uitgangspunten continu, ook omdat wet- en regelgeving aan verandering onderhevig is.

Gedurende 20 jaar bouw je verder en verder, totdat je op een dag naar je huis kijkt en denkt: wat een rommeltje. Het is een allegaartje van oplossingen geworden, waarbij alleen je nieuwe terrasdeuren aan de hoogste veiligheidseisen voldoen. Alle oorspronkelijke deuren zijn nog steeds onveilig, want al 20 jaar oud. Bovendien had je het te druk met het bouwen van de dakkapel, de carport en de terrasdeuren. Die deuren zagen er verder ook nog goed uit, toch!?

Natuurlijk... Iets wat 20 jaar op de markt heeft, heeft zich 20 jaar lang bewezen. Maar het voldoet ook aan de eisen van 20 jaar terug. Dan kan het tussentijds wellicht wel opgelapt zijn, maar het is en blijft nog steeds gedateerd.

[TheMak]

Ja, maar als je het nieuwe huis af hebt dan zijn de kinderen de deur uit. En blijkt dat het oorspronkelijk idee toch niet zo slecht was.

[Eeki]

Het onderhouden en verbeteren van een huis met software kun je niet vergelijken. Refactoren van software is een stuk makkelijker dan het refactoren van een huis.

[Boy]

Als ze het zo kunnen spelen dat dit OS voordelen heeft tov Android EN (wat zeker zal gebeuren) de Play Store is beschikbaar op het apparaat, waarom zouden fabrikanten het dan niet gaan gebruiken?

[2green]

Je ziet het verkeerd, zircon is geen OS en Android is een merknaam van google voor hun besturingsysteem (dus niet enkel een kernel).

Een OS (besturingssysteem) bestaat uit een heleboel onderdelen, waaronder een kernel.

Een fabrikant mag van een een apparaat alleen zeggen dat het android draait als het voldoet aan de voorwaarden van google, waaronder de aanwezigheid van specifiek apps, eisen aan de gebruikte kernel, etc.

Deze eisen veranderen voortdurend, dus kan google op moment X gewoon zeggen dat ze eisen dat je een linux-kernel of Zircon-kernel moet gebruiken, waarbij Zircon van de nodige voordelen geeft voor zowel fabrikanten als gebruikers.

Op moment Y zullen ze gewoon zircon verplichtstellen en whola android draait op zircon.

Beetje vereenvoudige weergave, maar ze gaan echt geen concurrent voor android maken, android wordt gewoon door ontwikkeld naar dit punt.

[Reactie gewijzigd door 2green op 23 juli 2024 22:38]

[Boy]

Ik zie het niet verkeerd, ik had het ook niet over de kernel, maar over Fuchsia OS. Ik weet wel grotendeels hoe een OS werkt.

Ik denk gewoon niet dat ze deze kernel compatible gaan maken met Android, ik denk dat dat te moeilijk gaat worden. Ik denk dat Zircon van grond af aan opnieuw is ontwikkeld zonder erbij na te denken dat Android erop moet kunnen draaien. Het lijkt me makkelijker om apps compatible ermee te maken.

Een fabrikant mag van een een apparaat alleen zeggen dat het android draait als het voldoet aan de voorwaarden van google, waaronder de aanwezigheid van specifiek apps, eisen aan de gebruikte kernel, etc.

Dat is niet waar, Android is niet van Google, Google Android is gebasseerd op AOSP. Fabrikanten mogen alleen de Play Store erop hebben, als ze specifieke apps erbij toevoegen, dat is gewoon marketing. En volgens mij mogen fabrikanten verder gewoon de kernel aanpassen hoe zij willen.

[2green]

Je vergist je, Android is van Google en bepaald wat android mag heten:

"The source code for Android is open-source: it is developed in private by Google, with the source code released publicly when a new version of Android is released. Google publishes most of the code (including network and telephony stacks) under the non-copyleft Apache License version 2.0. which allows modification and redistribution.[238][239] The license does not grant rights to the "Android" trademark, so device manufacturers and wireless carriers have to license it from Google under individual contracts. "
- https://en.wikipedia.org/wiki/Android_(operating_system)

Fuchsia OS is trouwens enkel een zandbak, een soort test OS. Het eind doel is niet bekend gemaakt, maar het ligt voor de hand dat google af wil van java, het android landschap niet kwijt wil en dit landschap niet wil fragmenteren en daarmee kansen creeren voor de vele concurenten die al diverse pogingen hebben gedaan er tussen te komen. Ergo, ze gaan integreren... als ze al iets met deze kernel gaan doen. Ze hebben eigenlijk geen andere keus.

Daarnaast moet je ook dit project niet overschatten, op dit moment is het een project dat opgepakt wordt in werknemers flexibele uren (werknemers hebben een potje die ze mogen besteden aan een selectie van projecten). Er ligt voorzover mij bekend nog geen strategisch plan aan te grondslag, formeel zijn er geen plannen vanuit andere afdelingen hier iets mee te doen, aldus mijn contacten daar en diverse nieuwsbronnen met soortgelijke contacten.

[Boy]

ah, dat wist ik inderdaad niet! En als ik nou een telefoon ontwikkel en gooi daar AOSP op, dan mag ik dus niet zeggen dat deze telefoon Android draait...hoe moet ik dat dan noemen?

[2green]

Goede vraag, eigenlijk geen idee...

met internetspiekwerk kom ik niet verder dan:
* blijkbaar zijn er geen standaard namen, behalve AOSP zoals je zelf al noemde.
* AOSP is natuurlijk een lelijke naam en je mag hem dan ook niet voluit schrijven omdat je dan door het woordje android een claim aan je broek krijgt als google het ergens leest.
* amazon hun AOSP geloof ik fire OS.
* ik zou gaan voor iets als opendroid, freeroid, etc... maar er is een kansje dat google dat ook pikt

Dit gedoe is trouwens ook een van de redenen waarom veel mensen open staan voor echt open besturingsystemen. Naast de naam, zit wel erg veel van het framework/middleware in google zijn gesloten software, kwam toevallig onderstaande inforgraphics tegen toen ik bovenstaande opzocht n.a.v. je vraag. Die geeft al aan hoe het bij android tv zit, android is zelfs nog iets erger:

http://divitel.com/android-tv-vs-aosp/

[Sandor_Clegane]

Zie Netscape voor de gevaren. Voor de rest, ik vind het wel een wrang, lekker op de schouders van reuzen staan door de Linux kernel te pakken, je eigen sausje erover en dan blijkt het aan te slaan.

Dan opnieuw beginnen. Ik had liever gezien dat ze de resources terug in Linux zouden steken, ik bedoel de problemen die ze hopen op te lossen met deze nieuwe kernel zal natuurlijk voor veel kernels in het algemeen gelden en voor Linux in het bijzonder, waarom zou je anders deze maken?

[dakathefox]

Het voordeel van Open Source is dat iedereen er mee aan de slag mag gaan, binnen de voorwaarden die de specifieke Open Source licentie stelt. Sterker nog: Android IS Open Source. Het argument dat Google de resources terug in Linux moet steken houdt daarom geen stand.

Google heeft bijgedragen aan meer dan 2.000 Open Source projecten, waaronder Linux. Wellicht dat met de komst van de eigen kernel de inbreng voor Linux zal dalen, maar dat zou niet meer dan logisch zijn.

[raro007]

Staat het vast dat de project open-source is?

[dakathefox]

Android zelf is Open Source. Zie ook: https://source.android.com/.
Google Play en de aanvullende diensten van Google zijn geen Open Source.

[raro007]

Ik heb het over de nieuwe kernel

[markvw]

License Mixed: BSD 3 clause, MIT, Apache 2.0 (bron)

[SuperDre]

Maarja, aan de andere kant is Linux inmiddels behoorlijk oud en de gedachtegang bij veel onderdelen ook. En voor toekomstige hardware voldoet de linux-basis misschien niet meer en wordt daar dus met dit nieuwe OS al wel rekening gehouden.

[Gyzome]

Linux "oud" noemen is toch wel niet zo correct. En de implicatie dat linux "verouderd" is nog een pak minder. Linux zelf stamt uit 1991; dat maakt het binnen 4 dagen exact 26 jaar oud wordt. Als we dit vergelijken met andere modere OS'en, dan kijken we vooral bijvoorbeeld naar Windows NT en Darwin (macOS kernel), dan zien we bijvoorbeeld dat NT slechts 2 jaar jonger is en Darwin ogenschijnlijk nog maar 17 jaar oud is. Maar Darwin is wel gebouwd op source code van NeXTSTEP, uit 1989, dat op zijn beurt gebouwd was op BSD, dat helemaal terug te dateren valt naar de originele Unix uit 1972. We beschouwen Darwin, dat vandaag op GSM's, Apple TV's, Apple Watches, Macbooks, etc... draait, niet bepaald verouderd, ondanks zijn zeer gevorderde leeftijd. Om kracht bij stelling te zetten dat de leeftijd van een kernel niets te maken heeft met hoe verouderd of achterhaald die is, kijken we even naar NT. Twee jaar jonger dan Linux, maar op veel vlakken (bijvoorbeeld security) toch niet meer zo up-to-date. Dat heeft te maken met Microsofts aversie om backwards compatibility te breken, waardoor veel verouderde elementen uit NT geen facelift krijgen. Linux daarentegen heeft wel het lef om compatibiliteit te breken, waardoor het ondanks zijn oudere leeftijd er toch in slaagt moderner te zijn dan NT. Ik heb hier trouwens bewust FreeBSD erbuiten gelaten, dat ondanks zijn even oude source tree als Darwin zowat de modernste en innovatieve kernel is.

Als je deze "oude" kernels vergelijkt met nieuwe ontwerpen, dan zie je dat de nieuwe ontwerpen vaak slechts in een bepaald, heel specifiek ding, een kleine voorsprong hebben op de traditionele kernels. Linux blijft een zeer performante kernel, anders zouden ze die niet op supercomputers gebruiken. In plaats van het te zien als 26 jaar aan "veroudering", zou u het liever zien als 26 jaar aan onafgebroken ontwikkeling en vernieuwing.

Hardware blijft eveneens op dezelfde paradigma's leunen. Een ARM core of een x86 core zijn uiteindelijk niet zo verschillend van spiksplinternieuwe architecturen zoals Power7 of RISC-V. Pas wanneer quantum computing van de grond komt met de radicaal verschillende hardware ga je nood hebben aan een nieuwe vorm van OS design.

[Sandor_Clegane]

Niet oud maar volwassen denk ik.

[cracking cloud]

refereer je aan deze? https://www.joelonsoftwar...u-should-never-do-part-i/

[Sandor_Clegane]

Yep.

[raro007]

De app gap is er niet want ik verwacht dat er in de beging android apps geemuleerd woord en in tussen tijd worden ontwikkelaars gepusht naar het nieuwe systeem.
Zelfde tactiek als wat Apple gedaan heeft met 32 naar 64 bit. Alleen was er geen emulatie.

[Boy]

waarom emulatie als ze ook de bytecode gewoon kunnen verwerken voor het nieuwe platform?

[jj71]

Google heeft genoeg geld voor dit soort experimenten.

Ze bouwen dit nieuwe OS wel helemaal van de grond af aan opnieuw op, maar dat betekent nog niet dat het volledig incompatible zal zijn met Android. Als dit ooit gaat leiden tot een volledig nieuw OS voor mobiele telefoons, dan is het goed mogelijk dat ze er een Android compatibility layer aan toevoegen zodat alle (of de meeste) bestaande Android apps er ook op kunnen draaien.

[IStealYourGun]

De geschiedenis leert dat de kans op success dan wel een stuk kleiner is, zeker bij grote projecten. Tegen het moment dat je klaar bent is de concurrentie al enkele jaren verder. Nu wordt dit wel parallel ontwikkeld met hun bestaand OS, maar dat betekent dat hun "nieuw" OS in concurrentie moet gaan met android en dus constant moet inhalen. Het is dat Google voldoende resources heeft, maar het zou me niet verwonderen mochten ze uiteindelijk toch de stekker er uittrekken.

[SuperDre]

Maarja, ze hebben wel een toekomst visie voor dit nieuwe OS, waarbij het bij Android door blijven draven op oude 'muk' waar je soms echt zwaar omheen moet werken om te voorkomen dat een nieuwere versie nog wel de meeste oude applicaties kan draaien.
Ook moet je niet vergeten dat het bouwen van een nieuw OS je ook betere inzichten geeft in eventuele aanpassingen die je kunt maken in het bestaande OS.

[g4wx3]

nou, Windows NT heeft Windows toch mooi vervangen, en Windows heeft Dos mooi vervangen.
Als je iets parallel ontwikkeld, en app-compatibileit behoudt is het zeker vooruitgang.

Anderzijds, kan je tot in het oneindige discuteren over kernel-structuren, net als alle andere structuren in een programma. Anders is niet fout. Zelfde discussies bij het bouwen van een huis, het opvoeden van een kind.
Vooral belangrijk is om te blijven ontwikkelen. En funderingen aanpassen is moeilijk, omdat je dat een hele berg erboven ook moet aanpassen, maar zal altijd noodzakelijk zijn.
Windows GDI is ook vervangen, .Net komt in de plaats van de win32 api te staan, drupal 8 is nu gebaseerd op symfonie, Wordpress heeft rest geïmplementeerd. Als je maar hard genoeg ontwikkeld aan iets geraak je wel vooruit. Soms is het gewoon van heel lang adem. (denk aan de vertragingen van windows Vista)

Opnieuw beginnen is vaak een nog veel grotere job, dan blijven ontwikkelen aan iets bestaands

[IStealYourGun]

Ik denk dat NT mijn betoog net bevestigt. Het heeft jaren (en versies) geduurd alvorens dat OS volwassen was.

[Verwijderd]

Niet gebaseerd op Linux.
Maar is het wel POSIX-compliant ?

Alle system-calls die je van een Unix systeem zou verwachten ?
En libraries, utilities, etc ? Lijkt het nog gewoon op Linux ?
Edit: mmm, ze hebben alleen de kernel vervangen. Ik zou dan denken dat verder alles bij hetzelfde blijft.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:38]

[Mithrildor]

Fuchsia heeft een microkernel, o.a. de filesystems draaien als services in userspace. De kernel kan dus niet POSIX-compatible zijn. Er is wel een POSIX-compatibility laag in de userspace.

Zircon lijkt weinig op Linux, Zircon werkt voornamelijk met objects, en communicatie met de kernel gaat via handles voor die objects. Het lijkt meer op de kernel van Windows NT dan op Linux.

[gepebril]

Snap alleen niet wat een video van applicatielaag te maken heeft met een nieuwe kernel.....

[Boy]

Omdat dit de eerste beelden van Fuchsia OS zijn en dit het enige OS is wat momenteel gebruik maakt van deze kernel.

[aldieaccounts]

Het grootste nadeel van een google-owned kernel vind ik precies dat: Google owned. Google's reputatie op het gebied van continuiteit is niet bepaald goed. Maar goed, hoe meer keus hoe beter hopelijk.

[Verwijderd]

Ik twijfel of zelfs een kapitaal krachtig bedrijf als Google, iets kan ontwikkelen wat het Linux kernel ecosysteem kan vervangen. In Linux zit decennia werk en er zijn een bijna oneindig aantal branches, waar mensen het nieuwste van het nieuwste ontwikkelen op informatica gebied. Google kan dit eco-systeem niet binnen een paar jaar evenaren, zelfs niet in tien jaar.

En los daarvan maakt Google de dodelijke fout om Zircon in C te ontwikkelen in plaats van C++.

[graey]

Och, of die fout dodelijk is zal wel loslopen, ze hebben daar ook geen echt domme koppen op gezet.
Daarnaast hoeven ze niet het hele Linux-kernel ecosysteem te vervangen. Ze kunnen zelfs beginnen met een OS dat maar op een kleine selectie hardware draait, waarbij ze dus een tiental drivers moeten maken.
Vervolgens gaat de Dalvik-VM daar bovenop, samen met een API-set die source-compatible is met de Android-API. Dan kan je alle Android-apps die niet naar machinecode gecompiled zijn draaien, en kunnen programmeurs hun native code simpelweg hercompilen met geen of weinig moeite. Langzamerhand komen er meer drivers uit voor dit OS, en op een gegeven moment vervangt het Linux/Android volledig en heeft Google haar hoofddoel met dit project waarschijnlijk bereikt.

En of het Google-owned deel zo'n probleem is, vraag ik me ook af.
Ik vertrouw Google niet echt als het gaat om 'openheid' in al haar zaken, maar waar ze gesloten in zijn is voornamelijk gebruikersdiensten en alles wat dat aanraakt (denk aan de search-app, de homescreen-app, toetsenbord, camera en meer waarvan de betere versies buiten AOSP closed-source worden ontwikkeld door Google).
Maar voor een OS-kernel is juist meer openheid beter, ook voor Google, want dat zorgt er nou juist voor dat je een breder publiek kan aanspreken (en makkelijker op meer hardware kan draaien omdat onafhankelijke hardwaremakers er zelf mee aan de slag kunnen).

[aldieaccounts]

Ik vertrouw google voor geen cent als het om 'openheid' gaat idd. Maar dat zal hier waarschijnlijk geen probleem zijn (in ieder geval niet zolang zircon niet een monopoliepositie heeft). Ik had het in dit geval echter meer over continuiteit. Ik zou als 3d party nooit afhankelijk willen zijn van een google owned project omdat ze nogal eens de stekker er uit trekken.

[graey]

Dat is waar, maar als je kijkt naar Android (en als dat is waar ze dit op mikken, is dat denk ik een goede inschatting), zal dat niet zo gaan. Als ze ineens de stekker uit Linux/Android trekken ten gunste van Zircon/Android, zijn ze in één klap een groot deel van de markt kwijt, die bovendien makkelijk verder kan met een fork van Linux/Android zonder Google. Ze zullen dus Zircon/Android aantrekkelijk moeten maken en houden voor derde partijen, zodat de marktpenetratie groot genoeg kan worden. En als dat gelukt is, kunnen ze ook niet zomaar de stekker eruit trekken (zelfde verhaal als Linux/Android nu is).

[SV_25]

Hadden ze niet verder kunnen gaan met GNU hurd?
(https://en.wikipedia.org/wiki/GNU_Hurd)

[jabwd]

Ik neem aan dat ze het vanaf de ground-up willen doen ook deels vanwege alle nieuwe mogelijkheden met hardware die ze in 1990 er nog niet waren.

Waarom anders ook gewoon niet minix pakken... zijn veel keuzes uiteindelijk.

[Blokker_1999]

Je bekijkt een demo op een android device en maakt daar direct uit op dat het niets zal worden. Knap, zeer knap.

En java hoeft helemaal geen probleem te zijn. Android is trouwens helemaal niet gebasseerd op java. Dat vele apps java based zijn maakt het os nog niet java based...

[mikesmit]

Ik heb een zakelijk s6 en de lag is er hoor! Alleen durf ik die niet 100% aan Android te wijten omdat Samsung hun speciale lag saus eroverheen gooit.

Het viel me vorig jaar bij de s7 van een maat van op dat ook daar gewoon lag is in de interface. Veel mensen kunnen daar blijkbaar mee leven, prima toch, maar ik niet. Dus vandaar een iPhone

[Shashisukhai]

Ik zeg niet dat het niets wordt, ik zeg alleen dat ik in het filmpje lag zie.
De lag die Android heeft in de UI komt mede doordat de garbagecollector van Java zijn werk doet.

Dit resulteert in een zichtbare lag die ik opmerk.

[NullZer0]

Vraag me af welk Android device jij gebruikt. De OnePlus 3 is hartstikke vloeiend

[Shashisukhai]

Een LG G6.
Sowieso vloeiende Interface, maar een verschil in lag is mijn inziens altijd merkbaar in vergelijking met IOS apparaten.

[Verwijderd]

Je bedoelt op het filmpje van een pre-pre-pre-pre-alpha OS waarvan dit de eerste beelden zijn zie je lag? Ik kan je vertellen dat je geliefde iOS in deze staat waarschijnlijk ook een grote bende van ellende was.
Ziet er meer naar uit dat je even wilt laten weten hoe goed jij Apple vindt in plaats van een onderbouwde reactie plaatsen over een nieuw OS, doe dat dan lekker niet en ga verder met iOS...

[Shashisukhai]

Begrijp me niet verkeerd, ik ben pro gebruikersvriendelijkheid. Of dat nou op Android of IOS is, dat maakt niet uit.

Gebruikersvriendelijkheid binnen een nieuw OS staat voor mij persoonlijk hoog en touch latency is hierin een belangrijke factor, vooral omdat je het direct merkt, het is visueel en kan afbreuk doen.

Neemt niet weg dat het klopt wat je zegt, het is de eerste fase wat hier getoond wordt en dit kan altijd geoptimaliseerd worden.

[aldieaccounts]

Garbagecollectors resulteren meestal meer in (micro)stutters dan in lag. Maar goed, ik heb het filpje niet gezien dus weet niet precies wat je bedoelt.

[dakathefox]

Ik hoopte dat de lag in de userinterface verminderd zou worden, echter zie ik dat dit nog steeds aanwezig is.

De specifieke structuur van Android zorgt ervoor dat er altijd vertraging is. In vergelijking met bijvoorbeeld een Windows Mobile is dat verschil wel te merken, maar als ik geen Windows Mobile had gehad, dan had ik niet beter geweten.