Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Interview with OpenBeOS Leader Michael Phipps 167

Posted by CmdrTaco from the because-we-can dept.
Gentu writes "Koki from the japanese site jpbe recently interviewed Michael Phipps, the project leader of OpenBeOS, the open source re-implementation of the BeOS. Read here for the english version of the interview where Michael is discussing the roots of the project, the current status, the roadmap, the choice of the MIT license, its relationship to YellowTAB's Zeta and the other efforts to resurrect BeOS, BeUnited and the Sun Java port and more."
This discussion has been archived. No new comments can be posted.

Interview with OpenBeOS Leader Michael Phipps More

Interview with OpenBeOS Leader Michael Phipps

Comments Filter:

  • Great! (Score:3, Funny)

    by NoMoreNicksLeft ( 516230 ) <john.oylerNO@SPAMcomcast.net> on Sunday December 21, 2003 @11:25AM (#7779044) Journal
    Where can I pre-order an OpenBeBox?
    • Redundant? It's one of the first 20 comments, I believe. No one even knows what a Bebox is, in all likelyhood. No other trolls can even manage the level of technically correct trollery that I can whip out in a microsecond!

      I demand you re-moderate this as the troll (or possibly flamebait) that it is.

      Oh, and just in case anyone has a bebox they'd like to find a good home for, please consider me for the role of caretaker. I refuse to try BeOS until I can run it on the real hardware...
  • about not using linux or a bsd kernel. then they'd get all the drivers for free that those projects have... think anyone's going to bother writing drivers for ANOTHER kernel with a fraction of the mindshare? dream on.

    He even says in the interview that the kernel is one of the 2 areas most in need of development help. Wake up! ... :(

    • Comment removed (Score:4, Interesting)

      by account_deleted ( 4530225 ) on Sunday December 21, 2003 @11:44AM (#7779143)
      Comment removed based on user account deletion
    • Which BSD kernel. Last I checked, they all don't interpolate with each other and you need to make sure the drivers work for each instance.

      'sides, if they are smart enough to write an OS, i'm sure they are smart enough to target an OS like freebsd or netbsd, or even linux, and port the drivers over.

    • Re:really a shame they're so stubborn (Score:5, Insightful)

      by BasilBrush ( 643681 ) on Sunday December 21, 2003 @11:53AM (#7779194)
      It's horses for courses. As the article says, Linux was designed for server use, and the BeOS for desktop use. The BeOS had a special feel to it, as the most responsive and multimedia capable OS of it's time. It was designed to handle large numbers of tiny threads and fibers well. Sure you mould a BEOS lookalike system around a Linux Kernel, but it doesn't mean it would feel like BEOS.
      • Yes it's true, BeOS traded off REAL performance (as in operations actually completing faster) for responsiveness.

        So that the system feels faster. Which is when you think about it perfect for a desktop user since they rarely actually need any true performance. The mouse was responsive, things appear on the screen in a blink... to a desktop user that's heaven, even if it takes 4hrs on to apply a basic gaussen blur to an image in photoshop on a 3ghz processor with a gig of ram.
        • I've applied gaussian blurs on images in BeOS (obviously not in photoshop, but in natively written image editting programs in BeOS), and at most it has taken a minute and a half to apply the effect. And a large part of that was buffering the image for an instant undo, if needed.

          I've had similar experiences with audio effects. BeOS was written to speed up multimedia opperations as well. I don't know where you got your idea that BeOS traded multimedia performance for desktop snappiness. That's just not t
          • And what if I told you the same blur effect on Photoshop 7.0 ran through wine typically does not require a visible hesistation at all? Of course this all general on both your and my part, this all varies with the image and size of said image and certain aspects of the image I'm sure those who have written blur filters could tell you better than I could ;)

            Photo editing really isn't a multimedia effect, it's generally math crunching (although admittedly on newer video cards it's becoming more and more crun

        • Well, once you get a few more CPUs, and you learn to push the vector math to the vector processor [slashdot.org], then you begin to feel the difference [apple.com].

          BeOS predicted that eventually, Moore's Law would begin to fade or would periodically dip so that SMP systems would be employed to gain performance. The heavy threading will make it trivial to scale performance approaching linearity with the number of processors.

          Think about fiber busses on the system board. Think stackable external CPU modules. Think Beowulf... (sorry

          • "Well, once you get a few more CPUs, and you learn to push the vector math to the vector processor, then you begin to feel the difference.

            BeOS predicted that eventually, Moore's Law would begin to fade or would periodically dip so that SMP systems would be employed to gain performance. The heavy threading will make it trivial to scale performance approaching linearity with the number of processors.

            Think about fiber busses on the system board. Think stackable external CPU modules. Think Beowulf... (sorry,
      • It was designed to handle large numbers of tiny threads and fibers well.
        >>>>>>>>>>>>>>&gt ;
        No, it wasn't. BeOS didn't have fibers at all (fibers are lightweight user-scheduled threads on NT), and its scheduler started choking at around 400 threads on a 300MHz PII. What made BeOS feel fast was:

        1) A preemptible, low-latency kernel, which Linux has now,
        2) A scheduler that was really good at seperating interactive from non-interactive processes, which Linux is gett
    • And then we'd have just another generic distro of *nix. BeOS is different, and proud to be so, to dilute the concept by using "another *nix kernel" would be to defeat the whole purpose.

      I for one am very glad they don't, I really don't like *nix (or MS for that matter, but that's another topic altogether)
      • I think you are confusing the kernel with the distro. There's not much in the linux kernel that makes it usable only in Unix boxes -- apart from single-rooted filesystem and the concept of 'everything is a file', I can't remember much else. It'd probably be easier to use Linux/*BSD underneath a masquerading layer to change unwanted behaviours.

    • Re:really a shame they're so stubborn (Score:5, Insightful)

      by AxelTorvalds ( 544851 ) on Sunday December 21, 2003 @01:13PM (#7779715)
      You want to hear my BeOS experience? I thought it might be a fun niche. I forked out the cash, I bought the OS, bought the metrowerks dev kit, bought the books. Opened up and I was amped. It was a fun toy. I joined the dev program. 6+ years ago MW and Be were promisng a java port, I thought that would be nice and make this legitimate. Never happened. Then they killed the MW deal and completely shifted to gcc, which is cool, it just cost me $200+. At least I didn't buy in to the PowerPC idea...

      The whole time, being a Linux user and developer, I was talking about opensourcing this and that, there was so much opensource in BeOS to begin with, why not take the bull by the horns. Be used Linux as a host platform to develop beos. Be used GCC. Be carped driver designs, and an OS platform from GPL libre software. Nothing ever happened. I even wrote to the company and explained it, the response is that we don't want to help linux, we want to be Be. Now the community is doing this and they are still against Linux; their FAQ even mentions that OpenBeos on linux would be an extension to linux and that is somehow a bad thing.

      Long story short, I've got no sour grapes, I don't care about the money, time, effort or anything else, I think some of the ideas behind beos are cool. What chaps me is the unwillingness to play ball and the simple lack of a techincal explanation as to what Linux or BSD kernels (which ones did you look at?) doesn't do that the be kernel needs. Are we talking new APIs? Are talking messaging queues? Latency isn't there (I call bullshit on this one, especially with 2.4 and now 2.6) what exactly is it? In the interview he even says outright that he hasn't gone very deep, pretty much just dismissed it.

      Be's problem as a company and a community has always been lot's of talk with no beef and some awful fear of playing with others. "Pervasive threading this," "media OS that" what does that mean? Why is it good? You'll never get an answer with numbers, at best "it feels" will be said. Further, in specifics, what is it that you need the linux kernel to do and why is it easier to start from scratch rather than fix linux to do that? Even if it isn't rolled into mainline, look at ucLinux, rtLinux, and other "forks." I'm simply asking as an engineer, which problem space is bigger? Again, I wish them well and have no real sour grapes other than I really want a project like this to succeed and from the information presented to me from them they aren't making good engineering decisions and aren't making a plan for success. If it's simply an experiment and they want to do it all then say that, but they aren't saying that and that makes me think they either don't know or it's some cultural flaw and either way I don't think it is a good thing for their success.

      • Perhaps this may give you a hint?

        # Quote from Ximian's Robert Love interview on OSNews.com (http://www.osnews.com/story.php?news_id=5459)

        OsNews: Where would you like to see kernel 2.8 or 3.0 to go towards? Are there plans to implement a "visual" method and help users install easily third party drivers, like nvidia's or winmodem drivers instead of using the command line to achieve this?

        Robert Love: There is definitely no plans to make binary drivers happier. Linus has made it clear: he and many other kern
        • Hmm? I don't understand what you're trying to say? The lack of binary drivers is the problem?
          • One place where BeOS was beginning to see some success (before the fscking "focus shift") was as the OS behind dedicated audio devices. iZ used beos as the OS for their Radar 24 hard disk recording station, and Tascam used BeOS as the core of a couple of devices that they released. Mr. Phipps and company are hoping that openBeOS might be able to pick up where the BeOS left off in those markets. the inability to have binary drivers could turn off some of those companies from using a particular OS; further
      • There is another project that is trying to build an open source BeOS-like operating system, that uses the Linux kernel. It is called BlueEyedOS, and their website is here [blueeyedos.com].

        Discussions on Slashdot are good, but sometimes sterile. Do you think the Linux kernel would be a better kernel for OpenBeOS? Cool! Go help the BlueEyedOS guys. Of course, that would involve a lot of donated work to a software that may never see the day of light, but, if you enjoy coding, go for that.

    • well, linux and bsd might be excellent, and have great kernels, but if you've ever seen beos in action, it can put them to shame.

      the original beos had excellent multitasking and multithreading support (you could run 20 mpeg movies at once.. and 50 mp3's... and there wouldnt be system lag.. at ALL.)

      this is what these guys are trying to re-implement, and the last thing we need is yet another linux or bsd based system
      the point of opensource is to be innovative. not to copy and work off someone else's technol
    • read the damn article. at the time, Linux was not up to snuff, and BSD was not high enough performance wise on the desktop. they are to far along on their new kernel and at this point, having developed their own kernel will make the system work better together.
    • also such a shame Ferrari is so adamant about not building 4-cylinder engines for their cars. Think anyone's going to bother making parts for a car with a fraction of the market share? dream on!

      The Kernel is what makes BeOS behave like BeOS. If you use a Linux kernel on it, it'll just be a different skin for Linux.
    • not using linux or a bsd kernel.

      Are you suggesting they make BeSD?

  • BeGone (Score:1, Interesting)

    by segment ( 695309 )

    Ok not to sound mean but aside from niche markets why would someone want to take BeOS serious, and I'm asking this as if I were a CTO'ish person. For one, with all the garbage being funneled into things *Open Source* by companies like SC(um)O and Mickeysoft, the entire *Open* anything is something I would (if I were purhasing) stay away from until the smoke clears.

    Now I'm not saying BeOS is garbage in fact I have an older cd lying around somewhere, and it's pretty neat, but why (aside from geekiness) would

    • Re:BeGone (Score:2, Informative)

      by Anonymous Coward
      The basic advantage of BeOS is that it's modern. It's designed with current computing principles. Windows and the UNIXes are all based on old cludge.
      • Here, here!

        If Windows and the UNIXes are to survive at all, it will be among OS dilettante dabblers.

    • Re:BeGone (Score:2, Insightful)

      by bluFox ( 612877 )
      [I wish more developers however would come together under one roof
      and make he all-in-one super-ninja-hop-chop-socky OS      ]

      According to what standards ? or better whose standards?
      Do you honestly think that all the needs of the diverse environments can be filled by a single os? Think of the difference between the server , desktop and mainframe,

      Second, is the cross-distro-platform thing desirable always? doesn't it also mean that you get the denominator of all but not the 100% for the particular pla

    • Why do you NEED a reason OTHER than for sheer geekiness? Be proud of your geekiness. Revel in it! If geekiness is a crime, LET ME BE GUILTY!

    • but why (aside from geekiness)

      For godsake dude, where are your priorities?!?!

      -- MarkusQ

      P.S. I am serious as I ever get.

  • time ? (Score:3, Redundant)

    by selderrr ( 523988 ) on Sunday December 21, 2003 @11:36AM (#7779109) Journal
    while I applaud the efforts to re-write beos, I wonder where these guys find the time to do so ! And even more : the funding, as I assume they still need $ to feed their families.

    I've done some small-scale OS projects, and even those took a serious bite out of my spare time, up to a level where I was getting sloppy in my day-time job... I could not, in any way, manage such a huge project unless some company paid me for it. (and even then i'd probably wouldn't have the skills, but thats another matter)

  • Can't they see... (Score:5, Funny)

    by bjarvis354 ( 319402 ) * on Sunday December 21, 2003 @11:38AM (#7779120) Homepage
    that OpenOS/2 is where its at?!

  • Advantages? (Score:2, Redundant)

    by spectrokid ( 660550 )
    Sure BEOS has some neat tricks (don't they all?). But what features does it have that are (as good as) impossible to port to Linux?

    • Re:Advantages? (Score:5, Interesting)

      by renoX ( 11677 ) on Sunday December 21, 2003 @02:06PM (#7780058)
      >What features does it have that are (as good as) impossible to port to Linux?

      I don't know if those feature are impossible to port on Linux, but so far they haven't been replicated on Linux:
      1) fast boot time: BeOS booted to the GUI on ~10s (to a usable GUI! Not like WinXP..), on Linux it take far longer, booting the kernel is slow, and KDE is quite slow to start too.
      Usually, after this, someone remarks that with Linux, you don't have to stop your computer, true, but my computer is very noisy and I like to sleep at nights!
      So fast boot time is quite interesting for desktop users, and no LinuxBiOS or equivalent doesn't count :BeOS used the standard BiOS..

      2) responsiveness: BeOS apps felt very responsive, you were never "blocked", I think that the extensive usage of thread in the apps was the reason.
      As a counter-example, there is Mozilla: if it doesn't manage to reach a server for a new page, the whole window can become freezed, in a responsive application, I should be able to continue browsing with the other tabs..

      Unfortunately I don't really think it was a BeOS kernel thing, otherwise it would be easy to replicate, I suspect that BeOS guidelines for programming apps were pushing the usage of thread which explains the smooth end-user experience..
      And changing the design of Linux applications to become smooth will take a looonnng time, if ever.

      Oh and I'm not trolling against Linux, I just explain what my end-user experience of BeOS was: much better than any Linux so far, but with too few apps!!!
      All BeOS technical prowess meant nothing as there were far too few apps.. :-(

      • How does a multi-threaded GUI work? (Score:5, Interesting)

        by Latent Heat ( 558884 ) on Sunday December 21, 2003 @04:10PM (#7780890)
        My experience is with Windows, but I suppose Linux is not that much different. The GUI is typically single-threaded and event-driven: the cooperative multi-tasking model. You can create all the threads you want, and I have even seen sample apps where those threads poke at the GUI, but to be technically rigorous, you really shouldn't do that. If you want to synchronize a worker thread with the GUI thread, all you need to do is SendMessage() (blocking call) or PostMessage() (non-blocking call), and the OS automagically takes care of the queueing and synchronizing to get this done.

        While Java tries not to be tied to any one OS, you kind of see the OS poking through. Java too has a single-threaded GUI, and you are not supposed to invoke methods on any GUI object from other threads apart from InvokeNow() (guess what -- SendMessage()) and InvokeLater() (also guess what -- PostMessage()). The advantage of the single-threaded GUI is that any GUI method is in effect synchronized -- each GUI method is essentially its own critical section that won't get stepped on or poked at for the duration of its execution, and variables won't get changed unless you SendMessage() or PostMessage() (i.e. cooperative reentrancy) to somewhere else.

        How does this work when you have a multi-threaded GUI -- are you declaring entire methods "synchronized" or have to have locks up the wazoo, or are there some easily-understood protocols?

        Now apart from the single-threaded GUI, Windows has a way of "going away" for 10's of milliseconds at the system level -- disk reading is very coarse grained, and they say it is for performance reasons. These hyperthreaded Pentium 4's are creating very cheap context switches while the processors are getting so much faster that what used to be 10's of ms is now in single digits, so Windows and Linux and whatever are perhaps getting to multimedia Nirvana by brute computing power. Moore's law, yes BeOS can do it all on a 60 MHz Pentium I, but no one is running a 60 MHz Pentium I these days.

        • > Moore's law, yes BeOS can do it all on a 60 MHz Pentium I, but no one is running a 60 MHz Pentium I these days.

          Only if the bottleneck is the CPU: if your application is busy waiting for the disk or the network, a faster CPU won't help you..
          That's why I'm quite pissed at single threaded applications which freeze the whole window when they access the disk or the network: in Windows explorer if I click on a directory with lots of file inside, the whole windows freeze, if I made a mistake, I cannot choose
          • You can write applications Windows applications that do non-blocking I/O, and that the GUI has one thread has nothing to do with it. The real problem is that the kernel schedules non-preemptible tasks that are coarse-grained, and faster CPUs help because those coarse-grained tasks become fine-grained (in time) when the CPU churns through them faster.

            That Explorer freezes on a file-tree expand is the fault of Explorer, and it would be Explorer's fault under BeOS if it were written that same way. The kind

  • Unresolved issues (Score:5, Interesting)

    by base_chakra ( 230686 ) on Sunday December 21, 2003 @12:32PM (#7779398)
    BeOS news always generates the same responses: it's unnecessary, it's unteneble, it falls short of expectations, etc. BeOS seems to receive more criticism than most other underdog OS's because--to some minds--its irrelevance has already been "proven" by Be, Inc's failure, while most others have still to define their niche--or are still too immature even to fail to compete.

    At this point I don't know whether I consider BeOS to be worth defending. I guess it comes down to these questions: is BeOS fundamentally a more efficient platform for multimedia development? Is Linux architecture so different as to be incapable of matching BeOS performance in regards to MIDI performance, audio processing, nonlinear video editing, or 3D development? Is the performance gap substantial?

    Even if the answer to all of these questions is "yes," surely it is not so when comparing 64-bit Linux to the BeOS (with the exception of MIDI performance). And if 32-bit Open BeOS is so difficult to realize, then how much moreso for a 64-bit BeOS?

    BeOS has a potential market in that there is no other "multimedia OS" as defined by Be, and for that reason there are hangers-on. Sadly, the implications brought up in previous BeOS discussions suggest that BeOS itself fails as a multimedia OS. If anyone has any encouraging counterpoints, please share.

    • Re:Unresolved issues (Score:3, Insightful)

      by unixbob ( 523657 )
      Actually I think the most criticized OS on /. is BSD. I've yet to see a BSD story posted in the last 12 months without numerous trolls about BSD being dead.

      With the increase in corporate interest in many open source projects, I think sometimes people miss the point about OSS. To qoute your post:

      I guess it comes down to these questions: is BeOS fundamentally a more efficient platform for multimedia development? Is Linux architecture so different as to be incapable of matching BeOS performance in rega

  • intolerance of other poeples business (Score:5, Insightful)

    by Selecter ( 677480 ) on Sunday December 21, 2003 @12:48PM (#7779519)
    It seems to be a /. point of view that anything outside of the Linux arena is a waste of time in some manner. If these folks want to try to revive BeOS, what business is it of yours, and why go on about it? There's 3 things BeOS had going for it - lighting fast GUI responsiveness, excellent handling of both audio and video media, and a way before it's time journaling FS that allowed you to yank the AC plug out of the wall with no data corruption. I daresay only one of these has been implemented on *nix ( the FS ) and the other two are still MIA. Until you open source guys get linux up to the same speed in the other 2 areas that they are concerned with, dont bother asking why they are working on OpenBeOS. They are doing it becuase even after 5 years not one operating system made compares in those 2 areas. And in general, pissing on other peoples parades shows insecurity about what you are doing. Let em alone.

    • Re:intolerance of other poeples business (Score:3, Interesting)

      by Anonymous Coward
      Most of these people even think that Linux developments are a waste of time.

      Linux gets some new kick-ass threading? WAH, it breaks Wine. Bruce Perens is coming out with a new distro? WAA, just use Gentoo. Oracle is making Linux their primary platform? BOOHOO, use mysql. RedHat has a new C++ compiler? MOMMMY, it's not an official release.

      Basically you are dealing with the Technology Taliban here. The only stuff that's "good" is Unix and Perl and other "Back To Basics" fundementalist crap that's older than
      • Well, "Technology Taliban" might be a little harsh, but you're examples all show the basic insecurity that most people share.

        People fear change in general, and when you've invested a lot of time & mental effort in learning a certain OS or language, the threat of having to learn something new, and all the associated stress can cause people to enter whine mode pretty easily.

        • Re:intolerance of other poeples business (Score:1)

          by Anonymous Coward
          I've spent years with the Amiga and BeOS community--supporting the former as part of my job and being a member of the latter--and they are not, nor have they ever been, immune from this behavior.

          I understand it's difficult to be kicked when you are down but perhaps they should have thought about that while they were on their way down.

          Every OS community has their share of asses including Linux/*BSD. Of course, if the bottom drops out of a FOSS OS, the rest of the community isn't scrambling to re-write thin
    • If you've used the 2.6.0 kernel you know another one of those things has been knocked out. Without the hacks that rob the system in other areas. You say BeOS was ahead of it's time. I say BeOS used hacks that robbed the system in other respects to make the gui, graphics and video responsive at the expense of slowing everything else. Linux waited and developed this (gui responsiveness) the RIGHT way and is continuing on that road with reworking the gui itself.

      Yes linux isn't as fast in terms of audio and
      • What would you say if I told you that I tried Linux 2.6.0 on the same computere where BeOS is installed, and BeOS still felt much snappier?

        And what would you say if I told you that a one-OS-fit-all approach is flawed, and that 1000+ node SGI "cluster" (you got that wrong, SGI isn't into clusters but large NUMA monsters) will not do for a destkop OS any good?

        I know, you have your Linux and that must be everbody's pet project, or else... 'cause you only like or/and know Linux. It's hard to understand things
        • "You got that wrong, SGI isn't into clusters but large NUMA monsters."

          Try again:
          http://www.google.com/search?hl=en&ie=UTF - 8&oe=UTF -8&q=SGI+linux+cluster&btnG=Google+Search

          "What would you say if I told you that I tried Linux 2.6.0 on the same computere where BeOS is installed, and BeOS still felt much snappier?"

          How can you feel snappier than instant response? Unless your test system is under 1ghz or doesn't have much ram (the ram being far more important on a linux system, which won't g
          • I was wrong about the SGI clusters, and you were right.

            I am convinced that there are different OS-es exactly because one can't perform in all the roles efficiently. If I was wrong on this one, today all computers would be running the same identical OS, but they aren't.

            I am not karma-whoring, I couldn't care less about Karma. If I wanted to, I'd be praising Linux in all circumstances, as that's what most Slashdot readers and moderators would find appropriate. But I don't think as the majority, but rather a
            • You just made my friends list with that post.

              "I am convinced that there are different OS-es exactly because one can't perform in all the roles efficiently. If I was wrong on this one, today all computers would be running the same identical OS, but they aren't."

              I'd counter that what is and what's best are not always the same thing. Your own logic supports my case better than yours since there are alot more computers currently running linux in all 3 of the major markets than BeOS, including the desktop.

              I
              • I admit that I am rather amazed that Linux has such a penetration in the embedded devices market. Maybe not by numbers, but certainly it did prove that it's capable to perform well. One thing that it's enabling Linux to run in embedded environments is certainly the high integration of powerful CPU/MCUs and memory, so it's not anymore necessary to use highly specialized OSes.

                That said, I would like to remind you that for real-time applications, the Linux kernel has to be compiled with special patches and mo
        • ... why to reinvent the wheel?
    • Being a long time Mac user, I liked the features and responsiveness of Be, but overall the potential of the OS came from the fact that it had a comprehensive, predictable environment. Like Mac OS you could just tell that there were certain rules at work. The GUI was consistent. The programs all behaved according to an understood structure and it was easy to see that in a few years the relatively nasty command-line-esque parts were going to be relegated and the whole OS was going to be a GUI power tool.
    • The Linux guys are saying: "look, do not waste time, use the Linux kernel, twist it and get the same functionality you used to have, that way you get drivers and many other things without the innordinate effort (we are talking about millions of loc!)".

      If I see a felow pedestrian going to fall in the same hole in which I just falled in, what I am suppossed to do? Warn him or wait there to laugh at him once he falls?
  • I wanted to take a BeOS test drive, and potentially use it in the future if I like it (...more than Linux) but I'm not sure where the OpenBeOS development is, is it something I could just install and use, or is it like 90% placeholders, "not implemented yet", "this thing will go here", and I should just go with the old original BeOS closed-source binaries?

  • I thought they changed the name (Score:4, Funny)

    by Unoti ( 731964 ) on Sunday December 21, 2003 @01:39PM (#7779892) Journal
    There's some neat things in that OS for sure. But I thought they renamed it to WasOS?

  • Sockets! (Score:2, Interesting)

    by ak3ldama ( 554026 )
    I think the best news in the whole interview is that they will change sockets to be more like file descriptors.
  • I would like to know what the performace issues were that kept them from using Linux (or a BSD for that matter) as the kernel of OpenBeOS. I read some comments that said that Linux wouldn't provide the right feel. What does that mean? I know the scheduler makes a difference in GUI app behavior but that is something which can be tuned to different behaviors. In any case, I'm sure that OpenBeOS with a linux kernel on current hardware would provide the right feel... fast. I know it must be cooler to devel

Slashdot Top Deals

With your bare hands?!?

Close