While I sympathise with some of the complaints the developer has, the idea that every software component should live as an isolated stack that duplicates its entire set of dependencies is misguided.
OS administrators want a maintainable, supportable system that minimises the number of security vulnerabilities they're exposed to and packages software in a consistent fashion. They also want deterministic, repeatable results across systems when performing installations or updates.
Likewise, keeping various components from loading multiple copies of the same libraries in memory saves memory, which helps the overall performance of the system.
Also, statements like this aren't particularly helpful and are factually inaccurate:
So package maintainers, I know you have your particular
package manager’s bible codified in 1992 by some grand
old hacker beard, and that’s cool. However, that was
twenty years ago, software has changed, hardware has
changed and maybe it is time to think about these choices
again. At least grant us, the developers of the software,
the benefit of the doubt. We know how our software works
and how it should be packaged. Honest.
Some packaging systems are actually fairly new (< 10 years old), and the rules determined for packaging software with that system have actually been determined in the last five years, not twenty years ago as the author claims. Nor are the people working on them grand, old, bearded hackers.
OS designers are tasked with providing administrators and the users of the administrated systems with an integrated stack of components tailored and optimised for that OS platform. So developers, by definition, are generally not the ones that know how to best package their software for a given platform.
As for documentation not being installed by default? Many people would be surprised at how many administrators care a great deal about not having to install the documentation, header files, or unused locale support on their systems.
Every software project has its own view of how its software should be packaged, and while many OS vendors try to respect that, consistency is key to supportability and satisfaction for administrators.
So, in summary:
* preventing shipping duplicate versions of dependencies
can significantly reduce:
- maintenance costs (packaging isn't free)
- support provision costs (think technical support)
- potential exposure to security vulnerabilities
- disk space usage (which does actually matter on
high multi-tenancy systems)
- downtime (less to download and install during updates
means system is up and running faster)
- potential memory usage (important for multi-tenancy
environments or virtualised systems)
* administrators expect software to be packaged
consistently regardless of the component being packaged
* some distributors make packaging choices due to lack of
functionality in their packaging system (e.g. -dev and
-doc packaging splits)
* administrators actually really care about having unused
components on their systems, whether that's header files,
documentation, or locales
* in high multi-tenancy environments (think virtualisation),
a 100MB of documentation doesn't sound like much, until
you realise that 10 tenants mean 10 copies of docs which
is a wasted gigabyte; then consider thousands of
virtualised hosts on the same system and now it's suddenly
a bit more important
* stability and compatibility guarantees may require
certain choices that developer may not agree with
* supportability requirements may cause differences in
build choices developers do not agree with (e.g.
compiling with -fno-omit-frame-pointer to guarantee
useful core files at minor cost in perf. for 32-bit)
I'd like to see the author post a more reasoned blog entry with specific technical concerns that are actually addressable.
"the idea that every software component should live as an isolated stack that duplicates its entire set of dependencies is misguided"
That's not what he said. He said that packagers frequently break his software for users by incorrectly breaking it up into the wrong pieces and then including a version of that piece that doesn't work. It's especially bad in the case of erlang applications as he enumerates and it's caused by packagers not taking the time to understand the consequences of where they split the software into packages, all in the name having only one version of lib-erl-foo installed on your system.
If the developer didn't make it clear the they had essentially forked Erlang or what the component's requirements are, the blame lies with them, not the packager.
If the developer did, then they need to reconsider how difficult their making the lives of their customers by forcing the potential for additional vulnerability exposures on the system.
> OS administrators want a maintainable, supportable system that minimises the number of security vulnerabilities they're exposed to and packages software in a consistent fashion.
I am the administrator of the machines I use. I am also the user of the machines I use. I care far, far more about my experience as a user than I do as an administrator. The less administrating I have to do the better. As the administrator of my array of personal computers what I want is for everything to work, and to stay working, and for new things never, ever, under any circumstances to break old things.
As a user of the machines I use, I value consistency. I don't want to have to hunt down documentation in weird and wonderful places, I want to go to one spot and have it there.
OS administrators want a maintainable, supportable system that minimises the number of security vulnerabilities they're exposed to and packages software in a consistent fashion. They also want deterministic, repeatable results across systems when performing installations or updates.
Likewise, keeping various components from loading multiple copies of the same libraries in memory saves memory, which helps the overall performance of the system.
Also, statements like this aren't particularly helpful and are factually inaccurate:
Some packaging systems are actually fairly new (< 10 years old), and the rules determined for packaging software with that system have actually been determined in the last five years, not twenty years ago as the author claims. Nor are the people working on them grand, old, bearded hackers.OS designers are tasked with providing administrators and the users of the administrated systems with an integrated stack of components tailored and optimised for that OS platform. So developers, by definition, are generally not the ones that know how to best package their software for a given platform.
As for documentation not being installed by default? Many people would be surprised at how many administrators care a great deal about not having to install the documentation, header files, or unused locale support on their systems.
Every software project has its own view of how its software should be packaged, and while many OS vendors try to respect that, consistency is key to supportability and satisfaction for administrators.
So, in summary:
* preventing shipping duplicate versions of dependencies can significantly reduce:
- maintenance costs (packaging isn't free)
- support provision costs (think technical support)
- potential exposure to security vulnerabilities
- disk space usage (which does actually matter on high multi-tenancy systems)
- downtime (less to download and install during updates means system is up and running faster)
- potential memory usage (important for multi-tenancy environments or virtualised systems)
* administrators expect software to be packaged consistently regardless of the component being packaged
* some distributors make packaging choices due to lack of functionality in their packaging system (e.g. -dev and -doc packaging splits)
* administrators actually really care about having unused components on their systems, whether that's header files, documentation, or locales
* in high multi-tenancy environments (think virtualisation), a 100MB of documentation doesn't sound like much, until you realise that 10 tenants mean 10 copies of docs which is a wasted gigabyte; then consider thousands of virtualised hosts on the same system and now it's suddenly a bit more important
* stability and compatibility guarantees may require certain choices that developer may not agree with
* supportability requirements may cause differences in build choices developers do not agree with (e.g. compiling with -fno-omit-frame-pointer to guarantee useful core files at minor cost in perf. for 32-bit)
I'd like to see the author post a more reasoned blog entry with specific technical concerns that are actually addressable.