4 ms·

It's derived from BeOS, rather than a Unix. Also it's a hybrid kernel written in C++, unlike Linux which is monolithic kernel in C.

by Ygg2 5y ago

capableweb 5y ago
Which means: - Different Kernel (based on NewOS if I'm not wrong) - Alright POSIX support but not 100% - Haiku has is unified base/GUI/OS compared to Linux distributions, that often choose their own window managers/composers/custom kernels (sometimes) and so on. One example is that the GUI is driven by the kernel in Haiku, in comparison to Linux distributions that often use X11 or similar software between - Different bootloader that seems more Windows OS aware than GRUB et al - Haiku focuses on personal computing, compared to Linux that (mostly) feels to aim for server usage, with supporting personal computing. But sometimes those things are at odds, and Linux allows you to configure it to be better for one or the other use case, while Haiku aims strictly for personal computing. - Haiku/BeOS always had multithreading/multi-processor in mind for it's design. If it's faster/better or not I'm not sure, but the focus been there since early - OOP API for development of Haiku software (if that's better not is an exercise left to the reader) I think the biggest selling point of Haiku is it's unity regarding the entire operating system being designed for one specific use case: personal computing. So responsiveness of the GUI is prioritized because that's the best for personal usage, while Linux (can) make other tradeoffs while allowing you to customize it. I'm writing this from the perspective of someone who test-driven Haiku a couple of times but never used it full-time, but am a daily user of Linux distributions (Arch, NixOS and Ubuntu). Some things might be wrong, I'm happy to be corrected if so, but this is what I've gathered from my usage and reading about it a little every time it pops up somewhere.
- hestefisk 5y ago
  Is it multi-user?
  - orionblastar 5y ago
    Not yet, like the Amiga there is no login. It is still in beta and needs hard drive encryption as well.
  - rvense 5y ago
    I don't know the details about Haiku, but at the end of its life, BeOS had some kind of multiuser support, in that the OS was aware of UNIX-like permissions in the filesystem (and for processes I think). But there was no GUI for logging in, so you were always root. It was meant for single-user workstations. Not having multiple users was not really a problem, except that it made (makes) some people look down their noses. In this day and age, the main security issue on my workstation is that I all applications - including the browser that downloads a bunch of untrusted code and runs it willy-nilly - run as the same user that owns all my important files. I'm a lot more concerned about what's in my home directory than anything under /usr! So if and when Haiku adds security measures to isolate applications from each other, I would prefer they looked at some kind of sandboxing to isolate every app from each other, rather than just copying the basic UNIX model, which does basically nothing for the problems people actually have. (OK, if you need to share a computer which another person you can't have separate settings and browser histories etc., but.. I don't know if that's really such a big deal that it needs to be tackled before the other one)
    - rzzzt 5y ago
      > you were always root baron :)
  - AnIdiotOnTheNet 5y ago
    What is the virtue of a multi-user desktop? There are vanishingly few use cases for such a beast.
    - jhbadger 5y ago
      I think most people with SOs or families see the benefit of having each user of a shared computer having their own user account.
      - AnIdiotOnTheNet 5y ago
        1) We used to share desktops with family before multi-user was a thing desktops did. 2) With smartphones and tablets and the like providing most of the functionality that people once shared a desktop for (web browsing really), there seems little reason to share one anymore. 3) I think having multiple user profiles one could switch between would cover almost any remaining use cases without the complication of multi-user in the kernel itself.
        em-bee 5y ago
        for a usable multi-user system it is necessary to be able to protect files from other users. a simple profile is not enough. fortunately haiku does have multi-user support in the kernel, it's just not implemented in the GUI yet.
        AnIdiotOnTheNet 5y ago
        > for a usable multi-user system it is necessary to be able to protect files from other users. a simple profile is not enough. That is what encryption is for. The big difference of course being that encryption is not one privilege escalation or boot disk away from being completely useless.
        em-bee 5y ago
        ok, so if we don't have multi-user support in the kernel, but instead implement it only as a layer in the GUI, each user gets a partition or disk image that is encrypted as their home directory that is mounted on login. the file/partition is protected against deletion. i suppose that could work, but i see a few downsides to this approach: all processes run in the same space. if i want to run a process in the background my home directory has to be remain mounted, and thus potentially be exposed to the next user. or i'd have to create a second partition for this special process which only an experienced power user would do. so while i think this approach is possible, it doesn't look like it would make anything easier. on the contrary. the emergence of hostile apps on android demonstrates that privilege separation of processes is becoming more and more important. the current multi-user approach is not good enough even for that. but instead of simplifying multi-user support to a single user, we actually need to make it more complex to properly handle multi-user-per-process separation.
