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

161–170 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#161

Post by simoncion »

ranguna wrote: post #126
okanat wrote: post #61

Earlier quoted context omitted.

It is more moonshot to design an API while Linux devs are constantly pulling the rug under. Microkernels provide nice secure API boundaries and optimizations to reduce performance impact when crossing them on modern CPUs. The monolithic design forces you to stay in either user or kernel mode as much as possible to not lose performance. Adding the API and ABI incompatibility makes it near impossible to maintain. It wi…

You have to wonder why the Linux devs are "pulling the rug under"

If you get your driver into the mainline kernel, it gets maintained. If your driver is not in mainline, then you have to deal yourself with kernel internals changing.

Hell, a while back one of the kernel devs was actively screaming for hardware manufacturers to reach out to them so folks could work with the manufacturer to get drivers for their products into mainline. There was even a website and nice instructions on what to do and who to contact... but I'll be fucked if I can find it anymore.

There's nothing nefarious going on... it's explicitly stated (and well-known) that the stable interface to Linux is the userspace interface. Inside the kernel, things are subject to change at any time. Don't want to have to work to keep up? Get your driver into mainline!

Re: Comparing Fuchsia components and Linux containers [video]

#162

Post by yencabulator »

vlovich123 wrote: post #141
xorcist wrote: post #138

Earlier quoted context omitted.

I believe you might be limited by your imagination just how bad out of tree third party drivers can be. We're talking about hardware with DMA access here. It's trivial to create a situation that can not be fixed in the kernel (without breaking other things). If you are running some generic PC hardware to write this comment, chances are that at least one tiny part somewhere which is dependent on some specific obscure…

I don't disagree with that and yet somehow Windows manages to largely maintain HW compat across major OS upgrades with the same crappy third party driver ecosystem.

Microsoft is exactly the kind of vendor that will be inserting those small delays in weird places to keep a popular-but-broken device working better. Their focus on backwards compatibility has historically been very strong, and at the same time that has often lead them to not even attempt to clean up their platform. NT came to be largely because the legacy mess got too hard to deal with.

Re: Comparing Fuchsia components and Linux containers [video]

#163

Post by yencabulator »

kyrra wrote: post #66
throwaway48476 wrote: post #58

Earlier quoted context omitted.

The point of linux is to upstream drivers so that devices just work.

The problem is the release cadence, especially around mobile devices. Driver packages for them tend to be worked on right up to shipping, because they are developed in parallel with the hardware. Android using the absolutely most head or tip version of the Linux kernel sounds like a QA nightmare of its own. Mobile SOC has to have everything to start up the phone, as there is no bios like system that the driver is kin…

The problem, especially around mobile devices, is that the vendors only care about a single-time sale. They just fork a specific kernel release, take a chainsaw to it until it stops crashing on their device, and try to never touch the source again. Very few hardware vendors put money into having maintainable drivers, because the next gadget they ship might have different chips in it, and the chips come from a subcontractor anyway.

Re: Comparing Fuchsia components and Linux containers [video]

#164

Post by vlovich123 »

xorcist wrote: post #143
vlovich123 wrote: post #141

Earlier quoted context omitted.

I don't disagree with that and yet somehow Windows manages to largely maintain HW compat across major OS upgrades with the same crappy third party driver ecosystem.

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.

Re: Comparing Fuchsia components and Linux containers [video]

#165

Post by yencabulator »

surajrmal wrote: post #49
fishtoucher wrote: post #39

Earlier quoted context omitted.

Fuchsia may not be outright dead, but it's definitely on life support and would've been killed a long time ago if senior people at Google weren't personally backing it. It had great foundations but without a concrete use case or product development was constantly pulled in different directions. It seemed like every year a new niche for Fuchsia was on the horizon, 6 months of development time would be dedicated to it,…

To wit, starnix has never been cancelled. Source: I work on fuchsia.

So the hope is that Starnix can emulate Linux syscalls well enough, while gVisor has been abandoned in later Google Cloud stuff because it couldn't emulate Linux syscalls well enough. Uh-huh.

Re: Comparing Fuchsia components and Linux containers [video]

#166

Post by vlovich123 »

bestorworse wrote: post #151
vlovich123 wrote: post #103

Earlier quoted context omitted.

Ok great. Now I put the phone home stuff within payload. It’s a game of whackamole you’re bound to lose. Like I said - if I control both endpoints, it’s going to be very hard for you to simultaneously give me a pipe connecting them while controlling the set of messages I’m allowed to send.

Sure, like you said, having control of the endpoints you could communicate anything if you can transmit bits. That’s unavoidable. But don’t lose the perspective on the benefits of such an architecture. Considering the networking access example: * If your process gets compromised it won’t be able to access the attacker’s C&C server. It wouldn’t have access to any other stuff that the process didn’t already have for th…

I really don’t know what point you’re trying to make. I am 100% in favor of capabilities and think it leads to better decomposed software with better security boundaries (provided the software engineers put in the work to separate components across process boundaries and the APIs make it convenient to do so).

All I said was that capabilities don’t solve the spyware problem and they largely don’t. They help protect you write software that itself can’t be hijacked to become uncontrolled spyware due to a compromise but if I am selling you software with “malware” bundled you’re going to have a hard time isolating the functional and “malware” bits (malware here being defined as software against the users wishes and intents).

You’ve extolled the benefits of it and they’re great and I think I largely agree with all of that, but it’s completely irrelevant to my initial point that it’s not a silver bullet for the vendor intentionally bundling malware into the code they’re distributing.

Re: Comparing Fuchsia components and Linux containers [video]

#167

Post by vlovich123 »

stouset wrote: post #140
vlovich123 wrote: post #123

Earlier quoted context omitted.

Firstly, VSCode runs on 3 major OSes that don’t have this capability and such software results the way it is partially because of targeting the lowest common denominator. Only a Fuscia first editor would do this. Secondly, the editor also does it this way this because of reasons other than support within the OS because even with components it would need to design a capabilities model for extensions and a sandbox proc…

> Only a Fuscia first editor would do this. The difference is in that every single one of those other operating systems, applications just have network access. By default. No capability needed. This would not be the case in an OS centered around capabilities. Multi-platform software develops integration with local OS APIs all the time . Like I said, your thinking is way too black and white. Your inability to see a di…

We’re getting way of topic. What I said is that capabilities in an extremely limited to ineffective tool for the end user to try to enforce their own privacy and security because it doesn’t offer controlling for the semantics of what happens. For example, it would be very hard to take a fuschia system that simultaneously allowed for the Google assistant feature and not for telemetry / Google storing mic data that was sent to them.

I’d ask you refrain from personal attacks. That isn’t a fair characterization of what I said. All I said is that capabilities fundamentally doesn’t solve the phone home problem in many real world cases. I also highlighted that there are very real economic forces that must be accounted for in terms of understanding why software is architected the way it is. And no, there’s very few applications that have a completely different architecture per major platform which is what we’re talking about with capabilities. That’s very different from abstracting some platform-specific APIs here and there.

Re: Comparing Fuchsia components and Linux containers [video]

#169

Post by thorncorona »

snarfy wrote: post #150
cletus wrote: 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…

Linux's ever evolving ABI is a feature, not a bug. It's how Linux maintains technical excellence. I'll take that over a crusty backwards compatibility layer written 30 years ago that is full of warts.

Driver instability is hardly a feature

Re: Comparing Fuchsia components and Linux containers [video]

#170

Post by spankalee »

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…

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

This isn't a nitpick, it's an important point.

Even on a small project, but especially at a huge company, there will be different ambitions and motivations for doing things.

ie, one person wants Fuchsia to eventually take over all of Google's OSes, another wants a secure IoT OS, another just wants a cool research project to pursue ideas about OSes they've had since grad school, etc...

Post reply on HN