Just a little heads-up:
I’ve been working on an HTML5-based port of the “0x40 Hues of Megumi” flash. Please go ahead and check out 0x40 Hues of HTML5 (working title). Some features are still missing, but I hope to add them in future updates.
I’m hosting the code (MIT licensed) on Github.
After a few glitches where I hit multiple bugs in their image transfer system, I moved this site to DigitalOcean’s new NYC3 site with IPv6 support. So, uh, have at it!
So, when poking around my Documents directory, I found this incomplete short piece of Science Fiction. Might as well share it…
I wake up to find him still sitting at the workbench he’d been hunched over hours ago when I’d given up for the night. He hears the rustle as I search the nearby floor for the cleanest of my uniforms and asks, without turning around, “You awake?”
I am, barely.
I vow: To not delete content. To preserve URLs (or redirect them if all else fails). To keep this site up for as long as I am able. To make sure that the Internet Archive can see my content, in case I fail at any of the above.
All in all, I’m actually quite surprised with how well the adaption of the Ender’s Game novel to the big screen went. There were changes made – but for the most part, they really did make sense. A fairly significant amount of material was dropped, but for the most part it wasn’t really story-critical and mostly served to reduce the amount of character development given to side characters.
(Note that if you haven’t read the novels or seen the movie, the following will contain spoilers; but honestly, who hasn’t read Ender’s Game by now?)
MusicBrainz contributors tend to be quite… thorough sorts of folks. Lets take a look at what I’ve been up to over the course of the past few days.
I’ve worked on a few Picard patches recently, including one that allows tagger script to access metadata from loaded files, and another that saves MusicBrainz track IDs to files. In the interest of giving these a thorough workout, I loaded my entire music library into Picard and went through album-by-album, reviewing the changes that Picard was going to apply and saving if the changes looked good.
Now, it’s been a few months since I’ve last done this, and the metadata in my collection is fairly out of date. There’s a fair number of changes being made to my files, so I’m making a few tweaks as I go – selecting the correct edition of a few albums which have gotten newly added data, and keeping an eye out for any “bad” edits that I may have missed.
Along the way, I notice that one of the CardCaptor Sakura soundtrack albums doesn’t have a catalog number or barcode. “An easy fix!” I think, as I go to look up the release in the MINC database, which is run by the Japanese music industry and has pretty comprehensive details on major label releases from the past 25 years or so.
Naturally, the soundtracks are also missing ISRCs, which I add, and are missing works, which I also add. I manage to finish adding these details to the first 3 CardCaptor Sakura albums before heading off to bed.
Along the way while editing the soundtrack albums, I had noticed that the data for 丹下桜 (Tange Sakura) was a bit of a mess. I had left a tab open on her page to remind me to take a look later – and since it is now later, I take a look. A good place to start when cleaning up an artist is always recording merges. There’s usually a few fairly obvious ones: recordings off pseudo-releases that should be merged with the corresponding ones from the real releases, recordings off compilations that should be merged with the ones from the original releases.
Next I take a quick look at her works page, and… it’s practically empty. (And also has a duplicate, which I go ahead and merge.) So I open up an album in the release editor, and start looking up work info. (For Japanese releases in this genre, cross-referencing Wikipedia, VGMdb, and the MINC database will give very comprehensive information.)
Out of curiosity, I start following links in the MINC database to see what other releases the songs I’m looking at have been released on – and I find out that 丹下桜’s is far, far from complete.
By some time very early in the next morning, I have managed to put something like 1 compilation, 2 albums, and 3 or 4 singles into their rightful place on MusicBrainz, all complete with crosslinked recording and work information.
There hasn’t really been any new revelations on this day. I simply continue to fill in 丹下桜’s discography by following links to see where else particular songs have appeared. By the end of the day, I’ve added another 2 albums, 1 mini-album, 5 singles, and 2 compilations. The number of tabs I have open containing things to look at has been going down steadily – and with each release, I find more and more recordings that I can reuse, or works that are already present in the database. Things are going well!
Perhaps one more day and I can finish adding works to the 4th CardCaptor Sakura soundtrack (and maybe the movie soundtrack and some of the compilations too).
I wonder if I’ll manage to ever finish retagging my music collection in Picard like I had originally intended.
It’s kind of curious that there’s a bit of a ruckus going on with regards to benchmarking accuracy on Windows 8. From what I’ve heard, the actual cause of the inaccuracy is quite simple:
Windows 8 appears to use the processor’s TSC as a timing source on modern processors. There is absolutely nothing wrong with this: it provides a very fast high resolution timing source as long as the TSC on the processor runs constantly and at the same rate. Modern Intel processors set CPUID bits that indicate this to be the case (nonstop_tsc and constant_tsc). Linux has supported using the TSC for timing for several releases, with no issues.
The only catch is that to turn the TSC into a clock source, it has to be calibrated against an external clock. Linux does this once at boot, calculating the value based on the processor’s reported frequency and double-checking against a realtime clock. Presumably Windows 8 does something similar.
The problem with the benchmarks comes in only on overclocked (or underclocked) systems where the clock speed of the processor is changed while the system is running, using for example a utility provided by the motherboard manufacturer. These utilities usually change the base clock rate that the processor is using as a reference. The key point: This changes the speed at which the TSC runs. And the utilities don’t bother telling the operating system to recalibrate the clock; presumably there is no standard API to do so.
So, what can be done? I don’t know. But if motherboard manufacturers want to push in-OS overclocking solutions, they’re presumably going to have to pressure Microsoft into offering an API to tell the Windows timesource to recalibrate the TSC clock, or even just tell Windows to switch to an older, less performant timing mechanism.
So, my site is now looking a little different from how it used to. I’ve actually changed how I’m hosting the service, completely. My original site was on Google Sites via my Google Apps account, but I’ve never really been satisfied with Google Sites and the limited control that was offered. So I took the plunge and got myself a “Droplet” on DigitalOcean, and installed WordPress.
The site may look different, but barring a couple of articles that I haven’t migrated yet (in particular, a couple of my old Anime Tierlist posts are still missing for now), all of the links from my previous site should still be active – either at the same location, or with a redirect. Please let me know if that’s not the case!
For the time being, my old Google Sites page will remain operational, but it will go away once I’m sure all content has been moved here.
Thanks to the Fedora developers, nut does actually ship some unit files for systemd. Unfortunately, those unit files provide a somewhat minimal functionality, with fairly fixed startup order and without taking advantage of systemd’s unit activation features. This caused some problems when I was building my new server a while back. This new machine is quite wicked fast with a quad-core IVB and an SSD—so fast, in fact, that systemd was starting nut’s UPS driver before the UPS itself was probed on the USB bus. As a result, startup failed quite badly, and it didn’t automatically recover.
So, obviously, we have to delay the startup of the nut driver until the USB device has been probed. But what about the other services? As it turns out, nut-server(upsd) and nut-monitor(upsmon) are actually perfectly happy to start up in any order with no more than a few warning messages in the logs as they wait for the other services to become available. So lets simplify the unit files for those. First, /etc/systemd/system/nut-server.service:
[Unit]
Description=Network UPS Tools - power devices information server
[Service]
ExecStart=/usr/sbin/upsd
Type=forking
[Install]
WantedBy=multi-user.targetIf you have configured upsd to listen to a particular network interface or on a particular network address (in upsd.conf) it almost certainly needs the interface to be configured first; you should add in After=network.target.
Now, we can tweak the unit file for the monitoring process: /etc/systemd/system/nut-monitor.service:
[Unit]
Description=Network UPS Tools - power device monitor and shutdown controller
After=nut-server.service
[Service]
ExecStart=/usr/sbin/upsmon
PIDFile=/run/nut/upsmon.pid
Type=forking
[Install]
WantedBy=multi-user.targetI’ve left in the After=nut-server.service for only one reason: To reduce the warning messages in the log output when starting both upsd and upsmon on the same system. It’s not strictly required.
One thing to double-check: Ensure that the nut packages on your system have installed the file /usr/lib/systemd/system-shutdown/nutshutdown. This file doesn’t need any modifications, but it’s required to handle emergency poweroffs and test reboots correctly. It should look something like this, and it must be executable:
#!/bin/sh
/usr/sbin/upsmon -K >/dev/null 2>&1 && /usr/sbin/upsdrvctl shutdownNow for the fun bit; handling starting up the nut driver for the USB UPS automatically once it’s been probed by the kernel. Ideally, we want to make this independent of things like which USB port it happens to be plugged into—this means creating a device file symlink with an appropriate stable name. Lets see what we have available…
# udevadm info --attribute-walk --name /dev/bus/usb/003/003
looking at device '/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.1':
KERNEL=="3-1.1"
SUBSYSTEM=="usb"
DRIVER=="usb"
[...]
ATTR{idVendor}=="051d"
ATTR{quirks}=="0x0"
ATTR{serial}=="4B1111P37995 "
ATTR{version}==" 1.10"
ATTR{urbnum}=="13527"
ATTR{ltm_capable}=="no"
ATTR{manufacturer}=="APC"
ATTR{removable}=="removable"
ATTR{idProduct}=="0002"
ATTR{bDeviceClass}=="00"
ATTR{product}=="Back-UPS ES 550 FW:843.K2 .D USB FW:K2 "
[...]I’ve stripped out a fair bit of the output, but as you can see we have some things to work with. The idVendor and idProduct will identify the device as a UPS, and the serial number will give a nice unique id for this UPS. Lets write a udev rule! I stuck it into the file /etc/udev/rules.d/53-nut-usbups-systemd.rules
ACTION!="add|change", GOTO="nut-usbups-systemd_rules_end"
SUBSYSTEM=="usb_device", GOTO="nut-usbups-systemd_rules_real"
SUBSYSTEM=="usb", GOTO="nut-usbups-systemd_rules_real"
SUBSYSTEM!="usb", GOTO="nut-usbups-systemd_rules_end"
LABEL="nut-usbups-systemd_rules_real"
ATTR{idVendor}=="051d", ATTR{idProduct}=="0002", TAG+="systemd", SYMLINK+="ups/$attr{serial}"
LABEL="nut-usbups-systemd_rules_end"With this, my UPS is now available with device file /dev/ups/4B1111P37995. And since I’ve tagged it with “systemd”, we will be able hook it up to our systemd unit. In order to keep things matching up, I defined the driver in my ups.conf as follows:
[apc]
driver = usbhid-ups
port = auto
serial = "4B1111P37995"Ok, lets go and write the systemd unit file to start up the driver for my “apc” UPS device. I’m going to make use of another cool systemd feature here, template unit files and instances. Create a unit file named nut-driver@.service, with the following content:
[Unit]
Description=Network UPS Tools - power device driver controller
[Service]
ExecStart=/usr/sbin/upsdrvctl start %i
ExecStop=/usr/sbin/upsdrvctl stop %i
Type=forkingSo far, so good! Now here’s the clever bit. Right now, systemd is exposing a unit for the device, but it’s using the name sys-devices-pci0000:00-0000:00:1a.0-usb3-3\x2d1-3\x2d1.1.device which is not only very ugly, but it’s also dependent on the usb path and port probe order. Lets create a unit with our new device name, in the file /etc/systemd/system/dev-ups-4B1111P37995.device:
[Unit]
Description=APC Back-UPS ES 550_FWYou don’t actually need any more in the file; systemd will handle hooking it up to the appropriate real device automatically. But now we can hook up our unit file to be automatically started when the ups becomes available:
# mkdir /etc/systemd/system/dev-ups-4B1111P37995.device.wants
# ln -s ../nut-driver@.service /etc/systemd/system/dev-ups-4B1111P37995.device.wants/nut-driver@apc.serviceNote that in the symlink that was created, I’ve added the string “apc” after the @ sign. When the unit is started, this will be substituted for the %i in the nut-driver@ template unit file. This will cause the upsdrvctl command to look for the driver named “apc” in ups.conf, thus completing the chain and starting the the appropriate driver.
And now my UPS drivers reliably start, even when my computer can boot faster than USB can probe.
The unfortunate part is that a lot of this work is fairly system-specific. I’m not sure that it is all suitable for use in the upstream nut package, due to the customization required. I’d appreciate any comments or thoughts.
This project has actually been around for quite a while now; the name comes from it being a clone of “the old Google Reader”, prior to the removal of the social features. As I mentioned in the introduction, I never actually used those features—so we’ll just see how it goes as a RSS reader application.
Signup is pretty easy—you can just log in through your Google or Facebook accounts. Transferring your feed selection from Google Reader to The Old Reader isn’t as seamless as Feedly, however: You have to export your feeds via Google Takeout and then upload them to The Old Reader.
I’m not off to a great start, though: “There are 35171 users in the import queue ahead of you.” The service has been very heavily hit with the sudden influx of users migrating away from Google Reader. They do load up a Trending feed that lets me go through the user interface immediately:
And, well, it does pretty much exactly what I want. Full article views and show only unread are supported; it even defaults to my preferred ‘oldest first’ on the All Items view.
There are minor quirks, of course. One of the happiest days of my Google Reader usage was when I finally figured out how to hide the sidebar (see the screenshot in the introduction). And The Old Reader brings the sidebar back, in full unremovable glory. I don’t really mind the space lost; the article page is big enough. The real problem is simply that if the mouse cursor is over the sidebar, the scroll-wheel on my mouse won’t scroll the page!
If I could hide the sidebar, The Old Reader would be perfect. As it is, it’s very good. One question is left: will they recover from the influx of Google Reader users and get the feed refreshes back up to speed? I hope they do.