101–110 of 624 posts
Earlier quoted context omitted.
Ubuntu has a much more aggressive 6 months release cycle, it's not nearly as outdated as Debian sometimes can be.
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.
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. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support. The old model works for established software, but breaks down a l…
AppImage is not like the other two, it is fundamentally just a way to make a self-contained binary directory into a single runnable file - a way to avoid having to tell the user to extract a tarball and run a particular file inside. Convenience, nothing more. The other two define entire alternate runtimes.
AppImages are not comparable with statically linked binaries.
Earlier quoted context omitted.
This model doesn't necessarily work for software that developers don't want others shipping for them .
Or you end up with useless packages like ancient versions of nodejs sticking around for half a decade.
Not being facetious, genuinely curious.
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.
Earlier quoted context omitted.
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.
There are plenty of projects to semi-automatically produce packages for a large number of distributions starting from just a git repo of the software to package. Sure, packaging software is a bit of a thankless task, but with enough automation, packaging thousands of bits of software on every git commit should be doable by just a few volunteers.
1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc...
2) a standard format for declaratively describing how to build a package.
Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templates, Gentoo ebuilds - they all do more or less the same thing in the same way, they all work really well, and they're all incompatible for sheerly incidental reasons. I'd like to see these incompatibilities papered over in such a way that I can write one template and generate all the others.
Earlier quoted context omitted.
The whole point of a distribution is that this job is done by the distributors, not the authors.
Is there a distribution (or whatever one would call it - a Linux) where the aim is to not be managing the whole end-user system of OS+Apps, but just the OS. E.g. similar to Windows, or Android?
You're expected to run most apps as flatpaks.
To begin with: It would be nice if the data of the containerized applications were stored in one place and one place only. Each application should simply be a single directory in /snaps/ or something.
At first I thought snap would be like that. But no. When I did some tests, the data of a snap seems to be splattered across various places on the file system.
They could do with improving the behaviour of snaps first before removing alternatives. The updates are currently awkward as they don't seem to work if the application is running which can be a problem with something like Firefox which I have running for days at a time. It's also annoying that it's gone from using simple "apt" commands to keep the machine up-to-date, to also needing a "snap refresh". I choose to use…
> The updates are currently awkward as they don't seem to work if the application is running The fix for this is currently being tested: https://bugs.launchpad.net/snapd/+bug/1980271 > before removing alternatives Alternatives remain available for install. They weren't removed.
You're technically correct (the best kind) about them not removing alternatives, but you have to do some manual intervention to get them back, so I consider it being removed when compared to the previous behaviour of having them available by default.
Earlier quoted context omitted.
> Choosing a distro is basically choosing a DE and package manager these days anyway What distribution doesn't support at least half a dozen desktop environments these days?
>What distribution doesn't support at least half a dozen desktop environments these days? Most usually come out of the box with official support for only 2 DEs. Of course they can theoretically support every one out there if you manually install them.
It's as simple as
apt-get install $DE