[howdydoo]

This is a little off-topic, but I've been wanting to switch from Windows to Linux and the one thing stopping me is the lack of a good package manager. WAIT, let me explain.

On Windows, you can just `scoop install ripgrep fzf jq` and you're in business. And updating all installed packages is one command away.

Meanwhile on Debian, the system packages are often years out of date. So authors have started making their own custom install scripts [1], or just telling you to `curl` the binary into /usr/bin [2]. To update these manually-curled binaries you need to run a different set of steps for every one. There's no way to list outdated apps, and there's no easy way to update everything.

On top of that, many apps I use aren't even packaged (k9s, broot are two random ones I just found). Sometimes you can find a third-party repo, but that's yet another person you rely on to get updates. Whereas with scoop, it fetches straight from the source, so there's never any waiting.

Is there some alternative to `apt` that everyone is using? Or how do people generally deal with this?

[1]: https://starship.rs/guide/

[2]: https://github.com/BurntSushi/ripgrep#installation

[GekkePrutser]

If you want up to date everything you simply chose the wrong distro. It's not really the package manager's fault.

Debian goes for stable versions during a release and backports security patches. It's one of their main design philosophies. It really shines for boxes you want to run something for years with minimal maintenance.

Get arch, manjaro or another rolling distro and you'll have what you want :)

Or perhaps Ubuntu which is Debian based, but they put a lot of effort into decoupling the OS packages and libs from third party software using snap. It does have some drawbacks though like launching speed and integration. Personally I go the rolling way for my daily drivers.

[howdydoo]

I just think it's weird that I can't have an LTS OS with non-LTS userland apps. But I guess I have to accept that.

Snap is a nonstarter for me for many reasons. Startup speed is important for shell pipelines, and also it's insane to bundle that much stuff just to run a statically-linked binary. And it wouldn't even solve the version problem, it looks like ripgrep on Snap is two years old. https://snapcraft.io/ripgrep

It looks like manjaro is the most recommended arch distro so I'll give it a try.

[GekkePrutser]

> I just think it's weird that I can't have an LTS OS with non-LTS userland apps. But I guess I have to accept that.

That's a good point, but it's kind of part of the structure of a traditional linux system. Every library is provided only once in the system. Also, the line between what is "the OS" and "the userland apps" tends to be pretty blurry on Linux.

It has big advantages too. That libSSL vulnerability? apt dist-upgrade and all your apps that use it are patched. No need for each app developer to incorporate it. And the dynamic shared memory can do the things it's supposed to. Great for efficiency.

Solutions like snap indeed trade off that efficiency and single point of patching for easier deployment by devs, but it has too many drawbacks for me too. Though snap is exceptionally bad in terms of startup speed compared to FlatPak and AppImage so perhaps you could look at a distro that does that.

[Shared404]

Manjaro kinda went off the deep end, I would recommend installing Arch manually, or maybe using Antergos.

Actually, Fedora may be better for your usecase. Assuming no proprietary drivers are required, it's a very simple install process, and tends to keep quite up to date software while remaining more stable than Arch.

[howdydoo]

Can you elaborate, what happened with Manjaro?

[Shared404]

A little while ago they forgot to upgrade their SSL certificate.

Their suggested work around? Users setting the clock back.

[Aeolun]

Hmm for anything Rust I just always run ‘cargo install xxx’. I realize that doesn’t help you, but I’m surprised using the package manager is actually the most convenient cross-platform way to install.

[b5n]

Or just use a fresher Debian release. Testing and unstable are often more dependable than other distro's version of stable.

[GekkePrutser]

That's true, I mentioned this in my post at first. But I removed it because Debian itself doesn't deem it stable and I didn't want to get into that whole discussion :)

But indeed Debian has a very different perception of the term 'stable' than Arch.

[christophilus]

Arch or Fedora. Even Ubuntu will likely be more up to date. Some people use Debian Sid, which is kinda like a rolling distro, if you squint.

But seriously: Arch-based or Fedora is what you want. They’re up to date.

[6figurelenins]

The backports repo solves most of it, with an occasional supplement from testing.

    # /etc/apt/preferences
    Package: *
    Pin: release o=Debian Backports,a=bullseye-backports
    Pin-Priority: 500
    
    Package: *
    Pin: release o=Debian,a=stable
    Pin-Priority: 100
    
    Package: *
    Pin: release o=Debian,a=testing
    Pin-Priority: 98
    
    Package: *
    Pin: release o=Debian,a=unstable
    Pin-Priority: 50

