Linked by Razvan T. Coloja on Mon 3rd Jan 2011 23:30 UTC
BeOS & Derivatives To understand what the BeOS and Haiku operating systems are, we first must remember that BeOS was developed with the multimedia user in mind. BeOS wanted to be what OS X has become today: an easy to use, attractive operating system. However, BeOS was a niche OS, destined for the media-hungry user. The percentage of audio and video applications available for Haiku is greater than the one in Linux, OS X or Windows, and the inner workings of the operating system were created in such a way, that the same multimedia passionate would find it easy to work with the user interface and files. Each application can interfere with other applications of its kind. A WAVE file selection can be dragged from a sound editor and onto the desktop, to create an audio file. Audio applications can interfere with each other via the Haiku Media Kit -- the corespondent of a Linux sound server. Applications like Cortex are a perfect example of how BeOS and Haiku deal with multimedia files: you can have more than one soundcard and use each one of those soundcards independently or separately. You can link one soundcard to the Audio Mixer, start a drum machine application and link that software to the Audio Mixer. If you want to output whatever you create with the audio application, all you have to do is drag the microphone and link it to the application's icon in Cortex.
Thread beginning with comment 455915
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: No it won't
by Vanders on Tue 4th Jan 2011 23:41 UTC in reply to "RE[2]: No it won't"
Member since:

GCD makes it easy for mortals to do mutli-threading, while simultaneously making it easier for the Operating system to provision threads more efficiently.

It's still just a thread abstraction model. There are many of them. GCD is nice, but it is not unique in that sense.

I also vehemently disagree that there is anything particularly difficult about writing threaded code. I am certainly not a superhuman and find it easy enough.

"Threading is hard" is the meme that just wont die. Developers hear that "threading is difficult" so they never try. They never learn how to do it, and when they finally must do it for something they resent it and inevitably make rookie mistakes. Because they made mistakes, "threading is hard", obviously.

GCD makes it easier for developers to express threaded execution paths without having to muck about in POSIX APIs (which has it's warts, as do all APIs). It doesn't solve the problem that developers still need to think in terms of threads and learn how to split their code into something that can be effectively run in parallel.

Reply Parent Score: 1

RE[4]: No it won't
by Bill Shooter of Bul on Wed 5th Jan 2011 00:11 in reply to "RE[3]: No it won't"
Bill Shooter of Bul Member since:

No, its more than just a thread abstraction model. Its an improved thread provisioning model. Its like a threadpool, but Operating system wide.

Ok, I now regret using the word "mortals" in my first response. That's being too kind to those that are not capable of doing it with OS level api's. Its as difficult as using pointers correctly. Some devs/ cs students just cant get it.

Side note. I once replaced a dev that managed to use threads in Visual Basic ( Impressive!), but didn't understand concurrency. It was confusing as to why he went out of his way to make it possible, but then didn't pay attention to any of the ramifications of parallel operations accessing the same data structures.

Reply Parent Score: 2

RE[4]: No it won't
by galvanash on Wed 5th Jan 2011 06:29 in reply to "RE[3]: No it won't"
galvanash Member since:

I also vehemently disagree that there is anything particularly difficult about writing threaded code. I am certainly not a superhuman and find it easy enough.

I don't know you, so maybe what you say is true for you... I on the other hand have been programming for over 20 years, have done quite a lot of programming for different concurrency models in different languages.

I've done straight win32 type threading (i.e. using raw threads and synchronizing using mutex/semephore), a bit of posix threading, using forks on Linux, Java threading, C# threading, asynchronous programming/message passing, overlapped IO, etc. etc. etc. I have not done any BeOS/Haiku development, so I wont speak to that.

Anyway, all of these approaches to concurrency were picked up with various levels of difficulty - some were easy to get my head around, some were harder - none were what I call terribly difficult. The concepts are not the problem...

The problem with pretty much all forms of multi-threading (ignoring asynchronous programming, forking, and other forms of non-threaded concurrency because they are fundamentally different) is not how hard it is to understand, or how hard it is to write code for. It is HARD to debug properly. I don't trust a programmer who says it is easy, they just haven't done it long enough. The language/runtime can help tremendously, some are much better than others - but even the very good ones are hard to debug.

It is very hard to do correctly in an optimal manner, and it takes years to recognize when your code is doing it wrong. It has a tendency to work perfectly fine 99% of the time - its the other 1% that gets you, and usually not until after you shipped.

So yeah, you can say it is easy for you. And it might be - for you. But I can honestly say I avoid it most of the time unless the payoff is very very big. It sometimes is worth the effort, but as my experience grew I realized better algorithms and other forms of concurrency besides threading can get you better, more predictable and maintainable results.

Reply Parent Score: 2

RE[5]: No it won't
by matako on Wed 5th Jan 2011 08:53 in reply to "RE[4]: No it won't"
matako Member since:

Well, I did some casual programming on the BeOS, I have an app listed on BeBits and Haikuware (hey, that binary compatibility thing actually works!).

If I had to choose one BeAPI concept that really stands out I would definitely choose the whole handler/looper concept. It _is_ simple. As a matter of fact my first thought was "where is stuff?". I really feel that the whole concept is both simpler and more flexible that many other frameworks and it does its magic with very basic C++, no template voodoo or anything, so it can be easily mapped to any OOP prog. language.

You pass messages, you handle them - essential locking (handlers) is done for you. If you make another message looper (like a window), then a new thread is created for you automatically. Of course, you can still do MT the old-fashioned way, remember - this is a messaging framework it is not a solution to everything, but for what it is designed, it works well.

As long as you pass and handle messages, you are fine. On top of that there is a high level of orthogonality - drag and drop, inter-app messaging, app scripting, mode monitoring.. you name it - it is all the same concept, the learning curve is excellent! The only thing I miss is perhaps some handy hooks for app scripting. I mean they did them for everything else.

HOWEVER... BeAPI is not for a total beginner. You do need to be a reasonably proficient computer programmer. But you know what - what's wrong with that requirement? Nothing any of us could not achieve.

Edited 2011-01-05 09:01 UTC

Reply Parent Score: 2