The car seat phenomenon is real, well studied, and interesting. The explanation is not only logical, but is exactly what you called a "serious" reason: cost. Parents must often buy a new car with the 3rd child, because they cannot fit 3 car seats in their current vehicle.
It says an enormous amount that we simply accept the premise that we must live in or near a major city. We don't have to trap all the livable jobs and housing there, but getting them elsewhere requires bootstrapping with a long lead-in, and we actively attack attempts to do that.
Many highly skilled jobs automatically gravitate towards the population centres because of the pool of the workforce available.
We have a dev team in one of the big cities of New Zealand, we need people, and we interviewed everyone available (yes, this must be on site).
When you have jobs, childcare, education, entertainment, government, etc, all inside cities, people migrate towards cities.
I wish I could move further away from the big city but I'd get paid third of my salary, my SO didn't found any openings, and I'd have to buy a second car so my kid could attend their school.
I see what you're saying but not every job is available outside.
I would love for Tailscale to work on a "paranoid mode". At the moment, you can be sure that Tailscale can't add machines to your network with Tailnet Lock where you have to authorize a new machine from a trusted node and not from the UI (which Tailscale could also do without me clicking it). That's great feature compared to their competitors which basically have a backdoor into your network.
But changing ACLs and many other changes can be done from the WebUI without needed authorization from a host. So I have to authorize the change in the UI - but Tailscale could really also do it without my consent. Would be great to have a mode that _ANY_ change to the Tailscale network must be authorized from a trusted node with a detailled changeset. So I could be sure that Tailscale can't tamper with my network.
Sure, I could run Headscale and completely work without the Tailscale servers. But I prefer to pay them the small monthly fee to not have to manage this central service of my fleet.
But SSDs (to my knowledge) only implement checksum for the data transfer. Its a requirement of the protocol. So you can be sure that the Stuff in memory and checksum computed by the CPU arrives exactly like that in the SSD driver. In the past this was a common error source with hardware raid which was faulty.
But there is ABSOLUTELY NO checksum for the bits stored on a SSD. So bit rot at the cells of the SSDs are undetected.
That is ABSOLUTELY incorrect. SSDs have enormous amounts of error detection and correction builtin explicitly because errors on the raw medium are so common that without it you would never be able to read correct data from the device.
It has been years since I was familiar enough with the insides of SSDs to tell you exactly what they are doing now, but even ~10-15 years ago it was normal for each raw 2k block to actually be ~2176+ bytes and use at least 128 bytes for LDPC codes. Since then the block sizes have gone up (which reduces the number of bytes you need to achieve equivalent protection) and the lithography has shrunk (which increases the raw error rate).
Where exactly the error correction is implemented (individual dies, SSD controller, etc) and how it is reported can vary depending on the application, but I can say with assurance that there is no chance your OS sees uncorrected bits from your flash dies.
> I can say with assurance that there is no chance your OS sees uncorrected bits from your flash dies.
While true, there is zero promises that what you meant to save and what gets saved are the same things. All the drive mostly promises is that if the drive safely wrote XYZ to the disk and you come back later, you should expect to get XYZ back.
There are lots of weasel words there on purpose. There is generally zero guarantee in reality and drives lie all the time about data being safely written to disk, even if it wasn't actually safely written to disk yet. This means on power failure/interruption the outcome of being able to read XYZ back is 100% unknown. Drive Manufacturers make zero promises here.
On most consumer compute, there is no promises or guarantees that what you wrote on day 1 will be there on day 2+. It mostly works, and the chances are better than even that your data will be mostly safe on day 2+, but there is zero promises or guarantees. We know how to guarantee it, we just don't bother(usually).
You can buy laptops and desktops with ECC RAM and use ZFS(or other checksumming FS), but basically nobody does. I'm not aware of any mobile phones that offer either option.
> While true, there is zero promises that what you meant to save and what gets saved are the same things. All the drive mostly promises is that if the drive safely wrote XYZ to the disk and you come back later, you should expect to get XYZ back.
I'm not really sure what point you're trying to make. It's using ECC, so they should be the same bytes.
There isn't infinite reliability, but nothing has infinite reliability. File checksums don't provide infinite reliability either, because the checksum itself can be corrupted.
You keep talking about promises and guarantees, but there aren't any. All there is are statistical rates of reliability. Even ECC RAM or file checksums don't offer perfect guarantees.
For daily consumer use, the level of ECC built into disks is generally plenty sufficient. It's chosen to be so.
I would disagree that disks alone are good enough for daily consumer use. I see corruption often enough to be annoying with consumer grade hardware without ECC & ZFS. Small images are where people usually notice. They tend to be heavily compressed and small in size means minor changes can be more noticeable. In larger files, corruption tends to not get noticed as much in my experience.
We have 10k+ consumer devices at work and corruption is not exactly common, but it's not rare either. A few cases a year are usually identified at the helpdesk level. It seems to be going down over time, since hardware is getting more reliable, we have a strong replacement program and most people don't store stuff locally anymore. Our shared network drives all live on machines with ECC & ZFS.
We had a cloud provider recently move some VM's to new hardware for us, the ones with ZFS filesystems noticed corruption, the ones with ext4/NTFS/etc filesystems didn't notice any corruption. We made the provider move them all again, the second time around ZFS came up clean. Without ZFS we would have never known, as none of the EXT4/NTFS FS's complained at all. Who knows if all the ext4/NTFS machines were corruption free, it's anyone's guess.
The problem is more that the companies want to keep their insane profit margin. They could produce in the US, pay workers more and sell for the same price.
But thats less revenue for the company. Less shareholder value. Less bonus for CEOs.
The problem is the hyper capitalism which we have for the past 50 years that every company needs more and more profits.
Transactions that haven‘t been written to the WAL yet are also lost when the server crashes or you run pgdump. Stuff not in WAL is not safe in any means, its still a transaction in progress.
