LinuxLists.cc - The naming wars continue...

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
> And the fact is, I can't see the point. I'll just call it all "-rcX",
> because I (very obviously) have no clue where the cut-over-point from
> "pre" to "rc" is, or (even more painfully obviously) where it will become
> the final next release.

This should be easy: the cut-over should be when you're tempted to
rename it 2.6.next. If you have no intention (or hope) of renaming
2.6.x-rc1 to 2.6.x, it is not a "release candidate" by definition.

What's the point? It serves as a signal that a) we're not accepting
more big changes b) we think it's ready for primetime and needs
serious QA c) when 2.6.next gets released, the _exact code_ has gone
through a test cycle and we can have some confidence that there won't
be any nasty 0-day bugs when we go to install 2.6.next on a production
machine.

> (*) In other words, I had a beer and watched TV. Mmm... Donuts.

Please devote some more beer and TV to this problem after you release
2.6.10.

--
Mathematics is the supreme nostalgia of our time.

2004-10-23 00:23:25

by Con Kolivas

[permalink] [raw]

Subject: Re: The naming wars continue...

Matt Mackall wrote:
> On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
>
>>And the fact is, I can't see the point. I'll just call it all "-rcX",
>>because I (very obviously) have no clue where the cut-over-point from
>>"pre" to "rc" is, or (even more painfully obviously) where it will become
>>the final next release.
>
>
> This should be easy: the cut-over should be when you're tempted to
> rename it 2.6.next. If you have no intention (or hope) of renaming
> 2.6.x-rc1 to 2.6.x, it is not a "release candidate" by definition.
>
> What's the point? It serves as a signal that a) we're not accepting
> more big changes b) we think it's ready for primetime and needs
> serious QA c) when 2.6.next gets released, the _exact code_ has gone
> through a test cycle and we can have some confidence that there won't
> be any nasty 0-day bugs when we go to install 2.6.next on a production
> machine.

I have this feeling Linus is laughing at us when he debates these
arguments. Nonetheless I finally feel obliged to say a "release
candidate" is a release candidate. It should only be called that if it
is planned to be the real version, and the real version is _exactly_ the
same bar the version number. If it isn't even planned to be released
unmodified it's a -pre patch.

/me still hears Linus laughing. He's only been doing this for 13 years.

Cheers,
Con

Attachments:

signature.asc (256.00 B)
OpenPGP digital signature

2004-10-23 00:08:48

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
> Linux-2.6.10-rc1 is out there for your pleasure.
> I thought long and hard about the name of this release (*), since one of
> the main complaints about 2.6.9 was the apparently release naming scheme.
> Should it be "-rc1"? Or "-pre1" to show it's not really considered release
> quality yet? Or should I make like a rocket scientist, and count _down_
> instead of up? Should I make names based on which day of the week the
> release happened? Questions, questions..
> And the fact is, I can't see the point. I'll just call it all "-rcX",
> because I (very obviously) have no clue where the cut-over-point from
> "pre" to "rc" is, or (even more painfully obviously) where it will become
> the final next release.
> So to not overtax my poor brain, I'll just call them all -rc releases, and
> hope that developers see them as a sign that there's been stuff merged,
> and we should start calming down and seeing to the merged patches being
> stable soon enough..

AFAICT the point is being able to refer to it by name and the only
relevant property of the name is that it's distinct from all others.
This does as well as most any other scheme giving each unique names.
I'd be fine with nightly point releases, though I don't insist.

On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
> So without any further ado, here's 2.6.10-rc1 in testing. A fair number of
> patches that were waiting for 2.6.9 to be out are in here, ranging all
> over the map: merges from -mm, network (and net driver) updates, SATA
> stuff, bluetooth, SCSI, device models, janitorial, you name it.
> Oh, and the _real_ name did actually change. It's not Zonked Quokka any
> more, that's so yesterday. Today we're Woozy Numbat! Get your order in!
> Linus
> (*) In other words, I had a beer and watched TV. Mmm... Donuts.

Sounds like a good way to come up with a new name to me. Cheers!

-- wli

2004-10-23 00:53:46

by Nigel Cunningham

[permalink] [raw]

Subject: Re: The naming wars continue...

Hi.

On Sat, 2004-10-23 at 08:05, Linus Torvalds wrote:
> Oh, and the _real_ name did actually change. It's not Zonked Quokka any
> more, that's so yesterday. Today we're Woozy Numbat! Get your order in!

I vote for a Klassy Kiwi release :>

Nigel
--
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Everyone lives by faith. Some people just don't believe it.
Want proof? Try to prove that the theory of evolution is true.

2004-10-23 01:19:22

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
>> And the fact is, I can't see the point. I'll just call it all "-rcX",
>> because I (very obviously) have no clue where the cut-over-point from
>> "pre" to "rc" is, or (even more painfully obviously) where it will become
>> the final next release.

On Fri, Oct 22, 2004 at 06:46:31PM -0500, Matt Mackall wrote:
> This should be easy: the cut-over should be when you're tempted to
> rename it 2.6.next. If you have no intention (or hope) of renaming
> 2.6.x-rc1 to 2.6.x, it is not a "release candidate" by definition.
> What's the point? It serves as a signal that a) we're not accepting
> more big changes b) we think it's ready for primetime and needs
> serious QA c) when 2.6.next gets released, the _exact code_ has gone
> through a test cycle and we can have some confidence that there won't
> be any nasty 0-day bugs when we go to install 2.6.next on a production
> machine.

I'm sure you have a well-founded logically consistent self-consistent
method of defining what release candidates are; unfortunately hordes of
others do, too, and their notions are in turn all subtly inconsistent
with yours and each other's, and they're all relatively vocal about them.

On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
>> (*) In other words, I had a beer and watched TV. Mmm... Donuts.

On Fri, Oct 22, 2004 at 06:46:31PM -0500, Matt Mackall wrote:
> Please devote some more beer and TV to this problem after you release
> 2.6.10.

Give the emperor penguin a break. There's bound to be enough weighing
on him as it is with just the usual barrage of technical issues. The
new release process hasn't even been given a chance to fail yet as the
two commercial distros with the largest userbases haven't even gotten
to the point where they've both released 2.6 yet, and debian isn't
using 2.6 as the install kernel yet either.

On Fri, Oct 22, 2004 at 06:46:31PM -0500, Matt Mackall wrote:
> Mathematics is the supreme nostalgia of our time.

It would be nice if this were qualified with something that distinguished
the outlandish idealizations you're actually criticizing from real math,
which makes no presumption that its axioms or hypotheses have any
connection to reality, observations, or predictions thereof. The abuse
you're speaking of is poor modelling for the sake of tractability of
symbolic calculations, which has nothing to do with proof or logic.

-- wli

2004-10-23 01:29:02

[permalink] [raw]

Subject: Re: The naming wars continue...

Hey guys, calm down, I meant "naming wars" in a silly kind of way, not the
nasty kind.

The fact is, Linux naming has always sucked. Well, at least the versioning
I've used. Others tend to be more organized. Me, I'm the "artistic" type,
so I sometimes try to do something new, and invariably stupid.

The best suggestion so far has been to _just_ use another number, which
makes sense considering my dislike for both -rc and -pre.

However, for some reason four numbers just looks visually too obnoxious to
me, so as I don't care that much, I'll just use "-rc", and we can all
agree that it stands for "Ridiculous Count" rather than "Release
Candidate".

More importantly, maybe we could all realize that it isn't actually that
big of an issue ;)

Linus

2004-10-23 01:37:40

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, Oct 22, 2004 at 06:15:49PM -0700, William Lee Irwin III wrote:
> On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
> >> And the fact is, I can't see the point. I'll just call it all "-rcX",
> >> because I (very obviously) have no clue where the cut-over-point from
> >> "pre" to "rc" is, or (even more painfully obviously) where it will become
> >> the final next release.
>
> On Fri, Oct 22, 2004 at 06:46:31PM -0500, Matt Mackall wrote:
> > This should be easy: the cut-over should be when you're tempted to
> > rename it 2.6.next. If you have no intention (or hope) of renaming
> > 2.6.x-rc1 to 2.6.x, it is not a "release candidate" by definition.
> > What's the point? It serves as a signal that a) we're not accepting
> > more big changes b) we think it's ready for primetime and needs
> > serious QA c) when 2.6.next gets released, the _exact code_ has gone
> > through a test cycle and we can have some confidence that there won't
> > be any nasty 0-day bugs when we go to install 2.6.next on a production
> > machine.
>
> I'm sure you have a well-founded logically consistent self-consistent
> method of defining what release candidates are; unfortunately hordes of
> others do, too, and their notions are in turn all subtly inconsistent
> with yours and each other's, and they're all relatively vocal about them.

Mine is the trivial one: a release candidate is something that is
intended as a candidate for release. I'm not suggested anything about
requirements for code quality, yadda yadda, just that there's an
intent to release the release candidates should they pass muster. That
does not appear to be the intent with most 2.6-rc of late.

> On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
> >> (*) In other words, I had a beer and watched TV. Mmm... Donuts.
>
> On Fri, Oct 22, 2004 at 06:46:31PM -0500, Matt Mackall wrote:
> > Please devote some more beer and TV to this problem after you release
> > 2.6.10.
>
> Give the emperor penguin a break.

But I did! He's got until after 2.6.10.

(yes, that probably warrants a smiley)

> On Fri, Oct 22, 2004 at 06:46:31PM -0500, Matt Mackall wrote:
> > Mathematics is the supreme nostalgia of our time.
>
> It would be nice if this were qualified with something that distinguished
> the outlandish idealizations you're actually criticizing from real math,
> which makes no presumption that its axioms or hypotheses have any
> connection to reality, observations, or predictions thereof. The abuse
> you're speaking of is poor modelling for the sake of tractability of
> symbolic calculations, which has nothing to do with proof or logic.

Actually just the opposite. It's more about Godel and Whitehead than
Feynmann in my interpretation.

--
Mathematics is the supreme nostalgia of our time.

2004-10-23 01:45:57

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, Oct 22, 2004 at 06:25:30PM -0700, Linus Torvalds wrote:
>
> However, for some reason four numbers just looks visually too obnoxious to
> me, so as I don't care that much, I'll just use "-rc", and we can all
> agree that it stands for "Ridiculous Count" rather than "Release
> Candidate".

I can probably live with that if you promise not to break the
automated tools for a while.

--
Mathematics is the supreme nostalgia of our time.

2004-10-23 01:50:12

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, 22 Oct 2004, Matt Mackall wrote:
>
> I can probably live with that if you promise not to break the
> automated tools for a while.

Ahh.. I just do it to keep you on your toes.

Don't get lazy on me now,

Linus

2004-10-23 02:13:07

by alan

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, 22 Oct 2004, Linus Torvalds wrote:

>
>
> Hey guys, calm down, I meant "naming wars" in a silly kind of way, not the
> nasty kind.
>
> The fact is, Linux naming has always sucked. Well, at least the versioning
> I've used. Others tend to be more organized. Me, I'm the "artistic" type,
> so I sometimes try to do something new, and invariably stupid.
>
> The best suggestion so far has been to _just_ use another number, which
> makes sense considering my dislike for both -rc and -pre.
>
> However, for some reason four numbers just looks visually too obnoxious to
> me, so as I don't care that much, I'll just use "-rc", and we can all
> agree that it stands for "Ridiculous Count" rather than "Release
> Candidate".
>
> More importantly, maybe we could all realize that it isn't actually that
> big of an issue ;)

Besides... -pre and -rc additions do not sort correctly unless your sort
routine has special cases to take care of it.

2004-10-23 02:39:09

by Eyal Lebedinsky

[permalink] [raw]

Subject: Re: The naming wars continue... - net/ipv4/netfilter/ipt_hashlimit.c does not build

Linus Torvalds wrote:
> Ok,
> Linux-2.6.10-rc1 is out there for your pleasure.

