Multi-round Desktop Linux distribution showdown.
-
I tried nixOS back in 2023 and it was still too raw for me to use as my primary OS.
The nix scripting language also seemed a bit inelegant.
Then there was the matter of having any given application available as a nix(pkg).
Looking now, the website looks slick, and it looks like nixOS has matured and stabilized. So I am thinking of giving it another go.
What is your feeling on the current state of nix? Especially, the nix pkg selection?
@purrperl @ar @abmurrow @rperezrosario
As a Nix user since 2020ish, package selection is bigger than ever, both literally in terms of having everything I want, and numerically; with more than Arch + AUR.
The language is largely unchanged, and the learning curve is still quite rough.
If you can get used to the language though it's a solid way to manage an OS though.
-
@purrperl @ar @abmurrow @rperezrosario
As a Nix user since 2020ish, package selection is bigger than ever, both literally in terms of having everything I want, and numerically; with more than Arch + AUR.
The language is largely unchanged, and the learning curve is still quite rough.
If you can get used to the language though it's a solid way to manage an OS though.
@purrperl @ar @abmurrow @rperezrosario
The best thing I can recommend if you decide to try Nix is find someone (like me as an example) who has been using Nix for a while, long enough to accidentally walk into the bear traps, and let them guide you through the woods.
-
I tried nixOS back in 2023 and it was still too raw for me to use as my primary OS.
The nix scripting language also seemed a bit inelegant.
Then there was the matter of having any given application available as a nix(pkg).
Looking now, the website looks slick, and it looks like nixOS has matured and stabilized. So I am thinking of giving it another go.
What is your feeling on the current state of nix? Especially, the nix pkg selection?
@purrperl @abmurrow @rperezrosario I've been using it since late 2019/early 2020, and - tbh - I didn't notice too many dramatic changes.
The nix language is still a somewhat weird functional programming language. The learning curve is a bit rough if you're not used to functional programming languages. REPL in the "official" implementation needs some love; one of the forks - Lix - mostly fixes REPL in my experience, and can be used on regular NixOS installations.
In my first few weeks/months of using NixOS i was treating
configuration.nixas just a silly json, with a slightly different syntax. I think that's a good approach to limit the number of things to learn at the same time.Flatpak and docker work on nixos, for the things that aren't packaged. AppImage sometimes need some work.
The number of packages in nixpkgs did grow.
-
@purrperl @abmurrow @rperezrosario I've been using it since late 2019/early 2020, and - tbh - I didn't notice too many dramatic changes.
The nix language is still a somewhat weird functional programming language. The learning curve is a bit rough if you're not used to functional programming languages. REPL in the "official" implementation needs some love; one of the forks - Lix - mostly fixes REPL in my experience, and can be used on regular NixOS installations.
In my first few weeks/months of using NixOS i was treating
configuration.nixas just a silly json, with a slightly different syntax. I think that's a good approach to limit the number of things to learn at the same time.Flatpak and docker work on nixos, for the things that aren't packaged. AppImage sometimes need some work.
The number of packages in nixpkgs did grow.
@ar @purrperl @abmurrow @rperezrosario I concur about treating it as silly json - Until you start doing conditionals and such you really can just treat it like that, and it's very effective.
Of course then you end up going down the flake based rabbit hole and end up like me with a configuration around 8000 lines long and covering give or take 5 different machines with varying degrees of difference - Laptop and Desktop are mostly the same, my router on the other hand...
(To be clear it's that complex because I enjoyed digging into it, not because it had to be.)
-
@purrperl @abmurrow @rperezrosario I've been using it since late 2019/early 2020, and - tbh - I didn't notice too many dramatic changes.
The nix language is still a somewhat weird functional programming language. The learning curve is a bit rough if you're not used to functional programming languages. REPL in the "official" implementation needs some love; one of the forks - Lix - mostly fixes REPL in my experience, and can be used on regular NixOS installations.
In my first few weeks/months of using NixOS i was treating
configuration.nixas just a silly json, with a slightly different syntax. I think that's a good approach to limit the number of things to learn at the same time.Flatpak and docker work on nixos, for the things that aren't packaged. AppImage sometimes need some work.
The number of packages in nixpkgs did grow.
Thanks for the thoughtful responses. I can probably get used to another quirky programming language, since I have worked with many other languages.
Might even look into writing a Ruby gem, or a Perl module, to implement a replacement to the nix language. Both Perl and Ruby are very flexible and user-friendly languages, and choosing either of those could significantly drive nixOS adoption.
-
Thanks for the thoughtful responses. I can probably get used to another quirky programming language, since I have worked with many other languages.
Might even look into writing a Ruby gem, or a Perl module, to implement a replacement to the nix language. Both Perl and Ruby are very flexible and user-friendly languages, and choosing either of those could significantly drive nixOS adoption.
@purrperl @ar @abmurrow @rperezrosario
Would that actually be... reasonable? I'm curious about your thoughts on how to implement it. -
Thanks for the thoughtful responses. I can probably get used to another quirky programming language, since I have worked with many other languages.
Might even look into writing a Ruby gem, or a Perl module, to implement a replacement to the nix language. Both Perl and Ruby are very flexible and user-friendly languages, and choosing either of those could significantly drive nixOS adoption.
@purrperl @abmurrow @rperezrosario I think you're underestimating the scope of "replace nix".
-
@purrperl @ar @abmurrow @rperezrosario
Would that actually be... reasonable? I'm curious about your thoughts on how to implement it.@krutonium @ar @abmurrow @rperezrosario
I'm speaking with very little knowledge here. I barely know the nix language. However, Ruby & Perl both lend themselves well to implementing Domain Specific Languages.
-
@abmurrow @rperezrosario I deal with debian packaging tooling at work, and the more I do so, the less I want to deal with debian in my own free time.
Nix and nix(pkgs) documentation are absolutely great compared to the mess around dpkg/apt/debhelper/lintian/different debhelper modules.
@ar @abmurrow @rperezrosario
The NixOS community strife pretty much put me off the project entirely. I don't know if it's been resolved at this point, but, regardless, the damage has been done. -
@krutonium @ar @abmurrow @rperezrosario
I'm speaking with very little knowledge here. I barely know the nix language. However, Ruby & Perl both lend themselves well to implementing Domain Specific Languages.
@purrperl @ar @abmurrow @rperezrosario I'm not sure how cleanly you could do it, considering a number of factors like the entirety of nixpkgs also being implemented as nix, and it being a functional language, which I'm relatively sure (I've never used them) Ruby & Pearl are not, which is going to cause a lot of issues on it's own.
That said, don't let me stop you, I do not know a lot about this problem domain.
But bare minimum I think you'd end up having to implement the nix language as well as your own DSL. Or have your code transpile to Nix maybe?
-
@purrperl @abmurrow @rperezrosario I think you're underestimating the scope of "replace nix".
Indeed, I am. However, I am launching a Free Software co-operative, and will actually hire other programmers and collaborate with them on something this ambitious in scope.
Here's the work-in-progress of the co-operative vision statement. Please feel free to send suggestions and pull requests.
-
@purrperl @ar @abmurrow @rperezrosario I'm not sure how cleanly you could do it, considering a number of factors like the entirety of nixpkgs also being implemented as nix, and it being a functional language, which I'm relatively sure (I've never used them) Ruby & Pearl are not, which is going to cause a lot of issues on it's own.
That said, don't let me stop you, I do not know a lot about this problem domain.
But bare minimum I think you'd end up having to implement the nix language as well as your own DSL. Or have your code transpile to Nix maybe?
@krutonium @ar @abmurrow @rperezrosario
Perl & Ruby are both multi-paradigm languages, and the functional programming paradigm is well-supported by both, in addition to OOP.
-
@krutonium @ar @abmurrow @rperezrosario
Perl & Ruby are both multi-paradigm languages, and the functional programming paradigm is well-supported by both, in addition to OOP.
@purrperl @ar @abmurrow @rperezrosario
Good to know!
I've never had an opportunity to use them, and now I kinda want to go read about this. -
@purrperl @ar @abmurrow @rperezrosario I'm not sure how cleanly you could do it, considering a number of factors like the entirety of nixpkgs also being implemented as nix, and it being a functional language, which I'm relatively sure (I've never used them) Ruby & Pearl are not, which is going to cause a lot of issues on it's own.
That said, don't let me stop you, I do not know a lot about this problem domain.
But bare minimum I think you'd end up having to implement the nix language as well as your own DSL. Or have your code transpile to Nix maybe?
@krutonium @purrperl @abmurrow @rperezrosario ruby can convincingly pretend to be a functional language.
Though I wouldn't want to start a new project in a language that features DHH on the front page.
Perl is something that would put me off from using Nix. I'm happy that some critical NixOS components are getting rewritten from perl into rust/python. I've been using Linux/unix-like systems for 25 years now, and perl did not seem to improve that much in all this time. It gained… function signatures. And for a while it had a "switch/case"-like syntax construct, but that has been deprecated again, apparently.
-
@krutonium @purrperl @abmurrow @rperezrosario ruby can convincingly pretend to be a functional language.
Though I wouldn't want to start a new project in a language that features DHH on the front page.
Perl is something that would put me off from using Nix. I'm happy that some critical NixOS components are getting rewritten from perl into rust/python. I've been using Linux/unix-like systems for 25 years now, and perl did not seem to improve that much in all this time. It gained… function signatures. And for a while it had a "switch/case"-like syntax construct, but that has been deprecated again, apparently.
@ar @krutonium @abmurrow @rperezrosario
Perl lost function signatures along the way, since they were considered impractical. Perl did gain a "class" keyword, to declare classes for OOP. It didn't use to have that, and supported OOP through an ugly bit of boilerplate code that Perl programmers would have to re-type for every class they wrote.
Raku is a sister language to Perl, written by the Perl community, and is a lot more modern, I'm told. I haven't tried Raku yet.
-
@ar @krutonium @abmurrow @rperezrosario
Perl lost function signatures along the way, since they were considered impractical. Perl did gain a "class" keyword, to declare classes for OOP. It didn't use to have that, and supported OOP through an ugly bit of boilerplate code that Perl programmers would have to re-type for every class they wrote.
Raku is a sister language to Perl, written by the Perl community, and is a lot more modern, I'm told. I haven't tried Raku yet.
@purrperl @krutonium @abmurrow @rperezrosario
Perl lost function signatures along the way, since they were considered impractical.
I still see them documented in perldoc, and no mention of deprecation.
https://perldoc.perl.org/perlsub#Signatures -
@krutonium @purrperl @abmurrow @rperezrosario ruby can convincingly pretend to be a functional language.
Though I wouldn't want to start a new project in a language that features DHH on the front page.
Perl is something that would put me off from using Nix. I'm happy that some critical NixOS components are getting rewritten from perl into rust/python. I've been using Linux/unix-like systems for 25 years now, and perl did not seem to improve that much in all this time. It gained… function signatures. And for a while it had a "switch/case"-like syntax construct, but that has been deprecated again, apparently.
@ar @krutonium @abmurrow @rperezrosario
Raku might actually be good candidate to replace Nix with.
Rust is too complicated, afaik, and I could be wrong about this, to be a easy, general purpose replacement for Nix.
Python is popular, though fragile due to whitespace sensitivity, which counts against it in this case.
-
@rperezrosario So here's my latest gripe with debian. I've been using debian (or its derivatives) on servers at most of the companies I've worked at, but only because most of my team members wouldn't be familiar with something that's different from "regular" linux distros.
debian packaging tools are funny. I encountered a package (not foss/in debian repos) with a
postinstscript that under certain (trivial) conditions would keep running forever. here's what happened when I tried installing it:- ctrl+c didn't work
- kill on the running apt/dpkg processes stopped it, but…
- it's impossible to remove the half-installed package;
apt purgetold me:Error: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. - spoiler alert:
dpkg --configure -aattempts to finish installing packages. that includes trying to run thepostinstagain, which wouldn't finish.
I could work around that. But I've been using linux for 25 years now, and have been working in sysadmin/devops-like roles for almost 18 years now.
I can't imagine a regular user even knowing where to start fixing something like this.
-
@rperezrosario So here's my latest gripe with debian. I've been using debian (or its derivatives) on servers at most of the companies I've worked at, but only because most of my team members wouldn't be familiar with something that's different from "regular" linux distros.
debian packaging tools are funny. I encountered a package (not foss/in debian repos) with a
postinstscript that under certain (trivial) conditions would keep running forever. here's what happened when I tried installing it:- ctrl+c didn't work
- kill on the running apt/dpkg processes stopped it, but…
- it's impossible to remove the half-installed package;
apt purgetold me:Error: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. - spoiler alert:
dpkg --configure -aattempts to finish installing packages. that includes trying to run thepostinstagain, which wouldn't finish.
I could work around that. But I've been using linux for 25 years now, and have been working in sysadmin/devops-like roles for almost 18 years now.
I can't imagine a regular user even knowing where to start fixing something like this.
@ar @rperezrosario I guess don't try to install wierd stuff. But this post now has me worried that I'll get this type of bs when I need to install some proprietary oem shit on my server
-
R AodeRelay shared this topic
