12 March 2017

A new Freestyle ...?

A bit of serendipity. Yesterday I noticed that hey, I barely charge my Bluetooth Kinesis Freestyle2 (which I reviewed here) once or twice per year. I duly tweeted about it, and the folks at Kinesis replied saying 4 to 6 months on a single charge is expected, which is awesome.

Then I went to their twitter page to follow their account, and there I discovered that they now have a kickstarter for a new Freestyle model, supposedly built for gamers. This looks awesome, in the sense that it addresses my few issues with the old model: the ability to program and remap keys, real mechanical switches, and backlighting.

It looks like the "first edition" pledges are US-only, but the simple preorders shipping in September are worldwide, so - go support the campaign! I did :)

19 December 2016

On relicensing etiquette

Almost 10 years ago, I wrote a simple throwaway script to migrate book collections from Anobii to Goodreads. Because I thought others could use it, I slapped a MIT license on it and released it. Back then Github was just a fledging startup (I didn't even open an account there before 2010). Later on, Alper Çugun helpfully updated the script and uploaded it to GH, so that more people could use it. Great! People started forking it and tweaking it, as they should. Except...

Uhm. There is one requirement to abide to MIT terms: keep the original copyright assignment. Apart from that, you can rip the code inside out and nobody will care; you can even relicense it to your heart's content (and someone did exactly that, re-releasing it as GPL - unfortunately, he also dropped the original copyright statement). Just leave the original copyright notice somewhere, and you're golden.

I've kindly let "infringers" know that I'd like them to reinstate the original credits -- it's just polite, and anyway everyone can see from GH commit history that they're being silly. Why do people do this? How hard is it to just add your own © line, or keep the original statement buried somewhere? Sometimes I just don't understand People.

18 December 2016

OWC 12-port Thunderbolt2 dock review

As you probably know, recently the Apple world has been rocked by the release of new MacBookPro models. One of the arguments of contention is the drastic switch to USB-C / Thunderbolt 3. Not by coincidence, I've recently decided to finally splurge for a Thunderbolt dock, although a TB2 one; my 2012 MBPr only supports TB1 (the port that looks like a MiniDisplayPort), so anything more would have been a waste of money. Here is a short review for people who might wonder whether this dock is worth the price.

I've dealt with my fair share of no-name Taiwanese stuff in my life, and I didn't want to risk it this time, so I turned to OWC - a very reliable supplier of Apple accessories. Their 12-port Thunderbolt2 hub got some good press, so I went for that. First impression was slightly disappointing - the unit is well built and feels pretty sturdy, but the one I received was scratched on top, and overall looked a bit like an ex-display or returned model. Let's not be "a typical Apple user", I thought, and see how it works before we knock it.

Sure enough, it works pretty well. I went from having all MBP ports occupied, to using one with even more attached devices than before. This is what I connected:

  • External Thunderbolt drive
  • External USB2 drive
  • 4k display (via HDMI)
  • Ethernet
  • headphones
  • two Amazon Kindle
  • gamepad controller

The hub is independently powered, so it can charge devices even when the laptop is shut down. However, it's not magic; there a few trade-offs you should probably be aware of.

The first is that attached Thunderbolt devices inevitably lose a little bit of performance, since bandwidth is shared. This is probably less noticeable if your laptop supports Thunderbolt2, which supports higher speeds, but it's definitely visible with TB1. My external drive saw a 20% loss of speed, from 360 to 300 MB/sec, which is inevitable: now that we're sharing one TB bus among 8 peripherals, the drive can't max it out on its own. It's still very respectable though, and likely a blip if you use TB2 throughout (i.e. MBPr models from 2013 onwards).

The second issue is more disappointing. Having both an HDMI port and one TB/DisplayPort available (the other is used for the actual connection to the laptop), the hub supposedly supports attaching two screens. I first connected my primary monitor to the hub HDMI port; HDMI is the only way to get 4k on the 2012 MBPr. This worked fine, exactly as it did on the actual laptop port. However, as soon as I attached a second screen to the TB port on the hub, the HDMI connection was downgraded to half the native resolution. This did not happen when I had both screens attached to the laptop, so it doesn't seem to be an issue with OSX; rather, the hub must be doing some internal processing over video streams, and must have some sort of ceiling in the amount of pixels it can push down the wire (or something to that effect). In short, I would recommend to only attach one monitor to the hub, if it is a high-res screen.

A similar behaviour appears if your HDMI screen happens to have speakers. Sound quality degrades so massively, it is simply unusable: lagging, skipping, terrible sound all around. It's weird, because the analog headphone jack works perfectly, so it must have something to do (again) with HDMI stream management.

The fourth issue, and the reason I wouldn't be surprised if it turned out this is indeed a returned model, is that the whole hub suffers something like a crash if you use the "high power USB" ports for more than a couple of hours. All attached devices suddenly stop working, and reconnecting the TB cable makes no difference. The couple of times it happened, I had to power-cycle the unit (which does not have a switch, so I had to unplug the mains cord) after disconnecting all non-essential devices, in order to get it back online. I've isolated the issue to the high-powered USB ports, which I used for two Kindle units: if I detach the cables after 20 or 30 minutes, all is fine, but if I leave them there for a few hours, inevitably I'll get a crash. To be on the safe side, I moved my precious TB drive back to the second TB port on the laptop (I simply cannot afford to corrupt that drive), and mostly stopped used those ports.

The last point is not a real problem, just a little gotcha. The headphone jack is analog, but it's not an automatic passthrough. In order to actually use it, you have to go to System Preferences / Sound / Output, and select "USB audio output" as your output device. Quality seems fine, but I'm not an audiophile so I will refrain from commenting further.

Overall, the hub seems to work more or less fine (bar the power-loss scare), and it's very convenient for my setup. Thunderbolt, even in its first incarnation, is an extremely powerful standard, just on the expensive side. I won't be buying a new MBP anytime soon (new models are just not as powerful as I'd like, the British Pound is moribund, and this 2012 model is still rocking), but if you do, you should find the power of TB3/USB-C outweighs the annoyance of migrating to yet another I/O standard.

08 December 2016

Best way to get locale info and localized strings on Python

One area where Windows often beats the Unix tradition is internationalisation. Traditional POSIX interfaces assume there will be One And Only One set of internationalised conventions (display language, date format etc) at runtime, and are mostly concerned with displaying data formatted for that One True Set. When you want something "international" on POSIX, you switch your locale with setlocale() and do your business. This approach unfortunately percolates in Unix-borne tools and languages, in this case Python. There is no "pure-Python" alternative to good ol' GetLocaleInfo, so there is no way to retrieve, say, the French name for January without switching the whole process locale with setlocale(). This is pretty insane and likely dangerous.

Most libraries hack their way around this by packing an arbitrary subset of i18n strings, or just go full-YOLO by switching process locale back and forth. It's a sad state of affairs.

However, there is a better way. The Unicode Consortium, in its infinite wisdom, maintains a big database of localisation metadata, the CLDR. You can either download the full set yourself and parse a bunch of XML files, or you can use the Babel library which basically does it for you.

$> pip install babel
...
$> python
>>> import babel
>>> locale = babel.Locale('fr')
>>> locale.months['format']['wide'][1]
'janvier'

Et voilà.

30 October 2016

On fixing hardware

There is a certain satisfaction in fixing hardware. It can be pretty trivial at times: unscrew a bunch of pieces, replace the broken bit, screw everything back together. The worst that can happen is to end up with one or two screws that don't seem to go anywhere once you put things back.

I recently fixed a Kindle from a few years ago (model D00901, aka "the one with a little keyboard"), and I had exactly this experience, minus the extra screws. I just opened it all up, disconnected the broken screen, replaced it with a new one from eBay (£16), and put it all back together - done. By then I'd already bought a replacement Voyage, but I can now give this to my kids. I was also pretty happy to get this particular model back, because it's much easier to hack than the Voyage (Amazon, wtf? I still can't change screensaver images, in 2016??)

Moral of the story - always try to fix broken hardware. It might save you a few pennies and, in the age of youtube, you don't even have to be an expert to do it.