[openbeos] Re: openbeos Digest V2 #2
- From: guillaume.maillard@xxxxxxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 2 Jan 2002 15:49:12 +0100
"John MacGrillen"
<Arc.Lites@btintern To: <openbeos@xxxxxxxxxxxxx>
et.com> cc: (bcc: Guillaume
Maillard/DR-SUR/BE/PHILIPS)
Sent by: Subject: [openbeos] Re:
openbeos Digest V2 #2
openbeos-bounce@fre
elists.org Classification:
01/02/02 02:55 PM
Please respond to
openbeos
Hi,
> First up I am only a dabbeler when it comes to coding, so feel free to
> dismiss any and all comments below as ramblings from the lunatic fringe.
I don't know if I have a place here, but...
> 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? I think
> not. A small, fast, light kernel with a good sellection of dynamically
> loadable drivers should be the way to go.
I had the same vision about the Linux kernel, thinking that the BeOS kernel
"was very small, fast, light .." . When I start to rewrite the KernelKit
on top of the linux kernel, I saw I was wrong. I started to clone 'ports',
and discovered how it is easy to crash BeOS by just write in ports :( ,
what's more the test suite I made showed me that BlueOS port are 2 times
faster than the original one (today it is not 2 but 1.2 because I added
cool stuffs like 'safe access' and memory allocation' to them that BeOS don't
provide).
Regarding the kernel size, a 'standard' linux kernel is not bigger (and often
smaller)
than the BeOS kernel. The kernel use dynamically loadable modules too.
Dozens of developers are improving this kernel every day, it doesn't make it
the best
kernel but it's enough to avoid to rewrite a new one and hundreds of
existing drivers.
> 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.
Here too you are ___partially___ wrong but I keep my mouth shut about this and
smile.
Regards,
Guillaume
Other related posts:
