i recently got my first real desktop system — as in: not a thinkpad. it’s an 8 core, 8GB, 1 terabyte system with an nvidia graphics chipset allowing two large displays to be powered: really sweet. installing ubuntu maverick 10.10 from the alternate install CD¹ was simple and straight forward. installing the latest nvidia drivers from the x-updates ppa and running nvidia-xconfig provides the correct configuration for the 1920×1200 display (second display on order and, except for suspend–resume, everything works fine.

the issue with suspend–resume is that the machine goes through the motions of suspending but then just comes back d’oh. googling around for “maverick suspend problem” i stumble over a post in the ubuntu forums citing the maverick release notes —

When the XHCI module is loaded for USB 3.0 operation the system cannot suspend. Manually unloading XHCI will allow suspend to complete normally. To avoid future suspend problems, the workaround is to add SUSPEND_MODULES=”xhci-hcd” to /etc/pm/config.d/unload_module then the system can suspend normally.

— hmph. following those instructions, suspend–resume are working.

one thing i quite like about scala is that ability to run it in “interpreted” mode via the scala command. that allows me — similiar to python or ipython — to experiment and quickly try things out or even test my classes and objects.

what was a bit of a pain was getting the proper classpath constructed so that not only target/classes was picked up but also all the required dependencies. poking a bit around in maven’s plugin documentation i came across the dependency plugin and in particular the dependency:build-classpath mojo, armed with that information i came up with the following rather useful shell script:

save under a convenient name, stir, and enjoy: call this script instead of calling scala directly.

note to self: maven differentiates between installing and deploying a package (which might have been built via a mvn package):

• install — just installs the JAR file and the POM file, if the -DcreateChecksum=true flag is provided it will create the SHA1 for the JAR only
• deploy — install JAR and POM and all necessary meta data along with SHA1s

to install a package to a shared repository a deploy is to be preferred over an install as with an install we’ll get missing checksum errors later in life.

so, this works like this (using the lift-ldap package as an example):

for over a year we’ve been meeting more or less once a month or two over lunch to discuss and chat about all things OpenSim — very creatively volker gässler and i called them OpenSim Zurich Lunches back then when. for the past year we’ve been having lunch at the cafeteria of the IBM Research — Zurich lab, this month’s OpenSim Zurich Lunch will be the first time we meet closer to the downtown zurich area:

• monday, january 25th, 12:30h — 14:00h (approx)
• king’s kurry, freyastrasse 3, zürich (close to the train station wiedikon)

so, if you are around, have time to spare, and are interested to meet up with fellow OpenSim-ers, let volker know by dropping him an email — fe11 at gmx.ch — so that we can reserve enough seats at king’s kurry.

in one of our projects we are using maven to build our web application. part of our build process involves maven resource filtering, in particular, we need to insert path names into resources controlling the build process. since our team uses both linux and windows, we need to be able to generate file: URLs that work irrespective of the underlying platform.

using a construct like

file://${project.build.directory}/path/to/stuff

didn’t really work: on linux the resulting file: URL was usable, on windows it was not: there was a / missing plus all occurences had been escaped.

after trying a couple of variations, i came across the available variables section of the maven documentation which listed project.baseUri — which seemed just the ticket!

alas, it turns out that maven’s resource plugin currently does not know about ${project.baseUri} — doh. yet, not all hope is lost: by adding the following property definition to the project’s pom.xml file did the trick:

instead of ${project.baseUri} we use ${projectBaseUri} in the resource file, which gets translated to the desired file: URL. bingo.

the latest rezzme now contains the necessary code to build debian/ubuntu dpkgs — making it as easy to install rezzme packages on the latest debian/ubuntu systems as it already is for windows and mac OSX machines as the dpkg format allows me to explicitly specify the prerequisites (such as PyQt4).

while working on the dpkg support i also found out that debian/ubuntu has the very useful /etc/firefox-3.0, /etc/firefox-3.5, and /etc/thunderbird directories that allow me to provide package specific javascript to, for example, add a protocol handler for the rezzme: URI scheme. that along with gnome’s gconf tool gives us the same seamless rezzme user experience as on windows or mac OSX — unfortunately, it seems that nothing comparable exists for redhat/fedora based systems.¹

also the windows build code has been cleaned up and the no longer required dependency on setuptools removed.

i just switched over from thunderbird 2 to the new sparkly thunderbird 3 — and i like it very much. particularly the tabbed user interface is quite nice but also lightning 1.0 seems to cope much better with those lotus notes generated calender invites

what did bother me was that i couldn’t find an easy to use function for keyconfig to bind the page left and page right keys (aka F19 and F20) of my X200 keyboard to “previous tab” and “next tab”. after some digging i stumbled across the mozilla thunderbird 3 tabmail page which then allowed me to figure out how to create the code for keyconfig:

[sourcecode language="javascript"] // next tab var windowManager = Components.classes['@mozilla.org/appshell/window-mediator;1']. getService(Components.interfaces.nsIWindowMediator); var winId = windowManager.getMostRecentWindow("mail:3pane"); var tabmail = winId.document.getElementById(‘tabmail’) tabmail.switchToTab((tabmail.tabContainer.selectedIndex + 1) % tabmail.tabInfo.length) [/sourcecode] and [sourcecode language="javascript"] // previous tab var windowManager = Components.classes['@mozilla.org/appshell/window-mediator;1']. getService(Components.interfaces.nsIWindowMediator); var winId = windowManager.getMostRecentWindow("mail:3pane"); var tabmail = winId.document.getElementById(‘tabmail’) tabmail.switchToTab((tabmail.tabContainer.selectedIndex + tabmail.tabInfo.length – 1) % tabmail.tabInfo.length) [/sourcecode]

copy & paste the code snippets and use keyconfig’s “add key” feature to bind the code to whatever key you’d like to use.

i recently switched all my systems from running kubuntu hardy heron 08.04.02 to xubuntu karmic koala 09.10¹ — a rather pleasant switch over. the only thing that was bothering me was the really crappy fonts in firefox and emacs. in firefox, no matter what i configured in firefox itself or in the appearance settings dialog of xubuntu (tried both gnome-control-center and XFCE’s appearance dialog) the fonts would still be blurry and below a certain size unreadable almost. in emacs i was suffering from the blurriness plus humongous menu fonts (i am getting older, i know, but so far i don’t need that large a print, really).

after a lot of research i finally managed to track it down to the following:

1. firefox doesn’t seem to be really interested in what the user’s desktop settings say, the only guy it will listen to is fontconfig configured via /etc/fonts/conf.d!
2. to get rid of the blurry fonts i needed to drop the 10-hinting-{full,medium,slight}.conf from fontconfig’s /etc/fonts.conf.d directory

that fixed the blurry fonts in firefox and emacs.

to get emacs menu’s back to a more sensible size i had to edit $HOME/.emacs.d/gtkrc — changing the default face via M-x customize-face only affected the buffer and modeline fonts but not the menu itself. i’m using the DejaVu Sans fonts, so my gktrc file looks like this:

style "user-font"
{
    font_name="DejaVu Sans 8"
}
widget_class "*" style "user-font"
gtk-font-name="DejaVu Sans 8"

style "default"
{
    font_name="DejaVu Sans 8"
    bg[NORMAL] = { 1.0, 1.0, 1.0 }
}

that one fixed emacs.

sean dague forwarded me this youtube vid:

lol…

…and actually fits quite well to this register story about android going to overtake iDon’t, err, iPhone in 2012.

a colleague of mine in japan contacted us asking whether our in-world collaboration tools could be extended to support japanese characters — he had tried our internal, public sametime 3d servers and had noticed that while in-world chat and instant messaging worked just fine, our flipcharts, brain storming boards, calendar, and voting tools did just display rather boring little rectangles

not good. even worse when it means lost leads. so i set out to investigate. since OpenSim is being used in japan, it was a fair assumption that we might have a font problem here. this was confirmed by a twitter from adamfrisby:

@DrScofield so it should load fine.Only issue you need to be aware of is fonts – you need to use a font with the correct charset availible.

so, first port of call: how are we specifying the font to use for text rendering? digging through the OpenSim source i ended up in the VectorRenderModule:

gulp: we’ve got it hard coded

so, next question: can we change it dynamically? looking through the code, it seems like we might:

except, hmph, there is no osSetFontName() OSSL function

a couple of SMOPs later, we had osSetFontName() and could also configure the default font name in OpenSim.ini, good. now to figure out which linux font would do the trick.

i tried:¹

• Arial — no good: doesn’t have japanese script support
• DejaVu Sans/Serif — again, no good, no japanese script support
• Kochi Mincho — works!

— the configuration for that one is:

[VectorRender]
    font_name = "Kochi Mincho"

my next quest was to see whether i could find a font that would support the whole range: european scripts as well as japanese and also chinese.

…unfortunately, while windows users have Arial Unicode MS there is no such complete beast available to linux users — yes, there are fonts such as bitstream cybit, but their license conditions either don’t allow commercial use or only for a single user. so, if you are running under linux you need to localize your OpenSim installation via OpenSim.ini.

but! at least we figured out how to get japanese character sets supported in OpenSim on linux and can now configure one of our sametime 3d servers to support japanese OpenSim users properly!