My Dad, Trains and his Signal

I should have realized how fascinated my Dad was with trains at an early age, but somehow I didn't.

When I was tiny - just four years old - he would ask kindly engine drivers at Liverpool Street station to show me round the cabs of their giant steam engines - Britannia and others - that pulled the express trains that would roar through our local station. The vast expanse - as it seemed to a small boy - and the roaring heat of the firebox are impressions I've never forgotten.

Or he'd take me to a nearby bridge to watch the trains go by. He bought me my first trainset when I was five. It was clockwork, with an oval of O-gauge track and two tinplate carriages. It just went round and round but I loved it. I moved up to an electric train - Triang OO gauge - on my seventh birthday. It was a success, because I have loved everything to do with trains ever since.

But I never realized how deep his own interest was until much later. After he retired my Dad would often call phone-in radio programmes, and it was to one of those that he told his own childhood railway story. Money was scarce back then, and toy trains were expensive even for the people who had money. He would have loved one but it was unimaginable. But one Christmas he got as a present a toy railway signal. Just the signal, nothing else - no track, no trains, just the signal.

Signals then were more than just lights. They had a long red arm which moved up and down, its position telling the train driver whether he could proceed or not. Down and horizontal, it meant stop. Up at an angle, meant go. At night, red and green lights shone through colored glass. It was operated by a signalman, in a signal box possibly a long way off. It was his sheer muscle power, transmitted via up to a mile of thick steel cable, that made it move.

For my Dad, the rest of the railway lay just in his imagination. A train was coming, the signal must be pulled to show clear. The train rushes by in a cloud of steam and smoke, the noise deafening, loaded goods wagons banging and bouncing over the joints in the track. Then it has gone leaving only a cloud of dust. The signal must be set to danger behind the train. But wait, there's another one coming, a passenger train, the express. The gleaming engine rushes past, passenger's faces peer out of the varnished carriages. Again the signal must be pulled off, the signalman putting all his weight behind the lever as the heavy arm rises.

But all this was only in his imagination. In reality there was just a small boy and a toy signal, as he moved the arm up and down. After he had told his story on the radio, other people called in to say he'd reduced them to tears.

Retrotech: Nixie Tube Clock

It all started when my friend George gave me a tee-shirt for my birthday, with the internal circuit of a Dekatron counter tube on it. The Dekatron was a 1950s piece of electronic wizardry, capable of counting to 10 with almost no external circuitry, as opposed to the numerous tubes that would be required otherwise. This reawakened my interest in retro-electronics, never far from the surface. A few years back I built several tube (valve) amplifiers, which I still use for daily listening, and I still have a well-equipped workshop for this kind of stuff.

I'll gloss over the Dekatron, since hopefully I'll have something to write about that quite soon. But then one thing led to another and I started looking at things I could do with Nixie tubes. These are about the coolest thing in retro-electronics. They look like normal tubes but inside they have ten electrodes and can display any digit from 0 to 9 in an orange neon glow. When they first appeared, in the late 1950s, they were way too expensive for consumer equipment. They were used in laboratory equipment and the like. My school, in around 1967, had a Sumlock Anita calculator, the first electronic calculator, which used ten Nixie tubes to display its result (and some very clever tube-era electronics to do the calculations).

Now of course LCD displays are cheaper, smaller, and generally more convenient. There's no commercial interest in Nixie tubes. But they are really cool, and there are still lots of them about. The Russian electronics industry carried on making them for a lot longer, maybe even still is. They're available for $5-10 each for the common types. As a bonus, if you have friends who collect stamps, you get all sorts of interesting stamps with them from places like Moldavia and Ukraine.

Retro-electronics is all very well, but to do anything with these tubes you have to give them something useful to display, like the time. And that's where a partnership with modern electronics comes in handy. For one thing they run on around 150 volts. With 1960s technology, that would mean a big, heavy transformer and associated parts. Today, it can be generated with a few tiny components that fit into a square inch or so on a corner of a circuit board using a boost-mode switched power supply circuit.

Powerful microprocessors are now available for a dollar or so, so it's easy to generate something interesting to display. There are several kits on the market for digital clocks using Nixie tubes. I chose one from PV Engineering in England - it had the best looks in my opinion, and it didn't hurt that it is quite a bit cheaper than any others. It took a few days to arrive, and when I opened the package there were six never-used Nixie tubes, an empty circuit board, and a bag of components.

In anticipation of its arrival, I'd already cleared off my workbench - a project that had been waiting for at least a year. So the only thing left was to launch into its construction. I started on Sunday morning, and by an admittedly very late dinner time it was working and housed in the very nice clear plastic box designed for it. I suppose the total actual assembly time was about 4-5 hours. By far the most painful part was wiring the tubes themselves. Unlike most vacuum tubes they have wire ends which have to be individually soldered into place, and there are eleven of them (necessarily) on each. Actually there are 13, because two aren't used and have to be cut off. This is a bit nerve-wracking the first time, it would be so easy to cut off the wrong wires and be left with useless tubes. The total number of solder joints to be made is probably about 500, of which roughly half are for the tubes themselves and their associated wiring. But the instructions are excellent and make it easy to do everything step by step and even test things along the way.

A Nixie-tube clock all by itself would be neat, but since it's controlled by a computer (one of the omnipresent PIC range - there are probably a couple of dozen in every car) it can do a lot more. At 50 seconds past every minute the digits all flash and spin, and it shows the date for a few seconds. There's an alarm clock. Underneath each tube is a three-color LED, with a nifty light tube made of shrink-wrap that shines up into the glass base of the tube. The color can not only be set, it can be set differently for each hour of the day and can be made to change slowly or quickly through the whole spectrum. It comes with a tiny GPS receiver which can be stuck onto a window and which ensures that it always shows the right time and date, even after a lengthy power outage. I wish all the other myriad household devices that include superfluous clocks were half as smart.

For now it's still sitting on my bench while I decide where I want it. It indeed looks very cool.

Update, April 2025

More than ten years later, my Nixie tube clock is still very much in use. Or rather, is again in use.

After about four years it stopped working, just showing random values in the display. A quick mail to the supplier got me instructions for a complete reset, which did the job. But the GPS receiver had stopped working too, so every time the power was interrupted it had to be manually reset. This is quite complicated and the result was that I just stopped using it. I put it away somewhere and that was the end of it. Then we moved to France, and with the chaos of unpacking into a new home I couldn't even say where it was.

A few months back I was looking for something else, and came across it. I plugged it in, and it worked - though still without GPS time. But I discovered that if I hung the GPS receiver out of the window of my office, after a few minutes it would synchronize. We wanted to put it in the living room though, in a place where there is no access to a window.

I'd been looking at the supplier's website, and I saw that he now has an NTP receiver. NTP is the universal internet time service, used by all computers to get the correct time. This tiny module connects to the home WiFi network and listens to NTP.

I also bought a 220 volt power supply. With the two of those installed, my Nixie clock now has pride of place in the living room.

Choosing a Linux Distro for an Embedded System

Many years ago, when my old employer Digital Equipment Corporation was trying to stave off the advance of Unix, it came up with the slogan "Unix ain't Unix". In other words, there were a lot of systems at the time (around 1988) that all called themselves Unix, but which in fact were all different - in management, in commands, and in the APIs they supported.

Fast forward to 2013, and Linux is really the only Unix that matters any more. (Yes, I know about BSD - more later on that - and I stand by my statement). But the statement "Linux ain't Linux" applies with just as much truth.

I've been using Linux as my main development environment for a couple of years now. I started with Ubuntu 11.04, for no better reason than I happened to have a DVD of it. It was a pretty decent system - it stayed up for weeks at a time and had a usable Windows-ish GUI. If only that were still true. Recent releases of Ubuntu rarely stay up for more than a day or two at a time, typically before the window manager dies leaving the rest of the system ticking away but completely unusable. And of course they made the incomprehensible decision to replace Gnome, which is dull but functional, with Spirit.  (There's an old - c. 1780 - and rather delicious quote that "Englishwomen's shoes seem to have been made by someone who has heard shoes described but never actually seen any". Ditto with Spirit and the Mac). The first thing I do whenever I bring up a new Ubuntu system is to replace it with "Gnome Classic". (The latest version of Gnome in turn seems to have been developed by someone who has heard Spirit described but never actually seen it).

