IIRC at least some of the motivation behind the current split had to do
with separating out modules which aren't generally platform agnostic
since platform specific stuff sometimes causes problems with downstream
linux distro adoption/packaging. I.E. the official python modules
should be
On 01/15/2014 06:42 AM, Jesse Becker wrote:
On Wed, Jan 15, 2014 at 8:41 AM, Nicholas Satterly nfsatte...@gmail.com
wrote:
If we are to look at redoing the XML parsing next then the two contenders
that come to mind are gzipped JSON and Google Protocol Buffers.
PB is meant to be very
Thanks for the suggestion, but dmidecode is not portable and is super
unreliable since it depends on upstream hardware vendors setting
reasonable values. Even running on a sample of 8-10 models of
motherboards all from the same vendor I get vastly different results
from dmidecode. I'd strongly
either
(TO BE ENTERED BY O.E.M) but I could see something like UUID on
startup and 'custom bits on the motherboard' as reasonable -- if not
common -- use cases.
On 08/01/2013 12:20 PM, Dave Rawks wrote:
Thanks for the suggestion, but dmidecode is not portable and is super
unreliable since
for the different supported
platforms.
Peter
-Dave
On Aug 1, 2013, at 9:20 AM, Dave Rawks d...@pandora.com
mailto:d...@pandora.com wrote:
Thanks for the suggestion, but dmidecode is not portable and is super
unreliable since it depends on upstream hardware vendors setting
reasonable values
On 07/30/2013 05:53 AM, Chris Burroughs wrote:
On 07/30/2013 02:45 AM, Nicholas Satterly wrote:
Could you expand on what you mean by multi-tenancy, please? I'm curious.
There is currently no application or other namespacing. If I have a
bunch of java apps on the same box and they are all
wrote:
I am not necessarily opposed to it if it's implemented in such a way not
to break backwards compatibility. Someone would need to contribute some
code.
Vladimir
On Fri, 26 Jul 2013, Dave Rawks wrote:
I'm curious to hear what you think is going to be more
I'm curious to hear what you think is going to be more efficient,
platform agnostic and portable than XDR? ASN1 would be the only thing I
would even consider using instead, but it is arguable whether it would
be worth the pain of supporting more than one serialization format and
it certainly
It becomes problematic when the two /debian subdirs diverge and then
you may end up with official debian packages owning a different set of
files or having different install locations than ones built directly
from upstream. Other packages which depend on or work in concert with
packages that
FWIW, the guys at github are eager to assist people with bulk importing
of issues via their json issue format. And they have been trying to
encourage people to write export tools for bugzilla and other
services/software.
I'd be a fan of moving from bugtracker to github just for the one-stop
On 04/04/2012 09:51 AM, Daniel Pocock wrote:
On 04/04/12 18:35, Dave Rawks wrote:
Not to speak out of turn, but making the build process dependent on a
very specific version of libtools and autotools seems like a really bad
plan. I've never run into a debian source package before
Am I missing something? I just downloaded the tarball tagged 3.3.4 from
github and attempted to build debian packages from it.
1. The debian changelog is not updated to reflect the version tag.
2. the build dependencies appear to be broken, as the build requires
libtools to be installed
I don't think this is a good patch. .pyc files are not meant to be
portable or stable. If at some later date we are meant to troubleshoot a
problem with a module that is loaded as byte compiled python it becomes
very difficult to gurantee that the bytecode is sane since the actual
code is not
On 1/27/12 6:59 AM, Im Root wrote:
I believe that adding json would be a mistake. The reason is that when
users install the main package there would be now a dependency on having
json installed. It just adds to the complexity and helps to perpetuate
RPM hell. I've had to deal with installing
On 1/27/12 7:24 AM, Gladish, Jacob wrote:
If you want access to that metric data in JSON format, the quickest
way, by far, is to write a small conversion utility that fetches data
from the gmetad. I can imagine a perl script running in Apache/CGI
that does it on demand. You'd then have
On 1/27/12 7:43 AM, Alex Dean wrote:
1. As a user, I sometimes want to consume ganglia data in other
contexts (not just in gweb). I'd much prefer working with JSON
instead of XML.
I think that most developers would prefer json to xml, if for no other
reason than json libraries/modules are
On 1/27/12 2:05 PM, Im Root wrote:
I forgot to add that by adding json, you will be restricting the types
of Linux that this platform runs on. Although it may be a nice to have
feature for a few developers who may want to customize things, this puts
an additional dependency on the platform.
Hey All,
We've been talking about adding json in addition to xml for the tcp
listen port exchange format. And I was curious if the EXTRA_DATA
subtree to the XML ever contains something aside from EXTRA_ELEMENTS
and if the EXTRA_ELEMENTS ever have attributes aside from NAME and
VAL.
Just
On 01/26/2012 12:07 PM, Bryan Thompson wrote:
Dave,
There is undoubtably fat in the XML. However, I think that you would get far
more savings by giving the client a means to request which data they are
interested in. Right now it sends everything each time, right? It would be
nice if
On 01/26/2012 01:16 PM, Jeff Buchbinder wrote:
On Thu, Jan 26, 2012 at 4:09 PM, Bryan Thompson br...@systap.com wrote:
Dave,
I thought that the web UI was driven this way. Or is it gmond providing the
XML output for the web UI (rather than gmetad)?
The web UI is driven that way, but
On 01/26/2012 02:02 PM, Bryan Thompson wrote:
Ok.
Not sure if this matters to your proposal, but GROUP is not always a
single name/value pair. There can be multiple GROUPs for a metadata
record.
If there is more than one value for GROUP it could be an array instead
of a string, That'd bump
21 matches
Mail list logo
