Google: Fuchsia is OS voor uitproberen nieuwe dingen

Google heeft op zijn ontwikkelaarsconferentie I/O voor het eerst gesproken over zijn komende besturingssysteem Fuchsia. Het zou vooral gaan om het proberen van nieuwe ideeën en technieken voor een besturingssysteem, aldus een topman.

Volgens Googles hoofd van diverse besturingssystemen Hiroshi Lockheimer is Fuchsia een investering in 'een soort van moderniseren en het uitproberen van nieuwe concepten rond besturingssystemen'. Dat zei hij volgens 9to5Google tijdens een sessie op Google I/O. "Natuurlijk nemen mensen aan: het is een nieuw OS van Google, dus het moet de toekomst zijn, weet je. Dat is niet hoe wij ernaar kijken."

Het is in elk geval niet primair bedoeld voor smartphones of computers, benadrukte Lockheimer. Voor die apparaten heeft Google al Android en Chrome OS. "In de wereld van het internet-of-things is er een groeiend aantal apparaten dat besturingssystemen en runtimes nodig heeft. Ik denk dat er ruimte is voor verscheidene besturingssystemen met verschillende sterke punten en specialisaties. Fuchsia is daar een van."

In 2016 bleek dat Google werkt aan Fuchsia. Concrete plannen over Fuchsia heeft het bedrijf zelf nooit bekendgemaakt. Wel verschenen er al diverse zaken over Fuchsia in het openbaar, zoals een interface die werkte op Android en op de Pixelbook.

Reacties (48)

Ik vind het een leuk concept, maar ik ben benieuwd hoe lang Fuchsia het vol houdt.
Google heeft wel vaker van die dingen die "opeens" gestopt worden.

Het is wellicht wel een mooie ontwikkelomgeving voor Chrome OS of Android.

De geruchten zijn altijd geweest dat Fuchsia de opvolger wordt van beide. Het is veel gemakkelijker om 1 OS te hebben en 1 ecosysteem. Ook zou het de oplossing zijn voor de patchproblemen. Maar deze uitspraken staan haaks op wat de geruchten tot nu toe waren dus het is even afwachten.

Klopt, voor Microsoft was het ook handiger om 1 Windows te hebben ipv nog een losse Windows Mobile. Ik hoop dat Apple ook ooit iOS en macOS samenbrengt tot 1 met 1 app store.

Toch werkte dat niet, W10M is dood. iOS, tvOS en macOS zijn praktisch gezien grotendeels gelijk, op een gegeven moment wordt het moeilijk om nou precies de scheidslijn te leggen tussen twee OSsen, en twee verschillende/gestripte versies van hetzelfde OS.

W10M was een compleet ander OS, misschien qua uiterlijk niet, maar onderwater zeer zeker. tvOS heb ik me nooit in verdiept, maar iOS en macOS staan mijlenver uit elkaar. Mijn punt is juist dat het handig zou kunnen zijn, om geen scheidslijn meer te hebben of beter; geen 2 OSsen.

Afgezien van de technische zaken (bijv. mobile CPU architectuur vs x86/x64), is de bediening de grootste uitdaging. Waar W10M nog enigszins gelijkenis vertoonde met de Metro stijl van Windows 8/10, lijkt iOS in het geheel niet op macOS.

Maar geen uitdaging welke Apple niet zou kunnen teckelen.

tvOS heb ik me nooit in verdiept, maar iOS en macOS staan mijlenver uit elkaar.

Deze OS-en lijken onder water zeer veel op elkaar. De kernels zijn min of meer gelijk, de verschillen zitten 'm voornamelijk in de user interface.

User interface design is altijd al een sterk punt van Apple geweest. Voor mobiel is er iOS, waarbij er duidelijke (interface) verschillen zijn of iOS op een iPhone of op een iPad draait. Overeenkomsten zijn oa draagbaar met touch interface.

Voor tv's heb je tvOS, wat in feite gewoon iOS is, maar dan met een 10 foot interface (en daardoor dus geen touch).

