So (1) nobody cared to improve the old tools, writing new ones is more fun, and (2) updating the old tools to reflect current reality would break old scripts, so the rational choice is to both let the old tool rot (thus quite possibly breaking anything that relies on it) as well as introduce a new tool that definitely isn’t compatible with the old scripts. Why do I feel like this line of arguing has a problem or two?
Pray tell, what happens when the interface provided by the iproute2 utilities no longer reflects reality. Let them rot and write yet another set of new tools? Break them? Introduce subtle lies?
Oh by the way, if you’re configuring IPv6 on linux, don’t use the old tools. They’re subtly broken and can waste you a lot of time. I’ve been there. Don’t mention it.
Meanwhile, I’m glad that OpenBSD’s ifconfig can show more than one IP per interface. And I can use the same tool to set up my wifi too. It’s a tool meant to work.
The BSDs are maintaining the kernel and the base system in locksteps. This is not the case for Linux distributions. Over the years, Linux developers started to do the same. That’s why we now have iproute2, ethtool, iw and perf, which are userland tools evolving at the same speed as the kernel (and sharing the version number).
The people who want to use the old tools want them to keep working the same way they always have. They already work that way, so the people who want to use the old tools have no motivation to make changes.
updating the old tools to reflect current reality would break old scripts
It would also piss off the people who want to keep using the old tools, since by definition they would no longer keep working the same way.
The names ifconfig and netstat are now claimed and cannot be re-used for a different purpose, in much the same way that filenames like COM1 and AUX are claimed on Windows and cannot be re-used.
Meanwhile, I’m glad that OpenBSD’s ifconfig can show more than one IP per interface.
My understanding is that OpenBSD reserves the right to change anything at any time, from user-interface details down to the C ABI. “The people who want to use the old tools” are discouraged from using OpenBSD to begin with, so it’s not surprising that OpenBSD doesn’t have to wrestle with these kinds of problems.
While this is true, I think you are taking it a little too literally. You won’t, for example, upgrade to the latest snapshot and find that ls has been replaced by some new tool with a completely different name, or that CVS has been replaced by GIT. And while POSIX doesn’t require (best I can tell) a tool named ifconfig it’s very unlikely you would find it replaced by something else.
Right. And by following the discussions on tech@, I’ve gotten the impression that Theo (as well as many other developers) do deeply care about avoiding unnecessary chance to the user facing parts as tools get replaced or extended. Case in point, daemon configuration. The system got extended with the rcctl tool, but the old way of configuring things via rc.local and rc.conf.local still works as it always did. Nothing like the init system swaps on Linux. Still, extending or changing the behavior of a tool even at the risk of breaking some old script seems to be preferred to making new tools that require everyone to adapt.
After a decade of using Linux as well as OpenBSD, I’d say that OpenBSD is way more committed to keeping the user facing parts finger compatible while breaking ABI more freely (“we live in a source code world”). In the Linux world I’ve come to expect ABI compatibility but user compatibility gets rekt all the time.
So (1) nobody cared to improve the old tools, writing new ones is more fun, and (2) updating the old tools to reflect current reality would break old scripts, so the rational choice is to both let the old tool rot (thus quite possibly breaking anything that relies on it) as well as introduce a new tool that definitely isn’t compatible with the old scripts. Why do I feel like this line of arguing has a problem or two?
Pray tell, what happens when the interface provided by the iproute2 utilities no longer reflects reality. Let them rot and write yet another set of new tools? Break them? Introduce subtle lies?
Oh by the way, if you’re configuring IPv6 on linux, don’t use the old tools. They’re subtly broken and can waste you a lot of time. I’ve been there. Don’t mention it.
Meanwhile, I’m glad that OpenBSD’s ifconfig can show more than one IP per interface. And I can use the same tool to set up my wifi too. It’s a tool meant to work.
The BSDs are maintaining the kernel and the base system in locksteps. This is not the case for Linux distributions. Over the years, Linux developers started to do the same. That’s why we now have iproute2, ethtool, iw and perf, which are userland tools evolving at the same speed as the kernel (and sharing the version number).
The people who want to use the old tools want them to keep working the same way they always have. They already work that way, so the people who want to use the old tools have no motivation to make changes.
It would also piss off the people who want to keep using the old tools, since by definition they would no longer keep working the same way.
The names
ifconfigandnetstatare now claimed and cannot be re-used for a different purpose, in much the same way that filenames likeCOM1andAUXare claimed on Windows and cannot be re-used.My understanding is that OpenBSD reserves the right to change anything at any time, from user-interface details down to the C ABI. “The people who want to use the old tools” are discouraged from using OpenBSD to begin with, so it’s not surprising that OpenBSD doesn’t have to wrestle with these kinds of problems.
While this is true, I think you are taking it a little too literally. You won’t, for example, upgrade to the latest snapshot and find that
lshas been replaced by some new tool with a completely different name, or that CVS has been replaced by GIT. And while POSIX doesn’t require (best I can tell) a tool namedifconfigit’s very unlikely you would find it replaced by something else.Right. And by following the discussions on tech@, I’ve gotten the impression that Theo (as well as many other developers) do deeply care about avoiding unnecessary chance to the user facing parts as tools get replaced or extended. Case in point, daemon configuration. The system got extended with the rcctl tool, but the old way of configuring things via rc.local and rc.conf.local still works as it always did. Nothing like the init system swaps on Linux. Still, extending or changing the behavior of a tool even at the risk of breaking some old script seems to be preferred to making new tools that require everyone to adapt.
After a decade of using Linux as well as OpenBSD, I’d say that OpenBSD is way more committed to keeping the user facing parts finger compatible while breaking ABI more freely (“we live in a source code world”). In the Linux world I’ve come to expect ABI compatibility but user compatibility gets rekt all the time.