Hacker News Reader

Comment by Roritharr | Hacker News Reader

I'm enthusiastic about Fuchsia, i really think there is a lot to gain by breaking with the old conventions, especially when you look at what is hindering true realtime computation approaches.

As a nice byproduct Google has a hedge against Linus dying and his replacement being incompetent at managing the community.

View on HN

Right now it kind of reminds me of BeOS, which could do absolutely incredible concurrent realtime low latency media processing but was absolute torture to get a proper Web Browser working.

The problem with legacy support is that it drags in the braindamage you were trying to avoid by rewriting the OS in the first place. But without legacy support it's almost impossible to grow beyond the toy OS stage. It's the whole "So, what do I do with it?" factor.

A couple of former BeOS folks are actually working on Fuchsia: Travis Geiselbrecht and Brian Swetland.

Travis Geiselbrecht is responsible for NewOS (http://newos.org/). The kernel in Haiku, the open-source BeOS recreation, was forked from NewOS' kernel.

Some logs from Travis Geiselbrecht in Haiku IRC channel about Fuchsia.[1][2] Also looks like Fuchsia barrowing some code from Haiku.[3]

[1] https://discuss.haiku-os.org/t/fuchsia-a-new-google-kernel-c... [2] https://echelog.com/logs/browse/haiku/1471125600 [3] https://discuss.haiku-os.org/t/fuchsia-a-new-google-kernel-c...

I watched a BeOS demo video ( https://www.youtube.com/watch?v=BsVydyC8ZGQ ) the other day and some of that stuff is /still/ impressive.

I had a roommate in college who had a BeBox with the twin PPC 603(?) processors and a row of LEDs on the front configured to show the current load of each CPU.

It was super cool and could make these absolutely insane multimedia demos, but he was forever trying to get software to work on it. Whatever POSIX compatibility it had was absolutely insufficient for modern (at the time) applications. Everything required some rewriting by hand, and there were definitely crashes. Worse, Netscape didn't release a BeOS version of Navigator so he was always hacking up the latest Mosaic release to try to get it working. I was running FreeBSD at the time and it was the polar opposite. Sound barely worked, the only video players were slow and unreliable open sourced school projects, but it was front and center on the newfangled Internet thing that was going around at the time.

from comments from people who worked on it (e.g., https://twitter.com/MCSpaceCadet/status/968666523425386497 https://twitter.com/slava_oks/status/958908471801294850 ), Microsoft seems to have reached this stage with their Midori project. This was a ground up OS project based on the usual suspects from the research world i.e. object-capability security, microkernel architecture, a new lightweight process model, memory-safe systems language, zero-copy IO etc.; the project lasted 9 years and occupied over 100 senior engineers at its peak. They tried various strategies to run it on top of Windows, run it on top of Linux, run Windows on top of it, run it on Hyper-V, etc etc. before eventually giving up.

Google has the advantage of having two consumer platform (Android and ChromeOS) running on Linux, but with the majority of application code written on top of additional abstractions on top of Linux so a lot of it would still run if the appropriate runtimes were ported over to Fuchsia.

Google is also developing Fuchsia openly, if quietly, giving developers a preview of where they are going. Microsoft developed Midori mostly in secret, and while we've heard a little bit about what they did in that project from blog posts and Twitter threads, nothing official has ever been released publicly.

And on the server side, virtualization and containerization are huge and growing, as many people find the benefits in flexibility, repeatability of deployment, and incremental billing to outweigh the absolute overhead over bare-metal performance. Fuchsia seems to support virtualization as a core part of the API, allowing you to run Linux VMs when you need to, and it could be possible to port containerized applications piecemeal to Fuchsia with some components still running on Linux on co-located or even the same hardware.

I feel like this is one of the benefits of the relatively simpler POSIX style API design, and extensive use of sockets for IPC, over the fairly complex, heaviweight Win32 API and NT kernel. I feel like a lot more software that runs on Linux (and is generally portable to several other POSIX-ish OS's) would be a lot easier to port to Fuchsia, and in an incremental way, than all of the software that runs on Windows systems would be to port to Midori.

They did not gave up, management pulled the cord on the team.

Joe mentioned at his Rustconf talk how hard it was to convince the Windows team, even with the system running in front of them.

When people are religiously against something, no amount of technical achievements is going to change their mind.

That is incredibly disheartening to hear. I wonder if Satya knows about this point of view.

It was on the closing Keynote

RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy

https://www.youtube.com/watch?v=EVm938gMWl0

You can get more glimpses of how things went when reading between the lines on his Midori postmortem, InfoQ content or occasional twitter comments.

Shouldn't they have launched it as an alternative to Windows, for those users who want the benefits (reliability, security, whatever) rather than abandoning it? Make it free ($0) and open-source to encourage adoption. And why couldn't it run Windows in a VM for backward compatibility?

I personally agree, but the counterpoint is that this would have taken Microsoft's already confusing and uncertain product and platform roadmap and make it even much worse. I think those worries were absolutely founded even though I think it would've been worth it anyway.

That's a valid concern, but one caused by selling too many editions of the same product ( https://medium.com/@karti/office-365-was-too-hard-to-buy-so-... ) with artifical differentation, not completely different products with different intrinsic tradeoffs.

>BeOS, which could . . . but was absolute torture to get a proper Web Browser working.

Ah, but that is exactly why I'm paying attention Fuchsia even though in general I ignore new OSes: it would not be hard for the organization behind Fuchsia to instruct the 1000-or-so developers it employs who maintain a web browser to make the web browse runs on Fuchsia.

(and it is open-source).

Wouldn't the hedge against an incompetent Linus replacement just be a fork of the kernel?

Is Google actually good at community collaboration? I honestly don't know. But I would imagine that they require CLA and that would hinder the community. It may be a big problem when BDFL dies if there is no blessed successor, but what is a greater trade off?

I must admit I find the development of Kubernetes extremely well organized fir the sheer size of the project.

Google did a great job starting the Kubernetes community, but they then contributed the project to CNCF (which Google also helped launch). Google remains the top contributor to Kubernetes, but even as their contributions remain substantial, their % of the total contributions is going down, due to the large number of other organizations now backing Kubernetes.

https://k8s.devstats.cncf.io/d/8/companies-statistics-reposi...

(Disclosure: I'm executive director of CNCF. We also build that DevStats tool.)

I think the point is, they don't have to be.

I think CLA is pretty standard for any open source project. I think the first one I ever signed was for Emacs. Emacs has done pretty well and the CLA doesn't seem to be putting many people off from contributing.

I imagine that it makes any potential litigation or dispute much simpler. Even if the license is FOSS, any sort of litigation could have hundreds or thousands of parties involved.

One of the core abilities of Linus is knowing when to say no (the how is more debatable).

Isn't there a way Linus could do what Debian did and ensure that the project lives on regardless of who's in charge?

That would be easy, but ensuring the same level of quality would need someone who thinks like Linus about these things.

Reply on news.ycombinator.com