[quote=PulkoMandy]
If getting all the Linux mess is your goal, why not run Linux? It’s a much better fit for the job, there are pleinty of distros available. It would be much simpler to port the Deskbar to run on Linux, if that’s the only thing you like about Haiku?[/quote]
Haiku’s kernel is more minimal and coded to support better multitasking, while on Linux to get the same performance you could on Haiku would mean editing parameters, tweaking the kernel and editing drivers to perform at their best performance. A new Linux user would probably not know how to do this and go back to their original operating system, because the fact that they have to edit a system to get a performance gain might scare them.
What’s great about Haiku is that as soon as you download and install the iso, the system is blazing fast, turning an old 10 computer to acting like a 5 year old computer.
And with X, new users could install their favorite Desktop or window manger to tweak it to there taste and still get far better performance then they would on any other distro. Making them stay with this OS and to not be tempted to try another.
So with X on Haiku we could bring more users and coders to Haiku to expand on what is already great.
The only thing I like about Haiku is the kernel to be honest.
Just thought of this. If any of you have heard of Joli OS, There WM is actual HTML5 code with a lot of javascript. It would be easier to have the current display manager which is in use with Haiku altered to support HTML5 code and start building a HTML5 desktop. Load times would be faster because HTML is small and also applications can get nice eye candy animations.
I don’t know why people think the reactive user interface is because of our kernel. It’s not. Our kernel is actually slower than the Linux one. Run any benchmark and you’ll notice that. Run a compiler and you’ll see it takes longer on Haiku. Haiku is not fast.
what makes the UI so reactive and pleasant to use is the well-designed APIs, with two main features: the mandatory separation of all apps in one application thread and one thread for each window ; and the default priorities for those threads. Add to this the fact that all apps use the same API and the same libraries, so we have to load those from disk once at boot, and then it’s in memory for every app you start.
If you try to bring the Linux userland over the Haiku kernel, you’ll lose a big part of the magic.
That’s the whole point of working on a complete operating system instead of just a linux distribution or a custom kernel: we have full control over all the layers, and we can tweak them at will to get a result that suits us.
I would imagine it’s because of a lack of understanding. I also don’t understand why you would take something like Haiku, and want to put something as crappy as X for window / desktop manager over it. The big problem with linux that I have seen and continue to see is the “I can do it better” mentality. Hence why there are so many different interface systems (GTK, Clutter, Qt?). The operating system should function as it needs to, and simplify the software by giving a unified front to the machine hardware. Which is why I like Haiku and BeOS. Because they actually do this, quite well. No fighting with what interface libs I may need because I’m running KDE but some people like GTK and some prefer QT and I have to live with those decisions by them if I use that one little software… It makes the whole thing look and operate like a giant children’s toy box. Nothing is ever quite 100% in that environment not to mention the bloat it causes alone. Again, why I believe Haiku is on the right track.
I agree with cpusci 100%. Linux has always been a nightmare, from installation, to application dependencies to configuring drivers. The less Linux-like Haiku is, the better.
If I enjoyed the headaches, I’d just use Linux to begin with, rather than messing up Haiku.
I agree ! ! ! Please don’t turn Haiku into NUX . . . We need some open source stuff ported to complete the user experience (Haiku-i-fied as much as possible) but not NUX windowing . . . Yuck!
“syscalls” are when an application needs the kernel to execute some code. This happens a lot when you run an application. Want to allocate memory? you need a syscall. Open a file? syscall. Write or read bytes to/from it? a syscall as well. Open a network socket? likewise.
This is not the only thing that makes Haiku slow. All the nightly builds, alphas, and the imags you built yourself (unless you configured them otherwise) are built with the kernel in “paranoid debug check” mode. This means when some memory allocation is released in the kernel, it is immediately erased with a “magic” value (0xdeadbeef) to help detecting something that would access it later on. There are many other checks like this all over the place in the kernel, which are very helpful for debugging it (they trigger the KDLs more reliably and closer to the place where the bug is).
There are other differences in the kernel architecture, but I’ll stop here as I’m not familiar enough with our kernel. anyway, the point is, try to benchmark it, and you will notice our kernel won’t make ported UNIX apps suddenly go fast. You can also ask the BlueEyedOS guys, this project was about rewriting the BeAPI to run on top of a Linux system (complete with X11 and everything). And they got apps running much faster than they did on BeOS. Haiku was not yet able to run apps at the time, so we don’t really have a comparison with it.
From a developer perspective all that is fine and good actually. There is a need to debug the kernel and “world” as much as possible and with it in a debug mode by default the project will catch more bugs this way. There will come a time when that isn’t the case but for now, I can see why it would be setup that way. I’m glad that you guys take the time you can to explain things to people who aren’t in the development areas at all about why things are the way they are.
