Please release a stable kernel Linux 3.0

Please release a stable kernel Linux 3.0

[Zoltán HUBERT]

Hello gentlemen (and ladies ?)

As a power-user (NOT a hacker) I kindly ask you to please 
change the naming scheme and come back to the traditional 
model, and release a stable kernel while working on a 
develoment branch.

I'm not on the [lkml] so should you answer please CC my 
e-mail: zoltan.hubert@zzaero.com

All people who might read this know that traditionally 
stable releases are even numbered and development branches 
are odd numbered. This changed during late develoment of 
2.6, according to my analysis because of the "invention" of 
GIT which was itself necessary because of BitKeeper (insert 
ooooooooold flame-wars here) and which allowed very dynamic 
develoment. While this has been effective, alternative 
voices (Mr Morton complaining that more bugs were added 
than repaired, semi-stable semi-supported 2.6.x.y branches 
where invented...) come more and more into the front. The 
upcoming GPL v3 versus v2 debate will make things worse, 
and we all know this. The un-ending stable ABI argument 
goes into this same direction.

So I feel that a turning-point is coming where a really 
really really (x 15) stable and reliable kernel is NEEDED.

You might think it's easy for me to simply "use" Linux and 
complain while you're doing the hard stuff. As it happens, 
the current development/stable model makes our life as 
"users" more and more difficult. I'm using Linux since 1997 
on a Mac thanks to LinuxPPC-1997, and I'm a hard pusher of 
Linux whenever possible, sometimes against the common 
sense, for example when I favor using National Instrument 
cards with Linux drivers and custom written TCP/IP server 
against easy LabView on Windows. While some of you dislike 
closed source drivers, the choices "we users" face are:
- closed source drivers with closed source OS
- closed source drivers with open source OS
Please consider that we are living in a REAL world, and not 
Disney-Land.



So I've demonstrated that from a "users" perspective a new 
stable Linux would be of advantage. I'll now list what I 
suggest for this new stable branch:

First, there are some fundamental ideas in the pipelines of 
forthcoming releases which should be part of the next 
"stable" Linux (Reiser4, the new scheduler from Mr. Molnár, 
virtualisation...). So any next stable kernel branch should 
include most of these recent developments, with the goal of 
stabilising them. May-be a poll on [lkml] as to which 
feature to include or not would help ?

Second, there was once a suggestion that 2.6 should be 3.0 
since a lot of things changed:
- modules called .ko and not .o
- the output of the compile
- ... (I don't remember)
This was a brilliant suggestion and I whish another 
consideration was given to that idea. You might even go a 
step further and call kernel modules .kmod. Why on earth 
call "kernel object" things that are "kernel modules" ? And 
that every person calls "modules" and not "objects" ? I 
know I know, in UNIX dynamic libraries are .so "shared 
objects", so what ? A "module" is a "module" and NOT an 
"object", call a cat a cat.

Third, while a stable ABI in a dynamically developed kernel 
is a difficult/impossible/unwanted feature, it should be 
possible to implement in a stable branch. This could even 
be a distinction between "stable" and "development" 
branches. And it would certainly help vendors of 
closed-source drivers.

Fourth, a finnish developper on this list suggested several 
times that people should be allowed to try stupid things. 
Well, I'm doing just that.



As a conclusion, please, please, consider splitting again 
the kernel in 2 distinct branches, one labeled 
"development" suiting your needs and another labeled 
"stable" for us users.

Sincerely yours,

Zoltán.





-- 
 
________________________

Zoltan
________________________

 

Re: Please release a stable kernel Linux 3.0

[Chuck Ebbert]

On 06/21/2007 05:49 PM, Zoltán HUBERT wrote:
> 
> So I feel that a turning-point is coming where a really 
> really really (x 15) stable and reliable kernel is NEEDED.

I'll say.

Re: Please release a stable kernel Linux 3.0

[Alan Cox]

> and we all know this. The un-ending stable ABI argument 
> goes into this same direction.

We don't have a stable ABI argument. Linus and others have repeatedly
made this clear; Stable user space ABI is important (sysfs developers
please note 8)). Stable kernel ABI/API not going to happen.

> So I feel that a turning-point is coming where a really 
> really really (x 15) stable and reliable kernel is NEEDED.

Its incredibly hard to keep a stable kernel side API/ABI by just
backporting fixes. Fortunately you can pay vendors to do this for you and
provide support, or if you just want the bits run stuff like Centos

Re: Please release a stable kernel Linux 3.0

[Zoltán HUBERT]

On Friday 22 June 2007 00:08, you wrote:
> > So I feel that a turning-point is coming where a really
> > really really (x 15) stable and reliable kernel is
> > NEEDED.
>
> Its incredibly hard to keep a stable kernel side API/ABI
> by just backporting fixes. Fortunately you can pay
> vendors to do this for you and provide support, or if you
> just want the bits run stuff like Centos

Thanks Alan,

but there was a time when a british bearded person did that 
just fine. Later a haired Brazilian did it fine too. Now 
that BIG bu$ine$$e$ are in the game shouldn't it be 
easier ?


z


PS: Centos ? WTF ?

-- 
 
________________________

Zoltan
________________________

 

Re: Please release a stable kernel Linux 3.0

[Jesper Juhl]

On 21/06/07, Zoltán HUBERT <zoltan.hubert@zzaero.com> wrote:
[snip]
> All people who might read this know that traditionally
> stable releases are even numbered and development branches
> are odd numbered. This changed during late develoment of
> 2.6, according to my analysis because of the "invention" of
> GIT which was itself necessary because of BitKeeper (insert
> ooooooooold flame-wars here) and which allowed very dynamic
> develoment.

Git itself, nor bitkeeper was not the main reason behind the desition
to maintain 2.6.x as the stable kernel going forward.

> While this has been effective, alternative
> voices (Mr Morton complaining that more bugs were added
> than repaired, semi-stable semi-supported 2.6.x.y branches
> where invented...) come more and more into the front.

I myself have argued that we should be focusing more on stability and
regression fixing, but I'm not so sure that a 2.6.7 devel branch would
solve this. In general the 2.6.x.y -stable kernels seem to be doing
the job pretty good.

>The
> upcoming GPL v3 versus v2 debate will make things worse,

How is the GPLv2 vs GPLv3 debate relevant to kernel stability, ABI
stability or anything else of the sort?

> and we all know this. The un-ending stable ABI argument
> goes into this same direction.

What I think you are wishing for is a stable API - which is not going
to happen; please read Documentation/stable_api_nonsense.txt
(http://lxr.linux.no/source/Documentation/stable_api_nonsense.txt).
A stable ABI we already have.

[snip]
> You might think it's easy for me to simply "use" Linux and
> complain while you're doing the hard stuff. As it happens,
> the current development/stable model makes our life as
> "users" more and more difficult.

In what way?

Most users should be using distribution kernels anyway, not vanilla
kernel.org kernels. Those distribution kernels should provide you with
all the stability you require.

>I'm using Linux since 1997
> on a Mac thanks to LinuxPPC-1997, and I'm a hard pusher of
> Linux whenever possible, sometimes against the common
> sense, for example when I favor using National Instrument
> cards with Linux drivers and custom written TCP/IP server
> against easy LabView on Windows. While some of you dislike
> closed source drivers, the choices "we users" face are:
> - closed source drivers with closed source OS
> - closed source drivers with open source OS
> Please consider that we are living in a REAL world, and not
> Disney-Land.
>

As far as I am aware, both nVidia and ATI have closed drivers
available for you to use if you please. And they should work just fine
with most distribution kernels as well as vanilla.


> So I've demonstrated that from a "users" perspective a new
> stable Linux would be of advantage. I'll now list what I
> suggest for this new stable branch:
>
I don't think you have demonstrated that.
How specifically is the current development model hurting you?
What exactely would we gain by switching back to the old
stable/unstable branch model?

[snip]
> Why on earth
> call "kernel object" things that are "kernel modules" ? And
> that every person calls "modules" and not "objects" ? I
> know I know, in UNIX dynamic libraries are .so "shared
> objects", so what ? A "module" is a "module" and NOT an
> "object", call a cat a cat.
>
It sure is an object, it's even called object code. I think the name
suits just fine. In any case, it's just a name.

> Third, while a stable ABI in a dynamically developed kernel
> is a difficult/impossible/unwanted feature,

A stable ABI is very much a wanted feature and one that a lot of work
goes into maintaining.
Note; ABI != API.

> it should be
> possible to implement in a stable branch. This could even
> be a distinction between "stable" and "development"
> branches. And it would certainly help vendors of
> closed-source drivers.
>
If they want to keep their drivers closed they get to do all the hard
work of tracking kernel API changes. Their choice, their problem. I
don't think you'll find very many people on this list who gives a damn
about the troubles of closed source driver developers.

[snip]


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Please release a stable kernel Linux 3.0

[Chuck Ebbert]

On 06/21/2007 06:29 PM, Jesper Juhl wrote:
> 
> I myself have argued that we should be focusing more on stability and
> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
> solve this. In general the 2.6.x.y -stable kernels seem to be doing
> the job pretty good.
> 
 
Even the good ones that get lots of fixes aren't all that good. The
biggest problem ATM is that suspend is badly broken and keeps getting
worse...

Re: Please release a stable kernel Linux 3.0

[Stefan Richter]

Zoltán HUBERT wrote:
> So I feel that a turning-point is coming where a really 
> really really (x 15) stable and reliable kernel is NEEDED.

Not satisfied with 2.6.16.y or one of the "enterprise" distro kernels?
-- 
Stefan Richter
-=====-=-=== -==- =-==-
http://arcgraph.de/sr/

Re: Please release a stable kernel Linux 3.0

[Zoltán HUBERT]

On Friday 22 June 2007 00:29, Jesper Juhl wrote:

> > You might think it's easy for me to simply "use" Linux
> > and complain while you're doing the hard stuff. As it
> > happens, the current development/stable model makes our
> > life as "users" more and more difficult.
>
> In what way?

Well, I'm using SuSE Pro 9.3 (excellent choice by the way), 
coming with kernel 2.6.10-SuSE, on a ATI laptop, and the 
drivers privided wouldn't compile (suspend & freinds). The 
SATA disks were only supported from 2.6.15 (which just came 
out), so I had to edit the "source code" of a closed source 
driver to make it all work well. If that's "easy" for you I 
doubt it is for 99.999% of earth's population. "World 
domination" is far away.

Also, the 7 National Instruments cards I'm using for a 
deformable mirror in Adaptive Optics in an industrial PC 
are "certified" for SuSE 9.3 only. Which, this week, got 
discontinued. So what now ?

> Most users should be using distribution kernels anyway,

???? should ???? who do you think "users" are ????

> not vanilla kernel.org kernels. 

Who said I was using vanilla kernels ?

> > "development" branches. And it would certainly help
> > vendors of closed-source drivers.

> Their choice, their problem. 

no, it's MY problem.

> I don't think you'll find very 
> many people on this list who gives a damn about the
> troubles of closed source driver developers.

and what about their users ?


z



-- 
 
________________________

Zoltan
________________________

 

Re: Please release a stable kernel Linux 3.0

[Rene Herman]

On 06/21/2007 11:49 PM, Zoltán HUBERT wrote:

> Please consider that we are living in a REAL world, and not 
> Disney-Land.

Well, I don't know about that so much; I've always thought Linus bears a 
striking resemblance to Mickey Mouse.

More to the point though -- could you please consider just going away for at 
least a month? Subscribers to this list just sat through a massive licensing 
flamefest and could at this point sort of do without a (delayed) bitkeeper, 
development branch, stable API and reiser4 one.

Deal? See you in a month?

Thanks in advance!

Rene.

Re: Please release a stable kernel Linux 3.0

[Zoltán HUBERT]

On Friday 22 June 2007 00:52, Stefan Richter wrote:
> Zoltán HUBERT wrote:
> > So I feel that a turning-point is coming where a really
> > really really (x 15) stable and reliable kernel is
> > NEEDED.
>
> Not satisfied with 2.6.16.y or one of the "enterprise"
> distro kernels?

so why not call this a day and make it 2.6-stable and the 
others 2.7 ?

z


-- 
 
________________________

Zoltan
________________________

 

Re: Please release a stable kernel Linux 3.0

[Lennart Sorensen]

On Thu, Jun 21, 2007 at 06:34:20PM -0400, Chuck Ebbert wrote:
> Even the good ones that get lots of fixes aren't all that good. The
> biggest problem ATM is that suspend is badly broken and keeps getting
> worse...

I wasn't under the impression suspend had really ever worked.  Such a
messy problem to solve.

And how does going back to having new features only arive in stable
kernels every 2 years an improvement over the current system?  Getting
support for new hardware (which lots of users keep insistingon because
for some reason they keep insisting on buying the stuff that is currently
for sale) also requires writing new code.

--
Len Sorensen

Re: Please release a stable kernel Linux 3.0

[Jesper Juhl]

On 22/06/07, Zoltán HUBERT <zoltan.hubert@zzaero.com> wrote:
> On Friday 22 June 2007 00:29, Jesper Juhl wrote:
>
> > > You might think it's easy for me to simply "use" Linux
> > > and complain while you're doing the hard stuff. As it
> > > happens, the current development/stable model makes our
> > > life as "users" more and more difficult.
> >
> > In what way?
>
> Well, I'm using SuSE Pro 9.3 (excellent choice by the way),
> coming with kernel 2.6.10-SuSE, on a ATI laptop, and the
> drivers privided wouldn't compile (suspend & freinds).

Didn't the distribution already come with pre-compiled drivers?

> The
> SATA disks were only supported from 2.6.15 (which just came
> out),

So you installed the distribution on hardware it did not support. How
is that the kernel's problem? Go talk to Novell about that.


>so I had to edit the "source code" of a closed source
> driver to make it all work well. If that's "easy" for you I
> doubt it is for 99.999% of earth's population. "World
> domination" is far away.
>
That's not easy. Agreed. But, that's hardly the kernels problem.
That's your problem for trying to install a distribution on
non-supported hardware. One could also argue that its your problem for
buying hardware without open drivers available.


> Also, the 7 National Instruments cards I'm using for a
> deformable mirror in Adaptive Optics in an industrial PC
> are "certified" for SuSE 9.3 only. Which, this week, got
> discontinued. So what now ?
>
Complain to the vendor of that hardware. Ask them to either continue
supporting the OS you are using or open source the drivers.
How can that ever be anything but an issue between you and your hardware vendor?

> > Most users should be using distribution kernels anyway,
>
> ???? should ???? who do you think "users" are ????
>

Well, you for one claimed you were a user, and I would say almost
anyone who doesn't hack the kernel or wants to test it falls into the
user category.

> > not vanilla kernel.org kernels.
>
> Who said I was using vanilla kernels ?
>
Noone, I made a guess.

> > > "development" branches. And it would certainly help
> > > vendors of closed-source drivers.
>
> > Their choice, their problem.
>
> no, it's MY problem.
>
Indeed. It is your problem. You bought hardware not supported by Open
Source drivers so noone on LKML can help you with that - only vendor
of the closed source driver can help you. To buy that hardware was
your choice, hence it it is your problem, we can agree on that.

> > I don't think you'll find very
> > many people on this list who gives a damn about the
> > troubles of closed source driver developers.
>
> and what about their users ?
>
That's between the vendor and their customers. The vendor made a
choice only to release closed source drivers and the customer made a
choice to purchase hardware only supported by closed source drivers.
That can never be anything but the vendor and customers problem.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Please release a stable kernel Linux 3.0

[Chuck Ebbert]

On 06/21/2007 07:01 PM, Lennart Sorensen wrote:
> On Thu, Jun 21, 2007 at 06:34:20PM -0400, Chuck Ebbert wrote:
>> Even the good ones that get lots of fixes aren't all that good. The
>> biggest problem ATM is that suspend is badly broken and keeps getting
>> worse...
> 
> I wasn't under the impression suspend had really ever worked.  Such a
> messy problem to solve.
> 

It never worked reliably for everyone, but with each new release it
seems to get worse.

Re: Please release a stable kernel Linux 3.0

[Lennart Sorensen]

On Fri, Jun 22, 2007 at 12:57:33AM +0200, Zolt?n HUBERT wrote:
> Well, I'm using SuSE Pro 9.3 (excellent choice by the way), 
> coming with kernel 2.6.10-SuSE, on a ATI laptop, and the 
> drivers privided wouldn't compile (suspend & freinds). The 
> SATA disks were only supported from 2.6.15 (which just came 
> out), so I had to edit the "source code" of a closed source 
> driver to make it all work well. If that's "easy" for you I 
> doubt it is for 99.999% of earth's population. "World 
> domination" is far away.

Have you ever tried installing windows xp from scratch on a new laptop?
Same (if not worse) problem.

> Also, the 7 National Instruments cards I'm using for a 
> deformable mirror in Adaptive Optics in an industrial PC 
> are "certified" for SuSE 9.3 only. Which, this week, got 
> discontinued. So what now ?

If you buy hardware that only works with one particular release of one
distribution, that is pretty much a way to ensure you will soon be
unable to use that hardware anymore.  Don't do that.

> ???? should ???? who do you think "users" are ????

People that install a distribution and use it.  Sometimes they upgrade
to the next release of the distribution.

> Who said I was using vanilla kernels ?

Well if you change the kernel on your distribution, then you aren't
running that distribution anymore.  You changed something.

> no, it's MY problem.

Well it is their problem to fix, and your problem that you bought their
stuff in the first place.

> and what about their users ?

The kernel developers can't fix the problems of the closed source code
anyhow, so it isn't the kernel developers problem.  It is a problem of
the closed source developer and their users (who chose that hardware
themselves.)  The kernel developers didn't recomend the hardware, and
didn't make the users buy that stuff.

--
Len Sorensen

Re: Please release a stable kernel Linux 3.0

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1545 bytes --]


