Jim Hall's article, “It's about the User: Applying Usability in Open-Source Software” in the December 2013 issue, was right on the mark and also applies to custom in-house software used by large companies. I was going to cite a number of examples but decided to keep this “short and sweet”, or should I say “short and sour”. There are plenty of examples, but today, I'm picking on just one, Kompozer.
I used Kompozer on an XP machine, and it did what I wanted to do. So, when I said good-bye to Windows, I wanted Kompozer or an equivalent program on my new Ubuntu 13.1 box.
Try installing Kompozer—I challenge you! The Internet has countless pages of questions and answers representing thousands of wasted hours by people around the globe. After following the step-by-step instructions, using copy and paste so I didn't make a mistake, I still don't have it running.
This is the very sort of thing that has been holding Linux back from becoming
mainstream! It kept me and others that I know from taking the plunge years
ago. All it would take is a few minutes from one
person who knows what they're
doing to package it properly and save thousands of hours of frustration for
Linux users everywhere!
Jim Hall replies: Thanks for your e-mail! You are correct that usability applies both to commercial/proprietary software and to free/open-source software. When you are intimately involved with the development of software, you become so familiar with it and what it does that it's easy to forget that ordinary people with average knowledge need to use the software. Usability means focusing on the users and what they need to do with the software. It's dangerous to assume that everyone will use the software the way you want them to.
Regarding Federico Kereki's article “More Secure SSH” in the
January 2014 issue,
using PAM, how can you lock a user to a directory?
Would it be better to use ChrootDirectory?
I would think PAM would be better, but I am lost at the moment.
I have never configured PAM, but I am interested in it because of this
Federico Kereki replies: I haven't actually used this, but there's a PAM module you could try called pam_chroot. However, I'd also point out that according to some accounts, there might be security problems with it, and jk_chrootsh should be preferred. As I said, I haven't tried this out, but I'll give these two options a whirl; good question, Tony!
Some years ago, I bought and installed a couple door locks with the Z-Wave interface feature, thinking that someday I would integrate them into what we call The Internet of Things. Today, I find that my only option with the manufacturer Schlage is to incorporate its own Web site into the path from lock to PC or smartphone.
Although the salesman offers glowing prospects, he has no way to deal with the contingencies I presented to him that are important failures to avert per my values. Doc Searls and others have been writing about silos for quite some time. Short of reverse-engineering, I see no way to avoid yet another one in my personal life.
This touches many topics actually—for example, security, embedded systems, service interruption, silos and the “biggie”, Internet of Things. I have regaled in some of Docs' successes in beating the lock-in of vendors. While my search for an alternative door-lock vendor is not done, I wonder if a “Silo Beaters Registry” might make good reading? Like open source, it would carry those who are receptive to providing open products of non-software nature—like door locks.
In any case, should Doc or others write more on the silo topic, I present
this example to them through you for their use.
Doc Searls replies: Thanks, Skip. I feel your pain—and I like the idea of a “Silo-Beater's Registry”.
I also would love to hear from other readers about what the qualifications would be. Meanwhile, I'll collect my own thoughts on the matter. Thanks again.
It seems there is a new fork of Bacula that deserves some attention, and I'd love to see LJ do a review if you have room in your queue (www.bareos.org).
Basically, a couple main contributors have forked from just before where Bacula Enterprise code went proprietary.
It isn't currently available via any of the distros other than Gentoo, but the authors do have packaged binaries for the majors.
It's well worth a look, and I'd love to hear what you think!
Very cool! I'll try to check it out, but at the very least, it will appear here for others to check out as well!—Shawn Powers
Recently, a new Linux Journal app was automatically downloaded to my Android phone replacing the existing Linux Journal app. The UI has been improved. I really appreciate this. But there are a few problems:
1) The new app will start, but then refuses to open a previously downloaded issue, unless it has Internet access. I don't think going off-line while reading prevents further reading of the same issue.
2) The new app crashes just after start once in a while.
With the “old” version of the app, I believe I could open downloaded issues without having Internet access. It is quite annoying at the moment, because I'm abroad and thus only connected to the Internet sporadically.
Will you consider bringing back the functionality to start reading while
The app development isn't done in-house, but I'll be sure to get your feedback to the right folks. Thank you for the input; the goal is, of course, to have the most usable, convenient app we can provide.—Shawn Powers
I am writing to your team to request that you please provide more
articles regarding system administration of Linux in future
useful commands, explaining the inet.d or .rc dirs, troubleshooting tips,
slow performance evaluations and best practices configurations. I could go
on, but I think you get the point. I enjoy reading these topics, as it
keeps me abreast of new things and refreshes my memory on others, and I
haven't seen this content in your past issues. Feel free to reach out to
me if you like.
Sysadmin topics are usually pretty popular, and it's one of the reasons we added my “Open-Source Classroom” column. We will continue to have issues that focus specifically on system administration, but I'll try to work some of the topics you mention into my column if nothing else. Thanks for the great ideas!—Shawn Powers
I'm writing about the article “Understanding Caching” published in January 2004, but still available on-line: www.linuxjournal.com/article/7105.
The author begins his article by stating processors have always been faster than memory. It's just plain wrong; early CPUs were slower than memory. Actually memory (SDRAM) density has greatly improved (as much as CPUs), not latencies as much.
1) Princeton Physics Laboratory: w3.pppl.gov/~hammett/comp/bench/bandwidth.html.
Figure 2 in this article: