Yeah. This fantastic woman married me. I have no idea why.

Also, I really don’t understand rockets at more than a superficial level, but I saw one launch once.

I’m quite uncertain about jet airplanes, especially when you’re, like, driving in the same direction and there’s a strong headwind, and it almost looks like you’re going faster than them? They’re just hanging there, god knows how many tons of metal and 300 people. It’s creepy.

And I really think economics is proof that we’re in the Matrix, because the more I think about it, the less (functional, not ethical) sense capitalism makes, and everybody who talks like they know about it just sounds like stringing together a bunch of buzzwords. Also, there’s that truism that if you ask four economists a question, you’ll get five opinions. Plus nobody can reliably predict the stock market; weather - a highly chaotic system - is more predictable than the stock market. It’s like the programmers put it in, but when it got to the point where they had to make it explainable, they couldn’t without introducing recursive conflicting rules, so it’s just hand-waving, and people pretending or misleading themselves that they know how it all works.

Sorry, it wasn’t the Arch wiki. It was this page.

I hate using Stack Exchange as a source of truth, but the Arch wiki references this discussion which points out that not all SSDs support “Deterministic read ZEROs after TRIM”, meaning a pure blkdiscard is not guaranteed to clear data (unless the device is advertised with that feature), leaving it available for forensics. Which means having to use --secure, which is (also) not supported by all devices, which means having to use -z, which the previous source claims is equivalent to dd if=/dev/zero.

So the SSD is hiding extra, inaccessible, cells. How does blkdiscard help? Either the blocks are accessible, or they aren’t. How are you getting a the hidden cells with blkdiscard? The paper you referenced does not mention blkdiscard directly as that’s a Linux-specific command, but other references imply or state it’s just calling TRIM. That same paper, in a footnote below section 3.3, claims TRIM adds no reliable data security.

It looks like - especially from that security paper - that the cells are inaccessible and not reliably clearable by any mechanism. blkdiscard then adds no security over dd, and I’d be interested to see whether, with -z, it’s any faster than dd since it perforce would have to write zeros to all blocks just the same, rather than just marking them “discarded”.

I feel that, unless you know the SDD supports secure trim, or you always use -z, dd is safer, since blkdiscard can give you a false sense of security, and TRIM adds no assurances about wiping those hidden cells.

Mine’s: “ummmmm…”

Ever see Minority Report?

That, but without the psychics. Insurance companies use things called actuary tables to estimate risk. If they have your DNA, they could decide that, since you have markers for early onset Alzheimer’s, they’re going to charge you double for life insurance.

Law Enforcement could decide that, since you share some trait with other common criminals, you’re more likely to do crime, and get warrants to surveil you more closely. Maybe you don’t do crime, but you get pulled in for a crime in the neighborhood because you’re the one with the highest crime DNA score, and that’s enough to convict you. Maybe you get pulled over more often for going a little over the speed limit, because you’re being watched more closely. Maybe they just decide you’re so likely to do a crime, they imprison you proactively.

None of this is absurd; it’s all been done before. The Nazis used to evaluate people by how big their skulls were - this is Eugenics on fucking steroids, backed by the smell of legitimacy because DNA. People have wrongly gone to prison and served entire sentences because of bad DNA testing, and it’s still used.

This should worry you. It’s not hypothetical, it’s not a conspiracy theory - the potential for abuse of a database like this should concern everyone, liberal or conservative.

Like all those white supremicists who discovered they have black ancestors; only, now, all their little KKK friends know, too!

It doesn’t. This is targeted at application builders. Could be an honest mistake; could be astroturfing.

You’re right, good catch. Now I’m going to have to go see how it’s set up; I thought it was being done in btrfs.

Then over-writing the size by a few gigs, reading the entire disk, and writing it again - as I put in my example - should work. In any case blkdiscard is not guaranteed to zero data unless the disk specifically supports that capability, and data can be forensically extracted from a blkdiscarded disk.

The Arch wiki says blkdiscard -z is equivalent to running dd if=/dev/zero.

Back in the old days you paid for a cable subscription and got to watch ads every 15 minutes

Oh, hell no. We had HBO my entire teen years, and that was the huge difference between cable and broadcast - there were no commercials on HBO.

I never had cable as an adult; I didn’t like being beholden to someone else’s tastes and show times, so we just rented videos: Blockbuster, or more often the locally owned rental place - they had weirder stuff.

When Cable became “infinite channels,” they did start showing ads, but that wasn’t paying for content: that was paying for delivery. It was supersized broadcast TV. To emphasize this, packages cost extra, and those special, extra channels (HBO, etc) didn’t have commercials. The basic package was just extra broadcast TV.

Netflix is more analogous to HBO than cable. Supporting this is their original operating model: a subscription fee that got you DVDs mailed to your house. Just like a subscription fee to Blockbuster that got you a certain number of rentals per month.

