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)
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.
Dear god. I looked at the kernel and it's awful
Stuff real operating systems have solved decades ago
WTF?
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.
This is how projects are born and die at Google. 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!
"People who are brutally honest generally enjoy the brutality more than the honesty." - Richard Needham
It resonates a lot with my experience.
He seems to be reciprocating the years of criticisms and verbal abuse given to him by Torvalds.
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.
"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.
Fuchsia is probably 2 or more years away from an Alpha release. Things are changing at a rapid pace.
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.
On the other hand, it's a reddit comment.
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.
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?
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.
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.