Given the amount of progress in porting Wine [0], RISC-V [1], 3D Acceleration and now has finally a full time developer (waddlesplash)
It very is astounding to see what the Haiku team has done with the resources they currently have on building what could be a useable alternative OS for the desktop.
I can only kindly suggest more of us donate to Haiku [2] there still needs to be more browsers (Chrome / Firefox) and polished ARM support (think Raspberry Pis)
> The name of the project is simply “Haiku”. Unfortunately, despite numerous attempts, the registration of haiku.org has not been possible; hence the reason for haiku-os.org.
And guess what, the domain haiku.org is collecting dust. What a surprise with how civil the domain market is.
Domains are used for more than just webhosting. The owner could have email accounts, etc, that use the haiku.org domain that they don't want to switch to another less recognizeable name.
Those ports are commonly exposed when using a web hosting provider. Visiting above IP serves with TLS cert for Siteground, which is a popular provider.
Maybe if they had tons of cash somehow, they would have bought it already, just like how Signal was able to buy signal.org (even with or without donations) regardless.
Assuming everyone here from many companies from large corporations / startups to small open-source companies know how expensive some domain names are.
IANAL: As I understand it, dotcom domain names are leased rather than owned.
Either way, if squatting of high value domains were illegal, you could make the case for some form of (civil) asset forfeiture, or eminent domain if the taker is a popular open source project. Not sure how I'd feel about this, though.
Open source projects with no backing run by a single overworked and unpaid developer, yeah, but the legal arm of billion dollar open-source company Redhat definitely going to try some shenanigans if you somehow managed to gain ownership of redhat.com
Which is a great boon for both Haiku and my old netbook. 9/10 times I'm using terminal, browser and Emacs anyway, and Haiku is stupid fast. Now if only wireless support was bit better...
It would be great to implement some of the windowing improvements as an addition to a current linux windowing system.
Pinning different applications together or being able to merge applications with tabs both sound useful... These sorts of ideas are why it's great to have another open source OS.
Tabbed window managers have existed for X11 for ages, but the concept only seems to have remained popular in tiling WMs, not stacking WMs. KDE had built-in support for tabbed windows for a while but it looks like the feature disappeared a few years back, which suggests it wasn't being used much.
Good points. Although tiling may be a departure wanted or unwanted from your normal workflow i3wm does provide support for tabbing arbitrary applications together however this neither supporting merging 2 tabbed application into a single level of tabs nor does it fully support using window manager tabs in place of application tabs because of the inherent lack of context that would require a deeper sort of integration.
For example in your browser you might want in its UI to open a particular link in the background or foreground or perform an operation on all tabs or a subgroup thereof that is specific to browser tabs that wouldn't make sense in the broader context like bookmarking, saving a session, sending to another device etc.
There is a good argument for opening a window in the fore or background being exposed to the application but it doesn't at present work that way.
Regarding multitab operations, do you display only the options that make contextual sense or perhaps list all the options that make sense?
Example 3 firefox tabs and 2 Emacs tabs in a group. Show bookmark all firefox tabs and save all Emacs tabs as operations that can be done to the group? Possibly show only the relevant options if some subset are selected. Example if only 3 firefox tabs are selected show only those operations.
There is an argument for retaining multiple levels of tabbing at the OS level and the application level other than simplicity. Often when you want to perform a group operation the app is an already defined group for that operation, and in addition it often makes more sense to page through application tabs and windows separately rather than as a singular operation. For example going one window to the left for your editor while leaving the existing firefox tab focused rather than having to hit a different shortcut to jump up a level.
I think it would be interesting if you could have like application windows automatically vertically tabbed like Firefox's tree style tabs and have a contextual option to either break out to a new tree or open a different applications link as a child tab of the tree.
One could then optionally switch between showing trees side by side/top bottom or joining them into a horizontal tab group.
Ideally operations performed on multiple tabs could be performed by hitting a singular hotkey or button that would present all relevant options without going into each apps menu or pressing a different key or ui per app.
This would however be both complicated and require coordination between players that would likely be impossible.
The looks are the least important part. It works differently. Applications interact in a different way, there' APIs (especially around filesystem metadata) that applications and scripts can use. It's not necessarily that the capabilities don't exist on other systems, it's just that they're exposed and most importantly used in a different way. It's also a system that was built from the ground up to be GUI-based. The command line is there, but it's not the primary means of doing anything much.
There are BeOS/Haiku window decoration themes for at least XFCE and I think OpenBox. But looks are really not what Haiku is about.
I guess you could look for themes (Gnome: https://www.gnome-look.org/p/1143497| XFCE: https://www.xfce-look.org/p/1013908/) but you won't get the same unified GUI as Haiku has, since everything is built with unification in mind, compared to the Linux ecosystem where modularity is usually king.
I guess Elementary OS is as close to a unified GUI you come that runs with a Linux kernel, but it tries to look more like macOS than BeOS.
I was completely oblivious to the existence of haiku until i saw a couple posts on HN. Is there any tl;dr version of how it is different than let's say a linux distro?
HaikuOS https://www.haiku-os.org/ is a free and open source rewrite of BeOS using APIs it can run BeOS code and has had a lot of apps portered to it. It needs less memory than Linux and is more like ReactOS https://reactos.org/ when they add in the WINE porting to run WIN32 and WIN64 apps.
BETA3 is stable enough to use a web browser and email program to get things done. It can be installed on old retro legacy PCs to make better use of them.
(Haiku developer here.) It works on my Zen 2 machine and I'm pretty sure one other developer runs it on Zen 3. Note that you have to use the EFI loader (only on x86_64) and you might need to use the fail-safe video driver if you get a black screen after the splash. If that doesn't work, yes, file a ticket.
> Note that you have to use the EFI loader (only on x86_64)
Does that mean booting into my flash drive using EFI boot rather than MBR? In EFI boot, Haiku reboots itself after lighting up 0 tiles, and in MBR boot, Haiku hangs at 0 tiles lit. And one time when I hit power, my motherboard didn't power down, but remained on with a black screen, and I smelled magic smoke. My computer still works... for now.
> use the fail-safe video driver if you get a black screen after the splash
If I hold Shift and/or Space during boot, the same thing happens. Note that I have a Nvidia GT 730 GPU salvaged from an older machine. I suppose I'll file a ticket.
EDIT: I can boot nightly 55756 if I hold Shift while restarting Windows, or run `efibootmgr -n ....`, but run into the same self-reboot issue if I press F12 from my motherboard.
- 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.
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)
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.
> 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.
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.
Privilege separation for applications is not the same as having separate user accounts.
> 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.
I disagree. This is such a small and vanishing use case that adding complexity for it is exactly what you shouldn't do.
Privilege separation for applications is not the same as having separate user accounts.
true, and yes, maybe the whole system needs to be redesigned for that. but nevertheless, this needs to happen in the kernel. and once we have proper process separation, adding multi-user support on top of that seems almost trivial.
Arguably you are one privilege escalation or boot disk away from being compromised to the point that the other user can acquire your passphrase or key from memory. If merely a passphrase it could even be gathered by a device between the keyboard and computer or plugged into a usb port.
Security vs someone who has physical access to your machine while you aren't there will probably remain crappy.
> 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.
(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 very is astounding to see what the Haiku team has done with the resources they currently have on building what could be a useable alternative OS for the desktop.
I can only kindly suggest more of us donate to Haiku [2] there still needs to be more browsers (Chrome / Firefox) and polished ARM support (think Raspberry Pis)
[0] https://discuss.haiku-os.org/t/my-progress-in-porting-wine/1...
[1] https://discuss.haiku-os.org/t/my-progress-on-real-risc-v-ha...
[2] https://www.haiku-inc.org/donate/