For newer hardware, one might have to use a kernel from testing or unstable so that hardware can be recognized. e. g. I just bought a socket A motherboard with an onboard nvidia ethernet device. 2.6.15 doesn't recognize many of the nvidia pci devices, but 2.6.17 does ( I found out from the knoppix CD).
So, to get internet connectivity, I had to install 2.6.17 on stable. This is really NBD and nothing has broken (yet). I am really interested in the backport option and, clearly, kernels should, and probably are, part of that process. Is there an official web page on the debian site that deals with backports? Art Edwards On Sun, Jul 23, 2006 at 02:38:13AM -0400, Godless Infidel wrote: > On Sunday 23 July 2006 01:49, Kevin Mark wrote: > > On Sun, Jul 23, 2006 at 01:34:42AM -0400, Godless Infidel wrote: > > > Is it true, as I have heard, that you must run "testing" or "unstable" > > > in order to run the recent versions of applications? > > > > Hi $NEW_USER, > > Debian has many streams and each has a goal. Stable is meant to be > > 'released' and has 'release goals' like stabillty and specific features. > > Since it is 'released' about every 18 months, it does not, by > > definition, contain the most recent versions of any software. > > Does it at least contain the most recent versions available at > release-time, or are they so afraid of introducing bugs that they > only use versions that have been out for a while? > > > But people who use it get 'enterprise-ready' and easy to use software. > > If you want something that has more recent versions, you can run testing > > or unstable. But you must deal with the shortcommings those version have: > > they are less well tested, libel to not be 100% installable and have > > changing sets of programs. > > This here is my main concern with unstable. About how much of the > unstable distribution is uninstallable right now? If it's low enough > percentage-wise, I need not worry about how old the software in 'stable' > is. > > > I use unstable, which has the most change, > > but I would not run it on a production server, it is better suited for > > experienced users who dont need enterprise-ready software, not that it > > isn't close to that already. There is one way to use more recent > > versions of some software on stable, that is to use 'backports'. Again > > this is a compromise but one that many make. It takes more recent > > version of important software for servers and recompiles that to work > > with library versions in stable. > > Are you talking about recompiling software outside of the package > manager, or do 'backports' work within the package manager. My > current Red Hat system is so full of such software (outside of > RPM) that there's no longer any point in trying to use RPM. I have a > directory full of the original source tarballs just to keep track > of what's installed and where it went during 'make install'. > > And since the subject of library versions came up, do > you know why new libraries are binary-incompatible with > old ones these days, even for applications that only use > the functions provided by the older library versions? I > remember a time when all you needed was a library with the > right symbols in it. But now, a simple program compiled > against the latest version of glibc won't work with an > older minor revision of glibc, because ld.so checks a > version number that is somehow embedded in the binary. > > > It provides an intermediate solution > > for stable users but it again affect the useability of stable as > > backports introduce a possible source of instability to the 'stable' > > release while giving a bit of improved functionality. > > cheers, > > Kev > > -- > checking for intelligent life... not found > -- The GIMP configure script > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
