Hacker News new | comments | show | ask | jobs | submit login
First Rule of Google Fuchsia OS Is to Not to Talk About It (fuchsiatalks.com)
89 points by secjet1 125 days ago | hide | past | web | 55 comments | favorite

Saw this rant about Fuchsia on reddit that appears on the surface to make some good points: https://www.reddit.com/r/programming/comments/6a026o/googles... Not my area of expertise for sure though.

Any kernel dev types here had a chance to look at Fuchsia? Is the criticism warranted?

Update: Fixed link to point at the right comment.

Edit: Should have mentioned the tone is a bit over the top. More interested in the actual points raised though.

I'd suggest that it's possible we're using simple, but functional placeholder implementations of things so the entire system can boot and run, and then various parts of it can be worked on at various paces, in parallel, etc.

Lot of moving parts in a kernel, or OS, and one could try to write all of them in their final form first and hope they all work together when done, or one could take a more incremental approach.

Personally, I think the evolution of the general kernel design / syscall interface, love it or hate it, is more interesting than have we optimized the timer implementation yet...

https://fuchsia.googlesource.com/magenta/+/master/docs/conce... https://fuchsia.googlesource.com/magenta/+/master/docs/sysca...

(It's all a work in progress, which has been and will continue to evolve)

(For context, swetland is currently the main contributer to Magenta, Fuchsia's kernel: https://github.com/fuchsia-mirror/magenta/graphs/contributor...)

The stats are a little unfair there, as I've done a lot of rearranging and housecleaning, which tends to inflate github's scoreboards. I suspect more of my work is outside the kernel than in (driver model/hosting/managing, userspace core glue, etc), but certainly I'm to blame for a reasonable chunk of kernel code too.

I also encourage anyone that sees something that could be done better to sign up and submit some code!

I suspect some are holding back since there's not been much shared about the end purpose. At the moment there's still speculation as to whether it's for mobile devices, desktops, both, or something else.

That would be a lot easier if it were GPL with no CLA.

The way it currently is, it looks like something Google will develop with the help of the FLOSS community, and then take the code, close it, and continue everything else in the dark.

As they’ve done with most parts of Android by now.

We all have bad days, but some of this rant is really toxic.

Dear god. I looked at the kernel and it's awful

Stuff real operating systems have solved decades ago


This is hilarious. Did they decide to reinvent all the wheels badly just because someone at Google was bored?

The ex kernel developer in me feels insulted that a serious company would release something this immature

So, have they actually released Fuschia? I was under the impression that this was still being developed in the open until such time as it actually becomes a "real operating system"? And IMHO the world needs a good open-source microkernel OS; I'm ok if the scheduler is suboptimal on release - that can be fixed eventually. Linux will never be a microkernel OS, but Fuchsia can always be optimized. Performance-wise it just needs to be good-enough on release.

> Did they decide to reinvent all the wheels badly just because someone at Google was bored?

This is how projects are born and die at Google. They live until no one is interested in them anymore and they are abandoned.

> They live until no one is interested in them anymore and they are abandoned.

Sometimes they don't even wait until no one is interested!

A quote that, while not automatically true, seems to apply to many situations:

"People who are brutally honest generally enjoy the brutality more than the honesty." - Richard Needham

A bit off topic, but thanks for this quote !

It resonates a lot with my experience.

>The ex kernel developer in me

He seems to be reciprocating the years of criticisms and verbal abuse given to him by Torvalds.

His comments sound more like he contributed to one of the BSD kernels.

He doesn't really indicate what kernel he worked on. Regardless, Linus knows no kernel boundaries ;)

I'm also surprised that someone, who purports to be knowledgeable on kernel development, was not cognizant of the fact that the code he was looking at was only started 8 months ago and no where near production quality. To start making assumptions on the quality of an OS based on very early code was extremely immature and makes me wonder what exactly his qualifications really are. The primary goal of the Fuchsia team is to try and get something booting up and running and then start to iterate and polish.

He does, later in the thread...

"I just learned by doing. Got annoyed by something being bad in one of the BSDs, found out how to get into their secret chat channel, started whining and got told to shut up and write the code. So I did."

And rambles more about why he feels Fuchsia did the wrong thing. Specifically because better implementations of some parts with licenses compatible with Fuchsia existed. Which I suspect is a nod again to BSD.

With a more calm tone I think saying that writing your own suboptimal tick timers, or locking strategy, or whatever...versus using something known good, is fair criticism. Not being my space, I wasn't sure if the base criticism was valid. The responses here seem to indicate they are.

The problem with his criticism is that he seems to think the present decisions the authors have made, for an 8 month old OS, are written in stone. It's like reviewing a car while it's still being assembled at the factory.

Fuchsia is probably 2 or more years away from an Alpha release. Things are changing at a rapid pace.

No, I got that idea. But, for his examples, he mentions existing solutions could have been lifted.

If the suboptimal stuff was existing, I take your point. Perhaps it was straight from LK?

But writing something new, that has flaws, as a placeholder...when something better exists already, and has a compatible license...that seems fair game to question.

Especially if it's something that has tentacles and creates dependencies. Placeholders sometimes don't stay as such.

That's a good point...I should have mentioned the tone. Despite it, though, there is some actual content in the rant.

On the one hand, the tone is pretty bad, and if someone on my team had done this in a code review, I'd have to have a serious discussion with them.

On the other hand, it's a reddit comment.

When you are trying to invent a new version of anything low level, sometimes it makes sense for you to just stub out a supporting library out with a naive implementation, because you then have an interface that you can move around easily. If you are wrapping an existing implementation, with lots of optimizations and corner cases, you'll just get bogged down in refactoring all of those expectations over and over.

Today I implemented an immutable-ish array in JavaScript. I'm using it because I needed something that could work in conjunction with the non-relational, non-key-value database I am building. There were other libraries that provided immutable arrays, probably much better than my implementation. But because I wrote both the immutable data structure and the database, and both implementations are naive, I can very easily trade functionality back and forth between them in order to get the interface right where it needs to be.

There's a good chance I'll then swap out my data store for some existing algorithm, but I really won't know which algorithm I even need until after I've built several applications on top of the naive implementation.

Really, the key here is that this is prototyping. When you're building a prototype, you don't do the thing that will lead to the most correct code, you do the thing that will teach you the most about what the design should be.

Yes...updating. thanks.

Well there is this: https://lwn.net/Articles/718267/

I don't see the rant; that's just the link to the whole discussion. Did you mean to link to a particular comment?

I haven't followed Fuchsia that closely, but I was under the impression that the team consisted of some all-star kernel developers; former BeOS people for example?

Can't tell which comment you mean, but if you mean the criticism that Dart is used as a userspace language, that's not related to the choice of kernel (which seems fine to me).

It wasn't that, no. Fixed the link...it is pointing to the right spot now.

>Their tlb shootdown is not only synchronous, but it only shoots one page at a time, synchronously.

QNX6.6 introduced this too (as a fix for a race condition that existed in QNX6.5 and lower) and it was a huge pain to get actual realtime inbetween the TLB flush storms. Like, this is a make-or-break issue right there. TLB flushes can easily eat 10% of all CPU cores if you start and end a process every second.

They plagiarized our story. Please don't link to them.

Original: http://www.androidpolice.com/2017/05/19/googles-dave-burke-f...

Not really any new information here. It's fun to speculate about what Fuchsia might become, but it's pretty clear Google's not ready to announce anything yet. The only reason we even know it exists is because they made the source code public.

Exactly this. And So fun to speculate on something far from its likely end goal or release state, because _only_ of who made it public.

A lot of cooks in the opinion kitchen looking out the window at wheat growing, pretending it’s already a baked cake, and of which they already dislike the taste.

(Disclosure: I work at Google, not on this.)

Since I work on Android, I try to follow Fuchsia closely since it might impact me greatly one day.

The funniest part is that I have seen reviews of Fuchsia on Youtube.

I am not at Google either but there are 99% chances that the UI that is committed right now is just a tech test designed by devs.

Of course, they chose to bake the cake out in the open, with an air of mystery about the purpose.

My guess is that some Google engineers started an OS project to scratch their own itch, or to test the waters on an anticipated business problem. Detailed speculation is probably useless at this point.

That being said, I really think the time is ripe for a new desktop OS. There's a lot of lessons from iOS and Android that just aren't showing up on Mac and Windows.

I can appreciate that, but I am also not excited about a walled garden growing around desktop.

Yeah, the evolution of Windows and OSX towards integrated "App Stores" and less control over app installation bums me out too. I grew up with a C64 and BASIC at the READY prompt, and hope the world of personal computing allowing anybody to write and run software survives well into the future.

Given that Google is progressively building higher and higher walls around Android, thinking a Google project is going to save you from walled gardens is perhaps a bit silly. Right now it's not marketable, but once it is, expect the business people at Google to start pushing Play Services and the like onto this platform too.

That being said, there's a lot of things about Fuchsia that are pretty interesting, and I'm definitely curious what ends up being done with it.

> thinking a Google project is going to save you from walled gardens is perhaps a bit silly

Not sure where you got that impression. I do not think this project will save me from anything.

Right on time.

When I first found out about Fuchsia (and from the comments on the HN post), I got the impression that it was supposed to be designed for both laptop/desktop (which excited me) and for mobile (which I couldn't care less about), but all the news I've read about it from third parties seem to describe it almost exclusively as a mobile OS. Is this just the media focusing on the parts that they think nontechnical people will find interesting, or were my initial impressions mistaken?

From what I've read the current UX is mobile-only but that really means nothing at such an early stage of development.

Or they wanted their own development platform that they had full control over. Having a RTOS OS that they can use anywhere from cars to phones is also a nice to have.

The first rule of almost any project at Google is not to talk about it. It the only job I've ever had where I could not tell my wife anything about my work, aside from how lunch was. My wife joked that Google was almost as paranoid as the DoD or NSA, and thought it was very presumptuous of them to force so much secrecy.

Have you worked at any other public company? It's pretty common to not share private company information...

There's private, and there's Google.. I work at Netflix now, and we are quite open in my area. Eg, I can tell my wife what I'm working on, ask her to proof-read my presentations, show her the office, etc.

Before Google, I worked for a privately held company, and it was quite a bit more open as well.

I had the same experience at Amazon with their secret projects, including each iteration of their kindle fires

Yeah, every company kinda does this. It seems like most of the the time it's a combination of:

a) we have no idea if this is unique or not (hint: a Kindle Fire revision probably isn't)

b) it makes things seem more exciting.

The weird thing about Fuchsia is that all of the development is done in the open, but noone wants to give any context.

Well if the company is publicly traded, secrecy of internal matters is a legal requirement and contingency of employment.

By default, certainly.

Btw: In February I spent some time looking at the then about 100 committers to Fuchsia/Flutter. Some quite impressive names. I think Fuchsia is a really serious effort in the Chrome team.

> I think Fuchsia is a really serious effort in the Chrome team.

There's definitely a lot of ex-Chrome people there, but I don't think it follows that it is in any way in the Chrome team. I'm still curious as to why all of them are essentially creating a new OS, though! Quite the departure from what they've worked on before (and many have been working on the web for two decades).

This looks to be plagiarized from Android Police.


EDIT: And the submitter has only submitted links from this blog.

Not exactly surprising.

Even something like Kotlin as 1st party language has been kept under wraps until the last moment.

Whether Kotlin is an experiment, the future of Android or something else, Google is not going to discuss about it for a while.

> Did they decide to reinvent all the wheels badly just because someone at Google was bored?

If I had to guess, it would be that (bored), or perhaps trying to specifically avoid existing patents/copyrights/etc by showing that they did completely reinvent the wheel instead of copying from existing "common knowledge"?

I'm no lawyer though, especially not a patent lawyer, so I could be way off the mark...

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact