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.

1. Apps are all on the desktop by default, instead of buried.
2. No 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.

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.

struct Object { float first; int second; };

Object scalar = {0.43f, 10}; // One Object, with first=0.43f and second=10 Object anArray[] = {{13.4f, 3}, {43.28f, 29}, {5.934f, 17}}; // An array of three Objects

There’s another example over at stackoverflow.

IBM has published the useful C++0x feature support in GCC 4.5.

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.

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

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.

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=*

aureport --tty

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.

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”.

Compare that to my corporate Windows Laptop. I open the lid and unlock it, wait for corporate anti-virus (I think) to chew through the I/O on my machine for several minutes. Then I can read my email using the unimpressive and slow Lotus Notes (I’d rather be using Thunderbird, Outlook, or speedy mutt).

Or compare to my home Windows Laptop. I open the lid, log in, and am bombarded with requests from several programs to install updates. I just want to check my email, not be attacked with annoying “update me!” windows. I see one from Thunderbird, another from Adobe Flash, another from Mozy and another from Firefox. By the time I’ve upgraded, sometimes I’ve forgotten what I wanted to accomplish in the first place.

Apple has it right with updates for the iPod Touch: They stay out of my way until I want to bother with them, and then they’re all manged together.

Linux has it right: A single package manager updates everything, in one shot, including from third parties.

I’ll continue to use Windows. There are other benefits, even though third-party updates are annoying.