I don't read it that way. OpenSSH uses a shadow password selected from some other user to mitigate a timing attack, which is fine. But then it determined success based on whether the encrypted password was equal to the stored password. Note that the stored password was not the password of the user being logged in! If root has a * placeholder, you should NEVER be able to login as root, even if they match because you gave the placeholder account's correct password. This potentially turns a user exploit into a root exploit.

If I needed to do this, I'd drag one tab to the RHS to snap it to the right half of the screen, and drag the other tab to the LHS to snap it to the left half of the screen, then write things up. On OSX, I have Magnet installed, so it would be C-O-left or C-O-right, but same basic idea (Magnet can do the drag-snap, but I find it interacts poorly with virtual desktops).

I still remember a lunchtime complaint session about how you could no longer ask something like "Implement malloc" as an interview question. Not because it as so impossibly hard, but because candidates no longer really understood the question. Instead, you would have to craft increasingly synthetic/academic questions which didn't really test things that people would have commonly interacted with.

The core issue was that software developers were becoming increasingly isolated by abstraction layers stacked on abstraction layers, one of which they understood how to implement.

That was a good 20 years ago. This is a change, but the horse was already out of the barn. Hopefully it will be like past trends over time, where the problem wasn't so much that there were NO engineers that grasped the core concepts, the problem was that writing software had changed so that half or three-quarters of the field consisted of people who were just wiring components together without the ability to really build the underlying frameworks.

Both GOOG and GOOGL pay dividends, the most recent being $0.22/share. I'd be surprised if class B doesn't also pay that dividend.

AFAICT, this is explicitly for fixing flips in transmission between the disk and the page cache. On the storage medium, data is almost certainly already encoded using Reed-Solomon codes or Hamming codes or something of that nature, so you won't receive a block with embedded errors, you will receive a failure to read the block. And you can get ECC for you rmemory. But there may not be end-to-end ECC for every step of transmission. So instead of imagining an entirely new hardware ecosystem (which will never happen), this just stores the data in an encoding which can be decoded once inside the ECC protection of the CPU and memory subsystem.

Saying it doesn't store redundant data isn't really correct. These codes necessarily inflate the storage size to accommodate redundancy. I don't think it's really comparable to the redundancy of ZFS or RAID, which group blocks together for encoding so that you can split the no-error fast path away from the slow error-recovery path.

All of that said, this seems like it would be cleaner as a device-mapper layer. Like you could have two in-memory pages encode into three on-disk pages, or four map to five, etc. Having it as a new filesystem could allow stronger optimization opportunities because you could have internal structures not cross page boundaries, but also infinite opportunity for errors. You'll still have to solve the problem of the decoded block size not matching the OS page size (Reed Solomon inline is going to eat 20% or 25% of the page's storage space).

Just thinking about having to bounds-check all of your short reads is kind of freaking me out. There are SO many assumptions baked in around having disk operations happen on memory-page-sized chunks.

The Internet suggests that Amazon has datacenters worth 44 gigawatts of usage under construction right now! I mean, I for sure support work towards generating more nuclear power, but this isn't even peanuts, this is "I'll gladly pay you Tuesday for a hamburger today".

No. Accountants can have actual utility. Often accounting FIRMS are heavily manipulated and broken ... because they are run by MBAs.

Visibility is on a continuum, to a certain point. You can be way too low, too low, just a bit too low, etc. But after a point, your headlights are casting enough light to do the job, and from there increases stop improving your outcomes and start degrading the outcomes for other road users.

But, also, a lot of this is about how the beams are in a focused point source lasering into the eyeballs of oncoming drivers. Incandescent headlamps naturally required a lot of surrounding lenses to direct the beam, which also dispersed the beam. LED headlamps often just blast photons forward with no subtlety. We can do better, but we can't be bothered to do better, because the only part which matters to making the sale is the output number.

We already know that these companies aren't entirely certain what their AI trial balloons are doing at any given time. If all the companies got together and agreed to "slow down" ... how would we even know if they did? How would we even know if they intended to slow down, and then whether they actually took actions to slow down and actually understood whether they were even on top of what they were previously doing?

I'm not saying that I think there are independent rogue AIs operating in there just waiting to escape. I'm saying that right now there are DEPENDENT rogue AIs which can't operate without the company's help, and those are routinely breaking out of confined networks, and the companies seem to be perfectly fine skirting disclosure on what's going on. There's no reason to think they would stop lying about such things if a new industry compact was made.

I get what they think they are doing. But you can't really achieve security by layering ill-thought-out systems on top of each other. I'm sure the new system does not at any security holes. I'm sure that the two systems together don't create any security holes one of them alone wouldn't have had. I'm sure.

The fact that your horrible replacement interface is becoming even more expensive to ship isn't my problem - I didn't ask you to replace time-tested physical interfaces with glass surfaces designed by morons.

It's not clear that anything we'd be able to send out there would be able to find out more. The Oort cloud is SUPER low-density.

First, they can cut their staffing.

Second, they don't have to deal with any of the problems their products have because they have no avenue to receive feedback (*).

Winning and winning again!

(*) a few decades ago I made a habit of periodically going and grabbing someone from QA or support just to chat, because they had been FORBIDDEN to talk to engineers. I'd almost always discover a completely fixable bug or misfeature that we could have fixed six months ago if anyone gave a damn about quality. For sure you can get lost in the weeds over it, it's just depressing that management is willing to have an ass product because of "metrics".

Google Maps sent us through Kingston Wilderness last winter because I40 was going too slow (due to a holiday). I kept pestering my navigator until I got yelled at about how it looked valid. It was not valid, in retrospect I should have taken the hint when I saw the Lincoln Towncar turn around. It was definitely the start of one of those "Idiot follows Google Maps and dies of exposure" stories, except there were so many other people also taking the route that we'd have had to work really hard to actually die.

When I got back I went online to rant, and ended up not bothering because there were so many past rants on Reddit from people sent on the same route.

Why? Isn't bitcoin perfectly self-policing? People should have done their due diligence on how they stored their keys, and if they didn't that is just the invisible hand of the market at work.