Google is officially releasing Fuchsia OS, starting with a first-gen Nest Hub | Hacker News Reader

Google is officially releasing Fuchsia OS, starting with a first-gen Nest Hub

9to5google.com

294 pointspanic314 comments

10 years ago I would be really excited, as I could expect some groundbreaking tech like search engine or revolutionary approach to something, like Gmail (no ads sent to users, great UI, hige disk space).

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...

Maybe I am wrong, I hope I am wrong.

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

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.

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...

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.)

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...

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.

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.

I came here for a technical discussion about Fuchsia and it's microkernel approach instead this is mostly fill with complains about Google as a company.

Is there a social justice forum I can visit where I may be able to have a technical discussion about Fuchsia?

I think the discussion cannot be really detached, since Google has strong ambitions that will undeniably influence features and capabilities of their OS.

But as for the microkernel approach, I think the advantages are on the table, but they are theoretical. Until now, no OS with a micro architecture was successful at getting significant market share.

What would your requirements at an OS like this be? For me, it would be extensibility and the minimalist approach.

Don't know the implementation details, but it sounds a lot like a time when people loved OOP too much, or later disliked it just as much.

Look outside of the desktop into embedded platforms.

QNX, Switch OS, INTEGRITY OS, L4.

To a certain extent, all Android OS services after Project Treble.

I work in the embedded area and it is true that these approaches are more successful here. But I think that is due to real pressure for memomy and speed or real time applications. That isn't really the case for general purpose devices like PCs. Those have an unlimited amount of memory and CPU power.

I might try it for embedded devices some day.

The irony is that hypervisors and containers have basically taken away whatever benefits monolithic kernels might have.

OS X and Windows are much better in this regard than GNU/Linux/BSDs with their ongoing efforts to move all drivers to userspace, even though they will never be fully pure microkernels when done with it.

He, true. Although I wonder if microkernels tend to expose more lower level function in user mode that could be relevant to overall system security. The big problem is probably memory access, which would be prohibited in user mode, but maybe there are other security implications (I couldn't answer that question).

Other than improved security that may also be protected by a hypervisor, you might still gain more stability when pushing drivers to user mode. Or your hypervisor has a bug and allows a guest to gain privileged kernel access. Not a security expert, so this is mainly guess work.

>Until now, no OS with a micro architecture was successful at getting significant market share.

Not sure in what sense you mean this. Minix may be the most common OS on the planet. Intel embedded it in an quite a number of its products.

You're for sure not using Minix consciously

For what it's worth, a few Google engineers are hanging around so if you have any specific technical question I think we'd be glad to answer it :-)

Could you say something, how the kernel is different from linux for example? Why would I want to choose Fuchsia for a smartphone, for example. Where is the advantage?

The key concepts are documented here: https://fuchsia.dev/fuchsia-src/concepts

Some things that Fuchsia was able to do thanks to starting from scratch:

- The system is based on capabilities, a security model which is based on explicit tracking of permissions. It wouldn't be possible to change Linux to be capability-based because the ambiant-authority model has been used pervasively since it was conceived 30 years ago.

- Fuchsia provides a stable binary interface (like Windows, but unlike Linux). This lets you update your system while keeping some components unchanged, eg. binary drivers from a hardware manufacturer that wouldn't provide updates for them anymore. I think Linux could technically change this, but they have historically been unwilling to, and it is unlikely to change in the future.

The micro-kernel architecture is definitely a game changer for this, compared to Linux...

Linux tried different things to reload dynamically the drivers & core stuff, without rebooting the computer, but I always had diverse issues after some hours...

Thanks for the link + info :)

> Fuchsia provides a stable binary interface (like Windows, but unlike Linux).

Linux does provide a stable binary interface, to userspace.

> eg. binary drivers from a hardware manufacturer that wouldn't provide updates for them anymore

That can be seen as much as a downside as an upside, because it makes life a lot easier for hardware manufacturers to ship more binary blobs

> That can be seen as much as a downside as an upside, because it makes life a lot easier for hardware manufacturers to ship more binary blobs

Which is essentially the point of this approach for Google, to exert greater control.

- Fuchsia provides a stable binary interface (like Windows, but unlike Linux).

Does it?

Fuchsia is a brand new OS, at least from the perspective of the world. One reason my interest in it died quite early on, despite being an aficionado of new operating system designs my entire life, was finding stuff like this in the docs:

https://fuchsia.dev/fuchsia-src/development/components/v2/mi...

It's brand new and there are already migration guides for core parts of the design. Also:

https://fuchsia.dev/s/results?q=deprecated

That's a lot of deprecated stuff for a project that started with a blank slate.

Well, I think it is no surprise that in the beginning things change. Everytime you do something new and big - you do find things that do not work out as designed. So you change the design. Which is allright for me, with a prerelease.

But now with the official release - I do expect some stability.

Implementing capability-based security in a typical Unix (and thus Linux) is definitely possible, see FreeBSD's Capsicum.

I don't know a lot about Capsicum, but from what I remember (and see from their website) it adds capabilities to FreeBSD but doesn't make them mandatory. As such, it is a tool to build compartimentalized applications. It does not provide a comprehensive solution to sandbox existing applications, and does not remove the ambiant-authority model. It is a better, safer chroot(). Fuchsia, on the other hand, is built on top of capabilities from the ground up, ensuring that you don't even have a concept of "file descriptor" or "centralized filesystem" to begin with.

We have several mailing lists you can converse on. We're happy to answer any technical questions.

https://fuchsia.dev/fuchsia-src/contribute/community/get-inv...

Congrats on the launch! I see iterating on Banjo is still on the roadmap - always more work to do :)

I think the cause of this phenomenon is that most HN readers are not qualified to comment on Fuchsia, are ignorant of any and all facts about it, but are also compelled to comment. So you get this thread, and most threads here. Actual technical exchange between people who are both not obviously wrong is rare here.

I wouldn’t say rare. But yes, the phenomenon you describe definitely takes place quite a lot.

I disagree, I think the state of this discussion thread is about what should be expected given what Fuchsia is and how the project is run.

Firstly, there is little technical discussion of Fuchsia here because there's actually very little to discuss. Fuchsia is, design wise, a pretty ordinary operating system differentiated from Linux mostly by using a microkernel. If you've ever looked at SEL4 then you've got the gist of what's going on here. I'm not aware of any obvious ways Zircon differs from any other microkernel design. Like all such systems it has an inter-component RPC layer (called FIDL) which if you've ever used the Android Binder will look familiar. And it's got a component system. In some ways these upper layers are reminiscent of COM and the whole OS has a bit of a Windows NT 3.1 architectural vibe. That's about all there is to say on the matter.

Fuschia is an oddly unambitious platform. Here's a representative quote from the docs:

"There is no concept of inter-package dependencies because transitive dependency closures have unbounded resolution time"

This statement is technically correct but practically incorrect: when users complain about dependency resolving package managers, they are complaining about out of date packages, broken dependency graphs, centralized repositories and other things. The fact that dependency resolution can be NP-complete in artificially constructed worst case scenarios never comes up because in the real world, dependency resolution takes a few seconds and the problems surface elsewhere. But they found an excuse to avoid doing anything hard or new in the world of software distribution, so they took it.

Elsewhere people promote its ABI stability compared to Linux. Maybe, but this is Google we're talking about. Constantly obsoleting stuff is literally built into their incentive structures, so we should double check that right?

https://fuchsia.dev/s/results?q=deprecated

120 results for deprecated already! Nobody even uses this OS yet and they already changed their mind about APIs all over the place.

The same lack of ambition is visible if we look at the Architectural Principles section of their site. Their principles are: "Secure, Updatable, Inclusive, Pragmatic". That's it. "Secure because capabilities" is a very old discussion with not much to add, and the rest is vague or just not that interesting.

Those principles brings us to the final reason the HN discussion is so lacking in technical depth.

The OP complains that the discussion here is all about politics and wonders in jest if there's a social justice forum where they might find technical discussion of the project. Amusingly the OP's wish is easily satisfied by the Fuschia website itself. Fuschia is by far and away the most ideologically biased operating system project you will have ever had the misfortune to encounter. It is something the world has never seen before, an entire operating system controlled by the hard left. Every single page in the docs has a giant banner across the top saying "Google is committed to advancing racial equity for Black communities". Note the demand for equity, not equal opportunity. Classical liberalism is dead here, tokenism is in. Of only 4 so-called architectural principles one of them is "Inclusive". They make a brave effort to pretend this is actually about technology by claiming that being just a microkernel+RPC is inclusive because they don't provide any language runtimes for the users (i.e. spinning missing features as a form of moral purity). Then it all falls apart and they go back to talking reducing harm and bias via language control - another tenet of hard left thinking.

So let's imagine we're looking for something better, fresher, bolder than Linux, macOS or Windows. We look at Fuschia. What we see is an extremely conservative OS design in which the most modern ideas in it pre-date Linux itself. We see an overwhelmingly political project, run by a company that has in the last year been systematically erasing from its platform crazy wack-jobs like, er, doctors and professors simply because they disagreed with the WHO. And we see that there's no discussion, anywhere, of any features that end users might actually care about.

That's why there's no discussion of technology in this thread.

Googlers thinking non-Googlers are unqualified to comment on anything seems like a fairly common theme to me.

I really wonder what caused this kind of ideological entitlement. Was it a company culture that never said "no"? Was it the constant talk of how Googlers are just smarter and more brilliant than everyone else? Genuinely curious.

It was the part where people decided to ignore what was actually being presented, and instead derailed every possible conversation about google into their predetermined track. Not you specifically, but this entire fuschia thread.

What is someone to think when every time their work is presented publicly the comments are all completed unrelated to what was presented? You too would conclude that group is unlikely to present meaningful feedback or thoughts.

(I have never, and will never, work for google).

I agree, actually, but that's fundamentally different from saying people aren't "qualified".

Perhaps it would useful for Google and googlers to "read the room" - as it were - and consider why a lot of people have such strong reactions to Google's conduct and methods, why a lot of people are distrustful of anything that comes out of Google (and FAANG in general), and why the reactions are so strong from privacy advocates and the open source/free software crowd in particular, in context of where and how Google started and where it is now.

I'm not sure what you are suggesting here. Should the developers that work on specific input methods for fuscia be "reading the room" and instead spend their time switching to work on ad tech, where they can influence it? Google has 10's of thousands of engineers, wedging ad tech discussions into the output of every last one of them seems completely and utterly unrelated to the article.

Ways to become qualified to comment on fuchsia are as simple as using it or reading its source code or docs.

Hacker News is still the best place for such discussions. There's just a lot of low-effort noise from people who force every topic to conform to their existing knowledge areas.

> Hacker News is still the best place for such discussions

In general it is, but I too have noticed this trend more specifically in Google-related threads. Most other subjects don't suffer from this as much, but almost every Google one devolves into jokes about when X will be canceled.

It should at the very least tell you how aggressively google has been burning its goodwill as of late.

Google offers things with the left hand while slapping you with the right and you seem surprised that people only want to talk about the slapping.

Has anyone done a comparison with Minix 3? What are the (dis)advantages to a new microkernel rather than building on Minix 3?

Fuschia forums? People are discussing the news of a new OS release and its implications.

Please post your thoughts and questions about Fuchsia!

I wonder where Fuchsia will be in 5-10 years. Will it thrive? If so, in what space will it thrive?

There’s no clear line here - it’s systems all the way down.

When a new component is added to the critical path, its vital to ask “What happens if my account gets flagged? How much of my life can Google shut down with a single bit flip?”

The personal is political. And the technical is political.

You cannot separate a work from the context in which it operates.