Voor de desktop heb je macOS, met veel overeenkomsten onder water en grote verschillen in gebruik. Een MacBook Air 13" en een iMac 27" draaien hetzelfde OS, maar in gebruik kan het totaal verschillend zijn, bv op je touch pad swipen tussen full screen apps vs allemaal half overlappende windows.

Met dezelfde code kun je bij Apple makkelijk apps voor de verschillende OS-en maken.

User interface design is altijd al een sterk punt van Apple geweest. Voor mobiel is er iOS, waarbij er duidelijke (interface) verschillen zijn of iOS op een iPhone of op een iPad draait. Overeenkomsten zijn oa draagbaar met touch interface.

sterker nog; met de komst van Marzipan is het feit dat alle besturingssystemen van Apple min of meer gelijk zijn zelfs een bewezen feit; universele apps voor iOS en macOS zijn dan realiteit. Apple heeft deze technologie al toegepast op apps als Boeken (iBooks) en gaat dat naar verluid ook doen met de muziek, films en podcast apps.
Apple heeft op dit moment juist een heel goed voorbeeld neergezet van een OS Core die op verschillende wijze kan worden toegepast.

iOS en macOS staan mijlenver uit elkaar

Juist niet, iOS draait op hetzelfde kernel als macOS en een groot deel van de userland is ook hetzelfde. Core Foundation is ook hetzelfde. UIKit is uiteraard anders dan AppKit (die laatste is ook ouder, UIKit zit wat moderner in elkaar) maar dat zijn dan ook de grootste verschillen.

macOS en iOS lijken behoorlijk op elkaar, vergelijk bv Launchpad met het iOS homescreen, en alle onderhuidse code (kernel, frameworks etc). Het belangrijkste verschil is de UI, iOS heeft de schaalbare vensters en muis support niet meegebakken.

Dat is juist het probleem met macOS.. Teveel functies van iOS worden naar de Mac gebracht terwijl die zich niet vertalen. Bijvoorbeeld launchpad, wie gebruikt dat nou echt? De iconen zijn veel te groot op een iMac. Het is net zo onhandig als het startscherm van Windows 8.

Ik zet altijd gewoon de Applications als stack op mijn dock, net zoals het voor Launchpad ook werkte, en meestal launch ik applicaties gewoon via Spotlight.

[Reactie gewijzigd door GekkePrutser op 10 mei 2019 18:08]

Gelijk heb je. Een telefoon of tablet is nu eenmaal een heel ander ding dan een laptop of desktop.
Het zal nooit gaan gebeuren dat een aanraakscherm op een laptop de voornaamste interface wordt.
Ok... zeg nooit nooit, maar voorlopig nog lang niet.
De kernel mag wat mij betreft hetzelfde zijn, als gebruiker zie je die toch niet, maar het is misschien handig voor ontwikkelaars.

Bijvoorbeeld launchpad, wie gebruikt dat nou echt?

Ik. Heb het dankzij de gesture altijd een fijne toevoeging gevonden.

[Reactie gewijzigd door n-evo op 11 mei 2019 22:16]

Toch werkte dat niet, W10M is dood

Of de uitvoering was gewoon belabberd, en daardoor de support vanuit developers matig. Waardoor het niet levensvatbaar is.

Bij Apple is dat denk anders.

Het verschil gaat m natuurlijk in de User Interface zitten en de hardware mogelijkheden die een laptop heeft tov een telefoon of tv, en visa versa.

Als je het "responsive web" uitgangspunt neemt voor het bouwen van native Apps voor Desktop én Mobile, dan heb je het native app probleem opgelost. Dat betekend dus; zelfde code-base, maar een "vloeiende" layout voor álle schermformaten, cross-OS. Volgens mij is Apple daar al mee bezig.

Uiteraard is niet iedere app daar geschikt voor, maar ik denk dat heel veel Apps daar wel van kunnen profiteren, ook om de ontwikkelingskosten laag te houden.

