why is eclipse so many version behind the current version? I do not think it would hurt to update a little faster.
If there's no people volunteering to update it, then there's nobody to update it a little faster.
Debian Packages That Need Lovin'
41–50 of 151 posts
Re: Debian Packages That Need Lovin'
#42I 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…
I 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-compi…
> Their secret, I think, is staying as-close-as-possible to upstream
I've wondered about this. This would depend on upstream being sane about how it does things or puts things.
Is this always the case?
Re: Debian Packages That Need Lovin'
#43Earlier quoted context omitted.
I 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-compi…
With zfs and boot environments the whole rollback issue is solved. No need for nixos for that.
seems like zfs would be a low-level solution and nix would be a high-level solution.
Re: Debian Packages That Need Lovin'
#44I 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…
> 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.
Debian 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.)
Re: Debian Packages That Need Lovin'
#45I 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…
After 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 sea…
I think arch is better for desktop sorts of things. remember:
- desktop users want the latest thing, immediately.
- server users want nothing to change, ever.
Re: Debian Packages That Need Lovin'
#46I once built a whole deployment system out of packaging all our services as Debian packages and running them out of our own apt repo. Once we got it working, this was a really low maintenance system and bringing new servers online was stupid easy. Since then Debian packages have become easier to create and maintain. And it’s a great skill if you ever need to create e.g. a custom-compiled version of nginx or some such…
What do you recommend for learning that stuff?
Re: Debian Packages That Need Lovin'
#47I 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…
> 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.
IMO, this moved forward with Linux at the OS level 20 years ago with apt and rpm.
Seems like now that hyper scale cloud vendors are displacing distros as gatekeeper, we’re going down a road towards niche packaging for languages, frameworks, etc.
Re: Debian Packages That Need Lovin'
#48Earlier quoted context omitted.
I 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-compi…
> Their secret, I think, is staying as-close-as-possible to upstream I've wondered about this. This would depend on upstream being sane about how it does things or puts things. Is this always the case?
Usually, yes, it appears. Maintainers of projects are generally pretty invested in getting their software into popular distros... and so they tend to follow the patterns that would allow that. (I mean, stuff like 'where do I put the binaries' is still often configured in Arch and other distros, so we're talking about stuff outside of that kind of thing. Most packages aren't complicated enough to require anything outside of simple configure flags.)
Re: Debian Packages That Need Lovin'
#49This is an off topic question, but is Debian a good alternative to Gentoo? Over the last three years I'm assuming Gentoo is so low on resources that they are just removing packages left and right. Every few months my install is broken due to this.
The main reason I'm still with gentoo is inertia and I really like the tools and just the way things work. The problem really is the portage tree (basically the repo) which is become more and more bare as the years go on. For example, I miss eix whenever I use debian, apt-cache just isn't as useful. Also, having to use not systemd is a plus and a reason I won't use Arch. Any suggestions?
Re: Debian Packages That Need Lovin'
#50I 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…
This 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).