[openbeos] Re: BeOS design flaws

  • From: "Jean-Baptiste Queru" <jb@xxxxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>, <helmar@xxxxxxxxx>
  • Date: Thu, 6 Sep 2001 01:03:51 -0700

Well, I guess I'll need to reply to everyone...


> > I think that all you're likely to achieve will be to polish things
> > a little bit and to release "yet anoher version of BeOS that
> > doesn't really solve people's real problems". I could name many

> Yeah but it would help it stay on the market (was it there already ???)

It would IMHO let it continue to lose grip on the market. It might slow
down that process. Or not. The big question is, how many more
applications would a new release bring to BeOS? How many of those
are "tractor apps" (i.e. that justify alone to move to a new platform)?
How many of those are "missing links" (i.e. the last application that
someone was missing to switch to a new platform or to stay on that
platform)?


> [description of lots of bfs problems]

Well, I didn't mean to start a technical discussion. My point was that
many (most) components actually have problems that can show up one
way or another, very often (too often) in real-world cases, and that
each one of those problems might be a reason why a given application
can't be properly developed or ported.


> Here I begin to think even if some criticised the openbeos project
> because we would reinvent the whell, it might prove useful in some
> extend. Could we get our hands on the bug database at Be ???

You wouldn't necessarily re-invent the wheel as re-define it by keeping
its essential properties (it is round, can be interchanged and grips tp
the road) but discarding its implementation (it is filled with air). Some
companies try to work around the "air" issue by tweaking their wheel
designs to use stiffer sidewalls. Some others are seeing further ahead
and investigating solid urethane to replaced inflated rubber.
A given sourcebase without its associated revision history and bug
database is 95% useless.


> Been hired at M$ ? ;)

No, but I'll be working in a company that might end up competing
with Palm (or Palm's software subsidiary).


> So it's true when they say 'from the ground up', except the ground
> here is not  a solid granit rock :-(

Yes, you could say that. I'd suggest that everyone goes read this
site : http://www.joelonsoftware.com/ and gets a few ideas. Joel
explains a few things that are essential to software engineering,
and that are sometimes overlooked.
(BTW, before everyone screams, I know that I sometimes feel
like violating the rule that code shouldnever be thrown away to
be re-written. I have some reasons to believe that the specifics
of OpenBeOS justify my trespassing that essential rule).


> Well, all I hope is BeOs is more than just a piece of crappy
> code tiing up blocks of licenced code.

No, the "native" code of BeOS is more than a piece of glue. There
are indeed bits and pieces of licensed code, which are essential
to the good working of the OS, but which are not central to its
architecture. Like the nuts that hold the wheels in place in your car.
Or like the font engine in BeOS (the most blatant example I can
think of).


--

Jean-Baptiste Queru <jb@xxxxxxxxx>



Other related posts: