Haiku R1/beta4 | Hacker News Reader

Haiku R1/beta4

haiku-os.org

440 pointswaddlesplash139 comments

3 days ago, I installed Haiku on bare metal: an old PC from ~2004. I was not aware that a new version was planned at that time, but the upgrade was completely smooth.

My idea when I installed Haiku was to make my own version of the "old computer challenge"[1], with an emphasis on using GUI apps.

Similarly to @probono (a FOSS dev), I also found Haiku "shockingly good"[2] at being a lightweight, responsive, easy-to-use desktop OS.

After some patching, I was even able to compile Tectonic[3], a modern LaTeX engine written in Rust, and Quaternion a Matrix client supporting E2EE[4]. All that running on a single core Athlon 64 and 1.5GB of RAM.

I posted some screenshots in a Mastodon threads if you are curious[5] (but my posts are in french sorry :/). And of course this comment is posted from Haiku!

[1]: https://dataswamp.org/~solene/2021-07-07-old-computer-challe...

[2]: https://medium.com/@probonopd/my-first-day-with-haiku-shocki...

[3]: https://tectonic-typesetting.github.io/en-US/

[4]: https://github.com/quotient-im/Quaternion

[5]: https://mastodon.tedomum.net/@tgoldoin/109554115997967651

Around 2001, I ran the contemporary BeOS demo on a Pentium MMX 200 MHz machine with 32 MB of RAM. Even with those limitations, the thing screamed. I believe it was live CD you downloaded and burned.

I am absolutely not surprised it works well on Athlon 64.

Ahh, the memories! (266 MHz PII, 64 MB RAM ... maybe upgraded to 384 MB RAM by the time I was quad-booting Debian, Win2k, BeOS and QNX)

Maybe I ran BeOS slightly before a demo CD was available, or maybe I just didn't risk burning a coaster. (Remember those days where you had to worry about your OS not being able to feed the CD burner as fast as it was writing?) When I demoed BeOS around 2000, it was on a floppy (I repurposed a free AoL floppy from a few years earlier... by that time AoL was mailing free CDs instead of free floppies). The demo floppy allowed one to format a BeFS partition on the drive, and I think even put the kernel on the drive, but kept the bootloader on the floppy to encourage purchase.

I woke up one morning to see the floppy drive light on, and apparently a BeOS kernel or usespace driver bug caused it to spin the floppy continuously all night without moving the read/write head. I popped out the floppy and pulled back the dust guard to discover a thin stripe where the magnetic media had been polished off of the floppy. The drive didn't read any floppy correctly after that; presumably the read/write head was covered in magnetic media dust.

I don't remember how, but I eventually found instructions for copying the bootloader off of the downloaded floppy image and getting GRUB to find it, so I didn't need to put my replacement floppy drive at risk.

I remember having the exact same experience on slightly less powerful hardware with that BeOS demo. I remember throwing everything at it and it just kept on going like it was no big deal and me constantly going "wow, wow, wow" haha! It was such a bummer going back to Windows after experiencing that.

Pentium 75 mhz was enough for the BeOS demo. It was almost like using QNX. I believe I tried BeOS on some 486'es too, but if I did not at least it screamed, and burned, as you said, even on a Pentium 75mhz. The only limitation of the 'demo' was that usable space was like locked into 512MB extendable user-space, if I'm not wrong. Please do correct me/this.

BeOS never (officially) supported 486 class processors, I can't recall if it actually uses Pentium instructions and won't run, or if it's just super slow on 486. I think it is actually compiled for Pentium.

> 3 days ago, I installed Haiku on bare metal: an old PC from ~2004. I was not aware that a new version was planned at that time, but the upgrade was completely smooth.

If there is one thing to say about Haiku, their slow and steady approach has resulted in a remarkably solid Kernel and base system. It is extremely light and has a well-built and consistent environment. I've always hoped more engineers would hop on the bandwagon to accelerate development, but what the team has achieved is notable in comparison to other alternative/"hobby" OSes.

It also runs really well on old netbooks - it's revitalised my Asus EEE 701 4G (even though the screen resolution is below the official minimum requirement), it fits comfortably on the internal 4Gb SSD, and even the wifi works!

I had a single core Athlon 64 that I upgraded to a dual core back in the day. That was my primary PC until I got a Ryzen 2400G several years ago. All are really great CPUs for many years after they're made. Next up might be a Zen 5 APU. I'm on a slow upgrade cycle...

I believe Linux should be even faster, right? Probably it only lacks a lightweight and responsive DE, and a distro with sane defaults, e.g. no gazillions of random processes running at the start. But e.g. the compilation, or anything compute heavy should be faster under linux?

I wouldn't have thought so, no.

Linux is a huge OS by the standards of BeOS and Haiku, with an early-1970s design and layers and layers of legacy cruft between the kernel and the user.

Dr Tanenbaum called it obsolete even 30 years ago: https://www.edn.com/linux-is-obsolete-thread-is-started-janu...

... and he had a point then.

The kernel is not huge though. Even a modern Linux kernel runs on really, really resource limited hardware ( eg. embedded ). As said above, it is all the other crap that takes up memory and slows it down ( and makes it useful of course ).

It is not the Linux kernel that makes the Linux Desktop so much heavier than Haiku though.

No, that is true and a fair call.

Saying that, the first machine I tried (and failed) to install Slackware 1 on was I think a 486 with 8MB of RAM, and I am not sure 21st century Linux will fit on that...

I switch between Haiku and Q4OS on the same netbook, and they are both very responsive. The Linux distro does indeed have some performance advantages. However I haven't tried beta4 yet.

It is possible that musl based distros such as Alpine, could somehow compete for having a lot smaller code footprint to execute, but "normal" glibc ones would hardly match Haiku's speed. That doesn't necessarily make Linux inferior; it's just the price to pay for decades of development from thousands of developers and being portable to a huge number of platforms. The upside is we (Linux users) have a lot more software and supported hardware than Haiku, as of today.

How's the support for Samba/NFS?

There's a built-in NFSv4 client, but I think it may have fallen a bit behind NFSv4's evolution; I recall hearing you had to turn some feature off in order to get it to connect to a standard exported volume from Linux.

SMB is supported by fusesmb, which is available as a package.

Cool. Network file system support is critical for how I would use it. I've loved the experience for the most part, otherwise.

Well, and Emacs support, but that's in now.

oh i loved reading the old computer challenge at the time. Solene did some great write ups about it

>One of the newly available GTK applications is GNOME Web aka. Epiphany, which is based on a very recent version of WebKitGTK. This provides an unfortunately non-native but largely functional web browser for Haiku for the first time in many years, with “just works” status for major websites like YouTube and others.

For many people that makes Haiku suitable to run daily.

WebPositive was also updated to latest WebKit. Honestly, it worked OK before and if it's using the same WebKit as GNOME Web then it should be just as good, but also using native UI.

I kind of get not using the Be GUI API makes it feel "non-native", but it's still a native port of GTK and Epiphany. It's not like they've built a Linux ABI emulation layer to run it.

There's not a Linux ABI emulation layer but it is running on top of a Wayland emulation layer, instead of using the Be GUI API directly (as the Qt, SDL, and Java Swing ports do.) That does make a difference, especially around stuff like keyboard handling.

>on top of a Wayland emulation layer

As per release notes, for time being it uses X11 layer instead for features and performance.

Uh ... no? The release notes state it started out using the X11 layer, but then switched to using the Wayland layer.

I should know: I wrote the X11 layer, contributed to the Wayland layer, and wrote most of these release notes. :)

Really impressive work man. Really great to see Haiku alive and kicking. I remember stanning for BeOS on Slashdot. Those were the days.

Yeah, skimmed through them and mixed up the wording. It says "port now is built atop [the Wayland compatibility layer] for both features and performance reasons", remembered it the other way.

So can it run Solvespace? CAD with GTK gui.

If anyone wants to quickly spin up a Haiku VM I leave here my Docker image [1].

It's just a proof of concept but some people are using it for CI as well [2].

[1] https://github.com/hectorm/docker-qemu-haiku

[2] https://github.com/HaikuArchives/ArtPaint/blob/7f5c49278545e...

thanks! will def check this out

> Since the last release, there is 1 new Haiku developer with commit access: davidkaroly, who has already made significant contributions to Haiku’s in-progress support for ARM. Welcome!

This is one the most interesting bits in an already awesome release notes! Haiku would rock with Raspberries and I can't wait to use it as the default OS for family 400s.

If you want to see something really rocking on a raspi, i would suggest to take a look at RiscOS ;-)

:-D

It's true, but Haiku is multithreaded now, and has SMP support and wifi... ;-)

As a BeOS users in the late 90's / early 2000's - the fact that Haiku is still going twenty years since its first inception is just incredible to me.

I am continually amazed at how much progress the project continues to garner. It really proves there was something magical to BeOS.

It's not just that there was something magical to BeOS, there's still something magical to Haiku, especially in the era of the "Linux desktop" with its free-for-all fractured ecosystem approach to desktop environments. We aren't working on Haiku just because it reminds us of the past, but because we think it could be the future, too.

This deserves to be expanded on: I very much see the need for innovation in OS research. But I just don’t see anything in BeOS/Haiku that would address any of the big challenges for operating systems. Which in my mind include the following:

Can we get away from the “leaky bucket” security paradigm where despite all of the best efforts and gradual improvements, prevalent operating systems “keep on giving” in terms of exploits that are discovered all the time. Is there something akin to what Rust is for programming languages?

Or what about an operating system for AIs? Is the current stack of Linux, GPU drivers, and some ML SDK on top an adequate answer for emerging AI applications?

Or if you still believe in Blockchain applications, what about a native OS for that?

And the list goes on.

All I see in Haiku/BeOS is a pretty, albeit dated user interface. Someone educate me what else they bring to the table.

It screams on super underpowered hardware. That’s a nice benefit over just about any modern OS.

Could also help with some of our biggest issues: use less energy, reduce energy costs, go green, use your existing hardware longer, less need for producing new things.

Sometimes making a better UX Operating system is enough.

> And the list goes on.

I would be keen to see more of this list, as two of the three items you mentioned are not at all interesting or useful to me (and, I would presume, to a majority of other users).

