Haiku/BeOS to me is simply peak computer design. This is beautiful!
johng 7 hours ago [-]
I agree, it's such a beautiful OS. The icons are perfect. I wish there was a UI like this for MacOS.
90s_dev 10 hours ago [-]
It gives me so much nostalgia for certain Trillian 0.7x skins that I can't put my finger on. Skinning apps was one of the things I wanted to bring back.
sockboy 9 hours ago [-]
Emulating extended attributes for a filesystem is a fascinating approach. It can significantly streamline lightweight OS customization without needing a full port of the filesystem driver. Has anyone experimented with this in open-source projects? Would love to hear about practical results or challenges.
wmf 7 hours ago [-]
Linux has supported xattrs for many years; there's no need to emulate them.
jdboyd 5 hours ago [-]
Linux's xattrs appear to only be an array of bytes, while Haiku's extended attributes are typed (string, mime, int, llong, float, double, bool, icon, or raw). This means a compatibility layer is probably needed to handle encoding types into the value of the xattr. Xattr(7) says there is a limit of 64kb for the value. Some haiku programs allegedly use more, but i dont have an example handy. Further, specific file systems may impose additional restrictions. For instance ext4 requires all xattrs to fit in a single file system block (assuming that the man page I'm reading is not out of date).
jonhohle 3 hours ago [-]
For compressed files, HFS+ puts the entire contents in an (xattr né resource fork).
em-bee 11 hours ago [-]
from BeOS/Haiku i am actually most interested in two things:
the way windows are styled/handled. so i'd like to see a BeOS styled compositor/window manager.
the database like filesystem, and of course gui and commandline tools to use it. (can the filesystem features be emulated with extended attributes, or is a full port of the filesystem driver needed to get a filesystem with the same features? (i am not looking for compatibility, just the feature set))
tialaramex 10 hours ago [-]
BeOS only actually had a "database like filesystem" in very early versions, so most likely you're thinking of BeFS, the filesystem used in BeOS R5 (which was given away free) and in Haiku.
But all BeFS has in the way of being "database like" is arbitrary named & typed btree indices, chosen by the owner. You can have a btree of filenames, a btree of "sent by" email addresses, maybe one of file types for example. If enabled (which is the default) you pay for this feature with a significant perf overhead on operations because those tree indices must be updated, but if it's disabled (common for disks with lots of small files) you lose the facilities enabled by having such an index.
Compared to full text indexing, which was also popular on some systems at about the same time, this doesn't produce very impressive results, yet you're paying for it everywhere. No surprise then that even the text indexing remains a niche feature, I know people who care about it a lot and others who've never been interested.
It's probably one of those niche features like wall switches for floor lamps (a socket is run off the lighting circuit and switched just like ceiling lights, but a floor lamp is plugged into that socket). A few people love it, most people aren't bothered, so, it's usually not done.
bigstrat2003 3 hours ago [-]
It may be a US/UK difference, but wall switches for floor lights are actually quite common in my experience. Most houses I've been in have had them. Of course I could just be getting uncommonly lucky to find so many.
the performance issue sounds like an implementation/design problem rather than a feature issue. most linux filesystems have extended attributes, and i am sure feature wise, the fields could just be mapped onto those.
indices are a standard feature in databases, and yes, they can slow down some queries while speeding up others, so you should use them judiciously. maybe BFS has an issue there, but that does not negate the concept.
practically speaking, what i want is a gui filemanager that lets me set arbitrary keys and values on files, display them and filter for them. indexing them is not required.
btw: UK style power sockets all have individual switches to turn them off or on. maybe elsewhere people aren't bothered because they are not used to the idea.
tialaramex 9 hours ago [-]
I live in the UK, so I'm aware our power sockets have switches. However, if I walk into a darkened room I certainly don't want to crawl around in the dark looking for a switch - so better that (as I believe a friend's home has in some of their guest bedrooms when I had reason to visit) there's an ordinary light switch, near the entrance door at a good height - to activate the distant socket.
Since you live in the UK you may also be aware that, unlike ordinary appliances, smaller low power (5 amp) connectors are authorised for lighting, so in that particular house because of its age the floor lamps literally can't plug into a conventional socket, the plugs are the wrong size, this has the further advantage that you can't accidentally plug an appliance such as a vacuum cleaner or television into a socket controlled from a light switch.
DougMerritt 4 hours ago [-]
Since the topic arose, FWIW, here in the U.S. it's common to have one power socket in a room (e.g. living room, bedroom) controlled by wall switch, and multiple other power outlets lacking such a switch.
I'm not in the industry, but I think the idea is that, in the absence of built-in lighting, one should be able to add lamps to a room that can be turned on/off by a handy power switch next to the room's entrance.
ab5tract 7 hours ago [-]
I don’t recall any real sluggishness with BeOS, in any category.
Come to think of it, I haven’t used an OS that could match the accuracy, speed, or most importantly utility of BeOS’ active queries since 2001.
tialaramex 6 hours ago [-]
Yes there are UI and UX choices which make it feel less sluggish, which is an important thing to do and e.g. Windows could certainly stand to improve there.
But in terms of wallclock time "less sluggish" just translates to it takes longer but you don't notice as much. Maybe the file copy takes 18 seconds but feels butter smooth, in contrast to this alternative where it took 14 seconds but wasn't nice - so for 4 extra seconds you get buttery smooth delay. Those seconds add up.
Gabrys1 9 hours ago [-]
I for one, love the wall-switched sockets
yjftsjthsd-h 7 hours ago [-]
> the way windows are styled/handled. so i'd like to see a BeOS styled compositor/window manager.
A window manager using this library would be very interesting
calvinmorrison 10 hours ago [-]
Right? Why wouldn't you want to expose your mailbox in the same file explorer as everything else it's so nifty
dkh 11 hours ago [-]
Finally, the killer app to checkmate the Wayland naysayers: BeOS API implementation
jbverschoor 12 hours ago [-]
Interesting.. back in the early ‘00, I implemented the BeOS api on top of the win32 api. Naive me thought that would make people adopt programming for BeOS and in turn would make it a popular OS.
netdoll 12 hours ago [-]
Was this an independent hobbyist reimplementation? Gobe did something similar in order to port their productivity suite (sorely missed) from BeOS over to Windows and Linux.
jbverschoor 9 hours ago [-]
Had juist a hobby. Never released it, but it worked quite well. It was remarkably easy to add the events and controls etc after I got the initial version working.
NonEUCitizen 11 hours ago [-]
Do you own the rights to it? Can it be published on github? Thanks.
jbverschoor 9 hours ago [-]
I’ll see if I can find it :)
ksherlock 7 hours ago [-]
You and me both (but for different reasons). Also for Flash/ActionScript.
jchw 12 hours ago [-]
Now this looks interesting. I am not familiar with the BeOS APIs, but the UI design is very pleasing.
One thing I don't see mentioned anywhere including the plans is accessibility though. Not having basic accessibility support would be a serious issue, so I'm hoping it is either already there and just not mentioned or at least planned in some way.
mouse_ 12 hours ago [-]
In a very real way, Windows XP was more accessible than anything made since, due to it being more friendly to hacks. There's a reason you see so many disabled people who refuse to abandon their ancient setups.
Smaller, simpler, more hackable software is inherently more accessible.
jchw 11 hours ago [-]
Okay. But in practice you do still need basic keyboard control and screen reader support. If Windows XP didn't have robust support for that I suspect it would be a very different story, but it did.
Edit: Of all the comments to disagree with, I am blown away that this is today's. You guys desperately need to explain what you're disagreeing with here. Seriously, leave a reply.
snozolli 9 hours ago [-]
and screen reader support
If you look at how classic Win32 applications are constructed, I don't think you need anywhere near the support for screen reader software that you do with modern applications. All of the elements of a dialog box, for example, are constructed from a standard set of controls, and can be interrogated programmatically for their text.
I don't know anything about the internals of BeOS software, but I would bet that it's closer to Win32 in this regard than it is to more modern UI systems.
jchw 9 hours ago [-]
Just to be completely clear I'm not suggesting the BeOS APIs are insufficient to implement robust screen reader support, just that Windows XP actually did implement it, from the ground up, and integrated it into Win32. I would love it if Cosmoe (and in general, more niche toolkits) would do this, too. It's non-trivial work so it's not like I expect it, but it makes using this toolkit for real programs intended for a general audience much more reasonable.
12 hours ago [-]
Apocryphon 11 hours ago [-]
More exciting UI news than Liquid Glass
tialaramex 10 hours ago [-]
One thing that's fun about this is that BeOS isn't going anywhere.
If you decided to do this for, say, Windows, Microsoft is going to release a new Windows version with new stuff you can't do and too bad.
But BeOS itself is dead, and the Haiku project (to basically make BeOS again, once named "OpenBeOS") is about a quarter of a century old yet seems barely closer to releasing anything. A lethargic snail could sleep walk to the finish before Haiku ships version 2.
i80and 9 hours ago [-]
Haiku is in genuinely good shape. I contributed some code to it years and years ago and even back then it ran nicely even on bare metal.
About the only thing I think you miss out on is GPU acceleration and maybe wifi? I haven't kept up with the current state.
dleslie 6 hours ago [-]
Wifi is as good as FreeBSD, because they share drivers.
But yes, graphics drivers are a problem.
chrsw 5 hours ago [-]
That's a shame because the the Haiku code base is relatively easy to get into. It's not overly complicated, it's consistent, it doesn't have layers of different styles from different eras and origins, and so on. It's C++ but it doesn't use last C++ feature to show off how clever you can be. At least, I'm pretty sure that's still the case because it's been years since I looked at it. I remember being surprised about how easy it was to form a metal model of the design and a model of the design-behavior interaction.
calvinmorrison 10 hours ago [-]
Haiku is pretty conservative with their versioning. You can definitely daily drive it.
tmountain 10 hours ago [-]
BeOS is the Latin of operating systems. LOL
danans 8 hours ago [-]
BeOS sold to Palm. Palm developed WebOS and sold that to LG. I wonder if any of BeOS ended up on my current WebOS powered LG TV. I bet someone here knows.
hollandheese 5 hours ago [-]
>I wonder if any of BeOS ended up on my current WebOS powered LG TV. I bet someone here knows.
None at all. Palm split into two companies in 2003, PalmOne and PalmSource. PalmOne handled the hardware and PalmSource handled the software. BeOS went with PalmSource.
PalmOne eventually bought the full rights to the Palm trademark from PalmSource in 2005 and switched back to being Palm. This is the company that made WebOS and got bought by HP.
PalmSource got bought by ACCESS (the company that made NetFront, one of the early mobile webbrowsers) and the rights to BeOS went to them in the sale.
tchbnl 8 hours ago [-]
AFAIK the only thing carried over from Be was Binder (from BeIA), which made its way to Android before being completely rewritten later on.
pjerem 13 hours ago [-]
Okay, I love this :)
imchillyb 12 hours ago [-]
“There are several sample applications included which demonstrate what it is capable of.”
This was the mantra of BeOs. Here’s a technology preview. Watch videos on a cube, now a sphere!
The OS was sold as a technology preview that was easy and accessible and the users only needed to wait for developers…
…that never showed up.
Similar occurrence with Microsoft phones and lack of developers. Pebble watch and lack of developers…
What these projects all lack are meaningful engagement instead of a few ‘oh wow’ moments.
cjbgkagh 11 hours ago [-]
Microsoft Phone was a giant pile of unforced errors on Microsoft’s part, it wasn’t the developers fault, that thing was a POS that never got better.
chipotle_coyote 10 hours ago [-]
I mean, I get that argument, but I actually ran BeOS full-time for over a year. It had a great Works-style office suite (GoBe Productive) written by the people who wrote ClarisWorks, a few good graphics programs including an amazing competitor to Macromedia Fireworks (e-Picture), a solid BBEdit-like programming editor (Pe), a few music programs that did things that I’m not sure I’ve seen other systems do to this day like SoundPlay’s wacky ability to act as a mixer, with speed control, between multiple MP3 files or ObjektSynth’s…object-oriented synthesizer (it’s very hard to describe). There was a stage control system for live performances whose name I forget now—the company is still around, as far as I know—that was used, running on BeOS, for several Broadway shows and Circue de Soleil installations. And an animation program that started on BeOS, Moho, is still around today.
The engagement was certainly starting, and I think there’s a chance—a small one, to be sure, but a chance—that if Be, Inc., hadn’t clearly decided that carving out a comfortable niche just wasn’t enough, BeOS might have succeeded. (Instead they decided to go all-in on “Internet Appliances,” which ended up dealing them the death blow rather than a big success. Ironically, I think that market effectively succeeded a decade later, but in the form of the iPad.)
Apocryphon 11 hours ago [-]
Microsoft making it difficult for users to run BeOS didn’t make things easy.
> The Flora Prius was preinstalled with both Microsoft Windows 98 as well as BeOS. It did not, however, have a dual-boot option as Microsoft reminded Hitachi of the terms of the Windows OEM license.[4] In effect, two thirds of the hard drive was hidden from the end-user, and a series of complicated manipulations was necessary to activate the BeOS partition.[5]
What are the practical benefits of this library?
We have gtk,qt,fltk,wx, and a long list of others some cross platform some not..
linguae 9 hours ago [-]
1. Cosmoe is a native C++ library, which may be of interest for C++ programmers.
2. Cosmoe is under the MIT license, which may be of interest for those wanting pure MIT/BSD-licensed solutions, as well as for those who want to use a C++-native toolkit but are concerned that their use cases may subject them to having to pay for a commercial Qt license.
3. BeOS appeal.
0x445442 11 hours ago [-]
Go read the following and draw your own comparisons.
Fair question. It feels like GTK is entrenched as the default these days.
phkahler 7 hours ago [-]
If you want cross platform and bindings for many languages (a universal gui toolkit) you land on GTK. QT is close, but it's not just a gui toolkit, it's C++, and there's a bit of commercial/OSS tension. GTK has its issues, but it's the most universal one.
mouse_ 12 hours ago [-]
yeah but I don't want to use any of those
kosolam 11 hours ago [-]
Got it. The practical benefit is that you have a library that you want to use, now? Good for you, sir.
But seriously, why have another native c++ gui library?
Disposal8433 10 hours ago [-]
Because that API is nice. Why have a Linux when you already have Windows?
kosolam 10 hours ago [-]
The reason that I started using Linux more than 20 years ago wasn’t a nice API for sure.
touggourt 3 hours ago [-]
Because his son started studying programming, so he resurrected this 20 years old project. Did you read the History page on Cosmoe website ? You should (https://cosmoe.org/history.html)
Ton of projects exists, ton of cars, ton of bicycles, ton of shoes, ton of pens, ton of keyboards, mices and screens... each of them are just another one and there is no real benefit to chose one rather than another (price excepted). They exist, because someone wanted to try someting or do something. Humans do things that way.
bboygravity 11 hours ago [-]
Because it looks (way) better than any of the others?
the way windows are styled/handled. so i'd like to see a BeOS styled compositor/window manager.
the database like filesystem, and of course gui and commandline tools to use it. (can the filesystem features be emulated with extended attributes, or is a full port of the filesystem driver needed to get a filesystem with the same features? (i am not looking for compatibility, just the feature set))
But all BeFS has in the way of being "database like" is arbitrary named & typed btree indices, chosen by the owner. You can have a btree of filenames, a btree of "sent by" email addresses, maybe one of file types for example. If enabled (which is the default) you pay for this feature with a significant perf overhead on operations because those tree indices must be updated, but if it's disabled (common for disks with lots of small files) you lose the facilities enabled by having such an index.
Compared to full text indexing, which was also popular on some systems at about the same time, this doesn't produce very impressive results, yet you're paying for it everywhere. No surprise then that even the text indexing remains a niche feature, I know people who care about it a lot and others who've never been interested.
It's probably one of those niche features like wall switches for floor lamps (a socket is run off the lighting circuit and switched just like ceiling lights, but a floor lamp is plugged into that socket). A few people love it, most people aren't bothered, so, it's usually not done.
indices are a standard feature in databases, and yes, they can slow down some queries while speeding up others, so you should use them judiciously. maybe BFS has an issue there, but that does not negate the concept.
practically speaking, what i want is a gui filemanager that lets me set arbitrary keys and values on files, display them and filter for them. indexing them is not required.
btw: UK style power sockets all have individual switches to turn them off or on. maybe elsewhere people aren't bothered because they are not used to the idea.
Since you live in the UK you may also be aware that, unlike ordinary appliances, smaller low power (5 amp) connectors are authorised for lighting, so in that particular house because of its age the floor lamps literally can't plug into a conventional socket, the plugs are the wrong size, this has the further advantage that you can't accidentally plug an appliance such as a vacuum cleaner or television into a socket controlled from a light switch.
I'm not in the industry, but I think the idea is that, in the absence of built-in lighting, one should be able to add lamps to a room that can be turned on/off by a handy power switch next to the room's entrance.
Come to think of it, I haven’t used an OS that could match the accuracy, speed, or most importantly utility of BeOS’ active queries since 2001.
But in terms of wallclock time "less sluggish" just translates to it takes longer but you don't notice as much. Maybe the file copy takes 18 seconds but feels butter smooth, in contrast to this alternative where it took 14 seconds but wasn't nice - so for 4 extra seconds you get buttery smooth delay. Those seconds add up.
pekwm with the right theme looks close enough and tabs windows together, which IMHO is the biggest feature: https://www.pekwm.se/themes/benu.html
(Of course, that's an X window manager, so AFAIK it can't be combined with this)
but yes, need something for wayland. but maybe cosmoe helps inspire someone to work on that.
One thing I don't see mentioned anywhere including the plans is accessibility though. Not having basic accessibility support would be a serious issue, so I'm hoping it is either already there and just not mentioned or at least planned in some way.
Smaller, simpler, more hackable software is inherently more accessible.
Edit: Of all the comments to disagree with, I am blown away that this is today's. You guys desperately need to explain what you're disagreeing with here. Seriously, leave a reply.
If you look at how classic Win32 applications are constructed, I don't think you need anywhere near the support for screen reader software that you do with modern applications. All of the elements of a dialog box, for example, are constructed from a standard set of controls, and can be interrogated programmatically for their text.
I don't know anything about the internals of BeOS software, but I would bet that it's closer to Win32 in this regard than it is to more modern UI systems.
If you decided to do this for, say, Windows, Microsoft is going to release a new Windows version with new stuff you can't do and too bad.
But BeOS itself is dead, and the Haiku project (to basically make BeOS again, once named "OpenBeOS") is about a quarter of a century old yet seems barely closer to releasing anything. A lethargic snail could sleep walk to the finish before Haiku ships version 2.
About the only thing I think you miss out on is GPU acceleration and maybe wifi? I haven't kept up with the current state.
But yes, graphics drivers are a problem.
None at all. Palm split into two companies in 2003, PalmOne and PalmSource. PalmOne handled the hardware and PalmSource handled the software. BeOS went with PalmSource.
PalmOne eventually bought the full rights to the Palm trademark from PalmSource in 2005 and switched back to being Palm. This is the company that made WebOS and got bought by HP.
PalmSource got bought by ACCESS (the company that made NetFront, one of the early mobile webbrowsers) and the rights to BeOS went to them in the sale.
This was the mantra of BeOs. Here’s a technology preview. Watch videos on a cube, now a sphere!
The OS was sold as a technology preview that was easy and accessible and the users only needed to wait for developers…
…that never showed up.
Similar occurrence with Microsoft phones and lack of developers. Pebble watch and lack of developers…
What these projects all lack are meaningful engagement instead of a few ‘oh wow’ moments.
The engagement was certainly starting, and I think there’s a chance—a small one, to be sure, but a chance—that if Be, Inc., hadn’t clearly decided that carving out a comfortable niche just wasn’t enough, BeOS might have succeeded. (Instead they decided to go all-in on “Internet Appliances,” which ended up dealing them the death blow rather than a big success. Ironically, I think that market effectively succeeded a decade later, but in the form of the iPad.)
> The Flora Prius was preinstalled with both Microsoft Windows 98 as well as BeOS. It did not, however, have a dual-boot option as Microsoft reminded Hitachi of the terms of the Windows OEM license.[4] In effect, two thirds of the hard drive was hidden from the end-user, and a series of complicated manipulations was necessary to activate the BeOS partition.[5]
https://en.wikipedia.org/wiki/Hitachi_Flora_Prius
2. Cosmoe is under the MIT license, which may be of interest for those wanting pure MIT/BSD-licensed solutions, as well as for those who want to use a C++-native toolkit but are concerned that their use cases may subject them to having to pay for a commercial Qt license.
3. BeOS appeal.
https://www.haiku-os.org/legacy-docs/bebook/ClassesAndMethod...
Ton of projects exists, ton of cars, ton of bicycles, ton of shoes, ton of pens, ton of keyboards, mices and screens... each of them are just another one and there is no real benefit to chose one rather than another (price excepted). They exist, because someone wanted to try someting or do something. Humans do things that way.