I have a few issues though:
* "ip" is useless as a keyword if you're looking for help online. It's extremely frustrating and probably my main issue actually learning how to use the damn thing.
* ifconfig's output is simply more readable IMO: https://svkt.org/~simias/up/20180525-113825_ip-vs-ifconfig.p... . It's pretty weird that a brand new tool manages to have worse output than a venerable old unix command. Because of this I often end up configuring the network with ip only to double-check everything is right with a quick ifconfig. That's silly.
I think at this point I would've preferred if they had made an "ifconfig2" instead, mostly identical to the old one but with a few breaking changes to add the missing functionality. An incremental update instead of a full rewrite. There's definitely some NIH going on.
Yes, this is key, and why ip is so terrible for the way I currently work. No doubt I'll have to get used to it, like those stupid biosdevname interfaces.
90% of my machines don't have more than 1 IP per physical interface, the rest are aliases
ifconfig outputs clear whitespace, so picking out the specific details of
- interface name
- ip address
Is far easier. I do prefer /28 to 255.255.255.240 when specifying subnets, but it does make it far harder to scan what the IP is. I suspect the people writing the utilities are the ones who are able to automate everything, as they do the same job 1000 times, with IP in, IP out, and no concern about physical devices, so rarely use the tool to read data, certainly not as a human.
You've then got the "what's the default gateway" problem
shows it nice and easy
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.26.32.1 0.0.0.0 UG 0 0 0 eth0
172.26.32.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0
ip route -n
Command "-n" is unknown, try "ip route help".
It's all good having tools to manage lots of ip namespaces etc, that's great in the subset of cases you need that functionality, but for those of us that manage physical machines with physical inputs/outputs, rather than datacenter scale devices, it's a right pain.
> > ifconfig's output is simply more readable IMO
I prefer iproute2's terseness.
Adding more punctuation to delimit the fields (, : etc...) would be nice too. I mean what the hell:
mtu 1500 qdisc pfifo_fast qlen 1000
I once tried to use tc and gave up after more than a day of trying, that is how bad it is. The syntax is a word soup and the semantics are very poorly explained.
tc is implemented by packet pacing at either egress or ingress steps.
and this is how iproute2 compares to the old net-tools stuff: https://linoxide.com/wp-content/uploads/2014/05/Linux-Nettoo...
regarding UI/UX/CLI. yes, there's no arguing about it, it's just horrible. no documentation, no discoverability, no sanity. but it works, and it's free :o
I'm with you on tc having the worst interface and documentation that I have seen from a command before. I spent maybe a few days total on it then gave up because I figured if there isn't much documentation on it, it isn't worth figuring out.
tc fit the bill nicely.
valid_lft forever preferred_lft forever
RFC 3484 "Default Address Selection for Internet Protocol version 6 (IPv6)".
> ip route | column -t
(With iproute2 4.3.0, I get the same output between "route", "route show", and "route show default"; no idea if it's changed since.)
Alas it doesn't work quite so well for "ip addr". It would have been great if they'd just decided on CSV or JSON or whatever and then relied on secondary utilities to go to "pretty-printed".
ip --oneline addr | column -t
ip route get X
I do use ip route a fair bit - if I have a machine connected to two (or more) network segments and want to ensure traffic gets routed back the way it came
However my main criticism for "ip route" is that it's inconsistent and a change route "route"
"route" does reverse dns lookups - e.g "my.server.tld rather than "18.104.22.168", or "default" rather than "0.0.0.0"
"route -n" shows 22.214.171.124
"ip route" doesn't do reverse lookup, however it does say "default" rather than "0.0.0.0".
Looking at it more closely now, ip addr's output doesn't seem that difficult to fix. Remove that random number before the adapter name (what the hell is that anyway? The order in which the adapter appeared? If so, why are not in that order?)
I think that alone would make it so much more readable! Maybe white space between each entry with a flag?
All of the help sections are awful too. I feel like I'm looking at language grammar definition instead of useful usage information.
Most docs will mention iproute2. You can use that for googling.
Of course in the specific case of "ip", both are going to return quite a haystack to search through...
> $ which ip
> $ dpkg -S /sbin/ip
> iproute2: /sbin/ip
I use cope to colorize my output, which makes 'which' useless to me for most common commands, but 'whereis' still works.
Edit for examples:
$ which ip
$ whereis ip
ip: /usr/bin/ip /usr/share/perl5/vendor_perl/auto/share/dist/Cope/ip /usr/share/man/man7/ip.7.gz /usr/share/man/man8/ip.8.gz
$ command -V ip
ip is /sbin/ip
$ command -V ll
ll is aliased to `ls -AlF --color=auto'
$ command -V command_not_found_handle
command_not_found_handle is a function
if [ -x /usr/lib/command-not-found ]; then
/usr/lib/command-not-found -- "$1";
if [ -x /usr/share/command-not-found/command-not-found ]; then
/usr/share/command-not-found/command-not-found -- "$1";
printf "%s: command not found\n" "$1" 1>&2;
Thanks for this! After 14+ years of using Linux almost daily, I had never heard of this command. I learned something new today, so now it's time to go home!
That being said while docs specifically written about the tool will probably mention it random forum posts, tutorials or even stackoverflow questions may not.
I don't know the decisions behind the naming either, but the ip shell command comes as part of the iproute2  package.
After I found out about this googling became much easier.
The point is that searching for "ifconfig tutorial" is going to give you what you want, while "ip route" is probably going to get you Cisco documentation, honestly. Even something like "parse ip output" is going to give you a mix of results from Linux, Windows, or web services while "parse ifconfig output" is a lot more clear.
"ip" is simply a saturated keyword, making it a bad keyword.
`ip` takes a --oneline arg to make it more parseable.
The only real gripe I have with IP is their long argument/switch format. Unlike everyone else, ip is a minority, which accepts long options with single dash "-". This prevents someone from combining many short parameters under a single dash, also it's confusing to use.
Yes, it unofficially supports the old double dash format, but if you are supporting it, there's no point in supporting single dash long options.
The flags that a UNIX command uses can sometimes used to carbon-date that command. For example, dd(1) doesn't use a dash at all, uses long args, and uses an equals-sign to connect a flag with its argument (e.g. `dd if=/dev/null`). It's because dd(1) was written in the dawn of UNIX, before a convention was established for flags.
I believe the first step in creating a convention was the introduction of the getopt(3) library, which introduced single dash, single character options (e.g. `tar -x`). Commands that only have short options tend to be old commands.
Later, GNU introduced getopt_long(3), which allowed for long options and double-dashes to distinguish them from the short ones. This made commands more readable.
There have also been cases where the `-` is optional. `tar xvf` for example. And with the `ps` command, the `-` is used to distinguish BSD flags from System V flags (e.g. `ps auxwww` vs. `ps -elf`).
There has also been a movement for subcommands rather than options (which bring to mind the Cisco CLI), of which `ip` is an excellent example: `ip route show`. But subcommands are not a substitute for options; sometimes you need both (e.g. `ip -6 route show`).
All this goes to show that, although long options are quite common, they are not only game in town, and UNIX commands have a rich and varied set of conventions.
Old versions of sort used a + to begin some options. So yes, there has been a lot of variation over time, but I see no reason to gratuitously diverge from the common standards now in use, unless following them is too restrictive in some way.
Extreme flexibility becomes a burden after a certain point if it lacks adaptability.
Standards are built for these reasons.
For the `find` command the single dash is for predicates not for options (not that it makes a whole lot of difference)
You'll find them in ex-Bell labs people (e.g. go-lang) and associated (docker).
The double dash was born in the 90s; there was a poll on Usenet gnu.misc (or similar). Those who did not habituate usenet didn't get the memo.
gcc uses single dash for long options too: -std, -pedantic, -dumpspecs, etc.
I am sure there are many more modern commands that do this.
Neither are for 'dd' or 'tar' (probably 30 YO) from the other comment.
There are probably other, younger commands not following the --long-option pattern, but i think that doesn't make it better to break this convention.
Not all subcommands support it though.
rascul@coyote:~$ ip -json addr
Option "-json" is unknown, try "ip -help".
rascul@coyote:~$ ip -V
ip utility, iproute2-ss160111
Mind expanding NIH?
It's better that the command you type often is short, (you can certainly alias ifconfig as "ifg" or anything too).
Take for instance a very simple query: "ip show default route":
There are a few obviously relevant matches in the first page but also a bunch of completely irrelevant results. Adding "command" doesn't improve that much. And that's for a very simple query that's probably been asked hundreds of times before.
Meanwhile if I search "ls sort date" I get mostly relevant results immediately because even though it's also a 2 letter identifier it's not quite as ambiguous: https://duckduckgo.com/?q=ls+sort+date&t=ffab&ia=qa
Let alone the non-conformity of other OS's like Solaris, HP-UX which really might not matter now. I'm sure FreeBSD matters to someone... just not me
$ ip -br -c a # ip -brief -color address
lo UNKNOWN 127.0.0.1/8 ::1/128
wlan0 UP 192.0.2.1/24 2001:db8::1/64 fe80::1/64
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 DOWN 00:12:34:56:78:9a <NO-CARRIER,BROADCAST,MULTICAST,UP>
wlan0 UP 12:34:56:78:9a:bc <BROADCAST,MULTICAST,UP,LOWER_UP>
Advanced options should be behind flags for power users, not the other way around.
That said, a new alias that does trigger these new behaviors as defaults would be a sane compromise.
Option "-br" is unknown, try "ip -help".
Friggin' RHEL I guess I'll have to check back in a couple of years.
That's crazy helpful. I'm aliasing it as well.
(FYI --color works too)
Now, Linux is slowly going rouge and changing everything in the supposedly name of "progress" I'm still salty as hell with the systemd rubbish. The problem is that all the cool toys are supported better on Linux and I don't feel like compiling from source for most things. :-(
SMD was based around XML, which caused a lot of boaking.
systemd was based around .desktop, aka .ini syntax.
It did take off and had a long and productive life.
Many, many of the early ISPs and webhosting providers were built on Solaris 2.6 and "7". In the late nineties it was very common to go into a datacenter and see racks full of ultra 2 boxes stacked on one another ...
If you went to college between 1992 and 1999 you were almost assured to log into a SunOS or Solaris system to read your email or ftp or whatever.
It was only when the dot-com money dried up that people (including myself) made the switch to PC based servers in an effort to save money.
Damn it, Apple have a similar thing going in OSX (or whatever their greasy marketing wants to call it this year) but when it was basically offered to the BSDs on a silver platter they didn't want it.
Launchd is mostly crappy, obtuse plist files, a semi-broken DAG, socket activation that spins your machine to death.
SMF was an access point to many things, it was clean, concise and pointed you towards the actual things that the OS provided. (like; log files) It was a pleasure to work with.
The only problem was that service definitions were configured with XML, I have never been a fan of XML.
Because Larry Ellison bought Sun.
I would imagine that there are a few others in the thread that read this article and felt similar.
With such a dominance there is not much point in syncing changes of the standard with other OSes. The moment it works different in Linux that is the new majority standard.
And while a lot more stuff is changed all the time than would be necessary one also can't expect things to stay the same for another 100 years just because they have been like that for a long time.
> the BSDs were the winner too at one point
When was that point? Strong doubts about that.
Above the kernel it is a wild west, with each "platform" implementing their own stack for anything beyond the core-utils (and those are more likely to be busybox based than GNU based for political reasons).
If I understand the term userland correctly it is a term from kernel developers to say "this is code that doesn't run in the kernel", so it might not be helpful to any popularity discussion at all.
Linux dropped the cost of using UNIX down to zero. And it's not like everything was this cross-UNIX Utopia where things worked from system to system consistently and reliably.
We went from a set of highly proprietary and expensive OSes that ran on hardware that a common person had no access to to something that nearly anyone can use.
That's way more important than having to adjust your skill set for new tools over time!
"Linux is only free if your time has no value."
I've been using it personally and professionally for over 20 years now. Unless you're specifically using the term "cost" to mean solely money, it is in no conceivable way without cost. There is, for example, a significant cognitive burden involved in keeping up with the ceaseless parade of travesties committed by people trying to "make things better" in Linux, who instead just compromise the system for those of us who disagree with their notions of betterness.
I'm reminded entirely too much by some corners of the Linux community of Apple's "We know what users want, and give it to them good and hard" attitude.
BSD had already done that, better, and earlier. Let's not try to rewrite history.
The legality of the free versions of BSD did not get resolved till there were many Linux users -- probably more Linux users than there were users of the free BSDs.
No, the issue is that no one at GNU or Linux cares about correct, simple tools (2 APIs for networking in the kernel?! What happened to manpages?! WTF info?). And thanks to that it runs on anything.
Pick your poison
See, for example, https://svnweb.freebsd.org/base?view=revision&revision=31237..., where the author added support for hardware packet pacing. The commit touches ifconfig, socket header files, and various parts of the kernel all in one atomic change.
This is easily disproven: ifconfig on FreeBSD doesn't rely on /proc and handles aliases just fine.
It sounds a bit like the whole OSS/ALSA discussion – some argued that ALSA was needed to replace OSS because OSS didn't support muxing multiple simultaneous audio streams, but strangely OSS on FreeBSD did support it, with no need to replace the entire audio API.
Linux's ifconfig is a part of net-tools (http://net-tools.sourceforge.net/) and the latest release of net-tools, v1.6, was released in April 2001. It's been unmaintained for over 17 years. Some distros began deprecating ifconfig when the Linux 2.2 kernel was released because it lacked features. The Linux ifconfig command doesn't support wireless network devices because they essentially didn't exists when the the command was written. Shit's old.
It's like comparing Seamonkey to Netscape Communicator.
There's a simple solution to the lack of maintenance on ifconfig: Maintain ifconfig.
There's no need to break shit.
My understanding is that the Linux version of net-tools was based on the BSD software, but I don't know how much code is actually shared between the two projects. It was intended to be syntactically equivalent and support the same features (at the time). You'd probably find it easier to write a net-tools-like wrapper for iproute2.
Yes, someone could have just extended net-tools. But nobody did. Instead, they wrote iwconfig and other tools when they were needed, and then someone decided to write a competing package, iproute2, that did everything. And that package added feature support when they were added them to the kernel, and bugs got fixed. Those didn't happen with net-tools unless each distro took care of it.
I use BSD. And while I would send in patches for ifconfig, I haven't needed to. I have sent in patches for other things.
So is the Linux ecosystem just going to rewrite tools everytime their original developer moves on or passes away? It's going to happen more in the future, so are we going to see more and more rewrites in Linux?
There's something to be said about the BSD approach of maintaining the OS (kernel + userland) as a whole. They don't seem to have this problem.
 It does support "interface aliases" and that seems to be something different
On FreeBSD (and presumably other BSDs), all of the interface configuration happens with ifconfig still, if something new comes up, it's added to the tool that already exists.
There are some legitimate concerns around interfaces though -- some of the apis are either parse ifconfig's output, or copy its source code, I don't think (but could be wrong) that there's a nice machine readable way to get this information.
That is indeed correct in the case of OpenBSD. Halfway rolling my eyes at the article's assertion that it's better to write a new tool than actually bother to maintain the existing one when it's very possible for ifconfig to be a one-stop shop for, you know, interface configuration.
Typically (on bsd-derived systems) there a clearly defined kernel IOCTL interface for any given mechanism is created when it is implemented along with with specific c-structs which can be used to query and configure the interface; the core tools are then added to the system or modified to use this interface (rather than publishing text files from proc that an optional 3rd party package then uses ) - depending on the importance of the api people then tend to write language bindings (or a standalone library which in turn has language bindings) for this or somesuch.
However, they really screwed up with ss: the output is really unusable/unreadable.
This really only becomes obvious when you pass the -p flag, where the program information is printed on its own line.
It gets slightly better if you pipe the output through cat: now the program information is printed on the same line, but the column spacing is incorrect instead.
On the other hand it's nice that they kept compatibility, at least for the most common flags (e.g. -nltp does the same thing in both).
It isn't on its own line, it's just wrapped so grep works properly.
>but the column spacing is incorrect instead.
ss output is column-based so it is useless to bother with tools like cat for parsing.
ss -p | less -S is the simplest solution for you
First: Apparently the ss developer(s) decided to finally fix the output in some recent version (it was changed to behave sanely somewhere between iproute2-ss161212 and iproute2-ss180402).
However, if you're stuck with an older version, what I said still stands, and the below applies to those versions:
> It isn't on its own line, it's just wrapped so grep works properly.
While technically correct, that doesn't really matter in any practical sense, because the columns are padded so that the final column containing the program is wrapped onto the next line.
When ss stdout is connected to a pipe it will produce different output: this output is much less wide, so that the program name fits onto the same line as the rest of the columns. But, as said previously, it screws up the alignment of the columns, making it impossible to quickly scan them (using your eyes).
> ss output is column-based so it is useless to bother with tools like cat for parsing.
What? cat doesn't do any parsing. The only reason for using cat there is to connect ss' stdout to a pipe and thus trigger its different output.
> ss -p | less -S is the simplest solution for you
No. '| less -S' gives no improvement over '| cat', since ss output fits onto one line without wrapping as soon as you pipe it through any other program. An actual improvement would be to instead use '| column -t', which would (mostly) fix issues with misaligned columns.
Anyway, if you can, just use a modern enough ss instead (not sure when it was fixed, but iproute2-ss180402 (iproute2 4.16.0) is definitely new enough), which has sane output regardless of whether stdout is connected to a pipe or terminal.
When I was younger I had time for deep dives into configs/manuals/googles/mailthreads. These days my job assumes I know all the stuff and ins and outs, not having a good time re-learning everything I already know how to do...
It's not new anymore and gives no joy for learning new things, no time to do it either. It sucks.
Putting a shinier coat of paint on the command line isn’t going to attract a wider audience, it’s just going to piss off the only people who actually use the command line regularly. The CLI is the last place you want “change for the sake of change”.
At the end of the day, it's fine though. It'll either satisfy the needs of people and become a new standard or it will be satisfy edge cases and become the new thing that needs to be deprecated because no-one contributes to the project and the original maintainer has lost interest.
Unless you mention Perl to someone now, and that someone might be 10 years younger but still your manager, and they look at you like you just spoke greek.
that's what really gives us grumpy old sysadmins the kneejerk reactions. every time i log into a system and i have to tipo "ip a" i need to stop and try to slowly decode the unformatted soup letter that is presented instead of a nicelly formatted table like on ifconfig.
But those work (to my knowledge) just like before (unless you setup private networking or otherwise container the thing). They just work differently on the surface.
I wouldn't know of a way of exposing IP aliases in a non-traditional way as the kernel needs to know them either way.
Where as someone could probably write a newer drop in ifconfig that uses modern kernel APIs, several people have tried to for systemd and it's just so massive no fork can keep up anymore and almost all have been abandoned.
- Show logs for the current boot: $ journalctl -b
- To get all errors that are of priority level ERROR and worse: $ journalctl -b -p err
- Show me logs for a given binary: $ journalctl /usr/sbin/libvirtd
- Or via its unit file: $ journalctl -u libvirtd -l
- Want to query all the errors for a given disk? Here we go: $ journalctl /dev/sda -p err
And so on...
The worst is 'system-cat' to send a log message (SysVInit used 'logger'). Why not just 'log'?
If I want to tail the log of a service, though, there's a mnemonic for that: 'journalctl -fu httpd' - that one sure is easy to remember!
I'm not sure what the low level difference is between an alias like in the article, or a "eth0:1" type alias (made with ifconfig eth0:1 xx.xx.xx.xx up), but the "eth0:1" type alias seems infinitely more useful.
This is also a major deficiency of the Ubuntu 18.04 netplan implementation, it can only do the systemd.networkd type aliases and not the "eth0:1" type ones. What gives?
Now you can use VNET/VIMAGE to give jails separate virtual network interfaces. If you want to. The option to use aliases is still there of course.
In my case, keepalived VRRP floating addresses.
You can even add an address with `ip addr add' that will be visible to ifconfig.
(This is especially the case if you may at some point shift an IP alias between systems in order to move traffic from one to the other.)
I also appreciate very much the mostly consistent syntax for various sub commands. Its often an easy guess to know how to do what...
I find the 'ip --help' is virtually incomprehensible, and the man page no better. There's no explanation about what the tool can do, only some machine-readable formatting of the syntax expected. This kind of documentation is useless IMO, it's actively hostile to new users.
... and trying them (the features) out. In VMs and in other network simulators. ( http://mininet.org/overview/ comes to mind, but simply using Vagrant / Virtualbox is okay )
Also, networking is very standardized (duh :)), so if you follow network related stuff ( https://www.reddit.com/r/networking/ ), you can sort of get a feel for what might come to the Linux kernel.
LWN is still the best in this regard, because it deals with new developments, so reading the archives will tell you what might be in the kernel.
Furthermore, since nowadays everything is kube-cloud-virtual-container-open-netes-stack, looking at network developments for these technologies will get you in the know. (Seemingly bonkers stuff, like BGP for containers is now bog standard with things like Calico. Running a full switch in kernel with an awesome distributed overlay network for "cloud" without OpenFlow? OVN by OVS got your back. Doing all this fast? DPDK is uber fast, but XDP is just so conveniently clever.)
Plus there's the datacenter networking stuff, like TRILL/SPB ( https://networkingnerd.net/2016/05/11/the-death-of-trill/ ), but those haven't got integrated into the kernel, because the aforementioned Calico, OVN and other overlay stuff.
Oh, and the best way is to keep asking questions!
And there are good books and endless awesome posts/blogs about Linux. The new low level stuff is not covered as well obviously. (And I think it's a shame devs don't communicate well, but they are not perfect, nor they are paid for writing good docs, only for code.)
Furthermore, was the modularity of Unix ever really exercised? Are there success stories replacing dd, cp, ls, or parts of lower level stuff?
However i do not agree about the man pages the switches are explained there in enough detail in my opinion...
You have to read the manual too ;)
This is the official one: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git
I disagree, on two grounds.
Firstly, the ifconfig commands in the BSDs are existence proofs that this is not so. The BSD people actually have modified ifconfig to keep up with changing kernel networking abilities, and one will find the (say) FreeBSD ifconfig of today having a lot more functionality than the Linux one. The BSDs, by their very natures, kept their ifconfig tools aligned with the rest of the operating system as it changed.
Secondly, an aversion to breaking (badly designed) scripts is isn't really the reason that ifconfig hasn't been changed. The reason that ifconfig hasn't been changed, as evident from the net-tools bug and other discussions of this, one of which I have hyperlinked elsewhere in this discussion, is more to do with (purportedly) doing things portably and not having two disjoint code paths, one for Linux using netlink and one for everything else using ioctl. Two code paths and code that was not portable to other operating systems would be the result of adding netlink capability to net-tools's ifconfig.
That reason does not itself hold water, however. The net-tools package is highly Linux-specific anyway, in the first place, so arguments about its portability are moot. Given that, the actually expressed reason for not doing this given by the developers themselves (as opposed to the differing reasons inferred by people other than the developers, the most often given one of which is directly contradicted by git repository activity as recent as 2016) founders.
One of the more disappointing things about Linux's ifconfig is that this:
# ifconfig lo inet6 ::1
Don't know how to set addresses for family 10.
Having fought that monstrosity very recently, I completely agree. The homepage of its site looks more like a marketing blurb than anything else, and everything about it has an unpleasant "enterprisey" feel to it. I don't care about YAML or "abstract network renderers" or whatever buzzword-compliance bingo it claims to support, I just want to configure one NIC for one static IP.
The fact that Windows' networking configuration is actually easier than on "modern Linux" should be a sign that something has gone horribly wrong.
Old does not mean bad but Linux chooses that path as it moves further away from UNIX and being a Unix-like system in its pursuit to be Windows.
It doesn't automatically mean "good" either.
> "in its pursuit to be Windows"
Would you please elaborate?
Well, people are still free to maintain and improve those older tools and bring them up to par with newer standards, if they want to.
Others would argue it's time to start phasing out code and so-called "standards" we've had since the early 90s in spirit of refactoring various elements in the ecosystem. As with most such efforts - lots of code will be thrown away, some of it will be re-used and re-purposed. I'd argue that in the long run - it's probably a necessary intervention.
When choosing platforms, how communities weigh this balance is a very important consideration. You want to associate with people and groups who value essentially the "reasonable breeze" mode that keeps life flowing through extant systems. "Natural disasters" may sometimes be justified to help clear out the way-too-old (e.g. systemd or SMF), but they should be rare; systems can only tolerate major disruptions like that once or twice a decade.
Linux has an "anything goes" approach, which is usually more symptomatic of the age/maturity of the crowd it draws in than a reasoned decision about where to fall on this balance. That's not necessarily bad, but it makes more of an experimental atmosphere than something reliable, trusted, and stable.
So the notional idea of 'refactoring' being better -- yes! But with the constraint being that the people doing the refactoring have to be at least as wise, tasteful, mature, sensible, and thoughtful as the people who came before.
Systemd does a similar thing.
Now, traditional BSD inetd had discard, chargen, echo, ... protocol support, which means that it was actually more integrated that systemd.
EDIT: I guess I have to clarify this statement a little; In Windows the concept of "logging" is up to the event manager, this mirrors journalctl. To be more precise they seem to focus on desktop operating systems with an example being the unit file itself: "The syntax is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files.", maybe you prefer talking about firewalld and it's "Zones" which are clearly inspired by desktop use. (Laptops more specifically).
There was something that I'm forgetting though, a terminology that was only used by microsoft to describe something and systemd used exactly the same terminology. It was very esoteric terminology though, I'm trying to find a reference.
With Solaris now headed for retirement and most of the rest of the SysV ecosystem having collapsed over the preceding 20 years or so, it makes it easier for companies like Redhat to "innovate" in new directions with less pressure from developers and sysadmins alike.
I'm not sure how much of this is just my imagination, but the rate at which "old world" UNIX commands and subsystems are being replaced or supplanted in Linux certainly seems to have increased.
I agree with the author that some of these changes are forced by the development in the kernel itself, but I consider that part of the same phenomenon I guess.
the kernel should just map the faster api on those standard file descriptions instead... but then, the "old" files were not part of a standard to begin with... but then again, the standard, whatever it is, was never designed but agreed upon after being in use by enough people.
I have no idea what to make of this. I guess I am just happy that people are moving things forward, whatever the direction.
And sure enough, about halfway through:
>This interface has an IP alias, set up through systemd's networkd.
The amount of pain and headache this init-kitchen-sink-wannabe-thing has caused me day-to-day is incalculable.
I remember using iproute2 to add multiple IP addresses to devices at my very first job in 2007. systemd didn't even come out until 2010.