Google werkt aan een nieuw besturingssysteem met codenaam 'Fuchsia'

Google werkt aan een besturingssysteem dat het bedrijf de codenaam 'Fuchsia' meegeeft. Het OS wordt vanaf de basis opgebouwd en lijkt bedoeld voor zowel smartphones en pc's als andere formfactors. De internetgigant heeft zelf nog geen ruchtbaarheid aan het systeem gegeven.

Dat schrijft Phoronix op basis van een Git-repository van Google. De commit 'fuchsia' laat slechts de zin "Pink + Purple == Fuchsia (a new Operating System)" zien, ofwel 'roze + paars == Fuchsia, een nieuw besturingssysteem'.

Fuchsia wordt opgebouwd rond Magenta en LK, ofwel Little Kernel. Magenta is van binnen gebouwd op LK, maar de lagen daarboven zijn nieuw. De ontwikkelaars schrijven daarover: "Magenta heeft het concept van een proces maar LK niet. Een Magenta-proces is opgebouwd uit LK-level constructs zoals threads en geheugen.

Wat verder precies het doel met het systeem is, is nog niet duidelijk. Zo is het niet bekend of Google hiermee daadwerkelijk een compleet nieuw besturingssysteem wil ontwikkelen dat het bedrijf gaat inzetten of uitbrengen. Als taal wordt Dart gebruikt, een taal die het bedrijf enkele jaren geleden ontwikkelde en het framework betreft Mojo.

De gebruikte licenties zijn Apache 2.0 en MIT. Deze licenties maken het makkelijker voor ontwikkelaars om closedsourceproducten voor het OS te maken, iets wat met GNU Public License moeilijker is.

Reacties (140)

[8-Ball]

Op HackerNews wordt gesuggereerd dat het OS voor VR ontwikkeld wordt, speciaal voor de lage latency van GUI pipe line.

I'm calling it now: this is for augmented reality displays and similar. You want an RTOS for loss and predictable latency. And current GUIs aren't really suited to 3D environments you can walk around inside.
This is Google's next Android, with a low latency rendering pipeline for the next generation of mobile devices.

[Reactie gewijzigd door 8-Ball op 23 juli 2024 14:17]

[Snikker]

Ik heb dit gevonden in de code:

LK is a Kernel designed for small systems typically used in embedded applications. It is good alternative to commercial offerings like FreeRTOS or ThreadX. Such systems often have a very limited amount of ram, a fixed set of peripherals and a bounded set of tasks.

On the other hand, Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation.

Magenta inner constructs are based on LK but the layers above are new. For example, Magenta has the concept of a process but LK does not. However, a Magenta process is made of by LK-level constructs such as threads and memory.

[Anoniem: 174991]

Kun je de link erbij zetten? Daar worden vaak zinnige dingen gezegd. Is het inderdaad een RTOS (Real Time Operating System)? Dat zou nuttig kunnen zijn voor VR, maar ook voor Internet of Things / geintegreerd OS. Dat mijn gok althans zijn.

[8-Ball]

Meer dan dit wordt er niet over gezegd, maar ik vond het een interessante blik op het nieuws bericht.

Hier volledige HN link:
https://news.ycombinator.com/item?id=12271354

+ comment link:
https://news.ycombinator.com/item?id=12273149

[Anoniem: 636203]

Waarom zou Linux met CONFIG PREEMPT RT niet werken hier?

[SV_25]

Misschien is het eerder een concept/research os dan iets dat wel degelijk een nieuw product moet vormen?
Microsoft heeft (had) dat ook met Midori
https://en.wikipedia.org/wiki/Midori_(operating_system)

EDIT: Een blogpost van iemand die er aan gewerkt heeft: http://joeduffyblog.com/2015/11/03/blogging-about-midori/

[Reactie gewijzigd door SV_25 op 23 juli 2024 14:17]

[Anoniem: 636203]

Midori was in C# geschreven. Ik vind het toch teleurstellend dat besturingssystemen toch nog altijd in C worden geschreven. Waarom niet C++? Dat zou het aantal beveiligingsfouten drastisch doen verminderen doordat veel geheugenmanagement door STL wordt gedaan.

Binnenkort wordt het ook mogelijk om een besturingssysteem in C# te schrijven.

[Reactie gewijzigd door Anoniem: 636203 op 23 juli 2024 14:17]

[koelpasta]

Ik denk dat er in kernels vanwege snelheid dingen met code worden gedaan die helemaal niet kunnen in puur C++.. Vandaar dat C wordt gebruikt, dat is bijna assembly als je het hardcore aanpakt. Magoed, je krijgt daarmee inderdaad een grotere kans op fouten etc.

[Anoniem: 636203]

C++ code is misschien 10 -15% langzamer dan C code en de veel betere beveiliging is het meer dan waard. Ook kan software veel meer gebruik maken van object georiënteerde technieken waardoor deze kleiner en flexibeler wordt.

[koelpasta]

Ach, voor een kernel is OO niet zo heel belangrijk. 't Is denk ik niet zo dat je allerlei libraries in je kernel gaat hangen zonder dat je die van binnen en buiten kent. En dan is de modulariteit die OO biedt niet zo boeiend denk ik. Je wilt bijvoorbeeld ook niet vastzitten aan de interface eisen die dit soort flexibiliteit met zich meebrengt.
Magoed, het zijn allemaal overwegingen.
BTW, jij zegt dat de code in C++ kleiner wordt, maar dat is maar schijn. In werkelijkheid ben je dan afhankelijk van externe libraries etc en dat betekent in de praktijk dus eigenlijk juist bloat.
Zo kun je een heel klein en lief kerneltje in java schrijven, maar zonder de java vm en libraries ben je nog nergens en verplaats je het probleem eigenlijk ergens anders heen (je moet dan vertrouwen op de omgeving en dat is in een kernel mischien niet de beste weg).
En qua herbruikbare datastructuren etc, dat kan C ook allemaal. Dus wat dat betreft blijft er weinig over van die OO technieken.

[Accretion]

