<object class="BLOG_video_class" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" height="266" id="BLOG_video-e10aebbc1dd937ed" width="320"><param name="movie" value="http://www.youtube.com/get_player"><param name="bgcolor" value="#FFFFFF"><param name="allowfullscreen" value="true"><param name="flashvars" value="flvurl=http%3A%2F%2Fv7.nonxt4.googlevideo.com%2Fvideoplayback%3Fid%3De10aebbc1dd937ed%26itag%3D5%26app%3Dblogger%26ip%3D0.0.0.0%26ipbits%3D0%26expire%3D1293804875%26sparams%3Did%252Citag%252Cip%252Cipbits%252Cexpire%26signature%3D4F186A3751631F2931BE78DB408398983676DB8E.2FDDADC2413DD729039774AA440EAB1C95EA068A%26key%3Dck1&amp;iurl=http%3A%2F%2Fvideo.google.com%2FThumbnailServer2%3Fapp%3Dblogger%26contentid%3De10aebbc1dd937ed%26offsetms%3D5000%26itag%3Dw160%26sigh%3Dx99eVmNAybTlHHC3EkTV9GH9eUI&amp;autoplay=0&amp;ps=blogger"><embed allowfullscreen="true" bgcolor="#FFFFFF" flashvars="flvurl=http%3A%2F%2Fv7.nonxt4.googlevideo.com%2Fvideoplayback%3Fid%3De10aebbc1dd937ed%26itag%3D5%26app%3Dblogger%26ip%3D0.0.0.0%26ipbits%3D0%26expire%3D1293804875%26sparams%3Did%252Citag%252Cip%252Cipbits%252Cexpire%26signature%3D4F186A3751631F2931BE78DB408398983676DB8E.2FDDADC2413DD729039774AA440EAB1C95EA068A%26key%3Dck1&amp;iurl=http%3A%2F%2Fvideo.google.com%2FThumbnailServer2%3Fapp%3Dblogger%26contentid%3De10aebbc1dd937ed%26offsetms%3D5000%26itag%3Dw160%26sigh%3Dx99eVmNAybTlHHC3EkTV9GH9eUI&amp;autoplay=0&amp;ps=blogger" height="266" src="http://www.youtube.com/get_player" type="application/x-shockwave-flash" width="320"></object>

My tip of day. When you lose control of a process (for example with a process launched with disown or, another example, when you close your SSH terminal with unsynced mutt), thanks gdb.

$ tty
/dev/pts/13
$ gdb --pid= pidof mutt 
(gdb) call close(0)
(gdb) call close(1)
(gdb) call close(2)
(gdb) call open("/dev/pts/13", 2, 0)
(gdb) call dup(0)
(gdb) call dup(0)
(gdb) detach
Detaching from program: /usr/bin/mutt-org, process 2932

Thanks to this comment on superuser.com for the original idea. Edit: correction on dup() calls. Thanks to Peter Pentchev for his explanation in comments.

If you're following me on identi.ca you probably already know that I've been designing a small PCB for a USB-based SPI chip programmer named openbiosprog-spi. The main use-case of the device is to help you recover easily from a failed BIOS upgrade (either due to using an incorrect BIOS image, due to power outages during the flashing progress, or whatever). The device only supports SPI chips, as used in recent mainboards (in DIP-8 form factor, or via manual wiring possibly also soldered-in SO-8 variants). It can identify, read, erase, or write the chips. Of course the whole "toolchain" of software tools I used for creating the hardware is open-source, and the hardware itself (schematics and PCB layouts) are freely released under a Creative Commons license (i.e., it's an "Open Hardware" device). The user-space source code is part of flashrom (GPL, version 2), the schematics and PCB layouts are licensed under the CC-BY-SA 3.0 license and were created using the open-source Kicad EDA suite (GPL, version 2).
The schematics, PCB layouts, and other material is available from gitorious:

  $ git clone git://gitorious.org/openbiosprog/openbiosprog-spi.git

You can also download the final Gerber files (ZIP) for viewing them, or sending them to a PCB manufacturer. Some more design notes:

• The device uses the FTDI FT2232H chip as basis for USB as well as for handling the actual SPI protocol in hardware (MPSSE engine of the FT2232H).
• Attaching the SPI chip:
  • There's a DIP-8 socket on the device so you can easily insert the SPI chip you want to read/erase/program.
  • Optionally, if you don't want a DIP-8 socket, you can solder in a pin-header with 8 pins, which allows you to connect the individual pins to the SPI chip via jumper wires or grippers/probes.
• The PCB board dimensions are 44mm x 20mm, and it's a 2-layer board using mostly 0603 SMD components.

Basic usage example of the device on Linux (or other OSes supported by flashrom):

  $ flashrom -p ft2232_spi:type=2232H,port=A -r backup.bin (reads the current chip contents into a file)

Over at the main projects page of openbiosprog-spi at http://randomprojects.org/wiki/Openbiosprog-spi I have put up a lot more photos and information such as the bill of materials, the Kicad settings I used for creating the PCBs, the Gerber files and the Excellon drill files and so on. The first few prototype boards I ordered at PCB-POOL.COM (but you can use any other PCB manufacturer of course), the bill of materials (BOM) lists the Mouser and CSD electronics part numbers and prices, but you can also buy the stuff elsewhere, of course (Digikey, Farnell, whatever). I already hand-soldered one or two prototypes and tested the device. Both hardware and software worked fine basically, you just need a small one-liner patch to fix an issue in flashrom, but that should be merged upstream soonish. In order to make it easy for interested users to get the PCBs I'll probably make them available in the BatchPCB Market Place soonish, so you can easily order them from there (you do still need to solder the components though). Note: I'm not making any money off of this, this is a pure hobby project. All in all I have to say that this was a really fun little project, and a useful one too. This was my first hardware project using Kicad (I used gEDA/PCB, also an open-source EDA toolsuite, for another small project) and I must say it worked very nicely. I didn't even have to read any manual really, it was all pretty intuitive. Please consider not using Eagle (or other closed-source PCB software) for your next Open Hardware project, there are at least two viable open-source options (Kicad, gEDA/PCB) which both work just fine.

When I started working on WebKitGTK+ I was a web developer, writing IT applications using Python and Django, and building features for content portals running Plone (argh). Even though I was an Epiphany user ever since it was forked off Galeon, I still had to use Firefox for my work, because I couldn t really live without Firebug. It should come as no surprise, then, that one of my first patches to WebKitGTK+ was actually making the awesome Web Inspector work in our port. After the initial support, though, not a lot has been done to further improve it, partly because it was already good enough for many uses, partly because I somehow started doing non-web development again ;). These last weeks, through my R&D efforts in Collabora, I have been able to push Web Inspector features and integration a bit further. A simple change that boosts the Inspector s usability quite a bit is having the nodes that are being hovered highlighted. Along with that, the ability to attach the inspector to Epiphany s window should make it easier to use for poking the DOM. The Web Inspector has a number of settings that control its behaviour. Since, for instance, enabling javascript debugging may slow down javascript performance, the inspector usually has it disabled by default, and provides a button to enable it. It also provides an option for always enabling that feature, but that does not work right now, because we are not saving/restoring the relevant settings. A solution to that is in the works using the GSettings infrastructure that was recently merged into glib. Here s a simple screencast, showing these improvements in action (click the video to check it out in full size): <video controls="controls" src="http://kov.eti.br/media/webkit/inspector.ogv" width="400"></video>

I've had the opportunity to look into the Joojoo tablet recently. It's an interesting device in various ways, ranging from the screen being connected upside down and everything having to be rotated before display, to the ACPI implementation that's so generic it has no support for actually attaching most embedded controller interrupts to ACPI devices and so relies on a hacked kernel that exposes individual interrupts as ACPI events that are parsed in userspace, to the ChangeOrientation binary that's responsible for switching between landscape and portrait modes containing gems like ps aux grep fgplayer grep -v grep and containing references to org.freedesktop.PandaSystem, a somewhat gratuitous namespace grab. Hardware-wise it seems to be little more than battery, generic nvidia reference design board and touchscreen with an accelerometer and LED glued to the chipset's GPIO lines. The entire impression is one of an ambitious project not backed up by the level of technical expertise required to get things done properly. Frankly, I think Michael Arrington came out of this rather better than he could have done - behind the reasonably attractive UI, the entire device is pretty much held together by string and a following wind.

Of course, releasing shoddily put together technology isn't generally illegal and from that point of view Fusion Garage aren't any worse than a number of products I've had the misfortune to actually spend money on. But they're distributing Linux (stock Ubuntu with some additional packages and a modified kernel) without any source or an offer to provide source. I emailed them last week and got the following reply:

Dear Sir,

we are still actively making changes to the joojoo software. We will make
the source release available once we feel we are ready to do so and also
having the resources to get this sorted out and organized for publication.
We seek your kind understanding on our position and appreciate your
patience on this. Thank you.

Best Regards
joojoo Support Team

Strong work, Fusion Garage. Hardware and software may not be your strong points, but you're managing copyright infringement with the best of them.

It s widely regarded that passwords should be changed regularly. The Australian government declared last week the National Cyber Security Awareness Week [1] and has published a list of tips for online security which includes Get a stronger password and change it at least twice a year . Can a Password be Semi-Public? Generally I think of a password as being either secret or broken. If a password is known to someone other than the sysadmin and the user who is authorised to use the account in question then you have potentially already lost all your secret data. If a password is disclosed to an unauthorised person on one occasion then merely changing the password is not going to do any good unless the root cause is addressed, otherwise another anothorised person will probably get the password at some future time. Hitachi has published a good document covering many issues related to password management [2]. I think it does a reasonable job of making sysadmins aware of some of the issues but there are some things I disagree with. I think it should be used as a list of issues to consider rather than a list of answers. The Hitachi document lists a number of ways that passwords may be compromised and suggests changing them every 60 to 90 days to limit the use of stolen passwords. This seems to imply that a password is something that s value slowly degrades over time as it s increasingly exposed. I think that the right thing to do is to change a password if you suspect that it has been compromised. There s not much benefit in having a password if it s going to be known by unauthorised people for 89 days before being changed! Fundamentally a password is something that can have it s value rapidly drop to zero without warning. It doesn t wear out. Why are terms such as Three Months used for Maximum Password Ages? The Hitachi document gives some calculations on the probability of a brute-force attack succeeding against a random password with 90 days of attacking at a rate of 100 attempts per second [2]. I think that if a service is run by someone who wouldn t notice the load of 100 attempts per second then you have bigger security problems than the possibility of passwords being subject to brute-force attacks. Also it s not uncommon to have policies to lock accounts after as few as three failed login attempts. Rumor has it that in the early days of computing when the hashed password data was world readable someone calculated that more than 3 months of CPU time on a big computer would be needed to obtain a password by brute-force. But since then the power of individual CPUs has increased dramatically, computers have become cheap enough that anyone can easily gain legal access to dozens of systems and illegal access to a million systems, and it has become a design feature in every OS that hashed passwords are not readable by general users. So the limiting factor is to what degree the server restricts the frequency of password guesses. I don t think that specifying the minimum password length and maximum password age based on the fraction of the key space that could be subject to a brute-force attack makes sense. I don t think that any attempt to make an industry-wide standard for the frequency of password changes (as the government is trying to do) makes sense. Can there be a Delay between a Password being Compromised and being Used by an Attacker? Hypothetically speaking, if a password was likely to be compromised (EG by having the paper it was written on lost or stored insecurely) for some time before an attacker exploited it, then if the password was changed during that time period it could solve the problem. For example when a company moves office there is the possibility of notepaper with passwords to be lost. So if the sysadmin caused every user password to expire at the time of the move then a hostile party would be unable to gain access. Another possibility is the theft of backup tapes that contain the list of unencrypted passwords. If users change their passwords every three months then the theft of some four month old backup tapes will be less of a problem. Another possibility concerns the resale of old computers, phones, and other devices that may contain passwords. A reasonably intelligent user won t sell their old hardware as soon as the replacement device arrives, they will want to use the new device for some time to ensure that it works correctly. If passwords expire during this trial period with the new device then passwords stored in the old device won t have any value. The down-side to this idea is that people probably sell their old gear fairly quickly and making passwords expire every two weeks would not be accepted well by the users. It seems to me that having bulk password changes (all passwords for one user or for one company) based on circumstances that lead to potential insecurity would do more good than changing passwords at a fixed schedule. How are Passwords typically Compromised? Dinei Flor ncio and Cormac Herley of Microsoft Research and Baris Coskun of Brooklyn Polytechnic University wrote a paper titled Do Strong Web Passwords Accomplish Anything? [3] which discusses this issue. The first thing that they note is that nowadays passwords are most commonly compromised by phishing and keylogging. In those cases passwords are typically used shortly after they are stolen and the strength of a password never does any good. That paper suggests that banks should use stronger user-names rather than stronger passwords to combat the threat of bulk brute-force attacks. Can a Password Last Forever? If a password is entered in a secure manner, authenticated by a secure server, and all network links are encrypted or physically protected then there should never be a need to change it. Of course nothing is perfectly secure, so for some things with minimal short-term value or which can be used without anyone noticing there is a benefit in changing the password. But in the case of Internet banking if a hostile party gets your login details then you will probably know about it in a few days when the bank calls you about the unusual transactions from foreign countries long before a 90 day password change schedule would have done any good. Maybe one of the issues determining whether a password should be changed regularly is whether an attacker could use long-term read-only access to gain some benefit. Being able to read all the email someone received for a year could be a significant benefit if that person was a public figure, and there s usually no way for an ISP customer to know that someone else is downloading all their mail via POP or IMAP. Should a Password be the only Authentication Method? It is generally agreed that an authenitcation method should ideally involve something you have plus something you know. That means a password and a physical device such as a smart card, token with a changing sequential password, or a key such as a Yubikey [4]. If the physical device can t be cloned (through some combination of technical difficulty and physical access control) then it significantly improves security. When a physical device is used the purpose of the password is merely to stop someone who steals the physical device from being immediately exploit everything the password only has to be strong enough to keep the accounts secure until a new token can be issued. The combination of something you have and something you know is very strong. Having a physical token stored on the desk next to the PC that is used for logging in provides a significant benefit, then an attacker needs to break in to the house and can t sniff the password by compromising the PC remotely. Conclusion In all aspects of security you need to consider what threats you face. If an attacker is likely to launch an immediate noisy attack (such as transferring the maximum funds out of an Internet banking account) then changing the password regularly won t do any good. If a subtle long-term attack is expected then changing the password can do a lot of good but a physical token is the ideal if the account is valuable enough. But to put things in to perspective, it s technically possible to use a mobile phone camera at close range (or a SLR with a big lens at long range) to take a photo of keys that allow reproducing them. But this hasn t stopped people from carrying their house keys in an obvious manner that permits photography or leaving them on their desk at work. Also I ve never heard of anyone routinely changing the door locks in case a hostile party might have got a key although I m sure that such practices are common in highly secure locations. Few people even take their house keys off the key-ring when they have their car serviced! Related Posts Defense in Depth and Sudo when using sudo can increase security and when it can t.
Logging Shell Commands how to log what the sysadmin does and what benefits that provides you, it doesn t help if the sysadmin is hostile.
Logging in as Root should you login directly as root?

