Google brengt Fuchsia OS uit voor Nest Hub

Google heeft Fuchsia OS uitgebracht voor de Nest Hub uit 2018. In de komende maanden zet de fabrikant apparaten over van het huidige Cast OS naar Fuchsia. Het is het eerste apparaat dat het besturingssysteem krijgt. Aan de interface en functies verandert niets.

Gebruikers in het Preview Program krijgen de update als eerste, zegt Google tegen 9to5Google. Daarna volgt een release onder andere gebruikers. De bedoeling is dat er niets verandert voor gebruikers, met dezelfde interface en dezelfde functies als onder Cast OS mogelijk is. Het is onbekend of de software sneller of juist minder snel werkt na de update.

De release is geen verrassing. Google liet enkele weken geleden een variant van de Nest Hub met Fuchsia keuren bij de Bluetooth SIG. Google heeft Fuchsia vijf jaar in ontwikkeling. Voorheen meldde het bedrijf dat het om een project ging om nieuwe ideeën en technieken voor een besturingssysteem uit te proberen. Het doel is nu om een general-purpose opensource-OS te ontwikkelen dat gericht is op beveiliging, updaten en prestaties. Fuchsia is niet ontwikkeld rond de Linux-kernel, maar op basis van Googles eigen Zircon-kernel.

Reacties (70)

[Tmaster]

Aangezien het een google apparatuur is, hoeveel data wordt er naar google gestuurd?
Als je bijv met pi hole al het uitgaande verkeer richting internet blockt, werkt het dan nog?
Of heb je een google account nodig met cloud/internet verbinding? (even los van het feit dat je app voor bediening wel naar binnen mag om de thermostaat te regelen)

[DNArjen]

Alle Google-Home devices hebben hun eigen vaste DNS (die van google ) in de software staan. De PiHole kan hier helaas niets in betekenen..

[Tranzy]

Tenzij je het, net als ikzelf, hebt geredirect (middels een catch all DNS traffic rule) naar Pi-hole.

https://waal70blog.wordpr...multiple-vlans-and-dnses/

[Reactie gewijzigd door Tranzy op 23 juli 2024 02:59]

[SeBsZ]

Helaas werkt dat ook niet goed, Google gebruikt op steeds meer devices DNS over HTTPS en dat is verschrikkelijk... Of heb je hier wel een oplossing voor?

[Nas T]

Misschien een antwoord wat we niet willen horen, maar: alles wat onze privacy kost boycotten?
Volgens mij weten we allemaal, zelfs degenen die niet zo behendig zijn met digitale apparatuur, dat delen van data vaak niet gewenst is.
Ik blijf hopen op een wet die verbiedt winst te maken met onze gegevens (winst is een prikkel om meer gegevens te verzamelen), maar dat zal er niet in zitten vrees ik. De overheid neemt maar mondjesmaat actie, de autoriteit persoonsgegevens is zwaar onderbetaald, kortom: daar hoeven we de komende jaren niks van te verwachten.
Ik ga de komende maanden/jaren overschakelen, waar ik kan. Signal omdat Facebook uiteindelijk ook teveel data gaat verzamelen, Sailfish omdat Android teveel moeite kost om privacyvriendelijk te zijn en we zo'n rot platform niet meer moeten steunen.
Google heeft er ook een handje van om privacyvriendelijk te lijken met allerlei initiatieven, maar uiteindelijk blijkt daar onder de motorkap toch nog steeds dezelfde intenties te zijn: datahonger.

Prima dat we ons voor de gek blijven houden, maar ik maak mijn eigen keuzes. Hopelijk anderen ook. Liever eergisteren dan morgen.

[Lrrr]

Ik zit de laatste tijd ook te denken hier stappen in te maken. Mag ik vragen wat voor devices jij gebruikt en welke tips je hebt qua privacy? Misschien dat ik daar nog wat inspiratie uit kan putten

[Nas T]

Ik gebruik op het moment een Sony Xperia 10 plus met Sailfish OS (betaalde versie).
Ik gebruik daar wel enkele Android apps op.
Daarnaast heb ik een Android smartphone die ik meer voor werk gebruik. Daar heb ik een ander account op, zo spreid ik informatie en is het minder waardevol voor Google.
Ik maak gebruik van een NAS, daar beheer ik foto's op en deel ik foto's/bestanden. Dat kan op basis van een wachtwoord en tijdsperiode en/of met een gebruikersnaam/wachtwoord.
Ik maak overal gebruik van adblockers, op Android via blokada (zet een lokale VPN server op en filtert daar de rotzooi er uit).
Cookies: altijd zo min mogelijk of via incognitomodus: dan vergaren ze maar data gelinkt aan een profiel die verdwijnt zodra de pagina/browser is gesloten.
Op Windows kun je het vergaren van telemetrische gegevens tegengaan met O&O shutup.
Voor de rest weinig draadloos gebruiken thuis: wat er draadloos niet is, kan niet opgevangen worden.
Geen social media, let op met een out of office melding: ipv "ik ben op vakantie tot x", kun je ook aangeven: "ik ben niet beschikbaar op het werk (eventueel met datum)". Op vakantie zou je een offline camera kunnen gebruiken, schiet je over het algemeen ook nog betere plaatjes en heb je minder kans dat iemand online ziet dat je niet thuis bent.
Ook vanaf 2023 tot minimaal 2029 geen nieuwe Ford (of Lincoln) kopen

[Lrrr]

Thanks! Hoe bevalt Sailfish OS? Heb je daar ook de Google Play Store/Services op?

[Nas T]

Mij bevalt Sailfish OS uitstekend, maar ik heb wel last van een confirmation bias , dus ik weet niet of ik heel objectief ben. Sailfish OS heeft in de betaalde versie de mogelijkheid om Android apps te installeren (.apk), er zijn sommige appstores die je kan installeren van waaruit je direct apps kan installeren. Ik heb bijvoorbeeld Aptoide.
Grootste voordelen van Sailfish zijn:

• root-toegang: staat niet standaard aan, maar is eenvoudig aan te zetten.
• Geen reclame: Sailfish OS zelf plus Sailfish apps hebben geen reclame.
• Privacy: voor zover ik weet, wordt geen (of minimaal) persoonlijke gegevens gebruikt.
• Updates: behalve de allereerste smartphone van Jolla, uit eind 2013, krijgen alle toestellen nog steeds updates.

Sailfish is er ook in een gratis smaak, maar dan heb je geen Android app support. De betaalde versie is €50 (volgens mij ook voor een toestel €30). Geen enkele (Sailfish) app is betaald trouwens. Dat kun je als voordeel zien, maar ook als nadeel: veel ontwikkelaars zouden graag betaald willen worden voor hun werk (en terecht, vind ik).

[Raan7]

Ik snap dat hele punt niet waarom je zo moeilijk doet om dat allemaal op gang te zetten. Als je niks te verbergen hebt, of liever gezegd wat heb je te verbergen!?
Als je zulke dingen onderneemt? Er voor betaald? En dan eindeloze workarounds en limitaties en ergenis, omdat je eigenlijk niet van vandaag de dag bent.

[Hkuit]

Jij zou eens moeten Googlen op 'privacy +niets te verbergen'; die reactie komt namelijk in iedere discussie terug. De voorvechters van privacy kunnen je heel goed uitleggen waarom de werkwijze van Google en anderen een probleem is en waarom het dus de moeite waard kan zijn om dit soort moeite te doen. Ik kan dat niet zo goed en ik ben aan het werk, vandaar dat ik je op het goede spoor wil zetten.

[Lrrr]

Hmm, interessant. Eerst maar eens een keer beginnen met een NAS. Bedankt voor de uitgebreide uitleg iig!

[maurict]

Is het niet mogelijk om de DoH domeinen te blokkeren, bijvoorbeeld met deze blocklist?