Met C++ kun je "for all practical purposes" hetzelfde (en meer) dan met C.

Ja, C++ heeft een aantal dingen die minder efficiënt (kunnen) zijn.

C en C++ worden beide gecompileerd naar machinetaal, als je als programmeur niets bijzonders doet, zal de compiler voor beide programma's hetzelfde uitspugen, wellicht bij C++ iets wat sneller is omdat je extra nuance kan toevoegen.

Een class heeft in principe geen runtime overhead, het helpt je echter wel om te structureren en een aantal trucjes toe te passen (al ben je niet daartoe verplicht).

Mensen die zeggen dat je beter C kunt gebruiken, zijn hetzelfde als mensen die zeggen dat je beter assembly kunt gebruiken.
Je kunt ook C++ programmeren, en assembly laten genereren en dat checken
Het is in theorie waar, maar een goede C++ programmeur wint het van een slechte C programmeur.
En tussen een goede C en goede C++ programmeur zou geen verschil hoeven zitten...

C++ heeft gewoon een aantal extra's die je niet hoeft te gebruiken, maar het kan zeker handig zijn.

[koelpasta]

Met C++ kun je "for all practical purposes" hetzelfde (en meer) dan met C.

Nou, nee dus.

C en C++ worden beide gecompileerd naar machinetaal,

Ja, je kunt elke taal wel compileren naar machinetaal. Maar dat maakt die talen nog niet equivalent.

Mensen die zeggen dat je beter C kunt gebruiken, zijn hetzelfde als mensen die zeggen dat je beter assembly kunt gebruiken.

Ja, omdat assembly en c vrijwel hetzelfde zijn. In c kun je vrij goed voorspellen welke assembly er uit gaat rollen.

Je kunt ook C++ programmeren, en assembly laten genereren en dat checken

Maar je kan niet van tevoren makkelijk voorspellen welke assembly dat gaat worden.

C++ heeft gewoon een aantal extra's die je niet hoeft te gebruiken, maar het kan zeker handig zijn.

Als je die extra's niet gebruikt dan programmeer je dus niet in c++ maar probeer je c te doen ofzo. Punt is dat de meeste c++ compilers ook c slikken.

Anders schrijf je even een mailtje naar Linus Torvalds en vertel je hem dat ze dom zijn omdat ze C en assembly gebruiken voor de linux kernel en dat ze over moeten naar C++.

[Accretion]

Linus heeft een sterke aversie tegenover C++, amper op feiten gebaseerd.

Bjarne Stroustroup is een betere bron van zinnige informatie.

Wat kun je dan met C++ niet, wat in C wel kan (en nut heeft).
C++ compilers kunnen inderdaad prima C, op veel momenten merk je dat je voordeel kunt halen uit C++, wanneer dat niet zo is, kun je nog steeds terugvallen op assembly of C.

[koelpasta]

C++ compilers kunnen inderdaad prima C, op veel momenten merk je dat je voordeel kunt halen uit C++, wanneer dat niet zo is, kun je nog steeds terugvallen op assembly of C.

Ja, maar goed, dat druist volledig in tegen het OO paradigma. En het feit dat de meeste C++ compilers gebouwt zijn om ook C en zelfs asm te slikken spreekt eigenlijk al boekdelen.

[Mithrildor]

Het is waarschijnlijk een OS voor Virtual Reality/Augmented Reality.

De kern van de kernel is Little Kernel, een kernel die voornamelijk bedoelt is voor embedded apparaten. Google heeft eerder al aangeven dat ze flink aan Android hebben geschaafd om de latency omlaag te krijgen, maar dat het nog steeds niet laag genoeg is. Een Realtime OS (zoals Fuchsia) heeft nauwelijks latency.

Het is ook vreemd dat Fuchsia Escher, een op een OpenGL gebaseerde realtime physically based renderer, bevat. Waarschijnlijk is dit bedoeld om de 3D GUI te renderen, waarom zou een OS anders by-default een 3D renderer bevatten?

[Anoniem: 636203]

Ik vraag me af of er wel behoefte is aan een nieuwe, kleinere kernel. Veel ARM processors zijn nu zo krachtig en goedkoop dat ze een volledige Linux kernel kunnen draaien. En (RAM) geheugen is ook geen issue meer tegenwoordig, flash al helemaal niet.

Het is indrukwekkend dat de LK maar 20KB inneemt maar waarom draait het dan niet op 8-bitters zoals AVR? Gebruikt het teveel RAM? Als ik ARM gebruik dan draai ik liever een volledige Linuix kernel, want je hebt dan enorm veel hardware- en software support.

[Reactie gewijzigd door Anoniem: 636203 op 23 juli 2024 14:17]

[Anoniem: 382732]

Leuk als men zich zo focust op 1 aspect maar uiteindelijk wil je toch een OS dat alles combineert? Lage latency is leuk, maar als het niet alle functies die bijvoorbeeld Facebook gebruikt niet biedt is het vrij nutteloos.

[parryfiend]

Potentiele opvolger van Android?
Wellicht met een beter geintegreerd update systeem....

[Gopher]

Android is Open source (Achtig). Dit betekend dat andere partijen het mogen gebruiken. Dan valt het buiten controle van google en dat is ook de reden dat je geen updates ontvangt.

Waarom blijven mensen dit roepen, neem een nexus en je krijgt gewoon je updates, waar je om vraagt is gewoon Stock Android.

[Blokker_1999]

Android zoals op de Nexus is geen volledige FOSS versie van Android. AOSP is de open source versie maar is een enorm kale distributie die door Google de afgelopen jaren verder gestript is van functionaliteit. Zo heeft Google ondertussen ook belangrijke onderdelen zoals de standaard telefoon dialer uit AOSP gehaald en in het gesloten deel ondergebracht.

Elke fabrikant die gebruik wenst te maken van die standaard mogelijkheden of bijv. van de Play Store moet van Google een hele waslijst aan verplichte Google Apps meeleveren.

