[openbeos] Re: Add-ons/Module problems/ideas??
- From: François Revol <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 31 Jul 2002 16:38:02 +0200 (MEST)
En réponse à Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>:
> >
> >I am listening to the audio from the Linux symposium in Ottawa this
> year. The
> >module presentation is quite interesting because, to me, it shows how
> much
> >better OpenBeOS should be able to do this, especially with its concepts
> of
> >bus managers and userland add-ons. [Caveat: I was not at the
> conference, so
> >I cannot know what transpired in the after talk chats.] At one point
> Rusty
> >Russell(?) suggests that Linux get rid of modules all-together. That
> >astounded me because under Linux:
>
> I think that he might have been smoking some of RMS' drugs. ;-)
>
> [snip]
>
> >Anyhow, my questions to the OpenBeOS community are:
> >
> >Does anyone else here card about these issues?
>
> Yes, we do. The main reason that you don't see them discussed here is
> that
> they are already decided for R1. In the name of compatability and of
> having
> a spec "out of the gate". Right, wrong or otherwise, that was my call.
>
> >Is the BeOS 5.0.3 implementation of addons good enough for OpenBeOS R1?
>
>
> Sure. Addons, as a whole, I think, are excellent. I don't remember
> anyone having
> *any* complaints about addons or modules in terms of how they work.
>
Actually, an load_addon_etc() with B_REUSE_ADDON flag would be nice.
That is, maintain a ref count, just like kernel modules.
> >Doesn't everybody here want a kernel that blows Linux out of the water
>
> >(excluding drivers which must come from 3rd parties)?
>
> Of course. And we will/do. Our kernel as it stands today is not feature
> complete, but
> it is already much better about SMP, IMHO, than Linux 2.4. It is much
> smaller and very
> fast. Of course, that is without some of the features that we will need
> (terminals come to
> mind). And remember, too, that Linux is "other-optimized" - it is
> designed and built to
> be a server. That is a different goal than ours - we intend to be a
> desktop OS. That means
> things like we will "waste" more CPU cycles task switching more
> frequently, but will be
> more responsive. We will have less focus on some of the more batch
> oriented directions
> and more on the light weight interactive. As with all design, there are
> tradeoffs.
>
> >P.S. I seem to have misplace the URL for the audio, but I can forward
> the
> >few ogg files that I downloaded to anyone who needs them. Don't
> bother
>
> I would like them.
>
>
>
>
Other related posts:
