The emperor has no clothes. LLM bots are not artificial and they are not intelligent. Not at all, not even a little bit, not even if you redefine the words "artificial" or "intelligent".  

"AI" is not "AI". The liars and the shills redefined what people used to mean by "AI" as "AGI", artificial _general_ intelligence, so they could market their stupid plagiarism bots as AI. 

AGI is not real. It doesn't exist. It will probably never exist. Hell, at the rate humanity is going, we won't be able to build new computers any more by 2050 and the survivors at the poles will be nostalgic for electricity.

AI is a scam. It's a hoax. It's fake news. There is no AI, and what is being sold as AI is such an incredibly poor fake that it is profoundly disheartening that so many people are so stupid to be deceived into thinking it is AI.

The blockchain is a scam. Everything to do with it is a scam. 

Alternative medicine is a scam. All of it. There is no such thing. If it's called "alternative" that means it's been proved not to work.

All religions are scams. No exceptions. 

People have made billions from selling scams for my whole lifetime.

Meanwhile, other scams, like plastics being recyclable -- they aren't, it's a lie -- or biofuels -- also a lie -- mean our civilisation is on the verge of collapse. We are killing the planetary ecosphere that keeps us alive with plastic and pollution from burning stuff. We have to stop burning everything, stop cutting down trees, and stop making all forms of single-use products. No more jet planes. No more private cars. No more foreign holidays. We can't afford it.

And with all that we are almost certainly still doomed.

But I kind of want to see my industry go first, if all it's got now is AI.

Snag is, I need a job. I have Ada to pay for.

It is one of the oddest things in computing that stuff to me, as a big kid of heading for 60 years old but who still feels quite young and enjoys learning and exploring, that the early history of Linux – a development that came along mid-career for me – and indeed Unix, which was taking shape when I was a child, is mysterious lost ancient history now to those working in the field.

It’s not that long ago. It’s well within living memory for lots of us who are still working with it in full time employment. Want to know why this command has that weird switch? Then go look up who wrote it and ask him. (And sadly yes there’s a good chance it’s a “him”.)

Want to know why Windows command switches are one symbol and Unix ones another? Go look at the OSes the guys who wrote them ran before. They are a 2min Google away and emulators are FOSS. Just try them and you can see what they learned from.

This stuff isn’t hieroglyphics. It’s not carved on the walls of tombs deep underground.

The reason that we have Snap and Flatpak and AppImage and macOS .app is all stuff that happened since I started my first job. I was there. So were thousands of others. I watched it take shape.

But now, I write about how and why and I get shouted at by people who weren’t even born yet. It’s very odd.

To me it looks like a lot of people spend thousands of developer-hours flailing away trying to rewrite stuff that I deployed in production in my 30s and they have no idea how it’s supposed to work or what they’re trying to do. They’re failing to copy a bad copy of a poor imitation.

Want to know how KDE 6 should have been? Run Windows 95 in VirtualBox and see how the original worked! But no, instead, the team flops and flails adding 86 more wheels to a bicycle and then they wonder why people choose a poor-quality knock-off of a 2007 iPhone designed by people who don’t know why the iPhone works like that.

I am, for clarity, talking about GNOME >3. And the iPhone runs a cut down version of Mac OS X Tiger’s “Dashboard” as its main UI. 

(Especially Haiku.)

It may seem odd but it's not.

Haiku is a recreation of a late-1990s OS. News for you: in the 1990s and until then, computers didn't do power management.

The US government had to institute a whole big programme to get companies to add power management.

https://en.wikipedia.org/wiki/Energy_Star

Aggressive power management is only a thing because silicon vendors lie to their customers. Yes, seriously.

From the mid-1970s for about 30 years, adding more transistors meant computers got faster. CPUs went from 4-bit to 8-bit to 16-bit to 32-bit, then there was a pause while they gained onboard memory management (Intel 80386/Motorola 68030 generation) then scalar execution and onboard hardware floating point (80486/68040 generation), then onboard L1 cache (Pentium), then superscalar execution and near-board L2 cache (Pentium II), then onboard L2 (Pentium III), then they ran out of ideas to spend CPU transistors on, so the transistor budget went on RAM instead, meaning we needed 64-bit CPUs to track it.

The Pentium 4 was an attempt to crank this as high as it would go by running as fast as possible and accepting a low IPC (instructions per clock). It was nicknamed the fanheater. So Intel US pivoted to Intel Israel's low-power laptop chip with aggressive power management. Voilà, the Core and then Core 2 series.

Then, circa 2006-2007, big problem. 64-bit chips had loads of cache on board, they were superscalar, decomposing x86 instructions into micro ops, resequencing them for optimal execution with branch prediction, they had media and 3D extensions like MMX2, SSE, SSE2, they were 64-bit with lots of RAM, and there was nowhere to spend the increasing transistor budget.

Result, multicore. Duplicate everything. Tell the punters it's twice as fast. It isn't. Very few things are parallel.

With an SMP-aware OS, like NT or BeOS or Haiku, 2 cores make things a bit more responsive but no faster.

Then came 3 and 4 cores, and onboard GPUs, and then heterogenous cores, with "efficiency" and "performance" cores... but none of this makes your software run faster. It's marketing.

