My co-worker is thinking of holding a small Wii party while at OLS (pending the outcome of trying to connect the Wii to the hotel's TV system). If you still haven't left home and want to join, grab your wii-mote -- she only has one -- and your favourite game, as her selection is limited. You guys can connect via twitter @nanananini -- I'm probably too old and decrepit to join in the festivities. :)
Entrance fee is beer, I'm told. :)
Tuesday, July 22, 2008
Monday, July 21, 2008
New camera!
Ste-Anne-de-Bellevue
Originally uploaded by mricon
The camera is nothing fancy -- a JVC Everio, which is a MPEG2 camera with a 30G internal HDD. It also supports micro-SD, but I don't have any of those lying around. Since it was a spur-of-the-moment purchase, I got it with my fingers crossed -- hoping that it will work with Fedora without too many glitches. Video is something I haven't yet had a chance to work with -- at all.
Thankfully, there are no glitches as far as getting stuff from the camera onto my desktop. You plug in the USB cable, select "back up files" from the camera console, and it shows up as simple external storage. The files are in .mod format, which is immediately playable by Totem, mplayer and vlc.
Editing is another matter -- I first tried Pitivi, but it didn't work very well for me. The interface is simple enough, but when I tried to trim a clip and render a theora movie, the result was that the video frame freezes where I wanted to trim it, but the sound just keeps going until the original end of the clip. Shoddy.
Next up was Kino. This works quite well, except for an occasional crash, and a very annoying bug that makes the sound lag the picture by about 2 seconds -- but only while editing. When rendering, everything matches perfectly. I'm sure this can be configured around if I ask the right people. I was even able to do some simple cheesy transitions between clips. See attached. :)
I also installed Cinelerra, but ran away scared. It's way over my head at the moment. For now, I'll stick with Kino -- seems to do everything I need it to do without too steep of a learning curve. Hopefully, the problems I'm seeing with it at the moment are just me cutting my teeth on it.
Sunday, July 20, 2008
Canada Post -- FAIL
Dear Canada Post:
It's one thing to claim that my version of Firefox is "insufficiently current" -- true, I need to upgrade to 3.0.1, but I have good reasons not to (broken deps galore). However, it's totally another to offer me a link to download Netscape or IE.
Dolts.
I fooled it easily with "Agent Switcher," but that's just broken.
It's one thing to claim that my version of Firefox is "insufficiently current" -- true, I need to upgrade to 3.0.1, but I have good reasons not to (broken deps galore). However, it's totally another to offer me a link to download Netscape or IE.
Dolts.
I fooled it easily with "Agent Switcher," but that's just broken.
Saturday, July 19, 2008
Canadian Doukhobors
I am into the history of Canadian Doukhobors lately. The religious side doesn't really intrigue me all that much -- what interests me is the dynamics of a large Russian community that migrated en masse to Canada, and then slowly assimilated into the mainstream Canadian culture. These days, you can find plenty of people with Russian names living around the Kootenays -- like "Popoff," "Tarasoff" or "Verigin" -- but if you talk to them, their knowledge of Russian language does not really go beyond a few token words, even for people of older generations. It's even weirder to suddenly be in the middle of a region called "Dolina Ootisheniya" (the "Vale of Consolation") -- somehow it doesn't feel right in the middle of British Columbia. It doesn't help that most signs omit the "Dolina" and just write "Ootisheniya" which simply doesn't make sense in Russian (it literally means "of consolation").
I visited the Doukhobor Museum in Castlegar, BC, while on vacation -- not that exciting, really. I think the best part was eating fairly decent vareniki at the Doukhobor diner -- but that's hard to get wrong. :)
In unrelated news, I'm going to this year's OLS. Any other Fedorans heading that way?
I visited the Doukhobor Museum in Castlegar, BC, while on vacation -- not that exciting, really. I think the best part was eating fairly decent vareniki at the Doukhobor diner -- but that's hard to get wrong. :)
In unrelated news, I'm going to this year's OLS. Any other Fedorans heading that way?
Monday, July 14, 2008
We're expecting!
For those of you who haven't yet guessed it from my wife's blog, we're expecting -- due at the end of January. This ultrasound was taken 3 weeks ago, so doesn't quite reflect reality.
We're all-around excited!
We're all-around excited!
Saturday, May 24, 2008
State of free desktop publishing
...is not that impressive. As some of you know, my wife runs her own business designing and selling cute knitted critters. Most of the revenue, however, comes from the sale of patterns, and not the actual toys, because the amount of time spent on knitting a toy pretty much offsets the price at which people are likely to buy it. Since I'm somewhat familiar with desktop publishing, I help her out with the layout of the patterns, and with the layout and design of the book.
In the world of free software, there's pretty much only two choices for doing desktop publishing -- either OpenOffice.org Writer, or Scribus. We started with OpenOffice, but while it's great at doing simple documents, introducing more complex layouts quickly brings it to its knees. Our book is only 40 pages of 2-column text with full-page graphics here and there, plus a sprinkling of floating frames. I dread reformatting it, as that inevitably causes Writer to go into fits. Sometimes just adding a paragraph causes it to insert dozens of blank pages somewhere in the middle of the document. My editing sessions almost always result in wailings and the grinding of teeth. Nothing more frustrating than saving a document only to find that it renders differently upon re-opening.
I tried Scribus when we first ran into some trouble with Writer, around November of last year. I wasn't impressed -- it was crash central, and I couldn't get even the simplest text frames to work correctly. Perhaps it was a bad build, or just a bad version release -- not sure -- but we decided to stick with OOo with all its failings. Recently, we started talking about releasing another holiday-themed pattern book, this time perhaps with an actual ISBN, which lets us hook into Amazon and B&N digital distribution system. Since Lulu's PDF file requirements for ISBN projects are a lot more strict, I decided to revisit Scribus again -- to see if things are any different six months later.
They are, but still not without drawbacks. Current version of Scribus in F8 and F9 is 1.3.4, which still crashes every now and again, though not nearly as often as before. The interface is not that confusing, and seems to render the content correctly -- at least when it's a few pages long, as I haven't yet had a chance to create a longer document. The main drawbacks with this version -- the rendering (and thus scrolling) is very slow, the undo is very weak, and it still links against qt3, meaning that if you don't have KDE3 installed on your machine, the interface will render in all its eye-stabbing Motif-y goodness.
Of all three, the incomplete undo is the most jarring. You can undo most operations on the objects, such as moving or resizing a frame, for example, but you can't undo any changes you made to the actual text. The argument from the Scribus development team is that you should currently use an external text editor until you're ready to import the finished text into the project. However, that doesn't help when I want to undo a style change, or restore something that got deleted due to my fat fingers.
Of the three main problems I have with it, only one is getting addressed -- the upcoming release of Scribus-1.3.5 uses qt4 to render the interface, and thus looks a lot less ugly. However, the lack of text undo and the slowness are still there, and I don't think they will get fixed unless Scribus gets an influx of developers (sadly, can't help them myself -- c++ and qt3 is not my idea of fun. ;)). Nonetheless, I think I'll stick to Scribus for my future work, and only use OOo for writing documents with simple layouts.
Using either of them is painful, but at least thus far I know that Scribus is not likely to subtly reformat my document if I save and re-open it later. I guess if I don't find a way to make Scribus do what we need, I'll have to bite my lip and get us a copy InDesign, though the price tag of $600 is currently way more than we can afford, not to mention that I'd have to boot into OS X just to use it.
In the world of free software, there's pretty much only two choices for doing desktop publishing -- either OpenOffice.org Writer, or Scribus. We started with OpenOffice, but while it's great at doing simple documents, introducing more complex layouts quickly brings it to its knees. Our book is only 40 pages of 2-column text with full-page graphics here and there, plus a sprinkling of floating frames. I dread reformatting it, as that inevitably causes Writer to go into fits. Sometimes just adding a paragraph causes it to insert dozens of blank pages somewhere in the middle of the document. My editing sessions almost always result in wailings and the grinding of teeth. Nothing more frustrating than saving a document only to find that it renders differently upon re-opening.
I tried Scribus when we first ran into some trouble with Writer, around November of last year. I wasn't impressed -- it was crash central, and I couldn't get even the simplest text frames to work correctly. Perhaps it was a bad build, or just a bad version release -- not sure -- but we decided to stick with OOo with all its failings. Recently, we started talking about releasing another holiday-themed pattern book, this time perhaps with an actual ISBN, which lets us hook into Amazon and B&N digital distribution system. Since Lulu's PDF file requirements for ISBN projects are a lot more strict, I decided to revisit Scribus again -- to see if things are any different six months later.
They are, but still not without drawbacks. Current version of Scribus in F8 and F9 is 1.3.4, which still crashes every now and again, though not nearly as often as before. The interface is not that confusing, and seems to render the content correctly -- at least when it's a few pages long, as I haven't yet had a chance to create a longer document. The main drawbacks with this version -- the rendering (and thus scrolling) is very slow, the undo is very weak, and it still links against qt3, meaning that if you don't have KDE3 installed on your machine, the interface will render in all its eye-stabbing Motif-y goodness.
Of all three, the incomplete undo is the most jarring. You can undo most operations on the objects, such as moving or resizing a frame, for example, but you can't undo any changes you made to the actual text. The argument from the Scribus development team is that you should currently use an external text editor until you're ready to import the finished text into the project. However, that doesn't help when I want to undo a style change, or restore something that got deleted due to my fat fingers.
Of the three main problems I have with it, only one is getting addressed -- the upcoming release of Scribus-1.3.5 uses qt4 to render the interface, and thus looks a lot less ugly. However, the lack of text undo and the slowness are still there, and I don't think they will get fixed unless Scribus gets an influx of developers (sadly, can't help them myself -- c++ and qt3 is not my idea of fun. ;)). Nonetheless, I think I'll stick to Scribus for my future work, and only use OOo for writing documents with simple layouts.
Using either of them is painful, but at least thus far I know that Scribus is not likely to subtly reformat my document if I save and re-open it later. I guess if I don't find a way to make Scribus do what we need, I'll have to bite my lip and get us a copy InDesign, though the price tag of $600 is currently way more than we can afford, not to mention that I'd have to boot into OS X just to use it.
Sunday, May 18, 2008
Unicode and strlen()
One of the common troubles in the world of modern software is its continuing inability to deal correctly with Unicode. One of the ways this inability manifests itself is when counting the length of the string.
Case in point -- let's take Twitter. Earlier today, I submitted the following update (because I was reading Astrid Lindgren's Karlsson-on-the-Roof in Chinese translation that I found on the web):
Now, this disconnect happens to be because my post contained many multibyte characters -- 3 bytes per each Chinese character, and 2 bytes per each Cyrillic character:
While this is arguably a sane default behaviour (if I wanted the string size, I would have asked for a string size, not length?), the trouble here is that this chokes on multibyte characters when calculating string lengths. Furthermore, this practice often results in data mutilation, for example when trying to auto-calculate the "short version" of a string and then offer a "read more" link, or when truncating something to fit into visual space constraints.
Consider this:
Different programming environments cope with this problem in different ways, but most of them require extra work. PHP deals with Unicode by providing an "mbstring" interface to most string functions. For example, we can use mb_strlen(), and mb_substr() to perform Unicode-aware string manipulation just as we would with regular strlen() and substr():
Python, which is also internally all-ASCII all the time (until python 3000 comes around, that is), deals with multibyte strings in simlarly clunky ways:
Conclusion:
Yes, Unicode is a pain in the ass, and requires jumping through extra loops whenever you get to deal with it. However, beleve me when I tell you that if you get used to the idea of Unicode from the very first line of your application, you won't have to later go back and rewrite things, potentially subtly breaking them in the process (e.g. see Twitter). Retrofitting an existing application to make it support Unicode quite often involves lots and lots of eye-stabbing and pain.
Oh, and the first person who says "why doesn't everyone just use English?" will be propmlty fed to the most rabid apparatchiks of the Office Québécois de la Langue Française. ;)
Case in point -- let's take Twitter. Earlier today, I submitted the following update (because I was reading Astrid Lindgren's Karlsson-on-the-Roof in Chinese translation that I found on the web):
我风华正茂：英俊、绝顶聪明、不胖不瘦！ (красивый, умный, в меру упитанный мужчина в полном расцвете сил) :DI was using the web interface to post it, and the counter at the top-right of the form dutifully told me that I had 53 more characters left, because Mozilla gets Unicode right. However, once I submitted the post, Twitter told me that oops, I went way over 140 characters and thus my post will be truncated when shown on the site.
Now, this disconnect happens to be because my post contained many multibyte characters -- 3 bytes per each Chinese character, and 2 bytes per each Cyrillic character:
print strlen('我') . "\n"; // output: 3A lot of software was written to deal with "unibyte" characters -- where one byte is used to represent a character, such as is the case with the venerable US-ASCII or ISO-8859-1. For example, such is the case with PHP -- when you use strlen() to calculate the length of the string, it will give you its length in bytes, and not its length in characters.
print strlen('я') . "\n"; // output: 2
While this is arguably a sane default behaviour (if I wanted the string size, I would have asked for a string size, not length?), the trouble here is that this chokes on multibyte characters when calculating string lengths. Furthermore, this practice often results in data mutilation, for example when trying to auto-calculate the "short version" of a string and then offer a "read more" link, or when truncating something to fit into visual space constraints.
Consider this:
print substr('你叫什么名字？', 0, 10) . " (read more)\n";That just sliced the string mid-character, and will usually show up as some version of an os-specific "[?]" glyph. And, of course, that actually truncated the string to 3 characters (plus junk) instead of achieving the wanted result.
Different programming environments cope with this problem in different ways, but most of them require extra work. PHP deals with Unicode by providing an "mbstring" interface to most string functions. For example, we can use mb_strlen(), and mb_substr() to perform Unicode-aware string manipulation just as we would with regular strlen() and substr():
mb_internal_encoding('utf-8');This will also do what we actually want and won't chop things off mid-torso:
print strlen('你叫什么名字？') . "\n"; // output: 21
print mb_strlen('你叫什么名字？') . "\n"; // output: 7
print mb_substr('你叫什么名字？', 0, 10) . " (read more)\n";PHP even has an option to replace all string functions with their multibyte equivalents, but this is rife with danger, because there's a good chance that the software you use will want to actually calculate the byte-length of a string and not its character length, i.e. when trying to figure out the size of a binary blob. Read more about mbstring and php.
Python, which is also internally all-ASCII all the time (until python 3000 comes around, that is), deals with multibyte strings in simlarly clunky ways:
mystr = '你叫什么名字？'In order to correctly handle Unicode strings, you have to first go from a string object to a unicode object by ways of using .decode('utf-8'):
print mystr[:4] + ' (read more)' # outputs junk
myuni = mystr.decode('utf-8')Alternatively, you can prepend all your unicode strings with 'u' to go straight to a unicode object, bypassing the ascii-centric string object:
print myuni[:4] + ' (read more)' # yay!
myuni = u'你叫什么名字？'However, you'll still be doing a lot of .decode('utf-8') when you are doing things like reading data from a file. The linked talk is probably the most succinct and useful presentation on python and Unicode I've found: you should read it.
print myuni[:4] + ' (read more)' # yay!
Conclusion:
Yes, Unicode is a pain in the ass, and requires jumping through extra loops whenever you get to deal with it. However, beleve me when I tell you that if you get used to the idea of Unicode from the very first line of your application, you won't have to later go back and rewrite things, potentially subtly breaking them in the process (e.g. see Twitter). Retrofitting an existing application to make it support Unicode quite often involves lots and lots of eye-stabbing and pain.
Oh, and the first person who says "why doesn't everyone just use English?" will be propmlty fed to the most rabid apparatchiks of the Office Québécois de la Langue Française. ;)
Saturday, April 26, 2008
Setting up Apple Remote Control with F9
I wanted to set this up for a while now, but it wouldn't work for me under F8, because of an older version of lirc. Well, it's working perfectly in Fedora 9, so here's how I did it (partly for my own reference, in case I have to do it again). This is on an i686 Mac Mini, but I'm pretty sure other Minis will have a similar configuration. Not so sure about Macbooks, but feel free to try it.
First of all, a note of warning of what to expect and what not to expect. Even though you'll get your Apple Remote Control working under Linux, this won't be Front Row. In Front Row, the remote functions differently depending on the context -- e.g. in DVD menus pressing forward/back will navigate the options, while "play/pause" will work as "select." With LIRC, you can only configure each button to have one function, so your Apple Remote will be nothing more than a 6-button remote control.
With that in mind, it's still quite nice to be able to pause the movie or adjust volume without getting off the couch, so here's how to do it.
Get the stuff
First, get all the necessary bits:
LIRC works like this -- a daemon listens to the HID device (builtin IR receiver) and maps events to its list of recognized buttons. There is a couple of contributed configurations, but they wouldn't work for me, so we'll generate our own. Run:
Now you have to set up the "client" side of lirc, by setting up an /etc/lircrc. The format is really quite verbose -- I'd hate to do this for remotes that have more than 6 buttons. Here's mine, which is configured for pulseaudio and for Totem: my /etc/lircrc.
Setting up PulseAudio
Edit /etc/pulse/default.pa and add the following:
Totem
That's easy -- just load it up and make sure the lirc plugin is enabled (Edit->plugins).
Other apps
I'm planning on setting it up with Exaile, but I haven't yet had a chance to get around to that. I can see from the packages available that several other apps have lirc capabilities, e.g. rhythmbox and xmms, but I don't use either of these, so I didn't bother setting them up.
I just wish Miro supported it, but currently it doesn't. In fact, Miro is having issues under F9 at the moment, so I didn't even get a chance to try.
Hope this was helpful to others.
First of all, a note of warning of what to expect and what not to expect. Even though you'll get your Apple Remote Control working under Linux, this won't be Front Row. In Front Row, the remote functions differently depending on the context -- e.g. in DVD menus pressing forward/back will navigate the options, while "play/pause" will work as "select." With LIRC, you can only configure each button to have one function, so your Apple Remote will be nothing more than a 6-button remote control.
With that in mind, it's still quite nice to be able to pause the movie or adjust volume without getting off the couch, so here's how to do it.
Get the stuff
First, get all the necessary bits:
# yum install lirc pulseaudio-module-lirc totem-lircSetting up LIRC
LIRC works like this -- a daemon listens to the HID device (builtin IR receiver) and maps events to its list of recognized buttons. There is a couple of contributed configurations, but they wouldn't work for me, so we'll generate our own. Run:
irrecord -H macmini -d /dev/hiddev0 /etc/lircd.confRead carefully the instructions, it's important! I labeled the buttons as follows:
menu, volume_up, volume_down, backward, forward, play_pauseOnce you are done, you should have everything you need to make the remote work. Now, edit /etc/sysconfig/lirc and set:
LIRCD_OPTIONS="-H macmini -d /dev/hiddev0"Now start lircd up:
chkconfig lirc onYou can test it to make sure that it's working by running:
service lirc start
irw /dev/lircdPress a few buttons and you should see events show up on the console. If something is not working, troubleshoot the previous steps. For your reference, my lircd configuration is available here: my /etc/lircd.conf.
Now you have to set up the "client" side of lirc, by setting up an /etc/lircrc. The format is really quite verbose -- I'd hate to do this for remotes that have more than 6 buttons. Here's mine, which is configured for pulseaudio and for Totem: my /etc/lircrc.
Setting up PulseAudio
Edit /etc/pulse/default.pa and add the following:
.ifexists module-lirc.soNote, that if you have more than one audio device, you'll need to list the sink here. To find out what sink you should use, run "pacmd" and then, at the prompt, "list-sinks". Look for the device that you want to control with your remote and copy the "name" without the angle brackets. You'll need to add it to the load-module command, e.g. like so (for me):
load-module module-lirc config=/etc/lircrc
.endif
load-module module-lirc config=/etc/lircrc sink=alsa_output.pci_8086_27d8_sound_card_0_alsa_playback_0You'll need to restart pulseaudio to take effect -- you can just log out and log back in for that. If all went well, pressing volume buttons on the remote should now change volume on your mac mini.
Totem
That's easy -- just load it up and make sure the lirc plugin is enabled (Edit->plugins).
Other apps
I'm planning on setting it up with Exaile, but I haven't yet had a chance to get around to that. I can see from the packages available that several other apps have lirc capabilities, e.g. rhythmbox and xmms, but I don't use either of these, so I didn't bother setting them up.
I just wish Miro supported it, but currently it doesn't. In fact, Miro is having issues under F9 at the moment, so I didn't even get a chance to try.
Hope this was helpful to others.
Monday, March 24, 2008
Old man and a pipe
I'm trying to get back into drawing, so I've done a couple of sketch studies over the holidays to freshen up my neglected pencil skills. This one turned out not too shabby -- I'm quite pleased with it. A couple of small mistakes, but nothing too major. I did one of a yawning baby yesterday, and that one was a disaster. (Most of my sketch studies are from images I find on Flickr).
Let's hope I don't neglect my art again -- my father really wants me to keep at it.
20x20cm, 2B pencil on brown paper, with white conté crayon for highlights.
Let's hope I don't neglect my art again -- my father really wants me to keep at it.
20x20cm, 2B pencil on brown paper, with white conté crayon for highlights.
Sunday, March 23, 2008
Showers need a "pause" button
Water conservation seems to be on everyone's mind lately. It seems to me that a fairly simple way to encourage people to use less water during shower would be to offer a convenient way to "pause" it. See, I'm all for turning the water off while soaping up, but it's a pain to get it going again at just the right temperature and pressure that I like -- and I think that the majority of people are the same way. When I'm soapy or have shampoo in my hair, I don't really want to fiddle with the taps to get the right temperature again, and I think that's the reason why most people just don't bother.
If there was a convenient switch that would let me shut off the flow of water but keep it at the right temperature and pressure the instant I turn it back on, I'd use it every time.
(This is not the same as shutting the water off automatically after 20 seconds. I've had an opportunity to use those a couple of times in Europe, and they are just annoying, as they shut off when you least want them to, like when you have soap in your eyes).
Seriously, something like a big knob on the wall. Pull it and the shower pauses. Slam on it, and it's back on again. I think people would actually use that.
If there was a convenient switch that would let me shut off the flow of water but keep it at the right temperature and pressure the instant I turn it back on, I'd use it every time.
(This is not the same as shutting the water off automatically after 20 seconds. I've had an opportunity to use those a couple of times in Europe, and they are just annoying, as they shut off when you least want them to, like when you have soap in your eyes).
Seriously, something like a big knob on the wall. Pull it and the shower pauses. Slam on it, and it's back on again. I think people would actually use that.
Subscribe to:
Posts (Atom)