CC [M] net/ipv4/netfilter/ipt_hashlimit.o
net/ipv4/netfilter/ipt_hashlimit.c: In function `__dsthash_find':
net/ipv4/netfilter/ipt_hashlimit.c:124: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c: In function `__dsthash_free':
net/ipv4/netfilter/ipt_hashlimit.c:173: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c: In function `htable_selective_cleanup':
net/ipv4/netfilter/ipt_hashlimit.c:261: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:261: error: structure has no member named `l'
net/ipv4/netfilter/ipt_hashlimit.c:261: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:269: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:269: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:269: error: structure has no member named `l'
net/ipv4/netfilter/ipt_hashlimit.c: In function `hashlimit_match':
net/ipv4/netfilter/ipt_hashlimit.c:460: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:460: error: structure has no member named `l'
net/ipv4/netfilter/ipt_hashlimit.c:460: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:469: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:469: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:469: error: structure has no member named `l'
net/ipv4/netfilter/ipt_hashlimit.c:482: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:482: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:482: error: structure has no member named `l'
net/ipv4/netfilter/ipt_hashlimit.c:493: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:493: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:493: error: structure has no member named `l'
net/ipv4/netfilter/ipt_hashlimit.c:497: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:497: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:497: error: structure has no member named `l'
net/ipv4/netfilter/ipt_hashlimit.c: In function `dl_seq_start':
net/ipv4/netfilter/ipt_hashlimit.c:572: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:572: error: structure has no member named `l'
net/ipv4/netfilter/ipt_hashlimit.c:572: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c: In function `dl_seq_stop':
net/ipv4/netfilter/ipt_hashlimit.c:606: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:606: error: structure has no member named `locked_by'
net/ipv4/netfilter/ipt_hashlimit.c:606: error: structure has no member named `l'
make[3]: *** [net/ipv4/netfilter/ipt_hashlimit.o] Error 1
make[2]: *** [net/ipv4/netfilter] Error 2
make[1]: *** [net/ipv4] Error 2
make: *** [net] Error 2

--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>

2004-10-23 03:00:18

by Espen Fjellvær Olsen

[permalink] [raw]

Subject: Re: The naming wars continue...

On 10/23/2004 07:05 AM, Linus Torvalds wrote:
> Ok,
> Linux-2.6.10-rc1 is out there for your pleasure.
>
> I thought long and hard about the name of this release (*), since one of
> the main complaints about 2.6.9 was the apparently release naming scheme.
>
> Should it be "-rc1"? Or "-pre1" to show it's not really considered release
> quality yet? Or should I make like a rocket scientist, and count _down_
> instead of up? Should I make names based on which day of the week the
> release happened? Questions, questions..

Do the -rcs first, let them contain everything that should go into the
next release.
And when you feel that you have released enough -rcs(Uh, whenever that
is...) release the -pres.
They should only contain critical bugfixes before the final release.

--
Mvh / Best regards
Espen Fjellv?r Olsen
[email protected]
Norway

2004-10-23 03:05:23

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, Oct 22, 2004 at 06:08:12PM -0700, alan wrote:
> On Fri, 22 Oct 2004, Linus Torvalds wrote:
>
> >
> >
> > Hey guys, calm down, I meant "naming wars" in a silly kind of way, not the
> > nasty kind.
> >
> > The fact is, Linux naming has always sucked. Well, at least the versioning
> > I've used. Others tend to be more organized. Me, I'm the "artistic" type,
> > so I sometimes try to do something new, and invariably stupid.
> >
> > The best suggestion so far has been to _just_ use another number, which
> > makes sense considering my dislike for both -rc and -pre.
> >
> > However, for some reason four numbers just looks visually too obnoxious to
> > me, so as I don't care that much, I'll just use "-rc", and we can all
> > agree that it stands for "Ridiculous Count" rather than "Release
> > Candidate".
> >
> > More importantly, maybe we could all realize that it isn't actually that
> > big of an issue ;)
>
> Besides... -pre and -rc additions do not sort correctly unless your sort
> routine has special cases to take care of it.

I've got a good page or so of compare function in ketchup already, I'm
loathe to teach it about -final though.

--
Mathematics is the supreme nostalgia of our time.

2004-10-23 03:05:21

[permalink] [raw]

Subject: Re: The naming wars continue... - net/ipv4/netfilter/ipt_hashlimit.c does not build

On Sat, 23 Oct 2004, Eyal Lebedinsky wrote:
>
> CC [M] net/ipv4/netfilter/ipt_hashlimit.o
> net/ipv4/netfilter/ipt_hashlimit.c: In function `__dsthash_find':
> net/ipv4/netfilter/ipt_hashlimit.c:124: error: structure has no member named `locked_by'

Yes. Disable NETFILTER_DEBUG for now.

Linus

2004-10-23 03:13:59

by Randy.Dunlap

[permalink] [raw]

Subject: Re: The naming wars continue...

Espen Fjellv?r Olsen wrote:
> On 10/23/2004 07:05 AM, Linus Torvalds wrote:
>
>>Ok,
>> Linux-2.6.10-rc1 is out there for your pleasure.
>>
>>I thought long and hard about the name of this release (*), since one of
>>the main complaints about 2.6.9 was the apparently release naming scheme.
>>
>>Should it be "-rc1"? Or "-pre1" to show it's not really considered release
>>quality yet? Or should I make like a rocket scientist, and count _down_
>>instead of up? Should I make names based on which day of the week the
>>release happened? Questions, questions..
>
>
> Do the -rcs first, let them contain everything that should go into the
> next release.
> And when you feel that you have released enough -rcs(Uh, whenever that
> is...) release the -pres.
> They should only contain critical bugfixes before the final release.

Well, several of us think that -pre's should come before the
-rc's and not after them.

It appears that we should concentrate on the
NAME=Zonked Quokka
part of Makefile for our sanity.

--
~Randy

2004-10-23 03:05:20

by Wakko Warner

[permalink] [raw]

Subject: Re: The naming wars continue...

> The fact is, Linux naming has always sucked. Well, at least the versioning
> I've used. Others tend to be more organized. Me, I'm the "artistic" type,
> so I sometimes try to do something new, and invariably stupid.

Given that the versioning was supposedly <major>.<minor>.<patchlevel> and
the difference between 2.4 and 2.6 was substantial, why not just bump
<major> instead of the minor. Then we'd have 3.0, 3.1, 4.0, 4.1.1 (for
stupid mistakes). Isn't it time we move off the 2.x series and start
thinking of the 3.x series?

--
Lab tests show that use of micro$oft causes cancer in lab animals

2004-10-23 06:24:07

by Nick Piggin

[permalink] [raw]

Subject: Re: The naming wars continue...

Linus Torvalds wrote:

> More importantly, maybe we could all realize that it isn't actually that
> big of an issue ;)
>
> Linus

Linus I agree it isn't a huge issue. The main thing for me is that
I could just give a _real_ release candidate more testing - run it
through some regression tests, make sure it functions OK on all my
computers, etc. I expect this would be helpful for people with large
sets of regression tests, and maybe those maintaining 'other'
architectures too.

I understand there's always "one more" patch to go in, but now that
we're doing this stable-development system, I think a week or two
weeks or even three weeks to stabalize the release with only
really-real-bugfixes can't be such a bad thing.

2.6.x-rc (rc for Ridiculous Count) can then be our development
releases, and 2.6.x-rc (rc for Release Candidate) are then closer
to stable releases (in terms of getting patches in).

Optionally, you could change Ridiculous Count to PRErelease to avoid
confusion :)

Other than that I don't have much to complain about... so keep up the
good work!

Nick

2004-10-23 11:23:57

by Erik Hensema

[permalink] [raw]

Subject: Re: The naming wars continue...

Linus Torvalds ([email protected]) wrote:
> Linux-2.6.10-rc1 is out there for your pleasure.
>
> I thought long and hard about the name of this release (*), since one of
> the main complaints about 2.6.9 was the apparently release naming scheme.
>
> Should it be "-rc1"? Or "-pre1" to show it's not really considered release
> quality yet? Or should I make like a rocket scientist, and count _down_
> instead of up? Should I make names based on which day of the week the
> release happened? Questions, questions..
>
> And the fact is, I can't see the point. I'll just call it all "-rcX",
> because I (very obviously) have no clue where the cut-over-point from
> "pre" to "rc" is, or (even more painfully obviously) where it will become
> the final next release.

When you (Linus) think a release is ready to be released, call it
-rc1. If you did your job correctly, you can just sit and wait
for a few days and release the -rc1 as a new kernel.
In the real world though, some bugs may crop up, so you'd be
forced to release a rc2. Which in turn may be released unchanged
as the final kernel.

Releases prior to a release candidate can be called whatever you
like. I'd choose -preX ;-)

--
Erik Hensema <[email protected]>

2004-10-23 13:17:32

by markus reichelt

[permalink] [raw]

Subject: Re: The naming wars continue...

Linus Torvalds <[email protected]> wrote:
> (*) In other words, I had a beer and watched TV. Mmm... Donuts.

seems to be a good opportunity even though I'm a bit late, but could
you please include this patch, written by Heikki Linnakangas?

http://mareichelt.de/pub/boot-off-usb/boot-off-usb-2.patch

applies cleanly to 2.6.7 vanilla, thus making boot off usb devices
possible

--
Bastard Administrator in $hell

Attachments:

(No filename) (414.00 B)
boot-off-usb-2.patch (4.45 kB)
Download all attachments

2004-10-23 13:21:24

by Christoph Hellwig

[permalink] [raw]

Subject: Re: The naming wars continue...

> o generic acl support for ->permission

..

> o xattr consolidation v3 - generic xattr API

Jeff, you'd been doing most reiserfs work lately - any chance to convert
reiserfs to these generic APIs? Once we have all filesystems converted
over maintaince will be much simpler. Take a look at ext2, ext3, or jfs
on how to use them - I'll do xfs in the meantime.

2004-10-23 13:20:09

by Chuck Ebbert

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, 22 Oct 2004 at 18:15:49 -0700 William Lee Irwin III wrote:

> I'm sure you have a well-founded logically consistent self-consistent
> method of defining what release candidates are; unfortunately hordes of
> others do, too, and their notions are in turn all subtly inconsistent
> with yours and each other's, and they're all relatively vocal about them.

Others are arguing about _subtle_ differences; what Linus did was huge
by comparison. It's as if they were discussing what shade of red to call
something and Linus came along and declared it green!

"Release candidate" means candidate for release. Simple and easy to
understand, no? Does Linus plan on possibly releaseing -rc1 as 2.6.10
tomorrow? I don't think so...

I plan to start testing 2.6.10 upon its final release.

--Chuck Ebbert 23-Oct-04 09:18:15

2004-10-23 14:35:11

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, Oct 22, 2004 at 06:15:49PM -0700, William Lee Irwin III wrote:
>> It would be nice if this were qualified with something that distinguished
>> the outlandish idealizations you're actually criticizing from real math,
>> which makes no presumption that its axioms or hypotheses have any
>> connection to reality, observations, or predictions thereof. The abuse
>> you're speaking of is poor modelling for the sake of tractability of
>> symbolic calculations, which has nothing to do with proof or logic.

On Fri, Oct 22, 2004 at 08:35:18PM -0500, Matt Mackall wrote:
> Actually just the opposite. It's more about Godel and Whitehead than
> Feynmann in my interpretation.

"The notion of a perfectly modellable world is dead" and branding a
field with the sins of those who misapplied it is not difficult to
understand. Worse yet, it's even arguable that even the idealizations
were done in full cognizance of their limited validity. Whatever else
you're reading into it is not there. I suppose in this and the instance
of some religiously-oriented .sig's there is little or no recourse.

-- wli

2004-10-23 14:47:11

by Taso Hatzi

[permalink] [raw]

Subject: Re: The naming wars continue...

On Sat, 23 Oct 2004 03:40:06 +0200, Linus Torvalds wrote:

>
> However, for some reason four numbers just looks visually too obnoxious to
> me, so as I don't care that much, I'll just use "-rc", and we can all

Drop the '2.'. What would make you go from 2 to 3 and realistically, is
it likely to happen?

In any case, if you replace the '-rc' suffix with just a number it will
be interpreted as 2.x.y.1 is better than 2.x.y which is a nonsense.
The "-rc" nomenclature makes it clear that the release will be 2.x.y

2004-10-23 14:51:18

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, 22 Oct 2004 at 18:15:49 -0700 William Lee Irwin III wrote:
>> I'm sure you have a well-founded logically consistent self-consistent
>> method of defining what release candidates are; unfortunately hordes of
>> others do, too, and their notions are in turn all subtly inconsistent
>> with yours and each other's, and they're all relatively vocal about them.

On Sat, Oct 23, 2004 at 09:17:52AM -0400, Chuck Ebbert wrote:
> Others are arguing about _subtle_ differences; what Linus did was huge
> by comparison. It's as if they were discussing what shade of red to call
> something and Linus came along and declared it green!
> "Release candidate" means candidate for release. Simple and easy to
> understand, no? Does Linus plan on possibly releaseing -rc1 as 2.6.10
> tomorrow? I don't think so...
> I plan to start testing 2.6.10 upon its final release.

Logical consistency can be quantified no further than consistency or
inconsistency. There is no useful notion of degree of such.

-- wli

2004-10-23 15:41:51

by Stephen Frost

[permalink] [raw]

Subject: Re: The naming wars continue...

* Linus Torvalds ([email protected]) wrote:
> However, for some reason four numbers just looks visually too obnoxious to

