3 ms·

> Perhaps you're talking about a different kind of "churn". I don't really think I am. I'm going to pick on your exact example: ip is replacing ifconfig beca

> Perhaps you're talking about a different kind of "churn". I don't really think I am. I'm going to pick on your exact example: ip is replacing ifconfig because linux distros are moving to netlink as a replacement for ioctl. Why are they doing that? Hardware support - Particularly WNICs. So did ifconfig need to be replaced? Strictly speaking, no - but if you want better hardware support - yes... ifconfig could have been updated, but the problem is that you're adding complexity to the system somewhere, either by expanding the old interface, or by replacing it with a new one. You can argue expansion would have been preferable to replacement, but I'm not totally convinced - they both have tradeoffs. Someone is paying the piper either way. The only way to avoid that cost (churn in the existing tool, or churn in the introduction of a new tool) is by not supporting that hardware. Which is what BSD is doing...

johnklos 4y ago
Sigh. I hear you, but your example is bad. ip replaced ifconfig NOT because of new hardware support. For one, ifconfig could, and has been, extended. Second, that wouldn't explain removing ifconfig. Third, other OSes, like the BSDs, have alternatives for additional functionality like wiconfig. ip could exist alongside of ifconfig, if ifconfig were really a subset of ip. It's political. And if you're going to echo that, "oh, someone needs to sit around and spend all sorts of energy keeping ifconfig up to date", then remember that they clearly don't if you contend that ip is all about supporting new stuff. In other words, there's nothing in what you're saying at all that would explain the need to remove ifconfig and break decades of common usage. That's unnecessary churn, in my opinion.