linux-kernel - Re: From 2.4 to 2.6 to 2.7?

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:	Sun, 20 Jul 2008 01:10:48 +0200
From:	"Peter T. Breuer" <ptb@....it.uc3m.es>
To:	Craig Milo Rogers <rogers@....EDU>, linux-kernel@...r.kernel.org
Subject: Re: From 2.4 to 2.6 to 2.7?

Craig Milo Rogers <rogers@....edu> wrote:
>>    rename 2.6.28 to 2.8.0
>> or 
>>    rename 2.6.29 to 2.9.0
>> or
>>    rename 2.6.30 to 3.0.0
>> 
>> i.e. .. whatever you are doing now, just drop the first two numbers (the
>> "2.6" bit) since they seem to be constant.

> 	So you're saying that the formula is to drop the "2.6" and place
> a period between the first and sedond digits of what's currently the
> release number? OK, I hadn't interpreted it that way.  Does the sequence
> continue like this?

The point is to rebase to a new system at a point coming up which is
convenient.  There is an opportunity at 2.6.28, which can be renamed
2.8.0, dropping the constant 2.6.

I suppose one counts 2.8.1, 2.8.2 from then on, or does whatever else
one wants to do.  I don't know - Linus' only objective is to get smaller
more meaningful numbers and the details of how one counts afterwards
don't matter.

Or if one misses the 2.6.28 point, one gets another good opportunity for
rebasing at 2.6.30, which could become 3.0.0, dropping the constant 2.6
again.

>> Remember that Linus' only objective is to have smaller numbers, which
>> may therefore
>> 
>>  1) be memorable
>>  2) be good advertising copy
>>  3) be meaningful
>> 
>> and that was the only intention of my scheme: "drop the constant bit".

> 	And the underlying problem is that there are only so many
> small numbers. 

We need smaller numbers now.

I.e.  We're happy with the system we've got, except for the high
numbers we're at, so just rebase.

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