Yes, now when Google's social enforcement algorithms label you an impediment, they can not only delete your YouTube video business and cut you off from your email, calendar, and Google Docs, they'll be able to turn the heat off in your house. The march of progress.

Five years ago, I would have thought you were trolling, but now you are right. With this scorched earth mentality exercised by the big companies, this is a very real possibility.

What scared me quite a bit was Apple blocking all services when an Apple Card wasn't paid. That leads me to believe that Google could via an algorithm's decision disable a Nest thermostat during winter. I don't see IoT as anything but a risk.

> What scared me quite a bit was Apple blocking all services when an Apple Card wasn't paid.

I'm not trying to sway your opinion of Apple, but you should know that Mr. Curtis's Apple ID problem was discovered to be unrelated. Apple doen't disable Apple ID services because of missed Apple Card payments.

https://9to5mac.com/2021/03/03/apple-card-apple-id-unrelated...

??? Your linked article says the situation is even worse. Not just Apple Card, you can have Apple services disabled if you owe money to any part of their ecosystem.

Google is even worse. You can get banned (your entire google account) because of a random algo. https://9to5google.com/2019/11/09/google-account-bans-youtub...

Or imagine, they can ban your because of speech their don't like i.e political opinions

and lock the doors

I'm so done with this smart home stuff.

"Alexa, turn on Living Room."

"I'm sorry, I'm having trouble understanding now."

I mean, yeah, I can toggle the light switch to get it to turn on, but then it gets screwed up and I need to go into the app to reset it when the internet comes back on.

I don't even want to think about a smart thermostat. My dumb thermostat from 10 years ago let's me set timers which is all I really need.

While I've never had issues with turning on and off lights via Alexa -> Smart Plugs, I have had my Echo Dot unable to play my wakeup alarm due to internet blips. Really? That particular function couldn't store some data in some sort of local storage? Like, I don't want the thing to be able to tell me Rick Springfield's biggest hits in order of Billboard chart performance while offline... I simply want my alarm sound to play at 6am.

You need an offline smart assistant: https://medevel.com/10-open-source-voice-assistants/

I think in this case it would be called an alarm clock.

Yes, while one could make the case that I should purchase and plug one more thing into my wall. Would it be impossible to place a small amount of memory on the board that remembers alarm settings? If this thing is built as a convenience, I don't want to have a bunch of other devices for convenience (a radio, a noise generator, an intercom....)

And it should be a wind-up mechanical one so that power failures don't affect it.

Mental failures affect those. I would never remember to wind it.

You don’t want a remote-controlled smart (actually: dumb) home. You want a fully local solution, then you can add remote, internet-dependent functionality like alexa to it. That way your primary mode of control will always work.

Agreed. I'll add to that a healthy application of the Principle of Least Astonishment. If you have a light, there should be an obvious light switch nearby that turns the light on and off, and does so even if your home automation system is offline for whatever reason.

"Smart" devices should, wherever possible, function as dumb devices if for whatever reason they can't be smart. There are a whole lot of devices that simply become bricks.

"An escalator can never break: it can only become stairs. You should never see an Escalator Temporarily Out Of Order sign, just Escalator Temporarily Stairs. Sorry for the convenience."

I know it’s a joke but if the failure mode is “brakes don’t work” on an escalator full of people, it is much worse than stairs

Very true— I would definitely imagine that escalator brakes are a thing that fail closed in the absence of power, but clearly there are failure modes (probably a rare confluence of multiple concurrent failures) where this kind of thing can happen, such as that incident in Rome in 2018:

https://www.youtube.com/watch?v=o1SjQfwLieU

Another in China in 2017

https://www.youtube.com/watch?v=ADb57ysvCbU

https://coconuts.co/hongkong/news/engineer-gets-2-months-in-... (misleading URL, actually suspended sentence)

Rather that than an falling elevator, but it still doesn't look fun

Rhasspy is an easy to use open source, fully offline, suite for this with wake word detection and integration with home assistant.

I've never understood the desire to control systems by speaking to them in code words. Speaking monopolizes a shared channel, requires diverting your conversation, and is really slow.

For practically anything that involves using code words to tell the computer what to do there are better input methods, like physical switches, or purely automated.

This is slightly off-topic, but in your opinion what are some of the reasons people prefer to use voice input with code words over the other options ?

Physical switches rely on light as a handshaking method.

When the light is off, the switch is invisible and you have to guess at where it is, or where you need to be walking (hitting your shins on things, or stepping on lego)

Using a non-light based interface means it works just as well when the light is on and off, vs being a broken experience for half of the usecases

Cooking. My hands might be occupied or dirty etc, but I need to set or change a timer.

Yep. Cooking is what I use Alexa for. The main control is homeassistant, but it forwards some lights to Alexa for me to control ober voice.

Or washing dishes; pretty much anything in the kitchen.

Thanks for helping me to understand this better.

1. Hands are dirty/unavailable (like other mentioned cooking) 2. The physical controls are physically across the room 3. The physical controls can't be located easily (lost remote, dark room)

Another point, the cognitive load of speaking a command is different than pecking through menus on a phone or finding the right button on the remote/device. It may be easier to just speak out load depending on your state if mind.

If I'm curled up comfortably with my SO, and don't want to take ten minutes of unwinding, doing whatever, then tucking back up together...

It seems like in that case a remote control could be placed nearby -- are you also using voice activated code words to control the television ?

> are you also using voice activated code words to control the television ?

I happen to have backed a Kickstarter that will hopefully enable me to do just that ;)

If you're interested in getting more quickly and WANT to write software, you can have the Raspberry Pi control most televisions over HDMI-CEC using libcec [0], and then you just need the voice recognition stuff mentioned above (Rhasspy [1]).

I had to do something similar (minus voice controls) to keep my existing remote's volume controls working with an analog volume device [2].

[0] https://github.com/Pulse-Eight/libcec [1] https://github.com/rhasspy/rhasspy [2] https://rkeene.org/viewer/tmp/cec-volume.cc.htm

Unless your SO is sitting on the remote

Agreed. I've been really happy with Ikea's Tradfri line. It's all on Zigbee, works without internet and doesn't need an "Ikea account". However lights and blinds only for now, plus they have perpetual shortages.

And get some motion detectors. Your lights should come on when someone enters the room and the light is below a threshold. I usually hit the off switch by the door when I leave, otherwise if no one is present the lack of movement will dim and then turn the lights off. It's 2021 people!

Motion detection is not presence detection. I still want the light even if I'm sitting still, such as reading a book or using a computer.

We use the motion detection to turn on lights and usually turn off manually. I've set up ours to remain on until a fair amount of inactivity. In two years it's only turned off once whilst we were watching a movie.

Do you not move when you're asleep?

Don't use the motion detection/automatic in bedrooms.

This is how the Honeywell stuff seems to work, at least for my thermostat. As long as there is some local wifi, thermostat and controlling unit will work, even if you cannot contact them from the internet.

What happens if power goes out, the units stop working if WiFi isn't on a UPS?

This would definitely be a problem in cold climates where a dead furnace could lead to frozen and burst pipes.

The unit is event-driven, so no, you would just lose the ability to change its current programming. Regardless, it can be bypassed on the actual boiler heater, it's just a thermostat. It's a decent set of compromises, definitely better than anything going "no internet, no service".

In my case: No power would mean I have nothing to control anyway. The only reason my local network is down would be my power down. That happened twice in the last 16 years.

I've actually had a really positive experience using a smart thermostat. The main benefit is having a temperature schedule, which my previous dumb thermostat didn't have. It's also handy being able to adjust the temperature from my phone whenever I'd like to. I find controlling it by voice kind of pointless. On the phone, you can easily see what it's currently at, then adjust it for the next e.g. hour, after which it'll switch back to the default schedule.

I agree being able to change the temperature settings from a phone would be convenient, but they've had "smartish" thermostats capable of relatively complex temperature schedules for at least 20 years.

No need for an internet connection or mega corp data collections.

can smartish ones detect when you leave home and turn down the heat until you get back? My nest can. This is great because my schedule is not the same every day.

Most dumb thermostats also have next-hour-override functionality, though I will say I had a Nest at a previous house and also thought it was pretty decent. In particular, it was nice being able to turn it way down when going away, but then crank it back up when heading home but still 30 mins away.

You don’t really need anything “smart” for this. This is basically simple remote with timer. My $50 thermostat has adjustable schedule with override capability. No machine learning needed. The only thing that’s missing is the phone capability but I think that would be easy to add.

Totally agree. I still don’t get the appeal of “smart” whatevers.

> No machine learning needed

Now this reminded me of the windows 10 update announcement proudly declaring that they were going to start using ‘machine learning’ to figure out if you were using your computer to minimise the disruption from their automatic updating. I’m still baffled by it. Why not solve the actual problem at hand - updates being really slow, risky/buggy, settings altering, and very disruptive even when scheduled, and users not having enough control over updating? I’m pretty sure ‘machine learning’ isn’t needed to determine whether a computer is being used.