• [1] http://www.staysmartonline.gov.au/news/news_articles/feature/national_cyber_security_awareness_week
• [2] http://psynch.com/docs/password-management-best-practices.html
• [3] http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf
• [4] http://etbe.coker.com.au/2010/03/15/yubikey/

The answer is probably no way! I like the way Jon Corbet put it (article will be free in a few weeks):

The SCO affair is kind of like a bad zombie movie; the plot is implausible, the acting is horrible, and, even though you know the good guys must win in the end, that obnoxious zombie just keeps coming back and ruining the party.

Realistically, what will happen? The judge in the Chapter 11 case has so far been quite interested in helping SCO succeed, so I guess there will be an appeal on this. The contract claims in the cases surrounding this are probably not very relevant, so I'm not sure how much press they'll get (although I'm sure Pam will continue to cover the issue although I think the Apple vs. Hitachi patent cause should be the one that should be in the center of attention right now.) And, of course, there's the Canonical vs. SPI lawsuit coming up. I find it very difficult to tell in what direction that will get decided, but I hope it won't take as long as the SCO case.

Working on some document today, it occurred to me, once again, that OpenOffice's method for designing and applying documents styling totally sucks! Granted, this was not the first time that I cam to this conclusion but, today, I've come to realize that OpenOffice's paradigms constantly make me waste time trying to form a mental image of how every style element is suppose to relate to the other one, yet without having the full picture available within a single, easy-to-read document. Also, there is a complete lack of consistency in how style elements work. Some want to be defined in millimeters, while others want to be defined in points, while other still in number of lines. What a mess! In short: to become remotely usable, OpenOffice needs to approach document styling via the "HTML document with a separate CSS style sheet" paradigm. In other words, I need to be able to edit styles globally, as a group and separately from the document content itself, rather than having to click my way through a multitude of dialogs, for each and every type of text elements. To compare this with web design, there, I can focus on the actual content, formatted around semantic text elements (headers, paragraphs, block quotes, etc.) and then decide on the presentation styling as a separate global process by attaching a CSS style sheet, in which the relation between each type of text element and how it will be displayed is crystal clear, because it's handled as a unified style editing process. I think that this is one area in which Free Software could innovate in a positive way, by distancing itself from the Redmondesque practices of Microsoft Word, from which OpenOffice borrows too much. How about having a proper Style Editor application (similar to a CSS editor), within the OpenOffice suite, while Open Writer itself would only be allowed to load the style sheets produced by it and to apply them to semantic text text elements?

In November 2007, we bought two of the first Eee PC netbooks available in North America: the model 4G in pearl white, one for me, and one for my wife. My plan was to start the Debian Eee PC project and get Debian working on them both which, thanks to the work of everyone on the team, has been a great success. Fast forward to February 2010, and they are still serving us well. Here is a list of hardware enhancements and issues over the past two years of continuous use: Battery life Asus claims 3.5hrs for the model 4G, though I don t think we ever experienced anything better than 2.5 hrs with wifi in operation. Today, I m down to something short of 2 hrs. If you consider the Lithium ion battery article on Wikipedia to be accurate, it is typical to permanently lose 20% capacity per year, so this sounds about right for the age of the battery. Touchpad The touchpad itself is fine. The buttons are not. They are hard to push and prone to become less responsive after a while, or to fail entirely. I now really have to bear down hard on my left button to make it work. Because the buttons are soldered to the motherboard, they would be hard to replace. Configuring the synaptics driver for tap-to-click is an acceptable workaround. Also, one of the first purchases we made was the Logitech VX Nano, one for each Eee, so most of the time now, we use our mice, falling back to the touchpad only when using a mouse is inconvenient due to space constraints (e.g. on the bus). Keyboard After two years of continuous use, both of our keyboards needed replacing. Some of the keys had been pounded flat and needed surgery (rubber springs sliced out of a scavenged Acer netbook keyboard and grafted on) to make them usable again. And aesthetically, the keyboards have really suffered, with a good percentage of the markings on the keycaps partially or completely eroded off. Fortunately, for $3 plus $10 shipping each, new keyboards can be ordered from a Chinese e-Bay seller. But with the new keyboards, there is still the problem with excessive flex in the keyboard making some keys less responsive than others. I m considering trying this hack to solve the problem. Display I have no complaints about the matte finish displays of either Eee. Both have stood up well. People tell me they don t care for a 7 display, but I find it bright, crisp and easy to get along with, so long as you maximize windows and increase font size as needed (e.g. for reading PDF books and magazines). When I really need the extra real estate, I just hook up an external monitor. Fan Some people complain about the noise of the fan, from the otherwise silent 4G (due to the lack of a hard drive) and seek ways to limit the amount of time the fan runs. We ve never had that problem. However, if any plastic bits break off inside the Eee, they will eventually find their way to your fan and get wedged. This has happened twice: once in my wife s Eee, and once in mine. Disassembly of the Eee to clear the blockage and get the fan running again was relatively painless both times. Plastic bits About those plastic bits: In my wife s case, I think the bit was some extruded plastic from the molding that had broken off. In my case, it was a deteriorating plastic post which was holding the hinge in place. More about this later. Sound Unfortunately, the integrated sound seems to be particularly sensitive to heat. During both fan failures, sound cut out. On my wife s system, it never fully recovered, and now only works on alternate Tuesdays, whereas on mine, after I unwedged the fan and brought the heat down, sound has functioned properly ever since. (Update: see my comments below on power adapters for an alternate theory about what killed sound.) We are waiting now for the delivery of a cheap ($1.42 including shipping, again from China) 3D Sound USB device which is reported to work on Linux. While some users complain about hum with this device, we re cautiously optimistic that on the Eee it won t be an issue. If it is, oh well, a buck and a half is a small gamble. Display hinge The plastic posts that hold the anchors for the machine screws for the hinge are fragile. Three out of four of these posts in my Eee have shattered, leaving the left hinge to float freely. For the past two days I was distressed about how I could fix this. Based on some helpful suggestions from #eeepc @ irc.freenode.net, I had worked out a plan to rebuild one of the posts with two-part epoxy, sand it and the fractured stub of the post, and use cyanoacrylate glue to affix it to the case. It sounded like fiddly work for which I didn t hold much hope of success. But this morning, I realized that the plastic in the bottom of the case was still sound, and that I could drop a screw into that hole, and with pliers, line up the anchor on the other side. This appears to work! I ll handle that hinge with care, but it should do me until I eventually repurpose the machine to some daily use that is less stressful on the hinge than daily travel on the bus. SSD and SDHC Some people were initially worried that the limited write life an SSD meant that you needed to take special measures to avoid its premature death, which I have always regarded as a myth. Our 4G SSDs each have no swap space, and ext3 filesystems. At the two year point, there are no problems. I expect our SSDs to outlast the other components. We did, however, eventually find the 4G to be a bit on the small side. We now each have Kingston 4G micro-SDHC cards for a bit of extra capacity for large media files and for some extra space for the apt cache. I recently priced the Lexan version of this card at $19 for a two-pack at Wal-mart, and these seem to work in the model 4G just as well (which seems to be an issue with this model not all SDHC cards work). Memory We found the 512M that came with the 4G somewhat constraining. Without any swap space (so we could maximize the space available on the small SSD) we decided our systems really needed a memory upgrade. At the time, 2G didn t seem overly expensive (though I no longer remember the exact price) so we splurged on 2G for each system, even though that was probably more than we needed. Power adapter When I first wrote this article, I forgot to mention the power adapter. The model 4G uses an unusual 9.5V power adapter for which it is hard to find a generic replacement. This unit is prone to fail in two places: in rare cases, (one out of 6 units that I have in some way assisted with: 3 of them mine, 3 belonging to others,) it will break at the wall plug end. The plug swivels into the unit for easy storage, but this adds a point of failure. More commonly, (in 3 out of six of the units,) the wires at the netbook plug end will fray due to stress on the non-angled cord, leading either to no connect, or to a short. In fact, since in the case of my wife s adapter, the netbook end of the cable shorted, making the cable heat up and the system spontaneously shut down after a little while, we can t say for sure whether the overheating of the Eee took out integrated sound, or whether this short did. On the one hand, I know for certain my own system, which never suffered a short, has responded to overheating by making the sound flaky, but it has never taken out sound completely. On the other hand, shorting the power cable can t be very good for the Eee, so who knows, maybe that s what ultimately killed my wife s Eee s sound. This is where it helps to have soldering skills, or a friend who can do the repair for you. In my case, it was the latter. While I was waiting for a replacement adapter I had ordered, we also found on eeeuser.com part#s for replacement plugs and sleeves from Digikey, total cost $20 including shipping, 10 pieces each. Cutting off the bad plugs on three units and attaching the new was a quick, straightforward operation, and succeeded in two out of three cases. Having carefully checked the failed repair, we deduced that the failure in that unit was at the wall end, and we judged there was nothing further we could do to try to save it. Even the unit that had previously shorted was returned to perfect health and has been in operation trouble-free ever since. Conclusion After over two years of continuous use, the model 4G has held up well for a $400 system. We definitely feel we have received our money s worth of value over that time. All of the problems we ve experienced so far have been fixable at very little expense, and we expect them to last at least another year before we seriously consider replacing them. In the next several months, I plan to order a high capacity 8-cell 10400mAh battery for my own system so that I can enjoy a 5-6 hr run time. The purchase will be roughly $55 including shipping, the most expensive purchase for my system to date, but still well worth it to extend the 4G s lifespan for another year or more.

This is an updated version of yesterday's post with corrected URLs -- by copy-and-pasting I had still referenced the previous slides from UseR! 2009 in Rennes instead of last Friday's slides from the ISM presentation in Tokyo. The presentations page had the correct URLs, and this has been corrected below for this re-post. My apologies! As mentioned yesterday, I spent a few days last week in Japan as I had an opportunity to present the Introduction to High-Performance Computing with R tutorial at the Institute for Statistical Mathematics in Tachikawa near Tokyo thanks to an invitation by Junji Nakano. An updated version of the presentations slides (with a few typos corrected) is now available as is a 2-up handout version. Compared to previous versions, and reflecting the fact that this was the 'all-day variant' of almost five hours of lectures, the following changes were made:

• the 'parallel computing' section was expanded further with discussion of the recent R packages multicore, iterators, foreach, doNWS, doSNOW, doMPI;
• a first discussion of GPU computing using the gputools package was added;
• the section on 'out of memory computing' using ff, bigmemory and biglm (including an example borrowed from Jay Emerson) reappeared in this longer version;
• minor fixes and polishing throughout.

Comments and suggestions are, as always, appreciated.

As mentioned yesterday, I spent a few days last week in Japan as I had an opportunity to present the Introduction to High-Performance Computing with R tutorial at the Institute for Statistical Mathematics in Tachikawa near Tokyo thanks to an invitation by Junji Nakano. An updated version of the presentations slides (with a few typos corrected) is now available as is a 2-up handout version. Compared to previous versions, and reflecting the fact that this was the 'all-day variant' of almost five hours of lectures, the following changes were made:

• the 'parallel computing' section was expanded further with discussion of the recent R packages multicore, iterators, foreach, doNWS, doSNOW, doMPI;
• a first discussion of GPU computing using the gputools package was added;
• the section on 'out of memory computing' using ff, bigmemory and biglm (including an example borrowed from Jay Emerson) reappeared in this longer version;
• minor fixes and polishing throughout.

Comments and suggestions are, as always, appreciated.

Just got back from Tokyo a few hours ago: I had an opportunity to give my 'Introduction to High-Performance Computing with R' tutorial / lectures (for which previous slides can be found here). This was an all-day talk at the Institute for Statistical Mathematics at their new site in Tachikawa in the greater Tokyo area, thanks to an invitation by Junji Nakano. Lisa and I turned this into a brief one-week trip to Kyoto and Tokyo, and we had a truly wonderful time on what was our first visit to Japan. I should blog some more about it, but now I will give in to the jet lag and catch up on some sleep...

A topic I've been trying to understand more about for some time is color calibration. I've used lprof to get a very rough starting point for my old CRT (sorely in need of replacement by now...) Since hardware colorimeters are not cheap and probably not many can be used with Linux (I've not really looked, to be honest) I've wondered if I couldn't use the one device that is (should be) calibrated that I already have: my camera. With some kind of feedback loop like shoot screen, analyze img file, adjust settings, shoot again (and the same process for the printer, and, possibly a bit more error prone since the freshly calibrated printer would be used to produce the template, the scanner), shouldn't it be possible to arrive at sane settings? The camera explicitly allows using sRGB or Adobe RGB color model, so I'd think the colors should be more or less narrowly defined, at least when shooting raw or using manual white balance. (Another thought: I have a dual screen system. Can X even do this? And if X can do it, is it possible to tell Gimp to set this up? But this is just idle speculatio. I've not really looked at Google's results yet, either.) Update: Haven't really thought about ambient light. But the display emits light, so I'd shoot the screen in a darkened room, with white balance of the camera set manually. OTOH thanks Jo l if I can get a colorimeter for not much above 100$, it's not worth investing too much time. I had always thought these devices were much more expensive. divide_by_zero Yes, I know CRT are usually much better than LCD, but OTOH my screen apparently starts to show its age: it will suddenly, and visibly, change brightness and color every few hours. I suspect the high voltage circuitry is not too stable anymore... And I won't buy another CRT, those things are just huge...

Humm... Has anybody else seen a pattern like this? I am getting a flurry of root login attempts at my main server at the University since yesterday 7:30AM (GMT-5). Now, from the machines I run in the 132.248.0.0/16 network (UNAM), only two listen to the world with ssh at port 22 And yes, it is a very large network, but I am only getting this pattern on one of them (they are on different subnets, quite far apart). They are all attempting to log in as root, with a frequency that varies wildly, but is consistently over three times a minute right now. This is a sample of what I get in my logs: [update] Logs omitted from blog post, as it is too wide and breaks displays for most users. You can download the log file instead. Anyway This comes from all over the world, and all the attempts are made as root (no attempts from unprivileged users). Of course, I have PermitRootLogin to no in /etc/ssh/sshd_config, but I want to understand this as much as possible. Initially it struck me that most of the attempts appeared to come from Europe (quite atypical for the usual botnet distribution), so I passed my logs through: The top countries (where the number of attempts 5) are: I am attaching to this post the relevant log (filtering out all the information I could regarding legitimate users) as well as the full output. In case somebody has seen this kind of wormish botnetish behaviour lately please comment. [Update] I have tried getting some data regarding the attacking machines, running a simple nmap -O -vv against a random sample (five machines, I hope I am not being too agressive in anybody's eyes). They all seem to be running some flavor of Linux (according to the OS fingerprinting), but the list of open ports varies wildly I have seen the following: Of course, it strikes me that several among said machines seem to be Linuxes, but (appear to) run Microsoft services. Oh, and they also have P2P clients.

Attachment	Size
Results of parsing the logs	21.58 KB
Relevant portion of the logs	1.05 MB

So, I was reading some random mumblings on the interwebs, and the pigeon with USB stick being a quicker method of data transfer in SA than their intertubes... then there was a thread on a mailing list discussing this, and someone mentioned using stacks of microSD cards... so then my brain decided to launch itself orthogonally, as it often does. What we end up with is wondering just how much storage you could fit in to the space a 3.5" drive would normally take - not taking in to account any method of attaching it at this point. So, a 3.5" drive is approx 102mmx147mmx26mm, a microSD card is 11mmx15mmx1mm, so, assuming that we're just lying them side by side, and not optimising the way they're stored at all, you can fit (with space round the sides) 9*9*26 = 2106 microSD cards in the area of a 3.5" drive. Assuming that each of those is 16G that's just shy of 33.7TB of storage! So, that set me thinking a bit further... I reckon that in that space you could do a 6*6 grid of cards with room for connectors, and just about get it to 10 high...so, that's 360 microSD cards, and probably enough room for some control gear (haven't worked out quite what we'd use for that), I then went in to wondering if we could then create a small embedded system to talk to those 360 microSD cards, if we did that then you could potentially do RAID0 across the "platters" with RAID6 on each platter. Now, to my poor head that meant that there should be 340*16G of available storage, which is 5.44TB... of course, that involves somehow interfacing the 360 microSD cards... I'm thinking that it might be possible with some form of embedded system... Unfortunately, it appears that to actually build this with consumer components... and without including the interface gear which I haven't even begun to work out yet... we're talking around about 26 per microSD card, so, erm, 9360... but I still think it'd be a really neat project... now, if someone can arrange for me to win the lottery, have lots of spare time, and some more brain power... :) Oh dear... my brain appears to have ticked further through, and I've realised that with spacing between each microSD card, you could, in theory, easily fit 400 of them upended in the space available. Erm. Of course, this still doesn't answer the "how the hell do you then get them all to talk in any sane manner" question... but I'm sure that will work out in my head sometime...

Because of the recently announced attack against the SHA-1 digest algorithm, I finally decided to move away from my old 1024-bit DSA OpenPGP key, landing to a shiny new 4096-bit RSA one. The old key will continue to be valid for some time, but I prefer all future correspondence to come to the new one. I would also like this new key to be re-integrated into the web of trust. I'm attaching a file with
the complete text of the transition, clearsigned by both keys to certify the transition. You can find the transition statement also on http://www.hanskalabs.net/key-transition_20090509.txt . You can check the validity of the file with something like:

$ gpg --decrypt key-transition_20090509.txt   gpg --decrypt

If you need to transition your key too, and you're one of my signees, then let's please coordinate, so that we have the new keys cross-signed, without spurious signatures fromgoing-to-be-revoked keys Thank you for your help.

Attachment	Size
key-transition_20090509.txt	4.03 KB

Finally I was able to clean up one of my m68k buildds: Spice. Actually I regularly clean up all of my machines so they continue to work properly. Usually I do this maintenance work every year around christmas, but this time was different. Anyway. I took some pictures:



In fact I assumed more dust inside after 512 days of uptime, but I was suprised that the dust was moderate. So the cleaning was easy and fast. This is the result:



Next and final step was to enable the Laptop mode. Sadly there was no /proc/sys/vm/laptop_mode, but the final solution wasn't that difficult either to have a portable Amiga 3000:



Well, the reason for that Laptop mode is quite simply: although the A3000 is quite silent with its Papst fan, its SCSI/SCA disks aren't. To safe some noise I plan to move the A3000/autobuilder to the guestroom, but when there's some visitors, I want to be able to relocate the machine without interrupting the build. So attaching a UPS and a wireless bridge is the way to go for this purpose.

The people who made the above magazine advert gave it two top-halves to the burger bun. But I think that there is actually a demand for such buns, and that it is possible to make them! Traditional buns have a flat bottom where they rest on a baking tray. One solution to this problem would be to bake in outer space, another possible solution would be to develop a rapid baking process that allows baking in a free-fall aeroplane, but both of these would be unreasonably expensive. It seems that it would be viable to bake double-ended buns by having a rapidly rising column of hot air to suspend the bun. The terminal velocity of a bun would probably not be that high (maybe 60Km/h) and it should be quite easy to have a pipe full of hot air that bakes the buns. As slight variations in the density and shape of the bun would affect the air-flow it would be necessary to closely monitor the process and adjust the air speed to keep the bun afloat. Manufacturing cheap ovens that use LASERs to monitor the position of the bun should not be difficult. This might blow the sesame seeds off the bun, but this problem may also be solvable through careful design of the bun shape to make it less aerodynamic and by strongly attaching the seeds. I m not sure how you would do this.

I usually use this blog to post about stuff I have written or that is somehow related to my work / professional life. This time, however, I'll just use it to share with you a short text my father published in the column he writes in the La Uni n de Morelos newspaper, Academia de Ciencias de Morelos: La Ciencia, desde Morelos para el mundo. My father has lived for over 20 years in Cuernavaca, la Ciudad de la Eterna Primavera (the city of the eternal Springtime), ~80Km south of Mexico City. Cuernavaca was for long years known mostly as a weekend city for Mexico City's middle-upper class, but it has grown way beyond that. According to Wikipedia, in Cuernavaca's metropolitan area there are about 700,000 inhabitants. And the city is blatantly built with no planning, no urbanistic analysis of any kind. I have been familiar for many years with the program to put some rational order renumber Cuernavaca's streets. Roberto Tamariz, the sociologist who built my father's house (yes, in a stroke of genius he acted as an architect for a piece of land he had bought - the results are quite decent, given his real occupation, but his lack of architectural background tends to literally come up from the floor every now and then), was involved in a municipal project to renumber Cuernavaca's streets, probably some 15 years ago. Anyway, Roberto's work was never really finished due to the severe lackings of our political culture. In this (one-and-a-third pages long, quite easy to read) text I am attaching to this post, my father writes about Cuernavaca's strange street naming system, the mathematical solutions (and political intrincacies) about renumbering a two dimensional space (and, of course, he could not help but wander into the third- and fourth-dimentional spaces, although very briefly). I like how this guy writes, all in all. Enjoy!

Attachment	Size
Calles y numeros de Cuernavaca.pdf	231.99 KB