she/they
I think Matugen is the closest (maintained) thing to what you’re asking for.
If you use a standalone Wayland compositor you might also be interested in the newest generation of “shells” (or more accurately, Quickshell dotfiles) like DMS or Noctalia. These usually also use Matugen under the hood to make their theme settings work.
I don’t have deep knowledge on the topic but you might want to look into EDID, which is how your system knows what resolutions the monitor supports. Incorrect detection of maximum resolutions and refresh rates is a semi-common problem on Linux and the fix for that is a custom modeline; setting one will be compositor dependent on Wayland (on X11 xrandr will do).
However it’s also possible that all the cables you have are bad and/or don’t support 8K.
Hardware development is just extremely difficult. The smallest company that I’m aware of that has their own laptop design is Framework, but their laptops are also about twice as expensive as equivalent models from other brands.
In addition, since basically all modern computer manufacturing has to go through Taiwan due to TSMC’s near-monopoly on competitive semiconductors, it makes sense to outsource design to Taiwan too. They already have the industry for it, and there’s no reason to have a random American company add their own profit margin to the price for no reason.
They do develop Linux drivers for the laptops they sell, so they’re not adding literally zero value. Though they also tried to prevent upstreaming with an incompatible (illegal) license so there’s that…
They are rebranded (and expensive) Clevos, but they are manufactured (or configured, or integrated - those all amount to the same thing) in Germany.
To be fair to them this applies to many, many other Laptop brands. Including pretty big ones like MSI.
In defense of the author and their education… They’re Brazilian so English probably isn’t their native language, and their history education was almost certainly in Portuguese. I don’t think it’s necessarily an indictment of their education that they weren’t taught about the English translation of a German phrase, and I don’t think it’s reasonable to apply the same standards of subtext awareness to native and non-native speakers either.
But that still leaves the question: How to install Nix in the first place? Without just running the script.
You can download tarballs with the precompiled Nix, though you’ll still need to run an install script (but you can at least read it to convince yourself it’s not malicious), see the relevant documentation for that.
Something that slipped my mind is that since OpenSUSE uses SELinux now, that means the recommended multi-user mode won’t work. Single-user mode should be fine afaik, but it’s a bit less convenient.
This command just runs the software once without actually installing it right?
The nix-env -iA does actually install the software locally, not completely unlike how a zypper in would. For running a program without installing you would use something like nix-shell -p yazi --command yazi. Of course that still downloads and “installs” the program, it just won’t add it to your PATH or create a GC root, which means the next time Nix does “garbage collection” it will be removed again.
And yeah I would recommend just trying OpenSUSE out and then if you realize you actually really do need stuff from third party package managers, then you can worry about whether getting into Nix is a good idea or not. Or fall back to the Arch/AUR in distrobox idea which is probably simpler to do overall, especially since from what I understand that’s what you’re supposed to do on the immutable spins like Aeon.
Late edit: I’ll also note that there are several OpenSUSE specific third party repos too. Packman has some proprietary codecs that OpenSUSE doesn’t want to ship (in case you really don’t want your browser to be a Flatpak), and the Open Build Service (OBS) which is basically the AUR for OpenSUSE. They’re not as useful because they’re nowhere near the size of the AUR, but if you just need one specific package (perhaps one with questionable legality like yt-dlp or something) they might just have it. And of course you can also build stuff from source and put it in your ~/.local/bin, which has been common practice since before Linux was able to run on real hardware.
That’s true from a technical perspective. But in reality devs (especially ones who aren’t making “Linux apps” but are doing things like porting a previously Windows-only game to Linux) will occasionally ship a broken Wayland client. The compositor could then still give that a basic titlebar with window buttons like KDE and Cosmic do, or alternatively it can refuse to do it and make the novice user annoyed at the system as a whole.
I’m not really convinced that requiring all Wayland clients to draw their own decorations was the correct decision in the first place, but even if we accept it, I think there’s still a convincing case for fallback SSDs.
Theoretically you could download the .rpm file which quite a few developers provide on and install it on Tumbleweed too? But I am not 100% sure about that so please correct me about that if I’m wrong.
Yeah that’s not going to work in the general case. A trivial RPM package might be fine but every additional dependency increases the chance that it depends on some package that OpenSUSE doesn’t know. There’s a reason OpenSUSE is usually considered an independent distro and not a “Fedora-based” one despite some shared components.
I don’t think security wise there’s much of a difference between running random software directly or via distrobox. Note that distrobox mounts your entire home directory into its containers, which removes any security benefit that containers could theoretically bring. In both cases you either need to audit the software yourself or you need to trust whoever you’re downloading the software from.
Out of the third party repositories you mentioned, I would personally consider Nixpkgs the most trustworthy because package specs are actually code reviewed, unlike the AUR into which anyone can publish packages with zero oversight. That doesn’t mean it’s impossible for Nixpkgs to end up with malware in it, but the AUR sets a low bar. Using Nix (not NixOS) is also not actually that hard, you can just run nix-env -iA nixpkgs.yazi and it does exactly what you would expect, even if NixOS users would scoff at the “imperativity”.
That being said, the OpenSUSE repositories really aren’t that bad. Especially if you combine them with Flatpak, and especially if you install Firefox and VLC (or equivalents of your choice) from Flatpak so you don’t need proprietary codecs in your base system. I used OpenSUSE Tumbleweed for years and got by just fine without Nix, homebrew or distrobox.
Now if there was just an official API from all window managers that can check this configuration
This actually does exist. Reasonable Wayland Compositors will negotiate with their clients on whether they should use CSDs or SSDs. To an extent Qt does this: It prefers SSDs but it can draw CSDs if the compositor can’t draw SSDs (or signals that it doesn’t want to), which is why proper Qt apps are perfectly usable on GNOME Wayland despite missing SSDs.
It would be possible to go even further and make apps that display menu and tool bars on compositors that prefer SSDs (like Plasma/KWin) and nice GTK-style decorations on others. It just happens that most apps either really want to draw their CSDs (mostly because they’re made for GNOME, a.k.a. anything using Libadwaita) or they don’t really have a use for them (like regular Qt apps).
The biggest drawback of not providing any SSDs even as a fallback is obviously… what if the app just doesn’t draw CSDs? ~~There are many new Linux users who try to get something like DaVinci Resolve running and then can’t maximize it because it doesn’t have CSDs. For these users it just makes using Linux feel broken for basically no reason.~~¹
This is also a burden for application developers. Maybe the DaVinci Resolve devs should just fix their app (from what I heard it’s a massive PITA in all aspects imaginable), but is it really reasonable to also expect e.g game devs to add dependencies on libdecor or whatever solely to unbreak window mode on GNOME Wayland?
¹ Edit: I have since learned that Resolve actually does draw CSDs, it just doesn’t draw the window buttons. That’s certainly a choice… I think the overall point isn’t too affected but this specific app isn’t a good example since it would still be broken if GNOME had fallback SSDs.
That’s a largely unrelated topic… You can have theming without SSDs (as seen in most standalone compositors and also kind of Cosmic) and you can have SSDs without theming (at least in theory, I’m not aware of a project actually taking this stance).
There’s apparently a ZSH plugin for this with a quite a few stars, though I haven’t used it and can’t speak for how well it works. In other shells what you want just doesn’t exist to my knowledge, though it should be possible to script it with enough effort.
The problem is that in the terminal you always have at least two layers of input handling in the terminal emulator and the shell. And these layers talk to each other by emulating a 70s VT100. This leads to some issues, in no particular order:
All of these problems gets worse if you add multiplexers like tmux by the way.
Now it would be possible to write a bespoke terminal emulator and shell combination that unifies selection and makes all the reasonable keybindings actually work. There are attempts at this, such as the Emacs Eshell. Unfortunately Emacs people don’t quite share your idea of what reasonable keybindings look like (and it’s also a little bit broken, though for mostly unrelated reason).
Ultimately though the main reason this is an unsolved problem is that most Linux users just get used to the regular Readline line editor that all commonly used shells ship with. Complex edits can always be done in your $EDITOR (via C-X C-E in Bash).
It’s been a while since I last gave it a try, but I remember frequently ending up in strange states where a window wouldn’t want to tile properly. Windows would also frequently end up overlapping or extending beyond the screen, in ways they just wouldn’t when I was using Sway, Hyperland or Niri. IIRC mouse dragging and mouse resizing windows was extremely jank too.
Most of this is KWin’s fault as far as I know, it’s built for stacking window management and there’s only so much you can fix with scripting around it. It’s also the reason for the bad multi-monitor experience; the way it interacts with workspaces in particular is in my opinion not useful and never what I want.
Additional cons:
You can also use <C-C> to quit command mode instead (and this one works in keymaps). It also works in Insert mode but doesn’t trigger the InsertLeave event, which might upset some plugins.
As far as I know the character pending mode thing that r does is a bit unique in that it isn’t insert mode, but also not quite replace or operator pending mode. If there’s a way to remap any key to work with r then I’m not aware of it.
Have you considered instead remapping <Esc> on an OS level? The XKB option caps:escape turns your Caps Lock key into an additional Escape key, which is even easier to type than <C-Space>.
Yes, that is true. Curiously Qt kind of has the opposite problem of trying to be too flexible, and we have like four theming engines of which only one actually works (and it’s the one that’s tied to the Plasma desktop). GTK4 + Libadwaita is at least consistent in that it supports basically nothing.
GNOME theming discussions are weird. A lot of people will peddle cargo culted bad (broken) approaches when asked about it, but honestly it’s not that complicated¹, just restrictive:
Use gsettings [get|set] org.gnome.desktop.interface gtk-theme [new value] to set the theme that GTK3 apps will load. Libadwaita apps will ignore this setting.
Use gsettings [get|set] org.gnome.desktop.interface color-scheme [prefer-light|prefer-dark|default] to control whether Libadwaita apps (and GNOME shell) will display in dark mode. GTK3 apps will ignore this setting.
prefer-light makes everything light mode.prefer-dark makes everything dark mode.default makes apps light mode but the panel will stay dark.If you insist on theming Libadwaita apps, put the theme in ~/.config/gtk-4.0/gtk.css. You can also have add an @import directive there to import a theme. Note that this file is only loaded at startup, so using this feature means that GTK4 apps can no longer respond to the dark mode toggle.²
All of the applications that promise to help in theming GTK/GNOME (regardless of whether you’re talking about Tweaks, Refine, the theming settings of other DEs, Gradience, etc.) just flip some combination of these settings, mostly the first two.³
¹ It might seem complicated based on the length of this comment, but trust me that Qt is worse.
² The newest GTK version has media selectors, so if all of your applications are already updated to use the new GTK and your theme is updated to use media selectors then dark mode toggles should actually work now. Mine unfortunately haven’t.
³ A handful (mostly random scripts from GitHub, but also more reputable stuff like home-manager) will also try some wrong ways:
Setting the GTK_THEME environment variable will prevent applications from loading the default Adwaita stylesheet completely, which will break all kinds of things.
You can also put a theme at ~/.config/gtk-3.0/gtk.css, but this does nothing you can’t do with gsettings except preventing you from changing the theme without restarting all your apps.
Not sure how you’re arriving at that low of a difference unless the US pricing is wildly better than in the EU.
If I follow the most obvious user flow on the Framework website (except for removing components that aren’t required) then I end up with a preorder for a Framework 16 with a Ryzen AI 7 350, 8 GB of RAM and no storage for 1,724 €. I can get the same CPU in a Gigabyte Aero X16 with the same CPU and 32GB RAM and storage and an RTX 5060 on top for 1,129 €. If I try to configure the Framework to be actually competitive with that model I end up at 2,384 €. It’s not just the Ryzen AI model that’s like this either, I did the same comparison with an older Ryzen CPU and it was in the same ballpark.
I’m sure the Framework is nicer in many aspects that don’t show up on data sheets like chassis finish and build quality (and of course Linux support) but that’s a lot of money.