zootboy

> Then guess what - people stop using those websites.

Wishful thinking. Sadly, the vast majority of people will be perfectly OK with a website telling them they have to use a recent iPhone or Play-enabled Android phone to do something. This is already the case for banking apps and a huge number of other phone-app-only services.

It's not wild at all. It's just behaving like any other MUA but with an extra step. You have to give GMail your SMTP submission credentials for the sending server of the target domain, then prove ownership of the specific address you want to send as. SPF/DKIM/DMARC works fine, as GMail is just submitting your message on your behalf the way any MUA would.

To be honest, it seems rather silly to go this deep into probability calculations when your N = 4 (hard drives). I can present numerous wildly-differing anecdotes about how single hard drives I have owned have fared. I have some drives that are 20 years old that still apparently work fine. I've had brand new drives silently corrupt sectors after less than a year in use. Trying to put hard numbers to the probability of failures is a fool's errand. Better to simply assume that components will fail over time, and architect your system to handle those failures gracefully.

That said, I actually agree with much of the final architecture decisions made by the author. BTRFS raid1 with an offsite copy in a geographically distant area is a pretty good solution for the average person's personal documents. Possible improvements would be:

- Multiple offsite copies in different locations

- Hardware diversity (differing models of HDD, host PC, power supplies, etc.)

- Staggered hardware upgrades on a 5-10 year cycle

- Cold storage (offline) copy

Life expectancy really depends on how the hardware gets used. I run a small fleet of servers that are heavily CPU / GPU loaded, and the most frequent hardware failure I see is power supplies, with RAM as #2 and spinning HDDs as #3. Each of these (on enterprise-grade gear) has some amount of reporting / monitoring, but it's rarely the case that I get any advance warning before a failure. The RAM is probably the nicest, as it sometimes starts with correctable ECC warnings. Nearly all of the PSU failures have been sudden deaths, with the only saving grace being N+1 redundant supplies usually keeping the victim server alive.

> Is it hurting the batteries of my devices?

Unequivocally no, assuming your chargers are reasonably spec-compliant (e.g. not Aliexpress garbage). This is the whole point of type-C / USB-PD: chargers and devices should be more or less interchangeable. It's up to the device, not the charger, to charge its battery at an appropriate rate. The worst that can happen is plugging in an undersized charger, which may cause the device to charge slowly or not at all. If the device accepts a charge from the charger at a rate you find acceptable, then you're golden.

Battery failure is a "when" because batteries have a limited number of charge-discharge cycles. Modern lithium-ion batteries have a life expectancy in the range of 300-600 cycles. So if you've never had such a failure, it probably just means you're not a heavy user of your devices.

I try to keep my cell phones as long as I feasibly can. Every single one I've used for more than 3 years has had its battery fail (as expected for a device that sees such heavy cycling). My current phone is on its 3rd replacement battery.

I'm not certain that the git committer tells you the full story. I don't believe the AUR enforces that the git commit email is the same as the current maintainer email. So this could have been an orphan package, adopted by a malicious user, generated a malicious commit with the previous maintainer's git info.

Unfortunately, I don't see a way of viewing the ownership history of a package in the AUR. I know you get emails with ownership changes if you're subscribed to a package, but I don't see this info in the web interface anywhere.

And this is why "mandatory app to configure" is an instant dealbreaker for me for any piece of hardware. Don't buy crap like this. Force companies to be better.

It's not outdated, you just actually need to follow it. 3 copies of data in separate S3 buckets is ignoring the "2" in the 3-2-1 rule: 2 different mediums, and also the "1" rule: 1 copy offsite. In the cloud era, offsite means not on the same cloud provider. Different mediums ideally means a non-cloud provider (e.g. a NAS at your office under your control).

J.K. Rowling, J.R.R. Tolkien, etc.

> ...affluent people leaving all of their moop because they don't care about the deposit

This is why I suggested an increasing deposit for repeat offenders. Leave a huge pile of trash? Next year's deposit is $100k. Do it several years in a row? $10MM deposit.

Sounds to me like there ought to be a MOOP cleanup deposit charged upfront, that only gets returned after this inspection. If the cleanup crew has to clean your site, you forfeit part or all of your deposit. Repeat offenders get charged increased deposits each time. Repeat inoffenders(?) get their deposit reduced.

> It's behind a UPS and a good surge protector.

To be clear, neither of these things are intended to address EMI/RFI. Most consumer-grade UPSes directly pass the AC power through when not on battery, so any noise on the lines will also pass through pretty much untouched.

Surge suppressors are just MOVs (metal oxide varistors) and a circuit breaker. If the line voltage rises too high, the MOVs try to shunt the voltage. But if the EMI's peak voltage is below the MOV's trigger threshold, it will do nothing and the EMI will pass straight through.

The DUP profile is meant for use with a single disk. The RAID* profiles are meant for use with multiple disks. Both are necessary to cover the full gamut of BTRFS use cases, but it would probably be good if mkfs.btrfs spat out a big warning if you use DUP on a multi-disk filesystem, as this is /usually/ a mistake.