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.
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.
So (Score:5, Insightful)
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)
Re: (Score:2, Insightful)
What is the point? If an intruder is already there couldn't they just upload their own binary?
Re:So (Score:5, Interesting)
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)
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)
except it DOESN'T secure anything, simply renders things a little more obscure... Since when is obscurity security?
Re: (Score:3)
Re:So (Score:5, Insightful)
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.
Re: So (Score:2)
pretty much my reaction. like wtf? otoh, redhat flavours all still on glibc2 starting to become a regular p.i.t.a. so the chances of this actually becoming a thing to be concerned about seem very low.
kinda like gdpr, same kind of group think that anyone actually cares or concerns themselves with policy these days.
Re: (Score:3)
Or they can do reverse traceroute at least until the border edge of your firewall via an external site.
Re:So (Score:4, Insightful)
Some folks, generally the dimmer of us, will disable echo responses or TTL expiration notices thinking it is somehow secure (and they are very fucking wrong) but nobody blocks all ICMP, except for very very dim witted humans, and only on endpoint nodes.
Re: (Score:3)
I am *the guy* who runs the network. I am our senior network engineer. Every line in every router- mine.
You have no idea what you're talking about, at any level. "disabled ICMP"- state statement alone requires such ignorance to make that I'm not sure why I'm even replying to ignorant ass.
Re: (Score:3)
I understand "networking" at a level I'm pretty sure you only have a foggy understanding of.
I write applications that require layer-2 packet building all the way up to layer-4.
In short, he's a moron. I have reason to suspect you might be, too.
Re: (Score:3)
Re: (Score:3)
> I'm not a network person
IOW, nothing you say about networking should be taken seriously.
Re:So (Score:4, Insightful)
No, TCP/IP is not working fine. It's broken and is costing you performance and $$$. But it is not evident because TCP/IP is very good about dealing with broken networks, like yours.
Th problem is that doing this requires things like packet fragmentation which greatly increases router CPU load and reduces the maximum PPS of your network as well s resulting in dropped packets requiring re-transmission and may also result in widow collapse fallowed with slow-start, though rapid recovery mitigates much of this, it's still not free.
It's another example of security by stupidity which seldom provides security, but always buys added cost.
Re: (Score:3)
As a server engineer I am experiencing this with our network team right now.
Do you have some reading that I might be able to further educate myself? I would like to be able to prove to the directors why disabling ICMP on the network may be the cause of our issues.
Re:So (Score:4, Informative)
A brief read suggests this is a good resource: https://john.albin.net/essenti... [albin.net]
Re: Denying ICMP echo @ server/workstation level t (Score:5, Insightful)
Linux has one of the few IP stacks that isn't derived from the BSD stack, which in the industry is considered the reference design. Instead for linux, a new stack with it's own bugs and peculiarities was cobbled up.
Reference designs are a good thing to promote interoperability. As far as TCP/IP is concerned, linux is the biggest and ugliest stepchild. A theme that fits well into this whole discussion topic, actually.
That would break scripts which use the UI (Score:5, Insightful)
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.
Re:That would break scripts which use the UI (Score:5, Informative)
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.
Re:That would break scripts which use the UI (Score:5, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:3)
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.
Re:That would break scripts which use the UI (Score:4, Informative)
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)
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
Re: (Score:3)
"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.
Re: (Score:3)
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.)
Re:That would break scripts which use the UI (Score:5, Interesting)
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.
Re:That would break scripts which use the UI (Score:4, Informative)
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.
Re: (Score:3)
They're not, as pointed out in the article (and I can point out even more ways).
Re: (Score:3)
Re: (Score:3)
If my car now has an electric motor, but I can't make my old gasoline motor dash make much sense with it... My electric motor is the problem?
Re: (Score:2)
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
Re:That would break scripts which use the UI (Score:5, Insightful)
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 :)
Re:That would break scripts which use the UI (Score:4, Interesting)
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.
Re:That would break scripts which use the UI (Score:4, Insightful)
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.
This.
I write many programs that I end up running exactly once after they're tested and working. Runtime might vary from milliseconds to a week. But the thing that impacts my time is writing the code, not getting on with other stuff while the computer works for me.
You mean the opposite of the Unix way? (Score:3)
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.
inotify / fswatch (Score:5, Informative)
>. Files don't generally call you, for example, you have to poll.
That's called inotify. If you want to be compatible with systems that have something other than inotify, fswatch is a wrapper around various implementations of "call me when a file changes".
Polling is normally the safest and simplest paradigm, though, because the standard thing is "when a file changes, do this". Polling / waiting makes that simple and self-explanatory:
while tail file
do
something
done
The alternative, asynchronously calling the function like this has a big problem:
when file changes
do something
The biggest problem is that a file can change WHILE you're doing something(), meaning it will re-start your function while you're in the middle of it. Re-entrancy carries with it all manner of potential problems. Those problems can be handled of you really know what you're doing, you're careful, and you make a full suite of re-entrant integration tests. Or you can skip all that and just use synchronous io, waiting or polling. Neither is the best choice in ALL situations, but very often simplicity is the best choice.
Re:So (Score:5, Insightful)
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)
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)
Following the systemd model, "if it aint broken, you're not trying hard enough"...
That's the reason (Score:5, Interesting)
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.
Re:That's the reason (Score:4, Insightful)
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.
Re: That's the reason (Score:3, Informative)
^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.
Re: (Score:3)
Someone cared enough to implement an entirely different tool to do the same old jobs plus some new stuff, it's too bad they didn't do the sane thing and add that functionality to the old tool where it would have made sense.
It's not that simple. The iproute2 suite wasn't written to *replace* anything.
It was written to provide a user interface to the rapidly expanding RTNL API.
The net-tools maintainers (or anyone who cared) could have started porting it if they liked. They didn't. iproute2 kept growing to provide access to all the new RTNL interfaces, while net-tools got farther and farther behind.
What happened was organic. If someone brought net-tools up to date tomorrow and everyone liked the interface, iproute2 would be d
Re:That's the reason (Score:4, Informative)
This source was always freely available for the net-tools guys to take and add to their own software.
Instead, we get this. [sourceforge.net]
Nobody is giving a positive spin. This is simply how it happened. This is what happens when software isn't maintained, and you don't get to tell other people to maintain it. You're free, right now, today, to port the iproute2 functionality into net-tools. They're unwilling to, however. That's their right. It's also the right of other people to either fork it, or move to more functional software. It's your right to help influence that. Or bitch on slashdot. That probably helps, too.
Re: (Score:2)
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)
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.
Re: (Score:2)
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
Re: (Score:3)
On the other hand, on most systems, vi is basically an alias to vim....
Bad idea (Score:5, Insightful)
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.
Re: (Score:3)
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)
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.
Re: (Score:3)
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.
Re: (Score:2)
...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.
Re: (Score:2)
Re: (Score:2)
Oh, yes. But seeing that takes actual insight and experience. The ones pushing for these new "faster" tools usually lack both.
Re: (Score:2)
SS Really (Score:5, Insightful)
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.
Re:SS Really (Score:5, Funny)
That made me chuckle a bit. Can't wait for the new wireless config tool luftwaffe.
Re: (Score:2)
As long as you don hack into my preferred WiFi network: "Terrornetzwerk", all fine by me!
Why do they need to be REPLACED? (Score:5, Insightful)
Install size and attack surface (Score:3)
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.
Re: (Score:2)
Re:Install size and attack surface (Score:5, Informative)
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.
Re:Why do they need to be REPLACED? (Score:4, Insightful)
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.
Re: (Score:2)
Re:Why do they need to be REPLACED? (Score:5, Insightful)
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.
We will 'correct' your tools, one by one. (Score:4, Interesting)
We will 'correct' your tools, one by one.
Mainly because ... (Score:3, Insightful)
Re: (Score:2)
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.
Really? I don't buy that! (Score:3)
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.
What utter nonsense. (Score:5, Insightful)
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.
After the systemd fiasco... (Score:3)
Re:After the systemd fiasco... (Score:5, Insightful)
Re: (Score:2)
...For a fiasco systemd is working pretty darned well. ...
For me, it is still unable to perform clean shutdowns. At least the filesystem has journaling to help recover from systemd's problem.
Re: (Score:3, Interesting)
For me, it is still unable to perform clean shutdowns. At least the filesystem has journaling to help recover from systemd's problem.
Funny you should say this, because RedHat now has systemd with xfs as the filesystem. And for some reason xfs likes to pretend it's written data when it hasn't, a lot more so than ext4 ever did. So, if an unclean shutdown occurs during a massive file op, such as a yum update, you end up with a seriously broken system with a bunch of 0 byte files in place of major libraries and binaries.
Who's Linux Paleface? (Score:3)
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.
Re: (Score:3)
...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.
The dislike of support work (Score:5, Interesting)
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.
Re: (Score:2)
Re:The dislike of support work (Score:5, Insightful)
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.
So windowification (making it incompatible) (Score:5, Interesting)
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)
To each his/her own (Score:2)
Output for 'ip' is machine readable, not human (Score:5, Interesting)
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.
Never break userland. (Score:4, Insightful)
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.
Linux' userland is UNSTABLE ! (Score:3)
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)
Let's try hard to break Linux (Score:3, Insightful)
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.
Re: (Score:3)
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.
Changes for changes sake (Score:4, Informative)
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.
Re:Changes for changes sake (Score:4, Insightful)
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.
I propose a new word: (Score:5, Funny)
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)
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).
Comment removed (Score:4, Interesting)
Re: (Score:3)
Some historical color (Score:4, Interesting)
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.
Re: (Score:3)
Yes. I mean it would be mathematically impossible to introduce a new tool and leave the old one there too.