[Reactie gewijzigd door JorzoR op 10 mei 2019 08:50]

Ik ben inmiddels erg sceptisch geworden over webapps en webtech, in 2007 werd het allemaal met veel bombarie gelanceerd als *het* framework voor iPhone apps en de toekomst, maar anno 2019 (een absolute eeuwigheid later in de tech wereld) wordt de wereld gerund op native iOS/macOS, Android en Windows applicaties, en leiden de talloze web-based OSsen en frameworks een marginaal bestaan (WebOS, FirefoxOS, Tizen, ChromeOS, UWP apps in JavaScript, AppJS en ga zo maar door).

Instagram, Snapchat, Facebook, Whatsapp, Youtube, Gmail, Maps, inchecken op je vlucht, bestellen van een taxi, e-banking - het verschuift allemaal geleidelijk van het web naar native apps toe. Zelfs Google, de allergrootste cheerleader van 'alles-in-de-browser' kan het niet tegenhouden.

[Reactie gewijzigd door Dreamvoid op 10 mei 2019 10:29]

Zelfs Google, de allergrootste cheerleader van 'alles-in-de-browser' kan het niet tegenhouden.

Klopt, ik heb die verschuiving ook gezien.

Echter, met nieuwe technieken in de browser komen we ieder jaar dichter bij een "native feel" in de browser (PWA), wat enorm waardevol is.

Maar zolang web apps niet de toegang hebben tot de systeem API's die native apps wel hebben, dan zal het nooit zo'n vlucht nemen.

Tegenwoordig zijn er heel wat use-cases die je gemakkelijk in een browser op kan lossen, daar is geen native app voor nodig. Dat was 10 jaar geleden wel anders.

Er is vooruitgang

Gelukkig is cross-platform bouwen voor native apps ook stukken gemakkelijker geworden dmv React Native, Flutter etc...

[Reactie gewijzigd door JorzoR op 10 mei 2019 10:58]

Probleem is dat webapps runnen op een browser engine. Welke OS maker wil in vredesnaam de browser engine toegang geven tot zijn low-level API's? Doe dat, en je bent 1 lullige javascript exploit verwijderd van een of andere blok ad banner code op een website die rechtstreeks in je hardware zit te rommelen. Iedereen is juist druk bezig met applicaties zo strikt mogelijk sandboxen.

Uiteraard, je kan proberen de boel met permissions te scheiden tussen 'deze webapp op de Chrome engine mag wel de webcam in en met USB en het filesystem praten, maar deze website op Chrome mag dat absoluut niet', maar dan moet je wel vertrouwen hebben dat Chrome zo waterdicht is geprogrammeerd dat processen nooit van de ene naar de andere 'status' kunnen springen. Dat is een hoop vertrouwen leggen in de handen van Google (of Mozilla, zo je wilt).

Los van de performance/memory bloat issues met JS -> browser runtime -> native api's, wat op een desktop met 8+ GB RAM misschien niet zo boeit maar op een telefoon wel waar elke cpu cycle telt op de accuduur.

[Reactie gewijzigd door Dreamvoid op 10 mei 2019 15:28]

Probleem is dat webapps runnen op een browser engine. Welke OS maker wil in vredesnaam de browser engine toegang geven tot zijn low-level API's? Doe dat, en je bent 1 lullige javascript exploit verwijderd van een of andere blok ad banner code op een website die rechtstreeks in je hardware zit te rommelen. Iedereen is juist druk bezig met applicaties zo strikt mogelijk sandboxen.

Precies. Microsoft heeft hier ooit iets voor bedacht in hun naiviteit. ActiveX controls heetten die. Was super handig om applicaties te maken (die alleen in IE werkten). Je kon elke DLL op je PC aanroepen. Je kon er de mooiste dingen mee maken. Maar hackers vonden het ook prachtig. Wie had daar nou aan gedacht?

Laten we alsjeblieft niet weer die kant opgaan. De vorige keer heeft het een berg legacy zooi opgeleverd die tien jaar heeft gekost om er vanaf te komen.

