5 ms·

What is a distribution if not a collection of software that obey the same standard? Without the latter, all you have is a burlap sack full of software. Hardly

by gspr 6y ago

What is a distribution if not a collection of software that obey the same standard? Without the latter, all you have is a burlap sack full of software. Hardly a distribution. Fine if that's what you want, but it's not what Debian is.

lmm 6y ago
A distribution is by definition distributing something that already exists, so I think distributions that stick close to upstream are more in the spirit of the concept. I also think Debian's approach has shown itself to produce something less reliable on the whole. Of course if you prefer the Debian approach, knock yourself out.
- gspr 6y ago
  For those of you that don't like that terminology: let's just use the words that Debian itself uses, namely "the universal operating system". What is an operating system if not a collection of software that follow a standard so as to interoperate? > I also think Debian's approach has shown itself to produce something less reliable on the whole I think the opposite. Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example.
  - lmm 6y ago
    > Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example. Debian's patches to cdrecord introduced so many bugs that they eventually ended up driving the original author away from open source. I think I remember something about the python 2 -> 3 transition being harder on Debian because of changes they've made? The packaged Tomcat on Debian is so different that every time I've seen someone running Tomcat they've installed it manually instead. Debian has essentially given up on packaging Hadoop. Some of their criticisms of its build process are certainly valid, but others seem to be an unreasonable expectation that everything will build exactly the way Debian expects. E.g. if I'm understanding correctly, they essentially take the position that they won't package anything built with Maven, on frankly spurious grounds. Debian tends to end up with very outdated versions of anything from an ecosystem that uses large numbers of small libraries, or, basically, anything that isn't written in C or Perl. E.g. Python libraries are typically a long way out of date (even compared to other distributions), and Debian's package management tends to be less compatible with Python's built-in tools like pip than other distributions (e.g. Debian is more likely to rename a Python library, in my experience, which then breaks reverse-dependencies on that library or leads to having two incompatible copies of it installed). So people running Python programs on Debian tend to end up with either a difficult-to-manage mix of system and non-system dependencies, or multiple parallel installs of Python. You could say that Debian offers a reliable platform and it's the users' fault for installing these unreliable things on top of it. But an OS exists to run applications, not the other way around, and I find that in practice Debian's approach means users are forced to step outside the managed parts of it much more than with other distributions, and it handles it less well when they do, making for setups that are less reliable in practice. Put it this way: the "add-on repository" culture is a lot stronger in Debian/Ubuntu than in other distributions, and I think that's actually a weakness rather than a strength.
    - gspr 6y ago
      > Debian's patches to cdrecord introduced so many bugs that they eventually ended up driving the original author away from open source. That's not how I remember it. I remember distros (Debian and others) patching cdrecord, which resulted in the upstream author getting furious and re-licensing cdrecord under a non-free license to stop them. Of course the software was then forked, and the author indeed ragequit free software development. People can read more of the story here: https://en.wikipedia.org/wiki/Cdrtools#License_compatibility_controversy https://en.wikipedia.org/wiki/Cdrtools#License_compatibility... There's a reason stuff like this is named after Schilling: https://mako.cc/copyrighteous/award https://mako.cc/copyrighteous/award > I think I remember something about the python 2 -> 3 transition being harder on Debian because of changes they've made? No? There was no transition. 2 and 3 coexisted, 2 was recently removed. > The packaged Tomcat on Debian is so different that every time I've seen someone running Tomcat they've installed it manually instead. Different as in file layout? > Debian has essentially given up on packaging Hadoop. Some of their criticisms of its build process are certainly valid, but others seem to be an unreasonable expectation that everything will build exactly the way Debian expects. E.g. if I'm understanding correctly, they essentially take the position that they won't package anything built with Maven, on frankly spurious grounds. Hadoop is not buildable with non-bundled dependencies, as far as I understand. This violates Policy. We were discussing reliability – am I missing something here? > Debian tends to end up with very outdated versions of anything from an ecosystem that uses large numbers of small libraries, or, basically, anything that isn't written in C or Perl. E.g. Python libraries are typically a long way out of date (even compared to other distributions), Can you show some examples? > and Debian's package management tends to be less compatible with Python's built-in tools like pip This is just not true. > than other distributions (e.g. Debian is more likely to rename a Python library, in my experience, which then breaks reverse-dependencies on that library or leads to having two incompatible copies of it installed) The package names are often renamed, but not the Python modules. > You could say that Debian offers a reliable platform and it's the users' fault for installing these unreliable things on top of it. But an OS exists to run applications, not the other way around Python libraries are hardly applications. > Put it this way: the "add-on repository" culture is a lot stronger in Debian/Ubuntu than in other distributions, and I think that's actually a weakness rather than a strength. Add-on repos are frowned upon in Debian.
jcelerier 6y ago
> What is a distribution if not a collection of software that obey the same standard? why would that definition make any sense ?
- gspr 6y ago
  For those of you that don't like that terminology: let's just use the words that Debian itself uses, namely "the universal operating system". What is an operating system if not a collection of software that follow a standard so as to interoperate?
  - jcelerier 6y ago
    > What is an operating system if not a collection of software that follow a standard so as to interoperate? I have never heard that definition of an operating system, but it seems that every university & place has its own so we're all speaking different languages anyways when using that word :-)

