News for hackers. Stuff that matters.
Re:Internet Draft: Let 'localhost' be localhost by kbutler on Monday August 07, 2017 @05:50PM (#14951565)
Does it matter if it's a bug in the client?

Make it work like expected.

Especially when changing infrastructure like IPV4->IPV6 - don't break existing userbase code! (This is a fundamental precept of Linux development.)

Re:Internet Draft: Let 'localhost' be localhost by frubar on Tuesday August 08, 2017 @08:45AM (#14957205)
Only in software development are we expected to go out of our way to support people who don't know what they're doing. Imagine a medical student complaining the professor that the scalpel doesn't cut on the dull end or a would-be airline pilot upside down in their seat complaining he can't reach the controls.

And your comment about never breaking existing userbase code is as ridiculous as it is unreasonable. This would only be a reasonable expectation if only correct code were possible to run. Since it's possible to run broken code (as this anecdote demonstrates) then it must be possible to fix the system even if that breaks some poorly written, but popular systems.

Does anyone want a world of e.g. Windows where decades old bugs have to be replicated because we can't dare break programs so old all the authors are retired or dead? I don't. Backwards compatibility has a cost and I'm not willing to pay it unconditionally.

Re:Internet Draft: Let 'localhost' be localhost by silotis on Monday August 07, 2017 @06:34PM (#14951841)
There's only so much the kernel can do to protect userspace from itself. When you have an interface which returns an explicitly extensible data structure, you have to assume userspace is going to at least ignore extended data it does not understand. Otherwise you cannot have such interfaces at all.
Re:Internet Draft: Let 'localhost' be localhost by pas on Tuesday August 08, 2017 @07:39AM (#14956735)
> Make it work like expected.

Expected by code or by the progammer(s)?

That said, strong API guarantees are the way, documentation should note the bug, introduce a fixed version for the API, maybe schedule deprecation in 10-15 years, and carry on with life.

It's not worth it to hunt down every client and make them fix your honest mistake.