Then:

    $ apt-cache policy ripgrep fzf jq
    ripgrep:
      Installed: (none)
      Candidate: 12.1.1-1+b1
      Version table:
         13.0.0-2 98
             50 http://ftp.us.debian.org/debian unstable/main amd64 Packages
             98 http://ftp.us.debian.org/debian testing/main amd64 Packages
         12.1.1-1+b1 100
            100 http://deb.debian.org/debian bullseye/main amd64 Packages
    fzf:
      Installed: (none)
      Candidate: 0.24.3-1+b6
      Version table:
         0.29.0-1 98
             50 http://ftp.us.debian.org/debian unstable/main amd64 Packages
             98 http://ftp.us.debian.org/debian testing/main amd64 Packages
         0.24.3-1+b6 100
            100 http://deb.debian.org/debian bullseye/main amd64 Packages
    jq:
      Installed: 1.6-2.1
      Candidate: 1.6-2.1
      Version table:
     *** 1.6-2.1 100
            100 http://deb.debian.org/debian bullseye/main amd64 Packages
             50 http://ftp.us.debian.org/debian unstable/main amd64 Packages
             98 http://ftp.us.debian.org/debian testing/main amd64 Packages
            100 /var/lib/dpkg/status

PS. Don't curl into /usr/bin, the distro owns that. Downloads go to $HOME/bin or /usr/local/bin.

[emptysongglass]

For the CNCF landscape of tooling there's Arkade, which would at least cover you on the k9s front. [1]

Personally, I just use Nix plus a Home Manager "flake". [2] It's completely self-contained so on any new computer I can install Nix, then build this flake manifest and have my entire developer environment ready to go in a few minutes. Having clean installed or adopted so many computers, at home or work, I have become obsessed with the fewest number of steps to productive environment.

[1] https://github.com/alexellis/arkade

[2] https://dee.underscore.world/blog/home-manager-flakes/

[deadbunny]

I've honestly rarely run into something that made me miss not having the latest version of something.

Sure is something is new or under heavy develoent it might be an issue but having a 3 year old version of jq vs a 3 day old version has rarely come up for me.

With that said you have plenty of choice:

Flatpacks provide the latest versions of lots of things.

Homebrew is available for Linux (I have never tried it)

Don't use Debian as many people have already suggested

Compile yourself/manage your own version. Like people have been doing for decades.

For this while I would highly suggest putting things in `~/bin` or `/opt` and adding it to your $PATH, never put things in `/usr/bin`, that's is what apt manages and you could easily shoot yourself in the foot if you fuck about there.

[rd07]

Have you tried Arch or Arch-based distribution? I am using Manjaro, and I feel that 'pamac' is a good package manager in terms of keeping up with package update. Arch and its derivatives mainly use 2 repositories, Arch Official Repository and Arch User Repository (AUR). Sometimes, a distribution also has its own repository. AUR is what blown me away a a former Ubuntu user. Because, it often has the package I want to install, even if has no official build for Arch.

[ahepp]

Have you considered using Debian testing or even unstable, if you want newer packages?

I absolutely agree that manually installing software leads to a maintainability nightmare.