I have smart thermostats, specifically the AVM Fritz! ones. They only require their own router (which, where I live, is a common thing to have) and use DECT to talk to the router (you can find DECT usb sticks that work on Linux, the protocol they talk isn't super complex). They run about 2-10 years on a single battery, depending on use.

And they're fully offline, the router has an API I can control them from (HomeAssistant instantly picked up both thermostats and lets me control them), pretty much everything I want.

AVM's smarthome story is miles ahead of Google/Apple/etc. Same for IKEA's smarthome stuff. If you need offline capable things, use those.

Check out Home Assistant. Not sure how well voice controls work with it but my automation is flawless so far. Really seems to help using local only open source firmware where I can and Zigbee for any sensors that aren't hard wired in (mostly for battery efficiency.)

I just read yesterday that Home Assistant is now automatically included in Raspian (Raspberry Pi targeted OS). I run my home and shop automation on Pi's but ultimately a NUC is probably a better long term solution.

I have openhab in place for issues like this. Enjoy the smart home with a local connect-to-everything controller/bridge. Runs on a Pi, as a VM, ... Works great!

I never bought in to the premise of the "smart home."

It sounds like endless minor annoyances and aggravation more than anything.

In my experience it brings minor conveniences: yelling at Google or Alexa to turn on the kitchen lights when your hands are greasy, or dimming the lights with your phone when you're sitting on the couch with a cat on your lap. None of these are huge selling points, but once in place they're nice.

If done right, though, the system just degrades gracefully to a normal set of switches.

Yep, that's pretty much been my experience.

I'm in a rental, so instead of smart switches I just use smart bulbs. For like <$10/bulb, I've got full RGB/colour temperature adjustable.

Most are configured so turning them on turns them on full brightness and pleasantly warm. The one in the bedroom and the baby's room are configured to turn on dim and warm, and if you do another quick off-on flick of the switch they'll come on at full brightness.

So they... work like normal light bulbs. Except they're all remote controllable from your phone. So if the baby falls asleep on top of you and the light's on you can turn it off without getting up and waking her up.

From there, I added some basic z-wave sensors in a few spots in the house. If you get up in the middle of the night to use the bathroom, as soon as you step in the hall the motion sensor picks up that (1) someone is moving in the hallway and (2) the hallway is currently really dark; and it turns the hall light on a really dim red. Enough you can see where you're going without killing your night vision. Then a minute after it stops sensing motion it turns off.

If you walk into the one end of the basement where the washer/dryer/workshop/storage/etc are, all of the lights will come on for you, and a couple minutes after it stops sensing motion they all turn back off. If you want them to stay on you can just flip the switch off-on to turn them all on and keep them on. So now if you just wander over to let the dog out, grab a tool from the shop, throw a load of laundry in, etc, the lights are just automatic. No need to try and balance a laundry basket while you screw around with light switches.

The room my office is in does the same thing except uses my computer's lock state for presence detection. So when I walk in the lights come on, when my computer unlocks it keeps them on. When I lock my computer it goes back to the regular program. At any point I can pull my phone out and flip them over to the super bright, super harsh light when I need it for doing fine work instead of working at my computer.

Just a lot of little, basic conveniences. And it's amazing how futuristic it feels to just wander around the house and have lights turn on and off for you as you do.

It all runs locally in a VM on my server, with all the smart devices entirely isolated from the internet. If the internet's out... nothing changes. If my server/WAP/whatever dies, then my house just goes back to working like a normal house.

> I mean, yeah, I can toggle the light switch to get it to turn on, but then it gets screwed up and I need to go into the app to reset it when the internet comes back on.

That doesn't sound right. All the Zigbee/Z-Wave switches I use maintain proper state through HA, even if they lose connectivity for a period of time.

I added a bunch of Shelly Wi-Fi relays to my house and I can see temperatures of every room, tell the heater to turn on etc, from anywhere in the world, with full self-hosting if I want it.

I have been presently surprised with Google Assistant in this regard, the integration with my TV (with new Google TV Chromecast) is amazing and a lot of time I don't bother to pick up the remote. (Saying things like "Play xyz on TV", switches on the TV, figures out the right app and starts playing the show saving me 4-5 actions on the remote)

We put Etekcity remote controlled sockets in a few places and stopped there. That being said, apparently you can buy a radio module to control them from a raspi, but we haven't gone there yet.

> Today, instead of excitement, I am wondering how this thing is going to push me in some walled garden, how I will be tracked, how my data will be fetched and sold, what will be the trick used to move people away from free Web...

Since Chrome came along, the 'Web' became less free from the start and the moment Google forked WebKit (called Blink) to use it in their own browser, it has turned the web more into a walled garden each time apps use specific Chrome features and it is getting worse. Even in that early decade, we knew about how Google and others were tracking us since the PRISM program leaks.

Later DRM was added with reasons and votes unknown, devs have to keep telling users to switch from any other browser to Chrome to use their apps and now this forked engine is in tons of Electron apps with Microsoft jumping in and using it in their Edge browser. The time to complain was 10 years ago and now it is almost too late.

Now Google is doing it again with Fuchsia which will eventually replace ChromeOS and Android. Fuchsia is highly dependent on Flutter and those apps will run on Fuchsia devices on day 1. There is an extremely low chance of that being abandoned so I'm afraid it will continue.

There's so much here that I don't really know where to start. Maybe some history could be useful?

When Chrome came along, the dominant browser was Internet Explorer 7. It had been out for two years when Chrome 1.0 was released. Before IE7, the world ran IE6 for five years. Web development was largely stagnant. That was the world that Chrome came into.

Before DRM support was added to browsers, you needed to install plugins to watch protected content. Despite what detractors might think, the content producers were never going to go YOLO and release their content without any protection. There are a lot of us that are happy that we can watch Netflix, Prime or whatever in our browsers.

That a ton of desktop apps use Electron is an indictment of the state of native toolkit. Saying that Fuchsia is highly dependent on Flutter is like saying Linux is highly dependent on GTK. With that said, maybe your crystal ball on the future of Fuchsia isn't so clear.

And so, the web has just switched hands from one behemoth to another. Nothing has changed since then. Now everyone depends on Chromium for almost everything. That is the point.

The alternatives have no chance in doing anything about it. Firefox is entirely dependent on Google for funding (and has been for years), Microsoft recently switched to Chromium for Edge and Safari is again years behind (Just like IE.). There are only really two competitors here. (Apple and Google once again!)

So let's sit back and just watch Google continuously adding more superfluous features into the Web like Web(USB, Bluetooth, NFC, etc) and the web-devs will force you to use Chrome again (which indirectly helps Electron apps); leaving the rest of the non-Chromium browsers in the dust.

> Saying that Fuchsia is highly dependent on Flutter is like saying Linux is highly dependent on GTK.

False equivalence.

You're the one that just compared a kernel with full operating system. Oh dear. I'm definitely sure that the device in the article is running Flutter right now.

> With that said, maybe your crystal ball on the future of Fuchsia isn't so clear.

Given that Fuchsia also has the intention of running unmodified Android apps as well, my crystal ball could not be any more clearer of its future. Perhaps you getting confused on your last sentence was an indication that your crystal ball has just malfunctioned.

> Nothing has changed since then.

There's a massive difference. Back then you had a single company that kinda-sorta didn't care about the web. They already had an application platform they were happy with. There wasn't really an incentive for them to evolve it once they had the dominant position. The web was stagnating for years.

Nowadays we actually have multiple players that are very active in the development of the web. The situation is not at all comparable.

> So let's sit back and just watch Google continuously adding more superfluous features into the Web like Web(USB, Bluetooth, NFC, etc) and the web-devs will force you to use Chrome again

Superfluous to you. If developers are using it, then it's obviously filling some need. What do you say to developers who are asking for those features? "Sorry, that's not compatible with my idea of what the web is. Go write a {Windows,Linux,MacOs} application and tell your users to download it".

It always comes back to this. People want progress in the areas they care about, but no progress in other areas.

If it wasn't for Safari, the Web would be a synomim for ChromeOS outside Chromebooks.

Firefox is getting irrelevant and the latest news show their focus isn't surely in turning the tide, UI revamp, really?

You might want to add: [I wonder] when it will be discontinued with just a one month's notice and will turn my device into a brick.

This is the bigger risk. I don't see Fuchsia as a walled garden OS as it's pretty well designed to avoid that. Userspace everything with a microkernel makes for a nice small security footprint for IoT devices that can be perpetually updated.

The issue is how long google keeps up "perpetual".

To add to the pot of cynics

I wonder how much of it is driven to supplant Linux's "viral" GPL-ness

Google open source engagement was already "throw over the wall" style before this.

I assume things will only get worse now.

Fuchsia, like Chrome, has been open-source for years, and all commits and reviews as well as the bug tracker are public. It is a very different model from how Android releases work.

(Disclaimer: I work on Fuchsia at Google.)

Chrome is not open-sourced, Chronium is. I cannot rebuild Chrome with full protection against tracking, for example, but with all other parts unchanged.

Android "open sourced" as well, but literally nobody runs AOSP, stock OSS apps are staled for years, Google makes a lot to make system barely usable without proprietary parts from Google Services.

That's a fair point, and the distinction between Chrome and Chromium is indeed relevant. Sorry for the confusion, see my sibling comment about how it applies to Fuchsia (ie. what is open source and what may not be).

What I really meant to say, though, is that Fuchsia is taking an approach to inclusiveness and open source which is much more similar to the one of Chromium than Android. You may find out more on https://fuchsia.dev/fuchsia-src/concepts/principles/inclusiv...

So, if I buy a device that runs Fuchsia (say, this Nest Hub), is enough of Fuchsia FOSS that I can run my own copy of it with e.g. a different UI and without Google services? This is true of Android devices by necessity as the kernel is GPL (bootloader locking aside); is it true of Fuchsia devices?

As for bootloader locking, Google releases some Android devices with unlockable bootloaders. Can we expect the same of Fuchsia devices?

There are several parts to your question, let me try and answer each of them as I understand them.

Fuchsia is built with a minimal core (sometimes called a microkernel) and many user-space services interacting with each other over an IPC protocol (called FIDL). The open-source part of Fuchsia, available on fuchsia.dev, is a standalone system which you can build and run on supported architectures. It contains all the services required to start a user interface, interact with the network, etc. Currently, the main supported hardware architecture for people wanting to build their own version of Fuchsia is the Intel NUC: https://fuchsia.dev/fuchsia-src/development/hardware/intel_n....

For a retail devices, such as the Nest Hub, vendors can build a custom system with additional or different services from what is found in the open-source release. Thanks to stability of the FIDL interfaces, those closed-source services do not prevent the core system from being updated. For more information on services and packages, you can read https://fuchsia.dev/fuchsia-src/concepts/software_model and the pages linked from it.

Some of those services are drivers; others may be in charge of communicating with Google Services or customizing the UI; and not all of them are necessarily open-source. So if you wanted to build your own version of Fuchsia for a Nest Hub, you'd need to replace the closed-source components. As far as the Nest Hub is concerned, I'm not sure what the exact status is. I believe a significant part of the drivers have been developed in the open (which is how 9to5google was able to guess in the past that we would be targeting this platform), but take this with a grain of salt, I didn't work on drivers. The part that interacts with Google Services is closed source. I'm not sure this is much different from the situation with Android: not all drivers or UI used on Android devices are open source, are they?

Finally, as you note, the bootloader can be locked on retail devices, preventing you from reflashing the system with your own build unless it is signed by an authorized key (mostly for security reasons, as far as I understand it). This is a product decision that is not related to Fuchsia itself, it depends on each manufacturer. I don't think it has ever been supported to reflash a Nest Hub, and the migration to Fuchsia shouldn't change that.

Thanks, this is useful information.

> For a retail devices, such as the Nest Hub, vendors can build a custom system with additional or different services from what is found in the open-source release. Thanks to stability of the FIDL interfaces, those closed-source services do not prevent the core system from being updated.

This is helpful so long as the interface does not change; do you anticipate ever having to change it or do you think it's pretty final at this point?

Regarding drivers, it's interesting that they're userspace services interacting with the rest of the system via IPC. Are there any sort of security guarantees to protect against malicious services? (Obviously a proprietary driver could do its job incorrectly, but if they can't otherwise mess with other parts of the system that's helpful.) EDIT: I suspect that as it's a capability-based system, there is a decent amount of isolation between drivers and the rest of the system, but I just want to be sure.

> I'm not sure this is much different from the situation with Android: not all drivers or UI used on Android devices are open source, are they?

Regarding Android drivers: my understanding is they sometimes do have proprietary userspace components. Any kernel-side components are necessarily FOSS however, as they are derivative of the Linux kernel and therefore GPL. (This doesn't mean that they're always easy to use though, as manufacturers seldom upstream them and the Linux kernel is a huge project.)

On the Android UI, you're correct; most often the UI on an Android phone is not FOSS. I suspect this is because, as that part of Android is permissively licensed, the device vendors don't have to release it. So they don't.

I've had mixed feelings with Fuchsia from a licensing perspective for that reason. On one hand, having a stable interface might make it easier to deal with proprietary drivers, provided that interface is locked in amber and never changes. On the other hand, Fuchsia's permissive licensing makes it more likely that manufacturers will make all their drivers proprietary, because they clearly do whenever they can. (At least the ARM vendors do; the x86 vendors seem to be a lot more open to working in public.)

> do you anticipate ever having to change it or do you think it's pretty final at this point?

We're not there yet, but defining a stable driver runtime is on our roadmap for 2021: https://fuchsia.dev/fuchsia-src/contribute/roadmap/2021/stab...

For non-driver interfaces, similar stability commitments may be shared over time, as the platform matures and we get more users.

> Are there any sort of security guarantees to protect against malicious services?

Fuchsia is based on capabilities, ie. handles to access resources, and those include memory regions. So a driver will only be able to access the parts of memory that you delegate to it. I don't know enough about drivers to provide a detailed security analysis, but I think it provides far more isolation than what you have in a monolithic kernel such as Linux.

> Fuchsia is based on capabilities, ie. handles to access resources, and those include memory regions. So a driver will only be able to access the parts of memory that you delegate to it.

Ah thanks - Fuchsia drivers having capabilities to specific memory regions mostly answers my concerns at that level I think.

Well, I guess I'll continue to be both interested in it from a technical perspective and conflicted about it based on licensing.

While the platform may be open source, the product may not be. We have products which are completely open source, but the one being used for the Nest Hub is not. This is similar to the idea where you may use Linux for the bottom half of an OS, but the top half may be something else entirety. Different products may make different decisions, but a common core is used amongst all products.

It's not really true for Android either because the graphics drivers are mostly userspace and end up coupled with a lot of the vendor provided stuff.

Fuchsia has no GPL so it's unlikely any of the driver source will be available to you.

> Fuchsia has no GPL so it's unlikely any of the driver source will be available to you.

The open-source repository already contains over 50 directories named `drivers`: https://cs.opensource.google/search?q=f:drivers%2F$&sq=&ss=f...

Yes, but it's very unlikely that chipset vendors like QC or MTK will provide the source to their drivers. Why would they?

On the other hand, if the driver interfaces are stable, it should be possible to implement a GPL kernel that can use these drivers.

The BSDs have lots of drivers too, but it's rare you see them coming to an embedded board first (and rarer you see BSPs published for them from vendors.)

Are unlockable bootloaders bootloaders that cannot be locked, or bootloaders that can be unlocked? Not a native speaker.

Hm. I think it is about bootloaders that can be unlocked.

In this case, unlockable means it can be unlocked. As a native American English speaker, I have not seen unlockable used as "cannot be locked", but both definitions are in the Oxford dictionary. If I understand correctly, a locked bootloader prevents you from installing a different OS or rooting a device you might "own".

"Unlockable" == "The option exists for the user to unlock the bootloader if they wish to do so."

Even as a native speaker, it can get awkward explaining 'unlockable bootloaders' because the impliction is that they're first locked if they can be later unlocked... when there are also locked bootloaders that CANNOT be unlocked.

It's better to just assume 'unlockable' means 'not restricted.'

Is Fuchsia meant only for embedded devices (smart displays, smartphones, etc) or will there be laptop releases akin to Chromebooks?

If you are interested in running Fuchsia on a laptop or desktop device, you probably want to follow the Workstation product effort:

- https://fuchsia.dev/fuchsia-src/contribute/roadmap/2021/work...

- https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

And as mentioned elsewhere, you can already build Fuchsia for an Intel NUC, with keyboard, mouse, ethernet and external screen support: https://fuchsia.dev/fuchsia-src/development/hardware/intel_n...

>We’ve been tracking the development of Fuchsia since 2016, starting from an ambitious experimental UI, to running on Google’s many internal testing devices for Fuchsia, ranging the full gamut of Google’s smart home and Chromebook lineup.

Smart phones are definitely general purpose computers

How many of your colleagues are outside Google?

I'm not sure I understand the question, but you may be interested in the following article about Samsung contributing to Fuchsia: https://9to5google.com/2021/05/12/samsung-contributing-f2fs-...

Your implication is that Google is not treating Fuchsia as a 'throw it over the wall' project, but as one with community participation. How many of your colleagues are from outside of Google? How often do you work with non-googlers as you develop it?

Are you regularly reviewing code submitted by your colleages at Samsung?

The fact that you're confused by the concept of working with people outside your company doesn't bode well for the open-sourceness of this project.

They're probably talking about things like Go where it's open source, but it's controlled by Google employees.

https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGoo...

Good thing trusty google never changes direction or policies and that fuschia is copyleft, so it can never be closed in the future.

The fact it's more permissive with its license already does not bode well. Just like with Chrome, there could be a myriad of forks that can be closed source themselves and so without easy means to peek inside what they're really doing, and although many distributors did the bare minimum with Android due to its Linux kernel's license, there was something.

Right on the money! Interesting/scary times ahead. But maybe there will be unexpected gifts in the form of open source dev around zircon

Built on GPL, but not encumbered by it! It's free to take whatever direction it wants! Join the independent* revolution! /s

This PSA is proudly brought you by Google's Bureau of Prop... ehrm Truth.

*: independence neither implies nor contains freedom.

Or: "Join the independent" is a slogan of the open handset alliance, users are required to install Google Play and related services on all applicable devices.

It may also have been a play to remove Java as a fundamental requirement due to their experience with Oracle and Android.

All new FOSS OS clones are BSD/Apache licensed.

RTOS, Azure RTOS, mbed, NuXX, Zephyr

For sure it isn't a coincidence.

Clones?

POSIX clones.

POSIX is a specification. Implementations are implementations, not clones.

And most of the systems you listed aren't even aiming for POSIX-compatibility.

Can you please clarify what your intent was by using the word "clones"?

That was it, if you want to be pedantic, be my guest.

>Today, instead of excitement, I am wondering how this thing is going to push me in some walled garden, how I will be tracked, how my data will be fetched and sold, what will be the trick used to move people away from free Web...

There's no need to wonder. Fuchsia's been designed to do all those things and more.

https://beebom.com/what-fuchsia-os/

Starting with a modular design that caters to device manufacturers that allows them to provide only part of the operating system. The days of devices with full os's are coming to an end.

Cloud based constant device syncing between all devices

>Dependency on Web Apps

Google and device manufacturers will have full control over the microkernel and bootloader

Honestly, I'm not excited at all. I've been dreading fuchsia since it was first announced. Everything about the os is designed around google having complete control over the os itself and everything on your device.

Yep. I would guess the main driver for Fuchsia is that being a microkernel, drivers can be userspace things. So less work for Google to manage phone vendors. And the Fuchsia version of "AOSP" is easier to keep their secret sauce out of since there's no Linux GPL wrangling.

Don’t worry, they’ll abandon it in a year or two because not enough people use it.

Nah, it's an hardware-related project, so it will get entrenched even if it's fundamentally different from other hardware-related Google projects.

Eventually you'll be able to buy Google devices that run Android, Google devices that run ChromeOS, and Google devices that run Fuchsia. It will be confusing, but that's fine, because it will all work great as long as you stick to Google's cloud-based services, which is what really matters.

Directly or indirectly, OS fragmentation actually helps Google's business model.

Brillo => Android Things => dead after three years.

Plenty of Google hardware stuff didn't make it, at least, Glass and more recently, Stadia.

It sucks. They tried to pull me into the walled garden by ending Works With Nest and I still hate that I had to change to a different solution. The Nest thermostats are great, but having to go through the internet for any automation sucks.

Moreover, they can arbitrarily ban you from their walled gardens and you're more or less screwed.

When their control your email (GMail), business infrastructure (Google Business Apps / Servers etc.), Google Play (matters if you're a developer)... basically your entire digital existence.

I really hope we add more regulations to protect people online. While it's not clear for everyone, your digital existence is an essential part of being part of the society.

I too have become more cynical in the recent years...

Seconded. However, you forgot to worry about the inevitable shutdown just when you would start to enjoy or rely on it.

> Today, instead of excitement, I am wondering how this thing is going to push me in some walled garden, how I will be tracked, how my data will be fetched and sold, what will be the trick used to move people away from free Web...

I've been worried about it since they announced it which feels like it was 10 years ago.

I'm wondering when it will be cancelled or replaced with something else

With how Google is acting, I am fairly certain that I well never willingly buy a device that runs Fuchsia. I will have to find a better alternative device/OS or keep my current Android phone going forever.

There is however a huge issue of being locked-in to only officially-sanctioned OS versions, and I fully expect Google to try and completely replace everything that is still open in Android with proprietary replacements, making the Fuchsia-based phone OS the only accepted version.

As an example of the lock-in, the primary mobile payments app where I live has the following list of requirements/restrictions:

  - Android or iOS only (there is no PWA or other web-based version)
  - Minimum version is currently Android 6.0 or iOS 11
  - Device must not be jailbroken or rooted
  - Device must not run a non-official ROM, such as LineageOS

The use of this app is pervasive in society here, if you buy/sell anything second-hand, people will expect you to use it and will be surprised, annoyed, and/or suspicious if you prefer to use cash instead.

And this is by far not the only app with these restrictions. Banking apps, streaming services, there are a large number of apps with these restrictions, all under the guise of security concerns. Thankfully most of them have web-based versions or alternatives, but it can present enough of a hurdle that even tech-savvy people either will not or cannot use anything but a recent Android or iOS device.

Almost as bad are websites that would work perfectly well in a mobile browser, but practice "soft" lock-in by condescendingly pointing you towards the official Play Store/App Store if you try to load the site in a mobile browser. Facebook Messenger is a huge and obvious offender here, there is nothing about instant messaging that wouldn't work perfectly well in a browser, after all the desktop version at messenger.com works just fine.

I think you are wrong that Gmail was revolutionary. It was a good service, but nothing special in my opinion.

But yes, the license would allow Google to close the system down whenever they want. Still curious to know how Fuchsia would be a better choice for a system.

Nest seems to be powered by Fuchsia...

Its so weird how fast history is forgotten. Gmail was a galactic leap forward in terms of mail clients. At school there was a grey market to sell gmail invites at 20 dollars per

It really is. Things get comfortable and people assume that's always how it was.

Like cell phones. Wow, over a decade of them and if you had one 15 years ago you were considered a early adapter, and 20 years ago you were way ahead the curve. If you had one in the 90's, wow.

Still, mobile computer in your pocket, wow.

> Still, mobile computer in your pocket, wow.

it really bothers me, you know?

we've got so much storage and so many/good sensors, yet the software kinda pushes you to use the device for watching dumb videos and/or to argue worthlessly with other random people, so that you can get served ads in the meantime.

I dunno, mine sees tons of use as a:

- Calculator

- Bill-paying device

- Flashlight (soooooo much use as a flashlight)

- Thermostat adjuster ("smart" thermostats saved us running a wire for a second-floor zone, so, whatever, we've got them, they're OK)

- Level

- Document scanner

- Note taking/reading device

- Timer (kitchen; any board or party game that has an hourglass that you've misplaced)

- iPod-alike for the car (replaces burned CDs)

- Alarm clock

- Takeout/delivery orderer

- Check depositing device

- Shopping list displayer

- Navigation aid

- Taxi hailer

- Probably other stuff I'm forgetting

I don't think I'm even particularly "in to" using it as much as some people do—I can't bring myself to trust Apple Pay to work, so it doesn't replace my wallet and in fact I think I've only used that feature once ever; I don't really game on it; I read on an e-ink reader or on a huge iPad, not my phone; I don't do any "smart home" stuff aside from the thermostat; my use of Siri is limited to setting reminders and alarms, and putting addresses into navigation to save having to type them; in about a decade of smartphone ownership I think I can count the movies or episodes of something that I've watched on my phone on one hand; I don't do workout tracking or any of that sort of thing.

[EDIT] oh, right, camera, obviously. It replaces the family camera and camcorder of my youth, completely.

What else do you think people ought to do with them? They're pretty small, so e.g. reading a book is a bit difficult, and using them as general purpose computers is difficult because they lack a keyboard (and thus an easy way to program them).

Symbian and PocketPC phones.

> Gmail was a galactic leap forward in terms of mail clients

Only in terms of storage and 'hive mind' spam detection. The UI was pretty shitty, and not much better than Hotmail.

>The UI was pretty shitty, and not much better than Hotmail.

UI performance was great due to early use of ajax. If you had bad connection, which was extremely common in 2000's, then it worked way better than any alternative.

Of course, now it's the other way around, static websites are fast and SPAs can be dogshit slow.

That’s like saying the automobile was only ahead in terms of propulsion, the UI was pretty shitty and not much better than a horse.

Uh, I still use the no-javascript interface in my personal gmail.

it's immensely fast when compared to modern crapware-gmail.

and btw I remember hotmail too... the nicest thing was that you didn't have to refresh the whole page, e-mails just appeared (ajax probably).

and the conversation view, that was really innovative. i mean, mail clients had been doing threading for like forever, but wemail mostly didn't.

Webmail still doesn't.

It does 'grouping' at maximum. Try reading a mailinglist in the gmail webinterface. A reply on a reply should be indented one level, not being shown at the same level as the mail it replies to.

Did you use hotmail? It was absolutely awful.

A gigabyte mailbox space was revolutionary when many competitors only gave 20 megabytes for free (and you could pay and upgrade to 150 megabytes or so).

That was an example where a simple change in a number turned into a qualitatively different service.

IIRC Hotmail was only 2MB at the time of announcement.

Spam blocking was on another level, I've managed setups with e.g. Spamassassin (?) back then and Gmail was something else.

Reading email within a usable UI where you didn't have to download the spam first before it could be sorted was a pretty fucking big deal.

It's still my preferred method of dealing with email to this day. I never want to deal with POP/SMTP local client email ever again.

The storage, the spam filtering, the interface were massive improvements over the status quo of the day.