Screentime Gotchas

Screentime is the de-facto standard for turning flash content into screensavers. It was painful 7 years ago, and it's still painful now.

• Screentime's AS3 support is broken right now. Specifically, checking existence of files and/or copying files always returns true, regardless of what actually happened. AS2 works fine though.
• When using stringWrite, on OSX, you must supply the full path to the file being written.
• Permissions behave a bit weirdly. When including, say, a config file, the Windows installation won't allow you to write to the file, but the OSX version will. You can get around this by supplying a default config, reading from that, and then writing it in the Win version - the newly created file then has all the permissions you'd want.
• Opening a URL from a Win screensaver creates a security loophole. If the user has checked the "on resume, display the logon screen"(or whatever), the box should basically be locked, but if you open a page in the browser, you're able to browse the machine. Using getSecurityMode() clears this up - it can tell you whether the box is checked or not, and you can behave accordingly.
• Screentime have drunk some sort of asynchrony cool-aid. I'm pretty sure this is implemented with speed and all that in mind, but having to use registerCallBack() for everything - even detecting the security mode means that I have to chain stuff together, which is brittle.

Postgres and Fsync

After an upgrade to a server I sometimes help out with, the perl script responsible for importing about 300 000 records into a Postgres database went from taking 2.5 to 6 hours.

Not overly fond of reworking things that aren't broken, I decided not to tweak the scripts to use COPY instead of the usual massive, bulky number of INSERTs... There had to be some bottle-neck somewhere...

Ultimately, checking out the warning logs pointed me to setting the fsync setting in postgres to "off"  - which made things tons better. Sure things won't work nicely if there's an OS or hardware freak-out, but if that happens, the state of the database will pretty much be the least of my problems.

Time taken to import those records now: 1.5 hours. I'm pretty convinced I'm missing something else subtle out here, but such a performance gain for so little effort is worth a few words here.

http://www.postgresql.org/docs/8.1/interactive/runtime-config-wal.html provides some more info.