On Jun 22 2007 00:29, Jesper Juhl wrote:
> On 21/06/07, Zoltán HUBERT <zoltan.hubert@zzaero.com> wrote:
> [snip]
>> All people who might read this know that traditionally
>> stable releases are even numbered and development branches
>> are odd numbered. This changed during late develoment of
>> 2.6, according to my analysis because of the "invention" of
>> GIT which was itself necessary because of BitKeeper (insert
>> ooooooooold flame-wars here) and which allowed very dynamic
>> develoment.
>[...]
> I myself have argued that we should be focusing more on stability and
> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
> solve this. In general the 2.6.x.y -stable kernels seem to be doing
> the job pretty good.

For my part, I think the 2.6.<odd> did not go as well as the 2.6.<even>,
beginning with x=16.

>> Why on earth call "kernel object" things that are "kernel modules"
>> ? And that every person calls "modules" and not "objects" ? I know
>> I know, in UNIX dynamic libraries are .so "shared objects", so
>> what ? A "module" is a "module" and NOT an "object", call a cat a
>> cat.
>>
> It sure is an object, it's even called object code. I think the name
> suits just fine. In any case, it's just a name.

Back in the 2.4 days and e.g. on Solaris (still) today, a kernel
object file is [can be] a kernel module. Under Linux, this is not the
case anymore since 2.6.x when kbuild started to postprocess modules
(creating these nice .mod.c and .mod.o files and the benefits
associated with it).



	Jan
-- 

Re: Please release a stable kernel Linux 3.0

[david]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1125 bytes --]

On Fri, 22 Jun 2007, Jan Engelhardt wrote:

> On Jun 22 2007 00:29, Jesper Juhl wrote:
>> On 21/06/07, Zoltán HUBERT <zoltan.hubert@zzaero.com> wrote:
>> [snip]
>>> All people who might read this know that traditionally
>>> stable releases are even numbered and development branches
>>> are odd numbered. This changed during late develoment of
>>> 2.6, according to my analysis because of the "invention" of
>>> GIT which was itself necessary because of BitKeeper (insert
>>> ooooooooold flame-wars here) and which allowed very dynamic
>>> develoment.
>> [...]
>> I myself have argued that we should be focusing more on stability and
>> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
>> solve this. In general the 2.6.x.y -stable kernels seem to be doing
>> the job pretty good.
>
> For my part, I think the 2.6.<odd> did not go as well as the 2.6.<even>,
> beginning with x=16.

you misunderstood the even/odd it was never 2.x.y with y odd/even being 
stable / development, it was the x being even/odd to indicate stable / 
development.

all 2.6.x are stable, all 2.5.x were development.

David Lang

Re: Please release a stable kernel Linux 3.0

[Måns Rullgård]

Chuck Ebbert <cebbert@redhat.com> writes:

> On 06/21/2007 07:01 PM, Lennart Sorensen wrote:
>> On Thu, Jun 21, 2007 at 06:34:20PM -0400, Chuck Ebbert wrote:
>>> Even the good ones that get lots of fixes aren't all that good. The
>>> biggest problem ATM is that suspend is badly broken and keeps getting
>>> worse...
>> 
>> I wasn't under the impression suspend had really ever worked.  Such a
>> messy problem to solve.
>
> It never worked reliably for everyone, but with each new release it
> seems to get worse.

2.6.22-rcsomething works better for me than any kernel before it.
It's certainly not only getting worse.

-- 
Måns Rullgård
mans@mansr.com

Re: Please release a stable kernel Linux 3.0

[Arjan van de Ven]

On Thu, 2007-06-21 at 19:08 -0400, Chuck Ebbert wrote:
> On 06/21/2007 07:01 PM, Lennart Sorensen wrote:
> > On Thu, Jun 21, 2007 at 06:34:20PM -0400, Chuck Ebbert wrote:
> >> Even the good ones that get lots of fixes aren't all that good. The
> >> biggest problem ATM is that suspend is badly broken and keeps getting
> >> worse...
> > 
> > I wasn't under the impression suspend had really ever worked.  Such a
> > messy problem to solve.
> > 
> 
> It never worked reliably for everyone, but with each new release it
> seems to get worse.

the thing is just fundamentally not designed right. Declaring it stable
ain't gonna fix that. Having someone do a right design (which will
obviously will go through some breakage period, even if it's an
evolution of the current design) is a required step of getting s/r more
reliable... but the current one doesn't get stable just by declaring it
so.

Re: Please release a stable kernel Linux 3.0

[Rik van Riel]

Zoltán HUBERT wrote:

> So I feel that a turning-point is coming where a really 
> really really (x 15) stable and reliable kernel is NEEDED.

You are free to create one, or follow Adrian Bunk's 2.6.16.x
series.  Nobody's stopping you.

Oh, 2.6.16 does not have the features you need?

You'd be out of luck with a stable/unstable kernel split,
since your stable kernel would not have the features...

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

Re: Please release a stable kernel Linux 3.0

[Bernd Petrovitsch]

On Fri, 2007-06-22 at 00:57 +0200, Zoltán HUBERT wrote:
[...]
> Well, I'm using SuSE Pro 9.3 (excellent choice by the way), 

Perhaps in April 2005. And if I read
http://www.pro-linux.de/security/7043 correctly it is unsupported
anyways (sorry, I can't find a date on that page).
ATM there are probably newer releases and I doubt that there are no
updates for the kernel (even Debian/Stable has them).

> coming with kernel 2.6.10-SuSE, on a ATI laptop, and the 
> drivers privided wouldn't compile (suspend & freinds). The 
> SATA disks were only supported from 2.6.15 (which just came 
> out), so I had to edit the "source code" of a closed source 
> driver to make it all work well. If that's "easy" for you I 
> doubt it is for 99.999% of earth's population. "World 
> domination" is far away.

That's an unsolvable problem: You want a "stable" distribution from year
X to support hardware designed and built in the future.

And BTW perhaps it is enough to take the kernel RPM (+ plus a few of the
kernel-near ones - dependencies will probably tell you) from the most
recent SuSE and try that if you for whatever reason want to stay with
the above release.

[...]

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Please release a stable kernel Linux 3.0

[Jan Engelhardt]

On Jun 21 2007 16:32, david@lang.hm wrote:
>>
>> For my part, I think the 2.6.<odd> did not go as well as the 2.6.<even>,
>> beginning with x=16.
>
> you misunderstood the even/odd it was never 2.x.y with y odd/even being stable
> / development, it was the x being even/odd to indicate stable / development.
>
> all 2.6.x are stable, all 2.5.x were development.
[2.even.x stable, 2.odd.x development]

True dat. But it _feels_ like 2.6.odd is becoming developmental.
(The good thing however is that there's a 2.6.even quite shortly after a
2.6.odd ;-))
So basically it's like "a good kernel every 4 months".


	Jan
-- 

Re: Please release a stable kernel Linux 3.0

[Xavier Bestel]

On Thu, 2007-06-21 at 23:49 +0200, Zoltán HUBERT wrote:
> While some of you dislike 
> closed source drivers, the choices "we users" face are:
> - closed source drivers with closed source OS
> - closed source drivers with open source OS
> Please consider that we are living in a REAL world, and not 
> Disney-Land.