En bovendien, vanwege privacy wil ik mijn browser niet in alles betrekken. Dat ding is 1 groot broeinest van tracking cookies. Ik gebruik in Firefox container tabs om dit een beetje te voorkomen maar het blijft lastig.

[Reactie gewijzigd door GekkePrutser op 10 mei 2019 18:09]

W10M is niet helemaal dood. Als aparte build in de markt voor smartphones, wel. Maar alle functionaliteit en features van Windows Mobile is nu onderdeel van Windows zelf.

Gerucht gaat dat iOS 13 en macOS "na-mojave" ondersteuning gaan toevoegen om universele apps te bouwen.

Of dit was het plan, maar het loopt allemaal niet zoals gedacht, en ipv afschieten gebruiken ze het als test omgeving.

Geen idee waarom je geen nieuwe dingen kan proberen op chrome of android, maar hey, ik heb de ballen verstand van code schrijven.

Chrome en Android zijn in de kern Linux, en dat zit nou eenmaal op een bepaalde manier in mekaar. Wat ik zo zie van Fuchsia, is dat (o.a.) juist om dingen te proberen die je niet met Linux voor mekaar kan krijgen.
Linux is uiteraard aan te passen, maar zijn de wijzigingen die je wilt maar groot genoeg, dan wordt dat ondoenlijk, en kan je beter opnieuw beginnen.
Het zou mss nog wel kunnen dat ze in Chrome of Android, Linux vervangen door Fuchsia, ze hoeven niet alles volledig opnieuw te maken.

Dat is maar ten dele waar...
Een OS dat alles doet is nergens echt goed in of voor. Dit is dan ook de reden dat ondanks dat ze erg vergelijkbaar zijn Apple bijvoorbeeld tvOS, iOS, watchOS en macOS heeft macOS draaien op een horloge is overkill er zijn te veel dingen die simpel weg niet nodig zijn dan wel veel te zwaar zijn om het horloge goed te laten werken het zelfde geld voor tvOS dat echt niet zal zorgen voor een goede ervaring op je telefoon of laptop.

Uiteindelijk als je kijkt naar de core zullen die 4 Apple OS'en echt niet heel erg verschillend zijn maar ze hebben bepaalde optimalisaties voor hun functies en de hardware mogelijkheden van het apparaat waar ze op zullen draaien.

Google doet een soort gelijk iets, de technieken en oplossingen die men voor Android gebruikt zouden maar ten dele werken voor een laptop waar je veel meer grote applicaties wil kunnen draaien en software op een hele andere manier in verschillende windows naast en over elkaar al dan niet gemaximaliseerd zal draaien. Veel van de compromissen die op een telefoon nodig zijn om de batterij blij te houden zijn op een desktop een stuk minder noodzakelijk.

Ik kan me heel goed voorstellen dat Google inderdaad dit fuchia OS alleen gebruikt om mee te experimenteren zonder dat vast zitten aan de beperkingen en conventies van Android, Linux, BSD, ChromeOS of welke andere voorganger dan ook.
Het lijkt me dat er binnen Google genoeg slimme mensen zijn die zich al tijden af vragen hoe je een modern OS zou maken als je het echt van af de grond af aan opnieuw opbouwt. Want als je kijkt naar macOS dat is grotendeels gebaseerd op freeBSD, wat zelf weer een afgeleide is van Unix. Linux is net als freeBSD afgeleid van Unix, Android is weer een zeer sterk aangepaste versie van Linux en dus afgeleid van Unix.
Zelfs Windows is duidelijk beinvloed door Unix en Linux als is dit een van de weinige OS'en dat echt flink afwijkt van de manier waarop Unix werkt.

