Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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] - 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/
Re: Please release a stable kernel Linux 3.0
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.
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
> 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 - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
On 06/28/2007 06:30 PM, Alan Cox wrote: Public domain is GPL compatible. Would you happen to have an opinion on the attached? I don't so much need it or anything but I thought about submitting this once when I was working on some stuff locally. I didn't since I was expecting arguments that public domain is not so much a license, and how it becomes GPL anyway, ... Stating that code which one intends to be in the public domain has "GPL and additional rights" is a bit of a travesty though. Signed-off-by: Rene Herman <[EMAIL PROTECTED]> Rene. diff --git a/include/linux/license.h b/include/linux/license.h index decdbf4..1176471 100644 --- a/include/linux/license.h +++ b/include/linux/license.h @@ -8,7 +8,8 @@ static inline int license_is_gpl_compatible(const char *license) || strcmp(license, "GPL and additional rights") == 0 || strcmp(license, "Dual BSD/GPL") == 0 || strcmp(license, "Dual MIT/GPL") == 0 - || strcmp(license, "Dual MPL/GPL") == 0); + || strcmp(license, "Dual MPL/GPL") == 0 + || strcmp(license, "Public Domain") == 0); } #endif diff --git a/include/linux/module.h b/include/linux/module.h index e6e0f86..2ecacf8 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -107,6 +107,7 @@ extern struct module __this_module; * or MIT license choice] * "Dual MPL/GPL" [GNU Public License v2 * or Mozilla license choice] + * "Public Domain" [Public domain products] * * The following other idents are available *
Re: Please release a stable kernel Linux 3.0
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... - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
> 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. - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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... - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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
-
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/
Re: Please release a stable kernel Linux 3.0
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? - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 kerne
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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... - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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-- PGP.sig Description: This is a digitally signed message part
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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.) - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 old 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
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
On Jun 21 2007 16:32, [EMAIL PROTECTED] wrote: >> >> For my part, I think the 2.6. did not go as well as the 2.6., >> 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 -- - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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] - 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/
Re: Please release a stable kernel Linux 3.0
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 old 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. did not go as well as the 2.6., beginning with x=16. you misunderstood the even/odd it was never 2.x.y with y odd/even being stable / development, it was the x being even/odd to indicate stable / development. all 2.6.x are stable, all 2.5.x were development. David Lang
Re: Please release a stable kernel Linux 3.0
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 >> old 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. did not go as well as the 2.6., beginning with x=16. >> Why on earth call "kernel object" things that are "kernel modules" >> ? And that every person calls "modules" and not "objects" ? I know >> I know, in UNIX dynamic libraries are .so "shared objects", so >> what ? A "module" is a "module" and NOT an "object", call a cat a >> cat. >> > It sure is an object, it's even called object code. I think the name > suits just fine. In any case, it's just a name. Back in the 2.4 days and e.g. on Solaris (still) today, a kernel object file is [can be] a kernel module. Under Linux, this is not the case anymore since 2.6.x when kbuild started to postprocess modules (creating these nice .mod.c and .mod.o files and the benefits associated with it). Jan --
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
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/ - 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/
Re: Please release a stable kernel Linux 3.0
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... - 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/
Re: Please release a stable kernel Linux 3.0
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 old 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 - 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/
Re: Please release a stable kernel Linux 3.0
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 - 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/
Re: Please release a stable kernel Linux 3.0
> 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 - 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/
Re: Please release a stable kernel Linux 3.0
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. - 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/
Please release a stable kernel Linux 3.0
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 old 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 - 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/
