Bad RAM is still a thing (even on regular PCs), there’s a reason ECC memory has a market (true ECC, not the stuff that DDR5 has built-in). But I agree that it’s likely just an OOM/Thrashing situation. Linux famously doesn’t handle them very well, and the behavior OP is seeing is very much consistent with that.

Ignoring the interactive features (or lack thereof) in dash/ksh, removing bash is not really something that’s possible on most distros (excluding Alpine and possibly Debian) since it’s used in scripts everywhere. And if you need to have bash installed anyways, why opt for the less pleasant shell in daily usage?

If your DE/Launcher uses systemd scopes properly you might be able to see something in the journal. As an example somewhere in my logs I can see this:

Jan 17 17:52:50 sky systemd[2171]: app-niri-steam-40213.scope: Failed with result 'oom-kill'.
Jan 17 17:52:50 sky systemd[2171]: app-niri-steam-40213.scope: Consumed 6h 32min 39.773s CPU time, 9.4G memory peak, 6.2G memory swap peak.

That’s pretty clearly severe thrashing and an eventual OOM event caused by a game. If you’re not familiar, the command journalctl -e -b -1 gives you the last log lines from the last boot. Use d and u to navigate the pager and q to quit. This will only work if the launcher you are using sets up transient systemd scopes and doesn’t just fork-exec into the application (Fuzzel does the wrong thing by default, as do many others).

I’ve also seen large Steam downloads causing such issues, so capping your download speed might help. As could enabling ZRAM.

Edit: Also, this is most likely completely unrelated but do note that Neon is basically abandoned. You should very much consider switching to a maintained distribution, whether that’s another Ubuntu spin or Fedora or something else entirely.

Der Vermieter hat, zumindest theoretisch, das Kapital aufgebracht um das Haus und die Wohnungen zu bauen, und ist auch für die Instandhaltung des Gebäudes verantwortlich und trägt entsprechende finanzielle Risiken. Klar ist das in der Realität eher ein Feigenblatt, eine Wohnung zu vermieten ist im Großteil der Fälle sehr wenig Arbeit und sehr profitabel, aber der Hauptmieter kann nicht einmal das von sich sagen. Er hat gar keine Arbeit, hat kein Kapital und trägt keine Risiken. Und meinte trotzdem er kann 500 € im Monat absieben.

Ich habe ehrlich gesagt wenig Sympathie für diesen Hauptmieter. Er bereicherte sich vollständig auf Kosten des Untermieters ohne selber irgendeinen Wert zu schaffen und erhöht damit auch indirekt die örtlichen Mietpreise. Das ist das selbe Modell wie Scalping von GPUs zur GPU-Krise oder Toilettenpapier während Corona, nur halt für Immobilien.

Tragisch ist nur, dass die Wohnung in Zukunft höchstwahrscheinlich nicht für den ursprünglichen Preis vermietet werden wird.

Edit: Ich sehe gerade dass das in Berlin war. Wäre es dem Vermieter hier überhaupt erlaubt gewesen, den Preis für den nächsten Mieter so stark zu erhöhen? Sonst war das zusätzlich noch eine heimliche Umgehung der Mietpreisbremse.

These… don’t even remotely solve the same problem?

• (1) AshOS: Package managers are fragile, and partial or broken updates can break systems (up to not booting at all).
• (2) Nix: Package managers need to solve a SAT problem (which may be impossible) to resolve dependencies.
• (3) Distrobox: Containerized programs are annoying to work with.
• (4) Homebrew: Your system doesn’t have a package manager (e.g. MacOS).

Problems (1) and (2) (arguably also (3)) are quite difficult and don’t have trivial solutions. Fedora Silverblue solves (1) but has to jettison a reasonable package manager, creating problem (4) and the demand for Linuxbrew. NixOS solves (1) and (2) while avoiding (4) but at the cost of recompiling the world and breaking SELinux/AppArmor.

I wouldn’t consider running AshOS personally (even ignoring the abandoned status) as any package install or update requires a reboot (a variation of (4)), so the UX doesn’t appear to meaningfully different from just running Silverblue or MicroOS. I have doubts that the design space here has been completely explored, but you have to look back at the mediocre past attempts to understand why they were mediocre.

Pandoc actually does a reasonable job at turning (Pandoc flavored) markdown into man-roff. Sure it doesn’t work for arbitrary markdown but it’s good enough to avoid writing roff by hand.

The main reason I see for not doing that (and using something like scdoc instead) is that you end up with a Haskell toolchain in your dependency graph.

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.

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.