Google Fuchsia/Zircon design decisions

[kzinti]

The graphics stack, network stack, i/o and event handling, driver model, file systems, security and privacy of both of them are attrocious. I could go on and into depth about these but that would be beating a dead horse.

Without going into too much depth about any of these, care to let us know what is so bad about everything in Windows and Linux? What would be better alternatives?

If there is one thing I think Windows is great at is I/O and event handling. In fact I haven't seen anything as good in any other system. The whole kernel was built around this I/O model and its design was the main driving force behind NT. It got a bad reputation because people have been trying to shoehorn Linux libraries into Windows and ended up with slower performances there. But this is not Windows' fault that people are trying to use polling when native async I/O and event handling should be used (something that Linux lacked for a very long time and still doesn't do a great job at).

[eekee]

[Windows] got a bad reputation because people have been trying to shoehorn Linux libraries into Windows and ended up with slower performances there.

True, but the problem is broader than this. I've seen — and been led into — some real hatred based primarily on some system not supporting some older dev's notions of orderly design. It can be difficult to determine whether this hatred is based on good reasoning or lack of thought. I recall one dev who really hated callbacks. He recommended a system based on threads and message passing, but then he recommended a library within that system which tranlated these messages to callbacks on a single main thread. What? But looking a little deeper, a paper of that system (Plan 9 from Bell Labs) states that it's easy to derive asynchronous behaviour from synchronous, but not to get synchronous behaviour from asynchronous. Clearly, Mr. Furious Callback-Hater believed this paper. This leaves me wondering if he understood the problem the paper describes, or merely believed it because it came from the Magnificent Code Masters of Bell Labs. I got the impression he tended to idolize people. (I don't think I understand the problem at present, it's been at least a year since I last considered it.)

Here's another example. I can find no indication that Gerry Rzeppa, database researcher and author of the CAL plain English programming system ever worked with Unix, but he still hated Windows and its event system. Here are his words, personifying CAL as if the ide/compiler system were speaking in the first person. (This was the fashion for computer tutorials in the past.)

If you looked around in my noodle a few pages back, you know that just "starting up" on the kluge requires over 100 lines of the goofiest code ever seen by mortal man. And if you look further into the event processing defined there, you will find that it gets nothing but worse.

Did he just not understand async IO, or had he seen something better? Perhaps it doesn't matter; he wasn't always the most farsighted researcher himself. To quote his blog:

And then came the surprise (which I report to my shame). When we tried to design a system for our own house — using the techniques we had been so successful at selling to others — we found both the tools and the resulting system to be exceptionally cumbersome and, in the end, altogether untenable.

But doesn't that epitomize what we're all trying to avoid? I'm sure everyone who has been programming for a decade or more recalls concepts and systems which seemed wonderful, even beautiful, but in practical use turned out to be "exceptionally cumbersome and, in the end, altogether untenable." The question of the moment seems to be whether Windows IO system is one of these. Some say yes, some no, which I'm sure is very interesting for psychology students. Perhaps different people have trouble visualizing how to work with different systems.