Re: SEUL: software map

[Luka (Peter) <luka@mit.edu>]

jmunoz@mho.net wrote:
>I worry that this will get dropped, it has been so quiet, I wonder if
>the project has collapsed under the weight of it's aspirations...

i hope not. :)
i'm actually trying to tone down the (short-term) aspirations a bit, to
make sure that doesn't happen.

the other thing you'll notice i'm doing (in this mail, even), is
partitioning discussion, to prevent the sort of confusing list explosion
that happened before (there's only so much you can do with subject-line
threading on a project this huge...).  so you'll see me pointing some of
the issues in this message over to the right seul-dev lists for them;
you can think of the dev lists as focus lists in this sense, allowing a group
of people can focus on developing one concept fully rather than addressing all
of the seul project as a whole all the time (yikes!).
once we get used to the new lists, seul-project should end up being just a
general list for discussing progress of the project as a whole, though there's
some transition time here as we get a feel for which groups are doing what.
(and as we wait for everyone to notice things are moving again and get subbed
to the right lists.)
(once again, if you haven't already done so, start subscribing to the various
dev lists, since that's where the real discussions will be going very soon.
see my last email for the instructions on how to subscribe.)


>Here is a shot at a very basic map that will have to be mapped into
>several potential install scenarios, them worked from top to bottom. 
> [...list of various scenarios snipped...]
>Have we selected a bsd or SystemV style config/init?
>This could go on forever, but that is what requirements are about...

yes, these are many valid issues.  what you are getting at here are specs
for a final distribution product, and there's definitely a /lot/ of detailed
planning and enumeration of different supported configurations that should
go into that.  in fact, it's worthy of a group in itself, and that would be
seul-dev-distrib.  your list contains a lot of good points which should be
remembered in the context of that group, and expanded on to a full spec.
i strongly suggest you sub to seul-dev-distrib if you haven't already since
these are exactly the kinds of issues that need to be expanded on there:
what sorts of config choices we want to offer which users and how the
choices will interact with each other...

the issue of init style is an interesting one i should address, since it
affects implementation of system-level code greatly, but i don't think it
affects our design at the level we're at yet (due to punting of the 'admin'
group for the moment).  just for the record, i think sysv is reasonable to go
with, or if we adapt from an existing distribution it would probably wise to
use whatever they have (unless it is clearly broken).  so... that's my 2 cents
for now, though if anyone has a stronger argument for why a particular init
style just rocks so much that we really should use it (or why they all are
terrible enough that we need to redesign), i'd like to see it mentioned here
on seul-project.  this may become a very significant issue in the long run,
so it's good to start thinking about it...


>
>Sam Revitch wrote:
>>There will have to be some way to mask startup messages from
>>the user like win95 does with that logo screen.
>
>I have trouble with this.  One, we are back to "are we going to support
>vga at boot time?" (I think we should).
> I think there is lots that could make it more intelligible, pretty,
>etc., but one of our goals should be to put info somewhere that the user
>can get it if they want.  Maybe we could do like you say with an option
>like windows ( logged boot see file bootlog.txt on root) in a menu
>selection, but w95's convention of press F8 to get boot-mode menu is not
>too intuitive.  Another approach might be to have the start-up menu say
>"type dmesg to see start-up log... and mask it as you suggest, Eric.

ah, installer ui design...
 (that pretty much sums up the topic of "this should go to seul-dev-install")
