Recently in SCALE Category

I've taken a few days off from OpenBSD, and in the interim I ran the NetBSD live CD for the first time on the Gateway Solo 1450 (the $0 Laptop). Again, it looks great, but I'm so far from figuring out how to manage the CPU fan in any of the BSDs that I'm not optimistic about running any of them on this laptop. I wish it were different, but until the heavens open and the path forward is made much more clear, I'll stick to desktops (and my old 1999-era Compaq Armada pre-ACPI laptop) for BSD.

During that time, I booted into Debian Lenny on the Gateway and installed 141 updates. Debian Lenny is moving along very quickly. I'm ready to put an Etch install alongside it for comparison's sake during the wait for Ubuntu 8.04 ... which is two months at this writing.

The best text editor for the job: The other day, I needed to do some work at home, and I wasn't having a great time with the Gedit text editor in Lenny. I somehow thought that Gedit had a way to change the case of words, but the Lenny version (Gedit 2.20.4) didn't seem to have it. Was I imagining it, or did the Gedit in Ubuntu 7.10 have this feature? (See below for the answer.)

Anyhow, I need a better editor ... so I went into Synaptic and installed three: Geany, Bluefish and Scite. I'm going to try them all out. So far I can't seem to change the case of letters automatically in Bluefish, but there are so many features that can help with Web development that it's probably worth using. But for the level of work I'm doing, I'm relying on Geany the most at the moment. I haven't used Scite much, but I do plan to give it a try soon.

But ... GEdit does have the ability to change the case of words/letters. Under Edit -- Preferences -- Plugins, there's a Change Case plugin. I enabled it, and now I can change case via the menu with Edit -- Change Case. I prefer to use the keyboard to do this ... so I'll probably keep the other editors in contention.

Foresight Linux: The Foresight Linux booth at SCALE 6X was fairly busy. I could barely get near it during the show, and since I didn't really put 2 and 2 together and remember that Foresight is dedicated to presenting the latest in the GNOME desktop environment, I didn't linger. But I do want to give Foresight a try. It has separate install and live images, so I downloaded the live CD image and am m going to see what it's like.

I'll be your server: I've never set up a server, and all this work with OpenBSD makes me want to roll one myself. I'm going to try to do one on the local network with NFS, Samba, FTP and Apache. I'll probably try in OpenBSD and Debian as well as Damn Small Linux.

Two excellent Linux books: Since I'm not made of money, I got both of these from the library. The "Linux Administration Handbook, " by by Evi Nemeth, Garth Snyder, Trent R. Hein and an army of more recent contributiors, is a hefty tome that's long on advice, Unix/Linux history and what people like to call "best practices."

While much of the book is flying right over my head, and I don't think you could really administer a system without a secondary reference that's specific to the Linux distribution you're using, this is a very valuable book that every serious Linux user should have. Especially when it comes to servers, there's a lot of information here.

"Linux Administration Handbook" is heavy on the philosophy of how to set up and maintain a system, and amid a sea of distro-specific how-tos that expire with every six-month release, that's a good thing to have. Still, what books like "Linux Administration Handbook" make evident is that at one level, most Linux systems are more alike than they are different, and the skills you develop using one distribution are very much transferable to the others. However, there are pointers everywhere in the book to specific instructions for Red Hat/Fedora, Debian/Ubuntu and Suse.

And if you want to see how professional sysadmins (or at least the good ones) go about their work, this is the book to get. It can't be the only book on your Linux shelf, but "Linux Administration Handbook" pairs very well with a doorstop-sized distro-specific how-to (like the "Unleashed" series of books, or Mark Sobell's "Practical" guide series) to help you get a handle on making Linux work for you.

The other book I got from the library, "Linux Administrator Street Smarts: A Real-World Guide to Linux Certification Skills," by Roderick W. Smith, is a great book for anyone who wants to figure out how Linux works from the command line. The book doesn't assume a vast knowledge of Linux or Unix. It offers many tips, instructions, and again, "best practices" on how to configure and manage a Linux system. This book is also not distro-specific; instead, it's one of the best command-line-centered books I've seen when it comes to basic system administration.

I don't know how good "Linux Administrator Street Smarts: A Real-World Guide to Linux Certification Skills," in helping you get actual "certification skills," but it will definitely help with the basics of setting up and maintaining a server or desktop.

Smith's style is clear and concise -- a rarity in these kind of books, which often leave me more confused than not. I definitely recommend taking a look at this "Street Smarts" volume.

So I had two winners here. I would probably buy both of these books, but that said, I still turn to Carla Schroder's "Linux Cookbook," which I'd love to see updated, and Michael Stutz's same-name-but-different "Linux Cookbook," which could use an update even more.

If I was in a buying mood, I'd get a more recent O'Reilly book, "Linux System Administration," by Tom Adelstein and Bill Lubanovic, and I really like Chris Negus' new "Toolbox" series of distro-specific books. They're fairly cheap and filled with good, timely tips, emphasis on the "timely" part. If only all of these great books were updated every couple of years instead of five years ... or never.

