Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

blog.farhan.codes

Post reply on HN
Print view View original

61–70 of 141 posts

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#61

Post by teddyh »

loeg wrote: post #40
tw04 wrote: post #25

Earlier quoted context omitted.

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.

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.…

> The Linux kernel notoriously considers all kernel interfaces unstable.

“You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree.”

— Greg Kroah-Hartman

https://www.kernel.org/doc/html/latest/process/stable-api-no...

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#62

Post by akira2501 »

asveikau wrote: post #7

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. Secondl…

> or even before they fully understand the old thing.

I feel that /sbin/ip is in almost every way a better tool than /sbin/ifconfig, is that not the concensus?

> Linux introduced a very complicated new API.

Which highlights the fact that the moment you want to have in-depth interactions with a driver for a piece of hardware ioctls are the wrong choice.

OSS was great if you had exceptionally simple needs.. the moment you want to do "professional" audio it was a nightmare. ALSA is _somewhat_ better for this, and I honestly wish they went with a more netlink(3) style API instead of an IOCTL driven one.

What's the point of pantomiming the old thing when the old thing wasn't designed properly in the first place?

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#63

Post by halyconWays »

JdeBP wrote: post #10

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…

If you'd read the article you'd see that it talks about how people tried to update ifconfig.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#64

Post by 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.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#65

Post by zymhan »

akira2501 wrote: post #62
asveikau wrote: post #7

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. Secondl…

> or even before they fully understand the old thing. I feel that /sbin/ip is in almost every way a better tool than /sbin/ifconfig, is that not the concensus? > Linux introduced a very complicated new API. Which highlights the fact that the moment you want to have in-depth interactions with a driver for a piece of hardware ioctls are the wrong choice. OSS was great if you had exceptionally simple needs.. the moment…

My opinion is that `ip` is a more powerful tool, but it is not as useful for quickly obtaining information or performing a basic action like up/down.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#66

Post by quotemstr »

wtallis wrote: post #59
quotemstr wrote: post #56

Earlier quoted context omitted.

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.

>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 ma…

> 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.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#67

Post by wtallis »

quotemstr wrote: post #66
wtallis wrote: post #59

Earlier quoted context omitted.

>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 ma…

> 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.

> 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?

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#68

Post by peterwaller »

djsumdog wrote: post #64

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…

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.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#69

Post by kccqzy »

dependenttypes wrote: post #33
JdeBP wrote: post #10

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…

Why are you using the dot for your site but not for stackexchange?

This might be the first time in quite a few years that I've seen people using a dot like that. Any reasons to do so? I figured most people do not have weird DNS search domains or some such to warrant that dot.

Re: Linux maintains bugs: The real reason ifconfig on Linux is deprecated (2018)

#70

Post by tssva »

zymhan wrote: post #65
akira2501 wrote: post #62

Earlier quoted context omitted.

> or even before they fully understand the old thing. I feel that /sbin/ip is in almost every way a better tool than /sbin/ifconfig, is that not the concensus? > Linux introduced a very complicated new API. Which highlights the fact that the moment you want to have in-depth interactions with a driver for a piece of hardware ioctls are the wrong choice. OSS was great if you had exceptionally simple needs.. the moment…

My opinion is that `ip` is a more powerful tool, but it is not as useful for quickly obtaining information or performing a basic action like up/down.

My opinion is that while a little more verbose it is just as useful for obtaining information or performing basic actions. Especially since it allows you to use the same cli and actions to maintain most network related actions rather than multiple tools with varying commands.
Post reply on HN