Avian’s Blog

Peek&poke is a retro computer club and a vintage computer museum in Rijeka, Croatia. They celebrated their first anniversary yesterday. I went with Dunja and Martin from Cyberpipe's computer museum to take part in the festivities.

Here are some highlights from their large collection:

Despite its appearance, Timex Sinclair 1500 is closer in capabilities to the original ZX81 than ZX Spectrum. Not surprisingly, it wasn't a big commercial success.

And speaking of Sinclair, they also have the infamous C5.

The collection also includes a number of computers from the former Yugoslavia, although they are in minority. When you look at the specs one thing becomes apparent: it looks like a popular approach to future-proofing computer designs was to include support for several processor architectures. This Croatian Ivel Ultra for example can run software written for MOS 6502 and Zilog Z80.

I've seen plenty of obscure systems, like this Didaktik M from Czechoslovakia. It's another Sinclair clone.

Even the sheer number of calculators they have is impressive, and I'm told that only a part of their collection is in the exhibit.

Last but not least, here's an interesting IBM laptop (Thinkpad 701 "Butterfly") with a folding keyboard so that it's wider than the base when the computer is in use but shrinks to fit inside when you close the lid. (watch the video at YouTube)

Yesterday was this year's European Researchers' night. I went to University of Ljubljana's Faculty of Chemistry and Chemical Technology to an evening of interesting experiments from the world of chemistry and physics.

In an hour and a half prof. Ivan Leban and his assistant showed the audience some of the things that make science interesting. The demonstrations ranged from simple try-this-at-home like how to make hydrophobic sand or how to achieve low temperatures by adding salt to ice to more interesting do-NOT-try-this-at-home like how to make kitchen salt from sodium and chlorine or what happens to a tennis ball chilled in liquid nitrogen. I held a lump of dry ice in my hands for the first time.

It was a nice, relaxed evening that reminded me a bit of high school (and made me realize just how much chemistry I forgot since then). I liked the fact that between the experiments we heard some purely practical advices like why you should read the instructions on your washing detergent and how to use a carbon-dioxide fire extinguisher. The audience was mostly kids with parents and I got the impression that it were the children that dragged the grownups there, not vice-versa. I was pretty surprised how much these kids know when they were asked how they would find melting points of various metals on the internet.

I guess my only complaint would be that explanations of some of the experiments could be a bit more detailed. I know that this was all just for fun, but given the audience maybe it would be nice to give the kids some more encouragement to repeat some experiments themselves and that they do not need to believe everything they are told. I'm also not sure that all people got the joke that scientists newer repeat successful experiments.

All in all, I think there should be more events like this.

Last time I took a break from the surgical work and had a peek into the only part of Pleo that can be accessed without using a scalpel.

This is how the green egg charger looks like inside. It's more complicated than I thought. Actually I was expecting to see nothing at all inside the egg shell. It's not unusual for a simple 1/10 C charger to be completely hidden inside the power brick. On the other hand this appears to be a bit more complicated than that.

It's fully analog. J2 looks like a diagnostics connector. In the upper right is an 33340 NiMH fast charge controller which is most likely the central point of this circuit (Pleo uses a 7.2 V 2200 mAh NiMH battery pack). The rest looks like a switching constant current regulator.

The conclusion is that as far as I can see this charger would run fine on any plain 12V power supply and doesn't need the exact power brick that came with it (which is nice, since the original runs on 110 V and requires a bulky transformer to operate on this side of the Atlantic). Be warned though that I haven't tried that yet.

I started working on Piki's neck today.

