3 ms·
There's no reason why someone can't get their act together and fix ifconfig, or if that is insurmountable, rewrite it while maintaining the same outward appeara
by asveikau 7y ago
There's no reason why someone can't get their act together and fix ifconfig, or if that is insurmountable, rewrite it while maintaining the same outward appearances.
I think this is not specific to Linux at all, and is not really about kernel ABI. This is a problem I see a lot, often in proprietary software too. Firstly, people opt to rewrite before they fix or even before they fully understand the old thing. Secondly, people confuse interface with implementation, and often don't bother trying to make their rewrites interoperable with the old thing.
Another example of that last one, in Linux from the late 90s, is ALSA. FreeBSD for example chose to fix the problems and maintain the old OSS API for audio devices. Linux introduced a very complicated new API.
[By the way, I spotted one sort of technical error in the article. I don't think most software keeps private copies of kernel data structures in their source tree. Rather, when they #include the kernel headers, they end up using an effectively-private version of those structures and constants in their object code. This is slightly different but a similar result.]
- burfog 7y agoSoftware using obscure kernel interfaces does keep private copies of kernel data structures. The reason is that people want the software to have full functionality no matter what system is used for building it. You can build on an old system, with a kernel that totally lacks the functionality, and produce a binary that can use the new kernel interfaces when run on a system that has them.
- asveikau 7y agoGlibc certainly does this, I would expect for limited periods per interface. It is often at the cutting edge of kernel interfaces, so that becomes necessary during interim periods. I really doubt it makes sense for old and stable things like ifconfig, or a tipical application.
- matheusmoreira 7y ago> Glibc certainly does this > It is often at the cutting edge of kernel interfaces Is it? It seems like support for Linux-specific features can take years. The getrandom system call, for example: https://lwn.net/Articles/711013/ https://lwn.net/Articles/711013/
- deleted 7y ago[deleted]
- akira2501 7y ago> or even before they fully understand the old thing. I feel that /sbin/ip is in almost every way a better tool than /sbin/ifconfig, is that not the concensus? > Linux introduced a very complicated new API. Which highlights the fact that the moment you want to have in-depth interactions with a driver for a piece of hardware ioctls are the wrong choice. OSS was great if you had exceptionally simple needs.. the moment you want to do "professional" audio it was a nightmare. ALSA is _somewhat_ better for this, and I honestly wish they went with a more netlink(3) style API instead of an IOCTL driven one. What's the point of pantomiming the old thing when the old thing wasn't designed properly in the first place?
- zymhan 7y agoMy opinion is that `ip` is a more powerful tool, but it is not as useful for quickly obtaining information or performing a basic action like up/down.
- tssva 7y agoMy opinion is that while a little more verbose it is just as useful for obtaining information or performing basic actions. Especially since it allows you to use the same cli and actions to maintain most network related actions rather than multiple tools with varying commands.
- jeltz 7y agoAnd my opinion is that ip is easier to use in almost every way than ifconfig. The man page used to be bad but the tool has always been easy to use as long as I remember.
- iso947 7y agoIfconfig wins on the following 1) name. It’s to configure the interface 2) default format. Far better spaced than “ip”’s various outputs. I find “ip -o a” just about manageable, but if config shows data far more cleanly imo
- zokier 7y ago> There's no reason why someone can't get their act together and fix ifconfig, or if that is insurmountable, rewrite it while maintaining the same outward appearances. But it's telling that nobody stepped up and actually bothered to do that despite all the bitching and moaning. Successful code is generally produced to solve problems, not fullfil some abstract ideals
- ferzul 7y agosome one in this very thread said did in fact do exactly that, since they needed compatibility with FreeBSD.
- comex 7y agoExcept someone did rewrite it: https://news.ycombinator.com/item?id=22628938 https://news.ycombinator.com/item?id=22628938 But with the Linux ecosystem's inertia being what it is, rather than the 2 existing implementations of ifconfig in use being displaced by this better one... now there are just 3 implementations of ifconfig in use. As mentioned in the Stack Exchange thread linked in that post, a different someone submitted a relevant patch to one of those existing implementations – way back in 2013. But it was never accepted. More inertia.
- JdeBP 7y ago2009, in fact. I put it in the further reading.
- kelnos 7y agoTo be fair, the third 'ifconfig' implementation is not compatible with the original in command-line options or in output, so adopting it would require changes just as adopting 'ip' does.
- JdeBP 7y agoTwo priors ("original" not really being the right word), each already not compatible with the other. * http://jdebp.uk./Softwares/nosh/guide/commands/ifconfig.xml#COMPATIBILITY http://jdebp.uk./Softwares/nosh/guide/commands/ifconfig.xml#...