Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Wed, Sep 28, 2011 at 02:44:06PM +, James wrote: The kernel gyrations are all really about something much more important. *MONEY* ...Commercial distros like Apple's offering are making billions. OS X is not a linux distribution. It uses the xnu kernel, which fuses elements of BSD kernels with the Mach microkernel to create a hybrid. Also, I think Linus still has a lot of say about kernel development and last I checked he's not particularly wealthy, so while there is some merit in what you say (mostly in the sense that money can buy more developer hours) I don't think Linux kernel development is all about the money. -- caveat utilitor ♫ ❤ ♫ ❤ ♫ ❤ ♫ ❤
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Am Mittwoch 28 September 2011, 17:15:34 schrieb Grant Edwards: Regardless, my point was that Linus's statement that it's unacceptable to break things seemed rather disingenuous given the API churn that Linux has compared with the BSD kernels. Linux has zero userland visible API 'churn'. You can't have less than zero. -- #163933
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Am Donnerstag 29 September 2011, 01:27:27 schrieb Peter Humphrey: On Tuesday 27 September 2011 17:52:24 Volker Armin Hemmann wrote: which is your own fucking fault. Get your drivers into the kernel. Problem solved. Does gratuitous obscenity come naturally to you, or do you have to work at it? I am naturally grumpy. I also have 'bastard' in my passport. -- #163933
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Volker Armin Hemmann volkerar...@googlemail.com wrote: Linux has zero userland visible API 'churn'. During what timeframe? There have been massive Linux API breakages in 2004. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Thu, Sep 29, 2011 at 12:19 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Mittwoch 28 September 2011, 17:15:34 schrieb Grant Edwards: Regardless, my point was that Linus's statement that it's unacceptable to break things seemed rather disingenuous given the API churn that Linux has compared with the BSD kernels. Linux has zero userland visible API 'churn'. You can't have less than zero. Uh, that can't be right. Largely, libc masks things. Several kernel options explicitly state in their description that they require new-enough versions of this or that userland tool to function properly. Randomizing module base addresses is one of those, IIRC. Some things related to sysfs. sysfs itself. I think some network filesystems. modutils. If there's no API churn, it should be pretty trivial to run a current userland on top of, e.g. 2.6.0-pre1, or even 2.6.0. I also STR 2.6.9 being a common pin point where a bunch of userland tools required that-or-newer. And that's ignoring dropping things like A.OUT support. I'm not arguing whether or not it's reasonable (it almost certainly is), but there certainly is churn. -- :wq
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
which is your own fucking fault. Get your drivers into the kernel. Problem solved. Does gratuitous obscenity come naturally to you, or do you have to work at it? I am naturally grumpy. Yeah we've noticed ;) I like reading your posts because you know stuff, and I like the fireworks. You probably have a serotonin deficiency. Be careful though, being grumpy is dangerously seductive.
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Friday 30 September 2011 01:45:39 Adam Carter wrote: Be careful though, being grumpy is dangerously seductive. It is? You could have fooled me -- Rgds Peter Linux Counter 5290, 1994-04-23
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Be careful though, being grumpy is dangerously seductive. It is? You could have fooled me Sorry - I meant being grumpy is seductive for the grumpy person. Its pretty much the opposite for the people they interact with, as you imply.
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Volker Armin Hemmann wrote: Am Donnerstag 29 September 2011, 01:27:27 schrieb Peter Humphrey: On Tuesday 27 September 2011 17:52:24 Volker Armin Hemmann wrote: which is your own fucking fault. Get your drivers into the kernel. Problem solved. Does gratuitous obscenity come naturally to you, or do you have to work at it? I am naturally grumpy. Wonder what I am? Then again, does it matter? Then again, do I want to know? :/ Dale :-) :-)
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Thu, Sep 29, 2011 at 10:29 PM, Dale rdalek1...@gmail.com wrote: Volker Armin Hemmann wrote: Am Donnerstag 29 September 2011, 01:27:27 schrieb Peter Humphrey: On Tuesday 27 September 2011 17:52:24 Volker Armin Hemmann wrote: I am naturally grumpy. Wonder what I am? Then again, does it matter? Then again, do I want to know? :/ You're naturally curious, and unafraid to push technical boundaries. Me, I'm just easily trolled. :) -- :wq
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Michael Mol wrote: On Thu, Sep 29, 2011 at 10:29 PM, Dalerdalek1...@gmail.com wrote: Volker Armin Hemmann wrote: Am Donnerstag 29 September 2011, 01:27:27 schrieb Peter Humphrey: On Tuesday 27 September 2011 17:52:24 Volker Armin Hemmann wrote: I am naturally grumpy. Wonder what I am? Then again, does it matter? Then again, do I want to know? :/ You're naturally curious, and unafraid to push technical boundaries. Me, I'm just easily trolled. :) I am the curious type except for one thing. SNAKES. Seeing one on TV is fine but in real life, lead poisoning. O_O I have killed three this year in my yard or garden. My cat isn't dead a year and they are moving in on me. Technical boundaries, I'd like to push the Fedora dev doing the /usr and /var on / thing off my roof, holding a snake. lol My Dad used to always tell me that a snake is more scared of us than we are of it. I came back with this, does the snake wear Depends? I know I was close to needing mine. If the snake is more scared, then he lost his. o_O I need to take my meds. Dale :-) :-)
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Am Mittwoch 28 September 2011, 14:44:06 schrieb James: Volker Armin Hemmann volkerarmin at googlemail.com writes: Breaking the user experience in order to ???fix??? something is a totally broken concept; you cannot do it. That's hilarious. The Linux developers are _constantly_ changing APIs in ways that break existing device driver code. There are repeatedly wholesale re-designs of some APIs that happen between minor versions of a supposedly stable kernel. which is seriously not a problem and does not matter in the slightest. Some perspective may ease the pain here. Folks on this list are focused on *their personal pain*. Welcome to unix/bsd/linux. (too many decades now) No pain, no gain. Gui experiences are what consumers see, feel and purchase; so Volker is very right here. The kernel gyrations are all really about something much more important. *MONEY* well, if you make money with linux, their are many choices for you. Nobody forces you to target the latest kernel. You can always go with one of the many stable releases out there. Look them up. Just think about it, on this list in the last few months, we have discussed how the stock market runs on linux, Some folks use GPU + CPU for very advanced things, Commercial distros like Apple's offering are making billions. Android. (on and on). The point is the Linux Kernel is the battle ground for software deployment, particularly firmware. An infinite number of user experiences can be packaged and sold on top of the Linux kernel. so what? what does this have to do with linux changing internal apis that are not supposed to be public? (hint: nothing) Here's another one: Carrier Grade Linux (runs most of the worlds communications systems, including most carrier grade cisco gear. Most legacy comm system at some point now, get boosted on top of private IP networks run by the carriers (or military). Cisco recommends embedded linux on their carrier switches and IOS is an unmanaged *hacked* pig, with little future. see above The gymnastics about the kernel and drivers are the public manifestation of a much deeper battle for embedded systems supremacy using linux. Wind River, unquestionable the largest commercial offering of embedded solutions has products based on both bsd and linux kernels. In ka-hoots with chip vendors they routinely offer enhanced drivers to companies that build products, with features never to found in the linux published sources. Binaries are available and yet clearly violate the spirit of the whole (whore) open source movement. WHY? *MONEY*. Governments and miltaries also feed at this trough. Linus would have his tits slapped together, if he every interfered with these industries. He in only in charge of the gyrations tell that yourself to make you happy. Tons of products still use embedded linux for the 2.4 kernel series. and there are even products with 2.2 kernels. What does that prove? Nothing? Companies build very large data base systems, using the latest technologies that work with the linux kernel. Often these technologies only appear for the masses, years after companies use a in house version as the key pillar for commercial success (MONEY). and again, what does that have to do with internal api changes? Take for example the company that does backups for one of the worlds largest and most complicated database needs. The good old US ARMY. They use linux, the latest open source databases and the newest file systems like CEPHS, yet they are years away from public consumption. Well financed companies are buying up the young (phd) experts whom have hack out versions and code that makes CEPH usable. Billions of dollars are being made and it's a real threat to Oracle. Customizations of low level drivers in the latest linux kernel are the key, and much of that work will not even be introduced to the linux kernel community..TOO MUCH MONEY AT STAKE! see above. (and you wonder why Oracle hates linux?) yeah, they really must hate linux. One of the first databases running on it, sponsoring btrfs etc pp. That is hate. What amazes me if that we get any real progress on the kernel at all. not me. Because keeping internal apis backwards compatible for some out-of- tree code is a sure way to go down the drain. They NEVER change user-space APIs and ABIs in incompatible ways. THAT is important. We have to touch our NetBSD and FreeBSD drivers maybe once every 3-4 years. and look how much devices they drive - because nobody has to send their drivers upstream, nobody does. Because embedded BSD, although still viable, does not have mindshare any more. Most do not care. The battle it to spin your version of embedded linux, and sell it to the product manufacturers. and thanks to that mindset BSDs are pretty much stagnant. Think about it.. Often our Linux drivers have to be updated
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Tuesday 27 September 2011 17:52:24 Volker Armin Hemmann wrote: which is your own fucking fault. Get your drivers into the kernel. Problem solved. Does gratuitous obscenity come naturally to you, or do you have to work at it? -- Rgds Peter Linux Counter 5290, 1994-04-23
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Am Montag 26 September 2011, 20:13:53 schrieb Grant Edwards: On 2011-09-26, Michael Mol mike...@gmail.com wrote: On Mon, Sep 26, 2011 at 3:37 PM, pk pete...@coolmail.se wrote: Hi, Happened upon this interview with Linus Torvalds that some of you might find interesting (if you haven't seen it already): http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons -on-Software-Development-Management/ba-p/440 Yeah, I just saw that. Admittedly, when I saw this section: --begin-section-- [...] Breaking the user experience in order to ???fix??? something is a totally broken concept; you cannot do it. That's hilarious. The Linux developers are _constantly_ changing APIs in ways that break existing device driver code. There are repeatedly wholesale re-designs of some APIs that happen between minor versions of a supposedly stable kernel. which is seriously not a problem and does not matter in the slightest. They NEVER change user-space APIs and ABIs in incompatible ways. THAT is important. We have to touch our NetBSD and FreeBSD drivers maybe once every 3-4 years. and look how much devices they drive - because nobody has to send their drivers upstream, nobody does. Often our Linux drivers have to be updated every 3-4 _months_ to keep up with changes in the kernel that break things. which is your own fucking fault. Get your drivers into the kernel. Problem solved. -- #163933
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Am Dienstag 27 September 2011, 04:05:31 schrieb Grant Edwards: On 2011-09-27, Michael Orlitzky mich...@orlitzky.com wrote: On 09/26/11 16:13, Grant Edwards wrote: That's hilarious. The Linux developers are _constantly_ changing APIs in ways that break existing device driver code. There are repeatedly wholesale re-designs of some APIs that happen between minor versions of a supposedly stable kernel. We have to touch our NetBSD and FreeBSD drivers maybe once every 3-4 years. Often our Linux drivers have to be updated every 3-4 _months_ to keep up with changes in the kernel that break things. I suppose one could try to claim that people who ship Linux drivers for their hardware aren't users of the kernel, and therefore our dealing with such breakage isn't a user experience. Contribute your drivers upstream. When the devs change an API, they'll update your code for you. That sounds good, but in practice it doesn't work. 1) The kernel developers don't support any existing customers. Bugs are only fixed for customers who are willing to run the next kernel verison. I've got customers that are still running 2.4 kernels. 2.6.18 is still widely used. Will the kernel developers add new features, support for new hardware, or fix bugs for those customers. Not a chance. so what? There are long term stable kernels with no api changes. Hmm... 2) The kernel developers only make sure that drivers compile. They don't have the hardware or knowlege required to actually test them. One of our drivers _is_ in the kernel. Sure, it builds, but AFAIK, it hasn't actually worked for at least 10 years. and nobody complains on lkml about it - seems that nobody uses your hardware. If something stops working (called a 'regression' btw) it has to be fixed. Linus is very clear about that. Trying to maintain two drivers (one in-kernel and one out-of-kernel) just creates twice as much work for no gain. then don't be outside the kernel. -- #163933
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On 09/27/11 00:05, Grant Edwards wrote: Contribute your drivers upstream. When the devs change an API, they'll update your code for you. That sounds good, but in practice it doesn't work. 1) The kernel developers don't support any existing customers. Bugs are only fixed for customers who are willing to run the next kernel verison. I've got customers that are still running 2.4 kernels. 2.6.18 is still widely used. Will the kernel developers add new features, support for new hardware, or fix bugs for those customers. Not a chance. If your users don't upgrade their kernel, then the API doesn't change, and there's no problem for these customers, right? 2) The kernel developers only make sure that drivers compile. They don't have the hardware or knowlege required to actually test them. One of our drivers _is_ in the kernel. Sure, it builds, but AFAIK, it hasn't actually worked for at least 10 years. Trying to maintain two drivers (one in-kernel and one out-of-kernel) just creates twice as much work for no gain. So (assuming the devs do break your stuff occasionally) you have to test and possibly fix at least one driver whenever the API changes. I see a few options: 1) Test/fix one driver, in-kernel (less work) 2) Test/fix one driver, out-of-kernel (more work) 3) Test/fix two drivers, one in- and one out-of-kernel (most work) In any case, even if I'm wrong about the amount of work involved, it would be nicer for your customers if they didn't have to ask your permission to upgrade the kernel.
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Tue, Sep 27, 2011 at 12:54 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Dienstag 27 September 2011, 04:05:31 schrieb Grant Edwards: That sounds good, but in practice it doesn't work. 1) The kernel developers don't support any existing customers. Bugs are only fixed for customers who are willing to run the next kernel verison. I've got customers that are still running 2.4 kernels. 2.6.18 is still widely used. Will the kernel developers add new features, support for new hardware, or fix bugs for those customers. Not a chance. so what? There are long term stable kernels with no api changes. Hmm... Except they have drivers which are buggy and require backported fixes. 2) The kernel developers only make sure that drivers compile. They don't have the hardware or knowlege required to actually test them. One of our drivers _is_ in the kernel. Sure, it builds, but AFAIK, it hasn't actually worked for at least 10 years. and nobody complains on lkml about it - seems that nobody uses your hardware. Except his customers. Who are going directly to him for support. If something stops working (called a 'regression' btw) it has to be fixed. Linus is very clear about that. That's all well and good, but it doesn't fix things that weren't working correctly in the first place. Upstream kernel doesn't backport fixes, that's what distros and people like Grant, for their customers. And Linus's statement as quoted in that article (and my snippet) doesn't include one important caveat: Sometimes, they drop support for things that either have no maintainer, or are obsolete and difficult to keep. Trying to maintain two drivers (one in-kernel and one out-of-kernel) just creates twice as much work for no gain. then don't be outside the kernel. If we take your position, in this context, to its logical outcome, it sounds like you're saying that distributions like Gentoo, Red Hat and Debian shouldn't maintain older kernels with backported fixes. There exist systems which cannot be upgraded with financial sanity; the existing install works well enough that it would cost more to upgrade. The reasons might be that they're using an old software package which was abandoned, and taking ownership of the code isn't always sane. I was actually approached by someone in my area a couple weeks ago who was in just this kind of scenario. -- :wq
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Mon, Sep 26, 2011 at 9:05 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: SNIP Contribute your drivers upstream. When the devs change an API, they'll update your code for you. That sounds good, but in practice it doesn't work. 1) The kernel developers don't support any existing customers. Bugs are only fixed for customers who are willing to run the next kernel verison. I've got customers that are still running 2.4 kernels. 2.6.18 is still widely used. Will the kernel developers add new features, support for new hardware, or fix bugs for those customers. Not a chance. Grant, Check out the Long Term Stable family of kernels. It's a bit hard right now due to the status of the kernel web site being down/changing. However you can see here at Andi Kleen's blog that he's interested in participation: http://halobates.de/blog/p/38 I know from watching the lkml list over the years that updates to long term stable kernels come out periodically and do include fixes. I don't know about new drivers, but reading Andi's blog it seems he's potentially open to receiving driver updates from folks interested in having the driver included. Hope this helps, Mark
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
Am Dienstag 27 September 2011, 13:07:02 schrieb Michael Mol: On Tue, Sep 27, 2011 at 12:54 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Dienstag 27 September 2011, 04:05:31 schrieb Grant Edwards: That sounds good, but in practice it doesn't work. 1) The kernel developers don't support any existing customers. Bugs are only fixed for customers who are willing to run the next kernel verison. I've got customers that are still running 2.4 kernels. 2.6.18 is still widely used. Will the kernel developers add new features, support for new hardware, or fix bugs for those customers. Not a chance. so what? There are long term stable kernels with no api changes. Hmm... Except they have drivers which are buggy and require backported fixes. and that is the reason stable series exist. They are stable and they backport fixes. Exclusively. 2) The kernel developers only make sure that drivers compile. They don't have the hardware or knowlege required to actually test them. One of our drivers _is_ in the kernel. Sure, it builds, but AFAIK, it hasn't actually worked for at least 10 years. and nobody complains on lkml about it - seems that nobody uses your hardware. Except his customers. Who are going directly to him for support. If something stops working (called a 'regression' btw) it has to be fixed. Linus is very clear about that. That's all well and good, but it doesn't fix things that weren't working correctly in the first place. Upstream kernel doesn't backport fixes, that's what distros and people like Grant, for their customers. wrong, long time stable series do backport fixes. That is the reason they exist in the first place. And Linus's statement as quoted in that article (and my snippet) doesn't include one important caveat: Sometimes, they drop support for things that either have no maintainer, or are obsolete and difficult to keep. and when they do that they warn everybody for years (just look up binary sysctl support as a prime example). Trying to maintain two drivers (one in-kernel and one out-of-kernel) just creates twice as much work for no gain. then don't be outside the kernel. If we take your position, in this context, to its logical outcome, it sounds like you're saying that distributions like Gentoo, Red Hat and Debian shouldn't maintain older kernels with backported fixes. no, but if you decide on one kernel you should use one of the long term supported one. Not 2.6.something-because-I-like-the-number. There exist systems which cannot be upgraded with financial sanity; the existing install works well enough that it would cost more to upgrade. so don't touch the kernel. Wow, that was hard. I think I need something to eat now. Hmmm... noodles The reasons might be that they're using an old software package which was abandoned, and taking ownership of the code isn't always sane. I was actually approached by someone in my area a couple weeks ago who was in just this kind of scenario. and if the system just works - why touch it at all? -- #163933
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Tue, Sep 27, 2011 at 1:22 PM, Volker Armin Hemmann
volkerar...@googlemail.com wrote:
Am Dienstag 27 September 2011, 13:07:02 schrieb Michael Mol:
Except they have drivers which are buggy and require backported fixes.
and that is the reason stable series exist. They are stable and they backport
fixes. Exclusively.
I hadn't even heard of these until Mark's email 20 minutes ago. It's
useful information. You might have saved us some arguing if you'd
presented it more specific and in an explanatory fashion, rather than
dropping a noun and assuming it was specifically known. I assumed you
meant the kernels maintained by distributions. Obviously, I was wrong,
but Mark's email cleared that up for me.
The reasons might be that they're using an old software
package which was abandoned, and taking ownership of the code isn't
always sane. I was actually approached by someone in my area a couple
weeks ago who was in just this kind of scenario.
and if the system just works - why touch it at all?
Because, in this case, the hardware, which is unreplaceable, went tits
up. Meaning it no longer works. It can't be replaced, and they're SOL
until they get the software ported forward. Their remaining hardware
of the same vintage had already died on them, and they didn't have any
migration path or hedge set up.
Other reasons--and this is why I *loathe* unnuanced if it works,
don't touch it mentalities--include security updates and migration
difficulty in the event of *necessity* of upgrades.
I know someone who's running Ubuntu 7.10 on a server that accepts
incoming, public connections--because they got it working, and didn't
even want to update to the Ubuntu 8.04 LTS, because of a if it just
works, why touch it at all? mentality. Eventually, they _will_ be
hacked as a consequence, even if it's just from someone scanning the
public IPv4 space with tools looking for vulnerable versions of
software.
The other general class of cases is something Gentoo users should be
able to understand in the abstract; the longer you go without
updating, the more difficult and expensive (in terms of time fixing
incompatibilities from un{tested,supported} version jumps, at the very
least) it becomes when you no longer have a choice.
--
:wq
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Tue, Sep 27, 2011 at 10:43 AM, Michael Mol mike...@gmail.com wrote: SNIP Because, in this case, the hardware, which is unreplaceable, went tits up. Meaning it no longer works. It can't be replaced, and they're SOL until they get the software ported forward. Their remaining hardware of the same vintage had already died on them, and they didn't have any migration path or hedge set up. Other reasons--and this is why I *loathe* unnuanced if it works, don't touch it mentalities--include security updates and migration difficulty in the event of *necessity* of upgrades. I sympathize with the hardware dieing, but one could argue (IMHO anyway) that that is as much a management problem on their part, or those supporting them, as it is an issue with the kernel. If someone is running a system which is critical and isn't planing for how to get new copies of the system or move forward to new hardware over time, then they are painted into a corner. I can pretty much promise you that one area likely to get LOTS of attention in this kernel series IS security updates, at least if they are kernel based security issues. That a major reason, if not the #1 reason, that this series of kernels exists. HTH, Mark
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Tue, Sep 27, 2011 at 2:24 PM, Mark Knecht markkne...@gmail.com wrote: On Tue, Sep 27, 2011 at 10:43 AM, Michael Mol mike...@gmail.com wrote: SNIP Because, in this case, the hardware, which is unreplaceable, went tits up. Meaning it no longer works. It can't be replaced, and they're SOL until they get the software ported forward. Their remaining hardware of the same vintage had already died on them, and they didn't have any migration path or hedge set up. Other reasons--and this is why I *loathe* unnuanced if it works, don't touch it mentalities--include security updates and migration difficulty in the event of *necessity* of upgrades. I sympathize with the hardware dieing, but one could argue (IMHO anyway) that that is as much a management problem on their part, or those supporting them, as it is an issue with the kernel. If someone is running a system which is critical and isn't planing for how to get new copies of the system or move forward to new hardware over time, then they are painted into a corner. I fully concur. IME, if it ain't broke, don't fix it is a large underlying driver for how people paint themselves into those corners. Management's (and a terribly high number of sysadmins') definition of 'broke' doesn't include 'can I recover if it gets hit by lightning tomorrow?' I can pretty much promise you that one area likely to get LOTS of attention in this kernel series IS security updates, at least if they are kernel based security issues. That a major reason, if not the #1 reason, that this series of kernels exists. And I think that's excellent; I wasn't even aware of them until today. -- :wq
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On Tue, Sep 27, 2011 at 11:33 AM, Michael Mol mike...@gmail.com wrote: On Tue, Sep 27, 2011 at 2:24 PM, Mark Knecht markkne...@gmail.com wrote: SNIP I can pretty much promise you that one area likely to get LOTS of attention in this kernel series IS security updates, at least if they are kernel based security issues. That a major reason, if not the #1 reason, that this series of kernels exists. And I think that's excellent; I wasn't even aware of them until today. I understand you weren't aware so I'm just trying to gently help you and others understand why this series exists. If you read through the requirements for submitting patches to the long term stable series one point is that an identical/similar patch must exist in the development tree. For security issues those are addressed pretty quickly, and as long as the code works in the earlier code it's conceptually pretty easy for someone to get it included in the long term series. Of course, I'm not a developer so I don't know what is _really_ required, but conceptually it's doable. Cheers, Mark
Re: [gentoo-user] Re: Slightly OT but interesting nonetheless...
On 09/26/11 16:13, Grant Edwards wrote: That's hilarious. The Linux developers are _constantly_ changing APIs in ways that break existing device driver code. There are repeatedly wholesale re-designs of some APIs that happen between minor versions of a supposedly stable kernel. We have to touch our NetBSD and FreeBSD drivers maybe once every 3-4 years. Often our Linux drivers have to be updated every 3-4 _months_ to keep up with changes in the kernel that break things. I suppose one could try to claim that people who ship Linux drivers for their hardware aren't users of the kernel, and therefore our dealing with such breakage isn't a user experience. Contribute your drivers upstream. When the devs change an API, they'll update your code for you.