To access the machinery that moves his neck I had to first remove the skin. There are no obvious means of doing that (removing the only visible screws on his feet didn't have any worthwhile effect). Since I want to leave as few visible marks as possible I spent some time choosing the spot where to start cutting the rubbery skin.

Closer inspection revealed a stitch running around the neck, above the shoulders and over the back. This seemed like a natural way to proceed. It was pretty easy to make clean cuts in the rubber with a scalpel around the stitch.

Well, it turned out that this first cut was the only thing that was easy about it. Removing the skin from the head was slow business. It's well glued to the framework around eyes, ears and nose. To avoid damaging anything I had to slowly separate the skin with a small blade from the inside. It took me the better part of the afternoon to do that.

Skinning the front half of the torso was easier. The rubber is flexible enough so I could pull out front two legs without any more cutting. I stopped there for now. On the belly the skin seems to be fixed to the plastic around the on/off switch and the battery hatch and I can see no obvious way to access it from the inside to cut off the glue.

So, currently I have clear access to what appears to be the front gear box. It looks like the servos for controlling the neck are there - it's now obvious that one of the thin steel wires that connect the neck to the servos has snapped. I hope I won't have to dig any deeper. Even now I'm a bit less optimistic about being able to restore Piki to his full health.

Stepping back for a moment, the sheer amount of stuff that is crammed in this little creature is amazing. There is not a cubic centimeter of space left inside and it's obvious that service access was left out of the list of design goals. Together with skin cutting this job is really starting to look like a surgeon may be better at it.

Another thing I'm starting to wonder is how do they manufacture Pleos? With this kind of complexity (and no larger standard parts like servos, etc.) it seems impossible that any kind of automatic process is involved. Or if it is, I guess we can expect the world to be soon taken over by UGOBE's self-multiplicating robotic overlords.

The other possibility seems equally improbable. Is it really possible to hand-manufacture something like this for less than $350?

Software is broken. No, really.

Ask any self respecting software engineer and he'll tell you that software never breaks. It can't wear out in the same way a mathematical equation never degrades over the years of use. The same person is usually quick to add how much he hates the hardware his perfect programs run on. Hard drives always fail when you need them, CPUs overheat and fan bearings seize.

Why is it then that software failure has become so ubiquitous in our lives, that a catastrophic failure in most systems does not even fall under warranty terms, while hardware is guaranteed to work for at least a year without errors or your money back? Why must basically every device today have a little button that says "reset" (or else you curse it because then that same common operation involves removing a battery or pulling the plug). Watchdog timers are common, a mechanism where imperfect hardware helps infallible algorithms do their job. I'm sure the possibility of data loss due to some software bug is several orders of magnitude higher that that of hardware failure.

Photo by Chris Shrigley CC BY 2.5

The software itself may indeed be immune to wear and tear (although even that could be debated), but its human authors are all but perfect, especially when faced with the immense complexity that is common today in software engineering. In contrast to physical products, software is usually equally broken when it's brand new as when it's of a ripe old age.

Complexity is causing all of these problems. Vast majority of production versions of software today should fall under the label of crude prototype. Engineering means understanding what you are doing. Software engineers do not understand their creations. Not with all the layers of abstraction, from high level programming languages, to underlying operating systems and complex CPU instruction sets. Even if you're writing low-level assembly, chances are you can't predict exactly how your code will execute on a user's PC. And given the reliability of embedded software in consumer electronics it looks like that's impossible even when you know exactly what hardware the program will run on.

High-level programming languages have made this problem worse. They give the programmer a false sense of security. It was way too easy for a C program to outgrow its creator's capacity to comprehend all its possible execution paths. It's stupidly easy to do that in Python. Latest trend towards web applications sounds like a bad joke in this respect. Industry that isn't capable of creating reliable consumer software that runs on a single computer wants to move to systems that span thousands of interconnected processes.

Physical systems do not tend to grow that large because production costs rise fast with complexity. Software has no production costs, only design and prototyping. And even then majority of design is usually skipped in favor of getting a semi-working prototype out on the market as soon as possible. The lack of documentation and write-only code is a running joke that comes true way to often.

Code reuse is seen by some as a holy grail that will solve this problem. The theory is that you use a library of well checked, proven code instead of rolling your own, probably flawed solution to a common problem. In practice however, this usually means that such code is used without understanding its full behavior and side effects, even when they are properly documented. It also makes it easier to make a blind assumption that someone else did his homework properly so you don't have to. In short, it makes the software author think he's actually in control.

This is not a technological problem and as such can not be solved purely by technological means. Software is still a novelty. Most users will fall for the shiniest, best advertised product, not for the one that will serve them best. Sadly, shiniest is usually the one with most features and hence the most complex and unreliable. Hopefully this will slowly correct itself when market gets more educated and computers stop being magic dust to most people. It's shockingly apparent that today in a lot of cases the final users are the ones that have the worst ideas about what functionality the product should have.

The software industry should also get its act together. It should have the courage to resist the vocal minority of users demanding thousands of new features and focus on providing simpler software that will work for the silent majority. Bugs should not be seen as an unavoidable problem. The engineering community should learn to respect simple, reliable solutions, not the most clever. Engineers should get a firm grasp of the complexity of the systems they are working on, even beyond the lines of code they themselves have written.

And finally new developer tools that aim to help this situation should focus on revealing the underlying complexity, not hiding it. They should help writing better software, not help writing more software. Rapid application development should become a thing of the past.

I needed a small glass bulb for some little project of mine. Since I couldn't find one that would fit my requirements I bought a bag of 20 mm test tubes at the local lab supply store and started looking around the internet for glass cutting how-tos.

It turns out there is quite a lot of information about that floating around. There are also several demonstrations on YouTube

Here are my comments on using these techniques for cutting a 60 mm piece of a 200 mm long test tube (diameter 20 mm, I guess it's borosilicate glass).

• Make a small scratch, then bend and pull until it snaps: Doesn't snap, possibly because the short end doesn't allow you to stress the tube enough. It turns out test tubes of this sort are much harder to break than I previously thought.
• Make a small scratch and apply a red-hot piece of iron on it: Tube breaks, but the break is pretty random and doesn't follow the circumference of the tube evenly. Pretty useless for my purposes.
• Make a scratch all the way around the tube and heat it with a hot wire: After some practice this one turned out to work perfectly. If you position the wire exactly on the scratch, the tube will break in a clean line.

So yes, it's perfectly possible to do this in the home workshop. I didn't use any special equipment (even the scratches were made with a tungsten carbide cutting tool for use in a metal lathe). Against my expectations I was even able to anneal the sharp corners with a cheap propane burner.

Today a beam of protons has made a full circle around the Large Hadron Collider for the first time.

Yet, we are still here. No large black hole has appeared, Earth was not converted to strangelets, we were not overran by time travelers and no monsters from an alternate dimension took over Geneva.

No particle collisions were actually performed today, since the equipment is still being calibrated. So I guess people that feared all of above won't be able to sleep well for another week or so.

Photo by dominikf CC BY-NC-SA 2.0

LHC is indeed the European Apollo project. And it's just so much impressive if you think that it was not primarily created to demonstrate technological supremacy of one country over another. This is genuine, most basic research, results of which are open to anyone. It's also an immense investment that will not pay back for decades, maybe even centuries.

It's one of those things that give you hope that there are still new frontiers being discovered, albeit in high-energy physics and not outside the Earth's gravity well. And that there are still people willing to support such endeavors.

With the future site for ITER also being in Europe, it's a nice feeling to live on a continent on which new and exciting research is being focused.

Piki is Zemanta office pet. He's a robotic Camarasaurus of the Pleo kind and can usually be seen wandering around the floor, chewing on UTP cabling, waiting belly-up for a fresh battery charge or, occasionally, pondering on the immense intellectual problems, like how to avoid office furniture.

Unfortunately it looks like the office is a pretty rough environment for such a delicate creature. After a couple of months, his skin looks seriously worn out at the main petting spots and, more worryingly, he looks like he has problems moving his neck. After some discussion involving real veterinarians and ad-hoc solutions (which left him with a nasty gash under the chin) it was finally decided that I should have a look.

So, now Piki is relaxing on my workbench and I'm researching the possibilities for his treatment. Right now it looks like one of the wires that move his cervical vertebrae has snapped, but there may be more damage hidden in his belly.

It doesn't look like it will be easy to fix this, at least by this report (Warning: page may be disturbing to baby dinosaurs), but I'm confident that he'll make a full recovery.

A couple of months ago I noticed that the local DIY store sells "flashing lightbulbs" at some discount price (around 4€ if I recall correctly). Since it looked like they could contain a xenon flash lamp I bought one just so that I could play a bit with this interesting component. Recently I got some time to actually take it apart and have some fun with it.

What they are selling as a lightbulb is actually a small electronic circuit that drives a lamp from AC line voltage from a standard E27 socket (similar to common compact fluorescent lights). Here's the circuit from this particular lamp:

A xenon flash lamp is a gas-discharge lamp that can make intense pulses of visible light. This achieved by sending a large pulse of current through the xenon gas. The current, which flows between two main electrodes (A and C on the diagram above) excites xenon atoms which then emit visible light as they return to their ground state. The power source for the burst is usually a charged high-voltage capacitor, which also helps defining the energy of each flash of light.

It would be hard to charge the capacitor to the breakdown voltage, where the lamp would start conducting on its own. So the gas is initially ionized by applying a high voltage spike on a third electrode (B) that is outside the isolating glass bulb. Although this doesn't send any current through the gas itself it creates an electric field around the main electrodes that is strong enough to strip xenon atoms of some of its electrons. This initial ionization then provides a starting point for the main discharge.

So how does this particular circuit achieve that? The main capacitor C2 is charged directly from the mains voltage through a rectifier D1. Together with it a smaller starter capacitor C3 is also charged. After the voltage on it reaches a threshold voltage or around 70V, a small neon lamp NL ignites. This sends current into thyristor Q1's gate, which switches it on. A current pulse travels through the primary winding of a small transformer T1, which produces a voltage spike on the open-circuit secondary. This spike ignites the main lamp, through which the main capacitor discharges, making the flash of light.

After the cycle both capacitors start to charge again and the whole cycle repeats approximately once per second. How this period is calculated is left as an exercise for the reader.

That's it for now. Next time: how to modify this circuit to do something more interesting.

I use SpeedyCGI to run some of the Perl CGI scripts on tablix.org (like the comment support on this blog). It helps to keep the load down on my little server and is generally considered a good thing.

While I was away however it stopped being so nice and spawned hundreds of processes and ate all the available RAM. You may have noticed that since some of the pages were returning 500 internal server error according to the server logs.

What was the cause of that?

As you probably know, SpeedyCGI is composed of two components. The front-end process (named speedy) is started exactly like a Perl interpreter. When you run it, it first checks if there is already a back-end process running (named speedy_backend). If so, it connects to it via a socket and a temporary file in /tmp. If not, or if that process is busy, it spawns a new back-end. The back-end keeps a byte-compiled version of your Perl code in memory, ready to be run at the front-end's request. On the other hand if a back-end isn't used for a while it times out and exits.

This system reduces the need to recompile a Perl program each time it is run by a web server and so reduces CPU load and page latency at the expense of a higher memory usage.

In my case logs do not show excessive traffic and one or two speedy_backend processes are usually enough to handle it. After much strace, gdb and poking around process info in /proc I found out that SpeedyCGI got into some broken state where a back-end process was running, but its files in /tmp were deleted. Since a new front-end process now had no idea that a back-end was already running, it started a new one. This new back-end created new files in /tmp. It then ran just fine for a while (hence my problems in finding the cause), until the first back-end time outed and deleted what it thought were its own files. Now the second process was cut-off from the front-end and the whole thing started again.

This resulted in a slow rise in the number of processes, since back-ends were generally left around unused until the timeout and sometimes two were started. With the growing number of orphaned processes the problem got worse since temporary files got deleted more often, which meant even more processes.

The solution:

• Stop Apache,
• kill all speedy_backend and speedy processes,
• delete /tmp/*speedy* and
• restart Apache.

Incidentally, a reboot does the same.

What caused the SpeedyCGI to get into this state? No idea. I haven't looked into the source code enough to get any definitive answer, much less make a patch. A quick search around the web shows that I'm not the only one with this problem, but I haven't found any explanations or solutions. The only thing I remember that may have caused it since the last server reboot is a bug in one of my scripts that caused the hard process limit for the SpeedyCGI's user to be reached (causing fork: resource temporarily unavailable errors), but that was some months ago.