Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Fuchsia components and Linux containers [video]

fosdem.org

Post reply on HN
Print view View original

171–180 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#171

Post by josephg »

IshKebab wrote: post #154
josephg wrote: post #130

Earlier quoted context omitted.

> "it's not meant to replace JavaScript" The word meant is doing a lot of heavy lifting here. Meant - by who? The technology itself doesn’t want anything. Do some people want to use wasm instead of JavaScript for websites? Yes. Will JS ever be removed from web browsers? Probably not, no. Wasm isn’t a grand design with a destiny it’s “meant to” reach. It’s actually just some code written by a bunch of people trying to…

> Meant - by who? The technology itself doesn’t want anything. The people who created the project and who are writing the code, obviously. This is clear from the context; you don't need to nitpick stuff like this. > Wasm isn’t a grand design with a destiny it’s “meant to” reach. Yes it is. The destiny is being able to create dynamic websites with languages other than Javascript. The first step was Asm.js which allowe…

Ah, but you’ve moved the goalposts! The original claim was that wasm would replace JavaScript. Now you’re just talking about wasm being another option from JavaScript for web development.

This distinction really seems to matter to some people. I suppose there’s something tribal about it. Is rust here to destroy C++? Rust gets a lot of irrational hate in the C++ community, and I think this perception is the reason. Is Fuscia here to destroy Android? To some, this will be a very emotionally important question.

> Yeah citation needed. The very first compiler release already described it as "a strongly-typed systems programming language (…)”

This is the article I’m thinking about, titled “The rust I wanted had no future”. Well worth a read: https://graydon2.dreamwidth.org/307291.html

> Performance: A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good.

Re: Comparing Fuchsia components and Linux containers [video]

#172

Post by xorcist »

vlovich123 wrote: post #164
xorcist wrote: post #143

Earlier quoted context omitted.

Windows drivers are absolutely version specific. Try to install a driver for an old Windows version sometime.

They generally tend to work for a very long time, like for 5 years at least. That’s literally the reason Windows has a stable ABI. Linux generally breaks drivers every 6 months or so.

It doesn't? Try loading a driver written for an old version of Windows. Third party drivers generally won't work for the next version of Windows. I have a printer that had a Windows 7 driver. It won't load on any more recent version than that.

The same printer works with Linux the same it has always done. But that's not Windows' fault or to Linux's credit. It's just the result of a really crappy vendor. However the Linux API is generally more stable than people give it credit for, it's just that it's the C headers only. Anything compiled for a kernel generally won't work anywhere else, and that's not what the crappy vendors wants.

In the embedded space, including most mobile phone vendors which seemed to be an important use case for Fuchsia, even reputable vendors will generally give you an image of an operating system heavily modified to work with their hardware. That's their "driver". Imagine buying a new PC and receiving a DVD with a Windows modified to work on that hardware only. Of course you can't upgrade or even patch security issues beyond what the vendor will give you! You're supposed to buy new hardware. Sure, you could extract the drivers and try to install them on a vanilla Windows, and that's exactly what projects like LineageOS do, but most users won't bother.

That's the situation with phones. It's not at all clear why Fuchsia thinks they could solve this. It's a cultural and an economical problem and can't be fixed with software alone. Why would phone manufacturer care about your microkernel architecture? They will just patch the whole operating system, binaries and everything, until it boots enough to start the GUI and ship that. Just like they always have.

The only thing that could improve this situation is by enforcing the GPL, or have similar contractual stipulations like only being allowed to ship a reference implementation unmodified, but Google shows no interest in doing that. They care about getting Android on as many devices as possible with no regard to their respective quality or product longevity.

Re: Comparing Fuchsia components and Linux containers [video]

#173

Post by aidenn0 »

amluto wrote: post #59
aidenn0 wrote: post #48

Earlier quoted context omitted.

> A micro-kernel with a clearly defined device driver API would mean that Google could update the kernel and android version, while continuing to let old device drivers work without update. A monolithic kernel with a clearly defined device driver API would do the same thing. Linux is explicitly not that, of course. Maintaining backwards-compatibility in an API is a non-trivial amount of work regardless of whether the…

> A monolithic kernel with a clearly defined device driver API would do the same thing. Maybe, but I doubt it. History has shown pretty clearly that driver authors will write code that takes advantage of its privilege state in a monolithic kernel to bypass the constraints of the driver API. Companies will do this to kludge around the GPL, to make their Linux driver look more like the Windows driver, because they were…

You do have a valid point that sufficiently boxing off the drivers can force them to use an API of your choosing. Even the smallest of hurdles against doing it the "wrong way" can help because many drivers are written by inexperienced teams with a tight schedule.

However, if you discover that the box was insufficient at any point, you have to choose between changing the box (and breaking some perfectly good drivers), or leaving the insufficient box in place. API versioning can let you delay this decision to reduce pain, but it will happen at some point.

FWIW, I'm hugely in favor of microkernels, but they are a lead bullet (which we need lots of), not a silver bullet for these sorts of problems.

Re: Comparing Fuchsia components and Linux containers [video]

#174

Post by summerlight »

bobajeff wrote: post #5

I'm surprised this is still being worked on I was under the impression that Google abandoned this. Also, I would be interested to see a comparison to the wasm component model as it also seems to want to do the same things docker containers do.

I think there's still significant investments into the project. Android is big enough so any sort of greenfield experiments cannot be done cheaply. Also there were so many custom variants of Linux based operating systems in Google and some of them moved onto Fuchsia. Probably it still have some values there.

Re: Comparing Fuchsia components and Linux containers [video]

#175

Post by tmp-fuchsia »

spankalee wrote: post #70
tmp-fuchsia wrote: post #36

I haven’t watched this talk, but I worked on Fuchsia from the start (I’m no longer at Google) and want to clear up some common questions and misconceptions: 1. Fuchsia is a general-purpose operating system built to support Google’s consumer hardware. 2. It’s not designed to compete with or replace Android. Its goal is to replace Linux, which Android is built on. One big challenge it addresses is Linux’s driver proble…

I was never that close to the Fuchsia project, but knew quite a few people who worked on it. My understanding from them was, as much as I can remember it now, something like: 1. That yes, Fuchsia was originally intended, by at least some in senior leadership on the team, to replace both Android and ChromeOS. This is why Fuchsia had a mobile shell (or two?) at one point. 2. The Android team wasn't necessarily on board…

That’s a narrative I’ve heard before, and there’s probably some truth to it.

There’s the product side, and there’s the technical side. I’m not sure what qualifies as “senior leadership,” but when a VP finally stepped into the org, all the ambitious product ideas were cut, and we landed on Nest as a product. Until then, I believe it was mostly courtship and sales pitches (I wasn’t in the room).

Apologies if this comes across as harsh, but Fuchsia always seemed to suffer from poor product judgment. I think it’s only healthy to acknowledge that. That said, it’s not entirely surprising—good product people don’t tend to stay very long at Google.

Yes, there was a mobile shell briefly. There was also a desktop shell. I think the narrative you’re describing could be better framed as a series of attempts and experiments to see if Fuchsia could find a use case and client. That doesn’t necessarily mean there was a concrete plan that was seriously contended or scrutinized.

Just to clarify, these are my personal opinions and observations. I don’t actually know what went on behind closed doors, but I’m not sure it’s all that useful to know either, for the reasons I mentioned above.

Re: Comparing Fuchsia components and Linux containers [video]

#176

Post by nicce »

surajrmal wrote: post #84
nicce wrote: post #14

Earlier quoted context omitted.

Sounds like it has just AppArmor/Seccomp/SELinux policies built in. You usually reach the same with previous.

The difference is that those solutions are mandatory access control. Fuchsia doesn't have a global namespace that everyone shares. Each component gets it's own view of the world based on what is passed to it. This is often easier to work with then MAC. It's similar to writing a program without relying on globals for state, but instead passing everything into every function that it needs.

> Each component gets it's own view of the world based on what is passed to it.

But isn’t that exactly the same as MAC with default deny..? Different terms.

Re: Comparing Fuchsia components and Linux containers [video]

#177

Post by intexpress »

surajrmal wrote: post #149
intexpress wrote: post #92

Earlier quoted context omitted.

They might be thinking about POSIX Lite losing favor

Posix lite didn't lose favor. It's still an important part of writing fuchsia native software. It enables us to use the c++ and rust standard libraries with minimal upstream changes. It was never meant to enable running all existing programs, only lowering the barrier. There isn't really much software that has been ported to run on fuchsia natively. Instead runners are implemented or ported and those provide the envi…

Right, that is the current status

But the historical perspective is that Starnix is a relatively recent addition to Fuchsia. Even though Fuchsia is roughly 10 years old now, Starnix has only been useful for about 2 years (RFC 4 years ago)

Before Starnix came along to help run Linux apps, as you said, “There isn't really much software that has been ported to run on fuchsia natively”. Because POSIX Lite wasn’t / isn’t being used much. So I guessed the OP could have been thinking about that. But who knows.

Re: Comparing Fuchsia components and Linux containers [video]

#178

Post by surajrmal »

geodel wrote: post #146
pfannkuchen wrote: post #101

Earlier quoted context omitted.

> Fuchsia pivoted to Nest devices, and a story of replacing just the kernel of Android, to reduce the conflict with the Android team This is like a textbook example of weak leadership of an executive team. The power jockeying of a fiefdom’s chieftain (power reduction mitigation in this case) is allowed to drive the organizational structure and product strategy.

"Google force replace Android kernel with Fuchsia and hit some teething troubles". This is example of technically incompetent clueless leadership. That's why MBAs should not be in control in technical companies. They have ruined a product running on billion devices by replacing rock solid kernel with immature experimental project. And so on...

Why do you think fuchsia is immature and/or experimental? It's been iterated on for nearly a decade and is deployed on millions of devices. Also why do you believe there are any MBAs involved in any decision making? Your understanding of how Google works seems to rely on faulty assumptions. It's also not clear why you seem to wish for Fuchsia to fail - having a Linux monoculture has all the same issues many folks argue against with other monocultures. Fuchsia succeeding will lead to improvements in all OS as they learn from each others advantages.

Re: Comparing Fuchsia components and Linux containers [video]

#179

Post by surajrmal »

josephg wrote: post #171
IshKebab wrote: post #154

Earlier quoted context omitted.

> Meant - by who? The technology itself doesn’t want anything. The people who created the project and who are writing the code, obviously. This is clear from the context; you don't need to nitpick stuff like this. > Wasm isn’t a grand design with a destiny it’s “meant to” reach. Yes it is. The destiny is being able to create dynamic websites with languages other than Javascript. The first step was Asm.js which allowe…

Ah, but you’ve moved the goalposts! The original claim was that wasm would replace JavaScript. Now you’re just talking about wasm being another option from JavaScript for web development. This distinction really seems to matter to some people. I suppose there’s something tribal about it. Is rust here to destroy C++? Rust gets a lot of irrational hate in the C++ community, and I think this perception is the reason. Is…

There might have been a time when Fuchsia included some UI/UX elements to it, but that was long ago. For the last half decade there has been basically no overlap in what Android offers vs what fuchsia offers. They don't really compete and there is no one who wants fuchsia to supercede Android. The only people who want this don't understand what fuchsia is and simply want some drama. Comparing it to rust vs c++ is not really a good comparison as those languages overlap a great deal in terms of use cases and features.

Re: Comparing Fuchsia components and Linux containers [video]

#180

Post by surajrmal »

TheDong wrote: post #46
knifie_spoonie wrote: post #40

Earlier quoted context omitted.

Thanks for the info. For those of us not familiar with it, what were the main motivations for building Fuchsia instead of just using Linux?

They did say: > One big challenge it addresses is Linux’s driver problem Android devices have been plagued with vendors having out-of-tree device drivers that compile for linux 3.x, but not 4.x or 5.x, and so the phone is unable to update to a new major android version wit ha new linux kernel. A micro-kernel with a clearly defined device driver API would mean that Google could update the kernel and android version, w…

It's worth mentioning that fuchsia doesn't currently actually offer a stable driver abi. Or at least not one that is stable for more than a few months.
Post reply on HN