There are real reasons for Linux to replace ifconfig, netstat, etc | Hacker News Reader

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

utcc.utoronto.ca

354 pointszdw256 comments

I'm trying hard to fight my old muscle memory to use ip instead of ifconfig on Linux.

I have a few issues though:

* "ip" is useless as a keyword if you're looking for help online. It's extremely frustrating and probably my main issue actually learning how to use the damn thing.

* ifconfig's output is simply more readable IMO: https://svkt.org/~simias/up/20180525-113825_ip-vs-ifconfig.p... . It's pretty weird that a brand new tool manages to have worse output than a venerable old unix command. Because of this I often end up configuring the network with ip only to double-check everything is right with a quick ifconfig. That's silly.

I think at this point I would've preferred if they had made an "ifconfig2" instead, mostly identical to the old one but with a few breaking changes to add the missing functionality. An incremental update instead of a full rewrite. There's definitely some NIH going on.

Exactly. Even the `ip` name is misleading as the command does much more than only ip-related things (link layer, network namespaces, tcp, …).

Always wondered about this - is IP 'internet protocol' or something else, since it's much lower level than IP? I've been using IP route 15 for 15, maybe 20 years now and hinestly have no idea.

Yes, it is 'internet protocol' [0] and part of TCP/IP.[1]

[0] https://en.wikipedia.org/wiki/Internet_Protocol

[1] https://en.wikipedia.org/wiki/Internet_protocol_suite

I know what IP is. Your reference doesn't answer the question as to whether 'ip' means IP.

> "ip" is useless as a keyword

Most docs will mention iproute2. You can use that for googling.

Yeah that’s what I loved about this article, I finally know what to google.

Future tip: your package manager should be able to find this for you, for example:

> $ which ip

> /sbin/ip

> $ dpkg -S /sbin/ip

> iproute2: /sbin/ip

You may also want 'whereis' instead of 'which'.

I use cope to colorize my output, which makes 'which' useless to me for most common commands, but 'whereis' still works.

Edit for examples:

    $ which ip
    /usr/share/perl5/vendor_perl/auto/share/dist/Cope/ip
    $ whereis ip
    ip: /usr/bin/ip /usr/share/perl5/vendor_perl/auto/share/dist/Cope/ip /usr/share/man/man7/ip.7.gz /usr/share/man/man8/ip.8.gz

> whereis

Thanks for this! After 14+ years of using Linux almost daily, I had never heard of this command. I learned something new today, so now it's time to go home!

Yeah, I recently "discovered" the commands 'whatis' [0] and 'apropos' [1] and my experience learning Linux improved quite a bit.

[0] https://linux.die.net/man/1/whatis

[1] https://linux.die.net/man/1/apropos

Thanks for passing those on as well!

In bash, there's also:

    command -V

