Haunted by ancient history
Haunted by ancient history
Posted Jan 9, 2015 20:20 UTC (Fri) by dlang (guest, #313)In reply to: Haunted by ancient history by moltonel
Parent article: Haunted by ancient history
Posted Jan 9, 2015 22:28 UTC (Fri)
by moltonel (guest, #45207)
[Link] (8 responses)
The point is that some (buggy but kernel-supported) software will use it to calibrate some kind of performance loop. So try to give them a usable value; if you get within 20% of the ideal value it's good enough. Don't go beyond the call of duty trying to give a "good" value to something that is bogus by design.
That said, I think (as a user) that the kernel's no-breakage stance is too strict. If you're willing to keep using old unmaintained software, you should be ok with using old unmaintained kernels that are still compatible with said software. I'd have been happy to see bogomips disappear from Linux immediately. But if you're not willing to do that today, please at least prepare things so that we can do it in a few years.
Posted Jan 9, 2015 23:33 UTC (Fri)
by dlang (guest, #313)
[Link] (3 responses)
you can't get it within 200% of the ideal value, it may not be possible to get it within 2000% of the ideal value. And the ideal value will change from time to time with no notice.
any software the uses delay loops is broken on a multi-user or even multi-application machine, let alone using bogomips to calibrate such loops.
That said, breaking software that's doing the wrong thing still isn't acceptable. Even if the software is maintained, getting the new version into the hands of users can take a LONG time. Rsyslog is very actively maintained and is on v8.6 right now. We still get people asking questions about v3.x, which was out of date in 2006.
Posted Jan 10, 2015 0:52 UTC (Sat)
by moltonel (guest, #45207)
[Link] (2 responses)
Since Linus has decreed that bogomips should be kept, we should keep it in the form that applications expect. We all know that that form is completely broken, but that's irrelevant. Apps ask a stupid question, and Linux gives a stupid answer in the name of retrocompatibility. That's what Linus asked for, and I'm not in a position to disagree.
What I *can* suggest is to take measures today so that in many years the compatibility argument gets weak enough to be ignored. Making bogomips configurable is such a measure, a pretty standard deprecation strategy (even if the time between deprecation and removal is huge).
Posted Jan 10, 2015 2:29 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
Posted Jan 11, 2015 22:56 UTC (Sun)
by moltonel (guest, #45207)
[Link]
Posted Jan 10, 2015 18:01 UTC (Sat)
by nix (subscriber, #2304)
[Link] (3 responses)
It is not possible for an old unmaintained kernel not to contain security holes (for the simple reason that the kernel is one single piece of software and has holes discovered from time to time).
Thus, your proposal would force people to upgrade to the latest and greatest, no matter how much of their workflows it broke. That's not very nice to the users. (This unthinking attitude that "I use a recent version of everything, therefore so can everyone else" is a large part of what's wrong with the modern Linux world IMNSHO).
Posted Jan 11, 2015 23:46 UTC (Sun)
by moltonel (guest, #45207)
[Link] (2 responses)
But there are various degrees of old, unmaintained, and incompatible. And Linux often takes what looks like a hypocritical decision on what to keep and what to remove. Where's the kernel for my devfs distro ? Can I really run this 15-years old XFree86 on 3.18 ? The "if someone notices" rule is both pragmatic and naïve. there are plenty of kernel-broken software out there. Note that the situation is worse with applications and libraries.
Having a zero-tolerance "no backward-compatibility" rule is very noble until you realize that so much stuff is broken anyway.
I'm doing the opposite of forcing people to upgrade to the latest : I'm telling them to keep running that old kernel if they need to. There are plenty of situations where this is fine. Not all security issues affect everybody. I've got plenty of systems I can't afford to update, so I just put them somewhere where they won't be exposed to threats.
And if that fails, virtualisation is easy nowadays. Bogomips can't have a decent value on most modern hardware, so I'd even have to use an emulator to get my old game working properly. Thankfully, the app that require this treatment and are in comon use should be a rarity.
Not breaking compatibility is important. But folling this rule to the extreme is silly.
Posted Jan 12, 2015 3:37 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
different people's estimates of how many are helped by the fix vs hurt by the regression will vary wildly.
you will end up breaking _something_ for people on a regular basis
people remember things that break for them FAR more than they remember new features or speed. You need something way over 10:1 fix:break ratio to begin to have things break even (some people think this is over 100:1)
Linux-kernel development has been there in the past, and it had a reputation for breaking users systems on a regular basis. Avoiding a repeat of this history is why Linus fights so hard against regressions.
I've reported problems with binary-only apps and seen the offending patch reverted within hours. However, if you don't run current upstream kernels, or don't report when things are broken, you can't count on anyone else reporting it either, and so it's possible for the problem to live for a long while. "Enterprise" distros make this worse due to the added lag in getting new kernels out to users, so when a problem is noticed, it make be due to a change that was made upstream years ago. Such problems still need to be reported, and as this case shows, they are taken seriously by Linus and get fixed.
Posted Jan 15, 2015 1:12 UTC (Thu)
by nix (subscriber, #2304)
[Link]
One nice example of a good recent fix for me was a series of helpful responses, suggestions, and finally a quirk addition when my Simtec Entropy Key started spontaneously failing in 3.16, even though 3.17 had been out for some time and 3.18 was fairly close to release. This was a particular monster to track down because it was timing-related, intermittent, only happened after a reboot, and required physical removal of a USB device to fix. I think I rebooted 180-odd times in the process of bisecting, and had two or three wrong bisection paths due to mistaking bad commits for good ones. I couldn't ask anyone else to do this -- Entropy Keys aren't very common -- and it took me some weeks to find the time to do it, but once it was tracked down, a fix was almost immediate, even though Entropy Keys are not exactly the most crucial hardware ever, and I say that even though my firewall won't boot without its nice juicy random numbers. Now that's the right way to fix bugs! So bravo Johan! :)
Haunted by ancient history
Haunted by ancient history
Haunted by ancient history
Haunted by ancient history
Haunted by ancient history
Haunted by ancient history
If you're willing to keep using old unmaintained software, you should be ok with using old unmaintained kernels that are still compatible with said software.
It is quite possible for old unmaintained software not to contain security holes and to work perfectly well. Software does not intrinsically rot.
Haunted by ancient history
Haunted by ancient history
Haunted by ancient history
people remember things that break for them FAR more than they remember new features or speed. You need something way over 10:1 fix:break ratio to begin to have things break even (some people think this is over 100:1)
Exactly! I was just about to follow up and comment on how a recent SCSI breakage of mine was fixed nice and fast -- but then I realised that that 'recent' breakage was in 2013! But it still *felt* recent, because it broke the boot in a scary fashion.