Author: Jared

Posted on

Why Linux?

I’ve acquired a used desktop computer with 6GB RAM, and I’ve been trying to figure out whether to put Linux or Windows 7 on it in the long term. I’d like it to be useful to the whole family.

Windows 7 is great for playing DVDs, Youtube movies, doing Netflix streaming, games, printing to our aging Kodak EasyShare 5100 printer, syncing with my iPod Touch, and it has a fantastic photo screensaver. Some of our favorite applications are available for Windows, but not Linux.

Windows has great parental control software available — via it’s built-in controls, or via third party software. We limit the amount of time our children can be on the computer each day, and we limit the kinds of websites they can visit.

Linux, on the other hand, costs less and supports the sound card and the graphics card better than Windows. And much to my surprise, Linux now supports our Kodak printer (but not its scanner).

There are several Linux distributions available, and I’ve tried Fedora 17 and Ubuntu 12.04 on this machine in their 64 bit variants. Both are well supported by a vibrant community and by commercial companies.

Fedora doesn’t play DVDs, has trouble with some Youtube videos, can’t stream Netflix, doesn’t have parental controls, doesn’t sync with my iPod Touch, and doesn’t even include a screensaver — just a screen blanker (thanks to the unfinished state of its shiny new-and-highly-immature desktop, Gnome 3). It’s possible to rectify many of these limitations, but it takes time to find and configure the software. Netflix streaming isn’t an option. Getting a photo screensaver requires the use of an alternate desktop environment, like KDE or XFCE. In short, Fedora isn’t family desktop ready.

Ubuntu has most of the same limitations as Fedora, but its desktop experience is more polished and the online help is phenomenal. The Ubuntu Software Center not only has application ratings, but can also recommend other apps. Ubuntu automatically told me there were proprietary ATI drivers available, and it was painless to switch to them, with enough improvement in accelerated performance to make it worthwhile. Ubuntu has parental controls in the form of Gnome Nanny, but it doesn’t work with 64 bit Linux, although a web browser extension is an option.

So why do I bother with Linux? It’s an exceedingly useful swiss army knife, runs blazingly fast, and doesn’t slow down over time when software is added. I’m heavily invested in it, and it gives me a technical edge in the workplace. There are thousands of interesting tools that are easy to install — Inkscape, Gimp, meld, Chromium and others. Linux has full featured, freely available development tools for C, C++ and Java — not crippled ones. And it’s multi-user enabled via ssh, remote-X, vncserver, or NX server. Mail servers, web servers and other servers work extremely well. With Linux, it’s easy to see what application or service is slowing down my computer with ‘top’ or ‘iotop’, whereas in Windows, it’s obscured because services run as threads in svchost. I love Linux Live CDs for troubleshooting computer problems, testing hardware and internet connections, and for recovering data from broken Windows installs.

So Linux is great for me as a software developer, but I’m not convinced that Ubuntu, Fedora or any other Linux distribution deserves to be a family desktop environment.

 

Posted on

HTC Vivid with Ice Cream Sandwich

A few weeks ago, I was able to borrow an HTC Vivid. I upgraded it to the latest version of Android: Ice Cream Sandwich. My overall verdict is that I like it, almost as much as iOS 5. Android is more polished than ever before.

Here’s what I like about the HTC Vivid ICS experience:

  1. Bluetooth keyboard support. Android ICS is the first release that supports my bluetooth keyboard, and that’s a killer feature for me. The GMail app is the worst when using the keyboard, because the keyboard suggestions pop up over the top of what I’m typing, which is very annoying. The other apps, including ColorNote, pop up suggestions just above the words that I type.
  2. Smoother Dropbox integration. Apps integrate with it far more easily by sharing files on the filesystem. This means that it’s much easier to keep my password database synced between computers than on my iPod Touch — I don’t have to think about it.
  3. One device instead of three. The Vivid has the functions of my iPod Touch, my Sansa Clip (FM Radio and Ogg Vorbis support), and phone. It’s easier to carry around one device and charge one device instead of three. On the other hand, it has to be charged more frequently than my iPod and my feature phone. The Sansa Clip is better for exercising because it’s so lightweight.
  4. Faster web experience, especially with web pages utilizing heavy JavaScript.
  5. Better web experience. The larger screen makes it easier to read web pages, books and email. Apple’s browser zooms in and out on the correct regions much better using double tap than does Android’s browser. It’s more convenient to watch YouTube videos on a larger screen and a faster CPU.
  6. Much nicer camera than the iPod Touch.
  7. Power usage stats, per application. The screen uses the most power by a wide margin.
  8. Network usage metering and control per app.

Here’s what I like better about iPod Touch:

  1. Apps are all on the desktop by default, instead of buried.
  2. No costly data plan.
  3. Easier to use apps. Most apps that can be found for both devices are easier to use on iOS than on Android, and they usually have more features on iOS.
  4. Better email app than Google’s Gmail app on Android. The Gmail app is too busy, and I haven’t figured out how to mark messages as unread.
  5. I find the iOS keyboard easier to work with.