Which knows about aliases and functions as well:

    $ command -V ip
    ip is /sbin/ip
    $ command -V ll
    ll is aliased to `ls -AlF --color=auto'
    $ command -V command_not_found_handle
    command_not_found_handle is a function
    command_not_found_handle ()
    {
        if [ -x /usr/lib/command-not-found ]; then
            /usr/lib/command-not-found -- "$1";
            return $?;
        else
            if [ -x /usr/share/command-not-found/command-not-found ]; then
                /usr/share/command-not-found/command-not-found -- "$1";
                return $?;
            else
                printf "%s: command not found\n" "$1" 1>&2;
                return 127;
            fi;
        fi
    }

I finally found out how to get netstat on these dang new systemd machines! :)

That's a good tip, thanks.

That being said while docs specifically written about the tool will probably mention it random forum posts, tutorials or even stackoverflow questions may not.

On my CentOS 7 system, there is no iproute2 package, but there is an iproute package. Neither 'man iproute' nor 'man iproute2' produce any man pages. The iproute package provides the contents of /etc/iproute2, among other things, so why is the package name just iproute? The man page for ip has the name iproute2 at the very bottom, where it is easily missed. It would never have occurred to me to look for either iproute or iproute2 for information on ip had I not come across this posting. A little consistency of naming, with better cross referencing, would sure be nice...

What you're describing seems like an inexcusable state of affairs, but as a practical matter `man -k <search term>` or `apropos <search term>` is useful for finding poorly named manpages.

Of course in the specific case of "ip", both are going to return quite a haystack to search through...

> ifconfig's output is simply more readable IMO

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.

to get the gateway: ip route show default

> > ifconfig's output is simply more readable IMO

I prefer iproute2's terseness.

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:

    mtu 1500 qdisc pfifo_fast qlen 1000

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.

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."

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)".

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.

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

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.

tc fit the bill nicely.

Did you remember to disable your swap file/partition?

https://stackoverflow.com/questions/22988824/why-swap-needs-...

MegaCLI (lsi hw raid control) sees your tc and raised you a few million awful flags.

I'm pretty sure MegaCLI was written by someone who used to write software for digital phone switches.

Ah, my old friend MegaCLI. Simultaneously the most verbose and the most useless --help output I've ever seen from a command-line program.

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.

Nah.. Just time to relearn it all with StorCLI instead.

:-(

I see your MegaCLI and raise you certutil: https://docs.microsoft.com/en-us/windows-server/administrati...

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.

That just shows its user-unfriendliness further. Here's a more readable version of the output:

> ip route | column -t

(With iproute2 4.3.0, I get the same output between "route", "route show", and "route show default"; no idea if it's changed since.)

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".

Somewhere else in here, someone else mentioned that "ip" has "--oneline", which does seem to work decently, at least for the first couple columns:

   ip --oneline addr | column -t

When asking "what's the default gateway?", more often than not, the real question you have is "what's the gateway to IP address X", which would be:

  ip route get X

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".

Then reask: whats the gateway to 0.0.0.0/0

The man page is good.

`ip` takes a --oneline arg to make it more parseable.

I'm not sure having everything crammed into a single line makes it better (at least if a human is supposed to parse it and not a machine): https://svkt.org/~simias/up/20180525-125636_ip-vs-ifconfig-2...

I have used ip -oneline to parse configuration of servers, and it's really practical.

The only real gripe I have with IP is their long argument/switch format. Unlike everyone else, ip is a minority, which accepts long options with single dash "-". This prevents someone from combining many short parameters under a single dash, also it's confusing to use.

Yes, it unofficially supports the old double dash format, but if you are supporting it, there's no point in supporting single dash long options.

This is ridiculous. I would love to know their justification for using single dash for long options. When did that become the "old way"?? Very old X11 commands and many Solaris commands use a single dash, but nearly all modern commands use double dash. And I agree that this syntax makes it hard to combine single-character options. They must have had a very compelling reason to use a non-standard option syntax.

The only other place I've seen single-dash long options be the norm is within TCL scripts (where that's conventional whenever a proc takes named arguments/options).

openssl uses single dash for long options too: -inform, -outform, -text, -noout, etc.

gcc uses single dash for long options too: -std, -pedantic, -dumpspecs, etc.

I am sure there are many more modern commands that do this.

As most applications older than a year are called legacy nowadays gcc (~30 YO) or openssl (~20 YO) are not what comes into my mind when asked for "modern" commands.

Neither are for 'dd' or 'tar' (probably 30 YO) from the other comment.

There are probably other, younger commands not following the --long-option pattern, but i think that doesn't make it better to break this convention.

The Golang flag [0] package uses a single dash for long options.

The flags that a UNIX command uses can sometimes used to carbon-date that command. For example, dd(1) doesn't use a dash at all, uses long args, and uses an equals-sign to connect a flag with its argument (e.g. `dd if=/dev/null`). It's because dd(1) was written in the dawn of UNIX, before a convention was established for flags.

I believe the first step in creating a convention was the introduction of the getopt(3) library, which introduced single dash, single character options (e.g. `tar -x`). Commands that only have short options tend to be old commands.

Later, GNU introduced getopt_long(3), which allowed for long options and double-dashes to distinguish them from the short ones. This made commands more readable.

There have also been cases where the `-` is optional. `tar xvf` for example. And with the `ps` command, the `-` is used to distinguish BSD flags from System V flags (e.g. `ps auxwww` vs. `ps -elf`).

There has also been a movement for subcommands rather than options (which bring to mind the Cisco CLI), of which `ip` is an excellent example: `ip route show`. But subcommands are not a substitute for options; sometimes you need both (e.g. `ip -6 route show`).

All this goes to show that, although long options are quite common, they are not only game in town, and UNIX commands have a rich and varied set of conventions.

[0] https://golang.org/pkg/flag/

The dd syntax is meant to mirror that of the IBM JCL command dd, and it may have been meant as a joke.

Old versions of sort used a + to begin some options. So yes, there has been a lot of variation over time, but I see no reason to gratuitously diverge from the common standards now in use, unless following them is too restrictive in some way.

Re: Go, it describes the flags with a single dash, but it will accept them with a double dash and a more traditional style (both --string "foo" and -string="foo" are accepted, for instance)

Accepting everything at the same time is very nice in theory, but in the optimal case, the library should be able to mimic at least some established conventions.

Extreme flexibility becomes a burden after a certain point if it lacks adaptability.

Standards are built for these reasons.

For tar, x,t,c are commands not options.

For the `find` command the single dash is for predicates not for options (not that it makes a whole lot of difference)

There's an old school of programmers who resist double dash for long opts. Partly for historical reasons.

You'll find them in ex-Bell labs people (e.g. go-lang) and associated (docker).

The double dash was born in the 90s; there was a poll on Usenet gnu.misc (or similar). Those who did not habituate usenet didn't get the memo.

A --json arg would be much more parseable. I wonder if they'd be against that?

They won't. In fact it is already implemented. Try `ip -json addr`.

Not all subcommands support it though.

Which version has implemented this? It's not available here.

  rascul@coyote:~$ ip -json addr
  Option "-json" is unknown, try "ip -help".
  rascul@coyote:~$ ip -V
  ip utility, iproute2-ss160111

Looks like it was added in August of last year. Obviously newer than what my distribution has.

https://git.kernel.org/pub/scm/network/iproute2/iproute2.git...

There's another universe near ours where libxo caught on widely, and every command supports text and JSON output out of the box:

https://juniper.github.io/libxo/libxo-manual.html

> "ip" is useless as a keyword if you're looking for help online.

I don't know the decisions behind the naming either, but the ip shell command comes as part of the iproute2 [1] package.

After I found out about this googling became much easier.

[1] https://en.wikipedia.org/wiki/Iproute2

Well, sure, but assume you're new and you don't know that. You can usually search for "man ip" to get close, but that usually just gets you a technical reference for an experienced user (the man page) and not a tutorial, introduction, or training doc for someone learning a new tool. "ip command tutorial" works well, though the results are still rather mixed. I get Cisco and Windows results as well until I search "ip command tutorial linux".

The point is that searching for "ifconfig tutorial" is going to give you what you want, while "ip route" is probably going to get you Cisco documentation, honestly. Even something like "parse ip output" is going to give you a mix of results from Linux, Windows, or web services while "parse ifconfig output" is a lot more clear.

"ip" is simply a saturated keyword, making it a bad keyword.

Not sure why you think I would disagree. I'd say that is exactly my opinion, so I wanted to share that googlable term with the other frustated people out there.

I don't think you'd disagree. I just think, "Well, you could search for iproute2," isn't that helpful because it's not that obvious that that is the package name.

I love how much shorter and terse the output is with iproute2. I reach for it a lot on my mac and get a bit sad when it’s not there.

Yeah, that's if you even have "ip" Was using one of Redhat's base image the other day and there was no "ip" installed, we tried all the tricks in the book searching through /proc to find the ipv4 for a new interface, and we couldn't, we could easily grab the ipv6. Ended up writing some code to grab it using python. :-/

NIH doesn't seem to make sense as "next of hop" or "not in here", and search for this initialism is obfuscated by the National Institute of Health.

Mind expanding NIH?

Not Invented Here (https://en.wikipedia.org/wiki/Not_invented_here)

Better to avoid vague grammars when not everyone is a native English speaker.

Pretty discoverable/common: https://www.urbandictionary.com/define.php?term=NIH

I think google is smart enough that you search with "ip command" (maybe plus "linux", it'll get relevant results.

It's better that the command you type often is short, (you can certainly alias ifconfig as "ifg" or anything too).

Yes, DDG gets relevant results too: https://ddg.gg/?q="ip+command"

Maybe you're better at googling than I am but I've had serious issues with that. The problem is that there are way too many false positives for any query containing "ip" regarding networking. And even looking at the excerpts on the search results page it's not always obvious if "ip" refers to the command or something else.

Take for instance a very simple query: "ip show default route":

https://duckduckgo.com/?q=ip+command+show+default+route&t=ff...

There are a few obviously relevant matches in the first page but also a bunch of completely irrelevant results. Adding "command" doesn't improve that much. And that's for a very simple query that's probably been asked hundreds of times before.

Meanwhile if I search "ls sort date" I get mostly relevant results immediately because even though it's also a 2 letter identifier it's not quite as ambiguous: https://duckduckgo.com/?q=ls+sort+date&t=ffab&ia=qa

I've always thought the same thing. ip addr's output sucks compared to ifconfig.

Looking at it more closely now, ip addr's output doesn't seem that difficult to fix. Remove that random number before the adapter name (what the hell is that anyway? The order in which the adapter appeared? If so, why are not in that order?)

I think that alone would make it so much more readable! Maybe white space between each entry with a flag?

All of the help sections are awful too. I feel like I'm looking at language grammar definition instead of useful usage information.

It’s the interface index which is mostly an incrmsenfing number. That can become important for sub interfaces and others things that may reference it. Though they could reference by name instead.

Poking at ip and its sub-commands reminds me of poking at the serial interface of a Cisco router, and not in any pleasant way...

Bookmark this PDF: http://homepage.smc.edu/morgan_david/cs70/ip-cref.pdf

It could also be preserved as a legacy flag.

  ifconfig -L

(I don't know if this is already taken. I haven't read the man pages in forever.)

If you like India Pale Ale, then the handy "ip a" command might come second nature to you. Sounds weird, but this mnemonic was what I needed to get on board.

If only ifconfig was standardized on the output... it's output has changed over time

Let alone the non-conformity of other OS's like Solaris, HP-UX which really might not matter now. I'm sure FreeBSD matters to someone... just not me

TIL: iproute2 has a color, a brief/human mode, and a one-line mode. I think I am going to be aliasing ip -color to ip from now on.

$ ip -br -c a # ip -brief -color address

  lo     UNKNOWN  127.0.0.1/8 ::1/128 
  eth0   DOWN
  wlan0  UP       192.0.2.1/24 2001:db8::1/64 fe80::1/64

$ ip -br -c l # ip -brief -color link

  lo     UNKNOWN  00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
  eth0   DOWN     00:12:34:56:78:9a <NO-CARRIER,BROADCAST,MULTICAST,UP> 
  wlan0  UP       12:34:56:78:9a:bc <BROADCAST,MULTICAST,UP,LOWER_UP>

Thanks! Just aliased that in my .zshrc. The route object doesn't seem to do colouring sadly.

You may want to consider installing cope, which colorizes the output of a number of common commands, including 'ip route'.

TLDRRTFM of the day

"read read"?

This is a good reminder that defaults should be simple and human readable.

Advanced options should be behind flags for power users, not the other way around.

Indeed. I don't get it why `ip` has -brief which is not a default behavior and why -verbose flag does not exist. Also there could be a -no-color instead of -color flag.

Or simply detect when piped and leave the color out, as just about every sane cli tool does it.

Spot on. A good pattern is to autodetect what to do by default and yet allow forcing on/off (e.g. --color and --no-color)

Agreed. It could be as simple as checking if there is a tty and whether or not we're inside a pipe.

AFAICT these options are new(er) and making them the default would likely be a backwards-incompatible change. I can see how it would be an uphill battle to convince the maintainers to introduce what appears to be a breaking change.

That said, a new alias that does trigger these new behaviors as defaults would be a sane compromise.

Just update ip to emulate ifconfig and netstat when called as such, like busybox does. Or all of those MTAs that ship with a sendmail command.

I'm one of those "grumpy old admins" they mention in the post, but I've switched to using ip for 5+ years now and have been happy. But, -brief -color is a new one on me, and I'm gonna add that to my toolbox.

The "-brief" switch is not mentioned in the default manpage, at least on my Ubuntu 16.04 installation. Why? This should be mentioned prominently, as it's so useful.

"-brief" is also missing from the ip manpage on my 16.04 desktop, however it is listed in the output from "ip help". Looks like someone needs to update the man page...

$ ip -br -c a # ip -brief -color address

Option "-br" is unknown, try "ip -help".

Friggin' RHEL I guess I'll have to check back in a couple of years.

WHOA

That's crazy helpful. I'm aliasing it as well.

(FYI --color works too)

When I started learning Linux when it was, I think, 0.99, I appreciated that so many commands where cross-Unix. It was a Unix lookalike. I could watch how something is done on one Unix, type this stuff into my Linux terminal, and get an equivalent result in Linux, and this helped a lot and created a sense of community. Now I see that Linux tears the standards apart, there are more and more obstacles with porting complex applications. More over, we can also see the emergence of "we support Ubuntu only, sorry" mentality - Linux became very diverged. I'm so happy to be using FreeBSD now on all my boxes, with it's init, ifconfig, file system hierarchy.

Consistency is great, but there’s a trade off between consistency and innovation. In a sense, what you’re describing is stagnation.

OpenBSD's ifconfig did not stagnate. It handles aliases, bridges, wifi, etc.

No, the issue is that no one at GNU or Linux cares about correct, simple tools (2 APIs for networking in the kernel?! What happened to manpages?! WTF info?). And thanks to that it runs on anything.

Pick your poison

https://man.openbsd.org/ifconfig.8

net-tools is not a GNU software package, note.

* https://sourceforge.net/projects/net-tools/

* https://www.gnu.org/software/software.html

I'm not sure what the point you are making here is. The developers behind "ifconfig" on Linux could support the new API (iproute2) just as the developers behind "ifconfig" on OpenBSD updated their software to support the new kernel API as they became available.

The point is that in the BSDs, ifconfig is developed and released together with the kernel.

See, for example, https://svnweb.freebsd.org/base?view=revision&revision=31237..., where the author added support for hardware packet pacing. The commit touches ifconfig, socket header files, and various parts of the kernel all in one atomic change.

So, if I'm understanding this correctly, your point is that Linux is a kernel ? Haven't we moved past this ?

Nothing stops anyone from offering patches to multiple projects to sync development. Hell, some of the biggest changes crossing the kernel/userspace divide have just that.

It's not stagnation if the majority system (Linux) makes an effort to reach consensus with the minority systems (*BSD) on changes and improvements. It is unclear to me that that happens to any meaningful degree.

Not to say I would be a great fan of Linux, but I think at this point it's quite clear it's the huge winner of OSes. Nearly all servers run on it nowadays, I think all relevant smartphones (not sure though, correct me if that's wrong), many desktop/laptop computers and even Windows is integrating more and more with Linux.

With such a dominance there is not much point in syncing changes of the standard with other OSes. The moment it works different in Linux that is the new majority standard.

And while a lot more stuff is changed all the time than would be necessary one also can't expect things to stay the same for another 100 years just because they have been like that for a long time.

Yeah, the BSDs were the winner too at one point, so was Sun and even WindowsNT. Don't underestimate how fast it takes to fall from grace.

> Don't underestimate how fast it takes to fall from grace.

Fully agree.

> the BSDs were the winner too at one point

When was that point? Strong doubts about that.

Mostly thanks Torvalds accepting just about anything into the kernel, not wanting to play politics if someone rolls a kernel with some drivers that are not GPLed, and keeps a strict API/ABI stability.

Above the kernel it is a wild west, with each "platform" implementing their own stack for anything beyond the core-utils (and those are more likely to be busybox based than GNU based for political reasons).

Kernel won, userland didn't.

And they still run around going "lalalala"...

It's not the first time I hear it, but what is it supposed to mean? Is there a single thing that can be called "linux userland"? Also, I doubt that someone combines Linux kernel with Windows XP userland. So in some regard all userland tooling running on the linux kernel might be considered "linux userland".

If I understand the term userland correctly it is a term from kernel developers to say "this is code that doesn't run in the kernel", so it might not be helpful to any popularity discussion at all.

> Also, I doubt that someone combines Linux kernel with Windows XP userland.

That's Wine.

Yup, you could say that again. I cut my teeth in Linux while in high school for the most path. First year of college, I go to the engineering labs to get a job, it's all SunOS/Solaris. It's like driving a car! There were very few commands that were different!

Now, Linux is slowly going rouge and changing everything in the supposedly name of "progress" I'm still salty as hell with the systemd rubbish. The problem is that all the cool toys are supported better on Linux and I don't feel like compiling from source for most things. :-(

You do realize Solaris implemented a service management system (which is also superior to systemd; and was also created prior to systemd's conception), right ? They switched away from legacy SysV init scripts BEFORE systemd existed.

> superior to systemd

SMD was based around XML, which caused a lot of boaking.

systemd was based around .desktop, aka .ini syntax.

SMF was quite nice. Solaris was incredible in a lot of ways. I always wonder why it never took off.

> I always wonder why it never took off.

Because Larry Ellison bought Sun.

"I always wonder why it never took off."

It did take off and had a long and productive life.

Many, many of the early ISPs and webhosting providers were built on Solaris 2.6 and "7". In the late nineties it was very common to go into a datacenter and see racks full of ultra 2 boxes stacked on one another ...

If you went to college between 1992 and 1999 you were almost assured to log into a SunOS or Solaris system to read your email or ftp or whatever.

It was only when the dot-com money dried up that people (including myself) made the switch to PC based servers in an effort to save money.

Because nobody were interested?

Damn it, Apple have a similar thing going in OSX (or whatever their greasy marketing wants to call it this year) but when it was basically offered to the BSDs on a silver platter they didn't want it.

Implying that launchd and SMF are similar shows how little you know about both systems.

Launchd is mostly crappy, obtuse plist files, a semi-broken DAG, socket activation that spins your machine to death.

SMF was an access point to many things, it was clean, concise and pointed you towards the actual things that the OS provided. (like; log files) It was a pleasure to work with.

The only problem was that service definitions were configured with XML, I have never been a fan of XML.

A lot of these changes are reminding me, a 40+ year old recovering sysadmin, that I am being left behind by the technology world.

I would imagine that there are a few others in the thread that read this article and felt similar.

Not even that old, and i feel it every damned day...

I think you're over-romantascizing the past here.

Linux dropped the cost of using UNIX down to zero. And it's not like everything was this cross-UNIX Utopia where things worked from system to system consistently and reliably.

We went from a set of highly proprietary and expensive OSes that ran on hardware that a common person had no access to to something that nearly anyone can use.

That's way more important than having to adjust your skill set for new tools over time!

> Linux dropped the cost of using UNIX down to zero.

"Linux is only free if your time has no value."

I've been using it personally and professionally for over 20 years now. Unless you're specifically using the term "cost" to mean solely money, it is in no conceivable way without cost. There is, for example, a significant cognitive burden involved in keeping up with the ceaseless parade of travesties committed by people trying to "make things better" in Linux, who instead just compromise the system for those of us who disagree with their notions of betterness.

I'm reminded entirely too much by some corners of the Linux community of Apple's "We know what users want, and give it to them good and hard" attitude.

> Linux dropped the cost of using UNIX down to zero.

BSD had already done that, better, and earlier. Let's not try to rewrite history.

Not true. AT&T claimed that the free versions of BSD violated their copyright on Unix with the result that even though anyone could download and install BSD at no cost, you never knew whether a court ruling would make your continuing to use it legally risky (at least if you want to use it in an enterprise or keep it connected to the net).

The legality of the free versions of BSD did not get resolved till there were many Linux users -- probably more Linux users than there were users of the free BSDs.

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 did support it, with no need to replace the entire audio API.

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).

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.

"and presumably other BSDs"

That is indeed correct in the case of OpenBSD. Halfway rolling my eyes at the article's assertion that it's better to write a new tool than actually bother to maintain the existing one when it's very possible for ifconfig to be a one-stop shop for, you know, interface configuration.

rolling new rather than maintaining is epidemics within the Linux world. One that most users are insulated from thanks to the hard work of distros for the most part.

> I don't think (but could be wrong) that there's a nice machine readable way to get this information.

Typically (on bsd-derived systems) there a clearly defined kernel IOCTL interface for any given mechanism is created when it is implemented along with with specific c-structs which can be used to query and configure the interface; the core tools are then added to the system or modified to use this interface (rather than publishing text files from proc that an optional 3rd party package then uses ) - depending on the importance of the api people then tend to write language bindings (or a standalone library which in turn has language bindings) for this or somesuch.

etc.

The summary is: ifconfig output format does not support new networking features like IP aliases[0]. Changing the output format would break many scripts, so ifconfig will not be changed.

[0] It does support "interface aliases" and that seems to be something different

Removing ifconfig (the implied end-goal of deprecating it) would also break many scripts.

BSD's ifconfig isn't really related to Linux's ifconfig anymore because BSD has continued development and the Linux fork or version (don't remember which it is anymore) hasn't.

Linux's ifconfig is a part of net-tools (http://net-tools.sourceforge.net/) and the latest release of net-tools, v1.6, was released in April 2001. It's been unmaintained for over 17 years. Some distros began deprecating ifconfig when the Linux 2.2 kernel was released because it lacked features. The Linux ifconfig command doesn't support wireless network devices because they essentially didn't exists when the the command was written. Shit's old.

It's like comparing Seamonkey to Netscape Communicator.

> BSD's ifconfig isn't really related to Linux's ifconfig anymore because BSD has continued development and the Linux fork or version (don't remember which it is anymore) hasn't.

There's a simple solution to the lack of maintenance on ifconfig: Maintain ifconfig.

There's no need to break shit.

It's open source. Feel free. I'd expect there are significant architectural differences between Linux and BSD by this point, though, that would make it quite a challenge. Alternately, it might be like adding major new features to Xorg: possible but extremely challenging.

My understanding is that the Linux version of net-tools was based on the BSD software, but I don't know how much code is actually shared between the two projects. It was intended to be syntactically equivalent and support the same features (at the time). You'd probably find it easier to write a net-tools-like wrapper for iproute2.

Yes, someone could have just extended net-tools. But nobody did. Instead, they wrote iwconfig and other tools when they were needed, and then someone decided to write a competing package, iproute2, that did everything. And that package added feature support when they were added them to the kernel, and bugs got fixed. Those didn't happen with net-tools unless each distro took care of it.

https://lwn.net/Articles/710533/

> It's open source. Feel free.

I use BSD. And while I would send in patches for ifconfig, I haven't needed to. I have sent in patches for other things.

> It's been unmaintained for over 17 years.

So is the Linux ecosystem just going to rewrite tools everytime their original developer moves on or passes away? It's going to happen more in the future, so are we going to see more and more rewrites in Linux?

There's something to be said about the BSD approach of maintaining the OS (kernel + userland) as a whole. They don't seem to have this problem.

One great thinker gave a very clear view of what is going on in so many open source projects:

https://www.jwz.org/doc/cadt.html

I prefer fixing bugs to rewriting. Anyone want to hire me? /semi-sarcastic

Maybe Linux distros should look into using BSD's ifconfig as their upstream.

So Debian can remove mysql and alias it to mariadb (with all kinds of interesting side-effects), but nobody thought to fork net-tools in order to actually maintain it, but instead decided to write something from scratch?

I'm all for the new tools (and actually prefer ip over ifconfig).

However, they really screwed up with ss: the output is really unusable/unreadable.

This really only becomes obvious when you pass the -p flag, where the program information is printed on its own line.

It gets slightly better if you pipe the output through cat: now the program information is printed on the same line, but the column spacing is incorrect instead.

On the other hand it's nice that they kept compatibility, at least for the most common flags (e.g. -nltp does the same thing in both).

>This really only becomes obvious when you pass the -p flag, where the program information is printed on its own line.

It isn't on its own line, it's just wrapped so grep works properly.

>but the column spacing is incorrect instead.

ss output is column-based so it is useless to bother with tools like cat for parsing.

ss -p | less -S is the simplest solution for you

What? No.

First: Apparently the ss developer(s) decided to finally fix the output in some recent version (it was changed to behave sanely somewhere between iproute2-ss161212 and iproute2-ss180402).

However, if you're stuck with an older version, what I said still stands, and the below applies to those versions:

> It isn't on its own line, it's just wrapped so grep works properly.

While technically correct, that doesn't really matter in any practical sense, because the columns are padded so that the final column containing the program is wrapped onto the next line.

When ss stdout is connected to a pipe it will produce different output: this output is much less wide, so that the program name fits onto the same line as the rest of the columns. But, as said previously, it screws up the alignment of the columns, making it impossible to quickly scan them (using your eyes).

> ss output is column-based so it is useless to bother with tools like cat for parsing.

What? cat doesn't do any parsing. The only reason for using cat there is to connect ss' stdout to a pipe and thus trigger its different output.

> ss -p | less -S is the simplest solution for you

No. '| less -S' gives no improvement over '| cat', since ss output fits onto one line without wrapping as soon as you pipe it through any other program. An actual improvement would be to instead use '| column -t', which would (mostly) fix issues with misaligned columns.

Anyway, if you can, just use a modern enough ss instead (not sure when it was fixed, but iproute2-ss180402 (iproute2 4.16.0) is definitely new enough), which has sane output regardless of whether stdout is connected to a pipe or terminal.

I've lost much muscle memory and skill with newer systems.

When I was younger I had time for deep dives into configs/manuals/googles/mailthreads. These days my job assumes I know all the stuff and ins and outs, not having a good time re-learning everything I already know how to do...

It's not new anymore and gives no joy for learning new things, no time to do it either. It sucks.

Yeah I don’t buy into the idea that because there were some under-the-hood changes that had to be made, that means the whole application has to be thrown away and a new interface re-written. I don’t believe for a second that these developers couldn’t have dropped in a new backend and mapped the same commands to it.

Putting a shinier coat of paint on the command line isn’t going to attract a wider audience, it’s just going to piss off the only people who actually use the command line regularly. The CLI is the last place you want “change for the sake of change”.

IMO, it's because understanding someone else's code and introducing your own changes is something that requires a considerable amount of experience and knowledge which many new developers have not acquired yet. Instead of trying to take the time to understand how to integrate the changes they're trying to make with an existing project, they create something new practically centered around this new feature and a lot of stuff gets lost along the way.

At the end of the day, it's fine though. It'll either satisfy the needs of people and become a new standard or it will be satisfy edge cases and become the new thing that needs to be deprecated because no-one contributes to the project and the original maintainer has lost interest.

While unrelated to subj or that new systemd wave, I want to state that almost all my sysadm skills are lost. Idk who is responsible for this and if they exists, or is it just time going, but I’m not a power user anymore. Long-term skill investments without a profession are so meaningless – ten years and you stare at the screen with no idea what to do. That was hard time and now it is all for nothing.

I am happy to reinvest the time if the new way is significantly better, it would be worth it. But it never is, someone just got bored and decided to reinvent the wheel. Probably while thinking that they were inventing it for the first time. And we all get dragged along.

But it was adopted on it's merits and not because of politics! /s

If you were a productive unix sysadmin in 2008 you are a productive unix sysadmin in 2018. Its just that Linux is no longer unix-like and you've switched from using, perhaps, Debian install media in '08 to FreeBSD install media in '18. Its not really that big of a problem. Its much easier and more productive to switch to FreeBSD than to switch to ... whatever it is Linux is becoming.

> If you were a productive unix sysadmin in 2008 you are a productive unix sysadmin in 2018.

Unless you mention Perl to someone now, and that someone might be 10 years younger but still your manager, and they look at you like you just spoke greek.

Ha ha! Perl has become the shit test for whether I feel like dealing with certain people. "Oh, you don't use Perl?...." Not everyone, just certain ones.

It's pretty clear that ip is the superior and more modern tool, i believe they could work on the presentation layer of the software tho... its output pales compared to ifconfig, as other peers have stated.

that's what really gives us grumpy old sysadmins the kneejerk reactions. every time i log into a system and i have to tipo "ip a" i need to stop and try to slowly decode the unformatted soup letter that is presented instead of a nicelly formatted table like on ifconfig.

I hear this argument a lot: this or that is the "more modern tool." The problem is I almost never see the benefits in the same way I can tell how, say, a battery-powered nail gun is superior to hammering hand-held nails. Usually it's just a hammer with a cross peen instead of a claw, painted a different color.

Isn't the described mismatch between "reality" and what ifconfig reports once again a case of systemd (networkd) not exposing IP aliases in the traditional way, and replacing established network concepts by it's own stuff? Meant as a genuine question rather than trolling (though I know I'd hate to bow to whatever systemd comes up with rather than just using ifconfig which has worked since the begin of times) eg. there might be a material problem here in how network interfaces are presented by ifconfig.

No. systemd has nothing to do with this. the issue has existed long before systemd. it's the kernel that changed to allow interfaces to have alias addresses.

Not that I know. Systemd itself doesn't manage networking (resolved, networkd and other services do that instead under the SD umbrella).

But those work (to my knowledge) just like before (unless you setup private networking or otherwise container the thing). They just work differently on the surface.

I wouldn't know of a way of exposing IP aliases in a non-traditional way as the kernel needs to know them either way.

No. The Linux kernel has two APIs, and has had since before systemd even existed. ifconfig uses the ioctl() API, which presents the concept of alias IP addresses in one way. ip uses the netlink API, which presents the concept of multiple IP addresses per interface in a different way. M. Siebenmann did include this point.

* https://sourceforge.net/p/net-tools/bugs/12/

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359676

This begs the question of why the kernel doesn't allocate an alias for backwards compatibility when adding IP adresses through the netlink API.

I think they are fundamentally different things. Correct me if I’m wrong, but I think a netlink alias is just an additional address and an old-school alias is more like a virtual interface.

Fortunately, not in this particular case - it's just a question of incompatibility between the two APIs. If you create an alias by ifconfig eth0:0, it will be visible by ifconfig. If you add a NIC:n entry to /etc/network/interfaces, ifconfig will display it. I don't believe this API will ever get obsoleted as millions of systems use it that way.

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.

I feel like systemctl and journalctl are the same way. They are terrible commands with awful usability. Having a full process control system is nice and helpful when writing a package once for several platforms, but I wish something had caught on that had better usability and didn't try to do everything from login management to filesystem mounting, but rather just process management.

Where as someone could probably write a newer drop in ifconfig that uses modern kernel APIs, several people have tried to for systemd and it's just so massive no fork can keep up anymore and almost all have been abandoned.

systemd has decided for you that these commands are better. It is now your responsibility to accept their decisions.

Are they really "terrible" with "awful usability"? In my day-to-day debugging, I do find `journalctl` much better. Let's see a couple of quick examples:

- Show logs for the current boot: $ journalctl -b

- To get all errors that are of priority level ERROR and worse: $ journalctl -b -p err

- Show me logs for a given binary: $ journalctl /usr/sbin/libvirtd

- Or via its unit file: $ journalctl -u libvirtd -l

- Want to query all the errors for a given disk? Here we go: $ journalctl /dev/sda -p err

And so on...

I quite like journalctl, but the naming could be better. 'system' means OS, and kernel, and init system, and computer, and many other things. 'start-service' would have been better.

The worst is 'system-cat' to send a log message (SysVInit used 'logger'). Why not just 'log'?

Yes that is an awful soup of switches that should either be separate commands or usages of existing Unix tools.

Ok, then you've traded one command with switches for multiple commands each with their own set of switches (and almost certainly following different switch 'standards'). I like systemctl/journalctl for cleaning up that mess, even if it requires me to learn how to use them.

Then you will have an awful salad of separate commands that you have to juggle around. I am all for "UNIX philosophy" within reason; it has its bounds, let us not over-romanticize it.

I have embraced systemctl, and it's intuitive to me, but I feel the way you do about journalctl.

If I want to tail the log of a service, though, there's a mnemonic for that: 'journalctl -fu httpd' - that one sure is easy to remember!

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 alias (made with ifconfig eth0:1 xx.xx.xx.xx up), but the "eth0:1" type alias seems infinitely more useful.

This is also a major deficiency of the Ubuntu 18.04 netplan implementation, it can only do the systemd.networkd type aliases and not the "eth0:1" type ones. What gives?

> What are people using them for?

In my case, keepalived VRRP floating addresses.

Yep. It was kind of funny watching a couple graybeards trying to figure out how keepalived was assigning addresses and how to view them. It’s a rare treat when you can help someone like that with something they might normally help you with.

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

Dont know, but when I used to do index arb trading they had vlans on virtual IPs on bonds and ifconfig simply couldn't show the addresses. 'ip' could

Yeah, your eth0:xx is just a label (a tag of sorts) attached to the entry. Otherwise, they're exactly the same thing.

You can even add an address with `ip addr add' that will be visible to ifconfig.

People don't seem to use them on Linux for containers, but on FreeBSD that was the way to set up IP addresses for jails. You just had tons of aliases on an interface and you gave these IPs to jails. Anything that binds to 0.0.0.0 inside a jail gets bound to the jail's IP.

Now you can use VNET/VIMAGE to give jails separate virtual network interfaces. If you want to. The option to use aliases is still there of course.

In many cases, the IP is the thing that comes first and foremost. You'll put it in DNS, you'll bind services to it (often because that's what the DNS is pointing to) or use it for outgoing traffic, and so on. Any interface name for it is simply an implementation detail, and you can live without it and even simplify your life if you don't have to come up with and keep track of those names.

(This is especially the case if you may at some point shift an IP alias between systems in order to move traffic from one to the other.)

FreeBSD just lists those IPs under the interface.

this makes it sound like the only thing ip does is replace ifconfig which is not the case. It is more like like a go to application to manage the network stack to some degree. You can set up various tunnel interfaces, vlans, routes, routing rules, IPsec policies, network namespaces and more. Learning how to deal with it gets you quite far. Learning how to read the help output is often enough to understand everything and definitely worth the effort, even if all you want to do is to show the assigned IP addresses...

I also appreciate very much the mostly consistent syntax for various sub commands. Its often an easy guess to know how to do what...

Learning how to read the help output is often enough

I find the 'ip --help' is virtually incomprehensible, and the man page no better. There's no explanation about what the tool can do, only some machine-readable formatting of the syntax expected. This kind of documentation is useless IMO, it's actively hostile to new users.

the help gets more specific the more complete your command gets. Try "ip link add type vlan help" for example. While i agree it does nothing to explain what the various switches do, if you know what you are trying to achieve this is most of the time enough.

However i do not agree about the man pages the switches are explained there in enough detail in my opinion...

The switches are useless until you have an idea about what the command can do. And yet the 'IP - COMMAND SYNTAX' section has text like 'link - network device'. What the hell does that mean? So 'ip link' does what exactly? Could the developers have typed more than just two words to try to explain this command (action?) Good luck to anyone who decides to RTFM.

SEE ALSO: ip-link(8)

You have to read the manual too ;)

The tool allows one to manipulate kernel objects more or less 1:1, so documentation and help of 'ip' and 'tc' is adequate enough if you know what those kernel objects are and how they behave, but it won't help if you don't know anything about linux networking or traffic shaping in the first place.

What's the best way to learn these things?

LWN ( https://lwn.net/Kernel/Index/#Networking ), LWN + kernel documentation ( https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... ) , more LWN + iproute2 source/news/commitlog ( https://git.kernel.org/pub/scm/network/iproute2/iproute2.git... and https://git.kernel.org/pub/scm/network/iproute2/iproute2.git... << basically the names will give you what to search for on LWN ), and a bit more reading ( https://www.netdevconf.org/ )

... and trying them (the features) out. In VMs and in other network simulators. ( http://mininet.org/overview/ comes to mind, but simply using Vagrant / Virtualbox is okay )

Also, networking is very standardized (duh :)), so if you follow network related stuff ( https://www.reddit.com/r/networking/ ), you can sort of get a feel for what might come to the Linux kernel.

LWN is still the best in this regard, because it deals with new developments, so reading the archives will tell you what might be in the kernel.

Furthermore, since nowadays everything is kube-cloud-virtual-container-open-netes-stack, looking at network developments for these technologies will get you in the know. (Seemingly bonkers stuff, like BGP for containers is now bog standard with things like Calico. Running a full switch in kernel with an awesome distributed overlay network for "cloud" without OpenFlow? OVN by OVS got your back. Doing all this fast? DPDK is uber fast, but XDP is just so conveniently clever.)

Plus there's the datacenter networking stuff, like TRILL/SPB ( https://networkingnerd.net/2016/05/11/the-death-of-trill/ ), but those haven't got integrated into the kernel, because the aforementioned Calico, OVN and other overlay stuff.

Oh, and the best way is to keep asking questions!

I'm sure you mean well, but this comment epitomizes the problem. Formerly, Unix was fairly modular, open to comprehension, and had excellent documentation guiding the user. Now, everyone who isn't a paying Red Hat support customer is not just on their own but thrown to the wolves.

But why would anyone be on their own in the age of stackoverflow and a thousand other user support avenues.

And there are good books and endless awesome posts/blogs about Linux. The new low level stuff is not covered as well obviously. (And I think it's a shame devs don't communicate well, but they are not perfect, nor they are paid for writing good docs, only for code.)

Furthermore, was the modularity of Unix ever really exercised? Are there success stories replacing dd, cp, ls, or parts of lower level stuff?

The real reason there is drift in Linux tooling is because there are two communities making tools for Linux (GNU and Linux Foundation associated projects) and the two groups seem to find new reasons to hate each other every year. It’s a dumb reason for tooling to drift, but an understandable reason. I have a feeling that ifconfig and netstat will keep up fine, but that the party line will be that they are deprecated.

Yeah, SysV init is still around, udev has been renamed eudev and is still being developed, etc. Don't tell anyone in Linux officialdom, though. It upsets them.

What's all the fuzz about this "sudden" change? iproute2 is part of linux (kernel) since 1999 or so.

It promptly got filed under "ah, learn that one day", then after coming up enough times got relegated to "ugh, stop bothering me about it, I'll get to it eventually" and everyone has been un-motivated-ly unimpressed about it ever since.

I think.

FWIW I can usually never get ifconfig to do what I want it to, but with ip it's usually fairly straight-forward.

Archlinux ships this as default now (and has for about a year) and I think Ubuntu is doing the same. Thus people are increasingly being exposed to iproute2.

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.

Why did they have to make the output of `ss` so cumbersome? I often end up installing the legacy tooling just so I can have `netstat`

I'm a fan of 'lsof -i', in fact of lsof for anything. Makes lots of sense to treat network sockets and files as equals: that's the big idea of UNIX.

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).

I'd appreciate it... would also make generating pretty UIs around console applications easier as well.

Powershell is on linux now... ;)

The most underrated tool barely used outside of Windows sysadmin world.

In what capacity is Powershell something other than just another shell (of your choice)? Feela like Windows finally got a real CLI for API stuff - and O am glad this happened - but it's not really any different than csh, bash, zsh et cetera. A shell as a lower-level interface to your OS.

The main selling point of PowerShell is that you cannot save intermediate results of a pipeline to a file for inspection.

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.

For the avoidance of doubt, this is not the official iproute2 repo.

This is the official one: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git

I noticed some shortcomings in ifconfig (only shows the first ip assigned to an interface if a NIC has many) so in some senses i see why it had to be updated, by i see no logical reason why both the command and the syntaxes had to change? Why not stick to the parameter standard at least?

if you're changing underlying functionality, you'll have to change at least some of those parameters ("show me the first IP address" of an interface might be a contrived example). So now you have the option to slightly change the parameters and keep some, but not all of the behavior, maybe even in a slightly different way or you can have a clean break and clean up the old parameter list with all its accumulated cruft and go for a designed and thought-out interface.

The new interface is close to plain english in most common cases, so I'd say it's a significant win.

M. Siebenmann's actual main point, ignored by much of the "I do/do not like ip/ifconfig." discussion here, is that it is valid to replace ifconfig because the standard output of the command is an interface contract that is set in stone because of people using it in scripts.

