SEUL: Re: Why a new package system ?

[lso8219@cs.rit.edu (Loren S Osborn)]

> In the case of the kernel this is mostly dealt with in 2.1 . All of the
> IP options, etc. are now run-time settable, even the number of inodes
> the kernel will support is run-time settable via an entry in /proc (I
> tried it on a heavily-loaded mail server that was running out of
> inodes, it worked and I didn't need to reboot, I was amazed). Of course
> device drivers are dealt with using modules, and you can even arrange
> to load a module to drive the controller of your _root_disk_ if you use
> the initial ram disk. So, forget about having the user recompile the
> kernel.
> 
> Ghostscript? We just build in _all_ of the drivers. It's a virtual-memory
> system, the ones that are not used will not get paged in to memory. If this
> was a big deal, you could make drivers work with run-time linking using
> libdl. So, forget about recompiling GhostScript.

But these are just two notable examples, neither of the solutions are great,
nor very efficient... (Honestly, If we allow a GUI to do all the
pre-compilation configuration, what is so hard about allowing the user to
press the "Update Executable" button... we don't even need the word
"compile") I see your solutions being better suited for SEUL than for
e-linux...  e-linux should be *JUST AS* flexible, powerfull as any other
linux distribution... but totally accessable from a GUI... (as well as a
command line)... I'm able to optomize my kernel from the commandline,
therefore I should be able to do so from a GUI... (actually, have you
seen 'make xconfig' for the kernel?)  I do know people who refuse to use
Linux "until the GUI is *AS POWERFUL* as the command-line"... (not to
mention that these people are shortsighted... they aren't concerned with
interface efficency, they don't want to lern Unix commands, they don't
want to learn to touch-type... they just want to be able to get the computer
to do what they want; their way...)

> Library paths are changed via configuration files or environment
> variables. If that doesn't work, fix the program.

In most cases, yes, but not always... (BTW, I don't mean .so files, I mean
program-dependant resource files, (ie the GUS files for timidity, etc.)

> > In addition, compiling programs helps fit them to the user's system,
> > and optomize them for their particular flavor of their processor...
> 
> Yes, you can get maybe a 13% gain (last I heard) if you recompile for
> Pentium Pro rather than 486. So if you insist on having this feature
> and want to make it easy, do it for the user and provide a Pentium Pro
> CD or a few pentium-pro versions of packages rather than having the
> user recompile the world. However, most naive' users would gladly
> sacrifice 13% performance for ease-of-use.

I'm not saying the user should re-compile the world... just that he/she
should be *ABLE* to.

> So, I still don't buy the need to recompile.

Not the need to re-compile (I *STILL* don't see what's so hard... click 
a few check-boxes, changes a text-box, and click the "Update executable"
button... If we're allowing the user to re-configure the run-time system,
why not let them re-compile the compile-time system...) The *ABLITY* to
re-compile...

> > Secondly, you seem to have mis-understood what I meant by software
> > "maintence"... I'm saying that there should be a GUI to change a
> > program's behavior once it's installed...
> 
> Right. Like the *-config scripts in Debian (which are currently shell
> scripts that may or may not use dialog boxes provided by the "dialog"
> program), but with a GUI. I currently run smail-config to change smail,
> etc.

Don't use Debian.  (Starting to wish I did... I *HATE* Red Hat... I either
need to go back to Slackware, or try Debian)... don't know, specifically
what you're talking about...

> > *EVERY* program would include a module for this config-program as a
> > requirement of the packaging format... 
> 
> Right. We are doing this with COAS. But it's not strictly per-package,
> because 10 packages need to know the paper-size in the printer (A4 or 8x10?)
> and we just have each of the ten check if the paper size has been set. If
> it has not been set, we run the paper-size configurator once, and don't
> ask you again unless you want to change it. When you are installing a
> package, you would be asked the question at the time you first select a
> package that needs the answer.

I *ALMOST* agree... I maintain my belief that the system should be just as
configurable from the GUI as from the CLI... the COAS team can't anticipate
*ALL* possible system configurations... What if the user has an A4 printer
*AND* a letter(8.5x11) printer?? the user/admin should be able to configure
the system that way... for more global settings (like paper-size) the system
will have a system-wide default, but the admin should be *ABLE* to override
this on a per-application, or per-service basis.

> > Does this clarify things?
> 
> It reinforces my notion that your teams need to look into these issues
> a bit more deeply and see what is being, and has been, done to address
> them.
> 
> I would invite the developers among you to put in some time as Debian
> maintainers so that you can get a better handle on some of these issues
> so that you won't design inferior or duplicate solutions when you go to
> build your own distributions. 

Also, keep in mind, that I'm not endorsing using a totally new packaging
system, just that our system won't be compatible with packages from
other sources, so creating a new *NAME* for the system would be less
confusing...

Comments? Suggestions?

Loren