Dev nonsense: netstat and ifconfig

Updated: August 18, 2018

I would like to brag for a moment, if I may. As it happens, bless me mom and dad, they have bestowed upon me the best bullshit detector in the world. It's an uncanny thing. Sometimes I am reading something online, and all of a sudden my eyes start to twitch and water. I begin sweating, and my lips are forming juicy swearwords in five different languages. It's happening. My bullshit detector is firing.

The klaxon usually goes to nine every time I read an article telling us why the old, proven network utilities like netstat and ifconfig need to be deprecated and replaced by some new tools that do exactly the same thing except they happen to have been re-written by some hot object-oriented jockey enamored with Python or GOLANG. This is among the biggest pieces of digital turd ever conceived, and I need an entire article to express myself. Please join me for an expletive-saddled ride.

Job security

We all know that modern software development is cancer. It's a new fad, propagated mostly by big companies in dire need of cannon fodder and cheap slave labor, who tout software development as something cool and hip and modern. Quality is not important. What matters is that people churn out code, play games in the dedicated game room in their shiny open-space building, and that words like agile and scrum are used frequently.

Moreover, there is very little real innovation in the software world, including Linux et al. If you think hard, the last big revolution was possibly, arguably the invention of mobile, touch-devices around the era of Palm or so early in the century. We are now only touching the realms of VR and AI, but that's still mostly the domain of the academy and a few giants. The rest? They are playing silly games in their digital sandbox, mistaking activity for productivity, getting gently drunk on the glorified idea of what software development is.

Software development is not an enviable domain. Because it's entirely replaceable. It has no intrinsic value. It's a means of putting ideas into practice, but the same was done with punch cards, wires and vacuum tubes, so it's only the technological medium that has changed. In twenty years, there might be a completely new way of creating machine interfaces, and software development as we know it will disappear.

If you think I'm talking nonsense, take a look at any which programming language. They come and go. They are entirely interchangeable. Windows, Linux, infotainment systems. The underlying code is not important. No one cares if Android runs this or that Java library. No one cares or knows what .NET means. For normal people, software is a million times less important than the color of their phone cover or if they will have a sufficient number of cup holders in their car.

Software languages come and go. FORTRAN, C, Perl, Javascript. Irrelevant.

This puts software developers in a difficult position - even if they are not aware of it. They either write code to meet an end goal (i.e. product specifications) or they develop code for their own sake.

Writing code to meet someone else's notion of functionality does not sound glamorous. And it's not. It's an unrewarding job of conflicting messages, shifting priorities and non-stop testing - at least that's how it's meant to be done in real companies that ship products to their users. Software development is not fun. In essence, software developers are like brick layers; they build a house to meet the architect's vision.

The alternative to this existence is writing code for the sake of it - like painting or writing books. It's a mental exercise that allows the specific type of mind (the kind that likes code) to exercise its intellectual freedom. Not bad on its own.

The problems start when this kind of mind projects its own internal state onto the bigger world.

Meet the world of open-source, where object-oriented fun wrestles with functionality.

Code for the sake of it, the outside world does not exist

The purpose of life is to survive - to propagate. The same is true of software development. If you write code once, you're done. Unneeded. Irrelevant. Obsolete. The solution is to continuously write code, of course. Products never get finished. It's always the next iteration or the next sprint or the next bullshit. There's no end goal. Only more code. Once you finish a project or get bored, you start a NEW project. You find reasons to justify your existence.

And so, every few years, we hear of a new initiative to replace the old with the new. Not because there's a reason. Simply because it allows software development to continue existing. Thus we got Wayland, which still isn't ready to replace Xorg. The reason for its existence? Wait for it. Quote mission statement, and I'm not joking: to make development easier. What? Since when is the life of a glorified digital welder supposed to be easy?

Thus we got systemd. Does it serve any real purpose? No. It's complicated, it's difficult to use, and the only reason it's there is to replace init, which was doing a good job. But you may say: wait, init wasn't doing a good job! Really? The Internet was invented, we got mega-super-computers and data centers filled with hundreds of thousands of servers long long BEFORE there was systemd. It was done with init.