For the last year I've been developing an embedded system for Internet traffic management and monitoring. From the beginning we've taken for granted that it would run on Linux. The question is, which Linux distro should we use? There are numerous choices: Ubuntu, Fedora, Red Hat, Centos, Arch, Gentoo - and those are just the well-known ones.

For sure Ubuntu is a poor choice. It's desperately trying to be a replacement for Microsoft Windows, and has way too much clutter and extra stuff for an embedded system. We're trying to keep the footprint small, both memory and virtual disk, and we really don't need to have three different GUIs, LibreOffice, three different database systems... you get the picture. So Ubuntu was out from the beginning.

I worked with a company that had selected Gentoo. The advantage of Gentoo is that you get to choose absolutely everything about the system, down to the tiniest details like which implementation of cron you use. The disadvantage of Gentoo is that you have to... do all that. It's true that it will give you an absolutely minimal system, tailored exactly as you need it, but it's a lot of effort, not to mention the learning curve. It might make sense when we're bigger. but right now we need everyone focussed on stuff that will really differentiate us.

Somewhere along the line we looked at BSD - we were using something at the time whose support was much better there than on Linux. What a nightmare! Everything has to be built from source - they have a repository system but it is 'temporarily out of service'. It's truly a system for hobbyists, like Xen.

I looked at Centos, and got as far as installing it on a system. Then I realised that it is rooted so far in the past that I'd almost have to dig out my stock of IBM punch-cards. In particular, it supports a truly ancient version of GCC (4.4 I think). We make extensive use of features from C++11, which means we need at least 4.7. There are ways to have a development environment which is distinct from the system's own build environment, but they look pretty terrifying and weren't something I wanted to try and get my head around - for the same reason I didn't want to become a Gentoo expert.

That left Arch. I'd heard good things about it, and it also tries to be minimalist, so it seemed to be the way to go. I  installed an Arch system without too much trouble, and got our system up an running on it. The only problem was log4cxx, which isn't available as a package and which wouldn't build from source either. Like much Linux software out there, it has a bunch of outdated assumptions about implict include files which don't work with recent versions of gcc. But the changes were simple and we quickly had a version that would build.

Networking in Arch is very quirky. It starts with ethernet devices, which instead of being called eth0 and so on, have names which reflect the PCI heirarchy like 'ep5d3'. It's a nuisance but not a major problem. But then it turns out they selected a completely different way to manage networking than other Linuxes. User administration is completely different, too. I'm sure the answer would be "but you can always build whatever you want and do it your own way." True, but not especially helpful.

Anyway, we persevered with Arch, and got our systems running. It took the passage of time to realise that Arch is constantly changing - as in, every day. An Arch system installed and configured today won't be the same as one installed tomorrow. Anything and everything can change - the kernel, the utilities, the drivers. When Boost 1.53 came out, Arch had it a few days later. Switching Boost versions is not something to be undertaken lightly, and indeed our system wouldn't build - some incompatible change involving locales, themselves a completely incomprehensible feature of Linux.

Our biggest problem came from trying to integrate the Intel DPDK package for high-performance user-space networking. Now, DPDK is essential to what we're doing. But  it is hardly a model of stability either, with a new version coming out practically every week. The combination of this with the ever-changing sands of Arch, especially kernel changes, just made it impossible to keep up. If we got things working on Monday, they'd be broken again on Tuesday.

We looked into somehow selecting our own stable intercept of Arch. In a VM environment, it's easy enough to build a master VM and just use that. But our system also has to run on bare metal, which is not so easy. There is, supposedly, a way to take a snapshot and make a private repository. But once again, the investment in time is just not something a tiny group like ours can afford to make if we are to ship a product in a reasonable time.

And so, with great reluctance, I made the decision last week that we will ship our product on Ubuntu. I know that it is really not the right choice for an embedded system. But it works, and it doesn't change on a daily basis. We're used to its quirks, like yet another gratuitously incompatible set of network configuration tools. Hopefully we'll have the luxury of re-examining this later on when we have more people and more time to look at it.

How to identify a string using regular expressions

A problem that crops up from time to time is to identify which of several possible strings matches a given target. For example, the list might be apple, banana, cherry, date, elderberry, fruit, grapefruit, ... Of course for a short list, just about anything will work fine, including just serially comparing with each of them. If the strings are an exact match, a tree or a hash table will work. It gets more complicated, though, if only a partial match is required, for example to identify which of the list of fruits is contained in the target. The general case is where each of the possible strings is an arbitrary regular expression, i.e. '.*apple.*', '.*banana.*' and so on.

There are well-known algorithms for constructing a suitable search tree, but they don't form part of any conveniently available library that I'm aware of. And they are extremely subtle and complex, especially if you want to accommodate the full power of regular expressions - which means that you'll probably get it wrong in some subtle and difficult to test way if you try to code it yourself.

On the other hand, every system has regular expressions - even C++ in the latest version. It seems fairly obvious to concatenate all the matching strings into one giant regex, separated by '|', and let the regex engine do the work. It surely implements one of the well-known algorithms and has been fully tested. What could be simpler?

Well, except that no regex system I'm aware of gives you an easy way to find out which substring you matched. It will tell you that one of the fruit names is somewhere inside the string, but not which one. It would be nice if there was some way to tag each of the alternatives and then retrieve the tag of the one that matched - but there isn't. You can retrieve the pattern that matched, or part of it, but that just gets you back to where you started.

This problem cropped up again recently for me, in this case matching URLs described by regular expressions. And this time, I thought about it long enough to find a solution, which is to say a way of getting the regex engine to tell me which substring it had matched.

Let's suppose, just to keep the examples simple, that there are fewer than 100 possible strings. As you will see, the technique can be extended to any possible number, but you do need to know an upper bound when you start.

First, append the string '#0123456789,01234567890' to the target string. '#' can be any character or longer string that you are sure will not appear in any of the possible matches.

Next, append to each of the match targets a string like '#.*?(2).*?,.*?(6).*'. The '2' and the '6' in the example should be replaced in each case by a number uniquely identifying the string in question. This is a mildly tricky regex (compared to some of them!) which functions as follows.

• the leading '#' just ensures that this won't accidentally match anything it shouldn't.
• .*? will match anything until it finds a '2'. The '?' says that this string should match as little as possible. Without it, the engine would try to match to the furthest '2'. If there are several digits, this would require it to back up several times during the matching process, and would be seriously time-consuming.
• (2) will match only the digit '2', and, most importantly, will capture it as a substring which can subsequently be retrieved. We know the '2' will be present, because we put it there ourselves.
• The following '.*?,' matches everything up to and including the following comma. 
• The following unit repeats the process to capture the '6' from the second group of digits.

For practical use there would be more digits, each repeating the first unit from the example.

Once the string has matched, all regex systems provide a way to retrieve the captured digits, which can then be assembled to get the identifier of the matched substring. In C++, a 'smatch' structure holds the result including the matched substrings. The following code snippet shows how it is done in C++.

int identify(const string &target)

{

    static string digits("0123456789,");

    string t(target);

    for (int i=0; i<digit_count; ++i) {

        t += digits;

    }

    smatch m;                    // structure that holds parse result

    if (regex_match(t, m, master_regex)) {

        string id_str;

        for (int i=0; i<digit_count; ++i) {

            id_str += m[i+1];    // retrieve and append successive digits

        }

        return lexical_cast<int>(id_str);

    } else {

        return 0;

    }

}

Et voila!

The short but happy (and rapid) life of Hercule "Purr-o-matic" Poirot, RIP

