Re: SEUL: available software

[Gabriel Krabbe <satan@bofh.studfb.unibw-muenchen.de>]

On Jun 9, Thomas Dietel wrote
regarding "SEUL: available software": 

[...reinventing the wheel...]

> I think we shoul compile a list of tools that are already available and 
> that could be included in SEUL or that could give some inspiration. This 
> list could show us where we will have to work, and we could concentrate 
> our forces on the necessary.

agreed, but whatever turns up needs a consistent interface with, in
the bile-raising words of pico$oft, "intuitive handling".

> - SuSE-distribution.

ack. no, please.
a hardly workable package management, combined with a tendency to
break support for half the packages in every upgrade, utter ignorance
of the fsstnd, a configuration manager that fails to even _notice_
manual changes... no, thanks. sure, the interface is simple to use,
but:
   a) vital parts behave slightly unpredictable (e.g. the user manage-
      ment, which automatically fills in all necessary fields of the 
      mask when a login-name is entered, but fails to notify the admin 
      whether these values are generated or read from the system files); 
   b) the help offered for the package-selection is worse than sub-par
      for quite a number of packages. most notably, there is no hint
      on differences between similar packages (e.g. sendmail and smail);
   c) should a user develop an interest in the config files themselves,
      he'll have a harder time than with any other distribution, as the
      paths given in the documentation are not adhered to, neither is
      the linux fsstnd. example: if a web-server is installed, the
      corresponding tree is installed below /local/www/, which is a 
      singularly poor choice (/usr/local/, /usr/share/, /home/www/ or
      similar would be rather more appropriate; better still, config
      files below /etc/(www|apache|cern|httpd|whatever)/, pages somewhere 
      below /usr/local/(dto.)/ etc. - the fsstnd is not cast in stone,
      but there is absolutely no call for creating new top level directo-
      ries, of all things. system startup scripts somewhere below /sbin/
      is a very special pet peeve of mine.

i repeat, suse has some interesting ideas for a text-/curses based admin
interface, but practically nothing else agrees with the idea of having
a system that is easily installable and maintainable for a user with little,
if any, interest for the internals, but which is also able to offer an easy
way to begin learning precisely those internals. suse agrees with the former
and absolutely opposes the latter.

countersuggestion:
base the whole seul-project on the debian efforts. their packaging system
is far superior to what suse has to offer, and offers facilities to add
rpm-based packages too, if so wished. the filesystem-layout is certainly
unconventional, but only insofar as it complies to the letter with what
the fsstnd, common sense and logic have to say: 
   - no config files outside */etc/
   - standard binaries needed at startup in /bin/
   - admin binaries needed at startup in /sbin/
   - X11 binaries in /usr/X11R6/bin/
   - other binaries (non-admin) in */bin/
   - other admin binaries (inetd-based daemons etc.) in */sbin/
   etc.pp.

the x setup provided with debian is graphics-based and just needs a very
little polishing up before it can be let loose on the curious but uniniti-
ated home pc user.
the package selection (dselect) is very well structured; placed behind
an option "custom". add on reasonable defaults (a little overkill isn't
_too_ bad, as long as no conflicts are introduced) for a "basic" and an
"advanced" (or similar) option, and the install is done. 
main difficulty with debian is, imnsho, the need for 7 disks. my vote goes
to convincing the debian team to reduce this to one disk with the option
of a bootable cd on systems that support them, with any remaining images 
read directly from the cd. keeping one disk handy to store information
about the cdrom, soundcard etc. read from existing dos/winblows config
files (after all, why ask the user when win manages to probe quite a lot
of necessary information and stores it in well-known locations?) is still
one of the better ideas posted to this list.

what is then needed is a series of administrative tools with a consistent 
interface. most of these will have to be written, if not from scratch, 
based on possibly large modifications to whatever tools already exist.
my vote wrt the interface is a basic approach: require curses for text-
based variants (no slang; it may be highly useful, but distrubution is,
imao, not yet high enough to have enough knowledgeable people out there
to have a broad enough base of developers), and require tcl/tk and/or
perl/tk for any x-based tools. the choice between tcl and perl need not
be made, as both use the same toolkit for the output, the look&feel 
will not differ beyond the specific ideas of the programmer(s).

to cut this short: when my present commercial project is over and done 
with (some time late this week, if the powers that be don't develop any
new requirements _again_), i'll hack together a perl/tk tool for the
user/group management, including related information such as /etc/shells.
when done, i'll post the source (or an ftp pointer to it should it be
larger than what i expect now) for general inspection.

-- 
Gabriel, beginning to be fed up with fruitless meta-discussions
Pet Store: "Buy one, get one flea."

PGP signature