Giving Haiku Beta 3 a try
friendlyskies.net
friendlyskies.net
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...
And guess what, the domain haiku.org is collecting dust. What a surprise with how civil the domain market is.
https://www.haiku-os.org/about/faq/#why-isnt-it-called-haiku...
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.
It's a laughable idea.
Which is why I mentioned it in relation to open source, separately from forfeiture :)
Assuming everyone here from many companies from large corporations / startups to small open-source companies know how expensive some domain names are.
Starting Nmap 7.80 ( https://nmap.org ) at 2022-01-01 14:17 CST
Initiating Parallel DNS resolution of 1 host. at 14:17
Completed Parallel DNS resolution of 1 host. at 14:17, 0.00s elapsed
Initiating Connect Scan at 14:17
Scanning haiku.org (35.213.168.88) [11 ports]
Completed Connect Scan at 14:17, 5.00s elapsed (11 total ports)
Nmap scan report for haiku.org (35.213.168.88)
Host is up.
rDNS record for 35.213.168.88: 88.168.213.35.bc.googleusercontent.com
PORT STATE SERVICE
21/tcp filtered ftp
25/tcp filtered smtp
53/tcp filtered domain
80/tcp filtered http
110/tcp filtered pop3
143/tcp filtered imap
443/tcp filtered https
587/tcp filtered submission
993/tcp filtered imaps
995/tcp filtered pop3s
3306/tcp filtered mysql
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 5.06 secondsPinning 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.
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.
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.
There are BeOS/Haiku window decoration themes for at least XFCE and I think OpenBox. But looks are really not what Haiku is about.
Also it's a hybrid kernel written in C++, unlike Linux which is monolithic kernel in C.
- 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.
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)
baron :)
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.
fortunately haiku does have multi-user support in the kernel, it's just not implemented in the GUI yet.
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.
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.
> 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.
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.
Security vs someone who has physical access to your machine while you aren't there will probably remain crappy.
"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.
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 :)
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.
Run it in a virtual machine first.
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.