And flooding every conversation with your political agenda so none else can discuss any other topics is abusive.

The above was edent's only comment. It's abusive if it's an organized effort, which it is not.

>You cannot separate a work from the context in which it operates.

Why not try?

Because I have a conscience.

A little hyperbolic, don't you think? If you're writing Fuchsia OS, then you don't a conscience?

That's clearly not what I said. I was responding directly to my parent comment which said we should try to separate a work from the context in which it operates. It was not a value statement on Fuchsia OS, anyone who worked on it, or anyone on Google. It was simply a statement on separating work from the context in which it operates.

>It was not a value statement on Fuchsia OS, anyone who worked on it, or anyone on Google.

This thread is about Fuchsia OS - so you're separating your statement from the context in which it operates?

Why would you choose to pretend you know less than you do?

Things are made by people and each individual person has their own background, circumstances and ideas. The culture of Bell Labs abetted (but did not cause) Unix and the sharing of source code. The lack of pressure to generate profit within Bell allowed Unix to use an unusual licensing model, which led to it being widely available in universities.

Context does not totalize - it allows and directs. Google has a business plan and a culture that promotes some things and prevents others. It's not a conspiracy - they're quite public about most of it. There are things that are possible at Google that are less possible elsewhere. We can, as participants and observers in culture, speculate about what is more possible and less possible in a Google OS project. To not do so would be blindfolding ourselves.

If you want to talk about something "outside" of its cultural context (if such a thing is possible), you certainly can - but will your conversation partners set the same things outside the context? Better to be explicit than blindly implicit imo.

"Because, I don't want for it to be good, because its Google, but it probably is."

That's what I have going in my mind and it's going to color any of my opinions on it, no matter how how objective I try to be.

So I think It's important to discuss this openly, so we know where we are at.

Looks like there is a growing minority of tech people who distrust Google and I am among them.

Minority? I feel like i can't read anything about google on HN without half the converstion being unrelated to the technology and strictly related to ads. The minority are the people that think "wow cool, another new shiny toy to investigate!".

HN is minority of tech people, and even on HN not everyone share same opinion, I doubt it's even 50%.

Because then work just becomes a more boring riff on the Nuremberg defense. You can't just be like "I'm just paid to write code and so will completely ignore any and all ethical issues with what my company does with it."

There's a reason the ACM code of ethics has "everyone is a stakeholder" and "avoid harm" as the top two overriding principles.

I can understand arguments about keeping political issues unrelated to your work and working relationships out but you this isn't that.

>Because then work just becomes a more boring riff on the Nuremberg defense.

Writing code to build Fuchsia OS does not involve great violations of morality and ethics that call out for something like the 'Nuremberg defense'.

>I can understand arguments about keeping political issues unrelated to your work and working relationships out but you this isn't that.

Where's the dividing line? Wasn't it Basecamp that had a large portion of their workforce quit because they couldn't be activists at work? Was that them mitigating the 'Nuremberg defense'? What about the recent issue with a principle of an elementary schools calling on parents to boycott Israel [1].

There are very few jobs in modern America that have these great ethical dilemmas. There are, however, plenty of people that are willing to engage in hyperbole and politicize every space they can. That's a much bigger problem.

[1]https://nypost.com/2021/05/24/nyc-principal-apologizes-for-a...

> Writing code to build Fuchsia OS does not involve great violations of morality and ethics that call out for something like the 'Nuremberg defense'.

Respectfully, while I don't think that Fuchsia warrants invoking the Nuremberg, I do think that it is highly likely to enable violations of morality and ethics down the line. The way I see Fuchsia, it's basically an effort to undermine the Linux kernel and switch it out for something with an MIT-style license. I see this as objectively immoral.

Linux is the de-facto open source kernel for the majority of people, and the fact that the open source kernel uses GPL (which strongly prefers end user freedoms) is one of the few things that holds the tide of privacy violations, user disempowerment and proprietary tech capture of our infrastructure, institutions and societal conventions. A world without a strong GPL base is a morass that drags down useful developments.

Quite frankly, I see no reason for Fuchsia to exist, and plenty of reasons why it shouldn't exist (not least because Google is in control). It should be boycotted. The society will be better off for it, though it may make a few billionaires cry.

You’re doing exactly what you condemn in your post. I said a boring riff specifically because I wanted to highlight that there’s a huge magnitude difference while being able to use the most common term for the particular line of reasoning.

You’re right, writing an OS for Google isn’t some world shaking ethical conundrum and it certainly wouldn’t be enough to turn down a FAANG salary and the experience for. But that doesn’t mean that the company’s corporate strategy for the product (i.e. the entire reason the project is funded) is suddenly irrelevant and you can wash your hands of it. If the business reason for pushing this OS is so that Google can have a desktop OS with lock-in to their services and have data collection at the deepest level like they do with Android then that doesn’t meet the bar for avoiding harm and that as engineers we ought to be empowered to push back or outright say no to to buildings things that hurt our users.

Nothing about this has anything to do with Israel or Pizzagate, or Black Lives Matter. Politics encompasses far far more than the things you see on CNN. I’m not saying that people should be advocating for random political causes they care about in the workplace. I’m saying that people should be able to act politically for things that are literally their work.

* Pushing for accessibility features being a requirement to ship is political.

* Pushing for telemetry to be anonymized is political.

* Pushing for ML datasets to include people with dark skin so they actually work is political.

* Pushing for data collection being opt-in is political.

* Refusing to build a product that interferes with EMT radio frequencies is political.

it's ok

there's dont be evil

Unfortunately, every new project coming from Google now has a couple of decades of baggage, directly caused by the unexpected / manipulative cancellation of projects.

While I am not Google-free at the moment, especially email, I have long ago learned to avoid trusting any Google product to stay stable, or even available.

And that doesn't even scratch the surface of the decades of "everything we do is tuned to collect as much data as we can steal without getting caught, and using it to our benefit in any way we can hide from you, our users."

