1. 43
  1.  

  2. 41

    It’s also developer-friendly because of its excellent wiki.

    I learned Linux doing everything by hand on a Slackware system, then moved to Ubuntu after ~8 years when I realized I’d stopped learning new things. Then a couple years ago I realized I didn’t understand how a bunch of things worked anymore (systemd, pulseaudio, Xorg, more). I looked at various distros and went with Arch because its wiki had helped me almost every time I’d had an issue.

    Speaking of distros, I’m currently learning Nix and NixOS. It’s very nice so far. If I can learn to build packages I’ll probably replace lobsters-ansible with it (the recent issues/PRs/commits tell a tale of my escalating frustration at design limitations). Maybe also my personal laptop: I can experiment first with using nix to try xmonad first because it’s mostly configured by editing + recompiling) and deal with python packaging, which has never worked for me, then move completely to NixOS if that goes well.

    1. 9

      I switched from Mac to NixOS and couldn’t be happier. At work we use Nix for building Haskell projects as well.

      1. 9

        The Arch wiki actually seems to be the only good documentation for using the advanced functionality of newer freedesktop components like pulseaudio, or much older software like Xorg.

        But I’ve noticed it’s documentation for enterprise software like ZFS is usually hot garbage. Not surprising given the community. The recommendations are frequently hokey nonsense: imaginary micro-optimizations or blatantly incorrect feature descriptions.

        What do you find better about nix for making packages than, say, making an rpm or deb? I’ve found those package systems valuable for large scale application deployment. Capistrano has also been nice for smaller scale, with its ability to deploy directly from a repo and roll back deployments with a simple symlink swap. And integration libraries are usually small enough that I’m comfortable just importing the source into my project and customizing them, which relieves so many minor tooling frustrations overall.

        Of course in the end the best deployment system is the one you’ll actually use, so if you’re excited about packaging and deploying with nix, and will thus devote more time and energy to getting it just right, then that’s de facto the best option.

        1. 3

          What do you find better about nix for making packages than, say, making an rpm or deb?

          I don’t, yet. The “If I can learn to build packages” sentence links to an issue I’ve filed. I was unable to learn how to do so from the official documentation. I’ve almost exclusively been working in languages (PHP, Python, Ruby, JavaScript) that rpm/deb have not had good support for, prompting those languages to each implement their own package management systems that interface poorly or not at all with system packaging.

          I’ve used Capistrano, Chef, Puppet, and currently use Ansible for deployment. Capistrano and Ansible at least try to be small and don’t have a pretensions to being something other than an imperative scripting tool, but I’ve seen all of them break servers on deployment, let servers drift out of sync with the config, or fail to be able to produce new deployments that match the existing one. Nix/NixOS/NixOps approach the problem from a different direction; it looks like they started from what the idea of system configuration is instead of scripting the manual steps of maintaining one. Unfortunately nix replicates the misfeature of templating config files and providing its own config file on top of them instead of checking complete config files into a repo. Hopefully this won’t be too bad in practice, though it’s not a good sign that they implemented a programming language.

          I appreciate your closing sentiment, but I’m not really trying to reach new heights of system configuration. I’m trying to avoid losing time to misconfiguration caused by services that fundamentally misunderstand the problem, leading to booby traps in common usage. I see almost all of my experience with packaging + deployment tools as a loss to be minimized in the hopes that they waste less time than hand-managing the global variables of public mutable state that is a running server.

          1. 1

            Hmmm. I don’t think the problems you listed are 100% avoidable with any tool, just easier in some rather than others.

            I like Puppet and Capistrano well enough. But I also think packaging a Rails application as a pre-built system package is definitely the way to go, with all gems installed and assets compiled at build time. That at least makes the app deployment reproducible, though it does nothing for things like database migrations.

          2. 1

            What do you find better about nix for making packages than, say, making an rpm or deb?

            Let me show you a minimal nix package:

            pkgs.writeScriptBin "greeter" "echo Hello $1!"
            

            Et voila! You have a fine nix package of a utility called greeter that you can let other nix packages depend on, install to your environment as a user or make available in nix-shell. Here’s a function that returns a package:

            greeting: pkgs.writeScriptBin "greeter" "echo ${greeting} $1!"
            

            What you have here is a lambda expression, that accepts something that you can splice into a string and returns a package! Nix packages in nixpkgs are typically functions, and they offer an a great amount of customizability without much effort (for both the author and the user).

            At work, we build, package and deploy with nix (on the cloud and on premises), and we probably have ~1000 nix packages of our own. Nobody is counting though, since writing packages doesn’t feel like a thing you do with nix. Do you count the number of curly braces in your code, for instance? If you’re used to purely functional programming, nix is very natural and expressive. So much so that you could actually write your application in the language if it’s IO system were designed for it.

            It also helps a lot that nix can seamlessly be installed on any Linux distro (and macOS) without getting in the way of its host.

            1. 1

              If only ZFS from Oracle hadn’t had the licensing compatibility issues it currently has, it would probably have landed in the kernel by now. Subsequently, the usage would have been higher and so would the quality of the community documentation.

            2. 4

              If I can learn to build packages I’ll probably replace lobsters-ansible with it

              Exactly. I don’t have much experience with Nix (none, actually). But in theory it seems like it can be a really nice OS-level replacement for tools like Ansible, SaltStack, etc.

              1. 1

                This is exactly what NixOps does! See here.

                1. 2

                  Thanks for the video. I’ll watch it over the weekend!

                  Curious - are you also running NixOS on your personal machine(s)? I’ve been running Arch for a long time now but considering switching to Nix just because it makes so much more sense. But the Arch documentation and the amount of packages available (if you count the AUR in) is something that’s difficult to leave.

                  1. 1

                    Yes, I’m using it on my personal machine :). I wouldn’t recommend switching to NixOS all at once, what worked for me was to install the Nix package manager, use it for package management and creating development environments, and then only switch once I was fully convinced that NixOS could do everything I wanted from my Ubuntu install. This took me about a year, even with me using it for everything at work. Another approach would be to get a separate laptop and put NixOS on that to see how you like it.

                    1. 1

                      Interesting. I’ll try it out for some time on a VM to get a hang of it. Thanks for the info!

              2. 2

                Even as a Ubuntu user, I’ve frequently found the detailed documentation on the Arch wiki really helpful.

                1. 2

                  I really want to use Nix but I tried installing it last month and it doesn’t seem to have great support for Wayland yet which is a deal breaker for me as I use multiple HiDPI screens and Wayland makes that experience much better. Anyone managed to get Nix working with Wayland?

                  1. 2

                    Arch’s wiki explaining how to do everything piecemeal really seems strange given its philosophy is assuming their users should be able to meaningfully help fix whatever problems cause their system to self-destruct on upgrade. It’s obviously appreciated, but still…confusing, given how many Arch users I’ve met who know nothing about their system except what the wiki’s told them.

                    1. 1

                      I gave up on my nix experiment, too much of it is un- or under-documented. And I’m sorry I derailed this Arch discussion.

                      1. 1

                        I’m happy to help if I can! I’m on the DevOps team at work, where use it extensively, and I did a presentation demonstrating usage at linux.conf.au this year. All my Linux laptops run NixOS and I’m very happy with it as an operating system. My configuration lives here.

                        1. 2

                          Ah, howdy again. I’m working my way through the “pills” documentation to figure out what’s missing from the nix manual. If you have a small, complete example of how to build a single package that’d probably be pretty useful to link from the github issue.

                          1. 2

                            I made a small change to the example to get it to build, and I’ve added it as a comment to your issue.

                      2. 19

                        I’ve tried several linux distribution in the last 10years (ubuntu,debian,fedora,arch,nixos) and honestly, NixOS is way above the others for a developer-friendly OS. It’s:

                        • super lightweight
                        • customizable
                        • with an awesome package manager
                        • well documented

                        I love being able to drop in a shell having the package or the lib I want and test things. In comparison, Arch feels like a totally standard linux distribution.

                        1. 9

                          I’ve been using NixOS everywhere around me for about 3.5 years and totally agree. I now work on Atlassian Marketplace which deployed using Docker images that are built from Nix.

                          1. 3

                            The nix model definitely seems like a great way to build docker images. Reproducible, minimal, flexible, it seems like a perfect fit.

                            1. 3

                              That sounds strange to me; if you’re already set up to use nix, why bother with docker? Maybe I’m overlooking some things?

                              1. 2

                                Because Atlassian has an internal PaaS which requires Docker. I use NixOS for everything but deploy our systems to that.

                                1. 1

                                  I’m not using NixOS. And it wouldn’t be for running locally, it would be for deploying on something like Kubernetes. But nix is a flexible, useful tool even when NixOS isn’t involved.

                                2. 1

                                  How can it be both good as my workstation, and good as a minimal container runtime?

                                  Not for the sake of being argumentative (I have yet to try Nix), just confused because those two seem like opposites.

                                  1. 3

                                    Flexible is the key adjective that makes it work for both. Nix allows you to install a package tree into a target directory, using binary packages. Analogous to debootstrap / kickstart. But it also lets you ad hoc add / update / remove packages in that directory like apt / yum does on a running system. It can also do all this according to a package spec a la bundler / npm / maven.

                                    And it can do all this live on a workstation too! So that’s why it works for both.

                                    It also does a great job of keeping things clean by installing packages into versioned directories, and symlinking the active package into the base system. Similar to what homebrew does on MacOS. That makes cleaning old versions a breeze, and allows multiple versions to be installed, which nix lets you switch between easily.

                                    That being said, I run more conventional distros to keep familiar with the server installs used by customers. I find the utility of that expertise greater than any utility NixOS provides. But since nix is also a standalone tool, it works on less interesting distros and can be used for homedir installs or building docker images.

                                    1. 2

                                      That being said, I run more conventional distros to keep familiar with the server installs used by customers.

                                      Interesting. I find that I do this as well. I.e. I use a minimal vimrc, bash (not zsh/fish), etc., to not confuse my muscle memory of my day job (which is bog-standard Linux/Debian sysadmin).

                                  2. 1

                                    Here’s a good blog post about using Nix to build Docker images: http://lethalman.blogspot.com/2016/04/cheap-docker-images-with-nix_15.html

                                  3. 1

                                    So all the images are built from the nixos base image? It’s the first big company that I hear is using nixos+docker!

                                    1. 2

                                      No base image - just x86_64-linux built Nix binaries.

                                3. 18

                                  I’ll add to the chorus of folks with good experiences using Archlinux. I’ve been using it for almost 10 years now, and it’s been extremely solid. I use it at home, at work, on my laptop and on my various media PCs. My wife uses it now too. There is nothing in particular that has really made me want to switch to something else. NixOS has piqued my curiosity since I read their paper many years ago, but I’ve never given it a fair shake because Arch has been so good to me, and because I tend to be a “worse is better” kind of a guy, but only when necessary. ;-) I love me some PKGBUILD!

                                  I’m not sure I’d sing praises for the Archlinux community. I do like their trial by fire approach to things. But my personal interactions with them haven’t been a shining beacon of friendliness, I can tell you that. I never really fit in with the Archlinux community, so I tend to avoid it. But I think that’s OK.

                                  1. 3

                                    Arch Linux is (mostly) friendly towards experienced users that also strives towards keeping things simple. How can a distro communicate that it’s not for beginners, nor for maximalists (excluding large groups of users, on purpose) while also communicating that it is friendly?

                                    1. 6

                                      I don’t know how to answer your question, but I will clarify my statement. I said that my personal interactions with people in the Archlinux community have not been what I’d call “friendly.” I’m talking about conversing with people, not the official documentation materials, which I’ve found do a great job of being friendly while simultaneously being a great example of the trial-by-fire approach to learning that really works.

                                      To be fair, I think it is very hard to mix trial-by-fire learning (which I think is one of many great ways to learn) with friendliness in an online community. It’s too easy to slip. But that’s just my belief based on what I think I understand about humans.

                                      Like I said, I just don’t fit in with that style of communication. But there are a lot of places that I don’t fit into. And I really do think that’s OK.

                                      EDIT: Also to add a positive note, not all of my interactions with Archlinux community members have been bad. There have been (very) good ones too. I guess it’s just much easier to focus/remember the bad. :-/

                                      1. 3

                                        I guess it’s just much easier to focus/remember the bad

                                        This is a known psychological effect called Negativity Bias. In theory it protects you to from forgetting things that could harm you, and helps you notice potentially dangerous situations.

                                        1. 2

                                          Yeah, this happens. Mainly because too many people forget how rolling works, and the forums are tired of answering the same questions :/

                                    2. 11

                                      While I’ve never actually used arch, I’d like to give the community a huge kudos on their documentation. Several times I’ve run into issues that had poor explanations (either ubuntu forums or stack overflow) if they had an answer. Arch’s wiki does a great job of explaining the what and the why of the problem, targeting multiple levels of user experience to give the user the ability to solve it themselves.

                                      1. 4

                                        This is very true. I wish every project had as dedicated a focus on documentation as the Arch team so obviously does. When forced to use Linux, I use Nix, because it is obviously the correct way to configure a system; but I get the answers to my general Linux questions from the Arch wiki.

                                      2. 17

                                        I’m often amused to remember that there are developers who want “bleeding edge” and rolling release and consider that to be “developer friendly”.

                                        What I want more than anything else is to have my computer work the same day-to-day without fear of it breaking. When I do an update, I want to be to easy rollback if something breaks. When I do an update, I want it update the smallest possible number of components to get the change that I needed.

                                        I’d be far more appreciative of articles like this if it was “why I like Arch” rather than “its developer friendly”. Its not “developer friendly”, its “you friendly”. I used Arch for a bit. Its a nightmare for someone like me, and… I’m a developer. That’s fine though. I don’t use it. For my Linux systems, I prefer point releases + long term support.

                                        1. 7

                                          I’m a developer too. At my workplace, the Arch users just upgrade their packages, and have a stable system for a decade, with a small risk of having to configure or force-install a package every N years. The Ubuntu/Mint people do a distro-upgrade or reinstall the system every N years.

                                          I’m not sure which is worse, but there is more cursing and complaints from the Ubuntu/Mint camp.

                                          1. 2

                                            Maybe it’s just me (I like occasionally hacking on drivers and such), but I consider “developer friendly OS” to mean “friendly to developing the OS itself” (which is why I run FreeBSD -CURRENT).

                                            Developing apps is not that special and doesn’t require much “friendliness”, IMO. Just having not-ancient versions of all common libraries/runtimes/etc. is enough.

                                            That said, mainstream Linux distros like Debian/Ubuntu/Fedora do have an “unfriendliness” in terms of splitting headers into separate -dev / -devel packages. What are they trying to do, save 10kb of disk space per shared library?! Artificially inflate package counts? This is infuriating: “What do you MEAN pkg-config can’t find this lib– OH DAMMIT I need the dev package! What, why is libwhatever-dev not found, oh I need to search because it’s called whatever01despacito-dev-69420.0.0002 WHO EVER THOUGHT THIS IS A GOOD IDEA”

                                            1. 2

                                              I haven’t used Arch but I have the same intuition. I run debian stable on my desktop and servers and have very rarely found myself wanting anything more cutting edge.

                                            2. 12

                                              As someone who uses arch on all my developer machines, arch is a horrible developer OS, and I only use it because I know it better than other distros.

                                              It was good 5-10 years ago (or I was just less sensitive back then), but now pacman Syu is almost guaranteed to break or change something for the worse, so I never update, which means I can never install any new software because everything is dynamically linked against the newest library versions. And since the arch way is to be bleeding edge all the time, asking things like “is there an easy way to roll back an update because it broke a bunch of stuff and brought no improvements” gets you laughed out the door.

                                              I’m actually finding myself using windows more now, because I can easily update individual pieces of software without risking anything else breaking.

                                              @Nix people: does NixOS solve this? I believe it does but I haven’t had a good look at it yet.

                                              1. 14

                                                Yes, Nix solves the “rollback” problem, and it does it for your entire OS not just packages installed (config files and all).

                                                With Nix you can also have different versions of tools installed at the same time without the standard python3.6 python2.7 binary name thing most place do: just drop into an new nix-shell and install the one you want and in that shell that’s what you have. There is so much more. I use FreeBSD now because I just like it more in total, but I really miss Nix.

                                                EDIT: Note, FreeBSD solves the rollback problem as well, just differently. In FreeBSD if you’re using ZFS, just create a boot environment before the upgrade and if the upgrade fails, rollback to the pre-upgrade boot environment.

                                                1. 9

                                                  Being a biased Arch Developer, I rarely have Arch break when updating. Sometimes I have to recompile our own C++ stack due to soname bumps but for the rest it’s stable for me.

                                                  For Arch there is indeed no rollback mechanism, although we do provide an archive repository with old versions of packages. Another option would be BTRFS/ZFS snapshots. I believe the general Arch opinion is instead of rolling back fixing the actual issue at hand is more important.

                                                  1. 8

                                                    I believe the general Arch opinion is instead of rolling back fixing the actual issue at hand is more important.

                                                    I can see some people might value that perspective. For me, I like the ability to plan when I will solve a problem. For example I upgraded to the latest CURRENT in FreeBSD the other day and it broke. But I was about to start my work day so I just rolled back and I’ll figure out when I have time to address it. As all things, depends on one’s personality what they prefer to do.

                                                    1. 2

                                                      For me, I like the ability to plan when I will solve a problem.

                                                      But on stable distros you don’t even have that choice. Ubuntu 16.04, (and 18.04 as well I believe) ships an ncurses version that only supports up to 3 mouse buttons for ABI stability or something. So now if I want to use the scroll wheel up, I have to rebuild everything myself and maintain some makeshift local software repository.

                                                      And that’s not an isolated case, from a quick glance at my $dayjob workstation, I’ve had to build locally the following: cquery, gdb, ncurses, kakoune, ninja, git, clang and other various utilities. Just because the packaged versions are ancient and missing useful features.

                                                      On the other hand, I’ve never had to do any of this on my arch box because the packaged software is much closer to upstream. And if an update break things, I can also roll back from that update until I have time to fix things.

                                                      1. 2

                                                        I don’t use Ubuntu and I try to avoid Linux, in general. I’m certainly not saying one should use Ubuntu.

                                                        And if an update break things, I can also roll back from that update until I have time to fix things.

                                                        Several people here said that Arch doesn’t really support rollback which is what I was responding to. If it supports rollback, great. That means you can choose when to solve a problem.

                                                        1. 1

                                                          I don’t use Ubuntu and I try to avoid Linux, in general. I’m certainly not saying one should use Ubuntu.

                                                          Ok, but that’s a problem inherent to stable distros, and it gets worse the more stable they are.

                                                          Several people here said that Arch doesn’t really support rollback

                                                          It does, pacman keeps local copies of previous versions for each package installed. If things break, you can look at the log and just let pacman install the local package.

                                                          1. 1

                                                            It does, pacman keeps local copies of previous versions for each package installed. If things break, you can look at the log and just let pacman install the local package.

                                                            Your description makes it sound like pacman doesn’t support roll backs, but you can get that behaviour if you have to and are clever enough. Those seem like very different things to me.

                                                            Also, what you said about stable distros doesn’t seem to match my experience in FreeBSD. FreeBSD is ‘stable’ however ports packages tend to be fairly up to date (or at least I rarely run into it except for a few).

                                                            1. 1

                                                              I’m almost certain any kind of “rollback” functionality in pacman is going to be less powerful than what’s in Nix, but it is very simple to rollback packages. An example transcript:

                                                              $ sudo pacman -Syu
                                                              ... some time passes, after a reboot perhaps, and PostgreSQL doesn't start
                                                              ... oops, I didn't notice that PostgreSQL got a major version bump, I don't want to deal with that right now.
                                                              $ ls /var/cache/pacman/pkg | rg postgres
                                                              ... ah, postgresql-x.(y-1) is sitting right there
                                                              $ sudo pacman -U /var/cache/pacman/pkg/postgres-x.(y-1)-x86_64.pkg.tar.xz
                                                              $ sudo systemctl start postgres
                                                              ... it's alive!
                                                              

                                                              This is all super standard, and it’s something you learn pretty quickly, and it’s documented in the wiki: https://wiki.archlinux.org/index.php/Downgrading_packages

                                                              My guess is that this is “just downgrading packages” where as “rollback” probably implies something more powerful. e.g., “rollback my system to exactly how it was before I ran the last pacman -Syu.” AFAIK, pacman does not support that, and it would be pretty tedious to actually do it if one wanted to, but it seems scriptable in limited circumstances. I’ve never wanted/needed to do that though.

                                                              (Take my claims with a grain of salt. I am a mere pacman user, not an expert.)

                                                              EDIT: Hah. That wiki page describes exactly how to do rollbacks based on date. Doesn’t seem too bad to me at all, but I didn’t know about it: https://wiki.archlinux.org/index.php/Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date

                                                2. 12

                                                  now pacman Syu is almost guaranteed to break or change something for the worse

                                                  I have the opposite experience. Arch user since 2006, and updates were a bit more tricky back then, they broke stuff from time to time. Now nothing ever breaks (I run Arch on three different desktop machines and two servers, plus a bunch of VMs).

                                                  I like the idea of NixOS and I have used Nix for specific software, but I have never made the jump because, well, Arch works. Also with Linux, package management has never been the worst problem, hardware support is, and the Arch guys have become pretty good at it.

                                                  1. 3

                                                    I have the opposite experience

                                                    I wonder if the difference in experience is some behaviour you’ve picked up that others haven’t. For example, I’ve found that friend’s children end up breaking things in ways that I would never do just because I know enough about computers to never even try it.

                                                    1. 2

                                                      I think it’s a matter of performing Syu update often (every few days or even daily) instead of once per month. Rare updates indeed sometimes break things but when done often, it’s pretty much update and that’s it.

                                                      I’m an Arch user since 6 years and there were maybe 3 times during those 6 years where something broke badly (I was unable to boot). Once it was my fault; second & third one is related to nvidia driver and Xorg incompatibility.

                                                      1. 3

                                                        Rare updates indeed sometimes break things but when done often, it’s pretty much update and that’s it.

                                                        It’s sometimes also a matter of bad timing. Now every time before doing a pacman -Syu I check /r/archlinux and the forums to see if someone is complaining. If so then I tend to wait for a day or two before the devs push out updates to broken packages.

                                                      2. 1

                                                        That’s entirely possible.

                                                    2. 4

                                                      I have quite a contrary experience, I have pacman run automated in the background every 60 minutes and all breakage I suffer is from human-induced configuration errors (such as misconfigured boot loader or fstab)

                                                      1. 1

                                                        Things like Nix even allow rolling back from almost all user configuration errors.

                                                        1. 3

                                                          Would be nice, yeah, though I never understood or got Nix really. It’s a bit complicated and daunting to get started and I found the documentation to be lacking.

                                                      2. 3

                                                        How often were you updating? Arch tends to work best when it’s updated often. I update daily and can’t remember the last time I had something break. If you’re using Windows, and coming back to Arch very occasionally and trying to do a huge update you may run into conflicts, but that’s just because Arch is meant to be kept rolling along.

                                                        I find Arch to be a fantastic developer system. It lets me have access to all the tools I need, and allows me to keep up the latest technology. It also has the bonus of helping me understand what my system is doing, since I have configured everything.

                                                        As for rollbacks, I use ZFS boot environments. I create one prior to every significant change such as a kernel upgrade, and that way if something did happen go wrong, and it wasn’t convenient to fix the problem right away, I know that I can always move back into the last environment and everything will be working.

                                                        1. 2

                                                          How do you configure ZFS boot environments with Arch? Or do you just mean snapshots?

                                                          1. 3

                                                            I wrote a boot environment manager zedenv. It functions similarly to beadm. You can install it from the AUR as zedenv or zedenv-git.

                                                            It integrates with a bootloader if it has a “plugin” to create boot entries, and keep multiple kernels at the same time. Right now there’s a plugin for systemdboot, and one is in the works for grub, it just needs some testing.

                                                            1. 2

                                                              Looks really useful. Might contribute a plugin for rEFInd at some point :-)

                                                              1. 1

                                                                Awesome! If you do, let me know if you need any help getting started, or if you have any feedback.

                                                                It can be used as is with any bootloader, it just means you’ll have to write the boot config by hand.

                                                      3. 6

                                                        For me as a programmer, what I need is just a stable Operating System which can always provide latest software toolchains to meet my requirements, and I don’t want to spend much time to tweak it.

                                                        Why is this? As a programmer I find I rarely need bleeding edge. I’m sure not going to install bleeding edge to production. It can be fun for hacking around but I don’t see why as a programmer it’s needed.

                                                        1. 7

                                                          It can be useful to have the latest compiler set and tooling for your project. I often find new potential issues with a newer GCC.

                                                          1. 4

                                                            For what it’s worth, Arch does distinguish between ‘stable’ and ‘bleeding edge’ in its releases, although the rolling release does mean that stable is generally much newer than you might find in, say, Debian.

                                                            I wouldn’t use it in production, though I have seen it done.

                                                            1. 3

                                                              I don’t want bleeding edge in general, but “your issue has been fixed in the latest version” get old quickly.

                                                            2. 4

                                                              I am also a happy Arch Linux user since about three years, without any reason to switch even though I tried almost any major Linux distribution in the years before.

                                                              The things I like most about it are:

                                                              • its rolling release model, so I have small incremental changes than one huge and fragile system update.
                                                              • that I get almost vanilla upstream packages.
                                                              • that I can get almost everything from the Arch User Repositories.
                                                              • that Arch’s package format is easy to learn.

                                                              It is not surprising to me that Arch is developer friendly because I would assume that almost no one without programming knowledge is using it.

                                                              1. 3

                                                                Because I am a developer, one SSH client is mostly enough, and fascinating desktop doesn’t appeal to me.

                                                                Which doesn’t mean that Arch doesn’t have nice desktops :). I use GNOME (it supports Wayland and HiDPI well) and Arch probably offers the best GNOME experience I ever had, besides Fedora. Arch tracks the upstream minor versions, so you get bug fixes quickly. This was especially useful in when Wayland support was not as good, many issues where fixed and then available in Arch days after reporting them.

                                                                I also agree that it is really nice to have recent gcc, clang, perf-tools, etc. versions. I also like the simple PKGBUILD format, it’s much easier to package up some software than e.g. Debian/Ubuntu.

                                                                1. 3

                                                                  Can’t say I like arch that much. The wiki is indeed a damn good resource. But using the OS involves too much config wank and “what broke now” after updating a pile of packages you didn’t want to update but had to because you needed to install one new package.. I’d also prefer not to have to hunt down all the packages I need to get a usable system up and running. Also I never liked hunting down aur pkgbuilds. Why not just a repo?

                                                                  Pacman also never made that much sense to me. Why “sync”? Why do I “sync” to search? And why do I also “sync” to install? apt install, dnf install, and pkg_add in particular make sense. pacman -Sy and -Ss and -S, not so much.

                                                                  I use it and I hate it.

                                                                  1. 2

                                                                    Yeah, I’m experiencing a similar thing. Arch works the best of the distros I’ve tried for what I’m doing (running a VM server with video passthrough) and I use it for daily development aside from that, but I would really like something more declarative like Nix. I don’t feel like I can stand using rolling for all my packages anymore.

                                                                  2. 2

                                                                    the only complaint I have with arch is that pip install and npm install fuck the system up. the solution is you have to use them inside virtualenv, nvm.

                                                                    1. 7

                                                                      Which is not a distro problem, but a problem with the defaults of these third party language package managers. Everyone assumes sudo pip install requests is a great idea while have these issues when installing the requests lib from the repository.

                                                                      I’ve configured my npm to install in ~ for globals things, so it doesn’t mess up my system :)

                                                                      1. 4

                                                                        The problem isn’t really an arch issue, it’s related to the defaults of pip and npm. I’ve never had an issue with either negatively affecting my system if I set it up as the arch wiki recommends.

                                                                        For pip, use --user if you aren’t in a venv, for npm, set $npm_config_prefix to be located in ~.

                                                                        1. 4

                                                                          You install pip or npm with the package manager

                                                                          then you use them according to the man pages and it borks your system.

                                                                          This is a fault

                                                                          If special configuration should be done this should come when you install it with the distro package manager. That’s the whole point of a linux distribution. If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool. UX matters.

                                                                          1. 7

                                                                            If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool.

                                                                            Actually almost every popular Python package suggests using virtualenvs (or more recently, pipenv). AFAIK, sudo pip install is considered bad practice in the Python community.

                                                                        2. 7

                                                                          Yeah, my solution to the npm problem is to stay far far away from npm.

                                                                          1. 1

                                                                            Not exactly a universally applicable solution.

                                                                            1. 2

                                                                              As a society, however, we’d all be better off if we could.

                                                                        3. 1

                                                                          I respect Arch Linux’s wiki and its commitment to simplicity, but I’ve always wished they would support more architectures. There is more in the world than x86_64.

                                                                          1. 2

                                                                            Which architectures in particular?

                                                                            1. 1

                                                                              ARM is the biggest one. I know there is a separate project that supports ARM, but it’s just that - a separate project. I’m also interested in MIPS and POWER.

                                                                              Here are some examples of interesting hardware that I can’t use with the base Arch Linux project:

                                                                              Eliminating lesser-used architectures goes along with simplicity, so I guess the decision makes sense. When I started using Arch, the focus on i686 and newer (eliminating i386 compatibility) was part of the appeal. These days I default to Debian for the architecture support.

                                                                              1. 2

                                                                                ALARM is good, why dismiss it as “just a separate project”? What’s wrong with that?

                                                                                1. 1

                                                                                  ALARM certainly looks a lot more complete than when I first encountered it a couple years ago. The device support page in particular looks nice. The ARM-specific wiki pages are somewhat meager.

                                                                                  The FAQ on the official wiki explicitly states “You may not want to use Arch if you require support for an architecture other than x86_64,” and I take that at face value. All the official wiki pages assume x64, although I’m sure much of the information is transferable.

                                                                                  1. 1

                                                                                    My issue with ARM is, it’s a totally different ecosystem and you need the specific hardware to reasonably support it. I would love to support ARM, but that would be only mainline and not all the closed source gpu’s and BSP kernels. Users probably would not like this.

                                                                                    Just supporting the RaspberryPi would be neat, but I believe aarch64 is still not 100% supported and requires a custom kernel :-(. And adding another kernel to our repo’s requires even more work when security issues pop up, which is already an issue currently.