FreeLists / openbeos / [openbeos] Re: The biggest problems?

[François Revol <revol@xxxxxxx>]

En réponse à Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>:

> >Johan asked:
> >> 1. Are there any showstoppers left? Is there anything that you think
> 
> >> will be very hard to duplicate for OBOS R1, or things that are very
> 
> >> worrysome?
> >
> >The whole project is hard - and there is still some very hard work left
> 
> >(i.e. the VM is currently being (re)written). So I don't think there 
> >will be any real "showstoppers", just still much work left; it's not 
> >impossible if you meant that :-)
> 
> There are some areas that really need some help.
> Marcus has done *phenominal* work on Media Kit, but he has been almost
> completely
> alone. Ditto DarkWyrm on app_server. The kernel kit, for some reason,
> seems
> to get a lot of attention. More, sometimes, than is managable. Drivers
> are another
> scary area. We don't have nearly enough.
> 
> >> 2. One thing that really amazed me when installing BeOS for the first
> 
> >> time (R4?), was how very simple it was to install and get up and 
> >> running 
> >> (If you had the right hw). The CD went into the slot, reboot, answer
> 
> >> some questions, wait, done! That is how an OS installation should be,
> 
> >> not like choosing among ~1000 packages and answering pretty cryptic
> 
> >> questions, like when you install Linux MDK or SuSE. Uhm, yeah, the 
> >> question: Will you make any effort to make OBOS as easy to install as
> 
> >> the original, or will you leave that to the distro makers?
> >
> >AFAICT we are aiming for a single approach for all possible 
> >distributions - so that different package mangagers like in Linux could
> 
> >be avoided. And an easy installation is a key to the success of an OS
> 
> >(after all, it's the first personal impression you can get of an OS).
> >That's why I think we will make sure it will be as easy as it was with
> 
> >BeOS (hopefully with less restrictions towards the correct hardware).
> 
> We are a fair distance from this, yet. I absolutely think that R5 is a
> model for
> an install. In fact, I kind of thought that doing developer install at
> install time
> was a bit of a hack - there should be no optional choices at install
> time - only
> the base should be installed. Development tools are something that
> people
Why just put it as it always was, in optional/ ?
This folder contains files the installer might or might not install
(it contains a file "_do_not_install_" with of course some attributes 
involved), and each folder in this one is presented as an optional package
by the installer (the "More options" list). On each folder are attributes
that defines the shown name in installer, its state (install by default, ...)
so, localisation is installed by default, devel is not, and is the user 
doesn't unfold the package list it's as if it didn't had any option to bother 
with. 

Has anyone begun to clone the R5 installer ? I can supply an R4 demo CD
bfs image (that was given away by a magazine) that has lots of optional
packages so we can check how it all works. Just come on beshare and 
search for BEOS_DEMO_CD_image2.iso (300M it's really bfs, the 1 is the iso
with boot stuff and windows stuff).

I think this installer is really a good start (personnaly I'd add something
that would spawn a terminal when you switch to workspace 1 so you can use the 
CD as rescue disk, or fix things before running the installer, and also have a 
game or something showing the BeOS multitasking when installing so we don't 
wait looking dumbly at the progress bar... even RedHat has this IIRC).

> can install later. Oh - wait - language support can and should be done
> at install
> time, when we do it.

It would be even better if it could be setup automagically, but I know no mean
to learn the country a PC is in, neither from the BIOS or the hardware...
That would be awesome though.
But we could add the possibility of setting this automatically from a floppy
if the installer finds one in the drive when installing, that would speed up 
mass-installs :)

> 
> >> 3. What about the GUI? Afaik, OBOS R1 will be an almost exact clone
> 
> >> (but 
> >> better?) than BeOS R5. But, will the GUI look the same? The window 
> >> hanging in a little yellow tab was what made it possible to always 
> >> identify a PC running BeOS as just that. But I guess there could be
> 
> >> restrictions on using the exact same look? If the BeOS GUI *is* 
> >> protected, is anyone working on a replacement?
> >
> >I am not sure if this has already been decided, but I think it will 
> >just look and behave exactly like R5 - although I guess it won't take
> 
> >long until that changes :).
> 
> OBOS has no intention of radically changing the look for R1. There will,
> I am sure, be
> some small, subtle differences - AFAIK, we are not duplicating pixel for
> pixel. But you will
> have no trouble looking at R1 and knowing what it is. 
> 

Hehe :)
In case we want to protect ourselves a bit more, what we could do is use a
window decor and "theme" that is a bit different from the R5 one by default,
but include a R5-looking one so we just have to change it. A small difference, 
but the fact that it wouldn't be the default maybe adds some little protection.
(it's then just a theme, like others)

François.