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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Feb 2010 22:59:23 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Phillip Lougher <phillip@...gher.demon.co.uk>
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 19:57:26 +0000, Phillip Lougher wrote:
> 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."

Yes, I did say that, and I can repeat it if needed. There's a big
difference between breaking an old scheme which used to be valid and
happens to no longer be, and designing a new scheme where breakages are
bound to happen by design. Even if technically that's the same
breakage, its reception by the affected users will be very different,
because in the latter case you have no excuse.

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

Prove it. Many people out there are still working on older trees. I am
working on 2.6.5 and 2.6.16 kernels on a weekly basis. If ketchup or
other tools break for these trees only and not more recent ones, that
won't help me at all, I will still have to update them.

> Your suggestions break everything for everyone.

This doesn't make me happy, but at least it is consistent and durable.
When you change something for everyone, it has the advantage that the
solutions are general, come quickly and are widely documented. Using
quirks to limit the effects is a burden for the future, and may not
even help that much in practice.

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

You didn't have to join this discussion in the first place.

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