| 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
| ||
|
Date: Fri, 12 Feb 2010 20:23:57 +0100 From: Jean Delvare <khali@...ux-fr.org> To: "J.H." <warthog9@...nel.org> Cc: Linus Torvalds <torvalds@...ux-foundation.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 11:02:52 -0800, J.H. wrote: > 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) Hardly a good reason IMHO. xz can be installed on these systems. When we switched to git, nobody had it and it did not stop us. > > Breaking things out into directories or such might be the easiest way > with that > > v2.6/ > v2.6/2.6.23 Yes. > v2.6/2.6.32.6 I'd rather group all 2.6.32.* files together, so that the main index is as small as possible. We're adding one indirection step, so it should be fast. > > etc > > Would clean up the v2.6 directory a lot. > >> (...) > >> 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-*. Care to give details? Given how often the old files get stuck, I am surprised any process can really rely on them. And I also can't really think of any automated process that would care. > 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. There's RSS, there's a mailing list and there's a web page. Certainly one of these 3 methods would work. > It also gives a quick indication as to what's > latest in the directory Sorting by time works just as well. > and a quick search on the page usually gets me > what I'm looking for when I do it. What's your workflow? I normally go to the download directory after either reading the kernel.org main page or some post on the announce mailing list. So I already know which version I am looking for. Having to search for "LATEST-IS" and then again for the version doesn't look terribly efficient. If we really want a helper to locate the latest version, I'd rather have a "latest" symbolic link pointing to the most recent v2.6.x subdirectory. Or maybe two, "latest-stable" and "latest-devel". Can be discussed... -- Jean Delvare -- 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