Herd Immunity Against Online Spying

Posted on by Michel L.

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…

Posted on by Michel L.

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)

Posted on by Michel L.

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

Posted on by Michel L.

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-1.0.43.6722-0.x86_64 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!