• NostraDavid@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      And to cover complexity, I just let an LLM do most of the work - it knows more about NixLang than me anyway (though I can read it).

  • KindaABigDyl@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 months ago

    For me, I always keep coming back to Arch tbh

    Sometimes I get fed up with managing a whole system and once in a blue moon bricking my system on an update, but the alternatives are always worse, and with btrfs now, I don’t have to worry about the latter problem.

    Nix was the closest to pulling me away. A centralized config? Beautiful. Static package store without dependency conflicts? Beautiful. Immutable applications? The WORST idea we’ve ever had as a community. For instance, imo, VS Code extensions are fundamentally incompatible with Nix. I spent weeks trying to get it to work doing multiple different things to try and hope it would work. It can’t. VS Code just has to be mutable.

    Anyway so I’m back to arch and have been for over a year since I tried Nix (and before that Fedora which has its own issues). Before that I had been on Arch for 4 years.

    I think I’ll stay now. It’s really the best option out there. In my mind, Arch is Linux, i.e. it’s how an OS should be built for the Linux kernel and the FOSS ecosystem, and it won’t ever be beat

    • Feyd@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      As soon as I realized distro upgrades are a minefield every time on a desktop I tried arch and never looked back. In hindsight, backports are insanity and just always using upstream is obviously the way to go. As a bonus, I can actually understand how arch is constructed when I need to because the wiki is amazing

  • vga@sopuli.xyz
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 months ago

    NixOS – now I’ve finally found the endgame distro!

    several days later CachyOS is actually much simpler.

      • cally [he/they]@pawb.social
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        2 months ago

        It’s there to solve your “This is boring” issue without having to do all of the system configuration stuff manually*.

        I was able to package a nightly AppImage as if it were installed normally like an app, and I could reinstall the system if I wanted to, and it’d still be there. NixOS is the opposite of manual dependency resolution, it’s dependency heaven. You can have unstable and stable repositories side-by-side, living in a utopic egalitarian society. You can write a configuration file that does everything. You can do anything with NixOS. NixOS is the one true god, all hail NixOS—

        Ah, I see why you may not want to use it. Consider it though, it’s genuinely good and trying doesn’t hurt.

        I haven’t even told you about nix-comma or nix helper (nh) yet. May the, uh, flake be with you.

        *You do have to write the config files, though you can just adapt someone else’s configuration.

    • Bonje@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      I adore the idea of nix. I fucking hate the syntax with a passion.

      oh use the .packages but only for this else use a flake and if you want dot files there is this other completely different thing with home manager but if you want this extra config customization or a custom system script then you need to make a derrivatio…

      its so damn exhausting.

      I just want a list of packages.

      That I can put in modules.

      And turn them on and off based on the computer I’m on.

      And if they are on they should use these dots.

      And not look like a spaghetti bowl made of curly braces sourced from json derulos left buttock.

      And the system should also have some additional sbctl hooks because we still have not figured out that dracut generated initramfs files don’t get purged from the database so I have to have a custom hook to not get error messages every time I paru ahahahAAHAHA…

      anyway dcli exists and is a fine middle ground.

    • Pommes_für_dein_Balg@feddit.orgOP
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Tried that, but my autism didn’t like it.
      The fact that YaST and the KDE settings had overlapping functionality, a GUI package manager frontend that shows you options you aren’t supposed to use in Tumbleweed, and it being the only modern distro that couldn’t install my printer-scanner-combo automatically drove me off.

      • insomniac_lemon@lemmy.cafe
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 month ago

        For me, I didn’t like patterns (or the work-arounds). A shame because it (or now, maybe slowroll) might be closer to what I’m looking for, especially if the talk of smoke-testing is true. (though I’ve also seen someone say that Zypper is slow)

        I like some of what I’ve seen with NixOS, though I see quite a few things that make it seem like not the answer either. And some of the things (like distrobox) seem like they probably add weight to updating as well (and/or clunkiness, if I have to manually do it).

        Also some of my issue is I’m still running a 1050Ti (and Arch putting the legacy drivers on the AUR, a bit of a pain for me… not sure if that has changed though), I know that’d likely be even worse on Nix as well.

        EDIT: I’ve tried Flatpak for user apps as well, and needing to download graphics drivers again really defeats the purpose.

        Ideally I’d like something that has an update system intended for slower internet. Something that can pull (/keep) slightly older dependencies when user-land stuff is a bit slow, or outright delay/reschedule possibly-broken (for any number of reasons) updates rather than wasting a user’s time and bandwidth. Guessing it doesn’t exist, though (or if it does, it has some other huge workflow flaw).

        Mentioning @LostWanderer@fedia.io because they’ve talked about Tumbleweed and Nix.

          • insomniac_lemon@lemmy.cafe
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 month ago

            It’s pretty easy to uninstall and make certain packages taboo

            I remember reading that you couldn’t turn it off unless you outright disabled recommended packages. Reading again, I see conflicting statements and it seems like a common thing people take issue with. Though even locking seems to me like it should just be something that happens during explicit removal, if that is a fix.

            So I still kind of hate stuff like that.

            Making a system either unresponsive or worse, broken. I feel it would be a workflow nightmare of a scale that would beggar belief and it would need constant attention from the maintainers…Something we’d probably not see in our lifetimes

            My system is currently outdated and mostly usable, but has 4 different application issues (1 crash, 1 flicker, 1 compiling/library error, 1 feature error)… before I stopped updating, rolling updates gave me a few bad rolls that did not fix some of these issues (and if I’d have rolled not even week later w/o reading the news, I would’ve been toasted into terminal-fix-it-now-land).

            So I’d say there’s a lot of room for improvement here. I dream of something that works like this:

            • bin.fast: Major.minor.greatest, 7…30 days
            • bin.stable: Major.minor.greatest, 30…180 days
            • userspace: any version (including non-system package formats), total install/non-shared-dependencies size may influence update frequency (or budget)
              • small things may update always, big programs may even get to the point where it switches the install over to a bin version for you rather than compiling again
            • userspace packages may also slow down dependencies

            Non-critical applications may be updated less. Security updates or marked-as-needed-fix more. Alternatively, supporting explicit branches (like Godot’s 3.X and 4.X) in official repos helps. Maintenance updates (nothing known broken) may be delayed if something seems/is-known wrong (build-bots, user reports or comments, upstream fix needed or dependency too new, admin/maintainer intervention etc)

            Ultimately, this could mean an update about every week or slower than once a month depending on packages and if the user encounters issues or not. And I’m sure this may be possible with some package system, but again not something default (and less effective if a package system doesn’t provide the needed structure/information).

            Hardware wise, yeah I’m otherwise still pretty happy with the performance level I have (and it’s a fine target for my own stylized projects, still working on that). A smaller(+more efficient) system would be nice, but GPUs seem to still be behind/lower-value than CPUs though. Polaris would be fine just to make things easier though, not that I want to buy a sidestep especially when the market is so stagnant. Same thing with workarounds that won’t be really cheaper either (esp, w/RAM etc pricing).

            This is why I am very careful to use a small amount of them as there are a few apps

            What I’m talking about was an issue with 1 package due to sandboxing, and it was Krita IIRC (something I don’t care about sandboxing on). I think KDE stuff was being pulled in too (I don’t use it, but I do use Kate and few other things that use Qt).

  • the_riviera_kid@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    2 months ago

    I’ll never understand why some people have the need to constantly fiddle with their OS install. But, different strokes for different folks.