6 ms·

Could it be possible to shove the linux kernel under the Haiku userland? This would give access to all drivers available in linux. You could sacrifice compat

Could it be possible to shove the linux kernel under the Haiku userland? This would give access to all drivers available in linux. You could sacrifice compatibility with the linux or POSIX userland. A bit the same thing as WSL1, but from Linux tu Haiku.

MisterTea 5y ago
There is a defunct project which did exactly that called BlueEyedOS. http://blueeyedos.com/ http://blueeyedos.com/
AshamedCaptain 5y ago
This is why I dislike Linux. Some of the policies regarding drivers may make sense, but the net result is that rather than having a lively ecosystem of free operating systems with all of them sharing decent hardware support, we have a Linux monoculture with it being the only operating system with any type of hardware support and the rest being terrible compared to it (even Windows is bad). In part I guess it's because there is no Linus-enforced requirement to have sane specifications, rather than only code. In fact, they seem to encourage having Linux-specific drivers to the detriment of other OSes. Having non-upstream "generic" drivers is not only heavily frowned upon but also rather hard due to the constant breaking API changes. And for upstreamed drivers, you basically have to make your kernel code all but Linux-specific in order to have any chance; generic code or code that doesn't use all the specific Linux infrastructure is basically forbidden everywhere except staging/. The lack of stable API/ABI should in theory prevent "write-once-and-forget" drivers, as well as discourage proprietary ones, but in practice we have both of these. I would really like to see how the world would look like if there was one stable, open, popular API for drivers.
- kitsunesoba 5y ago
  I think that perhaps pushing for drivers in userspace wherever possible would improve this situation significantly. Userspace drivers for Linux would still be built with various Linuxisms, but at least you get all the kernel specific bits disentangled which improves portability a lot and makes writing compatibility layers for other operating systems more feasible.
- phendrenad2 5y ago
  You're 100% correct. I'll add to that the fact that GPL drivers can't be used as-is in non-GPL kernels. It's a one-way street leading to Linux.
  - 1_player 5y ago
    The GPL is a virus, by design. I'd go so far as to say if Linux didn't exist, the GPL wouldn't be so common, and we'd prefer less restrictive licenses such as those from the BSD world.
    - selfhoster11 5y ago
      If anything, the open source movement (or the free software movement, tak your pick) would be much poorer for it, and see open source relegated to a library and infrastructure layer of the IT world. As is, with GPL at least there's a chance of having a vertically FOSS stack for hardware that's within most people's reach.
- MisterTea 5y ago
  This issue is not the fault of Linux but manufactures who REFUSE to release datasheets and programming manuals. Instead these manufactures "embrace" Linux (Which to them == open source) by writing undocumented drivers for undocumented hardware. So OS devs play reverse engineer and cargo cult the undocumented Linux driver bit twiddling dance routines into their driver code and pray it works.
  - AshamedCaptain 5y ago
    > In part I guess it's because there is no Linus-enforced requirement to have sane specifications, rather than only code. i.e. Imagine they just enforce that in order to submit a driver upstream you have to actually document it, so that problems can be fixed in the future.
    - MisterTea 5y ago
      Its a nice idea but it wont happen. A. those manufactures have zero incentive to give away their work and B. Linux is mostly used as a server/mobile OS so most people using it just want hardware to work.
- vanviegen 5y ago
  The alternative would be to have drivers that work against a fixed common ABI (or API, if you just want source level compatibility). Good lucking trying to get operating systems to agree on this ABI. Linux is constantly breaking these internal APIs for a reason: to keep adding new (hardware) features, while preventing each driver from implementing large amounts of would-be-common code each in their own non-standard and slightly broken way. That's why some types of drivers tend to be huge on Windows: they're offering functionality that the (relatively stable) driver API doesn't support. This approach requires drivers with user interfaces. Good luck doing that cross-platform. What you're asking for is highly impractical.
- hyperman1 5y ago
  It's a bit strange you blame this on Linux, instead of e.g. Microsoft. The PC (more or less accidentally) started out as standardized hardware. Everyone could write an OS for it. Then things like sound cards, network cards, advanced video were added on top, but standardization here was incomplete to nonexistent. All kinds if programs had drivers, e.g. games for sound cards etc. As an example, I had to install a printer driver in wordperfect 5.1, a word processor under DOS. Windows centralized these drivers. Games could talk to the sound API. Word processors to the printer API. Hardware vendors could stop writing drivers forceach program. But note a fundamental shift here: No more standard hardware spec, only a standard driver spec. Microsoft didn't ask for this, but didn't fight it too hard either. History accidentally gave them a moat, and they liked it. They could easily have pushed hardware specs harder, like they did for USB with HID and Mass Storage. There is no sane need for individual printer driver, for example. A standard way to push a bitmap, to read some specs( DPI), to control buttons, toner levels and lights gets you mostly there. We would have 1 stable high quality printer driver for each OS instead of the crappy mess we have now. In fact, IPP getsvus partially there. But you need a big player pushing for it, and Microsoft has everyone working for only them right now, so why would they change anything. Linux wrote its own drivers until it got big enough to get some love from some big hardware vendors. But I see no way for it to push hardware standardization.
  - AshamedCaptain 5y ago
    Yes, that is right; Microsoft needs a lot of the blame. But today Linux has the mantle. In fact a shitton of the Linuxisms that we have today in the embedded space (e.g. "BSP"s) come directly from Microsoft.
somewhatbetter 5y ago
Why linux advocates are like "Oh, here is a nice alternative OS, lets tamper it with linux, because everything is better with linux!"? Stop wishing others to change, start change linux instead. And yes, you can use Haiku kernel with gnu userland, so there is no big roadblock there. Good luck.
rodgerd 5y ago
> Could it be possible to shove the linux kernel under the Haiku userland? One of the joys of the BeOS kernel is that it is optimised to be extremely responsive to interactive, graphical workloads. The Linux kernel is not.
- renox 5y ago
  And it's so much easier to write several hundreds of drivers for the Haiku kernel instead of one 'desktop user' scheduler for Linux.. /S
  - rvz 5y ago
    Well I would like to know which Linux distros I need to support and test for my GUI software to be consistently guaranteed to be ‘officially supported’ like Windows, and Mac.
  - selfhoster11 5y ago
    The problem isn't just a "desktop user" scheduler (in fact, I'm pretty sure that compiling the kernel with a 1000Hz tick might address that). The problem is that the Linux GUI stack is largely corrupt beyond recovery: - the UI is largely awful. Most distributions adopt GNOME or resort to writing their own DE if they want to achieve a particular UX end-to-end. - the graphics stack is largely awful. X11 is bad, and Wayland is less bad but I want to see something that doesn't leave me wanting if it's the "end-all and be-all" of modernised UI stacks. - the audio stack is bad. PulseAudio should be replaced, IMO, but Pipewire may fix this - the graphics toolkits are bad. GTK still has the proverbial thumbnail picker missing, and QT has commercial licensing issues. - packaging is a mess. There are at least 3 "new" packaging formats (AppImage, Flatpak, Snap), and countless traditional packaging formats. It's a nightmare for independent software vendors, who only need to produce 1 (maybe 2) binaries per any other platform. - binary compatibility is capital-B BAD. Windows 10 can run GUI binaries compiled for Windows 95, and meanwhile Ubuntu 8.04 binaries will refuse to run on Ubuntu 20.04 unless they were statically compiled. "Don't break the userspace" begins and ends at the Linux kernel - literally everything above it, including core GUI libraries and the C runtime itself has broken old userspace usages. The problem is not reworking a scheduler, it's reworking large parts of the desktop stack and the culture surrounding it. At this point, I'd surrender Linux to the servers and wait another 10 years for another OS to have its Year of the "X" Desktop.

MisterTea 5y ago

There is a defunct project which did exactly that called BlueEyedOS. http://blueeyedos.com/ http://blueeyedos.com/

AshamedCaptain 5y ago

This is why I dislike Linux. Some of the policies regarding drivers may make sense, but the net result is that rather than having a lively ecosystem of free operating systems with all of them sharing decent hardware support, we have a Linux monoculture with it being the only operating system with any type of hardware support and the rest being terrible compared to it (even Windows is bad). In part I guess it's because there is no Linus-enforced requirement to have sane specifications, rather than only code. In fact, they seem to encourage having Linux-specific drivers to the detriment of other OSes. Having non-upstream "generic" drivers is not only heavily frowned upon but also rather hard due to the constant breaking API changes. And for upstreamed drivers, you basically have to make your kernel code all but Linux-specific in order to have any chance; generic code or code that doesn't use all the specific Linux infrastructure is basically forbidden everywhere except staging/. The lack of stable API/ABI should in theory prevent "write-once-and-forget" drivers, as well as discourage proprietary ones, but in practice we have both of these. I would really like to see how the world would look like if there was one stable, open, popular API for drivers.

kitsunesoba 5y ago
I think that perhaps pushing for drivers in userspace wherever possible would improve this situation significantly. Userspace drivers for Linux would still be built with various Linuxisms, but at least you get all the kernel specific bits disentangled which improves portability a lot and makes writing compatibility layers for other operating systems more feasible.
phendrenad2 5y ago
You're 100% correct. I'll add to that the fact that GPL drivers can't be used as-is in non-GPL kernels. It's a one-way street leading to Linux.
- 1_player 5y ago
  The GPL is a virus, by design. I'd go so far as to say if Linux didn't exist, the GPL wouldn't be so common, and we'd prefer less restrictive licenses such as those from the BSD world.
  - selfhoster11 5y ago
    If anything, the open source movement (or the free software movement, tak your pick) would be much poorer for it, and see open source relegated to a library and infrastructure layer of the IT world. As is, with GPL at least there's a chance of having a vertically FOSS stack for hardware that's within most people's reach.