I disagree, on two grounds.

Firstly, the ifconfig commands in the BSDs are existence proofs that this is not so. The BSD people actually have modified ifconfig to keep up with changing kernel networking abilities, and one will find the (say) FreeBSD ifconfig of today having a lot more functionality than the Linux one. The BSDs, by their very natures, kept their ifconfig tools aligned with the rest of the operating system as it changed.

* https://freebsd.org/cgi/man.cgi?query=ifconfig

* https://linux.die.net/man/8/ifconfig

* https://unix.stackexchange.com/questions/319350/

Secondly, an aversion to breaking (badly designed) scripts is isn't really the reason that ifconfig hasn't been changed. The reason that ifconfig hasn't been changed, as evident from the net-tools bug and other discussions of this, one of which I have hyperlinked elsewhere in this discussion, is more to do with (purportedly) doing things portably and not having two disjoint code paths, one for Linux using netlink and one for everything else using ioctl. Two code paths and code that was not portable to other operating systems would be the result of adding netlink capability to net-tools's ifconfig.

That reason does not itself hold water, however. The net-tools package is highly Linux-specific anyway, in the first place, so arguments about its portability are moot. Given that, the actually expressed reason for not doing this given by the developers themselves (as opposed to the differing reasons inferred by people other than the developers, the most often given one of which is directly contradicted by git repository activity as recent as 2016) founders.

* https://github.com/ecki/net-tools/commits/master

One of the more disappointing things about Linux's ifconfig is that this:

    # ifconfig lo inet6 ::1
    Don't know how to set addresses for family 10.
    #

is a fairly trivial oversight in a case statement in the code, a missing case for AF_INET6, rather than a fundamental design or implementation problem, and doesn't even need the netlink API to fix.

* https://sourceforge.net/p/net-tools/code/ci/master/tree/ifco...

(It took me a sec to realize you were using the verb "founder".)

Excellent point.

Maybe in new tools they should randomly change the formatting every run so that people can't parse the output.

I find it more frustrating that network configuration tools seem to be added in layer after layer, like with the new netplan took in Ubuntu. To me it seems more complex than it needs to be.

new netplan took in Ubuntu

Having fought that monstrosity very recently, I completely agree. The homepage of its site looks more like a marketing blurb than anything else, and everything about it has an unpleasant "enterprisey" feel to it. I don't care about YAML or "abstract network renderers" or whatever buzzword-compliance bingo it claims to support, I just want to configure one NIC for one static IP.

The fact that Windows' networking configuration is actually easier than on "modern Linux" should be a sign that something has gone horribly wrong.

Well "replace" sounds very serious; but in fact iproute2 has been here long enough to have replaced stuff already. I didn't really consider myself to be a "grumpy old admin", but now I do, having used ip a lot back in 2003. I mean. 14 years have passed since I first used a mature! thing. And some people call ip fresh...

I've perceived an acceleration in the rate of these changes in the last 2-3 years, and have started to put at least some of it down to Linux having annihilated most of the competition in the UNIX server space.

With Solaris now headed for retirement and most of the rest of the SysV ecosystem having collapsed over the preceding 20 years or so, it makes it easier for companies like Redhat to "innovate" in new directions with less pressure from developers and sysadmins alike.

