Cool that someone put the pictures together. I knew they were named after Toy Story characters, but as someone who's only watched the movie once or twice, I didn't know all the minor characters, and never bothered to look them up.
duncesplayed
joined 2 years ago
Anne Frank advertising baby clothes before discussing the horrors of the Holocaust
Wow, that is amazingly inhumane.
My first thought is they're necessarily making characters who aren't people. A person who has lived through the Holocaust just cannot cheerfully peddle baby clothes. I don't mean that it's physically not possible because she's dead: I mean in terms of the human psyche, a person just flat-out psychologically could not do that. A young boy who succumbed to torture and murder psychology cannot just calmly narrate it.
So obviously, yeah, it's quite a ghoulish and evil thing to take what used to be a person, and a figure who has been studied and mourned because of their personhood, because we can relate to them as a person, and just completely strip them of their personhood and turn them into an inhumane object.
But then that leads to me the question of, who's watching these things, and why? The article says they got quite a lot of views. Is it just for shock value? I don't quite understand.
OMF is by far the best fighting game I've ever played. Absolutely unmatched.
I chatted with Kenny Chou/cccatch on IRC once (the guy who wrote the soundtrack to OMF) and he told me about the technology stack they used for music in that game, which I found pretty interesting. He wrote the music in MultiTracker Module Editor and they had some proprietary software that would convert .MTM files into the music engine's native format and package them up. The clever thing is that all the songs were saved together in one package, which means that if he reused the same samples in all of the songs (which he had to do), then the tool would be clever enough to have each sample on disk/in memory only once, so samples only had to be loaded when you started the game. Then when the game switched songs, only the pattern data (notes) had to be freed/loaded.
I'm sympathetic to a Windows install taking days (I've been there), but you're right that it's not Windows' fault. It's always some 10 year-old hardware with dodgy or no-longer-supported drivers. Maybe you could make an argument that it's partly Windows' fault because they push driver support onto the hardware vendors, rather than use Linux' model of having the kernel developers maintain them.
Digg, ... don’t fail in a day
It depends on precisely what you mean by "fail" and how strictly you take "day", but Digg did lose 50% of its traffic within 30 days (and it never recovered).
Not the exact StagingTool, but the GitHub project mach2 that's linked to in the article supposedly supports many of the same features as StagingTool, I guess kind of an open source clone.
Edit: to add more detail. If you look in the project for some files that have been updated recently, such as this one, the feature list includes some numeric codes at the top, which are the same ones StagingTool uses. The ones without any symbolic name at all, I believe, are ones that have not been determined yet what they do.
I had a similar situation.
I had an old laser printer that was officially unsupported on OS X. Meaning that they had a driver for OS X for a similar model, but not exactly the same model, that supposedly worked for it, but they deliberately did not let you use it with my model of printer. Found some crazy instructions online that told you to install the drivers, then change the driver with a hex editor to force it to recognize your printer as a different model. It worked, occasionally, intermittently. I spend like half a week trying to get it to work under OS X and it just wouldn't work reliably.
Tried a Windows computer. Wasted half a day installing a driver, uninstalling a driver, plugging in, unplugging, turning on, turning off, but it just couldn't recognize it.
Booted into Linux and hit "print" and it worked perfectly. Didn't even need to install a driver.
TPM's not going to help with that situation, though, right? Either you're typing in your encryption password on boot (in which case you don't need TPM to keep your password), or you're not, in which case the thief has your TPM module with the password in it.
BitWarden+PiHole+NextCloud+Wireguard combined will add to like maybe 100MB of RAM or so.
Where it gets tricky, especially with something like NextCloud, is the performance you see from NextCloud will depend tremendously on what kind of hard drives you have and how much of it can be cached by the OS. If you have 4GB of RAM, then like 3.5GB-ish of that can be used as cache for NextCloud (and whatever else you have that uses considerable storage). If you have tiny NextCloud storage (like 3.5GB or less), then your OS can keep the entire storage in cache, and you'll see lightning-fast performance. If you have larger storage (and are actually accessing a lot of different files), then NextCloud will actually have to touch disk, and if you're using a mechanical (spinning rust) hard drive, you will definitely see the 1-second lag here and there for when that happens.
And then if you have something like Immich on top of that....
And then if you have transmission on top of that....
Anything that is using considerable filesystem space will be fighting over your OS's filesystem cache. So it's impossible to say how much RAM would be enough. 512MB could be more than enough. 1TB could be not enough. It depends on how you're using it and how tolerant you are of cache misses.
Mostly you won't have to think about CPU. Most things (like NextCloud) would be using like <0.1% CPU. But there are some exceptions.
Notably, Wireguard (or anything that requires encryption, like an HTTPS server) will have CPU usage that depends on your throughput. Wireguard, in particular, has historically been a heavy CPU user once you get up to like 1Gbit/s. I don't have any recent benchmarks, but if you're expecting to use Wireguard beyond 1Gbit/s, you may need to look at your CPU.
It's predominantly the first one. They have made a few unique design decisions, but is a fairly conservative "boring" RISC design. The only thing remarkable I can think of of the core ISA is the fact that they have no conditional status registers (no NZVC bits), so you have to kind of combine conditions and branches together, but that's not exactly unprecedented (MIPS did something similar).
In the ISA extensions, there is still some instability and disagreement about the best ISA design for some parts. Just the fact that RISC-V is going to have both SIMD and Vector instructions is a bit unique, but probably won't make a huge difference.
But it's a fairly boring RISC design which is free and open and without any licensing hoops to jump through, which is the most interesting bit.
If I can try to summarize the main findings:
- Computer-generated (e.g.., Stable Diffusion) child porn is not criminalized in Japan, and so many Japanese Mastodon servers don't remove it
- Porn involving real children is removed, but not immediately, as it depends on instance admins to catch it, and they have other things to do. Also, when an account is banned, the Mastodon server software is not sending out a "delete" for all of their posted material (which would signal other instances to delete it)
Problem #2 can hopefully be improved with better tooling. I don't know what you do about problem #1, though.
True as long as they keep an ad-free tier.