Even the other item (#1) is somewhat academic, as modern security practices are generally "good enough" for most people in most use cases. (That is, there is certainly room for improvement, but where we are now isn't nearly as bad as it could be.)

> Is there something akin to what Rust is for programming languages?

Check out the Genode OS framework

You’re listing tech that didn’t exist when Haiku started so how could it address those things?

Haiku is an OS for endusers.

Forgive me but as I can appreciate the effort put into Haiku and working on a single user targeted OS, I still can't get why the people behind it like to throw darts to Linux from time to time. That "era of the Linux desktop" phrase is something even we Linux desktop users themselves will laugh at, as there is not such thing.

Praising the positives of your work at the expense of the criticism of other's work won't do you any favours.

I think you are reading a little too much into it. Linux people throw darts at Haiku ("why would you ever use this and not Linux?" etc.) so it seems only fair we throw a few back. Many of us have desktop Linux installs, and some of us even have patches (or even have contributed significant amounts of work) in various Linux ecosystem projects.

> "why would you ever use this and not Linux?"

That seems to be a legitimate question, not a dart nor a criticism by any means.

Sometimes it is, and you can see elsewhere I've given real answers to that question.

But sometimes my criticisms of Linux are because, well, they are a real and genuine motivation for why I gave up on desktop Linux and devoted even more time to Haiku. It's not as if my criticisms are anything new, there's pages upon pages where Linux users and developers say similar things. I "throw such darts" here to make it clear how Haiku stands in contrast.

I do not think they are throwing darts. My read is that they are making the following two points:

- the “Open Source Desktop” is pretty much a Linux monoculture and they are an alternative to that

- the Haiku philosophy is to offer a unified and consistent user experience vs a collection of a thousand independent projects approach ( the Linux experience )

- Haiku offers everything needed for a desktop experience under the banner of a single project ( another way of saying the previous point )

Isn't adding X11 and Wayland and Wine getting you the same free-for-all toolkit and app mix in the end?

Free-for-all in terms of toolkit and application mix, yes, but that's actually the "lesser" problem of the Linux desktop. Ideally we would have all-native applications, but not even macOS can really manage that.

The X11 and Wayland compatibility layers are very different than XQuartz macOS or the Wayland-based WSL GUI are, they are much more tightly integrated into Haiku. While you are still going to notice some seams here and there, overall the experience is much more like a "full port" than most other OSes have on this point.

More to the point, all ported applications are still running on top of Haiku's kernel, Haiku's window manager / display server, Haiku's media services, Haiku's init system, Haiku's package manager, etc. On Linux, all those things come from separate projects, and some of them can even be swapped out within a Linux distribution, never mind between distributions. Not so on Haiku.

That’s a good observation. In many ways your approach is like Carbon on MacOS, or the bajillion UI toolkits that exist on top of the same display driver, clipboard, etc., infrastructure in Windows.

Many of the apps are designed to the conventions of the various desktop environments on Linux (or Windows, in case of Wine), and feel most at home in one of them. Without additional effort to e.g. implement D-Bus and XDG portals, having a Qt or GTK app run will mean those apps open File Open/Save dialogs that are not the native Haiku ones. In the end it will be a fractured feel as well.

I hear what you're saying and I do understand the point you're trying to make. However, I think it's interesting to point out just how app-centric systems have become, with many apps even shipping essentially their own unique HIG and look and feel.

If you look at Haiku's competitors, 10 years ago they were all much more editorialized with a strong sense of what a proper, native app for them should look like. And despite all having more such native apps than Haiku has now, the trends have - at least for the time being - pulled away from that. If Haiku gets more popular it'll similarly become subject to simply running the most popular software.

That's the issue with specific GUI toolkit.

Haiku has its own set of tools.

As long as it's integrated it might avoid Lisp Curse of Linux. It's too easy to fork and too hard to reintegrate.

I've spoken to some of the developers. There's a community of admiration and integrity that is really solid. You get the strong feeling that they enjoy each other and that's what drives them. It was obvious to me why it was still going after talking to a few people.

Both Haiku and SerenityOS seem to have enough momentum to potentially become viable contenders for the Open Source Desktop someday.

Both of them highlight how much nicer a vertically integrated user experience can be as well as how much lighter weight a modern desktop can be as well. They also demonstrate that it does not take dozens of corporate paid engineers to do it ( not that I would turn them away ).

Haiku has a long lead over Serenity in terms of hardware support and now app compatibility ( with the new X11 and Wayland stuff ). That said, having to drag along binary compatibility with BeOS must really be slowing Haiku down at this point.

I am looking forward to using one or both of them in the future.

It seems that both are struggling with drivers and more advanced system states, both are in a far worse position than Linux desktop was in the mid to late 2000’s…

And this is really where it’s difficult to get any real progress without massive industry backing.

So I’m not sure how either will become a contender for any real word desktop use without someone at the scale of Google putting their weight behind them.

I like RedOx too although it's going to be quite some work before it runs on a reasonably wide variety of hardware. Haiku was fun to play around a few years back, I remember being able to write a toy gui app in an afternoon with no particular dev experience (although some programming knowledge). Indeed everything seemed well integrated and coherent.

Is elementaryOS still going strong?

Isn’t ElementaryOS just another Ubuntu Linux based distro?

Debian now I think but otherwise yes.

Release notes: https://www.haiku-os.org/get-haiku/r1beta4/release-notes/

Downloads: https://www.haiku-os.org/get-haiku/r1beta4/

Very happy to see boot failure fixes in the release notes. Can't wait to give it another try with beta4!

I'm eager to test this. HiDPI, modern browser, wine, emacs... that's A LOT of useful stuff.

I use lightweight linux VMs to keep different workspaces and hobbyspaces separate from my main OS. Depending on how the test goes, I feel that Haiku might replace some of those linuxes.

Yep, this stood out for me as well:

> but now (thanks to Emacs developers!) has a fully-upstreamed, polished-to-a-shine native GUI.

This alone is definitely worth giving it a go!

I really love how responsive the Haiku gui feels.

I only use if for testing free software packages in a "weird" build environment, but every time I do I feel sad for how much we've regressed in terms of the latency of modern desktop software.

Beyond latency the UIs are also just a lot more useful, the subtle faux-3d delineates the boundaries of control surfaces and make it much more clear where you need to click and what will happen when you do.

Try it in the browser, new version should be available soon: https://copy.sh/v86/?profile=haiku

This is pretty impressive. GTK, WINE, Wayland… As a “lightweight” OS, it has a lot of potential for tinkering. I can’t wait until they get a working ARM version for a Raspberry PI or an RK3688 SBC.

The ARM port has made a lot of progress since the last release; it gets almost all the way to starting the desktop. Similar progress was made on ARM64. But that's not very exciting news, so it only got an oblique mention in the release notes.

The RISC-V port on the other hand is nearly fully usable even on bare metal. I know some people run it on HiFive Unmatched, at least...

The approaches to X and Wayland compatibility are interesting.

>Instead of running a full X server as XQuartz or other X11 compatibility packages do on other operating systems, it directly handles Xlib API calls and translates them into Haiku API calls, instead.

>It is a little more complicated than the one for X11, running an “in-process Wayland server” for each application instead of translating C API calls directly.

Unfortunately the Wayland part has no blog post similar to the X one.

Beyond the nostalgia: are there any other reasons to keep contributing to Haiku? Like critical infrastructure that is reliant on BeOS/Haiku. Or anything you can plausibly do best on Haiku?

It's an alternative to the fragmented state of the "Linux desktop": instead of having dozens of separate projects (GNOME, PipeWire, systemd, Wayland, ...) be combined by yet another project (a distribution), which is (in my view) a major cause of the fragile nature, slow pace of development (it's hard to request features if you have to spend minutes to hours figuring out where they need to be requested from!), and other problems it faces, Haiku is a one-project-governs-all: a single development team for the core operating system and userspace ("desktop environment"), with an interconnected distribution ecosystem.