[Oon]

Zou je niet op router-niveau het hele IP-adres achter die DNS-servers kunnen blokkeren? Weet niet of dat zo werkt want mijn kennis over DNS is beperkt, maar ook bij HTTPS moet de packet door je router heen naar een IP-adres gestuurd worden lijkt me?

[marcovit]

Ik heb mijn adguard op router niveau gedaan en ik zie de requests van de google hub erin voorbij komen. (ook via DoH)

[SeBsZ]

Hoe bedoel je dat? Adguard op router niveau?

[marcovit]

De DNS van de router naar de instance van je blocker verwijzen, zoals een raspberry pi.

[Tranzy]

@SeBsZ
Goede info... wist ik nog niet.

Wellicht dit?

https://nathancatania.com/posts/pihole-dns-doh/

[Reactie gewijzigd door Tranzy op 23 juli 2024 02:59]

[SeBsZ]

Dit klinkt meer als een manier om de DNS lookups vanuit pi hole via DoH te laten gaan, niet om DoH uit je netwerk te blokkeren of naar je pi hole te laten gaan,

[Tranzy]

Ik heb het niet verder goed bekeken maar zoals ik het lees installeer je een cloudflared deamon die zal luisteren naar DoH requests op poort 5053. Daarna configureer je deze proxy als custom upstream server.

Ik neem aan dat als je de requests ziet in Pi-hole dat je deze dan (ergens) ook kan blocken (op client niveau)?

Maar kan er naast zitten. Heb er verder geen tijd in gestoken om het uit te zoeken.

[akooijman]

Als ik het goed snap kun je DoH niet blokkeren omdat je niet weet dat het DNS is: het ziet er gecodeerd niets anders uit als elke andere http request.

[SeBsZ]

Precies, dat dacht ik ook

[AJediIAm]

Ik heb adguard draaien en zonder verdere configuraties zie ik de DNS requests van m'n google devices. Alles gaat naar google.

[TheFes]

Zonder internet zijn Google Home devices vrij nutteloos.
Vragen aan een Google Home device worden in de cloud verwerkt. Zonder internet kun je het dus niets vragen. Hoogstens wellicht om lokale content naar de casten.
Vrijwel alle integraties voor home appliances werken ook via cloud accounts. Zelfs iets als Home Assistant heeft een instance nodig die via het internet te bereiken is.

[Anoniem: 1532362]

Pi-hole blockt uberhaupt alleen DNS, is dus relatief eenvoudig om er omheen te komen voor Google. Je kunt beter een hardware firewall die echt IPs en netwerken en poorten kan blokkeren in je netwerk plaatsen zoals OPNsense of PFsense

[Reactie gewijzigd door Anoniem: 1532362 op 23 juli 2024 02:59]

[Frame164]

Dat zou op zich helemaal niet belangrijk moeten zijn. Mensen die geen data naar Google willen sturen kopen deze producten sowieso niet. En mensen die het wel kopen vinden het blijkbaar geen probleem. Als Google er maar goed werkende services tegenover stelt.

[akooijman]

Zolang Google zorgvuldig omgaat met de verzamelde gegevens heb ik er niet zo veel problemen mee.
Facebook heeft net wat te vaak al dan niet per ongeluk grote hoeveelheden data gelekt of gewoon verkocht om nog te vertrouwen.
De gerichte advertenties van (via) Google boeien me niet zo veel: de kans dat ik (bijvoorbeeld) nog een tweede set tuinstoelen koop wordt niet groter als ik wekenlang advertenties voor tuinstoelen zie terwijl ik op mijn nieuwe set van een biertje geniet.

[Tk55]

Ik ben heel benieuwd naar de verbetering (of verslechtering). Fuchsia is al lang in ontwikkeling en zou in alle opzichten beter moeten zijn dan huidige Android/Linux.

[MrFax]

