Posted
by
Hemoson Friday March 01, 2002 @01:53PM
from the making-things-pretty dept.

Bob Gortician writes "The BlueOS guys have posted a few screenshots of their progress in porting the BeOS interface to Linux. Note that this is an intermediary step toward a BeOS clone OS. " I actually had a Be machine for a while, and played with it - nice OS, and well thought out, just a problem of very little applications for it.

The CONTENT of the windows are just a picture. The window manager is real and fully interactive. It is just a demo/proof of concept to show that the window manager/environment works. They had to put something inside these windows, so they added this picture that looks like a real content, only it is not interactive, it is a picture.

Driver support. Had virtually no video or sound support, so everything was in grey and mute. I loved the interface, and it booted up as quick as can be, but there's only so much you want to do with no driver support. Why make an application when no one else has a machine it'll run nicely on?

Actually BeOS had quite some support with BeOS 5 and the third party drivers found on BeBits. I agree with BeOS 4 and 4.5 did not have many drivers, but version 5 was really good at the time. Now, it is 2 years with no BeOS official updates, so naturally, it is already out of date..:(

Not that the majority of Linux users care about the Mac, but the fact is that Mac OS X represents something I believe a whole bunch of Linux users should get behind if they want their OS to succeed - It's Linux with the useability that Joe Sixpack can handle.
BeOS has its uses, but aside from the glory hack of porting its interface to Linux, I'm afraid that this can only serve to fragment the already small effort behind pushing Mac OS X as Linux's true way to combat Windows, because let's face it - Neither KDE nor Gnome are going to make my mother leave Windows anytime soon...

Mac OS X might be UNIX's best hope, but as it's not Linux, I don't see how you can say it's Linux's best hope, let alone that "It's Linux with the usability that Joe Sixpack can handle." Different license, different kernel architecture, different filesystem . . .
That said, the more Unices or UNIX-likes there are, the more compatible everyone will be, and the better off we'll be. (Of course, the same could be said of Windows)

Well, I made that comment because while I'm totally offbase from a geek standpoint, for the average home user, Mac OS X presents them the closest semblance of a UNIX-like operating system they'll ever see. And more people out there in this decade have heard of Linux than UNIX (Again, we're talking about average schmoes)...so I think that X's popularity will further the interest in Linux (Even if it is based on BSD, which is another point entirely).

A lot of people, including me, are transitioning from Linux to the Macintosh. The Mac has all the deep applications people need, while including all the coolness that is Unix. (Call me when something like Final Cut Pro or After Effects runs on Linux. And when the fonts don't look like sixth-grader crayon sketches of text:-( ).

That being said, we must say that a certain amount of variety in the computing world is necessary. Some people don't have $1,299 for an iMac (assuming the low-end model comes out sometime in the next century or two). Some of them want to build computers themselves, or buy an eMachines with a crummy 15" CRT monitor picked up at a garage sale for fifty bucks.

We can't convince these people to buy Macs; Macs are always going to be a bit for the elite, a bit for those who like spending money on fine technology. They need Linux just as we need Macs. As long as they are off the dreaded Windows, we shouldn't turn against them; if they grow older and richer, like I did, they will appreciate the better things in hardware soon enough.

So don't be against this kind of project. If it can make Linux more cool, well, those who learn it are learning the same basic operating system that underlies Macintoshes. So there should be more cross-polination between the two worlds, which I feel is all for the better.

Advocate the Mac when you can, but don't consider linux the enemy. We have a common enemy, and you know what that is. All too often we get injured in internecine squbbles instead of taking care of the most important advesary.

Well, the leading standard operating system stinks and tries to lock you in to all sorts of proprietary stuff, so I can't say there's much of a choice there. In fact, I'd say you give up less freedom when you buy an iMac.

And Linux is similar to a proprietary OS in that there is a definite limit to what you can do - if you want to run mainstream creative applications, you need either a Windows PC or a Mac, and I know which of the two proprietary platforms I'd rather have.

Even much of Slashdot is noticing this - think about their addition of an Apple section, for instance, and the nearly fawning recent coverage. The Mac seems to be moving from strength to strength nowadays, on the path Leader Steve has blazed for us.

You can say a whole lot of bad things about Leader Steve, but nobody can say he's not effective at his job. I had a chance to take a close look at the new iMac, and it is almost lovable in its cuteness. Not to mention ergonomically perfect. The day commodity PC makers create an original design like that is the day I pay attention to them.

Ok #1) MacOS X is beautiful... but its also the Mach kernel with a BSD compatibility layer on it. Its definitly not linux and typical linux apps won't run on it without a little tweaking.

#2) Have you played with the KD3 beta2 yet? Did it last night and its gorgeous... has some bugs left, but we're talking beta software here. I think if we fix up the config file mess (slackware people excluded, because they like them;-)) and put kde3 on a machine, windows users should have no problem.

On a side note, my two little brothers accidently logged into my linux box. One didn't know he wasn't in windows and was using it fine and the other knew he was in linux but liked it better. Just something to think about.

KDE, GNOME still lack the consistency of a real desktop environment like Mac OS 9 or X

You know, after hearing this for so long, I actually picked up an older iMac off of eBay and put OS X on it. Let me tell everyone something right off: OS X is no more consistent than either GNOME or KDE... probably less.

The Apple freaks will flame me to hell for this, but it's true. I like OS X -- it's pretty and based on Unix. But it's anything but consistent. After spending a couple of hours trying to either get iTunes to work or find a decent MP3 player for OS X, I started to understand how normal 'users' feel about computers. Half the time I couldn't figure out what was a control and what wasn't, and when I could, the controls had to be played with to figure out what they did. No tooltips, no useful icons. But they sure were pretty.

Yeah, that's just one app. But it's from the company that made the bloody OS! And don't get me started on QuickTime Player or iMovie... they suffer from the same problems, so it's not like it's an isolated case.

Third-party apps that follow Apple's HIG (you know, the document that Apple decided to ignore) are pretty good. But then, so are the GNOME and KDE apps that do the same things. OS X is decent, but it's not the end-all of desktops that some people would have you believe.

Part of the 'hours' were spent looking online for a player that didn't suck as much as iTunes. (I never found one for OS X, unfortunately, and I can't see running the whole classic environment for just an MP3 player.)

But the consistency problems are hardly minor. They're part of a disturbing trend with Apple -- they're moving away from usability as their primary concern and going toward flashiness. Sadly, I've had much better out-of-the-box experiences with Linux (mostly Mandrake, but Red Hat is getting better and better) than I did with OS X. OS X is frustrating to use... Linux Just Works (tm). It's all a matter of taste. But I still wouldn't set up my grandmother with a Mac.

(I pick on iTunes because it's the single most frustrating end-user app I've ever used. It won't play OGGs, ignores some directories of MP3s at random, is a pain to reorder files in (I have them sorted by filename in subdirectories for a reason, thank you. If you're going to sort by ID3 tags, at least do it by track number instead of track name!), etc. etc. It's just painful to use.)

I run Darwin w/o Quartz. I still have all the Quartz/Aqua stuff installed, but quit out of it at boot. I run Darwin over Debian PPC for a couple reasons:

1. Power management: Darwin works very well with the hardware (iBook). This manifests in more than one place. Longer battery life, and sleep works well (by shutting the lid).

2. The option to go into Quartz/Aqua: One of the things I hated about using Linux/x86 (what I ran as my main OS for a couple years before getting a Mac) was having to reboot into Windows to play a game or use certain useful applications for which there's no equvilent in Linux. This was true back when I used Linux a lot more than it is now, though. But with OS X, I can play games and run real, useful apps. And if I choose to run XFree86 straight out of the text console in Darwin rather in tandem with Quartz, I can always quit X11, and go back into Quartz. A lot less hassle.

People have different preferences in processors. I prefer the PPC over Alpha hands down, largely because they're powerful, but not sloppy power-hogs like the Alpha. Speed isn't the only thing that matters.

The developing of a BeOS clone via this route may yield atleast the se two main benefits:* Linux and other *nix's will gain another easy to use, mature, comprehensive GUI.* BeOS will gain from more exposure and may get new development.

Say I have 20,000 emails in a year...
If it was on a Linux system, you'd run out of inodes on my disk, if it was on Windows I'd run out of sectors on my disk. Does BeOS have some new way of storing things on a disk that doesn't require such ways of addressing data?

Seperate workspaces at different resolutions is a cool idea and I'm surprised more people haven't talked about it. I assume you're thinking about the problem of the little app that shows the previews of the workspaces not working? it shows a scaled preview, so simply use different scales if workspaces use different resolutions. I could have a 1600x1200 workspace for doing programming and design work, and a 1280x1024 one for playing games (UT on Linux runs quicker at that res on my system), and an 800x600 one for if my gran wanted to use my computer as she might not be able to see text on a 1600x1200 display. This would be a really useful feature to have and might be possible if X was capable of changing resolution without restarting. Can BeOS do that?

Does BeOS have some new way of storing things on a disk that doesn't require such ways of addressing data?

Yes, in fact its filesystem was considered to be one of the nicest "advanced" systems of its kind - designed from the ground up with really nice features such as file indexing and metadata. It has been compared to being a database more than a filesystem (but of course, any filesystem is a database under a loose enough definition).

This would be a really useful feature to have and might be possible if X was capable of changing resolution without restarting.

What on earth are you talking about? Try running xvidtune; that will let you cycle resolutions on the fly. Most X setups will let you press C-A-+ or C-A-- to change resolution (+ and - on the keypad). Furthermore, UT on Linux is able to change resolutions in-game -- certainly without restarting X.

Anyway, since most games are "soverign programs" that take over your whole display, it makes little sense to have a seperate workspace for games (they will "create their own", so to speak, and set the resolution accordingly).

I'm not that familiar with the workings of X. One thing I have noticed though it that with Unreal Tournament running in X on RedHat 7.2 with the latest NVidia drivers (from www.nvidia.com), UT's resolution selection list only shows the current X resolution as an option. Furthermore, if you change teh resolution in the config file to one that is lower than what X currently runs at, the game will still run at the same res as X, just in a smaller box in the middle of a black screen. Setting it to one higher than X means that you don't see the menus cos theyre off the top of the screen.

Actually, if you use a filesystem like XFS or ReiserFS that dynamically allocates the inodes, your only limit is disk space. In BeOS, each inode is the size of one block (usually 1KB) plus say 1 block of data (another 1KB). Thus, the total space for those 20,000 emails would only be 80MB per year. You could store a lifetime's worth of email without ever running out of space.

Yes, it can. BeOS's workspace feature is basically virtual desktops that can exist at different resolutions. It gets especially cool if you have a monitor that changes resolution without any noise or fuss (like most Sony ones). Then, going to a desktop with a different resolution is just as easy as CTRL-Fx.

Back in the day we all had such high hopes for BeOS. They had the coolest apps for watching SMP apps utilize CPU. Then we all rejoyced when it was thought that Mac was going to use Be for there underlying OS, but to no avail. Then we cried when it was thought that Beos would be no more. I wore my T-shirt for a week in defiance. Now I have a little heart that it will still live on in our memories and in our porting dreams.

IMHO it could have been more than a PDA or a toaster oven OS. Too bad more apps wern't produced. I actually think I still have a CodeWarrior CD that will let me compile on Mac to Be. Not that i even know where to find a Mac anymore,*besides the one at work that runs linux*.

And does anyone remember that app they had that bounced a ball from one window into another window. In the day that was cool.

ahhh.. misspelling blis! Maybe i should have the doctors remove that 6th finger, they just don't make keyboards with us in mind!

I know there are some who think the multitude of GUIs for Linux hurts rather than helps, but I think a project like this, bringing another highly user-friendly interface to Linux is a plus. I may like a lightweight GUI with mouse-click menus and manually editing config files, but not everyone does. I can't expect my parents to learn vi or emacs if they want to change something;)

I have played around with BeOS some, it seemed good and solid. COuld someple please tell me what these screen shots represent? If this the BeOS API running ontop of Linux in the way that Win3.11 ran on top of dos? Or is it just another Desktop Environment ala KDE GNOME Ximian etc?

It is a port of the BeOS C++ API on top of Linux. Everything will be "wrapped" to resemble the BeOS API to the point to almost be source compatible with the BeOS applications. Even the filesystem API layer will be changed accordingly in order to accomodate OpenTracker, the BeOS Desktop and filemanager.So, in a sense it is like KDE and Gnome, it is a full desktop & development environment on top of XFree & Linux (they plan to remove XFree completely in the future), however lots of things will change in order the system to "feel" more BeOS-ish. They also apply some additional patches to the Linux kernel for better UI response, as this was one of the strong points of BeOS.

I appreciate the efforts of the BlueOS team, but I still have reservations about using Linux as the base for the new BeOS. I am glad to see that they have made progress, don't get me wrong; however, the OpenBeOS team has made huge strides as well, and may be more in line with the original spirit of BeOS. For example, they now have: BFS read support in their new driver, many preferences done, good progress made on the printing kit, a prototype app_server, and more. It looks like binary compatability will be achieved sooner than thought, too. Check out http://www.openbeos.org/ [openbeos.org] for more details on another team working hard on a worthy successor to BeOS.

No one would write a lot of apps until it had a larger user base, no user base would be generated until it had more apps.

It's the same set of problems Linux has faced in the past. BeOS was/is a fine OS, but it never seemed to have a good backer, nor a solid niche. Artsy types already prefer Macs, so it's hard to compete there. Ordinary desktop users have already been won over by Microsoft, so it's really hard to compete there. Linux users already had a free OS and a nice looking desktop if they wanted it (re: KDE, Gnome. You should know that by now).

I think that BeOS was a nice, stable OS that could have been a contender. It's a shame it didn't get more press or attention from major industry players. Oh well, I look forward to another nice Linux desktop all the same.

I feel the same way... in fact, there are a lot of PC items that are the same. Have you heard of this crazy USB thing? For the longest time USB was on every AT motherboard yet didn't come with the little wires that brought it to the outside of the case. The lack of USB support for the OS and the lack of devices that used USB painted a dim future for the interface.

Where is it today? It's everywhere and USB 2.0 is pushing firewire out of the picture. It took a LONG TIME to catch on, but it did.

Okay, it's comparing apples and oranges but the idea of the catch-22 being the block that stops progress is kinda wrong.

It's not that I think it blocks progress so much as it extends the time of acceptance.

The thinking would be something like, "I'd like to use BeOS, but it's not compatible with my video card yet." Now, multiply that statement by a couple of gazillion users. Said users don't need another desktop OS and BeOS didn't have any "killer apps", so the acceptance rate is much lower.

Like I said, it doesn't block acceptance. But it certainly influences it negatively when there isn't a "must have" application involved.

An evil monopoly didn't kill BeOS; Be, Inc. did. Every time they got momentum doing one thing, they decided it wasn't going to work and changed business plans. If Be had picked a good business plan and stuck to it, they could have at least carved out a niche. Instead they kept changing their minds about what their core business is.

They had a great (amazing!) piece of technology first, and then tried to decide how to make money from it, and screwed up over and over. BeOS was the nicest, cleanest, most well-engineered OS I've ever used, but it didn't have a chance.

Uh... Offering the OS for free says nothing about how worthwhile it is for these manufacturers to install it. A hundred Linux and BSD distros are available to computer manufactuers for free, but almost none of them install it. If it's not worth using, they're not going to waste their time getting an install image that works with their setup.

Then buy a computer without Windows. Problem solved. You cannot force every person buying a new computer to buy a machine running Linux or BeOS instead of Windows. The best you can do is "vote with your dollars," as they say, and buy a computer that doesn't come with Windows. It's not that hard.

Regardless of whichever conspiracy theory to which you subscribe, almost all people buying a computer with Windows installed don't care to have BeOS installed on it.

Some people just can't get past the denial that BeOS didn't come out on top, and that not everyone wants to use it. I'm sorry, but not everyone shares the same tastes and opinion as you, lad.

This demonstrates the essential problem of having ANY class of consumer product you like dependent on a single corporation. Single individuals and single corporations are STUPID. They do stupid things and make stupid decisions. All it takes is one corporate sabateur in the guise of CEO or manaager and you can kiss your pet product goodbye.

This is why monopolies are generally bad. They eliminate the diversity that allows an entire population to survive despite individuals being killed off.

Be died because they failed to embrace the developer community. They could have done more to court the end-user-developer. Instead, they casually dismissed the whole Free Software concept.

Had they encouraged more cross-pollination between Linux, FreeBSD and BeOS many of their "critical mass" issues might have solved themselves.

Without MicroSoft's tactics, there certainly would have been machines at BestBuy that dual-booted. They could put in the adds "includes BeOS, a $150 value, free!". In practicality most people would immedately reformat that partition as another Windows disk (in fact the company making the machine would do well to make this easy), but a *few* people would have tried BeOS.

At that time the video was MUCH better than Windows (probably still is) and I'm sure some games would have come out with BeOS versions (on the same disk as the Windows copy) and people could immediately see the better performance. That would have opened the gates to people using BeOS more and more, and applications being written for it.

BeOS may very well have failed and been wiped from the disk by every user too, but at least it could have tried!

But MicroSoft stopped this from ever happening. This is a fact and trying to pretend otherwise because "everybody here hates MicroSoft" is not going to change it.

While BeOS had a nice GUI, its read strength was its highly efficient threading model, which made the OS very effecient and responsive. The OS was especially adept at efficiently utilizing multiple CPUs.

While it is certainly nice that Linux users will have the opportunity to benefit from a nice new GUI and API, the best part of the OS, alas, is being left behind...

You do know that Linux's thread model is pretty damn good itself. What was special about BeOS wasn't that it kernel, but the way it was designed. Take multithreading, for example. Linux probably handles apps with multiple threads just as well as BeOS, as long as you stick to 4 CPUs. Yet, multithreading is tons more useful on BeOS because people actually USE it. The thread-phobic UNIX developer community just doesn't take advantage of the responsiveness gains to be had through multithreading. Take Galeon for example. Where BeOS and Net+ were agressively multithreading, Galeon is agressively single-threaded. It seems like the developers did everything they could to make sure that while the browser was doing anything, the whole UI would freeze up. On my PII-300 MHz, surfing the web with dozens of windows open is no problem in BeOS or Windows 2000. Yet, with Linux/Galeon, it is torture because everything I open a complex page in a new tab, the rest of the galeon UI locks up for several seconds while the page renders. I think that this BlueOS project is the greatest thing ever. It takes what is great about Linux (the kernel and the hardware support) and merges it with what's great about BeOS (the UI and development model).

I agree with you. For Linux to truly take off on the desktop, I think that a lot of existing and archaic stuff in current Linux distros needs to be removed or rewritten. A lot of effort has been put into the Linux kernel's development, but lately there has not been a whole lot to show for it on the deskop.

For my work, I mostly use Windows. I have to admit that Windows is bloated, but on my machines KDE and GNOME run very slow. I also don't like their overall design (their aura, of sorts), but I loved BeOS. It's so hard to explain... maybe it's just like how people love their Macs.

Also, writing apps for BeOS is very easy. For C++, it doesn't get any easier. Clean APIs, no library conflicts, etc, etc.

So anyway, I bet BlueOS does succeed in their goals over the next few years.

Geez, I hope BlueOS doesn't make the mistake of being closed source. For a commercial product, open vs. closed is perhaps debatable, for for a free project, open source is really the only way to make a project viable for the long term. As for binary compatibility, BlueOS might be able to do Linux binary compatibility, which would be good in itself. A think most existing BeOS applications would be recompiled if BlueOS ever became viable (since most of the BeOS developers were quite responsive to the user community) and providing compatibility with Linux/X apps would be useful while a native BlueOS application base built up. The situation would be something like that on OS-X, where older apps, while they don't"mesh" into the new OS, provide a transition base.

I would rate Linux as mediocre on both counts. On top of that, this project is taking a GUI originally found on a highly threaded graphics system am bolting it on top of the monstrosity known as X window, which makes very poor use of threading. There is no way that the result will be even remotely as responsive as the original, not when it is running on a bloated and buggy pig like X.

A GUI that actually uses those checkmarked features! The Linux kernel is a great base for an OS. I think its rather stupid for the OpenBeOS guys to try to write their own kernel. Hell, even XFree86 is fairly decent in its 4.x form. Its everything above xlib that is keeping the Linux desktop behind.

You can create the most beautiful, well-thought-out and consistant UI for an OS, but if the individual apps are written with sloppy UIs, it all falls apart.

The one problem I have with Linux is the fact that 90% of the GUI apps have simply idiotic user interfaces. I burst out laughing the first time I used Linuxconf. The dialog window that popped up the first time it ran had a "Quit" button instead of a "Close" button. That is a perfect example of the misleading, inconsistant and just difficult to use interfaces plague the platform. There needs to be some sort of effort put into implementing a consistant UI across all apps, or else all of this work will be for nothing.

On the Mac, and to a slightly lesser extend on Windows, almost every app is interacted with in the same way. A user knows what to expect when they start just about anything but a game. And while you can argue what paradigm is the best, the fact remains the consistancy is the key and Linux lacks not only that, but a core set of accepted design principles. You can argue this will somehow curtail your "freedom" or something all you want, but the fact remains it is a solution that offers much more promise than the embarassingly ameturisih one we currently have to suffer through.

Badly designed user interfaces make Linux look bad. It's simple as that. When Linux looks bad, it's adoption rate is affected. How do people expect to combat the negative stereotypes of the platform if they are unwilling to band together to overcome the easiest to fix, yet most glaring problem with the OS? This isn't as much about asthetics of Linux apps as it is about the success of Linux itself.

If you think "Oh, I just use the command line" or "Who cares, let them program it themselves" or "It's pretty, so what's the problem?" you are being ignorant of the demands and expectations of those you care attempting to bring over from Windows or wherever.

Drop the elitism, drop the selfishness, just realize what needs to be done and understand the awful truth of the computing industry, one that seems lost on most Linux developers:

Give them what they want, or they will go away.

It's not about what you want, it's about what they want, how they want to work. Never forget that. You can't force-feed them every paradigm change and excuse for every bit of laziness on your part. You have to adapt to their needs and adapt quickly. You only get one chance to make a first impression and pissing them off by acting high and mighty about changing things to make their lives easier is not the way to do it. Many a promising platfom has died because of this, don't for a second think Linux is immune to the negative effects of the choices made by its proponents.

People need to realize that ignoring this sort of thing forever will somehow fix the problem, or that we will slowly somehow overcome it. I don't think that meshes very well with reality. It's going to take a clear and consistant vision with a lot of effort on the part of the developers and users to overcome this impasse. And believe me, it is an impasse. The platform is currently reaching critical mass and a point where it decides where it wants to go, and what it wants to be. Sure, this is going to be unpopular, but I don't care, I'd rather get modded down to oblivion than let this go unsaid. Because it needs to be said, and it needs to be appreciated, if not neccesarily liked.

Goodness, Windows and MacOS have been using them for/years/. Why the hell hasn't the Linux community taken a hint? Every X program I run has a different dialog, the common thread among all of them being that, for the most part, they are all crappy.

While I am not involved in the BlueOS project, I think my work is complementary to theirs. Eventually, it should be possible to boot from a BeFS volume, compile and run BeOS apps, and not know that it is the linux kernel underneath it all.

Change notification, file attributes, and similar functionality could be useful for Linux. But the BlueOS effort sounds to me like they are just going to do the minimal thing necessary to provide that functionality in a BeOS-style ("kernel_server"), let the rest of the Linux world be damned. I think that would be wasted effort: a BeOS layer on top of Linux will always be a fringe effort and it just will not take the world by storm.

A better way of doing it is to think carefully of how one can provide that functionality in a way that is natural to a UNIX and Linux environment, and then build BeOS compatibility on top of that. With that, there is actually a chance that non-BeOS ports will start using the functionality as well.

Umm, putting glibc into the kernel would make all apps tons slower (since each function would be a system call!) Second, since glibc defines how applications are to make system calls, putting glibc into the kernel would prevent apps from making any system calls. Other than that, you're quite right about everything else.

Of the two main beos clone contendors, blueos and openbeos, which ones does everyone seem to think will be the one worth going with? To different groups hitting the same task from different perspectives, it should be interesting to see what shakes out.

I realize BeOS was a great OS. It had allot of terrific ideas. Im not suggesting Be was worthless. And I also recognize that people can scratch their own itch if they damn-well-please. Im not about to tell anyone what they should spend their Coding-Karma.

BUT

What is the point of rebuilding BeOS completely and totally? Why not move on? Steal (with pride) Be's good features and ideas, assimilate them into GNU/Linux and move on. Trying to re-implement something to have a work-alike seems more like drugery and backwards-itis.

I wish the BlueOS people great luck - but I would suggest that they should implement the features that they love into GNU/Linux and move forward - the beauty of the GNU/Linux system is that the best rises to the top (because there is no impedment by irrelevant externalities(sp?)) - if BeOS's features have merit, and they are implemented in GNU/Linux, then they will have a home.

Implement the best features from each OS, and invent your own where applicable.

I'll list a few examples of great features from various OS' along with some features of my own, and why they should be implemented in the BlueOS or OpenBeOS projects, and any other projects which want to create a great, fast, reliable OS:

1. BeOS' "tab" window bar, which doesn't span the entire "length" of a window. Why should the window tab span the whole length of the window? That just takes up extra space. Have the close, the maximize, the minimize, and the "barrize" buttons in a tab. Have all these features automatically "display" when you move your mouse over the tab; otherwise, have the name of the app. and file displayed. Furthermore, make the "tab" movable accross the length of the window. This allows you to "semi-maximize" all your windows such that their titles display in tab form accross the screen. Should able to be pulled up by keyboard commands, and navigated by keyboard, as well as mouse.

2. Apple's "universal menu". Why have a menu in every window? That just wastes space. The argument could be made that its inefficient to have to move your mouse WAY to the top of the screen for a small window, but you can always make it so users can "retrieve" the universal menu to their specific window, or send it back to the universal position, for each program. Furthermore, the universal menu should have the option of "auto-hiding" away, like Apple's "warf" or Win9x's "task bar". Should able to be pulled up by keyboard commands, and navigated by keyboard, as well as mouse.

3. The desktop. This is a BIG DUH. Though task-bars and warfs are nice, having icons on the desktop is still a must; it should at least be an option. But the desktop shouldn't just be complacently left alone, it should be improved. People should be able to make desktop regions, so when they "auto-organize" icons on the desktop, some will stay on the bottom, or top, and others on the left/right side, rather than all being automatically placed on one side. Should able to be put focus on it by keyboard commands, and navigated by keyboard, as well as mouse.

4. The warf. Another duh. Apple's or OpenStep's version is a great implementation. It should be scrollable, and should "hide away". Having icons or icon names "enlarge" or change color as you move over them should be an option. Should able to be pulled up by keyboard commands, and navigated by keyboard, as well as mouse.

5. The taskbar. Not that its completely original, but it is a nice feature in Windows. Having all the application titles appear in boxes, and having a customizable start menu with lots of neat features is nice. Also, having an address bar in the task bar is nice. Of course, the management of displaying window names should be improved, and task bar should allow you to scroll left/right or up/down rather than "shrinking" down the boxes when many windows are open. Should be hide-away.

6. Apple's new "file browser", Cocoa or whatever its called. Of course, its not new, but just a pretty skin of NeXT or OpenStep's file-browser. But the new folders displaying to the left of the old one's and scrolling right is nice.

7. A throwback. F1-F12 as FILE MENU KEYS. Alt-F for "File" as is typical in Windows and Linux, or no key-control for file menu's as is typical in OSX is CRAP. The KB is quicker for accessing file menu's than the mouse, but why should we have to press TWO buttons to access the file menu's? Also, it means we always have to look at the "underlined" letter to see which letter we have to press in combo with Alt. It would be much easeir to just ALWAYWS have F1 representing the first menu. This standardizes it unilaterally.

8. Right-clicking (Win9x) and "hold-clicking" (OSX) to get the "options menu". Great features. Should be combined. On a two-mouse button with a "scroll button", there should be a function for a left click, one for a right click, one for a double left click, for a double right click, for a hold on a left click, and for a hold on a right click.

9. Space-saving by dissapearing buttons. One great idea which might actually belong to Windows, though probably not (just I first noticed it in a MS Windows program; note, I said !might!, so don't jump all over me). Anyways, the feature is in the Windows DVD player that is part of Windows Media Player (just go to Xteq, and click on "enable DVD functionality" under Windows media player, fyi). When you watch a DVD, the buttons for play/forward and all the others are initially visible, and look normal (though small). Then, after a period of inactivity by your mouse, they dissapear. A nice feature! When u move the mouse again, they reappaar. This saves space on your screen while still having all the functionality, and gives you more room for your actual work. I think people should explore implementing this strategy accross many different applications, from browsers to word processors to image editors.

10. The "between space". Most of you are probably in front of a graphical web browser now. It probably has buttons at the top of it, with forward, back, stop, home, search, favorite, and history functions. These buttons probably have a "grey space" between them which serves no purpose. Why have useless space between them? Why not make it transparent to the underlying content of the window, with the buttons as opaque layers on top of the content of the window? This can be combined with #9.

11. The UNIX power. Ok, this is broad. But what I mean by this is the vast vast vast vast array of command-line commands you see in UNIX-like OS' such as IRIX, *BSD, and *Linux. This is a feature all OS' should have.

12. The UNIX-stability/security. Again, obvious. But should be pretty self-explanatory. Unices have a reputation for being stable and secure.

13. The hardware/software support of Windows9x. This is something easier said than done. It basically happens over time. Linux is getting there, so is Apple. This would be a factor totally based off the quality of the OS, were not MS a monopoly. But, as it is, no good deed by companies competing with MS goes unpunished; no vile deed by MS unrewarded.

14. The ease of use of BeOS, Amiga, and Apple-OS. This is another general feature. But these OS' are widely reputed as being easy to use. I believe its because of the KISS (keep it simple stupid) philosophy. Of course, Apple has standards almost set in stone for GUI's. But as some simple guidelines, always consider what the function of your program is, and if extra features aid in that function? Does that neat-looking (self-promoting) logo in the corner really serve any useful function? Or is it just eye-candy, something to be shown off in screen-shots? Make sure every graphical feature, button, whatever, in your GUI/apps has a function, and aids in ease of use as much as possible. In short, critically evaluate everything.

15. Condensing functions. Condense the functions of several related buttons into one button. I.e., I created a nice, efficient, easy-to-use system for media-player buttons. Have a play/fast-forward/next-track/next-CD button, a reverse/rewind/previous-track/previous-CD button, and a pause/stop/eject/open button. In each case, the first function listed would be done by single left-clicking; the second function, by holding a single left-click; the third, by double left-clicking; and the fourth by right clicking. This allows you to compress what would be 9 buttons into 3 buttons. More efficient, easier to use (as less hand-motion, and more intuitively like an MP3-player), and less wasteful of space. This would be, of course, combined with #10 and #9.

16. Load-time, run-time, RAM, and hard-drive requirements. These are all the performance-related issues. I believe a few distinguished OS' represent excellence in these fields: IRIX, BeOS, Amiga-Classic, Amiga (the new Amiga), QNX, *BSD, and some Linux' (i.e., Slackware, Debian). The reason for such excellent performance offered by these OS' is a combination of factors: efficiency, minimalist philosophy, innovative architectures/ideas, etc. I won't go into details, but sufficed to say, developers should be considering factors such as HD-size, load-time (ESP LOAD TIME for most apps, nothing worse than waiting for ever), RAM (another biggie, don't want the OS taking up half of my RAM), and run-time (a biggie for apps which do any serious crunching, such as phylogeny apps, or DNA alignment apps). A comparison of various OS' in terms of tech-stats can be found here: http://maxlinux.hypermart.net/comp_chart.htm. It can be observed that IRIX wipes the floor with everything else in every category. 9 million terabytes as max file size?

17. Transparent features. This one's a bit touchy. It shouldn't be over-used. You need to be *very* selctive when using this feature...but it can be great for certain apps, like terminals or word-processors (Office products, Vi, Emacs), and for certain parts of apps (like configuration boxes, occasionally). Obviously, its idiotic to make the material of a web-browser or image-editor (semi)-transparent.

18. Aqua/glassy/smooth/gradiated stuff. Obviously, MacOSX has a great-looking GUI. It isn't just eye candy -- it really helps you easily distinguish features from one-another. Lets not give Apple too much credit here. They just "heard" what the consumers wanted. Everyone likes gradiated stuff, which is smooth. There was gradiation and shinyness long before OSX's Aqua theme.

19. Now, an annoying, but *sometimes* useful feature. "Animation" effects on menus or windows. I.e., a menu "scrolling" into place, or window fading away when minimized, rather than doing so instantaneously. All such effects should be quick, should be such as to indicate what's happening, and should be configurable and deactivatable.

20. Plug & play, automatic hardware recognition. Another DUH. Windows and Apple have accomplished this to near perfection by sheer brute force. QNX has a more clever method, which involved some kind of "detection algorithm" to detect hardware and optimize the OS to it. I think this is the way to go. I.e., have the OS "search" for say a graphics, CD, CD-RW, CD-DVD, DVD-R, printer, speaker, sound-card, networking, etc hardware. Then when it finds the (say) graphics card, let it explore various values of that card in a conservative way (starting from very low values that won't mess up any hardware) and gradually working up, using some benchmarking and stability tests to find the optimal settings.

21. Cross-platform compatability. Amiga has achieved this by using VP Assembly; thus, their OS can run on virtually any hardware. You need to bite the bullet on this one. The initial "performance" decrease may be compensated for by less overhang because the stuff your loading from the HD is smaller...furthermore, just improving ONE part -- the virtual machine -- increases performance of everything everywhere. Also, the "performance" u might initially lose is moret han made up for by the additional efficiency you can put into it by having more time to work on better algorithms/smoother interfaces, b/c u don't have to port.

the window in screenshot #2 [blueos.free.fr] has the exact same selections as the screenshot from three months ago [blueos.free.fr]. I certainly hope it is coincidence. Note this isn't just preserving settings; the older screenshot was proviced by an outside source.

Then why wasn't it designed as a toolkit for X, or as an X alternative?

See above.

Was BeOS supposed to utilize SMP better by dividing applications into more threads?
Then why wasn't it designed as an application framework?

Out of interest, what do you think an Operating System is, if its not an "application framework"?

Was BeOS supposed to have a revolutionary OS design?
By still using file systems, giving no thought or insight to security, and a Unix-like model in a new OS, I don't think so.

If it was a Unix-like model, why didn't they have any security? How do your organise your data if you have no filesystem? Hint: Even if you use some fancy relational database, you still need some way of otganising the data on the physical medium. In other words, a file system!

An Operating system is software that manages physical computing hardware and provides interfaces to that hardware for application developers.

An apps API is not an OS.

Also, a filesystem is not required for an database. An RDBMS can just access the hardware itself directly (like Oracle can).

The guy's right: "What were they thinking".

An system is only as valuable as the size of it's userbase. Be should have done anything and everything to expand it including the distribution of OpenStep-esque variants that could run on top of other OSen and not be subject to device driver limitations.

Users running BeOS in crippled mode are better than not having those users at all. Besides, the compatibility API could have been an easy teaser to give people a small taste of the real thing and motivation to try the real thing.

No, an OS is what "runs your computer". Libraries are API's. You don't create a whole OS just to provide a new API, because' that's just stupid.

And by a file system, I mean a global namespace, a string-hierarchy to manage all of the system's objects.

This global namespace disallows confinment and security, and instead, you could use the revolutionary EROS model of orthogonal persistence to persist your objects and simply have capabilities to those objects spread across the specific processes that use them.

A global namespace as used in Be is just wrong both in terms of security and simplicity, Orthogonal persistency is much simpler.

As for "See above", that was simply moronic, they can write an X replacement to run at least as well on Linux as it may run on Be, the Linux process management and driver code is at least as good and even much more "fixable".

Frankly, you're talking out of your bottomside to make yourself seem like you have a clue, you don't.