I agree, four numbers is *very* obnoxious, I mean, really, if for no
other reason than *Oracle* uses four numbers. :)

Stephen

2004-10-23 15:45:00

by Hans Reiser

[permalink] [raw]

Subject: Re: The naming wars continue...

Christoph Hellwig wrote:

>
>Jeff, you'd been doing most reiserfs work lately
>
good stuff you are smoking, yes?

2004-10-23 21:27:29

by David Woodhouse

[permalink] [raw]

Subject: Re: The naming wars continue...

On Sat, 2004-10-23 at 08:56 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2004-10-23 at 08:05, Linus Torvalds wrote:
>
> > So to not overtax my poor brain, I'll just call them all -rc releases, and
> > hope that developers see them as a sign that there's been stuff merged,
> > and we should start calming down and seeing to the merged patches being
> > stable soon enough..
>
> Hehe, and a bunch of important (for me) ones that couldn't get in yet

Damn right. If 2.6.10 doesn't boot on the G5 with i8042 and 8250 drivers
built in, and doesn't sleep (well, more to the point doesn't resume) on
my shinybook, I shall sulk :)

--
dwmw2

2004-10-23 22:45:49

[permalink] [raw]

Subject: Re: The naming wars continue...

On Sat, 23 Oct 2004, Alexandre Oliva wrote:
>
> Release Cuality: if it works, it becomes the final release. No known
> bugs, except for typos ;-)

LOL.

Linus

2004-10-23 22:17:00

by Alexandre Oliva

[permalink] [raw]

Subject: Re: The naming wars continue...

On Oct 22, 2004, Linus Torvalds <[email protected]> wrote:

> However, for some reason four numbers just looks visually too obnoxious to
> me, so as I don't care that much, I'll just use "-rc", and we can all
> agree that it stands for "Ridiculous Count" rather than "Release
> Candidate".

Naah... That's too boring.

I think we should have several different annotations, to denote how
stable the tarball is supposed to be, and how close we are to a final
release. Say:

Raw Code, or Revamp & Catch-up: the sort of thing you'd get right
after the huge number of changesets we saw go in right after 2.6.9.
Depending on whether it contains mostly incremental changes or major
rework of internals, you'd go with the former or the latter.

Really Churning: more of the same, but not with such a big back-log
from waiting for the previous release.

Rapidly Changing: still accepting a large number of patches, fixing
bugs, adding features, whatever, but not as much of a dump of
never-tested-together patches as Raw Code tarballs.

Run with Care: sort of the same as above, but used to explicitly mark
tarballs in which patches that add significant risk of introducing
memory, disk or government corruption.

Ready or Close: as we approach a stable release, we stop merging new
features, and focus on installing only serious bug fixes.

Release Cuality: if it works, it becomes the final release. No known
bugs, except for typos ;-)

--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}

2004-10-23 21:52:05

by Matthias Schniedermeyer

[permalink] [raw]

Subject: Re: The naming wars continue...

On 23.10.2004 11:41, Stephen Frost wrote:
> * Linus Torvalds ([email protected]) wrote:
> > However, for some reason four numbers just looks visually too obnoxious to
>
> I agree, four numbers is *very* obnoxious, I mean, really, if for no
> other reason than *Oracle* uses four numbers. :)

Actually Oracle uses (or at least displays) 5 numbers. :-)

e.g. The version currently in use where i work: 9.2.0.5.0

Bis denn

--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

2004-10-23 21:04:13

by Christian Hesse

[permalink] [raw]

Subject: Re: The naming wars continue...

On Saturday 23 October 2004 02:43, Nigel Cunningham wrote:
> Hi.
>
> On Sat, 2004-10-23 at 08:05, Linus Torvalds wrote:
> > Oh, and the _real_ name did actually change. It's not Zonked Quokka any
> > more, that's so yesterday. Today we're Woozy Numbat! Get your order in!
>
> I vote for a Klassy Kiwi release :>

What is this real name good for? Is it "useful" in any way? I can not remember
where I could have seen it except in the Makefile...

--
Christian Hesse

geek by nature
linux by choice

Attachments:

(No filename) (499.00 B)
(No filename) (190.00 B)
Download all attachments

2004-10-24 00:02:07

by Stephen Frost

[permalink] [raw]

Subject: Re: The naming wars continue...

* Matthias Schniedermeyer ([email protected]) wrote:
> On 23.10.2004 11:41, Stephen Frost wrote:
> > * Linus Torvalds ([email protected]) wrote:
> > > However, for some reason four numbers just looks visually too obnoxious to
> >
> > I agree, four numbers is *very* obnoxious, I mean, really, if for no
> > other reason than *Oracle* uses four numbers. :)
>
> Actually Oracle uses (or at least displays) 5 numbers. :-)
>
> e.g. The version currently in use where i work: 9.2.0.5.0

Eh, their directory structure is (or at least, was last I checked) based
off of four numbers.

ie: /oracle/9.2.0.1

Stephen

Attachments:

(No filename) (603.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2004-10-24 00:47:17

by Jon Masters

[permalink] [raw]

Subject: Re: The naming wars continue...

On Sat, 23 Oct 2004 23:03:36 +0200, Christian Hesse <[email protected]> wrote:
> On Saturday 23 October 2004 02:43, Nigel Cunningham wrote:
> > Hi.
> >
> > On Sat, 2004-10-23 at 08:05, Linus Torvalds wrote:
> > > Oh, and the _real_ name did actually change. It's not Zonked Quokka any
> > > more, that's so yesterday. Today we're Woozy Numbat! Get your order in!
> >
> > I vote for a Klassy Kiwi release :>
>
> What is this real name good for?

ssssh. Don't tell them I told you, but it's what keeps all those
little penguins alive inside the harsh and treacherous confines of
such a small kernel. Really, I'm surprised animal welfare isn't on the
case.

Cheers,

Jon.

P.S. My cat is getting used to the giant stuffed tux I bought at Linux
World. He initially wasn't sure whether it was to replace him in our
affections or whether it should be attacked and eaten, but is now
happy to share the sofa with him.

2004-10-24 03:38:29

by Matthias Schniedermeyer

[permalink] [raw]

Subject: Re: The naming wars continue...

On 23.10.2004 20:02, Stephen Frost wrote:
> * Matthias Schniedermeyer ([email protected]) wrote:
> > On 23.10.2004 11:41, Stephen Frost wrote:
> > > * Linus Torvalds ([email protected]) wrote:
> > > > However, for some reason four numbers just looks visually too obnoxious to
> > >
> > > I agree, four numbers is *very* obnoxious, I mean, really, if for no
> > > other reason than *Oracle* uses four numbers. :)
> >
> > Actually Oracle uses (or at least displays) 5 numbers. :-)
> >
> > e.g. The version currently in use where i work: 9.2.0.5.0
>
> Eh, their directory structure is (or at least, was last I checked) based
> off of four numbers.
>
> ie: /oracle/9.2.0.1

The directory is a "user-supplied" value. AFAIR (last time i installed
an oracle-client myself is about 2 years ago (i never had to install a
server)) the "default" is/was something like: /oracle/OraHome1

My DBA collegues use a default of first 3 numbers without delimiters
ie: /server/oracle/920

When i connect to a server with sqlplus i get this:

- snip -
Connected to:
Oracle9i Release 9.2.0.5.0 - 64bit Production
JServer Release 9.2.0.5.0 - Production
- snip -

Oracle shows 5 numbers.

Bis denn

--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

2004-10-24 05:02:07

by Bernd Eckenfels

[permalink] [raw]

Subject: Re: The naming wars continue...

In article <[email protected]> you wrote:
> The directory is a "user-supplied" value.

Actually yes and no. With 10g, the "product" directory contain the (3
digits) version number (unrelated the actual ora home).

The different positions are well defined according to oracle, releases have
changes in the first 4 positions, where the first is the major product
version, the second is the release, the third are platform independend
features. The base release for 10g was 10.1.0.2, and the first patchset is
10.1.0.3

> My DBA collegues use a default of first 3 numbers without delimiters
> ie: /server/oracle/920

This has a bit changed with 10g.

Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

2004-10-24 08:53:25

by Matthias Urlichs

[permalink] [raw]

Subject: Re: The naming wars continue...

Hi, Linus Torvalds wrote:

> However, for some reason four numbers just looks visually too obnoxious to
> me

If you do something Really Big it's time to call the kernel 3.whatever.
If not, the new release management scheme suggests that the release
numbers are likely to stay within the 2.6 frame anyway.

Thus, the .6 is superfluous and can be dropped. Bingo, you have three
numbers again.

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [email protected]

2004-10-24 13:31:14

by Helge Hafting

[permalink] [raw]

Subject: Re: The naming wars continue...

On Fri, Oct 22, 2004 at 11:03:56PM -0400, Wakko Warner wrote:
> > The fact is, Linux naming has always sucked. Well, at least the versioning
> > I've used. Others tend to be more organized. Me, I'm the "artistic" type,
> > so I sometimes try to do something new, and invariably stupid.
>
> Given that the versioning was supposedly <major>.<minor>.<patchlevel> and
> the difference between 2.4 and 2.6 was substantial, why not just bump
> <major> instead of the minor. Then we'd have 3.0, 3.1, 4.0, 4.1.1 (for
> stupid mistakes). Isn't it time we move off the 2.x series and start
> thinking of the 3.x series?

Yes - lets stick to fewer numbers. They can count faster, instead
of having a long string of them. I hope linux doesn't
end up like X. "X11R6.8.1" The "X" itself is a counter, although
it is understandable if it never increments to "Y". But
that "11" doesn't change much, and then there are three more numbers. :-/

I think two numbers are enough. If "4.1" was a scre-up, release
"4.2" instead of a "4.1.1". People shouldn�'t try to readtoo
much information from the number structure - there are logs, docs and
websites for that.

Helge Hafting

2004-10-24 16:49:59

by Christoph Hellwig

[permalink] [raw]

Subject: generic hardirq code in 2.6.10-rc1

> o generic irq subsystem: core
> o generic irq subsystem: x86 port
> o generic irq subsystem: x86_64 port
> o generic irq subsystem: ppc port
> o generic irq subsystem: ppc64 port

Btw, it would be nice if all architectures that have more or less
a copy of the i386 irq.c could switch to the generic code.

That would be: alpha,ia64, m32r, mips, sh, sh64, um, v850

and possibly cris (it currently has a simplified version)

2004-10-25 06:03:11

by Miles Bader

[permalink] [raw]

Subject: Re: generic hardirq code in 2.6.10-rc1

Christoph Hellwig <[email protected]> writes:
> Btw, it would be nice if all architectures that have more or less
> a copy of the i386 irq.c could switch to the generic code.
>
> That would be: alpha,ia64, m32r, mips, sh, sh64, um, v850

Er, yeah, hold on (speaking for v850, I generally only ever look at real
releases and try to update for the next one).

