Hi,
The usual argument at this point in the discussion is that AIO packages
of any vendor will - by definition - have worse security support than
the system versions.
People who have to certify/verify/validate/audit all binaries that are
running on a given system will have additional high costs from bundled
components that may render using those packages infeasible.
Adding more binaries to a system will mean that they will require
additional non-dedup-able hardware resources.
Independently of those technical arguments, "freeing puppetlabs from the
ruby hell" will be read by free software proponents(sic!) as
"unwillingness to support the diversity of the free software ecosystem".
See also http://islinuxaboutchoice.com/ and so on. My own opinion is
split between the economical realities of vendors and the fact that
everything outside Debian main (+ backports) is not *Debian*.
Regards, David
On 2014-12-12 21:39, Byron Miller wrote:
I don't see these negatives at all. I think having puppet decoupled is a
good thing - for reliability, management and freeing us from "ruby
hell". I can't see an AIO package altering the native behavior of the
OS or system rubbies either..
Since it is OSS as well, is there a reason you wouldn't be able to pull
down the git repo and update ruby according to your own needs? my
assumption is that its a LOT easier to upgrade puppet ruby if it is
indeed decoupled from system ruby or ruby used by apps on the platform
your trying to manage.
-byron
On Thursday, December 11, 2014 3:53:15 PM UTC-6, John Bollinger wrote:
On Thursday, December 11, 2014 3:34:17 PM UTC-6, John Bollinger wrote:
If I cannot install Puppet into a Ruby installation of my choice
(of sufficiently recent version) and have it work correctly, or
if its installation alters the behavior of other software
relying on that Ruby, then I do not foresee updating until I or
someone else can fix those problems. I am unlikely to be able
to devote any effort to such an endeavor any time soon, so my
adoption of the new version would be forestalled indefinitely.
Similarly, as long as Puppet is unable to share general-purpose
third-party components, such as Ruby modules or a Java runtime, with
other subsystems, I do not anticipate updating.
Although I am disappointed that PL intends to offer only AIO
packages, that decision will be only an inconvenience for me as long
as the software does not inherently /depend/ on AIO structure and
layout. You may make suggestions, but you may not make system
configuration decisions for me.
John
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-dev+unsubscr...@googlegroups.com
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/052267c9-5504-4587-84d5-a2f5442065e5%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-dev/052267c9-5504-4587-84d5-a2f5442065e5%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
* Always looking for people I can help with awesome projects *
Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/548DFC3B.2070604%40dasz.at.
For more options, visit https://groups.google.com/d/optout.