Click frequency: The "publish every day at 5 a.m." thing hasn't been working out so well of late. I just haven't had all that much time to do entries in advance, but I have had an entry every day ... just not prewritten to publish at 5 a.m.

One man's FreeBSD: I admire this guy, William Denton, for chronicling eight years of personal use of FreeBSD.

Debian ... ah, Debian: In case it's not evident, I still really enjoy using Debian. While I'm a great believer in the slimmed-down application mix in the default install of Ubuntu (which is based on Debian) -- with less indeed being more, on many levels I've had a whole lot more success with Debian.

I've done the default GNOME install of Debian, the Xfce and KDE installs, a "standard" install to which I've added X, and a few "standard" installs that were console-only. The flexibility of Debian is legendary, as is its stability and usability.

Some of my hardware has been supported better by Ubuntu at times, but I keep coming back to Debian. I'd love for Debian Lenny to support the Alps touchpad as well as Ubuntu Gutsy does. I'm hoping it'll happen before Lenny is frozen, and I will be trying Ubuntu Hardy when it comes out, but I'd love for Linux in general to get everything right for my Gateway laptop.

But since fan management has gotten worse, not better, over the past six months in the Linux kernels I've used, I'm only cautiously optimistic.

Getting my feet wet in OpenBSD has gotten me thinking about how different operating systems handle software updates -- and how important security patches and bug fixes really are.

I'm thinking most of you will say they're very important. If you have a Debian-based Linux system, for instance, there are updates available almost every day, both security- and bug-related.

Live CDs are different. Knopix 5.1.1 has been around a very long time -- over a year at this point -- and plenty of people are using it, even though it's had no update of any kind in that period of time. But live-CD distros like Puppy Linux and Damn Small Linux have a new release every two or three months, and while the developers don't patch every single conceivable thing, I imagine that quite a bit of upgrading is done over the course of, let's say, six months.

OpenBSD, FreeBSD and NetBSD all offer apps in the form of ports, which are source files that you download and compile on your own machine, as well as precompiled binary packages for a variety of architectures (i386, powerpc, sparc, etc.). And the method for updating these ports and packages is something I'm still investigating.

m no expert yet, but I think the bulk of the updating for these BSD systems is done with ports through a CVS server. Taking OpenBSD as an example -- especially because that's what I'm running at the moment -- there are precompiled binaries for OpenBSD 4.2 that haven't changed since the version's release. So if you point to the packages created for OpenBSD 4.2 in your PKG_PATH, you get Firefox 2.0.0.6.

But if you look in snapshots, OpenBSD has a 2.0.0.12 package for Firefox on i386 that was uploaded two days ago.

