M. Siebenmann's actual main point, ignored by much of the "I do/do not like ip/ifconfig." discussion here, is that it is valid to replace ifconfig because the standard output of the command is an interface contract that is set in stone because of people using it in scripts.
I disagree, on two grounds.
Firstly, the ifconfig commands in the BSDs are existence proofs that this is not so. The BSD people actually have modified ifconfig to keep up with changing kernel networking abilities, and one will find the (say) FreeBSD ifconfig of today having a lot more functionality than the Linux one. The BSDs, by their very natures, kept their ifconfig tools aligned with the rest of the operating system as it changed.
Secondly, an aversion to breaking (badly designed) scripts is isn't really the reason that ifconfig hasn't been changed. The reason that ifconfig hasn't been changed, as evident from the net-tools bug and other discussions of this, one of which I have hyperlinked elsewhere in this discussion, is more to do with (purportedly) doing things portably and not having two disjoint code paths, one for Linux using netlink and one for everything else using ioctl. Two code paths and code that was not portable to other operating systems would be the result of adding netlink capability to net-tools's ifconfig.
That reason does not itself hold water, however. The net-tools package is highly Linux-specific anyway, in the first place, so arguments about its portability are moot. Given that, the actually expressed reason for not doing this given by the developers themselves (as opposed to the differing reasons inferred by people other than the developers, the most often given one of which is directly contradicted by git repository activity as recent as 2016) founders.
One of the more disappointing things about Linux's ifconfig is that this:
# ifconfig lo inet6 ::1
Don't know how to set addresses for family 10.
#
is a fairly trivial oversight in a case statement in the code, a missing case for AF_INET6, rather than a fundamental design or implementation problem, and doesn't even need the netlink API to fix.
I disagree, on two grounds.
Firstly, the ifconfig commands in the BSDs are existence proofs that this is not so. The BSD people actually have modified ifconfig to keep up with changing kernel networking abilities, and one will find the (say) FreeBSD ifconfig of today having a lot more functionality than the Linux one. The BSDs, by their very natures, kept their ifconfig tools aligned with the rest of the operating system as it changed.
* https://freebsd.org/cgi/man.cgi?query=ifconfig
* https://linux.die.net/man/8/ifconfig
* https://unix.stackexchange.com/questions/319350/
Secondly, an aversion to breaking (badly designed) scripts is isn't really the reason that ifconfig hasn't been changed. The reason that ifconfig hasn't been changed, as evident from the net-tools bug and other discussions of this, one of which I have hyperlinked elsewhere in this discussion, is more to do with (purportedly) doing things portably and not having two disjoint code paths, one for Linux using netlink and one for everything else using ioctl. Two code paths and code that was not portable to other operating systems would be the result of adding netlink capability to net-tools's ifconfig.
That reason does not itself hold water, however. The net-tools package is highly Linux-specific anyway, in the first place, so arguments about its portability are moot. Given that, the actually expressed reason for not doing this given by the developers themselves (as opposed to the differing reasons inferred by people other than the developers, the most often given one of which is directly contradicted by git repository activity as recent as 2016) founders.
* https://github.com/ecki/net-tools/commits/master
One of the more disappointing things about Linux's ifconfig is that this:
is a fairly trivial oversight in a case statement in the code, a missing case for AF_INET6, rather than a fundamental design or implementation problem, and doesn't even need the netlink API to fix.* https://sourceforge.net/p/net-tools/code/ci/master/tree/ifco...
* https://sourceforge.net/p/net-tools/code/ci/master/tree/ifco...