Can BeOs Live On As Open Source?
OSBlue writes: "After Palm announced the buyout of Be, Inc.'s intellectual property & Technology and after some consequent indications from several key people that Palm has no interest at Be's products and especially in BeOS, a number of the BeOS believers tried to find a new home. Some found comfort in AtheOS, others joined BeUnited's effort to license the BeOS source code, while some developers formed efforts like BlueOS and OpenBeOS. OpenBeOS consists from a number of BeOS developers who are trying to recreate the BeOS Kits in a form of a new, complete and open source Operating System that has source and if possible binary compatibility with BeOS 5. One of the most important people in this effort, Michael Phipps, is interviewed by OSNews.
One is tempted to make the correlation:
:-) But ya gotta know what to pull the life support....
Amiga == OS2 == BeOS.
All ahead of their time technologically. All killed by stupid managment decisions. All still have freaks that refuse to acknowledge their death.
Oh, and I've used and loved all three
In my (granted limited) experience, and from what I've heard, I think BeOS is an excellent little OS, even if it does have a small niche. That said, I hope it can survive as Open Source Software. If you ask me the more OSS Operating Systems (OSSOSs?) we have out there the better off we are--giev more leverage perhaps against the bit monolithic software houses who produce their proprietary crap (MS WinXP anyone?)
Just IMHO...
Beware the Whyte Wolf.
With a gun barrel between your teeth, you speak only in vowels...
I've been an avid supporter of Be for years. I like the OS and have bought many versions. I think it would do well as open source for numerous reasons. The one that sticks out most in my mind is that it is truly an object oriented OS. I am an object oriented developer and I've looked through and attempted to write some code for linux, and I really didn't like it. BeOS on the other hand, is something I'd like to contribute to. I'm sure there are many other object oriented developers who feel the same way. Imagine if you could get the BeOS GUI to run on top of the linux kernel. What a product it could be!
mp3's are only for those with bad memories
we're trying to build a continent out of them. Perhaps you can extend Linux to provide what it is you like about BeOS.
"The Most Fun Possible on 4 wheels" is at SunBuggy in Las Vegas
I wonder what kind of stuff some of the old Be guys could contribute to GNOME/KDE.
Don't get me wrong, I like the BeOS, but with Linux starting to make headway and gaining momentum, it would be awesome for these guys to jump in.
For me, some of BeOS's goodness in KDE3 would make me drool, all technical issues asside.
I think this shows are hard it is to have a niche OS market. Aside from wireless and imbedded technologies, it seems to me very unlikely that something as huge as an OS can exist on what basicly amounts to a niche. Where there are so many layers to an OS, adopting a whole new set of standards just to have a multi-media optimized OS just wasn't realistic.
That's what's so wonderful about distributions. You can make a niche distribution without the overhead of Yet Another EVERYTHING.
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
Remember that Linux has only gotten really good and has gained the kind of acceptance it needs to be taken serious in the eyes of application developers in the last few years.
I would love to see an openBe implimentation, because it would be really nice to have an opensource OS geard toward multimedia instead of networking and programming. (Linux is many wonderful things, but it simply not geared for multimedia.)
It would take at least the same amount of time to reach 'critical mass'.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Nope. As has been stated over and over again, BeOS cannot and will not be relicensed as Open Source software. There is simply too much proprietary, third party, technology embedded in it that it would take a lot of time, and probably a lot of cash, to strip away. It took SGI almost a year, if not longer, to get XFS released as GPL. Okay, the had to reengineer a good deal of the Linux kernel too. Besides, even if Be manages to strip out the proprietary bits you will most likely be left with a shell of code that will not compile, for a significant amount of time (*cough* Mozilla *cough*).
And IMHO, the "coolest" bits of BeOS have already made it into Linux -> 64-bit journalling FS with attributes, XFS! The other cool BeOS buzzword "pervasive-multithreading" didn't turn out to be that cool after all.
-adnans (ex-BeOS fool)
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
I've used and love BeOS. I've also used tons of other OSs. I've loved things about all of them. with the exception of Windows almost all of those other systems have been considered niche. Some of those niche OSs have thrived. I'd love to see some air breathed into Be again.
-
I managed to get a copy of the pre "freeware" version and I thought it was very well thought out, I would like to see more done with it...
oh and dont forget that it needs some Apps...
Thanks to file sharing, I purchase more CDs
Thanks to the RIAA, I buy them used...
Now finally I've found out what the odd thing in the reddish squarish area in the Be logo is.
It's a skull, of course.
I could've found out earlier: it was just about the time they started to go down the drain when they changed the logo.
There is absolutely no reason to panic.
Linux and X ?
Is it a good way to start a Desktop OS ?
- A consistent, easy-to-use and powerful GUI
- Strong multimedia support
- Runs fast on low-end hardware, and blazingly fast on high-end hardware
- A friendly, close community that welcomes new users
In addition, OS/2 has features that BeOS doesn't:- Great application support, namely DOS, Windows (including 32-bit Windows apps), OS/2, and even many Linux apps.
- Great hardware support (this was BeOS biggest problem).
- It's still being sold, marketed, and supported.
This last item brings me to eComStation, an OEM version of OS/2 that's effectively what OS/2 Warp 5 would be. I invite all BeOS users to check out eComStation. You'll be surprised what you find.And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Debian for ex-BeOS users.
"There ought to be limits to freedom"
Of course, you wouldn't want to leave out NeXT, but then the freak that headed that up was bought out by apple, and see what we have today? Perhaps both Linux and FreeBSD/Darwin/OSX/Aqua could learn some things from the BeOS architecture.
- passion
Seriously if you want something that plays in mostly the same space (except it is
written in C,
is well designed
I don't know QNX, but my impression was that BeOS was actually pretty well designed, all in all (even if you hate C++)? Cleanly designed extensively multi-threaded system, neat filesystem, reasonably good scheduling (even if not hard realtime, much lower latency than any other desktop OS) etc. etc. So which flaws did I miss?
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
From what I understand (having tried it a few times at various stages), beOS is like *nix with a kick ass graphics/windowing layer. Why not concentrate on bringing the beOS gfx layer to Linux ... I mean, the whole world seems to be holding its breath for the death of X11/freeX86. I'm not aware of the technical details, but is it feasible that the beOS graphics/windowing/desktop layer could be slapped onto Linux? If this could happen, beOS would be the desktop *nix box's killer app.
"Old man yells at systemd"
I don't mean to be frank, but what's the big deal? There are *plenty* of other OS's out there if one dies out, some much better. And most college students have shown that at its barest, anyone can custom-create an OS (or take an existing OS and modify it to their desires).
To me, it's like the people who still hang onto the Commodore 64 as "the ultimate gaming machine". I admit, I started my life on a TI-99/4A, but I haven't limited myself to it. This field is all about changing and adjusting and, quite frankly, the BeOS people are going to be left behind.
1) You're a moron.
2) C++ is just as useful as C in many kernel applications. For example, Linux has many implementations of lists, trees, etc. Using templating, you can get 99% of the advantages of having specialized lists for each datatype without the hassle of actually maintaining specialized lists. Also, Linux has a lot of structures filled with pointers to functions. ABC's fill that role much more cleanly. Operator overloading (like overriding 'new') also come in handy. Plus, its not like anyone is suggesting writing the kernel using STL or somesuch nonsense!
3) The BeOS kernel is written in 'C'.
A deep unwavering belief is a sure sign you're missing something...
We could call it BeSD :)
Don't get me wrong, I love Linux / UNIX. I'm typing this from a FreeBSD workstation right now. I personally love the windowmaker environment and the "UNIX way". I don't believe in wordprocessors (long live LaTeX---or LyX for you neophytes). I read my e-mail with mutt. I use lynx to browse the web most often. I use X to organize my terminals and set their geometry!!!
That all being said, I would not wish my computing lifestyle on anyone.
I'm also a closet BeOS user when I can be. Let me tell you what I like about BeOS.
Some of the other things that be had was a file system that you could do many database style things to. Ripping and organizing mp3s from the standard filesystem and OS features was cake!
Replicants and such were badass. I could imbed a webpage on my desktop with netpositive.
I could go on and on. I loved the system. I love Linux. I love them for vastly different reasons.
I love my Linux brethren because of their idealism, but sometimes they are too interested in ruling the world by exclusionary tactics. Don't assume that alternative OS users', their hacking ability and intellect belong to "the movement".
-Peter
. Penguins Surely Ca
beos doesnt have the hard real-time capability, but it actually IS written almost all in C... its the API that is in pure C++
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
Hang on BeOS users. For OpenSource coders who want to do something cool, but aren't sure what, this is a grand opportunity. These people have a plan, a working prototype, and the experience and skills with BeOS to make it happen.
Remember that BeOS is not Linux. The two will fail or succeed on their own merits.
As for reaching critical mass, well, that is a problem still with linux. I think OpenBeOS could do it though with careful planning and hard work. If not, then we get back our niche OS and best of all it will be Free.
-Peter
. Penguins Surely Ca
They want stability, simplicity, reliabilty & compatibilty. That's it. (unless of course they are into things pedaphilic, or they are a drug dealers, or they take work home with them, or they are paranoid schizos)
W2K & WXP are stable, reliable, compatible but definitly not simple (the average bloke doesn't give a fuck about multiple logons, they just want the computer to auto boot when they turn it on & quickly - gez W2K is a slow booter)
As far as Linux is concerned it has the same problems as W2K (you can go make a cup of coffee while waiting to boot all the way to the K desktop). Plus there's the esoteric Unix filetree
BeOS is simple, stable, reliable, but just lacks compatibility (drivers, apps). Its modified Unix file tree can actually be understood (its behind a 'BeOS' directory & only upgrades from BeInc go there, there's a complete mirror of it in the Home directory, so if some app or driver needs to add stuff to a system directory it goes there automatically during the pkg instalation. So you just install apps in a folder that you can actually call 'apps' in the home directory & you can install drivers in a folder called 'drivers' in the home directory, etc.)
W9X is simple & compatible, just no good as far as relibility & stability are concerned.
I agree, Glock27.
The kernel could be using C++, I understand the reasonings for that. However if you want to use GOOD C++ with Resource Aquisition Is Initialization (RAII) or have any non-trivial constructors, you NEED c++ exception handling, which can throw a big wrench into your special stack frames.
STL would actually be NICE to use within a kernel however!
The C++ API caused tons of stupid problems and workarounds in BeOS. Not only did they have to reserver vtable slots (in the right order!) they had to make sure that any methods that could be inlined were not if they might possibly be changed to non-inline in the future.
The BeOS api was started a long time ago - before the ANSI C++ standard came out. There are a number of design decisions that Be made back then that seemed reasonable then, but are not good now.
For instance, they should have designed their interface classes to contain pImpls - yes it is an extra redirection but it allows for dynamic library compatibility. Also, there should have been less focus on inheriting non-abstract system base classes. All user classes that the system needs to know about should be inherited from a pure abstract system base class. It would also potentially make their BLooper message dispatching system nicer - like libsignal++...
But one BIG problem with BeOS (besides bugs and slow networking) is their use of threads for EVERYTHING, in the language of C++ which officially has no concept of threads. Yes, you can do it but it is like fitting a square peg into a pentagram. Maybe Ada95 would have been a better choice? But that wouldn't be 1337 then I guess.
--jeff
ipv6 is my vpn
as long as the alleged source tree leak [begroovy.com] doesn't derail the project first.
As a precaution against legal liability, one of the more popular Beshare servers that hosted the tree, for however briefly, was voluntarily shut down.
Where does the school board find them and why do they keep sending them to ME?
and adding to the question...
:)
Is Timur Tabi still an active OS/2 user/advocate? I remember how proud I was the day he used my figshell program and complimented me on it
I think Timur's been playing with linux lately hasn't he?
And that's about what it's selling for.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Be Inc. had, for the most part, dropped BeOS entirely a year (at least) before Palm bought them.
They had been putting ALL of their efforts into the BeIA (I don't remember what the IA stands for) which was meant to be an "appliance OS", like PalmOS or Windows CE.
It was VERY cool, and used a lot of BeOS technology. BeIA is to BeOS what Windows CE is to Windows.
This is a reminder of why software needs to be free. BeOS, QNX, MacOS X; these are attractive systems, but when you invest your time in learning them you surrender control to a corporation. You head down a road which can be pinched off into a dead end at any moment. That's why I steer clear of this stuff, no matter how nice it looks.
I'd rather have freedom than a nice GUI. As long as you have freedom, you might make a nice GUI. But without freedom, you can't even hold on to your nice GUI.
I wish these developers the best of luck in creating free software to replace BeOS.
They were already screwed when they started BeIA -- it was a last ditch hope.
The main reason the company flopped was because they thought they could compete (or "co-exist", whatever that means) with Windows in the general purpose desktop OS market, where it didn't solve anyone's problems (unless 2ms latency helps your e-mail experience in someway I'm ignorant of.)
If they were smart, tney would have stuck to the original plan -- making high-end AV workstations using custom software for vertical markets.
When I hear the word 'innovation', I reach for my pistol.
What else did BE own?
Operating system designers with incredible skills (Most of them originally came from Apple, of course). In this day and age intellectual capital is everything, and that's exactly what Palm is buying in Be - brainpower.
== Paul Rickard, Editor of The Microsoft Boycott Campaign ====
BeOS was about latency, not throughput. When you move the mouse it moves NOW, not in a quarter of a second. Click on a button and it presses/releases IMMEDIATELY in response to what you did, and the new window snaps up NOW. It sucks as a router, but if having the GUI respond when you move it is what you think the system's first priority should be, then it's perfect.
Linux is about throughput and has sucky latency. Process switching is devoutly to be avoided. We won't put graphics in the kernel because that might slow down our packets per second as a router. We won't even apply the low-latency patches that have been floating around for a year and change. (Maybe in 2.5...)
Load a Linux box until it's thrashing and your rat pointer will jump inches at a time. You can't cut and paste text accurately when your mouse pointer jumps five letters a second and a half after you move it. That's how you get great throughput (batch up those transactions and run 'em through in CPU cache. Join together 50 mouse moves into one BIG mouse move!) But it sucks for GUI-ism, and that's what Windows users care about.
Moore's law will take care of half of this. As systems get faster, latency gets better because we deal with stuff as fast as it comes in. Nicing your X server down to -10 helps a bit, because it interrupts other tasks when it wants to do stuff, but that doesn't help applications you spawn and it doesn't do THAT much for the X server either because niceness is just a suggestion. Yet we don't even seem to do THAT as standard in Red Hat...
It's a question of what the system is optimized to DO. Getting good GUI performance from Linux has only been a goal for the past year and change. The KDE guys are trying it. The Gnome guys are trying to make sure the KDE guys aren't the ones to do it because they don't trust the KDE guys' judgement on licensing issues. The XFree86 guys are trying to undo the mistakes of the past 15 years. (That and get 3D acceleration, which is great, but 80 million triangles/second is reality (or the human perceptual threshold) and it won't be THAT long before Moore's law makes your low-end 3D card photorealistic images in realtime. And a hardware generation or three after that, software rendering will be able to do it. It becomes a much less interesting problem then...)
The kernel is fun, but the big block to Linux on the desktop isn't the kernel anymore. It's XFree86 and KDE. That's where effort can be used. But not until we understand the difference between latency and throughput. (Although getting the kernel to have seperate niceness settings for throughput and latency might be a good thing...)
Rob
I let anyone who visits my house (invited by anyone that lives in my house) use my PC (I can't stop them if I'm not there), but I don't want them to have the ability to send emails out in my name, read any file or change any file on the system. There's login passwords to ISP's in plain text in there, and technical reports that should remain confidention, plus lots of role playing stuff that could be taken out of context (not to mention a lot of fantasy art that may make people think I have a thing for tall women wearing little strips of leather and carrying 7 foot long swords).
In the office security is essential, if only to stop pranksters or the disgruntled from changing your files and settings. In the home at least you want to be able to stop people from assuming your identity (or your new girlfriend reading five years of your email outbox and saying tearfully "why didn't you write letters like that to me?").
Back to BeOS - how much effort would it really take to enable SSL and have a secure login screen? I suspect that it wouldn't take a lot to make everthing that comes in either authenticate itself or not be able to do anything outside of the program that asks for the data. As for file permissions, I don't know much about BeOS, but I know that it can support a few different filesystems, so it becomes a case of using one that supports file permissions.
The audio geeks love BeOS for it's low latency.
The multimedia geeks love it for the applications.
The proto-geeks love it for it's ease of use and stability.
It would be very bad to see Palm let it die. BeOS doesn't fit in the organiser market, but tiny PC's like the iPac are a growing market, and BeOS could fit squarely into the market of organiser sized PCs if Palm goes that way.
Of course, when the kernel is unstable and full of holes, that sort of kills its chances anyway, wouldn't you think?
I've long felt that BeOS would be an a good OS for STB's for interactive Digital TV. It's multimedia friendly, simple to use and a light-weight s/w load, it's Ideal. Combined with Palm's direction toward the remote Internet Appliance market this surprises me. However their loss looks to be be Open Sources gain.
Yes, this bigotted profiling has *got* to stop. It's wrong. It's evil.
Every day, thousands of people are stopped, just for using win98. Computer hardware is biased, assuming that win98 is more likely to crash than *nix. "Application" error, it says, as it stops the user for "investigation." "General Protection Fault", as it pulls the application away. Then, as civil libertarians try to investigates, it blue screens, all based on the notion that win98 users are less reliable.
This user profiling must be stopped *now*!
:)
hawk
You said C++ wasn't appropriate for a kernel, I pointed out that the kernel was in C. Second, there are hacks in other (C) OSs too. For example, paremeter passing to the kernel is always kinda ugly. Hacks are just a part of life in the kernel. Also, the C++ issues exist in Linux too. KDE/Qt gets around the FBC problem by breaking binary compatibility every major release. Given the smaller BeOS software base, the reserved function "hack" really isn't that bad.
A deep unwavering belief is a sure sign you're missing something...
Geez, stop complaining about threads! There is nothing wrong with pervasive multi-threading. Given the crappy responsiveness of the Linux GUIs, Linux people are in no position to talk. A lossy messaging system (as in BeOS) is an implementation problem, not something wrong with threading. Just learn how to do proper locking and everything will be rosey. The kernel people have to deal with it all the time (SMP locks), its not that HARD.
A deep unwavering belief is a sure sign you're missing something...
I use threads all the time! I just don't like them to be forced. However I'd like them better in a language that officially SUPPORTS them. C++ is not that language, unfortunately - think thread safe std::string, STL and exceptions, race conditions in singletons without a double guard (therefore the inability to have non-trivial constructors in static members of a class without wrapping them in a thread-safe dynamic singleton allocator object), debuggers, core dumps, profiling tools, memory leak checker tools, lack of warnings when using shared data without a semaphore, etc..
I've been using BeOS for ages and actually had a PPC BeBox too! Still have BeOS installed (which kernel panics when my real Roland 100% standard MPU-401 MIDI interface receives a MIDI byte).
Worked with www.lcsaudio.com where they are STILL SHIPPING commercial software for BeOS. At one point LCS had more BeBoxes than any other company besides Metrowerks. I used to be an enthusiast.
Not anymore.
I can't count how many BeOS applications are written with threading problems! Is it because most programmers actually suck?
Yes, most linux GUI's responsiveness sucks. No, having a seperate thread for each window would NOT always help - Most X apps only have one window anyways. However, having seperate non-gui worker threads WOULD help and should be done when appropriate.
--jeff
ipv6 is my vpn
The thing with BeOS threads is that they force you to seperate display logic from the actual program. This allows windows to redraw quickly without waiting for the application to catch up to it. This is a problem in many Linux GUI apps. Also, by seperating the display logic out, it takes away many of the pains of multithreading. The windowing thread shouldn't be doing anything super-complex, just displaying precomputed data. As such, multithreading shouldn't really make designing programs that much harder.
A deep unwavering belief is a sure sign you're missing something...
Well, I agree with you.
--jeff
ipv6 is my vpn
Plus there's the esoteric Unix filetree
Hmm?
The Unix file tree makes a lot of sense to me.. a lot more than the silly meaningless Windows file hierarchy.
Anyhow, what do you need to read from the tree directly for anyhow?
All your stuff use your own organization under $HOME in *nix, whereas its Windows where you have to browse and navigate throught its large, meaningless file hierarchy.