With Linux 2.0 out, commercial vendors are offering new products based on the 2.0 kernel. We want to keep everyone up to date, so we will be reviewing the various distributions. An updated chart (based on the one that appeared in Issue 29 of LJ) and new descriptive text will be made available on the Linux Journal web page at http://www.ssc.com/lj/distable.html.
by Phil Hughes and Jonathan Gross
The first distribution made available with the 2.0 kernel was Debian, and thus it is the first we will review. We would like to thank iConnect for making the CD available to us. iConnect's web page is located at http://www.i-connect.net/i-connect/services/cdrom.html.
From the Debian FAQ:
Debian GNU/Linux is the result of a volunteer effort to create a free, high-quality Unix-compatible operating system, complete with a suite of applications. The idea of a free Unix-like system originates from the GNU project, and many of the applications that make Debian GNU/Linux so useful were developed by the GNU project. Debian was created by Ian Murdock in 1993, initially under the sponsorship of the Free Software Foundation's GNU project. Today, Debian's developers think of it as a direct descendent of the GNU project.
Enter. Enter. Enter. Enter. Enter. Enter. You could pretty much train a chicken to install Debian: “Peck the enter key. Wait....okay, peck enter again...wait...okay, now peck enter...” I had time to think about this as I was installing Debian for the first time on an old 386 with no math co-processor. By the time I had installed it on my P60, I had an entire training session for my chickens, with plans to take over entire networks. (“Now it's upgrade time! Select FTP from the Access menu and peck enter....now peck enter again...”)
Debian installation begins with a set of floppies. I needed six: a base system spans three of them, a root, a boot and a sixth to make a backup boot disk.
The base system is installed, and from there, you go through the package selection process.
I've installed a fair number of Linux distributions, built a couple from scratch (no chicken pun intended) and bollixed up more than one installation—Slackware, Red Hat, SLS (shudder) and others. I've noticed that one of the things I do that causes problems is deciding to not install package foobar. It's big, I don't like the package name, the version number is 13, so I don't install it. Then I run Idependonfoobar, and it complains, “...can't find library libfoobar.” Phooey. So I waste a lot of time only to discover that the packages I left out contain files that other programs depend on.
Debian solves this problem for me, or at least warns me that I am making a mistake. Debian's package dependencies are very, very cool, and will be discussed at length.
Installation was self-explanatory until I came to the package selection screens, where I stumbled a bit, forging ahead without any documentation. I found I had to rethink my chicken training regime. The selection process reminds me of reading mail with trn: there are a couple of different screens that do different things, and a slew of keyboard controls for doing them. Is this part of the cost of having dependencies? I don't know, but I think that part could have been clearer. Once you figure out how things work, it is very helpful, but it is certainly not intuitive, like the rest of the installation.
For example: I decided not to install Tex. It's big, and I would rather have used that disk space for my large collection of gifs. So I left Tex unselected. Later, I chose apsfilter, a print filter that needs dvips to work its magic. Debian's package selection tool, dselect, told me that apsfilter depends, among other things, on dvips. That's cool. But even cooler is the fact that all these dependencies are presented in a list form that allows me to select packages from the list during the install, solving the dependency problems as they arise and without losing my place in the installation. Very cool.
Another example: I initially chose the Debian default mail transfer agent, smail, but then decided I really wanted sendmail in all its glory. I went back into dselect, and selected sendmail.
dselect complained that smail conflicted with sendmail, but I ignored it and tried to install it anyway. deselect wouldn't do it because of the conflicts with smail. You may consider it a blessing or a curse when software makes decisions like this for you. I admit it was slightly irritating that deselect wouldn't let me hang myself. Nevertheless, this sort of thing prevents damage to innocent hardware when people cannot get their new systems to work because of software conflicts and heave the machines out windows.
When I went back and heeded the warning messages, deselected (dselected?) smail, and tried again, smail was removed, and sendmail was installed and configured. During installation, you are prompted to configure sendmail to send mail to a hub, or run as a host. This option is nice for people who have simple mail needs.
Another of the best features of this distribution is the upgrade method—truly the most impressive feature of Debian. After you have the system basics installed and running, you can fire up dselect and do upgrades to your system. If you are connected to the Internet, you can do this via FTP. dselect allows you to select where you are getting your new packages—so you point it at ftp.debian.org. The upgrade acts just like the installation, the system updates the packages database, and gets all the newest packages from the FTP site, and continues with the install.
No more guessing which parts of the distribution you need to upgrade to run the new version of foobar—you just point dselect at the Debian FTP site and let the system worry about it—this is what computers are for—keeping track of all the “this package depends on this stuff, and you'll need to get the new version of blah-blah-blah.” Debian does all that for you—very impressive.
Debian allows you to install (and update) from CD-ROM, NFS, hard drive, previously mounted partition, floppy, or via FTP. I installed from the CD-ROM obtained from iConnect.
However, there are problems with the system. Apparently the installation procedure doesn't install LILO correctly. Unless you run LILO by hand before rebooting, it won't re-boot from the hard drive at all, even if you told the installation scripts that was what you wanted. Also, the modules do not load into the kernel. All these problems need to be dealt with before Debian is ready for the Big Time.
I also tried to get and install the kernel sources for 2.0.6 (the latest package as of this writing). The kernel building procedure is a little different for Debian than for other distributions, and I still don't have it working properly. The kernel builds, then some scripts run to make sure that if you upgrade your kernel packages, you don't overwrite your custom kernel configuration. These scripts don't seem to work correctly—the kernel building procedure aborted and I had to finish it manually, which is not a big deal if you know what you are doing. But these bugs are not trivial and should be fixed (and may be, by the time this article is printed).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SourceClear Open
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide