[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEUL: available software
> 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.
How about making reviews of each distribution and publishing them in
this list?
agreed, but whatever turns up needs a consistent interface with, in
the bile-raising words of pico$oft, "intuitive handling".
I have thought about Linuxconf but last time I tried itb removed the
SytemV init system and used its own. The author says Linuxconf is
superior but with the SystemV way you can make instllation software
adding or removing automatically starting of daemons when needed (it
does not MODIFY any file, just add or delete them). That seemed
harder with Linuxconf. I can check anew.
> - 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:
We can get ideas from them. And learn from their errors. Could you
write a more complete review about SuSE from the viewpoint of easiness
of use? I am interested in things making life easier even when they
are a bit broken.
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
Personally I would not care about making life harder for the people
wanting to hack things by hand if that allows spreading Linux in
places no Linux was seen before. :-)
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.
Have you checked about the existence of symbolic links making it
FSSTND conformant? Also how old is your experience? I have noticed
than some distributions ended adhering to FSSTND because not doing so
translated into poor sales...
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.
Expose these ideas. We are in this list because NO distribution is
good for an end user.
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.
NO!!!. Debian has good things like dpkg and the concept of
unconfigured packages so it asks you about configuring them. But: 1)
an end-user would never survive to dselect, 2) it comes with raw X
apps (sorry but for an end user I don't want X apps with black text on
white backgrounds) 3) the installation needs answering dozens of
questions. That would confuse an end user. Just try putting your
brother or sister (the one who is a complete computer illiterate) in
front of Debian.
My experience is from Debian 1.2.
By the way the placement of the files you described is identical to
what I have in my RedHat. Quite simply this is FSSTND.
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.
Are you sure this is not simply XF86Setup? By the way the Nvidia
cards do not work with the VGA server so we cannot rely on X to
configure X. At least we must provide a backup solution to allow the
user to avoid the user hostile xf86config. RedHat comes with the
satndard tools of XFree like XF86Setup but also with its own (but
GPLed) curses based software for configuring X.
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.
Debian 1.3 allows booting of CDROM.
A serious problem is than Debian 1.2 made little use of modules so
recompiling the kernel was nearly mandatory with Debian due to the
slow kernel startup. Needing to recompile the kernel is a definite NO
for a distribution aimed to end users. That is the reason modules
were created.
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).
RedHat has a fair number of them based on TCL/tk. A bit limited in
some areas and unusable outside X but they are nice and they can be
all invoked from the control-panel. They are GPLed.
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.
RedHat provides a tool who does all that. And it is GPLed. I think
you would be better creating a tool for configuring mail and news in a
context of UUCP/Dialup IP. The person who cannot get mail and news
working will be unable to get help. And this tool must be able to
work outside X.
--
Jean Francois Martinez
==================== The Linux. Use the Linux, Luke! =======================
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------