Hello HN, I'm the developer that has been hired. Happy to answer questions!
Or you can go make a (tax-deductible) donation to Haiku, Inc. directly to support my contract: https://www.haiku-inc.org/donate/
Or you can go make a (tax-deductible) donation to Haiku, Inc. directly to support my contract: https://www.haiku-inc.org/donate/
FreeBSD has fallen behind a bit, so you may want to check model numbers carefully before buying something. Intel hardware of the "9200" series and anything before it generally works (though it may not have all features enabled.) Atheros hardware is the next best, with anything before the "Killer" series especially well supported.
Slightly older ThinkPads tend to do very well. I have an E550 (from 2015) and a T60 (I dunno, 2009?) that are pretty great. My main machine is a custom Ryzen desktop where I carefully picked out hardware that I knew either was already supported or would soon be (e.g when I bought it, the NVMe driver was still in an unstable state and I had more work to do on it, but now it's pretty solid.)
FreeBSD has one WiFi driver ("iwm", or on Haiku we call it "idualwifi7260") that supports 802.11ac hardware, and supposedly the 802.11 stack is ready for ac (there is an out-of-tree driver that crashes a lot but does get ac speed), but nobody added ac support to the "iwm" driver.
Actually both my laptop and desktop use that driver, so who knows, maybe I'll poke at adding 802.11ac support to it one of these days.
I also believe there's a hack floating around to forward ac from a Linux VM, which some use.
(Haiku has its own troubles with FreeBSD drivers, for sure, but generally this seems to hold true: either it works nearly perfectly or it completely fails to recognize or initialize the hardware. Almost all tickets on our tracker now or in the past about such drivers have been along those lines.)
I find that I tend to prefer the FreeBSD take on things as well, so the Linux angle just feels weird the past few years.
I've considered donating funds to FreeBSD with the idea of earmarking them specifically for Wifi, but I don't know how much that actually helps...
Now we are three who could donate to FreeBSD-Foundation and wish for ac on Intel wireless.
Not criticizing, just observing how hard it is to work through new alphabet soup of standards without hardware vendor support.
What are the top three features that you like the most with Haiku?
That is, it's not like Linux/BSD desktop environments where the kernel, display server, window manager, desktop shell, file manager, distribution ... are all developed by separate teams in separate code repositories with separate goals, schedules, standards, etc. In Haiku, you can change the UI toolkit, display server, and init system all in a single commit to one repository.
This has a massive array of advantages. It means we never go back and forth about where responsibility for a bug lies, only where it should be fixed. It means we can decide to go with or against trends and standards as it makes sense to (our package manager is probably the biggest example of this.)
Virtually everything else I like about Haiku stems from this, whether it's the timeless UI, the overall system architecture, or even the code itself (which is a genuine pleasure to just read, not something that one can often say about any project.)
i booted haiku on a linux laptop that is using btrfs and it wasn't able to mount the linux partitions. (mounted it as almost empty with some broken entries, so it looks like btrfs needs more work)
i would expect that ext4 is most popular and thus more likely to be stable
the worst irritation with dual-boot is having to reboot to access data that's on the other OS disk. but this way i can boot and test haiku without having to move all my data over
there is mention of R1 and R2.
what are the goals for R1? any time estimates when R1 will be ready?
what's in store for R2?
there is discussion of multi user support for R2. what other interesting goals are there?
The Haiku kernel and CLI already supports multiple users, you can add them and SSH into them already. Permissions checks aren't quite there yet, and the GUI is totally non-multiuser-aware. It is a R2 requirement, but it could come sooner...
C++ finally has modules as of C++20.
Do you think there's any chance that the Haiku source code will be organized around modules instead of header files at some point?
I think if we had sufficient time and energy, we might have started our own programming language that takes a lot from C++ but would diverge sharply after the "C with Classes" part (we have joked about it before, at least.) For one, some of the paradigms we use a lot in Haiku might serve well as baked-in language features, or could be taken further with compiler support. Memory safety is also another big one; I know Rust is now the "C++ successor with memory safety," but at least to me I think it does not quite fit the bill; though we have an especially esoteric view of what "C++" is (notably I haven't put in the time to really learn Rust, honestly, though some of the other Haiku contributors are fans, and the Rust port to Haiku is sufficiently solid at this point)
The biggest thing I think we would ultimately change in any wildly hypothetical programming language we might come up with, though, would probably be ABI stability. C++ is just a huge pain to keep ABI-stable (C is as well, to a lesser extent), and there are all kinds of tricks that are clearly possible now in compilers, in ELF, etc. that there is clearly room for a slightly different language design coupled with a radically different language ABI to make ABI stability much less of a chore to maintain. (We are very big on dynamic linking and stable ABIs, something Rust seems to have basically given up on if it ever really tried, and the same in Go and other newer languages.)
I would imagine that modules instead of headers might come about as some kind of development along with ABI stability if nothing else.
On OSes that happen to be written in C, most devs tend to misunderstand the OS ABI for C ABI and then use both interchangeably.
A new OS update can bring changes, also on platforms whose OS isn't written in C, several C compiler can opt for different kinds of ABI thus not allowed for cross compiler linkage without extra steps.
It seems to be well deserved
Good luck and have fun!