[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Seul-Leaders: Time to take charge!
Oops. The original bounced because of majordomo idiocy. I just sent
this out:
From: arma@seul.org
To: grep@oriole.sbay.org
To: mjackson@seul.org
To: k.wetzel@welfen-netz.com
To: magnus.lycka@tripnet.se
To: starsend@interlog.com
cc: seul-leaders@seul.org
cc: bruce@pixar.com
cc: fluffy@benatar.dunadan.com
cc: paul@geeky1.ebtech.net
cc: nickm@mit.edu
cc: heineke@vanilla.r.umn.edu
cc: jfm2@club-internet.fr
Reply-to: seul@seul.org
Subject: Seul-Leaders: Time to take charge!
Date: Sat, 17 Jan 1998 07:44:30 EST
Sender: arma@mit.edu
I'm sorry for the delay here. Being one of the two people receiving
seul@seul.org mail makes for a vast amount of mail. And I also apologize
in advance for the cluttered atmosphere in this mail. It's after 7am and
I've been reading mail since midnight. But I have finally caught up.
So, an introduction of me for those who haven't heard much from me lately.
I'm a junior at MIT, doing way too many things at once. What I'm doing for
the SEUL project right now is hosting the web server, ftp server, mail
server, etc, plus being admin of said services and the machines themselves.
I'm supporting SEUL because I think it's a really cool idea and I want to
see it happen. I don't have enough time to do everything myself, and this
has become even more so lately. I wrote sdoc, which Omega's using for the
website, and I also have an alpha (soon to be beta) system log filter
sitting on our ftp site. I want to stop being a SEUL admin and start being
a SEUL programmer.
Which is where you guys come in. Omega and I have chosen you as some of the
more clueful-sounding people from the seul-project discussion, and we want
to put you guys in charge of various SEUL teams. Delegate delegate delegate.
(I've also cc'ed this to some other people who might be interested in reading
this mail for one reason or another.)
As you may or may not know, there are seul-dev-* lists that are designed
for more specific discussion of various facets of SEUL. We have not yet
succeeded in moving discussion to them, though we've tried several times
now. I'd like to put some of you in charge of various of those lists,
and hopefully you can get things going from there. You have free reign.
Ask me if you have any questions. The group in parens after your name is
one that you seem like you might be interested in. Let me know if you
have preferences, questions, etc. Switches are fine.
George Bonser (grep@oriole.sbay.org) (seul-dev-distrib)
Martin Jackson (mjackson@seul.org) (seul-pub)
Kai Wetzel (k.wetzel@welfen-netz.com) (seul-dev-?)
Magnus Lycka (magnus.lycka@tripnet.se) (seul-dev-distrib)
starsend@interlog.com (seul-dev-apps)
In the case of Magnus and starsend this is tricky, because they've
unsubbed from seul-project, presumably because of the signal/noise ratio.
I hope you won't abandon the project simply because half the people on our
open list are lame or confused. I'd love to find a solution to that one
myself. :(
Ken Duck (twoducks@globalserve.net) is in charge of seul-dev-help currently,
and is developing a good help engine.
Aldo (solaris@cicei.ulpgc.es) is in charge of seul-seg, the SEUL Expert
Group, a group intended to serve as user feedback for what SEUL should
become. If you have questions you want to ask a 'general populace', that's
the place. Ask Aldo for details. The SEG really ought to be advertised
more thoroughly. I think I've left it out of the majordomo .info files so
nobody is ever told about it. Oops.
Other people at our disposal are Paul Anderson (paul@geeky1.ebtech.net; I've
recently recruited him to fix up our website so it's actually useful), and
William Wilson (fluffy@benatar.dunadan.com), who's also working on website
stuff (database/mhonarc searching last I heard). Paul says he has lots of
free time, so if you have things you need done, let him know. :)
At the end of this mail I've included some old messages Luka wrote about
the various seul-dev-* groups. They may well be out of date by now, so use
them as ideas for what each group might want to do rather than strict task
divisions. Some of them look Just Plain Wrong.
Some are more detailed than others. I'll dig out further discussion of task
divisions later on. There was quite a bit of planning for these groups a
while back.
Please let me know if there's anything I can do to help get things started
or keep them moving. Somebody should figure out the best way to tell
seul-project about this so they don't remain confused.
As for ftp sites, I can give about 100megs from belegost (aka seul.org), cran
(aka dev.seul.org) has a bit more than a gig, and moria (aka moria.seul.org)
has about half a gig currently available. I can give any of you an account
on cran, so you can get mail @seul.org (most people make a .forward to go
to their actual address from cran), as well as do development work on a
stable networked linux machine if that's an issue.
Thank you!
--Roger
******************************************************************************
-------
seul-dev-admin
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 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! i've been looking into package managers and and distribs and am not
ready to commit to one to base seul on yet, though -- both redhat and debian
have distinct advantages and limitations. try to write code somewhat
independently of package manager for this reason (centralize pkgr-dependent
code, etc). i will suggest that we do the first implentation with rpm, though,
since it is currently the most well-documented and generally easily usable
pkg mgr out there: but this is open for debate within the admin group.
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
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.
-------
seul-dev-distrib
this group deals with the content of a seul "distribution".
the main thing this group should do is research our userbase a *lot*.
write up findings at least somewhat formally, so that everyone else can read
the info, and base the design of seul on a concrete knowledge of our users.
also, the written docs with actual data and logical conclusions, will
encourage us to believe that we are doing things the right way for the users
we are targeting.
(see mission statement for basic info about the target user.)
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. find out and record lots of info about our target user. figure out large
classifications of users we can target (the 3 big ones mentioned so far,
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.
-------
seul ui development
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
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.
this group has a leader! 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.
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 me/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).
i'm going to stop there for now.
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 installer development.
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.
******************************************************************************
===
SEUL-Leaders list, seul-leaders-request@seul.org
===