Mon, 20 Oct 2008
Xam'd: Lost Memories
It's been a while since I posted anything to the anime section of this blog. It is not that I don't watch anime anymore, it is just that I don't want to write about anime that is already widely known and appreciated (like Haruhi or Lucky Star). Recently I have discovered a new series, both good and unknown enough to write a blogpost about it.
Xam'd:
Lost Meories is a new series from Studio Bones
(Fullmetal
Alchemist,
RahXephon, etc.). When I have seen the first episode, I thought: OMG,
Eureka 7 with a different color key!
And yes, so far Xam'd is quite similar to Eureka: it has a flying ship with
crew consisting of weirdos (this time the leader is an angry glass-wearing
woman), working as a delivery service (this time delivering real snail-mail
letters rather than a random cargo), it has a group of kids onboard,
it has a smaller aircraft piloted by a cold-looking girl (altough Nakiami
is a bit more lively than Eureka), it has aliens which are probably related
to that girl somehow, it has an excellent opening song, and, of course, it has studio
Bones' excellent animation and vivid backgrounds.
I will not spoil the story (after all, so far there are only 11 episodes out),
but if you want something really worth watching, Xam'd: Lost Memories
can be for you, especially if you liked Eureka (hi Vlasta!). If you haven't
seen Eureka 7, watch it first so that you don't have to wait for further
episodes of Xam'd. Hope they will create a better ending than the one
in Eureka 7.
Fri, 17 Oct 2008
Stitching Photos
In Oregon, I took several photos from one point in order to try to stitch them to one panorama later. The shots were taken from hand, so it was not optimal. In further experiments I would have to use a wider angle lens and higher overlap of the frames (I used about 20 % on each side). Manual exposition and focus is a necessity in order to get the same level of light across the whole view.
The image above is composed from eight photos taken at the Crown Point above the Columbia River. Best viewed using two wide monitors in Xinerama/XRandr dual mode :-)
The image has been created using Hugin, which is a really nice and intuitive software. I have been able to create the panorama without even reading the manual. Altough, reading their tutorials definitely helps (a funny bug there - the tutorial section labeled "Czech/Čeština" contains only one tutorial, which is actually in Slovak :-).
Stitching photos is another ugly case of software patents abuse: the algorithm for automatically detecting suitable alignment control points is patented in the U.S., which means that even though the patent is definitely not valid in Europe, precompiled software distributed globally (like Hugin) cannot use it.
Thu, 16 Oct 2008
Driving in the United States
I will not write about everything I did in Oregon (you can get better insight to the way of life in the US from the point of view of a foreigner in a Linus' blog), but there is one pretty interesting topic: my experience from driving a car in the US. There are several differences for the European driver:
- Automatic gearboxes everywhere. It was impossible to rent a car with manual gearbox. More on it later.
- The speed limits are pretty low. It is not surprising that US people go for a "bigger" car (SUV or large pickups) instead of the car that performs better (i.e. stronger engine and better-tuned chassis). When I asked about the speed limits in the car rental, they said: "I don't know - just follow the car in front of you."
- That said, nobody follows the speed limit - all cars were driving +5 to +10 mph above it. However, the speed variance among the cars was surprisingly low - i.e. everybody was drving +10 mph, there was virtually no overtaking. In our country it is quite common (esp. on multi-lane roads) that somebody follows the speed limit (130 km/h on a motorway), but somebody drives maybe 30 % faster. That said, the fatality per capita is about 50 % higher in the US than in the Czech republic.
- Apart from arrow signs (prof. Donald Knuth has a nice collection:-), there were almost no pictographic signs - everything was explained in words. Even some not so common road marking, like both straight and dashed line in the middle of the road, had an explanation board near its beginning.
- 4-way stop crossings, and the "first come, first serve" principle. Sometimes it was not very clear who came first.
- Traffic lights after the crossings. Several times I nearly missed the red light, simply because I have expected it to be in a different place (i.e. before the crossing).
- The car models were very different. While I have seen several models which can also be seen in Europe (Ford Focus, Chevrolet Aveo, and even one VW Golf), in general the cars in the US are different to those sold in Europe, even when the manufacturer is present on both sides of the Atlantic (like Ford or Toyota).
As for the automatic gearbox, it was pretty interesting. While the machine can change gears definitely faster than human, it cannot predict what the driver wants to do. For example, I when I needed to accelerate in order to overtake, the car (Chevrolet Aveo and then a brand new Chevrolet Cobalt) firstly choked on a current gear for maybe two seconds, then shifted to a lower gear, providing some acceleration, and just before the engine entered the RPM area of the highest power, it decided that it is still not enough, and shifted down once more, taking the engine to the red RPM values :-(
Maybe I would learn how to accelerate properly with an automatic gearbox after some more driving, but for now it is not usable for anything more than slow and careful cruising (which is how people drive in the US). However, I can imagine that an automatic gearbox with some tweaking (probably a "hold the current gear unless RPM is already near maximum" button and a "shift one gear lower" button) would provide the better from both systems.
Wed, 15 Oct 2008
Kernel Summit, Day 2
Just a short report from the rest of the Kernel Summit:
Probably the most interesting discussion the second day was about
thread pools. I believe there is no clear solution, because it could
for example make sense to have N kcryptd threads for N CPU cores
if the most of your workload is in handling encrypted block devices,
but it probably does not make sense to have 2048 kernel threads to handle
networking bottom half on a 2048-CPU SGI box where most of the cores are
too far (NUMA-wise) from the network card, and the box mainly does other
things than handling networking. Maybe some kind of dynamic allocation?
However, moving even IRQ handlers to separate threads could help with
some latency problems like the one I observed on my router.
We have got a development board from Gumstix as a present. It is an interesting toy - a very tiny board with TI OMAP CPU (like the one from Nokia Maemo), memory, and a microSD slot. And a bit bigger daughterboard with I/O ports (several USBs, power, HDMI, sound, WiFi/BT, etc.). I just need to get a proper power brick for the local wall outlets (the one we got was for US outlets).
The joint dinner with the Linux Plumbers Conference: playing Wii Sports with Bartlomiej Zolnierkiewicz, Herbert Xu and Evgenij Polyakov (Wii is cool and definitely very different from other game consoles, try it!), and then discussing dm-crypt threads and Brno Red Hat branch with Alasdair Kergon.
Tue, 14 Oct 2008
SSH and the Network Gear
How do you configure and manage your network gear? Am I the only person in the world who uses SSH (OpenSSH) to remote login to my switches, access points, master switches, etc.? Does everybody use "unified" tools (but for one vendor only) like HP ProCurve Manager?
I have recently discovered that I cannot login to one of my HP ProCurve switches - the switch just kept dropping the connection with the following message:
Received disconnect from 147.251.XX.YY: 2: protocol error: rcvd type 80
At first I suspected a SW or HW failure on the switch side (it could not possibly be a software problem as even HP uses OpenSSH in their firmware). But even after rebooting the switch I was not able to log in. I was in a hurry so I configured the switch over a serial console. But yesterday I have found that I have similar problems even when connecting to my APC 7920 master switches. That definitely looked as a problem on my side instead. So I tried to downgrade OpenSSH from 5.1p1 to 5.0p1, and the connections to my network gear are working again. Repored to Fedora as bug#466818.
But I still wonder why the bug was not discovered earlier, according to the install date of my openssh packages, they are at least a month old (build date is even older). And an incompatibility between OpenSSH and OpenSSH? WTF?