Slashdot Mirror
Be-Alike: BlueOS Uses Linux For Its Kernel
OSBlue writes "A few days ago, news emerged regarding the OpenBeOS project, while now there is more information regarding the other effort to 'save' BeOS, BlueOS. BlueOS uses the Linux kernel 2.4.12 and Xfree as as the base of their OS. For now, they are building a BeOS look-alike Interface Kit and BeOS app_server on top of XFree, so it is not just a simple window manager, but a whole new API and environment. In future versions, the BlueOS team will completely bypass XFree and have a stand alone BeOS compatible app_server which will only use some of the XFree's system calls to be able to use its 2D/3D drivers. Guillaume Mailard, team leader in the BlueOS project gives more information in an interview to OSNews."
Um, points for not having even read the *summary*?!??!! I mean, I'm used to people not reading the article, this is slashdot, but to miss the title of the article and the summary is probably some sort of record. To summarize the summary:
BlueOS is implenting the app_server *on* *linux*. As in, within linux, you will be able to run beos programs. I can't think of any other way to make it simpler, so I'll leave it at that.
And if I seem cranky, it's because I am. Stupid headache.....
I dono why they are bothering with this.
A better project for them would have been to write a new BeOS like API to replace X and wrap over Linux.
I have a little concern that BeOS and AtheOS are both going to suffer the same problem. By not using CORBA or COM, they gain in simplicity, but C++ linkages are just not stable, especially with respect to future expandability and changing compilers.
Gentoo Sucks
In fairness developing such wrappers would give developers a very nice working environment but the original benefits of BeOS would be lost.
Somehow I don't think this is gonna fly.
Your pizza just the way you ought to have it.
So every BeOS application will have to be ported to this Linux/OpenBeOS project. And then ported again on the next non-x version of OpenBeOS? Whats they point? Why not just help finish the DirectFB and then keep everything native on linux. X is not as fast as a framebuffer, and BeOS was known for its video editing abilities.
M$ finally dropped dos, lets drop xwindows.
DirectFB was discussed a few days ago on Slashdot in case you missed it.
Is it BlueOS or BlueOS Linux?
Or perhaps Rick Stallman might suggest GNU/BlueOS? GnuBlueLinux? B.I.L.? BlueOS Is Linux
Now I have a headache.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
...Make an OS layer of some kind that multimedia developers can get behind.
The number 1 problem with the Linux OS, at least as far as I'm concerned, is that multimedia developers cannot fully support Linux. Each and every one of use has to dual boot to get anything done. I long for the day that I can truly be well and gone be done with Windows. For a long time, it seemed like BEos was the way to go, but then BeOS went Belly up and sold off to sony to keep from dying.
Well, here is a tired Windows/MacOS/Linux user who is tired of dual booting. Please make OpenBe what we can all look forward to in the way of multimedia OS.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Pasted the wrong url for the DirectFB article on slashdot.1 4&mode=thread
http://slashdot.org/article.pl?sid=01/10/23/12522
and sold off to sony to keep from dying.
:)
You mean sold off to palm...
sean
Now, with these new Beos clone projects starting, it's conceivable that in time I could migrate over to using one of these OSes (I personally lean towards the OpenBeos project), at least part time. The idea to use the Linux kernel is probably a smart one, although as someone on osnews.com commented, it sounds kind of "messy". I bet they'll have something usable up and running a lot sooner than OpenBeos though.
I've played around with Atheos as well, which borrows ideas from Beos, but the source code looks kinda ugly, and the development is tightly controlled by one person. I can't feel at home on an OS like that. It's a neat project, but only time will tell if it amounts to anything really usable. I wonder the same about these Beos projects.
You had me at "dicks fuck assholes".
Why not just help finish the DirectFB [directfb.org] and then keep everything native on linux.
*cough*
Not to get all flamey, but this project gives me somewhat of a bad taste in my mouth. I understand that Linux is the main driving force in the open-source world today, and that many current open-source projects are being actively developed by Linux users for Linux users. I am very thankful that many of these folks choose to make their works of art (software) portable to other Unix systems.
However, Unless DirectFB can be emulated somehow on non-Linux systems, the amount of Linux-centric software which will not be portable to other Unix platforms may begin to grow (depending on the popularity of DirectFB).
Right now, I'm very happy with portable X-based tools such as LyX, Gaim, and Mozilla - to only name a few. Without Linux, I beleive these projects would not be as popular as they are right now. As soon as projects like these that provide such useful functionality come to depend on DirectFB, I will be very disappointed if I am unable to run them on my choice of OS - which very often does not end up being Linux.
So anyhow, after this extensive rant, I hope I am not the only one that is a bit weary of DirectFB becoming the de-facto standard of newcoming Linux graphical application developers.
Can't really get excited about this, Be and Linux are two very different beasts, with almost opposite strong and weak points.
This sounds like just another X11 "desktop environment" wrapper.
I'd rather see someone attempt to implement an open, binary-compatible BeOS kernel, and display layer.
Yeah, it'd be a real bitch of a project, but it'd be super l33t.
But I'm sure something like that would be possible if the "open source" community would
stop writing more goddamned window managers for once.
Oh, yeah. Before you pledge your support, take notice that this project is NOT under a BSD or GPL license.
It doesn't even sound like they're going to release the source to world+dog at all.
M-X Bitter-And-Jaded
hmm, just how many UNIX operating systems do you think will be comercially viable in 5 years? How about 10?
X is a big reason for them all to die. For that and other reasons they are dying.
Linux should not follow them down that dark path. If Linux survives by cutting loose the boat anchor of X and hastens the demise of proprietary Unices, so be it -I say AMEN.
If *BSD cannot implement the same fb layer then it couldn't evolve fast enough. So be that, too.
For example, every single GUI element of a BeOS app is at least 1 thread, possibly more...
:)
:-)
No, every single BWindow has its own thread. All GUI elements in this window are controlled by the window looper. Of course you can spawn additional threads per window, but it's not as horrible as you sketch
Linux was not designed to create and destroy such a large amount of threads so frequently.
It wasn't? Who said this? It sure does rock then for a system that has supposedly slow thread creation. I just wrote a tiny app that spawns 1000 threads in less than half a second. That's should be enough for the things they want to do. I can't imagine anyone creating more than 1000 windows per half a second
How are you going to deal with this problem?
Apparantly this is not a problem at all!
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Almost all unix users, linux users, as well as developers that work directly with the X API, are disgusted by the complexity of X. X is nice because I can connect across the internet to it, but the X11 protocols for doing that are no faster than VNC. It's compatible with X Terminals, but they are all gone now save a few that could be replaced for 200$. The configuration to support accelerated video, USB mice, and anything else, is all done in one nice file that requires an experienced X user to fix if something goes wrong on auto detection.
:) Ahh, the mother test. Its harder than the turing test. Linux isn't ready for the desktop until I can teach it to my mother. Now I have hope that she'll still be able to see the monitor when that day comes :) (Reaching into my big basket of dreams and optimtism...) Maybe they can make an interface thats as easy to use as the Mac is noted to be, and handles fonts and media in a resonable way.
This leaves me wondering why X still exists. I would be extremely happy if the BlueOS team could implement a replacement for it. There isn't a concievable way that it couldn't be better than X. I was kinda disappointed that they were gonna start with X. They could probably replace X quicker than they could learn and develop for it.
Maybe, they can make an interface worthy of teaching my mother
Karma Clown
XFree would probably run faster than DirectFB would simply because DGA and Xv get to use video card drivers that recieve much more attention and are consequently better tuned.
/dev/fb*.
That's a very narrow view. Who knows what the future holds? Currently XFree86 gets lots of attention, while Linux Framebuffer drivers do not. There is no reason this can't change.
I do like the remoteness of XFree, but other aspects are just plain bad. The most obvious problem with XFree is the inclusion of drivers. Every other driver I use in Linux is controlled by the kernel -- except for video. Why? There is nothing special about video that requires it to be separate. I should be able to just "insmod video.o" and install the driver. Fortunately, that's what the Linux Framebuffer is trying to correct. Video access is controlled by the kernel, and the display is served up on
This would ensure longevity in drivers. Right now, if we were to abandon XFree86, closed source X drivers would become worthless. This is why writing drivers for X is senseless. They should be written as kernel modules. This way, our display system is irrelevent. It could be DirectFB, X, or anything, and the driver stays the same.
The Linux Framebuffer also solves the permissions issue. To run an X server requires root access (so the executable is setuid root). The Linux Framebuffer, on the other hand, has permissions like any other 'device' (just chmod it) and you don't have to be root to use it! Yay! Maybe this fixes some security issues too? The Linux Framebuffer obsoletes svgalib in this regard as well.
Really, the Linux Framebuffer only brings good things. About the only counter to this argument is that not all other *nixes have framebuffers, and so it is the job of X to provide this. And to that, I say: Wrong! Time for these other *nixes to evolve. Linux should not be dragged down.
Please, move all driver development into the kernel realm, and call XFree86 finished. The only new things coming out of XFree are video drivers which have nothing to do with the X protocol anyway.
In short: X should not die, but X video drivers should.
Is anyone aware of other OS project using the linux kernel but without building a unixlike environment on top of it?
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
"I'de advice all beos users to sitwh to macos X because you'll find in this os every thing you liked in BeOS." I will? So does that mean MacOS X runs on cheap hardware? nope Does it boot in 20-30 seconds not likely Is it incredibly fast and responsive? Not what *I* heard Is it very easy to use yet very powerful? Ok, granted, it probably is Will the apps start in a split seconds? not if I am to believe the reviews Does it have a very friendly and open community? I wouldn't know So will I find everything I liked in BeOS in MacOS X? Not likely
I agree with this entirely. I honestly think that X should sit on top of the frame buffer, and I see no reason why it shouldn't. You could still have the X protocol that allows everything we know and love about X (network transparency, lots of apps, etc) and dump the stuff we hate (the drivers, suid root, configuration, "slow", "bloated").
X as a protocol should be separated out from actual hardware level display by having a single X server make all the kernel calls. As you said, hardware interface should happen only at the kernel level, and the fact that it doesn't currently is really poor design. There's no reason to chuck X entirely, but to remove many of the dependencies that we have on the XFree project would be a major bonus.
I think the reason for all this X vs. FB bickering is that people are forgetting that X isn't XFree, and that we can have our cake and eat it too by simply breaking up the tasks that XFree is responsible for. XFree is so huge (not bloated, just big) that it's overwhelming. Small is beautiful is the UNIX philosophy, and the fact that so much revolves around X is a major break with that. Putting the hardware where it belongs will clean things up to a major point. I think this needs to happen, and I hope it does. It'll be a major shift for everyone, but it'll be worth it.
"I may not have morals, but I have standards."
move all driver development into the kernel realm, and call XFree86 finished
This is what MS did with Windows NT. This is what caused all those blue screens of death when a badly written video driver went wonky.
The kernel hackers seem to have a rule: if it can go in user-land, keep it in user-land. This allows them to keep the kernel, upon which everything else depends, simple (to them anyway), stable and reliable.
Of course, there is a point where the benefits of centralisation surpass the drawbacks of complexity. Perhaps DirectFB reaches that point, but your arguments don't convince me.
Your main argument seems to be about inclusion of video drivers in X. You don't explain why that's a problem. Perhaps you could.
I solve the "permissions issue" by running GDM from rc2.d.
Yours Sincerely, Michael.
Are those who want to do this project seriously interested in the actual things that made BeOS unique (the kernel, the threading, filesystem, etc).. or do they just want to replicate the 'look and feel' because they like it.
BeOS was about more than look&feel... it had some really cool things going on under the hood. Using the linux kernel & Xfree as a base.. doesn't sound like they are really going to bring much to the table, other than look&feel, and a way to compile BE apps (big deal... most BE apps were ported FROM unix in the first place)
Actually, I think most of the criticism of X is due to highly limited protocol specification - I mean you don't have alpha, only 1-bit mouse cursor and stuff that was undestandable year 1985 but not today. Sure, it has extension protocol and that's pretty much all we run nowadays if possible. This is pretty much the same thing as with OpenGL right now. You can do all the stuff with the officially supported protocol, but you really want to use all those extensions to get yourself off the ground. To say that X as a protocol is the way to go is obviously wrong. Creating a fresh protocol for network transparent windowing is the way to go - for example Berlin shows a great promise but seems to take eternity to complete. Hell, you shout out loud when we see another x86 compatible chip how we should drop backwards compability for better ISA and in the same time you don't want to drop ancient API to get better results. It's only software for Pete's sake.
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
Yes.. you can use the kernel to build a totally different user environment.
But.. the thing is... when people say 'Linux' they mean the common group of unix-like systems based on the Linux kernel. You know it, I know it, everyone knows it.
This is like trying to argue the meaning of the word 'Hacker'. Words mean what people take them to mean. Get used to it.
Ohh. And Linux has always been referred to countless times as 'A unix-like operating system aimed at posix compliance'. If that only brings to mind a kernel.. so be it.
I agree. BeOS was lightweight, quick-booting, and, as you say, smooth, quick, and responsive. Attempting to build a BeOS clone by starting with Linux is like trying to create a supermodel by dressing up Rosie O'Donnell.
Every 3 years, Microsoft "rewrites" the Windows API and adds it into a new version. Windows XP supports the Windows 3 API, the WIN32 API, OLE, COM, and .NET. This is the entire Microsoft strategy of constantly offering newer APIs to strengthen the OS. The disadvantage is that it becomes increasingly bloated. But maybe it is about time that Linux have the very clean and modern BeOS API added on top of it. By merging these two OSs we could obtain the strength and stability of *nix with the cleanly object-oriented design of BeOS.
At the cost of performance.
1. X Window System (not "Xwindows")
2. Migrate Linux users to DirectFB, lose interoperability with the rest of the open software (a.k.a. Unix) world.
3. X is not necessarily slower than a framebuffer, it depends more on the driver than on anything architectural. Even for 3D Nvidia's driver gets X to within 1% or so of the Windows FPS rates. DirectFB with the same driver implementation as X for each type of hardware will end up with more or less the same performance for each card.
Some people use X as a scapegoat for everything... Yet it's fast (with good drivers), it keeps adapting (anti-aliasing, dga, xvideo, xtt, etc.), it's network-transparent, and it's a long-standing standard that is open and interoperable. It should be a model for open software longevity, rather than a whipping-boy for Linux's hardware support shortcomings.
STOP . AMERICA . NOW
This argument may be a good one, but can go either way. There is no denying that there are benefits to being able to use a single X server to get at a kernel-based framebuffer.
However, I also cannot name the number of times I have been able to ssh from one workstation to another which has "hung" and type:
killall X
and "rescue" the unresponsive station from a power cycle. This has happened with a number of different types of graphics hardware. Had those video drivers been in the kernel, there would have been no choice but to hard reset or power cycle.
Not everything should be in the kernel...
STOP . AMERICA . NOW
I will admit that there is some complexity to video card drivers, in that there are both 2D and 3D drivers/APIs for many cards. But I don't think all graphics should be pushed into user-land. The fact is that with modern boxen this is an integral function of the system.
Note that I would still not like my box to hard crash when XFree goes down like a 2 dollar whore, if at all possible - but if the interface is well designed, I don't see why a crash in user land (X window system) would pull down the driver in kernel land.
As for sufficient justification - no matter what you here from the crusty old *nix gurus floating around here about how modern X implementations are really great, the fact is that XFree86 still sucks, though in version 4 it sucks somewhat less than it used to. 2D rendering is still slow (relative to what I expect from Win2k - not terribly slow with a fast box, but slower than it should be), configuration is still complicated and the X extensions like Xrender are just NOT well integrated into the framework - if you don't understand what I'm talking about look at how many different places font settings are stored on your box if you have Xft enabled and anti-aliased font rendering under KDE.
The fundamenal problem is that as long as there are less than PIII/Athlon/GeForce boxen around, people will want to get around X because it's too slow, and projects like Linux FB and DirectFB will flourish. If we could just unify the Linux video card driver work into one place (kernel modules) and make XFree a cleaner system that works on top of it, I think the world would be a better place.
This is more of a reply to various comments about non-X systems and how they would have to reimplement every device driver. However, with XFree86 4 all device drivers are modular with a very well-defined API - what's to stop an X replacement from simply reimplementing X's driver loader and then using XFree86's drivers in the first place?
:) But I'm just curious.
Of course, this still ignores the fact that there's nothing inherently wrong with X anyway
NT got destabilized because MS put the entire GUI in kernel space. Nobody is suggesting Linux do the same, they're suggesting that the graphics driver (which is much smaller and simpler) be put in kernel space. To tell the truth, BeOS did graphics best. The low level driver code was put in the kernel, while higher level acceleration was put in a userspace module. This meant that the graphics driver had the control over the hardware it needed (thanks to being in kernel space) and graphics calls were very fast (since most of the code was in userspace and thus no system calls were needed). NVIDIA adopts almost exactly the same architecture on XFree86. There is a kernel "resource manager" driver module to bang interrupts and such, while the majority of the rendering code is in module loaded into the X server.
A deep unwavering belief is a sure sign you're missing something...
Actually, XFS is faster than BFS, and has more features to boot. BFS is great because the system on top of it used its capabilities so well. Nothing prevents Linux desktops from using XFS the same way.
A deep unwavering belief is a sure sign you're missing something...
Because X will always remain the fastest GUI on Linux, if only for the sole reason that that's what NVIDIA writes their drivers for.
A deep unwavering belief is a sure sign you're missing something...
Quote 2:
"The main reasons why I don't like Linux are the non-flexibility and the "chaos"."
If you don't like why do you use it?
>>>>>>>>>
I think he is making the distinction between Linux the kernel and Linux the OS. Linux is a great kernel. It is a sub-par desktop system.
Quote 3:
"For "performance" addicted people, a version of the app_server which will only use the XFree86 drivers will appear on the BlueOS v2, it means that BlueOS will not use the XServer anymore!"
I'm quite interested how he will do this.
>>>>>>>>>
XAA is the new X driver architecture. Its nice and clean, and any windowing system should be able to load X drivers and use them (in theory).
A deep unwavering belief is a sure sign you're missing something...
The Linux kernel, and XFree86. They've just lost two of the cool things about BeOS. Does this thing run on ext2? If so, that's three things.
Applications are not exactly BeOS' strong suit.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
So now we will have a new version of Linux that can run BeOS applications -- most of which were ported from Linux.
Don't get me wrong. I'm a BeOS fan and have purchased the last two commercial versions. I'm sad to see it end, but you have to know when to admit that it's over.