As I said, every file read from disk, be it an executable, image or whatever gets cached in RAM automatically and always.

Having said that, if you read a file using read(2) (or like any API that uses read() internally, which is most), then you end up with two copies of the file in RAM, the version your OS put in the disk cache, and the copy you created in your process’s memory. You can avoid this second copy by using mmap(2). In this case the copy of the file in the disk cache gets mapped into your process’s memory, so the RAM is shared between your copy and the disk cache copy.

You can also give hints to the disk cache subsystem in the kernel using fadvise(2). Don’t though unless you know what you’re doing.

Does that stuff still happen? I didn’t try this but I had kinda hoped this stuff got fixed with the introduction of systemd.

This doesn’t explain what a disk cache (afaik often refered to as page cache) is, so here goes: When any modern OS reads a file from the disk, it (or the parts of it that are actually read) gets copied to RAM. These “pages” only get thrown out (“dropped”) when RAM is needed for something else, usually starting with the one that hasn’t been accessed for the longest time.

You can see the effect of this by opening a program (or large file), closing it, and opening it again. The second time it will start faster because nothing needs to get read from disk.

Since the pages in RAM are identical to the sectors on disk (unless the file has been modified in RAM by writing to it), they can be dropped immediately and the RAM can be used for something else if needed. The downside being obviously that the dropped file needs to be read again from disk when it is needed the next time.

They’re a sucker who’s gonna get fleeced. If they answer that they know the game is rigged (as most of them will), but that they totally understand how this works, they’re a super sucker who’ll get double fleeced.

I know all that. That doesn’t answer how this is supposed to work at all.

I don’t understand what the endgame is supposed to be here. In order to achieve its stated goals (demilitarization, denazification, catching their list of enemies), Russia needs to occupy (which they said they won’t, which makes no sense). There’s no way Ukraine’s govt can agree to or implement these demands.

So Russia will in fact need to occupy Ukraine and install a puppet govt. But how the are they ever going to get out of there ever again? That new government will get removed as soon as they leave.

So long term occupation it has to be, which will be a total disaster and that’s on top of the sanctions. Russia just fucked itself, no? How does any of this make sense?

Calling Ukraine neutral after the Western-backed coup of 2014, in which the US candidate became PM and Russian-hating Neonazis got into government is some twisting of facts. The whole Maidan (which was supported massively by Western governments, press and NGOs) was about aligning with the West for fuck’s sake! The invasion only happened after that.

Radio War Nerd. It’s a history podcast with a focus on war, but they do have some discussion about current conflicts too. They do a good job telling stories. This is NOT a technical podcast about weapons and such.

Debian allows setting up disk encryption during install for example. Never heard of VeraCrypt, I don’t think that’s popular on Linux. The relevant under the hood parts if you’re interested in how it works on Linux are:

• dm-crypt: Linux kernel feature for accessing encrypted partitions
• Luks: A header format / standard for encrypted partitions
• cryptsetup: command line tool to set up and manage all this

Linux accepting patches from Facebook that improves btrfs isn’t the same thing as working with Facebook on ad tech tracking proposals.

I haven’t read the thing and I’ll be waiting for someone decently trustworthy to explain this to me, but I consider tracking and advertising to be immoral, so this doesn’t bode well.

Yeah, looking at this list, there are multiple things that could cause worse outcomes in practice.

The most problematic IMHO are the I/O prio and niceness. This is because other processes like xorg and the compositor (and maybe even kernel threads, though not sure if you can starve those) need I/O and CPU too when running a game, and they get starved by the game hogging these resources. I remember when running the original StarCraft through wine you needed to de-nice it to avoid starving the X server of CPU.

Of course some of the other stuff is also sketchy since it could increase temps and therefore induce throttling. Depends on how good the cooling is I suppose.

A low latency scheduler can increase overhead and thus reduce average fps, but should not really increase stuttering (probably the opposite), so I don’t think that’s the problem really.