kuberoot

I sure hope people don't copy him, but arguably he's also experimenting with cheap designs for high-power switches and safety, and seems to know what he's doing. Not sure if he'll actually end up contributing anything meaningful to science, or if it'll forever just be entertainment, but it's better than a lot of things that money gets pumped into either way.

Yeah, it's so annoying how every crossplatform project is having to do that, it's such a burden on all those indie developers all managing so much hardware and automation to support those platforms. /s

I think I've seen the same argument against Linux package managers in general, and it's bullshit in the way that it's not on the projects to package for each distro, it's on the project to provide a functioning build system, or at least binaries, and from there it's on the distribution maintainers to figure out packaging.

But also, in cases where packaging is more complex than just one dependency system for a whole language, it would be beneficial to have one unified system - if all languages are packaged in a unified way for specific system package managers, then you only need to develop a system for them once across all languages, and then you might have one system you need to plug your project into, and from there it could be automatically packaged into all those systems.

Worth noting is that C# generally uses compiled libraries, not quite binaries but CIL rather than source code, so that's what you get when adding references and NuGet packages. And at the same time, compiled C# files include a lot of metadata about the code, like class structure and method signatures, so one .DLL is all you need to use a library.

NPM is a more complex situation. To say there is one build system is already misleading, since there isn't a build system built into JS - packages can be source distribution, or they can use a variety of tools, minifiers, packages for web or for Node, and occasionally include native libraries/binaries or otherwise compile native code from other sources.

I think generally new languages have their own package managers primarily because older languages weren't planned for convenient dependency management, so solutions for that are stapled on top of their stuff, aren't compatible with existing libraries, often have some annoyances, and there are often multiple alternatives that were independently developed. On the other hand, new languages can just plan things out from the start, tweaking the language to work well for libraries, and establishing a single tool to avoid fragmentation.

The image in the comment mostly just feels hipster to me, and that would fit jumping on a currently trendy distro that's also technically Arch. I don't know if there's more to it, it's just a vibe thing for me.

Don't take those memes seriously, I think the only bad thing I'd have about CachyOS is that it's probably getting popularity as a trend, which doesn't reflect on the distro itself.

In my particular personal opinion it seems like a good choice if you already know what you're doing, since it's mostly just Arch with a nice installer, which I consider to be a solid choice with good support.

Wouldn't a real Gentoo user use a genuine IBM era Thinkpad?

And if someone photoshopped something in a realistic way, it was impressive, like "damn, they got me too!", something to appreciate as art.

Ehh, pretty sure they know what they're talking about, they just have what I consider a really bad take about it, and present it as absolute fact. Because yes, you need a connection to steam to "install" a game from steam, whereas you can predownload a GOG game and then not need a connection to install. Which doesn't really matter to most people, since they don't care about having the game use an official installer, as opposed to either an unofficial one or just archived game files, but it is a difference.

From my understanding, screen tearing happens when the GPU sends a frame to the screen in the middle of that frame being written to the buffer, which means half of the buffer has the last frame, and half has the new one (citation needed on the exact mechanics). VSync works around this by keeping two (or more) final buffers, making sure there's always a full buffer ready to send to the screen, and waiting to start rendering another frame until one of the buffers is "free", having been displayed on the screen.

This means the phenomenon is different, because the monitor is displaying the image correctly - it's receiving an image with a tear in it, and faithfully rendering that.

As a bonus fun fact, Variable Refresh Rate (VRR, also known under marketing terms GSync and FreeSync) is a better way to work around this, it's basically monitor hardware that can render frames with freer timing (not stuck at a specific refresh rate), and a way for the GPU to send a frame to the monitor when ready instead of a strict schedule, so instead of the GPU waiting for the monitor to be ready, the monitor can wait for the GPU.

I don't have one, but when I was at uni one of the lecturers had this dinky old-looking laptop that apparently had a touchscreen, and he would project the screen and draw on it during lectures, which worked really well to illustrate what he was talking about. Had some software to just draw on top of what he was presenting, to be clear.

That depends, I might be losing the higher pitches tbh, but I noticed our stovetop responds differently to different pans/pots and to different loads. It's noisier when a pan is misaligned, and it starts making more noises when all the "burners" are in use, and so I also imagine different models will also act somewhat differently.

That's only if they need to isolate the sequence of numbers after the first 0, otherwise * is already optional.