This is slightly conspiratorial but I suspect that hearing aid vendors lock-in people the same way through neural adaption.
If someone has profound high frequency deafness, no amount of amplification will help. High frequencies carry a lot of the information about consonants and are how we distinguish "t" from "s" etc.
So modern hearing aids do frequency remapping. A low frequency signal is produced within the range of hearing when those high frequency inputs are detected. The sharp 2500 and 6000 Hz peaks of an aspirated "t" become a sort of raspy tone at 1500 Hz, for example.
This is why they say you need to wear your hearing aids for at least some weeks before you notice a benefit. You're relearning language with the extra DSP sounds added. If you grow up with and wear hearing aids most of the time, your brain will be fully adapted to the DSP-speech.
Which is proprietary to the manufacturer. Every manufacturer uses a different algorithm. There's several ways to remap - the classic time vs. frequency multiplexing question. This (along with different noise reduction algorithms) explains why hearing aids from two different manufacturers can sound so very different.
I am being quasi-conspiratorial about it being an intentional lock-in. But one does wonder. In practice the method used by the hearing aids you grew up with is probably the only method you can make full use of.
Not to knock the technology. It's quasi-miraculous for some types of partial deafness. With plain amplification even at 95 dB my WRS is like 60%, while with hearing aids set at much lower 80 dB output average I get 100%.
When I end up needing hearing aids, I intend to roll my own signal remapping via Bluetooth. Latency will be a thing, it will be worse than state of the art, but I can adjust and fix it.
My capacity to do that is rare, and it is not a public health solution.
A bill of bodily autonomy with prosthetics (no subscriptions, no self destruct or planned shutdown) and right to repair prosthetics seems like the path for the future.
I've wondered how much DSP can be fit into the open source PineBuds which have little ARM microcontrollers in them. They can do active noise cancelling so presumably some HA-like features are possible.
A vocoder is a good approximation for what a cochlear implant's speech processor does.
There's been one person who was implanted, who had their natural hearing return for unknown reasons. So they can hear both cochlear, and quite well naturally in the same ear.
This let researchers at Arizona State University ask basically: what sounds most like the cochlear input? The various samples involving their research about 15 years ago are probably your best bet for what it sounds like.
Some people with musical training before retain the ability to hear arbitrary melodies with perfect pitch. Some do not.
Of course it's not ideal. But you're really getting waylaid.
Here in Canada (where we supposedly like restorative justice and giving people second chances) the penalty for murder is life in prison.
The non-parole period (the amount that must be served) is set by the judge at sentencing and ranges from a minimum of 10 years for second-degree murder. (The longest period is never: indefinite incarceration until proven to be safe around others -- mostly reserved for serial killers.)
That is to say: the absolute shortest sentence you can get in Canada for murder is ten years.
In America I believe it's often many decades if not the death penalty, no?
Even Norway - renowned for the progressive humanity of its legal system - mandates at least 8 years jail for murder.
In just about any country anywhere 10 years for murder is, objectively, a relatively light sentence for murder.
Not at all sure what the sentencing for murder has to do with firearms, really. Other than firearms being an effective way to murder. Most murders in my country are beatings and stabbings, probably since firearms are not as widely available. Does that prevent a few? Probably. Still seems non sequitur.
I'm not "getting waylaid", I'm pointing out the best answer to how many years in prison for murdering someone is, by far, wu.
Firearms being an effective way to murder is exactly one thing underlying the dynamic. But my point is that it isn't even the existence of firearms per se, but rather a culture that emphasizes escalating minor disagreements into life or death confrontations. The bar seems much higher for bringing a situation to that point with beating or stabbing.
This speaks directly to your objectively comparing sentence lengths. How many people on the jury were thinking "shit, I drove here today, I everyday carry a gun, sometimes I lose my cool, I could easily end up in the situation the defendant was with some asshole" ? These situations need to be seen as exceptional and wildly out of societal norms, not practically routine.
EDSAC as early as 1949 had an "initial orders" module. A boot-up ROM. There was a bank of rotary selector switches, to set the octal digits in each ROM word.
David Wheeler (of subroutine fame) figured out the most sensible thing to put in the tiny ROM was a paper tape loader and mini-assembler that loaded the rest of itself from paper tape. So at switch-on the machine would start reading the tape input and run. Programs could be written on the teletype with mnemonics and relative addresses in octal.
It seems a little strange that more advanced later machines like the original PDP-11 from 1970, couldn't "autostart" from ROM like that. You had to toggle in a bootloader.
I think that was because core memory was non-volatile. (EDSAC didn't use core; it had a refreshing DRAM-like delay line memory.) With core, you only had to toggle the bootloader into once and, provided your software didn't accidentally overwrite it, it was still there after a power cycle. So re-toggling in the boot loader was not really that common, despite how much lore surrounds it.
DEC supplied optional boot rom cards for UNIBUS, starting with the BM792, which arrived as a 32 x 16 matrix of diodes. You had to remove some of the diodes by hand to set the boot code.
Later cards used PROMs, and were pretty fancy. The M9312 had 512 words and included some basic CPU diagnostics. Different variants handled boot from disk, paper tape, console, etc, and you had to specify the options you wanted when you bought the card.
Yes that early pdp-11s had core memory, its contents survived power cycling. We'd hand toggle in the bootstrap into high ROM and start it, it would load whatever we were running from paper tape - unless you did something stupid that trashed that high memory you'd get to reuse the bootstrap over and over
Having said that the bootstrap was something like 8 16-bit instructions, a pain but not impossible
DonHopkins comment is marked dead but I’m glad I had show dead on because it’s right in the intersection of what I’m interested in, especially the forth on pdp-7 stuff. (The intersection is my interest in explanations of implementing forth from scratch and about the pdp-7 specifically.)
We had a GT40 at the University of Maryland Vax lab, which we would play Lunar Lander on when the Vax was down.
Scott Swazey gave a great talk at VCF West 2024 about restoring a GT40 and getting Lunar Lander running on it again, and it touches on everything in this thread: core memory, bootloaders, front panel single stepping, light pens, and retyping lost ROMs from listings.
Your point about core surviving power cycles is part of the game (19:44): "because the game has core memory which is nonvolatile, so when I turn off the machine it saves everything, all of the carcasses from the crash landers of all the failed attempts are scattered across the screen. And interestingly enough, if you leave the game running long enough the game will crash, because there's no more memory left for any more carcasses."
It was also arguably the first Easter egg, in 1973 (20:17). Land next to the McDonald's and the astronaut walks over and says "I'll take two cheeseburgers and a Big Mac to go." At a show he crashed into it instead and got "You have destroyed the only McDonald's on the moon", and since core remembers everything, nobody else could find it after that (21:13).
The GT40 came up in a bootloader and pulled programs down the serial line, so no toggling, but debugging it was pure front panel. Hitting line feed crashed the PDP-11, so he single-stepped through the bootloader with a diagnostic card, down to a byte compare of the high byte, which goes through a shift, and found a dead 74194 4-bit shifter (15:50).
A PROM on one of the boards had failed, and no binary of it survived anywhere, so they typed its 256 entries back in from the listings (13:46). His rule number one is "don't trust anybody": he double-checked his friend's careful transcription and found two transposed digits that "would have created a bug so subtle that it would have taken us months to find it" (14:31). The same rule caught the downloaded diagnostics, which had a stray "!" and a newline inserted that made the loader abort (17:15). And on Bitsavers: "we could not have restored it without it" (13:10).
Other highlights: Atari's 1979 Lunar Lander turns out to be a direct copy of the GT40's vector generator, binary rate multipliers and all, with a 6502, ROM and static RAM swapped in for the PDP-11 and its expensive core (5:11). At VCF Midwest the wall power sagged to 90 volts, so he ran it off his camping battery (23:39). And he showed it next to the PDP-11/45 that animated the Death Star trench briefing in Star Wars, with a dueling light pen battle between the two (24:46).
I've been doing the same kind of thing without the soldering iron: bringing Heinz Lemke's 1972 PIXIE/SYMELEC light pen system for the PDP-7 and Type 340 back to life in a browser emulator, from a scanned listing, since no tape survives. Then DEC's own 1964 370 Light Pen Diagnostic, transcribed from a scan that skips from page 5 to page 7, so page 6 had to be rebuilt from how the surviving pages use each of its symbols.
Scott's rule number one turned out to be mine too. Every bug falls into one of three kinds: ours (the emulator got it wrong), the transcription's (the listing was misread off the scan), and 1972's (the listing itself is wrong, and the emulator should faithfully reproduce the mistake). The first one was a truncated literal pool. The conversion stopped at word 11741, so every (JMP INT literal read as 0, and the machine initialized itself into a wall. So far, every bug had its answer on paper before anyone went looking. The emulator's job is to run the listing until it disagrees with itself, and then to show where.
In 1972 the PDP-7 was the small one. It hung off Cambridge's Titan (an Atlas 2 that filled a room and ran the university) as a satellite, phoning home over Neil Wiseman's custom link to store and retrieve drawings in the Titan filestore.
The emulator inverts that: tiny-titan is the whole of Titan, as much of it as PIXIE ever saw, in one TypeScript file, serving its emulated satellite from inside a browser tab. It implements only what the one surviving caller ever dialed, and SYMELEC's unmodified link code runs against it.
Press the "DEMO" button and it will make a goofy child's drawing with the virtual light pen. I plan to ask Claude to make a new demo by trying to draw a pelican riding a bicycle.
Enable the MEMORY panel's "SOURCE" + "FOLLOW PC" mode, then slow the emulator down with the slider, to see the PDP-7 assembly source code it's executing (from the OCR of the scan of 128 pages of line printer output).
You can also pick "LIGHT PEN TEST (1964)" from the menu and press "DEMO", or pick "DUEL (1968)" and play spacewar for two, DECUS 7-40, loaded from paper tape through the RIM loader, the PDP-7's version of your bootstrap.
And I made a non-graphical "HILO (2026)" number guessing game and a "LUNAR LANDER (2026)" game to test out the TTY simulator. The lander is in the spirit of the turn-based original Scott describes (1:52), before the GT40 made it real time: "YOU ARE 500 FEET UP, FALLING AT 50 FT/S, WITH 60 UNITS OF FUEL."
PDP-7 Unix is coming soon. Warren Toomey, Phil Budne, Tom Everett, Sebastian Rasmussen, Robert Swierczek and friends did this kind of restoration on a much bigger scale with the pdp7-unix project. Starting in 2016 they typed in Ken Thompson's 1969-70 PDP-7 Unix from Norman Wilson's scans of the only surviving printouts, wrote a cross-assembler (as7) and a user-mode simulator, and got the kernel booting to a shell with a working filesystem.
In 2019 a second notebook of missing sources turned up and was scanned and typed in too, and in January 2020 it ran on a real PDP-7 at the Living Computer Museum. It even has moo, the bulls-and-cows number guessing game, a 1970 cousin of my HILO.
Their as7 was the precedent for my own assembler, which can run in the browser and produce symbol tables and source maps, the way a TypeScript to JavaScript compiler does. That's what drives the Memory panel's Source + Follow PC mode, and it's the groundwork for live coding:
To run Unix, the cabinet needs what its SIMH script asks for: 8K with EAE, the teletype, the clock, and the RB09 fixed-head disk. It loads boot.rim, and the bootstrap reads the system from disk. So the new part is porting SIMH's RB09.
B comes with it: the interpreter (bi.s) and loader (bl.s) survive in the scans, and Robert Swierczek rebuilt the missing compiler in 2016. There's no C on the PDP-7. C came later on the PDP-11, and B was Thompson's cut-down BCPL.
And a couple days ago Mitch Bradley wrote a PDP-7 FORTH for it, including a Turtle Graphics package, which I'll integrate soon too! That's the other half of live coding. My assembler is TypeScript running on the emulator host, but Forth will run on the PDP-7 itself: you type new definitions at the emulated teletype, and the turtle draws them on the 340, interactively, in a language living inside the machine.
B compiles to threaded code too, so the cabinet will have two threaded interpreters, 1970 and 2026, running side by side!
Fittingly for a thread about whether the ENIAC had a BIOS: Mitch is the one who wrote Open Firmware, the Forth-based boot firmware in Sun workstations, PowerPC Macs, and the OLPC XO. So the PDP-7 is getting its Forth from the same man who invented Open Firmware to put Forth in the BIOS.
Mitch's threading technique is a new one, as far as we can tell, small fast and elegant on the PDP-7. NEXT is three instructions, and the core of it is XCT I 10: it bumps an auto-index register and executes the thread cell it points at, so every cell in a compiled definition is itself a PDP-7 instruction, and its opcode is its type. CAL enters a colon word, JMP runs a primitive, and LAC or LAW pushes a constant or variable.
That makes location 10 a second program counter, running a virtual machine whose instruction set is the PDP-7's own. It doesn't fit Anton Ertl's threading taxonomy. For publication, "XCT Threading". For the T-shirt, "Indirectly Direct Threading".
The EDSAC's "boot ROM" consisted of a bank of large electro-meachanical "uniselector" rotary switches, hardwired to contain the 31 instructions ("initial orders") of the tape loader.
Subsequent computers could have followed this "electro-mechanical ROM" approach, but I suppose it was rather bulky and inconvenient to change.
You can see what the uniselectors looked like here at 8:50
Of course programmable ROM chips would have to wait, so in the meantime the alternatives were either the toggle-it-in approach (still also used by the 1974 MITS Altair 8800), or other more compact types of handmade/hardcoded physical ROM such as magnetic core or diode matrices.
Typically daily. They were used for troubleshooting and repairing military avionics. They survived decades onboard ships, etc. They got temperamental in their later years, but we kept them going.
If you have any interest you can search up the (sparse) information on the AN/USM-484 Hybrid Test Set (or System).
> It seems a little strange that more advanced later machines like the original PDP-11 from 1970, couldn't "autostart" from ROM like that.
Because the PDPs had magnetic core memory, so the bootloader, once toggled in, stayed in memory. The OS took care not to overwrite it.
And in normal operation you wouldn't have to use it at all, you just switched on your PDP, and it was in the same state as when you switched it off.
Also, bootloaders were short (because peripherals had lots of intelligence); toggling one in was a matter of minutes.
> I think that was because core memory was non-volatile.
Exactly. And when RAM cards were available to replace core (very late in the lifecycle of the minis), the RAM was battery backed to simulate that behaviour.
In Fred Hoyle’s science fiction novel, The Black Cloud, there is a computer in an early chapter that is clearly inspired by EDSAC. When they run a program on it, the process is just what you describe - they load a paper tape in through the tape reader, which Hoyle describes in detail.
I first read that book before I knew that in British English a vacuum tube is called a valve (from thermionic valve and which makes more sense than the American term, I think), so I was confused by the line about how warm the room was due to all of the valves!
Valve gear is particularly full of transatlantic differences, as well as valves vs tubes in many cases the same specific valves can have different names depending on the side of the Atlantic you're on such as EL84 vs 6BQ5. Your high voltage line is called HT in British but B+ in American, while what we'd call an anode in the UK is more commonly called a plate in the US. I'm not sure if it's as fixed but I've usually heard Americans calling what I'd call the heater the filament as well.
While 'valve' makes more sense from the point of view of what it does, 'tube' makes more sense from the point of view of what it is I think.
We called them thermionic valves too, just the terminology shifted a bit over time. We also called capacitors "condensers". Both were references to steam powered control systems.
They say the term did not originate from the steam condenser. Quite the opposite, it became deprecated because of the ambiguous meaning of steam condenser.
What I'm reading (and was told by grey beards) is that it originated as a metaphor to steam condensers, and was deprecated because the two different systems having the same term led to ambiguities. Including the fact that they do have different properties, such as steam condensers are able to absorb steam pressure, but can't actually return the steam when the input pressure drops back down (since it's already been condensed back into water).
I just met John Robson at a meeting who was one of the first people in the world to run a frequency domain analysis on time series data - on EDSAC! He spent a long time explaining the precise algorithms to me - amazing!
Processes like this are where "boot" comes from. The machine was pulling itself up by its bootstraps. The ROM was sometimes called the "bootstrap loader."
> But there have been no wars between major powers in the last 80 years. Maybe people in power have realized that all-out wars are no longer productive.
People talked like that before WW I. There hasn't been a major war in Europe since 1870 almost half a century and trade is such a large war would bankrupt all the major powers and so would never happen. The Great Illusion was published in 1909 and was positively received at the time:
> In The Great Illusion, Angell's primary thesis was, in the words of historian James Joll, that "the economic cost of war was so great that no one could possibly hope to gain by starting a war the consequences of which would be so disastrous."[4][5] For that reason, a general European war was very unlikely to start, and if it did, it would not last long.[6] He argued that war was economically and socially irrational[7] and that war between industrial countries was futile because conquest did not pay.
There was a major war between Russian and Ottoman empires in 1877–1878. And if you look outside Europe, there was an even greater war between Russia and Japan in 1904–1905.
0.15% of world population was mobilized to fight in the Russo–Japanese war. That would correspond to ~12.5 million combatants today. Napoleon's invasion of Russia saw more casualties from combat, starvation, and disease, but it involved a smaller fraction of world population.
I assume you're going off the 1.365M + 1.2M combatant strength listed in the Wikipedia article?
Those are figures for the total size of those national armies at the time. It'd be like saying the Iran war involved 3M people because the U.S. has about 2.1M in uniform and Iran has just under 1M counting reservists. Meanwhile there've been precisely zero boots on the ground in Iran, and the total number of military personnel directly affected is on the order of tens of thousands.
The text of the article has the Russian far east strength at about 95,000 at the start of the war, with another 410,000 trained in over the course of the war. The best proxy for Japanese (and Russian) combat strength might be the Battle of Mukden [1], which had about 250K Japanese and 292K Russian troops. These numbers are smaller by a factor of about 5x.
The present-day Russo-Ukrainian war is significantly larger. Estimated Russian deaths are 500K+, higher than the total number of Russian soldiers involved in the Russo-Japanese war.
If you continue reading the article, it mentions that Russia had mobilized almost a million soldiers in the Far East by the end of the war, and that mobilization largely happened after the Battle of Mukden. Without the naval defeat at the Battle of Tsushima, Russia would have had the upper hand at that point, and the war would likely have reached a different conclusion.
Industrial armies were massive. By the standards of that era, current US military strength exceeds 60 million. But they mostly relied on reserves, which were slow to mobilize. Japan's quick decisive victories ended the Russo–Japanese war before it had a chance to escalate further, potentially reaching the scale of the Eastern Front in WW1. But even then, the Battle of Mukden was one of the largest land battles in history until that point
It seems to be a vibe coded joke that implements a database in the worst way possible. For example, it appears to store post data in the timestamps and permission bits of the file system.
Besides Firefox, I don't think many of the browsers are user-agents anymore, but more like corporate-agents, as they don't seem to act in the interest of the software user anymore.
reply