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."

7 of 170 comments (clear)

  1. Re:I wish these people would spend their time: by Teancom · · Score: 3, Informative

    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.....

  2. Neat toy, but Id rather see a Linux Framebuffer... by BrookHarty · · Score: 3, Informative

    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.

  3. Quibble by grahams · · Score: 2, Informative

    and sold off to sony to keep from dying.

    You mean sold off to palm... :)

    sean

  4. Re:What's the point? by Anonymous Coward · · Score: 1, Informative

    Dude, I've tried the threading on BeOS, and it ain't so hot. It wasn't until BeOS fell over that the developers vented their spleens on the faults of BeOS and it turns out there were many. The latency and media abstaction were the cute things about BeOS and Linux is more than up to the job (with unofficial kernel patches, that is).

  5. Re:What's the point? by Adnans · · Score: 2, Informative

    What's the point in doing this. If they are wrapping Linux kernel in BeOS like calls defies the purpose of the excercise. BeOS has been known for its superb threading whereas Linux well... Let's just say it's not Linux's strongest side.

    Can you elaborate? There is nothing wrong with Linux threading. I had heavily threaded BeOS code which was ported to Linux and it ran just as efficient, if not faster! BeOS is known for its "pervasive multithreading", and there's nothing particularly "superb" about it. In fact, for large applications it pretty much sucks ass since BeOS can't guarantee 100% message delivery. Many big name vendors simply abandoned BeOS apps because of this trouble. Or, they created a global lock which got rid of the "pervasive" part of the threading just so they could predict the behaviour of their app. Imagine having your application running fine on a fast 1GHZ box, while it crashes and burns on a slower box because it looses 1 or 2 important messages! Of course, this would indicate a design flaw, but you can't blame the engineers for getting it wrong the first time. Unfortunately for Be, since they were a new entity it only took a couple of wrong turns to tick off potential customers.

    Read more on the art of loosing BMessages here (particularly JBQ's posts).

    -adnans

    --
    "In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
  6. Re:Threading will be a huge problem by Adnans · · Score: 4, Informative

    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
  7. Re:is BlueOS Linux? by sydb · · Score: 3, Informative

    I know you're trying to be funny, but just so the point is made, Stallman only wants distributions of Linux and GNU applications to be called GNU/Linux.

    According to the article, BlueOS is only using the Linux Kernel and X. Guillaume Mailard says they are NOT creating a new (GNU/)Linux distro.

    --
    Yours Sincerely, Michael.