/* Work in Progress. Not all of this is finalized. */
**********************************************************************
[final copy]
seul-seg -- SEUL Expert Group
The basic goal of the SEG is to get an exact idea of what our target
users really want, and provide that information in a clear form to
the rest of the SEUL project.
More specifically, the SEG would produce clear and concise reports of
the following questions. They would also include the raw data and
their methods for drawing their conclusions, so these results or
processes can be checked or reproduced in the future. Also, they should
compare everything with the user-types/percentages in the sample, so
we know how the survey results correlate with our target group's
interests.
* What do the end users indicate they want in an OS?
* What do the end users *really* want in an OS? Take their raw
answers and determine the underlying issues behind their
requests.
* What OS, applications, and hardware setup is the user sample currently
running, and what would they like to be running? What are they
currently dissatisfied with in the system they're using?
* Exactly what applications and OS features are desired by end users?
Give percentages of sample, so we know which are most important and
by how much.
Aldo (solaris@seul.org) is in charge of Seul-Seg. If you have any
questions or want to volunteer, please let him know.
The membership of the SEG will range from literate and intelligent
Windows user to technically competent Linux programmer interested in
the SEG tasks. Currently it is composed primarily of scientists, but
that may change.
Every SEUL group will be able to take advantage of the SEG and its
reports. Each group should also make sure to provide Aldo with the
specific information that is important to that particular group,
so the SEG can focus on getting the answers that SEUL needs to
progress on all fronts.
**********************************************************************
question: Do we really registry *all* files?!
seul-dev-admin -- Nick and Luka are rewriting this section. Ignore it.
things this group creates: (in reverse order, most likely)
1. assorted administration software: both automated and manual.
a. automated systems for things like log rotations, periodic security
checks(?), etc. these should also have appropriate front ends for
communicating with the appropriate user/sysadmin.
b. apps for manual low-level(ish) system tweaking: control-panel type apps,
for telling the system about hardware changes, software
installs/deinstalls, configuring time, etc, etc....
2. seul's master database, and an interface lib for it
(someone think of a cool name for it, please)
this is the centralized database for keeping everything synchronized. it will
involve a lot of the stuff package managers do now, but be much more
comprehensive.
this db will be used by the admin apps in (1) to tell the system about
anything they do (essentially to maintain state among all apps, between
invocations, if you like to think of it that way) -- it will need an
interface library so that other apps can use its services.
one significant example of the seul db being used:
user installs a package/package-set/whatever - seul db notices and records
it. the package installer, or the user through some control panel app or
something, tells the system to add apps from that package to a menu in the gui
for easy access. this is done by asking seul db to do the task of adding the
menu item. when the gui opens a menu (or just when it starts up, or realizes
it needs an update - if you're worried about efficiency), it queries seuldb
to find out what goes in that menu. when the file disappears, the file
removal has to go through seuldb - therefore seuldb can remove it from the
menu's contents automagically. next time the gui needs the menu, it checks
with the seuldb and finds out the correct new contents of the menu.
why the seuldb is cool:
(also some implementation points, for keeping it that way...)
all requests within the scope we define for seuldb get shuffled through it.
therefore nothing will ever get out of sync (unless a coder screws up an
efficiency optimization and throws the db clients out of sync with the db --
but this would be a bug; make sure it doesn't happen). in the case of the
example above, the effect is that the menus are always synchronized with what's
actually on the system. (not like the way they usually are now, i may note.)
seuldb is more expansive than a current package manager - it will deal with
multiple package formats and make some (semi-successful) attempt to arbitrate
if the user installs something bizarre. the interface will also encompass
plug-in replacements for utilities like tar and install, which are trivial
to implement with the db written correctly, since it will just involve adding
a call to seuldb_register(), or whatever, when the utility installs stuff.
pretty simple, and pretty useful -- provided the seuldb lib is done right!
seuldb will be abstracted from other apps through the seuldb lib, so they
do not need to know how it does stuff, just that it works. internally, lots
of cool stuff can be done, and different schemes can be tested easily while
this is in development.
more on implementation:
this is some stuff on internals: if you're not coding the guts of the
seul db engine, you do not know this (at least, in the sense that your seuldb
clients should not rely on any of this).
the package manager/db implementation: there are package managers out there!
use one! Currently we are basing the package manager off Debian's dpkg and
dselect, but we should keep our options open for later changes or updates.
furthermore - we will need the ability to extend the pkg managers abilities.
two things to look into here:
1. hacking the package database for whatever manager is being used.
2. augmenting it with a secondary database.
(3. (sidenote) don't forget about unix config file weirdness)
(1) will depend greatly in feasibility on the package manager used, but it
may be appropriate for efficiency and reasons, and if done well can make the
code more easy to maintain (if done badly, it can make it impossible to
maintain, too). (2) is probably the most appropriate approach to take right
now, since it is the most portable as we try out different stuff. i would
suggest looking into mysql (like msql, but different), to use for the secondary
db driver.
and what (3) is referring to is the fact the seuldb will get the fun and
nasty job of dealing directly with the config files (.rc's and everything else,
in all their incarnations), to make things happen. this is where things
will get nastiest as far as making things work right, because the user can't
touch a package db without going through the packager interface (for example),
but will be naturally tempted to or accustomed to or need to modify config
files by hand. i have some ideas on how to get this to Do the Right Thing,
but that is something to go into later, in much more detail.
suggested development plan for installer:
1. research packagers, db's, other stuff.
2. develop a spec for the seul db interface, coding enough to make it barely
functional as a package manager, and do sensible debugging output (for
development purposes).
3. continue coding the seuldb internals, and start on the admin ("control
panel") apps.
4. continue with the seuldb internals, and really dedicate effort to the
admin apps once the gui spec is available from the ui group.
that's all for the seul-dev-admin general layout. there's a lot of stuff here,
and it's bound to have problems, so criticize anything here if you know of
a better way to do it. do not start picking on small internal details yet
though, unless you think you've found something implied by this general spec
that will end up really messing things up at a lower level.
**********************************************************************
seul-dev-apps -- Final finished draft.
This group researches apps available for Linux, and writes reviews
focusing on features of those apps which make them good or bad for the
end-user. After determining which apps are best, they may improve areas
of each app which were determined to be weak from the end-user standpoint,
and adapt the app to fit into the SEUL system better (for example, by adding
support for the SEUL help system into the app).
This group may also develop new apps, or assist others in developing new
apps, in such a way as specifically be targeted at end-users, and to fit in
well with the SEUL system, supporting the SEUL look-and-feel, services, and
any other SEUL conventions which develop.
What I'd like to see from this group at first is a list of "Linux application
lists" from other sites, in the form of a database/table that SEUL users
and developers alike can reference. You should examine the application
search engines and decide if the world needs a better one. Discuss with
seul-dev-distrib about what sort of applications we need for each end-user
target class, and find/modify said apps for SEUL.
The leader of this group is Micah Yoder (yoderm@seul.org). Please contact
him if you are interested in volunteering. The group has a couple of
informational documents written, but full progress is not yet underway.
**********************************************************************
seul-dev-distrib -- final copy
This group deals with the content of a Seul "distribution". They
determine how to organize the packages and integrate the products of
all the other groups in the best configuration possible for the target
user. They will work very closely with the SEG group to determine what
needs to be learned about our target user to make Seul a successful
distribution, and will make direct use of that information to make
configuration choices for the stable distributions.
In the first stages of development, the results from this group will influence
the design of seul overall, such as the UI, and the making of decisions on
what to _include_ in seul as a priority because it is vital to the user, as
well as what to _exclude_ from seul, when it gets too difficult and is
relatively unimportant to the user.
In later stages, once other stuff has been coded and is ready for filling out
with configs targeted at particular users, this group will decide which users
we want seul to support directly (home, business, school, marine biologist...),
and define exactly what the configuration and options for each user should be,
in order to serve them best. The actual specific configs will then be coded
based on that info, which should be relatively painless if the other groups
did their user-specific abstractions correctly.
So, tasks in short:
1. Work with SEG to get lots of info about our target user. figure out
large classifications of users we can target (home, business, school,
and any other big ones that are discovered). Figure out what each user
group wants, and any distinctly good/bad setup for any user group.
Also, note commonalities among groups.
2. Decide which user groups we want to support, and the exact configs for
those user groups (as allowed for by the seul configurability available).
3. Write the configurations, compile the distribution. And complain when seul
configuration utilities mess up, so we can get them fixed.
Another project that seul-dev-distrib is working on currently is the Linux
Core Specification, a "base" distribution specification from which other
distributions may derive if they wish to be "Core Compliant".
The leader of this group is George Bonser (grep@seul.org). Please
contact him if you are interested in volunteering. This group has
had most of the attention recently, and they are well underway in
creating the Core Specification and discussing configuration for the
distribution.
**********************************************************************
seul ui development -- this section is Just Wrong. Luka is rewriting.
This group needs to start out by doing some research to gather knowledge
about existing GUI systems, toolkits/widget-sets, windowmanagers, etc.
They should then establish some sort of GUI standard for the SEUL system,
providing some arguments as to why that is the system that should be used.
The standard could be solely a specification, but that is probably not wise,
since developers will not use a standard if it is not easy to follow. Thus
this group should also gather/adapt/write tools to make it insanely easy to
code for the SEUL GUI standard.
Some specific areas that the SEUL GUI standard should probably encompass:
1. SEUL should support one main window manager fully - call it SEUL
windowmanager or something. It may be either a completely new wm or a hacked
version of another (whichever involves less work, and still comes out well).
It should be a window manager targeted specifically for the end-user.
In addition, SEUL should still be able to work equally well with any other
window manager. SEUL windowmanager is just the main wm we want to present
to the average user. SEUL wm should NOT be a direct copy of win95 or MacOS
or Amiga or any other existing system, although it can incorporate good
features from them. Remember we want to distinguish ourselves by developing
a new GUI that really works for the end-user, not a copy of some other
imperfect ui, which would only lead to the impression that we are trying
to keep up with another flawed system, rather than creating something better.
The "window manager" will also include a few apps that go along with it
traditionally such as pager, buttonbar/taskbar, pop-up menu, etc. These
should all be designed for a quick learning curve, more than the
do-everything Swiss Army knife concept that Unix is known for. The user can
always dig deeper to do more, but the initial impression should be simple,
uncluttered, and obvious to use for common tasks.
2. Common application look and feel. In order to make the system defined
for this actually be used, the group will have to provide a widget set
and easy to use tool kit for creating applications that follow the defined
look and feel in addition to ui style suggestions. The widget set/toolkit
should have bindings or interfaces to many programming languages if possible.
Thus apps in C or tcl/tk or perl or Python, for example, can be converted
equally easily, without having to rewrite the app in a new language.
Something that may be best is if we use one gui scripting language for
development with bindings to various other languages, and extendibility
to be called from other languages. Then we only have to write the widget
set to support that main language, and others can interface through it.
Tk, for example has bindings for Tcl, C, and Perl, and its windowing shell
can be instantiated from any app written in a language which can run
an external process and interface to its i/o pipes. Python also supports
bindings to multiple languages.
Something ideal may be as follows:
C (Xlib) SEUL widget set --------------- (C apps use widget set natively)
|
\|/
some GUI Scripting Language or "toolkit"
| | |
\|/ \|/ \|/
(bindings to other languages,
or a stdio-based interface, at least)
The reason this would be ideal is because ANY language can use the
widgets through the stdio interface (although that's rather inefficient),
common ones can have bindings written for them, like the way Perl has
a Perl/Tk module which provides a direct Perl interface to a Tk-style
interpreter (this is more effecient than just running a windowing shell and
sending commands to it). In addition, C apps can link directly against
the widget library, for optimum efficiency. This is appropriate since apps
that are critical on graphics display efficiency tend to be written in C.
Since many existing widget sets are written in C, this also means that good
parts of those can be reused through our toolkit of choice easily, since
the toolkit supports C language widgets.
Python may support something like this, since it can supposedly interface to
C directly, has its widget set written in C, and should support extension
to binding to other languages pretty easily, but these are things that
needs to be checked on carefully before committing to a particular toolkit.
**********************************************************************
seul-dev-help -- final finished draft.
This group will work on the help system for seul. Things that this group
will be doing:
1. Writing a help browser, and specs for other apps to use for
invoking/controlling it.
2. Writing specs for the help document format.
3. Writing some actual help docs.
This group may also acquire specialists in writing documentation, who
help write docs for other groups' stuff.
The leader of this group is Ken Duck <twoducks@globalserve.net>.
He is already working on some prototypes for this stuff which are coming
along nicely, and he has a good idea of what we want out of the help system.
Contact him if you are interested in volunteering or want more information.
here's some general info about the idea we are trying to get working for
the help browser:
Following the successful trend of documents toward hypertext-based systems,
the help format will probably be based on an extended html format.
The browser itself will have an interface allowing it to be invoked and
controlled by another app, will implement assorted navigation features,
and will support a plugin-model at the core level, such that the help browser
is essentially a very small kernel, with html, seul help, and other viewing
modules pluggable. This means that the browser can be reused as a web browser
if a good web/html module is written, in addition to being used for reading
seul help text, and can also be augmented with modules to do things like
display help-text in other formats used by 3rd party app developers.
Something to note, from recent seul-project discussions on docs: with a
foo2html converter, various helptext formats could be displayed on the fly
converted to html, given just an html module that knows all the tags used by
foo2html. Or to do things really right, we should include modules in the help
browser to support things like manpage and info format.
Of course, we are looking into existing browser and html-widget projects to
try and reuse as much code as we can. The functions for browser controls and
other specifics have also already been given some thought. For more info,
get in touch with twoducks, and watch for developments in the appropriate
places, as soon as we get per-group stuff set up (mailing lists, file storage,
web space, etc).
Just a quick note on interactions with other stuff:
o _Any_ other applications could wish to use the help browser - the interface
for other apps to use it should be simple and powerful enough to let it work
well regardless of what is calling it.
o One major dependency this group has is on the seul gui toolkit. to prevent
this from hindering progress, the help group should just plow ahead for now,
using whatever toolkit makes prototyping easiest. (At present, twoducks is
using tcl/tk, just because he already knew it, so it works out well for
the proto.) Just make sure the browser does not depend vitally on
particular quirks of the toolkit in use, and this will work. And as usual,
keeping the code well-abstracted will make plugging in new gui routines
later relatively easy.
**********************************************************************
seul-dev-install -- final finished draft, except status paragraph
This group writes software to get the user from *wherever* to a running
seul system, with minimal effort on the part of the user. This can be
installing a system from scratch, or installing over or next to an existing
OS. And if the user is trying to preserve data (as indicated by answering
a question like "do you want to keep another OS which is currently installed?")
then the installer should be extra careful about not destroying data that may
be related to that OS.
The installer should also be excessively verbose about _what to do_, if an
error occurs. Diagnostic info may be useful if you know what it means, but
the seul target user may not know a thing about linux or os jargon, so what
they need is instructions on what to _do_, to make things work, or pointers to
more info if necessary (and don't say look on the net, if they don't have a
net connection up yet!). Above all, make an effort to _never_ leave the user
stranded with no instructions on the screen.
Things that need to be implemented:
1. An fdisk/fips that rocks! (read "disk setup utility")
Current fdisk programs are not user-friendly, are not robust enough to
deal with weird stuff (such as the latest microsoft product) on the disk.
fips should also be integrated with this setup utility.
Important things:
o User-friendly
o Robust and relatively safe
Warn the user more if something is likely to fail, rather than just
offering a disclaimer every time a write is requested.
And remember to keep the front/back end separated, so that the back-end
can be integrated with the rest of an installer easily.
2. Device detection code
Gather and write code necessary for making all common setups be
detectable reliably. Document which parts are reliable and which aren't:
this info will go into hardware support publications.
If kernel hacks are necessary for this stuff to work, make sure they are
really necessary, and if so try to get the linux kernel team to do stuff.
It would be poor if we have to ship with a seul-hacked kernel for things
to work.
3. The rest of the installer.
We should almost certainly start by grabbing the best publicly
available (ie gpl'd) installer, enhancing it to be friendlier, fixing
the "why can't someone just go in and fix that?" bugs, adding the
increased device-detection support, and integrating everything to run
smoothly from start to finish.
And add seul-specific stuff (4).
But try to keep the general installer fixes separate from the
seul-specific changes, at least when starting out: this way, we could
even let the original distributor take the improved installer and use it,
and perhaps they'll end up distributing an alternate seul-enhanced
version for us as well!
4. Seul-extensions in the installer.
The concept here is that the installer will support a higher-level
packaging scheme than what is currently in use.
The installer should provide a framework for selecting things like
"typical", "full", "minimum", and "custom", installs, and each should
be in the context of a particular type of user.
Redhat already implements some stuff to support configuring sets of
packages to be used in an installation. This needs to be enhanced,
though, to allow easy configuration of user/install-style, and to pass
through info on package-sets to the seul database developed by the
admin group. Ignore that last part for now, but be ready for it when
the spec is done.
5. Gui/help system hooks.
Seul will be developing a uniform help system and gui. This is not
a major concern right now for the installer, since it can be pretty
independent of everything else. But if possible, the installer code
should make a clear distinction between the front and back ends, so
the gui can be replaced someday without having to understand how the
installer works internally. Also, help routines should be abstracted
into a set of routines that are grouped together and can later be
easily identified.
The installer work is mostly independent of the other groups.
Implementation in the order above means a lot can be done before you get down
to 4 and 5, where things need to be done such that they fit together
with the rest of seul.
This group is led jointly by Jean Francois Martinez <jfm2@club-internet.fr>
heineke@vanilla.r.umn.edu
******************************************************************************
[final finished draft]
seul-pub: SEUL Publicity, Publications, and Public Relations
* Linux Advocacy
- Why Linux?
- Why SEUL?
- (Why Windows?)
* "Public" SEUL docs and announcements (the non-technical ones)
- write and/or maintain
* Website -- seul-pub is wholly in charge of the website
* A section for each group, containing
- Mission statement
- Active members
- Archives
- Decisions and plans, in an easy to read/skim format
- Past/Current/Future projects, with documentation, links, todo list,
who's working on them, what sort of help they need
* Main/other:
- SEUL Mission statement
- SEUL FAQs
- Searchable, overall or by group
- Subscription form for seul-announce on front page
- List of seul groups/links w/ brief descriptions
- Other linux links w/ commentary/descriptions
Led by Martin Jackson (mjackson@seul.org), this group is well
underway for finishing the first draft of the new website,
with help from
******************************************************************************
Group Web Ftp
seul-dev-app Searchable/Browsable Database Modified apps (diffs?)
w/ Reviews New apps (Office, etc)
seul-dev-admin Searchable/Browsable Database Modified apps (diffs?)
w/ Reviews New apps (seuldb, proclog)
SeulDB API
seul-dev-help Taskhelp texts on page, searchable? Help libraries, stand-alone
cgi for adding new ones executable
Help API
dev-install List of Hardware supported/unsupported Install System
Ways to Detect Things
dev-distrib User group preference summaries Actual distributions
Core Spec (floppies, packages, etc)
dev-ui Searchable/Browsable Database Chosen/Modified UI (libs?)
w/ Reviews
UI API
seul-pub The page itself!
seul-seg User preference surveys and results
seul-leaders (no products. we're hosed enough already.)
******************************************************************************