Hacker News Reader

Comment by outworlder | Hacker News Reader

> Fuchsia is a long-term project to create a general-purpose, open source operating system

Why do we need this? We have Linux. It works. It is open-source, general purpose. It needs more support to become more mainstream (like what Valve has done with Proton).

Don't like Linux? Start with one of the BSDs. Heck, start with Haiku. Any of these projects are lightyears ahead of anything that's just starting.

The most likely explanation is that _we_ don't need this, but Google does, for some strategic purpose. It must be for some pretty compelling use-case, because we know how happy they are to kill projects.

View on HN

Why do we need Krita when we have GIMP?

Because every once in a while, it‘s easier to free yourself from the shackles of architectural decisions that were made because of the hardware and constraints of their time that are obsolete now but are supported for legacy reasons.

A security model that is designed from scratch into such a deep OS concern as with Fuchsia is one of the aspects that would be next to impossible to bolt onto such a conplex project such as Linux or BSD.

I‘m not saying it will play out, but it certainly brings a wave of fresh and radical new ideas into open source operating systems I haven‘t seen since the times of BeOS and Plan 9.

For me, OS research is always good. Experimenting from ground up is even better.

But Minix, the hero of the Microkernel research, became the guardian of Intel systems and preventer of tinkering and exploration.

Can we certainly say that Fuschia will be Free and mild natured like BSD and Linux or will it become another silent "hard-layer" like Minix?

GP (and I) certainly fear about the latter. Given Google's transformation to Modern day Microsoft of the 90s, it's not too far-fetched it seems.

why did Intel pick Minix, anyway? Licensing or something?

Partly license, partly memory footprint it seems. Even Tenenbaum doesn't know exactly why [0].

[0]: https://www.cs.vu.nl/~ast/intel/

FreeBSD has supported capability-based security model for a decade now: https://www.freebsd.org/cgi/man.cgi?capsicum.

There is definitely room to innovate more fundamentally in operating system design. POSIX is effectively a 50-year old API, and there are definitely places where the API it provides is far from optimal.

For something that interests me personally, the POSIX idea of ptrace and signals for debugging is a fundamentally broken and obtuse API that just don't work very well with how modern software is designed, and requires a decent amount of hacks to do anything rational with hardware traps. I did think a little bit about what kind of API I wanted if I were designing de novo, and happened to pop through Fuchsia's API at a glance to see what it decided... and it was exactly the kind of way I'd have thought about this space.

POSIX doesn't say anything about ptrace. And yeah, ptrace is somewhat horrible, but there's no reason you couldn't implement something better in existing systems; it's just that the amount of work necessary is so huge it's probably not worth it, but the same amount of work would be needed to write it from scratch.

ptrace is a Linux thing. POSIX is not Linux.

Ptrace long predates Linux: https://en.wikipedia.org/wiki/Ptrace#Unix_and_BSD

None of these are microkernels with a strict capabilities model. Open source isn’t the only desirable property of a kernel, and Unix is probably not the last word in advancements of general purpose OS APIs.

One application they’re probably interested in is a sandbox/containerization system with a drastically smaller surface area than the Linux primitives. That’s what excites me, we may get to the point where things like Firecracker VM and gVisor are no longer needed for robust isolation.

Isn't seL4 a microkernel with a strict capabilities model?

SeL4 currently doesn’t have shared memory concurrency, and is only the kernel part. It’s focused heavily on formal verification, and makes a number of other sacrifices (in particular to performance) to achieve that. I’m a big fan of formal verification, but seL4 levels of assurance are still too unwieldy with current tools for an application that doesn’t place a massive premium on it.

It’s also worth noting that the Fuchsia equivalent would be Zircon, which is a relatively small part of the Fuchsia project (and will only get smaller in proportion).

> Why do we need this?

About the biggest piece I can see which benefits the outside world is the fact that Fuchsia's drivers are independent of kernel version. This is one of the biggest pain points for Android upgrades.

A Fuchsia based kernel upgrade won't be held hostage by lack of Qualcomm/ Nvidia/ Mediatec binary drivers.

But mostly, I suspect Google just wants an OS that isn't burdened by GPL.

Because Linux isn't perfect. It can be improved upon.

* All code in the kernel including all drivers is 100% trusted. This is very bad for security.

* No stable driver ABI, so writing out-of-tree device drivers is very difficult.

* GUI is an afterthought, which means it is very difficult to do things like graphical secure attention keys, and frankly graphics/display support on Linux is very janky as a result.

* Many of its features are firmly stuck in the 80s.

Linux considers stable driver API as a nonsense. SoC manufacturers don't want to open source their drivers, they prefer to ship blobs and they prefer not to support those blobs for a future kernel updates. Those facts means that you can't upgrade your kernel. When you can't upgrade your kernel, you can't upgrade your userspace which depends on new kernel features. So basically your software is stuck and eventually obsolete.

There are two ways out of this situation. You can either replace Linux with another kernel with stable driver API or you can replace SoC manufacturers with those willing to upstream their drivers. Probably it's easier to go to the first route.

Surely we've learned a few things about designing systems since 1991 (and the hardware landscape has changed just a little bit in that time too). A new, from-scratch OS should be able to make some huge leaps with all of that new hindsight, and without all of that legacy baggage. It's an enormous task, of course, but if anybody has the research-cash to throw at it, Google does.

Of course from a business perspective it's definitely a power-grab, just like Chrome was. But from a technical perspective I think it makes a ton of sense.

We don't need it, we don't need anything at all really. But when* google turns it into reality everyone is either going to embrace it or it will fail like MS's arm attempt. If it succeeds, we'd all be like - "This is exactly what we needed!" But then we will realize it's just different bone structure under the same skin. Skin being metaphor for a highly locked down and centrally controlled ad delivery platform that doesn't let users truly own their paid for devices.

* - considering google's software mortality rate, i am skeptical of anything new and daring getting enough time to mature. It will be google plus'd.

Is there anything in Fuchsia that may be usable in Linux? I'm specifically thinking of something like a window manager?

They need work to give their thousands of devs

> Why do we need this?

So Google own the kernel under a license that lets them add secret sauce.

Reply on news.ycombinator.com