Note: There are many sources available which cover patching and upgrading the kernel. It involves downloading patch files or the Linux kernel source code and compiling a new kernel. This is not the best practice to follow on most Linux systems. Most distributions customize the kernel. Any such customizations would be lost if you do a generic kernel upgrade.
Upgrading the kernel on your Debian system can be done easily (kind of) using the the apt package tool to install a "kernel-image" package. The main reason for upgrading a kernel is to support a new piece of hardware or implement some new function. Note that the Debian CDs offer numerous newer kernel packages. If none of the newer kernels on your CDs don't support some new hardware or function, implement the new hardware driver or function by using a loadable module rather than by upgrading your kernel. Loadable modules are discussed on this page.
There is a lot of free software out there that is written for Linux/UNIX that's only available in source code format. As explained on the Basics page, this is the most efficient way for the developers to distribute their software. When you obtain the source code file(s) you compile them to generate an executable binary that's specific to your OS and hardware platform. Knowing how to compile source files is an indispensible skill in the Linux/UNIX world so we'll dedicate a good part of this page to it.
As mentioned on the Packages page, compiling programs can be a frustrating experience. You can run into all kinds of errors due to outdated library files, certain assumptions made by the programmer (which don't hold true on your system), and numerous other causes. Save yourself some grief and use packages whenever possible or at least use pre-compiled binaries if they're available for your particular system. On the bright side, the fact that Debian is distributed with over 14,000 packages you'd be hard-pressed to find something that isn't available as a package. Having said that, if all you can get is the source code, get that and press on.
There's actually two steps involved in generating an executable binary from a source file, compiling and linking. Most programs, whether written for PCs or mainframes, act pretty much the same way. They'll make "calls" to the operating system for specific "services" like "Give me the current date" or "Tell me which user is running this program". It would be a pain if programmers had to write the same code over and over again in every program they wrote to handle these common functions. To address this there are things called "libraries" that contain the code for tons of these routine tasks. Instead of writing the actual code to do a task, programmers simply add references to these library routines (often referred to as "function calls") in the source code of their program. Each of these routines (or "functions") has a unique name, and the programmer uses this name in their reference.
Once a programmer has written the source code for a program, which you may recall from the Basics page is in a human-readable text file format, they "compile" it using a compiler program. Each programming language has its own compiler (or several of them). The compiler program reads the text source code file as input and spits out a binary file called an "object" file. It's merely a binary (machine-readable) version of the programmer's soure code file, complete with those references to library routines.
The next step is called "linking" and it's where those library references are taken care of. The linker is also just another program. It reads in several files, the object file that was generated by the compiler and one or more library files. Every time the linker finds a reference to a library routine in the object file, it reads the library files and finds that routine. It then replaces the programmer's reference with the code for the routine from the library file. After it has replaced all the references with code from the library files the linker then spits out the executable binary file.
continuare...