Posted on

When CTRL-C in gdb shuts down a program insted of interrupting it

According to The Linux Programming Interface, a well-behaved multi-threaded UNIX program should use sigwait() or sigwaitinfo() instead of signal() or sigaction(). A linux-only program could even use signalfd().

Unfortunately, Linux/UNIX programs using sigwait() are hard to interrupt in the debugger. Instead of interrupting the program, it terminates the program. How does one work around this problem? See my answer on stackoverflow.

 

Posted on

Treating work like a race

Chad Fowler, in his book, My Job Went to India, made the following remarks about working effectively:

If you treat your projects like a race, you’ll get to the end a lot faster than if you treat them like a prison cell.

A sense of urgency, even if manufactured, is enough to easily double or triple your productivity.

I’d add that it needs to be an enjoyable race, and that urgency, sustained for too long, can wear a person out. Races are more enjoyable when run with a group of friends.

 

Posted on

Autojump: Faster than ‘cd’

Here’s a cool tool: autojump, written by Joel Schaerer (thanks, Joel). I spend much of my day as a programmer navigating around in the linux filesystem. Built-in tools like ‘pushd’ and ‘popd’ are nice, as are subprocesses — e.g.

 (cd ~/Download && wget http://somewhere.com/path/to/file)

… and when it finishes downloading, I’m still in the directory I was in before the download was started.

Now there’s autojump to add in to the mix. After I ‘cd’ to various directories, later, I can type ‘j Down’ to cd to my Downloads directory. Very convenient. I just wish it were built into every distribution of linux.

Posted on

Linux tty auditing

Since RHEL 5.4, and in recent Fedora releases, it’s possible to audit what users type at their tty (command prompt), thanks to the work of Steve Grubb, a RedHat employee.

Edit /etc/pam.d/system-auth and append the following, but not both:

session required pam\_tty\_audit.so disable=\* enable=root
session required pam\_tty\_audit.so enable=\*

Wait for users to log in and type into a terminal. Later, to see audited tty input, run:

aureport --tty

When a user logs in, the pam module tells the kernel to enable tty auditing for a process and its children. All tty input is logged, but it may not be incredibly easy to read (it includes backspaces, control characters, etc.). I’m unclear as to when and how often the kernel flushes out accumulated tty input to the audit log. The records are identified with a type of TTY in /var/log/audit/audit.log.

In addition to tty auditing, RedHat patched their bash shell so that it neatly audits each and every command line it executes, with a record type of USER\_TTY. It’s prettier to read than raw tty auditing — and it’s easy for a user to bypass by using a shell that doesn’t send its commands to the Linux audit system, like zsh, or a custom-built unpatched bash. Maybe that’s why “aureport –tty” doesn’t show USER\_TTY records.

—-

The Linux auditing system is powerful. It’s possible to write rules that watch for modification to certain files, or that log the use of certain system calls. See the “audit.rules” manpage for more information.

Posted on

Pitfalls of verifying signed jar files

In the Java world, it’s possible to digitally sign a jar file using ‘keytool’ to generate or import a digital signature, and ‘jarsigner’ to do the signing. What isn’t so obvious is that when we use ‘jarsigner’ to verify a signed jar, it doesn’t verify that we trust the signature that signed the file. It simply tells us whether the contents were signed by a public key that was included with the jar file.

Surprisingly, there’s no option to tell jarsigner to check for trusted signatures.

In code, we can use java.util.jar.JarFile to check the validity of a jar file. By default, the constructor to JarFile says we want to check the validity. Code must then iterate through each entry in the JarFile and seek to the end of each input stream, otherwise, the integrity isn’t checked. In other words, the java.util.jar.JarFile doesn’t give us the integrity checking with a simple method call such as isValid(), and it doesn’t give us an easy way to check that we trust the signature that the entries were signed with.

Anyone, anywhere, can create their own certificate, and sign a jar file — so if we want to establish trust for a signed jar, we get to do extra work. On stackoverflow.com, Jarek Przygódzki linked to code that shows how to check for trusted signatures.

I wonder why establishing trust for a signed jar isn’t easier. Could it be that signed jar files originated in the bygone era when we ran Java applets in our web browsers? Did web browsers use their certificate authority database to verify some level of trust for the signature contained in a jar file?

Verifying trust is a delicate issue, as demonstrated by the recently hacked certificate authorities including Diginotar and Comodo. Perhaps it’s a good thing that Java’s libraries and command line tools don’t make it deceptively simple to check jar files based on certificates trusted by Certificate Authorities.

Still, I wish the documentation for jarsigner and JarFile would shed more light on the limits of their default verification. I’d call it “hash checking” or “integrity checking based on hashing”.