Als je dat op die manier bekijkt en je weet dat je een zeer grote groep erg slimme IT specialisten voor je hebt werken en je hebt zo veel geld voor R&D dat je het je makkelijk kunt veroorloven dan is het niet gek dat je een groep van deze mensen vraagt om eens iets nieuws te maken dat niet afgeleid is van een systeem dat niet is afgeleid van een oplossing die ergens in de jaren '70 van de vorige eeuw (dus al weer bijna 50 jaar geleden) is geschreven.
Op dat moment waren meerdere cores, super krachtige GPU's en GB's of zelfs TB's aan geheugen nog ondenkbaar. Ook had men op dat moment niet kunnen weten dat we nu allemaal een SSD gebruiken en dat het zelfs voor een telefoon meerdere netwerk opties heeft en constant in contact staat met de rest van de wereld.

Het is een beetje als je af vragen of je als je nu het elektriciteitsnetwerk opnieuw zou kunnen ontwerpen je een beter netwerk zou kunnen bouwen (het antwoord is ja zeker). Kun je dat met een OS ook ik denk het wel het lijkt me heel erg sterk dat het originele ontwerp uit de jaren 70 geen ruimte bied voor verbeteringen.

Ik bekijk het zelf anders. Google is best wel divers aan het worden. Zoals ik het begrijp was er vroeger, toen de Unix kernel nog heer en meester was, behoefte aan iets wat bruikbaar was voor mensen die geen enorme licentie kosten konden of wilden betalen. In die race, die Linus toch wel heeft gewonnen, was de opzet van de Fuschia ook een kandidaat.

Uiteindelijk was de oplossing van Linus toch was simpeler in gebruik en paste het precies in de GNU stack en bleek het micro kernel principe toch wel erg complex.

Ik denk dat Google uiteindelijk Fuchsia OS, maar vooral de zircon kernel, als potentiële oplossing voor enorm veel zaken. Als je kijkt waar de Linux kernel, of afgeleide, allemaal gebruikt word dan is dat best wel indrukwekkend. Het betekend ook dat de kernel zo veel kan dat het risico met zich mee brengt. Als iemand ooit iets verzint om op grote schaal micro kernels te produceren heb je niet 1 standaard kernels wat overal werkt maar iets wat per case is geoptimaliseerd.

Denk niet dat we zoiets op korte termijn zullen krijgen maar we zijn wel beter geworden in grote complexe zaken makkelijker te maken..

Het is DE kans voor Google om met een schone lei te beginnen. De keuzes gemaakt in de vroege dagen van Android (kuch Java) zijn niet meer optimaal voor de moderne dag. Met Fuschia biedt Google bijvoorbeeld Swift ondersteuning en hebben ze nog veel meer controle over de kernel e.d.

Als ze dan toch aan een andere runtime gaan kunnen ze beter .NET Core gebruiken. Dan heb je direct ondersteuning voor alle platforms. Met Swift zit je volgens mij toch weer veel meer in de Apple hoek en ben je dus overgeleverd aan de grillen van Apple.

Met .NET ben je afhankelijk van (de grillen van) Microsoft. Daar zit 'm de winst m.i. niet in. Aan de andere kant is het voor Microsoft, Google en Apple niet in hun belang om teveel 'grillen' te hebben. Al zal er op alle platformen natuurlijk altijd een evolutie zijn.

.NET Core is open source. Ze kunnen altijd forken op het moment dat MS een koers vaart die zij niet willen volgen. Maar ik denk dat ze niet zo heel veel om x-platform geven, als gebruikers maar op android zitten vinden ze het allang best.

DotNet Core is even multiplatform als Swift al dan niet minder.

Swift en Core delen namelijk twee dingen; multiplatform taal - UI framework voor een enkele.

Ah, ik was me er niet bewust van dat je met Swift ook Windows applicaties kunt maken.

Swift is - en heeft - geen UI framework. Swift is niks meer of minder dan de programmeertaal die in de kern een soort schil is van Objective-c (wat op zijn beurt weer er superset is van c++).
Swift is open source en heeft verder geen “harde band” met andere apple software. Swift kun je wat dat betreft net zo goed toepassen als elke andere willekeurige programmeertaal die je multi platform neer zou willen zetten.

