Slashdot Mirror
There Are Real Reasons For Linux To Replace ifconfig, netstat and Other Classic Tools (utoronto.ca)
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.
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.
Only the State obtains its revenue by coercion. - Murray Rothbard
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.
Some drink at the fountain of knowledge. Others just gargle.
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.
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.
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.
We will 'correct' your tools, one by one.
Or more like, get rid of it entirely. F your Terminal. If it cannot be done through a GUI, your OS will never hit mainstream and will keep being niche among the few "elite" who think everyone has the time or will, to learn how to use the terminal for the slightest little thing.
Yes? Let's take a guess at what really happened:
- Some trifling, meddling asperg was poking around coreutils/netutils
- Spots what he has determined to be "inefficiency"; a common symptom of aspergers
- Decides what's needed is a whole new "System"
- probably needs it's own special, unique syntax and scripting format, which perfect sense to him
- feels Very Excited about forcing everyone to learn his new, obtuse, counter-intuitive AsperScript
Gotta love the preemptive "Linux's 'not invented here' attitude".
Why the fuck is this Thalidomide-brained moron blathering about "not invented here"? The whole blog post is an "I invented something better here!" self-congratulatory paean to mental masturbation that reeks of smug "not invented here" superiority.
Lenart Poettering hasn't screwed up linux enough already.
1. You find that being 5 takes all your concentration right not, so you don't know what people are referring to either by "30 something" or "parent's basement"
2. You can't wait to get away from your parent's basement but at least you aren't thirty.
3. You get your first job and make jokes about dweebs you meet who are 30 and in their parents basement
4. Your not sure how it work out this way, but somehow it's your 30th birthday and your bed is in your parent's basement.
5. You finally are free of your parent's basement.
6. You finally understand your parents! and would give anything to be 30 again or living with your parents again
Some drink at the fountain of knowledge. Others just gargle.
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.
Why not install the new and shiny tools by default, but keep the mature ones in a package (maybe "net-utils-legacy") - distros can e.g. decide, to put it in "-server" but not in "-minimal" ?
- The (tiny) crowd, who cares about inefficiency of ifconfig AND who cares about say 1MB bigger base image can just not install it
- The (huge) crowd who depend on some script calling "ifconfig -a" need not fear having to diagnose and rebuild their world.
Is that really the stuff of a new war, or can we just grow up and think of it as a no-brainer?
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.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
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.
-- Alastair
... 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.
but then I know very well that I in all likelihood won't sacrifice too much time to write a better implementation, so I may as well shut up and use what other people have done. Until such time that I make something better.
If new features are only available to new tools, we keep maintaining the old tools in deprecated status. But we should never break things. Have a look at Java. Runs with backwards compatibility. We should really continue to support ifconfig until nobody uses it anymore.
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.
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
How long does it take? Most of use use multi core system with lots of memory. It takes forever to load even 'simple' administrative and access /proc. So what? That is your argument? Save a few microseconds. I don't think in microseconds so I find the author's statement bogus. Return to ipconfig, which wasn't the best thing, I find ip not that good either. Many new tools are overkill for little use. It's like some programer has too much time on his hands. Go find a girl or boy friend and get a life. I find linux at the administrative level become as unnecessarily complex as Window and MacOS which is why I switched to linux. Now I might as well switch back. Complex can be the doom of an OS.
That and that they work and are solid. In the systemd era tons of totally unneeded buggy features tops all.
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.
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.
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.
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.
Knowledge is power; knowledge shared is power lost.
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.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
n/a
Also reasons for 'beefing up' existing tools too = possible (stops ping detection & of course, also traceroutes). Windows has settings in the registry for it, & thus, since most all IP stacks = BSD derived, I'd wager Linux & other *NIX have analogous settings for it (& you can BET malware makers/botnet herders use it so a ping -a w 1 doesn't pick up on them saying they are 'dead' etc. on reverse DNS resolution that way).
* Doable in IP stack parameterization for initialization & behavior... & you do NOT need a firewall for this (search ICMP echo in a windows registry) RIGHT DOWN TO THE ENDPOINTS no less (in addition to firewall (software/hardware) blanket redundant methods).
APK
P.S.=> I agree w/ you on Techs/pure coders NOT knowing that end of things (or security really) - but it takes TIME to get that under your belt imo & experience... apk
...i like these tools
As for the efficiency issue of netlink vs. /proc, that has nothing whatsoever to do with the user interface. The implementation of the traditional tools could change and nobody would notice or care.
The problem of scripts parsing command output is a moot point too. Ok, so I have a script that parses the output of ifconfig. If the output has to change, there can either be a new tool or ifconfig itself changes. Either way, my script has to be changed. But slightly changing an existing tool will be far less disruptive on the whole.
This blog post, and the decision to switch to different utilities, is simply wrong. It was an objectively bad choice. But that's Linux for you these days.
Wish I had mod points for this one. You nailed it.
Only the State obtains its revenue by coercion. - Murray Rothbard
I thought that ss was silly until I actually needed its extended features. There's no way to add that stuff to the output of netstat without breaking everybody that depends on netstat. I still find myself writing `netstat -lanp` out of habit, but when I see that the queue sizes are missing I remember and do something like `ss -tanp` instead. This is definitely one of those cases where you're blind to what you're missing until you play around with it.
"[We'll be] really getting inside your head and making it an unpleasant place to be" -- Trent Reznor
Linux is diverging, like AIX and other's. It seems like a natural progression. Switched to FreeBSD a few years ago. Felt like coming home after a bad road trip.
Kanga: That's not a fish, that's a bird.
Pooh: Yes, but is it a starling or a mackeral?
See subject: I'm recently returned to Linux (1st was 1994 Slackware 1.02, sucked - next was Redhat 1999, sucked, next 2010 on KUbuntu 10.10 got pretty good, now KUbuntu 18.04 fully patched = NICE & fairly stable/solid but, Plasma does OCCASIONALLY "hang" & I've noted what really causes it (long waits on LARGE files, I work in them a LOT & I think it's more ext4 journalling than anything based on that).
* I.E. - It's NOT really the KDE Plasma desktop 'crashing', but I was impatient a few times & shut it down improperly (pulled plug, lol) & had to do fsck /dev/sda(x) @ startup a couple times...
(Eventually, I learned to WAIT a bit sometimes but Windows NTFS, which iirc, is ALSO "journalling" for rollback on error like ext4, isn't "like that" lag-wise w/ HUGE files (300mb & up string processing here) - it's instant almost (better cache & commit delay?)).
APK
P.S.=> Still, I am on Linux & FINALLY imo? It is "THERE" & the dev tools I use now are too (FreePascal & Lazarus) - I'm going to test a BSD (most likely PC-BSD w/ KDE) to port this soon (past Windows & Linux already working) https://linux.slashdot.org/comments.pl?sid=12157004&cid=56683552/ ... apk
I've been using linux off and on since 96, running it part time since 97, then full-time since '99. During that time Linux's commands have never been 'unix', they have *ALWAYS* been unix-like. Even ifconfig didn't match the output of bsd ifconfig for instance. It was *CLOSE* but you always had to cater to the gnuisms of linux interfaces, including /proc. Things got better for a few years in the early '00s when making sure linux met POSIX compatibility was a big focus, but first there was some utility I forget, then ipchains, then iptables, and now we're looking at npf or something for firewalls, while simultaneously sort-of support BSD-like pf scripting. Sorry if I am getting some of these names/details wrong. I have mostly picked a set of interfaces that are supported by the distros I run and standardized on them. The ip tool allows access to certain things ifconfig does not, but if you are just trying to make quick and dirty network changes to test things out, ifconfig wins hands down. The biggest issue with ip in my experience is documentation however. If I don't have a system with network access, trying to sort out what proper ip command syntax REALLY is, compared to the limited syntax description it provides in the ip help/manpage is often really taxing, and only by reading online does some of the error messages or more advanced syntax make sense. Most of these same complaints apply to systemd, lxc, docker, etc, including the kernel interfaces they rely on.
Personally, while I still use linux as my primary desktop OS, I have been looking to migrate for quite a while. The only thing still holding me to it is driver support, but since most of the hardware I trust and rely on is approaching 10+ years old I am finding less and less need for linux to retain support for software, outside of OpenCL/Cuda/Vulkan and a few ancillary features. If every once of my systems had 16+ gigs of ram and the desktop handled everything for me, maybe I would change my tune. But if that were the case, why wouldn't I simply be running windows? It provides the same level of security as something you don't understand intimately and since that continues to be what commercial Linux distribution leaders seem to want to turn linux into, who are we to argue with them? Linux, despite its small share of the front-end market, has become a victim of its own success. And with things like Spectre and Meltdown, the arguement of Monolith vs Microkernel has been settled, even if the software development resources haven't been reallocated yet.
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.
I've had at least four ubuntu/debian/devuan installs hosed thanks to ext4 root filesystems in the past 2 years over exactly that sort of situation. The combination of a seagate hard drive and ext4 specifially leads to massive filesystem corruption when the drive overheats and apparently somehow drops files or corrupts metadata. If the filesystem is in readonly mode and you copy them off, they will show up fine, but if you reboot, fsck will hose the metadata and leave you with almost the entire filesystem in lost+found instead of its proper locations. A lot of the directory names won't align with the filesystem contents either.
apt-get updates seems to affect it even more, but since the system is already hosed by the time it's happened, it is hard to provide a bug report on it, since it requires a very specific set of conditions to trigger.
The key points though are: using ext3 with data=ordered doesn't seem to exhibit the same issues. ext2 as long as you fsck every boot doesn't seem to exhibit it. But ext4 in either data=ordered or data=journal mode seems to exhibit this issue pretty consistently. As a result of it, seagate hdds are on my shitlist, as has ext4, which has any performance or filesystem space benefits offset by its apparently far inferior level of reliability.
As to xfs: Much like jfs the recovery tools simply aren't there for it imho, which is why I stuck to ext2 for so long, then ext3, and now back to ext3. I just wish they hadn't removed the ext3 filesystem driver, since at least a few times running an ext3 fs on ext4 caused issues thanks to inconsistent filesystem option flags between i386 and x86_64 versions of ext3/ext4 requiring you to manually fix your fstab when switching kernel arches.
It's not enough to introduce new things, to the possible sound of crickets. Old familiar things must be dragged out of their offices into the street and be publicly lynched.
<blink>down the rabbit hole</blink>
Number of distributions is irrelevant in all contexts.
They are more functionally compatible then this proposed change.
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.
See subject & RECENT returnee to Linux https://linux.slashdot.org/comments.pl?sid=12157004&cid=56683706/ as I FINALLY do like it after many times NOT liking it over 24++ yrs. (devtools especially now too are good & that's ME coming from a decades long Windows background in that) & I wasn't aware of THAT factoid (taking you @ your word as honest etc. & I do find it SURPRISING (& non-sensical to an extent - why build from 'scratch' if a 45++ yr. long proven FREELY GIVEN solution exists in the BSD reference design)) but question:
Is there NO way to disable ICMP echo replies in Linux' IP stack @ a configuration/init. level of IP stack settings in Linux?
* Again - I'd actually find THAT surprising to be honest... but, it's your show, & see subject! Good software = HIGHLY flexible/configurable. I find it tough to believe it can't be done in Linux when Windows CAN do it.
APK
P.S.=> It's been a bit of a 'leap' getting used to *NIX type socketry again porting my code for it from WinSock2 to *NIX vs. WinSock 2 @ a programmatic level (for the app I've ported to Linux from Windows already per the link and links it in above) but for the MOST part it's been pretty straight-up (raw socket work too) in code but as far as "config" type work? Hey, turn me on man (I am here to learn more) - thanks! apk
Reference design does not mean that the code has to be incorporated somewhere in all other designs.
Except it's not 285 ways to do one thing. Most of them are specialized, the others are hobby projects. Who the fuck are you to tell people they can't toy with open source software?
If an app requires version 2.5 of a lib, and another requires 2.4, then install them both. It's been possible in Unix/Linux since, like, forever. If your distro of choice maintainer has no clue how to do that, then the problem is in him or her.
Why use BSD style, when BSD is obsolete. Hp-ux is dead, six will die in 5years. Slowlaris is dead, freebsd is ..not used by anyone... I feel very entertained when I see in history netstat...
sudo pacman -S net-tools
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.
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.
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.
FUCKERS!
A design is valid if it works flawlessly with the reference design and has the same responses in all test cases.
Well, that might be true if the standard is written around a reference design but TCP/IP isn't.
If it works flawlessly with the "reference" design then that is a good sign, but it is by no means guaranteed that the BSD stack is bug free.
If it conforms to the RFC then it is valid, if it doesn't it isn't.
Testing is good but doesn't formally prove anything.
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).
If it conforms to the RFC then it is valid, if it doesn't it isn't.
First start with RFC 1796.
Next understand RFCs are static documents. They can be updated or replaced only by new RFCs which takes years of doing a days of work and sitting on your hands for the next 6 months until the next meeting to get published. Sometimes published contradicts the text itself. Sometimes implementing an RFC does not result in a compatible with reality implementation.
I've personally intentionally violated SHALLs and MUSTs on dozens of occasions in order to prevent unacceptable behavior. RFCs are sometimes full of crap. Many of them are poor quality.
See subject: Correct me if I'm off/wrong but this shows it's doable apparently (no ufw/iptables/ipchains or routers needed) https://www.thegeekstuff.com/2010/07/how-to-disable-ping-replies-in-linux// to disable ping/icmp echo replies (traceroute too unfortunately but iirc, it's BUILT on pings/icmp) MINUS using routers OR software/hardware firewalls & @ the OS workstation OR server level...
APK
P.S.=> ... & "there ya go" + I learned something today which makes it NOT a 'wasted day' (time to drink a few beers I say, holiday weekend & 'what-not' in the USA this weekend + my program's portings are going EXTREMELY well & yardwork/spring cleaning's done AND bills are paid so... off we go, lol))... apk
Clearly, the most important reason to remove tools like "ifconfig, netstat and the like"? Is because they work well and nobody complains about them.
I mean, good God people. (I mean, Hail Science!)
Between the non-stop SJW posts, Microsoft rules posts, and Linux needs to break everything that actually works, posts.
Why the hell are you here? Who is paying you? How does it feel to be the worst of Slashdot?
And normally, you only get an RFC accepted if you put up source that implements the proposed RFC.
n/t
>. 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.
This is all a bit painful.
These commands were established by 2014. Four years ago. The old syntax has been there for me on all the systems I checked. And nobody is mentioning the reasonable abbreviations. Try ip a or ip r for a surprise.
Chuck
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.
I posted this from my Lisp((()))) phone.
Some drink at the fountain of knowledge. Others just gargle.
Honestly, in today's world of 1080p monitors, why does 'ss' default to trying fill my screen horizontally and padding the fields out accordingly?
And when I say "by default", I mean "external hacks are required to stop it". Use "ss | cat" to make it better.
Otherwise I find the rest of iproute2 to be good. It's a necessity in today's Linux IP stack with network namespaces, policy routing, and other advanced routing decisions like preferring a specific IP address for outbound traffic.
I agree intermittently with other people. Though the new tool needs to be installed by default, the old tool shouldn't be thrown away just because there's something newer. "New" doesn't mean "better". (Lately that's been increasingly true)
BUT
THERE IS NO REASON ON THE PLANET TO REMOVE THE OLD TOOLS even if the new ones are ten times better. Nor to make the new ones defaults, or ram them down people's throats.
We have nearly 50 years experience telling us that ramming new features down people's throats is not the way to get popular. If we want something rammed down our throats, a quick search of pornhub will explain how to get there. The fact that we are here and not on pornhub is supposed to tell you something.
Yours
an ex-gnome user.
Parent is correct. The current routing is mind bogglingly complex and powerful with rules and such so you can sling packets in a hundred different ways. ip route /ip rule/ip link/ip addr et all are fairly well thought out. I wasn't happy with it at
first, but the fact sometimes you just have to learn new stuff.
There has been a bit of a revolution in the IT world to push out older admins. One of the ways in which they are doing it is quite literally changing the very systems we operate since companies are not as willing to retrain. It creates labour through necessity. The process by which it's done is somewhat methodical. Complaining that /proc isn't fast enough for ifconfig, is moronic.
It wouldn't at all surprise me to see more attacks on people like RMS and Torvalds directly to undermine them. They are certainly setting the stage with "rules of conduct" being thrust upon any project with a heartbeat.
This blog post, is just that, a blog post. I'm surprised they weren't advocating for json to be standard. No idea why it even hit Slashdot.
A lot of those tools like ifconfig, route and alike still do work in any Linux environment, containerized or not
They work fine as long as you have a very simple network configuration.
They do not work at all if you need vrf, policy routing, seperately scoped addresses, alias addresses (not the same thing as an alias interface)
If you get modded down, it's because you're ignorant and you don't know it, not because you're speaking the truth to power.
Why is it even using /proc? /sys.
It's pretty much deprecated for years already. All info for hardware devices is in
My point being that I don't think it's unreasonable to expect to know and understand every aspect of my system's behavior, and to expect it to continue to behave in the way that I know it does. I've worked on systems where you had to type the sequence of numbers that was the machine code for the bootstrap sequence in order to boot the system. I know how the boot sequence works. I know how fork and exec and the default file handles work. I know how my system is supposed to start from the very first process. And I don't mind changing those things, as long as I trust the judgement of the people changing them. And I very much don't, for a lot of this new shit. Not systemd, not wayland, not the new networking utilities. Still not enough to take matters into my own hands, though.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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?
But that is always the problem when a system relies on amateurs volunteering their spare time. You can't get them to do what is needed, what is correct or what the overall plan requires.
You can only get them to do what they think is "fun", or that panders to their desire for recognition, self-importance or other forms of emotional payback.
Even when it is third-party companies donating the code, they still only do it for their own self-interest. While some of that might be to further "the cause", a lot of the time it is for self-promotion or as bait for developers - you can spend time writing OSS stuff.
Whatever the reasons, it means that "Linux" can't get the software it needs, or the support, maintenance and updates. The best it can do is to be grateful for the scraps that people want to do.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
What are they? The post doesn't mention any.
That's because $0 isn't very helpful without symlinks, and creating a symlink on Windows prior to Windows 10 buid 14972 requires administrator privilege even if the owner of the symlink and the owner of the target file are the same.
that's the problem. Its this kind of idiocy that makes people think windows 10 is a good gui.
Soooo irritating when I type ifconfig and this shit ain't found. Then I have to go on Google and look for the alternative command. Completely throws off my flow. I hate these people who try to change this shit. Fuck you.
... is that they often ship before they're ready, and don't stabilize for a long time, so when you are trying to figure out how to accomplish something, what you find on the Internet is a collection of popular hits which correspond to an old version of things, or a collection of thesis papers about how things should work.
As a for-instance, I've found it nigh unto impossible to decode systemd stuff. Don't get me wrong, I can see that there's an architecture in there, and I can see that it can likely accomplish what I want to accomplish, the problem is that there seem to be like 7 places where config files live, and configs are broken up into many pieces for different phases of things, and all of this interacts. So where an old-skool init-style system was just a shell script which you could easily write and test, now a bit of what you want to change can live in 21 different places, which aren't consistently binned across different sub-systems, and you can't easily test things in isolation. Oh, it didn't work - why? I don't know. Again, with init it was a shell script, you could usually just run it manually to see why it was failing, but under systemd the log output goes ... somewhere. Which you can figure out, but again now you're researching systemd architecture instead of solving the problem you came here to solve. It feels like C++ mindset applied to system startup.
And that's even before you've realized that the particular package you're trying to figure out is still maybe using upstart. Or init. And nobody documents that, so you have to figure it out via detective work. Fortunately find and grep still work, for now.
The 'new' tools turn turn 22 this year.
I first starting using them for LARTC about a decade ago, and was first *forced* to use them in RHEL7. Since then, I use them exclusively now. It's easier than trying to remember the idiosyncrasies of net-tools that give you straight up bad information on machines that may have complicated network configurations running on them.
Initially, I installed net-tools on every RHEL7 machine I deployed. I think I probably did that for a month. The last 40 or so are all net-tools free.
My APK Hosts File Engine 2.0++ for Linux (GTK3 via FreePascal + Lazarus 1.8.2) yields more security/speed/reliability/anonymity vs. ANY SINGLE solution (99% of threats = served by hostname vs. IP address (that most firewalls use)) more efficiently & FASTER + NATIVELY 4 less!
Cool story bro
Too bad that is all it is
From the very beginning... Linux (the kernel) was conceived as a UNIX clone...
.plan ----
Linus:
---- my
Free UNIX for the 386 - coming 4QR 91 or 1QR 92.
The current version of linux is 0.11 - it has most things a unix kernel
needs, and will probably be released as 1.0 as soon as it gets a little
more testing, and we can get a init/login going. Currently you get
dumped into a shell as root upon bootup.
-- End --
All the "utilities" that sit on top of the "Linux kernel" are gnu based utilities that predate Linux etc. This was not an accident.
https://en.wikipedia.org/wiki/Schutzstaffel
Familiar story. Just following the path of SystemD.
Looks like something is intentionally working towards breaking a beautiful working UNIX culture and philosophy if you like with all these useless changes to the UNIX systems. What is next you morons?
Devuan is a most useful up(!)grade from Debian which is systemd free and has a mindset that will resist this nonsense too. I'm using it on embedded devices, servers and as my desktop environment - the only exception being my Android/Chromebook devices. http://devuan.org/
Paul Beardsell
Factually wrong.
Windows has it's own stack, even though the initial one was BSD derived, but it got thrown out for being shit. Which basically leaves you with the various sorts of BSD implementations, not sure about OSX. Either way, the vast majority of all systems does not use the palaeolithic, under-maintained and under-performing BSD code. So Sad!
Stop messing with it, son.
From Nmap weâ(TM)ve learnt that no one implements it the same, not even same OS across versions. No one is validating to the BSD implementation
Most of the very low level parts of Linux are pretty decent because Linus keeps a close eye. As much as I love BSD, having a monoculture is not good long term and Linux has provided some competition, encouraging BSD to push forward where once stagnant. There's also a few situations where Linux spearheaded something BSD wasn't entirely sure about, allowing BSD to learn from Linux' mistakes and finally getting it done.
Overall, Linux has quite the Not-Invented-Here culture, not only reinventing what other's have done, but also what they have done.
At least with old tools, you know the limitations inside and out
Just fuck off you boring deluded cunt.
TFA's comments are the reason why having this dicussion is unproductive. Below and above you will find a bunch of butthurt, namecalling, and wrongthink accusations. There may be truely insightful or informative bits amongst the kilobytes of garbage, but you'll have to dig pretty hard to find them. Just digging through it makes me want to find something else to do. The discussion around the issue has become so repungent that you'd be insane to try and deal with the actual issue. All of you are scaring off every last person that may try to help you.
Note: In my opinion, not that it matters, I would say that if net-tools were updated to include support for the new functionality this whole dicussion would be a non-issue. However as others have already stated: It's not a priority for the net-tools maintainers right now, and hasn't been since they were notified about some of the issues in 2013. Unless that changes, people will naturally need to use other tools if net-tools doesn't provide the functionality they need.
...I don't care what you do under the covers if it improves things somehow, but don't gratuitously change the user interface.
I used to get really angry about things like this. I've seen one initiative after another after another, to get transparent, open, non-corporate software and standards obsoleted, and replaced with incomprehensible corporate crap, which ultimately has no other purpose or effect, than to eliminate the ability of the end user to either understand or control, the hardware or software they use.
I am becoming resigned to it, however; because I've realised that the relentlessly tenacious, compulsive stupidity and amorality of the Millennials can not be defeated. They rammed systemd through, and everyone just rolled over and capitulated, and anyone who didn't was just called a troll until they shut up.
So go ahead. Destroy everything in the name of corporate profit and looking superficially cool. In the end, you'll only harm yourselves.