On 10/03/2014 03:50 PM, jcbollinger wrote:
I feel compelled to point out that if the faster language happens to
be C++, then you will *need* a plug-in interface in some different
language (presumably Ruby, but straight C would be more typical). C++
APIs are sensitive to compiler and compile
On Thursday, September 25, 2014 3:33:00 PM UTC-5, Andy Parker wrote:
The language will remain in ruby for a while yet (the puppet-server uses
JRuby to run the puppet ruby code), and even after the interpreter gets
reimplemented in a faster language, ruby will be available for extensions.
On Wednesday, October 1, 2014 9:34:25 AM UTC-5, Felix.Frank wrote:
On 10/01/2014 03:35 PM, Jeffrey Watts wrote:
On Wed, Oct 1, 2014 at 8:13 AM, jcbollinger john.bo...@stjude.org
javascript: wrote:
As for a link, the C++ Frequently Questioned Answers
http://yosefk.com/c++fqa/ helped
On Tuesday, September 30, 2014 8:29:42 AM UTC-5, Felix.Frank wrote:
On 09/29/2014 05:19 AM, Kylo Ginsberg wrote:
I'm good with JVM, but C++ feels like a backward step in many regards.
My judgment here may be clouded by reading too many blogpost of them
naysayers.
C++ should be
On Wed, Oct 1, 2014 at 8:13 AM, jcbollinger john.bollin...@stjude.org
wrote:
I'm fine with C (which I use a lot), and I love Java, JVM and all. I'm
satisfied with a wide variety of scripting languages. Although it's not
chic, I even like Fortran for certain uses. But I hate C++.
As for a
On 10/01/2014 03:35 PM, Jeffrey Watts wrote:
On Wed, Oct 1, 2014 at 8:13 AM, jcbollinger john.bollin...@stjude.org
mailto:john.bollin...@stjude.org wrote:
As for a link, the C++ Frequently Questioned Answers
http://yosefk.com/c++fqa/ helped me crystallize some of my
previously less-focused
On 09/29/2014 05:19 AM, Kylo Ginsberg wrote:
I'm good with JVM, but C++ feels like a backward step in many
regards. My judgment here may be clouded by reading too many
blogpost of them naysayers.
C++ should be a forward step from a performance/footprint perspective.
I'm
More information along these lines, highlighting ease of use and
tools for users to see their catalogs, will go along way towards soothing us
touchy sysadmins.
Totally understand, I was a very touchy admin myself before working at
Puppet Labs and when the tools let you down it can be
And further, I'd really like to see non-Ruby scripting languages enabled to
participate as first-class citizens for the extension points - this (coupled
with better definition of core APIs) would really make the on-ramp for new
puppet users much lower friction.
Python support would be lovely.
On 9/29/14 2:09 AM, Ken Barber wrote:
The information around tuning Passenger/Puppet explicitly provided
by Puppet Labs was mostly crap.
Indeed, it was a bit of a black art because of this. It wasn't until
later that Passenger even added the ability to reasonably introspect
what was
Just to add on things that I'd like to see:
Tuning
- When it's not CPU, it's RAM. What to do when you have massive catalogs
(maybe not an issue?).
Operating
- Proper log rotation and maintenance
Security
- What do I need to let through?
- What do I need to lock down?
- How do I easily split off
More information along these lines, highlighting ease of use and tools
for users to see their catalogs, will go along way towards soothing us
touchy sysadmins. The performance gains while nice don't have the appeal
of better troubleshooting. I'm happy to learn yet another stack, but I'd
like
On Fri, Sep 26, 2014 at 4:42 PM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
On 09/26/2014 11:12 PM, Rob Reynolds wrote:
Felix, if your what? is about Java (the language), that was a
mistake. JVM on the server side, generally written in Clojure, is the
direction things are
FWIW,
(1) at my current shop, there's an immense hatred of everything JVM. That's
going to be a hard transition. Not to mention Puppet is the only place we
run Ruby, so it's nice and easy to let puppet do whatever it wants with
Ruby. Not so much for installing JVMs that may break production
(1) at my current shop, there's an immense hatred of everything JVM. That's
going to be a hard transition. Not to mention Puppet is the only place we
run Ruby, so it's nice and easy to let puppet do whatever it wants with Ruby.
Not so much for installing JVMs that may break production
On Fri, Sep 26, 2014 at 7:56 AM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:
+1 for a Native Code drop in. That would make me crazy happy actually.
-1 for sticking Java everywhere. That would make some of my users hate me
with passion.
Java just on server side. Native is moving towards
Works for me.
On Fri, Sep 26, 2014 at 3:45 PM, Rob Reynolds r...@puppetlabs.com wrote:
On Fri, Sep 26, 2014 at 7:56 AM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:
+1 for a Native Code drop in. That would make me crazy happy actually.
-1 for sticking Java everywhere. That would make
On 09/26/2014 09:45 PM, Rob Reynolds wrote:
Java just on server side. Native is moving towards C++.
No wait, what, really?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send
On Fri, Sep 26, 2014 at 1:30 PM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
On 09/26/2014 09:45 PM, Rob Reynolds wrote:
Java just on server side. Native is moving towards C++.
No wait, what, really?
Felix, if your what? is about Java (the language), that was a mistake.
JVM on
On Fri, Sep 26, 2014 at 4:02 PM, Andy Parker a...@puppetlabs.com wrote:
On Fri, Sep 26, 2014 at 1:30 PM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
On 09/26/2014 09:45 PM, Rob Reynolds wrote:
Java just on server side. Native is moving towards C++.
No wait, what, really?
On 09/26/2014 11:12 PM, Rob Reynolds wrote:
Felix, if your what? is about Java (the language), that was a
mistake. JVM on the server side, generally written in Clojure, is
the direction things are heading. C++ on the client side. Ruby is
still sticking around in order to
I got to test it in one of my dev environments while I was at
Puppetconf and it was pretty awesome.
Looking forward to having the time to add it as an option to my puppet
management module.
I am intending on running it in my dev environment to help out with testing.
On 23 September 2014 13:30,
On Tue, Sep 23, 2014 at 1:30 PM, Matt Zagrabelny mzagr...@d.umn.edu wrote:
On Tue, Sep 23, 2014 at 2:03 PM, Gabriel Filion gabs...@lelutin.ca
wrote:
On 23/09/14 12:11 PM, Nate Wolfe wrote:
We are thrilled to announce the preview release of Puppet Server, our
newest open source project.
On Thu, Sep 25, 2014 at 1:32 PM, Andy Parker a...@puppetlabs.com wrote:
Puppet apply will be sticking around. The exact way in which it will
work isn't completely clear yet. There are several possibilities from
requiring the jvm on all nodes that run puppet apply to changing apply to
use a
We are thrilled to announce the preview release of Puppet Server, our
newest open source project.
Puppet Server is a next-generation alternative to our current Puppet
master, which builds on the
successful Clojure technology stack underlying projects like PuppetDB.
Packages are available in the
On 23/09/14 12:11 PM, Nate Wolfe wrote:
We are thrilled to announce the preview release of Puppet Server, our
newest open source project.
Puppet Server is a next-generation alternative to our current Puppet
master, which builds on the
successful Clojure technology stack underlying projects
On Tue, Sep 23, 2014 at 2:03 PM, Gabriel Filion gabs...@lelutin.ca wrote:
On 23/09/14 12:11 PM, Nate Wolfe wrote:
We are thrilled to announce the preview release of Puppet Server, our
newest open source project.
Puppet Server is a next-generation alternative to our current Puppet
master,
Hi Gabriel,
From the recent PuppetConf talk on Puppet Server, the goal appears to be to
move this way. However, many things need to be worked out. Not the least of
which is how 'puppet apply' and msterless is going to work.
The speed improvements and smaller resource usage appear quite
28 matches
Mail list logo