MisterTea 5y ago
This issue is not the fault of Linux but manufactures who REFUSE to release datasheets and programming manuals. Instead these manufactures "embrace" Linux (Which to them == open source) by writing undocumented drivers for undocumented hardware. So OS devs play reverse engineer and cargo cult the undocumented Linux driver bit twiddling dance routines into their driver code and pray it works.
- AshamedCaptain 5y ago
  > In part I guess it's because there is no Linus-enforced requirement to have sane specifications, rather than only code. i.e. Imagine they just enforce that in order to submit a driver upstream you have to actually document it, so that problems can be fixed in the future.
  - MisterTea 5y ago
    Its a nice idea but it wont happen. A. those manufactures have zero incentive to give away their work and B. Linux is mostly used as a server/mobile OS so most people using it just want hardware to work.
vanviegen 5y ago
The alternative would be to have drivers that work against a fixed common ABI (or API, if you just want source level compatibility). Good lucking trying to get operating systems to agree on this ABI. Linux is constantly breaking these internal APIs for a reason: to keep adding new (hardware) features, while preventing each driver from implementing large amounts of would-be-common code each in their own non-standard and slightly broken way. That's why some types of drivers tend to be huge on Windows: they're offering functionality that the (relatively stable) driver API doesn't support. This approach requires drivers with user interfaces. Good luck doing that cross-platform. What you're asking for is highly impractical.
hyperman1 5y ago
It's a bit strange you blame this on Linux, instead of e.g. Microsoft. The PC (more or less accidentally) started out as standardized hardware. Everyone could write an OS for it. Then things like sound cards, network cards, advanced video were added on top, but standardization here was incomplete to nonexistent. All kinds if programs had drivers, e.g. games for sound cards etc. As an example, I had to install a printer driver in wordperfect 5.1, a word processor under DOS. Windows centralized these drivers. Games could talk to the sound API. Word processors to the printer API. Hardware vendors could stop writing drivers forceach program. But note a fundamental shift here: No more standard hardware spec, only a standard driver spec. Microsoft didn't ask for this, but didn't fight it too hard either. History accidentally gave them a moat, and they liked it. They could easily have pushed hardware specs harder, like they did for USB with HID and Mass Storage. There is no sane need for individual printer driver, for example. A standard way to push a bitmap, to read some specs( DPI), to control buttons, toner levels and lights gets you mostly there. We would have 1 stable high quality printer driver for each OS instead of the crappy mess we have now. In fact, IPP getsvus partially there. But you need a big player pushing for it, and Microsoft has everyone working for only them right now, so why would they change anything. Linux wrote its own drivers until it got big enough to get some love from some big hardware vendors. But I see no way for it to push hardware standardization.
- AshamedCaptain 5y ago
  Yes, that is right; Microsoft needs a lot of the blame. But today Linux has the mantle. In fact a shitton of the Linuxisms that we have today in the embedded space (e.g. "BSP"s) come directly from Microsoft.

somewhatbetter 5y ago

Why linux advocates are like "Oh, here is a nice alternative OS, lets tamper it with linux, because everything is better with linux!"? Stop wishing others to change, start change linux instead. And yes, you can use Haiku kernel with gnu userland, so there is no big roadblock there. Good luck.

rodgerd 5y ago

> Could it be possible to shove the linux kernel under the Haiku userland? One of the joys of the BeOS kernel is that it is optimised to be extremely responsive to interactive, graphical workloads. The Linux kernel is not.

renox 5y ago
And it's so much easier to write several hundreds of drivers for the Haiku kernel instead of one 'desktop user' scheduler for Linux.. /S
- rvz 5y ago
  Well I would like to know which Linux distros I need to support and test for my GUI software to be consistently guaranteed to be ‘officially supported’ like Windows, and Mac.
- selfhoster11 5y ago
  The problem isn't just a "desktop user" scheduler (in fact, I'm pretty sure that compiling the kernel with a 1000Hz tick might address that). The problem is that the Linux GUI stack is largely corrupt beyond recovery: - the UI is largely awful. Most distributions adopt GNOME or resort to writing their own DE if they want to achieve a particular UX end-to-end. - the graphics stack is largely awful. X11 is bad, and Wayland is less bad but I want to see something that doesn't leave me wanting if it's the "end-all and be-all" of modernised UI stacks. - the audio stack is bad. PulseAudio should be replaced, IMO, but Pipewire may fix this - the graphics toolkits are bad. GTK still has the proverbial thumbnail picker missing, and QT has commercial licensing issues. - packaging is a mess. There are at least 3 "new" packaging formats (AppImage, Flatpak, Snap), and countless traditional packaging formats. It's a nightmare for independent software vendors, who only need to produce 1 (maybe 2) binaries per any other platform. - binary compatibility is capital-B BAD. Windows 10 can run GUI binaries compiled for Windows 95, and meanwhile Ubuntu 8.04 binaries will refuse to run on Ubuntu 20.04 unless they were statically compiled. "Don't break the userspace" begins and ends at the Linux kernel - literally everything above it, including core GUI libraries and the C runtime itself has broken old userspace usages. The problem is not reworking a scheduler, it's reworking large parts of the desktop stack and the culture surrounding it. At this point, I'd surrender Linux to the servers and wait another 10 years for another OS to have its Year of the "X" Desktop.