[openbeos] Re: openbeos Digest V2 #2
- From: "Ithamar R. Adema" <ithamar@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 2 Jan 2002 15:04:42 +0100
>This is my first post so try to be gentle.
I will :)
>I think that using the Linux kernel is not a good idea. While it has
>widespread support from across the industry, it's also hugely bloated.
Most
>Linux geeks will re-compile the kernel to optimise it for use on their
>hardware. This is fine for said geeks, but for the average user=3F I
think
>not. A small, fast, light kernel with a good sellection of dynamically
>loadable drivers should be the way to go.
Sounds like newos :)
>Similarly I think X is a mistake too. Lets not forget even the GNU
world
>isn't that impressed with the performance and design restrictions it
>imposes. The Berlin Consortium are hard at work trying to provide a
viable
>alternative.
Agreed. But even the Berlin project seems like quite some overhead for
our purposes, but ah well....
>This is going to raise a few hackles, but I also believe that trying
to
>provide binary compatibility with R5 is a mistake. If it happens, well
>that's great, but why strive for it=3F Eugenia has pointed out some of
the
>pitfalls in the BeOS kernel, why would we want to build on that=3F At
some
>point a new kernel will have to arrive from somewhere, so why not bite
the
>bullet in the early stages=3F You could spend a lot of time getting the
>various kits to work with the Be kernel, only to have to change it all
again
>to get them working with the new kernel. Lets not forget, Be were not
afraid
>to break binary compatibility in order to improve the OS, and if they
were
>still around today they would have to do so again to move to gcc3.
Not entirely true, as there was already talk (by GCC experts) about
recompiling everything with GCC, and creating a binary loader that
could handle the translation from GCC 2.x to GCC 3.x ABI :) Also, we're
not claiming binary compatibility for all drivers and such, as most of
these will be rewritten to enable use of advanced NewOS features (yeah,
at last, mmap :))
>What's wrong with starting afresh, with a new kernel, along with Be's
>original goals and APIs as your blueprint=3F You could argue that you
want the
>current apps availble for BeOS to run on it, but by the time OBOS
comes out
>with R1, most of the apps will be so old you won't want to use them.
Don't agree. With no apps available at all, everything that still runs
is useful :) Or are you writing an Office Suite for BeOS currently=3F
>Hands up those who can swear they will still be using GoBe Productive
2 on
>BeOS/OBOS in a years time as their main work platform=3F If GoBe decide
to
>update the package they would have to recompile it anyway so where is
the
>harm=3F A 100% source compatible platform is a lot more useful.
I will still be using it, for one. As I said, there is no alternative,
and I do not think it will be there at OBOS R1 ... :(
>As I said at the top I'm no kernel hacker, and you could view this as
just
>the rantings of the lunatic fringe, so feel free to shoot it down in
flames.
No flames, just arguments. We're not copying Be's implementation, we're
borrowing their design. All the code is clean-room implemented,
including kernel, kits, etc. So we can correct quite a few (internal)
things already, and set it up with an open mind for the future. Binary
compatibility does take some work, but not much compared to =5Fimproving=5F
it. I would like to improve BeOS, but I don't think we know enough of
the drawbacks of R5 even now to be able to make a sure roadmap as what
to change and how..... We'll have lots of experience when R1 comes out,
and R2 will prob. be a major overhaul. For now, we pick up lots of
little things that have nagged us all along (read kernel VM for
example) and make a list of other things to do in the future..... We
don't want to be aiming for a moving target......
Regards,
Ithamar.
Other related posts:
