4 ms·

> But can you really be sure that people that do this stuff as an hobby can deliver this in the quality that you expect and require? Let’s be honest here, proba

by r0muald 11y ago

> But can you really be sure that people that do this stuff as an hobby can deliver this in the quality that you expect and require? Let’s be honest here, probably not. This must be the most short sighted description of Debian developers I have to see, cause 1) most do packaging as part of their paid job 2) apparently millions of people in the world believe that, yes, these people do a fine job at maintaining those packages. Not to mention those who develop the software they package or those who do academic research about software packaging and dependency resolution. But insulting Debian has become commonplace nowadays.

_yy 11y ago
The author also seriously recommends Arch Linux and Tumbleweed as alternatives. Anyone who ever maintained a server in an enterprise production environment knows how valuable the kind of stability that the author criticisms is. Not everyone lives in a DevOps environment where you can "move fast and break things". He does have a point about unmaintained packages, though. Debian probably shouldn't package things if they cannot support it over the lifetime of the release. Why would I ever want to use a two-years-old Wordpress version? I never understood why those kinds of applications are even packaged at all. Most sysadmins deal with this by including a third party repository for applications and Elasticsearch (any many others), often by the authors themselves, which takes care of security and version updates. This eliminates most of the concerns. You get a rock-solid operating system and an up to date application on top of it. Web applications like Wordpress or Owncloud aren't usually deployed using distro packages at all.
- msl09 11y ago
  For 99% of such packages all I really want is to be able to apt-get build-dep. I suppose that in those cases guix would be the ideal system.
- acdimalev 11y ago
  Countering one of your points, and yet bolstering your statement here. Even in a DevOps environment, packaging is important. Same as a system image or random artifact, a distribution package can provide consistency and repeatability. If I had to wait for a rebuild of the entire operating system to test deployment of a single application, how much confidence could I possibly gain in that application's deployment process? Also... it seems the author is suggesting that newer software always has fewer bugs. Hmm... .
snuxoll 11y ago
I also think this really shows the disconnect in mentality between the younger developers and the 'older' ones (I quote this because while I am 25 I often find myself in the latter category). Software used to be a thing you maintained, if you made a major release you would continue to support the old one for a period until users (in the case of libraries, developers are your users) had a chance to migrate off of it. This meant releasing security updates and bugfixes for the old release in parallel to the new one - or at least making it not impossible for these changes to be backported. Now everyone wants to be evergreen - you're still using 1.2.x of my library that has glaring security issues that have been fixed in 2.x? Well, better upgrade, because I'm only supporting the newest release. As someone who has to constantly deal with the headache that is NuGet for their day-job, I absolutely loathe this mentality and the idea that everyone should just use their language package manager. If any of the NuGet packages we use internally has some glaring security issue, I've got 20 applications to update, test and redeploy on a good day if there's no breaking changes - at least if for whatever reason the Fedora packagers can't backport a security fix for a python package I depend on it's easy enough to push a new version out in my local yum repository and have it automatically fixed for every application that uses it.
- 3pt14159 11y ago
  It's gotten too onerous to support old software. There used to be one Linux, one BSD, and a couple of Windows / DOS. Mac was probably around too, I just never interacted with it in the 90s / early 2000s. Backporting security fixes and replicating interconnected bugs across all the combinations of setups is impossible. Just getting the latest version fixed in all is onerous. Keep current is my philosophy. It's why I like the Ruby community, the global namespace makes it impossible for libraries to stay behind too long.
  - dozzie 11y ago
    > There used to be one Linux, one BSD, and a couple of Windows / DOS. Mac was probably around too And AIX of several releases. And HP/UX. And SGI Irix. And Solaris + SunOS, again, of several releases (mostly backward compatible, though). Don't say it was easier then than it is today, barring the young guns constantly breaking their new Node.js packages and Ruby gems.

by r0muald 11y ago

_yy 11y ago

The author also seriously recommends Arch Linux and Tumbleweed as alternatives. Anyone who ever maintained a server in an enterprise production environment knows how valuable the kind of stability that the author criticisms is. Not everyone lives in a DevOps environment where you can "move fast and break things". He does have a point about unmaintained packages, though. Debian probably shouldn't package things if they cannot support it over the lifetime of the release. Why would I ever want to use a two-years-old Wordpress version? I never understood why those kinds of applications are even packaged at all. Most sysadmins deal with this by including a third party repository for applications and Elasticsearch (any many others), often by the authors themselves, which takes care of security and version updates. This eliminates most of the concerns. You get a rock-solid operating system and an up to date application on top of it. Web applications like Wordpress or Owncloud aren't usually deployed using distro packages at all.

msl09 11y ago
For 99% of such packages all I really want is to be able to apt-get build-dep. I suppose that in those cases guix would be the ideal system.
acdimalev 11y ago
Countering one of your points, and yet bolstering your statement here. Even in a DevOps environment, packaging is important. Same as a system image or random artifact, a distribution package can provide consistency and repeatability. If I had to wait for a rebuild of the entire operating system to test deployment of a single application, how much confidence could I possibly gain in that application's deployment process? Also... it seems the author is suggesting that newer software always has fewer bugs. Hmm... .

snuxoll 11y ago

I also think this really shows the disconnect in mentality between the younger developers and the 'older' ones (I quote this because while I am 25 I often find myself in the latter category). Software used to be a thing you maintained, if you made a major release you would continue to support the old one for a period until users (in the case of libraries, developers are your users) had a chance to migrate off of it. This meant releasing security updates and bugfixes for the old release in parallel to the new one - or at least making it not impossible for these changes to be backported. Now everyone wants to be evergreen - you're still using 1.2.x of my library that has glaring security issues that have been fixed in 2.x? Well, better upgrade, because I'm only supporting the newest release. As someone who has to constantly deal with the headache that is NuGet for their day-job, I absolutely loathe this mentality and the idea that everyone should just use their language package manager. If any of the NuGet packages we use internally has some glaring security issue, I've got 20 applications to update, test and redeploy on a good day if there's no breaking changes - at least if for whatever reason the Fedora packagers can't backport a security fix for a python package I depend on it's easy enough to push a new version out in my local yum repository and have it automatically fixed for every application that uses it.

3pt14159 11y ago
It's gotten too onerous to support old software. There used to be one Linux, one BSD, and a couple of Windows / DOS. Mac was probably around too, I just never interacted with it in the 90s / early 2000s. Backporting security fixes and replicating interconnected bugs across all the combinations of setups is impossible. Just getting the latest version fixed in all is onerous. Keep current is my philosophy. It's why I like the Ruby community, the global namespace makes it impossible for libraries to stay behind too long.
- dozzie 11y ago
  > There used to be one Linux, one BSD, and a couple of Windows / DOS. Mac was probably around too And AIX of several releases. And HP/UX. And SGI Irix. And Solaris + SunOS, again, of several releases (mostly backward compatible, though). Don't say it was easier then than it is today, barring the young guns constantly breaking their new Node.js packages and Ruby gems.