OSNews

Let's refrain from spreading disinformation. Con did some interesting and important work in bringing completely fair scheduling to Linux. But his scheduler had problems... which is OK. But his attitude was that the people reporting the problems were corner cases and didn't matter... which is not. Linus told Con so in no uncertain terms. Con threw a hissy fit.

Ingo Molnar decided to do more than just talk and wring his hands regarding the issue. He wrote a new completely fair scheduler, which also had its problems at first. But Ingo took on a more responsible and "work with" attitude toward the bugs and his users. Linus selected Ingo's scheduler because of that, and said so. Petulant Con took his ball and went home, but not without posting one last drama piece on the way out.

Of course, recently he has made noises suggesting a return. And early indications suggest that he intends to bring the drama with him.

Edited 2009-10-27 14:17 UTC

sbergman27 posted...

That's not what it looked like to me when I went back and read through the kernel mailing list.

As for Ingo Molnar, as far as I can tell the only reason he was selected was because he was already in the clique. The scheduler he provided did not really help all that much in making Linux work as well on desktops as it does on the big iron. If I were spreading misinformation I'd claim that Molnar "stole" his scheduler by aping Con's work. I did not and do not claim this--not even Con says this. There is no misinformation here.

I just understand that Linus has made it quite clear oiver the years where his focus is--and that is not the desktop.

Which is fine, really, because it means that all projects like Haiku have to do is provide a better desktop oriented operating system and the users will follow them. If the user drain gets large enough we might even see some changes in how responsive the Linux desktop becomes... Ah the joys of competition!

Meanwhile, as I said we have the large pool of FOSS applications from which Haiku can draw and obtain those necessary basic applications until such a time they can be either forked and rewritten as native or native applications are written capable of taking full advantage of the Haiku framework.

No matter what happens the user wins!

Just understand that people will go with what works best on their hardware, so if Linus is more happy fiddling with 4096 CPUs instead of making basic stuff like flash work, well people who want the flash to work will go elsewhere.

--bornagainpenguin

I am all for native Haiku applications.

Actually I am more interested to try out Haiku than Linux nowadays.

I had some contact with BeOS back in the day, and still have the old R5 CDs somewhere.

My comment was more to emphasis that contrary to what many people think, multiplatform toolkits also bring problems.

For example, lets say you are targeting MacOS X, then maybe your usage of some CoreXXX APIs is what will set your application from the rest. Or if you are targeting Windows, maybe there are also some Win32 API calls that will make your application shine, when compared with the available applications.

This is of course an experience that cannot be made multiplatform.

Sometimes you can only target a specific platform.

I just have to correct this, because for some reason this is a mistake I see so often from people when talking about cross-platform toolkits (most recently Google made this mistake).

Just because you use Qt doesn't mean you can't put in platform specific stuff. I have apps that run on Windows, Mac, and Linux using Qt. 98% of the code is cross platform using Qt. On Windows there is platform-specific code to do things like speech synthesis and some specific Windows behaviour that's not in Qt. On Mac I have mac-specific code to integrate into system services like spell checking.

Qt doesn't stop you from adding platform specific code to integrate into the environment. If a cross-platform toolkit doesn't provide 100% of people's needs, they seem to be inclined to throw the baby out with the bathwater and just start from scratch. We'll I'd much rather share 98% of my code between platforms than rewrite the UI on every single one.