5 ms·

That's impossible because the distribution is responsible for the updates it provides. If you package libraries with your program alla Firefox, Chrome, or Java,

by wazoox 16y ago

That's impossible because the distribution is responsible for the updates it provides. If you package libraries with your program alla Firefox, Chrome, or Java, you simply make your program unmaintainable and unsupportable from the distro point-of-view. This is true of Ubuntu, as well as Debian or RedHat. This way of thinking is incompatible with basically all of the major distros.

wmf 16y ago
Honestly, I don't even want to get apps from distros at all; I'd prefer to get tested binaries directly from upstream, but all the disagreement over package formats and such makes that nearly impossible. I feel like distros have painted themselves into a corner with their rigid policies and now they're complaining about it.
- nkassis 16y ago
  But then the tested binaries + libraries is a big directory which doesn't respect any of the unices way of organizing files. I don't see how this makes it any more convenient on the users than downloading it from upstream makes it. I compare this to things like installing nginx on ubuntu which comes with files in the places I expect (/etc instead of the configure script default of /usr/local/conf) etc. Packages are actually very convenient for 90% of what I user on my computer. Ruby and Clojure stuff are the only thing I download and install myself.
  - FooBarWidget 16y ago
    Why does it matter whether it respects the way Unix organizes files? Other than having config files in /etc and having binaries in $PATH, who cares whether libfoo.so is in /usr/lib or in /usr/myawesomeapp.com/vendor/libraries?
    - theBobMcCormick 16y ago
      Very true. The traditional Unix way of organizing files makes sense in a command line world, and I'd expect that sed, awk, grep and friends will continue to live in directories like /usr/bin. But for GUI desktop apps, there's really no good reason each app can't live in it's own directory.
      - rbanffy 16y ago
        Except that then you would have to do some contortions in order to use it or its parts from a command line or a script.
    - sqrt17 16y ago
      Most commonly, it would be in /opt/awesomeapp/lib (and the binaries in /opt/awesomeapp/bin) See http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA... That's, more or less, what /opt is supposed to be. QT and KDE used to be "integrated" that way, until distros finally got around to put them into /usr. So, there really is a standardize mechanisms with those uncommunicative packages in the FHS. (Note that the Unix family as a whole does not standardize filesystem layout, even though Solaris also has /opt and uses it for exotic packages such as GNU gcc).
  - blasdel 16y ago
    > Ruby and Clojure stuff are the only thing I download and install myself. And why do you do this? Because the Debian/Ubuntu packages for these things are old and broken, primarily because they are insistent on breaking up the packages and scattering the files all over the FHS they worship. They despise RubyGems because it installs packages in a self-contained way and lets you install multiple versions of everything without mangling the names. It puts them out of a job.
    - rbanffy 16y ago
      > They despise RubyGems because it installs packages in a self-contained way A way that conflicts with the software management Linux distros use. You can't issue a command and have your system updated and, at the same time, your Ruby environment updated. Introducing some new gem can crash system software written in Ruby and make it impossible for the system management tools to rely on the same interpreter you do. If you want to install your gems, something like Python's virtualenv is recommended. I don't know if Ruby has one. If I relied on Ruby, I would make sure it had, even if it meant writing C.
    - regularfry 16y ago
      Except it doesn't, because nobody (that I've ever heard of) backports security fixes to old gem versions.
- theBobMcCormick 16y ago
  I agree. I'd much rather be able to go out to, as an example, mozilla.com and download the latest firefox in an easy to run installer (like I can do on Windows), than have to upgrade my entire fricking OS just to get the latest Firefox. Again, just using Firefox as an example. The same applies to most end user apps, stuff like Java and Flash, etc.
  - kree10 16y ago
    In the case of Firefox, I don't even want an installer. I like the OS X install process for Firefox (and many other apps): copy Firefox.app to /Applications. That's it.
    - GeneralMaximus 16y ago
      As much as I love application bundles, I'd like to point out that this method of distribution leads to code duplication. For example, almost every popular OS X application ships its own version of Sparkle and Growl (to verify this yourself, cd into the app bundle and go to Contents/Frameworks).
      - theBobMcCormick 16y ago
        Does it matter? Disk space and ram are both cheap and plentiful. The difference in disk space or ram taken by apps on an average OSX desktop, and average Windows desktop, and an average Linux desktop seems to be negligible.
        devdas 16y ago
        It matters when there's a security bug which needs patching in an underlying library. With shared libraries, only one library needs updating. With each package proving it's entire ecosystem, every package on your system needs such updates.
        coffeeaddicted 16y ago
- mjschultz 16y ago
  I'm want to agree with you, but I have a question. Binaries tested against what? Obviously the testsuite that upstream uses, but every program will have dynamic dependencies into the distro. In that case wouldn't the upstream maintainers have to test every version or every distro to make sure it works for you? That seems time intensive (not infeasible, but it would become chaotic very quickly when we multiply the number of distros by the number of apps people want). I'd also presume that the upstream maintainers include their testsuite with their source, so nothing should prevent the downstream distro maintainers from running the testsuite before shipping (I have always assumed they do, I hope I'm not wrong).
  - wmf 16y ago
    If there hadn't been multiple divergent distros in the first place, upstream developers wouldn't be faced with the prospect of a huge testing effort. The result seems to be that we're locked into a model of getting all software from the distros, but they don't necessarily have the resources to do a good job of packaging everything. If you're willing to take some abuse you can release server software only on RHEL/SLES and desktop apps only on Ubuntu and tell everyone else to fend for themselves.
    - sophacles 16y ago
      And further, there should have only ever been one webserver, one database, one KV store, one programming language and one CPU architecture right? The crappy webapp you work on, which is described as "like $x but better" probably shouldn't be in existence at all, because we already have $x.
- Goladus 16y ago
  For my own personal servers and workstations, yeah either way works pretty well. But when you have several hundred servers with a variety of different applications, many of which you don't use at all but you still need to keep patched and up to date, having a distribution helps a lot. I curse the guys at CSW all the time (eg up and changing config directories from /opt/csw/etc to /etc/opt/csw[1]) but they have probably saved me quite a bit of work testing and building packages. [1]For the record, I think /etc/opt/csw is better, just not better enough to be worth all the hassle of changing.
- wazoox 16y ago
  What disagreement? There are two package formats in large use, rpm and deb. Many software are distributed upstream as .deb or .rpm and you're free to use them that way. But this fly in the face of ease of administration and easy maintenance. It's OK for personal machine, but it simply isn't acceptable for any professional setup.
Sandman 16y ago
So? There is already a lot of software for which Canonical, for example, explicitly states that they do not provide updates. The software is then updated either directly by user or in the next OS release.

by wazoox 16y ago

wmf 16y ago

Honestly, I don't even want to get apps from distros at all; I'd prefer to get tested binaries directly from upstream, but all the disagreement over package formats and such makes that nearly impossible. I feel like distros have painted themselves into a corner with their rigid policies and now they're complaining about it.

nkassis 16y ago
But then the tested binaries + libraries is a big directory which doesn't respect any of the unices way of organizing files. I don't see how this makes it any more convenient on the users than downloading it from upstream makes it. I compare this to things like installing nginx on ubuntu which comes with files in the places I expect (/etc instead of the configure script default of /usr/local/conf) etc. Packages are actually very convenient for 90% of what I user on my computer. Ruby and Clojure stuff are the only thing I download and install myself.
- FooBarWidget 16y ago
  Why does it matter whether it respects the way Unix organizes files? Other than having config files in /etc and having binaries in $PATH, who cares whether libfoo.so is in /usr/lib or in /usr/myawesomeapp.com/vendor/libraries?
  - theBobMcCormick 16y ago
    Very true. The traditional Unix way of organizing files makes sense in a command line world, and I'd expect that sed, awk, grep and friends will continue to live in directories like /usr/bin. But for GUI desktop apps, there's really no good reason each app can't live in it's own directory.
    - rbanffy 16y ago
      Except that then you would have to do some contortions in order to use it or its parts from a command line or a script.
  - sqrt17 16y ago
    Most commonly, it would be in /opt/awesomeapp/lib (and the binaries in /opt/awesomeapp/bin) See http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA... That's, more or less, what /opt is supposed to be. QT and KDE used to be "integrated" that way, until distros finally got around to put them into /usr. So, there really is a standardize mechanisms with those uncommunicative packages in the FHS. (Note that the Unix family as a whole does not standardize filesystem layout, even though Solaris also has /opt and uses it for exotic packages such as GNU gcc).
