Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Google verandert naam van microkernel Fuchsia OS in Zircon

Door , 75 reacties, submitter: NiLSPACE

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.

Door Julian Huijbregts

Nieuwsredacteur

13-09-2017 • 13:06

75 Linkedin Google+

Submitter: NiLSPACE

Reacties (75)

Wijzig sortering
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.
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.
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.
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.
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.
Google legt hiermee de verantwoordelijkheid voor dergelijke issues bij de fabrikanten. Dat hoeft geen probleem te zijn, mits die fabrikanten dat stokje overnemen.
Probleem is als je nu kijkt naar updates van telefoon fabrikanten, ik niet het gevoel heb dat ze dat stokje echt willen overnemen..
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.
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 ArtGod op 13 september 2017 18:41]

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.
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.
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?
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.
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 13 september 2017 13:44]

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 mind123 op 13 september 2017 13:15]

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 13 september 2017 13:37]

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 13 september 2017 15:57]

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.
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?
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 13 september 2017 15:15]

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.
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?
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.
Ik heb het over de nieuwe kernel
License Mixed: BSD 3 clause, MIT, Apache 2.0 (bron)
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.
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.
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.
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.
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.
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 gryz op 13 september 2017 13:21]

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.
Snap alleen niet wat een video van applicatielaag te maken heeft met een nieuwe kernel.....
Omdat dit de eerste beelden van Fuchsia OS zijn en dit het enige OS is wat momenteel gebruik maakt van deze kernel.
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.
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++.
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...
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

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*