Okay, are you remembered if you receive the title of this segment as well, of course?
Tiki, here, welcome to today's episode of Hacker Public Radio.
Today I'm going to give you a short episode telling my experience, custom compiling a Linux
kernel from my computer, which happens to be an AMD Optoron computer, a single core model.
Now, the reason I decided to do this was because the how-to type of documents and podcasts
are bound, such as ones right here at HackerPublicRair.org, as well as ones referred to
us and you can find them easily.
So I thought we'd just two repetitious to tell you how to do it again.
I didn't want to bore you, but I thought instead, you might like to hear my impressions
of what it was like to have gone through the process.
So here goes.
Now, why are that aside to custom compiling Linux kernel?
Well, many reasons are often given about why one should custom compile.
Two common reasons are to learn about Linux internals and to tailor the kernel for your
hardware.
I found that I was drawn to compiling because I wanted to get a quick aboot from my
system.
I thought that I could build a monolithic kernel with all the drivers built in, and
avoid a step-called init RD loading.
What init RD is is, right when you start the computer, it quickly loads your bootload
quickly loads a initial RAM disk image into the system, and that RAM disk image looks around,
it's a version of the kernel, it's a micro Linux system, it looks around and loads the
drivers it needs to load, then it switches to the actual kernel on your hard disk, and
I thought I could build all the drivers built into the hard disk version and skip that
step.
Now without that step, if you're disk needs a driver, you can't switch the disk because
there's no driver for the disk, and that's why that step is there.
So I thought I could shave that time off.
So, what I found out was that I was mistaken about this because my main computer's
hardware uses an Nvidia SATA driver, and I could not work things out so that loading
this as a module could be avoided.
However, I did manage to make a kernel that offered me a feature that I would otherwise
had to do without, so I can say that I will be back to doing this again sometime, as
I like the field of the feature I have discovered.
So what was the learning experience like?
Well, to put it succinctly, it was frustrating, I know, and you want more than that.
Well, the first thing I decided to do was to use the method known as MakeK package, and
have a Debbie and Tool do the work for me.
I wanted to concentrate on the actual kernel, not the process, so I lowered up the tools,
and followed a handy how-to podcast I found on using this a Debbie and Tool.
I began with the X-base configuration tool, and found many interesting things in there,
but after finding my way around, I realized that the logical thing for me to do was to take
the configuration from my distribution stock kernel and modify it, and that was as easy
as copying a file from the slash boot directory to the directory I was working in.
I start by getting out of the generic processor, and specify the processor I know I owned.
I then desolated the compile for best size option, as I did not want to sacrifice any
speed for compactness.
Then I discovered all the things in there I did not need.
I took them out, not only for making better kernel size, but also because each one I removed
this bit of the compiling time. You see, I found that a stock kernel could take like an
hour to compile, removing the stuff I did not need to cut that down to something like
20 minutes compile. It took me about 10 compiles to get a working system going, so you
can see that the time saved was important.
So I took out the things that I didn't need, like dial-up support, and when support, as
I don't use dial-up anymore, and we'll probably never have a T3 line into my own
computer. Then I took out support for all the sound cards, not on my system, as well
as using only the set of this drive of four of my specific chipset. It was relatively
easy, as some of the help files name the module that would be loaded if it was enabled,
and X-term and LSmod, the listmod command, became my best friend for a while, because I
could, LSmod, see what was actually installed, find that module, enable it, and desolate
the other ones. All of these changes resulted in a smaller kernel, as well as a smaller
init RD file. However, there was no speed enhancement, I could find for doing this.
There also was no slow down and speed either. I did have a find feature that did cause
a speed up, and that is a feature that allows the kernel to have more voluntary give-ups
processor control. When it is under load, the X-base configuration did have this
mock as being for desktop environments, and I guess it is because Debian is a server as
well as a desktop, as well as a development platform, that they did not have this feature
as being on. Now while I did not notice any speed ups, I did notice that during my
next backup, which I have automatically scheduled on the cron, that the system was more
responsive. That takes a little explaining. You see speed is how fast things get done. Nothing
was faster. However, while I have a backup running, I tend to launch web browser windows,
open up audio streams from radio stations, check email, stuff like that. Well, when the
system was under the load of a full backup, it would launch quite slowly, and typing
would take longer to show up on the screen. But with the more give-ups feature, the system
would launch just as quickly as if it weren't under load, and the typing speed was always
responsive. So having done this, what is my conclusion? Should everybody compile? I don't think
everybody should try to run a custom kernel. Your favorite distribution security updates
to the kernel package is a huge trade-off. This is different if you make a significant
gain in speed, or a feature you really need, or turning off a feature you don't want.
Else, the educational benefit, just being able to know that you have done it, may make
you want to do this. That concludes this episode of Accomplicer Radio. I hope you enjoyed
it, and I hope you'll turn it tomorrow for yet something completely different. Thank
you.
Thank you for listening to Accomplicer Radio, HBO and Monster by Carol.net.