FreeLists / openbeos / [openbeos] Re: BeOS design flaws

["Zenja Solaja" <zenja@xxxxxxxxxxxxxxxx>]

Hi Helmar.   I appretiate the efforts you're taking on revitalising the 
OS we love - I'm sure that its not a risk-free venture, and god knows 
what nightmares you and your family face.  You are a man with ideas, 
and I salute you for rolling up your sleeves and doing something - 
you're the sort of person who ceases opportunities.  If you ever come 
to Melbourne, Australia, I'd gladly share a drink with you.  Enough 
butt-kissing.

JBQ is a perfectionalist.  Thats great.  Software engineering isn't a 
profession which helps pay the bills for him, but a passion he's deeply 
in love with.  When employed by BeInc, he expected to arrive in an 
environment where everything was **perfect** and functioned like 
clockwork, and realised that the object of his passion was just as ugly 
internally as all software on the face of this planet.   In any 
organisation you'll find people who treat their place of employement as 
a day job which helps pay the bills, and you'll also find a small group 
of geeks (well, artists) who love their job and really care about the 
product they produce.  The passionate ones are disgruntled by the 
carelessness shown by the former group (its just a day job), and fight 
internal battles trying to improve the quality of their products.  I'm 
pretty sure that everyone addressed in this email are part of the 
second group (we're all passionate about what we do), why else would we 
be here.  This is just a fact of life which (as mature adults) we all 
have come to realise.

So BeOS has messy internals.  No suprise here.   Almost every software 
project is a house of cards.  So how does modern computer science 
address this issue?  After almost half a century of developing 
software, through trial and error and many experiments, software 
engineers have finally grasped the holy grail of software design - 
modularity.  Thats right, a concept so simple its always treated with 
disbelief - how can modularity improve the quality of software?  The 
concept is actually quite simple: code will always suck, no matter how 
much care, attention and intelligence is behind it.   Its an unwritten 
universal constant that all code sucks.  Code will be weeded and 
pruned, and eventually thrown out and rewritten.  As long as the level 
of cohesion and coupling is well defined, modularity is the only 
concept which keeps the cards together.  If the initial design is 
solid, and each module is a self-sustained unit, then its easy to 
replace one component with a newer one.  You sacrifice performance in 
order to gain maintainability, which pays off in the long run.

To quote an email I forwarded to the OpenBeOS mailing list, try and 
remember what initially drew us all to BeOS (a new OS from a company in 
Menlo Park).  It wasn't the applications, or games or anything similar 
- it was an actual implementation of a radical concept "Screw legacy, 
lets make something which works better".  That is the philosophy which 
drew me towards BeOS.  I remember reading a quote where a spokesman 
from BeInc demoed BeOS to a group of university students, and stated 
"When we see our code become layered with levels of silt, we'll throw 
it out and start again." to which he received a standing ovation from 
the audience.  A **real** microkernel based OS draws from this 
philosophy, which is how BeOS was initially envisioned.

And guess what - OpenBeOS is actually possible because of this 
modularity concept I'm talking about.  The NetServer sucks.  Shit, lets 
get rid of it and replace it with a better version, which should be 
adequate for a few years.  After that, we replace it again, ad 
infinitum.  Look at Microsoft and their file systems.  Fat16, Fat32 , 
now NTFS.  This is a normal fact of software engineering.  Now take a 
quick guess as to what kind of software can adapt to changes faster.  
Thats right, modular software.  If your software is more modular than 
competing software, you'll adapt and replace it faster.  This is the 
primary goal any future BeOS version should strive towards.  If we want 
the term 'success' to be applicable to our project, then we must 
blindly follow the philosophy outlined.  Our prime directive, so to 
speak.  Only if BeOS (OpenBeOS) is able to adapt faster than any other 
software system will it have a chance of succeding.


To answer Helmar's question:
So is it worthwile having access to BeOS source code?  I actually think 
that having access to 'all' of BeOS code will make us lazy, and lazy 
programmers just hack away at existing code never really innovating, 
simply wanting to get the code out the door ASAP.  Although it may 
inject a new lease of life, it ultimately wont bring anything new and 
wont offer anything compelling to entice other users to migrate.  
Taking the "code sucks" universal constant into consideration, we'd 
eventually have to redo the problematic modules.  Here within lies a 
hidden danger - investing resources (money and time) into code which 
you'll eventually throw away. Really soon according to JBQ.  

I'm more inclined to take the longer route, which should lead to a 
better solution in the long term.  Redo the modules from scratch, and 
religiously enforce modularity.  Since the first version will be crap, 
redo it.  We all learn from past experience, and the second attempt 
will be a much better designed solution.  Yes, we would be reinventing 
the wheel, but that wheel gives us mobility.  Although the rest of the 
computing world would move along and reach their next releases (Win2002 
/ MacOS 11 /RedHat 9 whatever), we should at that stage be very mobile.  
Now comes the interesting bit.

What are the next generation stumbling blocks existing software will 
face (new computer paradigms)?  There is a new internet protocol 
(IPv6).  64 bit processors are here.  GCC 3.0 is here.  32 bit file 
systems are too small for video.  New input devices (speech) are almost 
here.  How easy do you think existing monolithic systems will adapt to 
these new paradigms?  How easy will a modular system adapt to these 
changes?  And here, my friends, is where I see our opportunity.  Not 
2002.  Our time is 2003 and beyond.

For the short term, I believe that we (OpenBeOS) can benefit the most 
from having the source to the app_kit/interface kit.  I believe that it 
is the most technically difficult kit to replicate, and it provides the 
core of the BeOS look and feel.  All other BeOS kits are easily 
reproducable, given enough time.  If the source to this kit can be 
obtained, a fresh coat of paint can greatly hold the user base over to 
2003, which is when all the fun should start.  If Palm/BeInc can be 
convinced to provide us with the the app_kit/interface_kit, then this 
whole experiment called BeOS can be assured a prolonged future.

Take care.
Zenja.