Re: [Ksummit-2008-discuss] DTrace

On Fri, 2008-07-04 at 15:44 -0700, Karen Shaeffer wrote:
> On Fri, Jul 04, 2008 at 01:00:55PM -0700, Karen Shaeffer wrote:
> > Hi,
> > I strongly agree with Roland here. And I'll go even further. I do not
> > think it is optimal to leave this critical, competitive capability in
> > the hands of any particular distributions, be it Red Hat or Debian. The
> > core, at the very least needs to be in the kernel tree, as Roland urges,
> > and distribution independent to be most useful and effective. There are
> > so many folks out there not using mainstream distributions, and this
> > capability, at least the core, is central to their needs as well. An
> > example is all the Venture backed appliance based tech firms in
> > Silicon Valley. Almost none of them use the distributions. And they
> > need this capability as well.
> 
> As a followup, I just joined the systemtap email list. And the second
> email I received is talking about designing in dependencies based on
> RPM and build id metadata. This is exactly my point. Most Linux based
> appliances are not using RPM. I fully recognize and even support Red
> Hat's right to design a system that is closed to their distributions,
> but I don't think the kernel community should be supporting that at
> the exclusion of folks who are not using Red Hat distributions. Or
> Debian distributions either. And this is why the core implementation
> is optimally distribution independent and in the kernel tree. And then
> let end user groups build on top of that to suit their special needs.

Isn't this rather like blaming a lion for hunting on the Savannah?

RHEL is the most commonly deployed distribution among the type of end
user who is crying out for DTrace like features.  They pay cash to Red
Hat to develop them and Red Hat throws engineers at the problem (the
problem, by the way, is the customers wanting DTrace functionality on
the Red Hat enterprise distributions) ... so far this is a classic old
world development model.  Fortunately, true to its open source
principles Red Hat has at least published the code, the bugzilla and the
mailing list.

The problem is that SystemTap hasn't really benefited from community
based innovation largely because it doesn't have much of a community.
The bigger picture problem Red Hat didn't see when they accepted the
cash was that this project wouldn't generate a community just from the
usual publish the code and they will come philosophy.  The result is
what we see to day: a klunky and accident probe tool that has sun
engineers writing trite little homilies on the benefits of a planned
political operating system.

There are a huge number of members of this class of problem:  Features
which users want but which developers aren't really interested in (and
hence the usualy open source model of scratch your own itch breaks
down).   Systemtap is slightly different because it isn't fully a member
of the class: it can me made useful to developers, it just has to be
easy and reliable before they find it easier to use than a simple printk
in the code.

The rising challenge it to find a way of bringing open source methods to
bear on this class of problem.  What SystemTap seems to have
demonstrated nicely is that simply paying a third party to solve your
problem doesn't really work largely because the tight feedback loop
between the producer and the consumer that drives open source innovation
is broken.  The project moves identically to an old style closed source
development one largely because even though the code is open source, the
consumers don't care; they take regular drops of product and provide
feedback for the next release (which moves at an enterprise cycle).

James


_______________________________________________
Ksummit-2008-discuss mailing list
Ksummit-2008-discuss@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/ksumm...