Trying to work in Haiku, the BeOS successor(arstechnica.com)
arstechnica.com
Trying to work in Haiku, the BeOS successor
https://arstechnica.com/information-technology/2017/07/ars-spends-too-much-time-trying-to-work-in-haiku-the-beos-successor/
25 comments
Another (occasional) Haiku user and supporter here. This article isn't even a review of the OS, it's just a web-browser grumbling session. In any OS I hardly ever use the browser for work-related tasks.
What job field are you in? I think I've been in web development too long, because this is not my experience.
I'm the CEO of the family firm. Formerly I was the CFO. I'm not involved in IT despite my history and prior experience.
I found the article bit disappointing. Basically the author focused almost exclusively on the failings of the browser. Of course I suppose that reflects on authors profession (being a writer for a web publication), but I would have hoped to see attempt at bit more diverse tasks.
>Of course I suppose that reflects on authors profession (being a writer for a web publication)
Far too much of this navel gazing when reviewing products from the tech press these days. Like the iPad being championed as a work device just because you can write up a blog post and a tweet on it and a complete disregard for any profession that isn't accomplished only via tweets and blog posts.
Hilarious a tech blog site being held up as a basic challenge for a web browser. IIRC the early WebKit team had extensive hacks and work arounds to make sure the abysmal code of major sites like this and newspapers actually rendered "correctly".
Far too much of this navel gazing when reviewing products from the tech press these days. Like the iPad being championed as a work device just because you can write up a blog post and a tweet on it and a complete disregard for any profession that isn't accomplished only via tweets and blog posts.
Hilarious a tech blog site being held up as a basic challenge for a web browser. IIRC the early WebKit team had extensive hacks and work arounds to make sure the abysmal code of major sites like this and newspapers actually rendered "correctly".
It fails at other things too.
I have a very fond memory of BeOS, I had a BeBox way back in the second half of the nineties. It was my first multi-processor (now "multicore") system and I've never looked back since. The system, the philosophy, and the OS were ahead of their time by leaps and bounds. That said, at the time it was a solution in search of a problem.
I've been trying out Haiku for several years. I have to say that it brings back very fond memories and is astoundingly feature-complete, but the limitations of its architecture is beginning to show: the system has no in-built notion of security and lacks even the most basic primitives for such purposes insofar as it isn't multi-user and has no notion of access privileges. The architecture is POSIX-complete but without users it is surprisingly limited.
Of course there is no real chance of extending the architecture to 64 bits or of porting it to non-x86 architectures.
Haiku is a great effort, but it's a requiem for what BeOS could have been.
EDIT: it seems that there is a 64-bit version I was unaware of.
I've been trying out Haiku for several years. I have to say that it brings back very fond memories and is astoundingly feature-complete, but the limitations of its architecture is beginning to show: the system has no in-built notion of security and lacks even the most basic primitives for such purposes insofar as it isn't multi-user and has no notion of access privileges. The architecture is POSIX-complete but without users it is surprisingly limited.
Of course there is no real chance of extending the architecture to 64 bits or of porting it to non-x86 architectures.
Haiku is a great effort, but it's a requiem for what BeOS could have been.
EDIT: it seems that there is a 64-bit version I was unaware of.
[deleted]
Based on what I've seen from the Haiku OS website and mailing lists, I believe the first beta of Haiku R1 is due to be released relatively soon (in the next 6 months, at the latest). Seems a shame this article had to be written before then, but I suppose at least a few more people might be made aware of its existence.
The main thing that was holding back the next release was the infrastructure around the package manager, but most of the development hurdles with this seem to be sorted. There's some ongoing work to build packages before the beta release, but I can't see that taking the rest of the year.
The main thing that was holding back the next release was the infrastructure around the package manager, but most of the development hurdles with this seem to be sorted. There's some ongoing work to build packages before the beta release, but I can't see that taking the rest of the year.
Honestly, not having a steady semiannual or annual release cadence—even if each release is a small increment over the last—has probably held Haiku back more than anything else.
Many people don't want to even try nightly builds, so they try the last many-yeas-old release, see issues many of which are already fixed, and write it off.
Were I them, I'd only block a new release on the ability to do manual and automatic updates from the UI. From there everything else is gravy.
Many people don't want to even try nightly builds, so they try the last many-yeas-old release, see issues many of which are already fixed, and write it off.
Were I them, I'd only block a new release on the ability to do manual and automatic updates from the UI. From there everything else is gravy.
Releases are a double edged sword though. Regular releases can drive more interest, but that also means more time spent answering queries and a faster accumulation of technical debt.
By iterating on ideas away from user demands, you can more quickly make progress with less concern about breaking changes. However, this period is only really useful whilst the fundamental parts of the software are getting implemented. Some would argue that package management is a fundamental part of an OS, others would not.
In other words, I'd expect that you'll see more regular releases after the first beta is out.
By iterating on ideas away from user demands, you can more quickly make progress with less concern about breaking changes. However, this period is only really useful whilst the fundamental parts of the software are getting implemented. Some would argue that package management is a fundamental part of an OS, others would not.
In other words, I'd expect that you'll see more regular releases after the first beta is out.
Basically my experience as well. I check it out every couple of years for nostalgia sake. It really is fairly feature complete for a BeOS clone. The problem is (besides the lack of a modern web browser for it) is that what was amazing about BeOS 20+ years ago is pretty much what is expected by any OS these days.
what was amazing about BeOS 20+ years ago is pretty much what is expected by any OS these days.
Which is why the story of BeOS is a story of lost potential.
Which is why the story of BeOS is a story of lost potential.
Except the part where you could run the whole OS, and a browser, off a 1.44mb floppy.
If that matters to you, Menuet OS[1] will still run off a floppy.
The bigger problem, these days, is finding a floppy drive that still works, and a floppy disk. I had to install MS DOS 6.22 on two computers about two years ago, and finding three floppy disks for the installation media was rather challenging. ;-)
[1] http://menuetos.net/download.htm
The bigger problem, these days, is finding a floppy drive that still works, and a floppy disk. I had to install MS DOS 6.22 on two computers about two years ago, and finding three floppy disks for the installation media was rather challenging. ;-)
[1] http://menuetos.net/download.htm
I too used Be-os in the late 90's. Our application was a stand alone internet browsing device. Lots of potential in the OS that was never realized, maybe if Apple had bought it over Next.
Today, I don't think we need another under-developed desktop OS; if anything, pouring more resources into Linux to get something that's actually competitive with MacOS and Windows instead of just semi-competitive would be a better use of time. Alas, after 20 years of waiting, I feel like that's unlikely to happen either.
Today, I don't think we need another under-developed desktop OS; if anything, pouring more resources into Linux to get something that's actually competitive with MacOS and Windows instead of just semi-competitive would be a better use of time. Alas, after 20 years of waiting, I feel like that's unlikely to happen either.
JL Gassee took the risk of asking the high price, Apple refused... we know the rest.
Rewatching late 90s BeOs demos made me really emotional. The actual performance, the mindset, the aesthetics so much was right. Felt better than my latest linux on a 2007 dual core.
Rewatching late 90s BeOs demos made me really emotional. The actual performance, the mindset, the aesthetics so much was right. Felt better than my latest linux on a 2007 dual core.
I remember porting gcc 3 and GDB to BeOS.
Reading this article, it doesn't look like the 32 bit version ever progressed past that :)
AFAIK the problem lies with GCC breaking the ABI. Haiku tries to solve the issue by building the userspace APIs with multiple GCC versions to preserve the ABI for older apps. I do not think this is a good idea in long term though since you need to keep older GCC versions around to provide backwards compatibility and make sure your C++ code compiles with all GCC versions from 2 to whatever is the latest one.
A better solution would be for GCC to provide means for working with binaries and libraries produced with older versions of the C++ compiler, ideally including 2.
Perhaps a more realistic solution would be to create "proxy" libraries for the previous GCC versions that all they do is to redirect the calls to the latest version.
A better solution would be for GCC to provide means for working with binaries and libraries produced with older versions of the C++ compiler, ideally including 2.
Perhaps a more realistic solution would be to create "proxy" libraries for the previous GCC versions that all they do is to redirect the calls to the latest version.
OpenBeOS started just after Be folded. Binary compatibility was a priority, and remained so for a long time. I think especially still having an office suite (Gobe Production) was important, but it is my impression that this concern has faded.
I used BeOS back in the day too. Doesn't look like Haiku is making much headway. Are there any alternate operating systems that are?
I'm not sure about headway, but the last ReactOS release took me from "blue screens constantly, unusable" to "actually able to run the Windows apps I make". It's possible I could actually get some work done and compile my software using it.
Problem is, when I actually need to get work done, it's easier to just use Windows 10.
Problem is, when I actually need to get work done, it's easier to just use Windows 10.
I did love my Bebox as it was the first multi core I've owned. The LEDs were amazing. Sadly it didn't have a brighter future.
Do you still have it? My dual-603e is still in working condition, but I preferred the colour scheme of the original dual-603.
I personally support the work of the Haiku project and have not had as many issues as the writer of this article. Maybe if so many sites were not bloated with garbage, the web browser would not have fallen over. Sites should have a fallback mode in case of situations where js is not turned on or the browser is not HTML5 compliant. As for the email client falling over, I think there is more at play than the author is letting on.