[openbeos] Re: scheduler/reminder

  • From: "Adi Oanca" <e2joseph@xxxxxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>
  • Date: Tue, 23 Sep 2003 15:24:01 +0300

From: "Isaac Yonemoto"
> >     OBOS is will be USER friendly, NOT geek friendly!
> These should not be exclusionary.  One need not sacrifice one for the
> other.  What BeOS is about is about being user friendly, and geek
> friendly.  We should also (in this day in age) aim to be administrator
> friendly.

    You are right! BeOS should be Friendly! :-)

> User friendly -- slick interface.  Easy-to-use file
> structure.  Queries.  No hangups.
> Geek friendly -- intuitive API, access to CLI, customizability, scripting.
> Admin friendly -- Easy to configure, restrict, upgrade, modular,
> sensible default values, secure secure secure.

    I agree with ALL this. #3 is not so important though!

> If we stick to these core values, I think we're set.
> In my opinion, #2 is the most important.  Since we aren't commercial, the
> geeks will write the software and the OS itself.  Sound architectural
> design (as opposed to Linux-style) which is necessary for #2 will help #1.

    Here I don't agree! :-) I think the order is: #1 #2. :-)

> To a certain extent, if we do everything right #1 is just a matter of
> quality control, that person with a white glove who makes sure that there
> isn't that veneer of dust on everything, and sends stuff back if it's
> broke.  Making things geek-friendly (i.e.  limited customizability) will
> allow us to test (and offer) different paradigms with ease.  Should "put
> to rest" (or rather, let lie) debates on whether we should have a
> mac-style menu or a PC-style menu, et cetera.

    :-) ... this justifies you choice! Now I don't know the right order
anymore! :-)))

> #3 is where OBOS needs to break ground.  Because BeOS never had
> this.  Again, good design that enables some of #2 should also facilitate
> #3.  For example, It's nearly impossible to find config files, -- mostly
> because of developers.  It stands to become worse when OBOS becomes
> multiuser.  To achieve #3 we need 1) a sound organizational doctrine, and
> 2) an auditing team that makes sure at the very least programs respect
> organization principles -- and at best scans through developer's source
> code (when available) & binary (when necessary) to suggest improvements.

    :-) Now I think I agree with you: #2 #1 #3 !


Other related posts: