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]

Message-ID: <4B75B2A6.5080006@lougher.demon.co.uk>
Date:	Fri, 12 Feb 2010 19:57:26 +0000
From:	Phillip Lougher <phillip@...gher.demon.co.uk>
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

Jean Delvare wrote:
> On Fri, 12 Feb 2010 19:02:39 +0000, Phillip Lougher wrote:
>> 5* Archive all the older 2.6.x files and move them into a separate
>>     directory (e.g. v2.6-pre20).  Moving all the pre 2.6.20 files
>>     saves 42% of the file listing.
>>
>> This seems an obvious solution, what am I missing?
> 
> This is confusing, inconsistent and unstable. Confusing because 2.6-pre
> referred so far to the releases immediately preceding 2.6.0.

I didn't say "2.6-pre", anyway it could be called something different,
like 'older-releases'.

> Inconsistent because it requires the downloader to have preliminary
> knowledge about what the break point is. Unstable because, while you
> consider pre20 to qualify as "old" today, in 5 years you will want
> pre30 to qualify as "old" instead, meaning that tools such as ketchup
> would have to be updated once again.

You yourself said "I wouldn't worry too much about breaking the current locations.
Just give some time for software authors (ketchup comes to mind) to update
their code and it shouldn't be a big problem."

The major advantage with my suggestion is for the majority of users/tools
interested in "recent" kernels, nothing changes at all.  Your suggestions
break everything for everyone.

> 
> I think we want to come up with a directory structure which won't change
> in the future.
> 

I think trying to do that is utterly futile.

Phillip
--
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/