she/they
There's a manual, a discourse (forum) and a Matrix. And an unofficial subreddit and a Lemmy community. As well as two wikis and a large number of random people writing blog posts and tutorials.
This might be a hot take but honestly I think the documentation quality isn't the problem. You can point to specific topics that aren't well documented but that isn't unusual. What's unusual is how NixOS is designed and how working around its quirks requires close to distro maintainer levels of knowledge.
Most distros don't require several pages of documentation on how to install a Python application. NixOS on the other hand...
This module is actually a bit of a pet peeve of mine and a big reason I soured on Home Manager in general...
You inevitably end up writing chimera configurations like this:
nix
# home.nix programs.sway = { enable = true; # not supported by module - need to use escape hatch # good luck getting your editor to syntax highlight this snippet btw extraConfig = /* swayconfig */ '' bindgesture swipe:right workspace prev bindgesture swipe:left workspace next ''; }; programs.waybar = { enable = true: # can't do that in Nix style = /* css */ '' window#waybar { background: #16191C; color: #AAB2BF; } ''; }; # configuration.nix # need to enable Sway a second time so the display manager can see it # this may also install a second Sway if you fuck up your HM setup programs.sway.enable = true;and in exchange for this you get:
- 30s+ iteration times for basic changes like keybinds
- No ability to copy paste config snippets from READMEs/Wikis (unless you use
home.file/extraConfigescape hatches) - No ability to edit configuration in scripts (breaks a lot of theming functionality in "shells" like DMS, Noctalia, etc.)
- More ways to write configs that look right but don't quite work or just do dumb things (extra Nixpkgs imports, duplicated packages, WMs that aren't visible to the DM, etc.)
Alternatively you could just use a dotfile manager like rcm or stow or chezmoi like everyone not on NixOS+HM and not have to deal with any of this.
Do you have some specific threads in mind? Maybe I'm lucky to never click on the bad ones but my experience is that nobody is more cynical regarding Nix/NixOS jank than the long time NixOS users. You might not always get the answer you want, because it is very jank and doing some things will get you into trouble. But people pointing that out isn't the same thing as gaslighting.
Guix SD might be worth a look, it seems to be just straight up better in many technical regards. It has no flakes, comprehensive documentation and a blessed way to manage user homes. At least as long as you don't really need WiFi of course...
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.
- JumpDeleted
Permanently Deleted
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 -1gives you the last log lines from the last boot. Usedanduto navigate the pager andqto 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.
A "pure" function could instead work around it by returning (without executing) a query, accepting a state and returning a new, modified state, or otherwise returning some kind of commands to the caller without directly querying the database.
At least in Haskell due to lazyness this is (almost) always what happens. A monad is just one kind of deferred computation, with an operator
>>=("bind") that happens to prevent compiler reordering or deduplication. Any IO actions are only executed whenmainis evaluated and no earlier. Strict languages to my knowledge don't need monads to do IO since they don't have the same issues with evaluation order that Haskell does (though they might want them for type safety purposes).Is a database handle you can write to not ... basically mutable state, the arch-nemesis of functional languages?
Well, kind of. You would treat it the same way you would treat pipe/terminal or file IO: You write some impure functions that do the actual IO (database calls), and some pure functions that work on your data types. Then you compose them together to make an application. Hopefully most of your code is in the pure part which means you can test it without having to mock the world.
This honestly isn't all that different from how a well written imperative code bases turn out. You generally don't want to put all of the IO and all of the business logic into one super function or method or even class, because that makes things really hard to test (and hard to reason about too if you go far enough).
You can have actual in-memory mutable state in functional programming too, you just don't get it on every variable by default. At least in Haskell you would usually achieve this by using a type that does it for you, like IORef or ST or MVar or TVar. The reasoning above applies to those - You would generally use them sparingly, when you really need mutability (e.g. to pass data between threads), and not everywhere.
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.
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.
- JumpDeleted
Permanently Deleted
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
/bootand/tmp) is a subvolume of the same btrfs volume. Your other drives just aren't in there.You might want to read
man fstaband 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 (usingnofailis also a good idea). And yes you can just mount them to/mediaif 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.
- JumpDeleted
Permanently Deleted
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
/runis 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/mediathey'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) orsystemd.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 -fto 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:
sh
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
:cnand: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
-noption. Not the useless synopsis or any other paragraphs that mention-nin 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
PATHmodification:sh
> 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/findor in script form:
sh
#!/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.
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.
I'm not sure that description makes a lot of sense. Nixpkgs/NixOS is a fairly large community project. Some of the contributors are certainly anti-woke (although quite a few of those were banned from official spaces a while back), and some are MIC employees (Anduril is somewhat infamous with a seat on the so-called "steering council"). That's not especially unusual by itself, and you can definitely do worse than "one guy is a MIC employee" (just ask the GNU or suckless folks). What is unusual is the very public meltdowns that happened surrounding it, including the moderation team resigning. The community fortunately seems to have survived all of that though.
Anyone curious can read through the most recently active governance related thread and the rest of the discourse meta category. Outside of that the subreddit had an issue with Lunduke spam at the time, but this has since died down (and the posts were removed). I don't frequent the Matrix (official) or Discord (unofficial) so maybe those are really bad and I don't know about it, but from my experience I honestly have little to complain about.