Strange, I'm currently using this option:
- open source drivers with open source OS
and I'm sure I'm not living in Disney-Land.

	Xav

Re: Please release a stable kernel Linux 3.0

[Bernd Petrovitsch]

On Fri, 2007-06-22 at 11:19 +0200, Xavier Bestel wrote:
> On Thu, 2007-06-21 at 23:49 +0200, Zoltán HUBERT wrote:
> > While some of you dislike 
> > closed source drivers, the choices "we users" face are:
> > - closed source drivers with closed source OS
> > - closed source drivers with open source OS

You forgot the third, correct, way to do to it: buy hardware where
open-source drivers exist if you don't want to live the above (and yes,
there are even open source graphic cards and WLAN drivers out there).

You didn't, tough luck. You could actually help driver developers if
only with testing new drivers versions.

> > Please consider that we are living in a REAL world, and not 
> > Disney-Land.

Yes, please also consider this and get rid of the "I'm an end user,
everything I do is right, I can demand what I want, everyone else must
follow for free and I need not do anything" attitude.

The usual alternatives include (but are not limited to):
- find someone else to fix *your* problems (it is up to you, how to
   motivate that being. "Money" is not the only motivation in the world
   but it sometimes works).
   Just demanding, whining and ranting on public mailing list doesn't
   motivate - at least not me.
- pay someone indirectly by buying a plug-n-play OS
- buy hardware with "Linux" pre-installed with the promise that
   everything works (and if something doesn't work, you should be able to
   give the hardware back or get a replacement or ...).
   Even if the pre-installed "Linux" doesn't fit you can install another
   one.
   If you really dislike closed source drivers, you better check that that
   hardware doesn't need ndiswrapper though. God knows what sales people
   tell you to sell a thing.
   Several shops hereover (in .at) actually offer to boot from a Live-CD
   (especially with laptops) so that one can see if and what is working
   or not.
- as mentioned above, buy hardware with parts where open source drivers
   exist
Probably the last two parts imply that it is not as cheap as the next
"special price" hardware (but think about "why should  a store sell
hardware cheaper than others and/or before?").

> Strange, I'm currently using this option:
> - open source drivers with open source OS
> and I'm sure I'm not living in Disney-Land.

Yes, but then you have to think before buying the next cheap hardware
and wonder afterwards that there are not 20 kernel developers eagerly
waiting to write a driver for a brand-new piece of hardware without any
documentation (except the products name).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Please release a stable kernel Linux 3.0

[Rafael J. Wysocki]

On Friday, 22 June 2007 00:34, Chuck Ebbert wrote:
> On 06/21/2007 06:29 PM, Jesper Juhl wrote:
> > 
> > I myself have argued that we should be focusing more on stability and
> > regression fixing, but I'm not so sure that a 2.6.7 devel branch would
> > solve this. In general the 2.6.x.y -stable kernels seem to be doing
> > the job pretty good.
> > 
>  
> Even the good ones that get lots of fixes aren't all that good. The
> biggest problem ATM is that suspend is badly broken and keeps getting
> worse...

Can you please provide me with any links to suspend-related bug reports from
you?

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Please release a stable kernel Linux 3.0

[Chuck Ebbert]

On 06/22/2007 11:00 AM, Rafael J. Wysocki wrote:
> On Friday, 22 June 2007 00:34, Chuck Ebbert wrote:
>> On 06/21/2007 06:29 PM, Jesper Juhl wrote:
>>> I myself have argued that we should be focusing more on stability and
>>> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
>>> solve this. In general the 2.6.x.y -stable kernels seem to be doing
>>> the job pretty good.
>>>
>>  
>> Even the good ones that get lots of fixes aren't all that good. The
>> biggest problem ATM is that suspend is badly broken and keeps getting
>> worse...
> 
> Can you please provide me with any links to suspend-related bug reports from
> you?
> 

I get so many suspend/resume bug reports that I've given up trying
to get them fixed. And there are so many bugs that are even worse,
like crashes during normal use, data corruption, etc. that suspend
bugs don't get much attention. But here are the ones for Fedora 6;
the list would be much longer if I included Fedora 5 and 7:

Suspend to memory does not work anymore on Acer TM 740
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216372

Power off and suspend-to-RAM not working on Sony Vaio VGN-C140G
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218341

Thinkpad T43 fails to resume after suspend
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220977

suspend does not work on 2.6.19-1.2895 (worked great on 2.6.18-1.2869)
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223731

problems by suspend after a resume from suspend
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224141

System crash on suspend
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225028

Suspend fails with latest kernel
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225062

Suspend to RAM fails after upgrade to 2.6.19-1.2895.fc6
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227789

Touchpad does not work after resume from suspend to ram
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229201

System ceased to resume from suspend on Toshiba Satellite A100-847
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229464

2.6.19* kernels won't suspend / resume laptop; 2.6.18 works fine.
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230853

Unexpectedly high power drain while suspended
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230947

Laptop overheats on resume from suspend to ram
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233246

Kernel 2933 crashes laptop on suspend
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234622

Kernel oops after attempted suspend
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244245

Re: Please release a stable kernel Linux 3.0

[Willy Tarreau]

On Fri, Jun 22, 2007 at 12:21:51AM +0200, Zoltán HUBERT wrote:
> On Friday 22 June 2007 00:08, you wrote:
> > > So I feel that a turning-point is coming where a really
> > > really really (x 15) stable and reliable kernel is
> > > NEEDED.
> >
> > Its incredibly hard to keep a stable kernel side API/ABI
> > by just backporting fixes. Fortunately you can pay
> > vendors to do this for you and provide support, or if you
> > just want the bits run stuff like Centos
> 
> Thanks Alan,
> 
> but there was a time when a british bearded person did that 
> just fine. Later a haired Brazilian did it fine too. Now 
> that BIG bu$ine$$e$ are in the game shouldn't it be 
> easier ?

Big businesses place their money where there are customers.
People maintaining stable releases do that because they use
them on some long term projects or because they want to do
it by conviction, but in both cases, there are very few, if
any at all, $$ involved.

For 2.4, I'm in the first category (used in products). But
I will not do this all my life (unless it ends sooner than
expected). After I do not use it, I will most probably
continue in the second category, then someday declare it
"out of support", perhaps when there will be no patch for
one year.

I think that Adrian Bunk directly started in the second
category with 2.6.16 (by conviction). And BTW, you were
not fair saying that 2.6.x.y are semi-stable and semi-
supported. 2.6.16 has been maintained for more than one
year now, and in my opinion, it is a success.

> PS: Centos ? WTF ?

it's a repackaging from Red Hat Enterprise sources. So you
have the long time fixes, and you can selfishly keep your
money for you without supporting any of the big businesses
in the game which ought to make it easier ...

Willy

Re: Please release a stable kernel Linux 3.0

[Rafael J. Wysocki]

On Friday, 22 June 2007 19:11, Chuck Ebbert wrote:
> On 06/22/2007 11:00 AM, Rafael J. Wysocki wrote:
> > On Friday, 22 June 2007 00:34, Chuck Ebbert wrote:
> >> On 06/21/2007 06:29 PM, Jesper Juhl wrote:
> >>> I myself have argued that we should be focusing more on stability and
> >>> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
> >>> solve this. In general the 2.6.x.y -stable kernels seem to be doing
> >>> the job pretty good.
> >>>
> >>  
> >> Even the good ones that get lots of fixes aren't all that good. The
> >> biggest problem ATM is that suspend is badly broken and keeps getting
> >> worse...
> > 
> > Can you please provide me with any links to suspend-related bug reports from
> > you?
> > 
> 
> I get so many suspend/resume bug reports that I've given up trying
> to get them fixed. And there are so many bugs that are even worse,
> like crashes during normal use, data corruption, etc. that suspend
> bugs don't get much attention. But here are the ones for Fedora 6;
> the list would be much longer if I included Fedora 5 and 7:

Well, thanks.

I'll have a look at these, perhaps I can figure out which patches are needed
to fix them (if there are any).  Also, please add my address to the CC lists
of any new hibernation/suspend-related bug reports, so that I'm aware of them.

FYI, I've started to cherry pick patches related to suspend and hibernation
that I think are relevant for each -rc kernel (at
http://www.sisk.pl/kernel/hibernation_and_suspend/).  [However, I don't
backport patches because of the lack of time, so when the next -rc is out, I
rediff the patchset against this one and don't add new patches for the previous
kernels any more.]

There also is the Hibernation/Suspend subcategory in "Power Management" in
the kernel bugizlla.  Please ask your users to file bug reports in there if
that helps.

Also, all of the currently tracked (with the bugzilla) problems related to
hibernation and suspend are linked to this entry:

http://bugzilla.kernel.org/show_bug.cgi?id=7216

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Please release a stable kernel Linux 3.0

[Chris Snook]

Zoltán HUBERT wrote:
> Hello gentlemen (and ladies ?)
> 
> As a power-user (NOT a hacker) I kindly ask you to please 
> change the naming scheme and come back to the traditional 
> model, and release a stable kernel while working on a 
> develoment branch.
> 
> I'm not on the [lkml] so should you answer please CC my 
> e-mail: zoltan.hubert@zzaero.com

Please don't do this.  It's very rude.  It's one thing to report a bug 
and say "Please CC me", but it's quite another to ask us to completely 
change the way we're doing everything without actually observing the 
process.  If you're going to make such sweeping requests like this, at 
least have the courtesy to subscribe to the list and read a sampling of 
the traffic for long enough to realize that the current development 
model, for all its flaws, was developed for very good reasons.

> All people who might read this know that traditionally 
> stable releases are even numbered and development branches 
> are odd numbered. This changed during late develoment of 
> 2.6, according to my analysis because of the "invention" of 
> GIT which was itself necessary because of BitKeeper (insert 
> ooooooooold flame-wars here) and which allowed very dynamic 
> develoment. While this has been effective, alternative 
> voices (Mr Morton complaining that more bugs were added 
> than repaired, semi-stable semi-supported 2.6.x.y branches 
> where invented...) come more and more into the front. The 
> upcoming GPL v3 versus v2 debate will make things worse, 
> and we all know this. The un-ending stable ABI argument 
> goes into this same direction.

What argument?  Userspace ABI is stable, by rule.  Kernel internal API 
and ABI is not.  There is no argument, just people who come along from 
time to time and ask us to do everything the way they like, without 
offering anything in return.

> So I feel that a turning-point is coming where a really 
> really really (x 15) stable and reliable kernel is NEEDED.

That's what vendor kernels are for.  If you don't want to pay the money, 
just download the source and rebuild it yourself.

> You might think it's easy for me to simply "use" Linux and 
> complain while you're doing the hard stuff. As it happens, 
> the current development/stable model makes our life as 
> "users" more and more difficult. I'm using Linux since 1997 
> on a Mac thanks to LinuxPPC-1997, and I'm a hard pusher of 
> Linux whenever possible, sometimes against the common 
> sense, for example when I favor using National Instrument 
> cards with Linux drivers and custom written TCP/IP server 
> against easy LabView on Windows. While some of you dislike 
> closed source drivers, the choices "we users" face are:
> - closed source drivers with closed source OS
> - closed source drivers with open source OS
> Please consider that we are living in a REAL world, and not 
> Disney-Land.

Closed or open, someone somewhere is probably willing to take your money 
in exchange for making it work.  If you're not willing to spend money, 
or offer something else in exchange, then nobody has any reason to go 
out of their way make life easy for you.  The community works to help 
itself, not the freeloaders.  Many of us (such as myself) actually get 
paid to maintain stable releases to ensure a good user experience, so 
we're well aware of the issues you face.

> So I've demonstrated that from a "users" perspective a new 
> stable Linux would be of advantage. I'll now list what I 
> suggest for this new stable branch:
> 
> First, there are some fundamental ideas in the pipelines of 
> forthcoming releases which should be part of the next 
> "stable" Linux (Reiser4, the new scheduler from Mr. Molnár, 
> virtualisation...). So any next stable kernel branch should 
> include most of these recent developments, with the goal of 
> stabilising them. May-be a poll on [lkml] as to which 
> feature to include or not would help ?

Actually, the current architecture is flexible enough that adding these 
things in isn't all that hard.  We already have kvm merged, and the 
scheduler work is proceeding nicely.  Please don't start another Reiser4 
flamewar.

> Second, there was once a suggestion that 2.6 should be 3.0 
> since a lot of things changed:
> - modules called .ko and not .o
> - the output of the compile
> - ... (I don't remember)
> This was a brilliant suggestion and I whish another 
> consideration was given to that idea. You might even go a 
> step further and call kernel modules .kmod. Why on earth 
> call "kernel object" things that are "kernel modules" ? And 
> that every person calls "modules" and not "objects" ? I 
> know I know, in UNIX dynamic libraries are .so "shared 
> objects", so what ? A "module" is a "module" and NOT an 
> "object", call a cat a cat.

These are build trivialities.  This is hardly reason to change the 
development model.

> Third, while a stable ABI in a dynamically developed kernel 
> is a difficult/impossible/unwanted feature, it should be 
> possible to implement in a stable branch. This could even 
> be a distinction between "stable" and "development" 
> branches. And it would certainly help vendors of 
> closed-source drivers.

If I submit a patch to a RHEL kernel that breaks kABI, people knife me 
in the hallways, because I get paid to maintain it.

> Fourth, a finnish developper on this list suggested several 
> times that people should be allowed to try stupid things. 
> Well, I'm doing just that.

No, you're asking *us* to do stupid things.  If you want a more stable 
kABI in the upstream kernel, then start submitting patches that 
implement the hooks you need to do it.

> As a conclusion, please, please, consider splitting again 
> the kernel in 2 distinct branches, one labeled 
> "development" suiting your needs and another labeled 
> "stable" for us users.

It's already been done in a few different places.  2.4.x is still 
maintained.  2.6.16.y is still maintained.  Several vendors maintain 
stable kernels, some even kABI-stable, for many years after release. 
Since the vast majority of users are running distro kernels rather than 
upstream kernels, I think it's fair to say that anything post-2.6.16 
from kernel.org is a de facto development kernel, at least to users with 
extreme stability requirements like yourself.  Find yourself a distro 
that's the right balance of modern and stable, and use that kernel.  If 
there isn't a distro that's both modern enough and stable enough, then 
there are probably some very good economic reasons why this is the case.

	-- Chris

Re: Please release a stable kernel Linux 3.0

[Rafael J. Wysocki]

On Friday, 22 June 2007 19:11, Chuck Ebbert wrote:
> On 06/22/2007 11:00 AM, Rafael J. Wysocki wrote:
> > On Friday, 22 June 2007 00:34, Chuck Ebbert wrote:
> >> On 06/21/2007 06:29 PM, Jesper Juhl wrote:
> >>> I myself have argued that we should be focusing more on stability and
> >>> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
> >>> solve this. In general the 2.6.x.y -stable kernels seem to be doing
> >>> the job pretty good.
> >>>
> >>  
> >> Even the good ones that get lots of fixes aren't all that good. The
> >> biggest problem ATM is that suspend is badly broken and keeps getting
> >> worse...
> > 
> > Can you please provide me with any links to suspend-related bug reports from
> > you?
> > 
> 
> I get so many suspend/resume bug reports that I've given up trying
> to get them fixed. And there are so many bugs that are even worse,
> like crashes during normal use, data corruption, etc. that suspend
> bugs don't get much attention. But here are the ones for Fedora 6;
> the list would be much longer if I included Fedora 5 and 7:

Can you please tell me what's the relationship between Fedora kernel vesions
and the kernel.org kernels?

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Please release a stable kernel Linux 3.0

[Chuck Ebbert]

On 06/24/2007 04:54 PM, Rafael J. Wysocki wrote:
> On Friday, 22 June 2007 19:11, Chuck Ebbert wrote:
>> On 06/22/2007 11:00 AM, Rafael J. Wysocki wrote:
>>> On Friday, 22 June 2007 00:34, Chuck Ebbert wrote:
>>>> On 06/21/2007 06:29 PM, Jesper Juhl wrote:
>>>>> I myself have argued that we should be focusing more on stability and
>>>>> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
>>>>> solve this. In general the 2.6.x.y -stable kernels seem to be doing
>>>>> the job pretty good.
>>>>>
>>>>  
>>>> Even the good ones that get lots of fixes aren't all that good. The
>>>> biggest problem ATM is that suspend is badly broken and keeps getting
>>>> worse...
>>> Can you please provide me with any links to suspend-related bug reports from
>>> you?
>>>
>> I get so many suspend/resume bug reports that I've given up trying
>> to get them fixed. And there are so many bugs that are even worse,
>> like crashes during normal use, data corruption, etc. that suspend
>> bugs don't get much attention. But here are the ones for Fedora 6;
>> the list would be much longer if I included Fedora 5 and 7:
> 
> Can you please tell me what's the relationship between Fedora kernel vesions
> and the kernel.org kernels?
> 

Fedora kernels are as close to upstream as we can get them, but we do add Xen,
Roland's utrace and exec-shield. The list of applied patches may be a bit long
but most of them are bug fixes that we couldn't get into -stable for one reason
or another (some not upstream yet, some judged too big for -stable.)

Re: Please release a stable kernel Linux 3.0

[Rafael J. Wysocki]

On Monday, 25 June 2007 18:38, Chuck Ebbert wrote:
> On 06/24/2007 04:54 PM, Rafael J. Wysocki wrote:
> > On Friday, 22 June 2007 19:11, Chuck Ebbert wrote:
> >> On 06/22/2007 11:00 AM, Rafael J. Wysocki wrote:
> >>> On Friday, 22 June 2007 00:34, Chuck Ebbert wrote:
> >>>> On 06/21/2007 06:29 PM, Jesper Juhl wrote:
> >>>>> I myself have argued that we should be focusing more on stability and
> >>>>> regression fixing, but I'm not so sure that a 2.6.7 devel branch would
> >>>>> solve this. In general the 2.6.x.y -stable kernels seem to be doing
> >>>>> the job pretty good.
> >>>>>
> >>>>  
> >>>> Even the good ones that get lots of fixes aren't all that good. The
> >>>> biggest problem ATM is that suspend is badly broken and keeps getting
> >>>> worse...
> >>> Can you please provide me with any links to suspend-related bug reports from
> >>> you?
> >>>
> >> I get so many suspend/resume bug reports that I've given up trying
> >> to get them fixed. And there are so many bugs that are even worse,
> >> like crashes during normal use, data corruption, etc. that suspend
> >> bugs don't get much attention. But here are the ones for Fedora 6;
> >> the list would be much longer if I included Fedora 5 and 7:
> > 
> > Can you please tell me what's the relationship between Fedora kernel vesions
> > and the kernel.org kernels?
> > 
> 
> Fedora kernels are as close to upstream as we can get them, but we do add Xen,
> Roland's utrace and exec-shield. The list of applied patches may be a bit long
> but most of them are bug fixes that we couldn't get into -stable for one reason
> or another (some not upstream yet, some judged too big for -stable.)

OK, thanks.

Still, I know that, for example, the Fedora 2.6.21-1.3193.fc8 kernel is in fact
2.6.22-rc3 (see http://bugzilla.kernel.org/show_bug.cgi?id=7988#c11).  Is there
a straightforward way to 'decode' such names? ;-)

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Please release a stable kernel Linux 3.0

[Chuck Ebbert]

On 06/25/2007 07:20 PM, Rafael J. Wysocki wrote:
> Still, I know that, for example, the Fedora 2.6.21-1.3193.fc8 kernel is in fact
> 2.6.22-rc3 (see http://bugzilla.kernel.org/show_bug.cgi?id=7988#c11).  Is there
> a straightforward way to 'decode' such names? ;-)
> 

http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?annotate=HEAD&root=extras

Then scroll down to the changelog. :)

I started putting the CVS version in FC6 changelogs but that doesn't
have this kind of churn.

Re: Please release a stable kernel Linux 3.0

[Helge Hafting]

Zoltán HUBERT wrote:
> On Friday 22 June 2007 00:29, Jesper Juhl wrote:
>
>   
>>> You might think it's easy for me to simply "use" Linux
>>> and complain while you're doing the hard stuff. As it
>>> happens, the current development/stable model makes our
>>> life as "users" more and more difficult.
>>>       
>> In what way?
>>     
>
> Well, I'm using SuSE Pro 9.3 (excellent choice by the way), 
> coming with kernel 2.6.10-SuSE, on a ATI laptop, and the 
> drivers privided wouldn't compile (suspend & freinds). The 
> SATA disks were only supported from 2.6.15 (which just came 
> out), so I had to edit the "source code" of a closed source 
> driver to make it all work well. If that's "easy" for you I 
> doubt it is for 99.999% of earth's population. "World 
> domination" is far away.
>
> Also, the 7 National Instruments cards I'm using for a 
> deformable mirror in Adaptive Optics in an industrial PC 
> are "certified" for SuSE 9.3 only. Which, this week, got 
> discontinued. So what now ?
>   
You either stick with SuSE 9.3 forever, or you
*try* something newer to see if it works,
or you pay the manufacturer to certify something newer.

This problem isn't linux specific - hardware vendors tend
to support software that is current at time of sale, then
the world moves on without them.  This happens
for all operating systems.

>   
>> I don't think you'll find very 
>> many people on this list who gives a damn about the
>> troubles of closed source driver developers.
>>     
>
> and what about their users ?
>   
Users of closed-source drivers get their support from
the closed-source vendor - not from the kernel developers.
It is that simple.
Again - this is how all operating systems works.
If you have closed windows 3.1 drivers, then microsoft do
*not* make sure they work with vista either - unless
the device is extremely mainstream.  For all other devices,
the device manufacturer have to provide updated drivers.

If your vendor don't want to support you anymore, try getting
the source. 

Helge Hafting

Re: Please release a stable kernel Linux 3.0

[Zoltán HUBERT]

On Tuesday 26 June 2007 13:59, Helge Hafting wrote:
> Zoltán HUBERT wrote:
> > Well, I'm using SuSE Pro 9.3 (excellent choice by the
> > way), coming with kernel 2.6.10-SuSE
> You either stick with SuSE 9.3 forever, or you
> *try* something newer to see if it works,

