Mold, desperation and sadness

I wrote snapshot hooks for Arch that fire before installing or upgrading packages and I have a simple shell alias that I can use to fire off a manual snapshot any time I need one. If a package breaks in an inconvenient way and can’t just be dowgraded back to function or I have some other time pressure I can just point my root partition at a clone of my most recent snapshot and reboot to roll back. I don’t usually bother rebooting into a cloned snapshot to test changes as I can just perform the same steps to roll back and the automated rolling snapshots mean I don’t need to baby anything to have the same protection.

Gimp 4.0 is on schedule for a 2040 release at this point

You can access Gmail over IMAP and pull down messages locally. If you do this; Back. Up. Your. Mbox.

Also, fun fact, you can move messages from a local mbox to Gmail while preserving read status and original dates if you want to add old email to Gmail for some reason.

+1, your list of browser extensions, list of plugins and list of available fonts are also available to anyone trying to fingerprint you. This idea that NAT will somehow obscure you enough to be anonymous online is security voodoo.

Yes, the machine that stays off 363 days of the year is such a security risk to my home network 🙄

Arch Linux so unstable it crashes other devices over the Internet! /S

I use Arch BTW

I mean, the horror of having to tick a box to use rotating v6 addresses. These are all solved problems, they’re not a flaw worth ignoring the entire ipv6 protocol over. Most major operating systems have moved to stable privacy preserving addresses by default, that’s true, but it’s not all that difficult to turn on address randomization and rotation either. And, hell, if you’re that married to NAT as security just use NAT66 and call it a day, nothing about NAT is exclusive to ipv4.

Your firewall should take care of that, it’s pretty rare to be connected directly without one and by default any decent routing package will filter incoming traffic that’s not in the state tracking table. NAT isn’t designed for security, any security benefit it provides is a side effect rather than the intended purpose.

Edit: check out ipv6 privacy extensions too, there are solutions there that can reduce info disclosure if that’s a concern. You can accomplish many of the same benefits of NAT with v6 features without the downsides that NAT brings.

Ipv6 is fantastic, it has less overhead than v4 and removes the need for NAT or other translation. Support can be spotty in cheaper and older devices but there’s no reason not to learn and adopt it where possible.

The only windows machine on my home network is the backup Windows laptop that I only boot when I need to run something like Odin to flash a tablet or some niche Nintendo switch management software.

I’m in favor of dictators worldwide standardizing on the cybertruck thanks. It’ll be easy to disable all of them with a garden hose or a baseball.

Most enterprise drives are TLC these days, MLC just doesn’t provide the storage density that enterprises require anymore. I only mentioned MLC because you’ll occasionally find mSATA drives in the <=256GB range that use MLC. You have to check the datasheet for each model, look for endurance rated at 5DWPD or higher, those will typically be MLC or heavily over provisioned TLC. If you want enterprise drives with greater endurance than the usual 0.5 or 1 DWPD look for the over provisioned models with capacities like 400GB, 800GB, 1.6T or 3.2T. those are 512GB, 1TB, 2TB and 4TB raw capacity drives with a bunch of flash set aside for wear leveling purposes. You don’t often see 300GB, 600GB, 1.2T or 2.4T drives anymore but those are often very high endurance (write intensive, 10 DWPD or so) models.

Check the datasheets for drives when you’re shopping and you can get a pretty good idea of what their durability is like, I usually buy 1 DWPD drives for write occasional bulk storage and 3+ DWPD for anything with a serious write workload. You can also help the drive controller a bit by running blkdiscard against the entire device before partitioning, then only partition and use ~80% of available space. The drive controller will typically grab free unused blocks and use them for wear leveling but only if they’ve been marked free (TRIMmed) and never allocated after. If you can’t find or can’t afford high endurance drives you can usually buy a larger lower endurance drive and over provision it in this way to extend its lifespan.

(The last time MLC flash was really common was back in maybe 2014-2015, some of the older Samsung pro drives like the 850/860 pro were built using MLC. Those had legendary real world endurance, I think they’d get up to 10+PB written before actually failing. It’s a shame they didn’t have PLP because they would have made good budget array storage if they did.)

My approach to this has always been to buy one enclosure and validate it, then go buy like 8 more after thorough testing. Obviously don’t place an order for 10 units of an unknown tech item from AliExpress or you’re looking at a bad time. Look for enclosures that use known good chipsets and there’s not as much risk as you’re expecting. I have something like 8 msata enclosures here that work flawlessly and another half dozen sata+nvme rtl9210b enclosures that also work well.

Buy used Samsung mSata or m.2 2230 drives on fleaBay. Stick with Samsung and other well known brands with decent spec sheets and warranties, that’s the cheapest way to handle durable storage on a pi. USB enclosures are like $5-7 on AliExpress or fleaBay.

Buy MLC drives if you need higher endurance (check the model no and look up the datasheet.) TLC will usually be fine for a few years, MLC will last a bit longer. If you’re killing drives faster than you expect buy larger (512 instead of 256GB), blkdiscard the entire device once it’s installed and then only partition 60-80% of it. Never touch the rest of the freed storage and the drive controller should be able to use those blocks for wear levelling to reduce the NAND wear rate.

Edit: One heads up, I usually buy used drives from eBay because their buyer protection is top tier, if there’s anything wrong with the drive when it’s delivered or when I test it it goes right back for a refund. This makes buying blind viable thanks to an easy return policy.

If you’re sourcing used drives somewhere else insist on seeing SMART data before purchasing and don’t buy heavily worn drives. Look at the drive model datasheet, find the warranted endurance of the drive (if it’s a 512GB drive rated for 1 DWPD over 3y that means the rated endurance is ~ 0.5T * 365 * 3 or roughly ~550TB written over 3y. Pass on buying drives approaching their rated endurance, try to buy lightly used drives wherever possible and you shouldn’t have problems with reliability.

I routinely do 1-4TB images of SSDs before making major changes to the disk. Run fstrim on all partitions and pipe dd output through zstd before writing to disk and they shrink to actually used size or a bit smaller. Largest ever backup was probably ~20T cloned from one array to another over 40/56GbE, the deltas after that were tiny by comparison.

Cold War 1 never ended, the west got a kick out of telling everyone that they won and took their eye off the ball while Russia continued playing.

There are more Russian agents in the US now than ever before and I guarantee that Europe is getting the same treatment. Small amounts of spending can yield outsized results for Russia, they learned this 50+y ago and are continuing to act on it.

Because you’re relying on compatibility between older Debian software (systemd, etc) and newer versions installed in the chroot. Things get weird quickly.

Consider a nested privileged container instead (LXC or similar) and cross your fingers that Debian systemd and Arch systemd play nice.

If the above fails just make a VM and pass through the GPU with GVT-g (otherwise pass through the entire GPU.)

If all of that fails install Arch to a USB attached SSD or something.

If you’re using an Intel chip look into GVT-g and consider running Arch from a VM, that’ll be the closest thing to native.

The unfortunate thing about running an Arch container from a Debian host is that you’re relying on an older kernel and an older systemd host side and I’ve found that often causes compatibility problems inside the Arch container. If you are very, very lucky Arch will just work inside the container, but IME that’s fairly rare as systemd often has breaking changes over several releases (and Arch tends to be at least several releases ahead of Debian.)

deleted by creator