Hi everyone,
I understand how BeOS was innovative and different at the time of its release (I also understand that Haiku is not BeOS). Yet in 2015, it seems like most modern iterations of Linux, OSX and Windows can do all the things that BeOS could do, and that Haiku does now, just as well.
My question is, are there still innovations in Haiku’s architecture, kernel, and overall “ethos and model” that enable it to do things that other modern OSes can’t? Does it still outperform other OSes in certain scenarios?
For example, today all the OSes support multi-threading, pre-emptiveness, etc. So, while this was awesome to see in the 90s from Be, it’s pretty common today.
This isn’t a “is Haiku still relevant?” thread. I’m genuinely interested in how Haiku might be a viable development platform for a particular application I have been working on.
But regarding multi-threading, isn’t this rather par for the course these days? For example, OSX’s UIKit has a dedicated UI thread, asynchronous method APIs and GCD. (Doesn’t Linux do the same?)
In terms of development, haiku has the advantage that it has a single “correct” way of doing things. If you look at linux for example, if you want to develop an application you can choose a different GUI toolkit, there are different audio APIs, different libraries for handling graphics, different video libraries etc. In haiku everything is “under one roof”, they decided on the best way to implement something and did it that way. So everything is divided into kits - layout kit, media kit, opengl, game, locale, network, interface, application kits etc etc. Tomorrow they wont decide that some other way is the best way and change to a completely new system. It also means the OS has a very nicely integrated feel.
Since Haiku aims to do it once and get it right first time, it also has a few features that aren’t commonly available in other OSs, here are a few:
o It has a databasing filesystem, so searches are fast (no need for indexing like in spotlight etc on other systems), and any extra data can be added as an attribute to a file. For example, audio files can have artist, song name, album as attributes. Contacts in haiku are stored as files with name, email etc as attributes.
o The package system is very neat. A ports system is used, like in BSDs/gentoo, where for each package there is a file (recipe) that tells the ports system how to grab the source for the program, build it, and what other packages it depends on. This is the same as in BSDs/gentoo, however what is different is that the packages produced do not need to be unpacked on to the filesystem, they create a single file (with a hpkg extension) that just needs to be dropped into the packages folder. To uninstall, just remove the file. (In the background, the file is unpacked onto the filesystem but is readonly, and its files are removed when it is moved from the packages folder).
o Icons are stored in a custom vector format, that is small enough to fit in the inode for the file. This means that to display the icon for a file it is not necessary to actually look up the file on the disk, as it is already present in the filesystem index for the file (so icons load really fast).
o The stack and tile window manager features are amazing. Hold the windows key while moving a window, and simply drop it on top of another window, and they will stack, so you will end up with two title bar tabs at the top to switch between the programs. You can also tile windows in the same way by holding the windows key and putting a window next to another. To resize a window, hold down ctrl and alt and move your cursor near to a side or corner of the window. As you move the cursor, the border of the side or corner you are nearest will highlight, and if you right click and drag the window will resize in that dimension only.
o Multi-threading in the API is still very useful. The UI of a program automatically gets its own thread, so programs don’t lock up while doing something in the background.
…
There are lots of other clever things you will notice as you look around.
I’m sure there are other answers to this question, just what came to mind for me…
My experience using OSX was that I saw the “beach ball of death” way too much. It was on a not-so-fast machine (mac mini - don’t remember the exact model), but still, thesethings shouldn’t happen. As far as I know, both GTK and Qt now allow, but do not enforce, the use of a separate thread for UI. A lot of applications are running single threaded for the most part. The Haiku approach is to force the use of a separate UI thread (one per window, actually), and design the API around that, by providing an easy to use messaging system between the threads. It is not rocket science, but the integration of all system components in a single project means the same messaging system is used everywhere. On “GNU/Linux” systems you may find that you want to run both SDL and a GLib event loop, for example, or whatever different event systems you need for different parts of an app, depending on which libraries you decide to use.
A little precision on the package system: the hpkg files are not unpacked to disk when installing. Instead, they are mounted into the filesystem. This is what makes it possible to easily uninstall a program and make sure nothing is left behind.
The “beach ball of death” is a wait cursor. Haiku (and BeOS) avoid the wait cursor by simply not telling the user at all when they’re blocked, not providing any indication at all. That’s all there is to the trick. It’s literally the absence of a feature.
The “beach ball of death” is a wait cursor. Haiku (and BeOS) avoid the wait cursor by simply not telling the user at all when they’re blocked, not providing any indication at all. That’s all there is to the trick. It’s literally the absence of a feature.[/quote]
Yes, but not necessarily. Development tools for other OSs now provide for provisions for better use of threading, but you don’t get those features by default, you have to add them. .NET has a lot of threading capabilities. OSX has Grand Central for powerful producer/consumer centric development. But Haiku has multi-threading as central to the basic app model, and this would result in apps that feel more responsive. Linux doesn’t have this, Windows doesn’t have this. You have to explicitly add this. Not sure about OSX. NoHaiku, please correct me if I’m off here.
Technically speaking, that’s not true. There is no system-wide wait cursor because each window UI thread is actually ready to accept user input.
Well, except if the window thread is crashy, but then it will hit debug_server quite quickly anyway.
It’s not a trick or an absent feature.
What is a absent feature is a BeOS or Haiku application that is doing long task from a window UI thread. But in such case:
it’s a trick (and bad programming) of this application developer, not the system itself.
he most probably didn’t understand at all multithreading and didn’t detect such UI blocking situation earlier. Which means that the same developer will have done the same conceptual error on other UI too, anyway.
but yet, if his application shows others windows, these will still be reactive to user input, and this thanks to system itsef.
and the clear indication of a blocked UI thread is actually provided by the system, as under other GUI: any redraw will be deferred, leaving blank areas on the blocked window.
I dunno any builtin or well known Haiku applications which show such misbehavior.
Contrary to any other GUI outside, where every window will be blocked (system wait automatic cursor or not, doesn’t matter really when all app’s windows are blocked, it’s unresponsive, period).
Except if the developer explicitly run each window in its own thread. Which they rarely do, as they most of them aren’t comfortable with multithreaded UI yet. Hence why we still see several MacOS X / Windows / Qt applications which freeze here and there from time to time…
Last but not least, if a programmer really really wants to indicate the UI won’t respond because his window thread is busy, he can show a busy cursor. Explicitly. As under other GUIs.
But it’s not an easiest path under BeOS/Haiku.
That’s all.
BeOS/Haiku try a lot to ease programmer to do multithreaded graphical applications, and make uneasy to NOT doing it.
Others GUI ALLOWS programmer to do multithreaded graphical applications, BUT make easy to NOT doing it right.
Not because “his window thread is busy” but because his application is blocked. You have fallen into the common BeOS trap of thinking everything is just a demo, some people are writing real world software that cannot just say “My event loop is still running so we’re not blocked”.
Let me give you a nice simple illustration. The turning circle on a decent sized cargo ship with engines set ahead is often a (nautical) mile or more in radius, the time from just asking for reverse, to slowing the main shaft, engaging a gear shift and actually switching to reverse propulsion can be several minutes even where none of these steps is done manually by an engineer. During this period there’s nothing to be done, much as you might like to, about the vessel’s motion. It is not uncommon to have enough time to sound an alarm, muster the entire crew fetch emergency supplies, radio ashore, and all swear at the person responsible before the inevitable sound of tearing metal from the actual collision.
The real world doesn’t care about your neat theoretical solution. Haiku can build a UI that lets you steer the ship like it’s a Mario Kart player, handbrake turn though a strait, look at your skills. The ship will sail on into a cliff because that’s just a pointless façade. Developers need a way to tell the user that despite any purported multi-threading their application is blocked, the real world doesn’t feature instant gratification and so the user will need to wait.
And Haiku provides nothing. So your answer is basically “Well, the programmer should improvise”. And you’re openly proud of that. Lots of time is thrown at problems that need never have bothered anybody but have been brought into existence by this stubborn insistence on having hundreds of extra idle threads, and nobody bothered to make a simple wait cursor available.
There is no such “blocked” state. An application is made of one or several threads, each one doing something, at least idling, at worse looping on heavy task (or non sense when crashy).
What seems a “blocked” state is due to the unresponsiveness of UI. Which then doesn’t reflect the actual state of the application. That’s a design flaw, not a feature. At the bare least, the UI should explicitly reflect that the application is genuinely busy on something.
In your “real world” example, while the UI for the reverse gear command is in a pending state (not blocked, pending, in progress, initiated, not a giant blind blocking wait", I really hope that the ship system is still running to allow the alarm subsystem to proceed as expected, with its UI showing what’s happening.
Don’t you?
Real world is not sequential.
It’s heavy asynchronous between multiple processes, some of them working in sequence… or not.
If such application should have been developed on Haiku, the UI for the ship steering system would just report reverse command is on progress, disable all controls except for a cancel button. Because the real device controlled behind don’t work instantly and is indeed in a progressing state.
Haiku provides exactly the same easy way to report a busy state at UI level: (system, eventually) modal alert, (custom) busy cursor, or (horror) busy loop on a semaphore, it’s one code line away and not rocket science really.
What it doesn’t provide is blocking other windows and let user deduce from this general unresponsiveness that the application must be too busy doing something.
If you put all your UIs in one single window, it’s exactly like other GUI.
If you split your UI in multiple windows, that’s on purpose in general.
Having one window blocking all windows at once is not considered on purpose in such case, but a flaw.
Haiku helps lot to avoid such situation, while others GUI don’t.
And, yes, I’m openly proud that Haiku don’t ease such poor code design.
The programmer don’t have to “improvise”, he have to show at least minimal UI design care.
Unresponsive, blocked, unrefreshing UI is NOT a feature, never was and any programmer thinking that’s
great should be fired. Or moved to code command line applications only.
This is quite offending, BTW.
WebPositive, Debugger, Media Player for instance are far from being “demo” software, and could qualify as real world web browser, graphical source debugger and multimedia player applications.
And I’m not even talking of Haiku itself, whose duty is to be always responsive and is quite successful at doing that.
Real World softwares that cannot say they’re busy otherwise than by making unresponsive their UI without any other explicit indication are crap.
Yes, there is. A lot.
But it’s not because they’re “real world” that this behavior is a feature. It’s buggy, crappy design, period.
It’s perfectly doable under Haiku too, but it will not comes for free, by default.
It does appear as though you think we’re all idiots, and I know that you generally do know what you’re talking about, but I think in this case you let your arrogance and negative attitude to haiku get the better of you.
Let me give you a “simple illustration” of a solution to the problem you explained in such simple terms for all the ‘idiots’ in the haiku forums. Instead of locking the whole UI with nothing but a busy cursor to engage with for feedback, in haiku you can use a modal dialog with a progress bar that says "Switching to reverse gear, please wait. Progress: " while the ship is turning. It’s nicer to give the user feedback on what is going on, rather than sloppily programming your UI thread to wait on the physical movement of a piece of machinery while displaying a busy cursor.
That’s not really a very useful understanding, and will probably be causing you problems elsewhere. In practice at the thread level almost all your Haiku threads are blocked waiting for an event.
And you should be suspicious that BeOS deliberately makes this harder.
Really?
So, no, Haiku provides nothing and you say well, people could roll their own.
[quote]
What it doesn’t provide is blocking other windows and let user deduce from this general unresponsiveness that the application must be too busy doing something.[/quote]
Actually it does do exactly this, and with one event loop per window (even for trivial windows) it’s not difficult for this to happen at all - the OS will do nothing to help the user out, there’s no indication beyond as you say “general unresponsiveness”. If that’s such a bad idea, why doesn’t the OS try, as OS X does, to at least keep the user informed?
The answer is miserable. Propaganda. BeOS was able to say “there’s no busy cursor” and let the poor users find out for themselves that this meant “it’s still busy, just now there’s no way to know”.
Oh yeah, it’s way harder under Haiku to change a widget text or color or to disabled them than on other GUI. Sure.
Please, really???
Somewhere at startup:
BCursor busyCursor(cursorData);
And when the too-lazy-UI-programmer-to-run-long-task-asynchronously-or-to-show-a-modal-dialog wants to explicitly state that his application UI is blocking because of his own lazyne…, sorry, great real world feature that can’t be implemented otherwise than by blocking UI too:
But, yes, on Haiku he must do write these two lines of code explicitly. Poor him.
Or one, if he takes a few minutes to wrap them into a scoped BusyUIUserMustBeInformedBySomeShapedCursor object, if he’s that addict to run long task everywhere from UI thread.
That’s the least he can do, cause, you know, real world software developer skills and so: he must be very smart, right?
Because it’s a wrong solution to the problem.
The problem is that some developers still don’t run long tasks asynchronously of the UI thread, when they should.
When they do, the user is way way better informed by the “in progress” text and/or progress bar and every controls disabled but cancel than by some color wheel spinning which, while very colory and lickable visual don’t transport any semantic message but “please wait…”.
Plus, show me how one could cancel a color wheel spinner!
Users like to keep some control on what is happening, sometimes, you know. I even thinks that’s the main purpose of the UI layer. Where is the cancel button on a color wheel spinner ?
But if developer don’t want to care, on Haiku it’s only 2 lines of code way.
You call that harder, I call that easy-to-be-lazy-as-always-but-not-free.
It’s 2015, multithreading and multicores are available everywhere, even on smallest embedded platforms.
It’s already very late for “real world” software developer to stop thinking only in term of sequential programming and start thinking according modern technologies which offer better user experience.
Like responsive UI and background tasks…
BTW, you do know that real world platforms like Android and iOS actually kill automatically applications which UI is unresponsive for too long ? That developers must at least handle some responsiveness by spinning something or whatever otherwise the system will kill app?
Now you’re the one doing bad propaganda. Actual applications on Haiku don’t block UI without explicit notice. Because that’s the whole point: they’re designed to not do that, because it’s easier to do it that way.
The situation you describe is actually more present when an user is facing a color wheel spinner : they know it’s busy, right, but that’s pretty much all.
They don’t know why, not how long it will take, not if it’s expected or due to some slowness somewhere else. They often pray that the spin won’t freeze, or will unfreeze quickly, too.
Again, busy cursor is a wrong answer to an actual problem.
And, yes yes and yes, I’m openly proud that Haiku promotes to do it the right - not lazyiest, easy - way.
That’s not a miserable answer.
That’s a post-sequential-programming answer.
Here’s the thing, it happens enough for there to have been bug reports about it. For a long period it happened all over the place to anybody unfortunate enough to be stuck with Haiku’s UP scheduler and a heavy compute load because that scheduler was garbage.
Even ignoring OS level problems, you seriously under-estimate how hard it is to have applications which “don’t block”. Superficially you can make this go away just by doing all substantive work in another thread, as you seem keen on. That’s why I used the example I did, to make it absolutely clear that just because your event loop is running doesn’t mean anything useful happens. You brought up Haiku’s debugger earlier, so let’s look at that instead. The debugger offers to display variable values through your GUI. Most of the time, that’s just a memory de-reference, practically instant. But, suppose the application’s heap was actually swapped out (perhaps the problem you’re trying to debug is a big leak, it’s not as if Haiku has valgrind). Suddenly reading that value from memory is silently (no notice to the debugger) transformed into a disk I/O operation which might take significant time.
So, go ahead and check, does Haiku’s debugger display a progress window with a cancel button when waiting? Or does it, in fact, just freeze?
It’s definitely super light, but still stable and nice looking (cough, LXDE.) I ran it in a VM with 256MB of RAM by accident and I couldn’t tell the RAM was that low until I looked, Haiku was running so smooth.