I did. It (2.6.15) didn't. Between 2.6.10 and 2.6.15 the 
suspend API changed. It was documented that it would change 
and break things and so it did. Is that what "stable" is 
about ?

> >> I don't think you'll find very
> >> many people on this list who gives a damn about the
> >> troubles of closed source driver developers.
> >
> > and what about their users ?
>
> Users of closed-source drivers get their support from
> the closed-source vendor - not from the kernel
> developers. It is that simple.

Translated: "It's not my fault"

> Again - this is how all operating systems works.

kernel 2.0/2.1 ?
Debian stable/testing/unstable ? 
FreeBSD 5.5/FreeBSD 6.2 ?

> If your vendor don't want to support you anymore, try
> getting the source.

I was asking for a stable kernel, like 2.4, 2.2, 2.0 were 
before. 2.6 is not. It's a great kernel, better than that 
of MacOS X, I never said you were doing a bad job, quite 
the contrary. I wouldn't be using Linux since 10 years if I 
thought it stinks. I never asked support for closed source 
drivers, only a stable kernel. 

Whatever "stable" means.


z


-- 
 
________________________

Zoltan
________________________

 

Re: Please release a stable kernel Linux 3.0

[Renato S. Yamane]

Zoltán HUBERT escreveu:
> On Tuesday 26 June 2007 13:59, Helge Hafting wrote:
>> If your vendor don't want to support you anymore, try
>> getting the source.
> 
> I was asking for a stable kernel, like 2.4, 2.2, 2.0 were 
> before. 2.6 is not. It's a great kernel, better than that 
> of MacOS X, I never said you were doing a bad job, quite 
> the contrary. I wouldn't be using Linux since 10 years if I 
> thought it stinks. I never asked support for closed source 
> drivers, only a stable kernel. 
> 
> Whatever "stable" means.

I think that Hafting try says: "last stable kernel", like 2.6.21.5
Are you try use this version?

Regards,
Renato

Re: Please release a stable kernel Linux 3.0

[Roland Kuhn]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

Hi Zoltan!

On 26 Jun 2007, at 16:37, Zoltán HUBERT wrote:

>> If your vendor don't want to support you anymore, try
>> getting the source.
>
> I was asking for a stable kernel, like 2.4, 2.2, 2.0 were
> before. 2.6 is not. It's a great kernel, better than that
> of MacOS X, I never said you were doing a bad job, quite
> the contrary. I wouldn't be using Linux since 10 years if I
> thought it stinks. I never asked support for closed source
> drivers, only a stable kernel.
>
> Whatever "stable" means.
>
What you mean by "stable" pretty much excludes any serious  
development, without which the Linux kernel would very soon be  
obsolete. If you want a stable system, then don't change it. If you  
update to a kernel which is 2.5 years newer, you simply cannot have  
stability, because that would mean stagnation, aka "death".

Ciao,
                     Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
--
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
--
Any society that would give up a little liberty to gain a little
security will deserve neither and lose both.  - Benjamin Franklin
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M 
+ !V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: Please release a stable kernel Linux 3.0

[Zoltán HUBERT]

Thanks Roland,

On Tuesday 26 June 2007 21:03, Roland Kuhn wrote:
> On 26 Jun 2007, at 16:37, Zoltán HUBERT wrote:
> > Whatever "stable" means.
>
> What you mean by "stable" pretty much excludes any
> serious development, without which the Linux kernel would
> very soon be obsolete. If you want a stable system, then
> don't change it. 

This is a problem. Do you remember that kernel vulnerability 
in 2.4 that made the Debian servers be attacked ? And 
mplayerhq.hu too if I remember right ? So what are we 
supposed to do with a perfect and optimised system, running 
smoothly, with an older kernel where some nasty bug is 
discovered ?

In MacOS X, you click "System Update" and you're done. 

In Linux, I expect "download the newest stable kernel, 
configure, compile, install, reboot". 

If I have to rely on the distribution to help me it spoils 
the whole benefit of open source. I don't trust Novell or 
RedHat or Google more than Microsoft or Apple. You "kernel 
developpers" are the keepers of the flame.

> If you update to a kernel which is 2.5 
> years newer, you simply cannot have stability, because
> that would mean stagnation, aka "death".

PostScript is a very old language yet we all still use it 
every day. HTML is a very old "thing" and we use it 
every-day, and it's still compatible with newer and older 
stuff.

I'm a system engineer, and a "stable" system is one where 
the interfaces are stable. Individual components can 
change, and do change, but if you change fundamental 
interfaces it is not the same system. Of course I 
understand that "sometimes" fundamental things have to 
change, but here "sometimes" is the keyword. If its 
"anytime" it simply is no stable system. And yes, designing 
and maintaining interfaces is a very difficult job.

I don't remember how it was during 2.4 and before, but I 
find it very suspicious that SuSE and RedHat only provide 
2.6.10 and 2.6.9 for their OS. It looks as if THEY didn't 
trust 2.6.x to be a replacement to 2.6.y

And as I understand it, this is (was ?) the whole point of 
stable/development kernels. "We" can trust a newer stable 
kernel to be a drop-in replacement for an older stable 
kernel (from the same series), while development kernels 
need time to stabilise with the new whizz-bang-pfouit stuff 
that you all so nicely add. 

Are the good ol' days lost in nostalgia ?

bye

Zoltán




-- 
 
________________________

Zoltan
________________________

 

Re: Please release a stable kernel Linux 3.0

[Alan McKinnon]

On Wednesday 27 June 2007, Zoltán HUBERT wrote:

> If I have to rely on the distribution to help me it spoils
> the whole benefit of open source. I don't trust Novell or
> RedHat or Google more than Microsoft or Apple. You "kernel
> developpers" are the keepers of the flame.

You seem to misunderstand kernel development. You also seem to expect a 
lot from something that is gifted to you gratis.

These nice people at kernel.org have never claimed that they will 
support older kernel versions. What they have said is that the -stable 
team currently publish 2.6.20 and 2.6.21 while Adrian Bunk is doing his 
thing with 2.6.16. As for back-porting new stuff into old kernels, 
that's the distro's job. If you don't trust the distro, then get one 
you do trust. If you trust none of them, then can I suggest you use the 
one resource you *can* trust - yourself?

*That* is the "whole benefit of open source" - you get to do it yourself 
if you choose to/need to

[snip]

> I don't remember how it was during 2.4 and before, but I
> find it very suspicious that SuSE and RedHat only provide
> 2.6.10 and 2.6.9 for their OS. It looks as if THEY didn't
> trust 2.6.x to be a replacement to 2.6.y

No, it means they chose 2.6.whatever for a specific version of their OS 
and they maintain that kernel series to fit that OS.

They also do not take any arb new glibc version and stick that into the 
OS either, because that breaks stuff. But I don't see you complaining 
about that.

> And as I understand it, this is (was ?) the whole point of
> stable/development kernels. "We" can trust a newer stable
> kernel to be a drop-in replacement for an older stable
> kernel (from the same series), while development kernels
> need time to stabilise with the new whizz-bang-pfouit stuff
> that you all so nicely add.

That might have been the case in the 2.4 era, but it's not the case now. 
It changed early on in the 2.6 series and it was changed for very sound 
engineering reasons. Put simply - a stable/dev scenario just didn't 
work and there was way tooo much work for way too little gain.

Distros themselves are the best resource to supply stable kernels, 
because they have been doing that anyway for a long time now.


alan


-- 
Optimists say the glass is half full,
Pessimists say the glass is half empty,
Developers say wtf is the glass twice as big as it needs to be?

Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five

Re: Please release a stable kernel Linux 3.0

[Al Viro]

On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> I'm a system engineer, and a "stable" system is one where 
> the interfaces are stable. Individual components can 
> change, and do change, but if you change fundamental 
> interfaces it is not the same system. Of course I 
> understand that "sometimes" fundamental things have to 
> change, but here "sometimes" is the keyword. If its 
> "anytime" it simply is no stable system. And yes, designing 
> and maintaining interfaces is a very difficult job.

What makes you think that module interfaces _exist_?  Over the years
we'd got a pile of exports.  Maybe 5-10% of it could form several
more or less sane interfaces.  And that's being very optimistic.
But try to get those interfaces and guess who'll scream bloody
murder?  That's right, the 3rd-party module developers.  The same
people who presumably want stability.  Because all that dreck had
been exported on someone's requests.
 
> I don't remember how it was during 2.4 and before, but I 
> find it very suspicious that SuSE and RedHat only provide 
> 2.6.10 and 2.6.9 for their OS. It looks as if THEY didn't 
> trust 2.6.x to be a replacement to 2.6.y

Eh?  Funny, but in the next xterm I've got an ssh session to RHEL-5
box.  2.6.18+many backported patches...  FC is simply following
mainline, but that's a separate story...

> And as I understand it, this is (was ?) the whole point of 
> stable/development kernels. "We" can trust a newer stable 
> kernel to be a drop-in replacement for an older stable 
> kernel (from the same series), while development kernels 
> need time to stabilise with the new whizz-bang-pfouit stuff 
> that you all so nicely add. 

"Drop-in" in which sense?  That out-of-tree modules keep working?
Not really...

Re: Please release a stable kernel Linux 3.0

[Helge Hafting]

Zoltán HUBERT wrote:
> Thanks Roland,
>
> On Tuesday 26 June 2007 21:03, Roland Kuhn wrote:
>   
>> On 26 Jun 2007, at 16:37, Zoltán HUBERT wrote:
>>     
>>> Whatever "stable" means.
>>>       
>> What you mean by "stable" pretty much excludes any
>> serious development, without which the Linux kernel would
>> very soon be obsolete. If you want a stable system, then
>> don't change it. 
>>     
>
> This is a problem. Do you remember that kernel vulnerability 
> in 2.4 that made the Debian servers be attacked ? And 
> mplayerhq.hu too if I remember right ? So what are we 
> supposed to do with a perfect and optimised system, running 
> smoothly, with an older kernel where some nasty bug is 
> discovered ?
>
> In MacOS X, you click "System Update" and you're done. 
>
> In Linux, I expect "download the newest stable kernel, 
> configure, compile, install, reboot". 
>   
Correct.

Just be aware of this:
If you use a binary-only driver, then you have an unsupported
configuration.  Unsupported by the kernel community at least.
So no support, and if it breaks - you keep the pieces.

You bring up MacOS X.  The same problem exists there.
If a third party makes a strange closed driver that do all
sorts of things apple says a driver shouldn't, then this
driver may very well break on the next "System Update".

Now, perhaps there aren't any such strange drivers for MacOS X,
perhaps all vendors figured out that it is smarter to
cooperate with apple and follow their rules when making
drivers.

Similiar guidelines and rules exist for linux driver development.
And one of the important rules is: post the driver to the kernel
list. Clean it up and maintain it until it gets merged. Then it
is a supported driver, and some care will be taken not to break it.

But some vendors just have to go and make an unsupportable
driver instead - all closed-source drivers fall into this category.
So those drivers are unsupported.
The kernel community advice against using them (they could
make your linux kernel unstable, and nobody but the
vendor can then help.)
If such a driver breaks on a kernel upgrade then
sure - "it is not our problem".  Just as it isn't apple's
problem if a unsupported mac osx driver breaks, just
as it isn't microsoft's problem if a third party driver breaks
because it was made against all guidelines.

Microsoft offer driver certification for vendors that want to
avoid this kind of problems. Linux has a similiar arrangement.
The "certification" equivalent is to get the driver merged
into the kernel source. Open source is but one requirement
for this to happen. Code quality is another.
> If I have to rely on the distribution to help me it spoils 
> the whole benefit of open source. I don't trust Novell or 
> RedHat or Google more than Microsoft or Apple. You "kernel 
> developpers" are the keepers of the flame.
>   
>> If you update to a kernel which is 2.5 
>> years newer, you simply cannot have stability, because
>> that would mean stagnation, aka "death".
>>     
>
> PostScript is a very old language yet we all still use it 
> every day. HTML is a very old "thing" and we use it 
> every-day, and it's still compatible with newer and older 
> stuff.
>
> I'm a system engineer, and a "stable" system is one where 
> the interfaces are stable. Individual components can 
> change, and do change, but if you change fundamental 
> interfaces it is not the same system. Of course I 
> understand that "sometimes" fundamental things have to 
> change, but here "sometimes" is the keyword. If its 
> "anytime" it simply is no stable system. And yes, designing 
> and maintaining interfaces is a very difficult job.
>   
Linux is stable then. The kernel component offer an unchanging
interface to userspace components. Strictly, the kernel
interface is expanded all the time, but old stuff keep working.

As you said - individual components may change. The kernel
is one such individual component, and it changes a lot.
The kernel offer *no* internal interfaces. A driver written
assuming a particular kernel-internal interface is broken
and unsupported *by design*. The vendor can still choose
to support such a driver, typically with a new version for
each kernel version. Nvidia seems to go that route with
their unsupported driver.  Your vendor instead selected to
leave you stranded. That is entirely the vendors fault,
that driver was never supported by the kernel community.
> I don't remember how it was during 2.4 and before, but I 
> find it very suspicious that SuSE and RedHat only provide 
> 2.6.10 and 2.6.9 for their OS. It looks as if THEY didn't 
> trust 2.6.x to be a replacement to 2.6.y
>
> And as I understand it, this is (was ?) the whole point of 
> stable/development kernels. "We" can trust a newer stable 
> kernel to be a drop-in replacement for an older stable 
> kernel (from the same series), while development kernels 
> need time to stabilise with the new whizz-bang-pfouit stuff 
> that you all so nicely add. 
>
> Are the good ol' days lost in nostalgia ?
>   
Upgrading 2.6.x kernels is supposed to work fine,
but you must upgrade the whole kernel then.  This includes
all driver modules. An older module may not work,
or it may even hang the kernel immediately. You can't
generally put together pieces of different kernels - the kernel
is one piece.  (Other pieces of a linux system is the
various packages your distribution vendor ships . . .)

Helge Hafting

Re: Please release a stable kernel Linux 3.0

[Chuck Ebbert]

On 06/27/2007 05:18 AM, Zoltán HUBERT wrote:
> If I have to rely on the distribution to help me it spoils 
> the whole benefit of open source. I don't trust Novell or 
> RedHat or Google more than Microsoft or Apple.

Hey, we're doing the best we can with Fedora and our source
tree is completely open. What don't you trust?

Re: Please release a stable kernel Linux 3.0

[Pavel Machek]

Hi!

> > >> Even the good ones that get lots of fixes aren't all that good. The
> > >> biggest problem ATM is that suspend is badly broken and keeps getting
> > >> worse...
> > > 
> > > I wasn't under the impression suspend had really ever worked.  Such a
> > > messy problem to solve.
> > > 
> > 
> > It never worked reliably for everyone, but with each new release it
> > seems to get worse.
> 
> the thing is just fundamentally not designed right. Declaring it stable
> ain't gonna fix that. Having someone do a right design (which will
> obviously will go through some breakage period, even if it's an
> evolution of the current design) is a required step of getting s/r more
> reliable... but the current one doesn't get stable just by declaring it
> so.

Ok, I guess one more pair of eyes would help.


