linux-kernel - Re: [kernel.org users] XZ Migration discussion

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 11:02:52 -0800
From:	"J.H." <warthog9@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Jean Delvare <khali@...ux-fr.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 02/12/2010 07:21 AM, Linus Torvalds wrote:
> 
> 
> 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.

It's probably worth keeping things like the .gz files around, if nothing
else for older distros, systems, etc that don't have xz yet (since it's
still relatively new)

Breaking things out into directories or such might be the easiest way
with that

v2.6/
v2.6/2.6.23
v2.6/2.6.32.6

etc

Would clean up the v2.6 directory a lot.

>> 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.

Only thoughts there are that there seem to be a lot of automated
processes that rely on LATEST-IS-*.  Personally I'd rather see them snag
the RSS feed and figure out what they want from there, but that may not
be completely feasible.  It also gives a quick indication as to what's
latest in the directory and a quick search on the page usually gets me
what I'm looking for when I do it.

- John 'Warthog9' Hawley
--
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/