Bijkomend is er geen enkele reden waarom het AOSP gedeelte van Android niet gewoon door Google/OHA kan worden bijgewerkt. Zowat elke linux distributie is modulair opgebouwd waarbij je alles onafhankelijk van elkaar kan updaten. Toch heeft Google ervoor gekozen om geen enkel centraal update systeem in te bouwen in Android maar alles via een lange, moeizame weg te laten gaan.

[Gopher]

In zoverre heb ik mij daar niet in verdiept, maar meestal is zo iets dergelijks niet zo gemakkelijk te realiseren mogelijk wel plausibel uiteraard. Dat neemt verder niet weg dat de reden van niet updaten nog steeds komt doordat de fabrikanten het niet meer updaten.

[Anoniem: 145867]

Dialer hoort ook niet bij Android vind ik persoonlijk. Je hebt toch ook geen Dialer op Windows 10 desktop.

Dialer is gewoon een applicatie. En elke OEM fabrikant bouwt zijn eigen dialer. Je moet het gewoon zien als een Applicatie dus ik vind de dialer een heel slecht voorbeeld.

Wat ik erger vind is dat veel applicaties afhankelijk zijn van Google Play services. Dat is toch een stuk erger als een domme dialer wat gewoon een applicatie is zoals kladblok op Windows. Een dialer maakt je niet afhankelijk van Google.

[Reactie gewijzigd door Anoniem: 145867 op 23 juli 2024 14:17]

[Jhinta]

je haalt een paar dingen door elkaar ,,
android zelf is 100% open srouce ,, dat Google hun eigen dailer gebruikt staat daar dus los van. jij maakt een verband met Android standaard framework en Google frame-work , 2 verschilende dingen .

Google framework is gesloten punt , daar valt onder de gehele framework dus ook dailer ook agenda etc etc.( als je een asop installeert kun je zelf er voor kiezen om de Google variant te instaleren wat dus niet het zelfde is als de asop !)
ook geef je aan dat ze de dailer uit de asop gehaald hebben wat totaal incorrect is -> ze hebben een eigen dailer gemaakt en jij heb nog de gelegenheid om de asop en source in te zien van de ASOP !! en dus niet van de Google framework!!

Android heeft een eigen dailer en agenda etc etc , 100% open source, en betreft updaten van bv een dailer., wat houd je tegen? want zoals je aan geeft wacht jij op Google, waarom eigenlijk? ik weet dat ik daar niet op hoe te wachten -> we kunnen er blij mee zijn als ze het updaten maar niet dat ze dat verplicht zijn. Los daar van wat wil je er aan updaten ? -> sneller bellen ofzo ?

en mensen hou is op met Google Framework met ASOP te mengen!
Men begrijpt totaal niet hoe het in elkaar zit, je kunt niets eisen van een gesloten werk is niet van ons we kunnen het enkel gebruiken als we het willen, en zij bepalen hoe en wat (over hun eigen software)

[Reactie gewijzigd door Jhinta op 23 juli 2024 14:17]

[Anoniem: 604167]

Het is ook niet dat mensen de source code van de Google apps in willen zien, al zou ik er natuurlijk geen nee tegen zeggen. Waar ik en denk anderen ook met mij tegen aan boksen is dat Google zegt dat Android open source is. Wat Google echter doet is steeds meer eigen closed source apps maken en de open source versies niet meer updaten, bijvoorbeeld search, muziek, etc. Het zijn apps die veelal nog in tijdperk Android 2.x hangen.

Een tweede is dat Google apps afhankeijk maakt van Google Play Services. "Vroeger" deden ze hun eigen zaken via jar bestanden aan app ontwikkelaars geven. Via Play Services zorgen ze echter dat apps voor Googles Android geschreven worden en niet voor een open Android dat iedereen kan maken,
Iets als locatie in Google Play Services hadden ze als vervanger voor systeem onderdelen aan fabrikanten kunnen uitreiken, maar hier kozen ze ook weer voor een eigen implementatie die niks met AOSP heeft te maken.

Google wil apps voor het eigen systeem, niet voor een open Android systeem.

[raro007]

Bijkomend is er geen enkele reden waarom het AOSP gedeelte van Android niet gewoon door Google/OHA kan worden bijgewerkt. Zowat elke linux distributie is modulair opgebouwd waarbij je alles onafhankelijk van elkaar kan updaten. Toch heeft Google ervoor gekozen om geen enkel centraal update systeem in te bouwen in Android maar alles via een lange, moeizame weg te laten gaan.

Dus als we Ubuntu pakken met een kernel die door canonical gemaakt woord en Samsung doet zijn aanpassingen aan die kernel is er geen probleem bij de volgende kernel updaten aan de zijde van canonical?
Dat is wat jij nu zegt maar de waarheid is anders.

[latka]

Correct als de apis gelijk blijven.

[Anoniem: 636203]

Google heeft opzettelijk carriers en OEM's de mogelijkheid gegeven om Android aan te passen om marktaandeel te winnen. Incompatibiliteit en slechte updates zijn de prijs die ze daarvoor moeten betalen.

[Nees]

Het zegt meer over de producent van de telefoons dan over Google. Google brengt namelijk updates uit en ze betalen dus geen "prijs".

[batjes]

Nee, dat de OEMs waardeloos met hun software omgaan, was al redelijk wat jaartjes bekend voordat Google met Android op de proppen kwam.

Google heeft verantwoordelijkheid bij de OEMs gelegd, de uitkomst van zo'n verdeelde Android markt waarbij een hele hoop mensen met geoutdate meuk rondwandelen was 100% voorspelbaar.

Er is een reden dat de grote Linux distro's en Windows op een bepaalde manier werken en hun meuk up to date houden.

Het zegt meer over Google dan over de OEMs.

[Grrrrrene]

Nee, dat de OEMs waardeloos met hun software omgaan, was al redelijk wat jaartjes bekend voordat Google met Android op de proppen kwam.