Just compare how simple - and intuitive - it is to list running services with systemd compared to init. For instance, it's service --status-all with System V init. What can be simpler than that? With systemd, you have systemctl list-unit-files --state=running (or any relevant state). What. Or perhaps with chkconfig --list, you'd get a list of all services, both ON and OFF for each runlevel, listed nicely. With systemd, you need systemctl list-unit-files | grep enabled. Do you get more functionality? No. Do you get better functionality? No. Do you get better or simpler commands? No. Is list-unit-files logical? No. Everything happened with init in place. If init was so bad, this would not have happened.

The other two tools that helped us on this ride were netstat and ifconfig.

Tens of millions of mission-critical servers were set up using these lovely tools. Complex data center networks run out there, sustaining the backbone of the Web, the entire world really, and all of it was done with tools created roughly thirty-five years ago, long long before any agile crap.

But now (dot com era crisis post-modernism if you will), the devs don't like these 72kb heavy tools, because they don't satisfy random, corner cases that no one really cares about - primarily in NEW infrastructure environments created in the past few years, because they have been designed in an odd and inefficient way. But hey, it's an opportunity to write NEW code, and nothing else matters.

A clash of mindsets

Writing code takes a special type of brain. I'm not saying this in a disparaging view. Being a mathematician requires a certain personality. Being a salesman requires a different type of personality. Lawyers, doctors, pilots, they all take their special mind tuning. Writing code also mandates its own cranial topography.

On its own, writing code isn't anything magical. But to be able to sit down and do this for 7-10 hours every day and really enjoy it, you need to have your brain adapted to this kind of task. Unfortunately, such mindset is completely opposite to how people (read users) perceive technology.

Which is why products designed by developers are usually horrible from the UX perspective.

The kind of mind that likes to see things in some binary, object-oriented way is not suitable for making abstract decisions on shape, form and function. That requires a philosopher's mind. The Ancient Greeks got this right. The philosopher is the one who defines things. And then you have the military to support him/her and the masses to execute his/her wishes. That's how it's done.

The software world is an exception - and an anomaly. This is a hot new playground, and so, the bending of rules is temporarily allowed, because it suits the powers that be. Big companies use the "devs R kool" approach to attract people, because we're still deep in the second industrial revolution, transitioning from analog to digital. And the same way steam engineers were once so highly sought after, so are the modern digital welders nowadays.

In the near future, there won't be any need for so much digital bullshit - all these buzzwords, useless whatever as a service and similar nonsense. There will come a point - once we develop practical AI - when developers will become as redundant as coal miners. Some will be needed, of course, but not nearly as many as today. At that point, only the top talent will be retained, and in corporate words, the rest will need to "retrain" their skills. We're about 30-40 years from that point yet. Mark my words.

This is why bullshit is allowed and tolerated. Attention-deficit kids with multiple monitors and whatnot are allowed to hammer down half-baked solutions, because the market is thirsty for labor, and it will soak up everything for now. Add good salaries, and this creates an illusion of unwarranted self-importance.

And so, occasionally, the devs tread onto the philosopher's turf, and things go bad.

And then, you get stuff like: oh, let's obsolete ifconfig.

Reality check

So, there's a claim. Old network tools are not good enough. On its own, this claim is neither good nor bad. It's something that needs to be verified with quantifiable facts. All right. My claims for are simple: tools do not survive thirty-five years of hard service if they are bad. Simple.

Moreover, I have worked in hyper-scale data center environments, with 10,000s of interconnected servers running HPC workloads against a massive, global storage backend, and there were many constraints that we had to face and deals with. Big, serious complex problems. The use of netstat or ifconfig was never an issue. That's real life, not an academic point on whether a user-space command takes three or six compute cycles.

Actually, no. Sorry. This is not true. The ONLY time we did have problems is when - again for stupid reasons - the naming convention for network devices was changed from sane ethX to enpXsY and similar nonsense, and we had to use custom udev rules to override this crap.

Now, from the dev point of view, the world is binary. If a tool does not do something - usually an obscure, corner case - it's a failure. Then, there's the speed and efficiency aspect. The speed factor is irrelevant for user space system administration utilities, because by the time the system calls have finished running, the user had barely lifted their finger off the keyboard.

