The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

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

FSF negociations



Bruce Perens:
 > I need a poll on how positive or negative you guys are on these FSF
 > requests: 

My overall take is: these are DESIGN issues.  We're not ready to talk
about implementation on any of them.  There's some serious design work
needed here.

 > 1. Install 100% unstripped executables on the hard disk.

I think this would be a mistake to do right now.  However, I can seem
some value to this.  I think it's feasible (and perhaps even a good
idea) to eventually support X% unstripped executables on the hard
disk.  However, at the moment, I think we should expect X to be rather
low.

I can see that providing 100% unstripped executables to a variety of
desktops would allow the development of some really neat system
integrity and administration tools.  I don't think that the right way
to go about it is to force everyone to pay the infrastructure cost for
such tools long before they're deployed.

 > 2. Install source code on the hard disk whenever the binary package is
 >    installed.

This is a configuration issue.

It should not be required.

I can see that, in the long run, a system which deals with system-wide
configuration at the source code level would be more secure, and
considerably smaller than the present debian distribution.  However,
most packages are not designed this way -- even GNU packages aren't
really designed this way.

I think it's perfectly reasonable to include some (even all) source in
a specific package, and provide a configuration interface which uses
the source and the development environment to build reconfigured
executables.  I can see the linux kernel evolving in this direction.
I can see qmail evolving in this direction (though it's further from
this point).  This fits with the "don't re-invent the wheel" concept
of good software development -- the development environment provides
some incredible configuration capability, why bother re-inventing an
inferior subset?

I imagine some people even would like the concept that a package can't
be easily reconfigured once the development environment is removed
from the system.

But, this is NOT something for the immediate release of debian.  It's
something debian might evolve into but on a package-by-package basis.
Also, before we tackle something like this, we need someone who really
understands existing configuration systems some dominant source-code
standards: BSD, GNU, RedHat, X.  Ideally, we'd like a base standard
that interoperated well with all of these -- and perhaps some
specifics oriented to these (and other) flavors of source.

 > 3. Make X-Windows, Emacs, and VI standard, not optional, parts of
 >    the system.

Again, not for 1.1

More to the point, this is a semantic issue as well as a labelling
issue.

At the moment, we've been operating (with varying degrees of success)
that there's only one rating system for determining desirable
packages.  I can see the need to provide hints for a variety of system
models.  The GNU double-decker bus model could be one of these.  The
"debian minimal core" serves a different purpose and it should stay
the way it is.

At the moment, I'm more interested in issues for getting up something
reasonably managable in a networked environment (where you don't want
to have a hundred machines each with several hundred megs of the same
stuff which is occasionally used by only a few people).  Note that
there's a lot of software development activity going on here so a lot
of what needs to happen is outside the scope of debian -- but that
also implies a need for some thought about migration paths.

Conclusion: this stuff is a lot of work.  I can see the value of doing
the work, but I don't think anyone currently involved in the debian
project is prepared to do it right now.

-- 
Raul