Apple heeft er echter voor gekozen om UIKit en AppKit niet vrij te geven. Deze frameworks zijn closed source en eigendom van Apple. Beide frameworks zijn overigens (grotendeels) geschreven in Objective C en hebben dus feitelijk niks met Swift te maken. Alleen omdat swift 100% backwards compatible is met Objective c is het zo dat je met swift zonder extra werk alles kan doen wat je ook kan moet Objective c.

Want Microsoft heeft nooit iets geks gedaan?
Laten we eerlijk wezen Google zal waarschijnlijk als ze ooit met een echte versie van dit OS op de markt komen waarschijnlijk een eigen taal gebruiken omdat ze dan alle controle hebben Swift is leuk maar Apple, .Net is grappig maar Microsoft, Java is schattig maar Oracle. Je kunt geen kant op met een taal van een ander. Als je kleine aanpassingen of optimalisaties wil maken voor jouw behoefte dan heb je een probleem zo als Oracle en Google bewezen hebben met het gedoe rond Java.

Ik kan me dan ook niet geheel voorstellen dat Google een zelfde verhaal wil beginnen met Apple of Microsoft. Nog kan ik me voorstellen dat ze aan een van deze twee bedrijven vast willen zitten voor het doorvoeren van aanpassingen aan de taal. Ik gok er op dat Google dat al eens een taal (Go) heeft uitgepoept vast en zeker een andere taal zal weten te produceren om op die manier zelf de volledige controle te hebben over de taal.
Dat ze op dit moment Swift ondersteunen is leuk maar het kan ook gewoon een oplossing zijn om niet te hoeven wachten op hun eigen taal of simpel weg om op die manier die eigen taal nog even onder de pet te houden en zo doende in alle rust verder te kunnen werken aan de taal.

Niet helemaal waar, het .NET Core framework is volledig open source inclusief compiler en runtime. Als je als Google zijnde iets dus niet zint kun je altijd je eigen weg gaan, zoals ze met Chromium ook gedaan hebben.

Het zijn er veel meer nog dan dat ik dacht, dingen die 'opeens' gestopt zijn.
https://killedbygoogle.com/

Zo! Dat zijn er inderdaad wel heel veel!
Zo veel had ik ook niet verwacht.

Tja, ook andere partijen stoppen weleens met dingen. In het geval van Google, betreft het dan vaak gewoon uitsluitend applicaties. Een Google+ dat de nek omgedraaid wordt? Denk niet dat daar veel mensen rouwig om zijn. Een Nest API die vervangen wordt door een andere API? Kan ik ook nog niet erg vinden.

Het wordt anders als er hardware in het spel is. Je zou maar een Windows Phone hebben, waar je intussen praktisch niets meer mee kunt. En vanaf eind december nog minder, want dan gaat ook WhatsApp eraan.

Fuchsia is OS voor uitproberen nieuwe dingen

net zoals google inbox [RIP] of een beetje zoals Works with nest [RIP] *EDIT* Android Auto app [RIP]
heel revolutionair, maar zodra google er klaar mee is trekken ze de stekker er uit.

hoewel google zich altijd heeft ingezet voor open initiatieven zijn ze zelf de boel enorm aan het dicht timmeren.

[Reactie gewijzigd door Proxx op 10 mei 2019 09:40]

De broncode is MIT.

ga jij zelf de ontwikkeling verder doen? als een core developer er mee stopt bloeien de meeste projecten na wat stuipen alsnog dood.

https://gcemetery.co/

De apps die je noemt konden niet geforked worden. Fuchsia wel want MIT. Totaal andere situatie.

Er is daarentegen zelfs ontwikkeling voor een FOSS GMS implementatie. Dus als Fuchsia closed source geraakt zie ik het positief in.

net zoals google inbox [RIP] of een beetje zoals Works with nest [RIP]
heel revolutionair, maar zodra google er klaar mee is trekken ze de stekker er uit.

