insomniac_lemon comments on Have you ever been disappointed with Linux?

Have you ever been disappointed with Linux? (libretechni.ca)

submitted 3 months ago by cm0002@libretechni.ca to c/linux@programming.dev

179 comments fedilink hide all child comments

Personally I haven't. While Linux is imperfect, choosing the right distro makes the rest of the experience straightforward. And with it's whole complexity, I find Linux more user friendly than Windows. Even driver issues, broken shadow file ownership and KDE specifics only made me more confident about my choice to use Linux after I solved everything.

OQB @pixeldaemon@sh.itjust.works

you are viewing a single comment's thread
view the rest of the comments

[–] insomniac_lemon@lemmy.cafe 4 points 3 months ago (14 children)

I'm a bit disappointed with packaging/updates. Specifically Arch, I have slow-ish shared internet and didn't update frequently enough now my system is too outdated (1050Ti, them moving legacy nVidia drivers to AUR is another reason I haven't updated in a while).

Looking at alternatives.

Void (I still might want something more user-friendly) musl? (but optional and interesting for creating static binaries)
Tumbleweed/Slowroll might be perfect if it weren't for patterns (and I wish update structure were smarter* than just scheduling).
NixOS is a fun idea but not with declarative desktop settings (I have my own XFWM window theme not uploaded anywhere) and extra mess when it comes to compiling/exporting also running non-packaged executables (especially if I decide to stop using Steam, running what library I can w/o client)

User packaging is also generally questionable, too. I know not to rely on it too much, but I'm also not going to be inspecting package scripts especially not every update.

Other package distribution is a neat idea, but needing to download another graphics driver for Flatpack sort of ruins the point for me (redundant data too). That, and less integration+more manual updates.

* it probably doesn't exist, but I'd like something that has some sort of awareness of compatibility (be it simple/explicit versioning, build bot troubles, user reports etc). If I haven't updated in a while, give me a safer update (hold more Major.Minor.newest packages to known-good). If I'm updating regularly, tell me if an update on tuesday might not be great and remind me on friday if it seems better. Let me mark software with some general issues (stability, rendering, features) and alert based on potential fixes.

hideshow 14 child comments

[–] a14o@feddit.org 3 points 3 months ago (4 children)

Give NixOS another look. It's no problem to run a declarative system as a base, and plain old dotfiles on top if you want, especially for user stuff. Not sure what you mean by "non-packaged executables" exactly, but I don't see how NixOS would give you a disadvantage here. Heoric works fine as a Steam alterntative.

parent

hideshow 4 child comments

[–] insomniac_lemon@lemmy.cafe 2 points 3 months ago (3 children)

and plain old dotfiles on top if you want

I'm not the type to put my dotfiles in git, though. A lot of things I just plan on starting fresh and configuring in-session.

Not sure what you mean by “non-packaged executables”

Pre-compiled, non-system binaries.Typically, stuff downloaded from GoG and itch without a client (also the odd thing like BrogueCE). I don't know if this is always an issue, but it is for anything that uses dynamic linking (checking with ldd is a thing, though can be misleading with runner scripts).

Heroic works fine

I've never been interested in the Epic store even for free games. I'm sure there are 10 ways to "solve" this each with their own benefits/drawbacks, but I feel like this is a philosophy issue that creates more problems than it solves for me. And this is without the ability to create static binaries (out of the box) like I'd get with void-linux musl.

That, and seeing talk about how great Nix is but also people having trouble later on too (major updates? bleeding edge woes?).

parent

hideshow 3 child comments

[–] a14o@feddit.org 1 point 3 months ago (2 children)

I’m not the type to put my dotfiles in git, though.

That's what I'm saying, you don't have to! Just install the package (like neovim or whatever) through NixOS and it will use your ad-hoc dotfiles like it would on any other distro. For a lot of stuff you can make use of declarative NixOS options (programs.neovim = { ... };), but you don't have to, except for really basic system stuff like networking I guess.

Pre-compiled, non-system binaries.

Gotcha. There's several ways do do this on NixOS (steam-run works like a charm!), but I'll concede that there's an extra step involved here that you don't have to do on other distros.

That, and seeing talk about how great Nix is but also people having trouble later on too (major updates? bleeding edge woes?).

There's a learning curve for sure, but I haven't looked back or experienced any major issues (where I hadn't shot myself in the foot) since 22.11.

parent

hideshow 2 child comments

[–] insomniac_lemon@lemmy.cafe 2 points 3 months ago* (last edited 3 months ago) (1 child)

you don’t have to! Just install the package
and it will use your ad-hoc dotfiles like it would on any other distro

And changes will last on reboot, y'know with the whole immutable thing?

EDIT: I couldn't find straightforward (to me) info on this even searching for stuff like 'NixOS mutable home', but after the reply to this I tried different terms and found the wiki page on impermanence. Specifically, the persisting+home managing sections:

Some files and folders should be persisted between reboots though (such as /etc/nixos/).
This can be accomplished through bind mounts or by using the NixOS Impermanence module, which will set up bind mounts and links as needed.

and

You can just make a home partition on a drive and mount it as normal, so everything in /home or /home/username will be persisted

However, then files are stored read-only in the Nix store. In order to persist files while still being writable, you can use the Home Manager Impermanence module

parent

hideshow 1 child comment

[–] a14o@feddit.org 1 point 3 months ago

Absolutely! I'll give you an example. In the NixOS config for my desktop I have the lines:

{
  environment.systemPackages = with pkgs; [
    firefox
    ...
  ];
}

So Firefox is installed every time I build a system with this config. This is just like apt-get install firefox in that very user can use it after installation. The config lives in the respective user's dotfiles (.config/mozilla/firefox) and will of course survive reboots.

What I chose to do additionally (but this is in no way required!) is a home-manager config for my main account with the lines:

{
  programs.firefox = {
    enable = true;
    policies = {
      DisableFirefoxAccounts = true;
      DisablePocket = true;
      DisableTelemetry = true;
      DownloadDirectory = "${config.home.homeDirectory}/tmp";
      OfferToSaveLogins = false;
      ...
  }
  ...
}

This is a declarative configuration that basically handles my dotfiles (profiles, extensions, themes, ...) for me. I think you have the impression that this is mandatory, but it is really a very specific behavior through the home-manager module, but you can absolutely run NixOS without it.

parent

[–] mrbigmouth502@piefed.zip 1 point 3 months ago (5 children)

What are your thoughts on Debian Stable?

It's not a rolling release, and you'll need to use Flatpak if you want newer versions of certain apps; unless you're willing to deal with the Backports repos and their limited level of support, but I think it might be a good fit for your use case.

parent

hideshow 5 child comments

[–] insomniac_lemon@lemmy.cafe 2 points 3 months ago (4 children)

I'm not sure about about using an older kernel.

I've already mentioned having issues with Flatpak's redundancy*, but I also imagine sandboxing could potentially have other issues too. Specifically I use Godot 4.6+ with bindings for a compiled language. (I haven't used it thus far, but Godot can potentially have a pipeline from Blender)

So, maybe something like that might be viable with a different package distribution system. I haven't looked into it though.

* and this could be another nVidia thing with the size of the driver?

parent

hideshow 4 child comments

[–] mrbigmouth502@piefed.zip 1 point 3 months ago* (last edited 3 months ago) (3 children)

EDIT: Hopefully this isn't too TL;DR. I got a bit carried away writing this response.

Debian Stable uses an LTS kernel, so while it's based on an older codebase, it still gets regular security updates. You won't get the most bleeding-edge performance features, but since you're using an older Nvidia GPU, not being on the bleeding edge might actually be helpful.

I honestly wouldn't be too concerned about the space used by Flatpak dependencies, unless you have a really small SSD that you're trying not to use too much space on. If you use a separate home partition, it's helpful to set up Flathub as a user repo (add --user to the usual install command) so that the space that gets used is on your home partition and not on root.

As far as sandboxing issues go with your development workflow, I'm not super well-informed on that subject, but I know that Flatseal gives you a fair amount of control over what Flatpak applications can access.

I think if Debian Stable has one big caveat, it's that it's not the lightest distro, particularly when you're running it with a full DE and Flatpak applications.

On machines like my Thinkpad X230t or my HP Elitebook 840 G1, EndeavourOS has been noticeably snappier. However, EOS is basically Arch, and I don't like running Arch on machines I don't intend to use regularly, since it tends to break when it hasn't been updated in a long time.

parent

hideshow 3 child comments

[–] insomniac_lemon@lemmy.cafe 2 points 3 months ago* (last edited 3 months ago) (2 children)

I honestly wouldn’t be too concerned about the space used by Flatpak dependencies

Space is a concern but not the concern, it's about download time. It's a considerable price of admission (worse with updates, though maybe not so anymore with legacy). I actually tried Flatpak at one point for Krita, and that is part of why I switched back to native.

You won’t get the most bleeding-edge performance features
EndeavourOS has been noticeably snappier

Yeah, I'm more worried about backtracking from my current setup (a bit more than half-a-year out-of-date but still newer kernel than Debian stable EDIT: correction). Particularly snappiness, I expect optimizations are a big part of that (CPU is Ryzen 2700, might be more important for that).

parent

hideshow 2 child comments

[–] mrbigmouth502@piefed.zip 1 point 3 months ago

I wasn't sure how powerful of a machine you had. The Ryzen you have likely slaughters the CPUs in both of the laptops I mentioned; an i5 4300U in the HP, and an i5 3320m in the Thinkpad. I should've been more specific about that.

I have Debian 13 running on a desktop i5 4570 box, and it seems to run well, though I have it set up differently than the laptops since it's a headless machine I mainly access over RDP and SSH. It also has twice the RAM (16GB vs the 8GB in both laptops), an NVME SSD for a boot drive, and XFCE instead of KDE Plasma.

Whatever the case, I feel like if your machine is powerful enough, the performance difference between Debian and more aggressively optimized distros shouldn't matter too much, BUT, I can see not wanting to use it if you're adamant about squeezing every last drop of performance from your machine.

parent

[+] mrbigmouth502@piefed.zip 1 point 3 months ago* (last edited 3 months ago)

[deleted]

parent

[–] sedot@feddit.org 1 point 3 months ago (2 children)

You don’t have to use patterns on Tumbleweed (and maybe Slowroll also?), if you don’t like them. It’s just a handy shortcut to get most, but not all, relevant packages.

parent

hideshow 2 child comments

[–] insomniac_lemon@lemmy.cafe 2 points 3 months ago (1 child)

It's annoying (compared to anything similar on Arch) and will reinstall things you've removed. There is conflicting information on the best way to deal with this, either way more complicated than 'off'. It's a problem that shouldn't be a problem, and it seems to be a common issue people have.

parent

hideshow 1 child comment

[–] sedot@feddit.org 1 point 3 months ago

It is possible to lock packages an those would not be reinstalled, even if they are part of a pattern - zypper rm foo, zypper al foo, thats it. Yes, the list of addlocked packages could be long depending on the starting point. But users have full control over everything what gets installed in the first place.

I have decided i don’t care much about patterns. There is no perfect distribution, but tumbleweed is pretty close for me.

parent