-Miles
--
`...the Soviet Union was sliding in to an economic collapse so comprehensive
that in the end its factories produced not goods but bads: finished products
less valuable than the raw materials they were made from.' [The Economist]

2004-10-25 12:36:41

by Christoph Hellwig

[permalink] [raw]

Subject: Re: generic hardirq code in 2.6.10-rc1

On Mon, Oct 25, 2004 at 03:02:59PM +0900, Miles Bader wrote:
> Christoph Hellwig <[email protected]> writes:
> > Btw, it would be nice if all architectures that have more or less
> > a copy of the i386 irq.c could switch to the generic code.
> >
> > That would be: alpha,ia64, m32r, mips, sh, sh64, um, v850
>
> Er, yeah, hold on (speaking for v850, I generally only ever look at real
> releases and try to update for the next one).

It's not urgent anyway - the old code continues to work, it'd just be nicer
if as many as possible architectures used the common code.

2004-10-25 21:33:30

[permalink] [raw]

Subject: Re: The naming wars continue...

Nick Piggin wrote:

> Linus I agree it isn't a huge issue. The main thing for me is that
> I could just give a _real_ release candidate more testing - run it
> through some regression tests, make sure it functions OK on all my
> computers, etc. I expect this would be helpful for people with large
> sets of regression tests, and maybe those maintaining 'other'
> architectures too.
>
> I understand there's always "one more" patch to go in, but now that
> we're doing this stable-development system, I think a week or two
> weeks or even three weeks to stabalize the release with only
> really-real-bugfixes can't be such a bad thing.
>
> 2.6.x-rc (rc for Ridiculous Count) can then be our development
> releases, and 2.6.x-rc (rc for Release Candidate) are then closer
> to stable releases (in terms of getting patches in).
>
> Optionally, you could change Ridiculous Count to PRErelease to avoid
> confusion :)
>
> Other than that I don't have much to complain about... so keep up the
> good work!

I do agree that the pre and rc names gave a strong hint that (-pre) new
features would be considered or (-rc) it's worth doing more serious
testing. If Linux doesn't like this any more, perhaps some other way to
indicate the same thing would be desirable. I admit that the kernel has
gotten so good that I only try -rc (by whatever name) kernel, I'm not
waiting for the next big thing. I think that's really good, actually.

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2004-10-25 21:44:32

[permalink] [raw]

Subject: Re: The naming wars continue...

David Woodhouse wrote:

> Damn right. If 2.6.10 doesn't boot on the G5 with i8042 and 8250 drivers
> built in, and doesn't sleep (well, more to the point doesn't resume) on
> my shinybook, I shall sulk :)

Suspend is Shakespearean, "to sleep, perchance to dream." I don't know
why people are still trying the fix suspend, it works perfectly on all
my machines, I would like to see some work on wake-the-@-up at this point.

The sad part is that using apm and 2.4, all my laptops seem happy to
sleep and wake when asked. One of the reasons I'm running 2.4 on the old
ones, the new ones boot fast enought that I don't care.

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2004-10-25 22:04:33

[permalink] [raw]

Subject: Re: The naming wars continue...

On Mon, 25 Oct 2004, Bill Davidsen wrote:
>
> I do agree that the pre and rc names gave a strong hint that (-pre) new
> features would be considered or (-rc) it's worth doing more serious
> testing.

Well, I actually do try to _explain_ in the kernel mailing list
annoucements what it going on.

One of the reasons I don't like "-rcX" vs "-preX" is that they are so
meaningless. In contrast, when I actually do the write-up on a patch, I
tend to explain what I expect to have changed, and if I feel we're getting
ready for a release, I'll say something like

..

Ok,
trying to make ready for the real 2.6.9 in a week or so, so please give
this a beating, and if you have pending patches, please hold on to them
for a bit longer, until after the 2.6.9 release. It would be good to have
a 2.6.9 that doesn't need a dot-release immediately ;)

....

which is a hell of a lot more descriptive, in my opinion.

Which is just another reason why the name itself is not that meaningful.
It can never carry the kind of information that people seem to _expect_ it
to carry.

Linus

2004-10-26 01:19:05

by Hua Zhong (hzhong)

[permalink] [raw]

Subject: RE: The naming wars continue...

But not everyone reads LKML or the annoucement..a lot of people may just
decide whether to try this out based on the name. They go to kernel.org from
time to time and say: I'll test the next rc release.

"RC" has a very well-known meaning. It would make people scared if they find
rc isn't stable, and lose a lot of potential testers. So why break it?

Even another meaningless name which doesn't collide with RC is better.

> Which is just another reason why the name itself is not that
> meaningful.
> It can never carry the kind of information that people seem
> to _expect_ it to carry.

2004-10-26 01:25:51

[permalink] [raw]

Subject: Re: The naming wars continue...

Salut,

On Sat, Oct 23, 2004 at 11:41:28AM -0400, Stephen Frost wrote:
> I agree, four numbers is *very* obnoxious, I mean, really, if for no
> other reason than *Oracle* uses four numbers. :)

$ ld --version | head -1
GNU ld version 2.15.91.0.2
$

Tonnerre

Attachments:

(No filename) (266.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2004-10-26 01:59:32

by Daniel Gryniewicz

[permalink] [raw]

Subject: Re: The naming wars continue...

On Mon, 2004-10-25 at 17:44 -0400, Bill Davidsen wrote:
> David Woodhouse wrote:
>
> > Damn right. If 2.6.10 doesn't boot on the G5 with i8042 and 8250 drivers
> > built in, and doesn't sleep (well, more to the point doesn't resume) on
> > my shinybook, I shall sulk :)
>
> Suspend is Shakespearean, "to sleep, perchance to dream." I don't know
> why people are still trying the fix suspend, it works perfectly on all
> my machines, I would like to see some work on wake-the-@-up at this point.
>
> The sad part is that using apm and 2.4, all my laptops seem happy to
> sleep and wake when asked. One of the reasons I'm running 2.4 on the old
> ones, the new ones boot fast enought that I don't care.
>

Well, for me, 2.6.9 *broke* wake up. Suspend still works fine, but I'm
back to 2.6.9-rc4 to get working wake up.

Daniel

2004-10-26 01:25:42

[permalink] [raw]

Subject: Re: The naming wars continue...

Salut,

On Sun, Oct 24, 2004 at 03:33:33PM +0200, Helge Hafting wrote:
> Yes - lets stick to fewer numbers. They can count faster, instead
> of having a long string of them. I hope linux doesn't
> end up like X. "X11R6.8.1" The "X" itself is a counter, although
> it is understandable if it never increments to "Y". But
> that "11" doesn't change much, and then there are three more numbers. :-/

X11 is the name of the protocol: the X Protocol, version 11, as
released by the MIT. There was an X10.

6.8.1 is the current X.Org release that we did because 6.8 turned out
to have a nasty idiot bug.

Tonnerre

Attachments:

(No filename) (626.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2004-10-26 06:08:56

by Chuck Ebbert

[permalink] [raw]

Subject: Re: The naming wars continue...

Linus Torvalds wrote:

> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
>
> which is a hell of a lot more descriptive, in my opinion.

Yes, but -rc is (was?) (should have been?) shorthand for exactly that.

Nobody but the fanatics read the actual messages. The rest rely on abstractions.

--Chuck Ebbert 26-Oct-04 02:03:05

2004-10-26 06:37:37

[permalink] [raw]

Subject: Re: The naming wars continue...

Followup to: <[email protected]>
By author: Tonnerre <[email protected]>
In newsgroup: linux.dev.kernel
>
> Salut,
>
> On Sun, Oct 24, 2004 at 03:33:33PM +0200, Helge Hafting wrote:
> > Yes - lets stick to fewer numbers. They can count faster, instead
> > of having a long string of them. I hope linux doesn't
> > end up like X. "X11R6.8.1" The "X" itself is a counter, although
> > it is understandable if it never increments to "Y". But
> > that "11" doesn't change much, and then there are three more numbers. :-/
>
> X11 is the name of the protocol: the X Protocol, version 11, as
> released by the MIT. There was an X10.
>

There also were a W, and and X1, X2, ... X11.

However, there is a tendency for numbers to get stuck (witness Linux
2.x). In particular, X11R6 got encoded in many places including
pathnames for no good reason. Under the pre-R6 naming schemes we'd
had R7 a long time ago.

-hpa

2004-10-26 07:33:36

[permalink] [raw]

Subject: Re: The naming wars continue...

On Tuesday 26 October 2004 09:37, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Tonnerre <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Salut,
> >
> > On Sun, Oct 24, 2004 at 03:33:33PM +0200, Helge Hafting wrote:
> > > Yes - lets stick to fewer numbers. They can count faster, instead
> > > of having a long string of them. I hope linux doesn't
> > > end up like X. "X11R6.8.1" The "X" itself is a counter, although
> > > it is understandable if it never increments to "Y". But
> > > that "11" doesn't change much, and then there are three more numbers. :-/
> >
> > X11 is the name of the protocol: the X Protocol, version 11, as
> > released by the MIT. There was an X10.
> >
>
> There also were a W, and and X1, X2, ... X11.
>
> However, there is a tendency for numbers to get stuck (witness Linux
> 2.x). In particular, X11R6 got encoded in many places including
> pathnames for no good reason. Under the pre-R6 naming schemes we'd
> had R7 a long time ago.

How true.

# pwd
/usr/src2/uClibc-0.9.26
# grep -r X11R6 .
./ldso/ldso/readelflib1.c: UCLIBC_RUNTIME_PREFIX "usr/X11R6/lib:"
./utils/ldd.c: path = UCLIBC_RUNTIME_PREFIX "usr/X11R6/lib:"
./utils/ldconfig.c: scan_dir(UCLIBC_RUNTIME_PREFIX "/usr/X11R6/lib");
./libpthread/linuxthreads/README.Xfree3.2:This file describes how to make a threaded X11R6.
./libpthread/linuxthreads/README.Xfree3.2:You need the source-code of XFree-3.2. I used the sources of X11R6.1
./libpthread/linuxthreads/README.Xfree3.2:cp XF3.2/xc/lib/*/*.so.?.? /usr/X11R6/lib/
./libpthread/linuxthreads/README.Xfree3.2:cd /usr/X11R6/lib/
./Changelog: o Made the lib loader also support libs in /usr/X11R6/lib by default

This should be removed.

cd /usr/lib; ln -s /usr/X11R6/* .
or
echo /usr/X11R6/lib >>/etc/ld.so.conf

are the better ways to handle this
(I use first one)
--
vda

2004-10-26 11:13:28

by Geert Uytterhoeven

[permalink] [raw]

Subject: Re: The naming wars continue...

On Tue, 26 Oct 2004, Denis Vlasenko wrote:
> On Tuesday 26 October 2004 09:37, H. Peter Anvin wrote:
> > Followup to: <[email protected]>
> > By author: Tonnerre <[email protected]>
> > In newsgroup: linux.dev.kernel
> > > On Sun, Oct 24, 2004 at 03:33:33PM +0200, Helge Hafting wrote:
> > > > Yes - lets stick to fewer numbers. They can count faster, instead
> > > > of having a long string of them. I hope linux doesn't
> > > > end up like X. "X11R6.8.1" The "X" itself is a counter, although
> > > > it is understandable if it never increments to "Y". But
> > > > that "11" doesn't change much, and then there are three more numbers. :-/
> > > X11 is the name of the protocol: the X Protocol, version 11, as
> > > released by the MIT. There was an X10.
> >
> > There also were a W, and and X1, X2, ... X11.
> >
> > However, there is a tendency for numbers to get stuck (witness Linux
> > 2.x). In particular, X11R6 got encoded in many places including
> > pathnames for no good reason. Under the pre-R6 naming schemes we'd
> > had R7 a long time ago.
>
> How true.

> This should be removed.
>
> cd /usr/lib; ln -s /usr/X11R6/* .
> or
> echo /usr/X11R6/lib >>/etc/ld.so.conf
>
> are the better ways to handle this
> (I use first one)

/usr/{bin,lib/X11 have been version-free symlinks since ages...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2004-10-26 11:14:09

by Geert Uytterhoeven

[permalink] [raw]

Subject: Re: The naming wars continue...

On Tue, 26 Oct 2004, Tonnerre wrote:
> On Sun, Oct 24, 2004 at 03:33:33PM +0200, Helge Hafting wrote:
> > Yes - lets stick to fewer numbers. They can count faster, instead
> > of having a long string of them. I hope linux doesn't
> > end up like X. "X11R6.8.1" The "X" itself is a counter, although
> > it is understandable if it never increments to "Y". But
> > that "11" doesn't change much, and then there are three more numbers. :-/
>
> X11 is the name of the protocol: the X Protocol, version 11, as
> released by the MIT. There was an X10.
>
> 6.8.1 is the current X.Org release that we did because 6.8 turned out
> to have a nasty idiot bug.

What a coincidence: use s/X11R/2./ to convert from X11 to Linux :-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2004-10-26 11:44:31

[permalink] [raw]

Subject: Re: The naming wars continue...

> > > However, there is a tendency for numbers to get stuck (witness Linux
> > > 2.x). In particular, X11R6 got encoded in many places including
> > > pathnames for no good reason. Under the pre-R6 naming schemes we'd
> > > had R7 a long time ago.
> >
> > How true.
>
> > This should be removed.
> >
> > cd /usr/lib; ln -s /usr/X11R6/* .
> > or
> > echo /usr/X11R6/lib >>/etc/ld.so.conf
> >
> > are the better ways to handle this
> > (I use first one)
>
> /usr/{bin,lib/X11 have been version-free symlinks since ages...

Why X server special cased at all?

Having /usr/XnnRmm was a mistake in the first place.
--
vda

2004-10-26 13:30:43

by Giuseppe Bilotta

[permalink] [raw]

Subject: Re: The naming wars continue...

Linus Torvalds wrote:
>
>
> On Mon, 25 Oct 2004, Bill Davidsen wrote:
> >
> > I do agree that the pre and rc names gave a strong hint that (-pre) new
> > features would be considered or (-rc) it's worth doing more serious
> > testing.
>
> Well, I actually do try to _explain_ in the kernel mailing list
> annoucements what it going on.
>
> One of the reasons I don't like "-rcX" vs "-preX" is that they are so
> meaningless. In contrast, when I actually do the write-up on a patch, I
> tend to explain what I expect to have changed, and if I feel we're getting
> ready for a release, I'll say something like
>
> ..
>
> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
>
> ....
>
> which is a hell of a lot more descriptive, in my opinion.

Yeah but try fitting that in the extraversion. Maybe we should
use -hopstt(hold on patches, stress-test this) for this kind of
stuff, and -beo (bring 'em on) for the "early" -rcX ... :)

--
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)

2004-10-26 16:26:15

[permalink] [raw]

Subject: Re: The naming wars continue...

Salut,

On Tue, Oct 26, 2004 at 01:11:12PM +0200, Geert Uytterhoeven wrote:
> > 6.8.1 is the current X.Org release that we did because 6.8 turned out
> > to have a nasty idiot bug.
>
> What a coincidence: use s/X11R/2./ to convert from X11 to Linux :-)

Yes, and it was even around the same time, just some days later
IIRC. And the culprit was a TLA: it was XPM, not NFS.

Tonnerre

Attachments:

(No filename) (399.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2004-10-26 16:29:54

[permalink] [raw]

Subject: Re: The naming wars continue...

Salut,

On Tue, Oct 26, 2004 at 06:37:08AM +0000, H. Peter Anvin wrote:
> There also were a W, and and X1, X2, ... X11.

I know. I didn't say there wasn't. They were all standards of the X
protocol, however.

(Note, however, that there is a tiny difference in the command layout
between the MIT X protocol specifiaction version 11 and the reality.)

> However, there is a tendency for numbers to get stuck (witness Linux
> 2.x). In particular, X11R6 got encoded in many places including
> pathnames for no good reason.

Well, I'm driving my X11 from /opt/xorg and I don't have any problems
yet. Just that the NVidia driver doesn't get it right, but I threw
away my NVidia card in favor of a dual-core Voodoo 5 anyway.

Tonnerre

Attachments:

(No filename) (745.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2004-10-26 17:54:36

[permalink] [raw]

Subject: Re: The naming wars continue...

* Linus Torvalds ([email protected]) wrote:
>> However, for some reason four numbers just looks visually too obnoxious to

On Sat, Oct 23, 2004 at 11:41:28AM -0400, Stephen Frost wrote:
> I agree, four numbers is *very* obnoxious, I mean, really, if for no
> other reason than *Oracle* uses four numbers. :)

I swear I had nothing to do with it.

-- wli

2004-10-26 20:42:25

[permalink] [raw]

Subject: Re: The naming wars continue...

Salut,

On Tue, Oct 26, 2004 at 02:43:54PM +0300, Denis Vlasenko wrote:
> Having /usr/XnnRmm was a mistake in the first place.

BSD has /X11R6, whilst I'd agree that /opt/xorg is probably a lot more
appropriate. If you want I can take this discussion back to the X.Org
folks again, but I don't think it's actually going to change anything.

Tonnerre

Attachments:

(No filename) (359.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2004-10-26 21:22:05

[permalink] [raw]

Subject: Re: The naming wars continue...

Daniel Gryniewicz wrote:
> On Mon, 2004-10-25 at 17:44 -0400, Bill Davidsen wrote:
>
>>David Woodhouse wrote:
>>
>>
>>>Damn right. If 2.6.10 doesn't boot on the G5 with i8042 and 8250 drivers
>>>built in, and doesn't sleep (well, more to the point doesn't resume) on
>>>my shinybook, I shall sulk :)
>>
>>Suspend is Shakespearean, "to sleep, perchance to dream." I don't know
>>why people are still trying the fix suspend, it works perfectly on all
>>my machines, I would like to see some work on wake-the-@-up at this point.
>>
>>The sad part is that using apm and 2.4, all my laptops seem happy to
>>sleep and wake when asked. One of the reasons I'm running 2.4 on the old
>>ones, the new ones boot fast enought that I don't care.
>>
>
>
> Well, for me, 2.6.9 *broke* wake up. Suspend still works fine, but I'm
> back to 2.6.9-rc4 to get working wake up.

I think you missed my point... I said suspend works now work on wakeup.
Same issue you have.

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2004-10-26 21:30:47

[permalink] [raw]

Subject: Re: The naming wars continue...

Linus Torvalds wrote:
>
> On Mon, 25 Oct 2004, Bill Davidsen wrote:
>
>>I do agree that the pre and rc names gave a strong hint that (-pre) new
>>features would be considered or (-rc) it's worth doing more serious
>>testing.
>
>
> Well, I actually do try to _explain_ in the kernel mailing list
> annoucements what it going on.
>
> One of the reasons I don't like "-rcX" vs "-preX" is that they are so
> meaningless. In contrast, when I actually do the write-up on a patch, I
> tend to explain what I expect to have changed, and if I feel we're getting
> ready for a release, I'll say something like
>
> ..
>
> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
>
> ....
>
> which is a hell of a lot more descriptive, in my opinion.
>
> Which is just another reason why the name itself is not that meaningful.
> It can never carry the kind of information that people seem to _expect_ it
> to carry.

I wasn't going to reply to this since it's your call and I've had my
say, but since several others have, let me throw out one more idea on
the off chance you like it:

Stop doing the pre's on the next version! After 2.6.10 comes 2.6.10.1
etc, which everyone can see are incremental changes to 2.6.10, and when
you really mean it, then put out 2.6.11-rc1.

Did that strike a nerve?

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2004-10-27 00:42:52

[permalink] [raw]

Subject: Re: The naming wars continue...

Followup to: <[email protected]>
By author: Giuseppe Bilotta <[email protected]>
In newsgroup: linux.dev.kernel
>
> Yeah but try fitting that in the extraversion. Maybe we should
> use -hopstt(hold on patches, stress-test this) for this kind of
> stuff, and -beo (bring 'em on) for the "early" -rcX ... :)
>

We could even spell them -pre and -rc.

-hpa

2004-10-27 02:42:56

by Marcos D. Marado Torres

[permalink] [raw]

Subject: Re: The naming wars continue...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 27 Oct 2004, H. Peter Anvin wrote:

>> Yeah but try fitting that in the extraversion. Maybe we should
>> use -hopstt(hold on patches, stress-test this) for this kind of
>> stuff, and -beo (bring 'em on) for the "early" -rcX ... :)
>>
>
> We could even spell them -pre and -rc.

Exactly.
If 2.4 works so well, why change it in 2.6?

Mind Booster Noori

- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFBfwrymNlq8m+oD34RAlqzAJ4h8s7eS3Jfkz8lvbGvnf35hVN9FgCeJYyQ
suVxn5dtr7sXQYN9FM/EVHM=
=9xz9
-----END PGP SIGNATURE-----

2004-10-27 03:18:08

by Marcos D. Marado Torres

[permalink] [raw]

Subject: Re: The naming wars continue...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 26 Oct 2004, Bill Davidsen wrote:

> Stop doing the pre's on the next version!

There are no -pre's in 2.6, at least not till now.

> After 2.6.10 comes 2.6.10.1 etc,
> which everyone can see are incremental changes to 2.6.10, and when you really
> mean it, then put out 2.6.11-rc1.

2.6.z.w is already "reserved" for another kind of updates. You're proposing a
system where you have:

2.6.10
2.6.10-???1
2.6.10-???2
2.6.10-???3
2.6.11-rc1
2.6.11-rc2
2.6.11-rc3
2.6.11
...

Or, in other words, you don't want Linus to "Stop doing the pre's", you're
wanting exactly the same scheme 2.4 is using and works preety fine: just
replace 10 by 11 in the '???' series, replace '???' by 'pre' and you have:

x.y.z
x.y.z+1-pre1
...
x.y.z+1-preN
x.y.z+1-rc1

2.4 model allways worked fine, we should stick with it instead of pulling our
hair out trying to figure out how to solve the problem that is already solved.

Mind Booster Noori

- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFBfw+JmNlq8m+oD34RAmsdAJwOMJz7GqtQV3zG/DJYz14pioNADACfTI3H
fVfR9SmC8BxHpmT0B9rWVNk=
=avZN
-----END PGP SIGNATURE-----

2004-10-27 03:34:55

by Barry K. Nathan

[permalink] [raw]

Subject: Re: The naming wars continue...

On Tue, Oct 26, 2004 at 05:32:16PM -0400, Bill Davidsen wrote:
> Linus Torvalds wrote:
[snip]
> >Which is just another reason why the name itself is not that meaningful.
> >It can never carry the kind of information that people seem to _expect_ it
> >to carry.
>
> I wasn't going to reply to this since it's your call and I've had my
> say, but since several others have, let me throw out one more idea on
> the off chance you like it:
>
> Stop doing the pre's on the next version! After 2.6.10 comes 2.6.10.1
> etc, which everyone can see are incremental changes to 2.6.10, and when
> you really mean it, then put out 2.6.11-rc1.
>
> Did that strike a nerve?

2.6.10.1, etc. suggests important bug fixes for 2.6.10, *not* prereleases
of 2.6.11. But... perhaps (with sufficient warning) the even/odd principle
could be applied to the third number. So, this would happen:

2.6.even = release
2.6.even.x = release, with added bug/security fixes
2.6.odd = first (zeroth?) -pre/-rc release
2.6.odd.x = additional -pre/-rc releases

A more concrete example:
2.6.11-rc1, 2.6.11-rc2, 2.6.11-rc3, 2.6.11, 2.6.12-rc1, 2.6.12-rc2, 2.6.12
would become:
2.6.11, 2.6.11.1, 2.6.11.2, 2.6.12, 2.6.13, 2.6.13.1, 2.6.14

How does this sound? (It just occurred to me that this might break
scripts, but it may be worth discussing anyway.)

-Barry K. Nathan <[email protected]>

2004-10-27 04:21:50

[permalink] [raw]

Subject: Re: The naming wars continue...

Tonnerre wrote:
> Salut,
>
> On Tue, Oct 26, 2004 at 02:43:54PM +0300, Denis Vlasenko wrote:
>
>>Having /usr/XnnRmm was a mistake in the first place.
>
>
> BSD has /X11R6, whilst I'd agree that /opt/xorg is probably a lot more
> appropriate. If you want I can take this discussion back to the X.Org
> folks again, but I don't think it's actually going to change anything.
>

/opt/X (or /usr/X) is really what it probably should be.

-hpa

2004-10-27 07:38:12

[permalink] [raw]

Subject: Re: The naming wars continue...

> Stop doing the pre's on the next version! After 2.6.10 comes 2.6.10.1
> etc, which everyone can see are incremental changes to 2.6.10, and when
> you really mean it, then put out 2.6.11-rc1.

Oh no. We had a perfectly working scheme of pre's and rc's,
why shall it be changed? This will break scripts for _zero_
gain.

Well, if Linus does not want pre's and wants to use rc's
only, that's fine with me, but fourth digit
(or other such innovations) is not.
--
vda

2004-10-27 08:33:50

[permalink] [raw]

Subject: Re: The naming wars continue...

On Wednesday 27 October 2004 07:21, H. Peter Anvin wrote:
> Tonnerre wrote:
> > Salut,
> >
> > On Tue, Oct 26, 2004 at 02:43:54PM +0300, Denis Vlasenko wrote:
> >
> >>Having /usr/XnnRmm was a mistake in the first place.
> >
> >
> > BSD has /X11R6, whilst I'd agree that /opt/xorg is probably a lot more
> > appropriate. If you want I can take this discussion back to the X.Org
> > folks again, but I don't think it's actually going to change anything.
> >
>
> /opt/X (or /usr/X) is really what it probably should be.

Why there is any distinction between, say, gcc and X?
KDE and Midnight Commander? etc... Why some of them go
to /opt while others are spread across dozen of dirs?
This seems to be inconsistent to me.

I won't push my solution to anyone, just going to show you
how does it look:

# ls /usr/app -1
Linux-PAM-0.75
MPlayer-0.90rc4
SDL-1.2.6
acrobat-5.06
acroread-5.0.8
alsa-lib-0.9.0beta12
alsa-lib-0.9.7
alsa-utils-0.9.0beta12
alsa-utils-0.9.7
apache-1.3.24
atk-1.2.4
audiofile-0.2.3
audiogalaxy-0520
autofs-4.1.3
bash-2.05b
bglibs-1.005
binutils-2.15.91.0.1
bridge-utils-0.9.6
bsdftpd-6.0-ssl-0.5.2
busybox-1.00-pre6
...

Typical package under /usr/app:

# ls -l /usr/app/gcc-3.4.1
total 12
-r-xr-xr-x 1 root root 1429 Oct 25 13:39 !vda_install
-r-xr-xr-x 1 root root 874 Sep 15 2003 !vda_install_root
-r-xr-xr-x 1 root root 157 Aug 17 2003 !vda_ver
drwxr-xr-x 2 root root 360 Oct 25 13:39 bin
drwxr-xr-x 3 root root 72 Jul 15 16:54 include
drwxr-xr-x 2 root root 224 Jul 15 16:54 info
drwxr-xr-x 3 root root 336 Jul 15 16:54 lib
drwxr-xr-x 3 root root 72 Jul 15 16:54 libexec
drwxr-xr-x 4 root root 96 Jul 15 16:54 man

This is how it is made visible to the rest of system:

# ls -l /usr/lib /usr/bin | grep gcc-3.4.1
lrwxrwxrwx 1 root root 26 Oct 25 13:39 c++ -> /usr/app/gcc-3.4.1/bin/c++
lrwxrwxrwx 1 root root 26 Oct 25 13:39 cpp -> /usr/app/gcc-3.4.1/bin/cpp
lrwxrwxrwx 1 root root 26 Oct 25 13:39 g++ -> /usr/app/gcc-3.4.1/bin/g++
lrwxrwxrwx 1 root root 26 Oct 25 13:39 gcc -> /usr/app/gcc-3.4.1/bin/gcc
lrwxrwxrwx 1 root root 29 Oct 25 13:39 gccbug -> /usr/app/gcc-3.4.1/bin/gccbug
lrwxrwxrwx 1 root root 27 Oct 25 13:39 gcov -> /usr/app/gcc-3.4.1/bin/gcov
lrwxrwxrwx 1 root root 44 Oct 25 13:39 i386-pc-linux-gnu-c++ -> /usr/app/gcc-3.4.1/bin/i386-pc-linux-gnu-c++
lrwxrwxrwx 1 root root 44 Oct 25 13:39 i386-pc-linux-gnu-g++ -> /usr/app/gcc-3.4.1/bin/i386-pc-linux-gnu-g++
lrwxrwxrwx 1 root root 44 Oct 25 13:39 i386-pc-linux-gnu-gcc -> /usr/app/gcc-3.4.1/bin/i386-pc-linux-gnu-gcc
lrwxrwxrwx 1 root root 50 Oct 25 13:39 i386-pc-linux-gnu-gcc-3.4.1 -> /usr/app/gcc-3.4.1/bin/i386-pc-linux-gnu-gcc-3.4.1
lrwxrwxrwx 1 root root 34 Oct 25 13:39 libiberty.a -> /usr/app/gcc-3.4.1/lib/libiberty.a
lrwxrwxrwx 1 root root 34 Oct 25 13:39 libstdc++.a -> /usr/app/gcc-3.4.1/lib/libstdc++.a
lrwxrwxrwx 1 root root 35 Oct 25 13:39 libstdc++.la -> /usr/app/gcc-3.4.1/lib/libstdc++.la
lrwxrwxrwx 1 root root 35 Oct 25 13:39 libstdc++.so -> /usr/app/gcc-3.4.1/lib/libstdc++.so
lrwxrwxrwx 1 root root 37 Oct 25 13:39 libstdc++.so.6 -> /usr/app/gcc-3.4.1/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 41 Oct 25 13:39 libstdc++.so.6.0.1 -> /usr/app/gcc-3.4.1/lib/libstdc++.so.6.0.1
lrwxrwxrwx 1 root root 34 Oct 25 13:39 libsupc++.a -> /usr/app/gcc-3.4.1/lib/libsupc++.a
lrwxrwxrwx 1 root root 35 Oct 25 13:39 libsupc++.la -> /usr/app/gcc-3.4.1/lib/libsupc++.la

It's pretty modular: I can remove and install packages
as needed, I can go back to older versions to check
regressions etc...

BTW today I just added uclibc and some uc-compiled apps to the mix.
They coexist nicely with the rest of the system
(I needed only some almost trivial tricks)

uc-Midnight Commander is 3 times smaller than glibc one :)
--
vda

2004-10-27 07:33:01

by Helge Hafting

[permalink] [raw]

Subject: Re: The naming wars continue...

On Mon, Oct 25, 2004 at 03:46:58PM -0700, Hua Zhong wrote:
>
> But not everyone reads LKML or the annoucement..a lot of people may just
> decide whether to try this out based on the name. They go to kernel.org from
> time to time and say: I'll test the next rc release.
>
> "RC" has a very well-known meaning. It would make people scared if they find
> rc isn't stable, and lose a lot of potential testers. So why break it?
>
I expect a "rc" to be a kind of beta - an attempt to get it right
rather than experiment - but it may still be broken. Someone
who want stability should try the latest point release
(2.6.9) or fix release (2.6.9.x with the current system)

Helge Hafting

2004-10-27 15:51:58

[permalink] [raw]

Subject: Re: The naming wars continue...

Salut,

On Wed, Oct 27, 2004 at 11:33:25AM +0300, Denis Vlasenko wrote:
> Why there is any distinction between, say, gcc and X?
> KDE and Midnight Commander? etc... Why some of them go
> to /opt while others are spread across dozen of dirs?

Well.

FHS specifies that everything needed to boot the system should got to
/bin and /sbin. The base system (build system, etc.) should go to
/usr. The rest should be /opt/itspackagename.

I'm not quite a FHS fan. I use libexec dirs, but I still have my build
system under /usr (and my home under /usr/home), and the rest (X, KDE
et al) lives under /opt.

Tonnerre

Attachments:

(No filename) (623.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2004-10-27 16:12:46

by Grzegorz Kulewski

[permalink] [raw]

Subject: [OT] Re: The naming wars continue...

On Wed, 27 Oct 2004, Tonnerre wrote:

> Salut,
>
> On Wed, Oct 27, 2004 at 11:33:25AM +0300, Denis Vlasenko wrote:
>> Why there is any distinction between, say, gcc and X?
>> KDE and Midnight Commander? etc... Why some of them go
>> to /opt while others are spread across dozen of dirs?
>
> Well.
>
> FHS specifies that everything needed to boot the system should got to
> /bin and /sbin. The base system (build system, etc.) should go to
> /usr. The rest should be /opt/itspackagename.
>
> I'm not quite a FHS fan. I use libexec dirs, but I still have my build
> system under /usr (and my home under /usr/home), and the rest (X, KDE
> et al) lives under /opt.

Hi,

In Gentoo everything goes to /usr/bin or /usr/sbin except very basic
things that are instaled in /bin or /sbin and binary-only packages that
are instaled in /opt (very good idea).

Yes, Linux (or UNIX) directory structure should be changed years ago but
nobody (except GOBO Linux I think) is going to do it. That will require
patching realy big amount of code and changing some standards. If somebody
has time for it feel free to contact me, and I will tell him (or her) what
should be changed to produce The New Directory Standard That Breaks
Everything But Is The Best And Most Sane In The World (TM)... :-)

Grzegorz Kulewski

2004-10-27 16:29:14

[permalink] [raw]

Subject: Re: [OT] Re: The naming wars continue...

Salut,

On Wed, Oct 27, 2004 at 06:11:43PM +0200, Grzegorz Kulewski wrote:
> Yes, Linux (or UNIX) directory structure should be changed years ago but
> nobody (except GOBO Linux I think) is going to do it. That will require
> patching realy big amount of code and changing some standards. If somebody
> has time for it feel free to contact me, and I will tell him (or her) what
> should be changed to produce The New Directory Standard That Breaks
> Everything But Is The Best And Most Sane In The World (TM)... :-)

This is not the case, thanks to autoconf and pkg-config. On one of my
systems, I have all the binaries under /Library/..., and all the libs
under /Frameworks/..., and the doc goes under
/Library/Documentation/someplace...

It's not a problem any more, thanks to the ongoing modularization.

Tonnerre

Attachments:

(No filename) (857.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2004-10-27 16:47:06

by Grzegorz Kulewski

[permalink] [raw]

Subject: Re: [OT] Re: The naming wars continue...

On Wed, 27 Oct 2004, Tonnerre wrote:

> Salut,
>
> On Wed, Oct 27, 2004 at 06:11:43PM +0200, Grzegorz Kulewski wrote:
>> Yes, Linux (or UNIX) directory structure should be changed years ago but
>> nobody (except GOBO Linux I think) is going to do it. That will require
>> patching realy big amount of code and changing some standards. If somebody
>> has time for it feel free to contact me, and I will tell him (or her) what
>> should be changed to produce The New Directory Standard That Breaks
>> Everything But Is The Best And Most Sane In The World (TM)... :-)
>
> This is not the case, thanks to autoconf and pkg-config. On one of my
> systems, I have all the binaries under /Library/..., and all the libs
> under /Frameworks/..., and the doc goes under
> /Library/Documentation/someplace...
>
> It's not a problem any more, thanks to the ongoing modularization.

Hi,

1. Not all packages use autoconf.
2. Not all packages use autoconf correctly.
3. Autoconf and others are broken in my opinion (yes they provide some
good features but have very high amount of bad features or stupid concepts
too). This is not only mine opinion btw.
4. Changing the directory structure just to rename /lib to /Library is not
very ambituous... I can even call it strange...
5. I am thinking of changing directory structure (and some other things)
some more... For example placing every package in its own dir - like
/apps/gcc/3.4.2/<install date>/{bin,lib,...} and placing symlinks in /bin
(or how to call it) to required files from packages bins (like RELINK),
adding something like /apps/<package name>/<version>/<install date>/deps
and keeping symlinks to all external libs/programs/scripts used by
<package name> there, changing autoconf to ask not test for features and
much more (= turning Linux standards upside down).

Grzegorz Kulewski

2004-10-27 17:37:50

by Måns Rullgård

[permalink] [raw]

Subject: Re: [OT] Re: The naming wars continue...

Grzegorz Kulewski <[email protected]> writes:

> 5. I am thinking of changing directory structure (and some other
> things) some more... For example placing every package in its own dir
> - like /apps/gcc/3.4.2/<install date>/{bin,lib,...} and placing

I've been placing things in /opt/package/version for quite a while. I
use a perl script to set the *PATH environment variables to point at
whatever versions I choose for each package. I patched aclocal (of
automake) to search in directories given by $ACLOCAL_PATH, but the
patch has been ignored for several years, so I'm not expecting it to
be picked up.

--
M?ns Rullg?rd
[email protected]

2004-10-27 19:24:04

[permalink] [raw]

Subject: Re: The naming wars continue...

Denis Vlasenko wrote:
> On Wednesday 27 October 2004 07:21, H. Peter Anvin wrote:
>
>>Tonnerre wrote:
>>
>>>Salut,
>>>
>>>On Tue, Oct 26, 2004 at 02:43:54PM +0300, Denis Vlasenko wrote:
>>>
>>>
>>>>Having /usr/XnnRmm was a mistake in the first place.
>>>
>>>
>>>BSD has /X11R6, whilst I'd agree that /opt/xorg is probably a lot more
>>>appropriate. If you want I can take this discussion back to the X.Org
>>>folks again, but I don't think it's actually going to change anything.
>>>
>>
>>/opt/X (or /usr/X) is really what it probably should be.
>
>
> Why there is any distinction between, say, gcc and X?
> KDE and Midnight Commander? etc... Why some of them go
> to /opt while others are spread across dozen of dirs?
> This seems to be inconsistent to me.

At one time Sun had the convention that things in /usr could be mounted
ro on multiple machines. That worked, it predates Linux so Linux was the
o/s which chose to go another way, and it covered the base things in a
system.

That actually seems like a good way to split a networked environment,
with /bin and /sbin having just enough to get the system up and mount
/usr. I can't speak to why that is being done differently now.

I guess someone was nervous about mounting a local /usr/local on a
(possibly) network mounted /usr and theu /opt, but that's a guess on my
part as well.

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2004-10-27 19:32:04

[permalink] [raw]

Subject: Re: The naming wars continue...

Barry K. Nathan wrote:
> On Tue, Oct 26, 2004 at 05:32:16PM -0400, Bill Davidsen wrote:
>
>>Linus Torvalds wrote:
>
> [snip]
>
>>>Which is just another reason why the name itself is not that meaningful.
>>>It can never carry the kind of information that people seem to _expect_ it
>>>to carry.
>>
>>I wasn't going to reply to this since it's your call and I've had my
>>say, but since several others have, let me throw out one more idea on
>>the off chance you like it:
>>
>>Stop doing the pre's on the next version! After 2.6.10 comes 2.6.10.1
>>etc, which everyone can see are incremental changes to 2.6.10, and when
>>you really mean it, then put out 2.6.11-rc1.
>>
>>Did that strike a nerve?
>
>
> 2.6.10.1, etc. suggests important bug fixes for 2.6.10, *not* prereleases
> of 2.6.11. But... perhaps (with sufficient warning) the even/odd principle
> could be applied to the third number. So, this would happen:

2.6.10.1 suggests nothing, that convention was used ONCE in the 2.6
series. I liked the -pre convention as it was, but Linus has dropped
that in spite of several hundred instances of its use. From that I
conclude that if Linus like 2.6.10.1 he will use it, and if not we will
have -rc releases which aren't release candidates. His call.

I personally think it will slow development because some people tested
the -rc releases harder, but that's not decided by vote.

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2004-10-27 20:20:07

by Martin Schlemmer

[permalink] [raw]

Subject: Re: The naming wars continue... [u]

On Tue, 2004-10-26 at 21:21 -0700, H. Peter Anvin wrote:
> Tonnerre wrote:
> > Salut,
> >
> > On Tue, Oct 26, 2004 at 02:43:54PM +0300, Denis Vlasenko wrote:
> >
> >>Having /usr/XnnRmm was a mistake in the first place.
> >
> >
> > BSD has /X11R6, whilst I'd agree that /opt/xorg is probably a lot more
> > appropriate. If you want I can take this discussion back to the X.Org
> > folks again, but I don't think it's actually going to change anything.
> >
>
> /opt/X (or /usr/X) is really what it probably should be.
>

Except if I am missing something, it is (or was) to be able to
distinguish between versions that broke protocol compatibility ...
so except if the protocol will never change again, it should really
stay as is, and the apps should actually just start to use /usr/bin/X11
and /usr/lib/X11 that points to the latest or most stable instead of
the versioned directories ...

--
Martin Schlemmer

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2004-10-27 22:55:02

by Jesper Juhl

[permalink] [raw]

Subject: Re: The naming wars continue...

On Wed, 27 Oct 2004, Linus Torvalds wrote:

>
>
> On Thu, 28 Oct 2004, Dave Airlie wrote:
> >
> > There has been a fair bit of bike shedding going on... so I think we
> > should use some sort of timber and paint it red...
>
> Ok, I nominate this for the strangest entry in the discussion so far.
>
Heh, yeah, glad I'm not the only one incapable of making sense of that. :)

Anyway, I've been reading this thread and just want to add my own small
comments to it :

Personally I was a bit sceptical of the "new development model" at first,
but as 2.6.x has progressed I've come to like it very much.
I'm using 2.6 on a number of boxes, servers, workstations at work and my
personal machine at work, and my impression is that it's the fastest
kernel we've had so far, and it's stable (at least I've not had any major
issues). So to me it seems to be working just fine.

Some people have been asking for a sepperate tree for all the experimental
and unstable stuff, but as I see it that role is fulfilled by Andrews -mm
tree.
Things go into -mm, then get a bit (or a lot in some cases) workout and
then slowly migrate into the mainline (Linus) tree as they settle down and
are proven to be stable. This is good since it keeps the stable kernel
up-to-date feature wise, and stuff has a place to get fixed and
stabilized before it moves to mainline, so mainline 2.6 is not a minefield
of unstable changes (and I think Andrew is doing a very good job at
this), but it's not a hugely out-of-date thing as it used to be with a
sepperate 2.<odd number>.x development tree.

The people asking for a very stable 2.6.x.y.z.whatever tree are forgetting
a few things in my oppinion;
First they seem to forget that point releases actually serve the role of
"new and improved stable kernel", so 2.6.x is the new "maintainance
release" of the 2.6.x-1 kernel.
Also they forget that there's a period of -rc releases before a point
release where stability and incompatibility problems can be dealt with.
They also forget that there's nothing stopping them from forking off 2.6.x
at any point in time and maintaining their own "ultra stable" kernel based
on that release (hopefully they would still merge their fixes into
whatever is the current Linus kernel).

I'm starting to ramble, all I really want to say is that I think the
current model works well - changes get testing in -mm before hitting
mainline, and mainline is not lacking behind in fixes and features as
badly as we've seen earlier with 2.4.x vs 2.5.x, 2.3.x vs 2.2.x and
previous development branches. And I think Andrew, Linus and the other
main kernel people are doing a very good job with the kernel atm.

--
Jesper Juhl

2004-10-27 22:28:13

by Dave Dodge

[permalink] [raw]

Subject: Re: [uClibc] Re: [OT] Re: The naming wars continue...

On Wed, Oct 27, 2004 at 11:15:15PM +0200, M?ns Rullg?rd wrote:
> Dave Dodge <[email protected]> writes:
> > If I recall correctly, in the GoboLinux case
[...]
> > I believe "/bin" is a symlink to the bin directory in the main
> > install prefix, but there are patches so that while "/bin" can be
> > used for lookups it does not appear when you list "/".
>
> If there's one thing I detest, it is such hiding of files. The GUI in
> MacOSX does such things too, even /tmp is hidden there.

I believe Gobo only has paths such as "/bin" for legacy compatibility
(for example scripts starting with #!/bin/...). "/dev" is another
case, since that isn't where Gobo puts its devices, but lots of things
are going to assume they can use "/dev/zero" and "/dev/null".

> It's visible from a shell though.

Gobo actually does it in the kernel; whether that's better or worse
depends on your point of view. There's a command-line tool "GoboHide"
that provides a list of hidden things:

http://gobolinux.org/index.php?page=doc/articles/gobohide

I think all of the things hidden in a normal GoboLinux desktop are
just legacy symlinks, and the real locations they point to are fully
visible. Unlike MacOS, where the Finder ignores a lot of real
directories and applications (I've been bitten there by "/tmp"
myself).
-Dave Dodge

2004-10-27 23:12:52

by Jesper Juhl

[permalink] [raw]

Subject: Re: The naming wars continue...

Whoops, wrong thread, This was actually meant more for the "new
development model" thread, but whatever, it'll just have to stay here now
:)

/Jesper Juhl

PS. Trimming CC as this is a fairly irrelevant little comment

2004-10-27 23:32:32

by Randy.Dunlap

[permalink] [raw]

Subject: Re: The naming wars continue... [u]

Martin Schlemmer [c] wrote:
> On Tue, 2004-10-26 at 21:21 -0700, H. Peter Anvin wrote:
>
>>Tonnerre wrote:
>>
>>>Salut,
>>>
>>>On Tue, Oct 26, 2004 at 02:43:54PM +0300, Denis Vlasenko wrote:
>>>
>>>
>>>>Having /usr/XnnRmm was a mistake in the first place.
>>>
>>>
>>>BSD has /X11R6, whilst I'd agree that /opt/xorg is probably a lot more
>>>appropriate. If you want I can take this discussion back to the X.Org
>>>folks again, but I don't think it's actually going to change anything.
>>>
>>
>>/opt/X (or /usr/X) is really what it probably should be.
>>
>
>
> Except if I am missing something, it is (or was) to be able to
> distinguish between versions that broke protocol compatibility ...
> so except if the protocol will never change again, it should really
> stay as is, and the apps should actually just start to use /usr/bin/X11
> and /usr/lib/X11 that points to the latest or most stable instead of
> the versioned directories ...

This won't get fixed on lkml.
If you want to contribute in this area, try LSB/FHS etc. & Please do.

--
~Randy

2004-10-27 21:42:43

by Martin Schlemmer

[permalink] [raw]

Subject: Re: The naming wars continue... [u]

On Wed, 2004-10-27 at 13:35 -0700, Randy.Dunlap wrote:
> Martin Schlemmer [c] wrote:
> > On Tue, 2004-10-26 at 21:21 -0700, H. Peter Anvin wrote:
> >
> >>Tonnerre wrote:
> >>
> >>>Salut,
> >>>
> >>>On Tue, Oct 26, 2004 at 02:43:54PM +0300, Denis Vlasenko wrote:
> >>>
> >>>
> >>>>Having /usr/XnnRmm was a mistake in the first place.
> >>>
> >>>
> >>>BSD has /X11R6, whilst I'd agree that /opt/xorg is probably a lot more
> >>>appropriate. If you want I can take this discussion back to the X.Org
> >>>folks again, but I don't think it's actually going to change anything.
> >>>
> >>
> >>/opt/X (or /usr/X) is really what it probably should be.
> >>
> >
> >
> > Except if I am missing something, it is (or was) to be able to
> > distinguish between versions that broke protocol compatibility ...
> > so except if the protocol will never change again, it should really
> > stay as is, and the apps should actually just start to use /usr/bin/X11
> > and /usr/lib/X11 that points to the latest or most stable instead of
> > the versioned directories ...
>
> This won't get fixed on lkml.
> If you want to contribute in this area, try LSB/FHS etc. & Please do.
>

While I appreciate the thought, I should admit that I was only trying
to be the local smart-ass, so I have to decline to go on the LSB/FHS
crusade :/ Maybe one of the others before me would be so kind.

PS: I probably should point out that my use of /usr/bin/X11 and
/usr/lib/X11 for the generic symlinks is not so generic, before
I step on more toes ...

Thanks,

--
Martin Schlemmer

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2004-10-27 21:22:25

by Måns Rullgård

[permalink] [raw]

Subject: Re: [uClibc] Re: [OT] Re: The naming wars continue...

Dave Dodge <[email protected]> writes:

> On Wed, Oct 27, 2004 at 07:27:04PM +0200, M?ns Rullg?rd wrote:
>> Grzegorz Kulewski <[email protected]> writes:
>> > 5. I am thinking of changing directory structure (and some other
>> > things) some more... For example placing every package in its own dir
>> > - like /apps/gcc/3.4.2/<install date>/{bin,lib,...} and placing
>>
>> I've been placing things in /opt/package/version for quite a while.
>
> That's essentially what the GoboLinux distribution does, except that
> it does it for everything down to and including core stuff like "sh"
> and "ls".
>
>> I use a perl script to set the *PATH environment variables to point at
>> whatever versions I choose for each package.
>
> If you have enough things installed you might run into problems with
> the size of PATH (perhaps unlikely on Linux, but I recall hitting
> the limit on Solaris at one point).

At my university they were running a locally hacked version of tcsh to
increase the maximum size of PATH to allow a similar setup.

> When I used to do this on Solaris, my most recent solution was to use
> GNU stow to create symlinks from a single prefix to all of the
> installed packages. Then I'd only need one additional entry in PATH,
> MANPATH, and so on. stow made it easy enough to add and remove
> packages, though there were trouble spots with duplicate files such as
> the emacs info directory.

The advantage with setting the environment variables directly is that
it's easy to switch between different versions of any package without
changing anything on disk, and I can have different version selected
in different xterms. A symlink based scheme doesn't allow this.

> If I recall correctly, in the GoboLinux case gcc 3.4.2 would be
> installed in "/Programs/GCC/3.4.2/{bin,lib,...}". A symlink from
> "/Programs/GCC/Current" to "3.4.2" would select that as the current
> version. The Current trees are symlinked into a single prefix (like I
> did with stow). Gobo has scripts to manage all of this. I believe
> "/bin" is a symlink to the bin directory in the main install prefix,
> but there are patches so that while "/bin" can be used for lookups it
> does not appear when you list "/".

If there's one thing I detest, it is such hiding of files. The GUI in
MacOSX does such things too, even /tmp is hidden there. It's visible
from a shell though. I won't even mention mswindows. If a file
exists, it should be visible, period. The standard hiding of .dot
files is perfectly good enough without any extra hacks.

--
M?ns Rullg?rd
[email protected]

2004-10-27 22:57:16

by Dave Airlie

[permalink] [raw]

Subject: Re: The naming wars continue...

> > >
> > > There has been a fair bit of bike shedding going on... so I think we
> > > should use some sort of timber and paint it red...
> >
> > Ok, I nominate this for the strangest entry in the discussion so far.
> >
> Heh, yeah, glad I'm not the only one incapable of making sense of that. :)
>

I think Linus made sense of it :-),

for anyone that needs a explaination (takes all the fun out of it :-)
http://www.unixguide.net/freebsd/faq/16.19.shtml

Dave.

2004-10-27 21:22:20

by Dave Airlie

[permalink] [raw]

Subject: Re: The naming wars continue...

>
> The subject line of my announcement was
>
> Subject: Linux 2.6.9-rc4 - pls test (and no more patches)
>
> and the body was
>
> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
>
> The appended shortlog gives a pretty good idea of what has been going on.
> Mostly small stuff, with some architecture updates and an ACPI update
> thrown in for good measure.
>
> (plus the shortlog).
>
> Not exactly "hidden", was it?

To sum up, why don't you call everything before you reach this point
-pre and then when you decide to write the mail and realise you want
to say no more patches just check in patch calling it -rc ? you claim
you don't know when to diffrentiate between -pre and -rc, (or maybe
you don't care) well how do you decide to write the above e-mail? I
think that would satisfy nearly everyone and I don't see what would be
so different from your POV, but it is in the end up to you...

> So far, nobody has had a good reason. People are just complaining, because
> this is an area where you can complain without actually having any real
> hard technical input. It's "easy" to have an opinion.
> So guys, look at the big picture. Is this really worth worrying over?

There has been a fair bit of bike shedding going on... so I think we
should use some sort of timber and paint it red...

Dave.

2004-10-27 21:32:15

[permalink] [raw]

Subject: Re: The naming wars continue...

On Thu, 28 Oct 2004, Dave Airlie wrote:
>
> There has been a fair bit of bike shedding going on... so I think we
> should use some sort of timber and paint it red...

Ok, I nominate this for the strangest entry in the discussion so far.

Linus

2004-10-27 23:12:42

by Måns Rullgård

[permalink] [raw]

Subject: Re: [uClibc] Re: [OT] Re: The naming wars continue...

Dave Dodge <[email protected]> writes:

> On Wed, Oct 27, 2004 at 11:15:15PM +0200, M?ns Rullg?rd wrote:
>> Dave Dodge <[email protected]> writes:
>> > If I recall correctly, in the GoboLinux case
> [...]
>> > I believe "/bin" is a symlink to the bin directory in the main
>> > install prefix, but there are patches so that while "/bin" can be
>> > used for lookups it does not appear when you list "/".
>>
>> If there's one thing I detest, it is such hiding of files. The GUI in
>> MacOSX does such things too, even /tmp is hidden there.
>
> I believe Gobo only has paths such as "/bin" for legacy compatibility
> (for example scripts starting with #!/bin/...). "/dev" is another
> case, since that isn't where Gobo puts its devices, but lots of things
> are going to assume they can use "/dev/zero" and "/dev/null".

I don't quite see the point in breaking compatibility just for the
sake of being different, or whatever their reasons may be. There is
absolutely no technical justification for doing it that way.

>> It's visible from a shell though.
>
> Gobo actually does it in the kernel; whether that's better or worse
> depends on your point of view. There's a command-line tool "GoboHide"
> that provides a list of hidden things:
>
> http://gobolinux.org/index.php?page=doc/articles/gobohide
>
> I think all of the things hidden in a normal GoboLinux desktop are
> just legacy symlinks, and the real locations they point to are fully
> visible. Unlike MacOS, where the Finder ignores a lot of real
> directories and applications (I've been bitten there by "/tmp"
> myself).

On MacOSX you at least have the option to ignore the braindead GUI
tools. Under the hood, it's largely POSIX compliant.

--
M?ns Rullg?rd
[email protected]

2004-10-27 21:08:04

by Dave Dodge

[permalink] [raw]

Subject: Re: [uClibc] Re: [OT] Re: The naming wars continue...

On Wed, Oct 27, 2004 at 07:27:04PM +0200, M?ns Rullg?rd wrote:
> Grzegorz Kulewski <[email protected]> writes:
> > 5. I am thinking of changing directory structure (and some other
> > things) some more... For example placing every package in its own dir
> > - like /apps/gcc/3.4.2/<install date>/{bin,lib,...} and placing
>
> I've been placing things in /opt/package/version for quite a while.

That's essentially what the GoboLinux distribution does, except that
it does it for everything down to and including core stuff like "sh"
and "ls".

> I use a perl script to set the *PATH environment variables to point at
> whatever versions I choose for each package.

If you have enough things installed you might run into problems with
the size of PATH (perhaps unlikely on Linux, but I recall hitting
the limit on Solaris at one point).

When I used to do this on Solaris, my most recent solution was to use
GNU stow to create symlinks from a single prefix to all of the
installed packages. Then I'd only need one additional entry in PATH,
MANPATH, and so on. stow made it easy enough to add and remove
packages, though there were trouble spots with duplicate files such as
the emacs info directory.

If I recall correctly, in the GoboLinux case gcc 3.4.2 would be
installed in "/Programs/GCC/3.4.2/{bin,lib,...}". A symlink from
"/Programs/GCC/Current" to "3.4.2" would select that as the current
version. The Current trees are symlinked into a single prefix (like I
did with stow). Gobo has scripts to manage all of this. I believe
"/bin" is a symlink to the bin directory in the main install prefix,
but there are patches so that while "/bin" can be used for lookups it
does not appear when you list "/".

-Dave Dodge

2004-10-27 20:29:07

[permalink] [raw]

Subject: Re: The naming wars continue...

On Wed, 27 Oct 2004, [email protected] wrote:
> >
> > which is a hell of a lot more descriptive, in my opinion.
>
> Indeed. But you hide this kind of information very carefully.
> Announcing with a subject like this one isn't very descriptive.

But that _wasn't_ in this idiotic thread.

The subject line of my announcement was

Subject: Linux 2.6.9-rc4 - pls test (and no more patches)

and the body was

Ok,
trying to make ready for the real 2.6.9 in a week or so, so please give
this a beating, and if you have pending patches, please hold on to them
for a bit longer, until after the 2.6.9 release. It would be good to have
a 2.6.9 that doesn't need a dot-release immediately ;)

The appended shortlog gives a pretty good idea of what has been going on.
Mostly small stuff, with some architecture updates and an ACPI update
thrown in for good measure.

(plus the shortlog).

Not exactly "hidden", was it?

And to everybody complaining about "-rcX" - people don't want to break
existing scripts, so the naming possibilities are either "-pre" or "-rc".
And we've used "-rc" for the whole 2.6.x series, so there had better be a
_good_ reason to change the naming.

So far, nobody has had a good reason. People are just complaining, because
this is an area where you can complain without actually having any real
hard technical input. It's "easy" to have an opinion.

So guys, look at the big picture. Is this really worth worrying over?

Linus

2004-10-27 19:46:20

[permalink] [raw]

Subject: Re: The naming wars continue...

Bill Davidsen wrote:
>
> I guess someone was nervous about mounting a local /usr/local on a
> (possibly) network mounted /usr and theu /opt, but that's a guess on my
> part as well.
>

/opt is structured, /usr/local is not; that's the big difference.

-hpa

2004-10-28 08:37:52

by [email protected]

[permalink] [raw]

Subject: Re: The naming wars continue...

On Mon, Oct 25, 2004 at 03:02:12PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 25 Oct 2004, Bill Davidsen wrote:
> >
> > I do agree that the pre and rc names gave a strong hint that (-pre) new
> > features would be considered or (-rc) it's worth doing more serious
> > testing.
>
> Well, I actually do try to _explain_ in the kernel mailing list
> annoucements what it going on.
>
> One of the reasons I don't like "-rcX" vs "-preX" is that they are so
> meaningless. In contrast, when I actually do the write-up on a patch, I
> tend to explain what I expect to have changed, and if I feel we're getting
> ready for a release, I'll say something like
>
> ..
>
> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
>
> ....
>
> which is a hell of a lot more descriptive, in my opinion.

Indeed. But you hide this kind of information very carefully.
Announcing with a subject like this one isn't very descriptive.
Also the majority of kernel downloaders probably don't read lkml at
all. So how should they figure out?

It would be very helpful if you could please include at least your
announcement in the changelog or some other file on kernel.org.
The changelog as of now is probably technically correct, but way to specific
and large for the average non kernel hacker - go ask someone who's happy
to get a kernel compiled by himself.

I don't care that much about the whole development model and the
numbering system as long as I can find the information above without
reading hundreds of lkml lists daily. I guess most of the average users
out there would think alike. You just don't address them right now.

Tom

ps:
using -rc suffix which everywhere else uses for release candidate
isn't a good choice. The -pre and -rc known from earlier kernels were
much more intuitive. Personally I'd even prefer something like
x.y.LATEST - x.y.LATEST-test{1,2..} - x.y.NEXT-rc{1,2,..} - x.y.NEXT

2004-10-29 14:43:26

[permalink] [raw]

Subject: [patch] 2.6.10-rc1: SCSI aacraid warning

On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
>...
> Summary of changes from v2.6.9 to v2.6.10-rc1
> ============================================
>...
> Mark Haverkamp:
>...
> o aacraid: dynamic dev update
>...

This causes the following warning with a recent gcc:

<-- snip -->

...
CC drivers/scsi/aacraid/aachba.o
drivers/scsi/aacraid/aachba.c: In function `aac_scsi_cmd':
drivers/scsi/aacraid/aachba.c:1140: warning: integer constant is too large for "long" type
...

