If You'd Built a "tool" That Stupid, Why Would You Advertise the Fact?

Do they? The institutions I've worked with shut off e-mail access between 6 months and 1 year after a student is no longer active.

I wonder what the benefit is.

Despite originally saying it was a perk of graduation, mine ended cutting access after 10 years by citing cost saving (I imagine Google Workspace bills add up quickly, compared to self-hosting email). I wouldn't be surprised if this is the trend now.

No because they aren't reliable. You don't want to be storing hallucinated data. They can help write the scripts that do the actual work though.

We can't even use AI language translation because of compliance / liability - we translate food ingredients.

"It says 'no shellfish', go ahead - eat it"

Even with lots context the various services we tried would get something wrong.

e.g. huile is oil in French and sometimes it would get translated as "motor oil"

No data replication or transformation is not a good use-case for text generators.

Ah yes, because hallucinations will definitely improve our data entry!

If your core feature is data entry, you probably want to get as close to 100% accuracy as possible.

"AI" (LLM-based automation) is only useful if you don't really care about the accuracy of the output. It usually gets most of the data transformations mostly right, enough for people to blindly copy/paste its output, but sometimes it goes off the rails. But hey, when it does, at least it'll apologise for its own failings.

Aha, no, Transmeta was a totally different thing, from the early 2000s. The idea there was they would have a special "Very Long Instruction Word" processor, kind of the opposite of RISC, where a lot of things would be embedded into a single 128-bit opcode. Think of it as being hell of a wide horizontal microcode architecture, if RISC is kind of a vertical microcode architecture.

It was pretty clever. You loaded x86 code (or Java bytecode, or Python bytecode, or whatever you felt like) and then it would build up a table of emulation instructions that would translate on-the-fly to run x86 natively on the Crusoe's ludicrous SUV of an instruction set. They were physically smaller and far less power-hungry than an equivalent x86 chip, even though they were clocked roughly 30% faster.

25 years ago they were going to be the future of computing, and people stayed away in droves. Bummer.

No no no, though, the transputer was a totally different thing. That was from 40-odd years ago, and - like the ARM chips we now use in everything - was developed in the UK by a company that did pretty okay for a while and then succumbed to poor management.

They were kind of like RISC processors. Much has been made of "you programmed them directly in microcode!" but you could say the same of any wholly combinatorial CPU, like the Good Ol' 6502, where the byte that's read on an instruction fetch directly gates things off and on.

The key was they had very very fast (like 10Mbps) serial links that would connect them in a grid to other transputers on a board. Want to run more simultaneous tasks? Fire in more chips!

You could get whole machines based on transputers, or you could get an ISA card that plugged into a 16-bit slot in your PC and carried maybe eight modules about the size of a Raspberry Pi Zero (and nowhere near as powerful). I remember in the late 80s being blown away by one of these in some fairly chunky 386SX-16 doing 640x480x256 colour Mandelbrot sets in like a *second*.

Again, they were going to revolutionise computing, this is the way the world was going, and by the time of the release of unrelated Belgian techno anthem Pump Up The Jam, transputers were yet another footnote in computing history.

Transputers were a 1980s CPU innovation that didn't live up to their original hype, and have little to no connection with TransMeta.