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

51–60 of 141 posts

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

#51

Post by gnulinux »

tw04 wrote: post #25
fargle wrote: post #23

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

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.

Did you read his mail though? He literally answers this criticism. ZFS is not userland so kernel developers are free to break it, just like they can break ext4 and do, and then they fix them. The problem with ZFS is that they can't fix it because it's not part of linux. It's a 3rd party kernel module. So your entire comment reads like a misunderstanding of the situation.

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

#52

Post by blaser-waffle »

JdeBP wrote: post #19
dooglius wrote: post #18

Earlier quoted context omitted.

> People actually tried to update net-tools ifconfig (one of the two ifconfigs back in 2018). What happened?

See the StackExchange answer.

It's a comprehensive reply -- good stuff, and worth a read.

The short version: > "As you can see, the GNU inetutils and NET-3 net-tools ifconfigs have some marked deficiencies, with respect to IPv6, with respect to interfaces that have multiple addresses, and with respect to functionality like -l.

> The IPv6 problem is in part some missing code in the tools themselves. But in the main it is caused by the fact that Linux does not (as other operating systems do) provide IPv6 functionality through the ioctl() interface. It only lets programs see and manipulate IPv4 addresses through the networking ioctl()s.

> Linux instead provides this functionality through a different interface, send() and recv() on a special, and somewhat odd, address family of sockets, AF_NETLINK.

> The GNU and NET-3 ifconfigs could have been adjusted to use this new API. The argument against doing so was that it was not portable to other operating systems, but these programs were in practice already not portable anyway so that was not much of an argument.

> But they weren't adjusted, and remain as aforeshown to this day."

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

#53

Post by sneak »

jandrese wrote: post #50
Aissen wrote: post #13

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

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" para…

If you try, you’ll hit the “can’t change it now, too many people rely on the output in scripts!” noise.

Really, just some whitespace in between the interfaces like in ifconfig would go a long way.

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

#54

Post by michaelmrose »

sheepdestroyer wrote: post #32
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.

ZFS is not user land. It's kernel code but without being in the kernel. So it has to be built separately and may not even be compliant with GPL (still has to be tested in court AFAIK). Linux's promise to not break userspace is just that, It can not be held responsible for code that should be in the kernel but does not play fair with the license.

It's not that it doesn't play fair. Sun published under a license that made inclusion in the kernel impossible thus the current developers are bound by the same decisions regardless of their opinion on the matter.

Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking.

It is entirely acceptable that they aren't responsible for out of tree code working but it would be great if they didn't deliberately sabotage other projects which is what they did here.

>My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?

The extra work is 10 seconds of work. How childish and unprofessional.

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

#55

Post by anon102010 »

jandrese wrote: post #50
Aissen wrote: post #13

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

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" para…

This - you think - new tool will be better and then are blinded :) If they would just move the noise down one line so you could see interface name without BROADCAST, MULTICAST, mtu 1500 qdisc up blah blah.

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

#56

Post by quotemstr »

wtallis wrote: post #47
quotemstr wrote: post #43

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

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.

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.

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

#57

Post by wtallis »

michaelmrose wrote: post #54
sheepdestroyer wrote: post #32

Earlier quoted context omitted.

ZFS is not user land. It's kernel code but without being in the kernel. So it has to be built separately and may not even be compliant with GPL (still has to be tested in court AFAIK). Linux's promise to not break userspace is just that, It can not be held responsible for code that should be in the kernel but does not play fair with the license.

It's not that it doesn't play fair. Sun published under a license that made inclusion in the kernel impossible thus the current developers are bound by the same decisions regardless of their opinion on the matter. Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux be…

> Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking.

It's not magical thinking. A work can be a derivative of multiple other works. It's completely plausible that adding Linux stuff to ZFS can make it a derivative work of Linux in addition to being a derivative work of whatever else it is already a derivative work of. There's room for debate about how much Linux stuff (and of what nature) something like ZFS can incorporate before it becomes a derivative work according to copyright law and the GPLv2, but you cannot dismiss the idea outright.

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

#59

Post by wtallis »

quotemstr wrote: post #56
wtallis wrote: post #47

Earlier quoted context omitted.

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.

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

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

#60

Post by wmf »

uluyol wrote: post #58

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?

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).
Post reply on HN