Recent Features
| |||||||||||||
On the value of static tracepointsOn the value of static tracepointsPosted Apr 28, 2009 20:23 UTC (Tue) by NAR (subscriber, #1313)In reply to: On the value of static tracepoints by bronson 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.
(Log in to post comments)
On the value of static tracepoints Posted Apr 29, 2009 9:54 UTC (Wed) by flewellyn (subscriber, #5047) [Link] 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. That's what the stable tree is for. The 2.6.x.y ones. You do know about those, yes?
On the value of static tracepoints Posted Apr 29, 2009 10:01 UTC (Wed) by NAR (subscriber, #1313) [Link]
And a 2.6.29.1 stable release would help in what way on a 2.6.16 kernel? Because running the same kernel for two years *is* stability, changing kernels every 6 months is not.
On the value of static tracepoints Posted Apr 29, 2009 10:21 UTC (Wed) by hppnq (guest, #14462) [Link] Obviously one would get the latest release for the kernel you are running. If that doesn't exist, maybe "stable" has become "obsolete". Arguing that "changing kernels" every six months is necessary is nonsense, even disregarding the fact that it has little or nothing to do with stability in the first place.If it has, you are doing something wrong.
On the value of static tracepoints Posted Apr 29, 2009 10:22 UTC (Wed) by abacus (guest, #49001) [Link]
If you can't live with fast changes, stick to an enterprise distro. These distro's even offer a stable binary kernel API.
On the value of static tracepoints Posted Apr 29, 2009 16:12 UTC (Wed) by nye (guest, #51576) [Link]
2.6.16 *was* maintained for over two years (and is no doubt still maintained by distributions even if the mainline support has been dropped). It's now been replaced by 2.6.27.x as the stable line. There's rather more than 6 months between 16 and 27, but if you really want long-term maintainence then you could always use 2.4.37.1.
On the value of static tracepoints Posted May 6, 2009 21:13 UTC (Wed) by roelofs (guest, #2599) [Link] ... but if you really want long-term maintainence then you could always use 2.4.37.1.Not if you want a working ntpd. Greg
|
|||||||||||||