Yes, this is key, and why ip is so terrible for the way I currently work. No doubt I'll have to get used to it, like those stupid biosdevname interfaces.
90% of my machines don't have more than 1 IP per physical interface, the rest are aliases
ifconfig outputs clear whitespace, so picking out the specific details of
- interface name
- ip address
Is far easier. I do prefer /28 to 255.255.255.240 when specifying subnets, but it does make it far harder to scan what the IP is. I suspect the people writing the utilities are the ones who are able to automate everything, as they do the same job 1000 times, with IP in, IP out, and no concern about physical devices, so rarely use the tool to read data, certainly not as a human.
You've then got the "what's the default gateway" problem
route -n
shows it nice and easy
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.26.32.1 0.0.0.0 UG 0 0 0 eth0
172.26.32.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
ip route -n returns
ip route -n
Command "-n" is unknown, try "ip route help".
Helpful, ip route help is no help at all
It's all good having tools to manage lots of ip namespaces etc, that's great in the subset of cases you need that functionality, but for those of us that manage physical machines with physical inputs/outputs, rather than datacenter scale devices, it's a right pain.
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 nice too. I mean what the hell:
It sounds a little bit like air traffic control: "roger dev gbe zero niner alpha one you are cleared for proto kernel scope link strip 4 dash 7 F L 11400 gamma zulu src please copy."
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 it is. The syntax is a word soup and the semantics are very poorly explained.
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
After working with it almost daily for years I'm finally fluent in MegaCLI. I can even understand the --help for the most part. Time to get a new job I guess.
Oh fair enough but in the context of Linux command lines I think MegaCLI is genuinely one of the worst UX designs ever. Up until recently (post Balmer), Microsoft didn’t heavily emphasize the CLI for most things so a bad UX is not surprising.
I spent a bit too long on playing with tc a while ago. The best I could get it was to limit each person's download speeds from the one internet connection we had.
I'm with you on tc having the worst interface and documentation that I have seen from a command before. I spent maybe a few days total on it then gave up because I figured if there isn't much documentation on it, it isn't worth figuring out.
I used tc for something interesting once: I setup Cassandra nodes in distinct docker containers running on a single laptop. I installed tc in each container to throttle packets flowing between containers and in so doing, simulated a lossy, high latency WAN network. The goal was to evaluate how Cassandra fared as network latencies increased.
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.
Wow. That's actually kind of a tiny little brilliant gem that remains to be discovered by many. I, for one, had never though about trying this.
Alas it doesn't work quite so well for "ip addr". It would have been great if they'd just decided on CSV or JSON or whatever and then relied on secondary utilities to go to "pretty-printed".
No it's not, it's usually "What is the default gateway on this network segment because I want to plug my laptop in"
I do use ip route a fair bit - if I have a machine connected to two (or more) network segments and want to ensure traffic gets routed back the way it came
However my main criticism for "ip route" is that it's inconsistent and a change route "route"
"route" does reverse dns lookups - e.g "my.server.tld rather than "1.2.3.4", or "default" rather than "0.0.0.0"
"route -n" shows 1.2.3.4
"ip route" doesn't do reverse lookup, however it does say "default" rather than "0.0.0.0".
Yes, this is key, and why ip is so terrible for the way I currently work. No doubt I'll have to get used to it, like those stupid biosdevname interfaces.
90% of my machines don't have more than 1 IP per physical interface, the rest are aliases
ifconfig outputs clear whitespace, so picking out the specific details of
- interface name
- ip address
Is far easier. I do prefer /28 to 255.255.255.240 when specifying subnets, but it does make it far harder to scan what the IP is. I suspect the people writing the utilities are the ones who are able to automate everything, as they do the same job 1000 times, with IP in, IP out, and no concern about physical devices, so rarely use the tool to read data, certainly not as a human.
You've then got the "what's the default gateway" problem
route -n
shows it nice and easy
ip route -n returns Helpful, ip route help is no help at allIt's all good having tools to manage lots of ip namespaces etc, that's great in the subset of cases you need that functionality, but for those of us that manage physical machines with physical inputs/outputs, rather than datacenter scale devices, it's a right pain.