The Google Nest Hub is first commercial Fuchsia device

I half agree with you. It's not so much that Linux lacks a clean driver interface, it's really that OEMs write shitty software that doesn't belong upstream. Ideally vendors stop writing garbage drivers and distributing hacked up kernels with their "sample code" (but ends up in production) and opaque binary blobs.

Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad.

Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money.

In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits.

I don't see Fuchsia replacing that anytime soon.

Why can't the vendors just contribute their drivers to the kernel? Why is it so hard? Looks like Intel is doing it and their products just work on Linux as a result. Why can't these shitty mobile hardware manufacturers do the same?

Will we see GNU/Fucshia someday maybe then? :P

Okay, but having a stable interface doesn't fix vendors shipping bad code, it just decouples it so you can run terrible drivers on a less-terrible kernel. Better yet, Fuchsia removes any obligation for vendors to share code (by both separating drivers from the OS and having the OS itself be permissively licensed), so third parties can't even start from vendor code and try to improve things.

> The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel.

To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."

It's a pet project. If you want to solve the kernel ABI problem, you can easily hard-fork and maintain that ABI indefinitely from any Linux kernel.

And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent.

In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally.

In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.

> Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions.

The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it.

And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.

> the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed

> In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository.

Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here.

If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.

"But Fuschia's goal is NOT to build another Android, but mainly to replace the Linux kernel."

"BPF will replace the Linux kernel" - Linux kernel developer

Funny that the B in BPF stands for Berkeley, as in "BSD".

I bet it will be renamed at some point.

> strict licensing terms made it hard to get code upstreamed back

How come?

Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does.

Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.

> It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit.

Unix is still a good fit for a kernel; e.g. it is used by Apple. The stuff built on top of the kernel (UI, etc.) can change, of course.

Given that Fuchsia is not GPL licensed (making proprietary forks possible & likely) and apparently developed behind closed doors, not by a self sustained community like the Linux kernel its not very far from your worst case scenario, especially if Google starts force feeding it into Android like it did with many non GPL and proprietary licensed software over the years.

What does the "Viet Nam conflict" have to do with capability-based security?

I share your feeling, but I'd rather have a none isolated driver I can trust than an isolated one I cannot trust. My threat model includes fishy OEM doing borderline things.

In driver development I often see abstraction violations or very loose abstractions: news hw capabilities can't be accounted for when designing framework abstractions.

I have never done dev on windows, but I guess there is a reason why the form factor of things running windows is pretty limited. I don't see how you can have fixed interfaces in an ever evolving wold.

Also, Google's internal politics are kind of broken. It's my understanding that a lot of the product launches and cancellations are a consequence of an internal culture that rewards launching new products, but not maintaining or improving them.

> Google develop 3+ different OS's?

It wont. From what I understand this new OS will replace others over time. Also it is way better than existing options.

This seems like a pretty flawed strategy to me. Lots of improbable products turned into multi-billion dollar companies. Tiny videos set to music, watching other people play video games, liking pictures of food, and so on. It seems to me that it's less about the product and more about the execution. There are lots of Google products that could have taken off if they had been iterated instead of abandoned. Take Apple as one example. They develop a product vision, then spend several versions refining the thing till it goes from a curiosity to a must have. Or look at Facebook with Oculus, they had a vision and released headset after headset, till they found a feature set that had the user engagement metrics they were looking for. They didn't just give up once the Gear VR proved to be a dead-end, which is exactly what Google did with their VR efforts and then cleanly missed the boat Oculus is on now with the Quest.

> All that we do now is find ways to make that hose go faster, and desperately search for another hose.

There’s one other thing Google does a lot of: try to foresee and actively forestall how someone else might cut-off or divert the flow to the existing hose. While both Chrome and Android evolved in directions that explored potential new hoses, they were clearly both initially directed at protecting the existing hose from being choked off or diverted by monopolies on the client side; Android was purchased and engineered to prevent Apple gaining the kind of dominance in mobile to do that, Chrome and Chrome OS against the desktop Windows monopoly and IE.

Google+ was deployed against Facebook and abandoned once it was clear that Facebook’s position, while making it something of a competitor for ad dollars, wasn’t, even without a competitive Google alternative, an existential threat to Google’s money hose.

This would be another benefit of antitrust scrutiny for the tech giants.

They're not innovating at this point. They're twiddling thumbs.

If we broke up Apple, Google, Facebook, and Amazon, then they'd be forced to fight for survival.

Struggle births innovation.

How exactly does a random piece of IoT junk that looks like it could come from any single one of countless fly-by-night manufacturers in Shenzen (namely the "Nest Hub" that's now running some version of Fuchsia, per the OP) turn into a money-making firehose for Google? Just curious, because I'm having trouble seeing how this could make sense.

Isn't that most private companies ?

Searching for sources of income ?

It would be really interesting if someone could benchmark the performance before and after the transition.

How is Fuschia licensed?

This is also why Android is such a security and privacy nightmare, with the terrible user experience (and environmental impact) of having to buy a new phone every 1-2 years.

Because Android is not GPL.

Google owns the software, so manufacturers really only make money from the device sales, and bundled spyware.

I disagree. One of the things that stops people from actually using Linux is that it is so hard to get devices working properly.

I would be willing to accept some closed source drivers if it meant Linux actually worked reliably on most modern hardware (no it really doesn't).

I think you give some valid concerns. I definitely understand you, but I want to give some counter arguments to where I'm seeing chances with Fuchsia in addition to the dangers that you rightfully point out.

First, there are thriving non-copyleft driver projects, like mesa. No copyleft forces Intel to contribute to it. No copyleft forces AMD.

Second, even in Linux, many drivers aren't maintained by their vendors, but third parties. I think that an upstream driver is generally easier to deal with for most parties, so most parties would prefer it. If fuchsia is indeed as modular as it promises to be, users can swap out those drivers, at least in custom ROMs. Android custom ROMs already copy over proprietary drivers from the native OS upon installation.

Third, the GCC compiler has artificially restricted the ability to use it as a backend for third party languages, which led to many projects choosing LLVM instead. These projects now contribute to LLVM's success. Yes, some extensions to LLVM are proprietary. Still many companies contribute to LLVM directly.

Fourth, legal action doesn't turn a company into a good citizen. They might release the source code in the end but they become extremely hostile to free software projects coming forward, because suddenly the legal department got involved. Those employees who share the cause can't freely talk on mailing lists any more because all mails to the project first require approval by a company lawyer. Etc. The released source code might be unusable anyways because it's done to a fork of an outdated version of the kernel.

Well if you hang Free Software's hopes entirely on the Linux kernel, or the Linux kernel doesn't mature to the point where it isn't the hall monitor for everyone's code quality, then that might be what happens.

Darwin might be knocking. Evolve or die.

(And its a bit weird that the Linux kernel is so centralized with a cabal lead mostly by one dude who yells at everyone on the planet about their shitty driver code quality. If you're at all Libertarian or libertarian, that should probably bug you a bit that Free Software picked that as the ideal model.)

Linux only happened because Microsoft didn't care to put much love on their POSIX subsystem for Windows NT, and BSD was busy fighting AT&T.

Looking at the pleothora of BSD/Apache/MIT OSes appearing for embeeded devices it is clear what the future of Linux will become, when the generation that gave birth to it is gone.

Completely true.

Also, the reason so much hardware doesn't have drivers for Linux until after many years, when it has been reverse-engineered.

So, it is both an advantage, and a hindrance.

I disagree. The comments, here, give some real meta-insight into how Google is seen in the tech world: As an unreliable partner.

Google has clearly and profoundly lost the confidence of the broader tech community.

In particular, Google's history of starting and cancelling random projects helps explain why people are wondering why Google is releasing Fuschia: without some understanding of their motivations, it's impossible to trust that it'll actually have any kind of extended lifespan.

For all we know, Fuschia, Android, and ChromeOS are basically the OS equivalent of Hangouts, Meet, Allo, and Duo, in which case becoming in any way reliant on it is a huge mistake.

At best, it'll be something others will be able to leverage and make forks out of, and thanks to its permissive license, they won't have that pesky requirement to make the source code of their fork available. At worst, it'll be yet another product abandoned in a couple years by Google because it failed to meet some ludicrous goals that are out of reach for 99% of the companies in the world anyway. Such is the way people see Google nowadays, and can you really blame us?

> The first major open source kernel since Linux, and somewhat arguably OS X, has been released.

Depending on your definitions, OpenSolaris and Redox would object. And it's open sourced in a way that's designed to support making proprietary products, so you'll forgive my not really celebrating.

It's probably preferable than continuing to use the JVM-clone like it's an OS, while porting Linux to be the actual OS to run their JVM-clone OS.

A large investment like this is likely a strategic move.

Perhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.

Good questions, and I don't know the answers, but it is kind of odd (particularly given the pace of change in other areas of computer tech) that the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area.

Of course, Apple is hard at work on iOS, but we don't know what sort of under the cover innovations that might good.

So. I'm glad to see something new.

Most OS's out there are unsuitable for making appliances, which this seems aimed at.

Right now your choices are a Realtime OS or Linux. Realtime OS don't support making GUIs and Linux has a lot of foot-guns.

Normally, updates to an appliance are one binary blob, this looks to support all of the various pieces having their own blob, and allow the OS to be updated independently from the application binaries, so security updates can happen without the appliance vendor needing to do anything.

Who needs an excuse to keep a lot of very senior OS developers happy to be employees?

I can't speak as to their motivations specifically, but one of the things that I've noticed from poking around the kernel API is that the kernel APIs are much more coherently designed than the conventional kernels we have are.

In particular, one of the key design goals appears to be a heavy use of a capabilities-enabled handle-based API, even for more conventional syscalls (e.g., mmap). One of the benefits of this approach is that it simplifies a lot more cross-process management stuff; you can inspect (or edit!) another process's memory maps, for example, with the same system call that a process would use to edit its own. It would also enable something like CreateRemoteThread; it would definitely be far easier to write a debugger for Fuchsia than it is for Linux.

Because things have changed since the time Linux became ubiquitous.

We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing (no shared memory, no shared filesystem), capabilities, new and extremely aggressive attack vectors, and a need to compartmentalize and virtualize at more fundamental layers even if it comes at a performance penalty.

You can't retrofit a microkernel-like abstraction on top of Linux. At the same time, a lot of the features you need for a shared multi-user system are basically cruft for modern mobile, single-user systems with little use for shared resources (not saying they're not shared; it's just that you can no longer trust apps installed in the user system so expecting apps to behave nicely is out of the window).

The new wave of OSes embraces formal correctness when possible, JIT, garbage-collected application programming languages, tightly-enforced resource boundaries, deny-by-default security models, provably-safe system programming languages (Rust and whatever else will come), immutability and copy-on-write at the cost of filesystem space, and secure memory abstractions for more RAM.

So why spend time supporting features that new OSes don't need, optimizing things that are no longer priority (HDD schedulers vs no-op SSD schedulers), when for once it _is_ actually easier to start over and fixing a lot of traditional pain points?

> Why is google building it?

As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development.

It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.

Google doesn't control Linux.

I guess a microkernel is pretty cool though, the academic ideal.

Linux is GPL.

It is in a sense something of a research kernel. The reason to not use Linux is that it’s 30 years old and crufted up with things like multiple users, processes running as the user that started them, and POSIX.

Linux also doesn’t have a stable kernel interface for drivers, which is probably a huge pain when dealing with supporting a device for many years. Either you don’t update the OS on the devices, or you have to modify all of your drivers every time you update the OS.

Why is that worth noting, and not the fact that the network stack is still Go-based? (So to say it’s discarded is inaccurate.)

Considering all resources are accessed via scoped and capability-based handles, I suspect so. Not sure I want to see more kubernetes more places though... I'd rather just write software on a secure os in the first place.

what should be used instead?

You don't, any C++ will do, as well as Java, Swift, etc etc etc. Also, it's a kernel, not a whole window management system + APIs + look & feel like people are reading here

I'm curious, do you mean actually show the time, or be able to respond to a voice query? I know newer Pixels for example run local-assistant and can answer a decent percent of queries locally, including telling time. I assume older Nest Devices don't yet have the local capability of processing your voice query locally, other than the hotword.

They never went away in the embedded space.

Ahhaha... Google is basically just a large data collecting bot net

In all seriousness - how is that any different from ChromeOS or Android? It's not like the kernel is what determines privacy issues.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

They got the vapor wave aesthetics with the name at least

Vaporware with shipping units and published source code?

it's literally shipping

If this can possibly replace Android, WearOS (or recently announced WearOS/Tizen mashup), and ChromeOS, it’s quite possible that Fucshia is here to stay.

Android apps and Chrome can easily run on a different OS, the only problem are device drivers, but I’m sure Google is in a position to persuade manufacturers to provide drivers for their OS.

Please don't repeat shallow-dismissal clichés and particularly not with added snark. You may not owe $BigCo better, but you owe this community better if you're participating in it.

https://news.ycombinator.com/newsguidelines.html

Sure, define your terms & odds, I'll take your money.

It's a last-gen device. Why not interpret the lack of fanfare -- by design, a user won't even notice the swap -- as a soft launch?

The smart home space has always been a shit show, from the radios up. It's a separate bag of rats from launching a research OS on real hardware.

Linux wasn't invented at Google.

There's a gigantic difference in developer effort to make an appliance OS versus a full-featured mobile OS.

> I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio.

It’s certainly the best way to immediately get it a whole lot of real world use and feedback with basically zero sales effort, and its economical since it lets them transfer resources allocation from supporting a dead-end effort to a live one.

> A bold move would have been to put this on the next Pixel.

“Bold” is sexy, but not the same as smart long-term strategy in many cases.

> I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio. That indicates to me that they don't see this as an Android killer just yet. A bold move would have been to put this on the next Pixel. Clearly, that's not happening. If that was at all feasible, they would have waited for that and that would have been the grand launch. So, clearly it's nowhere near ready for such a launch.

That seems like a good thing to me. Personally I'm not very interested in an OS that's 'bold', I want an OS that's stable and well tested and releasing slowly on a limited set of devices seems a good way of doing that.

Contrast with Apple: M1 and pump! launched it the major selling laptop.

That is how you know Apple mean business.

And this is how you know fucsia/google will not.

Another way of looking at it is that it probably takes a really long time to bring up an operating system to the point where it is production-ready.

It would be easier to do if you can target one hardware platform that does not change so that you don't have to also shift gears. If you're building the Great Pyramid, you don't want to also move it to a new construction site when it's half-completed.

Launching on hardware that was already released could mean they gave themselves that time. By the time they're finished (now), the hardware is old.

> A bold move would have been to put this on the next Pixel.

Which will delay the next Pixel at least several years while causing a unprecedented level of fragmentation in the Android ecosystem? BTW, I don't expect this kind of experimental projects can live without reaching any milestones. Replacing Android with Fuchsia is just not a feasible option at this moment.