This isn't just some random scenario. There's no reason to run netstat or ifconfig a thousand times per second or anything like that - if you do, you're doing it wrong. The setup of network interfaces is usually done during the boot sequence, only ONCE, especially in mission-critical 24/7 environments. You don't arbitrarily stop or start interfaces. Speed would be of essence for say memory allocation or disk access, done millions of times per execution of a task. Not so here.

Actually, maybe. If you're a giant search provider, and you're spanning thousands upon thousands of containers every minute, perhaps you do need special tools. How many companies do that? Three? Five? The rest are riding the hype, as in: do like the giants, you'll be a giant. Nope.

But you know what, let's assume that there are certain broad-purpose new types of functionality that these old tools do not do. This is possible, because, after all, ifconfig and netstat were designed a long time ago.

The solution is to fix them - retain the familiar format and backward compatibility.

Not replace them with "new" tools.

There's everything wrong with the dev-centric approach to this problem. If anyone should be asked what the tools need to do, those are system administrators, people who actually USE these tools in their work. The sacred users. The only audience that matters. There's also the matter of ego - everyone wants open-source, provided it's THEIR open-source. Everyone wants to be THE dev who made the difference, and their tool is the dominant one. That means always seeking opportunities to asset dominance - obsolete existing tools and create something new. In this regard, we're following the Darwinistic model to the letter.

And then, I need to talk about another gift that I have - technical intuition.

I have excellent intuition when it comes to software and products. I don't need help pages, I can figure out what products are supposed to do right away. Provided, of course, that these tools are designed by someone who actually has an understanding of USERS. Right.

Pretty much the entire breed of NEW software (last 5-6 years) is complicated and non-intuitive. It's designed for the OOP mind. It has no place in the hands of actual users. If I struggle with a piece of user-space utility, then you can be certain that it's crap and should be sent to outer space, straight for the Sun, and broken down into constituent atoms.

Part of that complexity is by design - like cloud systems and interfaces, "modern" tools semi-sponsored by tech companies. They are difficult so you would be inclined to ask their "professional services" help in figuring out how to use useless, bloated things that shouldn't exist in the first place.

On topic, for example, using ip instead of ifconfig (just a tiny example) - and please wait before you say ip is also an old command and whatever. Follow my example to the end, and then decide if it's useless:

ifconfig eth0:0

ip addr add brd dev eth0 label eth0:0

Wait, you say. The two commands are not equivalent. Nope. Because ifconfig by default uses /24 and will set the broadcast address to the last address in the segment. Ip will set /32 and use as the broadcast address. In other words, using just ip addr add dev eth0 label eth0:0 gives you the following difference:

eth0:0 flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet netmask broadcast

eth0:0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet netmask broadcast
ether 68:f7:28:6d:d4:b1 txqueuelen 1000 (Ethernet)

You may say, use an alias option to make the ip command shorter. That's still more useless activity. And then, reading the man page, alias is only mentioned, but there's no actual example, plus this:

The address is a protocol (IP or IPv6) address attached to a network device. Each device must have at least one address to use the corresponding protocol. It is possible to have several different addresses attached to one device. These addresses are not discriminated, so that the term alias is not quite appropriate for them and we do not use it in this document.

So, we have functionality that does not quite work in the NEW and improved tool. Hint: ip is an old command, introduced sometime around the kernel 2.2 branch or so, but fast forward a couple of decades, and we have a "replacement" tool that has massive shortcomings. It is, however, a development heaven!

The ss command is another gem, or rather another utility to investigate sockets [sic]. The VERY description itself tells you this is something that should not exist (another utility). But say you want to do some online search, y'know, just to get the hang of how to use this tool. Checking quickly on Google, the first search result will take you to the Wiki page on WW2 Germany. You can now combine ethno-politics with system administration. This is sad. It's a purely accidental bad naming choice, of course, like Pen Island of Therapist for a site, but it emphasizes a complete lack of user focus in its creation.