<-- snip -->

The fix is simple:

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.10-rc1-mm2-full/drivers/scsi/aacraid/aachba.c.old 2004-10-29 16:16:52.000000000 +0200
+++ linux-2.6.10-rc1-mm2-full/drivers/scsi/aacraid/aachba.c 2004-10-29 16:22:14.000000000 +0200
@@ -1137,7 +1137,7 @@
char *cp;

dprintk((KERN_DEBUG "READ CAPACITY command.\n"));
- if (fsa_dev_ptr[cid].size <= 0x100000000)
+ if (fsa_dev_ptr[cid].size <= 0x100000000ULL)
capacity = fsa_dev_ptr[cid].size - 1;
else
capacity = (u32)-1;

2004-10-29 14:51:49

[permalink] [raw]

Subject: Re: The naming wars continue...

On Wed, Oct 27, 2004 at 05:48:28PM +0200, Tonnerre wrote:
> Salut,
>
> On Wed, Oct 27, 2004 at 11:33:25AM +0300, Denis Vlasenko wrote:
> > Why there is any distinction between, say, gcc and X?
> > KDE and Midnight Commander? etc... Why some of them go
> > to /opt while others are spread across dozen of dirs?
>
> Well.
>
> FHS specifies that everything needed to boot the system should got to
> /bin and /sbin. The base system (build system, etc.) should go to
> /usr. The rest should be /opt/itspackagename.
>...

