My cat Toby has kept a tight lid on my productivity until recently by demanding too much attention, but I just discovered a new way to distract him...he is fascinated by the screensaver of the whales, which lets me work on my other Linux workstation. Kudos to the creators of that screensaver.
Mark Kilgard's “atlantis” is part of XScreenSaver, at jwz.org. —Ed.
GNU/Linux has never been about the hardware. GNU/Linux is about FREEdom. The distro that goes on the ULB, and what a user can do with that distro, is more important than the hardware that makes up the box. An effort should be made to use as much Free Software as possible and still be able to do all the desirable things.
At a minimum, the ULB should be able to do all the i-things that a Mac will do, and do them just as easily and well. Web video, Flash, radio, etc., should be as accessible as with a Mac. It should do the basic stuff like easy hookup of scanner and printer, icon mounting and umounting of USB removable drives and hardware. Really good stereo, and home theatre (including ripping DVDs and TiVo ability) seem essential for an Ultimate Box.
And gosh, wouldn't it be nice to be able to handle
personal finance or small business needs, AND be able
to do federal and state taxes? Plus, since Linux is
inherently a server OS, and this box is the ultimate
hardware, it might as well serve half-a-dozen thin
clients so the whole house, or small office, can enjoy
ULB power without the expense of multiple ULB boxes.
—
Eric Skalwold
Software patents keep free systems from supporting all the same audio and video formats that proprietary ones do. But, you'll be happy to know that we used the all-free Fedora for the Ultimate Linux Box this year. —Ed.
I am a new subscriber and I must tell you what an extreme pleasure it is to receive your magazine. I also subscribe to two other computer-related magazines at the present, although LJ is by far the best of them all by light-years.
Unlike most publications, you do not talk down to the readers; rather, you expect them to be beyond hand-holding to the point where they are actually willing to try things and experiment! From my experience with Linux over the past 3–4 years—I didn't know about LJ until recently—it is by taking bits of information I have read and trying things out, modifying things, simply experimenting.
I went from knowing almost nothing about Linux, except the name, to being in charge of a small LAN of about 25 computers running SuSE Linux Professional 9 and Microsoft Windows 2000 Professional, along with a server and backup server both running SuSE 9 as well. I have been constantly amazed at how easy both Linux and Windows clients work together on the network, much better in fact, than when the network was entirely Windows-based. Using a Linux server has also made the network much, much more secure than was possible using only Windows.
I have noticed that most of your program listings are
in languages like Python, Perl, PHP and C. Could you
do an article or two on C++, perhaps on the changes
that would need to be made to a C program you have
listed to make it compile with g++? Or an introduction
to using g++? I think many readers might be new to
programming and would enjoy a brief introduction
to C++.
—
Frank Robinson
Check out the June 2003 issue for a bunch of C++ articles. —Ed.
I enjoyed the article about Yum [LJ, June 2004]. However, yum.conf
is a read-only file. It would have been very helpful
if Mr Bauer had told how to make the file writable.
I am a newbie to Linux and I need all of the input I
can get on the fine points of any process. Yours is
the first Linux magazine I have purchased.
—
Steve Starr
Mick Bauer replies: I'm sorry you experienced difficulty configuring Yum. On my Fedora system, /etc/yum.conf has its permissions set to -rw-r--r--. In other words, it IS writable, but only by root. Nobody but root has any business editing much of anything in /etc to begin with, because it contains system-wide configuration files. Having said all that, maybe I'm overdue to write an introductory article on filesystem security. Thanks for putting the idea into my head!
Because of the regular appearance of photos of children in the Letters
section of Linux Journal, I will not be renewing my subscription. Your
kids are all adorable and all geniuses, no doubt, but this is not the
place.
—
Anonymous
This is a brief note of thanks for the amazing quality of Linux Journal! I must relate to you that when the LJ magazine shows up at my house, all else stops while I browse and read the first article of interest. It seems there is always at least one amazing piece!
I must add that the recent piece on SPF [LJ, May 2004] is a huge contribution to the industry at large. I am sure it will have a major influence for the better on all of us who are nearly totally dependent on e-mail. I found it especially helpful in communicating with the poor souls charged with keeping our network alive.
It used to be Byte, but now LJ rules!
—
Robert W. Carter
I love Marcel Gagnés articles and I love Linux Journal and I love the care you take in editing the magazine to ensure stylistic and orthographic decency. It is with a reluctant keyboard, therefore, that I beg you to fix the French tag in Marcel's column. It should be A vôtre santé, not A vôtre santé. Vôtre is the adjective form; vôtre the pronoun. As vôtre here is modifying santé, it is an adjective. Mille remerciements!
I was a little disappointed with the Arkeia review in the July 2004 issue. Although the perspective of a user new to the product is certainly valuable, a lot of us are herding systems that will stress the software a lot harder.
The number one issue for me right now is that if one scheduled backup job runs long, and the next scheduled job starts, both hang. The support response is that jobs should be scheduled further apart, but this fails to address the issue. In any serious system, there will be occasional overlaps, and the software should cope in some sensible fashion. Either canceling the second job or holding it until the hardware resources were available would be better than a hang. Also, some indication of a problem is not too much to ask.
A related problem is that the software is licensed per server, per client and per simultaneous data stream. If one has eight machines to be backed up, and four streams, the software will back up four machines at a time until all eight are completed. However, a backup job must have at least one stream assigned to it to stay in queue. Thus, when a second job starts, even if it cannot run, it steals a stream from the running backup. If the hang problem ever gets addressed, this is still potentially troubling.
The database structure used by the server to track files and tapes is stored in a filesystem directory tree that mirrors the backed-up data. The software seems to take a significant performance hit in dealing with large numbers of small directories.
Arkeia strongly recommends that non-ark methods be used to back up the root filesystem of the backup server and the Arkeia installation itself.
There are a number of issues with the GUI as well. Mr Wilder covered some of them, and his comments are well taken. Others nits include inconsistent placement of buttons with similar actions in different functions of the GUI, and the fact that the “go back” button is sometimes missing from the function bar (or that in one or two places, the function bar is missing altogether).
The log browser functionality has two frustrating quirks: in viewing the full system log, one sees a calendar month at a time. It's not at first obvious how to change months, which is accomplished by clicking on the text above the log text box naming the displayed month. Said text bears no indication that it's hot. It's also practically guaranteed that one backup per month will be split across two displays. Perhaps displaying the most recent 30 days or so would be more useful.
It seems that users would be better served by a GUI that wasted less
programming effort on flash, in favor of solid function.
—
Dennis Boone
Dan Wilder replies: I am curious as to whether you've looked into Amanda, an open-source backup system we use at Linux Journal. I believe it might address some of the difficulties you mention (www.amanda.org).
There's no GUI, but as I might have implied in the article, my personal opinion is that although a GUI might be useful for selling a backup software package, it is apt to be mostly a distraction for the accomplished user. Amanda configuration is performed entirely by editing text files, and backups are managed from the command line or from cron jobs.
Amanda acts as a scheduler and indexer for dump or tar, so it'll back up nearly anything UNIX-y in nature. Backups are centrally managed from a backup server. Amanda will handle any reasonable number of clients. Environments with many different processor architectures and OSes are not a problem.
There is no native client support for Windows operating systems. SMB shares exported from Windows systems can be backed up, but some attributes may be lost and backups of some files can fail due to share violations.
Amanda has a somewhat novel way of managing backups. You specify the volumes (hosts and their partitions or directories) to be backed up, along with some other constraints, and Amanda schedules the backup levels. Total dumped data volume is balanced from backup run to backup run by mixing levels for different volumes within a run. You wind up making much better use of scarce tape space and runtime, than you could likely do with a fixed schedule of backup levels. When possible, Amanda advances lower-level volume backups to exceed your constraints.
Support is provided by a low-traffic mailing list. Although this support does not offer the almost immediate turnaround I found with Arkeia, most installation questions raised on it get addressed, so long as they're really installation problems and not arguments about the fundamental design or demands for features nobody is likely to implement.
An FTP-like command-line browser is available for doing restorations. As with some other backup software, you're vulnerable if you happen to lose the on-line tape directory. At this point I am not aware of any reasonable way to rebuild the index from tapes. On the other hand, it's easy to locate the index and to make provisions outside of Amanda to keep copies. Indexes are kept in flat files mirroring the host/volume structure of the backup schedule, having one line per dumped file or directory. It is possible this scales better than the directory-mirroring structure you describe.
Some soft failover provision is made by Amanda's use of a holding disk for backups, from which they are streamed to tape. If you provide enough disk storage, an entire backup run can proceed on schedule even when a tape drive fails or when somebody neglects to load the expected tapes. The backup is then flushed to tape after the problem is corrected.
Support for stackers may require some scripting skills, there's almost no support for backing up to anything except tapes, and your first Amanda installation can be painful, as there are lots of ducks that have to be lined up precisely, so to speak. Multiple drives cannot be configured in sequence, so that when a drive is full, the backup simply moves on to the next. Multiple backup runs cannot be written to a single tape. If two runs to the same tape drive overlap, the second simply aborts. On the other hand, there are no license limitations to fret about. Once set up correctly, about the only thing you'll ever do to Amanda is change tapes, restore files and sometimes flush a failed dump to fresh tape.
This e-mail is in regards to the letter “BSD, Please”
in Linux Journal, July 2004. The reader loves BSD for its ports. I thought that I
would bring up Gentoo Linux (gentoo.org), one of the fastest-growing
distros, whose package management system, Portage, is based largely on
BSD's ports. It is a great source-based distro.
—
Nicolas Steinberg
Watch for an article on deploying Gentoo packages in an upcoming issue. —Ed.
I happily submit this photo of my husband Kevin, with his Linux-inspired 25th birthday cake. He is an avid reader of your magazine and user of Linux at home and work.
Photo of the Month gets you a one-year extension for your subscription. Photos to info@linuxjournal.com. —Ed.
The article “RTAI: Real-Time Application Interface”, which appeared in the April 2000 issue of Linux Journal, is missing attribution for a list of issues affecting real-time support in Linux. Attribution should go to “The RTLinux Manifesto” by Victor Yodaiken, which appeared in the proceedings of the 5th Linux Expo in 1999.
