To read all comments associated with this story, please click here.
Apparently you have never run BeOS / Zeta / HAIKU.
And apparently you are wrong, because I have run BeOS. And let me tell you something. It wasn't all that zippy because there was no 2d acceleration for the neomagic chipset in my 1998-era hardware that I ran it on.
The x server system is just too slow to get that feel that is the BeOS experience. If you have never run the OS you would not understand how uncomfortable any Linux / BSD desktop system is ... feels like you are running your computer under water... everything is just too slow.
You're confusing toolkits (gtk+) with X. X isn't slow. In fact, the BlueEyedOS (BeOS api on top of X/linux) developer wrote an article for OSNews years ago, showing how X was not slow.
If it's not going to have accelerated 3d, then it's not going to be much of a desktop operating system in 2007-8 and beyond, no matter what kind of nostalgic feelings you have for it.
there was no 2d acceleration for the neomagic chipset in my 1998-era hardware that I ran it on.
Ummmm did your Neomagic run fast on any platform?
The point of Haiku is to recreate the R5 experience as a solid foundation, THEN move onto new features (I think they call that project "Glass Elevator"). This way they don't waste time arguing about what features will or won't be included in the first release. It's the quickest way to get the actual product out.
Linux distros nowadays are so bloated and slow to bootup that they're just not true to the Be vision. Let the Haiku guys reach that first milestone and THEN worry about where to go next.
Be was about leaving behind legacy cruft. It could be argued that R5 itself is legacy, but I'd argue that it's a whole lot less crufty than modern Linux.
The truely entertaining part of this statement is that BeOS's graphics engine really was never that fast. NT's was faster, and X was faster still.
What made BeOS fast was that the whole thing was designed under one roof. The kernel scheduler, UI toolkit, graphics server, and window manager were all designed by the same group of people, and the window manager and graphics server were co-located in the app_server. As a result, synchronization could be handled propery, and the illusion of speed and responsiveness could be maintained.
the reason Linux GUIs are sedate by comparison is three fold. First, there is no synchronization to speak off. When you resize a window, the application, the X server, and the window manager all have to coordinate. But the kernel basically runs them randomly, and only eventually do you get the desired result. Second, many apps aren't multithreaded properly, or don't use a non-blocking I/O mechanism like select(). On BeOS, this was mandatory in the API. Third, the BeOS UI toolkit was very simple. It was pixel based, not font-sensitive, and had no layout engine. When you resize a window in a GTK+ app, the toolkit goes relayouts all the contents. It does widget layout, based on the widget containers specified in the window. It does internationalized text layout, with correct line-breaking. It also calls the theme to get newly-drawn widgets that fit the new layout. BeOS's toolkit didn't have to do any of that, because it didn't support widget containers, or font-sensitive UI elements.







Member since:
2006-03-25
I know the Haiku reasoning. "It's not a desktop kernel". How much are you giving up by it not being "a desktop kernel" though?
Apparently you have never run BeOS / Zeta / HAIKU. The x server system is just too slow to get that feel that is the BeOS experience. If you have never run the OS you would not understand how uncomfortable any Linux / BSD desktop system is ... feels like you are running your computer under water... everything is just too slow.