The last phrase isn't exactly correct.

The FHS says:
Distributions may install software in /opt, but must not modify or
delete software installed by the local system administrator without
the assent of the local system administrator.

E.g. Debian installs nothing under /opt .

> Tonnerre

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-10-29 14:57:38

[permalink] [raw]

Subject: Re: The naming wars continue...

On Wed, Oct 27, 2004 at 03:17:16PM -0400, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> >
> >Why there is any distinction between, say, gcc and X?
> >KDE and Midnight Commander? etc... Why some of them go
> >to /opt while others are spread across dozen of dirs?
> >This seems to be inconsistent to me.
>
> At one time Sun had the convention that things in /usr could be mounted
> ro on multiple machines. That worked, it predates Linux so Linux was the
> o/s which chose to go another way, and it covered the base things in a
> system.
>
> That actually seems like a good way to split a networked environment,
> with /bin and /sbin having just enough to get the system up and mount
> /usr. I can't speak to why that is being done differently now.
>
> I guess someone was nervous about mounting a local /usr/local on a
> (possibly) network mounted /usr and theu /opt, but that's a guess on my
> part as well.

Read-only /usr is required according to the FHS, and at least on Debian
a read-only /usr works without problems.

A bigger problem might be to properly support it in the package manager.

cu
Adrian