> > >> Even the good ones that get lots of fixes aren't all that good. The
> > >> biggest problem ATM is that suspend is badly broken and keeps getting
> > >> worse...
> > > 
> > > Can you please provide me with any links to suspend-related bug reports from
> > > you?
> > 
> > I get so many suspend/resume bug reports that I've given up trying
> > to get them fixed. And there are so many bugs that are even worse,
> > like crashes during normal use, data corruption, etc. that suspend
> > bugs don't get much attention. But here are the ones for Fedora 6;
> > the list would be much longer if I included Fedora 5 and 7:

(list of 20 bugs in redhat bugzilla).

...well, it looks a bit better from my side. Number of suspend bugs in
suse bugzilla is certainly lower, and I guess it works a bit better,
too. (But we do not claim s2ram support for machines outside of s2ram
whitelist).

Now, perhaps redhat should get someone to work on suspend/hibernation
support (kernel level)? IIRC you had Nigel at one point, but he was
working on something else?

Rafael and me am trying to look after hibernation, but I believe noone
is really working on suspend :-(.
						Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Please release a stable kernel Linux 3.0

[Rafael J. Wysocki]

On Thursday, 28 June 2007 23:15, Pavel Machek wrote:
> Hi!
> 
> > > >> Even the good ones that get lots of fixes aren't all that good. The
> > > >> biggest problem ATM is that suspend is badly broken and keeps getting
> > > >> worse...
> > > > 
> > > > I wasn't under the impression suspend had really ever worked.  Such a
> > > > messy problem to solve.
> > > > 
> > > 
> > > It never worked reliably for everyone, but with each new release it
> > > seems to get worse.
> > 
> > the thing is just fundamentally not designed right. Declaring it stable
> > ain't gonna fix that. Having someone do a right design (which will
> > obviously will go through some breakage period, even if it's an
> > evolution of the current design) is a required step of getting s/r more
> > reliable... but the current one doesn't get stable just by declaring it
> > so.
> 
> Ok, I guess one more pair of eyes would help.
> 
> 
> > > >> Even the good ones that get lots of fixes aren't all that good. The
> > > >> biggest problem ATM is that suspend is badly broken and keeps getting
> > > >> worse...
> > > > 
> > > > Can you please provide me with any links to suspend-related bug reports from
> > > > you?
> > > 
> > > I get so many suspend/resume bug reports that I've given up trying
> > > to get them fixed. And there are so many bugs that are even worse,
> > > like crashes during normal use, data corruption, etc. that suspend
> > > bugs don't get much attention. But here are the ones for Fedora 6;
> > > the list would be much longer if I included Fedora 5 and 7:
> 
> (list of 20 bugs in redhat bugzilla).
> 
> ...well, it looks a bit better from my side. Number of suspend bugs in
> suse bugzilla is certainly lower, and I guess it works a bit better,
> too. (But we do not claim s2ram support for machines outside of s2ram
> whitelist).
> 
> Now, perhaps redhat should get someone to work on suspend/hibernation
> support (kernel level)? IIRC you had Nigel at one point, but he was
> working on something else?
> 
> Rafael and me am trying to look after hibernation, but I believe noone
> is really working on suspend :-(.

I've been trying to for some time, but I still need to learn more.  Also, the
issues in there are difficult to debug.

Right now I'm collecting information and trying to help where I know what to
do. :-)

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Please release a stable kernel Linux 3.0

[Gerhard Mack]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1969 bytes --]

On Wed, 27 Jun 2007, Zoltán HUBERT wrote:

> I don't remember how it was during 2.4 and before, but I 
> find it very suspicious that SuSE and RedHat only provide 
> 2.6.10 and 2.6.9 for their OS. It looks as if THEY didn't 
> trust 2.6.x to be a replacement to 2.6.y
> 
> And as I understand it, this is (was ?) the whole point of 
> stable/development kernels. "We" can trust a newer stable 
> kernel to be a drop-in replacement for an older stable 
> kernel (from the same series), while development kernels 
> need time to stabilize with the new whizz-bang-pfouit stuff 
> that you all so nicely add. 
> 
> Are the good ol' days lost in nostalgia ?

Lost? maybe.  Improved on, defiantly so it's loss isn't a bad thing.

The 2.4/2.5 split was, as far as I recall, a mess.  2.5 had too many 
changes to stabilize in any reasonable amount of time and 2.4 then needed 
new drivers and features to keep it from becoming obsolete.  Back porting 
drivers without the needed infrastructure resulted in instabilities in 
the 2.4 branch.

I recall one time where I needed a certain raid device working and not a 
single kernel had that driver working properly.  2.4.x oopsed in the 
driver after random intervals and the 2.5 kernel crashed in other places.

Now development is broken into smaller stages that are easier to debug and 
made stable in shorter time.  If I just need to update a kernel and don't 
need any new features and drivers I can just update to the next point 
release and I know it won't break anything.  If I want new features I can 
update to the latest stable branch or the latest pre release but either 
way my stuff is more likely to work than I did back in the 2.5 days.

I think people who keep demanding a return to the old development system 
forget how badly it sucked in the first place.

	Gerhard



--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Please release a stable kernel Linux 3.0

[Pavel Machek]

Hi!

> > Now, perhaps redhat should get someone to work on suspend/hibernation
> > support (kernel level)? IIRC you had Nigel at one point, but he was
> > working on something else?
> > 
> > Rafael and me am trying to look after hibernation, but I believe noone
> > is really working on suspend :-(.
> 
> I've been trying to for some time, but I still need to learn more.  Also, the
> issues in there are difficult to debug.
> 
> Right now I'm collecting information and trying to help where I know what to
> do. :-)

Thanks for your work!

I'm basically trying to do that, too, but dedicated person working at
suspend would still be nice.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Please release a stable kernel Linux 3.0

[Rene Herman]

On 06/30/2007 04:11 AM, Daniel Hazelton wrote:

> On Friday 29 June 2007 17:27:34 Rene Herman wrote:

>> Arguably (no doubt, sigh...) someone could distribute the kernel in
>> binary form but refuse to provide source for the bits marked as being
>> in the public domain alongside it -- yes, can of worms when compared to
>> GPL demands, but I believe I can see why one shouldn't even go near
>> there.
> 
> Actually, they couldn't. Second PD code became included in the kernel it
> would be covered by the GPL. If it can be shown that the kernel binary
> was the product of merging PD code in, then there is no way top refuse
> access to the PD code.

If indeed. If the PD code compiles to a standalone module then this becomes 
every bit as arguable as binary modules. That's the "(no doubt, sigh)" bit.

Rene.

Re: Please release a stable kernel Linux 3.0

[Daniel Hazelton]

On Friday 29 June 2007 17:27:34 Rene Herman wrote:
> On 06/29/2007 11:05 PM, Bodo Eggert wrote:
> > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> Indeed if its public domain you may have almost no rights at all
> >> depending what you were given. Once you get the source code you can do
> >> stuff but I don't have to give you that. If its public domain I can find
> >> security holes in it, and refuse to provide the fixed module in source
> >> form even.
> >
> > The GPL forces nobody to not release his module under PD, therefore it
> > can't protect you from that. Even minor changes - like adjusting the
> > module to use to the current API - won't change that, at least in Germany
> > they'd have to qualify as a work of their own in order to create a
> > GPL-only derived work, because anything not qualifying for that could
> > also be integrated into the PD version, and both would remain identical.
>
> What I focussed on when asking were only my wishes as an author but Alan
> (if I understood him right ofcourse) pointed out that _the kernel_ does not
> want integrated code to be in the public domain regardless of my wishes.
>
> Arguably (no doubt, sigh...) someone could distribute the kernel in binary
> form but refuse to provide source for the bits marked as being in the
> public domain alongside it -- yes, can of worms when compared to GPL
> demands, but I believe I can see why one shouldn't even go near there.

Actually, they couldn't. Second PD code became included in the kernel it would 
be covered by the GPL. If it can be shown that the kernel binary was the 
product of merging PD code in, then there is no way top refuse access to the 
PD code.

DRH

> Rene.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.

Re: Please release a stable kernel Linux 3.0

[Rene Herman]

On 06/29/2007 11:05 PM, Bodo Eggert wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>> Indeed if its public domain you may have almost no rights at all
>> depending what you were given. Once you get the source code you can do
>> stuff but I don't have to give you that. If its public domain I can find
>> security holes in it, and refuse to provide the fixed module in source
>> form even.
> 
> The GPL forces nobody to not release his module under PD, therefore it can't
> protect you from that. Even minor changes - like adjusting the module to use
> to the current API - won't change that, at least in Germany they'd have to
> qualify as a work of their own in order to create a GPL-only derived work,
> because anything not qualifying for that could also be integrated into the
> PD version, and both would remain identical.

What I focussed on when asking were only my wishes as an author but Alan (if 
I understood him right ofcourse) pointed out that _the kernel_ does not want 
integrated code to be in the public domain regardless of my wishes.

Arguably (no doubt, sigh...) someone could distribute the kernel in binary 
form but refuse to provide source for the bits marked as being in the public 
domain alongside it -- yes, can of worms when compared to GPL demands, but I 
believe I can see why one shouldn't even go near there.

Rene.

Re: Please release a stable kernel Linux 3.0

[Bodo Eggert]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Fri, 29 Jun 2007 00:00:27 +0200
> Rene Herman <rene.herman@gmail.com> wrote:
>> On 06/28/2007 06:30 PM, Alan Cox wrote:

>> > Public domain is GPL compatible.
>> 
>> Would you happen to have an opinion on the attached? I don't so much need it
> 
> The answer is "NO!!!!"
> 
> Public domain also means "I don't have to give you the source".
> If its merged with the kernel the resulting work is GPL anyway
> 
>> Stating that code which one intends to be in the public domain has "GPL and
>> additional rights" is a bit of a travesty though.
> 
> Indeed if its public domain you may have almost no rights at all
> depending what you were given. Once you get the source code you can do
> stuff but I don't have to give you that. If its public domain I can find
> security holes in it, and refuse to provide the fixed module in source
> form even.

The GPL forces nobody to not release his module under PD, therefore it can't
protect you from that. Even minor changes - like adjusting the module to use
to the current API - won't change that, at least in Germany they'd have to
qualify as a work of their own in order to create a GPL-only derived work,
because anything not qualifying for that could also be integrated into the
PD version, and both would remain identical.
-- 
"Cluster bombing from B-52s is very, very accurate. The bombs are
guaranteed to always hit the ground."
-U.S.A.F. Ammo Troop
Friß, Spammer: 8wfPvrtu@j0o.7eggert.dyndns.org r@2ypKo.7eggert.dyndns.org

Re: Please release a stable kernel Linux 3.0

[Alan Cox]

> Thanks for the thoughtful reply.  _And_ for taking the time to look at
> the code.
> 
> I guess my half-assed notion is to have a single file w/"#ifdef-able"
> entries that flag API changes.  It at least would give me/us a single
> point of reference, and avoid the rather ugly version checking.  "LDDx"
> is fine, and lwn.net has saved my ass more times than I can count, but a
> single peg on which to hang my out-of-tree hat would seem useful.

Or you could hang your hat in tree ?

Alan

Re: Please release a stable kernel Linux 3.0

[Alan Cox]

On Fri, 29 Jun 2007 00:00:27 +0200
Rene Herman <rene.herman@gmail.com> wrote:

> On 06/28/2007 06:30 PM, Alan Cox wrote:
> 
> > Public domain is GPL compatible.
> 
> Would you happen to have an opinion on the attached? I don't so much need it 

The answer is "NO!!!!"

Public domain also means "I don't have to give you the source".
If its merged with the kernel the resulting work is GPL anyway

> Stating that code which one intends to be in the public domain has "GPL and 
> additional rights" is a bit of a travesty though.

Indeed if its public domain you may have almost no rights at all
depending what you were given. Once you get the source code you can do
stuff but I don't have to give you that. If its public domain I can find
security holes in it, and refuse to provide the fixed module in source
form even.

(And public domain is a pretty 'brave' choice of licence as in many
countries it does not imply any of the no warranty stuf the GPL does).

So essentially, if its public domain and you put a copy in the kernel GPL
the kernel copy. It doesn't mean the PD version ceased to be PD. If you
want to keep it PD then also ask that anyone contributing to the GPL
version also sends you a PD version of any changes. (They may not but
then right now they dont have to anyway)

Alan

Re: Please release a stable kernel Linux 3.0

[Rene Herman]

On 06/29/2007 12:48 AM, Alan Cox wrote:

> On Fri, 29 Jun 2007 00:00:27 +0200
> Rene Herman <rene.herman@gmail.com> wrote:
> 
>> On 06/28/2007 06:30 PM, Alan Cox wrote:
>>
>>> Public domain is GPL compatible.
>> Would you happen to have an opinion on the attached? I don't so much need it 
> 
> The answer is "NO!!!!"
> 
> Public domain also means "I don't have to give you the source".
> If its merged with the kernel the resulting work is GPL anyway
> 
>> Stating that code which one intends to be in the public domain has "GPL and 
>> additional rights" is a bit of a travesty though.
> 
> Indeed if its public domain you may have almost no rights at all
> depending what you were given. Once you get the source code you can do
> stuff but I don't have to give you that. If its public domain I can find
> security holes in it, and refuse to provide the fixed module in source
> form even.
> 
> (And public domain is a pretty 'brave' choice of licence as in many
> countries it does not imply any of the no warranty stuf the GPL does).
> 
> So essentially, if its public domain and you put a copy in the kernel GPL
> the kernel copy. It doesn't mean the PD version ceased to be PD. If you
> want to keep it PD then also ask that anyone contributing to the GPL
> version also sends you a PD version of any changes. (They may not but
> then right now they dont have to anyway)

Great answer. Thanks very much for the information.

Rene.

Re: Please release a stable kernel Linux 3.0

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On 06/28/2007 06:30 PM, Alan Cox wrote:

> Public domain is GPL compatible.

Would you happen to have an opinion on the attached? I don't so much need it 
or anything but I thought about submitting this once when I was working on 
some stuff locally. I didn't since I was expecting arguments that public 
domain is not so much a license, and how it becomes GPL anyway, ...

Stating that code which one intends to be in the public domain has "GPL and 
additional rights" is a bit of a travesty though.

Signed-off-by: Rene Herman <rene.herman@gmail.com>

Rene.

[-- Attachment #2: public_domain.diff --]
[-- Type: text/plain, Size: 940 bytes --]

diff --git a/include/linux/license.h b/include/linux/license.h
index decdbf4..1176471 100644
--- a/include/linux/license.h
+++ b/include/linux/license.h
@@ -8,7 +8,8 @@ static inline int license_is_gpl_compatible(const char *license)
 		|| strcmp(license, "GPL and additional rights") == 0
 		|| strcmp(license, "Dual BSD/GPL") == 0
 		|| strcmp(license, "Dual MIT/GPL") == 0
-		|| strcmp(license, "Dual MPL/GPL") == 0);
+		|| strcmp(license, "Dual MPL/GPL") == 0
+		|| strcmp(license, "Public Domain") == 0);
 }
 
 #endif
diff --git a/include/linux/module.h b/include/linux/module.h
index e6e0f86..2ecacf8 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -107,6 +107,7 @@ extern struct module __this_module;
  *					 or MIT license choice]
  *	"Dual MPL/GPL"			[GNU Public License v2
  *					 or Mozilla license choice]
+ *	"Public Domain"			[Public domain products]
  *
  * The following other idents are available
  *

Re: Please release a stable kernel Linux 3.0

[Al Viro]

On Thu, Jun 28, 2007 at 05:30:51PM +0100, Alan Cox wrote:
 
> > My (mild) beef is more like what I take to be Al's point: it feels like
> > there is a kind of hostility toward out-of-tree maintainers.  Why not
> 
> Some of that comes about because a lot of them are out of tree
> maintaining non-free stuff, shipping binary products - often entirely
> binary without a Linux or GPL label - until the man in black catches them
> and sues them in Germany.
 
Some, but not all, and you know damn well where the rest is coming
from (kABI is a four-letter word and anything that smells like
a slippery slope towards that in mainline kernel is not a good
idea, to put it very mildly).

It's really very simple:
	(1) There are too many exports
	(2) "should not break any code that uses only exported symbols" is
a very strong constraint.  Too strong to be feasible.
	(3) That constraint has become too strong because module authors
kept adding exports.
	(4) Unless the number of exports is trimmed by at least 1--1.5
orders of magnitude, forget about any such promises.
	(5) Trimming it down is unacceptable for module authors - the same
people who'd created that coprostalagmite in the first place and who keep
asking for such promises.

What can one do?  Well, get the code merged or maintain it on your own.
If the subset of exports you are using is relatively sane, the latter
option will cause you relatively little PITA.  If it's not, well, at least it
doesn't become a pain in our arses...

Re: Please release a stable kernel Linux 3.0

[William D Waddington]

Alan Cox wrote:

[snip]

>> A cleaned-up, consistent, and out-of-tree friendly way of handling API
>> changes might help us all.
> 
> The problem is that its very impractical. If I change a kernel API I fix
> up the in tree users and test those I can, that's "accepted practice" -
> you make mess doing a job you clean it up. I can't do that for out of
> tree code because its out of tree.

Thanks for the thoughtful reply.  _And_ for taking the time to look at
the code.

I guess my half-assed notion is to have a single file w/"#ifdef-able"
entries that flag API changes.  It at least would give me/us a single
point of reference, and avoid the rather ugly version checking.  "LDDx"
is fine, and lwn.net has saved my ass more times than I can count, but a
single peg on which to hang my out-of-tree hat would seem useful.

Thanks again,
Bill
-- 
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

Re: Please release a stable kernel Linux 3.0

[Alan Cox]

> Fair enough:
> http://www.tahomatech.com/downloads/drivers/linux_2.6/pci/x86/compressed_tarfiles/
> or for your browsing pleasure:
> http://www.tahomatech.com/downloads/drivers/linux_2.6/pci/x86/files/
> 
> But I really don't see much hope :(  Coding style, masses of ioctls,
> build and install technique,  limited user base, etc, etc, etc...  Most
> of the above to keep API compatibility with other OS/older drivers -
> back to SunOS 4.1.3.  (BTW, it does seem to work...)

Its small, its relatively sanely structured and its not that bad
stylewise. Nothing a few seds, an indent and a polish wouldn't cure. As
to the ioctls - its a specialised driver for specialised purposes so the
ioctls are not IMHO an issue beyond worrying about compat_ and if you
want compat_ interfaces for them or not.

> And I probably have the license wrong.  The code has always been in
> the public domain.  (Advice welcome...)

Public domain is GPL compatible. 

> My (mild) beef is more like what I take to be Al's point: it feels like
> there is a kind of hostility toward out-of-tree maintainers.  Why not

Some of that comes about because a lot of them are out of tree
maintaining non-free stuff, shipping binary products - often entirely
binary without a Linux or GPL label - until the man in black catches them
and sues them in Germany.

> encourage _all_ of us who are beavering away at open-source code?  My
> stuff doesn't belong in mainline, but it _is_ open, and in some minor
> way allows more folks to run Linux.

Quite honestly your stuff is *less* obscure than some of the hardware we
have in-tree drivers for, and rather cleaner.

> A cleaned-up, consistent, and out-of-tree friendly way of handling API
> changes might help us all.

The problem is that its very impractical. If I change a kernel API I fix
up the in tree users and test those I can, that's "accepted practice" -
you make mess doing a job you clean it up. I can't do that for out of
tree code because its out of tree.

Re: Please release a stable kernel Linux 3.0

[Al Boldi]

Al Viro wrote:
> On Thu, Jun 28, 2007 at 01:32:23AM +0300, Al Boldi wrote:
> > > > You are effectively inhibiting the development of an out-of-tree GPL
> > > > module pool, by constantly pulling the rug under that community.
> > >
> > > The same thing happens with any yet-to-be-merged code.
> > >
> > > > Do you think this is fair?
> > >
> > > Yes, it is fair.  Decision to maintain your code out of tree
> > > indefinitely is your decision.
> >
> > It's not my decision, it's the kernel maintainers decision to reject
> > inclusion for one reason or another.  One reason could be a simple "we
> > don't think this is useful".
>
> "I maintain a patch to $PROGRAM; maintainers of $PROGRAM don't think it's
> useful; they should abstain from making changes that might require rewrite
> of that patch".  Would you argue that this is fair?

No, that's not fair.  But, what's fair is to ask maintainers of $PROGRAM to 
be so kind and expose a stable API via some layer, which can be used to 
connect external patches which are considered not useful, in the hope that 
some day it may grow into something useful.

> BTW, "if it's GPLed, it's entitled to any internal function" is a shell
> game; it tries to convert GPL-given right to get to those functions into
> some kind of promise that those functions won't be changed.
>
> EXPORT_SYMBOL_GPL() should've been EXPORT_SYMBOL_INTERNAL(); like it or
> not, in-tree code *is* in different position exactly because it can be
> modified by whoever makes a change affecting such code.  For in-tree
> module one can expect such modifications to be done; for out-of-tree the
> same is obviously not true, but conclusion is not "you can't do changes",
> it's "authors of out-of-tree module get to do such modifications
> themselves".
>
> Sure, there are subsets of exports that have stronger promise of not being
> changed often; if a set of functions makes sense as an interface, it's
> less likely to change than randomly selected function that just had an
> export slapped on it at some point.  The promise is not absolute and it's
> not based on some obligations to out-of-tree modules; it's simply a common
> sense.
>
> Again, most of the exports had been added with very little justification
> at request of out-of-tree module authors.  That pile is many years past
> the stage when it could be described as set of sane interfaces and it's
> your [collective] fault.  Don't expect sympathy when you find the
> resulting devalvation unpleasant to deal with...

Ok, so some people made a mistake, and now everybody has to suffer?

What we need is a solution.  What is your suggestion?

Would a stable API exposing wrapper module be feasible?


Thanks!

--
Al

Re: Please release a stable kernel Linux 3.0

[William D Waddington]

Helge Hafting wrote:
> Bill Waddington wrote:
>> (And taking my drivers main-line isn't an option.  It would be fine
>> with me, but there is *zero* chance that my funky code would be
>> welcomed into the tree.)
>>   
> If the only merge-stopper is code quality, why not
> post your driver and get some feedback?  Cleaning up code
> will take some effort of course;
> but once it is done, you're protected from module API changes. . .

Fair enough:
http://www.tahomatech.com/downloads/drivers/linux_2.6/pci/x86/compressed_tarfiles/
or for your browsing pleasure:
http://www.tahomatech.com/downloads/drivers/linux_2.6/pci/x86/files/

But I really don't see much hope :(  Coding style, masses of ioctls,
build and install technique,  limited user base, etc, etc, etc...  Most
of the above to keep API compatibility with other OS/older drivers -
back to SunOS 4.1.3.  (BTW, it does seem to work...)

And I probably have the license wrong.  The code has always been in
the public domain.  (Advice welcome...)

It really isn't that important to me to get this into the mainline,
or to have a stable kernel API.  I _might_ argue that a stable and
well documented kernel API (DKI) is a sign of a grown-up OS, but I
won't :)  It isn't that hard to recode for API changes.  There's always
LDD17 or 18 or 99 or whatever...

My (mild) beef is more like what I take to be Al's point: it feels like
there is a kind of hostility toward out-of-tree maintainers.  Why not
encourage _all_ of us who are beavering away at open-source code?  My
stuff doesn't belong in mainline, but it _is_ open, and in some minor
way allows more folks to run Linux.

A cleaned-up, consistent, and out-of-tree friendly way of handling API
changes might help us all.

Thanks for listening,
Bill

-- 
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

Re: Please release a stable kernel Linux 3.0

[Helge Hafting]

Bill Waddington wrote:
> (And taking my drivers main-line isn't an option.  It would be fine
> with me, but there is *zero* chance that my funky code would be
> welcomed into the tree.)
>   
If the only merge-stopper is code quality, why not
post your driver and get some feedback?  Cleaning up code
will take some effort of course;
but once it is done, you're protected from module API changes. . .

Helge Hafting

Re: Please release a stable kernel Linux 3.0

[Al Viro]

On Thu, Jun 28, 2007 at 01:32:23AM +0300, Al Boldi wrote:
> > > You are effectively inhibiting the development of an out-of-tree GPL
> > > module pool, by constantly pulling the rug under that community.
> >
> > The same thing happens with any yet-to-be-merged code.
> >
> > > Do you think this is fair?
> >
> > Yes, it is fair.  Decision to maintain your code out of tree indefinitely
> > is your decision.
> 
> It's not my decision, it's the kernel maintainers decision to reject 
> inclusion for one reason or another.  One reason could be a simple "we don't 
> think this is useful".
 
"I maintain a patch to $PROGRAM; maintainers of $PROGRAM don't think it's
useful; they should abstain from making changes that might require rewrite
of that patch".  Would you argue that this is fair?

BTW, "if it's GPLed, it's entitled to any internal function" is a shell game;
it tries to convert GPL-given right to get to those functions into some kind
of promise that those functions won't be changed.

EXPORT_SYMBOL_GPL() should've been EXPORT_SYMBOL_INTERNAL(); like it or not,
in-tree code *is* in different position exactly because it can be modified
by whoever makes a change affecting such code.  For in-tree module one
can expect such modifications to be done; for out-of-tree the same is
obviously not true, but conclusion is not "you can't do changes", it's
"authors of out-of-tree module get to do such modifications themselves".

Sure, there are subsets of exports that have stronger promise of not being
changed often; if a set of functions makes sense as an interface, it's
less likely to change than randomly selected function that just had an
export slapped on it at some point.  The promise is not absolute and it's
not based on some obligations to out-of-tree modules; it's simply a common
sense.

Again, most of the exports had been added with very little justification
at request of out-of-tree module authors.  That pile is many years past
the stage when it could be described as set of sane interfaces and it's
your [collective] fault.  Don't expect sympathy when you find the resulting
devalvation unpleasant to deal with...

Re: Please release a stable kernel Linux 3.0

[Al Boldi]

Al Viro wrote:
> On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> > Al Viro wrote:
> > > On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > > > And as I understand it, this is (was ?) the whole point of
> > > > stable/development kernels. "We" can trust a newer stable
> > > > kernel to be a drop-in replacement for an older stable
> > > > kernel (from the same series), while development kernels
> > > > need time to stabilise with the new whizz-bang-pfouit stuff
> > > > that you all so nicely add.
> > >
> > > "Drop-in" in which sense?  That out-of-tree modules keep working?
> > > Not really...
> >
> > Al, be reasonable.  There are many out-of-tree GPL modules that won't be
> > accepted into mainline, never mind those that shouldn't be accepted. 
> > But these modules do have a right to not be obsoleted by constant API
> > changes.
>
> Modules do not have any rights; it's software...

Ok, this should have been read as kernel/module dev/user right to leverage 
each others code under GPL and out of good-will to yield an increased 
harvest.

> > You are effectively inhibiting the development of an out-of-tree GPL
> > module pool, by constantly pulling the rug under that community.
>
> The same thing happens with any yet-to-be-merged code.
>
> > Do you think this is fair?
>
> Yes, it is fair.  Decision to maintain your code out of tree indefinitely
> is your decision.

It's not my decision, it's the kernel maintainers decision to reject 
inclusion for one reason or another.  One reason could be a simple "we don't 
think this is useful".

Also, I think it's unrealistic to expect thousands of little-used modules to 
be included into mainline.

But, should we hinder that community to grow?


Thanks!

--
Al

Re: Please release a stable kernel Linux 3.0

[Al Boldi]

Adrian Bunk wrote:
> On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> > Al Viro wrote:
> > > On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > > > And as I understand it, this is (was ?) the whole point of
> > > > stable/development kernels. "We" can trust a newer stable
> > > > kernel to be a drop-in replacement for an older stable
> > > > kernel (from the same series), while development kernels
> > > > need time to stabilise with the new whizz-bang-pfouit stuff
> > > > that you all so nicely add.
> > >
> > > "Drop-in" in which sense?  That out-of-tree modules keep working?
> > > Not really...
> >
> > Al, be reasonable.  There are many out-of-tree GPL modules that won't be
> > accepted into mainline, never mind those that shouldn't be accepted. 
> > But these modules do have a right to not be obsoleted by constant API
> > changes.
>
> "have a right" are strong words.
> Who is granting them this right?

Good-will GPL style.

> > You are effectively inhibiting the development of an out-of-tree GPL
> > module pool, by constantly pulling the rug under that community.
> >
> > Do you think this is fair?
>
> Why are these modules not submitted for inclusion into the kernel?

There are many reasons for this, but basically they are too under-developed 
to be included, and need more time to mature out-of-tree.


Thanks!

--
Al

Re: Please release a stable kernel Linux 3.0

[Al Viro]

On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> Al Viro wrote:
> > On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > > And as I understand it, this is (was ?) the whole point of
> > > stable/development kernels. "We" can trust a newer stable
> > > kernel to be a drop-in replacement for an older stable
> > > kernel (from the same series), while development kernels
> > > need time to stabilise with the new whizz-bang-pfouit stuff
> > > that you all so nicely add.
> >
> > "Drop-in" in which sense?  That out-of-tree modules keep working?
> > Not really...
> 
> Al, be reasonable.  There are many out-of-tree GPL modules that won't be 
> accepted into mainline, never mind those that shouldn't be accepted.  But 
> these modules do have a right to not be obsoleted by constant API changes.

Modules do not have any rights; it's software, for fsck sake...
 
> You are effectively inhibiting the development of an out-of-tree GPL module 
> pool, by constantly pulling the rug under that community.

The same thing happens with any yet-to-be-merged code.
 
> Do you think this is fair?

Yes, it is fair.  Decision to maintain your code out of tree indefinitely
is your decision.

Re: Please release a stable kernel Linux 3.0

[Adrian Bunk]

On Wed, Jun 27, 2007 at 12:08:12PM -0400, Chuck Ebbert wrote:
> On 06/27/2007 11:52 AM, Adrian Bunk wrote:
> > On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> >> Al Viro wrote:
> >>> On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> >>>> And as I understand it, this is (was ?) the whole point of
> >>>> stable/development kernels. "We" can trust a newer stable
> >>>> kernel to be a drop-in replacement for an older stable
> >>>> kernel (from the same series), while development kernels
> >>>> need time to stabilise with the new whizz-bang-pfouit stuff
> >>>> that you all so nicely add.
> >>> "Drop-in" in which sense?  That out-of-tree modules keep working?
> >>> Not really...
> >> Al, be reasonable.  There are many out-of-tree GPL modules that won't be 
> >> accepted into mainline, never mind those that shouldn't be accepted.  But 
> >> these modules do have a right to not be obsoleted by constant API changes.
> > 
> > "have a right" are strong words.
> > Who is granting them this right?
> > 
> >> You are effectively inhibiting the development of an out-of-tree GPL module 
> >> pool, by constantly pulling the rug under that community.
> >>
> >> Do you think this is fair?
> > 
> > Why are these modules not submitted for inclusion into the kernel?
> > 
> 
> I was trying to figure that out for this one:
> 
> http://code.ximeta.com/trac-ndas
> 
> No mention of ever trying to get this upstream AFAICT... but this is
> interesting:
> 
>   The linux market is limited comparing that of MS Windows.
>   it is very hard for us to support the various linux distros.
>   we, Ximeta, are trying to support those requests as many as
>   we can, though the resources are very limited.

One of their module contains a 180 kB binary blob and
MODULE_LICENSE("Proprietary, Send bug reports to support@ximeta.com").

And it calls tons of functions EXPORT_SYMBOL'ed by their other
3 modules that are MODULE_LICENSE("Dual BSD/GPL")...

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

Re: Please release a stable kernel Linux 3.0

[Dmitry Torokhov]

Hi Chuck,

On 6/27/07, Chuck Ebbert <cebbert@redhat.com> wrote:
>
> I was trying to figure that out for this one:
>
> http://code.ximeta.com/trac-ndas
>
> No mention of ever trying to get this upstream AFAICT... but this is
> interesting:
>
>  The linux market is limited comparing that of MS Windows.
>  it is very hard for us to support the various linux distros.
>  we, Ximeta, are trying to support those requests as many as
>  we can, though the resources are very limited.
>

I would not worry about that one too much:

[~] ls -la ndas-1.1-6/*.sfx
-rw-r--r-- 1 TOROKHDM mkgroup-l-d 60416 Jun 27 12:22 ndas-1.1-6/libndas.a.sfx

-- 
Dmitry

Re: Please release a stable kernel Linux 3.0

[Chuck Ebbert]

On 06/27/2007 11:52 AM, Adrian Bunk wrote:
> On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
>> Al Viro wrote:
>>> On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
>>>> And as I understand it, this is (was ?) the whole point of
>>>> stable/development kernels. "We" can trust a newer stable
>>>> kernel to be a drop-in replacement for an older stable
>>>> kernel (from the same series), while development kernels
>>>> need time to stabilise with the new whizz-bang-pfouit stuff
>>>> that you all so nicely add.
>>> "Drop-in" in which sense?  That out-of-tree modules keep working?
>>> Not really...
>> Al, be reasonable.  There are many out-of-tree GPL modules that won't be 
>> accepted into mainline, never mind those that shouldn't be accepted.  But 
>> these modules do have a right to not be obsoleted by constant API changes.
> 
> "have a right" are strong words.
> Who is granting them this right?
> 
>> You are effectively inhibiting the development of an out-of-tree GPL module 
>> pool, by constantly pulling the rug under that community.
>>
>> Do you think this is fair?
> 
> Why are these modules not submitted for inclusion into the kernel?
> 

I was trying to figure that out for this one:

http://code.ximeta.com/trac-ndas

No mention of ever trying to get this upstream AFAICT... but this is
interesting:

  The linux market is limited comparing that of MS Windows.
  it is very hard for us to support the various linux distros.
  we, Ximeta, are trying to support those requests as many as
  we can, though the resources are very limited.

Re: Please release a stable kernel Linux 3.0

[Adrian Bunk]

On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> Al Viro wrote:
> > On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > > And as I understand it, this is (was ?) the whole point of
> > > stable/development kernels. "We" can trust a newer stable
> > > kernel to be a drop-in replacement for an older stable
> > > kernel (from the same series), while development kernels
> > > need time to stabilise with the new whizz-bang-pfouit stuff
> > > that you all so nicely add.
> >
> > "Drop-in" in which sense?  That out-of-tree modules keep working?
> > Not really...
> 
> Al, be reasonable.  There are many out-of-tree GPL modules that won't be 
> accepted into mainline, never mind those that shouldn't be accepted.  But 
> these modules do have a right to not be obsoleted by constant API changes.

"have a right" are strong words.
Who is granting them this right?

> You are effectively inhibiting the development of an out-of-tree GPL module 
> pool, by constantly pulling the rug under that community.
> 
> Do you think this is fair?

Why are these modules not submitted for inclusion into the kernel?

> Thanks!
> Al

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

Re: Please release a stable kernel Linux 3.0

[Bill Waddington]

On Wed, 27 Jun 2007 13:53:32 UTC, in fa.linux.kernel you wrote:

>Al Viro wrote:
>> On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
>> > And as I understand it, this is (was ?) the whole point of
>> > stable/development kernels. "We" can trust a newer stable
>> > kernel to be a drop-in replacement for an older stable
>> > kernel (from the same series), while development kernels
>> > need time to stabilise with the new whizz-bang-pfouit stuff
>> > that you all so nicely add.
>>
>> "Drop-in" in which sense?  That out-of-tree modules keep working?
>> Not really...
>
>Al, be reasonable.  There are many out-of-tree GPL modules that won't be 
>accepted into mainline, never mind those that shouldn't be accepted.  But 
>these modules do have a right to not be obsoleted by constant API changes.
>
>You are effectively inhibiting the development of an out-of-tree GPL module 
>pool, by constantly pulling the rug under that community.
>
>Do you think this is fair?
>
>
>Thanks!

No, thank *you*!  Here I thought I was the only one...

As a low-life out-of-tree maintainer, I would like to plead for at
least a mitigation of the pain of constantly changing kernel/module
APIs.  I realize that an interface freeze is out of the question, but
how about a more formal and regularized way of flagging changes.  The
nasty mess of version checking works (I guess) but it would sure be
nice to have change flags that were actually tied to the changes
themselves.  Consistently.

(And taking my drivers main-line isn't an option.  It would be fine
with me, but there is *zero* chance that my funky code would be
welcomed into the tree.)

Thanks,
Bill (donning asbestos shorts...)
-- 
William D Waddington
william.waddington@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

Re: Please release a stable kernel Linux 3.0

[Al Boldi]

Al Viro wrote:
> On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > And as I understand it, this is (was ?) the whole point of
> > stable/development kernels. "We" can trust a newer stable
> > kernel to be a drop-in replacement for an older stable
> > kernel (from the same series), while development kernels
> > need time to stabilise with the new whizz-bang-pfouit stuff
> > that you all so nicely add.
>
> "Drop-in" in which sense?  That out-of-tree modules keep working?
> Not really...

Al, be reasonable.  There are many out-of-tree GPL modules that won't be 
accepted into mainline, never mind those that shouldn't be accepted.  But 
these modules do have a right to not be obsoleted by constant API changes.

You are effectively inhibiting the development of an out-of-tree GPL module 
pool, by constantly pulling the rug under that community.

Do you think this is fair?


Thanks!

--
Al