Nou nou... Het is natuurlijk niet zo dat je helemaal niks hebt. Inbox functionaliteit zie je steeds meer terugkomen in Gmail, Works with Nest wordt gewoon onder de Google Assistant gehangen. Voor mij zijn het tot nu toe logische besluiten.

voorzover bekend kan een derde partij vragen of google assistant de lamp aan doet.
maar kan de derde partij niet aan google assistant vragen of de lamp aan staat. (privacy)
misschien is het inderdaad een storm in een glas water(ik hoop het van harte). als dat zo is heeft google het nieuws wel heel erg slecht in de markt gezet.

maar daar gaat het hier niet om, het gaat erom dat die Fuchsia OS een experimenteel os word en die uitspraak deed google bij veel van de 150 projecten die sinds 2006 gestart en gestorven zijn.

fuchsia os word het speelveld, later gaat chrome os of android verder met de functies van fuchsia os en die zal sterven. zo zie ik het.

"Het is natuurlijk niet zo dat je helemaal niks hebt. Inbox functionaliteit zie je steeds meer terugkomen in Gmail, Works with Nest wordt gewoon onder de Google Assistant gehangen."

Het is alleen jammer dat ze niet eerst die functies overhevelden. Een beetje alsof een straat wordt gerenoveerd, dan heropend na de renovatie maar de parkeervakken nog een jaar dichtblijven...

[Reactie gewijzigd door TheVivaldi op 10 mei 2019 12:25]

True.

Opzich wel logisch toch. Als ik voor m'n gebruikers een nieuwe applicatie maak dan wil ik liever 6 maanden werken, een soort van beta uitbrengen en kijken wat de mensen ervan vinden IPV 2 jaar ontwikkelen, reeksen en ontdekken dat iedereen het slecht vind

Nu bijv inbox.... Misschien was het aantal gebruikers laag en het onderhoud duur... Misschien betekent elke aanpassing aan Gmail dat inbox potentieel kapot gaat. Het onderhouden is dan niet logisch

Nu is Gmail in feite een ander product met misschien wel een miljard gebruikers. Het zou mij logisch lijken dat alle lessons learned van inbox naar het Gmail team gaat. Omdat de gebruikers populatie dermate groter is kan je niet zomaar alles implementeren wat de kleine gebruikers groep van inbox leuk vond. En de code base is anders dus ook dat kost wat tijd.

Als ik naar mezelf kijk lijkt het me een fijne manier van werken. Ik zou het niet kunnen op brengen om continue te werken aan een applicatie waarvan ik weet dat ik eigenlijk bezig ben met iets draaiend houden omdat het bedrijf waar ik werk vind dat we moeten wachten totdat een ander team klaar met het eventueel opnemen van onze features als dat voor een maandje of wat is hoort het erbij maar bijv een jaar lang zoiets doen zit er voor mij niet in. Dan neem ik liever ontslag en ga ik ergens werken waar ik wel aan iets meewerken met een toekomst en doel

Gmail heeft 1,5 miljard gebruikers en Inbox had iets meer dan 20 miljoen gebruikers. Ja, dat is een stuk lager dan Gmail, maar iets meer dan 20 miljoen lijkt me ruim voldoende (veel andere diensten kunnen alleen maar dromen van een getal als 20 miljoen...) om het iets langer in de lucht te kunnen houden.

Helemaal afhankelijk van de code tov aantal gebruikers.

Een van de grootste zakelijke redenen om in te zetten op Google Fuchsia, is het zelf mogen opstellen van de licentievoorwaarden. Android draait op de Linux Kernel welke de GPL gebruikt, en dat maakt het mogelijk voor de (privacy-bewuste) eindgebruiker om onderdelen op zijn telefoon aan te passen. Door de Linux Kernel te vervangen, is Google niet langer verplicht om de code te delen welke zij ontwikkelen voor Android. Dit zou ze dan ook de macht geven om sideloading, rooting en custom roms tegen te houden.

Nja, rooten tegenhouden weet ik zo net niet... iOS wordt ook steeds weer gejailbreakt. Verder wel met je eens.