[1]

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-10-29 15:35:47

by Mark Haverkamp

[permalink] [raw]

Subject: Re: [patch] 2.6.10-rc1: SCSI aacraid warning

On Fri, 2004-10-29 at 16:37 +0200, Adrian Bunk wrote:
> On Fri, Oct 22, 2004 at 03:05:13PM -0700, Linus Torvalds wrote:
> >...
> > Summary of changes from v2.6.9 to v2.6.10-rc1
> > ============================================
> >...
> > Mark Haverkamp:
> >...
> > o aacraid: dynamic dev update
> >...
>
>
> This causes the following warning with a recent gcc:
>
> <-- snip -->
>
> ...
> CC drivers/scsi/aacraid/aachba.o
> drivers/scsi/aacraid/aachba.c: In function `aac_scsi_cmd':
> drivers/scsi/aacraid/aachba.c:1140: warning: integer constant is too large for "long" type
> ...
>
> <-- snip -->
>
>
> The fix is simple:
>
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> --- linux-2.6.10-rc1-mm2-full/drivers/scsi/aacraid/aachba.c.old 2004-10-29 16:16:52.000000000 +0200
> +++ linux-2.6.10-rc1-mm2-full/drivers/scsi/aacraid/aachba.c 2004-10-29 16:22:14.000000000 +0200
> @@ -1137,7 +1137,7 @@
> char *cp;
>
> dprintk((KERN_DEBUG "READ CAPACITY command.\n"));
> - if (fsa_dev_ptr[cid].size <= 0x100000000)
> + if (fsa_dev_ptr[cid].size <= 0x100000000ULL)
> capacity = fsa_dev_ptr[cid].size - 1;
> else
> capacity = (u32)-1;

Sorry about that, I have it fixed in my working version. I must have
forgotten to add it to the patch.

--
Mark Haverkamp <[email protected]>

2004-10-29 15:38:13