Just a quick note to mention how impressed I have been with my current backup solution, Bacula (using an Overland Neo2000 tape library, which also does the job nicely). A basic setup is pretty straightforward, and after that it runs smoothly and with very little need for intervention (other than tape switching. I have yet to find software that will pull the tapes out of the fireproof box for me & put them into the tape library…).
It handles very large filesets well - I need to do a restore of nearly 1TB of data next week, & initial dry run indicates that while it takes a *long* time to build the directory tree (lots of little files in that dataset, which doesn’t help), it will work OK. I understand that more recent versions are quicker (I’m running the version currently available in Debian etch, which is 1.38.11).
Smaller restores happen fast, and the restore interface is pretty usable. (I think there’s a graphical interface available; I use command-line style stuff).
Support is also excellent, with an active mailing list - the developer seems to spend a lot of his time answering questions there very patiently.
Might not be worth the setup time overhead if your backup requirements are small, but definitely well worth it for anything upwards of a couple of machines.
I’ve had software patents on my mind for several years. After listening
to my colleage Allison Randal work on the Artistic License
2.0 for several years, I’ve finally noticed that other updated
OSI-compatible licenses deal with software patents in two ways.
One is an implicit patent grant for receipients of the software. The
other is some form of patent protection for receipients of the software.
(It’s difficult to create a penalty for acting in an anti-social way
regarding patents other than to nullify some portion the license for the
offendor, in which case standard copyright law applies, but it can be an
effective deterrent.)
It’s interesting to compare, for example, the Microsoft Permissive License to the Apache 2.0
License, with regard to software patents.
A complete set of GNOME 2.18 packages have been added to the Vector Linux Extra repository. This means that users of Vector Linux 5.8 Standard or SOHO can add GNOME easily in addition to Xfce or KDE. From the command line a simple
slapt-get --update
slapt-get --install gnomemeta
will add or upgrade roughly 100 packages on your system. Oh, and no, it doesn’t break KDE or Xfce. For those who are a bit command line phobic you can also find the gnomemeta package in gslapt, the graphical package management tool. Previously GNOME was only offfered with the Deluxe (paid for) versions of Vector Linux.
Fair warning: if you don’t have any GNOME bits on your system already doing this install can consume over 900MB in hard disk space. Installing GNOME online is definitely not recommended for those who still have only dial-up internet access.
I’m still not a huge fan of GNOME but I do think choice is good and making it easy to choose from a variety of Linux desktops is a very good thing for Vector Linux.
I ran across a mention of Callgrind in a weblog the other day. “Hm,” I thought. “I should use that to profile Parrot.”
I have a little PIR program that prints “Hello, world!”. I use it for valgrinding Parrot. Profiling Parrot’s startup and shutdown time seemed useful:
$ valgrind --tool=callgrind -v parrot hi.pir
When you do this, run callgrind annnotate on the resulting output file to get a nice report of which functions did the most work. I saw:
20,301,112 PROGRAM TOTALS
3,034,654 ???:dl_new_hash [/lib/ld-2.5.so]
2,985,581 mmd.c:mmd_expand_y [/home/chromatic/dev/parrot/blib/lib/libparrot.so.0.4.12]
2,974,773 ???:do_lookup_x [/lib/ld-2.5.so]
2,652,803 ???:_dl_relocate_object [/lib/ld-2.5.so]
Here’s what happened when I dug into the code.
The third release of Xubuntu, the variant of Ubuntu with the lightweight Xfce desktop, appeared last month. Feisty Fawn (version 7.04) uses the final gold code of Xfce 4.4.0 rather than the release candidates in Edgy Eft (version 6.10) and Dapper Drake (version 6.06). I had very positive experiences with both Edgy and Dapper so I had very high expectations for Xubuntu Feisty Fawn. In some ways the new release does take a step forward but in some truly important areas it took a couple of steps backwards and has been something of a disappointment.
Once again my test bed for Xubuntu has been my four and a half year old Toshiba Satellite 1805-S204 laptop which has a 1 GHz Celeron processor and 512MB of RAM. With this relatively slow processor KDE is sluggish. Xfce is also noticeably faster than a recent release of Gnome when doing significant work. Two Xfce based distributions, Xubuntu and Vector Linux, perform very well on this laptop. I really like Xfce 4.4.x. It strikes the right balance between brisk performance and features. I feel that Xubuntu is a good candidate for newer, more powerful systems as well. Having said that I’m not at all sure that upgrading from Edgy Eft to Feisty Fawn is a terribly good idea while Edgy is still well supported.
One of my users complained today that automount for USB devices wasn’t working on his machine (running Debian etch). I did a little light Googling, & came across this article on the subject.
Which seemed horrendously complicated for something that (surely?) should Just Work out-of-the-box. Hmm. Messed around a bit with the suggestions there, but to no avail.
Further googling produced this blog post which suggested a much more simple solution - add the user to the plugdev group. This worked like a charm. My thanks to Matt!
I note in passing that this is one of the downsides of central auth - the “emergency” local user is automatically added to this group (& also part of the audio group), but Kerberos/LDAP users unsurprisingly aren’t.
Printing in Linux gets better all the time, especially when you find the right drivers.
For those of you who (like me) separate the root partition & user data, and don’t bother backing up the former because it’s a standard install & therefore easy to recreate: note that whilst this is in general true, it may not be in the case of /root.
I at least have a tendency to leave a handful of Useful Scripts there, in particular in the case of server machines. It is annoying to realise that the death of Machine X has also resulted in the loss of the Useful Script you had spent some time developing.
Conclusions I have drawn from this:
1. Back up /root.
2. Consider keeping the Useful Scripts more centrally, even if they are machine-specific in a couple of instances (I do this already with everything else I am not sure why I haven’t thought to do it for these. Some peculiar form of blind spot, evidently.)
In a further relevant note: the rescue mode of the Debian etch SPARC CD works fine, albeit quite slowly. The only real issue is that the cursor fails to show up on any of the screens so choosing the correct option is to some extent a matter of guesswork (most irritating when your guess results in hitting the “Reboot now” option rather than the “Choose another root partition” option). Useful Scripts now safely rescued, however; and backed up.
If you define the problem as “A product 100% binary, bug for bug, compatible with Excel that releases new versions at the same time as Excel” you kinda stop even the hope of migrating someday in the future, because that ain’t possible.
— jmorris2 on LWN’s “A think tank’s view of free software”
Proprietary software companies such as Microsoft have their own source code and they have unencumbered access to read any free software source code they wish—without incurring any legal obligation to distribute their source code. If they truly wanted interoperability, they could pursue it anytime.
From Christopher Blizzard on one laptop per child and open source:
For once Microsoft is getting the reverse Linux laptop experience: little support and little documentation for the hardware. The result will be a platform that doesn’t include any of the really novel features that we’re building in, bad power management, no systems management via the firmware and apps that will randomly crash because they can’t fix the virtual memory problem in the same way we’re approaching it. A second class citizen, to be sure.
A couple of times I’ve encountered problems with the sound card on Debian boxes. Some notes I’ve found that may help others having difficulties:
- Check the permissions on
/dev/dsp, and make sure that the relevant user(s) are in the audio group in /etc/group. You may need to log out & back in again for this to take effect.
- If using the alsa sound daemon, install the
alsa-utils package and run alsaconf. This should pick up your sound card. You may need to run alsamixer to check the volume levels are correctly set afterwards.
- Blindingly Obvious (but easy to overlook) Note: make sure that the volume control on
xmms (or other media player of choice), and on your headphones/speakers is sufficiently up. (I once spent ages prodding at a user’s sound config before realising that the headphones had their own volume control which I hadn’t noticed, and it was all the way down.)
- With KDE, I found recently that to get sound running it was necessary to run the KDE sound control utility, turn off KDE’s sound management and click Apply, close the utility down, reopen it, turn the sound management back on, & click Apply again. Then it worked.
Ten Tec is an American manufacturer of all sorts of radio equipment based in Tennessee. They make a neat little black box which attaches to any PC via a serial port. The box, called the RX-320D, is a shortwave (general coverage) receiver that works very well indeed with performance rivaling more expensive desktop receivers. If you read Ten Tec’s advertising you’d think you need Windows based software to use this radio. Think again.
Hector Peraza has written Linux software which offers the same functionality as the Windows software provided by Ten Tec when you buy an RX-320D. The current version of his rx320 software is version 0.6.2, with source code available on his Sourceforge web page. I’ve used my RX-320D with Mr. Peraza’s code for quite a while now and I’ve been extremely satisfied. I also maintain the rx320 package in the Vector Linux Extra repository. I’ve also built Ubuntu packages which work well under Edgy Eft and should work under Feisty Fawn as well. For some reason my serial port stopped working under Feisty and I need to take the time to do some troubleshooting to find out why.
