4,800 karma · joined December 20, 2010
I pictured having a current driver on each plane, so the data bits coming in would be enable bits for the current drivers. Which obviously means 18xQty current drivers.
I think you're describing having one big current driver for the whole job, and then data bits drive the inhibits to counter them.
I guess I'm looking through too modern a lens - pumping 18*600mA into the write cycle, plus (up to 18)*600mA into the inhibit, sounds insane to me (hitting 20A for a write) - but I can see that multiplying the current drivers may have sounded nuts in the 50s.
If a write cycle is just a read cycle with a) a reversed polarity and b) you don't care about the contents of the sense line - I don't get why current coincidence is sufficient during the read cycle, but not during the write cycle?
Every description of this I've ever read, sound like inhibit and current coincidence solve the same problem - but have never left me clear on why we need to solve it twice.
Also the same way we got viruses, long before anyone I knew had the Internet.
journalctl >/tmp/all.log 0m59.763s
journalctl | grep -c sshd 0m57.767s (otherwise >all is the only example encumbered by write speeds)
wc -l /tmp/all.log 0m0.336s
grep -c sshd /tmp/all.log 0m1.776sWe blame usb-c for all this, but it does feel like some mffrs are going out of their way to screw it up.
It seems this should just be a single input field styled appropriately, but it feels like there must be an underlying reason I'm missing.
Almost 30 years, and every so often I still wonder about where that got him.
(Not that I'm claiming anything's original here, ftp & smtp are both in the nwg/ietf family tree, which makes it easy to draw parallels. There's probably 100 other influences.)
I think it's neat that you can still find echoes of this. MAIL worked by just appending to MLFL, separating records with CRLF.CRLF - which is still how Data segments are terminated in SMTP.
But this cost-effective route isn't readily available to most people, as most people don't build homes. Developers build lots, and then sell finished homes. So you need to entice developers. And historically, "the stick" is the only enticement developers remotely pay attention to.
"If you want a swift brick, install one yourself" is much easier said than done - you're talking about removing an existing brick, replacing it, hoping you don't damage the course or the cavity, probably voiding any warranty on a new home, etc. It's certainly not a £35 retrofit.
So Winter is Nov, Dec, Jan - and Spring is Feb, March, April. Which honestly, makes sense to me.
Except it's the middle of April, I'm freezing, and got pelted with hail yesterday. The west coast cares little for seasons!
I believe IBM hardware is still applicable for this, the Thinkpad just isn't IBM hardware anymore.
Propagation might be a useful way to visualise it, but doesn't match reality unless every cache is a warm cache.
Imagine it's 1926 and none of this tech is an issue yet. The police can fingerprint and photograph you at intake, they can't compel speech or violate the 5th.
That's exactly what's being applied here. It's not that the police can do more or less than they could in 1926, it's that your biometrics can do more than they did in 1926. They're just fingerprinting you / photographing you .. using your phone.
This is a myth. The first IBM harddrive was 5,000,000 characters in 1956 - before bytes were even common usage. Drives have always been base10, it's not a conspiracy.
Drives are base10, lines are base10, clocks are base10, pretty much everything but RAM is base10. Base2 is the exception, not the rule.
Here's my theory. In the beginning, everything was base10. Because humans.
Binary addressing made sense for RAM. Especially since it makes decoding address lines into chip selects (or slabs of core, or whatever) a piece of cake, having chips be a round number in binary made life easier for everyone.
Then early DOS systems (CP/M comes to mind particularly) mapped disk sectors to RAM regions, so to enable this shortcut, disk sectors became RAM-shaped. The 512-byte sector was born. File sizes can be written in bytes, but what actually matters is how many sectors they take up. So file sizing inherited this shortcut.
But these shortcuts never affected "real computers", only the hamstrung crap people were running at home.
So today we have multiple ecosystems. Some born out of real computers, some with a heavy DOS inheritance. Some of us were taught DOS's limitations as truth, and some of us weren't.
RAM had binary sizing for perfectly practical reasons. Nothing else did (until SSDs inherited RAM's architecture).
We apply it to all the wrong things mostly because the first home computers had nothing but RAM, so binary sizing was the only explanation that was ever needed. And 50 years later we're sticking to that story.