Tuesday, 28 February 2012

dtrace4linux - support and issues

I would like to thank the audience of people using and
trying out the DTrace/Linux port (now hosted at github and
my other tarball downloads).

Can I ask people - when facing compile issues - to ensure they
have all prerequisites before reporting compilation issues.

It is my goal to have DTrace work on all releases of
Linux - both forward and backward releases, but time and space
doesnt permit validating each release (of Linux) - especially
older ones. I do attempt to look at Ubuntu and Fedora (usually after
a prod by the community). I try to avoid downloading the latest
Ubuntu releases until at least a week or two has passed, so that
I can feel more comfortable I am not going to suffer resume+suspend or
wifi or video glitches, like I have done in the past.

One thing I have done brazenly and badly, is keep track of what I
installed on my system in terms of packages. When I first started
DTrace, it was not a virgin Linux distro, but one polluted with my
favorite development packages.

By the time the first DTrace port went out, I couldnt tell the
difference between a virgin install and my own system. Over time, I have
realised this is important for newcomers who download and try out
DTrace, that it works "out of the box", and have attempted to create
scripts (get-deps.pl) to semi-automate updating your system with the
required packages. Even for Fedora and Ubuntu, and 32 and 64 bit variants,
validating that the script works is nearly impossible.

I hope to do better in the future, but there can be no guarantee.

One of the commonest issues reported is missing header files, e.g.
for 32-bit compiles. Even doing a package search using yum or apt-get
or whatever the package installer of choice is called, is a nuisance - as
you get flooded with possible matching libraries. Most of it makes sense
to me, but it likely confuses newcomers to Linux, or people who
are not programmers. Unfortunately, that is life on Linux.

(Maybe I should be adopting a standard RPM format so that the
dependencies can be described properly; something for a different
rainy day).

At the moment, for a short while, I am switching my focus back
to CRiSP - adding features and enhancements; I find it good to switch
back and forth from DTrace to CRiSP, as I sometimes lose focus on
what I am trying to do. DTrace for Linux should be in a good state, and
there are a lot of miniprojects to work on (I had started on the CPC
provider, and theres more SDT probes to work through, along with
refinements on the INSTR provider).

If people find DTrace good for them, feel free to publicise or drop
me a mail, so that I know it is worthwhile.

Post created by CRiSP v10.0.26a-b6206

No comments:

Post a Comment