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

This isn’t a very good article IMHO. I think I agree (strongly) with what it’s trying to say, but as it’s written, it just isn’t it.

Wrappers and VMs and bytecodes and runtimes are bad: they make life easier but they are less efficient and make issues harder to troubleshoot.

Runtimes/“VMs” like the JVM also allow nice things like stack traces. I don’t know about the author but I much prefer looking at a stack trace over “segmentation fault (core dumped)”. Having a runtime opens new possibilities for concurrency and parallelism too.

The COSMIC desktop looks like GNOME, works like GNOME Shell, but it’s smaller and faster and more customisable because it’s native Rust code.

This just doesn’t make any sense. COSMIC is more configurable because it wants to be, this has absolutely nothing to do with Rust vs Javascript.

Dennis Ritchie and Ken Thompson knew this. That’s why Research Unix evolved into Plan 9, which puts way more stuff through the filesystem to remove whole types of API. Everything’s in a container all the time, the filesystem abstracts the network and the GUI and more.

And here the author just contradicts themselves. So wrappers, runtimes and VMs are bad, except when it’s Ken Thompson doing it in which case adding containers and a language runtime into a kernel is a great idea actually?

Lastly, I didn’t address the efficiency arguments in the quotes because it’s mostly just true… but I do think it requires some more careful consideration than “JS bad Rust good”. Consider this unscientific sample of different apps on my PC and how much of my (expensive!) RAM they use:

• Spotify (Electron): 1G
• Ghostty (Zig/GTK): 235M
• Decibels (Typescript/GTK): 140M
• Anyrun (Rust/GTK): 110M

Note that Electron, and only Electron, is a supermassive black hole of bloat. Whatever is going on here, it’s not Javascript.

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.

You can run the LXQt Wayland Session with Hyprland as compositor. You can also forget about the session and just run the panel in a startup command or a systemd service, although I’m not sure if all widgets will work correctly this way.

XFCE also has experimental Wayland support; Hyprland isn’t officially supported but IIRC it uses the same wlroots protocols as the supported Labwc so it should work. Documentation is fairly sparse even compared to LXQt though and it’s a bit buggy, I personally haven’t gotten it to work (but others have so it’s definitely possible).

Edit: Also, Waybar has task bar widgets too. But it doesn’t support any kinds of “popup” like start menus or control centers, you just have the bar.

No, you are getting the correct Lutris derivation, but it seems like you can’t override buildFHSEnv in this way (unlike a regular derivation) which is unfortunate. Looking at it again the package takes an extraLibraries parameter (but it’s a function taking a pkgs argument and producing a list, not a bare list). In principle this should work:

home.packages = with pkgs; [
  (lutris.override {
    extraLibraries = pkgs: [ # shadows the other pkgs!
      (pkgs.runCommand "steamrun-lib" { } ''
        mkdir "$out"
        ln -s "${pkgs.steam-run.fhsenv}"/usr/lib64 "$out"/lib
      '')
    ];
  })
];

But it actually fails because both steam-run and lutris provide /usr/lib64/ld-linux.so.2 leading to a name collision. So unfortunately it seems the idea of just adding the steam-run env to Lutris doesn’t quite work…

You could instead try something like this:

home.packages = with pkgs; [
  (lutris.override {
    extraLibraries = pkgs: with pkgs; [
      glibc
      libxcrypt
      libGL
      # ... other libs in steam-run.fhs but not in the lutris FHS env
    ];
  })
];

Which library the problem game actually needs is anyone’s guess. That information might show up somewhere in the logs, or maybe ldd could tell you… but the signal to noise ratio probably won’t be very good.

Untested but I think you want this expression:

home.packages = with pkgs; [
  (lutris.overrideAttrs (_: prevAttrs: {
    multiPkgs = prevAttrs.multiPkgs ++ [
      (pkgs.runCommand "steamrun-lib" { } ''
        mkdir "$out"
        ln -s "${pkgs.steam-run.fhsenv}"/usr/lib64 "$out"/lib
      '')
    ];
  }))
];

Note the extra parenthesis and use of prevAttrs to get the original multiPkgs to append to.

I don’t use Lutris but there’s an issue on Nixpkgs describing it as “utterly broken”. So I would recommend just not using Nixpkgs Lutris. The Flatpak will probably work.

Nix in single user mode can apparently work with SELinux in enforcing mode, although AFAIK binaries installed via Nix can not have SELinux metadata which could be an issue for some programs.

Determinate Nix claims to have seamless integration with SELinux (unlike upstream Nix and Lix, but it’s not a fork, alright whatever you say Eelco). Using that and removing the proprietary garbage their installer also adds might be easier than making regular Nix play nice with it.

My understanding is that most of this is down to ARM’s (relative) lack of standardization. Consumer ARM SoCs don’t even have ACPI, so you aren’t even guaranteed to be able to do things like powering off the system. Qualcomm pretty much has to add some minimum support for their SoCs to the kernel because most of their consumers will want to get Android working on them, but that doesn’t mean they’ll do more than they have to for that.

There’s a reason you can install Linux on any x86 PC and it will mostly work, but you can’t install an ARM Linux on a phone. Even Android forks like Lineage don’t support all Android phones, even though they’re shipping basically the same thing the manufacturers are.

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.

I have this in my config:

function lastcmd
    echo $history[1]
end

abbr --add "!!" --position anywhere --function lastcmd

I believe I originally got this implementation from the GitHub issues. The key is that abbreviations can also call functions, which can in turn index into the history list. We also need to specify that we want the expansion even if we’re in an argument to another command, such as in sudo !!.

Unfortunately I don’t think there’s a nice way to do that. You can retrieve secrets from pass (albeit with quite a bit of working around the intended evaluation model) but I don’t see a good way to actually deploy the secrets without just putting the plain text into the Nix store (unless you also use a big server management thing like NixOps, as the author of that blog is, but in the time since blog was written NixOps has decided people shouldn’t be using it anymore… so it’s a bit of a mess). You’d really want something like sops-nix or agenix for that.

You can of course decide you don’t care about the secrets being in the Nix store. It “just” means that every local user on the system can read them, as can anyone booting a live USB if the disk isn’t encrypted. And, while this almost certainly isn’t relevant to you right now, if you use the system as a binary cache for other systems those can get the plaintext secrets too. But you might not actually actually care about any of these.