As someone who’s built his own PCs for years, I’ve never really bothered with a BIOS update.
Then again, one of the main reasons to update BIOS is to gain support for new CPUs, but I’ve been using Intel which switches to a new socket or chipset every other generation anyway. I’ve almost always had to buy a new motherboard alongside a new CPU.
My understanding is that Flatpak was never designed to be a secure environment. It’s all about convenience.
Running software you know you can’t trust is idiotic no matter how well you sandbox it.
That quote actually links to a really good article: https://www.phoronix.com/news/Linux-6.10-Merging-NTSYNC
Seconded. Having an awesome Fish setup doesn’t help at all when you’re constantly having to shell into other machines unless you somehow keep your dotfiles synced, and that sounds like a total hassle.
I’d rather my muscle memory be optimized for the standard setup.
Wanting to and actually doing it are two different things.
The problem is that open source devs also have to be their own project managers, but those two jobs have very different skillsets.
In regular software development, it’s the PM’s job to deal with the drama, filter the idiocy out and collect concise and actionable user stories, and let the developers just write code.
In open source, you tend to deal with a lot of entitlement. All kinds of people, who never gave you a dime, come out out of the woodwork to yell at you over every little change. The bigger and farther reaching a project is, the more this happens, and it wears you down. I can only imagine what it’s like working on a huge project like GNOME.
And the toxicity feeds into itself. Be kurt with one person, and suddenly it gets out that you’re an asshole to users. Then people come in expecting hostility and react defensively to every little comment. And that puts you in the same mindset.
At the end of the day, you can’t satisfy everyone. Sometimes you gotta figure out how to tell someone their feature request is stupid and you’re not gonna work on it, especially not for free. And a lot of people need to learn to try to fix problems themselves before opening an issue. That’s kind of the whole point of open source.
https://lemmy.zip/comment/11156711
It doesn’t excuse the behavior, but I get where it’s coming from.
At this point, no. But it’s still incredibly annoying and a little spooky when I’m laying in bed and I see my computer screen light up in the next room when it’s not supposed to.
It’ll even wake itself from sleep when it wants to update, but it won’t start it automatically, I think because it hits the lock screen.
I’ll probably try Linux on ir when Windows 10 hits EOL.
Someone should force this guy to read about the principle of least astonishment.
Doesn’t surprise me that a developer from Microsoft doesn’t understand this. To this day, when I select “Update and Shut Down” in Windows, it only actually shuts the computer down about half the time.
This only happens when both network connection on the host are active.
I’m not a networking expert by any means but this seems like a pretty strong hint that it’s a routing issue.
Check the routing tables on the host? I’d bet that the internet is only reachable on the LAN interface (again, not an expert but one of them has to take priority, right?). I’m guessing that disconnecting the LAN interface changes the routing to go through the WLAN interface instead.
You could possibly add a static route to work around this: https://libvirt.org/formatnetwork.html#static-routes
The compiler is getting more and more parallel but there’s a few bottlenecks still. The frontend (parsing, macro expansion, trait resolution, HIR lowering) is still single-threaded, although there’s a parallel implementation on nightly.
Optimal core count really depends on the project you’re compiling. The compiler splits the crate into codegen units that can be processed by LLVM in parallel. It’s currently 16 for release builds and 256 for debug builds.
This theoretically means that you could continue to see performance gains up to 256 cores in debug builds, but in practice there’s going to be other bottlenecks.
Compilation is very memory and disk-I/O intensive as well. Having a fast SSD and plenty of spare memory space that the OS can use for caching files will help. You may also see a benefit from a processor with a large L3 cache, like AMD’s X3D processor variants.
Across a project, it depends on how many dependencies can be compiled in parallel. The dependencies for a crate have to be compiled before the crate itself can be compiled, so the upper limit to parallelism here is set by your dependency graph. But this really only matters for fresh builds.