You can't run all the components of a modern CPU at once. It would burn itself out in seconds. Most of the chip is turned off most of the time, and there's an onboard management core running its own OS, invisible to user code, to handle this.

Silicon vendors are selling us stuff we can't use. If you turned it all on at once, instant self-destruction. We spend money on transistors that must spend 99% of the time turned off. It's called "dark silicon" and it's what we pay for.

In real life, chips stopped getting Moore's Law speed increases 20 years ago. That's when we stopped getting twice the performance every 18 months.

All the aggressive power management and sleep modes are to help inadequate cooling systems stop CPUs instantly incinerating themselves. Hibernation is to disguise how slowly multi-gigabyte OSes boot. You can't see the slow boot if it doesn't boot so often.

For 20 years the CPU and GPU vendors have been selling us transistors we can't use. Power management is the excuse.

Update your firmware early and often. Get a nice fast SSD. Shut it down when you're not using it: it reboots fast.

Enjoy a fast responsive OS that doesn't try to play the Win/Lin/Mac game of "write more code to use the fancy accelerators and hope things go faster".   

From a Reddit post. 

     A very brief rundown:

1. If you are using Microsoft tools, you need to load the 386 memory manager, emm386.exe, in your CONFIG.SYS file.

2. But, to do that, you need to load the XMS manager, HIMEM.SYS, first.

3. So your CONFIG.SYS should begin with the lines:

DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICE=C:\WINDOWS\EMM386.EXE
DOS=HIGH,UMB

4. That's the easy bit. Now you have to find free Upper Memory Blocks to tell EMM386 to use.

5. Do a clean boot with F5 or F8 -- telling it not to process CONFIG.SYS or run AUTOEXEC.BAT. Alternatively boot from a DOS floppy that doesn't have them.

6. Run the Microsoft Diagnostics, MSD.EXE, or a similar tool such as Quartdeck Manifest. Look at the memory usage between 640kB and 1MB. Note, the numbers are in hexadecimal.

7. Look for unused blocks that are not ROM or I/O. Write down the address ranges.

8. An example: if you do not use monochrome VGA you can use the mono VGA memory area: 0xB000-0xB7FF.

9. One by one, tell EMM386 to use these. First choose if you want EMS (Expanded Memory Services) or not. It is useful for DOS apps, but not for Windows apps.

10. If you do, you need to tell it:

DEVICE=C:\WINDOWS\EMM386.EXE RAM

And set aside 64kB for a page frame, for example by putting this on the end of the line:

FRAME=E0000

Or, tell it not to use one:

FRAME=none

11. Or disable EMS:

DEVICE=C:\WINDOWS\EMM386.EXE NOEMS

12. Important Add these parameters one at a time, and reboot and test, every single time, without exception.

13. Once you told it which you want now you need to tell it the RAM blocks to use, e.g.

DEVICE=C:\WINDOWS\EMM386.EXE RAM FRAME=none I=B000-B7FF

Again, reboot every time to check. Any single letter wrong can stop the PC booting. Lots of testing is vital. Every time, run MSD and look at what is in use or is not in use. Make lots of notes, on paper.

14. If you find EMM386 is trying to use a block that it mustn't you can eXclude it:

DEVICE=C:\WINDOWS\EMM386.EXE RAM X=B000-B7FF

The more blocks you can add, the better.

15. After this -- a few hours' work -- now you can try to populate your new UMBs.

16. Device drivers: do this by prefixing lines in CONFIG.SYS with DEVICEHIGH instead of DEVICE.

Change:

DEVICE=C:\DOS\ANSI.SYS

To:

DEVICEHIGH=C:\DOS\ANSI.SYS

17. Try every driver, one by one, rebooting every time.

18. Now move on to loadable Terminate and Stay Resident (TSR) programs. Prefix lines that run a program in AUTOEXEC.BAT with LH, which is short for LOADHIGH.

Replace:

MOUSE

With:

LH MOUSE

Use MSD and the MEM command -- MEM /c /p -- to identify all your TSRs, note their sizes, and load them all high.

This is a day or two's work for a novice. I could do it in only an hour or two and typically get 625kB or more base memory free, and I made good money from this hard-won skill.   

I learned about a new DIY machine to me, the Cody Computer. 

First Unix box I ever touched, in my first job, here on the Isle of Man 36Y ago.

It was a demo machine, but my employers, CSL Delta, never sold any AFAIK. It sat there, running but unused, all day every day. Our one had a mono text display on it, and no graphics ability that I know of.

I played around, I wrote "Hello, world!" in C and compiled it and it took me a while to find that the result wasn't called "hello" or "hello.exe" or anything but "a.out".

If I had the knowledge then, I'd have written a Mandelbrot generator or something and had it sit there cranking them out -- but I was not skilled enough. It was not networked to our office network, but it had a synchronous modem allowing it to access some IBM online service which we used to look up tech support info.

Synchronous modem comms, or serial comms, are very different indeed to the familiar Unix asynchronous serial comms used on RS-232 connections for terminals and things. Sync comms are a mainframe thing, more than a microcomputer thing.

https://wiki.radioreference.com/index.php/Asynchronous_vs_Sy...

That modem was a very specialised bit of kit that cost more than a whole PC -- when PCs cost many thousands each -- and it couldn't talk to anything else except remote IBM mainframes, basically.

