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]

exchange with Richard Stallman

Here's my take on this:

(1) Unstripped executables probably have some technical advantages in
some circumstances.  I don't think it's reasonable to require this for
debian 1.1.  I don't think it's reasonable to require strip for a base
system until its size can be brought down (it's nearly 200k).  I can
think of several viable ways of building unstripped debian packages,
but somewhere you have to deal with storage management.  More thought
needed here.

Personally, I'd be happy to distribute the packages I maintain,
unstripped.  I'd even be willing to dual-upload: once to an FSF disk
(unstripped) and once to a debian site (stripped).  I'd want to think
a little bit about conventions (e.g. naming, announcements, dpkg)
before implementing this.  I wouldn't want to bother if no one else is
interested.

(2) Encouraging people to write documentation is very different from
mandating people write documentation in texinfo.  I think it's
reasonable to point people at the texinfo documentation from the
debian standard, and suggest that it's a acceptable format for
material that's a mixture of user manual and reference.  I wish I knew
more about how to convert this format to html.  Html seems more
oriented towards small documents and live presentation.  Texinfo
better for printed manuals and lots of information.  The info browser
has its flaws, but it will let you interactively search multiple files
for a single string -- this alone has saved me hours of time
(libc.info).

(3) I think we're already working on a simpler installation with clear
documentation.  If we want trivial X configuration, we should probably
focus on vanilla 640x480 configurations for the mono and 16-color x
servers.  I agree that putting disk partitioning in an "experts only"
area is probably a good idea -- it is possible to trash a disk in
fdisk -- but if it's not trivial, it's not for 1.1.

(4) RMS's point 4 is not completely clear to me.  I don't think we'd
run into any problems if we gave him permission to distribute copies
of the specs with phrases which offend him removed.  Perhaps these
should be re-labeled as GNU specific specs?  I suppose the point is
that having a forked standard is probably a bad idea?


Other than point 4 (which maybe I don't understand), I think all of
Richard's points have some valid technical basis.

Instead of making a blanket statement out of this ("we can't work with
you"), maybe we should factor this into the individual concepts?  I
feel very comfortable saying "we won't be able to put this into 1.1".
I feel quite a bit less comfortable saying "we don't want to tackle
these issues."

-- 
Raul