171–180 of 624 posts
Earlier quoted context omitted.
But that means I have to update my OS and my application when I want a new version instead of just my application. Say what you want about Windows, but I can download and run the latest version of all my applications on Windows 7 without it missing a beat.
Hackers can also run their applications on your Windows 7 installations without missing a beat
Moved to Fedora for the mess around snaps and I'm not going to look back.
Really is a joy to use.
Earlier quoted context omitted.
>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that. If an app can't use a standard .deb or .rpm then the distro is doing something wrong…
Have you ever actually worked on distribution packaging? There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for. You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.
I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.
Wow they're still pushing snaps, the project with some the worst engineering I've ever seen. - Extremely slow at doing anything, even the most basic commands. - Ridiculous auto-update mechanism (you can't even disable it wtf). - Random, nonsense limitations (why can't I open dot files and dot directories???). So terrible that for most apps that I installed with snaps I end up installing the deb version later on. What…
Earlier quoted context omitted.
Conversely, `pacman -Syyuu` doesn't complete reliably without user intervention, which is far from ideal. I say this as an Arch user - the expectation that I'm going to manually attend to package upgrades in practice leads to me using outdated packages
I'm genuinely curious about this, as I see people say it a lot but it's not my experience at all. I have an Arch Linux desktop (KDE + AMD), I update it every few days, and it's always fine. I also have a shell VM that runs IRC etc that often isn't updated in months, and I run `pacman -Syyu` and everything works fine. I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more…
Also worth pointing out - the fact that you can so easily perform a partial update with pacman and totally break your system is infuriating to me. If an upgrade fails, it should revert to a cached package database. Otherwise an update will fail, the user will go to install something else, and all of a sudden nothing can link to libcrypt because you installed ntpd, which upgraded all of your auth stuff after an openSSL vuln was discovered, and everything is hosed.
Can we go back to just shipping apt packages? They worked fine, and I don't feel like having multiple types of containers and update methods and mounted image file systems really made anyone's life better.
What you are really saying is you want all software developers to publish Debian packages (no such thing as "apt" packages) compatible with your particular Debian distribution, even though they might be using a different Debian based distribution, a completely different altogether, maybe even a different architecture, even though that compatibility isn't their primary concern.
Wow they're still pushing snaps, the project with some the worst engineering I've ever seen. - Extremely slow at doing anything, even the most basic commands. - Ridiculous auto-update mechanism (you can't even disable it wtf). - Random, nonsense limitations (why can't I open dot files and dot directories???). So terrible that for most apps that I installed with snaps I end up installing the deb version later on. What…
Don't you just remove it if you're using Ubuntu, never install it if you use Debian/Fedora/Arch, and pretend it doesn't exist? I've never run into an app I want that is only packaged for Snap.
Earlier quoted context omitted.
Arch Linux would like to have a word
This. Also void and alpine. Which have simple, no-nonsense package formats. We get it that deb and rpm are a hassle to learn and write, but it's completely a false dichotomy to say snap or flatpak are the only alternative. In fact they push a widely different model of software distribution, one that completely destroys "user unions" which is a crucial aspect of what distributions are.
They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo.
> false dichotomy to say snap or flatpak are the only alternative
we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing.
Edit: names
I was outspoken in my interview about snaps. Of course this is the path to success in a monoculture.
Earlier quoted context omitted.
At which point was nodejs five years older than the distro it shipped on? Not being facetious, genuinely curious.
> At which point was nodejs five years older than the distro it shipped on? https://askubuntu.com/questions/1259840/why-an-old-nodejs-ve... Nodejs v4.x was "new" when Ubuntu 16.04 LTS came out. It was added to its apt repos, LTS releases are supported for 5+ years, and LTS policy is not to update major versions of software within a release. So while nodejs was pumping out new major versions every 6-months, people run…