Slashdot Mirror
There Are Real Reasons For Linux To Replace ifconfig, netstat and Other Classic Tools (utoronto.ca)
Several readers have shared a blog post: One of the ongoing system administration controversies in Linux is that there is an ongoing effort to obsolete the old, cross-Unix standard network administration and diagnosis commands of ifconfig, netstat and the like and replace them with fresh new Linux specific things like ss and the ip suite. Old sysadmins are generally grumpy about this; they consider it yet another sign of Linux's 'not invented here' attitude that sees Linux breaking from well-established Unix norms to go its own way. Although I'm an old sysadmin myself, I don't have this reaction. Instead, I think that it might be both sensible and honest for Linux to go off in this direction. There are two reasons for this, one ostensible and one subtle.
The ostensible surface issue is that the current code for netstat, ifconfig, and so on operates in an inefficient way. Per various people, netstat et al operate by reading various files in /proc, and doing this is not the most efficient thing in the world (either on the kernel side or on netstat's side). You won't notice this on a small system, but apparently there are real impacts on large ones. Modern commands like ss and ip use Linux's netlink sockets, which are much more efficient. In theory netstat, ifconfig, and company could be rewritten to use netlink too; in practice this doesn't seem to have happened and there may be political issues involving different groups of developers with different opinions on which way to go.
(Netstat and ifconfig are part of net-tools, while ss and ip are part of iproute2.)
However, the deeper issue is the interface that netstat, ifconfig, and company present to users. In practice, these commands are caught between two masters. On the one hand, the information the tools present and the questions they let us ask are deeply intertwined with how the kernel itself does networking, and in general the tools are very much supposed to report the kernel's reality. On the other hand, the users expect netstat, ifconfig and so on to have their traditional interface (in terms of output, command line arguments, and so on); any number of scripts and tools fish things out of ifconfig output, for example. As the Linux kernel has changed how it does networking, this has presented things like ifconfig with a deep conflict; their traditional output is no longer necessarily an accurate representation of reality.
The ostensible surface issue is that the current code for netstat, ifconfig, and so on operates in an inefficient way. Per various people, netstat et al operate by reading various files in /proc, and doing this is not the most efficient thing in the world (either on the kernel side or on netstat's side). You won't notice this on a small system, but apparently there are real impacts on large ones. Modern commands like ss and ip use Linux's netlink sockets, which are much more efficient. In theory netstat, ifconfig, and company could be rewritten to use netlink too; in practice this doesn't seem to have happened and there may be political issues involving different groups of developers with different opinions on which way to go.
(Netstat and ifconfig are part of net-tools, while ss and ip are part of iproute2.)
However, the deeper issue is the interface that netstat, ifconfig, and company present to users. In practice, these commands are caught between two masters. On the one hand, the information the tools present and the questions they let us ask are deeply intertwined with how the kernel itself does networking, and in general the tools are very much supposed to report the kernel's reality. On the other hand, the users expect netstat, ifconfig and so on to have their traditional interface (in terms of output, command line arguments, and so on); any number of scripts and tools fish things out of ifconfig output, for example. As the Linux kernel has changed how it does networking, this has presented things like ifconfig with a deep conflict; their traditional output is no longer necessarily an accurate representation of reality.
keep the command names the same but rewrite how they function? Nah makes too much fucking sense. I've had distros where my default route wasn't working and traceroute wasn't even installed by default. Talk about a shit show. What was the reason for replacing "route" anyhow? It's worked for decades and done one thing.
Only the State obtains its revenue by coercion. - Murray Rothbard
Unix was founded on the ideas of lots os simple command line tools that do one job well and don't depend on system idiosyncracies. If you make the tool have to know the lower layers of the system to exploit them then you break the encapsulation. Polling proc has worked across eons of linux flavors without breaking. when you make everthing integrated it creates paralysis to change down the road for backward compatibility. small speed game now for massive fragility and no portability later.
Some drink at the fountain of knowledge. Others just gargle.
What moron has called the tool SS ? I thing someone who does not check Google first. It is not only Unix history being wiped here.
A LOT of scripts use ifconfig and friends. Changing them would be bad, imho. Better would be to call it ifconfig6 or whatever if you're going to change the output or the meaning of commands, so you don't break existing scripts.
In general, it's better for application programs, including scripts to use an application programming interface (API) such as /proc, rather than a user interface such as ifconfig, but in reality tons of scripts do use ifconfig and such.
What's wrong with just ADDING newer commands and leaving the old ones?
We will 'correct' your tools, one by one.
The size increase due to stuff like netstat and ifconfig is trivial. Where the bloat comes from is needing python, java, javascript, often in various versions to make a system run. There is absolutely no reason this crap needs to be mandatory. And talk about expanding the attack surface.
Lenart Poettering hasn't screwed up linux enough already.
It done one thing: Maintain the routing table.
"ip" (and "ip2" and whatever that other candidate not-so-better not-so-replacement of ifconfig was) all have the same problem: They try to be the one tool that does everything "ip". That's "assign ip address somewhere", "route the table", and all that. But that means you still need a complete zoo of other tools, like brconfig, iwconfig/iw/whatever-this-week.
In other words, it's a modeling difference. On sane systems, ifconfig _configures the interface_, for all protocols and hardware features, bridges, vlans, what-have-you. And then route _configures the routing table_. On linux... the poor kids didn't understand what they were doing, couldn't fix their broken ifconfig to save their lives, and so went off to reinvent the wheel, badly, a couple times over.
And I say the blogposter is just as much an idiot.
Per various people, netstat et al operate by reading various files in /proc, and doing this is not the most efficient thing in the world
So don't use it. That does not mean you gotta change the user interface too. Sheesh.
However, the deeper issue is the interface that netstat, ifconfig, and company present to users.
No, that interface is a close match to the hardware. Here is an interface, IOW something that connects to a radio or a wire, and you can make it ready to talk IP (or back when, IPX, appletalk, and whatever other networks your system supported). That makes those tools hardware-centric. At least on sane systems. It's when you want to pretend shit that it all goes awry. And boy, does linux like to pretend. The linux ifconfig-replacements are IP-only-stack-centric. Which causes problems.
For example because that only does half the job and you still need the aforementioned zoo of helper utilities that do things you can have ifconfig do if your system is halfway sane. Which linux isn't, it's just completely confused. As is this blogposter.
On the other hand, the users expect netstat, ifconfig and so on to have their traditional interface (in terms of output, command line arguments, and so on); any number of scripts and tools fish things out of ifconfig output, for example.
linux' ifconfig always was enormously shitty here. It outputs lots of stuff I expect to find through netstat and it doesn't output stuff I expect to find out through ifconfig. That's linux, and that is NOT "traditional" compared to, say, the *BSDs.
As the Linux kernel has changed how it does networking, this has presented things like ifconfig with a deep conflict; their traditional output is no longer necessarily an accurate representation of reality.
Was it ever? linux is the great pretender here.
But then, "linux" embraced the idiocy oozing out of poettering-land. Everything out of there so far has caused me problems that were best resolved by getting rid of that crap code. Point in case: "Network-Manager". Another attempt at "replacing ifconfig" with something that causes problems and solves very few.
I'm responsible a lot of production systems (somewhere around a thousand VMs, it varies), so of course I worry about CPU use, memory use, I/O, etc. I have never, ever, in decades of sysadmin'ing, worried about how much of the above ifconfig or netstat take. (It's not like what's in /proc are actual files, after all; /proc a kernel interface.)
Worried about efficiency? In the aggregate you'll waste more CPU- and man-hours compiling and debugging your replacement tools than using ifconfig or netstat will. Go spend that time on something useful.
-- Alastair
In theory netstat, ifconfig, and company could be rewritten to use netlink too; in practice this doesn't seem to have happened and there may be political issues involving different groups of developers with different opinions on which way to go.
No, it is far simpler than looking for some mythical "political" issues. It is simply that hackers - especially amateur ones, who write code as a hobby - dislike trying to work out how old stuff works. They like writing new stuff, instead.
Partly this is because of the poor documentation: explanations of why things work, what other code was tried but didn't work out, the reasons for weird-looking constructs, techniques and the history behind patches. It could even be that many programmers are wedded to a particular development environment and lack the skill and experience (or find it beyond their capacity) to do things in ways that are alien to it. I feel that another big part is that merely rewriting old code does not allow for the "look how clever I am" element that is present in fresh, new, software. That seems to be a big part of the amateur hacker's effort-reward equation.
One thing that is imperative however is to keep backwards compatibility. So that the same options continue to work and that they provide the same content and format. Possibly Unix / Linux only remaining advantage over Windows for sysadmins is its scripting. If that was lost, there would be little point keeping it around.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
So basically there is a proposal to dump existing terminal utilities that are cross-platform and create custom Linux utilities - then get rid of the existing functionality? That would be moronic! I already go nuts remoting into a windows platform and then an AIX and Linux platform and having different command line utilities / directory separators / etc. Adding yet another difference between my Linux and macOS/AIX terminals would absolutely drive me bonkers!
I have no problem with updating or rewriting or adding functionalities to existing utilities (for all 'nix platforms), but creating a yet another incompatible platform would be crazily annoying.
(not a sys admin, just a dev who has to deal with multiple different server platforms)
All output for 'ip' is machine readable, not human.
Compare
$ ip route
to
$ route -n
Which is more readable? Fuckers.
Same for
$ ip a
and
$ ifconfig
Which is more readable? Fuckers.
The new commands should generally make the same output as the old, using the same options, by default. Using additional options to get new behavior. -m is commonly used to get "machine readable" output. Fuckers.
It is like the systemd interface fuckers took hold of everything. Fuckers.
BTW, I'm a happy person almost always, but change for the sake of change is fucking stupid.
Want to talk about resolvconf, anyone? Fuckers! Easier just to purge that shit.
Do it like it is done correctly:
Leave the old interfaces/tools in, including their inefficiency. If you dont like to haven these in your special kernel, the proc filesystem can be disabled......
For those systems which need something more efficient (i suppose things involving heavy use of containers or virtualization), use the new interfaces.
This worked well for a lot of things up to now in linux.
Well yes, systemd was intended to cater to a different set of users and use cases than the old system, so of course it 'worked well', or was 'a fiasco', depending on what one was doing.
What pisses me off is when I go to run ifconfig and it isn't there, and then I Google on it and there doesn't seem to be *any* direct substitute that gives me the same information. If you want to change the command then fine, but allow the same output from the new commands. Furthermore, another bitch I have is most systemd installations don't have an easy substitute for /etc/rc.local.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Linux has one of the few IP stacks that isn't derived from the BSD stack, which in the industry is considered the reference design. Instead for linux, a new stack with it's own bugs and peculiarities was cobbled up.
Reference designs are a good thing to promote interoperability. As far as TCP/IP is concerned, linux is the biggest and ugliest stepchild. A theme that fits well into this whole discussion topic, actually.
TFA is full of shit.
IP aliases have always and still do appear in ifconfig as separate logical interfaces.
The assertion ifconfig only displays one IP address per interface also demonstrably false.
Using these false bits of information to advocate for change seems rather ridiculous.
One change I would love to see... "ping" bundled with most Linux distros doesn't support IPv6. You have to call IPv6 specific analogue which is unworkable. Knowing address family in advance is not a reasonable expectation and works contrary to how all other IPv6 capable software any user would actually run work.
Heck for a while traceroute supported both address families. The one by Olaf Kirch eons ago did then someone decided not invented here and replaced it with one that works like ping6 where you have to call traceroute6 if you want v6.
It seems anymore nobody spends time fixing broken shit... they just spend their time finding new ways to piss me off. Now I have to type journalctl and wait for hell to freeze over just to liberate log data I previously could access nearly instantaneously. It almost feels like Microsoft's event viewer now.
SysD: (v). To force an unnecessary replacement of something that already works well with an alternative that the majority perceive as fundamentally worse.
Example usage: Wow you really SysD'd that up.
I am Linux kernel network and proprietary distributions developer and have actually read the code.
Reading stuff in /proc is a standard mechanism and where appropriate, all the tools are doing the same including 'ss' that you mentioned (which is btw very poorly designed)
Also there are several implementations of the net tools, the one from busybox probably the most famous alternative one and implementations don't hesitate changing how, when and what is being presented.
What is true though is that Linux kernel APIs are sometimes messy and tools like e.g. pyroute2 are struggling with working around limitations and confusions. There is also a big mess with the whole netfilter package as the only "API" is the iptables command-line tool itself.
Linux is arguably the biggest and most important project on Earth and should respect all views, races and opinions. If you would like to implement a more efficient and streamlined network interface (which I very much beg for and may eventually find time to do) - then I'm all in with you. I have some ideas of how to make the interface programmable by extending JIT rules engine and making possible to implement the most demanding network logic in kernel directly (e.g. protocols like mptcp and algorithms like Google Congestion Control for WebRTC).
>. Files don't generally call you, for example, you have to poll.
That's called inotify. If you want to be compatible with systems that have something other than inotify, fswatch is a wrapper around various implementations of "call me when a file changes".
Polling is normally the safest and simplest paradigm, though, because the standard thing is "when a file changes, do this". Polling / waiting makes that simple and self-explanatory:
while tail file
do
something
done
The alternative, asynchronously calling the function like this has a big problem:
when file changes
do something
The biggest problem is that a file can change WHILE you're doing something(), meaning it will re-start your function while you're in the middle of it. Re-entrancy carries with it all manner of potential problems. Those problems can be handled of you really know what you're doing, you're careful, and you make a full suite of re-entrant integration tests. Or you can skip all that and just use synchronous io, waiting or polling. Neither is the best choice in ALL situations, but very often simplicity is the best choice.
The OP's argument is that netlink sockets are more efficient in theory so we should abandon anything that uses a pseudo-proc, re-invent the wheel and move even farther from the UNIX tradition and POSIX compliance? And it may be slower on larger systems? Define that for me because I've never experienced that. I've worked on single stove-pipe x86 systems, to the 'SPARC archteciture' generation where everyone thought Sun/Solaris was the way to go with single entire systems in a 42U rack, IRIX systems, all the way on hundreds of RPM-base linux distro that are physical, hypervised and containered nodes in an HPC which are LARGE compute systems (fat and compute nodes). That's a total shit comment with zero facts to back it up. This is like Good Will Hunting 'the bar scene' revisited...
OP, if you're an old hat like me, I'd fucking LOVE to know how old? You sound like you've got about 5 days soaking wet under your belt with a Milkshake IPA in your hand. You sound like a millennial developer-turned-sysadmin-for-a-day who's got all but cloud-framework-administration under your belt and are being a complete poser. Any true sys-admin is going to flip-their-shit just like we ALL did with systemd, and that shit still needs to die. There, I got that off my chest.
I'd say you got two things right, but are completely off on one of them:
* Your description of inefficient is what you got right: you sound like my mother or grandmother describing their computing experiences to look at Pintrest on a web brower at times. You mind as well just said slow without any bearing, education guess or reason. Sigh...
* I would agree that some of these tools need to change, but only to handle deeper kernel containerization being built into Linux. One example that comes to mind is 'hostnamectl' where it's more dev-ops centric in terms of 'what' slice or provision you're referencing. A lot of those tools like ifconfig, route and alike still do work in any Linux environment, containerized or not --- fuck, they work today.
Anymore, I'm just a disgruntled and I'm sure soon-to-be-modded-down voice on /. that should be taken with a grain of salt. I'm not happy with the way the movements of Linux have gone, and if this doesn't sound old hat I don't know what is: At the end of the day, you have to embrace change. I'd say 0.0001% of any of us are in control of those types of changes, no matter how we feel about is as end-user administrators of those tools we've grown to be complacent about. I got about 15y left and this thing called Linux that I've made a good living on will be the-next-guys steaming pile to deal with.
Just to give you guys some color commentary, I was participating quite heavily in Linux development from 1994-1999, and Linus even added me to the CREDITS file while I was at the University of Michigan for my fairly modest contributions to the kernel. [I prefer application development, and I'm still a Linux developer after 24 years. I currently work for the company Internet Brands.]
What I remember about ip and net is that they came about seemingly out of nowhere two decades ago and the person who wrote the tools could barely communicate in English. There was no documentation. net-tools by that time was a well-understood and well-documented package, and many Linux devs at the time had UNIX experience pre-dating Linux (which was announced in 1991 but not very usable until 1994).
We Linux developers virtually created Internet programming, where most of our effort was accomplished online, but in those days everybody still used books and of course the Linux Documentation Project. I have a huge stack of UNIX and Linux books from the 1990's, and I even wrote a mini-HOWTO. There was no Google. People who used Linux back then may seem like wizards today because we had to memorize everything, or else waste time looking it up in a book. Today, even if I'm fairly certain I already know how to do something, I look it up with Google anyway.
Given that, ip and route were downright offensive. We were supposed to switch from a well-documented system to programs written by somebody who can barely speak English (the lingua franca of Linux development)?
Today, the discussion is irrelevant. Solaris, HP-UX, and the other commercial UNIX versions are dead. Ubuntu has the common user and CentOS has the server. Google has complete documentation for these tools at a glance. In my mind, there is now no reason to not switch.
Although, to be fair, I still use ifconfig, even if it is not installed by default.