
Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018) - pjmlp
https://blog.farhan.codes/2018/06/25/linux-maintains-bugs-the-real-reason-ifconfig-on-linux-is-deprecated/
======
JdeBP
It's not quite that simple. People actually _tried_ to update net-tools
ifconfig (one of the two ifconfigs back in 2018).

In 2019, I simply wrote an ifconfig that uses the netlink API, because for
portability I needed a Linux ifconfig that had a FreeBSD-like command-line
syntax. It doesn't have the old interface aliasing mentioned in the headlined
article, and has no problems setting up and reporting IPv6 addresses or
additional IPv4 addresses.

* [https://unix.stackexchange.com./a/504084/5132](https://unix.stackexchange.com./a/504084/5132)

* [http://jdebp.uk./Softwares/nosh/guide/commands/ifconfig.xml](http://jdebp.uk./Softwares/nosh/guide/commands/ifconfig.xml)

I have a system to convert Debian /etc/network/interfaces into a BSD-style
rc.conf, which then in turn gets converted into a suite of native service
bundles. One of the service bundles is ifconfig@interface , which invokes
ifconfig with a uniform command-line syntax across Linux and FreeBSD, hence
the need for a more FreeBSD-alike ifconfig on Linux.

* [http://jdebp.uk./Softwares/nosh/guide/rcconf-amalgamation.ht...](http://jdebp.uk./Softwares/nosh/guide/rcconf-amalgamation.html)

* [http://jdebp.uk./Softwares/nosh/guide/rcconf.html](http://jdebp.uk./Softwares/nosh/guide/rcconf.html)

* [http://jdebp.uk./Softwares/nosh/guide/networking.html](http://jdebp.uk./Softwares/nosh/guide/networking.html)

~~~
Phemist
Off-topic: I can't help but be nosy and check the https version of your page.
You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might
want to get this looked at :)

Edit: Interesting,

[https://jdebp.uk](https://jdebp.uk) has the correct cert configured, whereas
[https://jdebp.uk](https://jdebp.uk). serves the cert as mentioned above.

~~~
tialaramex
So, firstly don't put a dot at the end. Whatever you might feel about it, the
decision in practice was that the host part of the URL is an FQDN but doesn't
need a dot at the end. So don't write one there. The browser should probably
trim it out when you type in or follow such a link.

The Apache web server that the bulk host is using for that site has a fairly
poor implementation of HTTPS. It's unsatisfactory in various ways, some very
technical, but what you're seeing here is the weird way it handles SNI.

By default when you say you want jdebp.uk. and there is no such virtual host
(there's only jdebp.uk with no trailing dot) Apache will pick a default
virtual host and act as though you asked for that, sending over the
certificate for that host and so on. In this case, at a bulk hosting site,
it's some unrelated Antiques Shop outfit, likely because that begins with 'A'
which is the first letter of the alphabet.

This actually caused a problem for Let's Encrypt because their tls-sni-01
challenge type assumed nobody would be crazy enough to answer queries for a
random name with a certificate chosen by somebody else entirely. But that's
exactly what Apache is doing here. The current tls-alpn-01 challenge was
introduced to fix that - it asks for a reserved ALPN service instead of a
spurious SNI server name.

~~~
bane
I wonder how much trouble this causes for censys.io as I believe they pull
certs based off of ip address requests.

~~~
tialaramex
Censys gets these defaults (you could probably measure a slight bias in their
data towards alphabetically earlier names as a result, but I have never
checked) for sites using Apache, and for other servers with a default they get
that default (in nginx I believe you have to explicitly configure a default if
you want one). If there is no default the site says you need to specify which
name you wanted or too bad.

You'll see the same for various other providers that crawl the IPv4 Internet
looking for services. My last job (it seems prescient now to have no job, very
convenient in current situation to have no reason to go outside anyway) had me
trying to fit some of this data to other service discovery information.

------
fargle
This is _highly_ biased opinion piece. I like BSD. I liked pre-Oracle Solaris.
And I like Linux at lot too.

And it is factually inaccurate. Deprecation of ifconfig is a distro issue.
"Linux" did not deprecate it. And the reason is that it was unmaintained, not
that it couldn't handle multiple IP addresses. In fact it can, I still use it
50% of the time. Works fine for setting and displaying multiple addresses.

The Debian maintainers wanted to drop it, and the other distros all followed
suit a couple years later. Good information and links here:

[https://serverfault.com/questions/633087/where-is-the-
statem...](https://serverfault.com/questions/633087/where-is-the-statement-of-
deprecation-of-ifconfig-on-linux)

"Linux maintains known bugs – and actively refuses to fix them. In fact, if
you attempt to fix them, Linus will curse at you, as manifest by this email."

That is a bold statement but is not at all supported by the linked email.
You'll see Linus cursing at a bad patch that would break something in
userland, not for "maintaining a bug". He's preventing at least two bugs
(unnecessary change to behavior and ENOENT is indeed the wrong return value).
I think I liked the old Linus better...

So it's a shame. I'd love to read a series about BSD, but this is really just
inaccurate propaganda.

~~~
tw04
That's a great theory, but Linus picks and chooses when to decide it's
outrageous to make changes that break userland tools based on his personal
preferences. They intentionally broke ZFS - then Linus follows up with a
wildly inaccurate statement about why he thinks nobody should use ZFS.

It's difficult to take him seriously when he picks and chooses when to enforce
his supposed "never break userland" ethos.

~~~
loeg
For a scary few days he was considering completely breaking the ABI of
getrandom(2). If he decides to break interfaces, I don't know that anyone can
stop him. It is a downside to the BDFL model.

Edit: Breaking ZFS is not a great example — as sibling comment points out,
that is a kernel module using kernel-internal APIs, not userspace syscall ABI.
The Linux kernel notoriously considers all kernel interfaces unstable. GregKH
has in the past characterized this as a feature, not a bug.

~~~
inshadows
I think that it is a upside of BDFL model, unless it's someone incompetent. If
you dig deep in the threads you'll find that so far his judgement on what to
break or not has always been stellar. As long as you have someone as competent
as Linus making the call, BDFL model is perfect.

RE getrandom(2): As Linus said several times, we don't break userspace rule
does not apply to security bugs. If there's no other way to fix security bug
other than breaking userspace, then userspace has to be broken, for obvious
reason. If you don't understand that reason, you shouldn't really have a say
in any such critical decision.

~~~
loeg
> unless it's someone incompetent.

Unfortunately, Linus is dangerously incompetent at cryptography. As was the
case with getrandom(2).

> RE getrandom(2): As Linus said several times, we don't break userspace rule
> does not apply to security bugs.

I don't think you understand or correctly recall the scenario in which Linus
nearly broke getrandom(2). The bug Linus was attempting to fix by breaking
getrandom(2) was _not_ a security bug. It was an availability bug, in
userspace, caused by broken userspace code deadlocking itself.

~~~
inshadows
> Unfortunately, Linus is dangerously incompetent at cryptography. As was the
> case with getrandom(2).

I beg to differ. Of all people I know of, Linus is one of the most competent
person when it comes to cryptography, more so than any of those Twitter
celebrities. I suggest you dig into LKML archives. Exactly what in the case of
getrandom(2) do you think makes him incompetent?

> I don't think you understand or correctly recall the scenario in which Linus
> nearly broke getrandom(2). The bug Linus was attempting to fix by breaking
> getrandom(2) was not a security bug. It was an availability bug, in
> userspace, caused by broken userspace code deadlocking itself.

I recall correctly. Optimizations in ext4 unveiled broken design of previous
getrandom(2). To keep backward compatibility an easy choice could have been to
supply early userspace with possibly predictable random numbers, which, of
course would be a security issue. Another would have been to keep the bug
hidden and revert any optimization that lowers early entropy pool. In the end,
the solution at which the community arrived is best compromise given the
constraints. The kernel is one of the few places where you can real software
engineering to take place.

I think your comment is driven more by personal hatred for a great mind rather
than technical merit.

~~~
loeg
> Of all people I know of, Linus is one of the most competent person when it
> comes to cryptography

This statement strikes me as bizarre because it's just so off-base. It seems
you relate to Linus as some kind of personal hero, which is fine, but then use
that as a reality-distortion field, which is probably unhelpful for you. (It's
just confusing to others.)

To the best of my knowledge, Linus has not done _any_ significant work in
cryptography, nor is he regarded by any practitioner as an expert in the
field. I would love to learn about any work he has done; I am just not aware
of any, and I have some experience in the field.

> Exactly what in the case of getrandom(2) do you think makes him incompetent?

getrandom(2) is the only good random number ABI in Linux. It is the only way
to request real random numbers that blocks until initial seeding and never
blocks afterwards (i.e., BSD /dev/random behavior). It has a flag that can be
used to avoid blocking.

Linus seriously proposed changing the ABI for getrandom() with flags
specifying "please block until real random numbers are available" to _silently
ignore those flags_ if the routine would block, and instead return garbage.
This would break _all existing software that used getrandom() correctly_ and
would be especially egregious for anything using getrandom(2) for
cryptographic keys — which is a good and correct use of the interface.

His proposal was fundamentally similar to, for example, changing the ABI of
/dev/random to silently return /dev/zero output instead of blocking.

> I recall correctly. Optimizations in ext4 unveiled broken design of previous
> getrandom(2).

Nope, you've still got it wrong.
[https://lwn.net/Articles/800509/](https://lwn.net/Articles/800509/)

1\. The design of the getrandom(2) API was and continues to be fine. It is
exactly what was missing on Linux, and has room for future expansion via
additional flag bits. It is not broken.

2\. The getrandom(2) ABI had been in the kernel for five years at the time
Linus proposed breaking it.

3\. The bug was in GNOME Display Manager, which ran early in boot on the
particular system that lead to the report, and GDM managed to deadlock itself
by incorrectly invoking getrandom(2) with a blocking request for entropy that
it did not need.

4\. (Broken user code can also deadlock itself by calling, say, sleep(99999).)

5\. Yes, an ext4 optimization lead to slightly reduced initial entropy on that
particular machine and the sighting of the underlying deadlock condition in
GDM. But that latent condition was always present.

> To keep backward compatibility an easy choice could have been to supply
> early userspace with possibly predictable random numbers, which, of course
> would be a security issue.

This (1) does not keep backwards compatibility, and (2) is exactly the
approach Linus initially proposed and had to be talked down from. This is the
proposal that was dangerously incompetent. From the thread at the time:

Andy Lutomirski:

    
    
      There are programs that call getrandom(0) *today* that expect secure
      output…  We can't break this use case.  Changing the semantics of
      getrandom(0) out from under them seems like the worst kind of ABI
      break -- existing applications will *appear* to continue working but
      will, in fact, become insecure.
    

Matthew Garrett (various emails):

    
    
      We've been recommending that people use the default getrandom() behaviour for key generation since
      it was merged. Github shows users, and it's likely there's cases in internal code as well. …
    
      The semantics many people want for secure key generation is urandom, but 
      with a guarantee that it's seeded. getrandom()'s default behaviour at 
      present provides that, and as a result it's used for a bunch of key 
      generation. Changing the default (even with kernel warnings) seems like 
      it risks people generating keys from an unseeded prng, and that seems 
      like a bad thing? …
    
      In one case we have "Systems don't boot, but you can downgrade your 
      kernel" and in the other case we have "Your cryptographic keys are weak 
      and you have no way of knowing unless you read dmesg", and I think 
      causing boot problems is the better outcome here.
    

The getrandom(2) saga was a long thread of Linus repeatedly ignoring the
knowledge and concerns of the his own security deputies.

> In the end, the solution at which the community arrived is best compromise
> given the constraints.

Yes, catastrophe was avoided and in the end a happy resolution was reached —
in spite of Linus, not because of him.

> I think your comment is driven more by personal hatred for a great mind
> rather than technical merit.

Nope.

------
tytso
There's an assumption which this article makes which is not true; namely, that
the only utilities which do (or should) use ioctl's are system programs like
ipconfig which are shipped with the kernel. There are other programs, like for
example Kerberos, who want to know what network addresses are used by the
network, and requiring them to screen scrape ipconfig is not especially
reasonable. So if you randomly change ioctls, then you randomly break other
programs that might not be shipped with the kernel that need to use those
ioctls. Maintaining proper backwards compatibility for userspace applications,
and not labelling some set of interfaces as "can randomly change, and if you
use them and you're aren't part of the privileged set of programs shipped with
the kernel, well, it just sucks to be you", is not, in my opinion a
professional way to run an OS.

~~~
loeg
It seems like for many userspace applications, the appropriate backwards
compatibility ABI would have been at the SO level. ELF shlibs make it easy to
version interfaces without breaking old dynamically linked programs. Linux is
sort of the odd duck in that it considers the entire syscall surface a stable
ABI. It leads to a lot of neat results, but can obviously also cause pain when
some older interfaces are not sufficient.

That said — new ioctls could be added and new ifconfig could use those? Old
ifconfig and user programs could continue using the old ABIs.

~~~
spacenick88
I would argue that the stable syscall interfaces is one of the main drivers
behind Linux success. Containers as we know them would be quite different if
they needed to somehow merge the kernel version appropriate .so files into the
fs. They would forever remain just sandboxes of the essentially the same
distro as the host just like they are on Solaris/FreeBSD.

Also something like WSL would be impossible

~~~
loeg
> I would argue that the stable syscall interfaces is one of the main drivers
> behind Linux success. Containers as we know them would be quite different if
> they needed to somehow merge the kernel version appropriate .so files into
> the fs. They would forever remain just sandboxes of the essentially the same
> distro as the host just like they are on Solaris/FreeBSD.

I suspect the order of cause and effect is reversed. Linux is amazingly
successful and as a result containers were shaped to fit the capabilities and
needs of Linux. The reason Linux has a strong syscall ABI is because it
doesn't have a userspace. Glibc is only loosely related to the kernel and
cannot be the kernel's ABI compatibility layer, as they are wholly independent
projects.

Another way of looking at this is that the overhead and additional abstraction
of containers is a workaround for the deficiencies of Linux jail/zone
facilities (i.e., it doesn't have them; you have to carefully piece together a
secure sandbox out of various cgroup and namespace components).

> Also something like WSL would be impossible

Some interesting things about that:

1\. WSLv1 was a partial Linux syscall emulator, sure.

2\. Microsoft gave up on that approach and WSLv2 is just an Ubuntu VM running
in HyperV. So maybe it was impossible anyway — Linux just provides a _ton_ of
system calls and it will always be difficult to faithfully implement all of
them. And as some side threads have noted, Linux likes to break ABI of sysfs
files all the time. But those don't count, for some reason.

3\. FreeBSD has a linux syscall emulation layer (that long predates WSL) using
essentially the same premise as WSLv1. You're correct that this style of
implementation (syscall ABI) only works due to Linux's syscall ABI choices.

4\. However, something _like_ WSL is _not_ impossible against a shlib ABI. The
canonical example here is WINE. WINE implements (much of) the Windows NT
shared library (DLL) level stable ABI. The same could be done for other
systems that provide ABI stability at the DLL level, such as MacOS or FreeBSD.

------
asveikau
There's no reason why someone can't get their act together and fix ifconfig,
or if that is insurmountable, rewrite it while maintaining the same outward
appearances.

I think this is not specific to Linux at all, and is not really about kernel
ABI. This is a problem I see a lot, often in proprietary software too.
Firstly, people opt to rewrite before they fix or even before they fully
understand the old thing. Secondly, people confuse interface with
implementation, and often don't bother trying to make their rewrites
interoperable with the old thing.

Another example of that last one, in Linux from the late 90s, is ALSA. FreeBSD
for example chose to fix the problems and maintain the old OSS API for audio
devices. Linux introduced a very complicated new API.

[By the way, I spotted one sort of technical error in the article. I don't
think most software keeps private copies of kernel data structures in their
source tree. Rather, when they #include the kernel headers, they end up using
an effectively-private version of those structures and constants in their
object code. This is slightly different but a similar result.]

~~~
zokier
> There's no reason why someone can't get their act together and fix ifconfig,
> or if that is insurmountable, rewrite it while maintaining the same outward
> appearances.

But it's telling that nobody stepped up and actually bothered to do that
despite all the bitching and moaning.

Successful code is generally produced to solve problems, not fullfil some
abstract ideals

~~~
comex
Except someone _did_ rewrite it:

[https://news.ycombinator.com/item?id=22628938](https://news.ycombinator.com/item?id=22628938)

But with the Linux ecosystem's inertia being what it is, rather than the 2
existing implementations of ifconfig in use being displaced by this better
one... now there are just 3 implementations of ifconfig in use.

As mentioned in the Stack Exchange thread linked in that post, a different
someone submitted a relevant patch to one of those existing implementations –
way back in 2013. But it was never accepted. More inertia.

~~~
kelnos
To be fair, the third 'ifconfig' implementation is not compatible with the
original in command-line options or in output, so adopting it would require
changes just as adopting 'ip' does.

~~~
JdeBP
_Two_ priors ("original" not really being the right word), each already not
compatible with the other.

* [http://jdebp.uk./Softwares/nosh/guide/commands/ifconfig.xml#...](http://jdebp.uk./Softwares/nosh/guide/commands/ifconfig.xml#COMPATIBILITY)

------
djsumdog
I really do not like the default UI in ip. You have to remember a lot of weird
stuff to get useful information. The default listing is compressed, hard to
read, and noisy. Then I saw someone who had these aliases:

    
    
        alias ipa 'ip -br -color a'
        alias ipl 'ip -br -color link'
    

Night and day! I try to not use the aliases because I'm often on servers
without them, but the options for brief and color with the command to list
adapters or links at the end it one all sys admins should memorize. It returns
output that isn't terrible.

~~~
peterwaller
Nice hint, thanks :)

According to the manpage, -color can be shortened to -c and link shortened to
`l`, as `addr` can be shortened to `a`. -br stands for -brief, which knowing
makes it easier to remember.

    
    
      ip -br -c a
      ip -br -c l
    

Now I need the aliases less.

------
AnthonyMouse
> The only to prevent this would be to conduct regular massively coordinated
> updates to system utilities when the kernel changes, and properly version
> applications for specific kernel releases.

Well, no. What you do is create a new struct with correct behavior and let new
applications use that. The old struct becomes deprecated but continues to
exist until things stop using it. Which may be indefinitely, but that's not
really a lot more work than maintaining a compatibility library to serve the
same purpose.

The thing with ip vs. ifconfig was more to do with there being somebody
interested in creating ip and nobody interested in maintaining ifconfig. If
you want to go add support for multiple addresses on the same interface to
ifconfig, nobody is stopping you -- in fact that has already happened now.

~~~
Gibbon1
I've been actively working on firmware that is now over ten years old. My
advice tends to be if you have an api that takes a pointer to a structure you
should have a version field from the get go.

------
Aissen
Indeed, ip is vastly superior. But it took me almost a year of working with
internet gateways (i.e as a day job) to let old habits die. Learning the new
output format takes time.

I've almost replaced route with "ip route" as well. arp isn't fully replaced
yet in muscle memory.

Also, as a comment on the article, ip can now fully replace brctl. (and iw
replaces iwconfig and iwlist).

~~~
jandrese
IP may be better from an ABI standpoint, but I still find its output to be
much harder to parse with the Mk 1 Eyeball than ifconfig. Most of that is
probably just ip shoving more information on the screen than ifconfig, but
most of the information isn't useful 99% of the time and maybe it would be
nicer if ip pared down some of the "qdisc noqueue state UNKNOWN group default"
noise unless someone adds a "verbose" parameter?

Or maybe only show them in the basic use case when they are set to something
other than the default?

All of the "valid_lft" lines add a lot of visual noise.

~~~
tene
While I agree that different defaults might be nice, modern versions of ip
support a -br[ief] option which is pretty nice:

    
    
      $ ip -br a
      lo               UNKNOWN        127.0.0.1/8 ::1/128
      eth0             UP             10.123.45.67/24 fe80::7ed3:aff:fe51:4612/64
      $ ip -br l
      lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
      eth0             UP             7c:d3:0a:51:46:12 <BROADCAST,MULTICAST,UP,LOWER_UP>

~~~
jandrese
'ip -br a' get real messy if you have IP6 unfortunately. IPv6 hosts like to
make lots and lots of addresses, which all get smooshed together on a single
line of hard-on-the-eyeballs hex noise.

~~~
gerdesj
Well yes but come on daddyo (I'm a granddad btw), who still routinely uses an
80 column terminal these days 8) Besides, you can always feed the output to
awk for an easier on the eyes report. I have three IPv6 including the link
local address on my wlp2s0 and they all fit on one line with the IPv4.

I've just run up the manual and the kool kids could be using 'ip --json
--pretty address' or 'ip -j a | jq'

------
kentonv
The fact that the Linux ABI is stable is the whole reason why containers are
possible.

If it were necessary to use the matching version of userland tools to your
kernel version, then a container engine would only be able to run container
images that match the kernel version -- you wouldn't be able to run containers
based on two different versions of Debian, for example.

------
corndoge
I don't buy it. Yes, Linux never breaks userland. Yes, ifconfig is deprecated.
But I still don't see how these are related.

~~~
wuunderbar
I still don't understand how this "Linux never breaks userland" thing holds
up, it's been proven false.

The 4.13 kernel introduced a change to effectively namespace sysctl settings
(prevent the change from default from being copied to the host system into
container processes). This broke any container runtimes that relied on host-
wide sysctl settings.

[1] [https://github.com/aws/amazon-ecs-
agent/issues/789](https://github.com/aws/amazon-ecs-agent/issues/789)

[2] [https://success.docker.com/article/ipvs-connection-
timeout-i...](https://success.docker.com/article/ipvs-connection-timeout-
issue)

~~~
simias
I think the real guarantee is more like "linux doesn't break the syscall API"
(the API, not the ABI). I think sysctl is not really part of it.

~~~
loeg
How do you think sysctls are implemented?

In fact, prior to Linux 5.5, Linux had a direct sysctl syscall and removed it
— which, uh, is clearly an ABI break.

With Linux's sysctl pseudo-fs model, you can argue the actual structure and
behavior is just some aspect of sysfs, and the open/read/write syscalls are
obviously not broken, but I think that's pretty simplistic. sysctls (and
sysfs) are provided by the kernel.

Linux doesn't break ABIs that Linus judges to be worth more stable than
rototilled. That's all. Usually Linus swings conservative on this.

------
nailer
Here's an example from a decade ago (ifconfig was deprecated then too):

\- bonded interfaces

\- with vlans

\- with multiple IPs

If this sounds unrealistic, it was the standard config for index arbitrage at
an investment bank.

The interfaces, added with distro scripts, will use `ip` and all the
interfaces will show up in `ip addr` and work perfectly. ifconfig won't show
about half of them - they won't be up, or down, they just won't appear.

~~~
hpcjoe
I set up systems in 2009+ that had multiple IPs per phy, bonded, vlan, etc. on
linux. I used the config files within the distro (mostly CentOS/RH then) to do
this. Worked fine. I developed somewhat better inspection scripting to augment
this. My users never had problems with this.

I think the distro tooling used ip under the covers. I didn't care one way or
the other. Nor did the users.

~~~
nailer
Yes, that's correct, all distros use ip and have for about 15 years.

------
roca
Linux's stable kernel ABI makes tools like rr and strace much easier to
maintain. It sounds like maintaining rr for FreeBSD would be harder since
you'd have to keep updating its syscall model for changes to existing syscalls
as well as new syscalls. And that's if we only supported the latest FreeBSD in
each rr version; supporting multiple versions of FreeBSD would require a lot
more code.

------
kazinator
> _On FreeBSD this is not a problem. They update the kernel and userland tools
> in tandem._

Yes it is a problem, to some programs doing, say, nice FFI to get at that
ioctl and structure cleanly instead of forking and piping some utilities and
text-processing their output.

The concept of an ABI, and one that is stable, is very real and important.

------
matharmin
Interesting backstory, but the article doesn't actually provide a reason. It
just states ifconfig has a bug, and "I do not fully understand they did not
just update ifconfig(8)".

------
squarefoot
Huh?!?

I use multiple addresses a lot, and recall having used them through ifconfig
for years, probably well over a decade. Anyway, at least on Debian, the
package net-tools brings ifconfig it back, again with full multiple addresses
support.

    
    
      # uname -v
      #1 SMP Debian 5.4.19-1 (2020-02-13)
    
    
      # ifconfig
      enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 192.168.10.42  netmask 255.255.255.0  broadcast 192.168.10.255
            inet6 fe80::2e4d:54ff:fed8:7b59  prefixlen 64  scopeid 0x20<link>
            ether 2c:4d:54:d8:7b:59  txqueuelen 1000  (Ethernet)
            RX packets 1162942  bytes 1627138668 (1.5 GiB)
            RX errors 0  dropped 42049  overruns 0  frame 0
            TX packets 546159  bytes 41181499 (39.2 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
      lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 16  bytes 818 (818.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 16  bytes 818 (818.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    
      # ifconfig enp2s0:1 192.168.1.42
    
      # ifconfig
      enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 192.168.10.42  netmask 255.255.255.0  broadcast 192.168.10.255
            inet6 fe80::2e4d:54ff:fed8:7b59  prefixlen 64  scopeid 0x20<link>
            ether 2c:4d:54:d8:7b:59  txqueuelen 1000  (Ethernet)
            RX packets 1163011  bytes 1627147417 (1.5 GiB)
            RX errors 0  dropped 42089  overruns 0  frame 0
            TX packets 546185  bytes 41184061 (39.2 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
      enp2s0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 192.168.1.42  netmask 255.255.255.0  broadcast 192.168.1.255
            ether 2c:4d:54:d8:7b:59  txqueuelen 1000  (Ethernet)
    
      lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 16  bytes 818 (818.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 16  bytes 818 (818.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

~~~
gnosek

        ifconfig enp2s0:1 192.168.1.42
    

Now try

    
    
        ip addr add dev enp2s0 192.168.42.1/24
    

and observe how ifconfig ignores the second IP on the same interface. enp2s0:1
is an alias to enp2s0, not enp2s0 itself. To replicate your ifconfig command,
you'd use

    
    
        ip addr add dev enp2s0 192.168.1.42/32 label enp2s0:1
    

and then it shows up in ifconfig as well.

~~~
squarefoot
Understood, thanks, I'm so used to ifconfig that always tried to avoid using
ip. Time to learn it I guess.

~~~
gerdesj
I spend a lot of times dealing with new devices. Plug it into the same VLAN as
my desktop and then in a term:

# ip a a 192.168.1.32/24 dev eth0

Then put 192.168.1.1 into browser etc. Do job. Back to term. Up arrow to get
last command, change the second a to d (for delete) and the extra address is
gone.

------
quotemstr
The Linux approach to system call stability is awful. I've written about it
extensively before. See this thread [1]. The gist of it is that a system
doesn't need to place the ABI support boundary at exactly the same page as the
ring3-to-ring0 boundary, and that Linux does is 1) basically shipping the org
chart, and 2) harmful in all sorts of ways.

The right way to do OS ABI stability is to require that system calls go
through some user-space library before executing a privilege transition. This
way, the kernel's interface can change as needed without breaking existing
userland binaries. Windows gets this right: system calls go through ntdll.dll.
Fuchsia gets this right as well: they don't have an ntdll.dll, but they have a
_huge_ vdso that amounts to the same thing.

If I had my way, Linux would take the Fuchsia approach: require every system
call go through a vdso.

"But golang!" and "but I have multiple libcs!" and "but my static linking!"
are not valid excuses. Windows also has Go and it also have multiple libcs and
the NT kernel isn't forced to maintain decades of userland-facing crud.

As for static linking: you can statically link the world if you'd like, but
you can do that and still call through a vdso or load the platform libc.

[1]
[https://news.ycombinator.com/item?id=20854857](https://news.ycombinator.com/item?id=20854857)

~~~
wtallis
How exactly does a ntdll/vdso approach make it easier to preserve binary
compatibility? It obviously _moves_ the place at which binary compatibility
needs to be preserved, but I'm not seeing how that move makes maintenance
easier, unless you're implying that the userspace portion would not be the
responsibility of the kernel developers.

~~~
quotemstr
User space has a lot more flexibility than the kernel when it comes to
implementing ABIs. For example, Linux has to maintain a relatively large table
of system calls for legacy reasons. (Consider socketcall(2)). Legacy "system
calls" provided by a VDSO or ntdll.dll-like mechanism are just tiny regular
functions with no special security or performance implications.

~~~
wtallis
>Legacy "system calls" provided by a VDSO or ntdll.dll-like mechanism are just
tiny regular functions with no special security or performance implications.

Are you saying that wrapper code implementing an old interface by wrapping
around a new interface is easier to do correctly in userspace than in the
kernel itself?

I think I need you to be more concrete in pointing to a specific performance
penalty or avoidable maintenance burden.

~~~
quotemstr
> Are you saying that wrapper code implementing an old interface by wrapping
> around a new interface is easier to do correctly in userspace than in the
> kernel itself?

Yes.

> I think I need you to be more concrete in pointing to a specific performance
> penalty or avoidable maintenance burden.

I already did: socketcall. And NT does all 32-bit compatibility in userspace.

~~~
wtallis
> I already did: socketcall

Got anything that applies to modern platforms or recent kernel versions?

Also, does socketcall actually have higher overhead than doing a similar
dispatch in userspace, or does it just mean you get a cache miss slightly
later in the process?

(You could try elucidating an actual argument rather than just naming a
syscall and assuming that the rest of your argument is obvious.)

> And NT does all 32-bit compatibility in userspace.

So? Is it faster to do that in userspace than in the kernel?

~~~
saagarjha
Doing things in userspace prevents a context switch, presumably.

~~~
wtallis
Not when it's just prep work before doing an unavoidable syscall.

------
jabl
Another place where ifconfig doesn't work properly is that it assumes network
interfaces have 48 bit hardware addresses. Works fine on ethernet but not on
infiniband.

------
phoe-krk
So, if a kernel bug happens in some interface, the only way of not being
affected by that bug is actually deciding to not use that interface. Bugs
become features, and "do not ever break userspace" causes cruft to accumulate.

------
uluyol
Somewhere, the OS had to provide a stable interface. Why does it matter if
it's in userspace vs the kernel? If you have to break the interface, it seems
like applications have to be adjusted and/or recompiled, no?

~~~
wmf
It matters if userspace and the kernel are developed by separate teams, as is
the case with Linux. If you break the kernel interface but have a library with
a stable interface then you can't support static linking (which fell out of
favor for a decade but is now back in style).

~~~
kelnos
Right, and the article seems to have some sort of axe to grind with Linux, so
the author paints "developed by separate teams" as somehow an inferior choice
deserving of scorn.

I generally found the article to be light on technical accuracy and heavy on
pointless "my OS is better than yours" prattle.

------
mpolun
I don't think this is accurate. Other people may know better, but from my
understanding the maintainers of ifconfig realized that to update it to use
the new behavior, they would have to end up changing the output. The output of
ifconfig is used by a lot of scripts, so changing the output would break a
million users, so they decided to write a new tool, rather than add a flag or
something to opt into new behavior.

So it's userspace compatibility, not the linux kernel compatibility that lead
to a new tool.

(and linux will drop old interfaces if it can be proven that no one uses them,
or if they're insecure)

------
justlexi93
The indirection allows for versioned APIs and compatibility shims, along with
lengthening the migration window while not tying the kernel down and keeping
it from fixing misdesigns or changing circumstances.

------
carapace
> We should look at the whole project [Linux] as a cautionary tale of the kind
> of leveraged destruction that some programmers of modest ability but extreme
> confidence can wreak on our industry.

[https://news.ycombinator.com/item?id=21168895](https://news.ycombinator.com/item?id=21168895)

~~~
mixmastamyk
(Generalized cliche) There are two kinds of systems, ones that everyone
complains about, and ones that no one uses.

I'm also reminded of the "expert beginner" series of blog posts about
jealously guarded fiefdoms and the folks that dominate them.

