On the value of static tracepoints
Posted Apr 28, 2009 20:23 UTC (Tue) by NAR
In reply to: On the value of static tracepoints
Parent article: On the value of static tracepoints
Presumably DTrace has solved a lot of these concerns. What decisions did they make?
I guess they are not releasing a new kernel every 3 months... I think this "new release every 3 months" schedule with the "no stable ABI" policy just doesn't work well with "enterprise". I mean an application developer or system administrator might spend a considerable time to get to know these tracepoints, but if they change with every release, then the users won't be happy. And it's not just tracepoints, but tuning parameters under /proc or /sys, configuration parameters, etc. Even filesystems can start to work differently with each new kernel version (see the ext3 issues). I would hate to develop for such a moving target (it's quite enough to follow the customer's requests).
On the other hand people are forced to upgrade to get the security fixes, so they can't afford to stay with the stable well-known solution. I know that this is the market for the enterprise distributions, but it also means that the kernels of the (enterprise) distributions are diverging from the mainline kernel, even though the new kernel development methodology supposed to prevent this.
Mark Shuttleworth had this idea some time ago that the distributions (or applications) should sync their releases. It might be useful if let's say RHEL, SLE[SD], Ubuntu LTS (and maybe Debian stable) would be released around the same time, would get the same kernel and the same tracepoints, tuning parameters, etc. This could be labelled as a .0 release. This way the enterprise distrubitions could also backport the same security fixes from the later kernel versions.
to post comments)