/* 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 . 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 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.) ******************************************************************************