Hi list.
I tought long about writting this mail. I'm a linux use since many years.
At the moment i'll getting more then frustrated about the actual develoment
model of the kernel. In the latest releases things where broken from release
to release.
For example take the ipw2200 driver.
From 2.6.12 -> 2.6.13 the header file ieee80211.h was incompatible with
driver.
Also transfer speed decreased dramaticaly.
From 2.6.13 -> 2.6.14 you included the ipw2200 driver. But in an too
old version
without WPA support. The external driver on ipw2200.sourceforge.net
seems not
to work with 2.6.14.
I had also several problems with some other not in kernel drivers.
I realy liked it to have the latest state of the art kernel, but at the
moment i'm forced
to use 2.6.12 ( ipw2200 -> WPA ).
I can't understand it why you have to break compatibility from kernel
release to kernel
release. Don't you think that this makes 3'rd party driver developers
frustrated?
It can't be an option for 3'rd party developers and users to check if
external drivers
still works with new kenrel releases.
From my point of view the actual linux kernel is far away from a stable
development
process.
cu
ED.
hostmaster <[email protected]> :
[...]
> I can't understand it why you have to break compatibility from kernel
> release to kernel release.
Please read the archives of [email protected]. ipw2200 popped up
again yesterday.
--
Ueimor
Hi, huh...
... don't you have a real name? Posting as "hostmaster" may impress
teenagers, but over there we tend to prefer people with real names.
> I tought long about writting this mail. I'm a linux use since many years.
> At the moment i'll getting more then frustrated about the actual develoment
> model of the kernel. In the latest releases things where broken from release
> to release.
> For example take the ipw2200 driver.
> From 2.6.12 -> 2.6.13 the header file ieee80211.h was incompatible with
> driver.
> Also transfer speed decreased dramaticaly.
> From 2.6.13 -> 2.6.14 you included the ipw2200 driver. But in an too
> old version without WPA support.
> (...)
> I realy liked it to have the latest state of the art kernel, but at the
> moment i'm forced to use 2.6.12 ( ipw2200 -> WPA ).
Your problems seem to be very specific to wireless networking, right?
Blaming the whole development model because one area seems to have
problems is a bit awkward, don't you think? Report to the persons
responsible for that area and/or specific driver, tell them about the
problem, they'll surely listen to you and improve the process if
possible.
Also, the point you mention for the 2.6.13 -> 2.6.14 transition is
irrelevant with regards to the development model. With a different
development model, the driver wouldn't have been added at all. This
wouldn't have made any difference for you as far as I can see.
> The external driver on ipw2200.sourceforge.net seems not to work
> with 2.6.14.
> (...)
> I had also several problems with some other not in kernel drivers.
Third party drivers don't work, and you complain to us. What's the
point?
> I can't understand it why you have to break compatibility from kernel
> release to kernel release.
You should read this document:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/stable_api_nonsense.txt
> Don't you think that this makes 3'rd party driver developers
> frustrated?
We don't care. It's their choice, not ours.
> It can't be an option for 3'rd party developers and users to check if
> external drivers still works with new kenrel releases.
It is. If they are not happy with that, they simply get their code
integrated into the main Linux tree, and get to work with us rather
than apart on their own. It's easier for us, it's easier for them,
and it's easier for the users. Everyone benefits.
> From my point of view the actual linux kernel is far away from a stable
> development process.
Yet you don't propose anything to improve it?
--
Jean Delvare
Hi.
Sorry for not posting my Name.
Maybe you don't understand what i wanted to say or it's my bad english.
The ipw2200 driver was only an example. I had also problems with, vmware,
unionfs...
What i mean ist, that kernel developers make incompatible changes to the
header
files, change structures, interfaces and so on. Which makes the kernel
releases
incompatible.
There are several reasons why modules are not in the mainline kernel and
will never
get there. So saying, bring modules to the kernel is wrong.
The right way would be to take care of defined interfaces, header files,
and so on.
Otherwise you could only say the kernel 2.6.14 is only compatible to
2.6.14.X and
you there is no stable 2.6 mainline kernel.
I think it's also no task for the user, to search the net why external
driver xyz not
works with a new kernel ( because of incompatibilties ). Basicly in new
kernel there
could be a chance for the user a driver works better, because a bug was
fixed in the
kernel.
Hopefully this time it's more clear why i blame the development process
and i'm a
so frustrated linux user.
cu
ED.
Jean Delvare wrote:
>Hi, huh...
>
>... don't you have a real name? Posting as "hostmaster" may impress
>teenagers, but over there we tend to prefer people with real names.
>
>
>
>>I tought long about writting this mail. I'm a linux use since many years.
>>At the moment i'll getting more then frustrated about the actual develoment
>>model of the kernel. In the latest releases things where broken from release
>>to release.
>>For example take the ipw2200 driver.
>> From 2.6.12 -> 2.6.13 the header file ieee80211.h was incompatible with
>>driver.
>>Also transfer speed decreased dramaticaly.
>> From 2.6.13 -> 2.6.14 you included the ipw2200 driver. But in an too
>>old version without WPA support.
>>(...)
>>I realy liked it to have the latest state of the art kernel, but at the
>>moment i'm forced to use 2.6.12 ( ipw2200 -> WPA ).
>>
>>
>
>Your problems seem to be very specific to wireless networking, right?
>Blaming the whole development model because one area seems to have
>problems is a bit awkward, don't you think? Report to the persons
>responsible for that area and/or specific driver, tell them about the
>problem, they'll surely listen to you and improve the process if
>possible.
>
>Also, the point you mention for the 2.6.13 -> 2.6.14 transition is
>irrelevant with regards to the development model. With a different
>development model, the driver wouldn't have been added at all. This
>wouldn't have made any difference for you as far as I can see.
>
>
>
>>The external driver on ipw2200.sourceforge.net seems not to work
>>with 2.6.14.
>>(...)
>>I had also several problems with some other not in kernel drivers.
>>
>>
>
>Third party drivers don't work, and you complain to us. What's the
>point?
>
>
>
>>I can't understand it why you have to break compatibility from kernel
>>release to kernel release.
>>
>>
>
>You should read this document:
>http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/stable_api_nonsense.txt
>
>
>
>>Don't you think that this makes 3'rd party driver developers
>>frustrated?
>>
>>
>
>We don't care. It's their choice, not ours.
>
>
>
>>It can't be an option for 3'rd party developers and users to check if
>>external drivers still works with new kenrel releases.
>>
>>
>
>It is. If they are not happy with that, they simply get their code
>integrated into the main Linux tree, and get to work with us rather
>than apart on their own. It's easier for us, it's easier for them,
>and it's easier for the users. Everyone benefits.
>
>
>
>>From my point of view the actual linux kernel is far away from a stable
>>development process.
>>
>>
>
>Yet you don't propose anything to improve it?
>
>
>
On Sat, Nov 05, 2005 at 02:19:30PM +0100, Edgar Hucek wrote:
> Hi.
Hi Edgar,
> Sorry for not posting my Name.
>
> Maybe you don't understand what i wanted to say or it's my bad english.
> The ipw2200 driver was only an example. I had also problems with, vmware,
> unionfs...
> What i mean ist, that kernel developers make incompatible changes to the
> header
> files, change structures, interfaces and so on. Which makes the kernel
> releases
> incompatible.
you've already been given a pointer to the
Documentation/stable_api_nonsense.txt document in the kernel sources
that explains these issues.
> There are several reasons why modules are not in the mainline kernel and
> will never
> get there. So saying, bring modules to the kernel is wrong.
It's not wrong.
Every vendor of any kind of software will tell you A is supported and
B is not supported.
It's a consensus among the Linux kernel developers that the Linux kernel
does not support a stable API for external modules.
You don't have to like this decision, but stable_api_nonsense.txt
explains it.
If you dislike this decision, there are several other operating systems
whose vendors do offer a stable API for external modules.
> The right way would be to take care of defined interfaces, header files,
> and so on.
> Otherwise you could only say the kernel 2.6.14 is only compatible to
> 2.6.14.X and
> you there is no stable 2.6 mainline kernel.
The 2.6 is a stable kernel series in the sense that it doesn't crash
very often.
2.6.14 is not API-compatible with 2.6.15.
But this has always been this way, the new development model only brings
more API changes than the previous development models.
> I think it's also no task for the user, to search the net why external
> driver xyz not
> works with a new kernel ( because of incompatibilties ). Basicly in new
> kernel there
> could be a chance for the user a driver works better, because a bug was
> fixed in the
> kernel.
>...
I do agree, this is not a task for the user.
It's a task for the vendors of the external modules.
> cu
>
> ED.
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 Saturday 05 November 2005 13:19, Edgar Hucek wrote:
> Hi.
>
> Sorry for not posting my Name.
>
> Maybe you don't understand what i wanted to say or it's my bad english.
> The ipw2200 driver was only an example. I had also problems with, vmware,
> unionfs...
Read the document linked to by Jean. It explains why a volatile API is
ultimately beneficial to the Linux development process.
It's frustrating for vendors and maintainers to keep their code up to date
with the latest kernel, but if it's done incrementally after Linus releases
(or during the very lengthy RC process), it's usually very easy.
Also, you're gelling together many projects which have completely different
reasons for breaking across kernel revisions.
ipw2200 "works" in 2.6.14, it's just the maintainer has opted to use a "stable
version" which lacks experimental features while ieee80211 gets up to
scratch.
OTOH, unionfs is poorly maintained and is a particularly sore example of how
the linux development model is detrimental to external module development.
There are people constantly working to make binary modules like VMWare, NVIDIA
and ATI work under the newest kernels. Just google it. Ultimately we can't
allow ourselves to be held down by slow-moving binary vendors. It's too
inefficient (not to mention of questionable ethics).
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On 11/5/05, Edgar Hucek <[email protected]> wrote:
> Hi.
>
> Sorry for not posting my Name.
>
> Maybe you don't understand what i wanted to say or it's my bad english.
> The ipw2200 driver was only an example. I had also problems with, vmware,
> unionfs...
> What i mean ist, that kernel developers make incompatible changes to the
> header
> files, change structures, interfaces and so on. Which makes the kernel
> releases
> incompatible.
> There are several reasons why modules are not in the mainline kernel and
> will never
> get there. So saying, bring modules to the kernel is wrong.
> The right way would be to take care of defined interfaces, header files,
> and so on.
> Otherwise you could only say the kernel 2.6.14 is only compatible to
> 2.6.14.X and
> you there is no stable 2.6 mainline kernel.
> I think it's also no task for the user, to search the net why external
> driver xyz not
> works with a new kernel ( because of incompatibilties ). Basicly in new
> kernel there
> could be a chance for the user a driver works better, because a bug was
> fixed in the
> kernel.
> Hopefully this time it's more clear why i blame the development process
> and i'm a
> so frustrated linux user.
>
There is a very simple solution to your problem. Use the kernels
provided by your distribution and not the kernel.org kernels.
--
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
Am Samstag, 5. November 2005 15:34 schrieb Jesper Juhl:
> There is a very simple solution to your problem. Use the kernels
> provided by your distribution and not the kernel.org kernels.
If enough people do so, testing will suffer.
Regards
Oliver
On 11/5/05, Oliver Neukum <[email protected]> wrote:
> Am Samstag, 5. November 2005 15:34 schrieb Jesper Juhl:
> > There is a very simple solution to your problem. Use the kernels
> > provided by your distribution and not the kernel.org kernels.
>
> If enough people do so, testing will suffer.
>
But people using Linux from user-point of view or for running
applications/services and not for system development then the kernel
with the distributions are the best choice for them because they are
optimized by-default with the other applications/services provided by
the distro !
--
Fawad Lateef
On Sat, Nov 05, 2005 at 03:48:12PM +0100, Oliver Neukum wrote:
> Am Samstag, 5. November 2005 15:34 schrieb Jesper Juhl:
> > There is a very simple solution to your problem. Use the kernels
> > provided by your distribution and not the kernel.org kernels.
>
> If enough people do so, testing will suffer.
For a _user_, it is the best choice to use the kernel provided by the
distribution.
There _are_ incompatible changes between 2.6 kernels, and if you e.g.
try to run kernel 2.6.14 on a Debian stable that ships only 2.6.8 you
can always run into problems here or there.
And it seems we already have many big guinea pigs running the
development branch of Fedora.
> Regards
> Oliver
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
Alistair John Strachan wrote:
>
> ipw2200 "works" in 2.6.14, it's just the maintainer has opted to use a "stable
> version" which lacks experimental features while ieee80211 gets up to scratch.
I haven't been able to get it working. Nor does the external one seem
to work with 2.6.14 -- still stuck on 2.6.13 here, which impacts my ability
to help with testing of dev kernels.
-ml
On Saturday 05 November 2005 22:23, Mark Lord wrote:
> Alistair John Strachan wrote:
> > ipw2200 "works" in 2.6.14, it's just the maintainer has opted to use a
> > "stable version" which lacks experimental features while ieee80211 gets
> > up to scratch.
>
> I haven't been able to get it working. Nor does the external one seem
> to work with 2.6.14 -- still stuck on 2.6.13 here, which impacts my ability
> to help with testing of dev kernels.
Well, the in-kernel 1.0.0 works fine here on 2.6.14 (no WPA of course). The
only caveat is that you need to downgrade your firmware if you've been using
1.0.7 (or 1.0.8) prior, which I had and was initially confusing.
Otherwise, I suggest you file a bug report.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On 11/5/05, Edgar Hucek <[email protected]> wrote:
> Hi.
>
> Sorry for not posting my Name.
>
> Maybe you don't understand what i wanted to say or it's my bad english.
> The ipw2200 driver was only an example. I had also problems with, vmware,
> unionfs...
> What i mean ist, that kernel developers make incompatible changes to the
> header
> files, change structures, interfaces and so on. Which makes the kernel
> releases
> incompatible.
I will ask you just one question: as a user, why did you want to
upgrade your kernel?
On a server you want stability. So you don't upgrade. On a desktop,
there are probably a bunch of out of kernel modules that will need
upgrading with each new kernel modules. Just on the laptop I am using
right now, I will have to upgrade the vmware bridge, nvidia driver,
madwifi wireless driver, etc. And that's normal. The new development
model didn't change that.
I avoid touching my kernel on boxes I do real work with. I do build a
new kernel for test purposes and to give feedback if there's an issue.
But most of the time I skip 2-3 versions before finding a very
compelling reason to upgrade. And I stick with my distribution kernel
as much as I can.
As for kernel/drivers developers, it's another story.
If it ain't broken, don't fix it.
Jerome
jerome lacoste wrote:
> On 11/5/05, Edgar Hucek <[email protected]> wrote:
>
>
>> Hi.
>>
>> Sorry for not posting my Name.
>>
>> Maybe you don't understand what i wanted to say or it's my bad english.
>> The ipw2200 driver was only an example. I had also problems with,
>> vmware,
>> unionfs...
>> What i mean ist, that kernel developers make incompatible changes to the
>> header
>> files, change structures, interfaces and so on. Which makes the kernel
>> releases
>> incompatible.
>>
>
>
> I will ask you just one question: as a user, why did you want to
> upgrade your kernel?
>
>
Depends on the user and what he wants to do. There are several
reasons why a user wanna upgrade to new kernel. Maybe new supported
hardware and so on. It's frustrating for the user, have on the one side the
new hardware supported but on the other side, mybe broken support for
the existing hardware.
> On a server you want stability. So you don't upgrade.
Sure, but what about securrity updates. When a new kernel release
comes out the updates are stopped for older releases. And why should
dirstribution makers always backport new security fixes ?
> On a desktop, there are probably a bunch of out of kernel modules that
> will need
> upgrading with each new kernel modules. Just on the laptop I am using
> right now, I will have to upgrade the vmware bridge, nvidia driver,
> madwifi wireless driver, etc. And that's normal. The new development
> model didn't change that.
>
>
From my point of view, it makes a difference if i have to recompile
a module or realy upgrade it.
> I avoid touching my kernel on boxes I do real work with. I do build a
> new kernel for test purposes and to give feedback if there's an issue.
> But most of the time I skip 2-3 versions before finding a very
> compelling reason to upgrade. And I stick with my distribution kernel
> as much as I can.
>
>
>
So you wanna say a new "stable" kernel isn't a realy a stable one
and i can't relay that it behaves like the older one ? If it's so, then
something is completely wrong in kernel development.
> As for kernel/drivers developers, it's another story.
>
> If it ain't broken, don't fix it.
>
> Jerome
>
>
>
cu
ED.
On Sun, Nov 06, 2005 at 12:55:14PM +0100, Edgar Hucek wrote:
> jerome lacoste wrote:
>...
> >On a server you want stability. So you don't upgrade.
>
> Sure, but what about securrity updates. When a new kernel release
> comes out the updates are stopped for older releases. And why should
> dirstribution makers always backport new security fixes ?
>...
Because it's their job.
As long as a vendor supports a release of his distribution, the absolute
minimum he has to provide are regular security fixes for all the
software the release offers - including the kernels shipped with the
release.
E.g. the latest security update RedHat offered for the kernel 2.4.9 (sic)
used in their version 2.1 server products was two months ago.
And they will provide security updates until 2009.
> cu
>
> ED.
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 Sun, 2005-11-06 at 12:55 +0100, Edgar Hucek wrote:
[...]
> Sure, but what about securrity updates. When a new kernel release
> comes out the updates are stopped for older releases. And why should
> dirstribution makers always backport new security fixes ?
Because they have no other choice.
Or are you here to do this for them?
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On 11/6/05, Edgar Hucek <[email protected]> wrote:
> jerome lacoste wrote:
[...]
> >I will ask you just one question: as a user, why did you want to
> >upgrade your kernel?
> >
> >
> Depends on the user and what he wants to do. There are several
> reasons why a user wanna upgrade to new kernel. Maybe new supported
> hardware and so on. It's frustrating for the user, have on the one side the
> new hardware supported but on the other side, mybe broken support for
> the existing hardware.
New kernel feature and new supported hardware would be the only reason
for me to upgrade. Personally that doesn't come that often. My
hardware configurations don't change that much. I make sure it's well
supported, not just recently. When one buys a non supported hardware,
one should know the path chosen won't be the easiest.
> >On a server you want stability. So you don't upgrade.
> >
> Sure, but what about securrity updates. When a new kernel release
> comes out the updates are stopped for older releases.
For vanilla kernels, yes.
> And why should dirstribution makers always backport new security fixes ?
Because they want to ensure maximum stability. That's what users are
(sometimes) paying for.
And second 90% of the security issues will not affect the majority of
the home users (because they are restricted to a particular area of
the kernel not affecting the user, or because they already require
access on the machine to be exploitable). You will have much more
risks using a box with an unpatched php or apache than with an
unpached kernel, or without a proper firewall configuration.
> >On a desktop, there are probably a bunch of out of kernel modules that will need
> >upgrading with each new kernel modules. Just on the laptop I am using
> >right now, I will have to upgrade the vmware bridge, nvidia driver,
> >madwifi wireless driver, etc. And that's normal. The new development
> >model didn't change that.
> >
> >
> From my point of view, it makes a difference if i have to recompile
> a module or realy upgrade it.
That only happens for out ot tree modules, which shouldn't be really
out of tree in the first place. That's the issue. If they are out of
tree, it's for a reason. Either they cannot be in tree, or they are
not stable enough.
There you see the issue.
> [...]
> cu
>
> ED.
Jerome
On Sat, Nov 05, 2005 at 10:42:15AM +0100, hostmaster wrote:
> It can't be an option for 3'rd party developers and users to
> check if external drivers still works with new kenrel releases.
Who should check? It can't be the kernel developers since they
don't know who the 3'rd party developers are.
- Jim
--
[email protected]
SDF Public Access UNIX System - http://sdf.lonestar.org
--- jerome lacoste <[email protected]> wrote:
> On 11/5/05, Edgar Hucek <[email protected]>
> wrote:
> > Hi.
> >
> > Sorry for not posting my Name.
> >
> > Maybe you don't understand what i wanted to say or
> it's my bad english.
> > The ipw2200 driver was only an example. I had also
> problems with, vmware,
> > unionfs...
> > What i mean ist, that kernel developers make
> incompatible changes to the
> > header
> > files, change structures, interfaces and so on.
> Which makes the kernel
> > releases
> > incompatible.
>
> I will ask you just one question: as a user, why did
> you want to
> upgrade your kernel?
>
> On a server you want stability. So you don't
> upgrade. On a desktop,
> there are probably a bunch of out of kernel modules
> that will need
> upgrading with each new kernel modules. Just on the
> laptop I am using
> right now, I will have to upgrade the vmware bridge,
> nvidia driver,
> madwifi wireless driver, etc. And that's normal. The
> new development
> model didn't change that.
>
> I avoid touching my kernel on boxes I do real work
> with. I do build a
> new kernel for test purposes and to give feedback if
> there's an issue.
> But most of the time I skip 2-3 versions before
> finding a very
> compelling reason to upgrade. And I stick with my
> distribution kernel
> as much as I can.
>
> As for kernel/drivers developers, it's another
> story.
>
> If it ain't broken, don't fix it.
>
> Jerome
> -
> 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/
>
Another method, the one I use, is to keep a small
drive with a minimum system on it to test/update the
kernel. After updating the kernel and any modules
required on the test driver, its then a simple matter
to move them, if there are no problems, to my working
system.
Jack
John Carlson
<[email protected]>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
--- Jim Nance <[email protected]> wrote:
> On Sat, Nov 05, 2005 at 10:42:15AM +0100, hostmaster
> wrote:
>
> > It can't be an option for 3'rd party developers
> and users to
> > check if external drivers still works with new
> kenrel releases.
>
> Who should check? It can't be the kernel developers
> since they
> don't know who the 3'rd party developers are.
>
> - Jim
>
> --
> [email protected]
> SDF Public Access UNIX System -
> http://sdf.lonestar.org
> -
> 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/
>
Nor do they always have the required hardware to test
the fixes.
jack
John Carlson
<[email protected]>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
Hi Edgar,
> It's frustrating for the user, have on the one side the
> new hardware supported but on the other side, mybe broken support for
> the existing hardware.
> (...)
> So you wanna say a new "stable" kernel isn't a realy a stable one
> and i can't relay that it behaves like the older one ? If it's so, then
> something is completely wrong in kernel development.
"stable" is a relative notion. It's a tradeoff between improvements and
the lack of regression. What you are asking for is absolute stability.
This can only be achieved by the absolute lack of change. As soon as
any change is made to the kernel, there is a risk of regression. Blame
it on the complexity and variety of computer hardware.
It is our collective belief, as the kernel developers, that the current
development model represents the best tradeoff we can achieve. We know,
because we are the ones who suffer the most when the development model
is not efficient.
Having a separate development branch is not a solution. It was
discussed on this list and various other places several times already.
Read the archives. The bottom line is that separate trees increase the
workload on developers and divide the testing efforts, so we're losing
on all fronts.
Let's imagine we have a separate development branch for a minute. This
means we wouldn't be adding new stuff to the stable branch, right? Else
it wouldn't be stable. So, you would complain that the stable branch
doesn't have the latset ipw2200 driver. We would direct you to the
development branch, which has it. You would complain that some drivers
are broken for you in this branch, which is expected to happen in a
development branch. See? Separate branches did not even solve your
problem.
You blame your current problems on the development model, yet you
failed to demonstrate how exactly this development model was
responsible for them, as you failed to propose a different model which
would solve them.
--
Jean Delvare
On Sat, 2005-11-05 at 14:19 +0100, Edgar Hucek wrote:
[...]
> Maybe you don't understand what i wanted to say or it's my bad english.
> The ipw2200 driver was only an example. I had also problems with, vmware,
> unionfs...
> What i mean ist, that kernel developers make incompatible changes to the
> header
ACK. The reason is the improve the kernel and drivers.
> files, change structures, interfaces and so on. Which makes the kernel
> releases incompatible.
ACK. It needs (a lot of) work to keep backwards compatibility and who
wants can do it (probably).
At what to do at the point where you actually have to break it?
> There are several reasons why modules are not in the mainline kernel and
> will never
> get there. So saying, bring modules to the kernel is wrong.
The last conclusion doesn't hold. Especially not in this general form.
You have to list the "various reaons" and then we can discuss each of
them.
> The right way would be to take care of defined interfaces, header files,
> and so on.
The only defined interface of the kernel can be found in POSIX, SUSv3
and similar documents.
> Otherwise you could only say the kernel 2.6.14 is only compatible to
> 2.6.14.X and
> you there is no stable 2.6 mainline kernel.
Compatible in what way? Source? Object? User-space binary interface?
> I think it's also no task for the user, to search the net why external
Then don't do it.
> driver xyz not
> works with a new kernel ( because of incompatibilties ). Basicly in new
> kernel there
Who is interested in the new driver/kernel/..?
The user. So guess who's job is to do it (or find someone to do it -
paid or unpaid).
> could be a chance for the user a driver works better, because a bug was
> fixed in the kernel.
> Hopefully this time it's more clear why i blame the development process
> and i'm a so frustrated linux user.
Who do you mean with "user"?
A typical "user" just installs $DISTRIBUTION (be it a free or commercial
one) and that's it. *If* the bug is severe enough (and the relevant
maintainers does it) there will be a new rpm/deb/... with the newest
kernel release or a backport.
If not, you can do it on your own anyways.
But then you are half a programmer and more like a sys-admin and no
longer a "user". Voila.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Sun, 6 Nov 2005, jerome lacoste wrote:
> On 11/6/05, Edgar Hucek <[email protected]> wrote:
>> jerome lacoste wrote:
> [...]
>>> I will ask you just one question: as a user, why did you want to
>>> upgrade your kernel?
>>>
>>>
>> Depends on the user and what he wants to do. There are several
>> reasons why a user wanna upgrade to new kernel. Maybe new supported
>> hardware and so on. It's frustrating for the user, have on the one side the
>> new hardware supported but on the other side, mybe broken support for
>> the existing hardware.
>
> New kernel feature and new supported hardware would be the only reason
> for me to upgrade. Personally that doesn't come that often. My
> hardware configurations don't change that much. I make sure it's well
> supported, not just recently. When one buys a non supported hardware,
> one should know the path chosen won't be the easiest.
>
There are other reasons for using a new kernel. One of them is
interactivity. In the days of 2.4 one could achieve decent interactivity
for the desktop using preempt and low latency patches. For 2.6
interactivity was a real issue (possibly because of the new development
model).
>> And why should dirstribution makers always backport new security fixes ?
>
> Because they want to ensure maximum stability. That's what users are
> (sometimes) paying for.
>
Maximum stability of what ? If the distribution kernels are based on
vanila kernel (i.e. are based on unstable kernel) how stable will they be
?
On lkml someone said that "stable means it won't crash very often".
This sounds like Windows(TM)
> And second 90% of the security issues will not affect the majority of
> the home users (because they are restricted to a particular area of
> the kernel not affecting the user, or because they already require
> access on the machine to be exploitable). You will have much more
> risks using a box with an unpatched php or apache than with an
> unpached kernel, or without a proper firewall configuration.
>
Some holes are remote ;-)
>>> On a desktop, there are probably a bunch of out of kernel modules that will need
>>> upgrading with each new kernel modules. Just on the laptop I am using
>>> right now, I will have to upgrade the vmware bridge, nvidia driver,
>>> madwifi wireless driver, etc. And that's normal. The new development
>>> model didn't change that.
>>>
>>>
>> From my point of view, it makes a difference if i have to recompile
>> a module or realy upgrade it.
>
> That only happens for out ot tree modules, which shouldn't be really
> out of tree in the first place. That's the issue. If they are out of
> tree, it's for a reason. Either they cannot be in tree, or they are
> not stable enough.
>
> There you see the issue.
>
>> [...]
>> cu
>>
>> ED.
>
> Jerome
Calin
--
On Sun, 6 Nov 2005, Bernd Petrovitsch wrote:
>
> Who do you mean with "user"?
> A typical "user" just installs $DISTRIBUTION (be it a free or commercial
> one) and that's it. *If* the bug is severe enough (and the relevant
> maintainers does it) there will be a new rpm/deb/... with the newest
> kernel release or a backport.
> If not, you can do it on your own anyways.
> But then you are half a programmer and more like a sys-admin and no
> longer a "user". Voila.
>
So a user which is not typical user should not use a Linux distribution ?
--
On Wed, 9 Nov 2005 11:11 am, [email protected] wrote:
> There are other reasons for using a new kernel. One of them is
> interactivity. In the days of 2.4 one could achieve decent interactivity
> for the desktop using preempt and low latency patches. For 2.6
> interactivity was a real issue (possibly because of the new development
> model).
Eh? Where are the bug reports for this? I've only seen better interactivity
and responsiveness with 2.6.
The only time I've seen bad behaviour repeatedly on forums and elsewhere has
been due to misconfigured IDE drivers not using DMA and X servers still
reniced to -10.
Cheers,
Con
Hi, posting from the outside so, no nice quotes and stuff.
Anyways, I was also miffed that the kernel folks merged a 'ancient'
version of ipw2200 and ieee802.11, if they had merged something more
current everything would have worked out of the box and all the cleanups
would have been easier to cope with. Ie, the intel ppl could release
straight patches to the in kernel version. I dunno if they have changed
the way their driver works now.
Atm, the 'ancient' ieee802.11 is what breaks the ipw2200 build. So,
basically all testing of cutting edge kernels gets very tedious due to
the ieee802.11 package removing the offending .h file and making
reversing -gitX and applying -gitY a real PITA.
Also, I dunno if it says what version of the firmware it should have...
Anyways, current state of ipw2200 is sad, and ieee802.11 is more
developed out of tree. So imho at least ieee802.11 should be merged more
closely and then generalized if needed (i think i saw some patches like
that) and preferably ipw2200 should be merged as well.
This b0rkage has actually kept me from using wlan AND testing kernel.org
kernels.
PS. Above, wrt merging, i assume that the API isn't quite 'stable' and
that changing any drivers using them should be simple and
straightforward.
stable as in, used all over and require major rewrites to change =)
DS.
PPS. Why merge a outdated version of a driver/protocol/thingy at all?
DS.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
El Wed, 9 Nov 2005 11:23:51 +1100,
Con Kolivas <[email protected]> escribi?:
> Eh? Where are the bug reports for this? I've only seen better interactivity
> and responsiveness with 2.6.
It has certainly much better behaviour under load for me, to the point
that sometimes I don't notice there's some computing-intensive process
running in the background until I run top (and i thank you a lot for
that ;)
Diego Calleja (who had lots of VM problems and suffered from filesystem
corruption two times with 2.4 and its "stable" development model)
On Wed, 2005-11-09 at 02:47 +0100, Ian Kumlien wrote:
> Anyways, I was also miffed that the kernel folks merged a 'ancient'
> version of ipw2200 and ieee802.11, if they had merged something more
> current everything would have worked out of the box and all the cleanups
> would have been easier to cope with. Ie, the intel ppl could release
> straight patches to the in kernel version. I dunno if they have changed
> the way their driver works now.
>
> Atm, the 'ancient' ieee802.11 is what breaks the ipw2200 build. So,
> basically all testing of cutting edge kernels gets very tedious due to
> the ieee802.11 package removing the offending .h file and making
> reversing -gitX and applying -gitY a real PITA.
Those are no "ancient" versions, they are the "stable" versions of
ieee80211, ipw2100 and ipw2200. ipw* folks think, and I have to agree,
that for the stable kernel (Linux tree) it makes sense to add the stable
versions of their projects.
For more about their versioning, make sure you read
http://ipw2100.sourceforge.net/#downloads .
--
Marcos Marado <[email protected]>
Novis ISP
On Wed, 2005-11-09 at 11:08 +0000, Marcos Marado wrote:
> On Wed, 2005-11-09 at 02:47 +0100, Ian Kumlien wrote:
>
> > Anyways, I was also miffed that the kernel folks merged a 'ancient'
> > version of ipw2200 and ieee802.11, if they had merged something more
> > current everything would have worked out of the box and all the cleanups
> > would have been easier to cope with. Ie, the intel ppl could release
> > straight patches to the in kernel version. I dunno if they have changed
> > the way their driver works now.
> >
> > Atm, the 'ancient' ieee802.11 is what breaks the ipw2200 build. So,
> > basically all testing of cutting edge kernels gets very tedious due to
> > the ieee802.11 package removing the offending .h file and making
> > reversing -gitX and applying -gitY a real PITA.
>
> Those are no "ancient" versions, they are the "stable" versions of
> ieee80211, ipw2100 and ipw2200. ipw* folks think, and I have to agree,
> that for the stable kernel (Linux tree) it makes sense to add the stable
> versions of their projects.
Yes, that would make sense if everyone interested changed the 'unstable'
version instead, since they change the version merged it only creates
problems. And if you DO check out the ipw2200 site you see that there
has been no stable release for about a year and that there has been a
large amount of bugfixes.
Also, the 'stable' version didn't use a separated ieee802.11 stack.
So to summarize:
Merging the latest version of both and then, if someone has problems,
tell them to downgrade would be simpler. This also means that the
ipw2200 team could release patches against the kernel as well as
standalone modules.
The 'stable' version that got merged is more or less useless to people
who are smart about their wlans. And on a side note, even the firmware
has improved since then.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
El Wed, 09 Nov 2005 12:30:32 +0100,
Ian Kumlien <[email protected]> escribi?:
> The 'stable' version that got merged is more or less useless to people
> who are smart about their wlans. And on a side note, even the firmware
> has improved since then.
People who is smart about their wlans is smart enought to update their
kernels to use the new and possibily more unstable version. What's the
problem? People maintaining the main tree may have a different (and
valid) view on this issue. People is allowed to have different
opinions than you, deal with it.
On 11/9/05, [email protected] <[email protected]> wrote:
[...]
> >> reasons why a user wanna upgrade to new kernel. Maybe new supported
> >> hardware and so on. It's frustrating for the user, have on the one side the
> >> new hardware supported but on the other side, mybe broken support for
> >> the existing hardware.
> >
> > New kernel feature and new supported hardware would be the only reason
> > for me to upgrade. Personally that doesn't come that often. My
> > hardware configurations don't change that much. I make sure it's well
> > supported, not just recently. When one buys a non supported hardware,
> > one should know the path chosen won't be the easiest.
> >
>
> There are other reasons for using a new kernel. One of them is
> interactivity. In the days of 2.4 one could achieve decent interactivity
> for the desktop using preempt and low latency patches. For 2.6
> interactivity was a real issue (possibly because of the new development
> model).
I don't get it. You say that with 2.4 + patches you had good
interactivity and with 2.6 you don't? Why did you switch then?
> >> And why should dirstribution makers always backport new security fixes ?
> >
> > Because they want to ensure maximum stability. That's what users are
> > (sometimes) paying for.
> >
>
> Maximum stability of what ? If the distribution kernels are based on
> vanila kernel (i.e. are based on unstable kernel) how stable will they be
> ?
Maximum stability of the kernel they deliver. When you fix a
vulnerability, you fix a vulnerability. You don't just happen to add a
new bunch of features, and a new bunch of bugs. Otherwise you are
going to piss off your users a lot.
Everybody does that, including Microsoft (most of the time).
> On lkml someone said that "stable means it won't crash very often".
> This sounds like Windows(TM)
I've had Linux running on various hardware, from Pentium I machines to
AMD 64bits machines and various laptops. The most problematic hardware
I've had to deal was a MythTV box running on a Via EPIA M motherboard
(due to what seems to be DMA issues on the board), and PCMCIA hang a
on a Dell laptop. Some installation issues on new hardware and a
wireless pcmcia card whose drivers are not stable. Apart from that,
Linux has always been running very well. I had less than 10 hangs and
hard reboots in 8 year with 20 machines. I had more oopses but 95% of
the time confined to a module and not critical. And I've had more
hardware failures, drives, disks, keyboards, pcmcia&usb ports, mice,
motherboard than kernel issues.
On the security side, I've been broken into twice, one because of a
very dumb misconfiguration on my part on a desktop (guest/guest
account, no firewall, ssh server enabled and not restricted....), one
on a server, probably because of an external php program whose
security was not handled by the distribution (haven't investigated the
issue yet, server is down).
To me, the most problematic crashes on desktops are X failures,
because I lose several minutes to set up my desktop again.
And firefox crashes (or becomes unusable) way too often (around twice a week).
> > And second 90% of the security issues will not affect the majority of
> > the home users (because they are restricted to a particular area of
> > the kernel not affecting the user, or because they already require
> > access on the machine to be exploitable). You will have much more
> > risks using a box with an unpatched php or apache than with an
> > unpached kernel, or without a proper firewall configuration.
> >
>
> Some holes are remote ;-)
That's your 10% (probably even much lower than that). And if you have
a firewall on your desktop, most services turned down, and are behind
a private network with a router with its own firewall, the probability
that you get a remote attack on your particular version of the kernel,
for which they are very few exploits in the wild anyway, is much lower
than having a hard drive failure or a X server crash because of a
driver issue.
If you care about stability, don't touch what works.
J
On Wed, 2005-11-09 at 12:30 +0100, Ian Kumlien wrote:
> On Wed, 2005-11-09 at 11:08 +0000, Marcos Marado wrote:
> > On Wed, 2005-11-09 at 02:47 +0100, Ian Kumlien wrote:
> > > Atm, the 'ancient' ieee802.11 is what breaks the ipw2200 build. So,
> > > basically all testing of cutting edge kernels gets very tedious due to
> > > the ieee802.11 package removing the offending .h file and making
> > > reversing -gitX and applying -gitY a real PITA.
> >
> > Those are no "ancient" versions, they are the "stable" versions of
> > ieee80211, ipw2100 and ipw2200. ipw* folks think, and I have to agree,
> > that for the stable kernel (Linux tree) it makes sense to add the stable
> > versions of their projects.
>
> Yes, that would make sense if everyone interested changed the 'unstable'
> version instead, since they change the version merged it only creates
> problems. And if you DO check out the ipw2200 site you see that there
> has been no stable release for about a year and that there has been a
> large amount of bugfixes.
>
> Also, the 'stable' version didn't use a separated ieee802.11 stack.
>
> So to summarize:
> Merging the latest version of both and then, if someone has problems,
> tell them to downgrade would be simpler. This also means that the
> ipw2200 team could release patches against the kernel as well as
> standalone modules.
>
> The 'stable' version that got merged is more or less useless to people
> who are smart about their wlans. And on a side note, even the firmware
> has improved since then.
I totally disagree. See: for those who don't crawl on lkml, don't
compile kernels or modules or stuff like that, they had two choices: be
without ipw2100 or ipw2200 or learn how to put the drivers in their
kernels. Now, with the stock kernel you have ipw* support, even if
limited for some uses. Most people will be happy with this version, but
yes, there's still work to be done. When there's a new version
considered stable it will get merged into the kernel. Until then, if you
want to ride the unstable horse, you'll have to patch it yourself into
the kernel.
If you want to simplify the process of building the unstable versios of
ipw* or if you think that the newer versions of ipw* should be
considered the new stable, or if you at some point disagree with ipw*
development model you should complain in ipw2100 mailing list at
http://lists.sourceforge.net/lists/listinfo/ipw2100-devel .
Kernel-related, the decision of supporting the latest stable is good and
justifiable.
--
Marcos Marado <[email protected]>
Novis ISP
On Wed, 9 Nov 2005, jerome lacoste wrote:
> On 11/9/05, [email protected] <[email protected]> wrote:
> [...]
>>
>> There are other reasons for using a new kernel. One of them is
>> interactivity. In the days of 2.4 one could achieve decent interactivity
>> for the desktop using preempt and low latency patches. For 2.6
>> interactivity was a real issue (possibly because of the new development
>> model).
>
> I don't get it. You say that with 2.4 + patches you had good
> interactivity and with 2.6 you don't? Why did you switch then?
>
Because i like to test new kernels. On 2.4 I run the vanila kernel and a
test kernel. When something went wrong on a test kernel was always a
stable kernel to use.
2.6 looks a lot like 2.5. New features are added very quickly without much
testing. Of course there is Andrew's -mm tree but this one sometimes
is too broken.
For me linux looks now like it has one unstable tree (2.6) which is
something like -ac was in days of 2.4 and -mm was in the days of 2.4
-2.5 and -mm which looks like it became very unstable.
This is what i saw ok lkml (maybe my view is distorted).
I'll stop ranting and try both of them because i have some bugs to report.
>>>> And why should dirstribution makers always backport new security fixes ?
>>>
>>> Because they want to ensure maximum stability. That's what users are
>>> (sometimes) paying for.
>>>
>>
>> Maximum stability of what ? If the distribution kernels are based on
>> vanila kernel (i.e. are based on unstable kernel) how stable will they be
>> ?
>
> Maximum stability of the kernel they deliver. When you fix a
> vulnerability, you fix a vulnerability. You don't just happen to add a
> new bunch of features, and a new bunch of bugs. Otherwise you are
> going to piss off your users a lot.
>
That's what's happening on 2.6. Every 2.6.x release is different.
The 2.6.x.y kernels sometimes are almost no different from 2.6.x
--
On Wed, 2005-11-09 at 16:03 +0200, [email protected] wrote:
> On Wed, 9 Nov 2005, jerome lacoste wrote:
> Because i like to test new kernels. On 2.4 I run the vanila kernel and a
> test kernel. When something went wrong on a test kernel was always a
> stable kernel to use.
> 2.6 looks a lot like 2.5. New features are added very quickly without much
> testing. Of course there is Andrew's -mm tree but this one sometimes
> is too broken.
> For me linux looks now like it has one unstable tree (2.6) which is
> something like -ac was in days of 2.4 and -mm was in the days of 2.4
> -2.5 and -mm which looks like it became very unstable.
> This is what i saw ok lkml (maybe my view is distorted).
> I'll stop ranting and try both of them because i have some bugs to report.
Man, -mm are unstable kernels, 2.6.x[.y] are the stable ones.
> The 2.6.x.y kernels sometimes are almost no different from 2.6.x
That's true, and good. the .y is the -stable tree, that is supposed to
add only stability and security fixes.
--
Marcos Marado <[email protected]>
Novis ISP
On Wed, 2005-11-09 at 13:03 +0100, Wed, 9 Nov 2005 13:03:07 +0100 wrote:
> El Wed, 09 Nov 2005 12:30:32 +0100,
> Ian Kumlien <[email protected]> escribi?:
>
> > The 'stable' version that got merged is more or less useless to people
> > who are smart about their wlans. And on a side note, even the firmware
> > has improved since then.
>
> People who is smart about their wlans is smart enought to update their
> kernels to use the new and possibily more unstable version. What's the
> problem? People maintaining the main tree may have a different (and
> valid) view on this issue.
Since it out of tree, it's not a issue of 'updating' a kernel, it's more
of a issue of making it compile with a kernel.
(which if you read the original post was one of the problems mentioned.)
And, yes, they might have a valid view, but the kernel also has
"experimental" features, why not merge a driver that can be used, mark
it as experimental until it's merged with a stable rel. The issue of
getting the first rel in to the kernel is that all of the sudden more
developers starts hacking away on it and the original developers have to
keep it all in sync (as i mentioned before).
> People is allowed to have different opinions than you, deal with it.
And that applies to me to, now deal with it.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
On Wed, Nov 09, 2005 at 04:49:17PM +0100, Ian Kumlien wrote:
> > People is allowed to have different opinions than you, deal with it.
>
> And that applies to me to, now deal with it.
That's easy - you are welcome to maintain whatever tree you like according
to your opinion. Same as everybody else.
Repost, forgot the CC etc lines. (Yeah i know, reply to all etc)
On Wed, 2005-11-09 at 12:37 +0000, Marcos Marado wrote:
> On Wed, 2005-11-09 at 12:30 +0100, Ian Kumlien wrote:
> > So to summarize:
> > Merging the latest version of both and then, if someone has problems,
> > tell them to downgrade would be simpler. This also means that the
> > ipw2200 team could release patches against the kernel as well as
> > standalone modules.
> >
> > The 'stable' version that got merged is more or less useless to people
> > who are smart about their wlans. And on a side note, even the firmware
> > has improved since then.
>
> I totally disagree. See: for those who don't crawl on lkml, don't
> compile kernels or modules or stuff like that, they had two choices: be
> without ipw2100 or ipw2200 or learn how to put the drivers in their
> kernels. Now, with the stock kernel you have ipw* support, even if
> limited for some uses. Most people will be happy with this version, but
> yes, there's still work to be done. When there's a new version
> considered stable it will get merged into the kernel. Until then, if you
> want to ride the unstable horse, you'll have to patch it yourself into
> the kernel.
Since it has to be out of tree the way it is now, you don't patch or
upgrade, you simply have to make it compile. And if you are happy with
wlan driver that hardly does wep then you have some issues as well.
> If you want to simplify the process of building the unstable versios of
> ipw* or if you think that the newer versions of ipw* should be
> considered the new stable, or if you at some point disagree with ipw*
> development model you should complain in ipw2100 mailing list at
> http://lists.sourceforge.net/lists/listinfo/ipw2100-devel .
> Kernel-related, the decision of supporting the latest stable is good and
> justifiable.
Thats why we have "experimental" drivers in the kernel?
like, f.ex.:
Packet Engines Yellowfin Gigabit-NIC support (EXPERIMENTAL)
New SysKonnect GigaEthernet support (EXPERIMENTAL)
Or the protocols? (STCP, DCCP, etc)
IF a unstable version of a driver is better for the user isn't it better
to merge it as experimental instead of merging a old version that wreaks
havock on users of newer kernels (and they will STILL run the unstable
version on older kernels anyways).
Note: I use skge myself, so pointing out that they are experimental is
in no way negative, i actually prefer it to the stable driver.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
On Wed, 2005-11-09 at 15:58 +0000, Al Viro wrote:
> On Wed, Nov 09, 2005 at 04:49:17PM +0100, Ian Kumlien wrote:
>
> > > People is allowed to have different opinions than you, deal with it.
> >
> > And that applies to me to, now deal with it.
>
> That's easy - you are welcome to maintain whatever tree you like according
> to your opinion. Same as everybody else.
ROTFLOL, Yeah i know, I just think it's more about the users need than
'stable' and 'unstable', Just label it experimental so the user knows
what they are getting into. (Just like the examples posted in other
mails)
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
Marcos Marado wrote:
> On Wed, 2005-11-09 at 02:47 +0100, Ian Kumlien wrote:
>
>
>>Anyways, I was also miffed that the kernel folks merged a 'ancient'
>>version of ipw2200 and ieee802.11, if they had merged something more
>>current everything would have worked out of the box and all the cleanups
>>would have been easier to cope with. Ie, the intel ppl could release
>>straight patches to the in kernel version. I dunno if they have changed
>>the way their driver works now.
>>
>>Atm, the 'ancient' ieee802.11 is what breaks the ipw2200 build. So,
>>basically all testing of cutting edge kernels gets very tedious due to
>>the ieee802.11 package removing the offending .h file and making
>>reversing -gitX and applying -gitY a real PITA.
>
>
> Those are no "ancient" versions, they are the "stable" versions of
> ieee80211, ipw2100 and ipw2200. ipw* folks think, and I have to agree,
> that for the stable kernel (Linux tree) it makes sense to add the stable
> versions of their projects.
To what end? The current drivers compile and load, but they don't
function for wireless communication! What's the point of having code
which is essentially a no-op, why have it if it doesn't provide any
functionality?
With the current firmware and driver a "scan" shows 14 connectible
points outside an apartment building (only one secured in any way ;-)
whic is just what Windows shows. With the stock kernel zero are found.
That's not stable that's moribund.
>
> For more about their versioning, make sure you read
> http://ipw2100.sourceforge.net/#downloads .
>
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Wed, 2005-11-09 at 14:05 -0500, Bill Davidsen wrote:
> With the current firmware and driver a "scan" shows 14 connectible
> points outside an apartment building (only one secured in any way ;-)
> whic is just what Windows shows. With the stock kernel zero are found.
> That's not stable that's moribund.
Sorry to disagree, but I use the stock kernel version of ipw2100 almost
daily, with no problems.
--
Marcos Marado <[email protected]>
Novis ISP
On Wednesday 09 November 2005 20:10, Marcos Marado wrote:
> On Wed, 2005-11-09 at 14:05 -0500, Bill Davidsen wrote:
> > With the current firmware and driver a "scan" shows 14 connectible
> > points outside an apartment building (only one secured in any way ;-)
> > whic is just what Windows shows. With the stock kernel zero are found.
> > That's not stable that's moribund.
>
> Sorry to disagree, but I use the stock kernel version of ipw2100 almost
> daily, with no problems.
I concur, ipw2200 is also fully functional here. This sounds like a genuine
bug, or a mis-configured system, not a criticism of the current Linux
development model.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Wednesday 09 November 2005 16:01, Ian Kumlien wrote:
[snip]
> > I totally disagree. See: for those who don't crawl on lkml, don't
> > compile kernels or modules or stuff like that, they had two choices: be
> > without ipw2100 or ipw2200 or learn how to put the drivers in their
> > kernels. Now, with the stock kernel you have ipw* support, even if
> > limited for some uses. Most people will be happy with this version, but
> > yes, there's still work to be done. When there's a new version
> > considered stable it will get merged into the kernel. Until then, if you
> > want to ride the unstable horse, you'll have to patch it yourself into
> > the kernel.
>
> Since it has to be out of tree the way it is now, you don't patch or
> upgrade, you simply have to make it compile. And if you are happy with
> wlan driver that hardly does wep then you have some issues as well.
Eh? WEP seems to work here with different key sizes. I think most people
should be satisfied with finally being able to use their wireless controller
in ANY form on a Centrino laptop without having to find a driver!
> > If you want to simplify the process of building the unstable versios of
> > ipw* or if you think that the newer versions of ipw* should be
> > considered the new stable, or if you at some point disagree with ipw*
> > development model you should complain in ipw2100 mailing list at
> > http://lists.sourceforge.net/lists/listinfo/ipw2100-devel .
> > Kernel-related, the decision of supporting the latest stable is good and
> > justifiable.
>
> Thats why we have "experimental" drivers in the kernel?
>
> like, f.ex.:
> Packet Engines Yellowfin Gigabit-NIC support (EXPERIMENTAL)
> New SysKonnect GigaEthernet support (EXPERIMENTAL)
>
> Or the protocols? (STCP, DCCP, etc)
>
> IF a unstable version of a driver is better for the user isn't it better
> to merge it as experimental instead of merging a old version that wreaks
> havock on users of newer kernels (and they will STILL run the unstable
> version on older kernels anyways).
I'm not sure what you mean by "wreaks havoc". There have been bugfixes, but
they do not affect many general use-cases. Equally the WPA work really IS
brand new.
The primary "havoc" I had when upgrading to 2.6.14 was finding the older
firmware and co-installing it.
> Note: I use skge myself, so pointing out that they are experimental is
> in no way negative, i actually prefer it to the stable driver.
I really don't think this is your call. The driver maintainer can push
whatever code he's most happy with for whatever reasons he likes. I'm
confident that in time appropriate changes from 1.0.8 will make it into
mainline.
Perhaps the only criticism here that is valid is that Intel haven't released a
1.0.9 that builds against release quality (2.6.14) kernels _yet_. But at best
that is a topic for another mailing list, not the LKML.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alistair John Strachan wrote:
>
> Eh? WEP seems to work here with different key sizes. I think most people
> should be satisfied with finally being able to use their wireless controller
> in ANY form on a Centrino laptop without having to find a driver!
Err.. there are lots of different APs out there,
and the in-kernel borken driver doesn't work for me
with several APs I need to access.
Not to mention that WEP doesn't provide any meaningful security,
whereas the out-of-tree driver even does WPA2 with ease.
The big problem for users, is that they used to be able to just go
and grab the *real* ipw2200 driver, and build/install it with a few
simple commands.
But because the kernel now contains all of this way-outdated
stuff for ieee80211 and ipw2200, there are tons of header file
conflicts and protocol mismatches when attempting to build/use
the real driver.
Sure, us kernel folk can cope with all of that (in theory,
though in practice I'm still stuck with 2.6.13 because I haven't
yet gotten working ipw2200 with 2.6.14, with *either* driver).
But things just got WAY more complicated for most users of ipw2200.
Sure, they can ignore us and just continue to run their old vendor
kernels. But this means they don't get up-to-date kernels with
bug fixes and security fixes. And more importantly to LKML,
we've now just cut off a potentially large crowd of kernel-testers.
Ugh. Ugly.
On Thursday 10 November 2005 15:10, Mark Lord wrote:
[snip]
> Sure, us kernel folk can cope with all of that (in theory,
> though in practice I'm still stuck with 2.6.13 because I haven't
> yet gotten working ipw2200 with 2.6.14, with *either* driver).
I'm probably asking a silly question here, but presumably you've grabbed
ieee80211 1.1.6 and ipw2200 1.0.8 from their respective websites, compiled
them, installed them (whilst running 2.6.14) and the resulting driver does
not work?
> But things just got WAY more complicated for most users of ipw2200.
> Sure, they can ignore us and just continue to run their old vendor
> kernels. But this means they don't get up-to-date kernels with
> bug fixes and security fixes. And more importantly to LKML,
> we've now just cut off a potentially large crowd of kernel-testers.
>
> Ugh. Ugly.
I completely agree with this assessment, I was merely defending the "linux
development process" which I do not believe to be at fault here.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Thu, 2005-11-10 at 19:29 +0000, Alistair John Strachan wrote:
> On Thursday 10 November 2005 15:10, Mark Lord wrote:
> [snip]
> > But things just got WAY more complicated for most users of ipw2200.
> > Sure, they can ignore us and just continue to run their old vendor
> > kernels. But this means they don't get up-to-date kernels with
> > bug fixes and security fixes. And more importantly to LKML,
> > we've now just cut off a potentially large crowd of kernel-testers.
> >
> > Ugh. Ugly.
>
> I completely agree with this assessment, I was merely defending the "linux
> development process" which I do not believe to be at fault here.
It isn't, this started as a mail from someone, and was continued because
ipw* and ieee* things was mentioned. I really hope that a newer version
is merged... It can be branded experimental and all... =)
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
On Thu, 10 Nov 2005, Alistair John Strachan wrote:
> On Wednesday 09 November 2005 20:10, Marcos Marado wrote:
> > On Wed, 2005-11-09 at 14:05 -0500, Bill Davidsen wrote:
> > > With the current firmware and driver a "scan" shows 14 connectible
> > > points outside an apartment building (only one secured in any way ;-)
> > > whic is just what Windows shows. With the stock kernel zero are found.
> > > That's not stable that's moribund.
> >
> > Sorry to disagree, but I use the stock kernel version of ipw2100 almost
> > daily, with no problems.
>
> I concur, ipw2200 is also fully functional here. This sounds like a genuine
> bug, or a mis-configured system, not a criticism of the current Linux
> development model.
Given that using recent firmware and drive software works and stock
doesn't, I personally have a hard time saying that the configuration is
wrong. Being old-fashioned I conclude that the thing you change to fix a
problem is most likely the thing that caused the problem in the first
place.
can't speak to the 2100, I have a 2200, and with the current firmware and
driver it works.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
While an unsigned integer can never be negative, it can be less than zero
for sufficiently large values of zero.
On Thursday 10 November 2005 20:08, Bill Davidsen wrote:
> On Thu, 10 Nov 2005, Alistair John Strachan wrote:
> > On Wednesday 09 November 2005 20:10, Marcos Marado wrote:
> > > On Wed, 2005-11-09 at 14:05 -0500, Bill Davidsen wrote:
> > > > With the current firmware and driver a "scan" shows 14 connectible
> > > > points outside an apartment building (only one secured in any way ;-)
> > > > whic is just what Windows shows. With the stock kernel zero are
> > > > found. That's not stable that's moribund.
> > >
> > > Sorry to disagree, but I use the stock kernel version of ipw2100 almost
> > > daily, with no problems.
> >
> > I concur, ipw2200 is also fully functional here. This sounds like a
> > genuine bug, or a mis-configured system, not a criticism of the current
> > Linux development model.
>
> Given that using recent firmware and drive software works and stock
> doesn't, I personally have a hard time saying that the configuration is
> wrong. Being old-fashioned I conclude that the thing you change to fix a
> problem is most likely the thing that caused the problem in the first
> place.
>
> can't speak to the 2100, I have a 2200, and with the current firmware and
> driver it works.
You need to use *exactly the right version* of the firmware (2.2 I believe)
with the ipw2200 driver in 2.6.14. Non-2.2 firmwares just don't work with the
1.0.0 driver (though the latest firmware obviously works with 1.0.8).
Are you using WPA{,2}? The driver in 2.6.14 doesn't do WPA, only WEP.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Marcos Marado wrote:
>On Wed, 2005-11-09 at 14:05 -0500, Bill Davidsen wrote:
>
>
>
>>With the current firmware and driver a "scan" shows 14 connectible
>>points outside an apartment building (only one secured in any way ;-)
>>whic is just what Windows shows. With the stock kernel zero are found.
>>That's not stable that's moribund.
>>
>>
>
>Sorry to disagree, but I use the stock kernel version of ipw2100 almost
>daily, with no problems.
>
>
>
Well if ipw2100 works on one machine for one person, obviously ipw2200
must be correct as well. I never said they didn't work anywhere, and I
have no old 2100 hardware.
But the new {firm,soft}ware works and gives the same results as XP,
while the default says there are no usable signals in range. And like it
or not, it has to work at least as well as Windows on the same machine
to be considered functional. Many devices work better.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979