Want voor Google met Android kwam, waren mensen erg bezig met hoe snel hun telefoon updates kreeg? Voor Android waren er nauwelijks smartphones, behalve met Windows Mobile, BB OS en PalmOS. Ik heb alleen telefoons met WM gehad en een PDA (jaja) met PalmOS erop. Beide hebben nooit een update gekregen.

Google heeft verantwoordelijkheid bij de OEMs gelegd, de uitkomst van zo'n verdeelde Android markt waarbij een hele hoop mensen met geoutdate meuk rondwandelen was 100% voorspelbaar.

Je maakt je heel druk om iets waar bijna niemand zich druk om maakt, blijkbaar. Samsung is met afstand de grootste telefoonfabrikant en staat bekend als een fabrikant die nauwelijks updates uitbrengt. Als het geen gevolgen heeft voor Samsung, waarom zouden ze dan ineens meer updates uitbrengen? Voor de duidelijkheid: ik vind dat het beter moet, vanwege de beveiliging van je telefoon, maar ik ben ook een tevreden Nexus-gebruiker en zal dat met het huidige updatebeleid van de fabrikanten ook wel even blijven denk ik

Het zegt meer over Google dan over de OEMs.

Dat is gewoon een anti-Google uitspraak. Het staat de OEM's vrij om de updates die Google uitbrengt over te nemen, maar dat willen ze niet. Als het allemaal aan Google zou liggen, zou er geen verschil tussen fabrikanten zitten. En dat is toch echt niet het geval, sterker nog: sommigen doen het heel netjes, anderen maken er een potje van en updaten alleen topmodellen van 600+ euro

[Anoniem: 636203]

Omdat men tot nu toe geluk heeft gehad. Als er een worm op de markt komt die via StageFright of zo tientallen of honderden miljoenen telefoons 'bricked' dan zie ik wel dat er consequenties komen voor Android.

[Grrrrrene]

Nee hoor, dan komen er consequenties voor Samsung. Met Android is er nml helemaal niks mis, dat wordt prima onderhouden getuige de Nexus-lijn. Consumenten kopen ook helemaal geen Android-telefoon, maar een Samsung, HTC of Sony.

[Anoniem: 636203]

Veel consumenten begrijpen niet dat er misschien een patch is maar dat Samsung die niet uitgerold heeft. Men weet alleen maar dat men een Android besturingssysteem heeft en zal dus de schuld bij Google neerleggen.

[epdm2be]

Eigenaardig genoeg ben ik nog nooit een "bricked" telefoon van die zogezegd honderden miljoenen tegengekomen. Veel poeha om de een of andere hacker zijn 15 minuten roem te gunnen.

Zoals reeds is gezegd. Hier wordt een drama gemaakt over iets waar weinig mensen last of interesse van hebben. Zeker als toch al die aps werken vanaf 4.x.x

[Anoniem: 636203]

Omdat hackers op dit moment meer gefocussed zijn op geld verdienen en niet zozeer om telefoons onbruikbaar te maken. Maar technisch is dit natuurlijk heel goed mogelijk. Als een baldadige tiener dit wel besluit te doen dan is er een groot probleem.

[Grrrrrene]

Dan nog zijn al die oude telefoons aangesloten bij de Play Store van Google waar sowieso al gecontroleerd wordt op malafide software. Die onwetende mensen hebben een app van hun bank (die al strenge eisen stelt aan al dan niet rooten en de versie van je OS) en misschien eens Whatsapp en wat spelletjes. Die halen echt niks buiten de Play Store om binnen.

Zoals reeds enkele keren gezegd: storm in een glas water

[Anoniem: 382732]

Google had gewoon een fatsoenlijk upradebeleid in de licentievoorwaarden kunnen opnemen. En dat hebben ze (bewust of onbewust) niet gedaan.

[Anoniem: 636203]

Waarschijnlijk omdat carriers en OEM's daar sterk op tegen zijn en Google ook niet wil dat zij een ander besturingssysteem zoals Windows 10 Mobile gaan 'pushen.'

[parryfiend]

Je hebt 2 versies van Android; Google android en AOSP android.
Alleen het laatste is open source!

Voor Google is het nalatige update beleid van fabrikanten wel degelijk een probleem omdat het Play ecosysteem er vanaf hangt. Mensen zijn alleen bereid te shoppen op Android indien het OS veilig is; zoniet dan bestaat het gevaar dat het Android ecosysteem dat Google met zoveel moeite heeft opgebouwd instort als een kaartenhuis door een opstapeling van beveiligingslekken.
Bij fabrikanten in de low/mid end is er gewoon weinig animo om een updatebeleid op te zetten omdat ze toch niets kunnen terugverdienen op al verkochte hw.

Google heeft verreweg het meeste belang bij een veilig android ecosysteem en een stabiel update beleid; zij slepen al het geld binnen met de Playstore, gapps.en het advertentie netwerk. Punt is, ze kunnen geen patchbeleid afdwingen bij hun hw partners of ze zijn gewoonweg niet bereid ertoe. Waarschijnlijk omdat fabrikanten met goedkope handsets wellicht in de knel komen met omzet marges. Bovendien verkopen de hardwareboeren je liever een nieuwe device elke 2 jaar ipv een degelijk update beleid op te zetten.

Verandering zal dus niet snel komen van hw makers.
Google zal degene moeten zijn die het initiatief neemt als ze een robuust update systeem willen. Wellicht het OS meer inrichten als desktop Linux waarbij updates centraal geregeld zijn. Contractueel mogen fabrikanten dan alleen een aparte schil voor skins modden maar verder zo min mogelijk? Met deze stap zou het updatebeleid weggehaald worden bij de hw fabrikanten en verplaatst naar google, de plek waar het wellicht thuis hoort.

AOSP kan blijven bestaan maar dat is dan weer niet google's verantwoordelijkheid. Wie wil forken mag dat doen maar moet zelf een updatebeleid opzetten. Wat dat betreft verandert er niet zo veel bij custom roms.

[Reactie gewijzigd door parryfiend op 23 juli 2024 14:17]

[joco]

