Herd Immunity Against Online Spying

The Weekly Sift

Can people like us make the NSA’s job harder?

Unlike Senator Lindsey Graham, I’m not “glad” the NSA is hoovering my data into a big database that they pledge (cross their hearts and hope to die) not to access without court authorization and Congressional oversight.

Last time I checked I wasn’t conspiring with terrorists, and off the top of my head I can’t think of any big secrets I’m hiding, but the whole thing just makes me uneasy, given what has happened in the past. The meaning of “terrorist” sometimes gets stretched from jihadist mass murderers to, say, environmentalists who sabotage bulldozers or maybe even Martin Luther King. And while I don’t know how seriously to take Steven Rambam’s claim that it’s “routine” for authorities to log all the cell phones at demonstrations like Occupy Wall Street, I can’t call it unbelievable either.

So, as I said last…

View original post 1,078 more words

Oh, the Windows/Fedora time schizophrenia…

Every other beta test release, my time zone goes askew, thanks to Windows defaulting to keeping the hardware clock at localtime and Linux kernel+userland’s ever shifting way of dealing with this (to be fair, at least they tried – OS X just insisted on the clock being set to UTC).

Right now it seems that systemd expects the kernel to assume the clock was UTC and so it had to do the heavy lifting of adding the 7 hours offset — but somehow the kernel (or some other utility?) has already added those 7 hours, with the result that my clock ended up 14 hours ahead. And somehow this didn’t manifest itself until I booted to Windows to pull some pictures from my Lytro…

Going to try a clean installation first, to reduce the possible things that could go wrong – and help test the new Anaconda installer in advance of the Fedora 18 beta – but if this fails, I’m seriously going to just tell Windows to use UTC (though *that* codepath there is not well tested either, and used to be buggy in Windows XP and Vista).

Update: after a complete reinstall (still using the F17 installer since the pre-beta live image is broken), having verified that on F17 prior to upgrading it works, the same issue still occurs. Bug filed; moving on to more productive endeavors for the rest of the weekend.

Oh, Oracle… (on dates and sane defaults)

An Oracle DATE stores timestamp information as well, with reduced granularity, while a TIMESTAMP also store timestamps. With the result that if you use DATE Oracle’s own SQL Developer tool assumes, by default, that you don’t want the (less accurate) timestamp and default to only showing the date part.

Compare and contrast with PostgreSQL’s sane types and weep. To paraphrase that saying, friends don’t let friends use Oracle products.

Google Music Manager not installable on RPM systems: workaround

Per the subject line, Google’s Music Manager software (used for uploading music to its cloud offering, Google Play Music) is currently not installable on RPM systems, at least Fedora 17 and the pre-release of Fedora 18.

This seems to be either due to changes in Google’s packaging of google-musicmanager-beta, or changes in how strictly RPM validates packages with duplicate directory ownership — as attested by the error message:

Transaction Check Error:
  file /usr/bin from install of google-musicmanager-beta- conflicts with file from
package filesystem-3.1-2.fc18.x86_64

Contacting Google is so far an exercise in futility (they really need to beef up on technical support — anyone who has tried filing Android bugs and feature requests could attest to this):

  • when sending a support request online, the clueless response is from someone who clearly does not understand Linux at all. He suggested I might have a corrupt download
    <facepalm />
  • when sending an email to the address listed in the RPM metadata:
    $ rpm -qpi ./google-musicmanager-beta_current_x86_64.rpm | grep -i packager
    Packager    : Google Music Team <musicmanager-linux@google.com>

    Believe it or not, that email address bounces…

Which leads me to using a workaround:

mkdir -p ${sometempdir}
cd ${sometempdir}
rpm2cpio /path/to/google-musicmanager-betacurrent${arch}.rpm | cpio -vid
mkdir -p opt/google
mv opt/google/musicmanager /opt/google

and then just launching Music Manager manually whenever I need to — probably not worth manually registering the application entry and the cron (scheduler) job also in that package.

If anyone has a contact who does Linux packaging for Google, please forward this to them — thanks!

Important milestone in support for Clojure in Fedora reached

Screenshot of Leiningen 1.7.1, installed from RPM on Fedora 17

It works! A major part of our (Kushal Das and myself) proposed Clojure feature for Fedora 18, the Leiningen build tool used by Clojure project, is now up and running.

After packaging many dependencies, rigging up build scripts, and reporting bugs against other components we depend on (some are not fixed yet but hopefully all the fixes will get applied soon) — now we can turn our attention to packaging real apps. Yeah!

To follow our progress (and chip in — volunteers welcome!), see our progress documentation, with complete links to issues in Fedora’s bug tracker.

Firefox and Thunderbird 13.0, zero installation required*

Now that Mozilla has released version 13 of both Firefox and Thunderbird, it’s high time that I port their relevant 0install interfaces — they were last updated when I was with the OSR group, as the versions packaged in Fedora have been up to date for the past few months.

A simple invocation of

0desktop http://hircus.multics.org/interfaces/2011/firefox-launcher.xml


0desktop http://hircus.multics.org/interfaces/2011/thunderbird.xml

would give you desktop launchers for those two; they will check for updates periodically and you can manually override which version you want to run, out of the ones listed in the feed.

*you’d need to install zeroinstall-injector first, either through your distribution package or by hand.

e.g. on Fedora:

yum install zeroinstall-injector

and on Debian/Ubuntu:

apt-get install zeroinstall-injector