Well, last time i tried Haiku i tried to write a simple program and at some point when i pressed save in the editor the entire OS crashed, so there is that :-P.
ALSA not playing either means that there are driver issues - and i highly doubt Haiku solves the problem of drivers having bugs - or there is some configuration issue.
But this (configuration) issue and the desktop focus do not seem to require getting rid of the entire kernel and - most importantly - the systems it supports. If X11 doesn't do (which i doubt, X11 ran on way more restricted hardware than what is available even on $5 "computers" today, but lets roll with it) you could simply write a new window system from scratch and provide a layer for everything you may think a desktop system needs so that any application written on that layer will keep working if the backend library/tech changes.
And from my understanding of Haiku, this is basically what happens already (<Stuff>Kit depends on some popular open source library for <Stuff> that is already available on Linux but exposed to applications through the <Stuff>Kit API), except with a kernel that doesn't support most things that people need today.
Personally i like the idea of Haiku as a desktop focused system, i just do not see what exactly having a custom kernel with its own need for drivers and hardware compatibility provide that a layer on top of kernel that exposes a similar API doesn't (beyond of course the hack value and the fun of making a kernel - something i am 100% totally behind as i personally write a lot of stuff just for the fun of it).
> when i pressed save in the editor the entire OS crashed, so there is that
Well, when was this? Probably a few years ago? We've really improved since then.
> or there is some configuration issue
In the case I alluded to here it was a configuration issue. I eventually solved it, but it took me about 4-5 hours of Googling and reading settings files. Really not something an end-user should have to think about.
> on way more restricted hardware than what is available even on $5 "computers" today, but lets roll with it
Great. Show me a Linux distribution right now that can do that, while also having the default installed web browser play YouTube. Is it "possible"? I don't know, but nobody seems to be doing it.
> except with a kernel that doesn't support most things that people need today.
> Well, when was this? Probably a few years ago? We've really improved since then.
Yes it was a couple of years ago.
> In the case I alluded to here it was a configuration issue. I eventually solved it, but it took me about 4-5 hours of Googling and reading settings files. Really not something an end-user should have to think about.
Indeed, but if your project controls everything above the kernel to the desktop environment (what Haiku already does, minus the kernel itself) you can handle the configuration too. The idea is that a program will talk to your desktop API which will talk to the kernel - the configuration is up to you to handle pretty much the same way as Haiku already does.
> Great. Show me a Linux distribution right now that can do that, while also having the default installed web browser play YouTube. Is it "possible"? I don't know, but nobody seems to be doing it.
I think you totally misunderstood the part you quoted. I was referring to X11, the earlier implementations of which was running on hardware like IBM 6152 with a 5.9MHz CPU and 1MB of RAM. A $5 Raspberry Pi Zero is a sci-fi level supercomputer compared to that.
> [[Citation needed]]
There is no point going antagonistic over this, the Haiku site has all the information you need:
> I think you totally misunderstood the part you quoted. I was referring to X11, the earlier implementations of which was running on hardware like IBM 6152 with a 5.9MHz CPU and 1MB of RAM. A $5 Raspberry Pi Zero is a sci-fi level supercomputer compared to that.
I know. I mean, if that's possible, why is nobody doing it with Linux today? Or is it impossible in practice?
> There is no point going antagonistic over this, the Haiku site has all the information you need:
That page is pretty severely outdated; most of the drivers listed on that page are now confirmed as working, and we've merged more network ones from FreeBSD as time permits. Really, our hardware support is actually pretty good these days.
> Also last time i checked there wasn't even accelerated OpenGL.
There still is not, but there are blueprints for implementing it. If we had more than a man-month of development effort spent per month, we might actually get to it...
> I mean, really consider the issues people have on a popular OS like Linux to get hardware working properly - Haiku is in a much worse position here.
Maybe. But if that's the one con vs. all the aforementioned pros to having our own kernel, why is that such a problem, really? If the system really is "that much better," then users will be fine with buying specific hardware, at least until we can get the time and resources to support more.
ALSA not playing either means that there are driver issues - and i highly doubt Haiku solves the problem of drivers having bugs - or there is some configuration issue.
But this (configuration) issue and the desktop focus do not seem to require getting rid of the entire kernel and - most importantly - the systems it supports. If X11 doesn't do (which i doubt, X11 ran on way more restricted hardware than what is available even on $5 "computers" today, but lets roll with it) you could simply write a new window system from scratch and provide a layer for everything you may think a desktop system needs so that any application written on that layer will keep working if the backend library/tech changes.
And from my understanding of Haiku, this is basically what happens already (<Stuff>Kit depends on some popular open source library for <Stuff> that is already available on Linux but exposed to applications through the <Stuff>Kit API), except with a kernel that doesn't support most things that people need today.
Personally i like the idea of Haiku as a desktop focused system, i just do not see what exactly having a custom kernel with its own need for drivers and hardware compatibility provide that a layer on top of kernel that exposes a similar API doesn't (beyond of course the hack value and the fun of making a kernel - something i am 100% totally behind as i personally write a lot of stuff just for the fun of it).