cobbler

A headache for most network administrators or engineers setting up labs is the installation process of numerous servers and systems. With Fedora, PXE-installation and kickstart files takes some of the manual challenges out of the process, but it is still fairly task intensive.

Cobbler takes care of this issue and does it in style (Cobbler is an install server; batteries not included). It automates several of the tasks so that user doesn't end up switching between commands and applications when building new systems.

I personally liked a feature that I didn't think the system would have. One of the systems I was setting up did not have the BIOS updated to be able to do a PXE install. Cobbler has an option to create an installable CD/DVD and your system matches the rest that you have installed doing the automated PXE-install.

Fairly useful for organizations running a Linux servers network.

tips for baby steps in kernel debugging

Even if you have been a programming in C for a while, getting into kernel debugging can be intimidating. If you are used to c-tags or using an IDE for your development, the task is even more challenging. However, a few tools listed below help you get started very quickly:

Obviously the first step is getting the kernel, and depending on what kernel you are running and/or what Linux distribution you have, this can be tricky. For Fedora systems, there are simple ways to get the kernel source.

LXR - Linux Cross Reference
This is a very useful resource if you want to get a quick idea about the flow of code, structures. LXR is a toolset that has the entire kernel source indexed. It's an Ajax interface and makes it very easy to browse source code.

printk()
This is the printf of the kernel. The syntax is similar to printf. The useful argument is the loglevels that can attach a level of importance to your messages. The definition of the loglevels are in include/linux/kernel.h

dump_stack()
Sometimes, tracking the code flow is easier if you can show the program stack. Most architectures have dump_stack() implemented. This can be a very useful weapon in a newbie kernel debugger's arsenal.

There are some good tutorials that do some hand-holding for writing kernel modules, but if you have to track an issue in the core kernel or just want to get a better understanding, the tools described above are very useful.

Go on, get your feet wet in kernel debugging.

handling the cross-compiling nightmare

If you have ever faced the challenge of running your code on different platforms with need to support different system libs (glibc/uClibc), you probably know it's not a simple task building the toolchains. Very simplistically, a toolchain is what makes up the tools that compile, assemble and link the code being developed.

For this case, crosstool-NG comes to your rescue. It's a versatile toolchain generator that is very simple to configure. You simply fill in the appropriate values with the adequate options in a configuration file. Then point your compiler option in the Makefiles to the right compiler.

There is a decent tutorial on how to use crosstool-NG here, but it has not been updated for the newer releases. The current release is version 1.5.2.

linux in msft search

I read about this somewhere else, but I had to try it out myself...

The first two links in Microsoft Search when looking for Linux is "how to remove Linux". Elegant.

you have to be kidding me with Vista

I am not one to rant, and certainly not one to not appreciate the complications with building an operating system.

But, you have got to be kidding me with the Vista crap. I have been using it on a work laptop (was provided with it) since about a week and I have had my laptop actually CRASH (blue screen) after plugging-in and unplugging a usb mouse, my usb cell phone and after trying to wake up after hibernating.

Oh, and unless I enable "sending of null packets to keep session active" and enable TCP keepalives in my putty sessions, I get "Network error: Software caused connection abort" every few minutes.

People pay to buy this crap?

Okay, rant over.

final sign on the "road to 64-bit"

I wrote about switching to 64-bit Ubuntu a few days ago.

Then I added an update a few days later with more information.

The major conclusion there was that if you have > 3GB RAM, unless you are using a customized kernel or the 64-bit Ubuntu, you are not going to be able to use more than 3GB RAM.

Anyways, not that I needed more convincing, but tuxradar has a damn good write-up with performance numbers comparing Ubuntu 9.04 with 32-bit and 64-bit version:

Ubuntu 9.04 32-bit v/s 64-bit performance numbers

I think this conclusion summarizes it nicely -
"Putting aside the issue of Flash for a moment, moving from 32-bit to 64-bit is pretty much painless. In fact, you can't tell the difference without running uname -a in a terminal - all the programs you're used to are likely to run identically, and ultimately it's only a matter of time before x86-64 becomes the standard."

There is no turning back, I am convinced 64-bit is the way to go.

update on "the road to 64-bit"

A couple of days ago, I wrote about moving to 64-bit ; seems like it's going to be a simple decision for me.

A 32-bit operating system is limited to 4 GB of memory ( you can only reference 2 ^ 32 = 4GB ). However, 32-bit Ubuntu is limited to 3 GB. If you are considering between 32-bit and 64-bit Ubuntu and you have more than 3 GB of memory that should be a simple decision.

There is a workaround however if you are still not convinced 64-bit is the way to go - install server kernel as it has support for upto 4 GB. But think about the future when your 4GB will not be enough and you add more memory?

There is a bug (=4GB memory">Bug 74179) that covers releasing a 32 bit option for high memory ( > 3 GB) system.

kerneltrap.org has a good page on kernel and high memory with a good explanation of physical memory versus virtual memory.