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!)

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.

(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.

> 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"?