8 ms·
I have been using Debian on and off since the late 90s, including some time creating packages. It was wonderful to be able to install a recent, working version
by tacostakohashi 6y ago
I have been using Debian on and off since the late 90s, including some time creating packages. It was wonderful to be able to install a recent, working version of pretty much anything you wanted for the vast majority of that time.
More recently, so many things I want to use are not available as a reasonably up-to-date package. Some examples are hugo and eclipse, where the versions provided are unusably ancient.
https://lwn.net/Articles/842319/ https://lwn.net/Articles/842319/
Meanwhile, more and more software is actively hostile to packaging / distributions, and things seem to have devolved into grabbing things from random github repos, or various dedicated/language-specific package managers like npm, pip, brew, ...
It's definitely annoying, seems like a step backwards, and its not clear to me whether there's some better distro i could be using, whether some funding / volunteer time could help, or the world has just "moved on" (backwards...) from the idea of a linux distribution with reasonably stable, up-to-date packages that "just work" for basic infrastructure so you can spend your time developing on your own project, instead of with the tedium of fetching and installing software and managing version compatibility problems yourself.
- markstos 6y agoAfter using Ubuntu for over a decade, I switched to Arch Linux. If you exclude the duplicated architecture packages in the Ubuntu repos and include the community-maintained packages, Arch has more packages new packages seem to commonly available within 24 hours of an upstream release. For example, I use some utilities based on "rofi". A search for Ubuntu packages containing "rofi-" contains just no results, but a search for Arch packages returns about 50 results. https://packages.ubuntu.com/search?suite=groovy§ion=all&arch=any&keywords=rofi-&searchon=names https://packages.ubuntu.com/search?suite=groovy§ion=all&... https://aur.archlinux.org/packages/?O=0&SeB=n&K=rofi-&outdated=&SB=n&SO=a&PP=50&do_Search=Go https://aur.archlinux.org/packages/?O=0&SeB=n&K=rofi-&outdat... AUR packages look easier to maintain than PPAs, so I'm more likely to get get involved with packaging something on Arch then I was on Ubuntu.
- Quekid5 6y ago> After using Ubuntu for over a decade, I switched to Arch Linux. Hah! Very similar experience; see my sibling reply :)
- metafunctor 6y agoYes. However, Arch Linux means you need to spend time, probably several times per year, to fix stuff that worked yesterday but doesn't work anymore. Arch Linux is just an entirely different thing compared to Ubuntu. I'd like someone who isn't me to make sure stuff works. Only very rarely will I be bothered to do actual work to upgrade to a new breaking version on my daily driver. Randomly breaking my shit on a Tuesday will make me install something more stable. On the rare occasion that I'd like to try something unstable, I can usually find a PPA or something. I don't like edges that make me bleed on my base OS.
- deleted 6y ago[deleted]
- bombcar 6y agoThere’s a continuum between something like Arch or Gentoo and CentOS on the other side - the amount of “pain” is roughly similar but when you encounter it changes - it’s usually easy to figure out WHAT broke on Gentoo as it was probably the last thing you installed - whereas a move from CentOS six to seven can be a huge undertaking (even more of you jump straight to 8). But there definitely is something nice about general stability (until you have to install something on an old OS that requires a new package and you enter a whole new hell).
- mixedCase 6y ago> Yes. However, Arch Linux means you need to spend time, probably several times per year, to fix stuff that worked yesterday but doesn't work anymore. Largely a myth and config-dependent. I used to have this issue 10 years ago but now most of my troubles are self-inflicted. Things are as stable as they come when using software from the official repos.
- piyh 6y agoI feel like a fairly competent Linux user and within 2 months had my Arch install broken to a point where I didn't want to invest the time to go down that "why is right click broken along with all these dependencies" rabbit hole. I went back to my mint/debian/Ubuntu safe space.
- m463 6y agoI think arch is better for desktop sorts of things. remember: - desktop users want the latest thing, immediately. - server users want nothing to change, ever.
- karlmdavis 6y agoAs a desktop user, not so much, no. I want things to work. I don’t want to spend my time arguing with my tools, just for the sake of having the latest and greatest. I might go through and upgrade everything every couple of years, at most. Beyond that, I just want security upgrades to happen without me having to think about them.
- Quekid5 6y agoI think the future is probably something more NixOS-like. Now, personally, I've tried it and found it a bit wanting UX-wise (and for really niche stuff), but for providing cutting edge and the ability to roll back safely I don't think it can be beaten. If you have databases, etc. that might need to be rolled back things get more complicated, ofc. Right now, I'm running Arch Linux with a small smattering of self-compiled stuff. Arch seems to actually be pretty stable, unless you're using their 'testing' repos... and it's very close to bleeding edge. Their secret, I think, is staying as-close-as-possible to upstream -- the trouble usually starts when distros start to add large patches. This has been a huge issue for me with Debian/Ubuntu.
- mvanbaak 6y agoWith zfs and boot environments the whole rollback issue is solved. No need for nixos for that.
- Quekid5 6y agoDefinitely for most cases, yes... but 'data' is still an issue (if you care about the data). NixOS has an interesting mechnanism for separating "package" upgrades from "data" upgrades, tho, so that's a slight advantage. (They basically keep around old binaries to be able to run and back up an old database and restore it on a newer version. Straightforward file system snapshots don't really do that.) EDIT: Sorry, I feel I didn't explain this very well. The main point is: You can have multiple versions of all the software on your system, including stuff like PostgreSQL. That's actually very powerful. Another potential problem is the licensing and root-on-ZFS. Personally, I'm really looking forward to an in-upstream-kernel FS like bcachefs. (I'm actually a fan of ZFS, we use it on our servers, etc. I still feel a bit uneasy about the licensing issues and the fact that it's not in-kernel.)
- ducktective 6y agoAFAIK, nixos isn't about just rollbacks...Things like ability to declare the state of your system (with all your apps) in a single file and possibility of having two different build of the same program in the system seems very futuristic and productive to me...I mean, this thing frees us from docker/vbox. I think even the Linux kernel would be a component of NixOS and could be substituted with something else. The whole idea is just an enterprise-proposal away from getting polished around the edges.
- milofeynman 6y agoI have the same problem. While setting up home stuff recently. I was doing everything through ansible on LXC containers and found myself doing a lot of building from source. I still continue to use it but will explore other distros in the future.
- spyc 6y agoPackaging Eclipse is something that _any_ distro will have a hard time with, and for good reasons, given the number of jars involved here.
- mvanbaak 6y agoMaybe FreeBSD is an option? Their packages repo has a “latest” which is very up to date. One can also use ports for more control and custom options etc
- ilammy 6y ago> things seem to have devolved into grabbing things from random github repos Devolved from what? I believe from software not having any dependencies unless they absolutely must because adding dependencies is such a royal pain. Software written in C and C++ has long been used to the system package manager being language package manager, and the (UNIX) OS being its IDE.
- nine_k 6y agoDebian successfully packages a ton of Python software, notorious for its complicated dependency graphs. Has been for decades. Debian packages a noticeable amount of C-based software which is just old. Emacs, for example. I suppose that skipping major versions (25 to 27) is considered unacceptable, and packaging and maintaining several versions is just proportionally harder. (This is why my laptop now runs Void, and I get a fresh Firefox next day after the release.)
- ilammy 6y ago> Debian successfully packages a ton of Python software, notorious for its complicated dependency graphs. Has been for decades. But that's what I'm talking about. Suppose there is no software in Debian that uses a Python dependency that you need, hence no one packaged it. Now instead of adding a line to your setup.py (or whatever Python devs use), you have to go through the entire adventure of cooking a Debian package if you want to follow the Debian way. And them submitting it to the main repo which is an adventure and commitment of its own which most people are not ready to make. Sure, that works to the benefit of everybody, not only your app. And that's the whole point of Debian distribution. Debian developers work on improving Debian. Not on publishing their software. This is the main difference between “app stores” and “package repositories” and “distribution”. Debian is a distribution, and a package repo is only a part of that. But it kinda saddens me that every language ecosystem has their own package repository, and every distribution ends up having to do effectively busywork of adapting those packages to their distribution and its rules.
- takluyver 6y ago> Debian successfully packages a ton of Python software, notorious for its complicated dependency graphs. I guess this depends on your definition of success, but from my perspective as a Python developer, it doesn't really. Most Python software I'm aware of encourages users to get it by other means (e.g. pip, Anaconda, containers), and anecdotally, the majority of users seem to do so. The occasional people who use apt cause frustration 'upstream' when they report bugs in a version that's 2 years out of date. One package which I help maintain upstream had a security flaw with a CVE, left open in the Debian package for many months after we fixed it. No-one upstream is a Debian developer, and no-one in Debian was updating the package. Python started out with a traditional model of applications sharing libraries, and is now moving in the direction of self-contained applications with separate dependencies. Languages like Javascript and Rust went straight for the latter model, so are probably even less amenable to Debian packaging.
- indymike 6y agoThis might just be evolution. For development, at least for me, the experience was never install a distro and some packages from the distro and start coding. There was always something that would require a bunch of bespoke installations. Libthis or libthat out of date. Files in the wrong place in the distro (or upstream developer's config). Old version of the database server. Now, I think there's a pretty nice balance going on. Seems like the distros do a good job of getting you to a working GUI and command line, and we've had all kinds of new tools show up for getting to the latest/greatest for development. That said, I think the distros could do a much better job helping devops and admins understand how to use tools like apt and yum. Then there's the whole container thing, which really does give us a more universal way to distribute software (ok, maybe not snaps).
- saagarjha 6y agoHomebrew is meant to be language agnostic.
- elboulangero 6y ago> More recently, so many things I want to use are not available as a reasonably up-to-date package. Some examples are hugo and eclipse, where the versions provided are unusably ancient. I understand your comment but Hugo is the wrong example, this package is actively maintained and is up to date in Debian unstable. https://tracker.debian.org/pkg/hugo https://tracker.debian.org/pkg/hugo