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]

Re: FSF negociations



While I vote no on everything, I have a few thoughts for solutions
which may come closer to meeting FSF's suggestions without Debian
giving in to unworkable ideas.  I know I may be putting my foot in my
mouth by making any suggestion at all, but here goes.

>>>>> "Bruce" == Bruce Perens <bruce@Pixar.com> writes:

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

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

We need a good method for allowing bugs to be solved, both by users,
when they are willing, and by the maintainers/developers.
Realistically, unstripped executables are too big.  My answer is no,
unless someone comes up with a brilliant suggestion for avoiding the
disk usage and download time.

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

Source code should be *real* easy to install along with a package.
For some future release of dpkg or dselect, would it be possible to
give an option to install the source code along with a package?  Of
course, the source code would have to be downloaded first.  Very few
people would do this, but it *may* be a simple extension to dpkg, and
it *may* make the FSF happier.

I would also like to see an ftp option to dselect, but I am so far
unwilling to do the work myself.

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

The essential parts of Linux should be as small as possible.  Perhaps
priority should be a bit more standardized.  vi or emacs could be
"suggested", maybe even "important", but not "required".  Perhaps we
could meet FSF part way here, without giving up our preferences.
Clearly, an editor as a real nice thing to have.  Suggesting an editor
may make installation easier for an experienced Unix person.
Likewise, within the X11 section, it would nice to quickly determine
the packages which are likely to be necessary, given that I want X.
However, X should not be absolutely required.

Perhaps, some time after the 1.1 release, we can rethink priorities a bit.

Kevin Dalley
kevin@aimnet.com