Letters to the Editor

Readers sound off.
Modules and Mr. Crow

I think your treatment of modules both in your article about 2.0 and in Mr. Crow's article about them is totally wrong. You focus only on memory savings. Mr. Crow even goes so far as to explain that for drivers used permanently, it is better to compile them in the kernel due to the 2K loss per module when they are page-aligned—besides, you lose twelve pages due to kerneld.

Let me answer this first. If you have 20 modules loaded (an unrealistically high number) you lose 40K—add the kerneld and you are still under 100K. Well, what's the matter? This is Linux, not stinking DOS. We have no 640K barrier, and 100K will not cause a noticeable difference in speed (unless you have only 4MB of RAM, but today this is rare).

Consider a beginner using 1.2: he must choose from dozens of boot diskettes the one able to support his hardware. Despite this, the kernel has so many unnecessary drivers that it is 1MB too big (and that WILL make an important difference in speed). And despite being so large, this kernel lacks things he wants, like sound support. So our beginner (still barely able to copy a file) is confronted with the task of compiling a new kernel. It is not so difficult, as we know, but this has an undesirable effect: Linux gets the reputation of being a “hackers only” OS—you can't put it in the hands of a person without some computing experience.

Now consider a (future) 2.0 distribution: only one boot image (well, perhaps half a dozen, if you want to optimize for Pentiums). All the drivers are modules. At installation time, the user answers some questions about his hardware, and the installation procedure builds the config files for kerneld and /etc/rc.d/conf.modules for “permanent modules”. The user reboots and he is running.

Your kernel is perhaps slightly suboptimal, but recompiling is no longer a requisite. That means handling drivers in Linux becomes a lot easier than editing CONFIG.SYS or AUTOEXEC.BAT. Add to this the new package managers, some configuration tools, and a good file manager—with a little hand holding, I now have a hope to rescue my 15-year-old niece from the clutches of the Evil Empire.

—Jean Francois Martinez jfm@sidney.remcomp.fr

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState