Haunted by ancient history

Posted Jan 9, 2015 23:33 UTC (Fri) by dlang (guest, #313)
In reply to: Haunted by ancient history by moltonel
Parent article: Haunted by ancient history

> if you get within 20% of the ideal value it's good enough.

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.

Haunted by ancient history

Posted Jan 10, 2015 0:52 UTC (Sat) by moltonel (guest, #45207) [Link] (2 responses)

We may disagree on the maths but we agree on the basic observations; I'm not sure what you're trying to add ?

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).

Haunted by ancient history

Posted Jan 10, 2015 2:29 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

As I read Linus' message, he was saying that some value needed to be there, even if it was known to have n relation to reality (because software broke if it wasn't there to read). In your posts it sounded like you were saying that there needed to be an option to provide a "real" value. That's a much more demanding option than just having some value there.

Haunted by ancient history

Posted Jan 11, 2015 22:56 UTC (Sun) by moltonel (guest, #45207) [Link]

If no program depends on a "real" value then great, just return a constant like "1" and be done with it. I find it unlikely that there isn't a program that uses the value in its logic (as opposed to just displaying it), but I admit I don't have an example to provide.