We can merge a change to Haiku's kernel and drivers, and test builds will be available with it on the "nightly" channel within hours. We can issue a patch for the system C library headers, trigger rebuilds of packages from the ports tree against it as soon as CI builds finish. We can send users experimental builds of work-in-progress features for testing, with very little technical know-how required to install such a patch or revert to the previous version if it breaks something.

There are so many huge advantages Haiku has due to how the project is structured that the "Linux desktop", whatever upsides it does possess, basically cannot ever have by its very nature.

> instead of having dozens of separate projects (GNOME, PipeWire, systemd, Wayland, ...) be combined by yet another project (a distribution), which is (in my view) a major cause of the fragile nature, slow pace of development (it's hard to request features if you have to spend minutes to hours figuring out where they need to be requested from!), and other problems it faces, Haiku is a one-project-governs-all: a single development team for the core operating system and userspace ("desktop environment"), with an interconnected distribution ecosystem.

So there will never be 3rd party software? Not even a GNU Emacs? Surely you're using GNU GCC, aren't you?

Have your read the release-notes? Hint emacs. It's about the coresystems (network, graphic, sound, storage), the bsd systems do that (partially) so is windows and macos.

What I tried to convey is that this is an arbitrary line to draw. What difference does it make to an user whether graphic and network bugs can be reported to the same organisation, but bugs in the IDE (I'm thinking of IntelliJ here, not Emacs) go somewhere else vs. all bugs go to their respective software package's bug tracker?

There was a time when DEC or IBM could act as a single point of contact for all your software needs, but we live in a much more diverse world now and the all-inclusive software offering / SPOC is just not a realistic or (IMHO) desirable target anymore.

The difference is not to which organization to report, rather having a cohesive arquitecture design of the OS stack instead of a bunch of lego bricks with incompatible pins.

The arbitrary line is normally base to 3rd party, the line is blurry, but you read too much in in, just compare it with macOS would you?

Mostly for fun. Something kinda helped by that Haiku retains some interesting concepts (e.g. built to have small footprint, written in C++, object-oriented and concept-oriented API, database-like filesystem, replicants, standard scripting mechanism, ...) and being enough different from other Unix-like systems.

It's just a fun OS

Who is the designer behind Haiku's icons and general "feel"? It looks really nice.

That would be "stippi" aka. Stephan Aßmus on both counts, I believe. At least the icon style was chosen after a competition all the way back in 2006, where stippi's style got the most votes [1]. The look & feel of controls was done by him in 2009 [2], not sure if there was ever an announcement about that (I see an old forum thread that may be related, though.)

These days, stippi does not have much time for Haiku, but there are a number of developers & community members who have picked up where he left off, continuing work on the UI and drawing new icons when required.

(Old hands from the BeOS days may remember stippi as the co-developer of the shareware "WonderBrush", which now runs on Haiku and has been open-sourced [3].)

[1]: https://www.haiku-os.org/news/2006-11-03_icon_contest_and_be...

[2]: https://github.com/haiku/haiku/commit/2f86ba45579bdc9648b232...

[3]: https://github.com/stippi/WonderBrush-v2/

Where do you even see them? I clicked around the website for a minute and can't find a freaking screenshot of anything anywhere. How frustrating.

The front-page should probably have more screenshots, yeah.

There's a screenshot tour here: https://www.haiku-os.org/slideshows/haiku-1/

And the release notes, linked from the release announcement, have screenshots: https://www.haiku-os.org/get-haiku/r1beta4/release-notes/

The user guide has some: https://www.haiku-os.org/docs/userguide/en/gui.html

I can't speak to the specific person(s) however the Haiku inc. (The non-profit for Haiku Org stuff) has an FAQ entry about them: https://www.haiku-inc.org/trademarks/haiku_icons/

Edit: Fixed typo

Oh what would have been what could have been had Apple bought Be instead of Next. We'd likely not have any iPhones or a 2.5T Apple but we could have had some really cool software. BeOS and now Haiku will always have a special place in my nerd-head.

consider sponsoring the team here: https://github.com/sponsors/haiku

Many Be employees, including myself, ended up at Apple; some after a brief time at Eazel and others later on. They had, and continue to, make great contributions. As a former Be employee and lover of BeOS, I can say that Apple acquiring Be would have been a disaster for Apple. I have no ill will to Gil Amelio, Ellen Hancock, Steve Glass and the other leadership, but they didn't have what it took (other than the NeXT purchase) to pull Apple out of crisis.

I find this take somewhat baffling. At the moment that Apple bought NeXT, NeXTSTEP had a mature software toolchain, a working IPv4 networking stack, and enterprise customers, three things that BeOS lacked. BeOS had a primitive software toolchain ecosystem based on pre-standard C++. BeOS IP networking barely worked and despite everything claimed in their advertising it was fully serialized, single-threaded networking. BeOS had zero customers.

The only thing that Be did have was one nifty demo, and a somewhat innovative file system. Apple must have correctly deduced that it would be easy to improve the filesystem, because they later did so, with the same author.

Comparing BeOS and NextSTEP in 1997 is like comparing a ham sandwich to a piglet and a bag of flour. One of these things was a finished product.

(Just because I love this argument): Have you used Mid-90s OpenStep and BeOS on period hardware? People rose-tinted-glasses the hell out of OpenStep (...and the first few OS X releases), it's ridiculously sluggish and brittle (in that same kind of "I did something to config and rendered it unbootable" way as early 2000s Linux). BeOS is shockingly performant and flexible on the same hardware.

As much as the original BeOS network stack was mediocre (and it was, it wasn't fixed until the BONE design in that final Dano leak in 2001) the much-touted NeXT networking stack was literally the open source 4.3BSD networking code running hosted, with their awful NetInfo system on top, which Apple spent the next several years excising. Excising like the Adobe license fees cost more than a PC, few major vendors (not even Adobe!) willing to port their software to, Display PostScript GUI they had to throw out and replace.

I'll grant that they got a really good set of development tools they're still essentially using, and Be's were rough (and kind of alien, that kind of pervasive threading is _still_ hard with decades of work on the tooling).

Apple bought NeXT because the stack looked architecturally like a less-bungled version of their own failed Pink/Taligent effort, and Steve Jobs had a better relationship with people still at Apple than Jean-Louis Gassée.

I ran NEXTSTEP 3.2 and I think, 3.3, on both 486 DX2/66 and original NeXT hardware. At one job I ran on a 25Mhz Mono slab as my daily and only machine. I did Web surfing, email, used VarioData for the home-built sales/contact system, etc.

There were some pieces that were slow, but overall it was a fantastic experience. The "Shelf" was great; I would store commonly-used docs there, reference materials etc.

Look I'm not going to bat for NeXTSTEP as a user nirvana, but at the time Apple bought it it was hugely advanced compared to BeOS, which still had not reached R3. A few things that NeXT could do that Be could not do at the time: run on an Intel PC, burn CD-Rs, and print.

BeOS R4–the first revision that did useful things users actually wanted–came out two years after Apple agreed to acquire NeXT. The current BeOS at the moment was "DR8" as in "developer release".

The fundamental thing Apple got out of the NeXT acquisition was an adult OS management team. The software acquired was totally irrelevant (at the time). What was important was new people in charge, who unlike the previous Apple management, could actually make decisions. The decisions were often bad, but they were decisions!

If Amelio and Hancock had been competent, they would have actually set up a management structure internally and started focusing on shipping Copland-based software instead of shopping externally. Strip it down and get it out the door and build on that. It could absolutely have been done.

Of course, you wouldn’t have the iMac or iPod or iPhone. And Apple might not have survived. The world would be very different.

(That all said, OpenStep was truly dire in 1997. Yes, it could print, although they ended up having to write an entirely new graphics stack from scratch anyway. It actually took six years from 1997 to turn moribund OpenStep into a viable consumer OS (I could not recommend anything before Jaguar to end users — the Finder, among other things, was unusable up to that point).

The tale of major incumbents' completely bungled OS/Platform projects of the 80s and 90s really is one of the great epics of the field.

A short - and playing it a little fast and loose for narrative like a Malcolm Gladwell piece - telling of the circumstances:

Apple failed utterly with Taligent, and Copland, and mismanaged A/UX into the ground, so it's the mid 90s and they're shipping a hyper-extended version of a one-off from 1984 that had to be hacked for even cooperative multitasking, looking around for a platform to jump on to. With IBM's help in two of those cases. They even, reportedly, batted around giving up and becoming a shell on top of NT or Solaris by porting Quickdraw during their flail in the early 90s. Then they bought NeXT, took one more (and it was at least the third after A/UX and the MAE product which was really more of an emulator, but so was Classic) pass at "Let's slap a Mac-like shell and compat layer on top of a UNIX and call it a day" and got successful selling mostly handheld appliances running basically that stack.

IBM failed utterly with their share of Taligent and the A/UX/AIX merger planning, and mismanaged OS/2 into the ground, until IBM, once of "IBM and the Seven Dwarves" dominance, became a midsize player in the PC market they created (more through incumbent effects than technical prowess), until they gave up and sold the businesses to a Chinese clone maker and retreated to high-end niche markets. (Their spun out printer division, the legacy of their once dominant typewriter business, would also later also be bought out by a Chinese cartridge cloner, so it's almost a theme for them.)

DEC dithered on ...literally everything because they didn't understand the world after minicomputers, so all their talent left as they crumbled (which is also a large part of how AMD64 happened, there is an awful lot of Alpha lineage in the K8 design). Eventually their corpse was consumed by a PC cloner, who were themselves consumed by HP.

The UNIX vendors were too busy infighting to get much done, and all the UNIX-brand-UNIX vendors license cost overhead was too high to put up credible consumer offerings anyway, until eventually a hobby project from some kid in Finland ate their entire software business while Intel (possibly accidentally, Itanium is the culmination of a series of failures - 432,860,960 - for them too) ratfucked their long term hardware projects to death.

...And so Microsoft, then famous for 8-bit BAISCs, slowly abandoning their own successful but mutant UNIX offering (Xenix), managing to sell Seattle Computer Products' DOS to IBM after Digital Research/Gary Kidall (CP/M) didn't want to deal with IBM, and the surprising success of their awful DOS shell, ran away with nearly the entire mainstream OS market for decades by gathering everyone competent from the VMS and OS/2 lineages (they put Dave Cutler and Moshe Dunie in charge) and having them write NT. Running mostly on Intel's inescapable accidental success extension-of-an-extension-of-an-extension legacy architecture.

It's a weird field we're in.

Spot on man. I think we've all learned that the best tech stack will not win without also having a good sales, marketing, and management team to support it. And if you are completely incompetent at those things it doesn't matter how good your tech is, you will turn into a hilarious failure we'll all be laughing at later. (Though we'll have a lot of fun making YouTube videos where we run all your shit through emulation.) I know people always shat on Microsoft's engineering, though the truth is I think they tried to do the best they could with what they had and they also understood how important backwards compatibility was, and they had to work within that limitation. But I think that maybe they were just a bit jealous that their management was so far ahead of everyone else (really only Apple after Jobs came back could rival them)!

I'm not sure that attributing the successes to "sales or marketing" had as much to do with it as timing and position. Management _failures_ certainly dominated the era, there were vast numbers of unforced errors due largely to managerial empire building, feature creep/novelty seeking, and ambition exceeding the scale of tractable development practices. The note up-thread about "What was important was new people in charge, who unlike the previous Apple management, could actually make decisions. The decisions were often bad, but they were decisions!" is, IMO, a great read on the situation. I've posted in earlier HN threads about my belief in the "Next bought Apple with Apple's money" idea, and the replacement (or reversion since a lot of them were Apple folks to start with) of Apple's management with Next folks in short order. They were making largely the same kinds of decisions that almost bankrupted Next, but under more favorable circumstances.

Even as someone who has run Linux most of the time for like 15 years, the underlying tech in NT is in many ways by far the best design of the OSes that survived to modern maturity. I just hate almost everything they've done with the upper layers of the stack since 7.

R3 could actually run on Intel PCs; it was the first release to have that option available. The other two you are probably right about, I'm not actually an expert in BeOS history pre-R5 :)

NetInfo did have some good ideas, and I suppose it could have been improved, but the market wanted a standards-based solution. I think macOS was the first commercial operating system to ship with a RFC2307 LDAP client. Jaguar (10.2) had a NetInfo to LDAP bridge and subsequent versions removed NetInfo entirely, although I think NOOP stubs may still remain in libSystem.

Also, NeXtSTEP could reliably print stuff. Which, given that publishing was the niche that arguably kept the Mac alive during those years: kinda important!

NeXT even had stuff like WebObjects, which was really ahead of its time back then. And AFAIK it still powers some services at Apple.

iTunes and App Store seem to both still be backed by webobjects services. Stuff like [1] still respond at WO-like URLs and still include headers like `x-webobjects-whatever` so I surmise these are still production WO apps.

1: https://itunes.apple.com/WebObjects/MZStoreServices.woa/ws/w...

It would be interesting to see what would have happened had Apple bought Be instead of Apple, but I think it's pretty clear Apple made the "right" move. NeXT had really good software, and of course, Steve Jobs (and let's not forget about the rest of the NeXT team with people like Avie). Hard to imagine Jean-Louis Gassée (or anyone else really) being able to turn the company around like Steve did.

Exactly. In acquiring NeXT, Apple bought leadership and culture. And we can argue forever if Apple’s engineers could have shipped the first OSX release earlier or in a better state, had they instead acquired Be. But I doubt it. Because - again - they bought themselves a high-performance culture, which they might not have gotten from Be. Porting BeOS to Apple hardware / existing software would have likely required an equally Herculean effort.

Oh and they got Steve Jobs of course who made quick work of pushing out the old Apple leadership. And good that he did.

BeOS already ran on existing Apple PowerPC hardware of the time:

http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/su...

In school, I quad-booted Debian, Win2k, QNX, and BeOS on my desktop.

BeOS was very light weight. Its ethernet driver for 3c509 was buggy and crashed often, but being a userspace driver, I just got a popup asking permission to restart the driver. Conversely, a couple years later I had an OSX laptop, and a corrupted backup CD that would kernel panic OSX, Win2k, and Linux. (Honestly, ISO 9660 and FAT32 drivers should be migrated out of mainstream OS kernels, since kernel latency is very far from being the bottleneck when using thunmb drives or CDs.)

On the other hand, BeOS had some questionable uses of metadata. After improperly using tar to backup my home directory before a reinstall, I lost all of my NetPositive browser bookmarks. I didn't realize each bookmark was a zero-sized file with the URL actually stored in metadata. My improper backup procedure dropped the metadata fork.

Also, there was a kernel bug related to semaphores. I had some semaphore code that worked fine under Linux but would kernel panic BeOS.

Had Apple purchased Be, we'd likely have a much lighter weight OSX, though perhaps with poorer support for multiple users.

I'm still hoping that someday QNX RTP gets open-sourced. A hard real-time light weight microkernel OS was fun to play around with. In particular, a cache benchmark I ran for a systems class showed quite a bit smaller cache footprint for QNX vs. Debian. (Though, Debian almost certainly had more daemons running, so it's not an apples-to-apples comparison of kernel cache footprints.)

Circa 1999 one of the popular machines in my uni's computer club was the BeBox - it had a solid web browser, it was fast, it had the cool CPU usage indicator on the front, and it was *nix enough to compile most stuff or to work on assignments in ANSI C. And it was just so snappy, it could do more than one thing without getting janky.

A real shame that they faded out. I kind of miss those days with all the different and varied workstations – Be, SGI, DEC, HP, IBM, Sun, ...

I'd like to see the GeekPort reintroduced on non-Pi class machines. A bit of digital GPIO, some analog lines, maybe SPI...

Twenty years ago I might have liked that too, but these days I much prefer dedicated machines (MCUs like Arduino, P8X32A, R.Pico etc. or "single-board" (or rather "open-frame") computers like R.Pi, BBB etc.) for the acoustic noise alone (not to speak of power bill and electrical safety). USB or Ethernet (preferred for galvanic separation) on the PC does just fine to connect to those.

I wonder why there isn't a $20 PCI-E card (or perhaps USB dongle) that offers a 40-pin RasPi-style port.

If you had a PCI card you would need some kind of external adapter or breakout box for the GPIO pins. Seems much more practical to have the board in the "breakout box" and connect it via USB.

I don't know about the prices but mixed-signal GPIO rigs for PCIe and USB are very common. Look at the "LabJack" for example. The LabJack U3-HV has almost exact feature parity with the geekport.

A quick google puts it at $130, well beyond the price of "just buy a Raspberry Pi or similar device, which also comes with all the SoC smarts too."

Fair enough. It compares more favorably to an odd port inconveniently located on the back of a $5000 (2022 dollars) tower PC.

Assuming Apple's success by going with Be instead of NeXT, we would have yet another mainstream OS where C++ plays a major role, thus settling the whole discussiong regarding C vs C++ for OS design.

Linus Torvalds has settled that whole discussion, by rejecting C++ and subsequently adopting Rust. Even Windows is basically written in C in its lowest layers anyway, they apparently don't find C++ itself very useful.

Linus Torvalds has settled that whole discussion for the Linux kernel.

Thankfully his opinion about C++ is meaningless outside Linux world.

Windows started to adopt C++ on the kernel since Vista, you can make use of Windows Implementation Library, a C++ template library for kernel, drivers and userspace code. Just gotta to love that VC++ /kernel flag.

macOS with its NeXTSTEP heritage, changed from having Objective-C drivers on kernel space to C++ drivers in kernel space.

Then if you bother to broaden your horizons beyond FOSS UNIX clones, there are enough OSes already shipping C++ on the kernel.

> One of the newly available GTK applications is GNOME Web aka. Epiphany, which is based on a very recent version of WebKitGTK. This provides an unfortunately non-native but largely functional web browser for Haiku for the first time in many years, with “just works” status for major websites like YouTube and others.

I was really waiting for this! I want to install Haiku in an old computer for an old lady friend to use (and for me to see how she will use it). They only problem always was that youtube never really worked. That is the chance!

This is maybe about the limit for a list like this, and I omitted a few less interesting ones. If anyone knows of a good thread that I missed, we can merge it in!

Show HN: Xlibe – A serverless Xlib (X11) compatibility layer for Haiku - https://news.ycombinator.com/item?id=31167562 - April 2022 (46 comments)

Giving Haiku Beta 3 a try - https://news.ycombinator.com/item?id=29757451 - Jan 2022 (48 comments)

My progress in porting Wine - https://news.ycombinator.com/item?id=29753069 - Dec 2021 (62 comments)

Haiku Now Has Experimental 3D Acceleration - https://news.ycombinator.com/item?id=29390689 - Nov 2021 (71 comments)

Haiku has hired an existing contributor to work on Haiku full-time - https://news.ycombinator.com/item?id=28305191 - Aug 2021 (105 comments)

20 Years of Haiku - https://news.ycombinator.com/item?id=28241255 - Aug 2021 (119 comments)

Haiku Beta 3 - https://news.ycombinator.com/item?id=27955755 - July 2021 (96 comments)

HaikuOS running on RISC-V hardware (HiFive Unmatched) - https://news.ycombinator.com/item?id=27867941 - July 2021 (80 comments)

The Dawn of Haiku OS (2012) - https://news.ycombinator.com/item?id=27616822 - June 2021 (15 comments)

Haiku Monthly Activity Report – May 2021 - https://news.ycombinator.com/item?id=27395511 - June 2021 (20 comments)

Haiku OS ported and running on RISC-V - https://news.ycombinator.com/item?id=27129305 - May 2021 (86 comments)

Haiku Activity Report – January 2021 - https://news.ycombinator.com/item?id=26055781 - Feb 2021 (24 comments)

Haiku: Call for Wallpapers - https://news.ycombinator.com/item?id=24756787 - Oct 2020 (24 comments)

Haiku: Contest for System Sounds - https://news.ycombinator.com/item?id=24593719 - Sept 2020 (15 comments)

A decidedly non-Linux distro walkthrough: Haiku R1/beta2 - https://news.ycombinator.com/item?id=23676975 - June 2020 (46 comments)

Haiku R1/beta2 has been released - https://news.ycombinator.com/item?id=23469209 - June 2020 (254 comments)

Haiku Alpha 1: Rebirth of legend - https://news.ycombinator.com/item?id=22401383 - Feb 2020 (14 comments)

500 Byte Images: The Haiku Vector Icon Format (2016) - https://news.ycombinator.com/item?id=22373422 - Feb 2020 (91 comments)

The Haiku Operating System - https://news.ycombinator.com/item?id=20812877 - Aug 2019 (1 comment)

My sixth day with Haiku: Under the hood of resources, icons, and packages - https://news.ycombinator.com/item?id=20443136 - July 2019 (38 comments)

Most long-standing XHCI (USB 3.0+) issues resolved - https://news.ycombinator.com/item?id=19352839 - March 2019 (58 comments)

Haiku Beta is finally here - https://news.ycombinator.com/item?id=18769814 - Dec 2018 (53 comments)

What makes BeOS and Haiku unique - https://news.ycombinator.com/item?id=18583722 - Dec 2018 (219 comments)

Haiku R1/beta1 has been released - https://news.ycombinator.com/item?id=18099127 - Sept 2018 (79 comments)

The State of Rust on Haiku - https://news.ycombinator.com/item?id=17472907 - July 2018 (84 comments)

LibreOffice is now available for Haiku - https://news.ycombinator.com/item?id=17440862 - July 2018 (157 comments)

Haiku Project - https://news.ycombinator.com/item?id=15973918 - Dec 2017 (64 comments)

Scripting the Haiku GUI with hey - https://news.ycombinator.com/item?id=15697697 - Nov 2017 (47 comments)

Trying to work in Haiku, the BeOS successor - https://news.ycombinator.com/item?id=14697308 - July 2017 (24 comments)

Porting Swift to Haiku - https://news.ycombinator.com/item?id=14617453 - June 2017 (49 comments)

Haiku booting in UEFI mode - https://news.ycombinator.com/item?id=13200633 - Dec 2016 (94 comments)

Haiku Project - https://news.ycombinator.com/item?id=12566056 - Sept 2016 (143 comments)

500 Byte Images: The Haiku Vector Icon Format - https://news.ycombinator.com/item?id=12420763 - Sept 2016 (81 comments)

Haiku OS Action – From BeOS compatible to Desktop [video] - https://news.ycombinator.com/item?id=9713843 - June 2015 (4 comments)

Haiku OS – Fundraising 2015 - https://news.ycombinator.com/item?id=9046701 - Feb 2015 (27 comments)

Whatever Happened to BeOS? - https://news.ycombinator.com/item?id=8175135 - Aug 2014 (17 comments)

Interview with Haiku developer Paweł Dziepak - https://news.ycombinator.com/item?id=7754772 - May 2014 (47 comments)

Haiku meets 9th processor - https://news.ycombinator.com/item?id=6987731 - Dec 2013 (44 comments)

Haiku Operating System - https://news.ycombinator.com/item?id=5564766 - April 2013 (110 comments)

Haiku OS (BeOS clone) - https://news.ycombinator.com/item?id=4123941 - June 2012 (46 comments)

HaikuOS x86_64 port part of Google Summer of Code - https://news.ycombinator.com/item?id=3906710 - April 2012 (15 comments)

The Dawn of Haiku OS - https://news.ycombinator.com/item?id=3904972 - April 2012 (110 comments)

* Haiku Project Announces Availability of Haiku R1/Alpha 2* - https://news.ycombinator.com/item?id=1334827 - May 2010 (11 comments)

Haiku: A Perfect Desktop Operating System? - https://news.ycombinator.com/item?id=1009751 - Dec 2009 (5 comments)

Haiku - https://news.ycombinator.com/item?id=826986 - Sept 2009 (29 comments)

Haiku Project Announces Availability of Haiku R1/Alpha 1 - https://news.ycombinator.com/item?id=820844 - Sept 2009 (20 comments)

Haiku OS first alpha scheduled for September 6th - https://news.ycombinator.com/item?id=767766 - Aug 2009 (11 comments)

BeOS Lives: Haiku Impresses - https://news.ycombinator.com/item?id=475756 - Feb 2009 (19 comments)

HaikuOS still going strong

If we like it on our pcs

Install and use it

It's awesome that Haiku has come a long enough way that it runs on my Framework out-of-the-box. Still ain't quite there as a daily driver, but it's very close.

Have you tried the newly-ported GNOME Web browser, mentioned in the release notes? It seems that it solves the "web browser problem" many users have complained about.

I haven't yet, but my daily-driver-blocking issues during my last attempt were more around stability. Much of it I think is the hardware (OpenBSD and Haiku both would spontaneously reboot on occasion; given that it was more frequent on battery, I suspect it's some quirk with the Framework's power management - or maybe there's something in the iwx driver that freaks out the whole machine), and some were likely attributable to being on nightly; I'll have to re-test with beta4 (and maybe the latest UEFI updates on my machine) to see if that straightens some things out.

The lack of a built-in solution for full-disk encryption is also a blocker for me. It's something I keep meaning to try and tackle (say, by porting over OpenBSD's FDE implementation), but I ain't quite comfortable enough yet with Haiku's codebase to even know where to start.