The RT/PC felt more powerful than a high-end IBM PC compatible of the time, but only marginally. It had a bit of the feeling of Windows NT about 6-7 years later: when you were typing away and you did something demanding, the hard disk cranked up and you could hear, and even feel the vibrations, that the machine was working hard, but it stayed responding to you the same as ever. It's a bit hard to describe because all modern OSes work like this, but it was not normal in the 1980s.

Then, OSes didn't multitask or they did it badly, and things like hard disk controllers of the time took over the CPU completely when reading or writing. So on MS-DOS, or PC-DOS or OS/2 1.x or DR Concurrent DOS, when you typed commands or interacted with programs, the computer responded right away as fast as it could. But if you gave a command that made the machine work hard, like asked for a print preview or a spell-check of a multi-page document, or sorted a spreadsheet of thousands of rows, or asked it to draw a graph from hundreds of points of data, the computer locked up on you. The hard disks span up, you heard the read/write heads chattering away as it worked, but it was no longer listening to you and anything you pressed or typed was lost. Or, worse, buffered, and when it was done, then it tried to do those commands, and quite possibly did something very much not what you wanted, like deleted loads of work.

(Decades later something similar happened with cooling fans, and now that's going away too. But with hearing the fans spin up, there's a hysteresis: it takes time, and tens of billions of CPU cycles, for the CPU to heat up, so the fans come on later, and maybe stay on for a while after it's done. A PC locking up as the hard disk went crazy was immediate.)

The RT/PC was a Unix box. It didn't do that. No idea how much RAM or disk ours had: maybe 4MB if that, perhaps 100-200MB disk. A lot for 1988! But if I did, say,

cd / ls -laR

... then it would sit there for several minutes with the HDD chuntering away, listing files to screen... but what was remarkable was that you could switch to another virtual console and it stayed perfectly responsive as if nothing were happening. That hard disk was SCSI of course, so it didn't use loads of CPU under heavy disk load.

The machine always felt a little slower, a little less responsive than DOS, but it never slowed down even when working hard. You had the feeling of sitting behind the wheel of a Rolls Royce with some massive engine there, but pulling a massive weight, so it didn't accelerate or brake fast, but could just keep accelerating slowly and steadily 'til you ran out of road... and you'd make an impressively large crater.

We sold a lot of IBM PS/2 machines with Xenix, and it was a Unix too and felt the same... but limited by the puny I/O buses of even high-end 1980s IBM PS/2 kit, so it sssslllloooowwwweeeedddd way down doing that big directory listing.

Whereas contemporary PC OSes responded quicker but just locked up when working hard. This included Windows 2, 3.x, 95, 98 and ME, and also OS/2 1.x, 2.x, and Warp. The kernels did not support multithreading and background I/O very well, so it didn't matter that the hardware didn't either.

Then Windows NT 4.0 came along, and it did. Suddenly the hardware mattered. But if you had a Pentium 1 machine, with an Intel Triton chipset on the motherboard, there was an innocent looking driver floppy in the box. On that was a busmastering DMA driver for the Intel PIIX EIDE controller. Install it on Win9x and it could see a CD-ROM on the PATA bus. Handy but not world-shattering.

Install it on an NT machine and once the kernel booted, the sound of the hard disk changed because the kernel was now using busmastering to load stuff from disk into RAM. As the machine booted the mouse pointer kept moving smoothly, with no jerkiness. When the login screen appeared it blinked onto the screen and you could press Ctrl-Alt-Del and start typing and your username appeared slowly but smoothly. The stars representing your password, the same.

It suddenly had that "massive computer power being used to keep the machine responsive" feeling of an RT/PC the decade before. Like that PIIX driver had made the machine's £100 cheapo IDE disk into a £400 SCSI disk.

This is the second, and I very much fear the last, part of my friend Chris "da Kiwi" Thomas' recollections about PCs, Linux, and more. I shared the first part a few days ago.

Having found that I could not purchase a suitable machine for my needs, I discovered the Asus ROG Windows 7 model, in about 2004. It was able to have a RAM upgrade, which I duly carried out, with 2 × 8GB SO-DIMMs, plus 4GB of SDDR2 video RAM, and 2×500GB WD 7200RPM hard drives. This was beginning to look more like a computer. Over the time I used it, I was able to replace the spinning-rust drives with 500GB Samsung SSDs, and as larger sticks of RAM became available, increased that to the limit as well. I ran that machine, which was Tux-compatible [“Tux” being Chris’s nickname for Linux. – Ed.], throwing away the BSOD [Blue Screen Of Death – that is, Microsoft Windows. – Ed.] and putting one of the earliest versions of Ubuntu with GNOME on it. It was computing heaven: everything just worked, and I dragged that poor beast around the world with me.

While in San Diego, I attended Scripps and lectured on cot death for three months as a guest. Scripps at the time was involved with IBM in developing a line-of-sight optical network, which worked brilliantly on campus. It was confined to a couple of experimental computer labs, but you had to keep your fingers off the mouse or keyboard, or your machine would overload with web pages if browsing. I believe it never made it into the world of computers for ordinary users, as the machines of the day could not keep up.

There was also talk around the labs of so-called quantum computing, which had been talked about since the 1960s on and off, but some developments appeared in 1968.

The whole idea sounds great – if it could be made to work at a practicable user level.  But in the back of my mind, I had a suspicion that these ideas would just hinder investment and development of what was now a standard of motherboards and BIOS-based systems. Meanwhile, my Tux machine just did what was asked of it.

Thank you, Ian and Debra Murdoch, who developed the Debian version of Tux – on which Ubuntu was based.

I dragged that poor Asus around the Americas, both North and South, refurbishing it as I went. I found Fry's, the major technology shop in San Diego, where I could purchase portable hard drives and so on at a fraction of the cost of elsewhere in the world.

Eventually, I arrived in Canada, where I had a speaking engagement at Calgary University – which also had a strong Tux club – and I spent some time happily looking at a few other distros. Distrowatch had been founded about 2001, which made it easy to keep up with Linux news, new versions of Tux, and what system they were based on. Gentoo seemed to be the distro for those with the knowledge to compile and tweak every little aspect of their software.

Arch attracted me at times. But eventually, I always went back to Ubuntu –  until I learned of Ubuntu MATE. The University had a pre-release copy of Ubuntu MATE 14.10, along with a podcast from Alan Pope and Martin Wimpress, and before I could turn around I had it on my Asus. It was simple, everything worked, and it removed the horrors of GNOME 3.

I flew happily back to New Zealand and my little country cottage.

Late in 2015, my wife became very unwell after a shopping trip. Getting in touch with some medical friends, they were concerned she’d had a heart attack. This was near the mark: she had contracted a virus which had destroyed a third of her heart muscle. It took her a few years to die, and a miserable time it was for her and for us both. After the funeral, I had rented out my house and bought a Toyota motorhome, and I began traveling around the country. I ran my Asus through a solar panel hooked up to an inverter, a system which worked well and kept the beast going.

After a couple of years, I decided to have a look around Australia. My grandfather on my father's side was Australian, and had fascinated us with tales of the outback, where he worked as a drover in the 1930s and ’40s.

And so, I moved to Perth, where my brother had been living since the 1950s. 

There, I discovered an amazing thing: a configurable laptop based on a Clevo motherboard – and not only that, their factory was just up the road in Fremantle.

Hastily, I logged on to their website, and in a state of disbelief, browsed happily for hours at all the combinations I could put together. These were all variations on a theme by Windows 7, and there were no listing of ACPI records or other BIOS information.

I looked at my battered old faithful, my many-times-rebuilt Asus, and decided the time had come. I started building. Maximum RAM and video RAM, latest nVidia card, two SSDs, their top-of-the-line WiFi and Bluetooth chipsets, sound cards, etc. Then, I got it sent to New Zealand, as I was due back the next day.

That was the first of four Metabox machines I have built, and is still running flawlessly using Ubuntu MATE. 

My next Metabox was described as a Windows 10 machine, but I knew that it would run Tux beautifully – and so it did. A few tweaks around the ACPI subsystem and it computed away merrily, with not a BSOD in sight. A friend of mine who had popped in for a visit was so impressed with it that he ordered one too, and that arrived about three months later. A quick wipe of the hard drive (thank you, Gparted!), both these machines are still running happily, with not a cloud on the horizon.

One, I gave to my stepson about three months back, and he has taken it back with him to the Philippines, where he reports it is running fine in the tropical heat.

My new Metabox arrived about six weeks ago, and I decided – just out of curiosity – to leave Windows 11 on it. A most stupid decision, but as my wife was running Windows 11 and had already blown it up once, needing a full reset (which, to my surprise, worked), I proceeded to charge it for the recommended 24 hours, and next day, switched it on. “Hello” it said, in big white letters, and then the nonsense began… a torrent of unwanted software proceeded to fill up one of my 8TB NVMe drives, culminating after many reboots with a Chatbot, an AI “assistant”, and something called “Co-pilot”. 

“No!” I cried, “not in a million years!” – and hastily plugging in my Ventoy stick, I rebooted it into Gparted, and partitioned my hard drive for Ubuntu MATE.

So far, the beast seems most appreciative, and it hums along with just a gentle puff of warm air out of the ports. I needed to do a little tweaking, as the latest nVidia cards don’t seem to like Wayland as a graphics server, and the addition to GRUB of  acpi=off, and another flawless computer is on the road.

Now, if only I could persuade Metabox to move to a 128-bit system, and can get delivery of that on the other side of the great divide, my future will be in computer heaven.

Oh, if you’re wondering what happened to the Asus? It is still on the kitchen table in our house in the Philippines, in pieces, where I have no doubt it is waiting for another rebuild! 

Chris Thomas

In Requiem 

03/05/1942 — 02/10/2024 

 

 This is interesting to me. I am on the other side, and ISTM that the tiling WM folks are the camp you describe.

Windows (2.01) was the 3rd GUI I learned. First was classic MacOS (System 6 and early System 7.0), then Acorn RISC OS on my own home computer, then Windows.

Both MacOS and RISC OS have beautiful, very mouse-centric GUIs where you must use the mouse for most things. Windows was fascinating because it has rich, well-thought-out, rational and consistent keyboard controls, and they work everywhere. In all graphical apps, in the window manager itself, and on the command line.

-- Ctrl + a letter is a discrete action: do this thing now.

-- Alt + a letter opens a menu

-- Shift moves selects in a continuous range: shift+cursors selects text or files in a file manager. Shift+mouse selects multiple icons in a block in a file manager.

-- Ctrl + mouse selects discontinuously: pick disconnected icons.

-- These can be combined: shift-select a block, then press ctrl as well to add some discontinuous entries.

-- Ctrl + cursor keys moves a word at a time (discontinuous cursor movement).

-- Shift + ctrl selects a word at a time.

In the mid-'90s Linux made Unix affordable and I got to know it, and I switched to it early '00s.

But it lacks that overall cohesive keyboard UI. Some desktops implement most of Windows' keyboard UI (Xfce, LXDE, GNOME 2.x), some invent their own (KDE), many don't have one.

The shell and editors don't have any consistency. Each editor has its own set of keyboard controls, and some environments honour some of them -- but not many because the keyboard controls for an editor make little sense in a window manager. What does "insert mode" mean in a file manager?

They are keyboard-driven windowing environments built by people who live in terminals and only know the extremely limited keyboard controls of the most primitive extant shell environment, one that doesn't honour GUI keyboard UI because it predates it and so in which every app invents its own.

Whereas Windows co-evolved with IBM CUA and deeply embeds it.

The result is that all the Linux tiling WMs I've tried annoy me, because they don't respect the existing Windows-based keystrokes for manipulating windows. GNOME >=3 mostly doesn't either: keystrokes for menu manipulation make little sense when you've tried to eliminate menus from your UI.

Even the growing-in-trendiness MiracleWM because the developer doesn't use plain Ubuntu, he uses Kubuntu, and Kubuntu doesn't respect basic Ubuntu keystrokes like Ctrl+Alt+T for a terminal, so neither does MiracleWM.

They are multiple non-overlapping, non-cohesive, non-uniform keyboard UIs designed by and for people who never knew how to use a keyboard-driven whole-OS UI because they didn't know there was one. So they all built their own ones without knowing that there's 30+ years of prior art for this.

All these little half-thought-out attempts to build something that already existed but its creators didn't know about it.

To extend the prisoners-escaping-jail theme:

Each only extends the one prisoner cell that inmate knew before they got out, where the prison cell is an app -- often a text editor but sometimes it's one game.

One environment lets you navigate by only going left or straight. To go right, turn left three times! Simple!

One only lets you navigate in spirals, but you can adjust the size, and toggle clockwise or anticlockwise.

One is like Asteroids: you pivot your cursor and apply thrust.

One uses Doom/Quake-style WASD + mouse, because everyone knows that, right? It's the standard!

One expects you to plug in a joypad controller and use that.

ARRA was the first ever Dutch computer.
 
There's an account of its creation entitled 9.2 Computers ontwerpen, toen ("Computer Designs, then") by the late Carel S Scholten, but sadly for Anglophone readers it's in Dutch.

This is a translation into English, done using ChatGPT 4o by Gavin Scott. I found it readable and fun, although I have no way to judge how accurate it is.

C.S. Scholten

In the summer of 1947, I was on vacation in Almelo. Earlier that year, on the same day as my best friend and inseparable study mate, Brain Jan Loopstra, I had successfully passed the qualifying exams in mathematics and physics. The mandatory brief introduction to the three major laboratories—the Physics Laboratory, the V.d. Waals Laboratory, and the Zeeman Laboratory—was behind us, and we were about to start our doctoral studies in experimental physics. For two years, we would be practically working in one of the aforementioned laboratories.

 

One day, I received a telegram in Almelo with approximately the following content: "Would you like to assist in building an automatic calculating machine?" For assurance, another sentence was added: "Mr. Loopstra has already agreed." The sender was "The Mathematical Center," according to further details, located in Amsterdam. I briefly considered whether my friend had already confirmed my cooperation, but in that case, the telegram seemed unnecessary, so I dismissed that assumption. Both scenarios were equally valid: breaking up our long-standing cooperation (dating back to the beginning of high school) was simply unthinkable. Furthermore, the telegram contained two attractive points: "automatic calculating machine" and "Mathematical Center," both new concepts to me. I couldn’t deduce more than the name suggested. Since the cost of a telegram exceeded my budget, I posted a postcard with my answer and resumed my vacation activities. Those of you who have been involved in recruiting staff will, I assume, be filled with admiration for this unique example of recruitment tactics: no fuss about salary or working hours, not to mention irrelevant details like pension, vacation, and sick leave. For your reassurance, it should be mentioned that I was indeed offered a salary and benefits, which, in our eyes, were quite generous.

 

I wasn't too concerned about how the new job could be combined with the mandatory two-year laboratory work. I believed that a solution had to be found for that. And a solution was found: the laboratory work could be replaced by our work at the Mathematical Center.

 

Upon returning to Amsterdam, I found out the following: the Mathematical Center was founded in 1946, with a goal that could roughly be inferred from its name. One of the departments was the 'Calculation Department,' where diligent young ladies, using hand calculators—colloquially known as 'coffee grinders'—numerically solved, for example, differential equations (in a later stage, so-called 'bookkeeping machines' were added to the machinery). The problems dealt with usually came from external clients. The head of the Calculation Department was Dr. ir. A. van Wijngaarden. Stories about automatic calculating machines had also reached the management of the Mathematical Center, and it was clear from the outset that such a tool—if viable—could be of great importance, especially for the Calculation Department. However, it was not possible to buy this equipment; those who wanted to discuss it had to build it themselves. Consequently, it was decided to establish a separate group under the Calculation Department, with the task of constructing an automatic calculating machine. Given the probable nature of this group’s activities, it was somewhat an oddity within the Mathematical Center, doomed to disappear, if not after completing the first machine, then certainly once this kind of tool became a normal trade object.

 

We were not the only group in the Netherlands involved in constructing calculating machines. As we later discovered, Dr. W.L. v.d. Poel had already started constructing a machine in 1946.

 

Our direct boss was Van Wijngaarden, and our newly formed two-man group was temporarily housed in a room of the Physics Laboratory on Plantage Muidergracht, where Prof. Clay was in charge. Our first significant act was the removal of a high-voltage installation in the room, much to the dismay of Clay, who was fond of the thing but arrived too late to prevent the disaster. Then we thought it might be useful to equip the room with some 220V sockets, so we went to Waterlooplein and returned with a second-hand hammer, pliers, screwdriver, some wire, and a few wooden (it was 1947!) sockets. I remember wondering whether we could reasonably submit the exorbitant bill corresponding to these purchases. Nonetheless, we did.

 

After providing our room with voltage, we felt an unpleasant sensation that something was expected from us, though we had no idea how to start. We decided to consult the sparse literature. This investigation yielded two notable articles: one about the ENIAC, a digital (decimal) computer designed for ballistic problems, and one about a differential analyzer, a device for solving differential equations, where the values of variables were represented by continuously variable physical quantities, in this case, the rotation of shafts. The first article was abominably written and incomprehensible, and as far as we understood it, it was daunting, mentioning, for instance, 18,000 vacuum tubes, a number we were sure our employer could never afford. The second article (by V. Bush), on the other hand, was excellently written and gave us the idea that such a thing indeed seemed buildable.

 

Therefore, it had to be a differential analyzer, and a mechanical one at that. As we now know, we were betting on the wrong horse, but first, we didn’t know that, and second, it didn’t really matter. Initially, we were not up to either task simply because we lacked any electronic training. We were supposed to master electricity and atomic physics, but how a vacuum tube looked inside was known only to radio amateurs among us, and we certainly were not. Our own (preliminary) practicum contained, to my knowledge, no experiment in which a vacuum tube was the object of study, and the physics practicum for medical students (the so-called 'medical practicum'), where we had supervised for a year as student assistants, contained exactly one such experiment. It involved a rectifier, dated by colleagues with some training in archaeology to about the end of the First World War. The accompanying manual prescribed turning on the 'plate voltage' only tens of seconds after the filament voltage, and the students had to answer why this instruction was given. The answers were sometimes very amusing. One such answer I won’t withhold from you: 'That is to give the current a chance to go around once.'

 

Our first own experiment with a vacuum tube would not have been out of place in a slapstick movie. It involved a triode, in whose anode circuit we included a megohm resistor for safety. Safely ensconced behind a tipped-over table, we turned on the 'experiment.' Unlike in a slapstick movie, nothing significant happened in our case.

 

With the help of some textbooks, and not to forget the 'tube manuals' of some manufacturers of these useful objects, we somewhat brushed up on our electronic knowledge and managed to get a couple of components, which were supposed to play a role in the differential analyzer, to a state where their function could at least be guessed. They were a moment amplifier and a curve follower. How we should perfect these devices so that they would work reliably and could be produced in some numbers remained a mystery to us. The solution to this mystery was never found. Certainly not by me, as around this time (January 1948), I was summoned to military service, which couldn’t do without me. During the two years and eight months of my absence (I returned to civilian life in September 1950), a drastic change took place, which I could follow thanks to frequent contacts with Loopstra.

 

First, the Mathematical Center, including our group, moved to the current building at 2nd Boerhaavestraat 49. The building looked somewhat different back then. The entire building had consisted of two symmetrically built schools. During the war, the building was requisitioned by the Germans and used as a garage. In this context, the outer wall of one of the gymnasiums was demolished. Now, one half was again in use as a school, and the other half, as well as the attic above both halves, was assigned to the Mathematical Center. The Germans had installed a munitions lift in the building. The lift was gone, but the associated lift shaft was not. Fortunately, few among us had suicidal tendencies. The frosted glass in the toilet doors (an old school!) had long since disappeared; for the sake of decorum, curtains were hung in front of them.

 

Van Wijngaarden could operate for a long time over a hole in the floor next to his desk, corresponding with a hole in the ceiling of the room below (unoccupied). Despite his impressive cigar consumption at that time, I didn’t notice that this gigantic ashtray ever filled up.

 

The number of employees in our group had meanwhile expanded somewhat; all in all, perhaps around five.

 

The most significant change in the situation concerned our further plans. The idea of a differential analyzer was abandoned as it had become clear that the future belonged to digital computers. Upon my return, a substantial part of such a computer, the 'ARRA' (Automatische Relais Rekenmachine Amsterdam), had already been realized. The main components were relays (for various logical functions) and tubes (for the flip-flops that composed the registers). The relays were Siemens high-speed relays (switching times in the order of a few milliseconds), personally retrieved by Loopstra and Van Wijngaarden from an English war surplus. They contained a single changeover contact (break-before-make), with make and break contacts rigidly set, although adjustable. Logically appealing were the two separate coils (with an equal number of windings): both the inclusive and exclusive OR functions were within reach. The relays were mounted on octal bases by us and later enclosed in a plastic bag to prevent contact contamination.

 

They were a constant source of concern: switching times were unreliable (especially when the exclusive OR was applied) and contact degradation occurred nonetheless. Cleaning the contacts ('polishing the pins') and resetting the switching times became a regular pastime, often involving the girls from the Calculation Department. The setting was done on a relay tester, and during this setting, the contacts were under considerable voltage. Although an instrument with a wooden handle was used for setting, the curses occasionally uttered suggested it was not entirely effective.

 

For the flip-flops, double triodes were used, followed by a power tube to drive a sufficient number of relays, and a pilot lamp for visual indication of the flip-flop state. Since the A had three registers, each 30 bits wide, there must have been about 90 power tubes, and we noted with dismay that 90 power tubes oscillated excellently. After some time, we knew exactly which pilot lamp socket needed a 2-meter wire to eliminate the oscillation.

 

At a later stage, a drum (initially, the instructions were read from a plugboard via step switches) functioned as memory; for input and output, a tape reader (paper, as magnetic tape was yet to be invented) and a teleprinter were available. A wooden kitchen table served as the control desk.

 

Relays and tubes might have been the main logical building blocks, but they were certainly not the only ones. Without too much exaggeration, it can be said that the ARRA was a collection of what the electronic industry had to offer, a circumstance greatly contributed to by our frequent trips to Eindhoven, from where we often returned with some 'sample items.' On the train back, we first reminisced about the excellent lunch we had enjoyed and then inventoried to determine if we brought back enough to cover the travel expenses. This examination usually turned out positive.

 

It should be noted that the ARRA was mainly not clocked. Each primitive operation was followed by an 'operation complete' signal, which in turn started the next operation. It is somewhat amusing that nowadays such a system is sometimes proposed again (but hopefully more reliable than what we produced) to prevent glitch problems, a concept we were not familiar with at the time.

 

Needless to say, the ARRA was so unreliable that little productive work could be done with it. However, it was officially put into use. By mid-1952, this was the case. His Excellency F.J. Th. Rutten, then Minister of Education, appeared at our place and officially inaugurated the ARRA with some ceremony. For this purpose, we carefully chose a demonstration program with minimal risk of failure, namely producing random numbers à la Fibonacci. We had rehearsed the demonstration so often that we knew large parts of the output sequence by heart, and we breathed a sigh of relief when we found that the machine produced the correct output. In hindsight, I am surprised that this demonstration did not earn us a reprimand from higher-ups. Imagine: you are the Minister of Education, thoroughly briefed at the Department about the wonders of the upcoming computing machines; you attend the official inauguration, and you are greeted by a group explaining that, to demonstrate these wonders, the machine will soon produce a series of random numbers. When the moment arrives, they tell you with beaming faces that the machine works excellently. I would have assumed that, if not with the truth, at least with me, they were having a bit of fun. His Excellency remained friendly, a remarkable display of self-control.

 

The emotions stirred by this festivity were apparently too much for the ARRA. After the opening, as far as I recall, no reasonable amount of useful work was ever produced. After some time, towards the end of 1952, we decided to give up the ARRA as a hopeless case and do something else. There was another reason for this decision. The year 1952 should be considered an excellent harvest year for the Mathematical Center staff: in March and November of that year, Edsger Dijkstra and Gerrit Blaauw respectively appeared on the scene. Of these two, the latter is of particular importance for today's story and our future narrative. Gerrit had worked on computers at Harvard, under the supervision of Howard Aiken. He had also written a dissertation there and was willing to lend his knowledge and insight to the Mathematical Center. We were not very compliant boys at that time. Let me put it this way: we were aware that we did not have a monopoly on wisdom, but we found it highly unlikely that anyone else would know better. Therefore, the 'newcomer' was viewed with some suspicion. Gerrit’s achievement was all the greater when he convinced us in a lecture of the validity of what he proposed. And that was quite something: a clocked machine, uniform building blocks consisting of various types of AND/OR gates and corresponding amplifiers, pluggable (and thus interchangeable) units, a neat design method based on the use of two alternating, separate series of clock pulses, and proper documentation.

 

We were sold on the plan and got to work. A small difficulty had to be overcome: what we intended to do was obviously nothing more or less than building a new machine, and this fact encountered some political difficulties. The solution to this problem was simple: formally, it would be a 'revision' of the ARRA. The new machine was thus also called ARRA II (we shall henceforth speak of A II), but the double bottom was perfectly clear to any visitor: the frames of the two machines were distinctly separated, with no connecting wire between them.

 

For the AND/OR gates, we decided to use selenium diodes. These usually arrived in the form of selenium rectifiers, a sort of firecrackers of varying sizes, which we dismantled to extract the individual rectifier plates, about half the diameter of a modern-day dime. The assembly—the selenium plates couldn't tolerate high temperatures, so soldering was out of the question—was as follows: holes were drilled in a thick piece of pertinax. One end of the hole was sealed with a metal plug; into the resulting pot hole went a spring and a selenium plate, and finally, the other end of the hole was also sealed with a metal plug. For connecting the plugs, we thought the use of silver paint was appropriate, and soon we were busy painting our first own circuits. Some time later, we had plenty of reasons to curse this decision. The reliability of these connections was poor, to put it mildly, and around this time, the 'high-frequency hammer' must have been invented: we took a small hammer with a rubber head and rattled it along the handles of the units, like a child running its hand along the railings of a fence. It proved an effective means to turn intermittent interruptions into permanent ones. I won't hazard a guess as to how many interruptions we introduced in this way. At a later stage, the selenium diodes were replaced by germanium diodes, which were simply soldered.

 

The AND/OR gates were followed by a triode amplifier and a cathode follower. ARRA II also got a drum and a tape reader. For output, an electric typewriter was installed, with 16 keys operable by placing magnets underneath them. The decoding tree for these magnets provided us with the means to build an echo-check, and Dijkstra fabricated a routine where, simultaneously with printing a number, the same number (if all went well) was reconstructed. I assume we thus had one of the first fully controlled print routines. Characteristic of ARRA II’s speed was the time for an addition: 20 ms (the time of a drum rotation).

 

ARRA II came into operation in December 1953, this time without ministerial assistance, but it performed significantly more useful work than its predecessor, despite the technical difficulties outlined above.

 

The design phase of ARRA II marks for me the point where computer design began to become a profession. This was greatly aided by the introduction of uniform building blocks, describable in a multidimensional binary state space, making the use of tools like Boolean algebra meaningful. We figured out how to provide ARRA II with signed multiplicative addition for integers (i.e., an operation of the form (A,S) := (M) * (±S') + (A), for all sign combinations of (A), (S), and (M) before and of the result), despite the fact that ARRA II had only a counter as wide as a register. As far as I can recall, this was the first time I devoted a document to proving that the proposed solution was correct. Undoubtedly, the proof was in a form I would not be satisfied with today, but still... It worked as intended, and you can imagine my amusement when, years later, I learned from a French book on computers that this problem was considered unsolvable.

 

In May 1954, work began on a (slightly modified) copy of ARRA II, the FERTA (Fokker's First Calculating Machine Type A), intended for Fokker. The FERTA was handed over to Fokker in April 1955. This entire affair was mainly handled by Blaauw and Dijkstra. Shortly thereafter, Blaauw left the service of the Mathematical Center.

 

In June 1956, the ARMAC (Automatic Calculating Machine Mathematical Center), successor to ARRA II, was put into operation, several dozen times faster than its predecessor. Design and construction took about 1½ years. Worth mentioning is that the ARMAC first used cores, albeit on a modest scale (in total 64 words of 34 bits each, I believe). For generating the horizontal and vertical selection currents for these cores, we used large cores. To drive these large cores, however, they had to be equipped with a coil with a reasonable number of windings. Extensive embroidery work didn’t seem appealing to us, so the following solution was devised: a (fairly deep) rim was turned from transparent plastic. Thus, we now had two rings: the rim and the core. The rim was sawed at one place, and the flexibility of the material made it possible to interlock the two rings. Then, the coil was applied to the rim by rotating it from the outside using a rubber wheel. The result was a neatly wound coil. The whole thing was then encased in Araldite. The unintended surprising effect was that, since the refractive indices of the plastic and Araldite apparently differed little, the plastic rim became completely invisible. The observer saw a core in the Araldite with a beautifully regularly wound coil around it. We left many a visitor in the dark for quite some time about how we produced these things!

 

The time of amateurism was coming to an end. Computers began to appear on the market, and the fact that our group, which had now grown to several dozen employees, did not really belong in the Mathematical Center started to become painfully clear to us. Gradual dissolution of the group was, of course, an option, but that meant destroying a good piece of know-how. A solution was found when the Nillmij, which had been automating its administration for some time using Bull punch card equipment, declared its willingness to take over our group as the core of a new Dutch computer industry. Thus it happened. The new company, N.V. Elektrologica, was formally established in 1956, and gradually our group’s employees were transferred to Elektrologica, a process that was completed with my own transfer on January 1, 1959. As the first commercial machine, we designed a fully transistorized computer, the XI, whose prototype performed its first calculations at the end of 1957. The speed was about ten times that of the ARMAC.

 

With this, I consider the period I had to cover as concluded. When I confront my memories with the title of this lecture, it must be said that 'designing computers' as such hardly existed: the activities that could be labeled as such were absorbed in the total of concerns that demanded our attention. Those who engaged in constructing calculating machines at that time usually worked in very small teams and performed all the necessary tasks. We decided on the construction of racks, doors, and closures, the placement of fans (the ARMAC consumed 10 kW!), we mounted power distribution cabinets and associated wiring, we knew the available fuses and cross-sections of electrical cables by heart, we soldered, we peered at oscillographs, we climbed into the machine armed with a vacuum cleaner to clean it, and, indeed, sometimes we were also involved in design.

 

We should not idealize. As you may have gathered from the above, we were occasionally brought to the brink of despair by technical problems. Inadequate components plagued us, as did a lack of knowledge and insight. This lack existed not only in our group but globally the field was not yet mastered.

 

However, it was also a fascinating time, marked by a constant sense of 'never before seen,' although that may not always have been literally true. It was a time when organizing overtime, sometimes lasting all night, posed no problem. It was a time when we knew a large portion of the participants in international computer conferences at least by sight!