de enige mensen die ik rond om me ken die zitten te zeuren over updates en veiligheid zijn de tweakers
rond om mij, zoals mijn vriendin, mijn pa en ma, eigenlijk gewoon iedereen die niet direct echt onderlegd is aan de IT maakt het geen snars uit. Als hun telefoon maar doet hun apps maar blijven doen.

[mhnl1979]

Maar dat betekent natuurlijk niet dat ze een veilige telefoon hebben als ze op android 2.2 draaien. Ze zien alleen de gevolgen niet als het fout gaat.

[epdm2be]

".. Mensen zijn alleen bereid te shoppen op Android indien het OS veilig is;..."

En waar haal jij die wijsheid?

De meeste hebben geen benul van "veiligheid" op hun smartphone. De meeste gebruiken amper de helft van de mogelijkheden. En heb je echt de bleeding edge nodig om alleen maar te bellen en te SMS-en?

[parryfiend]

Geen wijsheid maar simpele deductie. Leken zijn zich heerlijk onbewust van de veiligheid op hun systemen; totdat het goed foutgaat. Dan laten ze google net zo hard vallen als Nokia en Blackberry indertijd (herinner je je die nog?) voor de "next big thing".

Zaak voor google om preventief te handelen met projecten als fuchsia. Niet zozeer omdat ze zo van de consument houden maar omdat ze hun ecosysteem en verdienmodel moeten beschermen en voorbereid willen zijn op de toekomst.

[Reactie gewijzigd door parryfiend op 23 juli 2024 14:17]

[SuperDre]

Ook bij de Nexus toestellen stopt na een paar jaar de updates, ondanks dat ze nog geschikt zouden zijn om nieuwere updates te ontvangen...

[Anoniem: 126717]

Waar ze de volledige baas over zijn! Dus niet zoals nu dat fabrikanten en telecommaatschappijen er ook nog invloed op kunnen uitoefenen.

[84hannes]

Android is gebasseerd op Linux. Linux heeft een prima functionerend updatesysteem.

edit:
Dat zeg ik verkeerd. Het moet zijn: voor de Linux kernel en de GNU omgeving die samen het OS GNU/Linux vormen, zijn prima updatesystemen verkrijgbaar

Het zijn de lagen die Google er zelf bovenop heeft ontwikkelt, allerlei bibliotheken, gui's, dalvik spul, drivers, die het updaten zou ingewikkeld lijken te maken.
Dat gezegd hebbende: hoe goed Linux ook is, het is natuurlijk vreemd dat er feitelijk maar één besturingssysteem voor telefoons, set-up boxen, autonavigatie en servers is. De niche markt die Windows en macOS bedienen daargelaten. Daarom vind ik een beetje concurrentie geen kwaad kunnen, en er zijn dan ook genoeg alternatieven, maar geen eentje weet echt momentum op te bouwen. Steun van een technologiegigant kan dan wel helpen, en vanaf het begin open (source) zijn lijkt me ook een must.

[Reactie gewijzigd door 84hannes op 23 juli 2024 14:17]

[bbob]

Steun van een technologiegigant kan dan wel helpen, en vanaf het begin open (source) zijn lijkt me ook een must.

Lees laatste stukje van het artikel:

De gebruikte licenties zijn Apache 2.0 en MIT. Deze licenties maken het makkelijker voor ontwikkelaars om closedsourceproducten voor het OS te maken, iets wat met GNU Public License moeilijker is.

Lijkt me dus duidelijk dat google niet richting open source gaat maar eerder richting closed source zoals MS en Apple.
Of we daar nu blij van moeten worden, ik denk het niet. Google doet zich leuk voor als open source aanhanger maar het gaat bij google gewoon om geld verdienen en schijnbaar zijn ze tot de conclusie gekomen dat dat met closed source meer mogelijkheden heeft.

[CH4OS]

Dat betekend dat het makkelijker voor 3rd parties is om closed software te maken voor het OS. Niet over het OS zelf, lijkt me.

En natuurlijk is Google een bedrijf en geen liefdadigheidsinstelling, natuurlijk is het Google dan (primair zelfs) te doen om geld verdienen.

[Reactie gewijzigd door CH4OS op 23 juli 2024 14:17]

[kidde]

Wel voor toekomstige versies: Ze kunnen van hun open source OS "A" zelf een 'closed source' fork "B" maken. "B" wordt verder ontwikkeld en krijgt updates en "A" laten ze doodbloeden. Bij GPLv3 kan dat (bijna?) niet.

Vervang "A" door AOSP anno 2014 en "B" door Android+Google Play / Framework services anno 2016 en je ziet dat het een beproefd recept is: AOSP is open maar sinds 2014 zo dood als een pier. Maw, het is bij Google open zolang ze hulp van de gemeenschap nodig hebben, en goede sier en reclame moeten maken om zieltjes te winnen. Zodra de zieltjes ten prooi zijn gevallen aan vendor lock-in en er geld verdiend kan worden schieten ze in closed source mode.

[T-men]

Google doet zich leuk voor als open source aanhanger maar het gaat bij google gewoon om geld verdienen en schijnbaar zijn ze tot de conclusie gekomen dat dat met closed source meer mogelijkheden heeft.

Wow.... over "Jumping to conclusions" gesproken.

Tot op heden is er niet meer gebeurt dan dan dat er wat code op GIT is gecommit. Waar het toe dient of hoe het gebruikt wordt, dat is nog totaal onbekend.

Dat het Android zou gaan vervangen en dat het dan helemaal closed source zou zijn is op dit moment niet meer dan pure speculatie !

Google is een commercieel bedrijf. Een commercieel bedrijf wil (moet !) winst maken. Commerciële bedrijven zijn er legio. De kans dat jij er zelf ook voor zo eentje werkt is groot.

Wat is daar vreemd, fout of bijzonder aan ?

[Anoniem: 145867]

Misschien wordt het wel een OS voor hun server park?

[Viince1]

Daar lijkt het nu op, maar is het mogelijk dat google de ontwikkeling closed-source doet en bij uitbrengen van het OS (weer) overstapt naar een andere licentie?