I'm not sure how much of this is just my imagination, but the rate at which "old world" UNIX commands and subsystems are being replaced or supplanted in Linux certainly seems to have increased.

I agree with the author that some of these changes are forced by the development in the kernel itself, but I consider that part of the same phenomenon I guess.

Bookmark https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...

This sort of thing is the reason I never use Linux for anything more serious than a laptop. It's impossible to know when a new table like this will become necessary to do really basic stuff that I already learned how to do years ago.

I am not sure it is such a big deal, the old stuff are good enough for the majority of cases, I reckon. He has probably a good point about performance, but pain versus gain I am not sure it makes a lot of sense, on average.

Ok. Fully admit, old unofficial sysadmin here (50, started with computers at 10 - and I don't work as a sysadmin, but often wind up helping our sysadmin who has less experience). ifconfig, netstat, lsof are some of my top go to tools. I haven't learned the iproute suite of tools yet, but this article is prompting me to start doing that. It will be hard, my memory is fuzzy on when net-tools commands first came out..I remember using Slackware in mid 90s, but don't remember if they were in there yet, but I think I've maybe been using them for 20 years, or close to it.

Back in 2005 I was actually wondering why ipsuite wasn't part of standard Debian, tbh, which at the time was very big in the networking world

So https://netplan.io/ was invented to replace them right?

More and more it seems that smaller users of Linux gets the shaft to placate the needs of the cloud behemoths...

the output of 'ip address' is so much harder to parse, visually :/

As I opened this article, I thought "I bet this is going to be related to some Goddamned systemd change".

And sure enough, about halfway through:

>This interface has an IP alias, set up through systemd's networkd.

The amount of pain and headache this init-kitchen-sink-wannabe-thing has caused me day-to-day is incalculable.

Of course, that does not say that this was a systemd change, and reading this very discussion at https://news.ycombinator.com/item?id=17151686 shows that you lose your bet.

Multiple IP addresses on an interface have been a thing since long before systemd existed.

I remember using iproute2 to add multiple IP addresses to devices at my very first job in 2007. systemd didn't even come out until 2010.

ifc TAB ENTER is just so much faster then ip addr.

I'm still used to typing ifconfig just out of muscle memory, but ip seems to very loosely match

"ip a" will be matched the same as "ip addr" or "ip address"

Learning that made me much more accepting of the new command

systemd is like the rajneeshpuram of Unix. first it's the init scripts, now they want to take away ifconfig.

ask the people of Oregon how this will all work out...

"... 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 does not mean bad but Linux chooses that path as it moves further away from UNIX and being a Unix-like system in its pursuit to be Windows.

I would like to argue with you, but then again, systemd exists (and is thriving) while being the most windows-like software existing by default on all popular linux distributions.

EDIT: I guess I have to clarify this statement a little; In Windows the concept of "logging" is up to the event manager, this mirrors journalctl. To be more precise they seem to focus on desktop operating systems with an example being the unit file itself: "The syntax is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files.", maybe you prefer talking about firewalld and it's "Zones" which are clearly inspired by desktop use. (Laptops more specifically).

There was something that I'm forgetting though, a terminology that was only used by microsoft to describe something and systemd used exactly the same terminology. It was very esoteric terminology though, I'm trying to find a reference.

> "Old does not mean bad"

It doesn't automatically mean "good" either.

> "in its pursuit to be Windows"

Would you please elaborate?

Windows subsumes a lot of small network daemons into a monolithic process called SVCHOST.EXE.

Systemd does a similar thing.

What are you talking about? Systemd (pid 1) just does socket activation, it has no high level functionality. Yes, there are related programs like systemd-timesyncd, but they are completely separate processes, and can be managed separately and even omitted altogether.

Now, traditional BSD inetd had discard, chargen, echo, ... protocol support, which means that it was actually more integrated that systemd.

A bird in the hand is worth two in the bush. The article speaks of old software but, instead of fixing what it has and being standards compliant, it chooses to break away and do its own thing along with the new bugs and other issues which will surely arise.

> "instead of fixing what it has and being standards compliant, it chooses to break away and do its own thing along with the new bugs and other issues which will surely arise."

Well, people are still free to maintain and improve those older tools and bring them up to par with newer standards, if they want to.

Others would argue it's time to start phasing out code and so-called "standards" we've had since the early 90s in spirit of refactoring various elements in the ecosystem. As with most such efforts - lots of code will be thrown away, some of it will be re-used and re-purposed. I'd argue that in the long run - it's probably a necessary intervention.

They don't need to change the frontend to change the backend. There's a certain cognitive load to having to re-learn basic commands, and a certain annoyance when those changes are of little benefit to my day-to-day sysadmin duties.

"others" would be right, but the present team doing the refactoring is actively, aggressively incompetent, doesn't listen to even constructive feedback, closes critical bugs with snarky comments, refuses outside contributions, claim outside contributions are literally impossible, and absorbs independent functionality in the name of empire building.

So the notional idea of 'refactoring' being better -- yes! But with the constraint being that the people doing the refactoring have to be at least as wise, tasteful, mature, sensible, and thoughtful as the people who came before.

Do I have to state the obvious? This is an open source effort. Not all attempts at persuasion bear fruit. If you feel you are being ignored (by what would appear is a group of maintainers you absolutely despise), I guess the other option would be to fork the repo. This would not be the first time in history people split code over disagreements.

Unfortunately, Red Hat have politically suborned all of the major distributions, and have rapidly and effectively created dependencies between their solution and other codebases in a transparent effort to create and maintain lock-in and to build barriers against the 'fork' strategy.

As in everything else important, there is a balance to be stricken between stagnation and upheaval.

When choosing platforms, how communities weigh this balance is a very important consideration. You want to associate with people and groups who value essentially the "reasonable breeze" mode that keeps life flowing through extant systems. "Natural disasters" may sometimes be justified to help clear out the way-too-old (e.g. systemd or SMF), but they should be rare; systems can only tolerate major disruptions like that once or twice a decade.

Linux has an "anything goes" approach, which is usually more symptomatic of the age/maturity of the crowd it draws in than a reasoned decision about where to fall on this balance. That's not necessarily bad, but it makes more of an experimental atmosphere than something reliable, trusted, and stable.

“GNU's Not Unix”. Don't say they didn't warn you.

the argument that applications using standard files must be update to another api is BS.

the kernel should just map the faster api on those standard file descriptions instead... but then, the "old" files were not part of a standard to begin with... but then again, the standard, whatever it is, was never designed but agreed upon after being in use by enough people.

I have no idea what to make of this. I guess I am just happy that people are moving things forward, whatever the direction.

ifconfig is obsolete for how long? 14 years or so? :)

Yeah damn idiots broke ifconfig so it already misses some interfaces. Just say no to this insanity.

Reply on news.ycombinator.com