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."