[MBV]

Welk updatesysteem dan? Yum of apt-get?

[84hannes]

Maakt me niet uit, beide zijn met afstand beter dan de alternatieven voor andere besturingssystemen.

[sfranken]

dnf of apt-get (alhoewel, eigelijk apt, want apt-get is een frontend) dan he

[Nazlive]

Android is begonnen als 'OS' voor camera's. In de basis is het dus niet opgestart voor telefoons,

Zou mooi zijn als het opnieuw wordt opgebouwd, en goede support wordt geboden wat betreft updates.

[Anoniem: 669957]

Zou ik je bron daarvan mogen als je die nog hebt ?

Lijkt me interessant leesvoer.

[Nazlive]

https://en.wikipedia.org/wiki/Android_(operating_system) op de nederlandstalige wiki staat ook wat, maar wat minder uitgebreid.

[Anoniem: 669957]

Thanks !

[SED]

Linux heeft een prima functionerend updatesysteem.

Linux heeft geheel geen update systeem. Er zijn binnen GNU wel onderdelen gemaakt die deze functionaliteit als Package manager kunnen bieden. Apt-get of Yum bijv.
Linux is alleen een kernel. GNU linux is een verzameling van bijv package manager en de kernel.( en andere zinvolle GUI software zoals KDE, Gnome etc om het tot een bruibaar geheel te maken.)

https://en.wikipedia.org/wiki/GNU/Linux_naming_controversy

[blorf]

Eigenlijk is dat hele updaten en 'uitrollen' naar mijn idee moeilijk gedoe en uit de tijd. Het is het nastreven van het idee dat het OS een groot bouwwerk is waarbinnen alles met elkaar is verweven.
Bij een modulair ingericht OS zoals *nix vervang je inderdaad de kernel,een of meerdere binaries of andere onderdelen. Of je geeft een opdracht waarmee alles automatisch gecheckt wordt en eventueel vervangen met nieuwe versies.
De scenario's waarin het hele OS op zijn bek gaat door een foute uitgerolde systeemupdate of door misbruik van een weken lang openstaand lek waarvoor de patch met een major update mee moet komen zijn eigenlijk compleet belachelijk. Zo moeilijk is het in het echt allemaal niet, het wordt zo gemaakt.

[Reactie gewijzigd door blorf op 23 juli 2024 14:17]

[SED]

Alls gangbare OS sen zijn modulair opgebouwd.
Wekenlange of zoals recent bij linux jarenlang openstaande gaten in onderdelen zullen nooit te voorkomen zijn.

[Jhinta]

android is gebaseerd op java -> davlik (tegenwoordig art) , en java/art draaid op linux dus Android draaid niet op linux om correct te zijn.

nou is het wel zo dat art versie het omzet naar native, maar meer als native macihne code en niet zo zeer linux

je kan bijwijze van ,, een nt kernel maken als je de source hebt , en art aan de gang krijgen en android draaien , wat is er dan linux aan ?

[Reactie gewijzigd door Jhinta op 23 juli 2024 14:17]

[epdm2be]

Die waren er ooit eens:

Sailfish OS
Ubuntu for phones
Bada
Tizen
Firefox OS

[84hannes]

Zonder uitzondering dezelfde kernel met daarop andere (80% dezelfde) bibliotheken voor i/o, gui etc.

[CH4OS]

Zolang fabrikanten zelf ook uodates kunnen bijdragen, voor hun apparaten specifiek.

Ben benieuwd wat hier uit de hoed getoverd gaat worden uiteindelijk! Naast Windows zou een hybride os dat op een scala aan soorten apparaten werkt mooi zijn (want concurrentie en zo). Al vrees ik ook voor een verdere integratie van de Google Apps...

[Reactie gewijzigd door CH4OS op 23 juli 2024 14:17]

[Gopher]

En waar gaan ze die dan op installeren op hun eigen telefoons! Ofwel de nexus reeks, ofwel ongewijzigde android toestellen welke gewoon updates ontvangen.

[blorf]

Als je het mij vraagt durfden ze dat altijd al nauwelijks bij Android. Een beetje ARM-computer draait alle ARM-compatibele besturingssystemen. Alleen niet als het "Android-hardware" is. Daarop beperkt het ARM platform zich tot enkel Android en kan de eigenaar geen admin meer zjin. Heel logisch...

[gjmi]

Je kunt android heel goed updaten, alleen willen fabrikanten hun eigen sausje over Android gooien en vervolgens steken ze geen geld in het up to date houden.
Heeft niets met Android an sich te maken, maar de manier waar er mee omgegaan word. Dat vang je alleen af door aanpassingen te verbieden. Dat zou mischien kunnen met de licenties die ze nu gebruiken misschien te voorkomen zijn.

[Loller1]

Zolang de radiostack, hetgeen waar ISPs controle over hebben, aan het OS blijft gebonden en zolang OEMs de vrijheid krijgen om aanpassing te doen aan het OS zelf (ipv bovenop het OS), valt dat niet zo op te lossen.

[SuperDre]

Elke nieuwere versie van Android heeft wel weer strengere regels waar men aan moet voldoen om oa de naam Android te mogen blijven gebruiken.

[Kliko]

Zouden ze een ecosysteem willen maken net zoals ze bij Linux proberen?
Dus een telefoon in sync met een pc. Of zelfs je telefoon aansluiten op een scherm, tobo en muis?

Dat zou best vet zijn.
Beetje een interface zoals windows 10 en byebye windows! Altijd je PC bij je hebben!

[Nazlive]

Merkwaardig hoe je aankaart dat het vet zou zijn als het een interface zou hebben zoals Windows 10, en dat het kan draaien op alle devices, zodat je altijd je 'pc' bij je hebt, om in dezelfde zin te zeggen 'bye bye windows!' Terwijl dat het zo'n beetje het enigste OS is wat dat enigzins aanbied.

[Ge0force]

"Terwijl dat het zo'n beetje het enigste OS is wat dat enigzins aanbied."

