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

131–140 of 191 posts

Re: Comparing Fuchsia components and Linux containers [video]

#131

Post by rjsw »

kllrnohj wrote: post #13
bestorworse wrote: post #6

Earlier quoted context omitted.

It's technically a general-purpose OS. They had a workstation build target sometime ago which was used for the desktop use-case. They've shipped only for an IoT device so far (Google Nest Hub). Main goal would be to replace the core of AOSP considering the main work that's being done, but it seems like Google isn't convinced it's there yet.

Android is very unapologetically Linux and it's unlikely anyone seriously proposed doing anything other than use Linux. Fuchsia more likely was for all the stuff that Google kept experimenting with using Android just because it was there rather than because it was a good fit - wearables, IoT, AR/VR, Auto, etc...

Other operating systems have emulated Linux so that you can run Linux userland applications on top of a different kernel, WSL1 and FreeBSD are good examples.

Re: Comparing Fuchsia components and Linux containers [video]

#133

Post by fredoralive »

mmooss wrote: post #82
wqaatwt wrote: post #30

Earlier quoted context omitted.

IIRC it didn't take that long to develop first production versions of macOS? A couple of years maybe? It's not like Fuschia was supposed to be a "fully capable OS developed from scratch", either? I mean it's "just" the kernel and other low level components, most of the software stack would remain same as Android/Linux at least for the time being.

> IIRC it didn't take that long to develop first production versions of macOS? If you mean the early 1980s OS, that is not comparable. It probably ran in something like 512K of memory off of a 5.25" floppy disk (or a tape?). > It's not like Fuschia was supposed to be a "fully capable OS developed from scratch", either? I mean it's "just" the kernel and other low level components I don't know the answer, but doesn't t…

The original Mac has 128kB RAM, a 64kB ROM with a fair chunk of the OS in it, and used 400kb single sided 3.5" discs. The paltry RAM is generally considered to be the main problem, but the Mac team were working to a target price of $1500 (which they missed), and that’s all that could afford, with the largish ROM being a compensation. A quick unscientific look at Byte's January 1984 issue seems to show 128kB as the base level for IBM PC clones at the time as well, but they don't have a GUI.

In comparison, the Lisa OS required 1MB RAM and a 5MB hard disc, hence the eye watering $10,000 introductory price.

Development on the Mac apparently started in 1979, and release in 1984 although the early Jeff Raskin era machine was quite different to the final Steve Jobs led product.

Re: Comparing Fuchsia components and Linux containers [video]

#135

Post by wilsonjholmes »

plagiarist wrote: post #54
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…

I would love to have an open source microkernel OS that works as well as Linux on modern hardware even if the API wasn't stable. I am making assumptions that you could have ZFS and secure boot at the same time without jumping through hoops, containerization without needing fictitious UIDs for every user, and other things of that nature. The monolithic kernel is very frustrating with some things.

Why does a monolithic kernel make those features have "hoops to jump through" compared with how a micro-kernel would handle those features?

Re: Comparing Fuchsia components and Linux containers [video]

#137

Post by goodpoint »

knifie_spoonie wrote: post #40
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…

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?

The goal is to make devices more controlled by google and less FOSS. The many GPL violations happening around drivers are telling.

Re: Comparing Fuchsia components and Linux containers [video]

#138

Post by xorcist »

vlovich123 wrote: post #79
est31 wrote: post #62

Earlier quoted context omitted.

It's still possible that drivers might be so buggy that a newer OS version might interact with them in a slightly different way which is still legal by the API definition but it still makes them crash or stop working.

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 timing to come up properly which just happens to work because someone inserted a small delay somewhere.

Re: Comparing Fuchsia components and Linux containers [video]

#139

Post by tonfa »

ckocagil wrote: post #53
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…

Instead of a moonshot micro kernel, why didn't Google just build and maintain a new Linux driver API/ABI layer with backwards compatibility and security? Not an easy endeavor, but is it harder than Fuchsia?

Was it what project treble was about? https://android-developers.googleblog.com/2017/05/here-comes...

Re: Comparing Fuchsia components and Linux containers [video]

#140

Post by stouset »

vlovich123 wrote: post #123
stouset wrote: post #113

Earlier quoted context omitted.

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

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 different world doesn’t make one impossible to exist. What is even the point of thinking this way? Your entire mindset boils down to “nothing can ever be better”.

Post reply on HN