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
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.
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
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.
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.
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.
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.
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.
Dit klinkt heel vegelijkbaar met project Treble waarbij alles via een HAL aangesproken gaat worden en elke aosp kan draaien op een treblized telefoon.
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.
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?
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/
waarom emulatie als ze ook de bytecode gewoon kunnen verwerken voor het nieuwe platform?
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.
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
Ik denk dat NT mijn betoog net bevestigt. Het heeft jaren (en versies) geduurd alvorens dat OS volwassen was.
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).
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.
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).
Hadden ze niet verder kunnen gaan met GNU hurd?
(https://en.wikipedia.org/wiki/GNU_Hurd)
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.
Een LG G6.
Sowieso vloeiende Interface, maar een verschil in lag is mijn inziens altijd merkbaar in vergelijking met IOS apparaten.
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...
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.
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.
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.

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

*