I don’t think his statement is true though. If https://www.reddit.com/r/linux_gaming/comments/1ce7z19/gaming_on_linux_ep131_ntsync_vs_fsync_nobara_39/l1ho8od/ is not manipulated in any way, games with lots of these calls still get big improvements with ntsync over fsync (about 30% in this particular case, which is a massive boost). So while nobody can rule out that his statement may be true on average or in general, there are still cases where ntsync offers a tangible advantage – be it improved FPS or the fact that the game runs at all.

Yes, sorry

If you know that you want to play a game that only runs on Windows?

It’s their device, I never tried Windows on the notebooks I bought in recent years either

Any linking against GPL software requires you to also release your source code under GPL. ALGPL allows you to link to it dynamically without relicensing, but as explained, there are platforms where dynamic linking isn’t an option, which means these libraries can’t be used if one doesn’t want to provide ALGPL licensed source code of their own product.

fsync isn’t faster than ntsync, it’s merely a workaround to match Linux to Windows synchronization primitives. From ntsync’s official description:

It exists because implementation in user-space, using existing tools, cannot match Windows performance while offering accurate semantics.

So without this, you either have a huge perfomance hit in case of an accurate implementation or you have good performance, but might run into edge cases where software doesn’t work well or at all because it’s not accurate (see https://github.com/ValveSoftware/Proton/issues/2922 for examples)

Apart from security and upgrades, there might arise situations where you want to change aspects of the underlying operating system, and these changes might require changes to the source code.

Also if you remember Stuxnet, those computers were also airgapped not connected to the internet.

One goal of ReactOS is to run Windows drivers, which Wine can’t do. There are old specialized devices with Windows exclusive drivers still running in production requiring something like Windows XP or 2000. You can’t replace these with Linux and Wine. It makes sense for Russia to sponsor it; they probably depend on these old installations in either their refineries or somewhere in their nuclear program.

Fuck Russia but I wouldn’t interpret too much into this

the average package quality is currently closer to that of the AUR than the official repos of other distros.

Care to elaborate? I don’t remember packages not working, but if anything, they’re not building; which is basically the reverse of what happens at other distributions where sometimes, breakage during building isn’t noticed because the packages aren’t getting rebuilt when a dependency or the compiler toolchain changes.

While the full number might be inflated, it still has one of the most complete official repositories.

You can game “now” ? 🤨

Well, you can… in fact you you could also before… but it’s technically correct

True! My original point though is that just providing a hash for a downloaded file is generally not required. It doesn’t provide anything that other layers haven’t already (a hash only guarantees integrity, while downloading over HTTPS provides authenticity). Personally, I see them as a relic of the past that made more sense when transmission was less robust (though even back then, a lot of layers provided some sort of error detection and correction), and modern filesystems can detect errors as well.

Those must have been really helpful in 1999.

Or any long-running process that’s attached to a terminal for which you can’t or don’t want to guarantee that you keep it open all the time, yet still want to look at the output.

As someone said. they’re different things, though they overlap in some areas.

Probably still looking for hosts that have weak Debian SSH keys that users forgot to replace. https://www.hezmatt.org/~mpalmer/blog/2024/04/09/how-i-tripped-over-the-debian-weak-keys-vuln.html

While still not correct with that in mind, the “initially” refers to a sound server a that sits above ALSA. There were others before Pulse, for example the aRts daemon and ESD. However, these were mostly used within their respective Desktop Environment while the rest used ALSA directly, so Pulse being the first Sound Server being widely used under Linux is one way to look at it. JACK on the other hand never left the (semi)professional niche I think.

In fairness to Pulse, Pipewire built heavily on its foundation; in fact, is initially was only supposed to be “Pulseaudio for video”, and Pulse led to huge improvements in ALSA and audio drivers. Pipewire simply couldn’t have worked as well back then as it does today if it had been released when Pulse was initially.

Rust is dead. Haven’t you heard? We’re rewriting everything in Zig now.

I don’t think the broader zig community has the rewrite spirit that the rust community has. For Rust, this mentality was also motivated by an increased security, which zig does improve over plain C, but not to the extent Rust does.

To preface anything that follows, I’m not a developer, so this is little-informed opinion.

Writing in rust just doesn’t seem very enjoyable. It’s a language with security in mind, which is a good thing. However, zig also isn’t inherently insecure (though it doesn’t provide the same security guarantees) and coding in it just seems so much more pleasant. To me, the language makes more sense, which is also something I like about Go. Even manual memory allocation looks well-designed. At no point did I look at zig and thought “oh, that’s an odd choice”.

The language isn’t frozen yet though, so everything you write in it may require changes later on, so I wouldn’t recommend it for anything in production. Notably, there’s no built-in async or something comparable. If you’re fine with these limitations, go ahead and try it out, and if you feel like it, maybe even rewrite an existing tool in it.

ncdu for example is such a tool where the original author rewrote it in zig for version 2.

Ah cool, that’s interesting.

SDL is kind of the equivalent to DirectX. It provides a standard interface for multimedia applications regardless of underlying mechanisms. Except the 3D acceleration part I think which is handled by OpenGL / Vulkan.

Realtime is not about being fast, it’s about time guarantees. It helps with or is required for workloads that require realtime, which I think includes audio production, but might also be helpful for things like controllers etc. where you need to make sure incoming data is processed in a guaranteed time or else fail. Browsing the web isn’t part of these, so an RT kernel will most likely be a hindrance.

My opinion : far too many distros are « pet distros »

I think those are actually great. Personally wouldn’t use them for a prolonged time or anything critical. But I love the spirit, even if the distribution is of no use to me.