There's a non-built-in solution in axeld's DriveEncryption, but it doesn't support encrypting boot disks.

Probably we should try and incorporate DriveEncryption into Haiku itself and see about adding support for boot disks... that will require some discussion and agreement on how to change the bootloaders.

It is excellent to see a modern browser on Haiku, but one thing remains:

If we get a web browser with advert blocking, it will be ready for the modern web.

GNOME Web has built-in adblocking.

With so much compatibility now how much work would it be to port Firefox? What are the showstoppers?

> The thumbnails themselves are stored in extended attributes of the files themselves, which means applications can create their own thumbnails for custom filetypes, if they want (for example, a screenshot might be the thumbnail of an emulator’s save-state.)

This is pretty neat. Is it something that script-type applications can do, as opposed to more formally-programmed applications?

Or for that matter is there that kind of system scripting language for the OS, like an ARexx for Haiku? I've used Haiku but not at this level.

Installed this beta4 on a ThinkPad T410, 4GB RAM, 1280x800 display, SSD drive. Seems pretty fast, the Emacs UI is nice, everything is VERY responsive.

It detected only 1024x768 when it started up, which made things look blurry; fixed by going into the Screen app and changing it. Haven't figured out the Wifi yet, but the Ethernet was detected and worked immediately. With both Web and WebPositive browsers up and with a page or two loaded, 1.2GB RAM was in use, total, for everything.

