[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments please



On Wed, 28 Jan 1998, Rick Jones wrote:

> That is the problem with the dependancies I was refering to. 

What problem?  Red Hat is dependancies too.  It just does not let you know
about them until you waste your time downloading a package and then try
to install it and fails because you need something else.  So now you
download and install it and THAT fails because you need to upgrade
yet something else.  

The entire point of Debian's system is that you know at the start
everything you need to do to get a certain package installed.  You see
that as a weakness, I see that as a major benefit.

> Reguardless of that problem being fixed or not, it is a black mark on
> Debian's record and I don't think we should stigmatize our distro by
> saying we are using it. 

Stigmatize?  Huh?  It would be stigma to use Red Hat or Slackware. It is
far more advanced than any other distribution. It beats the pants off of
Red Hat or Caldera or Slackware. I have used all four of them. If
anything, I feel that Debian is vastly superior.  Its weakpoint is the
dselect program. We will not use it and Debian is replacing it too. 

Debian has the potential to be MUCH more user friendly then any of the
others if it has a good enough front-end.

> If we do use it, I assume you mean the handling
> methods not dselect, we would ofcourse include a statement in the readme
> or whatever that it is based on Debians dpkg etc.

I would surely HOPE that we would not use dselect.  It is much too complex
for a new user.  As for dpkg, that is the program that unpacks .deb
packages ... just like rpm is the program that unpacks .rpm files.  To
manually install a package you issue a dpkg -i <packagename> command. Any
system that uses .deb files is going to need dpkg.
> 
> I'm not at all against using dpkg, with the dependancies fixed.

What fix?  I think you are confused between dselect and dpkg.  As for
dependancies, rpm and dpkg behave about the same.  As a matter of fact,
dpkg was used as the model when rpm was designed.  

Debian has a thing called the Packages file that a program can download
BEFORE it upacks the packages to make it aware of potential conflicts
earlier in the process ... I still do not see whay you see that as a
weakness.

> I am
> just aprehensive of prominantly displaying that given that it does have
> a bad reputation, even if it is an exagerated reputation.

Bad reputation ... where?  Debian is in many of the latest polls I have
seen such as at slashdot.org the #2 Linux. As I said, the only bad rep
they have is due to dselect.  Can you think of any other?

> 
> > 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.
> 
> The last I heard from Bruce was that he wasn't promissing anything, but
> would "give us a shot...don't blow it."

I ment SEUL's project leadership, not Debian's. 


> While that isnt't flat out
> refusal, it doesn't sound like an "effort" on their part.

What I read Bruce's comment to mean was "we aren't going to bet the farm
on you till we see some product." 

> Sounds like
> they might if it suits them.

Should they if it doesn't?

> I have nothing against Bruce, or Debian. 

You just said it has a bad reputation and that its dependancies were
somehow broken.  I would say that you SOUND like you have a lot against
Debian.

> I have used Debian for over 2 years and am pleased, for the most part,
> but given that Bruce posted that when a discussion about the
> "cooperative effort" was going on in the list, I tend to think he was
> letting us know that some of us were reading a bit too much into the
> cooperation.

I think the ball is in our court. Those guys are busting their rears
producing a distribtion for exactly zero pay.  You can not say the same
for ANY other distribution.  Their plates are pretty full and I do not
blame them for not wanting to commit to a lot more work at this point.
They are addressing many of the same issues that we are only they are
operating on a different priority schedule.  Yes, they realize the user
interface for newbies sucks, they are working on it.  In the meantime,
they have to keep the rest of the distribution current with the rest of
the community. They can have an obsolete distribution with a great
interface OR they can have a great distribution with a difficult but
improving interface.  We stand to speed up their interface development and
they can keep the main guts of our distribution up to date.  It can be a
win-win situation.

> I absolutely agree.  My impression from your doc was that we, basically,
> won't make a move without Debian. 

Well, that is not true.  We are not going to START till 2.0 is released
because that gives us a complete distribution to start with but where we
go from there is anyone's guess.  Debian can save us a lot of work in the
guts because they can be trusted to provide core programs that are FSH
compliant, they are responsive to bug reports, and their stuff is well
integrated.  This allows us to devote our fledgling resources to the
installation, package selection, desktop and array of applications. As we
grow and become more popular, we will quite likely take over the
maintainance of more packages that will be unique to SEUL. 


> I'm saying we shouldn't have to do or
> not do anything because Debian does.

We are completely free to diverge from Debian wherever it is in our
interest to do so. When we do that, we take on the responsibility of
having to maintain those things from then on.  In the beginning, while we
are small, it might be in our best interests to concentrate our resources
in the areas that are of the highest priority and leave the more mundane
parts of the distribution to someone else ... in this case, Debian. 

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

Thank you for pointing that out.  I will keep that in mind.


> 
> > The last thing the world needs, in my opinion, is yet another incompatable
> > linux distribution. 
> 
> SEUL's goal is to be _a_ leader in the cause to standardize Linux
> distro's.

Yes ... eventually.  We need to crawl before we can walk.


> We should standardize things efficiently.  That makes it
> attractive to others to follow and vendors to endorse.

I completely agree. That is the main reason for glibc. Remember, there is
a larger goal as well.  86Open is shooting for binary compatablility
between Linux, SCO, Solaris x86, and *BSD (without iBCS). I would like to
see SEUL as a major contributor in this effort.  It GREATLY expands the
range of available applications.

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

Red Hat is commercial.  They are going to support what is in there best
interest commercially to support.  rpm sucks, glint sucks. They have a
brain-dead package manager sitting on a half-hearted copy of dpkg. We
could use Red Hat but would have to invent something like diety and
Packages files for it.

Here is an example: There is a project called diety. How much do we know
about it?  How involved are we in it?  Will we adopt it?  Will it be
designed with our interests in mind?  Can we get someone on board with
that project to influence its development, contribute to the code and see
that it DOES take our interests into account? If they have 5 people
working on it and one of our people joins the project, they gain a
developer, we gain 5. If we can not spare 6 for a project of our own, can
we spare 1 or 2 to assist in a project well underway someplace?  As we
grow we can always apply more resources.

Rather than making large investments of scarce resources to reinvent
wheels, can we invest our resources in shaping wheels currently under
development? Can we adopt and modify already invented wheels UNTIL we get
larger?

I think it is not only prudent but probably key to our survival to do so.
We can get on board other projects, not within Debian or the Debian
community.  Can a person be dispatched to Gnome rather than stand around
waiting for Gnome to be released?

Believe me, the concept for SEUL is very important. I will make every
attempt to influence others with the concept. I do not thing divergence is
the key ... standardization is. It is give and take.  It is a heavy ship
sailing through space and we might need several bursts from a small
thruster to put us on our course to our goal rather than a single large
one with no reserve if things shange on the way.

 
> Remember, we are trying to lead, not follow.  

True enough, but we must set an example in order to lead, we can not
simply command the linux community to follow.  They are going to look to
us and see what we have to benefit them.  


> The good aspects of Debian
> are going to augment SEUL, along with any other distro with good
> aspects.

That is true. It so happens that the bad aspects of Debian are also our
main goals for improvement and the good aspects of debian free up our
resources to concentrate on those bad aspects.  That makes it a great fit.

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

Yes!

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

I would expect Red Hat, and a lot of other distributions to adopt our good
ideas ... maybe even feed us back improvements.  That is what FREE
software is all about.  They are free to completely copy everything we do
if they want to .... and make a bundle off of it. It is separate only to
the extent that other distro's do not want to adopt our ideas.  We are, as
I see it, not out to make ourselves different than other linux
distributions.  THe goal is for a STANDARD core (meaning no different than
any other) with a great user interface that, hopefully, the other
distributions adopt.  We are, in REALITY, not out to be "different" so
much as I think we are out to be the reference standard.  Hopefully all
distributions would adopt out tools and we actually become a subset of
them ... or better ... they become a superset of us.


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


Think of it as an augmentation to linux ... not Debian. Debian is just the
best platform to build on at this point.


> This is the purpose of SEUL.  To do it better and make it appeal to the
> other distros to follow our lead.

And then surpass us.  

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

RIght, that includes your changes.  In other words, the complete source
code of what you are running, this includes the origianal source and all
changes made by you.

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

I am sure that our current developers certainly are. WHo knows who will
show up in the future.  Debian has a very strict policy for uploading.
You must meet in person with another developer and you must show
identification such as a passport, drivers license, or birth certificate.
You must have PGP and have your key signed by other developers. You must
PGP sign all uploads and if you are not on the maintainer keyring, your
upload is rejected.  These are rather strict security measures.  We do not
have enough people and are too scattered to duplicate them.  In that case,
I suggest that 1) we trust the original source, 2) we trust the debian
developers 3) we trust the diffs that our people submit.

Remember the cc thing? The original cc had a back door. Whenever it
compiled a certian program, it compiled that backdoor into it. If it was
recompiling itself, it checked to see if the source had that backdoor code
in it, if not, cc compiled the backdoor into the new cc anyway.

I would like to make that more difficult.


> 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?

You are free to modify the source but you must make your changes
available.  It is just easier to make a diff of your few changes than to
upload the entire source including your changes.

> I hate to get off on a tangent, since this is not my point, but which
> GPL are you talking about?  I have never d/l'd a tarball that had a diff
> in it for each person that modified it since the original.

But that tarball had to contain each change.  Think of it this way ... if
there is a 6Meg source ... the kernel for example. And I make about 100
bytes of changes.  I either have to upload the ENTIRE 6Meg source that
includes my changes OR I may upload a diff that can be applied to the
original source to produce a duplicate of my source.



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

The source of your changes included.


George Bonser 
If NT is the answer, you didn't understand the question. (NOTE: Stolen sig)
http://www.debian.org
Debian/GNU Linux ... the maintainable operating system.

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