Adieu Hercule. It was a short life but a happy one. Born, maybe early May 2012. Died some time in the night of 17/18th June 2013, instantly and in the only too common way for cats, hit by a car.

When our first cat, Lewis, died in February 2012 after a long illness, we were so sad that we didn't really think about getting another cat.  Then in July, we learned of someone who had rescued a litter of feral kittens and their mother. We visited, and saw five beautiful kittens. Finally we chose two of them, a black male with a tiny white patch exactly where a bowtie would go, and a three-colour female. We brought them home - they were so tiny that both fitted comfortably in one cat bag. Once home, they cowered in a corner of a bookshelf in the room we'd set aside for them.

It took us a long time to find names for them. We wanted something that was he-and-she pair, but nothing we came up with really suited them. It was weeks before we thought of Hercule Poirot and Miss Marple, always abbreviated to Missy, names which seemed to suit them very well.

Hercule was always the bold one. Missy spent her first days with us cowering on the bookshelf, or hiding behind the books - she developed an amazing talent for hiding herself which she retains even now, despite being several times bigger.

But Hercule was soon exploring everywhere in the house. He grew fast - after our experience with Lewis I weighed them regularly and kept a chart, so I could see how quickly he was gaining weight.

It took only the slightest thing to make him purr. Just looking at him was enough. We called him "Hercule Purr-o-matic Pussycat".

As he grew up, he became more and more like Lewis. It was as though, from somewhere in pussycat paradise, Lewis was advising him. We fed them both slices of beef, calling it rat in the hope they'd get a taste for it. But soon Hercule would eat nothing but prawns, Lewis's favourite treat - well, and his usual dried catfood of course. In so many ways he seemed to be copying Lewis.

He was a hunter - his sister too, and we mostly didn't know who had done the hunting. They often showed signs of their feral background - Hercule with his hunting, Missy with her ability to hide.

At the back of our house is a stream, usually dry. It's possible, though tricky, for humans to cross it, but nothing for a cat. Just the other side is the garage of a neighbor's house, and under the floor there is a space easily big enough for cats to hide in. It became their second home. Usually when we came home in the evenings we'd call and they come running across our back fence.

Sometimes, especially lately, they waited for us to come to them. My fondest memory of Hercule is him sitting on the opposite bank, looking at me curiously, his eyes bright, his pretty white bowtie shining through the leaves. I never did manage to take a picture of him there, he'd run off before I could reach for my camera.

He ran everywhere, all the time. He never walked. Even going through his catflap he ran - we worried if that ever it was locked, he'd hurt himself. While we were eating breakfast, he'd run to the little dish of cream, sniff it, run somewhere else, run back, lap up a little, run off, run back... we joked that he wasn't really black, it's just he ran so fast that the photons couldn't keep up.

Just two weeks ago, Missy came home one evening with what turned out to a broken femur. She had surgery and as I write this she's still limping with a huge shaved patch on her left flank.

He was always too busy to be really affectionate - sometimes he'd accept a cuddle for a few seconds but then he'd be off somewhere on an urgent mission. But when he was snoozing during the day he was always very happy to have his tummy tickled. He'd roll over and stretch out, purring noisily as I ran my hand up and down his belly. He'd even make a Moebius, his tail pointing the opposite way to his ears - another sign of Lewis's influence. That's my last memory of him, late yesterday afternoon. Then he remembered an important appointment and ran outside. The next time I saw him - broke my heart.

Last night I saw neither of them all night long - which is unusual. This morning Missy was around, but when I called "Hercule, cream" - which always brings him running - there was nobody else. I found his poor dead body in one of the streets the other side of the stream. It's not a busy street, but I suppose a black cat, at night - and of course he was certainly running.

We have no idea what this will mean for Missy, his inseparable sister, together since they were born and rarely far from each other. We hope she won't be too sad, but nobody understands the social life of cats.

So, adieu, Hercule, Purr-o-matic Pussycat. We hope at least that you've found Lewis up there in pussycat paradise.

On typename - and why C++ is a parser's nightmare

