Re: Comments please

[Roger R Dingledine <arma@mit.edu>]

In message <34CECB4B.8E5EA1C8@siservices.net>, rickya@siservices.net writes:
>I'm not at all against using dpkg, with the dependancies fixed.  I am
>just aprehensive of prominantly displaying that given that it does have
>a bad reputation, even if it is an exagerated reputation.

Hopefully with the new Core Spec we'll have a better idea of how
dependencies ought to work. Also, I suspect the package managing stuff
that seul-dev-admin comes up with to keep track of installed software
will deal correctly with this sort of thing.

If we say something like 'we use dpkg with the seul dependency system',
that should satisfy both of you...

>> The last I heard from the project leadership, it is to be a cooperative
>> effort.  Debian has resources that can be very useful and, in turn, we can
>> be a very useful resource for Debian. I do not see why they can not adopt
>> a  better installer or package defaults from SEUL if they wish.

In fact, many of the products that SEUL produces will be useful to other
distributions. If we make a bunch of things and everybody else starts
using them, then we win, because Linux wins. Our project, in addition to
trying to make that happen, is to collect all the cool stuff that other
people have done, and configure/package it well. And if other people like
our configuration choices, (provided we're Right) great!

>The last I heard from Bruce was that he wasn't promissing anything, but
>would "give us a shot...don't blow it."  While that isnt't flat out

Bruce was saying this because the seul-project list did not have its
act together, and there were a bunch of idiots flaming each other about
decisions that had been made months ago, because the leaders hadn't
gotten those decisions out in the open in a good enough fashion. We
still haven't. We need that website.

Please take a moment to skim over the seul-pub section of
http://web.mit.edu/arma/Public/seul-tasks and realize what we're going
to want from you for your group. I don't know what format of presentation
the seul-pub people will choose, so I can't give you all the details.
But they say the webpage will be presentable by the end of the week.
So either send them relevant information now, or have it ready to send
them when they realize they don't have it yet.

Er, where was I. :) I think our organization and signal:noise has
increased significantly since then. We actually look like we're
getting something done. Until we actually see a product or some
milestones, we won't know for sure, but...

>I absolutely agree.  My impression from your doc was that we, basically,
>won't make a move without Debian.  I'm saying we shouldn't have to do or
>not do anything because Debian does.  If that is not what you meant to
>convey in the doc, it might be of use to you to know it can be perceived
>that way.

Yes, we will use Debian because
a) they've got a lot of packages and software
b) they've got people and experience we can make use of.

I've got no problems with taking stuff from redhat, slackware,
solaris, dos, whatever, and doing it our way. Hopefully Debian
will see what we do, realize it's cool, and adopt that too. It
would be nice of us to package up the SEUL things and hand them
to Debian, or even maintain the Debian version of those packages.
That's why Debian can use us (the mirror image of the above list).

Redhat is going to benefit from our work without giving much
directly to us. Bleah, but so be it.

[snip]
>Debians way, so be it.  If it's not, so be it.  The idea isn't for us to
>jump in line with the best of the worst but to select the best of all
>and make it easy for all to base their distro on.  Since we are aiming
>at standards there is no way we are going to be "incompatable".

If we make the standards and nobody else likes them, we fail. It will
be tricky.

>Remember, we are trying to lead, not follow.  The good aspects of Debian
>are going to augment SEUL, along with any other distro with good
>aspects.  At this time Debian good out weighs it's bad by a larger
>margin than the rest and therefore we use it as a base reference.
>
>> It is quite possible that a good many of Debian's
>> packages could be maintained by SEUL project members at some point in the
>> future.  By the same token, some of Debian's package maintainers might
> actually like what we are doing and blend our ideas into their work.
>
>Right here is what I'm saying about us not being a Debian diff.  You say
>that "Debian packages" may be maintained by SEUL maintainers but "Debian
>maintainers" *might blend* our *ideas* into "their work".  That makes us
>sound like an extension of Debian, rather than a seperate distro working
>in common with Debian to standardize Linux and produce a long needed
>user-friendly distro.
>
>The way you refer to SEUL is more as an augmentation *to Debian* than
>it's own distro taking the good ideas from another distro to make a
>better, seperate, distro.  Whether you mean to or not you make it sound
>that way.

SEUL will be its own distribution. We will look quite a bit like the
current Debian at the beginning. I suspect that we will remain similar
to Debian, but that will be because we'll keep handing the major SEUL
programs to Debian and they will use them to start looking more
user-friendly. So both distributions will progress in the same direction.
And maybe Slackware and Redhat will use our programs too. And suddenly
not only will it be more user-friendly, but it will also be more familiar
to users of other linux distributions...

