lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 12 Feb 2010 07:21:37 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jean Delvare <khali@...ux-fr.org>
cc:	"J.H." <warthog9@...nel.org>,
	"FTPAdmin Kernel.org" <ftpadmin@...nel.org>, users@...nel.org,
	lasse.collin@...aani.org,
	linux-kernel <linux-kernel@...r.kernel.org>, mirrors@...nel.org
Subject: Re: [kernel.org users] XZ Migration discussion



On Fri, 12 Feb 2010, Jean Delvare wrote:
> 
> Maybe that's just me, but my main concern is neither download times nor
> decompression times. My main concern is the access time to directory
> indexes when browsing the kernel archive, because there are 5 entries
> for every patch or tarball: .bz2, .bz2.sign, .gz, .gz.sign and .sign.
> This is horribly slow.

This was actually the main reason for me personally to ask about just 
dropping support for .gz files - not because I care deeply about how much 
disk space kernel.org wastes, but because the long directory listings make 
it slower for me to mentally index the directory.

> 1* Keep a single compression format. This saves almost 40% of the
> files.
> 
> 2* Move one of the compression formats somewhere else, so that it
> doesn't get in the way but is still available if needed.
> 
> 3* Create a new subdirectory for every 2.6.x kernel, and move all the
> related files there.

I did 3* for the testing kernels (exactly because the directory listing 
got to be unreadable), and you just complained about it ;)

Of course, your complaint was that the subdirectory wasn't done 
immediately, and that the old files get moved to their own subdirectory 
later as a "archival" thing.

I just didn't want to change the location for the latest kernel.

> 4* Get rid of the LATEST-IS-* files. This is a small count, won't save
> much, but these files seem totally useless to me these days.

Yeah, they also end up continually being stale.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