These compatibility layers are huge and are going to skyrocket Haiku’s strength as a daily driver. I’m really rooting for everyone working on it. Keep up the good work guys.

> This means Haiku is only the third open-source operating system (to the best of our knowledge) after Linux and OpenBSD to support 802.11ac WiFi, as not even FreeBSD supports it (yet?) despite having worked on it intermittently for years.

9front also uses OpenBSD drivers for Intel cards, so it might also be one

> Supporting these drivers required the addition of an “OpenBSD compatibility layer”, which builds on top of the existing FreeBSD compatibility layer.

This doesn't look very good, in my opinion. While having working WiFi is important, stacking compatibility layers is not a good architectural decision.

OpenBSD is itself a fork of FreeBSD from many years ago, and while there has been a significant amount of API divergence, the differences are not as large as you might first expect. The "OpenBSD compatibility layer" is just a bunch of headers which add more or differing functions from FreeBSD, it does not have any .c files. It works just fine.

OpenBSD was actually a fork of NetBSD ca. 1996; NetBSD and FreeBSD in turn are basically sibling-forks from 386BSD.

Ah right, seems I got the BSD lineages mixed up. Well, the basic point still stands, anyway.

While I totally despise Electron it might be a great moment for new OSes and UI toolkits to emerge. In near future it might be enough to port Electron and a web browser and your niche OS might become actually usable on daily basis.

