In this video (.torrent, Quicktime) "you will see great attempts at crashing the Haiku app_server, some commentary on the robustness of the code, and a staggering amount of threads for Java running on BeOS R5." Here is more about the video.
To read all comments associated with this story, please click here.
Member since:I would be interested in how far you could get the same speed on a different kernel.
Or is really the kernel the main reason for the fast and responsive gui?
If I understand correctly, BeOS´ kernel follows closely a microkernel design approach, which brings some performance concerns of its own. The main reason for the BeOS GUI snappiness is that, unlike Linux´s, it runs in kernelspace (X is a userspace application in *NIX) and the BeOS kernel is heavily multithreaded.
I've heard that Beos had a somehow better/finer grained multitasking but that it was harder to program on because of that.
I´m not a developer (at least, not one that´s worth to mention :-)) but I heard the same thing. The freely available Be Book, which has a somewhat outdated reference to the BeOS API helps a lot but in the end, it is up to the developer to leverage the benefits of the heavily multithreaded environment.
I mean, if it was just a design flaw in the kernel than linux should have fixed it by now.
As stated above, it is not a flaw, but a design decision. The Linux kernel is a project completely separated from the GUI, that is an user space application, common to all Unices, running on top of the Linux kernel. There is no such a thing as the Linux GUI.
DeadFish Man
Member since:The kernel does have quite a large effect on the fast and responsive GUI, in that it can do fairly quick task/thread switching, and message passing. However, that's only one of the things that contributes to a responsive GUI.
The BeOS kernel doesn't suffer from a single-threaded Big Kernel Lock that slows things down. Technically, the BeOS kernel isn't a true microkernel, as it does include a lot of things in kernelspace, such as video, network, storage, etc. drivers, but it isn't quite that simple. In the BeOS design, there are kernel level drivers that are often quite minimal, and deal directly with the hardware, and then there are accelerants, which are drivers that run within userspace, that communicate with the kernelspace portion of the drivers. This is how networking and video/GUI is done before BONE (Be OS Networking Environment, which is all within kernelspace) and this means the most complicated stuff (and usually the most likely to be buggy) is done in userspace. This does have performance overhead, of course.
Starting with Windows NT 4.0, Microsoft has done all their GUI stuff within kernelspace; BeOS, Zeta, and Haiku use the kernelspace low-level driver for the video card, combined with the accelerant driver in userspace, and this is driven by the App_Server, which is an entirely userspace application.
The BeOS GUI is very finely multithreaded, which allows it to be more responsive, though not necessarily faster in absolute raw speed than another system for graphics. However, the rest of the system design may make things feel faster. BeOS has a 3 ms standard time quanta, whereas Windows and Linux have much larger ones, typically at least 10 ms each. This also tends to make things more responsive, but it also tends to thrash the CPU cache a bit more as well. Now, for the GUI programming, there's no question that the finer multithreading does make it more difficult to program than writing single-threaded GUI applications in other systems. In BeOS GUI applications, you have a minimum of one thread for the C++ BApplication object that is in the main thread, and also one thread for each separate BWindow, which may be covered with one or more views (aka controls in Windows) that are distinctly different. In Windows, windows contain nested windows and all are handled the same, and each window can have a separate thread and message queue for the most part; in BeOS, a window is something that then has views that can be further divided into views (BView's) where each view is tied to the parent BWindow, which uses one message queue.
BeOS has a much richer message handling system than Windows, and that makes some useful differences. However, Windows in some ways has a better system that's more reliable, though simpler, because the threading model is easier to deal with in Windows. How the GUI is drawn has some significant differences between the two, and what Windows supports for graphics operations in many ways is more powerful/flexible than BeOS has, but of course, it all comes at a price. BeOS uses floating point numbers for the coordinate system in drawing, and Windows uses integers, among other things. But, if you are really curious, look at Windows documentation and the Be Book 
Member since:
I would be interested in how far you could get the same speed on a different kernel.
Or is really the kernel the main reason for the fast and responsive gui?
I've heard that Beos had a somehow better/finer grained multitasking but that it was harder to program on because of that.
I mean, if it was just a design flaw in the kernel than linux should have fixed it by now.