Haiku R1/beta1 has been released
haiku-os.org
haiku-os.org
https://download.haiku-os.org/nightly-images/arm/
It's even buggier than the x86 version though, and you don't have any software beyond what you compile for it yourself.
You can see the current video drivers here:
https://github.com/haiku/haiku/blob/master/build/jam/images/...
Which are all x86/amd64-based. The RPi would actually be relatively simple to throw a framebuffer video driver together for, though:
* https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/s...
* https://github.com/raspberrypi/firmware/wiki
* https://github.com/dwelch67/raspberrypi/tree/master/video01
Incidentally, I recall the early eees (like mine) having a faulty SD card slot and were unreliable writing to SD cards. Real MMC cards work fine. But that was years ago, so maybe there's a workaround now.
Already back in '99, not leveraging 3D hardware was a problem for adoption. These days even more so, as not only 3D software but also 2D, audio and scientific software leverage GPUs.
[0] - https://discuss.haiku-os.org/t/plans-for-3d-acceleration/727...
The downside for Haiku would be that they're giving up on the original goal of maintaining binary compatibility with original BeOS software. But that ship may have largely sailed, anyway, with the decision to go 64-bit.
The upside is that it would reduce the number of different hardware devices that they would need to support in order for people to perceive it as useful software by approximately 5,367 orders of magnitude.
(Well, that and a bunch of rework to get over to the different hardware, ofc.)
I know that even BeOS 4 came on CD, and I think the free PE version of BeOS 5 was about 50 Mb (although that might have been a virtual hard disk image? It's been a few years...)
Second, not directly related to what changed with the ABI, but it I think it would be more hassle than it is worth to try and make newer versions of GCC emit compatible binaries. There is work to run Haiku GCC 2.95 libraries alongside binaries built with a newer version. The runtime loader would be responsible for picking the correct so files. This also would work on the x64 builds as well, similar to how Linux (and others) can load x86 programs on x64 OS's. This feature is close to working but there were some last minute issues found, so it was left out of the Beta.
It's not a server OS, and it's not particularly secure, so it's not a particularly good choice in any environment where it's faced with the outside world: it assumes that you own the machine, trust it, and control what software runs on it. Remember it came out of the DOS and Win95 era.
But it's really good at giving you a comfortable Unix-ish development environment on old Pentium-grade hardware which Linux struggles on.
BeOS core API was designed for multi core systems from day one, so the design is more modern than older systems.
The core API is C++, from kernel to user space.
Lots of things to like, it just needs more polish and devs to flourish.
Except, while that's often what the blurb says, the implementation is typically paste in whatever somebody else wrote and call it a day.
For example years back Haiku announced it was going to have WiFi. Its own WiFi stack, far more integrated and reliable than things you were using on other systems. Very exciting.
And then as a "stop gap" it pasted in FreeBSD's PCI 802.11 driver subsystem, and the WPA Supplicant you've seen on all your Free Unix systems. And that's where they stopped. Last time I checked they had a version of WPA Supplicant vulnerable to KRACK but I'm sure they'd updated for the Beta.
How does their "integrated" solution handle your WiFi credentials? They use the powerful Haiku "KeyStore" password protection system. Here's how that works: You write the plaintext password into a file. Don't worry though, in KeyStore they wrote "TODO: Actually encrypt". Which I think you'll agree is almost as good as using encryption ?
> BeOS core API was designed for multi core systems from day one, so the design is more modern than older systems.
More modern is relative. "Older systems" in this context is stuff from the 1980s, because BeOS is roughly the same age as Linux, started in 1991.
However in Haiku you won't find anything like IO Completion ports, or futexes. You won't find any privilege separation because everything runs as "root". Everybody else moved on and Haiku is stuck being really quite good by 1990s standards.
According to the Linux Kernel Security Summit 2018, 68% of kernel exploits are caused by out-of-bounds errors.
That is just one example, there is plenty of material available to anyone that wants to dive into the subject.
So just because GNU/Linux faires better in security towards Haiku, doesn't mean there is nothing left to improve.
The GUI runs as root, but you can start applications as non-root users (in fact the sshd does run as another user by default, etc.)
However, privilege separation doesn't really work, even if you go out of your way to become a genuinely non-root user, you can still read, modify and replace system files for example.
Huh? Maybe this was true on alpha4 (I have no idea), it certainly isn't true now.
> even if you go out of your way to become a genuinely non-root user, you can still read, modify and replace system files for example.
Root can't even replace system files anymore due to packagefs; but in general, there was a massive refactoring and cleanup of the VFS layer between alpha4 and beta1 which means filesystem permissions are actually enforced now.
I followed these instructions on a live Haiku Beta ISO:
https://www.haiku-os.org/guides/daily-tasks/netservices/
Following these instructions resulted in me connecting to the Haiku machine as root (named "user" but with user ID zero and thus root rights). I was able to "kill" processes run by the desktop user and so on.
> Root can't even replace system files anymore due to packagefs
While packagefs prevents a naive user from being able to modify their system files, it actually makes it easier for an attacker because you can just add a package to modify things or remove one that's in your way.
Even after creating a separate non-root user and logging in to that rather than the root equivalent user, I was able to continue manipulating the system in this way without trouble, at first removing documentation in the desktop user's language and then gradually replacing software with my own.
Well ... yes, because you set the sshd to allow root login, and then logged in as the root user. This is the intended behavior, yes? You can leave that option off, `adduser`, and then log in as the new user instead.
> Even after creating a separate non-root user and logging in to that rather than the root equivalent user, I was able to continue manipulating the system in this way without trouble, at first removing documentation in the desktop user's language and then gradually replacing software with my own.
Hmm, well, that is a bug then; last I tried I thought this was impossible. Perhaps the directory permissions on /system/packages are incorrect.
Yeah, but isn't most user space one would want to use some GNU util or another or from any number of third-party projects?
But, yes, WSL proves the point.
My remark was into the sense of those using OS X and WSL as pretty GNU/Linux.
In this context, a certified UNIX has a couple of surprises to those that never left GNU/Linux.
This is why I use FreeBSD.
That was what made me get interested in BeOS in first place.
Because the first question that popped into my head was, "How do they enable modern GPU support?"
We don't want to be confined to VMs forever; in fact we already have a sizeable number of users running on bare metal.
You may want to install the VMware add-ons via HaikuDepot after installation:
1. Applications > HaikuDepot
2. Tools > Refresh repositories
3. uncheck "Show only featured packages"
4. search for or scroll down to "VMware add-ons"
For access to shared folders, use christiaan's suggestion found in the Ratings tab (instead of the instructions found in the About tab):
-> mkdir /boot/home/VMware
-> mount -t vmwfs -o localhost/Volumes/VMware /boot/home/VMwareWhen Apple were looking at BeOS / NeXT what they were really trying to decide was whether to have Jobs or Gassée back. They picked Jobs.
After Be, Inc. sank JLG arranged to run Palm's software spin-off. This produced the version of PalmOS that's remarkable because instead of being used more palmtop devices than previous PalmOS versions it was used in none at all, even the Palm hardware company never used it.
IMO Gassée would be nobody you've heard of if not for the fact of his being in a position to force Jobs out of Apple. Everything else follows from that.