From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Definitely stick to the OS package manager. Not doing this is a mistake a lot of devs make.
Otherwise you end up with an app that doesn't run on most systems, and expecting people to do curl piped to bash as root.
Stick to the stable branch. Stick to the OS repos.
Thanks for the advice :)
Stick to the stable branch
Arch testing you say? No problem!
uninstalling sometimes doesn't work when you install from source, so i've learned to be patient and always use the distro package.
This is why you should build a package when compiling from source instead of doing make install directly. Packages can easily unistalled or upgraded.
For personal use, I previously used system packages, but now I'm installing them through nix home-manager. It's really nice, especially because I've got a list of them now and don't have remember what to install ever again.
I'm also curious about getting Nix on non NixOS, are there any simple example home manager configurations to look at so that I can easily start?
I made this comment for that purpose.
Nice, thanks!
I guess it's a kind of "Easy start" and "Nix", name a more iconic duo situation XD
It's actually pretty easy if you start with those files, getting to them was a hellish process that took multiple failed attempts though. I'm actually planning on writing a short guide, but didn't find the time yet.
I'll try asap!
Good luck on your guide, I think it can be handy
Finally got to it and I AM SO GIDDY RIGHT NOW!!!
I looked at your files to know what I should have expected, then, since I'm on Silverblue, I followed this guide https://julianhofer.eu/blog/01-silverblue-nix/ coupled with with Home Manager's Flake manual and finished off with installing Devbox (through Home Manager, which isn't listed as one of the official installation options for some reason), made a Python environment with it and... it's all looking good!
Declarative workflow, here I come 🤩 (and I can soon shelve all those rusty distroboxes that don't start anymore because Podman/Distrobox weirdnesses which have been all to frequent in my usage, yikes)
Thanks again! I probably wouldn't have taken the plunge so soon without your comment
Niiice, I'm glad you made it and that I was able to help! It's really funny that your comment came in right after some other dude wrote to me that nix is dying because of drama articles.
I haven't heard of devbox before. Why choose it over nix develop?
Actually I hadn't heard about nix develop, I came across Devbox pretty randomly
useless backstory
I remembered that I once saw a website Zero to Nix (on which I made a silly joke in the past on Reddit, but for the life of me can't seem to find so it's probably deleted) that said it would help learn the concepts of Nix, so I opened it just in case, then i saw that there was this FlakeHub banner on top that piqued my curiosity, I was like, is this a nod to Flathub:
Then I saw this Fleek thing that sounded like Home Manager but more user friendly (?)
Then I saw that it was deprecated so I was back to Home Manager(which in the end was easy enough anyway), but first I checked out their website that mentioned this Devbox thing
Between that and the rest, for the whole journey (that took surprisingly little time) I constantly jumped around from one website to another to piece together information and verify that it was accurate and up to date, to avoid messing up at least this one thing 😵💫
So, after I saw it, I went to look into it more and found that it's like a sort of nix shell for who is used to NPM and the like and I immediately wanted to try it out, because it just sounded like less mental burden then learning yet another thing, which was devenv as far as I got, which I found through these Reddit and Hacker News discussions.
So for now I feel right at ~~~~~ home with it.
In your experience, do you think using nix develop would slim things down without sacrificing too much comfort?
Damn, that's a wild ride.
I'm honestly not sure how useful that flakehub is, and I feel the same dislike as I do for like AUR. First time I'm seeing it though.
In your experience, do you think using nix develop would slim things down without sacrificing too much comfort?
Honestly, I've only ever used it a few times when I see that a repo has it. I checked out some of them, and with barely no nix language knowledge I was able to roughly understand what's going on, but I doubt I'd be able to make it without a template or LLM.
I'll keep devbox in mind if I ever need that functionality.
I'm honestly not sure how useful that flakehub
Me neither, I completely skipped over it, but it sounds interesting, maybe it wouldn't be as wonky as the AUR since it's Nix at least, idk
with barely no nix language knowledge I was able to roughly understand what’s going on
That's actually great! Maybe I'll try those as well, since sooner or later I'll have to learn the Nix language anyways and keeping a purer system is always a good thing if possible.
Good luck with devbox btw
edited: how tf did I end up ordering the text like that?
maybe it wouldn't be as wonky as the AUR since it's Nix at least
That's for sure, since nix handles dependencies a lot better than pacman. But I meant that due to the sheer size of nixpkgs, and the way you can add a repo to your flakes, there's no real need for it. But that's just pure speculation.
I think a sensible progression is: nix + home-manager -> flakes -> develop -> nixOS
You build on previous knowledge without getting overwhelmed. I tried using guixos without ever using guix or nix, and it's really not nice when you have to spend a week trying to figure out how to do something that takes you 5 mins in a regular distro. It even took me a few attempts to get started with nix simply because the docs are abysmal, almost all info is on nixos, and home-manager is rarely mentioned.
It sounds like it makes sense, but I'm not knowledgeable enough yet, I just found this as a maybe explanation https://flakehub.com/docs/faq#flake-versions I'd have to dig more in the rest of the ecosystem
I think a sensible progression is: nix + home-manager -> flakes -> develop -> nixOS
I can already see a good meme shaping up here, and I'm all for it XD
I really agree it might be the easiest way in, I'm already standing on the shoulders of giants having waited so long to start, so I guess I was lucky enough to skip the official docs
That's pretty interesting, I'll need to give it a try.
I use Nix, even on my Ubuntu machines, to install tooling in my user profile.
Nixpkgs unstable stays pretty up to date. The few I want something on release day or bleeding edge nightlies, I override the derivation source. I use nvfetcher to pull the latest release or head of the default branch as part of my update routine.
I'm pretty new to Nix, so its been slow integrating into my workflow, but I plan to start integrating flake's into my repos. My team seems to have constant issues with keeping their tooling up to date which breaks things locally from time to time.
one more for using nix, but for language tooling I generally prefer a nix shell and installing per project dependencies there. then updates don't break random projects and you know all the dependencies of a given project
nixos, I use devshells with flakes (and direnv)
Depends what I am working on.
Sometimes I have to work with a mess of angular and node versions, which I don’t want polluting my main system and be something to need to manage. So I use containers for development and have all dependencies for that specific project in the container
+1 to running whatever is packaged by your distro. For me, Fedora is rarely out of date. If worse comes to worse, you can always volunteer to become a packager and improve the ecosystem for everyone while fixing your own problems.
I use stuff like Rustup, in a Distrobox dedicated to the work area.
I usually use a version manager to install those stuff so I can install multiple versions when I need it. asdf is my first choice because it support a lot of languages via its plugin system, and the list of plugins is huge.
I just checked it out, it seems really cool
Usually distro packages, even mingw and android's sdk are packaged now (at least on Ubuntu which i'm forced to use).
Not shying away from upstream though.
I use Arch BTW, so no problem with outdated packages. ;)
I'm a big fan of Condaforge for this sort of thing. Keeps my development software separate from my daily driving software.
I run Ubuntu and use the Nala frontend for APT to keep a log of my package installs. That way, I can easily remove everything if I no longer need to work with a particular language or set of dependencies. For anything too complicated, I like to drop into a Docker container (which integrates nice with VSCode/Codium)
Don't do that. I would use distrobox with a Fedora container
Since I run Fedora, the repos are very up to date. Not as bleeding edge as Arch may be, but plenty fine for learning and development. There are a lot of issues you can run into during manual installation/uninstallation, so I always use distro package managers. Plus, that ensures that software has a much greater chance of running in an environment similar to an end user, so it's just ideal overall. I can certainly understand frustrations with Debian packages being out of date, but that's an ideological choice, and the user should have been aware of that before choosing Debian. All I usually have to do is install the compiler/runtime, a language server for neovim, and some minor configuration for IntelliSense, then I can be up and running with a new language.
The other side to this is that you don't necessarily need to be using the latest version of the language to learn or develop in it. It's often a good idea to stick with the latest LTS release of the language so that it's most available and compatible with the runtime/environment that the end user has access to. Utilizing features only available on bleeding edge versions of the language can make it difficult for others to use your software, as they'd have to go through the hassle of manually installing the latest version, and can lead to breakage if the language changes before the next stable version is released.
The only "compiler" I need is npm... Usually just use the one from the repos, however if it's too old, which on most stable distros it usually is, I install a tool, called n from the old version of npm and use that to update npm...