Regarding Brian Trapp's interesting article on SSDs [“Solid-State Drives—Get One Already” in the January 2014 issue], there's one thing I would like to know. Mr Trapp should have been more elaborate on this: how does he reconcile his remark on TRIM and RAID setups with this: serverfault.com/questions/508459/implementing-linux-fstrim-on-ssd-with-software-md-raid??
I have a RAID 1 setup running on an SSD, which works perfectly well with
fstrim.
—
jouthuis
Brian Trapp replies: Thanks for your note. My assertion that SSDs, TRIM and RAID are a bad combination was indeed incomplete. Never bet on Linux not having a feature for long!
If you're using hardware-based RAID (using the RAID feature built in to your motherboard's BIOS, a standalone RAID card or a RAID on a NAS device), TRIM support still is probably not going to work. Intel seems to be working hard on the RST chipsets, but check the notes for your specific driver carefully.
On the other hand, if you're using software-based RAID, the picture is much prettier! According to the 3.7 Linux kernel notes (kernelnewbies.org/Linux_3.7, December 2012), TRIM was added to mdadm for modes 0, 1 and 10!
Thanks for the pointer. I'm going to try a RAID 1 on my workstation the first chance I get!
I did a lot of research on SSDs and found “The SSD Endurance
Experiment” by Tech
Report, Geoff Gasior. There are several parts to the report with the last
one on
300TB testing on six SSDs. The results are impressive.
—
Roman
Brian Trapp replies: Thanks for the link Roman! While the 200TB update came out after I had already written the article, it is a good resource for data on how the extreme upper end of write loads affect SSD performance and endurance.
The article “It's about the User: Applying Usability in Open-Source Software” by Jim Hall in the December 2013 issue was fantastic! I work for the US government, and usability is a significant issue that has plagued many of our software projects.
The GNOME Human Interface Guide (HIG) provides on-target usability responsibilities, and I even used it as the foundation for a government software HIG several years ago. While the GNOME HIG is great, it lacks many of the key points made by Jim. Maybe GNOME 3 would have ranked higher in the 2013 Best Desktop Environment category if the HIG had a stronger emphasis on user testing.
Speaking of user testing, I can't figure
out one element of Jim's Gedit test—that is, how do you change the default
font in Gedit?
—
Peter Cook
Jim Hall replies: Thanks for your comments! Your question about how to change the default font highlights a usability issue in Gedit. From my usability test, all participants either were unable to change the default font in Gedit, or they experienced extreme difficulty in doing so.
I conducted my usability test with Fedora 17 and GNOME 3.4, and in that version of Gedit, there was a Preferences menu item under the Edit menu. In the current version of GNOME (3.10), the Preferences menu item is located under the gedit application menu in the top bar. From the Font & Colors tab, you can set the default font for Gedit. See Figures 1 and 2 for screenshots using Fedora 20 and GNOME 3.10.
Figure 1. Gedit Preferences
Figure 2. Font Tab
Jim Hall's article on usability testing in the December 2013 issue was excellent! I have done some of the things he mentions, and one thing in particular is really important: when you have a user struggling during the testing, don't jump in to “fix” it. The problem is not the user; the problem is the program, particularly when a number of people face the same issues.
Another example
I found that agreed with my experience is regarding the use of “hot
corners”.
I have always found that the biggest annoyance, and I cannot imagine it got
in with the help of any usability testing. As an experienced user, I know I
can find the place to turn it off (and I always do), but it exemplifies to
me the problem with software designed by developers for developers. Open
source has a culture that puts the developer at the top of the pyramid,
with users at the bottom, and hot corners is a result. We are at the point
where often the open-source alternative is every bit as functional as the
proprietary software, but cannot get traction because of usability issues.
This is the next frontier for open source if we really want to take over.
And since Microsoft seems to have committed a huge usability blunder with
Windows 8, we have a shot, but only if we can provide an alternative that
is easier for people to use.
—
Kevin O'Brien
Jim Hall responds: While GNOME was not a focus of my usability test, almost every participant experienced problems with the GNOME hot corner. This usually occurred right away in the first task, when testers first tried to use the menus. They would often “overshoot” the menu and activate the hot corner instead. Although testers were able to recover from this pretty quickly, it definitely caused unexpected problems during the test.
During the usability tests, I kept a running log of comments made and actions performed by the participants. When they accidentally activated the GNOME hot corner, participants were immediately confused, asking “What just happened?” or exclaiming “Whoa!” or “Oops!” One user became so frustrated, he started swearing at the computer whenever he hit the hot corner.
I'd like to make 2014 the year of usability in open-source software. Even proprietary software has usability issues (the dramatic change to the Windows 8 desktop is one obvious example), but I want to focus on open-source software. I'm glad you share this enthusiasm! Please bring this energy to your favorite open-source software project to help find and fix usability issues. This will help everyone who uses open-source software, and together we can make Linux even better!
Thanks to Shawn Powers for his “Encrypting Your Cat Photos” article in the January 2014 issue. I'd like to share a solution to a problem I face while working with encrypted volumes in the cloud. The problem is how to automate entering passphrases when accessing encrypted volumes; in my case, access is done from a script, and users cannot be prompted.
I'm using this command to solve the problem:
cryptsetup --key-file $pass_file luksOpen ↪$vol_name my_volume
Before calling it, I copy $pass_file, which contains the passphrase. Then I delete the file.
This is not very secure method. I wonder if there is a better way to do it.
—
Evgeni Stavinov
That is, unfortunately, an issue with encrypting a filesystem. The only solution I know for non-interactive decryption is what you are doing, which is to have a password file. Usually, that's a file stored with protected permissions somewhere on a system, but of course, you see the problem, the password is in a file! I'm not sure how you're copying the password file, but if it were me, I'd temporarily copy the file (with secure permissions of course) to a ramdisk so the file isn't recoverable from the hard disk. There's no great answer I'm aware of, however.—Shawn Powers