Fuchsia zou in theorie sneller moeten zijn omdat het een zogenoemde "microkernel" is. De kernel is dit veel minder gecompliceerd en makkelijker te onderhouden. Ook zou het veiliger moeten zijn omdat minder code = minder lekken.

Maar de praktijk moeten we nog maar ff zien

[arithcoder]

Microkernels zijn niet sneller dan monolitische kernels. Een van de reden dat Linux monolitisch is, is snelsheid.

[MrFax]

Het voordeel van een microkernel is toch dat je componenten kan optimaliseren zonder de kans dat je zomaar ergens anders iets breekt. Bij een monolitische kernel bestaat die kans altijd.

[arithcoder]

Bij microkernels draaien de drivers in user space. Alleen de kern van een microkernel draait in kernel space. Dit heeft als voordeel dat als een driver crash't, het niet het hele systeem onder brengt. Bij monolitische kernels krijg je een "kernel oops" waardoor het systeem niet meer naar behoren werkt. Men kan zeggen dat de andere kant van monolitische kernels is dat het bevorderd om "betere" code te schrijven zodat er geen crashes (meer) gebeuren. Microkernels met hun user-space drivers hebben een kleine "speed overhead" tov monolitische kernels.

[Reactie gewijzigd door arithcoder op 23 juli 2024 02:59]

[Rob Coops]

Ondanks dat er vast een kleine performance hit zal zijn met microkernels denk ik dat we min middels voor de meeste consumenten elektronica dat probleem al lang voorbij zijn. De dagen van z80 chips en iedere clock tick moeten tellen zijn al lang achter ons de meest simpele dingen met een scherm of enige interactiviteit zijn in middels al voorzien van een simpele ARM processor die vaak veel te krachtig is voor de taken maar makkelijker in gebruik dan een minder krachtige processor.

Ik denk dat je niet moet vergeten dat Google een heel groot probleem heeft met Android, ten opzichte van de concurrentie (iOS) de drivers die nodig zijn voor een andere modem, een nieuwe GPU of wat dan ook zijn moeilijk door een derde partij in te passen. Waardoor updates en fixes vaak langer op zich laten wachten dan nodig is. Aan de Apple kant heeft men om te beginnen veel meer controle over welke hardware er gebruikt wordt en omdat alleen Apple het OS beheert is een update pushen totaal geen probleem. Aan de Google kant is dat heel erg veel lastiger.

Maar met een micro kernel is dat probleem opgelost, Google kan de kernel updaten zo vaak men maar wil zonder dat welke fabrikant van hardware dan ook in de problemen komt. Alle drivers kunnen los van elkaar worden geupdate zonder dat de telefoon fabrikant er iets aan hoeft te doen. Hier door kunnen de telefoon fabrikanten de noodzaak om updates te blijven leveren tot in de lengte van dagen neer leggen bij de hardware bouwers en hoeven de telefoon makers alleen hun custom UI werk te onderhouden.
Ook hier zie ik een zelfde "probleem" oplossing, zelfs de goedkoopste budget telefoons zijn razend snel, en als ik zeg, 1.5% performance in lever omdat de kernel overal nu eenmaal tussen zit dan is dat helemaal niet zo'n probleem meer de chips zijn snel zat.

Een volgende stap lijkt me dan ook dat Google als de andere hardware er eenmaal op draait en men tevreden is over de manier waarop het OS werkt om dit op een Google telefoon te zetten. Als ook daar dingen naar behoren werken dan zie ik Android nog wel eens vervangen worden door dit nieuwe OS.
Want een nieuw OS dat zich meer richt op beveiliging, upgradability en performance lijkt me zeker niet iets dat Google alleen voor een paar "slimme" speakers zal hebben ontworpen.

[arithcoder]

Dat ontken ik niet. Heb alleen geprobeert om het verschil tussen micro- en monolitische kernels uit te leggen. Als Google voor een microkernel gaat, hebben ze wel een goed reden.

[Frame164]

Ja, maar dat wil niet zeggen dat het sneller is. Net als met micro-services breek je de boel op in manageable stukjes die op zich stabieler zijn. Maar de softwarearchitectuur heeft niet als uitgangspunt dat het gedaan wordt voor snelheid.

[MrFax]

Maar het maakt het wel veel makkelijker om de code beter onder controle te houden en uit elkaar te houden, waardoor het veel makkelijker is om oude code onder de schop te doen om het te moderniseren en sneller te maken. Dat was mijn punt Jouw punt klopt ook, dus het is maar wat het in praktijk zal worden.

[Reactie gewijzigd door MrFax op 23 juli 2024 02:59]

[AlephNull]

Een van de redenen dat microkernels zo weinig populair zijn, onlangs de vele voordelen, is juist de performance. Bij een microkernel draaien zoveel mogelijk taken als separate processen buiten de kernel. Alle communicatie tussen OS taken moet dus plaatsvinden via een vorm van IPC. Bij een monolithische kernel, zoals Linux, vindt alles plaats in hetzelfde process en address space. Communicatie tussen de verschillende taken is over het algemeen dus veel efficiënter.

Maar in 2021 kan je je afvragen of performance nog steeds de belangrijkste motivatie is om niet naar een microkernel over te stappen. Voor Google is dat duidelijk niet het geval.

[Frame164]

Voor individuele apparaten zoals een Nest hub is performance inderdaad geen motivatie meer. Onderhoudbaarheid en stabiliteit zijn veel belangrijker. Bij dit soort dingen waarvan er miljoenen in het veld staan is iedere fout na een update er 1 te veel. De impact is gigantisch (zowel technisch als publicitair).

Voor data centers is performance nog wel steeds een belangrijk topic. Een paar procent performance winst kan tientallen of meer servers schelen. Iets slimmere software kan voor een veel betere TCO zorgen.

[RoestVrijStaal]

Minder gecompliceerd? Minder code?

Ik denk dat dat niet helemaal waar kan zijn, omdat er onder andere tussen de kernel en subsystemen meer Inter-process communication plaats moet vinden en daarvoor moeten ook de nodige fallbacks voor geïmplementeerd zijn.

Juist de delegerende insteek van de architectuur van de microkernel maakt het gemakkelijk adaptief voor toepassingen in nieuwe contexten (installeer en gebruik enkel de subsystemen die nodig zijn). Maar omdat de subsystemen in userspace draaien, kan het foutgevoeliger en onveiliger zijn.

[Schway]

In het artikel staat dat de verwachting is dat het niets uitmaakt. de hele UI en alles draait toch via Flutter. De onderliggende architectuur zou dus geen invloed moeten hebben.

[Hans C]

Dat staat er niet. Er staat dat het er hetzelfde blijft uitzien. Maar over de prestaties zegt het artikel niets anders dan dat dat nog maar de vraag is.

[Schway]

right sorry! Dat had ik uit het 9to5 artikel gehaald. "Considering the interface and experience will be unchanged, it’s likely that Nest Hub owners won’t even notice they’ve been switched over to Fuchsia OS. "

[reneflo]

Tja, daar gaat het ook wel om de UI. Als het ineens 2x zo snel wordt allemaal hebben mensen nog niet door dat ze over zijn naar Fuchsia OS, ze denken dan gewoon dat hun bestaande systeem sneller is geworden.

[Schway]

Dus dan noticeën ze het wel dus?

[reneflo]

Dit is leuk artikel over het verschil
https://9to5google.com/20...fuchsia-video-comparison/

Samenvatting, met Fuchsia is het systeem soms een klein beetje sneller, maar eigenlijk zie je dat alleen als je ze naast elkaar zet.

[Mellow Jack]

Mja hoeveel zouden de prestaties kunnen verschillen? Misschien iets sneller booten omdat dit alleen bevat wat gebruikt wordt... Voor de rest is het dezelfde hardware en ik kan me zomaar voorstellen dat Fuchsia ook gebruik zal maken van opensource producten.

Net zoals dat je niet zo 123 kan zien dat VMware ESXi geen Linux kernel draait

[Frituurman]

De bedoeling is dat er niets verandert voor gebruikers met dezelfde interface en dezelfde functies als onder Cast OS mogelijk is. Het is onbekend of de software sneller of juist minder snel werkt na de update.

Dat staat nadrukkelijk niét in het artikel. De interface en functies blijven hetzelfde. Het is onbekend of de software sneller of juist minder snel werkt.

@Hans C Je was me net voor

[Reactie gewijzigd door Frituurman op 23 juli 2024 02:59]

[Schway]

Klopt, ik had het bron artikel gelezen, daar staat "Considering the interface and experience will be unchanged, it’s likely that Nest Hub owners won’t even notice they’ve been switched over to Fuchsia OS. "

Was even niet scherp en had niet door dat het tweakers artikel het alleen over de functionaliteit had.

[fapkonijntje]

Trager kan dit ding toch niet worden.

[i-chat]

Dat hangt nogal af van

De kwaliteit van de nieuwe code
De vraag of externe kernel modules de boel niet vertragen

[dutchnltweaker]

Ik vraag me af of fuchsia os ook voor smartclocken komt zoals deze: pricewatch: Lenovo Smart Clock met Google Assistent Lichtgrijs

[Vullisbak]

Lenovo zou dan moeten besluiten om Fuchsia in te zetten voor hun producten. Google levert alleen OTA updates voor hun eigen producten.

[Rob Coops]

Ik vraag me af hoe lang Google als dit een success wordt op hun eigen hardware, nog Android zal aanraden voor dit soort hardware van andere fabrikanten.

Hier zijn de voordelen als je Fuchsia gebruikt in plaats van Android.

• De kernel kan onafhankelijk van de hardware worden geupdate en is volledig de verantwoordelijkheid van Google
• De drivers kunnen onafhankelijk van elkaar, het os of de fabrikant van het apparaat door de makers van de chips worden geupdate
• De UI en alle daarbij behorende apps kunnen onafhankelijk van de rest van het system worden geupdate door de maker van het apparaat.

Het enige "grote" nadeel is dat het nieuwe OS eventueel iets trager zal zijn als dat al merkbaar zal zijn voor de eindgebruiker.

Ik kan me helemaal voorstellen dat de huidige apparaten echt niet meer geupdate gaan worden maar dat je over een jaar of 3 alleen nog maar oude modellen kunt vinden met Android en de rest in middels allemaal Fuchia draait.

Het argument dat @Vullisbak hier onder maakt zal juist de reden zijn dat een Lenovo en andere bedrijven juist heel erg graag Fuchia op hun nieuwe apparaten zullen willen zetten. Het neemt een heleboel werk uit handen van de maker van het apparaat en legt veel meer verantwoordelijkheid bij andere.

[Drardollan]

Ik ben benieuwd, mijn Nest Hub werkt wel maar om nou te zeggen dat het zo geweldig is. Communicatie met apparaten stokt regelmatig of je krijgt de respons dat (bijvoorbeeld) een lamp niet aangezet kan worden terwijl hij net aan gegaan is

[telenut]

maar dat staat volledig los van de Hub zelf toch...

[Drardollan]

De Hub praat met Homey en met een paar apparaten direct, met alles gaat het vaak mis. Ik zie bijvoorbeeld mijn Homey apparaten vaker niet dan wel.

Om eerlijk te zijn is de Hub voor mij een digitaal fotolijstje waar ik eenvoudig foto's heen kan sturen. Gebruik hem verder vrijwel niet door alle perikelen.

[Fire69]

Same here, maar ik denk niet dat dat aan de Hub ligt hoor.
Ik heb nog een hoop Mini's en een Nest Audio, die hebben hetzelfde probleem.
Ze verbinden gewoon naar Google en als die zegt dat er een probleem is met je apparaten papegaaien je Hub/Mini/Audio dat gewoon na.

