> Thats great, but certain populations are being demonstrably soft-genocided in that their birth rates are below replacement level, and internet porn is a leading cause.

So, by deciding not to have children, people are guilty of "soft genocide"?

I've seen some crazy beliefs and weird moral systems on HN but this one takes the cake.

From the same link:

> As mentioned, satellites measuring the ice sheet mass have observed a loss of around 200 Gt/year over the last decade.

Looking at the data for one year is not very useful. This is a long term process, as the long article you didn't read went to great pains to explain.

Fair enough. It would also be useful to know that 200 GT/year translates into 0.01% per year. Or 1% per century. It's indeed a long term process.

On recent android versions you can allow calling from the lock screen. So just lock your phone and switch to the dialer before handing it over.

You modify the bootloader to grab the password on next decryption. The bootloader is in cleartext on the disk, otherwise the machine couldn't boot.

More advanced versions would involve modifying the BIOS to add a SMM-mode hook. That way the malware runs completely outside the view of the OS. Alternatively, any device with DMA access could have its firmware altered to read sensitive information from memory.

Physical security is an unsolved problem.

>You modify the bootloader to grab the password on next decryption. The bootloader is in cleartext on the disk, otherwise the machine couldn't boot.

Mine isn't - I have GRUB installed to my BIOS chip, and I decrypt the single encrypted partition from there.

>More advanced versions would involve modifying the BIOS to add a SMM-mode hook.

That one could still get me though, yeah.

> Also, yes, we need to make sure photosensitive people can browse more safely (for the same reason we put airbags in cars).

I'm kind of surprised that we don't have "epilepsy mode" in a browser somewhere. Just limit the redraw speed. It'd mess with the browsing experience but much less than a seizure.

Same for TVs, for an epileptic user it's much better for a highly dynamic scene to look washed out or just blur to a whitish color than to show it accurately and potentially cause a seizure.

Interesting. Was this data loss of CrashPlan announced publicly? Did it affect more users?

It's concerning to hear, since I know people using it for backups.

I'm not aware of it. But you know, in some other company (don't even know which) I remember a story where after the data loss the CEO contacted the user and tried to do whatever he can including sending hard drives to speed up uploading new copies.

In my case it was 90GB, a whole single machine. The fact that they were pretty causal about it, is worrying. But I still use them for some use cases because they have unlimited storage with software for Linux, although I don't depend on them.

Quote from the support ticket:

"I have looked again for your data, but we are unable to locate the archive anywhere in our system.

I am sincerely sorry that we have let you down as there is not a reason that I can find that this data should not be here.

If there is anything that I can to for you, please do not hesitate to ask and I will do so."

Tor does nothing of the sort. In order to throttle a client, there would need to be a central authority that could identify connections by client, which would very much defeat the purpose of Tor. And besides, how would it deal with multiple Tor clients for the same user?

That said, it's not particularly effective a as a brute-force DoS machine due to the limited bandwidth capacity and high pre-existing utilisation. Higher level DoS by calling heavy dynamic pages is still possible.

The parent didn't specify that the outages were during the period that the scraping was coming from Tor. It's equally possible that it only started affecting availability after they blocked Tor and switched to cloud machines.

All that said, screw people who use Tor for this kind of thing. They're ruining a critical internet service for real users.

Locking it to the bike isn't a good solution if you live in a place where it rains or snows a lot. So you end up having to carry it with you on errands. If you bike a lot, those small inconveniences add up.

I can't imagine fashion sense is much of a reason, that seems like a strawman argument commonly conjured up by helmet laws advocates.

Out of curiosity, is cycling a common mode of transportation where you are from?

I recall seeing studies showing that helmet-laws generally coincided with low use of bicycles. Places where cycling is extremely common (like Denmark and Holland) never seem to have them, and it's uncommon to see cyclists using them unless they're doing something particularly dangerous (riding in traffic, off-road, etc).

I would guess in places where biking is extremely common (like Denmark and Holland), it's also a lot safer to bike (dedicated bike lanes, etc.)

No disrespect intended, but my experience is that SuSE has always played fast and loose with the filesystem defaults.

I recall they switched to reiserfs as default at one point. reiserfs was never a good choice for data consistency - the fact that storing a reiserfs image in a file on the host reiserfs filesystem and then doing an fsck on the host FS would corrupt the FS should be a clear signal that there are fundamental problems remaining to be solved.

That said, I'm playing with btrfs on some of my machines, and it seems quite nice. But no way would I risk using it on a production server at this time.

None taken. To be clear, we do provide enterprise support for ext4 and XFS as well (which a lot of people use for the reasons you mentioned). In my experience, btrfs still has some growing pains (especially when it comes to quotas, which will cause your machine to lag quite a bit when doing a balance) but is definitely serviceable as a daily driver (though for long-term storage I use XFS).

Ah, that's good to hear. It's been a while since I've used SuSE.

Of course, someone has to go first and filesystems never truly get battle-hardened until distros start pushing them. I appreciate that SuSE does this from that perspective. It means when I switch over there will be less bugs. :)

I'm using btrfs as a daily driver on my workstations so I get some experience with the tooling, and also because features like consistent snapshots are really nice to have. Still haven't taken the plunge on the server side, I expect I'll give it a few years until it's considered "boring".