[-] Scholars_Mate@lemmy.world 27 points 3 months ago

Texas does have anti-SLAPP laws passed and they are among the strongest in the nation. Unfortunately, the courts have ruled that they cannot be used in federal courts.

2
[-] Scholars_Mate@lemmy.world 36 points 5 months ago

Then Linus responded pretty poorly (and ended up stepping down as CEO and is now a chief creative something or other iirc)

Linus didn't step down in response to this. I don't remember the exact timelines, but he either stepped down before this, or was in already in the process of transitioning to the new CEO when this happened.

[-] Scholars_Mate@lemmy.world 30 points 6 months ago

No. Modern SSDs are quite sophisticated in how they handle wear leveling and are, for the most part, black boxes.

SSDs maintain a mapping of logical blocks (what your OS sees) to physical blocks (where the data is physically stored on the flash chips). For instance, when your computer writes to the logical block address 100, the SSD might map that to a physical block address of 200 (this is a very simplified). If you overwrite logical block address 100 again, the SSD might write to physical block address 300 and remap it, while not touching the data at physical block address 200. This let's you avoid wearing out a particular part of the flash memory and instead spread the load out. It also means that someone could potentially rip the flash chips off the SSD, read them directly, and see data you thought was overwritten.

You can't just overwrite the entire SSD either because most SSDs overprovision, e.g. physically have more storage than they report. This is for wear leveling and increased life span of the SSD. If you overwrite the entire SSD, there may be physical flash that was not being overwritten. You can try overwriting the drive multiple times, but because SSDs are black boxes, you can't be 100% sure how it handles wear leveling and that all the data was actually overwritten.

30
83
submitted 9 months ago by Scholars_Mate@lemmy.world to c/pics@lemmy.world
40
[-] Scholars_Mate@lemmy.world 19 points 9 months ago

To native English speakers, yes. To non-native speakers, this is yet another bizarre rule they just have to memorize.

25
submitted 10 months ago by Scholars_Mate@lemmy.world to c/factorio@lemmy.ml
31
submitted 10 months ago by Scholars_Mate@lemmy.world to c/factorio@lemmy.ml
34
submitted 11 months ago by Scholars_Mate@lemmy.world to c/factorio@lemmy.ml
[-] Scholars_Mate@lemmy.world 14 points 11 months ago
  • SLC -> Single-Level Cell, i.e. 1 bit per cell
  • MLC -> Multi-Level Cell, i.e. 2 bits per cell
  • TLC -> Triple-Level Cell, i.e. 3 bits per cell
  • QLC -> Quad-Level Cell, i.e. 4 bits per cell

The more bits per cell you store, the more dense and therefore cheaper your flash chips can be for a give capacity. The downside is that it is slower and less reliable since you have to be able to write and read exponentially more voltage states per cell, e.g. 2 states for SLC, 4 states for MLC, 8 states for TLC, etc.

[-] Scholars_Mate@lemmy.world 14 points 11 months ago

The Trine series is pretty fun. It's a 2.5d puzzle platformer game. There are some combat bits, but most of the game is puzzles. I'd recommend the second one.

[-] Scholars_Mate@lemmy.world 47 points 11 months ago

He killed four of his classmates and wounded seven others. 15 years old is old enough to know how terrible the impact of his actions would be. There is certainly more that we as a society could have done to help him with his mental illness, but that does not erase his agency and make him not responsible for his crimes. He has more than earned his punishment.

28
submitted 11 months ago by Scholars_Mate@lemmy.world to c/factorio@lemmy.ml
[-] Scholars_Mate@lemmy.world 15 points 11 months ago* (last edited 11 months ago)

the timer has no idea if it was triggered during last boot. It only has the context of "this" boot, so it will do it right after a reboot and set a timer to start the service again after a week of uptime.

This is not correct. Persistent=true saves the last time the timer was run on disk. From the systemd.timer man page:

Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive.

OP needs to remove Requires=backup.service from the [Unit] section so it stops running it when it start the timer on boot.

[-] Scholars_Mate@lemmy.world 9 points 11 months ago

You have the timer requiring backup.service, so it will run that service every time the timer starts on boot. Remove Requires=backup.service, and that will fix the issue.

[-] Scholars_Mate@lemmy.world 15 points 11 months ago

Well, for one, it's network attached storage. If it's not present in the network for one reason or another, guess what, your OS doesn't boot... or it errors during boot, depending on how the kernel was compiled and what switches your bootloader sends to the kernel during boot.

Just use nofail in the fstab.

Second, this is an easy way for malware to spread, especially if it's set to run after user logon.

If your fileshare is accessible to you, it is also accessible to malware running as your user. Mounting the share via a filemanager doesn't change this.

50
32
61
[-] Scholars_Mate@lemmy.world 14 points 1 year ago

Holy shit, they actually did it! We're getting train bridges! This looks incredible!

71
[-] Scholars_Mate@lemmy.world 26 points 1 year ago* (last edited 1 year ago)

USB 2 is 480 Mb/s, not 480 MB/s. 480 Mb/s is 60 MB/s, so the 500 MB/s from PCIe 2.0 x1 is quite a bit faster and is about the limit of what a SATA 3 interface could do. Also, sequential throughput isn't nearly as important as most people think. Random IO, which NVMe drives excel at, will make a far more noticeable impact on real world performance.

view more: next ›

Scholars_Mate

joined 1 year ago