Don’t try to normalize it by claiming “it’s always been this way,” because it hasn’t.

television was designed around the advertising break

Television was free. Netflix was originally movies. Movies don’t have ads (not specific, non-story related ones, anyway; they’ve always had product placement). It’s been only relatively recently that Netflix has gotten into the episodic game, which is even less justification for ad breaks, because episodes are shorter than movies. Which have no ads.

You’re entitled to pay for what you like and be happy with it, buy fuck if I’m going to pay someone to watch their ads. If I was a TV watcher, I’d pay for choice - a thousand channels, with ad-ridden content. I draw the line at going to a movie theater, paying for a ticket, and then having the movie interrupted with ads, which is what this is equivalent to. You can always skip the ones up front with timing, and fuck those ads too.

Fair enough question. I don’t think it deserves the downvotes - the answer is informative.

FeeeVoipDeal is super cheap

With “Free” in the name, I should hope so.

I have no doubt ZFS is solid, too, FWIW. I leaned toward btrfs because it was simple, the commands straightforward and clear, nothing required more than one step - this is all super valuable to me because there are other things I want to spend my time on than fiddling with the filesystem.

@[email protected] said that btrfs is poor at software RAID.

You should check for yourself. I haven’t used software RAID in years - RAID 0+1 gives me no value - but the btrfs team and Arch wiki say 0, 1, and 10 are solid. You should not use 5 or 6, as they’re known to be buggy and even the btrfs man page tells you to not use it. So, yeah? btrfs is poor at RAID 5/6; to my understanding, it’s good at 0/1/10.

btrfs can do encryption, compression, snapshots, and some RAID. I found combining mdadm and lvm and FS built a jenga tower, of which if part failed, the entire end result was borked. I once did an OS upgrade and lost the mdadm config, and spent two days recreating it. I never used it on a new machine after that. Separation of concerns is great, but having an all-in-one that can self repair and boot into snapshots is better.

I can’t speak to performance. No doubt Toms of someone like that’s looked into that in detail.

What was the context? This is the first time I’ve ever seen this person.

Yeah, the one in my car was on the old AT&T GSM network. I’m pretty sure there’s no network left for it to talk to, but I’d still like to find the component and wrap it in aluminum foil. The car’s been paid off for 6 years, and OTA services cut off a couple years after that. There’s no legitimate (from my perspective) reason for anyone but me to be able to talk to my car.

I did read (on the Arch wiki) that blkdiscard -z is identical to dd if=/dev/zero, so that tracks. It’s (blkdiscard) is easier to use. However, given my memory and how infrequently I’ll ever use it, I’ll have forgotten the name of the command by next week. I’ll never forget dd, though, mainly because it’s more general purpose and I use it occasionally.

OP probably wants blkdiscard -z, though.

IME, btrfs is easier to work with than ZFS. It has all of the features you asked for; its RAID ≠ 0/1/10 are buggy, but 0/1/10 are considered reliable. In the past year, I heard a rumor that they were going to announced RAID > 1 to be also stable, but that’s hearsay; I haven’t read anything authoritative on the subject - the Arch btrfs page and the btrfs man page both still say 5/6 are not reliable.

I’ve been using btrfs on a variety of computers and VMs, from tiny little ODROIDS, to laptops, to VPSes, to desktops for… over a decade? I’ve had much better reliability than ext4. I was attracted to the POLS of the commands, vs ZFS.

I don’t know how much my opinion weighs; I have a feeling a data center person would suggest ZFS as being more “enterprise”. I’ve been really happy with it. I’ve been watching bcachefs for the caching and target options - really neat features useful for home gamers - but otherwise I wouldn’t bother - btrfs has been solid and done everything I could want. It was a huge upgrade from mdadm and lvm in UX, and was only possible when disks got so cheap they outpaced my need for RAID5, and I could afford multiple backup drives that held years worth of nightly incremental backups.

Hum. I read that blkdiscard only marks the blocks (cells?) as empty, and doesn’t change the contents; and that a sophisticated enough lab can still read the bits.

In particular, the disk has to claim to support “Deterministic read ZEROs after TRIM”; if it doesn’t, you have no guarantee of erasure. Without knowing anything about the make and model, blkdiscard would be categorically less secure.

Right?

Not that much extra.

Yes, too bad it’s impossible.

/s

I definitely make sure to annotate jokes that I feel may offend someone. Otherwise, ibi nullus timet mortem sed pro Baccho mittunt sortem.

Oh, man. That was bad. I love it.

I agree dd isn’t useful for individual files. I contend that if I have an SSD of size X, and I write X amount of random bytes to it, there’s nothing magic about the SSD construction that will preserve any previous information on the drive. Wear leveling can not magically make the drive store more data than it can hold.