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: [email protected]
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
________________________
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.
> 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
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
________________________
On 21/06/07, Zolt?n HUBERT <[email protected]> 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 <[email protected]>
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
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...
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/
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
________________________
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
________________________
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
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.
On 22/06/07, Zolt?n HUBERT <[email protected]> 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 <[email protected]>
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
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.
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
On Jun 22 2007 00:29, Jesper Juhl wrote:
> On 21/06/07, Zoltán HUBERT <[email protected]> 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
--
On Fri, 22 Jun 2007, Jan Engelhardt wrote:
> On Jun 22 2007 00:29, Jesper Juhl wrote:
>> On 21/06/07, Zoltán HUBERT <[email protected]> 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
Chuck Ebbert <[email protected]> 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
[email protected]
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.
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.
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
On Jun 21 2007 16:32, [email protected] 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
--
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
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
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
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
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
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
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: [email protected]
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
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
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.)
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
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.
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
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
________________________
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
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------
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
________________________
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...
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
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
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
[email protected]
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
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
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
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.
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?
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 [email protected]").
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
Hi Chuck,
On 6/27/07, Chuck Ebbert <[email protected]> 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
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.
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
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
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...
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
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
[email protected]
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
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
> 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.
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
[email protected]
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
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...
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
*
On Fri, 29 Jun 2007 00:00:27 +0200
Rene Herman <[email protected]> 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
On 06/29/2007 12:48 AM, Alan Cox wrote:
> On Fri, 29 Jun 2007 00:00:27 +0200
> Rene Herman <[email protected]> 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.
> 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
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
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
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
[email protected]
<>< As a computer I find your faith in technology amusing.
Alan Cox <[email protected]> wrote:
> On Fri, 29 Jun 2007 00:00:27 +0200
> Rene Herman <[email protected]> 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: [email protected] [email protected]
On 06/29/2007 11:05 PM, Bodo Eggert wrote:
> Alan Cox <[email protected]> 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.
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
On Friday 29 June 2007 17:27:34 Rene Herman wrote:
> On 06/29/2007 11:05 PM, Bodo Eggert wrote:
> > Alan Cox <[email protected]> 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 [email protected]
> 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.
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.