Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

utcc.utoronto.ca

Post reply on HN
Print view View original

261–270 of 270 posts

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

#261

Post by pas »

felixgallo wrote: post #159
pas wrote: post #45

Earlier quoted context omitted.

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... https://www.netdevconf.org/ ) ... and trying them (the features) out. In VMs and in other network…

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?

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

#262

Post by bayindirh »

65a wrote: post #235
brian_cunnie wrote: post #157

Earlier quoted context omitted.

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…

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.

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

#263

Post by [deleted] »

linsomniac wrote: post #139
iod wrote: post #58

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 eth0 DOWN 00:12:34:56:78:9a wlan0 UP 12:34:56:78:9a:bc

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.

[deleted]

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

#264

Post by nineteen999 »

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.

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

#265

Post by nineteen999 »

sanjayjc wrote: post #205
OnMyPhone wrote: post #118

Earlier quoted context omitted.

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

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

#266

Post by twic »

amyjess wrote: post #154
Izkata wrote: post #64

Earlier quoted context omitted.

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

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
    }

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

#267

Post by twic »

sdfgdfhjdgj wrote: post #171
hiccuphippo wrote: post #149

Earlier quoted context omitted.

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.

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

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

#268

Post by emmelaich »

rootbear wrote: post #84
bayindirh wrote: post #51

Earlier quoted context omitted.

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…

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.

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.

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

#269

Post by emmelaich »

brian_cunnie wrote: post #157
rootbear wrote: post #84

Earlier quoted context omitted.

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 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…

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)

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

#270

Post by aepiepaey »

mandelbulb wrote: post #127
aepiepaey wrote: post #10

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…

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

Post reply on HN