| |||||||||||||
Re-deprecating sysctl()Re-deprecating sysctl()Posted Aug 30, 2007 14:25 UTC (Thu) by mrshiny (subscriber, #4266)In reply to: Re-deprecating sysctl() by jengelh Parent article: Re-deprecating sysctl()
I would disagree. Having worked in a computer sales/support/repair role, I can say that many times I had a headache of trying to make an old application run on a new platform. Usually there was no chance of upgrading the application because of a variety of reasons, including budgetary or regulatory reasons. Sometimes the vendor still supported the application but didn't support it on a modern OS or hardware.
For one example: many DOS programs were bitten by a bug where they crashed when run on a Pentium III with a 100Mhz bus. This was caused by some flaw in the time logic in some standard library (a Pascal library of some sort, IIRC). There was actually a program floating around on the internet that could patch these programs and make them work properly, but in many cases the vendors themselves did not have a solution for the clients.
Anyway, my point is that hardware failure can necessitate hardware upgrades which can necessitate OS upgrades which can lead to sysctl() not being present if you're upgrading Linux. I don't think it's an unlikely scenario.
(Log in to post comments)
Re-deprecating sysctl() Posted Aug 30, 2007 14:47 UTC (Thu) by jengelh (subscriber, #33263) [Link] That is a standpoint I can accept. But then again, vendors don't have their software certified or (officially) tested for this new kernel _at all_ (example: VMware). When you call their hotline, they will just tell you that. And then you are stuck - either buy hardware that runs on the usual kernel, or do anything to get the old software to run on a new kernel, possibly modifying the application in ways that invalidate the service contracts. And this is the point I really was aiming at. When enough people get into that awkward situation and request support for newer kernels, the vendor will (if we look at this on a purely mathematical and logical basis...) revalidate their software for newer kernels (...otherwise the customers will be running away). The sooner the better.
Bet what will happen. I bet that if sysctl() is going away in September 2010, then the earliest userspace software upgrade wrt. sysctl() we will see will be after {date of next non-rc release after sysctl removal}. What I believe is that even though we shout "sysctl() is going away in 3 years!", noone will be listening until it actually happened. And when it is about to go away, one side of the kernel developer group ("Janitors") will try to remove it while the other side ("Home") whines about retaining it.
Just look at the RAW character device driver. There have been futile attempts at other things too.
Re-deprecating sysctl() Posted Aug 31, 2007 1:29 UTC (Fri) by mrshiny (subscriber, #4266) [Link] Well, don't get me wrong, I think a certain amount of backwards compatibility can be sacrificed in the name of progress, especially if (as is believed) nobody is actually using the sysctl interface anyway. Anyway it may be possible to write a patch for certain programs if those programs can't be modified; basically a stripped down sysctl could be made to emulate the behaviour of an unfixable app. But I can pretty much guarantee that SOMEONE will suffer due to the loss of this function. Some app somewhere that can't or won't be fixed will stop working and some business will lose money while a solution is investigated.
Re-deprecating sysctl() Posted Aug 31, 2007 8:03 UTC (Fri) by jengelh (subscriber, #33263) [Link] Constructive destruction ;-)
Re-deprecating sysctl() Posted Sep 1, 2007 0:38 UTC (Sat) by landley (guest, #6789) [Link] > Anyway, my point is that hardware failure can necessitate hardware> upgrades which can necessitate OS upgrades which can lead to sysctl() > not being present if you're upgrading Linux. I don't think it's an > unlikely scenario.
And if the hardware that failed was at least 3 years old you can run the
Re-deprecating sysctl() Posted Sep 1, 2007 12:55 UTC (Sat) by mrshiny (subscriber, #4266) [Link] As long as you don't require custom hardware that isn't accessible to qemu.
|
|||||||||||||