[telenut]

Dit dus. Heeft niks met de hardware of software op het apparaat te maken. maar met de backend bij google, of de link naar homey natuurlijk...
Al de mijne werken zeer goed eigenlijk. Ook al begrijpen ze niet altijd even goed wat ik vraag... maar ook dan ligt het aan de AI van Google. Kan dus altijd beteren met de tijd.

[Fire69]

[...]Kan dus altijd beteren met de tijd.

Of gigantisch slechter worden...
Ik zie toch wel veel klachten van users die zeggen dat het alleen maar slechter wordt en ik kan er mij wel in vinden.
Als mijn Nest Audio muziek speelt lijkt het wel of hij een mentale beperking heeft. Zelfs 'stop' snapt hij niet dan. Ik moet via de Home app de muziek stoppen.
Ook krijg ik nu sinds verleden week plots 'ok, ik doe de licht uit'.... Wat?

[Drardollan]

Alles hangt aan elkaar met experimentele touwtjes. Ik vind dat niet zo erg, we zijn toch een soort van pioniers op deze manier. Over 25 jaar zal de wereld er heel anders uitzien, maar hebben wij wel aan de basis gestaan van.

Met dat in gedachten is het overigens best leuk speelgoed allemaal, maar wel een reden om ook alles autonoom te laten werken (lichten, thermostaat, etc.). De Homey en Hub zijn leuk als aanvulling op, maar als het puntje bij paaltje komt wil ik wel gewoon dat het warm is en ik met een knopje alsnog het licht kan aandoen.

[Drardollan]

Allemaal Google platform

Ik heb mij er bij neergelegd, ik vond het het geld wel waard om het als fotolijstje en weerbericht te gebruiken. Mogelijk is er in de toekomst meer mogelijk, en dan zal ik daar zeker naar gaan kijken.

[AJediIAm]

De response dat een lamp niet aangezet kan worden is omdat de dienst die hem aan zet geen goede, te vroeg of te laat feedback geeft.
Net name als er geen feedback gegeven wordt heeft de google hun het moeilijk omdat het blijft wachten op een antwoord.

[TiSneu]

Dit weekend de een update ontvangen - merk dat het swipen precies iets sneller gaat fyi

* edit : draai nog steeds het oude OS bij nazicht.

[Reactie gewijzigd door TiSneu op 23 juli 2024 02:59]

[sam45]

Wat is het versienummer van de update?

[AJediIAm]

Volgens google is de laatste preview versie nog steeds 1.52.249798.
Dit versie heb ik nu ook. In de software licenses staat dat de kernel nog steeds onder een license van de free software foundation valt. Ik neem aan dat dit dus nog niet de Fuchsia release is.

Ik heb nog geen screenshot kunnen vinden waaraan te zien is dat Fuchsia draait. Mocht iemand die hebben, graag naar tweakers sturen voor een update van dit artiekel.

[Renect]

Zeer benieuwd naar de snelheid van dit nieuwe OS. Het huidige "systeem" van Google dat draait op de Nest Hub heeft een responsetijd van 2 seconden bij iedere touch/swipe. Indien te fanatiek en de gehele hub loopt vast.
De 5 FPS Hub is wel toe aan wat vernieuwing naar mijn mening.

[xFeverr]

Eens. Het is gewoon een webapp waar je naar zit te kijken en dat trekt dat ding gewoon niet in de huidige implementatie. Ik vind het verschrikkelijk om het touchscreen te gebruiken omdat het gewoon niet vloeiend is.

Heb er niet direct hoop in dat deze update daar iets aan gaat doen. Van mij mogen ze er voor het grootste gedeelte gewoon een native interface van maken, dat zou een hoop schelen!

[DigitalExorcist]

Knap van Google dat ze een 3 jaar oud device überhaupt nog ondersteunen!

[Raan7]