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."
Improving linux and its support for the beos rather than create an entirely new set of useless binarys. Why not just make an app server that can run on linux?
They would probley like the fact that then they could be used in the bsd compatibility layer. That would open up their user base for all beos apps by 10 fold! All linux and bsd users (not to mention people that use a Virtual PC set up to run linux) could use this very easily, much like wine. I don't see a point in working for an os that is just going to die like the beos did. Don't get me wrong, I still *run* the beos on a first gen be box BUT I would rather have beos support on linux, than no beos without all the benifits of linux.
"Not my manner of thinking but the manner of thinking of others has been the source of my unhappiness." - M
So is this going to be a Linux fork or just a very specialized distro? Interesting though.
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
What are the legal ramifications of this? Now that Palm owns Be, will they go after the theme makers, ala Microsoft and Apple?
SIGFEH
is that this will be a sweet merge between linux an BeOS. The more mergers and collaboration between software developers, the better.
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.
At first, I was rather pleased with the decision to use the Linux kernel. It has proven itself capable, and is definitely capable of being cusomized to do a job well. Perhaps HURD would be better for the Be-architecture standpoint, but it's not far enough to really be basing entire other projects on it, IMHO.
On the other hand, I dishearntened to hear XFree was going to be used. X is notoriously bad at pretty much all the things Be could do well. Then I read a little more and realized X is just a stepping stone on the way - it provides a stable, well developed point to work with for now while the other APIs are fleshed out.
I think this approach will work well for the project - it allows functionality tobe put im place first, while it is abstract enough to replace most of the low-end without problems later. I hope the best for the project, and I'm excited by the recent number of BeOS-related OS projects. I hope one (or more!) of them get(s) to a truly usable state in the near future.
± 29 dB
BeOS was great because it was smooth, quick, responsive, and different from other OSes.
Now these developers have opted for (surprise surprise) a Linux based system.
How many OSes need to be based off Linux? It seems these days someone gets an amazing idea for a new OS, and instead of working from the ground up to realize it, they just decide to make another incantation of Linux.
Seems there are all these projects going on now for new "alternative" OSes. I can't think of them as an alternative when it's still based off Linux. So much for being creative or original.
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
yet another pipedream of resurrecting something that isn't going to be.
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.
The BeOS was designed to do thread switches extremely quickly and the Kits are built around that fact.
For example, every single GUI element of a BeOS app is at least 1 thread, possibly more...
Linux was not designed to create and destroy such a large amount of threads so frequently.
How are you going to deal with this problem?
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
Using linux as a kernel...wow that is cutting eadge and innovative. X as the window manager?!?!?! I'll bet this is super fast....
I used to work for them in the eighties, way before that swedish guy Thorvaldsen took over. The managers would distribute free beer as a bonus. It was great fun.
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.
BeOS doesn't really have any apps anyway, so porting isn't a problem ;-)
Are you a troll or a moron?
X is a great piece of technology that was superbly designed 10 years ago and is doing quite well. X offers more features than any other windowing environment, *and* has backwards compatibility to apps written 10 years ago, and does it all without sacrificing performance.
Moreover, X allows one to do things like choosing window managers and desktop environments, doing what it does quite well.
In short, shut up with this anti-X crap. You're stupid, and shouting down great projects doesn't make you look big, it just makes you look like the pathetic looser who's never administrated a system or coded a line of a gui program in your life that you almost certainly are.
In short, please help the community of rational people to drop you.
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
You obviously have no clue. X is NOT Bloated. X is NOT slow. X is not a big mess.
In fact, most criticisms levelled at X are actually criticisms of some ancient X reference implementation that's years old, that modern XFree 4 has relatively little in common with, since it's modular rewrite.
Because DirectFB is a pointless hack. If implemented correctly(ie, not reliant on any X protocol stuff), such a BeOS wrapper for 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.
I don't really check up on these things much, but just how fast would a nVidia card run without their closed source drivers? Also how about 3d acceleration with any other card? X integration would do much for its 3d capabilities.
M$ finally dropped dos, lets drop xwindows.
M$ has yet to drop DOS, it still seems to be in WinXP after all. They simply replaced pure DOS with something that could do everything it can (including run DOS) plus some extra crap. Any X server supporting DGA or Xv can do everything DirectFB can, but can DirectFB do everything that X can?
Linux is, by definition, a kernel. Most of the software that runs on the Linux kernel is Open Source software. Most people confuse open source with linux, but the two are actually very different. So, I conclude that BlueOS isn't BlueOS at all, its linux; no different then RedHat or Debian.
Given the large current install based, much of what exists now will still be in use in five years. In ten years, you'll still have systems like AIX, Solaris, and probably HPUX. The trend to consolidate towards linux will likely die down now that linux has demonstrated that it won't be making money for anyone in the future. Unix isn't dying; it is and has been evolving over the many decades of its existence. It won't die in the next decade, and neither will X. X is a network protocol; it's hardly a boat and anchor. It has provisions for expansion and evolution, and it has and continues to do so. That unices tend to rely on the use of XFree and the like for display drivers as well is merely a technicality. But if you want to compare the irrelevant, you are free to look at just how much more video hardware is accelerated by X servers than the framebuffer. While you're at it, let's see you get that precious hardware accelerated OpenGL, too. The DirectFB project's goals don't even align with the removal of X. They want a simple, small environment for being able to bring graphics to portables, and to refactor the acceleration out of the X server. All noble goals, but that's not to suggest that every project should dump X (pointlessly I might add) and go through the process of direct, raw DirectFB access. On the other hand, it's also not a bad idea for general interfaces (X, GTK, Qt, ...) to have backends for direct access.
The real main strength of BeOS is its very good kernel, excellent multi-processing ability, its Filesystem and multimedia ability. I think that if someone really wants to save BeOS, save the Be Filesystem first.
I completely agree with you, the other guy is an idiot. After all of the smoke I see pro-DirectFB people create, I have not yet seen even some half-assed benchmarks. I think they got that idea from here. Ok, fine, they have an "xwindows" port. All it seems to me, is that they are re-inventing the low-level drivers that are included with "xwindows". I like the M% finally dropped dos, lets drop xwindows comment. Suprisingly, there are only two things wrong with that statement. The first problem is that M$ finally dropped dos is not a valid argument for lets drop xwindows. I'm not sure if they did drop DOS, but I think they probably did. However, why does that mean that "xwindows" should be dumped? Because Microsoft dumps an old product, that means that "we" have to? Microsoft likes to say they same thing about UNIX in general. They say it is just "old technology" and should be dumped.
Factoring all of the display drivers used by unices ten miles away from the X server isn't a bad thing. Of course DirectFB does pretty much jack shit, though, because it has a handful of accelerated drivers and only one of them is of any quality, and that's for ass-Matrox cards. w00t. ...).
The concept is a good one, though. Linux and the BSDs should move toward a unified framebuffer and have XFree backends to utilzie them. This code should be usable by things not tied or related to a X server, even if in the general case software will still be written for either X, or one of the toolkits that currently has a X backend (Gtk, Qt,
It should just as equally provide a system of access for OpenGL, and a unified means of dealing with input devices. Really, what the KGI/GGI people were striving for, but failed to accomplish because they were too busy flaming X and working on Bloaty Berlin to ever get anywhere worth being.
This is a very good idea. They are doing a great job of getting accelerated drivers. Also, I think it would be very easy to port opengl to it as well. all of opengl is in libGL and libGLU. The window creation and manipulation code is in glx, which can probably easily be recreated for directFB. It would also be easy to port to other operating systems, because all video cards have a framebuffer. You could probably keep the closed source nvidia driver and still have hardware 3d acceleration, but you'll still have to write the 2d for nvidia if they wouldn't.
However, they would rather be creating a GUI/wm for DirectFB more than DirectFB. It would be nice to see DirectFB used instead of X to begin with. They might even decide to keep it that way so that it could be easily ported and the driver database kept current.
Karma Clown
superbly designed 10 years ago
10 years ago? Who's the moron now, fuckwit?
You all know it is true.
I think this project is another one of those that briefly appears n slashdot then dies, never to be seen again.
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.
I used to have a falcon030 and saw the death of Atari and all the survival things that went around this death. I then Got myself a bebox (I tsill own one has well as an original Hobbit Bebox), and played with beos for 4 years. I was for the upcoming of the ppc platform. I've ditched beos because of Be and its lack of support for their user's base and their lack of long term visoin, they never should have switched to BeIA without releasing version 6.0.
There's already 2 projects, one which is OpenBeoS hosted on Sourceforge and BlueOS. BlueOS aims at speed because the don't rewritte everything.
I think these project are loosing precious developers time, they should help the only saving project that looks worth it the one hosted by beunited which aims at obtaining a license from Palm for beos, to develop and upgrade it. They simply could help by creating application that will help the os, because the big problem for beos is it's lack of applications. The Authors of blueOS was writting Eden an Image manipulating program - he is now spending time on an OS layer and applications for that os layer won't be available when that layer is.
What I like about beos was, the UI+CLI, the ease of use of its OO programming API.
I've now found the same thing in another OS, and with that OS I can find commercial software, I'de advice all beos users to sitwh to macos X because you'll find in this os every thing you liked in BeOS.
none Yet.
Stupid troll.
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.
But if Palm didn't buy Be for their OS then what, exactly, did they buy? And why? It seems like a lot of people got screwed in the deal and that every piece of Be technology that anyone interested in the company cares about is going to evaporate. What are Palm's plans? Why spend the money? Is there some good reporting around about what's going on?
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.
Won't this suck to much resources if it using the Linux Kernel and Xfree?
I thought one of the points of Beos was to run on minimal hardware with a microkernel and everything?
I would like to see more support for QNX. I've been toying with it, and if it had support for my laptops Yamaha/opl3 soundcard, I might actually switch completly over to it.
How is this anything other than linux? It might not be GNU/linux, but if it has the linux kernel, AND XFree, it IS linux, not a new BeOS. Give me a break.
-- "Perceptions create reality. By changing your perceptions you change your reality."
What a waste of time and development energy! Who needs yet another OS?
I am very happy to see someone else realize that Linux != GNU/Linux. i.e. the Linux kernel is perfectly capable of supporting any user-space environment you care to create, not just the standard glibc + GNU utilities. (yes this particular project is building on glibc/XFree, but you get my point).
I was very disappointed to see a lot of earlier OS projects (including the other BeOS-based ones) starting from scratch with their own kernel. This is nonsense. A startup group is never going to be able to write Ethernet drivers or debug VM code faster than the Linus-led kernel group. Why not just start with the Linux kernel and build up from there? Even if your project does need extra kernel-space functionality, just write a Linux module to provide it.
Don't get bogged down starting from scratch on your own MM system or IDE drivers when working, well-tested code is just waiting for you to reuse! (and if the GPL bothers you, there is this thing called FreeBSD...)
I liked Be before they sold out and changed their logo. They used to be cool and indie. Swirly lightbulbs just don't cut it in today's high tech world.
PPC rules!
It's a whole new API and environment, but it uses Xfree and the linux kernel.. Hmm.
Why not spend their efforts working on something compatable, or porting the various 'good ideas' they have to linux? (I Guess they are, kinda), rather than suffering the 'Not Invented Here' syndrome?
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.
So would the set of command line utilities for the new OS be called...
Blue's CLU's?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I read the whole interview a few days ago and resisted to comment on the false info that was presented, but couldn't stand now as it was published on our beloved /.
:)
Quote 1:
"Guillaume Maillard: Sure! We are using a Linux kernel 2.4.12 modified with the Alan Cox's low latencie patch. In order to make our Kernel Kit working, I made few changes in the Linux IPC limits."
Hmm, I think this should be Robert Love and not Alan Cox, bad skill of copy/pasting
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?
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.
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
First off, have we seen any source code whatsoever? Any papers regarding any APIs? Any standards documentation?
I've seen quite a few of these "projects" announced on Slashdot turning out to be vaporware projects/products. And, I must add, quite a poorly named one.
Sounding overly ambitious, one thing I noticed is the website portion mentioning goals denotes ReiserFS, stating in exact words "a complete system needs to be done" for a better standard in their system. While ReiserFS may not be that great, by the time [and if] they actually have an alpha release, XFS will (and, despite it's current kernel updating latency, I truly believe this) be up to date in terms of patches (or perhaps even integration into the kernel tree itself. This, I'd very much like to seee, as I'm really excited about this high profile technology we could see in Windows. They must have a lot of time to waste.
My question is this: Does anyone actually have access to the Consortium Area and would like to invalidate my comment; saying, perhaps, they have atleast started work? It's easy and common to get excited over a dream computer related, believe me..... but sitting down and actually doing it is much, much different. This fantasizing goes too far when people put up pages boasting of their work but don't have anything whatsoever to show for it.
Notice I will not tell BeOS programmers and users to "look elsewhere", I just despise the idea of people continuing to cling onto what was a failure of an operating system via being mislead by shit like this. My attitude will change when they have something to talk about.
mwtr / THIS SIG HAS BEEN PRAYED OVER AND MAY BE USED AS A POINT OF CONTACT (ACTS 19:12)
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
It's sad enough that BeOS has drowned. But to build the B API around a Linux Kernel for the sake of B and to rescue it is just so plain silly it hurts.
BeOS wasn't very pretty. Enlightenment is. It wasn't the eyecandy that made BeOS, it was the seamless integration of the kernel and widgets and grafic stuff that made BeOS. And made it so f+cking fast.
I doupt they'll make BlueOS boot into the Desktop in 10 seconds flat with a Linuxkernel. Which the original B actually does.
They might as well take the BeOS Theme for E.
We suffer more in our imagination than in reality. - Seneca
Please dont report about a project untill it has started and become something serious... there is nothing more irritating that when you start a project you have to spend 90% of your time answering emails and building html pages
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.
The problem with Linux is the non-standard UI. With BeOS, Win32, and Mac, ALL windows look alike. I have the same widgets, the same colors, and everything else.
If The OpenBeOS projects could make EVERYTHING look like BeOS, it would work. But, if I have Mozilla running its UI, things running Qt(KDE), GTK, Swing, Athena and WINE, things start to look like crap.
If BlueOS can fix these problems, life would be good. Otherwise, I'm sticking with BeOS 5.
-twb
and acts like a penguin, why not just use linux? ;)
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
1. Not Linux, GNU/Linux.
If DirectFB becomes a viable alternative to X, GTK/GNOME and QT/KDE will be ported pretty quick. Thereby abstracting the applications written for them from the display type they will run on. There's already a non-X version of QT, so it won't be that hard.
With the majority of future Linux apps being either server based (and not needing a GUI) or written for the above toolkits, portability will not be an issue.
Besides which, dismissing DirectFB without giving it a chance is very unfair. The right thing is for us to have a choice of both, and then to let the best technology win.
Some stiff competition might even be good for X, after all, it's not done KDE or GNOME any harm has it!
Yes, yes, yes, I agree 101% !!
However, I also see their reason to go with X, for now (I am playing the devil's advocate, here, because I personally hate X), and that's the huge number of supperted graphics cards.
Sigged!
Do not get me wrong but the strengths and uses of linux are the complete opposite of BeOS. BeOS was all about threading and objected oriented microkernel design, linux is solidly monolithic approach. BeOS was ligthweight and fast linux is larger and quite a bit slower. X windows is large, slow and feature laden, BeOS windowing system was lightweight fast and short on advanced features. BeOS has one fatal flaw in it's OO Frameworks which is why apple did not by them, they are based on C++ and still suffer from the lack of object flexibility that is inherent in C++. C++ is pretty bad as an OO Language because of it's heritage, it ideologically is based off of Simula 67 a pretty old and limited OO model. The only company who has effectively gotten around the flaws is TrollTech, MS also figured a way around but still it ain't so great, Apple got around it with Carbon but still the OO features are limited. Be did not get as far a any of these OSes. For OO NeXT nailed it right on the head and now with OS X and the progress of GNUSTeP we finally might see the promise of clean true OO design. So why reinvent the wheel, if you like OO kernel design like be go help the HURD, if you want an OO Framework set go help GNUSTeP, if you like linux write for linux, or if you are into server OSes go help FreeBSD. Why do we have multiple attempts to replicate an OS using fundamentally bad pieces. Blue OS has no chance, OpenBe in time will be able to replicate the be os as they are heading in the right direction. But it will take probably 3-4 years assuming they can get some people, if they got more people it would be finished sooner. This is why blue os is dumb, help open be or do something else the project is counter productive.
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...
X is a great piece of technology that was superbly designed 10 years ago and is doing quite well. X offers more features than any other windowing environment, *and* has backwards compatibility to apps written 10 years ago, and does it all without sacrificing performance
"Without scarificing performance"!? What color is the sky on your planet? XFree on my Athlon/800 resizes and moves and resizes windows about as fast as MacOS 8 on my 100MHz powerbook.
Moreover, X allows one to do things like choosing window managers and desktop environments, doing what it does quite well
Ah yes, X provides you with low level API, so you can write Xlib, which gives you a mid-level API, so you can write a GUI toolkit (you need at least 3 of these, since nobody can agree on which one to use) That gives you a high-level API, so you can write a WindowManager or desktop environment (of which there are many, and most apps seem to *require* at least one of them be installed). Then, you can actually think about getting some useful work done.
In short, shut up with this anti-X crap. You're stupid, and shouting down great projects doesn't make you look big, it just makes you look like the pathetic looser who's never administrated a system or coded a line of a gui program in your life that you almost certainly are.
You don't need to be able to build a Yugo to know they're bad cars. You don't need to be a kernel hacker to know linux is more stable than WinME, and you don't need to be a sysadmin to know which GUI sucks the most. (hint, it starts with an "X")
It was 40 lines, actually. That's how much it took to convince me I never wanted to code for X. Not coincidentally, that's the same 40 lines it took to code an X version of "hello world"!
MacOS 10 runs through what appears to be a VM on top of OSX.
That should read "MacOS < 10"...
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.
your post was funny cuz youre incredibly lame.. like me! Mr. AC
I'm not sure what you would call it, but I call replacing DOS and the win9x kernel with NT Loader, the NT kernel, and cmd.exe (for when you want that command prompt) "dropping DOS". As in, DOS does not exist. Sure, you can still make a DOS bootdisk, but that's just functionality added for the sake of format.exe. Make that dos bootdisk, then try to run windows (win.exe) from that command prompt. Unlike win9x, that's not going to happen with XP. XP is based on Windows 2000, which in turn is based on Windows NT 4, which ... you get the picture. DOS is gone.
no one cares about network transparency...
mentioning it only hurts your argument. stick with saying that X is just as fast as the framebuffer approach. (a true statement so for the current fb implementations).
Why is it that the people opposed to X are so consistently uninformed.
The Linux FB is not accelerated. It's a way to provide terminals for chipsets that don't have that feature as part of the bios.
It seems that everybody is speaking of BeOS in past tense. Yes Be the company is gone, but here is a group that is combining one of the best pieces of open source software and at the same time fixing the two biggest bugs, x, and lack of consistency. Any product that does this will have a place on my desktop. Stop bitching and support these people.
-- the computer doesn't want any beer, no matter how much you think it does. NEVER, EVER feed your computer beer.
I think it sounds intressting, but i hope that the fact that they will use the linux kernel 2.4x and Xfree won't have the result, that the new BeOS isn't so fast than the old one. A few years ago, when the First public BeOS Version was released Be told the people that this OS is so fast because it uses a Miragekernel which was completly rewritten in Assembler. What's about the new Idea? Possible to run fast as the old one?
If this really happened with a number of different types of graphics hardware -- and those used different video drivers -- then chances are good that the server, rather than the driver, was the source of the problem.
Thus it makes no difference in this case where the drivers are located, as long as the server is in userspace.
Wasn't GGI meant to do some of this stuff, or am I barking up the wrong tree?
www.ggi.org