Klopt, daarom zou concurrentie van Google een goeie zaak zijn. Veel mensen "tolereren" Windows omdat er geen deftig alternatief is. Of een OS van Google al dan niet een deftig alternatief is laat ik voorlopig in het midden.

[StefanJanssen]

Veel mensen accepteren google omdat er geen beter alternatief is xD

[Ge0force]

Voor zover ik weet bestaan er toch wel degelijke alternatieven voor de meeste producten van Google. Als pc gamer is er echter geen degelijk alternatief voor Windows als OS. Dat alternatief zou er wel kunnen komen als het OS van Google een succes wordt. Ik gebruik reeds verschillende diensten van Google (Gmail, Drive, Android etc) dus ik zou er geen probleem mee hebben om over te stappen.

[StefanJanssen]

De enige reden dat ik nog google gebruik is omdat er geen alternatief voor youtube is en ik nog geen goed alternatief voor de DNS heb kunnen vinden.
Ik heb voldoende apps op windows phone, maar voor velen is het toch een puntje waarom ze niet overstappen. Ze ergeren aan android (mede door de vele bloatware die google meeleverd) en iOS is buiten de pricerange.

[Reactie gewijzigd door StefanJanssen op 23 juli 2024 14:17]

[Audiodude]

OpenDNS, tegenwoordig van Cisco, is naar mijn mening een goed alternatief (niet voor 'grotere' bedrijven dan eenmanszaakjes, te kostbaar). Geeft meteen de mogelijkheid om filtering toe te kunnen passen.

Heb het thuis en bij al mijn familie die nog (kleine) kinderen heeft ingesteld. Beste beslissing ooit.

[Reactie gewijzigd door Audiodude op 23 juli 2024 14:17]

[Bunga]

Dat was precies ook mijn gedacht. Ik moest meteen aan canonical denken. Sites worden al via responsive design geschikt gemaakt. Nu moeten de toestellen ook nog volgen. Op het werk toekomen en smartphone met het scherm laten verbinden en hopla desktopomgeving. Even naar de meeting, connecteren met beamer of scherm en je kan beginnen. Zou knap zijn voor bedrijven om enkel maar smartphone en scherm te moeten voorzien. Al je apps en documenten in de cloud (van google natuurlijk ) ... ik zie het ergens wel zitten.

[SED]

Je bedoelt wat Windows 10 nu al heeft.. een account met uniforme bediening en toegang tot al je data op al je apparaten ongeacht of dat een pc, mobiel, tablet of game console is.

[Sugocy]

Wat Microsoft poogt te realiseren dmv Continuum? Ik denk dat dat menig OS dit wil gaan doen. Android app ondersteuning in Win10 en Continuum kan die afhankelijkheid van het mobiele platform proberen te gebruiken. Monopolie nooit goed Linux er ook bij maakt concurrentie!

[loki504]

Dat doet Windows toch al met continuum?

[RoestVrijStaal]

Als taal wordt Dart gebruikt, een taal die het bedrijf enkele jaren geleden ontwikkelde en het framework betreft Mojo.

Ik had eerder Go verwacht, want die is meer low-level dan Dart. Dat zegt wel iets over de performance van het nieuwe OS.

[MBV]

Denk je? Ik denk dat een low-level taal het veel belangrijker maakt dat je goede ontwikkelaars hebt, in een high-level taal heeft dat minder invloed. In principe kan C++ sneller zijn dan Java of C#, maar dat geldt alleen als je goed programmeert. Het is heel makkelijk om in C++ een foutje te maken waardoor het veel meer geheugen en CPU kracht gebruikt.
Ik heb me niet in Dart en Go verdiept, maar dat meer controle beter is voor de performance is heel vaak niet waar. Meer controle maakt het vooral makkelijker om dingen te verprutsen

_{Om reacties voor te zijn: ik begin met 'in principe kan C++ sneller zijn', dus dat hoeft niemand mij te bewijzen}

[Anoniem: 174991]

Dart en Go zijn toch echt voor verschillende domeinen bedoeld en geschikt. De analogie met C++, Java en C# loopt daarmee enigszins spaak. Hoewel deze ook hun onderlinge verschillen kennen.

De verschillen in performance zijn echt significant en op het eerste gezicht is Go een meer geëigende taal voor een OS. Dart is toch echt een client-side scripttaal vergelijkbaar met Javascript. Dat heeft mensen er niet van weerhouden om OS'en in Javascript te schrijven.

In de praktijk zie ik weinig voordeel aan de vervaging van de grens tussen client en server. Iets dat vaak genoemd wordt als voordeel van een Javascript OS als Node. Het hergebruik van code gebeurt in de praktijk niet of nauwelijks en er zijn zelfs voordelen aan een striktere scheiding.

Overigens lijkt de source van Fuchsia toch vooral in C geschreven. Dat is al tientallen jaren de voornaamste taal om een OS in te schrijven. Het voordeel ligt in de performance en mogelijkheden om te fine-tunen. Bovendien zijn de ontwikkelaars over het algemeen van een hoog niveau (iets dat Linus als belangrijk argument geeft).

Zie hier wat random C spul:
https://fuchsia.googlesource.com/escher/+/master

edit, aanvulling:
Als men ergens een noodzaak ziet voor een nieuw OS, dan toch wel het "internet of things". Vaak grijpt men naar Android, maar dit kent genoeg problemen (gebruik Java, maatwerk fabrikanten, erfenis van telefoons, performance). Zou reden genoeg kunnen zijn om een nieuwe start te maken.

Wellicht dat met Dart ziet als taal om de apps in te ontwikkelen. Of wellicht als één van de talen, waarbij veeleisende apps ook in Go ofzo kunnen worden gedaan.

[Reactie gewijzigd door Anoniem: 174991 op 23 juli 2024 14:17]

[SuperDre]