If you've done any significant C++ programming using templates, you'll certainly have run into the annoying rule requiring you to write "typename" before constructs of the form "class::member" if the class is actually a template parameter. For example:

template <class C>
class foo
{
     typedef typename C::value_type value_type;
};

If you miss out "typename" the compiler will complain. What's more, if it's GCC it will complain in a completely mysterious fashion, giving you no clue as to what the actual problem is.

And yet, surely it's obvious that this must be a typename? Why require all those extra keystrokes and visual clutter for something which is obvious? Every now and then I'd wonder about this, and read something which described the obscure situations where it isn't obvious. But I'd promptly forget, until the next time I spent ages pondering over unhelpful error messages until the little light came on - "aha, it wants a 'typename'!".

There's a good explanation of why actually it isn't obvious, to the compiler at least, here. But it took me trying to explain C++ parsing to someone for me to really get it.

C++ teeters on the hairy edge of total ambiguity the whole time, without you even realising it as a user. And one of the worst culprits is the apparently innocent reuse of the less-than and greater-than symbols as template brackets. Consider the perfectly clear snippet:

foo<bah> foobah;

It's blindingly obvious that this is declaring 'foobah' to be an object of class 'foo' instantiated with 'bah' (presumably another class) as its template parameter.

Well, except that if all three names are actually ints, those template brackets suddenly turn into relational operators. It's not a very useful code snippet, but it is syntactically correct. First compare foo with bah, creating a bool result. Then compare that with foobah, having first cast the latter to bool. Then throw the (pretty meaningless) result away.

You don't even need templates. The reuse of '*' for both multiplication and dereferencing can also lead to ambiguity. Combining the two can get exciting:

foo<bah> *fbptr;

Obviously a declaration of a pointer to a 'foo<bah>'. Unless of course foo and bah are both numeric and fbptr is a pointer to a numeric. Then it's a replay of the previous example.

This is all made worse because C++ (necessarily) allows you to refer to class members before they're defined. Consider the following example:

class c1
{
    template<class C> class d1 
    {
        ....
    };
    class e1
    {
        ....
    };
};

class c2 : public c1
{
    void fn()
    {
        d1<e1> f1;
    }
    ....
    int d1, e1, f1;
};

When the parser sees the apparent declaration of f1, everything it knows tells it that this is indeed a declaration. Only later does it come across other declarations that completely change the interpretation. I  wonder how compilers deal with this - it would seem necessary to hold two completely different parse trees and hope that one of them will make sense later. Just to make it more interesting, the class could also go on to redefine the '<' and '>' operators, so they apply to different classes.

Even lowly Fortran IV wasn't immune to this kind of problem. It had no reserved words, and gave no significance to spaces. So when the compiler saw:

DO 100 I=1

which is obviously the beginning of a DO statement (equivalent to 'for' in C++), everything hinges on the next character. If it's a comma, this must indeed be a DO statement. But if it's say '+', or there is no next character on this line, then it's an assignment to a variable called 'DO100I' - and of course Fortran also didn't requires variables to be declared, so they could just pop up like this.

I'm glad I don't write compilers for a living!

The End of The Russian Triode Saga

Today I sent my last package of Russian triodes, ending a saga which began 15 years ago at an audio tradeshow in London.

In 1997 I bought my flat in London - the best investment I ever made. I looked for an audio system, and rather to my surprise discovered that everything they said about valve (vacuum tube) amplifiers was true - they really did sound a lot better. I bought a valve system for London, and was then so dissatisfied with the system I had at my main home in France that I set about creating a system there too. That led me to build the extraordinary and wonderful Atma-Sphere MA60 transformerless (OTL) valve amplifiers, and to spend a lot of time investigating all the possibilities of this new-to-me but very old technology.

Somewhere along the line, I became fascinated by the massive Russian 6C33C-B power triode. This was built like the proverbial tank - with good reason, since that's almost where they were used. Supposedly they were built as voltage stabiliser valves for use in Mig jet fighters. Somewhere on the web I indeed saw a picture of some Russian avionics with one of them in it, so I suppose it's true. They're huge, and can pass a continuous current of over half an Amp. This is amazing for a valve - they are really high-voltage, low-current devices (high-impedance in electrical terms). Getting one to pass this kind of current, at a fairly low voltage, requires some very special engineering. For driving loudspeakers directly, without a transformer to turn volts into amps, they seem like the perfect device.