It’s slow and a total memory waste, but web became a new UI toolkit that actually solved OS compatibility issues. Who would have thought…

Aren't most electron apps available as regular web pages anyway?

I mean I tried a number of electron apps and always end up using the web version that is always the most up to date and are as wll integrated to the desktop thanks to desktops support for web notifications.

And in many cases, the web version end up more stable/reliable than the electron one. MS Teams is a great example of that.

any way to run this bare metal on an m1 mac? can i dual boot it?

The ARM64 port doesn't yet boot all the way to desktop in QEMU, so it certainly won't run bare metal on an M1, unfortunately.

You can certainly dual-boot it on x86 machines, though.

Is RISC-V port in any better condition?

Yes. As I noted in another comment, the RISC-V port is basically "fully functional" and only lacks software (HaikuPorts is set up to build on it, but we haven't yet created binary package repositories for RISC-V.) I know at least one Haiku developer has a HiFive Unmatched and it runs Haiku pretty well.

@dang Could the URL be changed to the release notes? https://www.haiku-os.org/get-haiku/r1beta4/release-notes/

It's a much more filled-out page, and probably what most people are clicking through to anyways.

Changed from https://www.haiku-os.org/news/2022-12-23_haiku_r1_beta4/. Thanks!

Reply on news.ycombinator.com