linux-kernel - Re: Linux 2.6.32-rc3

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: <20091007025147.2690ec23@schatten>
Date:	Wed, 7 Oct 2009 02:51:47 +0200
From:	Florian Mickler <florian@...kler.org>
To:	Frans Pop <elendil@...net.nl>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, hohndel@...radead.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Linux 2.6.32-rc3

On Tue, 6 Oct 2009 20:29:08 +0200
Frans Pop <elendil@...net.nl> wrote:

> On Tuesday 06 October 2009, Linus Torvalds wrote:
> > Have you missed the whole discussion about why it doesn't work?
> > Have you missed the point on why it is FUNDAMENTALLY WRONG to do?
> 
> No, I've followed the discussion. I guess I just disagree with you as my 
> perspective is different. I still think there are practical advantages to 
> it, even if it is not 100% theoretically correct from a versioning PoV 
> (which I've already said I agree with).

We shouldn't try to weaken the version-numbering-scheme
more. And every action which only 'suggests' that the version-number
has more weight, than it actually has is just papering over the real
bug. 

It works if you are only some bird sitting at
one branch of the kernel-development-tree (the git DAG, that is)
looking at what he thinks is the tip of the tree. 

But this scheme does not work in the 'decentralised' kernel-scenario.
Because if only one subsystem-maintainer forgets to 'put the zero' into
his branch, anybody who tries that branch is at the same situation
as before.  So it would be useless for any 'colaboration based effort'. 

Nice to have as a bird, but as a ranger you can't expect every tree to
have a tip. ( actually you can .. note to self: ... i'm getting
confused in this alegory... whatever... just relax, refocus and go
on.. ) 

On the other hand, if you could modify the DNA of the trees to make
them 
a) better, so they prevail and other trees extinguish over time and 
b) have him grow 'pluses' at the tip (or whatever distinguishing
feature a released tree exhibits ) the ranger could then wander through 
the forest and just look for pluses to do, whatever he needs to do
with those branches.. aerm trees ... ah whatever. 

i hope you are not lost in the woods, and to sumarize: i've no business
whatsoever in the linux-kernel, but read lkml instead of doing smth
useful. ah, and i think a change in the build-mechanics to distinguish
releases is the way to go, instead of a commit. 

but the problem you noted with the 'export' from git into the ''real
world'' is of course there. 
maybe there is a solution to this? eventually smth like "if you don't
use git you have to always tell the truth? or any other way to 
'dirty' the makefile at export-time ?  in-kernel boot-time checksumming
of the kernel-image? to get at least uname -r right?

dunno,
Florian

-- 
A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?  
>> A: Top-posting.  
>>> Q: What is the most annoying thing in e-mail?
--
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/