While you’re still in reinstalling mood, you could try out something with KDE, Xfce and Cinnamon desktops to see if you like those better than GNOME (you wouldn’t be alone if you do). However this part in particular:

Easy access to the launcher (Ubuntu only has SUPER key and then you can switch via mouse between all running programs aswell as start any installed app by typing)

Sounds a lot like you actually just want GNOME. While we have a lot of choice for Windows clones, there’s nothing that does the Super workflow quite like GNOME does.

You can also try the PopOS Shell or PaperWM extensions to try out some tiling functionality. You’ll have to spend a few minutes fixing up some key bindings, but you’ll still be running GNOME and won’t have to worry about desktop portals or authentication agents or notification daemons. You also won’t have to reinstall if you end up not liking it, you can just remove the extension, reset the key bindings and you’re back to the default experience.

I don’t really like the mix of snap and apt, that’s why I wanted to try an arch based distro with pacman but it failed in so many other ways.

Unfortunately it’s not that easy to stay on just one package manager unless your expectations for available software are very low (or you are willing to jump into NixOS, which I would not recommend). Even on Arch you end up with two because pacman does not pull from the AUR. You might get away with running a Fedora Atomic Desktop (or a derivative like Bazzite) and just pretending that Flatpak is the only thing that exists though.

I would tentatively suggest Fedora Silverblue actually, because while it isn’t without issues (missing codecs, Fedora Flatpak vs. Flathub, etc.) it is designed with the non-technical user in mind (which, with no offense intended, you are). That’s not true of Arch or any of its derivatives. Debian and Mint are also good options. That being said… there’s not really anything wrong with Ubuntu either. It’s not “cool” and of course Lemmings (like Redditors) will always recommend their own favorite distribution you’ve never head of, but if Ubuntu works for you, you can just keep using it.

NB: If you do end up trying GNOME on a non-Ubuntu distribution, you will want the AppIndicator extension. Ubuntu installs this by default, but Fedora doesn’t. Without it you won’t have Steam or Discord in your panel.

But /etc/fstab has the same UUID for every drive, I have no idea what to do with it.

That would be because every entry (except /boot and /tmp) is a subvolume of the same btrfs volume. Your other drives just aren’t in there.

You might want to read man fstab and maybe the Arch wiki pages for fstab and NTFS. It’s not that difficult as long as you make sure to not reboot with a broken fstab (using nofail is also a good idea). And yes you can just mount them to /media if you want, as long as the mount point is an empty directory.

Ubuntu Studio might have achieved this in a different way but since you’re in Arch land now it’s probably better to do what the Arch documentation recommends.

From what I can tell, it has to do with the drives mounting on /run/media, and apparently /run is a temp folder or something.

Probably not. Yes /run is a tmpfs, but that doesn’t affect any other filesystems mounted inside of it - those have their own permissions (or don’t in the case of FAT).

Since the drives are being mounted in /run/media they’re probably being mounted by your file manager, not via /etc/fstab. You could instead have them mounted on boot by the root user via /etc/fstab (the classic way) or systemd.mount (slightly friendlier), or configure polkit to allow mounting drives without a password (more reasonable if you’re talking about external or thumb drives).

The permission issue is probably for a different reason. Are you sure the filesystem(s) you’re mounting supports POSIX style permissions? FAT doesn’t, and NTFS requires a special flag for it. The files might look like they have permissions, but they’re coming from the mount options and modifying them will either fail outright or not do anything.

Edit: Run lsblk -f to see all connected drives, partitions and file systems and their file system type.

I’m not much of a one-liner collector but I like this one:

vim +copen -q <(grep -r -n <search> .) 

which searches for some string and opens all instances in vim’s quickfix list (and opens the quickfix window too). Navigate the list with :cn and :cn. Complex-ish edits are the obvious use case, but I use this for browsing logs too.

Neovim improves on this with nvim -q - and [q/]q, and plenty of fuzzy finder plugins can do a better version using ripgrep, but this basic one works on any system that has gnu grep and vim.

Edit:

This isn’t exactly a command, but I can’t imagine not knowing about this anymore:

$ man grep
/  -n       # double space before the dash!

brings you directly to the documentation of the -n option. Not the useless synopsis or any other paragraphs that mention -n in passing, but the actual doc for this option (OK, very occasionally it fails due to word wrap, but assuming the option is documented then it works 99% of the time).

The GNU utils vs BSD utils issue should be easy to work around with a bit of symlinking and PATH modification:

> type find
find is /bin/find

> type gfind
gfind is /usr/local/bin/gfind