Cynicism is pretty much the norm now, and is going to color everything Google does forever.

I'm sure there are forums and github sites with actual technical details, but that's only a fraction of what gets traded here. YMMV.

I've only recently started fiddling with Fuchsia and I'd be interested to see it running on a device and see how truly usable it could be in the real world. It seems the community is pretty active online which is a good thing: I raised a concern about building Fuchsia on non-Debian based distros and potential solutions(one of which I tested and workes) and I had 4 or 5 replies in a couple of hours. And while the thread has turned into yet another "bash Google" thread, I'd like to thank the engineers for their work and hoping to see more in the future. As I said I haven't tested it on an actual device but if it is as lightweight and versatile as advertised, it has the potential to become incredibly big and valuable. I guess only time will tell.

Around December or January I tried to get Fuchsia going in QEMU to play around a bit and maybe contribute back some code, but nothing quite worked as I expected. Based on this experience I had figured they were still years off from shipping but I'm pleasantly surprised to see that I was (obviously) wrong.

Congrats to the team and looking forward to seeing it work as intended!

If you're willing to give it another go, you should try it in FEMU (our fork of QEMU): https://fuchsia.dev/fuchsia-src/get-started/set_up_femu

Something should be particularly wrong with the project if you have to use your own fork of qemu...

It's actually pretty standard to fork QEMU when you want to emulate a custom kernel/board. QEMU is a good common emulation platform, but in no way it can emulate correctly every quirks of a custom pci or even PIC device expected by the system.

I'm not expert in QEMU, but to my understanding, it would make sense to fork QEMU to support a new hardware/board/platform, but not so much to support a new "software"/"firmware" on top of an already existing and used board platform.

Why did Google choose to fork QEMU?

I had a brief look at the setup information and there’s nothing that makes it clear why there’s yet another piece of highly Google-specific (though presumably open source) software that people would need to learn to use while they learn about Fuschia.

FEMU is really AEMU, it forked from QEMU many years ago for a variety of reasons.

Today this configuration offers Vulkan support, which will hopefully make it's way back to QEMU eventually.

We use both QEMU and FEMU in our work, if you checkout Fuchsia you will find prebuilts of both in //prebuilt. QEMU provides broader control over hardware and broader emulation features, often useful to the kernel and driver teams. FEMU provides Vulkan graphics, more useful for teams working on GUI applications.

Any pointers to any hardware / dev boards that one can run fuchsia on? I remember seeing Intel NUCs being used in the past, is there a recommended hardware configuration for developers now?

https://fuchsia.dev/fuchsia-src/development/hardware/intel_n... describes which NUCs are known to work.

Thank you!

Not to discredit the effort, but saying you've released your own fork of QEMU to run your own OS, creates an impression that you're perfectly happy to (prefer to?) create a parallel universe for yourself, with your own tools and its own ecosystem... Which will obviously all be controlled by Google. Not very good optics, IMO.

If you want promote Fuschia as a useful, general purpose computing platform (and not just an attempt for Google to avoid the GPL), you probably want to work upstream with existing projects to improve support generally instead of creating your own suite of forks.

As raggi mentioned above, you can use both.

The additional feature that FEMU provides us is Vulkan support, which allows you to interact with a GUI.

On the team, we use both. For example, I know many folks on the Zircon team prefer vanilla QEMU.

Yet Google's Browser engine is a fork of WebKit and surprise it is used in Chrome, Electron and QtWebEngine and everyone is using it.

As Fuchsia is highly dependent on Flutter and the whole ecosystem will be able to run Flutter apps on day 1, I would bet that this is going to be the Android replacement in this decade.

This is how old google would have worked. Now that google is all grown up they take a more cost conscious approach. How the mighty have not so much fallen, as sunk.

Why the down votes ? Perfectly polite and mostly valid comment.

I'm almost more excited because of the proxy network affect this will have on microkernel popularization and alternatives like Dahlia OS (https://dahliaos.io/) that are looking to be independent distros of Fuchsia.

I understand peoples concern about a walled garden situation here, but I'd argue to only become worried if Fuchsia suddenly stopped being committed to openly and someone needed to maintain a fork. The working code for both the microkernel and the OS is all open source.

What is interesting about Fuchsia is how Google first created Flutter and made it popular for Android/iOS and to a lesser extent the web. And now they start releasing Fuchsia OS/devices and developing apps/software for it will immediately feel familiar to many mobile developers.

This could help adoption instead of yet another GUI framework to learn from scratch.

Huawei is doing the same kind of approach, make android apps compatible with their Harmony system. I think everybody has learned from Microsoft and Samsung's experience trying to launch a new ecosystem without support for current application android ecosystems.

FWIW Harmony OS is just an AOSP skin.

Similarly, free software running on proprietary Unix OSes became (during the years 1983 through 1991) very popular before any free Unix kernel started getting traction.

Congratulations to the team, this is a big milestone. I worry that this will permit Google to disengage from the linux community, but I'm optimistic that it will result in improved device security.