tialaramex 5y ago
> Also it's a hybrid kernel written in C++, unlike Linux which is monolithic kernel in C. "Hybrid" doesn't mean anything here. The "hybrid" design claims all the benefits of a monolithic kernel, without the disadvantages of a microkernel. Huh. Wait, let's read that again. It's a monolithic kernel with better marketing. Even the networking, which in BeOS back in the 1990s was genuinely userspace code - is baked inside the Haiku kernel just like the IP stack in Linux. C++ is not used very much in Haiku's kernel. This is because the Haiku kernel ABI boundaries are defined in C not C++ and because they're stuck with stuff from last century for compatibility reasons. If you know C++ 20 you will find Haiku's C++ dialect pretty archaic, they don't yet have C++ 11 era smart pointers for example. In practice, unlike Linux the Haiku kernel has a very 1980s attitude to hardware, it's big on "probing" at boot time for devices, like DOS would have, making it a poor fit for modern intelligent peripherals. As a hack USB is treated a bit differently so that at least it has some sort of "hot plug" like a 1990s PC. Where Haiku tried to go beyond probing they chose something very strange, they focus on capability discovery. So Haiku's thing is, you want a sound device, lets look for a sound device, I can't see one, give up. In Linux, discovery is driven by the peripherals, so this is a PCI controller, let us explore the PCI bus, OK there's a USB controller on it, let's explore the USB bus, OK there's an Intel HDA controller on it, let's explore that, it's a PCM output. We can play sound through that. Haiku's approach might fit well in some other universe, but the Linux strategy matches how your hardware actually works in our universe.
- waddlesplash 5y ago
  (Haiku developer here.) We have our own homegrown smart pointers and do make plenty of use of them, though we could stand to make more. Already pretty much any short-lived objects (i.e. that have no lifetime beyond the function they are immediately in) are smart-pointer-managed. The "probing" approach needs a rewrite and we know it. Most of that code is confined to about 2-3 files inside the kernel. It will be a big job to fix it, but we won't need to reinvent the world. Eventually I or someone else will probably get around to it, but we haven't needed it yet; the people who need PCI hotplugging will have to do without Haiku for now. (Or they can submit patches :)

It's derived from BeOS, rather than a Unix. Also it's a hybrid kernel written in C++, unlike Linux which is monolithic kernel in C.

by Ygg2 5y ago

It's derived from BeOS, rather than a Unix. Also it's a hybrid kernel written in C++, unlike Linux which is monolithic kernel in C.

capableweb 5y ago

Which means: - Different Kernel (based on NewOS if I'm not wrong) - Alright POSIX support but not 100% - Haiku has is unified base/GUI/OS compared to Linux distributions, that often choose their own window managers/composers/custom kernels (sometimes) and so on. One example is that the GUI is driven by the kernel in Haiku, in comparison to Linux distributions that often use X11 or similar software between - Different bootloader that seems more Windows OS aware than GRUB et al - Haiku focuses on personal computing, compared to Linux that (mostly) feels to aim for server usage, with supporting personal computing. But sometimes those things are at odds, and Linux allows you to configure it to be better for one or the other use case, while Haiku aims strictly for personal computing. - Haiku/BeOS always had multithreading/multi-processor in mind for it's design. If it's faster/better or not I'm not sure, but the focus been there since early - OOP API for development of Haiku software (if that's better not is an exercise left to the reader) I think the biggest selling point of Haiku is it's unity regarding the entire operating system being designed for one specific use case: personal computing. So responsiveness of the GUI is prioritized because that's the best for personal usage, while Linux (can) make other tradeoffs while allowing you to customize it. I'm writing this from the perspective of someone who test-driven Haiku a couple of times but never used it full-time, but am a daily user of Linux distributions (Arch, NixOS and Ubuntu). Some things might be wrong, I'm happy to be corrected if so, but this is what I've gathered from my usage and reading about it a little every time it pops up somewhere.

hestefisk 5y ago
Is it multi-user?
- orionblastar 5y ago
  Not yet, like the Amiga there is no login. It is still in beta and needs hard drive encryption as well.
- rvense 5y ago
  I don't know the details about Haiku, but at the end of its life, BeOS had some kind of multiuser support, in that the OS was aware of UNIX-like permissions in the filesystem (and for processes I think). But there was no GUI for logging in, so you were always root. It was meant for single-user workstations. Not having multiple users was not really a problem, except that it made (makes) some people look down their noses. In this day and age, the main security issue on my workstation is that I all applications - including the browser that downloads a bunch of untrusted code and runs it willy-nilly - run as the same user that owns all my important files. I'm a lot more concerned about what's in my home directory than anything under /usr! So if and when Haiku adds security measures to isolate applications from each other, I would prefer they looked at some kind of sandboxing to isolate every app from each other, rather than just copying the basic UNIX model, which does basically nothing for the problems people actually have. (OK, if you need to share a computer which another person you can't have separate settings and browser histories etc., but.. I don't know if that's really such a big deal that it needs to be tackled before the other one)
  - rzzzt 5y ago
    > you were always root baron :)
