Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Network Networking Operating Systems Linux

There Are Real Reasons For Linux To Replace ifconfig, netstat and Other Classic Tools (utoronto.ca) 478

Several readers have shared a blog post: One of the ongoing system administration controversies in Linux is that there is an ongoing effort to obsolete the old, cross-Unix standard network administration and diagnosis commands of ifconfig, netstat and the like and replace them with fresh new Linux specific things like ss and the ip suite. Old sysadmins are generally grumpy about this; they consider it yet another sign of Linux's 'not invented here' attitude that sees Linux breaking from well-established Unix norms to go its own way. Although I'm an old sysadmin myself, I don't have this reaction. Instead, I think that it might be both sensible and honest for Linux to go off in this direction. There are two reasons for this, one ostensible and one subtle.

The ostensible surface issue is that the current code for netstat, ifconfig, and so on operates in an inefficient way. Per various people, netstat et al operate by reading various files in /proc, and doing this is not the most efficient thing in the world (either on the kernel side or on netstat's side). You won't notice this on a small system, but apparently there are real impacts on large ones. Modern commands like ss and ip use Linux's netlink sockets, which are much more efficient. In theory netstat, ifconfig, and company could be rewritten to use netlink too; in practice this doesn't seem to have happened and there may be political issues involving different groups of developers with different opinions on which way to go.

(Netstat and ifconfig are part of net-tools, while ss and ip are part of iproute2.)

However, the deeper issue is the interface that netstat, ifconfig, and company present to users. In practice, these commands are caught between two masters. On the one hand, the information the tools present and the questions they let us ask are deeply intertwined with how the kernel itself does networking, and in general the tools are very much supposed to report the kernel's reality. On the other hand, the users expect netstat, ifconfig and so on to have their traditional interface (in terms of output, command line arguments, and so on); any number of scripts and tools fish things out of ifconfig output, for example. As the Linux kernel has changed how it does networking, this has presented things like ifconfig with a deep conflict; their traditional output is no longer necessarily an accurate representation of reality.

This discussion has been archived. No new comments can be posted.

There Are Real Reasons For Linux To Replace ifconfig, netstat and Other Classic Tools

Comments Filter:
  • So (Score:5, Insightful)

    by ArchieBunker ( 132337 ) on Sunday May 27, 2018 @11:04AM (#56682972) Homepage

    keep the command names the same but rewrite how they function? Nah makes too much fucking sense. I've had distros where my default route wasn't working and traceroute wasn't even installed by default. Talk about a shit show. What was the reason for replacing "route" anyhow? It's worked for decades and done one thing.

    • Re:So (Score:5, Interesting)

      by jfdavis668 ( 1414919 ) on Sunday May 27, 2018 @11:09AM (#56682996)
      Traceroute is disabled on every network I work with to prevent intruders from determining the network structure. Real pain in the neck, but one of those things we face to secure systems.
      • Re: (Score:2, Insightful)

        by Anonymous Coward

        What is the point? If an intruder is already there couldn't they just upload their own binary?

        • Re:So (Score:5, Interesting)

          by Hylandr ( 813770 ) on Sunday May 27, 2018 @05:57PM (#56685274)

          They can easily. And often time will compile their own tools, versions of Apache, etc..

          At best it slows down incident response and resolution while doing nothing to prevent discovery of their networks. If you only use Vlans to segregate your architecture you're boned.

      • Re:So (Score:5, Interesting)

        by gweihir ( 88907 ) on Sunday May 27, 2018 @12:19PM (#56683422)

        Also really stupid. A competent attacker (and only those manage it into your network, right?) is not even slowed down by things like this.

      • Re:So (Score:4, Interesting)

        by bferrell ( 253291 ) on Sunday May 27, 2018 @12:20PM (#56683430) Homepage Journal

        except it DOESN'T secure anything, simply renders things a little more obscure... Since when is obscurity security?

        • Doing something to make things more difficult for a hacker is better than doing nothing to make things more difficult for a hacker. Unless you're lazy, as many of these things should be done as possible.
          • Re:So (Score:5, Insightful)

            by DamnOregonian ( 963763 ) on Sunday May 27, 2018 @04:37PM (#56684878)
            No.
            Things like this don't slow down "hackers" with even a modicum of network knowledge inside of a functioning network.
            What they do slow down is your ability to troubleshoot network problems.
            Breaking into a network is a slow process. Slow and precise. Trying to fix problems is a fast reactionary process. Who do you really think you're hurting?
            Yes another example of how ignorant opinions can become common sense.
    • by raymorris ( 2726007 ) on Sunday May 27, 2018 @11:10AM (#56683002) Journal

      A LOT of scripts use ifconfig and friends. Changing them would be bad, imho. Better would be to call it ifconfig6 or whatever if you're going to change the output or the meaning of commands, so you don't break existing scripts.

      In general, it's better for application programs, including scripts to use an application programming interface (API) such as /proc, rather than a user interface such as ifconfig, but in reality tons of scripts do use ifconfig and such.

      • In general, it's better for application programs, including scripts to use an application programming interface (API) such as /proc, rather than a user interface such as ifconfig, but in reality tons of scripts do use ifconfig and such.

        ...and they have no other choice, and shell scripting is a central feature of UNIX.

        The problem isn't so much new tools as new tools that suck. If I just type ifconfig it will show me the state of all the active interfaces on the system. If I type ifconfig interface I get back pretty much everything I want to know about it. If I want to get the same data back with the ip tool, not only can't I, but I have to type multiple commands, with far more complex arguments.

        The problem isn't new tools. It's crap tools.

        • by gweihir ( 88907 ) on Sunday May 27, 2018 @12:22PM (#56683440)

          The problem isn't new tools. It's crap tools.

          Crap tools written by morons with huge egos and rather mediocre skills. Happens time and again an the only sane answer to these people is "no". Good new tools also do not have to be pushed on anybody, they can compete on merit. As soon as there is pressure to use something new though, you can be sure it is inferior.

          • Crap tools written by morons with huge egos and rather mediocre skills.

            ...with the backing of companies with a large clout in the Linux community... like Pottering. Without Red Hat, Pottering would be a forgotten, ridiculed developer nobody would pay attention to.

          • Eh. The author of the article is correct, though.
            ifconfig, route, and netstat are insufficient for an actual view of reality within the networking stack.

            This isn't a good argument for *getting rid of* those tools, by any means (and I still install them all on any RHEL7 machine I'm deploying) but iproute2 is necessary for any kind of advanced networking.
          • by slack_justyb ( 862874 ) on Sunday May 27, 2018 @07:45PM (#56685728)

            Good new tools also do not have to be pushed on anybody, they can compete on merit

            That's exactly what happened with the new tools. The new tools are insanely better by every single measure possible. The code is incredibly clean and well maintained, everything in net-tools uses old, slow, and poorly maintained code. Hell even the people who maintain net-tools don't want to maintain net-tools. We already had the competition and the new tools won out hand over fist. I know everyone is just now getting to the game here, but these "crap tools" were written something like nine ~ ten years ago. I mean, how much notice and merit is everyone looking for here? The only reason there's a push now, is cause over the last five to six years vendors have been telling everyone that they're dropping net-tools. But yeah, we already did the whole "compete" thing, net-tools sucked so bad, it wasn't hard convincing the folks on every level to start focusing on the new tools.

            • Re: (Score:3, Informative)

              by gweihir ( 88907 )

              The new tools are insanely better by every single measure possible.

              Either you are _really_ clueless or you are lying directly here. Because that is very obviously not true.

              • Re: (Score:3, Interesting)

                Either you are _really_ clueless or you are lying directly here. Because that is very obviously not true.

                Apparently managing 1100 virtual host spread across 20 Power8 boxes and on-fly doc generation isn't something you do, I don't blame you, compliance in my wing is shit to begin with but I don't dictate that, I just get to pick which way I comply with that in the fastest manner so I can move on with life. Using an ifconfig approach which I am forced to do with AIX on a different 15 box Power7 set of systems even with thread count set to eight can take several hours to doc-gen the values from all of the prodd

                • by gweihir ( 88907 )

                  "I am so great you cannot even comprehend it" fallacy. (Can't be bothered to look up the correct name, but only losers use it.) Your immature posturing does nothing to strengthen your position. It weakens it further. Also, you seem to be stupid, because "every single measure possible" does very obviously include measures that are taken against different situations than your special case.

            • by skids ( 119237 )

              The new tools are insanely better by every single measure possible.

              I use both, and I know that iproute2 is definitely better in many respects.

              But definitey not all: the output is less readable/useful (workflow matters more than logical structure, guys) and the manpages suck (yes you should have BNF somewhere in the manpage, but it should not *be* the manpage. A manpage should list most common usages first, and end with a list of examples... examples, not restatements of the BNF... for intermediate use cases.)

        • by Anonymous Coward on Sunday May 27, 2018 @02:00PM (#56684068)

          The problem isn't new tools. It's crap tools.

          The problem isn't new tools. It's not even crap tools. It's the mindset that we need to get rid of an ~70KB netstat, ~120KB ifconfig, etc. Like others have posted, this has more to do with the ego of the new tools creators and/or their supporters who see the old tools as some sort of competition. Well, that's the real problem, then, isn't it? They don't want to have to face competition and the notion that their tools aren't vastly superior to the user to justify switching completely, so they must force the issue.

          Now, it'd be different if this was 5 years down the road, netstat wasn't being maintained*, and most scripts/dependents had already been converted over. At that point there'd be a good, serious reason to consider removing an outdated package. That's obviously not the debate, though.

          * Vs developed. If seven year old stable tools are sufficiently bug free that no further work is necessary, that's a good thing.

        • by locofungus ( 179280 ) on Sunday May 27, 2018 @02:46PM (#56684296)

          If I type ifconfig interface I get back pretty much everything I want to know about it

          How do you tell in ifconfig output which addresses are deprecated? When I run ifconfig eth0.100 it lists 8 global addreses. I can deduce that the one with fffe in the middle is the permanent address but I have no idea what the address it will use for outgoing connections.

          ip addr show dev eth0.100 tells me what I need to know. And it's only a few more keystrokes to type.

      • by ceoyoyo ( 59147 )

        In general, it's better for application programs, including scripts to use an application programming interface (API) such as /proc, rather than a user interface such as ifconfig, but in reality tons of scripts do use ifconfig and such.

        Yes, the UNIX way has a fundamental flaw. It gets even worse when you realize that entire scientific disciplines have decided that shell scripting and files on disk is the best way to do stuff. There's nothing like an iterative algorithm that loads and saves it's (large) data

        • Yes, the UNIX way has a fundamental flaw.

          It's not a flaw. Process creation is cheap on Unixlikes.

          There's nothing like an iterative algorithm that loads and saves it's (large) data to disk multiple times per iteration.

          That's not a problem inherent to scripts; if you do it wrong, you can do it that way with a coded program, too. Some things, of course, should just not be done with shell scripts. For those things, there is perl :)

        • by gweihir ( 88907 ) on Sunday May 27, 2018 @12:23PM (#56683450)

          Being able to code things fast and have them execute slow is not a "fundamental flaw". It is a valid design choice and actual experts understand that.

        • The number one rule of the Unix way is "everything is a file". Including everything in /proc. PS, ifconfig, etc read the information in proc and format it for human consumption. There is nothing in the Unix way that says "get confused about what is an application programming interface (proc) and what is a UK report (ifconfig)".

          In fact the Unix way, everything is a file, makes it easy for scripts to use the API - the APU isn't some complex binary system like COM, it's just a directory of files.

    • Re:So (Score:5, Insightful)

      by Z00L00K ( 682162 ) on Sunday May 27, 2018 @11:11AM (#56683004) Homepage

      I agree - I don't care how the commands work under the cover as long as they have the names and syntax I expect since ages ago.

      Most of the listed programs aren't really performance hogs anyway so there's not a huge reason to rewrite them unless there's some serious safety issues or stability issues that has to be taken care of.

      Please don't generate time wasters trying to force people find new commands with new syntaxes doing what the old commands did fine. It's not worth it.

      • Re:So (Score:5, Interesting)

        by HanzoSpam ( 713251 ) on Sunday May 27, 2018 @12:40PM (#56683562)

        Not only not worth it, but a major pain in the ass if you're trying to build scripts that need to be deployed on multiple platforms. Yo, there's still plenty of Solaris, HPUX and AIX out there. And not infrequently, they're all deployed in the same shop.

        This is reminiscent of Windows, "embrace, extend and extinguish" strategy. Linux (or more accurately, Linux distributions) seems to be acquiring all of the characteristics that drove people to abandon Windows for Linux in the first place.

    • Re:So (Score:5, Insightful)

      by Anonymous Coward on Sunday May 27, 2018 @11:13AM (#56683016)

      Following the systemd model, "if it aint broken, you're not trying hard enough"...

    • That's the reason (Score:5, Interesting)

      by Anonymous Coward on Sunday May 27, 2018 @11:35AM (#56683144)

      It done one thing: Maintain the routing table.

      "ip" (and "ip2" and whatever that other candidate not-so-better not-so-replacement of ifconfig was) all have the same problem: They try to be the one tool that does everything "ip". That's "assign ip address somewhere", "route the table", and all that. But that means you still need a complete zoo of other tools, like brconfig, iwconfig/iw/whatever-this-week.

      In other words, it's a modeling difference. On sane systems, ifconfig _configures the interface_, for all protocols and hardware features, bridges, vlans, what-have-you. And then route _configures the routing table_. On linux... the poor kids didn't understand what they were doing, couldn't fix their broken ifconfig to save their lives, and so went off to reinvent the wheel, badly, a couple times over.

      And I say the blogposter is just as much an idiot.

      Per various people, netstat et al operate by reading various files in /proc, and doing this is not the most efficient thing in the world

      So don't use it. That does not mean you gotta change the user interface too. Sheesh.

      However, the deeper issue is the interface that netstat, ifconfig, and company present to users.

      No, that interface is a close match to the hardware. Here is an interface, IOW something that connects to a radio or a wire, and you can make it ready to talk IP (or back when, IPX, appletalk, and whatever other networks your system supported). That makes those tools hardware-centric. At least on sane systems. It's when you want to pretend shit that it all goes awry. And boy, does linux like to pretend. The linux ifconfig-replacements are IP-only-stack-centric. Which causes problems.

      For example because that only does half the job and you still need the aforementioned zoo of helper utilities that do things you can have ifconfig do if your system is halfway sane. Which linux isn't, it's just completely confused. As is this blogposter.

      On the other hand, the users expect netstat, ifconfig and so on to have their traditional interface (in terms of output, command line arguments, and so on); any number of scripts and tools fish things out of ifconfig output, for example.

      linux' ifconfig always was enormously shitty here. It outputs lots of stuff I expect to find through netstat and it doesn't output stuff I expect to find out through ifconfig. That's linux, and that is NOT "traditional" compared to, say, the *BSDs.

      As the Linux kernel has changed how it does networking, this has presented things like ifconfig with a deep conflict; their traditional output is no longer necessarily an accurate representation of reality.

      Was it ever? linux is the great pretender here.

      But then, "linux" embraced the idiocy oozing out of poettering-land. Everything out of there so far has caused me problems that were best resolved by getting rid of that crap code. Point in case: "Network-Manager". Another attempt at "replacing ifconfig" with something that causes problems and solves very few.

      • by locofungus ( 179280 ) on Sunday May 27, 2018 @03:27PM (#56684516)

        It done one thing: Maintain the routing table.

        Should the ip rule stuff be part of route or a separate command?

        There are things that could be better with ip. IIRC it's very fussy about where the table selector goes in the argument list but route doesn't support this at all.

        I also don't think route has anything like 'nexthop dev $if' which is a godsend for ipv6 configuration.

        I stayed with route for years. But ipv6 exposed how incomplete the tool is - and clearly nobody cares enough to add all the missing functionality.

        Perhaps ip addr, ip route, ip rule, ip mroute, ip link should be separate commands. I've never looked at the sourcecode to see whether it's mostly common or mostly separate.

        • by Anonymous Coward

          ^this^

          The people who think the old tools work fine don't understand all the advanced networking concepts that are only possible with the new tools: interfaces can have multiple IPs, one IP can be assigned to multiple interfaces, there's more than one routing table, firewall rules can add metadata to packets that affects routing, etc. These features can't be accommodated by the old tools without breaking compatibility.

    • keep the command names the same but rewrite how they function?

      Well, keep the syntax too, so old scripts would still work. The old command name could just be a script that calls the new commands under the hood. (Perhaps this is just what you meant, but I thought I'd elaborate.)

    • Re:So (Score:4, Insightful)

      by gweihir ( 88907 ) on Sunday May 27, 2018 @12:18PM (#56683412)

      What was the reason for replacing "route" anyhow? It's worked for decades and done one thing.

      Idiots that confuse "new" with better and want to put their mark on things. Because they are so much greater than the people that got the things to work originally, right? Same as the systemd crowd. Sometimes, they realize decades later they were stupid, but only after having done a lot of damage for a long time.

    • I didn't RTFA (this is Slashdot, after all) but from TFS it sounds like exactly the reason I moved to FreeBSD in the first place: the Linux attitude of 'our implementation is broken, let's completely change the interface'. ALSA replacing OSS was the instance of this that pushed me away. On Linux, back around 2002, I had some KDE and some GNOME apps that talked to their respective sound daemon, and some things like XMMS and BZFlag that used /dev/dsp directly. Unfortunately, Linux decided to only support s

  • Bad idea (Score:5, Insightful)

    by goombah99 ( 560566 ) on Sunday May 27, 2018 @11:08AM (#56682986)

    Unix was founded on the ideas of lots os simple command line tools that do one job well and don't depend on system idiosyncracies. If you make the tool have to know the lower layers of the system to exploit them then you break the encapsulation. Polling proc has worked across eons of linux flavors without breaking. when you make everthing integrated it creates paralysis to change down the road for backward compatibility. small speed game now for massive fragility and no portability later.

    • Gnu may not be unix but it's foundational idea lies in the simple command tool paradigm. It's why GNU was so popular and it's why people even think that Linux is unix. That idea is the character of linux. if you want an marvelously smooth, efficient, consistent integrated system that then after a decade of revisions feels like a knotted tangle of twine in your junk drawer, try Windows.

    • Re:Bad idea (Score:5, Insightful)

      by llamalad ( 12917 ) on Sunday May 27, 2018 @11:46AM (#56683198)

      The error you're making is thinking that Linux is UNIX.

      It's not. It's merely UNIX-like. And with first SystemD and now this nonsense, it's rapidly becoming less UNIX-like. The Windows of the UNIX(ish) world.

      Happily, the BSDs seem to be staying true to their UNIX roots.

      • Since SystemD, I felt that the *BSDs have been kicking so much Linux ass. So much that it's starting to be humorous (unless you have an interest in Linux, in which case it's a bit painful/pathetic).

        I like Linus. He's smart and he is a great coding leader. If he decides to put his foot down (even though his ingerence, in principle, is only the kernel) maybe Linux can be salvaged. Otherwise, it's just another shitty Windows wannabe, just with smaller usage share.

    • ...Unix was founded on the ideas of lots os simple command line tools that do one job well and don't depend on system idiosyncracies. If you make the tool have to know the lower layers of the system to exploit them then you break the encapsulation....

      Stop standing in the way of progress. There is a new order now. Follow it or get out of the way.

    • by jythie ( 914043 )
      I think linux was doomed once developers got to gether and went 'hey, Window's registry is great, why don't we do something like that?'. As linux gained popularity, the culture shifted and 'unix people' increasingly got sidelined. It is kinda sad that I actually find more familiar in OSX than newer versions of Ubuntu.
    • by gweihir ( 88907 )

      Oh, yes. But seeing that takes actual insight and experience. The ones pushing for these new "faster" tools usually lack both.

  • SS Really (Score:5, Insightful)

    by barryvoeten ( 5508 ) on Sunday May 27, 2018 @11:08AM (#56682988) Homepage

    What moron has called the tool SS ? I thing someone who does not check Google first. It is not only Unix history being wiped here.

  • by freeze128 ( 544774 ) on Sunday May 27, 2018 @11:12AM (#56683010)
    What's wrong with just ADDING newer commands and leaving the old ones?
    • Installing more programs by default makes the install image larger (in megabytes) and take longer (in seconds). It also increases the attack surface, as more lines of code generally* mean more defects that an intruder can exploit to either gain initial access or elevate privilege.

      * Assuming a constant defect rate measured in defects per thousand lines.

      • by ZeroPly ( 881915 )
        By that logic, we should just get rid of Linux, and stick to using Windows. Less total lines of code and all.
      • by Anonymous Coward on Sunday May 27, 2018 @11:29AM (#56683112)

        The size increase due to stuff like netstat and ifconfig is trivial. Where the bloat comes from is needing python, java, javascript, often in various versions to make a system run. There is absolutely no reason this crap needs to be mandatory. And talk about expanding the attack surface.

    • by gweihir ( 88907 ) on Sunday May 27, 2018 @12:26PM (#56683474)

      Then you would have to compete on merit, i.e. your new shiny greatest thing (TM) would actually have to be better to be successful. It rarely is.

    • by jythie ( 914043 )
      The problem is maintenance. The old tools can stick around, but someone has to maintain them, update them, and it increases the potential security problems if you have two parallel sets installed at the same time so distros will try to go with one or the other. And there is the deeper issue : as usage changes, more and more internals are also changing. The new tools are intended to dovetail with the direction some users want linux to go, so cutting off the old tools frees them up to make deeper changes.
    • by c ( 8461 ) <beauregardcp@gmail.com> on Sunday May 27, 2018 @01:48PM (#56683988)

      What's wrong with just ADDING newer commands and leaving the old ones?

      People would just keep using the old ones and ignore the new ones. This would be a blow to the egos of the people reinventing the wheel and hence can't be allowed.

  • by Anonymous Coward on Sunday May 27, 2018 @11:18AM (#56683052)

    We will 'correct' your tools, one by one.

  • Mainly because ... (Score:3, Insightful)

    by thadtheman ( 4911885 ) on Sunday May 27, 2018 @11:33AM (#56683134)
    Lenart Poettering hasn't screwed up linux enough already.
    • by gweihir ( 88907 )

      Indeed. Just wasted several hours ripping his crap out of armbian. Now things actually work in the way I want and I can customize things easily.

  • by aglider ( 2435074 ) on Sunday May 27, 2018 @11:51AM (#56683236) Homepage

    Who ever has seen a netstat or ifconfig run taking more than a second or two?
    Unless you put them in a tight loop, you won't ever notice the difference in the load of the system.

  • by AJWM ( 19027 ) on Sunday May 27, 2018 @11:51AM (#56683238) Homepage

    I'm responsible a lot of production systems (somewhere around a thousand VMs, it varies), so of course I worry about CPU use, memory use, I/O, etc. I have never, ever, in decades of sysadmin'ing, worried about how much of the above ifconfig or netstat take. (It's not like what's in /proc are actual files, after all; /proc a kernel interface.)

    Worried about efficiency? In the aggregate you'll waste more CPU- and man-hours compiling and debugging your replacement tools than using ifconfig or netstat will. Go spend that time on something useful.

  • by QuietLagoon ( 813062 ) on Sunday May 27, 2018 @11:54AM (#56683252)
    ... I've pretty much resigned myself to the fact that Linux is no longer a part of the UNIX family, that I now have to write scripts separately for my Linux boxen. So I'd say that I am OK with breaking nearly every script I've written in Linux in order to stay current with the direction being set by the Linux community.
  • by Maltheus ( 248271 ) on Sunday May 27, 2018 @12:01PM (#56683278)

    Not on my Linux. Gentoo will have this stuff around forever. Still using OpenRC too without a hiccup. Bit of a pain to keep up-to-date, but it always does what I want, with no talking back.

    • by gweihir ( 88907 )

      ...but it always does what I want, with no talking back.

      And that is just the thing: Once you are an actual system administrator and not just a glorified user with delusions, this is priceless.

  • by petes_PoV ( 912422 ) on Sunday May 27, 2018 @12:01PM (#56683282)

    In theory netstat, ifconfig, and company could be rewritten to use netlink too; in practice this doesn't seem to have happened and there may be political issues involving different groups of developers with different opinions on which way to go.

    No, it is far simpler than looking for some mythical "political" issues. It is simply that hackers - especially amateur ones, who write code as a hobby - dislike trying to work out how old stuff works. They like writing new stuff, instead.

    Partly this is because of the poor documentation: explanations of why things work, what other code was tried but didn't work out, the reasons for weird-looking constructs, techniques and the history behind patches. It could even be that many programmers are wedded to a particular development environment and lack the skill and experience (or find it beyond their capacity) to do things in ways that are alien to it. I feel that another big part is that merely rewriting old code does not allow for the "look how clever I am" element that is present in fresh, new, software. That seems to be a big part of the amateur hacker's effort-reward equation.

    One thing that is imperative however is to keep backwards compatibility. So that the same options continue to work and that they provide the same content and format. Possibly Unix / Linux only remaining advantage over Windows for sysadmins is its scripting. If that was lost, there would be little point keeping it around.

    • by jythie ( 914043 )
      Unfortunately, backwards compatibility has always been a weakness in OSS and has been getting worse over the years. I am actually reluctant to suggest linux to small teams now if they look like they are going to be up and running for a long time, the cost of keeping 'up to date' gets too high and you have to keep devoting development time to rewriting stuff that already worked or replace entire subsystems because some devs went 'we are doing cool stuff in our next version which breaks everything! but you a
    • by DamnOregonian ( 963763 ) on Sunday May 27, 2018 @05:13PM (#56685074)
      iproute2 exists because ifconfig, netstat, and route do not support the full capabilities of the linux network stack.
      This is because today's network stack is far more complicated than it was in the past. For very simple networks, the old tools work fine. For complicated ones, you must use the new ones.

      Your post could not be any more wrong. Your moderation amazes me. It seems that slashdot is full of people who are mostly amateurs.
      iproute2 has been the main network management suite for linux amongst higher end sysadmins for a decade. It wasn't written to sate someone's desire to change for the sake of change, to make more complicated, to NIH. It was written because the old tools can't encompass new functionality without being rewritten themselves.
  • by Craig Cruden ( 3592465 ) on Sunday May 27, 2018 @12:11PM (#56683352)
    So basically there is a proposal to dump existing terminal utilities that are cross-platform and create custom Linux utilities - then get rid of the existing functionality? That would be moronic! I already go nuts remoting into a windows platform and then an AIX and Linux platform and having different command line utilities / directory separators / etc. Adding yet another difference between my Linux and macOS/AIX terminals would absolutely drive me bonkers!

    I have no problem with updating or rewriting or adding functionalities to existing utilities (for all 'nix platforms), but creating a yet another incompatible platform would be crazily annoying.

    (not a sys admin, just a dev who has to deal with multiple different server platforms)
  • The reasons that he puts forth are hardly convincing - the first one being downright laughable: if the commands are poorly written, rewrite them. This aside, the truth is that Linux is distancing itself more and more from its Unix roots. Many obviously like this. Others, like me, don't. We still have the BSDs, so there is a fallback. However, the scenario is already looming in the horizon in which if the choice comes down to Linux or Mac, the latter will be preferable even if one has to pay.
  • by Anonymous Coward on Sunday May 27, 2018 @12:16PM (#56683388)

    All output for 'ip' is machine readable, not human.
    Compare
    $ ip route
    to
    $ route -n

    Which is more readable? Fuckers.

    Same for
    $ ip a
    and
    $ ifconfig
    Which is more readable? Fuckers.

    The new commands should generally make the same output as the old, using the same options, by default. Using additional options to get new behavior. -m is commonly used to get "machine readable" output. Fuckers.

    It is like the systemd interface fuckers took hold of everything. Fuckers.

    BTW, I'm a happy person almost always, but change for the sake of change is fucking stupid.

    Want to talk about resolvconf, anyone? Fuckers! Easier just to purge that shit.

  • by drolli ( 522659 ) on Sunday May 27, 2018 @12:26PM (#56683480) Journal

    Do it like it is done correctly:

    Leave the old interfaces/tools in, including their inefficiency. If you dont like to haven these in your special kernel, the proc filesystem can be disabled......

    For those systems which need something more efficient (i suppose things involving heavy use of containers or virtualization), use the new interfaces.

    This worked well for a lot of things up to now in linux.

  • by SigmundFloyd ( 994648 ) on Sunday May 27, 2018 @12:39PM (#56683558)

    I'm growing increasingly annoyed with Linux' userland instability. Seriously considering a switch to NetBSD because I'm SICK of having to learn new ways of doing old things.

    For those who are advocating the new tools as additions rather than replacements: Remember that this will lead to some scripts expecting the new tools and some other scripts expecting the old tools. You'll need to keep both flavors installed to do ONE thing. I don't know about you, but I HATE to waste disk space on redundant crap.

  • Piss and vinigar (Score:5, Interesting)

    by fluffernutter ( 1411889 ) on Sunday May 27, 2018 @12:46PM (#56683592)
    What pisses me off is when I go to run ifconfig and it isn't there, and then I Google on it and there doesn't seem to be *any* direct substitute that gives me the same information. If you want to change the command then fine, but allow the same output from the new commands. Furthermore, another bitch I have is most systemd installations don't have an easy substitute for /etc/rc.local.
  • by what about ( 730877 ) on Sunday May 27, 2018 @01:35PM (#56683874) Homepage

    It does not make any sense that some people spend time and money replacing what is currently working with some incompatible crap.

    Therefore, the only logical alternative is that they are paid (in some way) to break what is working.

    Also, if you rewrite tons of systems tools you have plenty of opportunities to insert useful bugs that can be used by the various spying agencies.

    You do not think that the current CPU Flaws are just by chance, right ?
    Immagine the wonder of being able to spy on any machine, regardless of the level of SW protection.

    There is no need to point out that I cannot prove it, I know, it just make sense to me.

    • by Kjella ( 173770 )

      It does not make any sense that some people spend time and money replacing what is currently working with some incompatible crap. (...) There is no need to point out that I cannot prove it, I know, it just make sense to me.

      Many developers fix problems like a guy about to lose a two week vacation because he can't find his passport. Rip open every drawer, empty every shelf, spread it all across the tables and floors until you find it, then rush out the door leaving everything in a mess. It solved HIS problem.

  • by WaffleMonster ( 969671 ) on Sunday May 27, 2018 @01:52PM (#56684010)

    TFA is full of shit.

    IP aliases have always and still do appear in ifconfig as separate logical interfaces.

    The assertion ifconfig only displays one IP address per interface also demonstrably false.

    Using these false bits of information to advocate for change seems rather ridiculous.

    One change I would love to see... "ping" bundled with most Linux distros doesn't support IPv6. You have to call IPv6 specific analogue which is unworkable. Knowing address family in advance is not a reasonable expectation and works contrary to how all other IPv6 capable software any user would actually run work.

    Heck for a while traceroute supported both address families. The one by Olaf Kirch eons ago did then someone decided not invented here and replaced it with one that works like ping6 where you have to call traceroute6 if you want v6.

    It seems anymore nobody spends time fixing broken shit... they just spend their time finding new ways to piss me off. Now I have to type journalctl and wait for hell to freeze over just to liberate log data I previously could access nearly instantaneously. It almost feels like Microsoft's event viewer now.

    • by DamnOregonian ( 963763 ) on Sunday May 27, 2018 @05:30PM (#56685130)

      TFA is full of shit. IP aliases have always and still do appear in ifconfig as separate logical interfaces.

      No, you're just ignorant.
      Aliases do not appear in ifconfig as separate logical interfaces.
      Logical interfaces appear in ifconfig as logical interfaces.
      Logical interfaces are one way to add an alias to an interface. A crude way, but a way.

      The assertion ifconfig only displays one IP address per interface also demonstrably false.

      Nope. Again, your'e just ignorant.

      root@swalker-samtop:~# tunctl
      Set 'tap0' persistent and owned by uid 0
      root@swalker-samtop:~# ifconfig tap0 10.10.10.1 netmask 255.255.255.0 up
      root@swalker-samtop:~# ip addr add 10.10.10.2/24 dev tap0
      root@swalker-samtop:~# ifconfig tap0:0 10.10.10.3 netmask 255.255.255.0 up
      root@swalker-samtop:~# ip addr add 10.10.1.1/24 scope link dev tap0:0
      root@swalker-samtop:~# ifconfig tap0 | grep inet
      inet 10.10.1.1 netmask 255.255.255.0 broadcast 0.0.0.0
      root@swalker-samtop:~# ifconfig tap0:0 | grep inet
      inet 10.10.10.3 netmask 255.255.255.0 broadcast 10.10.10.255
      root@swalker-samtop:~# ip addr show dev tap0 | grep inet
      inet 10.10.1.1/24 scope link tap0
      inet 10.10.10.1/24 brd 10.10.10.255 scope global tap0
      inet 10.10.10.2/24 scope global secondary tap0
      inet 10.10.10.3/24 brd 10.10.10.255 scope global secondary tap0:0

      If you don't understand what the differences are, you really aren't qualified to opine on the matter.
      Ifconfig is fundamentally incapable of displaying the amount of information that can go with layer-3 addresses, interfaces, and the architecture of the stack in general. This is why iproute2 exists.

  • by JustNiz ( 692889 ) on Sunday May 27, 2018 @01:55PM (#56684030)

    SysD: (v). To force an unnecessary replacement of something that already works well with an alternative that the majority perceive as fundamentally worse.
    Example usage: Wow you really SysD'd that up.

  • Total nonesense (Score:3, Interesting)

    by Andrew Gryaznov ( 4260673 ) on Sunday May 27, 2018 @02:30PM (#56684222)

    I am Linux kernel network and proprietary distributions developer and have actually read the code.

    Reading stuff in /proc is a standard mechanism and where appropriate, all the tools are doing the same including 'ss' that you mentioned (which is btw very poorly designed)

    Also there are several implementations of the net tools, the one from busybox probably the most famous alternative one and implementations don't hesitate changing how, when and what is being presented.

    What is true though is that Linux kernel APIs are sometimes messy and tools like e.g. pyroute2 are struggling with working around limitations and confusions. There is also a big mess with the whole netfilter package as the only "API" is the iptables command-line tool itself.

    Linux is arguably the biggest and most important project on Earth and should respect all views, races and opinions. If you would like to implement a more efficient and streamlined network interface (which I very much beg for and may eventually find time to do) - then I'm all in with you. I have some ideas of how to make the interface programmable by extending JIT rules engine and making possible to implement the most demanding network logic in kernel directly (e.g. protocols like mptcp and algorithms like Google Congestion Control for WebRTC).

  • by adosch ( 1397357 ) on Sunday May 27, 2018 @04:04PM (#56684724)

    The OP's argument is that netlink sockets are more efficient in theory so we should abandon anything that uses a pseudo-proc, re-invent the wheel and move even farther from the UNIX tradition and POSIX compliance? And it may be slower on larger systems? Define that for me because I've never experienced that. I've worked on single stove-pipe x86 systems, to the 'SPARC archteciture' generation where everyone thought Sun/Solaris was the way to go with single entire systems in a 42U rack, IRIX systems, all the way on hundreds of RPM-base linux distro that are physical, hypervised and containered nodes in an HPC which are LARGE compute systems (fat and compute nodes). That's a total shit comment with zero facts to back it up. This is like Good Will Hunting 'the bar scene' revisited...

    OP, if you're an old hat like me, I'd fucking LOVE to know how old? You sound like you've got about 5 days soaking wet under your belt with a Milkshake IPA in your hand. You sound like a millennial developer-turned-sysadmin-for-a-day who's got all but cloud-framework-administration under your belt and are being a complete poser. Any true sys-admin is going to flip-their-shit just like we ALL did with systemd, and that shit still needs to die. There, I got that off my chest.

    I'd say you got two things right, but are completely off on one of them:

    * Your description of inefficient is what you got right: you sound like my mother or grandmother describing their computing experiences to look at Pintrest on a web brower at times. You mind as well just said slow without any bearing, education guess or reason. Sigh...

    * I would agree that some of these tools need to change, but only to handle deeper kernel containerization being built into Linux. One example that comes to mind is 'hostnamectl' where it's more dev-ops centric in terms of 'what' slice or provision you're referencing. A lot of those tools like ifconfig, route and alike still do work in any Linux environment, containerized or not --- fuck, they work today.

    Anymore, I'm just a disgruntled and I'm sure soon-to-be-modded-down voice on /. that should be taken with a grain of salt. I'm not happy with the way the movements of Linux have gone, and if this doesn't sound old hat I don't know what is: At the end of the day, you have to embrace change. I'd say 0.0001% of any of us are in control of those types of changes, no matter how we feel about is as end-user administrators of those tools we've grown to be complacent about. I got about 15y left and this thing called Linux that I've made a good living on will be the-next-guys steaming pile to deal with.

    • by Greyfox ( 87712 )
      Yeah. The other day I set up some demo video streaming on a Linux box. Fire up screen, start my streaming program. Disconnect screen and exit my ssh system, and my streaming freezes. There're a metric fuckton of reports of systemd killing detached/nohup'd processes, but I check my config file and it's not that. Although them being that willing to walk away from expected system behavior is already cause to blow a gasket. But no, something else is going on here. I tweak the streaming code to catch all catchab
  • by jgotts ( 2785 ) <jgottsNO@SPAMgmail.com> on Sunday May 27, 2018 @06:17PM (#56685380)

    Just to give you guys some color commentary, I was participating quite heavily in Linux development from 1994-1999, and Linus even added me to the CREDITS file while I was at the University of Michigan for my fairly modest contributions to the kernel. [I prefer application development, and I'm still a Linux developer after 24 years. I currently work for the company Internet Brands.]

    What I remember about ip and net is that they came about seemingly out of nowhere two decades ago and the person who wrote the tools could barely communicate in English. There was no documentation. net-tools by that time was a well-understood and well-documented package, and many Linux devs at the time had UNIX experience pre-dating Linux (which was announced in 1991 but not very usable until 1994).

    We Linux developers virtually created Internet programming, where most of our effort was accomplished online, but in those days everybody still used books and of course the Linux Documentation Project. I have a huge stack of UNIX and Linux books from the 1990's, and I even wrote a mini-HOWTO. There was no Google. People who used Linux back then may seem like wizards today because we had to memorize everything, or else waste time looking it up in a book. Today, even if I'm fairly certain I already know how to do something, I look it up with Google anyway.

    Given that, ip and route were downright offensive. We were supposed to switch from a well-documented system to programs written by somebody who can barely speak English (the lingua franca of Linux development)?

    Today, the discussion is irrelevant. Solaris, HP-UX, and the other commercial UNIX versions are dead. Ubuntu has the common user and CentOS has the server. Google has complete documentation for these tools at a glance. In my mind, there is now no reason to not switch.

    Although, to be fair, I still use ifconfig, even if it is not installed by default.

Competence, like truth, beauty, and contact lenses, is in the eye of the beholder. -- Dr. Laurence J. Peter

Working...