4 ms·

True, but is there any point to Haiku now that the Linux PREEMPT_RT patchset is just around the corner and will probably give us soft-realtime capabilities on a

True, but is there any point to Haiku now that the Linux PREEMPT_RT patchset is just around the corner and will probably give us soft-realtime capabilities on a par with the old 16-bit computer OS's (Amiga, Atari ST, etc.) and with BeOS/Haiku itself? Sure, the default UIs (GNOME-Shell, Plasma) are nothing to write home about from a performance POV, but lightweight alternatives do exist and are still highly usable. I find that LXDE or Xfce are no trouble at all even on hardware that's a decade old or perhaps more (the one thing they don't really address is touch-screen focused use, where GNOME itself has a big, if serendipitous, headstart).

rwmj 8y ago
It's a bit more than just a kernel. The whole UI is very light and responsive. I'd urge you to try it and see for yourself, you can run it under QEMU.
- microcolonel 8y ago
  I remember having a PC with BeOS loaded up on it in the early 2000s (aside from a PC 5150, we were not uhh... with the times), and while I agree that it was quick, that could be chocked up to being compared with the Windows of the time, which already had a lot of legacy to contend with (and frankly was plenty fast anyway, at least when it came to basic UI).
- agildehaus 8y ago
  You can also run it off a LiveCD. Much better experience (please report if it doesn't boot).
acdha 8y ago
The big thing about BeOS was that everything was non-blocking - simply adding a kernel patch won’t fix all of the software which locks up any time I/O blocks, whereas the BeOS UI on 90s hardware was more responsive than, say, Windows 10 is today.
- zozbot123 8y ago
  > simply adding a kernel patch won’t fix all of the software That's tautologically true, but something like the RT preemption kernel patch is still a basic requirement for a truly responsive system. Once that's merged, you then have buy-in for that use case and can start fixing all the things that are broken in user-space, as well. Additionally, there's a lot that can be fixed by simple tuning. There's no excuse for UI input locking up when a system is low on RAM, for example. Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority, so that (1) they're always responsive, no matter what, and (2) when the system starts thrashing, they can still grab enough of whatever system resources are available (RAM, CPU, device I/O), so that the user can survey the situation and kill the offending process. Linux distributors are dropping the ball here - this sort of system-wide tuning is their job!
  - acdha 8y ago
    Developers could have used asynchronous interfaces for decades now and it would make the user experience substantially better with no kernel changes at all. There are reasons why they haven't but I don't see any reason to believe those will change with yet another real-time kernel patch. > Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority This approach is prone to priority-inversion and it doesn't help with the underlying problem that programmers have written tons of synchronous I/O all over the place and the call chains are often highly non-obvious. For example, most Linux desktop environments will freeze if you use an authentication provider which isn't instantly responsive and that prevents things like interacting with menus, closing windows, etc. because various low-level libraries do things like check settings which at some point does something like getting your list of groups, which is normally very fast because it's cached. I got some patches into pam_ldap years ago to set socket-level timeouts so it would recover from something like a single socket error but the better solution would be fewer dependencies and interfaces which don't have tons of different things happening on a single thread.

rwmj 8y ago

It's a bit more than just a kernel. The whole UI is very light and responsive. I'd urge you to try it and see for yourself, you can run it under QEMU.

microcolonel 8y ago
I remember having a PC with BeOS loaded up on it in the early 2000s (aside from a PC 5150, we were not uhh... with the times), and while I agree that it was quick, that could be chocked up to being compared with the Windows of the time, which already had a lot of legacy to contend with (and frankly was plenty fast anyway, at least when it came to basic UI).
agildehaus 8y ago
You can also run it off a LiveCD. Much better experience (please report if it doesn't boot).

acdha 8y ago

The big thing about BeOS was that everything was non-blocking - simply adding a kernel patch won’t fix all of the software which locks up any time I/O blocks, whereas the BeOS UI on 90s hardware was more responsive than, say, Windows 10 is today.

zozbot123 8y ago
> simply adding a kernel patch won’t fix all of the software That's tautologically true, but something like the RT preemption kernel patch is still a basic requirement for a truly responsive system. Once that's merged, you then have buy-in for that use case and can start fixing all the things that are broken in user-space, as well. Additionally, there's a lot that can be fixed by simple tuning. There's no excuse for UI input locking up when a system is low on RAM, for example. Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority, so that (1) they're always responsive, no matter what, and (2) when the system starts thrashing, they can still grab enough of whatever system resources are available (RAM, CPU, device I/O), so that the user can survey the situation and kill the offending process. Linux distributors are dropping the ball here - this sort of system-wide tuning is their job!
- acdha 8y ago
  Developers could have used asynchronous interfaces for decades now and it would make the user experience substantially better with no kernel changes at all. There are reasons why they haven't but I don't see any reason to believe those will change with yet another real-time kernel patch. > Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority This approach is prone to priority-inversion and it doesn't help with the underlying problem that programmers have written tons of synchronous I/O all over the place and the call chains are often highly non-obvious. For example, most Linux desktop environments will freeze if you use an authentication provider which isn't instantly responsive and that prevents things like interacting with menus, closing windows, etc. because various low-level libraries do things like check settings which at some point does something like getting your list of groups, which is normally very fast because it's cached. I got some patches into pam_ldap years ago to set socket-level timeouts so it would recover from something like a single socket error but the better solution would be fewer dependencies and interfaces which don't have tons of different things happening on a single thread.