(A quick check of the NetBSD repository for binary packages yielded Firefox 2.0.0.11, as well as preliminary versions of Firefox 3, for NetBSD 4.0.

So is it better to stick with the 4.2 packages, or to use the newer "snapshot" packages?

I'll give myself the answer: RTFM. While much is the same in the various BSD projects when compared to the hundreds of Linuxes out there, much is different -- and in the service of user choice.

But when it comes to getting the latest versions of ... well, everything, thus far I haven't yet figured out if there's a prebuilt script for updating binary packages en masse in OpenBSD and NetBSD. I know that FreeBSD has an app called freebsd-update that accomplishes this task, and I'm anxious to try it, but I'd like to know if I'm missing a similar utility in NetBSD and OpenBSD, or if the absence of this sort of tool is intentional.

My question: Am I compromising my OpenBSD system by running older precompiled binary apps? Does it really matter?

I'm conditioned by using Debian, Ubuntu and Slackware to expect updates on a continual basis and I wonder if I need to have the same level of vigilance with the BSDs. And should I be using ports instead of packages? While I'm on the subject, here's a way to keep up with new ports for OpenBSD. And here's the listing for Firefox.

Helpful site for OpenBSD: From OpenBSDSupport.org comes this page on how to replace Windows with OpenBSD. While it's based on OpenBSD 3.7 instead of the current 4.2, and that makes some of the information out of date, there are more than a few tips that can be applied to the newer version.

Plugging into OpenBSD: I've just signed up for a bunch of OpenBSD mailing lists, but there's also the OpenBSD Journal to help you keep up with what's going on.

Summing up: So far I'm having a lot of fun looking into the BSD operating systems. I met networking and security instructor, as well as prolific author Dru Lavigne at SCALE 6X, and she's going to send me a copy of her new book, "The Best of FreeBSD Basics," which means I'll be doing some work in FreeBSD in order to evaluate the book. In case you want your own copy, here it is on Amazon.

When users say the documentation is excellent in the BSD operating systems, they're not lying. Besides the excellent handbook/FAQs available for download or online browsing for NetBSD, FreeBSD and OpenBSD, the man pages are way more valuable than I ever though.

In OpenBSD, they're up to date -- and they have plenty of plain language throughout.

I've been looking for the file that enables me to modify the menus in the default fvwm window manager in OpenBSD, and I was having a little trouble. Here's where I went:

$ man fvwm

And besides an exhaustive explanation of every feature in fvwm, the man page told me the exact location of the file: /usr/X11R6/lib/X11/fvwm. (The exact file name in that directory is system.fvwm2rc.) The man page also told me that fvwm looks first for .fvwmrc in the user's home directory and then looks for the systemwide file in /usr/X11R6/lib/X11/fvwm.

I met Dru Lavigne at SCALE 6x: I plan to write more about it in the near future, but I did meet author and BSD expert Dru Lavigne at the FreeBSD/PC-BSD booth at the Southern California Linux Expo on Saturday. We chatted for a good 10 minutes before I found out her name, and I really should've written down more of what we talked about. At any rate, she is a powerful advocate for running any of the BSD operating systems, especially FreeBSD. She has a new book out, "The Best of FreeBSD Basics." Given how smart and well-spoken she is, I have high hopes for the book.

Also at the FreeBSD/PC-BSD booth was Matt Olander, the CTO for iXsystems, the company behind PC-BSD. He also does PR for FreeBSD, the system behind PC-BSD (and DesktopBSD). Like Dru, he's enthusiastic -- and way smarter than I am. Among the things he told me was that the next version of PC-BSD will be a live CD/installer combo -- just like the latest version of the FreeBSD-based DesktopBSD.

Matt also said that while it's early in the process, the teams at PC-BSD and FreeBSD are working together to bring DesktopBSD's graphical ports interface to PC-BSD so users of the latter can make use of ports without using the command line. I don't know whether or not PC-BSD's PBI files -- applications that can be installed with one click -- is something that DesktopBSD will adopt in kind, but it's nice to see these two desktop BSD projects work together to benefit all of their users.

Among the things Matt and I talked about were the inclusion of Sun's ZFS filesystem in FreeBSD 7. And Wikipedia also says that ZFS is coming to NetBSD as well.

Dru, Matt and I talked about more than this. I'll write up the rest in the days ahead.

More BSD: I really like the new "toolbox" series of books by Christopher Negus. Looks like there's going to be one for the three BSD's soon: "BSD UNIX Toolbox: 1000+ Commands for FreeBSD, OpenBSD and NetBSD." Release date is May 12, 2008.

Damn Small Linux won't add just any application to its 50 MB distribution. But when there's a big hue and cry, things that users really need tend to get added. I thanked Robert Shingledecker for adding my favorite lightweight image editor, MtPaint, to DSL, and I'm anxiously awaiting another improvement:

Firefox in DSL will move from the current version 1 to the GTK 1 version of Firefox 2. That's a big deal because a lot of Web sites require at least Firefox 1.5 for full functionality. It means, for one thing that it'll be possible to use Google Docs and Spreadsheets with Damn Small Linux.

Robert has two machines running DSL at the booth. One was that really, really small Sony laptop, on which DSL looked great. The other was one of those great little Damn Small Machine fanless Mini-ITX PC's that are sold at the DSL Store. It had no hard drive. DSL booted off of a USB key, which was then pulled out of its jack.

I really, really want one of these little computers. I'm a huge fan of Mini-ITX and fanless machines in general. They save space as well as energy, and I really enjoy the quiet.

As far as the 3 series of Damn Small Linux, Robert is keeping its development going for at least the near future because it's the version that the Damn Small Linux book is based on.

As far as competition among the smaller-footprint distros go, Robert said there's no bad blood between DSL and Puppy Linux. "We're doing our own thing -- there's no rivalry," he said.

I mentioned the nascent Damn Small BSD project to Robert, and all he would say was that DSL's John Andrews was looking into the situation. I took that to mean they're not ecstatic about another project appropriating the "Damn Small" name.

The highlight of SCALE 6x for me so far has been meeting Robert Shingledecker, whose Damn Small Linux is one of the best distributions out there for hardware that's seen better days.

I won't go into all we talked about, but in the way of news, Robert told me that Damn Small Linux will soo go beyond the 2.4 Linux kernel and put out a release based on 2.6 at some point in the near future. Robert plans to keep the 2.4-based version of DSL going because he foresees continued demand for it, but the newer kernel will be welcome news to many DSL users.

Robert talked a little about replacing Fluxbox with JWM as the main window manager for DSL. One of the reasons was the fact that JWM is smaller than Fluxbox and makes it easier for DSL to stay within its 50 MB size limit. That limit appears to be something that Robert is content to stick with going forward.

I hadn't yet tried DSL 4.2, but Robert showed me how the right-click application menu has come back into the distro, and he explained how the DFM file manager, besides being smaller in size than the ROX-filer, works well -- and shares icons with JWM.