but to slip in my view on which way to take this issue from here:
from a ui design point of view, i see one net /effect/ that needs to come out
of whatever impl we choose for this (vga cover-up, redirected logs, post-boot
log viewing are all very specific impls).  the effect which is important to
have during boot up is that if the system is working well, the user should
see very little, except something symbolic of the system working right, but
if (and only if) the system has a problem, an intelligent error message
should come up.  to further define "intelligent error message", it should
include 1. a naturally recognizable symbol indicating severity of the error
(make the user panic precisely as much as he ought to), and 2. details of the
error which are sufficient to allow any user with a minimum prerequisite of
intelligence know what to do next (even if it's only "error #xxx: see manual",
as long as we've made sure the user has the manual and the manual then makes
it easy to look up error #xxx and understand what to do about it.
 you can sort of relate this to the old macos boot-up: it displays a happy mac
or a sad mac, depending on whether the boot goes well.  it also does that
thing where it displays system components as icons at the bottom of the screen
as it loads them, with alternate icons for steps that fail.  so it's got the
happy/sad bootup condition down pretty well (and pretty literally too,
considering their choice of symbol).  unfortunately, its well-known failure
mode is a dialog "error of type n occured", with no further details.  i've
heard all these errors are listed in some book that true mac gurus know about,
but i think the fact that average user comes out of the failure with no info
except a meaningless number indicates that my 2nd requirement is not met
adequately by macos.
 of course on the other hand, dos boot involves spewing a ream of whatever it
feels like during boot, not stopping at errors (so the user can realize
something's wrong but has no idea what just scrolled past his screen after
that).  and i think win(95) is pretty much just a cover-up of this same
operation.
 nt does a pretty reasonable job of popping a dialog on error, and writing
to a system log which can then be viewed for more details.  of course, it
has other problems due to the exact implementation which i won't go into
here.
 you're thinking along the right lines though, by saying "put info somewhere
that the user can get it if they want".  and just how to do that best is up
for grabs.  i have some specific ideas but i'll save them for the full
discussion.
 so anyway.... sub to seul-dev-install to continue discussion of this area...
there's a lot more to be said, but these are the right issues that require
debate still.


>I still think that we should treat our target audience as if they could
>learn, not as incapable of learning and dangerous with any information.

absolutely.


>Greg Bell Writes:
>>We can get all the information from the appropriate (RPM, DEB, etc) >themselves so why not just make a general installer???
>
> Ohhhh Yeah! Regardless of our long-term plans, this is a fast way to
>get a working base distribution out the door.  This will be a great
>short term plan, will not require us to decide on a distribution right
>away, and will put us in the position of co-operating with several
>distributions instead of competing with them and duplicating their
>efforts on a separate branch of a code development tree (read
>non-resusable effort).
>

yup.  you are very correct that this is something we can work on right away
and get really good immediate results out of.  i am psyched for it if
anyone is willing to do the actual development.  so... seul-dev-install.  if
you're interested in this, plz sub to that list right away.  if there are
actually people who want to work on this aspect of the project, i would really
like to prioritize it as one of our short-term goals.  at present i'm not
viewing it as such because i haven't heard a lot of interest expressed from
people who actually want to code this stuff.  but coders if you're out there,
it's time to speak up.  this would be a very cool area to work on (and you
can learn more as you work, too; you don't have to be a master hacker yet).
so if your interested, just sub to the list, and take a hack at something --
how much the group expands will ultimately just depend on what's actually
being done.


>  I just read Peter Luka's mail, and this all sounds like tha project
>mail might start up again.  The Organizational structure sounds good. 
>What about test?  Should there be a separate list?  The key here will be
>communication between developers and testers.  The Developers should
>unit test this code.  What has always been the hard part is to do a
>decent job of documenting the intricacies of the implementation so that
>an "objective" audit of the finished product can be carried out
>independently at the same time that the integration testing is being
>done.  Obviously, more testing on more different machines will improve
>our chances of developing a robust product, if we know how it is
>supposed to work, and if we can use the feedback the testing generates.  

good point.  i actually thought about this a while ago when evaluating
task coverage given the group structure i was designing.  i was thinking
about who would do qa ("quality assurance" == testing) on seul, since a major
problem with linux software (and other free software) is lack of a strong
documentation and qa system on the avg dev project.  my final thought was
that this is something we can put off, since we won't actually be /releasing/
anything major for quite a while... but we may want to rethink that.
so for a less superfluous analysis.... what if we follow a policy of testing
within each dev group for now, supervised by the group leaders (or designated
qa people w/i the group)?  this places some pressure on the group to produce
decent code, knowing that it will be checked over periodically.  since some
groups will develop code faster than others, it will also allow for each
group to naturally match its use of qa to its own development pace.
i don't think we should put together a full "qa-team" right now though, since
we need to start by getting development off the ground first, though once
we know that we're actually moving and have code to test, we can (and should)
put together stricter coding guidelines and a qa/testing group.
creating the coding guidelines will also be easier to do intelligently in
view of the experiences we have as we start working on this project.
what remains to be explored if proper tools for getting these tasks done
efficiently (see below).

>  This will require some attention to how we communicate, especially
>since we only work across the web.  As I understand it, we will have web
>space somewhere for each project.  There should be a heirarchical
>requirements definition for each area, and possibly some sort of defect
>tracking tool.  Any ideas on a freebie?  I use Pure's DDTS (html based)
>and find it invaluable...  We do alot of our requirements based on it
>too.  It is highly configurable due to it's perl based engine.
>

well, web and then some...
status of our infrastructure so far includes a web server as well as a
cvs/file server with 2 gigs drive space (backed up regularly).  direct
cvs access is being handled mainly on a restricted-use basis right now,
with ftp for general-purpose access, though the intent is to give every
developer direct cvs access once we finish hacking up the system to deal
well, and establish a simple authentication scheme for everyone to use.

hierarchical requirements are the intent, yes.  and you can see some of
those in the group specs on the web (though those are outdated, and i
am working now on updating that info).  also working out more concrete task
lists per-group is happening, and you'll hear more about these within each
group's mailing list and final spec files/task lists that will be stored
in each group's cvs directory hierarchy.

one important point you bring up here is that of automated testing/
defect-tracking tools.  this is something we need to do serious research on,
and also just play with so we can see how various tools hold up in actual
use.  things we'll need to deal with include all the traditional
bounds-checking and bug-tracking systems.  one extra thing i'd like to
emphasize considering the os we're developing for though: programs intended
to be suid should be thoroughly checked for security bugs like overflow
conditions.  does anyone know of tools which can assist with this?

>  Regardless, attention to automation of some of these tests will be
>extremely important to efficient use of testing resources, and to good
>coverage of code.  I think that there is a lot to dicuss in terms of
>testing hooks for test drivers/automation, QA process, allocation of
>responsablilties for unit test, documentation, and integration, test
>coverage, repeatability of tests, and target machines.
>

yeah.  i'd like to keep this discussion open here on seul-project, if
anyone else has input on appropriate qa tools/methods given our situation.
as i said, i don't think it's crucial that we start an all-out qa team
this very second, but let's start looking now at approaches we can take that
will be most appropriate once we do get to the point that qa becomes the
5/6 of the development effort which goes into a typical, high-quality,
user-oriented product.

=====-----------------------------------------=====
 Peter Luka            ...            luka@mit.edu
 SEUL Project development leader/systems architect
               http://www.seul.org
-----=========================================-----