Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Be-Alike: BlueOS Uses Linux For Its Kernel 170

Posted by timothy from the must-ipso-facto-half-not-be dept.
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."
This discussion has been archived. No new comments can be posted.

Be-Alike: BlueOS Uses Linux For Its Kernel More

Be-Alike: BlueOS Uses Linux For Its Kernel

Comments Filter:
  • 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.

    • Re:I dono.. (Score:1, Insightful)

      by Anonymous Coward
      Yeah, but if they replaced X, they would have to write new graphics drivers (or extract the code from those X drivers that are Open Source). This would be a much bigger task... maybe something for the future. Wrapping around X seems a sensible first step to me.
      • (or extract the code from those X drivers that are Open Source)
        ...which is precisely what they're doing -- releasing a 1.0 on top of XFree, then taking its drivers for 2.0. It's about 2/3 of the way through the article.

        Sheesh,
        /s

    • I've been wondering about this for a while - C++ linkages, as currently implemented, are a kludge - why aren't they done at a higher symbolic level then? Surely it would eliminate stupid kludges like vtable-slot-reservation and so on?

      Is it because people don't want to give the linker explicit knowledge of C++ and OO programming methodology?

      Why not just expand the linker to be a little more intelligent - it would have advantages for other OO languages too, I'd imagine.
      • Well, for one, the linkers ARE build on the old procedural model. I think the major reason for this is because the current model is language-neutral. You don't have to exactly pair the linker with the compiled language.

        And that wouldn't really help, because different C++ compilers do things a little differently. Differences in RTTI, exception handling, memory management, etc. come in to play.

        Which is why a system like CORBA, COM, or the like is so useful.

        Except that all of those systems are slightly annoying on some level, so people want to avoid using them. So I'm not sure what the best answer to that is.

  • Legal? (Score:1)

    by x136 ( 513282 )
    What are the legal ramifications of this? Now that Palm owns Be, will they go after the theme makers, ala Microsoft and Apple?
    • If Palm wants to persue BeOS, then there isn't a NEED to try to recreate BeOS in other ways.

      It stuns me that there is STILL so much interest in BeOS among so many, yet the "owners" of BeOS STILL refuse to make it available! It's like they made such an amazingly BAD decision with this Internet Appliance thing that they can't face up to the reality that they had a good thing going.
  • is that this will be a sweet merge between linux an BeOS. The more mergers and collaboration between software developers, the better.
  • 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.

    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.

    • Re:What's the point? (Score:1, Informative)

      by Anonymous Coward
      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).
      • I've heard much about the amazing low-latency kernel patches for Linux... anyone know *why* they are unofficial? I've been hearing about them for over a year now, and it seems like they would have been integrated into the official kernel unless there's something evil and bad about them. Any comments from people in the know?
        • There aren't any real problems with the patches (I'm using them right now on an XFS kernel, btw), its just that they make an extensive change to spinlocks, which are a very basic part of the kernel. As such, they touch almost every piece of code in the system. Because of that, they are considered 2.5 material.

    • Re:What's the point? (Score:2, Informative)

      by Adnans ( 2862 )
      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) [osnews.com].

      -adnans
    • I'm not overly impressed to begin with...

      Think about this: it's not open source. They have a whole question on this in the FAQ: Why should we trust them? I agree with you, but with different reasoning. There's no point in a (partially) closed-source clone of an existing dead project -- it's an attempt to profit off of something that didn't pull a profit in the first place.

      When BlueOS dies I want its creators to take a lesson: the whole point of cloning something is to future-proof something that seemed like a good idea but was locked up. Locking up the clone is pointless and self-defeating.

      /Brian

  • Neat toy, but Id rather see a Linux Framebuffer... (Score:3, Informative)

    by BrookHarty ( 9119 ) on Sunday October 28, 2001 @04:27AM (#2489134) Journal
    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 [directfb.org] 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 [directfb.org] in case you missed it.

    • Pasted the wrong url for the DirectFB article on slashdot.
      http://slashdot.org/article.pl?sid=01/10/23/125221 4&mode=thread [slashdot.org]

    • Re:Neat toy, but Id rather see a Linux Framebuffer (Score:2, Insightful)

      by Anonymous Coward
      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.

      • Re:Neat toy, but Id rather see a Linux Framebuffer (Score:2, Interesting)

        by Anonymous Coward
        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.

      • 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!
    • Why not just help finish the DirectFB [directfb.org] and then keep everything native on linux. X is not as fast as a framebuffer, and BeOS was known for its video editing abilities.

      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?

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

        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 /dev/fb*.

        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 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.
        • 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.
          • The drivers should go in the kernel for several reasons. First of all, though you make a good point about stability, methinks it's not consistently applied. Sound card drivers, mouse drivers, USB drivers, IDE/SCSI drivers - these all use the modular/monolithic kernel driver mechanism provided by Linux to interface to the hardware layer of your pee-cee. Why should the video card be different? And why should incorporating video card drivers into the kernel module mechanism destabilize the kernel any more than IDE drivers, sound card drivers, etc.?


            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.

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

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

        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.

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

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

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

  • Missing it (Score:1, Insightful)

    by Anonymous Coward
    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.
    • On the other hand, what's the use of a bunch of people writing kernels and drivers from scratch when a proven, efficient, powerful system already exists. Honestly, there's not a lot in the realm of operating systems that remains to be innovated until the next paradigm comes along; by borrowing the kernel, alternative OSes can concentrate on the higher levels which do have room for innovation.
    • Comment removed based on user account deletion
      • With the appropriate kernel config and patches (low-latency patch, especially) Linux can be lightweight and responsive/quick/excellent for media applications. The quick booting thing shouldn't be too hard to do. There may already be a project to do a load-core-from-disk boot, I don't know.


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


    • Re:is BlueOS Linux? (Score:3, Informative)

      by sydb ( 176695 )
      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.
  • ...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.

    • Quibble (Score:2, Informative)

      by grahams ( 5366 )
      and sold off to sony to keep from dying.

      You mean sold off to palm... :)

      sean
      • You mean their IP is GOING to be sold to palm.
        This still needs to be sanctioned by the shareholders on Nov 12th.
  • I tried out the free version of Beos awhile ago, and I thought it was very cool. I liked how the desktop seemed to Just Work(tm), and things seemed integrated. The unix-y aspects of it were kind of strange, but nice to have around. However, since I use FreeBSD as my primary OS, I would find it difficult to move away from an open source OS with all the activity and development surrounding it. I like it that I can follow in detail what is happening on the development level. That's why Beos never excited me too much, even though I thought it was nifty.

    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.

    • I would find it difficult to move away from an open source OS with all the activity and development surrounding it

      WHAT activity? Have any apps that WORK shipped? Can anyone use Linux on the desktop yet? Open Source DOESN'T WORK because there is no INCENTIVE to get anything DONE! No one gets PAID for their work.

      Just look at Gobe Productive to see the difference in quality between open source and commercial software!

      • WHAT activity? Have any apps that WORK shipped? Can anyone use Linux on the desktop yet?

        I wasn't specifically referring to Linux, I was talking about FreeBSD, where I can subsribe to the freebsd-current mailing list and most definitely see a lot of activity and development going on. Personally, I find the development of the OS itself more interesting than most of the apps that run on it.

        For example, I run KDE as my desktop. It pretty much stays out of my way, and has 95% of the features I need. I'm typing this message from Konqueror, which I consider near the quality of Internet Explorer and better than any version of Netscape. I would consider that to be software that WORKS. But I don't follow the development of KDE very closely because I don't find it too interesting. It's the operating system that interests me. That's why I said I wouldn't run Beos, because I wouldn't be able to view the details of its development.

        Open Source DOESN'T WORK because there is no INCENTIVE to get anything DONE!

        Your statement is far too sweeping and shows your trollish nature. I think the amount of progress that has been made to create KDE in such a short amount of time alone proves that you are wrong. Open source may not work in all situations, and it is certainly no guarantee of quality software, but it does work sometimes. The same can be said of proprietary software. Not all proprietary software is successful, is it?

        No one gets PAID for their work.

        There are many people hired to work on FreeBSD, Redhat, and other projects.

  • 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?
    • In the most straight forward way. They'll explore the Linux kernel code, and improve it in terms of threading, and preemptibility.
      Using the Linux kernel has many advantages:

      1. They don't have to write their own kernel from scratch.
      2. They benefit from the man hours spent on the kernel, and the devices it supports.

      Plus, any changes they make will be released and contributed back to the Linux kernel.

      Anyhow, it'll be interesting to see how it develops. And for those many comments as to why they bother doing such a thing, I have simple answer.

      They want to. Period.
    • Nope. Every window has it's own thread.

    • then they'll make a library that will use user-level threads (not kernel-level threads)
      since user-level threads have the smallest context-switches time.

    • Re:Threading will be a huge problem (Score:4, Informative)

      by Adnans ( 2862 ) on Sunday October 28, 2001 @05:42AM (#2489212) Homepage Journal
      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
  • 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
    • Have a look at OpenBeOS, at http://open-beos.sourceforge.net/ - this is implementing the BeOS user-space programs on top of NewOS, which is written by an ex-Be engineer and apparently similar to the BeOS kernel. They are aiming for binary compatibility as far as possible, source compatibility where not.
    • MacOS and BSD are completely different beasts too. They were combined into a single well running OS.

      I am also rather annoyed w/the comments I have been reading about this, "why are they wasting their time making new binaries, why are they wasting their time doing this, it is just another WM for X." -- no fools, it is a project that someone wants to do. Let them do it stop judging so fast. Remember Linux started the exact same way and heard the exact same comments...
      • MacOS and BSD are completely different beasts too. They were combined into a single well running OS.

        Not really.
        OSX is mostly based on NeXT technology, which Apple acquired several years ago.
        Apple just prettied up and modernized the OpenStep OS for the general public's use.
        MacOS 10 runs through what appears to be a VM on top of OSX.

        So no, old MacOS has not been fused with BSD.
        (And OpenStep has always been pretty damn close to UNIX.)

        C-X C-S
        ObBitch: Anyone know why a goddamn PCI ATA controller costs $100 for a Mac and $30 for a PC?
        The only thing that appears to be different is the ROM. Fuck!

  • The end of X! (Score:2, Interesting)

    by j3110 ( 193209 )
    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.

    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 :) 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.
    • I find X significantly faster than VNC... plus, I can get the benefit of local fonts/graphics engine -vs- remote one. Plus it's less work for the server. And less network traffic.

      X still exists because it's useful.

      You need to go look at a real, well built unix network sometime.. workstations, servers, the works.. where everyone is running a combination of local & remote apps, seamlessly...

      And when you say Linux isn't ready for the desktop.. what you MEAN is that Linux isn't ready for the masses until you can teach it to your mother. Very true. The same goes for ANY os out there, including Windows.

      As for MY desktop, linux has been ready for quit some time, and has now surpassed my expectations.
    • There is a difference between teaching your mother an interface and teaching her an operating system.

      My mother runs linux, but she knows the interface. She does not know the operating system. Her machine is running QVWM with a gtk theme based on the reigh engine. Screenshot [hostnoc.net]

      She has no problems with it. it is easy, it works, and it is fast.
    • Um, X blows VNC away for speed... Perhaps you haven't used them on a fast enough network connection+machine to tell? Given a fast enough machine and network, you have trouble noticing that your X clients are remote at all. You can always tell you're on a network with VNC.

      Plus, there are still a LOT of very important environments with existing Unix installations and existing X-terminal installations that Linux needs to be interoperable with, unless we are willing to give up on Linux for anything other than a "home" operating system for desktops.

      • Yeah, but try using X where you actually *need* remote access, like over a 56k modem link or even 128k cable.

        It's a pig.

        TightVNC performs better in this case than ssh-compressed X-Windows, but the really sad thing is that Windows Terminal Server blows them all away.

        The fastest Remote Access technology for the GUI desktop is currently only available on and for Windows, and the OS/GUI that supposedly was 'built around network transaprency' is sadly not even close to WTS in terms of performance.

        If These guys make a new GUI that works as well as the BeOS does, with a remote client application that uses local copies of the BlueOS widgets in preference to the remote ones, then they will have something that, at least for me, would easily be better than X for both local and remote display purposes
        • Citrix ICA is also pretty fast, even over my 500K DSL connection.
        • TightVNC performs better in this case than ssh-compressed X-Windows, but the really sad thing is that Windows Terminal Server blows them all away.

          I can't help but think that this might be because on X, with GTK, QT, and so on, the rendering for all the widgets, menus, etc. is all done client-side, then sent to the X server as pixmaps, whereas I expect Terminal Server can merely send events - 'make a menu with these items', 'make a button called this', and so on, since the remote server knows what the widgets look like.

          If only that could be incorporated into X somehow - make it use GTK/QT/whatever, and have GTK apps send events, not pixmaps.

          Just a thought.

          --Dan
          • You are exactly on target. Unfortunately, this is why a lot of us say that X is long in the tooth and its time is hopefully nearing an end. Network transparency should really not mean rendering stuff on the server (err... X client... err... you know what I mean) and transmitting large bitmaps over the network. Furthermore, the X protocol is somewhat chatty, at least according to people who know better than I do.


            The problem is that this is more or less dictated by the genericity of X - the widget sets have to be rendered on the server because widgets aren't part of X itself, but rather are tacked on top of X. Some argue this makes X flexible, you can have GTK+ widgets, Athena/XAW widgets, Qt widgets, etc. It may be possible to tack some other egregious hack on top of the current X window system, and if widgets are available on the client then render them there with far lighter messages, like you said. But then you basically aren't using the X protocol anymore.


            Also X has so many extensions and egregious hacks already in place (Xrender/Xft font crap for anti-aliasing, the direct multimedia extension - whatever it's called), that adding more just makes my skin squirm.


            The fact is that 1-bit bitmaps for fonts doesn't hack it these days, rendering widgets on the (X-client) server side is slow and the concept of entirely separating widgets from the windowing environment is not beneficial for remote usage of GUI apps nor for consistency of look and feel as a whole. These are required features for a modern graphical environment, and BeOS and MacOSX do this well. Windows also does this well, even though it sucks in many ways. And this lets WTS beat the pants off of X for remote display, and lets Windows beat X for local windowing operations (this is an empirical statement based on my observations and not something I can prove meaningfully to you).

  • BeOS Strengths (Score:1, Insightful)

    by Anonymous Coward
    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.
    • 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.
  • Is anyone aware of other OS project using the linux kernel but without building a unixlike environment on top of it?
    • Is anyone aware of other OS project using the linux kernel but without building a unixlike environment on top of it?


      Mac OS X? Oh wait, that's on BSD, not that it's a big difference from a PAI point of view.

  • 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?
  • 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.
  • 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...)
    • 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.

  • 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)
    • I was not at all impressed with the "look and feel" of Be. The interface pretty much sucked as far as I was concerned.

      But what on behind the scenes was so *smooth*. That was impressive. As you opened up more apps everything just seemed to slow down, but nothing stopped, nothing seemed to stuggle. It just got slower gracefully as you loaded the machine.

      I think they're trying to reproduce the wrong part.

      • Hmmmmm I am surprised that you didnt like the LnF. Most people I have shown it too just "got it" almost instantly. I keep a copy on machine just to remind me how nice it is. Why you no like it?

        Yeah, completely agreed about the way BeOS handles itself when you start to drain system resources :)

        Personally I hope one of the Be impersonators can emulate/rewrite both aspects.....

        Regards
    • Honestly, the Linux kernel one-ups the BeOS kernel in several ways these days. BeOS development has stood still for several years, and in that timespan Linux has gotten better latencies (preempt patches), a killer filesystem (XFS), and improved graphics (XFree86 4.1 /w NVIDIA drivers). The only things really left to improve are audio (integrate ALSA, ditch the stupid software mixers like esound and aRts) and the applications (compare ROX and GMC and you'll find out how crappily programmed most Linux GUI apps are).
  • So would the set of command line utilities for the new OS be called...

    Blue's CLU's?
  • 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.
    • Actually, I think Microsoft does this just so Pointy-Haired Bosses and Mordac types can have another TLA to point to as something nothing but their favorite OS (Windows) supports.

      /Brian
  • 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.
  • 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.
  • 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.
  • 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?

    Of course, this still ignores the fact that there's nothing inherently wrong with X anyway :) But I'm just curious.
    • Of course, this still ignores the fact that there's nothing inherently wrong with X anyway :)

      Well, there may not be anything 'inherently wrong with X', but X is wrong for a lot of things - for what I do, I don't need remote X serving, multiple display support, and a hundred other things that X provides. What is nice is having a uniform API, fast, responsive, and streamlined.

      In my opinion, X/XFree/etc should be the exception in the UNIX world, not the rule; I'd guess 99% of people spend 99% of their time not using 99% of the complexity of X. It's a waste of memory for me, and I wish there was an alternative.

      Then again, I use MacOS now, so...

      --Dan
  • 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.
  • Comment removed based on user account deletion
  • 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.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close