Live data from Hacker News

There are real reasons for Linux to replace ifconfig, netstat, etc

utcc.utoronto.ca

101–110 of 270 posts

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#101

This is slightly off topic. Netflix has transformed the output of netstat to have more immediate visibility. Its good to have something like this. https://imgur.com/a/g8P2Nm2

That’s pretty neat actually. Thanks for sharing.

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#102

I've never understood the purpose of IP aliases like the "secondary em0" the author is setting up with systemd.networkd. These aliases are practically useless, you cannot bind() to them without knowing the IP, you cannot use them in firewall rules, you cannot setup dhcp for them etc. What are people using them for? I'm not sure what the low level difference is between an alias like in the article, or a "eth0:1" type…

> What are people using them for? In my case, keepalived VRRP floating addresses.

I've used eth0:xx style aliases for that for a decade with no problem. Do you know what the difference is?

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#103
While this article makes a case for the new command, the reality is simple. I personally learned ifconfig continually in my life and so I learned how to read it and interpret what it was trying to say. It output its commands in a fairly easy to parse way. The new command, while I am sure is progressive and forward thinking, feels clunky. I often have to try to remember the name of the command itself as it is not obvious. It is a good example of a command not really doing the function of making the job easier on the network admin in favor of accommodating new conceptions of features. All the thousands of hours I spent on ifconfig are, basically, useless unless I want to be antiquated and have useless debates about standards. Basically, I just want the computer to do what I tell it with as little extra trouble as possible.

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#104

Earlier quoted context omitted.

It seems like a missed opportunity not to have a JSON (or other explicitly machine readable format) output option for easy scripting use through jq. Every time I need to craft a grep regex to get some trivial piece of information from one of these tools, I feel there's a bug waiting to happen (and I'm usually right).

ip has a --json flag: https://github.com/CumulusNetworks/iproute2/commit/5df607725...

Hmm, not for everything, apparently. It works with "-json addr" or "-json link", but not with eg. "-json route" or most other things i've tried.

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#105
post #43

Earlier quoted context omitted.

I'm not sure "terse" is the right adjective. It presents basically the same amount of information as ifconfig (minus the packet counters) and actually adds a few more flags. It's all about the formatting really. Simply adding an empty line between each interface would go a long way. Also starting the line with the interface name instead of the index. Adding more punctuation to delimit the fields (, : etc...) would be…

Huh, does "ip" also support "tc" (traffic control) commands - qdisc is a queueing discipline... tc seems to be the an earlier thing from the people who brought us ip. tc must have the worst command line interface and documentation ever - it is very hard and very frustrating to use, like no other command line interface I've ever seen. I once tried to use tc and gave up after more than a day of trying, that is how bad…

ip/ss/tc are all netfilter based things all in the iproute2 repo.

http://inai.de/images/nf-packet-flow.png

tc is implemented by packet pacing at either egress or ingress steps.

and this is how iproute2 compares to the old net-tools stuff: https://linoxide.com/wp-content/uploads/2014/05/Linux-Nettoo...

netfilter: https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilte...

regarding UI/UX/CLI. yes, there's no arguing about it, it's just horrible. no documentation, no discoverability, no sanity. but it works, and it's free :o

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#107
post #86
post #43

Earlier quoted context omitted.

I'm not sure "terse" is the right adjective. It presents basically the same amount of information as ifconfig (minus the packet counters) and actually adds a few more flags. It's all about the formatting really. Simply adding an empty line between each interface would go a long way. Also starting the line with the interface name instead of the index. Adding more punctuation to delimit the fields (, : etc...) would be…

I can take "mtu 1500" part, and sort-of "qdisc", but what's up with repeating obscure parameters at their default values, for each and IP address: valid_lft forever preferred_lft forever

Those are lifetimes for default (outgoing) address selection.

RFC 3484 "Default Address Selection for Internet Protocol version 6 (IPv6)".

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#108
post #69

So, to summarize, ifconfig has to be replaced because it relies on the /proc filesystem and it doesn't handle aliases? This is easily disproven: ifconfig on FreeBSD doesn't rely on /proc and handles aliases just fine. It sounds a bit like the whole OSS/ALSA discussion – some argued that ALSA was needed to replace OSS because OSS didn't support muxing multiple simultaneous audio streams, but strangely OSS on FreeBSD d…

Isn't ifconfig on BSD just an app that happens to share the name and some syntax with the Linux ifconfig? You could map most ifconfig operations to netlink and away from /proc, but that would have other tradeoffs.

It is the opposite - ifconfig on linux is an app that happens to share the name and syntax with the BSD utility. BSD sockets came first in 1983. linux re-implemented the interface from about 10 years latter (I'm not sure exactly when, I'd guess 1992 but that is a guess).

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#109
post #43

Earlier quoted context omitted.

I'm not sure "terse" is the right adjective. It presents basically the same amount of information as ifconfig (minus the packet counters) and actually adds a few more flags. It's all about the formatting really. Simply adding an empty line between each interface would go a long way. Also starting the line with the interface name instead of the index. Adding more punctuation to delimit the fields (, : etc...) would be…

So glad I'm not the only one with the same criticisms

I think the problem is, that these tools lack the extended human friendly output. They work well for those who use them regularly, but there's no `ip --explain`. Alas Linux and the kernel is famous for having very barebones or bloated and useless documentation.

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#110
post #69

So, to summarize, ifconfig has to be replaced because it relies on the /proc filesystem and it doesn't handle aliases? This is easily disproven: ifconfig on FreeBSD doesn't rely on /proc and handles aliases just fine. It sounds a bit like the whole OSS/ALSA discussion – some argued that ALSA was needed to replace OSS because OSS didn't support muxing multiple simultaneous audio streams, but strangely OSS on FreeBSD d…

Isn't ifconfig on BSD just an app that happens to share the name and some syntax with the Linux ifconfig? You could map most ifconfig operations to netlink and away from /proc, but that would have other tradeoffs.

I would say the difference is that Linux ifconfig was written once, and never modified. Get a new interface config, write a new tool (see mii-tool, iwconfig, etc)

On FreeBSD (and presumably other BSDs), all of the interface configuration happens with ifconfig still, if something new comes up, it's added to the tool that already exists.

There are some legitimate concerns around interfaces though -- some of the apis are either parse ifconfig's output, or copy its source code, I don't think (but could be wrong) that there's a nice machine readable way to get this information.

Post reply on HN