Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Upgrading the kernel...?
- Date: Sun, 30 Jul 2006 17:03:38 +0900
- From: "Stephen J. Turnbull" <stephen@example.com>
- Subject: Re: [tlug] Upgrading the kernel...?
- References: <44CB5808.8070702@example.com>
- Organization: The XEmacs Project
- User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b27 (linux)
>>>>> "Dave" == Dave M G <Dave> writes: Dave> First, isn't 2.6.17 waaayyyy over on the bleeding edge? I've Dave> seen talk of 2.6.16, but this is the first time I've heard Dave> of 2.6.17. No. First, let's talk about the traditional Linux kernel version numbering. I'm not sure what the criterion for major numbering is (# of Torvalds children? floor(sqrt(FreeBSD major version))), but if the major version changes, you're looking at replacing the whole system. However, it's been "2" since 1997 or so, so I wouldn't worry about it. The minor version (the "6" in "2.6") tells you about changes in internal APIs, things like udev or (much older) the proc filesystem. Minor versions come in two flavors, "odd" (as in, "that's odd, I've never seen a 'pink screen' kernel oops before") and "even" (as in "even keel"). There are constraints on what Linus will permit himself in the odd series, but you should not bet a business on it. However, the even series are intended for bugfixes and extensions. The reason that extensions are permitted is that you couldn't use them before, so you can't hurt yourself (in theory) if you refuse to use them now, because the internal APIs aren't permitted to change within the same minor version series. By contrast, "2.7" is the bleeding edge. The micro version (the "17" in "2.6.17") tells you that bugs have been fixed and extensions (eg, new drivers added). "2.6.17" vs. "2.6.18" is unlikely to give your system even a second of indigestion. Recently (with the 2.6 series?) a "nano" version has been added. These are guaranteed to include bugfixes only, I suspect. Dave> Second, people in the bug report talk about upgrading Ubuntu Dave> Dapper to 2.6.17 like it's no big deal. But I don't get Dave> it... aren't a whole bunch of drivers and stuff going to Dave> crap out on me? No. Those drivers that are build into the kernel are, well, built into the kernel and will therefore have to be replaced by the version that comes with the new kernel. The drivers that are loadable modules are stored on disk according to kernel version. If you do "ls /lib/modules" you will see a list of subdirectories that look like kernel versions. That's because they are! Dave> I mean, there's a fundamental I don't understand about Dave> this. I thought Ubuntu Dapper and a 2.6.15 kernel were bound Dave> together. Is it still "Dapper" if I change my kernel? Yes. You could use a 1.0 kernel and (to the extent that things continued to work, which mostly they wouldn't :-) it would still be recognizably Dapper and not Debian "sid" or Gentoo or FC5. The Linux kernel is an amazing accomplishment, and Linus is a certifiable genius. Nevertheless, the system around it, including the GNU System proper as well as the parts that they've shamelessly OEM'ed as "part of the GNU System" (TeX, perl, Ghostscript, X11, GTK+, GNOME, etc) is bigger, and entirely responsible for the "look and feel" (only a few truly WiReD geeks ever talk directly to a kernel). The reason is this acronym "API" (application programming interface) that comes up a lot. Simply put, the API is a set of names for *what should be done*. The programs are various implementations, which may differ internally but should do the same thing. In open source, because everybody does their own thing, we all agree on a large number of APIs to describe the interfaces between our programs. Because the APIs don't change within a minor version, you can expect that working programs will continue to work. Dave> Third, aren't I probably going to simply be changing Dave> headaches? "Possibly", yes. "Probably", no. Dave> It was kind of like this before when I went from Fedora to Dave> CentOS to Ubuntu. Each one did some things better than the Dave> other, but some things worse. With a few exceptions, that will not be true of the kernel upgrade at the micro or nano version level. Things will just get better. The upgrade itself is potentially trouble, but once you succeed in doing that, you will notice very few changes, except that a few things work better than before. But I have a date with my daughter ... see ya later. :-) -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
- Follow-Ups:
- [tlug] Odd/Even Major Revision Numbers (wasRe: Upgrading the kernel...?)
- From: Jim
- Re: [tlug] Upgrading the kernel...?
- From: Josh Glover
- References:
- [tlug] Upgrading the kernel...?
- From: Dave M G
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] Tokyo Missile Command source
- Next by Date: Re: [tlug] Upgrading the kernel...?
- Previous by thread: Re: [tlug] Upgrading the kernel...?
- Next by thread: [tlug] Odd/Even Major Revision Numbers (wasRe: Upgrading the kernel...?)
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links