- blasdel 16y ago
  > Ruby and Clojure stuff are the only thing I download and install myself. And why do you do this? Because the Debian/Ubuntu packages for these things are old and broken, primarily because they are insistent on breaking up the packages and scattering the files all over the FHS they worship. They despise RubyGems because it installs packages in a self-contained way and lets you install multiple versions of everything without mangling the names. It puts them out of a job.
  - rbanffy 16y ago
    > They despise RubyGems because it installs packages in a self-contained way A way that conflicts with the software management Linux distros use. You can't issue a command and have your system updated and, at the same time, your Ruby environment updated. Introducing some new gem can crash system software written in Ruby and make it impossible for the system management tools to rely on the same interpreter you do. If you want to install your gems, something like Python's virtualenv is recommended. I don't know if Ruby has one. If I relied on Ruby, I would make sure it had, even if it meant writing C.
  - regularfry 16y ago
    Except it doesn't, because nobody (that I've ever heard of) backports security fixes to old gem versions.
theBobMcCormick 16y ago
I agree. I'd much rather be able to go out to, as an example, mozilla.com and download the latest firefox in an easy to run installer (like I can do on Windows), than have to upgrade my entire fricking OS just to get the latest Firefox. Again, just using Firefox as an example. The same applies to most end user apps, stuff like Java and Flash, etc.
- kree10 16y ago
  In the case of Firefox, I don't even want an installer. I like the OS X install process for Firefox (and many other apps): copy Firefox.app to /Applications. That's it.
  - GeneralMaximus 16y ago
    As much as I love application bundles, I'd like to point out that this method of distribution leads to code duplication. For example, almost every popular OS X application ships its own version of Sparkle and Growl (to verify this yourself, cd into the app bundle and go to Contents/Frameworks).
    - theBobMcCormick 16y ago
      Does it matter? Disk space and ram are both cheap and plentiful. The difference in disk space or ram taken by apps on an average OSX desktop, and average Windows desktop, and an average Linux desktop seems to be negligible.
      - devdas 16y ago
        It matters when there's a security bug which needs patching in an underlying library. With shared libraries, only one library needs updating. With each package proving it's entire ecosystem, every package on your system needs such updates.
        coffeeaddicted 16y ago
mjschultz 16y ago
I'm want to agree with you, but I have a question. Binaries tested against what? Obviously the testsuite that upstream uses, but every program will have dynamic dependencies into the distro. In that case wouldn't the upstream maintainers have to test every version or every distro to make sure it works for you? That seems time intensive (not infeasible, but it would become chaotic very quickly when we multiply the number of distros by the number of apps people want). I'd also presume that the upstream maintainers include their testsuite with their source, so nothing should prevent the downstream distro maintainers from running the testsuite before shipping (I have always assumed they do, I hope I'm not wrong).
- wmf 16y ago
  If there hadn't been multiple divergent distros in the first place, upstream developers wouldn't be faced with the prospect of a huge testing effort. The result seems to be that we're locked into a model of getting all software from the distros, but they don't necessarily have the resources to do a good job of packaging everything. If you're willing to take some abuse you can release server software only on RHEL/SLES and desktop apps only on Ubuntu and tell everyone else to fend for themselves.
  - sophacles 16y ago
    And further, there should have only ever been one webserver, one database, one KV store, one programming language and one CPU architecture right? The crappy webapp you work on, which is described as "like $x but better" probably shouldn't be in existence at all, because we already have $x.
Goladus 16y ago
For my own personal servers and workstations, yeah either way works pretty well. But when you have several hundred servers with a variety of different applications, many of which you don't use at all but you still need to keep patched and up to date, having a distribution helps a lot. I curse the guys at CSW all the time (eg up and changing config directories from /opt/csw/etc to /etc/opt/csw[1]) but they have probably saved me quite a bit of work testing and building packages. [1]For the record, I think /etc/opt/csw is better, just not better enough to be worth all the hassle of changing.
wazoox 16y ago
What disagreement? There are two package formats in large use, rpm and deb. Many software are distributed upstream as .deb or .rpm and you're free to use them that way. But this fly in the face of ease of administration and easy maintenance. It's OK for personal machine, but it simply isn't acceptable for any professional setup.

Sandman 16y ago

So? There is already a lot of software for which Canonical, for example, explicitly states that they do not provide updates. The software is then updated either directly by user or in the next OS release.