This is exciting to see (in a neutral way, I'm not rooting for it) because I wonder how large fuchsia will grow and if it will contend with Linux. Why wouldn't Google want to push containers running it's brand spanking new os without 30+ years of cruft on gcp. And if it has performance/security why wouldn't developers start moving over.

It's aimed at the opposite end from GCP, aimed at things like phones, tablets, and laptops.

fwiw, I got us booting on GCE years ago, and the scripts may still work.

https://cs.opensource.google/fuchsia/fuchsia/+/main:scripts/...

"permission denied"

https://fuchsia.googlesource.com/fuchsia/+/main/scripts/gce may work better. I will ask around if there's something up with some ACLs in code search, it seems to work for me on personal machines and incognito.

> without 30+ years of cruft

AKA learned experience

Learned experience for long-lived multi-user systems running on heterogenous hardware, of questionable relevance to today's landscape.

That’s true. But unfortunately all that baggage comes with lots of genuinely useful stuff too. Starting from scratch rarely works, unless you’re willing to put in a lot of time and effort, and are in it for the long haul, and people that want to start from scratch rarely are, and google doesn’t have a good track record in these matters either.

They have an OS running on a consumer device that connects to the wifi where you can play media, browse the web, and run flutter apps, so it seems like they already put the time and effort.

It even self-updates, so in some sense it's already ahead of the standard linux distributions!

> They have an OS running on a consumer device

I read this as "prototype".

Which standard distribution are you running that doesn't self-update? All of the ones I use (Fedora, Centos, Debian, Ubuntu, Qubes) do this and have done for years.

Normally I'd agree about Googles track record. But they HAVE to innovate in the android/mobile space. It would be their death as opposed to just dropping a random messaging app.

And they did all the "from scratch" work. It would be short sighted to not let zircon at least have the potential to replace Linux.

Apple vertical integration strategy recently took a big step forward and googles response may well be this.

> And they did all the "from scratch" work.

We should judge on what has been finished rather than what has been started. After people start to work with it, that's when the real costs will start to be incurred.

Apple are an interesting case in that they have done this very very gradually over many many years - building on top of existing tried and tested platforms where possible.

Google seem to be dominant in android/mobile despite their crappy OS. Whether they're threatened or not, this does need to be improved. This may or may not be due to Linux - to me it seems to be more the case that it's again their failure to stick to things that's the most frustrating aspect of using Android - but maybe using Linux means they spend more development time doing that than dealing with features. Perhaps they're just trying to emulate Apple's strategy alá cargo cult.

Hmm, looks like Fuchsia still uses Dart/Flutter for the front end. My experiences have been positive (although I’m sure someone will be happy to explain how my opinion of Flutter is wrong) so I’m glad to see it.

I'll gladly come in with the other end of the argument :)

Dart? A half-baked language with quite a lot of unexpected gotchas that can cause you to lose days trying to find why something isn't working (only to notice a lib author forgot to add a return for one branch of the code, or the code works differently depending on what runtime it's on).

The Flutter ecosystem is constantly breaking, the plugin system was broken for at least a year and "in migration" where most of the stuff you do is either "broken for future" or "is going to be broken in future". Dependencies are in a circular hell where updating one thing might make you update the whole project, but then your project might not be compatible with the current Flutter version so you'll have to nuke your directories and call 'flutter create' again in the project so it recreates stuff with the new templates.

Also don't get me started on issues. Had a crash span for over 6+ months on all devices with low-budget Adreno GPU-s, most of the issues were "closed automatically" because of inactivity or because they declared it does not follow the template google requires for the issue, altho there is dozens of them reported, they held a hotfix for months on end in a branch with other changes because it was " a lot of work" to merge it downstream. Had a talk with the Flutter team about reconnecting to isolates on one conf, one dev's answer was "oh yea that's problematic, maybe just the best is for the user to restart the app".

It's classic Google behaviour wrapped in a "new cool thing" package.

Flutter is a great thing if you wanna build a cheap app fast and never worry with maintaining it ever again. If you're going for something long-term, avoid it like plague.

So your complaints seem to be that it’s still under development in some areas like null safety and types. Yes, new things get updates.

Dart / Flutter is nice, the problems with it back in the day were mostly just the fact that it was (previously) competing with JavaScript on the front-end.

Congrats to the Fuschia/Zircon team! It's very exciting to see a freshly-architected OS appear on the scene, with a non-copyleft license, a big company behind it (so hardware vendors will actually write drivers for it), and direction set by one company (instead of 10+ as is the case with Linux/Android). Can't wait to play around with it :-)

according to ars technica [1] they removed the ui layer from the repo... is that accurate and does that mean we are in for a macos type situation where the real treasure (the ui bits) are locked away?

[1] https://arstechnica.com/gadgets/2021/05/google-launches-its-...

What problem does Fuchsia solve? Google already has at least three other operating systems to use.

On the other hand, Google has never seemed particularly shy about starting something new rather than work on something old. I'm thinking of their messaging systems that they start every couple of years.

Also, the branding isn't great. The top image in the linked story immediately makes me think this has something to do with T-Mobile.

It's capability based, so instead of this weird hodgepodge we have in the Linux world that resulted in Docker containers it's natively a part of the OS design.

Also its not GPL, so we will see actual binary drivers instead of GPL <> proprietary shims in Linux that need to be recompiled on kernel upgrade.

So it solves a lot of problems for Google and can replace Android/Chrome OS/Cast OS.

> Also its not GPL, so we will see actual binary drivers instead of GPL <> proprietary shims in Linux that need to be recompiled on kernel upgrade.

That could be prevented by hardware manufacturers manning up and releasing their source code in full. If the community cared about that hardware, it'd eventually get upstreamed into the kernel, or at least actively maintained as a patchset.

I also believe there's significant chunks, like the network stack, written in memory-safe languages like Rust. An improvement over C.

They haven't worked on the base stuff of Android and ChromeOS. Both use Linux software abandoned by upstream, e.g. ChromeOS uses upstart and have their patched non-mainline kernels. This requires lots of extra work, then even doubled since they have 2 platforms. Wanting to have one mature platform for both makes sense to me.

My wild guess is it reduces the amount of privileged code. In Linux the entire kernel (all 20 million lines of it), can do what it damned well pleases, and auditing 20M lines of code is mission impossible. You could think of it in terms of Windows/OSX/Linux Distro vs Android / iOS / WinPhone. In the former, this is nothing stopping one application stomping over anothers data. The result has been endless uninstallable viruses and malware. The latter force complete almost isolation between applications. What interaction does happen occurs over interfaces that are very heavily policed by the OS (think: is generally doesn't happen without the user giving some permission). The result has been a revolution: almost no one bothers with anti virus software on the phone OS's any more, and any malware you do install can be uninstalled with the click of a button.

Fuschsia, being a micro kernel, puts each functional unit (device driver, network protocol driver, file system, crypto functions, yada yada) into its own isolated process, so the damage a rogue function unit can do is more limited. Interaction between functional units must happen via the Fuschsia kernel (they can't talk directly), and surprise surprise Fuschsia heavily polices those interactions using the "capabilities" provided by the kernel. Capabilities are are very similar to user assigned permissions.

That seems obvious and attractive, but keeping those processes isolated and policing those permissions incurs a overhead, or perhaps more accurately the cost of communication between two isolated processes is much higher than non-isolated (think processes communicating with pipes vs memory sharing threads). In Linux that overhead is still visible as the syscall overhead, which is large enough that high performance applications go out of their way to avoid it. io_uring is another attempt to avoid it. Microkernels multiplies that overhead by many times. Possibly worse, that overhead is getting worse with the advent of spectre like cache timing attacks forcing cache's to be invalidated on a context switch.

In my very brief look at Fuschsia is looked refreshingly clean, small and well thought out. But then all many projects do. Sadly it started like as a C++ code that is now moving towards (as in is now 50%) Rust. To be true to it's safety goals it should all be Rust. And it doesn't seem to bring much new stuff to the table. seL4 has been in the same space for the same reasons for years how. So I don't see how Fuschsia's introduction will change the basic equation that's lead to the dominance of monolithic kernels.

What both seL4 and Fuschsia both desperately need is some magical hardware solution to "isolated process communication" overhead, one that also addresses spectre. Mind you, if a way to isolate code with bugger all overhead came along, it's so attractive I suspect they would be in a race with the existing monolithic kernels to exploit it.

> What interaction does happen occurs over interfaces that are very heavily policed by the OS (think: is generally doesn't happen without the user giving some permission). The result has been a revolution: almost no one bothers with anti virus software on the phone OS's any more, and any malware you do install can be uninstalled with the click of a button.

Taken to its extremes (which Google has been moving Android towards), unfortunately it also breaks a number of existing workflows.

If you follow the documentation, any multi-file formats (HTML documents with their assorted resources – JS/CSS/images/links to other HTML files/..., playlists, videos with externally stored subtitles, multi-part archives, ...) are broken on recent Android versions if you need to handle them in an external app, e.g. if you're writing a file explorer which then naturally needs to call out to other installed apps for actually opening those files.

Would this solve the extreme UI lag and make google hub finally useable?

It really depends on the polish of Fuchsia for Nest Hubs. Getting a few more FPS out of the 1st gen hardware is something I'm actually hoping for because it's gotten really slow and I rarily touch the screen anymore because of the lag.

Seriously, this device is only a few years old and it runs like a 2013 windows netbook. Apps crash all the time, bluetooth glitches, unresponsive UI, etc.

A big success for Rust in the wild

By that metric JSON is the clear winner but that's not the case, its a win for Rust and also for C, C++, Dart, GO, Python and many more.

  ───────────────────────────────────────────────────────────────────────────────
  Language                 Files     Lines   Blanks  Comments     Code Complexity
  ───────────────────────────────────────────────────────────────────────────────
  Rust                     10640   3126941   295777    480090  2351074     125641
  C++                       8744   2025857   318786    180185  1526886     174494
  C Header                  7293    894250   148795    199271   546184      18621
  GN                        5014    303531    38062     39284   226185       6367
  Go                        2873    800205    75566    113344   611295      87456
  Markdown                  2648    288903    74633         0   214270          0
  C                         1708    365017    49446     53285   262286      46408
  JSON                      1305   4454311       82         0  4454229          0
  FIDL                      1303     94290    13433     43888    36969          0
  Dart                       606     69163     9153     10205    49805       4425
  License                    545     21628     3271         0    18357          0
  YAML                       421     10036      784      1882     7370          0
  Plain Text                 368    127457    14426         0   113031          0
  Python                     352     56456     4845      5083    46528       4096
  Assembly                   301    128989    12067         0   116922        828
  Shell                      281     24032     3022      4754    16256       1971
  BASH                       234     22508     2795      4752    14961       2117
  TOML                        65      4043      198        90     3755          1
  JavaScript                  56     33445     1768       855    30822       3695
  GLSL                        51     12951     2347      4386     6218        756
  SVG                         48      8543        1         2     8540          0
  gitignore                   43       388       31        69      288          0
  Perl                        41     48582     3874      4185    40523        858
  Handlebars                  31       556       41         4      511         18
  Mako                        31      1453      174         0     1279         49
  XML                         31      1473       16       129     1328          0
  Protocol Buffers            28      5160     1068      1562     2530          0
  HTML                        19       882       40        12      830          0
  Makefile                    18       527      107        34      386         24
  Bazel                       17      1493      131       170     1192         37
  Dockerfile                  17       248       33        19      196         18
  C++ Header                  14     10691      214       206    10271        103
  CSV                         13    140350        0         0   140350          0
  Autoconf                    12       910       34        32      844          7
  ReStructuredText            11      1969      659         0     1310          0
  Vim Script                  10       428       65         0      363         31
  Device Tree                  9       246       32        43      171          0
  Go Template                  7       521       80         0      441          5
  Module-Definition            5       176       23         0      153          4
  Smarty Template              5        74       24         0       50          5
  CMake                        4       396       45       123      228         38
  CSS                          4       387       51        13      323          0
  JSX                          3       355       15        39      301          0
  Patch                        3      2591      105         0     2486          0
  Scala                        3        80       13         0       67          3
  Fish                         2       140       16        40       84         18
  LD Script                    2       122        4        10      108          0
  PHP                          2         4        1         0        3          0
  AWK                          1        97       14         4       79          0
  Batch                        1        23        3         0       20          2
  Emacs Lisp                   1        71       14        12       45          2
  Meson                        1        12        3         0        9          0
  Nix                          1         7        1         0        6          0
  Prolog                       1        45       11         0       34          0
  ───────────────────────────────────────────────────────────────────────────────
  Total                    45247  13093013  1076199   1148062 10868752     478098
  ───────────────────────────────────────────────────────────────────────────────
  Estimated Cost to Develop (organic) $467,287,312
  Estimated Schedule Effort (organic) 142.185717 months
  Estimated People Required (organic) 291.973834
  ───────────────────────────────────────────────────────────────────────────────
  Processed 437275620 bytes, 437.276 megabytes (SI)
  ───────────────────────────────────────────────────────────────────────────────

    Estimated Cost to Develop (organic) $467,287,312
    Estimated Schedule Effort (organic) 142.185717 months
    Estimated People Required (organic) 291.973834

Where does this come from? Does cloc now try to estimate how much time/money would be required to build software?

I'd be interested what it thinks of my code. Do you have to give it a lot of code for these numbers to appear?

That's probably sloccount or scc, not cloc.

At least for sloccount, the cost/effort estimation model has very little to do with reality in the modern world though.

I’m 99% sure it’s mostly C and C++

Fuchsia has a lot of Rust code. (Disclosure: I write Rust code for Fuchsia on a daily basis.)

CLOC says about ~1 MLOC of Rust and ~1.1 MLOC of C++ in https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...

I'd still call this a success for rust in the wild, if a huge entrenched company like Google would include it so much for a big OS play, even if it shares that room with more established languages.

There are many ways to cut metrics, but here's some line counts:

C 365017 C Header 894250 CMake 396 C++ 2025857 C++ Header 10691 Rust 3124869

Being these two the most important functions [1], [2].

The rest is merely overhead :)

[1] https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z...

[2] https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z...

I am planning on not purchasing any new google smart home hardware. I am annoyed that my nest thermostat no longer has a way to interface with their API. I purchased it right before the Google acquisition and I would have gone with an Ecobee if I knew the Nest would be inaccessible to a regular user.

I believe having an open API is an important part of smart home hardware, even if most users don't use it.

This doesn't have anything to do with Fuchsia though.

Does anyone know if Fuchsia, or any higher-level environment built on top of it like this new software for the Nest Hub, includes a screen reader for blind users? This will be necessary before Fuchsia can be considered a full replacement for Android, Chromium OS, etc.

Yes, Nest displays have a screen reader feature: https://support.google.com/googlenest/answer/9167457

As explained in the article, the release of Fuchsia should not change any supported feature (please report a bug via the "send feedback" option if you notice otherwise!).

Thanks for the response. I know what the article said, but I also tend to assume that accessibility will be overlooked or treated as not very important.

I'm tempted to buy a first-generation Nest Hub, maybe off eBay, to find out for myself.

Having a smart speaker with a display doesn't make sense for a bling person imao.

It might make sense for a blind person with sighted family and friends.

Given that this describes my family and we have a first gen Nest Hub I expect to be able to soon report whether Fushcia is as accessible as the prior Linux stack.

Thanks. If you find that there's a regression in accessibility with this update, I'd appreciate it if you would email me (my email address is in my HN profile), to make sure I get the message even if I forget to check this thread, so I can help sound the alarm.

Yes, the Home Hub includes both a screen reader and touch exploration mode.

I can't say I've ever thought about the OS on my Nest Hub. It's a digital picture frame, and it plays YouTubeTV/Music while I'm in the kitchen. It occasionally answers a question - what will this new OS change?

> What will this new OS change?

Nothing, this release is a field test.

Google has officially outdid itself in under-marketing a major platform.

A brand new OS, and... barely anything even on hacker news. No barrage of media leading up to the annoucement.

Is this basically a boondoggle being relegated to IoT?

The badbadbad part is that this won't be open, and it'll force adoption of restricted hardware that will no longer be usable by the AOSP. Prolly 5 years out, but still; pour one out for unlocked Android-compatible hardware at any price. Gonna hafta go full tinfoil hat and get a PinePhone.

What I really wanted to know:

https://www.quora.com/What-is-the-difference-between-the-col...

(not much)

Its just a attack on linux. Just like what they did to firefox. Made a superior browser and make it opensource and gain monopoly.

Now they have control over os. They can do anything.

Wake me up when they do that "anything". In the mean time they've created useful and successful open-source products which anyone can benefit from.

You must have not noticed that Chrome is the new IE, or that they recently revoked API keys that open source Chromium forks (including ones that just disable certain features, so they are 99% the same as official Chrome) have been using for years to allow them to sync bookmarks and the like.

> "Chrome is the new IE"

Safari is the new IE. It's stagnated in the same way IE did, which has slowed the progression of web standards. How long did it take to get input type="date"?

Apple's attack on PWAs also shows they wish to neuter the web to encourage use of their app store (where they take a 30% cut) instead.

> "or that they recently revoked API keys..."

The code is open-source, but they aren't obligated to grant access to their services.

> Safari is the new IE. It's stagnated in the same way IE did, which has slowed the progression of web standards.

Chrome is not like IE in that it stagnates the web. It's like IE in that it reinforces the dominance of nearly the entire web by a single company - Google.

Chrome, also much like IE, has a stranglehold on what makes it into new web standards and what doesn't. That the web standards are technically open is irrelevant, if Google de-facto rules the whole standardisation process. What they decide goes, goes. What they decide doesn't go, doesn't. The W3C standards process is neutered at best, and corrupt at worst.

Hypothetically, even if they weren't the dominant W3C stakeholder, their market share gives them control over the experience and control of an enormous amount of users. They can trial and enforce FLoC, Manifest v3, and other changes that take away user control. Once user expectations get readjusted, culture around such toxic features shifts and they become acceptable. I'd be surprised if that's the end of it.

Some websites only get tested on/built for Chrome ("works best with IE"), because "everyone only uses, develops and tests on Chrome anyways". Non-Webkit/Blink browsers are collateral damage. Most webby runtimes like Electron, and most third party browsers, will also embed some variant of Blink these days. This leads to browser engine monoculture, and is capital-B Bad. Firefox managed to outmanouver IE by being bug-for-bug compatible enough, but these days, web standards are two orders of magnitude or more complex. The effort needed to build a new, compatible browser engine is more akin to building something like Wine[0] from scratch.

[0] winehq.org

> The code is open-source, but they aren't obligated to grant access to their services.

Of course they aren't. But this is after letting open source projects do it for years. What changed now, all of a sudden? Besides, the open browsers that are more-or-less straight-up Chromium forks usually are not materially different. Just a different logo and maybe some telemetry ripped out, big deal. The kind of person that uses Google sync in a fork is the kind of person who already's in deep into the Google ecosystem. They really don't have a reason NOT to let people use FOSS-specific API keys, especially since any abuse they might get because of these is so miniscule it's not worth mentioning.

And yanked them out from underneath the adopters whenever it wasn't fun anymore.

I don't trust in anything Google anymore except that internal politics and profit motive will override anything beneficial eventually. Look at Chrome if you're not sure what I mean.

Yea I can see that with chrome. They created useful in that time that any opensource benefit others. After that they started writing their own spec for chrome, made youtube slow on firefox using shadow dom api etc.

These I think google is more evil that microsoft. But many people enjoy free service thats why they are not complaining.

Which architectures have fuchsia ports? And what cpu feature/device support is needed to port fuchsia?

x64 and arm64

https://fuchsia.dev/fuchsia-src/concepts/architecture/archit...

imagine releasing a new OS in 2021 written largely in a non-memory-safe language.

Modern C++ is memory safe. More so than (unsafe) rust. Also, this OS was not started in 2021..

What's the community-driven alternative?

There is no other micro kernel OS being developed with similar effort.

There is seL4: https://sel4.systems/

The resources going into seL4 appear to be nowhere near "similar effort" to what Google is putting into Fuchsia, but it is a legitimate alternative.

Sadly CSIRO axed entire seL4 team, "to focus on AI".

Sadly yes, but it only happened after seL4 Foundation[0] was established, and thus seL4 became independent from CSIRO.

[0]: https://sel4.systems/

GNU Hurd will be released any time now!

/s?

Nooo, completely serious!

https://www.linuxfoundation.org/en/blog/the-power-of-zephyr-...

Linux

This is the correct answer. Do not allow a subtly different technical design distract you from the largest switcheroo here: this is a single-vendor enterprise OS delivered under the guise of open source, it comes with all the trappings of a single-vendor enterprise OS.

Let's not be too quick to forget when Android first started out, all the idealism about the wonders of a free software mobile OS. A decade later, it's almost impossible to buy an Android phone that hasn't been strongarmed (no pun intended) into including Play Services, Chrome and Gmail, often including through threats to the manufacturer's unrelated businesses.

We're older and wiser, avoid this garbage like the plague, and don't fall for all the same old tricks.

Android would be dead in the water today if it wasn't for Play Services. Developing for Android is still painful today because but Play Services at least meant that you could expect a certain range of features spanning multiple major releases of Android.

I'm pretty sure that Play Services wasn't something Google really wanted to have but were forced to implement because so many OEMs just shit the bed w/r/t their Android forks.

Only because they didn't licensed Android in a way that would have prevented that in first place, nor have proper clauses on their Play Store contracts.

Yes, although at least both Android and Fuchsia are released under genuinely open source licenses, even if they development model isn't open.

These licenses are totally meaningless when Google make anti-competitive threats to their partners for attempting to exercise that license. They benefit from all the marketing of their vendor ecosystem in the public eye using the open thing, while quietly holding a gun to everyone's head in the background. That is the absolute antithesis of what "genuine open source" is supposed to be about, it is a marketing ruse and you've fallen for it.

I have a Pixel phone and run GrapheneOS on it. No Play Services, no Google apps, only open source software from F-Droid. Works really well.

That is because you are clearly a Computer person. The average person has their entire digital life owned by Google.

Genode[0], which you can follow on the Genodians[1] blog.

[0]: https://genode.org/

[1]: https://genodians.org/

I guess GNU Hurd [1], jokingly speaking, but correct from an architecture (ukernel) point of view.

The real community-driven alternative is Linux, which started and still is a monolithic kernel, but the multiple features it got along the years may make the distinction even less clear [2]. It seems it will also accept some Rust code in the future, so the difference may drop even in languages used. [3]

[1] https://www.gnu.org/software/hurd/

[2] https://qconlondon.com/system/files/presentation-slides/thom...

[3] https://lore.kernel.org/lkml/CANiq72khBa2GcB6-PHM3A44Y90d6vz...

Redox OS is pretty cool, but without at least one big corporate sponsor it won't be able to amass the ecosystem needed to be viable for most use-cases. That said, I believe it's almost self-hosting now, so definitely a real OS that you can run software in today.

Never trust a company without a customer service department.

The average person uses android OS.

I wonder if it will last longer than Stadia did.

I am not sure I trust Google with an operating system anymore

I recall reading that Huawei's microkernel was actually more interesting/better than fuchsia, on a technical sense (don't know the metric).

Anyone has a (founded) opinion on the subject?

So is this Zircon kernel based? Or just fancy name for linux?

It is using Zircon kernel.

Why would anyone want to into this? From industry perspective it baffles me how Google divided an conquered not one but multiple platforms: (Android, Google TV, Google Auto).

From the user perspective I don't need another toy OS. I was able to develop Linux Kernel modules on my 486dx with 8MB of RAM. I was able to use excel, word on it.

Right now I have a mobile phone with better hardware than my work PC from only few years back (8GB RAM, 512GB UFS storage powerful multicore CPU). Still Android only allows me to click colourful buttons and simple apps, it has not progressed at all in the last decade.

Samsungs of the world, please come together, build a non-profit consortium and develop an open platform with real OS with full capabilities.

Reply on news.ycombinator.com