> The whole "centralized, trusted repository that has all your apps" system is wrong at a fundamental level.

I've done it both ways. Centralized works a LOT better. It's not even close.

You get a more stable system, and you get security bugs fixed faster, and more reliably.

What you lose is access to the "latest and greatest", because it takes time for the new stuff to filter in. And that's OK.

> What you lose is access to the "latest and greatest", because it takes time for the new stuff to filter in.

Depends on the distro. Archlinux is pretty fast to update packages.

This! Our company OpenSUSE Tumbleweeds were still vulnerable on Friday. On Arch, the package was already available for two days then.

The thing is, the distro maintainers need to decide whether they want a fast moving "latest and greatest" approach, which might break stuff by accident, or go a "slow but always dependable" route, which you can depend on as company, with painful losses if things go south (in which case there should be an express lane for important security fixes).

It's perhaps coincidental, but I don't remember ever having a trouble on an update that I couldn't find a quick fix for in the Archlinux homepage.

In my opinion, the reason why Archlinux can be so dependable is that packaging is based on really simple ideas, like not starting or stopping services on installation like Ubuntu would, and that most if not all system files belong to a package. The package manager can do a whole OS installation just by installing the basic packages on a directory different from /. The package format is also really simple. Getting into the guts of Archlinux packaging is really approachable and that makes me feel at ease for whatever trouble I may find myself in.

