141–150 of 198 posts
Earlier quoted context omitted.
Quirky, clunky tooling with a bunch of arbitrary shit you have to memorize to use correctly. People enjoy that kind of thing after they learn it.
Enjoy? No. But yeah, it gets easier once you've done it a few times.
Earlier quoted context omitted.
With many other non-copyleft alternatives shaping up, and systems like ChromeOS and Android, with the Linux kernel and completely unrelated userspace, I firmly believe when our generation is gone, Linux won't stay around on its present form for much longer.
I wonder if the end-game is a BSD, or some sort of hard fork of the Linux ecosystem. Ubuntu and RedHat basically don’t work by any of my definitions of “work”. They’re both enterprisey and bloated and flaky in all the ways Windows was in the 90’s, except they add flatpack/snap, letting each program be its own flaky OS install, compounding the problem. Want to save a file to ~? Read this 1000 page tome on the 21 succe…
Debian's policies also led to a heavily restricted version of RetroArch being available instead of the real version. Specifically, RetroArch has its own package management functionality built-in through its "Core Updater" feature, which downloads and installs emulators in the form of library files. This is banned by Debian because it sidesteps the whole package manager system. Meanwhile, you can still build the full…
Earlier quoted context omitted.
> If your goal is to distribute software across multiple distros and operating systems, bundling dependencies makes sense. Of course, an important "exception to the exception" is when you're making software that can easily be distributed by distributions, e.g. because it's end user software and open source. I think the optimal cases for bundled dependencies are (a) large closed source binaries that never change, like…
> is when you're making software that can easily be distributed by distributions, e.g. because it's end user software and open source. I have trouble understanding why this is desirable for either authors or end users. Even for open source end user applications, I want the software that I'm running to be reflective of the software that was authored and not the software that some distro maintainers think it should be.
I don't. As an end-user, I couldn't care less about what the author wanted, I want to run the best possible version of the software. Often that's the version maintained by my distro, as they've put in the effort to make sure all the different software on my system works well together.
Earlier quoted context omitted.
I think either approach makes sense depending on who you are. If your goal is to distribute software across multiple distros and operating systems, bundling dependencies makes sense. If your goal is to maintain a distro, shared libraries that you can apply a security patch to exactly once is obviously better. But these are two different people with either goal.
What about the user? If your goal is to consume software for which you need long term reliability, accepting software that bundles an unmaintainable (to you) set of dependencies does not make sense. Unless you have no better option [edit: or if you're paying to delegate your problems to someone else I suppose]. As a user, using software sources that make the same choices Debian makes is always preferable for you if t…
Mandating shared dependencies means that Debian is often running software against a dependency version that the original author did not develop against or test against. Sometimes the Debian package is effectively a fork. This results in Debian-specific bugs which get reported upstream. Distribution-specific bugs are a crappy experience for upstream developers because it wastes their time, and it's a crappy experience for users to be told that their software cannot be supported upstream because it's a fork.
Maintaining a huge repository of forked software is also an enormous undertaking. It's common for Debian users to be running fairly old versions of software. This is also not ideal, particularly for desktop users who read upstream documentation and require support when entire features are missing from their antique Debian version.
What I don't like in Debian: - 3rd-party software is not welcome; there is no mechanism for installing it securely because you are supposed to either install software from official repository or compile what you have written yourself. For example, if you want to install Sublime Text, or VS Code, there is no way to do it securely, without giving untrusted software access to your browser history and SSH keys. Of course…
> For example, if you want to install Sublime Text, or VS Code, there is no way to do it securely, without giving untrusted software access to your browser history and SSH keys. First, if you don't trust a bit of software, why are you installing it? But more importantly - you don't want your text editor to be able to open and edit your browser history files, or your ssh key files? If my text editor wasn't able to ope…
The more people you trust, the larger is the chance that you get deceived.
> But more importantly - you don't want your text editor to be able to open and edit your browser history files, or your ssh key files?
Only with my permission.
What I don't like in Debian: - 3rd-party software is not welcome; there is no mechanism for installing it securely because you are supposed to either install software from official repository or compile what you have written yourself. For example, if you want to install Sublime Text, or VS Code, there is no way to do it securely, without giving untrusted software access to your browser history and SSH keys. Of course…
> For example, if you want to install Sublime Text, or VS Code, there is no way to do it securely, without giving untrusted software access to your browser history and SSH keys. First, if you don't trust a bit of software, why are you installing it? But more importantly - you don't want your text editor to be able to open and edit your browser history files, or your ssh key files? If my text editor wasn't able to ope…
I just switched to Debian this year after ~13 years of Ubuntu, and I really appreciate it It grew on me after a long time. I always thought it was not the most "technically sound" way of doing things i.e. I don't really like the packaging model of global updates where you don't know what's going on, and sometimes there are version conflicts But I have come to appreciate the stability and good intentions of the Debian…
What are you getting conflicts on? Unless you’re pulling from Sid, and did something fun like upgrading libc6, you shouldn’t see version conflicts if everything was installed via apt.
Earlier quoted context omitted.
What about the user? If your goal is to consume software for which you need long term reliability, accepting software that bundles an unmaintainable (to you) set of dependencies does not make sense. Unless you have no better option [edit: or if you're paying to delegate your problems to someone else I suppose]. As a user, using software sources that make the same choices Debian makes is always preferable for you if t…
Engineering tradeoffs are always tradeoffs. One is not strictly better than the other from the user's perspective. Mandating shared dependencies means that Debian is often running software against a dependency version that the original author did not develop against or test against. Sometimes the Debian package is effectively a fork. This results in Debian-specific bugs which get reported upstream. Distribution-speci…
If you're an upstream who gets frustrated by Debian users, then it's worth considering why they're using Debian the first place.
There are some users who don't want this, and they tend to be the vocal minority. Debian is not the right distribution for them!
I personally love and use Debian exactly for its principles and stability. I have heard users of other distros and a few upstream complaint that Debian "modifies" their packages? Is it so? If yes, there surely must be a good reason. Can someone tell me about it?
There's mainly three kinds of patches: * make the software behave like Debian needs it (configuration is stored somewhere in /etc/, no additional downloads at runtime, use the system libraries instead of vendored ones) * security backports. Debian freezes the functionality at release and only provides security updates. Many software nowadays just includes security fixes in new releases bundled with new functionality.…
This type is actually really common. Debian packages something like 30k upstreams, and so some are always behind.