soneil

Giving too much detail could be an issue in itself, because it starts to misrepresent what permission you're actually giving it.

If an app says "I'd like local network access to find other copies of myself", and you say yes - you're not giving it permission to find other copies of itself. You're giving it all local network access.

If you give it 'full disk access' because it wanted to access one file, and 'local network access' because it wanted to scan for copies of itself - you've given it full permission to export all of your data to your LGTV.

I actually really like having § at that position. I have it mapped to a Quake-style terminal, and § means it's not only the correct key, but I don't have to give up a useful key for it.

(This may not translate well for USians; Quake disregarded keymaps, so the console wasn't actually on ~, but on "the key that would be labelled ~ in the US". On UK-PC, that's backtick, on Uk-Mac, that's §.)

Eight Megabytes would be a feature, these days.

ahh - I see where my dots weren't connecting, then.

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.

Can I confess I've never quite wrapped my head around the application of the 'inhibit' line in this?

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.

It’s probably worth noting it’s (2002) too. The internet was a different audience.

Was C really later? I thought UNIX had been ported before it made it to Berkeley.

yeah, software travelled exactly the same way as rumours that such and such had a rib removed - remarkably effectively.

Also the same way we got viruses, long before anyone I knew had the Internet.

Sligo's not _that_ bad.

Yeah it's pretty much a John Smith, which I assume was half the point, and is now most the problem.

I tried similar. Each command looped 5 times, ignore the best and worst times, and average the mean three.

    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.776s

I have a couple of devices that are 12V over usb-c. The devices themselves are fine, but the wallwarts the mffr provided are just that - 12v over usb-c. No PD. If a device is expecting 5V, there's a healthy chance it'll .. stop expecting 5V.

We blame usb-c for all this, but it does feel like some mffrs are going out of their way to screw it up.

I'm curious if there's a reason this six-cell mechanism has become the defacto?

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.