Re: SEUL: Common SEUL/e-linux tools needed

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

> No, but as I mentioned, we could run Windows in it and be done with
> compatilibity problems altogether.  If M$ can write it, we can run it.
> Sounds neat, but you really have no idea the unimaginable amount of work
> involved.  It would be about the scale of DOSEmu and about half the kernel
> too.

Actually, I do... I was in discussion with the Wine team about how to build
a JIT to be just as good as a instruction-by-instruction emulator (w/o the
slowdown) and actually came up with some neat ideas, but we needed an existing
emulator to add JIT to.  I printed out the Pentium II instruction set to
see if I might be able to make heads or tales of it, but gave up... this is
really the job for a Computer Engineer, not a Computer Scientist... I see
hardware stuff and cringe... I'm more proposing this in hopes of us *FINDING*
these tools, not writing them... Barring that, I guess I'm shooting for the
stars; hoping to reach the clouds.

> > 	3) I think that if we want to have plug-in modules for this
> > 		configuration tool included with *ALL* packages, then
> > 		we need to have a new format that gaugentees that such
> > 		a file does *INDEED* come with each package.
> 
> What?  dpkg and RPM both have perfectly adequate verification systems.  If
> we leave the configuration file out of a package, that's our brain-dead
> maneuver.  Let's just not screw up like that (of course, RedHat left the
> executable out of the Kaffe package in 5.0... :) )

I may need a few lessons in RPM, but if we make a stipulation that all RPMs
need to have configuration file 'A' in it, How can we have any athority
over that for packages outside of SEUL??? I'm not saying we shouldn't use
RPMs format, just their name (so as not to confuse users)... How do we explain
to them which RPMs *WILL* work and which won't... especially if they're still
learning the concept of a file???

> > 	4) The PGP key, and the integrity checking will provide a moderate
> 
> RPM implements MD5 checking, already, which will protect against corrupted
> files.  Developer hostility is just not something we should worry about.
> We can't prevent users from installing bogus packages, with a little luck,
> that shouldn't be a problem.  I've never heard of it happening to any
> other distribution, why would it hit us?

The PGP athentication is primarily for the purposes of assuring that we
verified that it meets it's requirements for itself...


Comments? Suggestions?

Loren