> sudo mkdir -p /usr/local/opt/gnuutils/bin/
> sudo ln -s /usr/local/bin/gfind /usr/local/opt/gnuutils/bin/find

> PATH="/usr/local/opt/gnuutils/bin:$PATH" type find
find is /usr/local/opt/gnuutils/bin/find

or in script form:

#!/bin/sh
# install as /usr/local/bin/gnu-run
# invoke as gnu-run some-gnu-specific-script script-args
export PATH="/usr/local/opt/gnuutils/bin:$PATH"
exec "$@"

/usr/local/opt/... is probably not the best place to put this but you get the idea, you can make it work with POSIX tools. I don’t know that much about Chimera Linux but I’d be very surprised if nobody has thought of doing this systematically, e.g. as part of a distributable package.

This is probably the main reason every mainboard has TPMs now, since all common operating systems (Android, iOS/MacOS and Windows) do it.

From what I heard the Ubuntu installer offers a version that doesn’t suck (if secure boot is enabled at install time) so using that is probably fine, but I would beware of trying to DIY it since it’s easy to do incorrectly, most guides are wrong, and you will likely end up with easily bypassable encryption.

If your privileged user doesn’t have a password, in some cases this could lead to any program being able to elevate their privilege quietly, unlike UAC.

I think this is the most important part. There really isn’t any protection against random processes trying to do some version of exec sudo $0 except for the fact that it requires a password.

The FSF says this is the case but the actual legal situation is less clear, especially in the EU. Linking does not necessarily constitute a derivative work. Even decompilation of a (proprietary) library in order to link to it might be acceptable depending on the circumstance.

This isn’t something that can be fixed with a license, it’s a direct result of EU copyright law. Historically companies have tended to err on the side of the FSF interpretation, but it is on somewhat shaky grounds.

Sure it’s a problem when that happens. It’s not the only problem, and honestly in the case of coreutils it’s not really the most relevant one.

Do you think it’s likely that corporations will take over UNIX-likes with proprietary coreutils extensions forked from uutils? Because that’s the one thing that is legal to do with an MIT/BSD licensed coreutils but not with GPL licensed ones.

GPL has been battle tested in court

Well… parts of it have been. Others have not. Notably the FSFs view on whether or not linking to a GPL-licensed library constitutes a derivative work (and triggers the GPLs virality) is not universally shared by legal scholars. In the EU in particular linking does not necessarily create derivative works, despite what the FSF says. This has not been tested in court.

Some other parts like the v3 anti-tivoization hasn’t gone to court either, but that has lesser ramifications (assuming you’re not TiVo).

THAT’S how we have corporations profiting from GPL. Not because GPL allows anyone to use it.

What distinction are you trying to draw here exactly? They can do it precisely because the GPL (v2) allows it. The GPLv3 has some extra restrictions but doesn’t do anything about closed source drivers (beyond the linking thing) or the Google Play Services type of proprietary extensions.

Funny you say that because OS X shipped (and probably still ships) plenty of copyleft licensed software such as Bash. The Linux kernel is used in Android and ChromeOS.

If you want to stop corporations from profiting off your work, putting a GPL on it isn’t gonna do it. In fact no free software license will do it, because by definition they allow anyone to use and ship your software.

All of the 5 people who use (non-ESR) Firefox on their 2002 Pentium 4s will certainly be very unhappy about this.

The term used is “Solução final”, and it’s a pretty literal translation. It’s absolutely possible to make the connection between the terms, but it does require bot ha somewhat in-depth education on the Holocaust and some linguistic sense. Now it’s entirely possible that LGFaé’s history teachers really dropped the ball on the first part, but it’s not clear to me that this is what must’ve happened here.

Speaking for myself I would be embarrassed but not especially surprised if some phrase that I use frequently has a similarly unfortunate meaning, especially regarding an African or Asian genocide. As bad as all genocides are, you just can’t be well educated on all of them, especially with just a regular K-12/A-level/equivalent history education which also has to do things like teaching people how to read (something most of the world is currently failing at).

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.

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.

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.

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:

• Terminal emulator keybindings will step on shell keybindings, and the shell will never know about it because it can’t actually see the keys being pressed.
• Even if the terminal doesn’t care about a key, it might be impossible or error-prone to detect anyway. This applies to surprisingly regular keys like Tab.
• As you’ve noticed some terminals try to get clever and do things like making Ctrl-C copy if you’ve selected text. The shell doesn’t know about this either.
• Most shells and TUI apps have selection modes. These are independent from terminal selections.
• There’s no standard way of using the clipboard in Linux, but multiple different ones that may or may not work.

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).