7 ms·
I'll go one step further: The whole "centralized, trusted repository that has all your apps" system is wrong at a fundamental level. The way shared libraries
by sandov 7y ago
I'll go one step further:
The whole "centralized, trusted repository that has all your apps" system is wrong at a fundamental level.
The way shared libraries are used in Linux is built upon the assumption that package managers and centralized repositories are the right way to do things.
- Analemma_ 7y agoI 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.
- hoistbypetard 7y agoThe 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.
- microcolonel 7y agoI 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.
- TheCraiggers 7y agoIt'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.
- snazz 7y agoNon-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.
- zozbot234 7y agoYou 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.
- kelnos 7y agoI 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.
- gyuserbti 7y agoI 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.
- sandov 7y ago> 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.
- abtinf 7y agoWhy are they “wrong at a fundamental level”?
- espadrine 7y agoI 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.
- Ericson2314 7y agoI 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.
- sandov 7y agoBecause 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.
- ars 7y ago> 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.
- jolmg 7y ago> 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.
- archi42 7y agoThis! 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).
- snazz 7y agoAs 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).
- jolmg 7y agoIt'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.