And it wasn't just a 4KB "stick" of RAM or something, it was literally magnetic rings threaded onto wires called Magentic Core Memory. Further, 4 KB implies that it was 4096 bytes, but it was actually 2048 "words" consisting of 15-bits (+1 parity bit) [source]. 2048 words requiring 16 bits each means 32,768 magnetic rings weaved onto tiny wires. Oh, and another fun detail about magnetic core memory is that if you read a value, I.e check to see if one of those magnetic rings is set to 0 or 1, that is a destructive operation. So if you wanted to read without deleting, you have to read and then immediately rewrite.
Oh, and another fun detail about magnetic core memory is that if you read a value, I.e check to see if one of those magnetic rings is set to 0 or 1, that is a destructive operation
Yeah, this is the same thing with modern RAM. The Magnetic Core Memory is doing roughly the exact same thing modern DRAM is doing. In the MCM it's magnetic hysteresis that's holding a bit of magnetic charge, in DRAM it's a tiny capacitor holding a bit of an electric charge. Either way, the charge is placed into a thing called a sense amplifier. The amplifier is a flip-flop circuit. During the refresh cycle the state of the sense amplifier is written back to the cell whence it came.
Static RAM, SRAM, is the kind of RAM that a read is non-destructive. It's really expensive (Here's a 2MB SRAM as an example of cost) and doesn't do well at really fast clock speeds at the moment. However, SRAM is really simple to interface with (Block diagram on page 1 and you can see you just have Address pins (A0-20), IO pins (I/O0-7), and the control pins that you turn on or off to indicate what the heck you are doing with the chip (CS#, OE#, WE#). Which the OE means output enabled (read) and WE means write enabled (write). See super easy to interface with) and it's usually what's used when folks proto circuits that need RAM. It doesn't matter what your clock speed is nor how you probe the contents of the memory, all of it is non-destructive. But DRAM, is stupid cheap compared to SRAM and handles higher clocks a lot better.
Those 4kb only held a fraction of the computation needed to fly to the moon though. All the complicated heavy stuff was done by humans and bigger computers down on earth.
Well, most of the websites now are mostly bloatsites with so much useless effects and/or scripts.. 8 gigs of ram is not a problem here, current standards or maybe let’s call them fancy e-fashions are.
Few days ago I stumbled upon a single page website that was loading like 12 fonts and I don’t remember how many effects libraries just to use some fading and one font in two weights.
I accept sites looking not as imagined by the designer and even partially not working sites ... But I'd never ever disable the ad blocker, the cookie whitelist and the JavaScript whitelist.
If the site does not work at all and if I really need the content of that site I open it in a new private window. If I can find the needed information elsewhere, Ctrl+W it is!
Just curious, what were you doing with Firefox to pull anywhere near that much RAM? Right now I've got a few tabs open along with Steam/Discord/Spotify/a few terminal windows/Helvum and I'm not using 3gb for the entire system according to htop. Just curious how many tabs you have open to pull 32GB from Firefox.
it's not mainly how many but how long. I leave my desktop running for weeks, and there was a while when clearing Firefox's cache was the main reason I needed to restart. I do leave something like ~100 open at a time.
htop/top are a bit tricky because Firefox spawns a bunch of sub processes, so it's frequently an undercount; I forget whether htop accounts for that.
yeah, so hypothetically, yes, but when I'm running scripts, frequently their memory usage can cause my computer to freeze if I don't immediately have that memory available. and those are the actual reason I need 64GB, not feeding Firefox's insatiable hunger for RAM.
Computing resources got cheaper so development didn't need to be as careful.
If one month you have $100 for food, but the next month you'll have $2000 are you still going to eat like you've got $100? Of course not!
But another part of the problem is that when development was slim you also weren't running very many things at once. I can remember writing different autoexec.bat and config.sys files to boot straight into whatever game I was going to play. Most to all of the resources were available.
Now we're constantly running a handful of things. The OS itself is huge, plus a browser that you haven't closed with a handful of tabs, plus the app for the store you bought the game from, and whatever else is in the background, and so on. So you feel the drag more because everything wants as many resources as it can grab before something else does.