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: Compression through e2compr

Christoph wrote:
> I really wish we would get rid of compression requirements. We still have
> no sane way of compressing .html files and preserving link integrity.
> Could we agree on making compression recommended for now? If that kernel
> level compression really works out then we can gradually back off from
> compressing files with gzip (debmake users will just have to rebuild to
> get a package without compression some day).

I'm doubt you're suggesting that we recommend it now, but just in case:
I don't think we should yet.

If you're suggesting that we recommend it as soon as we've had time to
test it, and it's gone into the standard kernel sources, then that's
probably a good thing, assuming our testing is/was comprehensive enough.

I think we should test how it relates to speed.  If it gives faster disk
I/O on a P90 with a load-av of 1.0 (before starting the test), then I
think we could recommend (but not require) it, for a moderate-usage
desktop machine.

We also should consider what it would do on a single-CPU (or MP!) server
with many people/processes writing.  If it does turn out to be faster on
a reasonably loaded one-user machine, that doesn't mean it'd be a gain
on a high-end server with a fast disk controller.  Note that it's common
to take a machine with a moderate CPU and blazing disk I/O and
networking, and make it a fileserver or similar (EG Auspex).

We should also test it overtop of md.

We should also test how it performs at reading and writing
already-compressed data.  If it performs poorly at this, that should
make any recommendation more situational.

Yes, we can make some reasonable predictions about how it should behave
in these circumstances, but we don't have good reason to draw
conclusions until it's been tried.

Some things should always be explicitly compressed, EG .deb files.   But
many things would indeed benefit from implicit compression.


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com