Tool names need to be meaningful. Ifconfig means interface config. Netstat means network statistics. Ip means nothing. Ss means nothing. Maybe we should switch to single letter tools? That should teach them!

P.S. I know you're already arguing "but Dedo, ifconfig cannot this or that." Wait. Did I say that ifconfig is the perfect tool? It is not. It can't do everything - and it's not supposed to. You use it alongside netstat and route and whatever. But it's a perfect tool in the sense that it's small, light, simple, and modular. That's how tools should be designed. UNIX philosophy - KISS. Not over-complicated undebuggable monstrosities.

P.S.S. Is ip useless? Absolutely not! It has its uses. And that's the thing. EACH tools has its uses. A single tool that does everything is just a compromise that does nothing.

Backward compatibility

This is the pinnacle of everything we have discussed so far. At the moment, there are MILLIONS of scripts out there in the wider world, from tiny companies to huge enterprises, that rely on ifconfig and netstat to parse system information. Using the "new" tools technically means replacing an endless amount of valuable, proven code and system tools already in place - that ACTUALLY WORK, LET ME REMIND YOU - for no good reason other than whimsical child-in-a-sandbox type of dev games.

Moreover, the server world - the corporate world. It's dominated by Red Hat and then SUSE, or shall we say RHEL and SLES, respectively. And the primary reasons are: excellent 10+ years support, fanatical backward compatibility and no ABI breakage. Hence, almost 100% market among these two. Do you think medical systems or financial institutions can afford random bullshit changes every now and then? Do you think it's all just a silly game?

As a user, it is your sacred duty to resist this bullshit by all means necessary. You must never allow random, arbitrary boredom to intrude into your world and affect your productivity and efficiency. Any which tool that adds more work (rather than take it away) is shit. And pretty much any user-space "tool" in the past six years or so only adds work. Inefficient bullshit. Windows 8, new system settings in Windows 10, Gnome 3, Systemd, Wayland, and this new breed of "dev" tools for "system administration" - see the paradox right there?

Indeed, why are DEVS even bothering with SYSTEM tools? One day, I would like to able to write something nice about software methodologies, new algorithms, more efficient ways to schedule tasks or use the memory, some new breakthrough in coding. But I guess that's reserved for true giants like Turing, Shannon, von Neumann, Ritchie, Berners-Lee, and Torvalds. And THAT is where the philosophy and purity and art of software development really lie! Oh, well.

The 10 commandments for healthy coding

I compiled this short list, so anyone involved in code and product can refresh their mind now and then:

The users are sacred; without users, software is worth nothing.

Writing code is neither special nor glamorous; it's a means to an end.

Product design should always be done by a philosopher, a person capable of abstract ideas.

Backward compatibility is like your one remaining kidney; preserve it at all costs.

Software tools need to have meaningful names.

Do not invent 99% new tools to fix 1% in the old tools.

Create a fully functional replacement (not a rolling 20% done agile crap) before you remove the old one.

Changes need to be transparent to the user (done under the hood); if you disrupt the user space, you're doing it wrong.

Don't get enamored with this new-age Millennial-crap buzzword religion; you're just an well-paid tool.

Your software language is completely interchangeable.


Here we are, the rant, end of. I am not happy writing these kind of articles, because one may assume that I have something against developers, especially since most people don't actually bother reading, and I can already imagine the discussions on forums and boards around this - in fact, please do me a favor, don't link or share, just read. Anyway, I have nothing for or against any particular group of people. It's nothing personal. What I detest is pointless bullshit.

I hate when people disrupt efficiency, productivity and results without an end goal. If someone could say that some new tool will bring in 850% improvement in speed or accuracy or something, I could accept the necessary change and sacrifice. But changes for the sake of it are bad. Development-driven product design is wrong, because it caters to no user. Complication and obfuscation that have become the norm today are evil, and they must be resisted.

Finally, a simple question: will ifconfig and whatnot die? Perhaps. Things change. In a decade or two, no one will remember the fights and the bickering. This happened a thousand times before. But that's no reason to let stupidity and bullshit waste your time NOW. After all, 'tis the survival of the fittest. As the user, the actual person fighting in the trenches of data center, you have the final say. Use it.


You may also like: