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

141–150 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#141

Post by vlovich123 »

xorcist wrote: post #138
vlovich123 wrote: post #79

Earlier quoted context omitted.

That can be treated as an OS bug that’s fixed by updating the kernel to the latest version that fixes compat with that driver, which you can do because the driver remains unchanged. With Linux, even with DKMS, you’d need to backport your fixes to that old kernel in addition to maintaining the latest kernel version. And on mobile DKMS is not a thing.

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.

Re: Comparing Fuchsia components and Linux containers [video]

#142

Post by saghm »

surajrmal wrote: post #52
saghm wrote: post #29

Earlier quoted context omitted.

I think the problem is that "lack of public information about their future plans" is hard to differentiate from "no future plans exist". For a company that's in the past been known for their willingness to go for low-likelihood but high impact "moonshot" projects and seemingly open with some of their long-term plans (like everyone knowing that they were working on self-driving cars years before self-driving became a…

Fuchsia's UI layers are roughly equivalent to Wayland. There is a compositor, but no special alignment to any particular UI toolkit like flutter. Fuchsia is not itself a consumer product, it's an open source project meant to be used to build a product. There is no application runtime for app developers to care about or UI for an end user to see. It would be strange to talk about things like mesa or the Linux kernel t…

> Fuchsia is not itself a consumer product, it's an open source project meant to be used to build a product. There is no application runtime for app developers to care about or UI for an end user to see. It would be strange to talk about things like mesa or the Linux kernel the way you are talking about fuchsia.

The difference is that those aren't entirely funded and developed by a single a for-profit entity that presumably expects some sort of net positive results from the effort spent on them in the future. To be clear, I don't consider anything I said in my previous comment to be a reflection of whether Fuschia is useful or whether it has any technical merits; my commentary is intended to be entirely scoped to Google's _intent_ for Fuchsia, which is what I read the part of the top-level comment that the parent comment I responded to directly to be discussing.

It's certainly possible that you're correct that Google has had plans for Fuschia this whole time and didn't discuss them because they didn't think it was relevant, but I guess I just don't find that convincing enough to change my mind about what I perceive to be going on.

> It shouldn't really matter where and how it gets used to the end consumer, only that when it is used there are tangible benefits (more stable, less security problems, etc). I don't really understand why folks are so keen to understand what internal plans for using it may or may not be.

This is probably just a matter of differing personalities. I don't think I have any explanation for why I'm curious about the topic, but I just am. I think you could make any number of similar statements about not understanding why people find certain things interesting (sports, video games, celebrity gossip, etc.), and you wouldn't be wrong or right; in my experience, it's not a personal choice to decide to find something interesting or not.

Re: Comparing Fuchsia components and Linux containers [video]

#143

Post by xorcist »

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.

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

Re: Comparing Fuchsia components and Linux containers [video]

#144

Post by cmrdporcupine »

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…

+1

I worked on the Nest HomeHub devices and the push to completely rewrite an already shipped product from web/HTML/Chromecast to Flutter/Fuchsia was one of the most insane pointless wastes of money and goodwill I've seen in my career. The fuchsia teams were allowed to grow to seemingly infinite headcount and make delivery promises they could not possibly satisfy -- miss them and then continue with new promises to miss --while the existing software stack was left to basically rot, and disrespected. Eventually they just killed the whole product line so what was the point?

It was exactly the model of how not to do large scale software development.

Fuchsia the actual software looks very cool. Too bad it was Google doing it.

Re: Comparing Fuchsia components and Linux containers [video]

#145

Post by Fluorescence »

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…

> 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

What's preventing adding a driver compatibility layer over the unstable API? I would accept a some performance cost and NOPs for new features using a shim for existing legacy binary drivers compared to being forced to junk functioning hardware.

Re: Comparing Fuchsia components and Linux containers [video]

#146

Post by geodel »

pfannkuchen wrote: post #101
spankalee wrote: post #70

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…

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

Re: Comparing Fuchsia components and Linux containers [video]

#147

Post by PaulDavisThe1st »

lukan wrote: post #128
saagarjha wrote: post #117

Earlier quoted context omitted.

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.

It is a OS. Intended to run on mainstream devices. Main difference to Linux: stable driver API. So vendors could make their blobs and support them easier, without open sourcing, like linux demands.

Stable driver API and open source/GPL'ed drivers are orthogonal.

They are both significant for some companies in deciding whether to support Linux, but they are independent from each other. If Linux ever had a stable driver API, the GPL requirement would still cause some vendors to not provide drivers for Linux. If Linux dropped the GPL requirement (such as it is), but did not promise a stable driver API, some vendors would still choose not to provide drivers for Linux.

Re: Comparing Fuchsia components and Linux containers [video]

#148

Post by pantalaimon »

throwaway48476 wrote: post #96
kyrra wrote: post #66

Earlier quoted context omitted.

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…

In PC land linux driver support is not always day one as they are working on the drivers up to and sometimes after the release. Somehow the mobile vendors aren't capable of this.

On the PC a lot more is handled by the UEFI firmware so you need a lot less device specific drivers.

Re: Comparing Fuchsia components and Linux containers [video]

#149

Post by surajrmal »

intexpress wrote: post #92
tbodt wrote: post #50

Earlier quoted context omitted.

I work on Starnix and I've never heard of anything meant to replace it. What are you talking about?

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 environment applications require. For instance a flutter runner, web runner (chromium), and starnix (a Linux runner of sorts) provide the basis of running many existing applications.

Re: Comparing Fuchsia components and Linux containers [video]

#150

Post by snarfy »

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.
Post reply on HN