- AnIdiotOnTheNet 5y ago
  What is the virtue of a multi-user desktop? There are vanishingly few use cases for such a beast.
  - jhbadger 5y ago
    I think most people with SOs or families see the benefit of having each user of a shared computer having their own user account.
    - AnIdiotOnTheNet 5y ago
      1) We used to share desktops with family before multi-user was a thing desktops did. 2) With smartphones and tablets and the like providing most of the functionality that people once shared a desktop for (web browsing really), there seems little reason to share one anymore. 3) I think having multiple user profiles one could switch between would cover almost any remaining use cases without the complication of multi-user in the kernel itself.
      - em-bee 5y ago
        for a usable multi-user system it is necessary to be able to protect files from other users. a simple profile is not enough. fortunately haiku does have multi-user support in the kernel, it's just not implemented in the GUI yet.
        AnIdiotOnTheNet 5y ago
        > for a usable multi-user system it is necessary to be able to protect files from other users. a simple profile is not enough. That is what encryption is for. The big difference of course being that encryption is not one privilege escalation or boot disk away from being completely useless.
        em-bee 5y ago
        ok, so if we don't have multi-user support in the kernel, but instead implement it only as a layer in the GUI, each user gets a partition or disk image that is encrypted as their home directory that is mounted on login. the file/partition is protected against deletion. i suppose that could work, but i see a few downsides to this approach: all processes run in the same space. if i want to run a process in the background my home directory has to be remain mounted, and thus potentially be exposed to the next user. or i'd have to create a second partition for this special process which only an experienced power user would do. so while i think this approach is possible, it doesn't look like it would make anything easier. on the contrary. the emergence of hostile apps on android demonstrates that privilege separation of processes is becoming more and more important. the current multi-user approach is not good enough even for that. but instead of simplifying multi-user support to a single user, we actually need to make it more complex to properly handle multi-user-per-process separation.

tialaramex 5y ago

> Also it's a hybrid kernel written in C++, unlike Linux which is monolithic kernel in C. "Hybrid" doesn't mean anything here. The "hybrid" design claims all the benefits of a monolithic kernel, without the disadvantages of a microkernel. Huh. Wait, let's read that again. It's a monolithic kernel with better marketing. Even the networking, which in BeOS back in the 1990s was genuinely userspace code - is baked inside the Haiku kernel just like the IP stack in Linux. C++ is not used very much in Haiku's kernel. This is because the Haiku kernel ABI boundaries are defined in C not C++ and because they're stuck with stuff from last century for compatibility reasons. If you know C++ 20 you will find Haiku's C++ dialect pretty archaic, they don't yet have C++ 11 era smart pointers for example. In practice, unlike Linux the Haiku kernel has a very 1980s attitude to hardware, it's big on "probing" at boot time for devices, like DOS would have, making it a poor fit for modern intelligent peripherals. As a hack USB is treated a bit differently so that at least it has some sort of "hot plug" like a 1990s PC. Where Haiku tried to go beyond probing they chose something very strange, they focus on capability discovery. So Haiku's thing is, you want a sound device, lets look for a sound device, I can't see one, give up. In Linux, discovery is driven by the peripherals, so this is a PCI controller, let us explore the PCI bus, OK there's a USB controller on it, let's explore the USB bus, OK there's an Intel HDA controller on it, let's explore that, it's a PCM output. We can play sound through that. Haiku's approach might fit well in some other universe, but the Linux strategy matches how your hardware actually works in our universe.

waddlesplash 5y ago
(Haiku developer here.) We have our own homegrown smart pointers and do make plenty of use of them, though we could stand to make more. Already pretty much any short-lived objects (i.e. that have no lifetime beyond the function they are immediately in) are smart-pointer-managed. The "probing" approach needs a rewrite and we know it. Most of that code is confined to about 2-3 files inside the kernel. It will be a big job to fix it, but we won't need to reinvent the world. Eventually I or someone else will probably get around to it, but we haven't needed it yet; the people who need PCI hotplugging will have to do without Haiku for now. (Or they can submit patches :)