Aan de andere kant denk ik dan ook weer, waarom yet another language terwijl er al meer dan genoeg talen zijn, probleem ligt helemaal niet bij de taal ansich, maar bij de gebruikte compiler.. Meeste nieuwe talen zijn eigenlijk niets meer dan de oude bestaande talen met wat extra nieuwe libraries en functies.. Vaak is het ook omdat de makers de syntax van een andere taal niet fijn vonden, maar voegt de nieuwe taal niets echt nieuws toe wat ook al niet mogelijk wat met de reeds bestaande talen.

[Anoniem: 174991]

De meeste talen die hier voorbij komen en zeker degenen die ik noemde, voegen wel degelijk iets toe. Dart rekent af met enkele tekortkomingen van JS, Go maakt parelle uitvoering makkelijk, compileert als een jekko en is simpel.

Als een taal niets nieuws toevoegt, dan lost dat zichzelf op. Niemand zal het gebruiken. Het is de realiteit dat er verschillende problemen zijn, die verschillende gereedschappen (talen) nodig hebben.

[Anoniem: 145867]

Klopt helemaal. Javascript kan soms ook performance hebben dat dicht in de buurt van C komt... belangrijker dan de taal is de programmeur!!

[NASUM]

Dat is precies wat ik dacht toen ik het las inderdaad. Go is imho een veel efficiëntere taal om lower level spul in te bouwen. Maar aangezien Dart gebaseerd is op Javascript en ook compileert naar Javascript is het wellicht mogelijk dat web-app integratie een grote rol gaat spelen op dit platform. Google maakt al enige tijd bewegingen richting een meer web-stack based apps maar weet dit op Android tot noch to niet echt van de grond te krijgen. Misschien dat een Dart based OS hier diepere integratie zou kunnen bieden en dus de nadelen van een web-based app zou kunnen doen afnemen.

[Anoniem: 145867]

Dart is niet gebaseerd op javascript. Ja je kan het compileren naar Javascript. Maar je verliest wel performance als dat je Dart echt in zijn eigen Dart VM zou draaien. Het zit even anders in elkaar dan je denkt. Dart is geen coffeescript achtig gebeuren. Maar Dart is weer geen Go. Want Go draait niet in een VM.

[Anoniem: 636203]

Impliceert dit dat Android niet geschikt is voor desktops? Lijkt mij onzinnig, je kan volgens mij Android prima aanpassen voor op een desktop.

Wellicht wil men bij de opvolger van Android de code niet meer openbaar maken om 'forks' er van te voorkomen? Lijkt zinnig maar dat zal ook een heleboel mensen afkeren van dit systeem en dus een mogelijkheid creëren voor derde partijen om ook een mobiel besturingssysteem op de markt te brengen.

Lijkt mij een slechte zet van Google als ik gelijk heb, maar ik vermoed dat het nog te vroeg is om hier iets over te zeggen.

[sfranken]

Wellicht wil men bij de opvolger van Android de code niet meer openbaar maken om 'forks' er van te voorkomen?

Waarom zet Google dit dan online en met een vrijere licentie dan Android? Dat is toch tegenstrijdig? Als dit een "hush hush" project zou zijn zie je er, IMO, nooit wat van online tot er een aankondiging is en het OS de "gold" status heeft.

[Anoniem: 636203]

Omdat Google dan de mogelijkheid heeft om code geheim te houden net zoals Apple dit ook doet met FreeBSD. Als het OS een bepaald marktaandeel heeft kan men makkelijker de duimschroeven aandraaien.

[sfranken]

Uh? FreeBSD is zo open als maar zijn kan, wat heeft Apple daarmee te maken? Of bedoel je Darwin (de kernel/low-level laag van macOS)? Ik mag *hopen* dat je dat bedoelde..

Verder: als je iets opensourced is het érg lastig om code geheim te houden, aangezien letterlijk Jan en Alleman je code kan inzien... Dus, nogmaals, waarom een "hush hush" project open source maken? En zeker zo vroeg in de ontwikkeling voordat er ook maar iets van bevestigt is of op de markt is... Dat is letterlijk jezelf in beide voeten tegelijk schieten als Google het echt verborgen wil houden.

[Anoniem: 174991]

De kans dat er nu een OS wordt ontwikkeld dat specifiek desktops target, lijkt me klein. Er liggen grotere vraagstukken en meer groeikansen in andere domeinen.

[SuperDre]

achja, windows, macos, iOS zijn ook allemaal niet openbaar, en toch maken er legio mensen gebruik van.. Ik hoef niet perse een echt compleet opensource OS te hebben, zolang de performance en betrouwbaarheid maar goed is.. Opensource betekend helemaal niet dat het beter is dan closed source..

[Auredium]

Het was al langer een gerucht dat Google na Microsoft en Canonical ook convergence in zijn OS zou willen. De ultieme Darth Vader move is natuurlijk het volgende:

De gebruikte licenties zijn Apache 2.0 en MIT. Deze licenties maken het makkelijker voor ontwikkelaars om closedsourceproducten voor het OS te maken, iets wat met GNU Public License moeilijker is.

Nu was Google natuurlijk altijd al een beetje de Anikin Skywalker aangezien Android niet echt open source was.

Come to the dark side, we have cookies. _{You can choose between trackingcookies and supercookies.}

[MrHankey]

Wel jammer dat niet bekend is wat het doel van dit OS is. Gaat het om AI, IoT, search, holographic GUI? En wil google dan ook een nieuw business model aannemen?

Daar is wel wat voor te zeggen namelijk, mensen die nu nog zonder internet zitten en dus makkelijk een nieuw OS adopteren, zijn niet bepaald hardcore consumenten

[kristofv]

Dit vind ik een "double edged sword"

Langs de ene kant is competitie welkom ( en zelfs goed). En is het begrijpelijk dat Google dit wil doen.

Langs de andere kant is het verdelen van de OS markt in twee grote kampen een potentiële ramp. De gevolgen hiervan kunnen zeer vergaand zijn op wereldvlak.

Dus ja, al bij al moet ik zeggen dat het allicht voor iedereen beter zou zijn dat Google zich zou neerleggen bij Desktop OS = Windows (of linux / osx). Voor servers ligt dat dan weer heel anders.