I suspect George realizes this, too. He's intelligent enough to realize
that just copying Debian isn't going to get anybody anywhere. Yes, he's
a Debian fan. He wants to make it better, by making SEUL better. Great.
It's all Linux.

>> Debian gives us an economy of scale ( not in dollars so much but in
>> potential user base and number of developers ) that would take a long time
>> for us to develop on our own.  Sure, maybe we will diverge so far as to be
>> completely unrecognizable from Debian but if our ideas are really good
>> ones, I suspect that Debian will adopt a good many of them and therefore
>> we will not really diverge as far as we might.
>
>This is the purpose of SEUL.  To do it better and make it appeal to the
>other distros to follow our lead.

Exactly.

>> It is required by the GPL to provide source. Debian's model is to provide
>> the pristine source and their diffs against that source as a separate
>> bundle. 
>
>It is required under the GPL to supply the source *or* be able to point
>a user to the source if they want it.  Not that I dissagree with
>archiving it ourselves, but that wasn't my point.

Actually, this is a good point. We're providing a distribution for
end-users. They will want source on their CD, but if they're installing
via ftp over a modem, do they really want to pull over a package that's
1/5 bin and 4/5 source, and then only install the bin part of it?
Other distributions deal with that by having a bin package and a
source package. Is that the best way to do it?

>> In addition, it is protection for our users. Think of it as both a
>> security and a stability feature. Since the pristine source is obtained
>> from the official archive, there is less chance of malicious fiddling with

This is a good point. the key is that our primary developers won't be doing
*all* of the packaging. we'll be getting random packages from people saying
"hey, use this." A lot of programs are big enough that it would be very
difficult to hunt for a backdoor somebody had introduced. The first thing
I'd do would be to diff against a copy that I trusted. So....

>> that source by someone. The diff against that source is scrutinized as a
>> sanity check. We need to make sure that no obvious security holes are
>> inadvertently created and that the package does things according to
>> policy. The package in then compiled on a reference machine to provide
>> stability. After testing, the source, diff AND THE RESULTING BINARY

Is it the original pristine source, or the source with the diff integrated?
(Sorry, I've not used debian packages yet.) If it's the pristine source,
I suspect Debian users would get pretty good with the diff command pretty
quickly. I don't want to do that to our users. At least, not without a
pretty gui for it.

>> package are placed on the FTP site for download.  Binary packages will not
>> be accepted for UPLOAD but most customers will be downloading the
>> resulting binary package.
>
>What you're saying here is that our developers aren't trusted to QC the
>source.  I seriously doubt that Bruce sat up every night QCing compiling
>and packaging over 2000 packages.  I've browsed the incoming at Debian
>and they are deb files.

Yes. We cannot trust everybody who makes a package. That's life. I
doubt Bruce did that too, but I suspect somebody "in the Debian chain of
command" has done that for every one of the .deb packages they offer in
their distribution.

>Again.  I am not talking about Debian packages specifically.  Where does
>the GPL specify that anybody has to make a dif to the original source?

It doesn't. But it sounds like it might be a good idea.

>All that is "required" by the GPL is that the source is *available* to
>the user.  It doesn't matter if it's on our site or the originating site
>if the "source" is unchanged.  

On the other hand, let's try to be user-friendly here. We're probably
going to have a neat gui for going out and fetching source, and maybe
even unpacking it afterwards, viewing it, editing it, making it, whatever.

So let's put all the source on one site -- ours -- so it doesn't keep
disappearing from us when other sites go down.

>Again.  My point isn't whether or not we archive the source for the
>user.  It's probably best if we do.  My point is that there is no reason
>why a person can't *add* a script that improves the software from an
>end-users standpoint that *doesn't* modify the original product, and
>submit that in a binary package.  If we want to archive the source, as
>you are saying, then that same user can just transfer the original
>tarball from the programmers site to the SEUL archives in addition to
>the binary package.

We might allow that. It's borderline in terms of policy. I want to be
very certain that the binaries we're giving our users are the ones that
we'd get if we got the source and did it ourselves. It would be nice if we
could trust everybody out there. Maybe we can. But I'm paranoid.

>That will make life easier for everybody since the compiling will not be
>done by the same one, or two people.  We are talking about thousands of
>packages.

seul-dev-distrib really isn't all that small. And they really don't
have very many other tasks, besides poking at the packages we give
them. In fact, that's their job. They're supposed to make sure all
the packages look good, work, and are configured how we want them.
Right?

--Roger

===
SEUL-Leaders list, seul-leaders-request@seul.org
===