How does scoop solve the problem? Is it simply by moving faster (which one could do with the less stable Debian repos), or is it doing something like isolating all shared dependencies for every package (I know this is in style these days, but I'm not a huge fan of it).

[howdydoo]

The name "testing" kind of turns me off tbh. I want my OS to boot reliably. I don't want to be a test subject.

> How does scoop solve the problem?

It skips intermediate packaging steps and goes directly to the source. e.g. if the author publishes on GitHub, Scoop will request `github.com/ripgrep/releases/latest` (or whatever) and then download `ripgrep-$version.exe`. It has very primitive dependency handling, but I don't think that matters because I mostly install Go/Rust tools which are statically linked.

I honenstly think it's a genius solution. There's no wait time for updates, and you don't have to trust whatever user created the package on every version update.

[kortilla]

How is that genius? It basically ignores compatibility and stability as concepts entirely. Most people don’t want breaking changes to happen at arbitrary updates.

[stjohnswarts]

almost nobody uses debian on the desktop. If you're using tools like jq, fzf, ripgrep then you're smart enough to use cargo/flatpak/snap to get anything that you want. You can put it in a script and have it all ready for now and in the future if you like if you'd doing it on a lot of machines.

[Georgelemental]

As others have said, Debian Stable is not the way to go if you want up-to-date packages. Personally I find Fedora to be ideal in terms of update cadence, packages are kept up-to-date but still get some more testing compared to a fully rolling distro.

[mindB]

One alternative you could use is nix. It works as a package manager even when not running NixOS, and the software is generally up-to-date in the unstable channel (which most people use as far as I can tell).

[mise_en_place]

You could use pkgsrc or Nix.

[mavhc]

Being out of date is Debian Stable's whole thing. Don't pick that if you want the latest versions, or just use containers

[pydry]

I made the mistake of using debian stable when I first used it and ran into this problem.

Debian stable is not a good desktop OS.

[themodelplumber]

You can search distros based on the exact kind of packaging solution you want. The diversity is pretty amazing.

[howdydoo]

Scoop installs directly from the first-party source, so you only need to write a package once per app, instead of once per version of each app. Are there any distros that work like that?

[themodelplumber]

It sounds a bit like a good reason to use PPAs in some ways. But the rest of your writeup above is also the exact reason you want multiple ways to go about this thing, rather than one way. I think I use at least six different methods of getting the software, each with various strengths depending on the situation.

For example I see that Scoop runs best with "portable" apps and links directly to those third-party binary web resources. But what does the Scoop ecosystem do about third-party platforms that require special compile-time flags? Typically that's where a third-party repo maintainer would come in.

[linux_is_nice]

Arch Linux :)

[howdydoo]

I heard rumors long ago that Arch has occasional stability problems caused by updates. Is that still true these days?

I guess that's ironic to hear considering my original question, but I appreciate a different update cadence between the OS (I want LTS, stable) and things like `ripgrep`, which if there's a bug, it won't keep me from booting my system and I can just downgrade if I notice it.

[nopenopenopeno]

I haven’t used it, but Manjaro is the more stable Arch. It has a longer release cycle, but nothing is like Ubuntu LTS, which I use for the same reason. I’d rather just not even be tempted to deal with newest updates and Ubuntu seems to be the only way to avoid that because enough people realize they have to keep a maintained version compatible with the current Ubuntu LTS.

[ByteJockey]

> I heard rumors long ago that Arch has occasional stability problems caused by updates. Is that still true these days?

Been using arch for ~5 years. Maybe once a year something goes funky and I have to check the news page to see if any manual interventions are required.

They give you the exact command to run most (all?) of the time.

[rajishx]

i am not experiencing such instability, compared to a normal distro, i have actually no idea what breaks because so many things happened on the system, here a few packages here in there and i can easily pinpoint what problem is!

[ejj28]

Indeed, after pacman and yay I'm never going back to Debian-based systems for personal use. The Arch User Repository is so much more hassle-free than trying to install stuff on Debian from 3rd-party repos.

[nopenopenopeno]

What gives people confidence in the security of the user repository packages?

[commoner]

You can audit the PKGBUILD scripts yourself. A good AUR helper, such as paru (https://github.com/morganamilo/paru), will by default automatically present the PKGBUILD for the user to evaluate before proceeding with the installation.

[nopenopenopeno]

Thank you

[rajishx]

guix is what you are looking for, (I think)

a bit complicated at first sight but if you value your freedom and is a poweruser then it is the panacea, and you can do this on any linux or unices...

alternatively nix,

[nopenopenopeno]

I’m pretty sure there is a homebrew for linux project, but I’ve never used it.

Remember apt packages have a rigorous review process. Scoop installs every program in user space, which is very good, but it’s nothing like what apt’s review process offers. The comparison on convenience alone is naive.

I think scoop is really nice. It’s a near perfect solution for the problem it solves, but the only problem it solves is convenience, and you’re still stuck using Windows.

Ultimately, I’ve found the most hassle-free solution is a default Ubuntu installation with a maintained dotfiles repo that has a ./scripts directory to document installation methods when necessary.

Or, do one better and make Dockerfiles for your dev environments and barely install anything on your local machine.

I am tempted by Manjaro, but I generally like to stick to the beaten path as much as possible so I don’t run into too many snags that slow me down.