They've been used in a few commercial designs. Atma-Sphere at one time sold an amplifier using them. A company called BAT - which I think is still in business - had another. But - so the story goes - it's difficult to get them to work reliably. This must have been very reassuring to the Mig pilots.

I went to a high-end audio show in London, and got talking to the UK importer for the Sovtek Russian valves. He offered me a great price on the 6C33C if I bought a box of 50 of them. As it happened, I'd just seen somewhere that the factory in Russia had just realised the value of what they were making and were planning to increase the price - like by a factor of ten. At that time you could buy them direct from Russia for about $10 each.

"Aha," I thought. "I can get enough for my own projects, and make a tidy profit selling the rest when the price goes up". We talked some more and eventually I agreed to buy his whole stock of 400 valves, for a really excellent price. I wrote him a check, shook hands and that was that.

Several weeks later, a delivery truck showed up at my home in France. I couldn't believe my eyes! I had no idea that these things were so enormous! Each one came in a cardboard box about eight inches long and four inches square, beautifully protected by foam spacers and more cardboard inside. There were eight huge cartons, each one about two feet on each side. I stacked them all in the garage - where fortunately I had plenty of space - and started to wonder what on earth I was going to do with them.

I looked around at the pricing on the web, and decided I could sell them at a decent profit and still be cheaper than anyone else. I wrote an advert and put it on my own website - in 1997 running a website was a lot more complicated than it is today.

The response was modest, to say the least. I sold a handful during the remaining couple of years I lived in France. So when I moved to California in 2001, I still had my eight huge cartons. Well, mostly. They'd been tucked away in a back corner of the garage, where a combination of humidity and mice had reduced one of the cartons to crumbs, and several of the boxes inside as well.

Once in the US, I had more success. I was selling them way cheaper than the only other supplier outside Russia, and I had a special deal on a whole carton of 50. This made practically no profit, but my main goal was to get rid of them, not to make money. In fact any possible profit was wiped out by the storage I ended up renting so they didn't take up all the available space in my garage.

I think I sold four complete cartons like this. One led to the best pasta I've ever eaten. A guy in Japan bought them, and since I happened to be in Tokyo around that time we got together. He took me to a tiny place in a basement somewhere near Ebisu station where I had the most marvellous tagliatella carbonara ever, a melt-in-the-mouth creaminess that I've never experienced anywhere else.

It may seem surprising that the best Italian food should be in Tokyo, but it isn't really. The best French meal I've ever eaten (including living in France for ten years) was there too, as well as the best French patisserie. When the Japanese copy something, they do it extremely well!

I was amazed by the number of people who'd inquire about them, often sending several emails, and then just not place an order. But I guess it's the same as when you sell a car, and people spend ages on the phone asking every possible detail, and don't show up as arranged. Some people must just have far too much time on their hands.

The pile of boxes in the storage gradually shrunk. Then one day I took my car for service and got a huge pickup truck as a rental. (This was quite common, the local Enterprise offloaded whatever they had for these one-day rentals. I had a Cadillac deVille once, too. Verdict: interesting but don't sell the Audi). I realised the pile had shrunk enough that it would fit in the garage, and emptied the storage.

The pile continued to dwindle, until finally there was just one carton left, plus a few mouse-nibbled boxes that I was keeping for myself. Then, on May 5th 2013, someone ordered eight of them. This left only a dozen, which I'm keeping just in case I ever want to build a mega-transformerless amplifier with them. It's not likely, but then that's true for an awful lot of stuff I keep just in case. And I'be annoyed if I did want some, and had to buy them at the current retail price of $75.

So that's it, the end of the Russian triode saga. Now, does anybody want any 6CW4 Nuvistors by any chance? They do take a lot less space, but I have 100 of them...