by gspr 6y ago

lmm 6y ago

A distribution is by definition distributing something that already exists, so I think distributions that stick close to upstream are more in the spirit of the concept. I also think Debian's approach has shown itself to produce something less reliable on the whole. Of course if you prefer the Debian approach, knock yourself out.

gspr 6y ago
For those of you that don't like that terminology: let's just use the words that Debian itself uses, namely "the universal operating system". What is an operating system if not a collection of software that follow a standard so as to interoperate? > I also think Debian's approach has shown itself to produce something less reliable on the whole I think the opposite. Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example.
- lmm 6y ago
  > Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example. Debian's patches to cdrecord introduced so many bugs that they eventually ended up driving the original author away from open source. I think I remember something about the python 2 -> 3 transition being harder on Debian because of changes they've made? The packaged Tomcat on Debian is so different that every time I've seen someone running Tomcat they've installed it manually instead. Debian has essentially given up on packaging Hadoop. Some of their criticisms of its build process are certainly valid, but others seem to be an unreasonable expectation that everything will build exactly the way Debian expects. E.g. if I'm understanding correctly, they essentially take the position that they won't package anything built with Maven, on frankly spurious grounds. Debian tends to end up with very outdated versions of anything from an ecosystem that uses large numbers of small libraries, or, basically, anything that isn't written in C or Perl. E.g. Python libraries are typically a long way out of date (even compared to other distributions), and Debian's package management tends to be less compatible with Python's built-in tools like pip than other distributions (e.g. Debian is more likely to rename a Python library, in my experience, which then breaks reverse-dependencies on that library or leads to having two incompatible copies of it installed). So people running Python programs on Debian tend to end up with either a difficult-to-manage mix of system and non-system dependencies, or multiple parallel installs of Python. You could say that Debian offers a reliable platform and it's the users' fault for installing these unreliable things on top of it. But an OS exists to run applications, not the other way around, and I find that in practice Debian's approach means users are forced to step outside the managed parts of it much more than with other distributions, and it handles it less well when they do, making for setups that are less reliable in practice. Put it this way: the "add-on repository" culture is a lot stronger in Debian/Ubuntu than in other distributions, and I think that's actually a weakness rather than a strength.
  - gspr 6y ago
    > Debian's patches to cdrecord introduced so many bugs that they eventually ended up driving the original author away from open source. That's not how I remember it. I remember distros (Debian and others) patching cdrecord, which resulted in the upstream author getting furious and re-licensing cdrecord under a non-free license to stop them. Of course the software was then forked, and the author indeed ragequit free software development. People can read more of the story here: https://en.wikipedia.org/wiki/Cdrtools#License_compatibility_controversy https://en.wikipedia.org/wiki/Cdrtools#License_compatibility... There's a reason stuff like this is named after Schilling: https://mako.cc/copyrighteous/award https://mako.cc/copyrighteous/award > I think I remember something about the python 2 -> 3 transition being harder on Debian because of changes they've made? No? There was no transition. 2 and 3 coexisted, 2 was recently removed. > The packaged Tomcat on Debian is so different that every time I've seen someone running Tomcat they've installed it manually instead. Different as in file layout? > Debian has essentially given up on packaging Hadoop. Some of their criticisms of its build process are certainly valid, but others seem to be an unreasonable expectation that everything will build exactly the way Debian expects. E.g. if I'm understanding correctly, they essentially take the position that they won't package anything built with Maven, on frankly spurious grounds. Hadoop is not buildable with non-bundled dependencies, as far as I understand. This violates Policy. We were discussing reliability – am I missing something here? > Debian tends to end up with very outdated versions of anything from an ecosystem that uses large numbers of small libraries, or, basically, anything that isn't written in C or Perl. E.g. Python libraries are typically a long way out of date (even compared to other distributions), Can you show some examples? > and Debian's package management tends to be less compatible with Python's built-in tools like pip This is just not true. > than other distributions (e.g. Debian is more likely to rename a Python library, in my experience, which then breaks reverse-dependencies on that library or leads to having two incompatible copies of it installed) The package names are often renamed, but not the Python modules. > You could say that Debian offers a reliable platform and it's the users' fault for installing these unreliable things on top of it. But an OS exists to run applications, not the other way around Python libraries are hardly applications. > Put it this way: the "add-on repository" culture is a lot stronger in Debian/Ubuntu than in other distributions, and I think that's actually a weakness rather than a strength. Add-on repos are frowned upon in Debian.

jcelerier 6y ago

> What is a distribution if not a collection of software that obey the same standard? why would that definition make any sense ?

gspr 6y ago
For those of you that don't like that terminology: let's just use the words that Debian itself uses, namely "the universal operating system". What is an operating system if not a collection of software that follow a standard so as to interoperate?
- jcelerier 6y ago
  > What is an operating system if not a collection of software that follow a standard so as to interoperate? I have never heard that definition of an operating system, but it seems that every university & place has its own so we're all speaking different languages anyways when using that word :-)