I’m a robotics researcher. My interests include cybersecurity, repeatable & reproducible research, as well as open source robotics and rust programing.

  • 133 Posts
  • 113 Comments
Joined 2 years ago
cake
Cake day: June 9th, 2023

help-circle














  • I haven’t dug into Guix yet, so is the config more of a markup and less of Turing complete language? That sounds like it’d be easier to grock or optimize an LSP for.

    I have heard that Guix takes a stronger stance with respect to unfree software. I don’t think any of the official nix Hydra infrastructures build for unfree packages, but they are packaged and indexed into nixpkgs. Has Guix been difficult at all in that regard, i.e. using proprietary drivers or closed libraries for work or personal hardware?



  • Well let me at least leave why I think Nix is not it at the moment:

    • Software Center - browsing search.nixos.org isn’t quite the same in terms low friction and discoverability
      • You already have to know what you’re looking for, and it can’t make system config on your behalf
      • Debian or conventional package managers usually offer a native GUI for package selection and deployment
    • System Defaults - the minimality of a basic default install can cause a lot of papercuts
      • the default boot partition is rather small given the OS’s prepecity to add new kernels with new generations
      • and without any garbage collection service enabled by default, user first encounter switch failures due to this
    • External Binaries Compatibility - Linux also suffers from this in general as compared to MacOS or Windows
      • in addition to being much more niche, reuse of existing binaries from more prevalent distros becomes complicated
      • the desktop ISO could suggest a nix-ld config with default libs most binary distributes expect, easing in new users
    • The Nix language - much more complex than conventional cong markup langs, being more of a turing complete DSL
      • partial working LSP impare introspection while writing, and the runtime error messages are poorly formatted
      • most desktop users (in debian or fedora) have little need to learn their OS’s packaging schemas, but NixOS users do

  • What are we doing here? This isn’t even an argument.

    Correct, this isn’t an argument, or at least I’m not trying to argue.
    All I wanted to learn what exact properties you though makes for a better desktop OS.

    I’m in agreement that NixOS isn’t the best for mainstream desktop user base, but like any decent inquiry or survey, if I just preemptively bias someone’s responses with my own observations on NixOS defecenties, then there wouldn’t be as much of a case to before ask what they think other Linux Distro do better in the first place.

    Not everyone who strikes up a convo online for a debate, and not all (but quite a few) who ask questions are trolls.



  • It doesn’t matter, because Nix isn’t built for it. That’s not it’s purpose or what it’s best at.

    I was asking more about linux distros other than NixOS.

    They all offer a better desktop experience because they are tuned with their packages and experience.

    • Would you say it’s a front end aspect? If user driven system changes were as simple as using a Software Center UI?
    • A similar [desktop] experience sounds relative, what the comparison? Windows, MacOS, <Not Fedora> linux?








  • Ah, that’s a shame. Thanks for the context though.

    I did feel a little bit of that slight dismissal or elitism from the thread I linked above about the graphical installer ISO. Although I think the relative surge of new users after graphical ISO’s implementation did end up changing some minds on the merit of its continual development.

    It seems like some tools just never fully realize their potential market demand until they’re finally implemented and consequently adopted. Quite the catch 22.

    I also wonder if it’s a bit of a motivational aspect for individual contributors, as in demand with mostly originate from novice users who’ve yet to master the Nix language, yet by the time one’s gained enough experience to contribute to Snowflake OS, you’ve kind of grown out of outgrow the need for it. That kind of reflects my personal interests around graphical programming, as I became more familiar with various languages, my inkling for a graphical representation of control flow gradually waned.

    Still, I think lowering the barrier to adoption is in the long run best serves the community and in sustaining new contributors. Sort of like the conventional Greek proverb:

    A society grows great when old men plant trees whose shade they know they shall never sit in.


    Nix can create attribute sets from JSON, so there isn’t a need to generate nix code.

    Is there a good way of mixing and mashing JSON attribute sets with conventional nix config files? Perhaps relegating some config to machine-generated JSON, and some hand crafted configs?