KubeRoot

The weakest part of any security system is the people.

Well, maybe not any, but most ;D

Shouldn’t it be more efficient to download only the changes and patch the existing files?

As people mentioned, that becomes problematic with a distro like arch. You could easily be jumping 5-6 versions with an update, with some more busy packages and updating less frequently. This means you need to go through the diffs in order, and you need to actually keep those diffs available.

This actually poses two issues, and the first one is that software usually isn’t built for this kind of binary stability - anything compiled/autogenerated might change a lot with a small source change, and even just compressing data files will mess it up. Because of that, a diff/delta might end up not saving much space, and going through multiple of them could end up bigger than just a direct download of the files.

And the second issue is, mirrors - mirrors need to store and provide a lot of data, and they’re not controlled by the distribution. Presumably to save on space, they quickly remove older package versions - and when I say older, I mean potentially less than a week old. In order for diffs/deltas to work, you’d need the mirrors to not only store the full package files they already do (for any new installs), but now also store deltas for N days back, and they’d only be useful to people who update more often than every N days.

Ah, sorry, I confused you for the original commenter. The first sentence is a bit nonsensical, it is a bit rude and snarky, but I meant it as a joke, since I had the wrong impression the person having issues with flatpak steam is asking about issues with flatpak steam.

I don’t have a reference, but I’ve been seeing random individuals asking for help and finally saying they fixed their issue by switching away from flatpak, so… You, I guess? Your.problem might be a perfect example of one of the many problems that keep popping up, that seem to only happen on the flatpak version.

I think you’re wrong about one thing - it’s not about compute cost, but about complexity of accounting for latency. You could check if the player can see the enemy they’re claiming to have shot, but you really need to check if they feasibly could’ve seen the enemy on their computer at the time they sent the packet, and with them also having outdated information about where the enemy was.

The issue gets more complex the more complex the game logic is. Throw physics simulation into the mix and the server and clients can quickly diverge from small differences.

Ultimately, compensating for lag is convoluted, can still cause visible desync for clients (see people complaining about seeing their shots connect in CS2 without doing damage), and opens up potential issues with fake lag.

More casual games will often simply trust the client, since it’s better for somebody to, say, fly around on an object that’s not there for other players, than for a laggy player to be spazzing out and rubberbanding on their screen, unable to control their character.

I suppose the thing I’m worried about is more general Linux SteamVR support than the streaming itself… But duh, the headset can run games on Linux standalone, so they’ve gotta have SteamVR working well. The only question is, am I behind on the news, or have they been holding back the updates internally?

I do believe they called out that the steam machine is designed to work with the frame, right? I’d have expected to see Linux SteamVR updates leasing up to this, to get it fully fixed up and tested ahead of time, though I might also have missed something…

Both java and go seem excessively complex at runtime for fundamental system utilities, featuring garbage collection. Rust, on the other hand, keeps the complexity in the compiler and source, keeping the runtime code simpler. And of course it’s doing that while trying to make it easier to manage memory and harder to make mistakes, without forcing extra runtime logic on you.

I think most of the work is in the fact that there often isn’t an “equivalent call”, and it can be quite a lot of code to make it work. One funny thing is the whole esync-fsync-ntsync issue, where synchronization is done differently on Linux and on windows, and translating it was a big performance hit, and difficult to do accurately. If I understood correctly, esync, fsync and ntsync were a series of kernel patches implementing additional synchronization code in the kernel, with ntsync actually replicating the windows style.

Not the same person, but the Hyprland developer is… controversial, so that could be the reason.

I might be wrong, but I don’t think proton is either? It’s running x86 instructions either way, wine just provides a way to load it from the windows executable and library formats, and together with proton they provide implementations of windows libraries for those executables to use.

Are you sure that site is trustworthy? It kinda reads like an LLM being told to explain the difference between two names for the same thing and basically rephrasing the same thing. I’d imagine it might just be a different name to get rid of a male-coded word.

It definitely didn’t always require a wipe - I think it might be storage encryption by default that was introduced, that made it a requirement, where modifying/replacing system/bootloader components means it can’t decrypt the data anymore.

If I understand correctly, it’s a different kind of “immutable”, since distros like Bazzite provide premade immutable images you use and anything else you need you install using alternative means, whereas NixOS is an immutable image generator that requires you to set up your own definitions for the image, but also lets you install software by adding it to that image.

The game, including worldgen, will still bug out at longer distances - the issues were reduced and a world limit was added to prevent you going too far, and IIRC past a certain point the world turns into non-stop ocean, but I’m pretty sure if you bypass those limits you’ll encounter chunks that outright fail to generate.

In-memory kernel patching is complicated, AFAIK only select distributions support it, right? If kernel hotswap is successfully implemented this way, it should allow switching between arbitrary kernels at runtime without extra work or setup.

Of course, that’s a pretty big “if”, but a simple unified system sounds like a great thing. And of course there’s more to this than swapping kernels.

That actually sounds like a fun SCP - a word that doesn’t seem to contain a letter, but when testing for the presence of that letter using an algorithm that exclusively checks for that presence, it reports the letter is indeed present. Any attempt to check where in the word the letter is, or to get a list of all letters in that word, spuriously fail. Containment could be fun, probably involving amnestics and widespread societal influence, I also wonder if they could create an algorithm for checking letter presence that can be performed by hand without leaking any other information to the person performing it, reproducing the anomaly without computers.

I’m not a security expert, but to my knowledge that’s the point - even a unique salt global to your site/service can help. Worth mentioning are rainbow tables, which are databases of hashes for known strings, so you can take a hash and look up the string, and very easily defeated by salts.

If the password is securely hashed, and the attack only includes data exfiltration, then there’s theoretically no risk of breaking into users’ accounts anyways. However, the issue is that if somebody can log into your Plex account, that means they got your password somehow - and if they did get that password, they can use it elsewhere. So if there’s any reason to change your password on Plex, then there’s just as much reason to change that same password elsewhere.

I do think they missed a bit about password reuse, since they tell you to reset the password on their site, you should be changing the password on any other sites where you reused it. But yeah, not arguing about it being good otherwise.