waddlesplash

> From the pics it looks like KeePassXC and GIMP run on Haiku? Sweet!

Yep, and for a number of years now, too.

> I wonder how it compares to otto malloc wrt canaries, UAF and so on.

A few of the more performance-affecting features have been disabled, and the global caching layer probably affects at least some of the mitigations too. But many of the checks are still intact, and indeed it's caught a bunch of memory violations in both first- and third-party applications already (though not that many in first-party code, as we did and still do use the guarded_heap system periodically, which is also very good at finding such problems.)

> that insufficient attention is paid to security

Security is not one of our biggest priorities at the moment, no, but it's not totally de-prioritized either. When we notice security issues or get reports of them, we do fix them.

> but I know a lot of improvements have been made.

Yes, there's definitely been a lot of progress in this area over the last 10-15 years. We have a number of the basic mitigations (ASLR, DEP, SMAP, etc.) but there's a lot of parts of the kernel and drivers that haven't been audited to make sure they do all necessary permissions and access checks (though these have been shrinking; I do set aside some time now and again to work on this.)

(Haiku developer here.)

> Am I missing something?

Haiku's not nearly as well-tested for security as most other OSes. We have a lot of the basic features (ASLR, NX bit, safety checks for kernel/userland data copies, some use-after-free detection in malloc, etc.) but things haven't been seriously audited or pentested the way other OSes are. We fix security bugs when they get found, but not too many people are looking for them that I know of.

> What do they mean by "infrastructure" here?

The web/internet infrastructure: software depot (has accounts for people to post ratings/reviews), forums, bug tracker, code review, etc. And it contains all the usual "sensitive personal data": IP addresses, email addresses, some private communications, and so on.

> If I'm happy with my Linux DE and so on, why would I choose Haiku?

Well, I guess the question is, are you really happy with your Linux DE? Because every time I've run desktop Linux, I have to spend what feels like 5-10% (or sometimes more) of my time fixing things that randomly break, or otherwise don't do or behave the way they're expected to, usually by finding some obscure configuration file and changing some random option.

On Haiku, since the system is designed and developed by one team, it all goes together in a way that Linux DEs can't really achieve. The downside is that, of course, we can't reuse much of the Linux's work (we have lots of Linux software ports, but the base system is all us), so we have a lot more to do than your average Linux distro, and so we're quite a ways from general feature parity with the Linux desktop (but the gap does decrease year over year, at least in some areas...)

> And things such as ruby don't work on it.

What doesn't work about it? We have Ruby in the software repositories, and Ruby is required to build WebKit (and we build WebKit on Haiku), so clearly it works for that much at least. I don't see any open tickets at HaikuPorts about bugs in the port, either.

It's Unicode code points. I don't know why you say this is "tragic", it's a logical unit to work in here.

> with new techniques and materials on top of old work done in a way that was usual at the time.

But is there any long-lived project for which this isn't true? Linux and the BSDs surely have many components that fall into this category.

> For example there's BString and BList.

BString is a much nicer string class to work with (IMO) than std::string. It lacks some modern conveniences, and it has some unfortunate footguns where some APIs return bytes and some return UTF-8 characters (the former should probably all be considered deprecated, indeed that's a BeOS holdover), but I don't think there's any intent to drop it.

BList could be better as well, but it's still a nicer API in many ways than std::vector. Our other homegrown template classes also are nicer or have particular semantics we want that the STL classes don't, so I don't think we'd ever drop them.

> Haiku also has seams of BSD code where there'd be a project to do Whatever (WiFi, TLS, drivers, etc.) "properly" in a way unique to Haiku

What would be the point of implementing WiFi drivers from scratch "uniquely" for Haiku? Even FreeBSD has started just copying drivers from Linux, so that may be in our future as well. I don't know that anyone ever really considered writing a whole 802.11 stack for Haiku; there was some work on a "native" driver or two at one point, but it was for hardware that we didn't have support for from the BSDs, and it still used the BSD 802.11 stack. Writing our own drivers there just seems like a waste of time; we might as well contribute to the BSD ones instead.

(One of the Haiku developers here. Thanks for your support!)

Have you read the User Guide on these subjects? https://www.haiku-os.org/docs/userguide/en/workshop-filetype...

The RISC-V port was done almost entirely by one developer who took an interest in it. It wasn't as though the project got together and decided to prioritize RISC-V over ARM; it was just that someone did a port, and then it got (mostly) upstreamed. Nobody has taken an equivalent interest in ARM, in large part because, well, the developers are all running x86 machines as you might expect, so that's what Haiku gets developed on. If someone comes along (or one of the existing developers takes interest) in working on the ARM port more, we will hardly reject the patches!

Well, there's nothing preventing it from happening if that's what you mean. It's just a difficult thing to do, and requires effort (and expertise.)

I might take a crack at porting the KMS/DRM drivers from Linux eventually, but it's not near the top of my TODO list.

Haiku's "raison d'être" is to be a fully-fledged desktop operating system for general use. So, if there aren't native applications to fulfill daily tasks, then Linux ones tend to get ported.

Anyway, as for the question "why Haiku, if it's just ported Linux apps?" well, because Haiku is a much more cohesive system than any Linux distro. Even if every app you are running on it is from Linux (besides Tracker and Deskbar), the entire system underneath those applications remains tightly integrated.

There's a "flat" decorator which makes things look more 'modern', if that's what you want: https://github.com/unarix/haiku_darkstyle#darkflat

(Available in the Depot; install "haiku_extras" package.)

(Haiku developer here.) There is one hardware accelerated driver, for Radeon Southern Islands; but it's third-party, out-of-tree, and not particularly simple to set up and get running. So, not really.

(Haiku developer here.) This is a pretty common misconception, but it isn't true; Haiku doesn't have a "POSIX compatibility layer", it's just natively POSIX under the hood. You can find some elaboration on an old forum thread: https://discuss.haiku-os.org/t/is-haiku-a-unix-like-os/8801/...

> The Alpha doesn't promise that there's any coherent ordering at all unless you've imposed one

Yes. But why did you bring this up in this thread about API usage? It's the implementation's problem to make this work out. "Add()" should be the equivalent of a full memory barrier (at least for the condition variable's memory) no matter how that happens internally.

> This price isn't unique to Haiku, but the choice to pay it (almost) everywhere is, at least in terms of operating systems people would be using today.

Haiku is, in many ways, poorly optimized when compared on such details with Linux or FreeBSD, all the developers know this fact, and we make no secret of it. If this was your entire point in the first place, why not just say so?

By the way, as far as I can tell, OpenBSD's kernel atomics (sys/atomic.h) do not have different versions for different memory orderings; in fact they use the older-style GCC builtins and not the C++11-style ones, so they are also using sequential consistency everywhere they use atomics. Is OpenBSD not a "modern operating system people would be using today"?

> Your "no possible way" is assuming Sequential Consistency,

I am assuming events cannot finish before they are started, yes! I am pretty sure that even the (in)famous DEC Alpha could not possibly have time-traveling results.

Once again: there is a distinction between the API itself, and the API's implementation. Once the "Add" function returns, the "Entry" is now waiting on the "Variable". How the "Add" function ensures that is entirely abstracted away from the consumers of the API.

The implementation of "Add", at least, is synchronized using a very standard spinlock, just like similar operations are for mutexes, semaphores, etc. not just on Haiku, but on all the BSDs and Linux. We don't even need to think about CPU operations ordering for that, the spinlock takes care of it for us.

I am pretty sure Linux (and every other operating system, ever) would be in all kinds of trouble if you could read stale values from memory protected by spinlocks, so I don't know why you are casting doubt on these things.

> It's possible that the vaguely named "atomic" operations in Haiku provide you with adequate ordering

Hey, you already wrote a comment elsewhere in this thread about this point, and I replied to your comment with a bunch of information proving definitively: they do, in fact, provide that ordering. But in the cases I described in the parent comment here, it does not matter, because here we are talking about API consumption, not implementation.

Haiku uses the System V ABI (mostly.) So, we're doing the same things Linux and the BSDs are here, simply by using GCC or Clang without any special tuning here.

> I reckon that before trying to claim you've innovated here it might be a good sense check to compare baseline.

The baseline is "what are other operating systems' kernel- and userland-level condition variables APIs?" And none of the ones I looked at had anything like what Haiku has here, they all have something which is the more classical "lock-switched condvars" just like POSIX has.

The API itself does not depend on what memory ordering semantics are any more than a "mutex_lock()" API does. The implementation will be somewhat contingent on it, of course, but those are two separate matters.

> What exactly are the Haiku atomic operations, in terms of the C++ 11 Memory Model?

The atomic_() functions are (on most architectures, x86 included) implemented using GCC/Clang's __atomic_* functions, with various __ATOMIC_* orderings chosen as appropriate. You can see them defined in the system header here: https://github.com/haiku/haiku/blob/master/headers/os/suppor...

> because you're innovating before 2011, you're inventing the model

No, not really? GCC has had atomic builtins since at least 4.1.0 in 2006. The documentation (https://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins...) says: "In most cases, these builtins are considered a full barrier. That is, no memory operand will be moved across the operation, either forward or backward." -- which is basically equivalent to today's __ATOMIC_SEQ_CST.

> so Haiku is off in the jungle on its own and everybody else has a map now, figure out where you are on that map first.

We already did that years ago. The atomic_*() functions linked above in SupportDefs.h have been implemented using the C++11-standard GCC builtins since 2014, and the older __sync_* builtins for years before that.

Anyway, the algorithm described in this article, even if Haiku's atomic functions were not 1:1 with C++11-standard definitions (which they are, as noted above), is clearly portable to other OS kernels. So I am not sure what basis your comment has, regardless.

You are correct that deadlocks can be caused by signals occurring before the wait starts, and thus some sort of mechanism to ensure this does not happen is needed, but I explained as much in the article. The point of this API is that the atomic lock-switch is not restricted to just locks; and further, in some situations, no lock-switch is needed at all.

The former is simple enough, and directly equivalent to what FreeBSD's API allows you to do (and what Haiku's API provides as "convenience methods", as the article notes), and is "atomic" -- it just pushes the atomicity up a level and lets the programmer control it more directly:

    ConditionVariableEntry entry;
    gSomeConditionVariable->Add(&entry);
    mutex_unlock(&someLock);
    /* (I could unlock more locks here, if needed, I'm not limited to 1) */
    entry.Wait();
    mutex_lock(&someLock);

The latter case is the more interesting and unique one, and the article references one place it is actually used in practice (team/process creation), though it doesn't give a pseudocode example, so let me try to give one here:

    ConditionVariableEntry entry;
    someLongRunningOperation.conditionVariable->Add(&entry);
    someLongRunningOperation.start();
    /* (I can do whatever I want here, no need to Wait immediately) */
    entry.Wait();

Since this "long-running operation" is not even started until after the local Entry has been Add'ed to the Variable, there's no possible way for this operation to complete and signal before we have started 'waiting' (because, even if the Wait() call is at the end, it's the Add() call that counts.)

That's not normal behavior (these days, anyway!) A lot of users are able to go months without kernel panics, especially on certain kinds of older hardware.

Did you report any of these panics?

(Haiku developer here.) The correction is wrong; while some select portions of BeOS were released as open-source (most notably Tracker, Deskbar), the OS as a whole was not, and Haiku is thus largely a clean-room reimplementation.

> The only current issue with ext4 that I found was https://dev.haiku-os.org/ticket/16392

A 3 year old ticket with only one reproduction from 2 years ago, and it appears to have been fixed in the interim, and now the ticket has been closed by the main developer of the ext2/3/4 driver. I wouldn't be too worried about that.

> I don't think I will be plugging in my primary backup drive just yet

That's probably a good idea anyway.

> but at least it can now deal with journaling on ext4, progress.

I think it's supported journaling for many years, I don't believe that to be a new feature.

> ZFS and Btrfs both are very good these days?

We don't support ZFS at all, and btrfs support is read-only (there's experimental write support but it's disabled in default builds still, I think.)

> Can linux mount the Haiku version of BFS?

Yes, read-only with the upstream Linux driver. There is a way to get read-write support with Haiku's driver under FUSE, however it's not very performant to say the least.

(Haiku developer here.)

I would trust the NTFS driver pretty implicitly at this point both for read/write; it's based on NTFS-3G, and following the rewrite I did of the Haiku-specific parts of it in late 2021, appears to be very solid in testing.

The EXT2/3/4 driver is also very good, but there may be some issues remaining there. However I haven't heard reports of it destroying data.

The FAT driver, on the other hand, has some cases where it has been known to corrupt directories. It could probably use a rewrite; most of its code dates to the 1990s...

Those are the "big 3" of other filesystems, anyway. I don't think there's a status page for all of them.

> It is lovely to use once you learn the keyboard shortcuts

If you mean Alt vs. Ctrl, you can swap to Ctrl-based keyboard shortcuts by clicking the button in the "Keymap" application. But, the Quick Tour tells you this, there's a reason we encourage users to take it :) https://www.haiku-os.org/docs/welcome/en/quicktour.html#shor...

Haiku already has support for multiple users at the kernel and filesystem level. You can `useradd`, `passwd`, and then `su` (or even SSH into your newly-created user on your Haiku install from another machine), and also `chown`, `chmod`, etc.

What isn't properly supported yet is running GUI applications as anything other than UID 0. Adding support for that will require some careful refactoring across a few different components. Actually, if you added a handful of hacks in a few places it might work already...

(Haiku developer here.) This is actually a very common misconception that Haiku is not a UNIX, and it's sad to see The Register get it wrong.

It's debatable whether or not BeOS was a UNIX, but I think by most standards it is: the `fork()`-based process model, UNIX-style file descriptors (but no `mmap`), etc.

Haiku has all the bits BeOS had, of course, but we have far extended our POSIX compliance: of course we have mmap, but also pthreads, and /dev/ (including all the staples, like /dev/null, etc.) These aren't mere compatibility wrappers, but often the "native" APIs; some of the Be APIs are implemented on Haiku using them (while others use lower-level APIs.) There is no "POSIX compatibility layer" in the kernel, it's just natively POSIX all the way down.

Yes. As I noted in another comment, the RISC-V port is basically "fully functional" and only lacks software (HaikuPorts is set up to build on it, but we haven't yet created binary package repositories for RISC-V.) I know at least one Haiku developer has a HiFive Unmatched and it runs Haiku pretty well.

Ah right, seems I got the BSD lineages mixed up. Well, the basic point still stands, anyway.

OpenBSD is itself a fork of FreeBSD from many years ago, and while there has been a significant amount of API divergence, the differences are not as large as you might first expect. The "OpenBSD compatibility layer" is just a bunch of headers which add more or differing functions from FreeBSD, it does not have any .c files. It works just fine.

There's a built-in NFSv4 client, but I think it may have fallen a bit behind NFSv4's evolution; I recall hearing you had to turn some feature off in order to get it to connect to a standard exported volume from Linux.

SMB is supported by fusesmb, which is available as a package.

There's a non-built-in solution in axeld's DriveEncryption, but it doesn't support encrypting boot disks.

Probably we should try and incorporate DriveEncryption into Haiku itself and see about adding support for boot disks... that will require some discussion and agreement on how to change the bootloaders.

GNOME Web has built-in adblocking.