As I mentioned downthread, surprisingly little stuff breaks by accident nowadays on Arch (on my desktop, zero breakage in the last year with a fairly complex stack; on one server machine I had one strange interaction between a language package manager and pacman that ended up being my fault). The "slow but dependable" solution ends up breaking as soon as software becomes too complex for maintainers to be able to backport security fixes onto old versions, so they just ship the latest version of those packages, negating the dependability aspect (like Debian's treatment of Firefox and Chromium).

and breaks constantly, which is why I stopped using it.

"brake" makes it sound like one would have to reinstall the whole thing. I don't think I've ever had that happen in the 10 years since I started using it for nearly everything.

I've had my drive fail, but that was the drive's fault, and even in that case I also didn't need to reinstall everything. I just copied the good files and reinstalled only the packages whose files got corrupted.

That's a semantic point.

If I sit down in front of my PC and can't do work, it's broken. That I can spend an hour or two fixing it rather than reinstalling is irrelevant.

I see, when you said "break", I thought you meant because of a bug or other error, but now I guess the fact that it needs configuration and learning how to do that configuration is what you're calling broken.

Certainly, Arch is definitely not a "it just works" OS. It's a tinkerer's OS. Different distros favor different types of users. By what you said, probably something like Ubuntu or Mint is better, something that "just works" with minimal learning curve for someone not familiar with Linux in general and that does not wish to invest the time in learning it. (Not saying that you're not at least familiar with it, but that's what these distros optimize for, I believe.)

Arch is not an easy distro to use even if you know what you're doing. Every Arch user essentially creates their own distribution which can break at any point depending on their particular environment. You need to take care of all the little things yourself.

Personally I didn't experience all that much breakage, but eventually got frustrated by kernel updates breaking hotplug kernel module loading until reboot because Arch removes kernel modules for the running kernel. This breaks random things like plugging in a USB drive unless you happened to load the module previously, so you're essentially forced to reboot every time you upgrade the kernel or take care to manually exclude it.

I'm grateful for Arch because their wiki is beyond excellent, but I wouldn't recommend it to anyone unless they just want to tinker.

Once you understand this, it seems to me to be a very simple step to align your kernel upgrades with reboots. I fail to see this as an usability issue.

Well, I still had to manually exclude the kernel every time I wanted to update other packages. It's a minor issue, but an annoying one.

Why respond in this dishonest manner? When I left Arch I had been using it for over 10 years. I probably still understand it better than you do.

Is your supposition that a "misconfiguration" just "happened" randomly over night?

No, it's a rolling release distribution, software on it will break randomly on updates. You need to read their FAQ, even their official document will tell you this happens and it's not their responsibility due to the rolling release nature of the distribution.

What's dishonest about it? I'm trying to understand the issues that you mean, and the need to configure before getting to work is what I understood you to mean as broken. I'm not talking about misconfiguration; that's different. You emphasized that if you couldn't get straight to work then it was broken. When I can't get straight to work, it's because I need to configure something. I'm using "configure" to mean any sort of maintenance on the machine itself that doesn't involve "real work".

If that's not it, then I've no clue anymore about what you mean as broken.

no one else in this conversation has the same "misunderstanding" that you do. Go ask them for clarification.

My main computer was an arch box for about 7 years (I moved computers after 3 years, hence why my other comment says 4, I just remembered my old tower from around 2014 that also runs arch). In that time, the only breaking updates that occurred always had clear solutions on the homepage, with something you could paste in and fix. I stopped using it because systemd randomly hung on boot, for no clear reason (even after debugging it and trying to speed up boot), but I've had that with several other systemd-related distributions, too.

Why are they “wrong at a fundamental level”?

I believe they are suboptimal for the same reason that lexical binding won over dynamic binding in language design: it is easier to reason with immutable bindings, and to maintain as little global state as possible.

The work done in Nix and Guix is interesting in this regard.

I wouldn't say nix isn't anti-centralization, I'd say it's policy-agnostic. At the end of the day, not everything composes, only things whose interface is in some way compatible.

Traditional package manager conflate having something with composing something (everything is ambiantly available and interacting). Nix separates those, so you can have every version of everything, and only try to compose things that fit.

Because they impose a middleman between the application developer and the user.

I don't want a middleman, I want to get my programs from the developer, and store them using the tools I know (regular files on a filesystem).

Are package managers easy to use (most of the time)? Yes.

Are package managers (as they exist today) a universal, well designed way to distribute software? No, because they impose a middleman.

I agree, and I think that people are too emotionally invested in the package manager concept to back out now. I mean, for years Linux proponents have been touting it as the key advantage over software distribution on Macs/PCs.

I think the empirical evidence is against you here, though. If package managers weren't a good way to do things, brew wouldn't exist. Neither would the Mac app store, or whatever the equivalent on Windows is these days.

As a Debian user, I appreciate that the stuff I install had at least gone through some minimal vetting first. And if I have to add a third party repository or download something myself to run, I'm much more likely to view that as the possibly-dangerous action that it is, and try to actively assess the reputation and trustworthiness of what I'm installing.

That's certainly not an average, noon-technical user thing, though. Vetted app stores are there to help average users avoid malware, assuming they're doing their job properly.

I agree with the OP a little. Central repository models have advantages but they've always seemed like short term benefits in exchange for long term costs.

Things like the app store, in for profit scenarios, seem like ways to slip in monopoly control. Brew is an attempt to circumvent it.

I don't want to come across as suggesting they're a bad idea or don't have advantages, just that on balance I've always had a sense there had to be a better way.

> If package managers weren't a good way to do things, brew wouldn't exist.

Package managers are an easy way to do things, most of the time. That's why brew exists.

They are not a universally good way to distribute and install software. It twists the relationship between the software developer and the user.

I mean, it is a key advantage, on ArchLinux. If you don't have a rolling release, it's pure pain: you're often just stuck with old versions of software which aren't any more stable than the current stable release.

It's only pure pain if you want bleeding edge AND stability. Non-rolling releases are just fine if you only need new features once a year.

Non-rolling releases might work with smaller software where your distro maintainers can backport security bugfixes easily, but as soon as your software gets too big and complicated the distro maintainers won't be able to backport fixes themselves and will have to just resort to packaging the latest version of certain packages (like Debian had to do with Chromium and Firefox).

Also, for the most part, the "Arch is unstable" thing hasn't been true for a long time. I find that it's far more stable than Debian or Ubuntu LTS on my machine because of newer kernels containing newer hardware drivers.

You can run backported kernels on Debian and Ubuntu LTS too. On the latter it's pretty much the default - they provide "hardware enablement" releases so that users can avoid issues on cutting-edge hardware.

The existence and popularity of homebrew, macports and fink (on mac) and ninite, chocolatey, cygwin, mingw and nuget (on windows) would suggest that the concept appeals to mac and windows users also.