𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 @ sxan @midwest.social

🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆.

---

Read more

Posts

26

Comments

3,729

Joined

3 yr. ago

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.

I think they're looking to, like, call grandma on her telephone, not do a video call. Does Meet let you call land line telephone numbers now?

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.

@ikidd@lemmy.world 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.

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.

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.

I did some light reading. I see claims that wear leveling only ever writes only to zeroed sectors. Let me get this straight:

If I have a 1TB ssd, and I write 1TB of SecretData, and then I delete and write 1TB of garbage to the disk, it's not actually holding 2TB of data, with the SecretData hidden underneath wear leveling? That's the claim? And if I overwrite that with another 1TB of garbage it's holding, what now, 3TB of data? Each data sequence hidden somehow by the magic of wear leveling?

Skeptical Ruaraidh is skeptical. Wear leveling ensures data on an SSD is written to free sectors with the lowest write count. It can't possibly be retaining data if data the maximum size of the device is written to it.

I see a popular comment on SO saying you can't trust dd on SSDs, and I challenge that: in this case, wiping an entire disk by dumping /dev/random must clean the SSD of all other data. Otherwise, someone's invented the storage version of a perpetual motion device. To be safe, sync and read it, and maybe dumb again, but I really can't see how an SSD world hold more data than it can.

dd if=/dev/random of=/dev/sdX bs=2048 count=524288

If you're clever enough to be using zsh as your shell:

repeat 3 (dd if=/dev/random of=/dev/sdX bs=2048 count=524288 ; sync ; dd if=/dev/sdX ba=2048)

You reduce every single cell's write lifespan by 2 times; with modern life spans of 3,000-100,000 writes per cell, it's not significant.

Someone mentioned blkdiscard. If you really aren't concerned about forensic analysis, this is probably the fastest and least impactful answer: it won't affect cell lives by even a measly 2 writes. But it also doesn't actually remove the data, it just tells the SSD that those cells are free and empty. Probably really hard to reconstruct data from that, but also probably not impossible. dd is a shredding option: safer, slower, and with a tiny impact on drive lifespan.

Educate me.

My response would normally be: dd if=/dev/random of=/dev/sdX ba=1024M, followed by a sync. Lowest common denominator nearly always wins in my book over specialty programs that aren't part of minimal core; tools that also happen to be in BusyBox are the best.

What makes this situation special enough for something more complex than dd? Do SSDs not actually save the data you tell them to? I'm trying to guess at how writing a disk's worth of garbage directly to the device would fail. I'm imagining some holographic effect, where you can actually store more data than the drive holds. A persistent, on disk cache that has no way of directly affecting, but which can somehow be read later and can hold latent data?

If I were really, I'd dd, read the entire disk to /dev/null, then dd again. How would this not be sufficient?

I'm honestly trying to figure out what the catch is, here, and why this was even a question - OP doesn't sound like a novice.

I have to put in a plug for herbstluftwm.

It really depends on whether you like the keyboard and tiling widow managers, or if you like dragging windows around and resizing them. Tiling widow managers are popular, but they're definitely a taste.

hlwm and bspwm are a - "configurationless" breed - I think river on Wayland is the same. This has become my one requirement for a window manager. Every configuration is done through a command line client call, and it's game changing. The "configuration" is just a specific shell script hlwm runs when it starts up, and it's full of whatever client calls needed to configure the system. Every call in that script can be run outside the script; it's literally a just shell script. I run all sorts of things in that script: launching "desktoppy" programs like kanata, setx, autostart programs that start on a specific screen; one script lays out one screen in a complex 2x1 layout where each pane is tabbed and contains three terminals each, and then launches terminals that connect to various remote computers - that's my "remote server" screen, and it's all set up when I log in.

However - definitely for tiling enthusiasts. I used i3 for a decade before I found bspwm, which converted me to configurationless WMs, and I ended up with hlwm. It's honestly what's preventing me from giving Wayland a serious go, although river might do the trick.

Certainly, although OSX has enough closed source parts, and obfuscation is good enough to let a supply chain attack live in Go's module ecosystem for years. Obfuscation is reasonably effective, especially when the DMCA in the US makes reverse engineering legally hazardous, and it's iffy in the EU as well. Anyone who found an issue would have to make it public very anonymously.