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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