I faced this as well on KDE and got around it by creating a window rule to match it by window title and force a .desktop name to the vs code window, so it shows the correct icon on the taskbar. I wonder if there is a similar functionality on Gnome?
KWin allows the end-user to define rules to alter an application’s window attributes.
For example, when an application is started, it can be forced to always run on Virtual Desktop 2. Or a defect in an application can be worked-around to force the window above others.
Just like the holy grail, a stable and up-to-date distro doesn’t exist. Stability and recency of software typically constitute a tradeoff. Human software developers produce some number of bugs per line of code. Unless all changes made to a piece of software are bug fixes, new changes mean new bugs, almost invariably. Therefore the only way to stop the increase of bugs in a piece of software is to stop the changes to it or only do changes that address bugs. In the context of distros, a stable one is a distro where the number of bugs stays constant or decreases over time. This is how Debian, Ubuntu and every other distro that locks its software versions for a certain release work. After a release is out, only bug fix changes are permitted, with some special exceptions. The idea that there are multiple types of stability is a bit of a false narrative. Adding features, adds lines of code, which increases the number of defects. This is a fundamental fact of software engineering that’s actively managed during the development cycle of most software. A collection of software like a rolling Linux distro that receives a constant stream of new features may feel bug-free to specific users, however that is typically a coincidence. Just because those X number of people didn’t hit any significant defects during their usage, doesn’t mean that you won’t. This is true for every distro, however stable distros generally have an ever-decreasing number of bugs over their lifespan. In addition, bugs that are never fixed can be documented, workarounded and the workarounds will keep working for the lifespan of the release because there are no changes.
With all of that out of the way I hope it’s clearer why there’s a tradeoff between stability and recency of software in distros. There are various strategies to have a bit of both and they typically revolve around letting the bits you want be recent, while keeping everything else stable. These days the easiest and most foolproof way to get new software is via Flatpak or Snap.
You could of course abandon stability and go for recency via some rolling release distro and see if you step on any significant bugs. Maybe you won’t and you’ll be happy with that. Many people are.
As a personal and professional Linux user that lives with and maintains a significant number of machines, I typically go for a stable base like Debian or Ubuntu LTS and update only the software I need via Flatpak, Snap and Docker. I no longer use PPAs. This provides a great balance between stability and recency. But that’s just me.
Gentoo. Great rolling release that is stable and had timely updates, but has the flexibility to configure my system down to the tiniest details, with a great and knowledgable community. I love source-based distros and Gentoo is definitely the best.
Yes, though there are some prebuilt binaries for large packages. I use gentoo on a desktop and updates don’t take too long, minutes. Big updates that cause lot of packages to rebuild can take hours.
I’ve used Manjaro for a while and my system broke twice in that time just by updating my system (And with “broke” I mean it didn’t boot anymore). Then I switched to EndeavourOS and I haven’t had that issue once. Been using that for over 2 years now.
What I’m missing from wayland, it’s not really something from wayland itself. Examples are several needed electron based applications, which some will refuse to properly work (for meetings, desktop sharing, etc), wine, gtk4 applications not respecting GDK_DPI_SCALE (not sure if already addressed) when not using gnome (wayfire being used as compositor), no proper support for conky (or eventually equivalent wayland functionality) yet, and several nuances with waybar, and some other tools. Major issue is my work dependency over some non floss electron binary blobs, like teams, slack, and so on, which particularly for desktop sharing and meetings don’t yet work properly, no matter the electron options one can use for them, and some floss I use like signal, freetube, jitsi. Wine has a horrible hack, which I might live with, but it’s horrible…
So I’ll have to wait further for non wayland stuff to truly support wayland, and it has taken ages for that to happen, :(
I haven’t tried labwc, andit sounds interesting, though I don’t like openbox configs, and I really love fluxbox ways, which are also text files, but I never got used to openbox configs, perhaps just because I got way too familiar with fluxbox, which is what I use with Xorg (fluxbox + picom + tint2 + conky).
GTK does not use env vars for configuration, those are for development. There are some GSettings that control scaling like org.gnome.desktop.interface text-scaling-factor.
The env var works fine on Xorg though. And yeap, several applications need to catch up. That’s what I meant when I said it’s not wayland fault itself. However it’s been years things have been trying to catch up. Every now and then I try, but a couple of months back I couldn’t routinely use wayland, given all missing functionality plus additional nuances… The hard part is that if not using gnome, or plasma for that matter, getting things working take a lot of time, just to find out some things, I depend on for work, don’t work yet. At any rate, I still pay attention as well, to forums like this, to see if there’s some news that might trigger another retrial…
It is part of their kernel. And there are a few different schedulers at play, you have the CPU one as well as the I/O one. Arch Linux has various different kernels (such as the zen one) that use different CPU schedulers (with lots of options in the AUR as well) and there are various settings you can tweak for different I/O ones.
I general you should go through the Improving performance wiki page on the details for these and even more performance tweaks you can do.
There is also pages for tuning things for better battery life for laptops as well that you may also find interesting.
Faster here has many different meanings. The tests in that benchmark are more batch processing tasks. But that is not the only measure of speed. Zen I believe is more tuned for desktop use and keeping the system in a more snappy state which comes at the cost of some raw throughout performance. There is forever a tradeoff between latency and throughput, optimising for one is generally done at the expense of the other and both are optimising for performance, just different kinds.
I only mentioned zen as one of the official alternative kernels that is worth a look at though, making no claims as to if it the best for anyones particular workloads.
This is why it is best to do your own benchmarks for the stuff you care about and pick the best solution for your situation.
Arch wiki to the rescue. I swear the forms of arch Linux must just be riddled with references to the wiki. Eventually I’ll learn that it just knows. Thanks for the response.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.