free as in beard.

Thoughts on software and all things free and open source.

Archive
Identi.ca / Twitter
Subscribe by Email
Legal information

Code

Aug
25th
Wed

python-websocket - a WebSocket client library for Python

So, have you heard about this WebSocket thing? Apparently it’s the new hotness in web development. It gives you “TCP-like” networking capabilities from within your browser, through a JavaScript API. But sometimes you just want to write a desktop application. Unfortunately, the selection of WebSocket client libraries is quite scarce, and not all of them are compatible with the server implementations since the WebSocket spec has yet to stabilize. I needed a client library for Python, so I wrote one. The protocol itself is quite simple: just a HTTP handshake (with optional cookies), followed by a thin layer on top of TCP. The code is currently lacking proper testing, so I wouldn’t recommend using it for production stuff.

Here’s how to use it:

def my_msg_handler(msg):
  print 'Got "%s"!' % msg

socket = WebSocket('ws://example.com/demo', onmessage=my_msg_handler)
socket.onopen = lambda: socket.send('Hello world!')

try:
  asyncore.loop()
except KeyboardInterrupt:
  socket.close()

Pretty sweet. It tries to mimick the browser API to a T. Now, onto the good stuff:

Source and docs: http://github.com/mtah/python-websocket
License: GPLv3

Tip O’ The Week To Ya! (Customizing GDM 2)

As of GDM 2, customization of the login screen has been severely limited. Here’s a quick (yet surprisingly elegant) hack to change a few aspects of the login screen.

sudo ln -s /usr/share/applications/gnome-appearance-properties.desktop \
/usr/share/gdm/autostart/LoginWindow

Log out. The “Appearance Preferences” dialog will reveal itself on the login screen. Here you can customize the login screen to your liking. Once done, log back in. Now, run

sudo rm /usr/share/gdm/autostart/LoginWindow/gnome-appearance-properties.desktop

to keep the “Appearance Preferences” from appearing on every login. Neat, huh?

Apr
29th
Thu

The annoyance of time in Windows

When it comes to Windows, there are a lot of things to rant about - but right now I’m going to address something that has been bothering me for years: the way Windows deals with time.

Let’s start off by talking legacy. MS-DOS and the early Windows releases treated the hardware clock (also known as the real-time clock, or RTC for short) as if set to local time. When Windows NT eventually came around, the kernel started using UTC internally but to enable users to dual-boot between the old systems and NT, Microsoft stuck with the old way of treating time (with the kernel converting local time to UTC on boot). The same has held true for subsequent NT releases.

So what are the implications? For one, it’s just dumb. UTC is independent, while local time may depend on time of year for certain geographical regions. For me, it means that the RTC needs to be reset twice a year (luckily, Windows can do that for me). Furthermore, consider the problems of having a laptop that frequently travels between timezones, or a remote server on which multiple users each want time to be presented according to their own time zone, and you’ll see why UTC is a better choice for representing hardware time. Bottom line is: the RTC should be absolute, and once set it should never be reset!

While the first implication is not an inconvenience for Windows-only users, it becomes a royal pain for dual-booters. Any sane OS (such as Linux or BSD) consistently works with UTC. Uh oh, now we have two operating systems fighting over what the time should be! This can for instance trigger integrity warnings for some filesystems (such as EXT3) if Windows sets the clock back to a point before the last time that filesystem was mounted.

There is a way to make Windows treat the RTC as UTC though, by enabling the following registry setting:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

However, while doing this I’ve encountered strange bugs. For instance, if the machine goes into suspension, the local clock will reset to UTC once operation is resumed. This was in XP, and I’m not entirely sure if this bug has been fixed in subsequent releases. If it has, it’s about time.