Arch Linux is much superior to Debian, imo.
However I wouldn't dream of running on a fleet of several. I currently have 6 nspawn containers I run, and it's not as consistent to ensure an update won't break it.
Debian is great if you are running many servers. It's slow moving rate is due to care of not breaking the world.
The community is great, but current package management techniques and processes are the equivalent of SVN, with modern approaches like Nix or Guix being the equivalent to Git. In Debian, the whole tree of packages has to be in sync. That works well for Arch, as it is a rolling release, but IMHO that slows down Debian as it doesn't use their manpower efficiently.
Longtime ago, when Nix was not popular, there was a discussion in debian-devel about adopting Nix. It was probably premature. This discussion has resurfaced a number of times. I think currently they would benefit enormously from Nix or rolling out their own tooling that implemented equivalent ideas.
With such a big community and large package set, packages should be able to be decoupled from each other so that they can depend on different library versions and move at their own pace. Also, Nix-like tooling would allow to automate and test most package updates when upstream changes, or find common vulnerabilities and exposures (CVEs) automatically. Currently, there's a lot of manual intervention needed to do this.
This would also be advantageous for end users, as they could mix and match packages from different channels. PPAs are an inferior solution.
Despite some of the difficulties the author mentioned in the article, Debian has successfully spearheaded some ambitious project-wide initiatives, like reproducible builds. So I don't think it's out of the question that they could vastly improve the packaging experience for both users and developers with something like Nix or Guix.
Of course the biggest question is: how does one get there from here? For example-- can the Nix packaging approach coexist and play nice with the current Debian packaging system for years to come?
Yes, Nix or an equivalent implementation like Guix stores all packages in a separate tree (e.g. /nix). In fact, Nix can be used outside NixOS. It's in fact quite popular in some distros and macOS.
Hence, rolling out Nix or an equivalent tool can be done smoothly. Both can co-exist nicely.
Of course the devil is in the details-- graphics drivers, bootstrapping, etc.
The switch is disappointing for me, since I’d prefer Debian with a minimalist wm. However, manjaro + kde is good enough for light usage, and definitely easier for more mainstream users.
https://lists.debian.org/msgid-search/CAM8zJQvyaL0quk57Tyzqb... https://news.ycombinator.com/item?id=25166634 https://news.ycombinator.com/item?id=24974822
What is Arch’s charter? How are its leaders elected? How are its processes defined?
Your living in a world where OS/2 kills windows 3.11 for workgroups. Where Sega's master system outsold Super Nintendo.
Win 3.11 was more user friendly than OS/2.
Not sure about the Sega/Nintendo issue, the Master System was comparable to the NES, the SNES to the Genesis/MegaDrive
But that isn't really true. Arch historically has always been a DIY distribution with an equally DIY contribution structure. Our leaders has been BDFLs for close to two decades until the process was formalized and we held our first project leader election this year.
https://wiki.archlinux.org/index.php/DeveloperWiki:Project_L...
https://www.archlinux.org/news/the-future-of-the-arch-linux-...
There isn't any RFC process, but some consensus making on the mailing list and who wants to work on stuff.
The only other formalized structure is the Trusted Users which are elected in a formalized process.
https://aur.archlinux.org/trusted-user/TUbylaws.html
There is probably a lot of bad things with a less formalized process, but it allows Arch to move fairly rapidly and decide things without a lot of internal politics.
I can provision 100+ Debian servers in any configuration I want under 15 minutes by utilizing the features of the OS itself and, forget them after setting them up.
We actually lost one Debian server in a system room (in a rack of unlabeled cluster of identical servers) and, it was working flawlessly when we re-found it months later.
I do still have a throwaway cheap VPS with Arch, but even then I can't recommend it because the security story is largely non-existent.
EDIT: My comment was ambiguous, I didn't mean that there are no Archlinux-specific patches; rather that there's more of an effort with Archlinux to let upstream be upstream.
https://github.com/archlinux/svntogit-packages/search?q=patc...
https://github.com/archlinux/svntogit-packages/search?q=sed
But putting that aside, all distros need huge amounts of patching to make each package get along with the rest of the system. Without patching, many of them won't even build in the first place.
I've read this at least a dozen of times, mostly on HN, and mostly by Archlinux advocates. Many people seem to ignore that Debian testing and Debian unstable are continuously updated (rolling releases). Please stop propagating false claims that taint Archlinux's community reputation.
I think the parent comment was silly, but let's not pretend that Sid is a meant to be used as a daily driver.
Compare "outdated projects percentage":
Moreover, when comparing different distributions, it would make more sense to have a closer look at the release process rather than compare how they label their packages. Since Debian tests its packages for a longer period of time than Arch, Debian testing should be just as stable as Arch stable.
> Debian testing should be just as stable as Arch stable
Sure, but how up-to-date is Debian testing when compared to Arch?
Guarantee is a strong word. Can Arch guarantee this? Occasional breakage is bound to happen with bleeding-edge rolling releases.
> no security team
Weaker guarantees than stable, but that doesn't mean Debian doesn't handle security issues in unstable or testing. It'll be too late if they start dealing with security issues once a package enters stable.
> no support system
Actually, support is the same for any Debian release. https://www.debian.org/support
> Sid isn't meant to be used as a daily driver
That shouldn't matter much for people who're willing to use Arch as a daily driver.
> if your computer stops working that will be expected in Sid but a gigantic bug in Arch
A gigantic bug but still happens nonetheless.
> Sure, but how up-to-date is Debian testing when compared to Arch?
According to repology, Debian testing has twice the number of latest packages than Arch official [1]. Considering that packages of higher importance tend to be more actively maintained, I'd assume that Debian won't be significantly behind the latest release for packages that exist in both Arch official and Debian.
Automatically upgrading every day is not smart, since then you're virtually guaranteed to catch every breaking change. See https://wiki.debian.org/DebianUnstable#What_are_some_best_pr...
In contrast, Arch has been both up-to-date and rock-solid - my current install has been carried over through three PCs since 2015.
I have also had update issues with Ubuntu. There was a bug with Ubuntu 20.04 where a server would lose its default route when it had multiple network interfaces. And another bug where, after an update, network interfaces were renamed on a reboot rendering the server inaccessible. Is having a server with more than one network interface that unusual?
I have yet to find a distribution where updates are not problematic.
Pretty picture: https://repology.org/repositories/graphs
Numbers for the X axis: https://repology.org/repositories/statistics/total
Numbers for the Y axis: https://repology.org/repositories/statistics/newest
Summary for people who like neither pictures nor tables:
* Debian Unstable (31k) has way more packages than Arch (9k without AUR), but the AUR (57k) has way more packages than Debian.
* The total number of packages that are at the latest upstream version are about equal for Debian (17k) and AUR (15k). Arch (without AUR) has way less total updated packages (7k).
* Arch has about the highest percentage of fully updated packages (85%), Debian is lower (72%), and the AUR is even lower (69%).
* NixOS rivals the AUR in number of total packages (53k), has a big margin in total latest upstream versions over everything else (24k, thus 30% more than Debian or Arch), but does not have as high as an update percentage (79%) as as Arch.
The numbers are not perfect because of split-packages and alternative packages (e.g. the AUR often has addtional `-git` variants), but they give a rough idea.
Hope this helps!
> If security or stability are at all important for you: install stable. period. This is the most preferred way.
> If you are a new user installing to a desktop machine, start with stable. Some of the software is quite old, but it's the least buggy environment to work in.
https://www.debian.org/doc/manuals/debian-faq/choosing.en.ht...
> Testing has more up-to-date software than Stable, and it breaks less often than Unstable. But when it breaks, it might take a long time for things to get rectified. Sometimes this could be days and it could be months at times. It also does not have permanent security support.
> Unstable has the latest software and changes a lot. Consequently, it can break at any point. However, fixes get rectified in many occasions in a couple of days [...]
https://wiki.debian.org/DebianUnstable#What_are_some_best_pr...
> The most important thing is to keep in mind that you are participating in the development of Debian when you are tracking Testing or Unstable.
...
Since we're comparing Debian with Arch, I'll add that Arch also has testing and staging repositories, in addition to the ones meant for normal usage.
Here are two specific examples which other distros might struggle with:
repackaging a tarball to a proper system package which is tracked by the package manager
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dotne...
building a proper system package from the source (with one command! no `configure; make; make install` lunacy):
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=sway-...
I'm a Debian fan, but these two points are very true. Arch documentation is great, and writing PKGBUILD files is easier than packaging for distribution via Apt. I don't even use Arch, but I still release for it because it's easy.