Fixing broken userspace is NOT the kernel's job
Posted May 4, 2012 17:44 UTC (Fri) by giraffedata
In reply to: Fixing broken userspace is NOT the kernel's job
Parent article: Fixing the unfixable autofs ABI
That's the wrong analogy for this debate. I'm sure you can think of a 100 cases where users got burned by a design decision in a user space program 5 years ago, and a kernel change today could compensate for it, but the consensus is the users should suffer.
Here's a closer analogy: John has 12 steps in his house. He likes to walk down them with his eyes closed and count the steps. Mary invites John over to her house and he resists, saying "I know where everything is in my house and I'm afraid I would get lost in your house." Mary assures him that her house is just like his in every relevant detail, and on that basis John accepts. But Mary has 13 steps and John, walking down with his eyes closed and counting to 12, falls and breaks his arm. Should Mary pay for his medical bills?
Did Mary break her promise? Is having one more step in the staircase is a relevant detail? Is a person entitled to walk down stairs with his eyes closed?
We typically say you can move a program from a 32 bit computer to a 64 bit one without change because the environment is the same in every relevant detail. We also say you can move a program from kernel release N to N+1 for the same reason. Automount and Systemd users are relying on some interpretation of those promises.
to post comments)