Live data from Hacker News

Comparing Fuchsia components and Linux containers [video]

fosdem.org

111–120 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#111
post #59
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…

> driver authors will write code that takes advantage of its privilege state in a monolithic kernel to bypass the constraints of the driver API.

Well, your job is shipping the driver. If the API is limited and/or your existing drivers in Windows or other OSs do something and the linux driver doesn't then you have a problem

Linux kernel pros: it evolves organically

Linux kernel cons: it evolves organically

Re: Comparing Fuchsia components and Linux containers [video]

#112
post #102
post #75

Xoogler here. I never worked on Fuchsia (or Android) but I knew a bunch of people who did and in other ways I was kinda adjacent to them and platforms in general. Some have suggested Fuchsia was never intended to replace Android. That's either a much later pivot (after I left Google) or it's historical revisionism. It absolutely was intended to replace Android and a bunch of ex-Android people were involved with it fr…

This is probably the most complete story told publicly, but there was a lot of timeline with a lot of people in it, so as with any such complicated history "it depends who you ask and how you frame the question": https://9to5google.com/2022/08/30/fuchsia-director-interview...

I remember reading the fuchsia slide deck and being absolutely flabbergasted at the levels of architecture astronautics going on in it. It kept flipping back and forth between some generic PM desire ("users should be able to see notifications on both their phone and their tablet!") to some ridiculous overcomplication ("all disk access should happen via a content-addressable filesystem that's transparently synchronized across every device the user owns").

The slide with all of the "1.0s" shipped by the Fuchsia team did not inspire confidence, as someone who was still regularly cleaning up the messes left by a few select members, a decade later.

Re: Comparing Fuchsia components and Linux containers [video]

#113
post #95

Earlier quoted context omitted.

Your perspective is coming from a very rigid all-or-nothing mentality and I don’t think it’s wise to see things that way. Sure, a web browser that needs to open arbitrary network connections can be built to phone home. But nearly none of the components it’s built out of can. The image decoding and rendering libraries can’t touch the network, the rendering engine can’t touch the network, and nor can the dozens of othe…

But your editor extensions can’t phone home only if your editor sandboxes them into a separate process. Hint: VSCode doesn’t do such sandboxing and neither do most editors that I can think of. Anyway, you’ve just proven my point with “install extensions out of band” - you’ve ceded that it’s a losing position technically and are arguing for alternative UX solutions. I’m not pretending it has to be perfect. Like I said…

Your editor doesn’t do it because handling, delegating, and slicing up capabilities isn’t a core part of the OS.

Re: Comparing Fuchsia components and Linux containers [video]

#114
post #19

Earlier quoted context omitted.

Is it similar to NixOS? Recent convert, would be interested to read a comparison to fuchsia from someone in the know of both. If it’s anywhere close Google might be sat on a huge opportunity to tread the same ground while solving the ergonomic issues that NixOS has. (I’ve never been more happy with a distro, but I’ll admit it took me months to crack)

NixOs is built on Linux kernel, Fushia is built on a new (micro-ish) kernel called zircon, they are not interchangable. They are working on some components/layer to run things from Linux, but you would not expect all things built to work directly or as well as thing designed from the get-go for Fushia in mind.

Thanks - I figure its step away in terms of target platform.

I meant a little more in the way that software is packaged and run. My understanding is that theres a similar mechanism for storing and linking shared libraries that means multiple versions can go exist and be independently linked depending on the requirements of the calling package.

Re: Comparing Fuchsia components and Linux containers [video]

#115

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 think if google collaborated with NetBSD it would be successful than creating new OS from scratch

Re: Comparing Fuchsia components and Linux containers [video]

#116

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 think if google collaborated with NetBSD it would be successful than creating new OS from scratch

Coincidentally, Android ABI is a scaffolding on *BSD by the way of bionic.

https://android.googlesource.com/platform/bionic/ (cf. "What's in libc") / https://github.com/GrapheneOS/platform_bionic/tree/15/docs

Re: Comparing Fuchsia components and Linux containers [video]

#117
post #99

Earlier quoted context omitted.

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…

You got the high drama stories with the timelines re-arranged to fit the narrative :D Fuchsias underlying goals are to be a great platform for computing. This is distilled in its current incantation into a short tagline on fuchsia.dev: simple, secure, updatable, performant. The details of how when and where Fuchsia might fit / gets exercised are nuanced and far more often about other factors than those which make gre…

Look I understand the context here but if you're going to go around saying "a great platform for computing" it's not really telling me much about the project.

Re: Comparing Fuchsia components and Linux containers [video]

#118
post #74

Earlier quoted context omitted.

Yes. And without over stating it, iOS is an amazingly robust, very secure OS. it has high trust and low trust models, a secure zone, special purpose hardware and an operating system designed around minimum access rights models which manages to keep going, despite app authors worst intentions. At one level, it proves the model. The shame is that Mach otherwise has kind of not taken off. Gnu the OS was going to be Mach…

I'd have to disagree -- the lack of OS-level sandboxing primitives such as seccomp-bpf and SELinux[1] means that exploits happen rather regularly in iOS rather often ([2], among others). [1] https://source.android.com/docs/security/app-sandbox#protect... [2] https://www.csoonline.com/article/3811322/iphone-users-targe...

iOS has a perfectly good sandboxing model that is literally called "the sandbox". You will note that the impact of that bug is limited to the process it is triggered in for precisely this reason.

Re: Comparing Fuchsia components and Linux containers [video]

#119

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…

> Fuchsia isn’t trying to replace Android. Its survival for over a decade—through layoffs and with hundreds still working on it—says a lot.

Says a lot about managing to cling onto another product as a dependency to save the team from cancelation. Gotta thank the Directors for playing politics well. (Dart also played that game.)

Does not say much about necessity. Won't be surprised if it gets DOGE'd away at some point.

Re: Comparing Fuchsia components and Linux containers [video]

#120
post #100
post #32

I wish message passing and capabilities based OS had taken off stronger in the 80s because I sometimes feel like there are design goals and approaches latent in what we do now, which we could have been advanced in before now, beyond research models.

I don't think they were as tenable then as they are now. When I was doing performance work on the platform one of the notable things was how slow some of the message passing was, but how little that mattered because of how many active components there are computing concurrently and across parallel compute units. It'd still show up where latency mattered, but there are a ton of workloads where you also basically hide…

This is why Linux works and is good and most other kernels are slow and don't work. Linux has been optimised over the years based on how software actually works rather than fantasies about how it would work it we got to rewrite the world.
Post reply on HN