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!

The compat-wireless dance

At Fedora, our kernels tend to track upstream as much as possible, which sometimes makes for an amusing wireless experience. Here’s a tale, amusing in hindsight, of my three Sony computers, all using the ath9k module.

Firstly acquired is the 15″ Vaio EB I use as a desktop replacement. It works fine with stock drivers — at least, no known problem until today. We’ll get back to it later. Next, the 10.2″ Vaio W netbook. With this the wireless driver would need to be cycled — unload and reload — unless it’s kept active by, say, a continuous ping session.

Now, the EB did not use to work with the experimental compat-wireless drivers — basically the wireless code not yet merged into the Linux kernel; while the W absolutely requires these to avoid the ping keep-alive workaround.

Then comes the 13″ Vaio Y I got on a closing sale — at a nice discount price. Both the EB and the Y need to be on Fedora 15 because of graphics quirks (the former Radeon 5650, the latter Intel Arrandale), but that’s for another article. Everything seems to work fine, until I realized today, attempting to transfer a large-ish (> 100 MB) tarball from the Y to the EB, that the wireless on the Y keeps freezing up if I continuously transmit! It’s not a regression, or not a recent one, since older kernels do that too.

In goes compat-wireless to the rescue, and lo and behold, the transmission now works fine. Only then I find out that now the EB also acts up when it’s downloading at maximum speed. Sigh… funnily, now compat-wireless works fine on it, and fixes the problem.

I don’t even think I want to file bugs on this — different issues on different laptops — I’m just glad the latest wireless code works uniformly well now, and am just waiting for it to land in the mainline kernel.

Good bye del.icio.us, hello Xmarks and Firefox 4!

How fast the wheel turns. Not too long ago, Xmarks‘ public bookmark-syncing service is shutting down, while Yahoo’s Delicious seems reasonably healthy (despite worrying indicators such as lack of support for the more recent Firefox 4 betas, and lackadaisical support for Chrome that, I think, no longer works either). And now the latter is closing — though it’s ironic that you see no official announcement when logging into Delicious, save the news articles and switching guides bookmarked by users!

Now Xmarks is owned by LastPass, and hopefully will be integrated soon with their own offerings — Xmarks’ password-sync is inferior, for instance, and if they offer a unified SSO with LastPass’ multi-factor authentication then that would be wonderful. I carry a Yubikey around these days, with the primary key set for Fedora’s Account System, and the second key set for Yubico’s public server for use with LastPass. If someone were to use a keylogger on a public computer that I use, then by all means; the password they tapped won’t be enough.

These all mean that I’m no longer trapped on Firefox 3, since the other extension without official Firefox 4 support, Greasemonkey, supports it in their nightly builds. Gmail is really annoying to use without Greasemonkey’s Gmail Fixed Font script! Makes one wish that Google integrates its Mail and Groups teams a bit better — Groups’ interface allows switching between fixed-width and propotional fonts for reading, while Gmail only offers it for composing. Sadly Groups’ new beta interface does not even have this feature implemented — ah well, there are three feature requests for it already, hopefully they’ll get it implemented before the new interface goes live.

EDIT – looks like Delicious will survive but will be spun off. Hope it gets taken over by a company that can give it the attention it needs — less laggy FFox support, and proper Chrome, iOS, Android support would be nice. Xmarks works well enough for me that I’ll probably stick with it though.

Android : flashing :: programming : ?

Your editor will confess that he still feels a certain childlike joy at the prospect of reflashing an expensive device that he depends on, possibly bricking it, then painfully restoring all of the settings and discovering all of the new bugs which have been added. It’s the sort of adrenaline experience that others, perhaps, seek through horror movies, bungee jumping, investing in equities, or PHP programming

Jonathan Corbet, The end of the road for the Nexus One, Linux Weekly News

iTunes feed extractor

The downside of Apple’s iPod/iPhone being so popular is that so many podcasts only publish iTunes links, instead of the more standard RSS/Atom feeds. And I know of OS X and Windows users who detest iTunes — imagine how Unix users feel!

Well, the feeds are still there, but hidden from plain sight — turns out, though, that if you pretend to be iTunes, you can actually trick the iTMS server into giving you the raw data. And with Python 2.6’s built-in support for Apple’s property lists, extracting the feed is a trivial matter.
Continue reading

Worrying trend in open-source graphics drivers

It is not so long ago that one could get high-end notebooks with integrated Intel graphics — not the most performant hardware, but with decent[1] open-source drivers directly supported by the manufacturer. Yet when I did a precautionary replacement purchase for my laptop a few months ago, the situation has changed — unless you opt for the business laptops, you either get Intel on the low-end (no Core for you) or AMD/nVidia on the higher end. There are exceptions, but not many. Dell, the company that previously allows you to tweak virtually anything, now does not offer graphics card options for its Studio line-up, at least in Germany. The Sony Vaio E-series, which I purchased, is no longer produced with an Intel card.

Open source drivers for AMD (née ATi) and nVidia cards are improving — and one is grateful for AMD to actually cooperate with open-source developers with documentation and technical help, but at the moment one is caught in a three-way bind: buy Intel and be stuck on the low end (or very limited vendor choices), buy nVidia and get great proprietary drivers and good open source drivers, but supporting the company with the most FLOSS-unfriendly business practices, or buy AMD/ATi and have good-ish proprietary drivers (provided one downgrades one’s Linux install or at least the X components) and so-so (but improving) open source drivers. Being stuck in the latter camp, I was running the open-source Radeon driver, which currently has no DRI support for the Radeon HD 5400 series (no gnome-shell. Not even gthumb, nowadays!) — but then noticed that an older problem might be resurfacing itself — that my graphics card is not being throttled down, contributing to the awful (~ 1 hr) battery life on Linux. That’s about the last straw one can take: my old netbook has snazzier graphics and better battery life[2] than my new notebook!

Going to try the newly-updated proprietary Catalyst driver, coupled with a downgraded X installation from Fedora 12, and see how it goes. Will report my experience here — and recuse myself from submitting X and kernel bug reports until the next version of X comes out and hopefully make the situation less painful.

First time in many, many years using proprietary graphics drivers, but I’m not killing my battery and my hearing (the fans are rather loud) over this.

[1] ports to new APIs tend to introduce periods of instability and performance regressions, but overall the impression is positive
[2] after close to two years, battery capacity just dropped precipitously to ~ 30% of the original, so it’s now getting a new — and higher-capacity — replacement. This is probably the last upgrade — there better be a dual-core, 2 GHz+ netbook out by the time the new battery fails (or a well-supported, affordable ARM smartbook), and it better has SSD options (Dell, what happened to your great Mini 9 SSD deal?)