5 ms·

So, to summarize, ifconfig has to be replaced because it relies on the /proc filesystem and it doesn't handle aliases? This is easily disproven: ifconfig on Fr

by ptx 8y ago

So, to summarize, ifconfig has to be replaced because it relies on the /proc filesystem and it doesn't handle aliases? 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.

viraptor 8y ago
Isn't ifconfig on BSD just an app that happens to share the name and some syntax with the Linux ifconfig? You could map most ifconfig operations to netlink and away from /proc, but that would have other tradeoffs.
- bluGill 8y ago
  It is the opposite - ifconfig on linux is an app that happens to share the name and syntax with the BSD utility. BSD sockets came first in 1983. linux re-implemented the interface from about 10 years latter (I'm not sure exactly when, I'd guess 1992 but that is a guess).
- toast0 8y ago
  I would say the difference is that Linux ifconfig was written once, and never modified. Get a new interface config, write a new tool (see mii-tool, iwconfig, etc) 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.
  - yellowapple 8y ago
    "and presumably other BSDs" 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.
    - digi_owl 8y ago
      rolling new rather than maintaining is epidemics within the Linux world. One that most users are insulated from thanks to the hard work of distros for the most part.
  - cat199 8y ago
    > I don't think (but could be wrong) that there's a nice machine readable way to get this information. 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. see also: https://www.freebsd.org/cgi/man.cgi?query=netintro&sektion=4&apropos=0&manpath=FreeBSD+11.1-RELEASE+and+Ports https://www.freebsd.org/cgi/man.cgi?query=netintro&sektion=4... etc.
deleted 8y ago
[deleted]
qznc 8y ago
The summary is: ifconfig output format does not support new networking features like IP aliases[0]. Changing the output format would break many scripts, so ifconfig will not be changed. [0] It does support "interface aliases" and that seems to be something different
- yellowapple 8y ago
  Removing ifconfig (the implied end-goal of deprecating it) would also break many scripts.
da_chicken 8y ago
BSD's ifconfig isn't really related to Linux's ifconfig anymore because BSD has continued development and the Linux fork or version (don't remember which it is anymore) hasn't. Linux's ifconfig is a part of net-tools (http://net-tools.sourceforge.net/ 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.
- ori_b 8y ago
  > BSD's ifconfig isn't really related to Linux's ifconfig anymore because BSD has continued development and the Linux fork or version (don't remember which it is anymore) hasn't. There's a simple solution to the lack of maintenance on ifconfig: Maintain ifconfig. There's no need to break shit.
  - da_chicken 8y ago
    It's open source. Feel free. I'd expect there are significant architectural differences between Linux and BSD by this point, though, that would make it quite a challenge. Alternately, it might be like adding major new features to Xorg: possible but extremely challenging. 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. https://lwn.net/Articles/710533/ https://lwn.net/Articles/710533/
    - 8y ago

by ptx 8y ago

viraptor 8y ago

Isn't ifconfig on BSD just an app that happens to share the name and some syntax with the Linux ifconfig? You could map most ifconfig operations to netlink and away from /proc, but that would have other tradeoffs.

bluGill 8y ago
It is the opposite - ifconfig on linux is an app that happens to share the name and syntax with the BSD utility. BSD sockets came first in 1983. linux re-implemented the interface from about 10 years latter (I'm not sure exactly when, I'd guess 1992 but that is a guess).
toast0 8y ago
I would say the difference is that Linux ifconfig was written once, and never modified. Get a new interface config, write a new tool (see mii-tool, iwconfig, etc) 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.
- yellowapple 8y ago
  "and presumably other BSDs" 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.
  - digi_owl 8y ago
    rolling new rather than maintaining is epidemics within the Linux world. One that most users are insulated from thanks to the hard work of distros for the most part.
- cat199 8y ago
  > I don't think (but could be wrong) that there's a nice machine readable way to get this information. 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. see also: https://www.freebsd.org/cgi/man.cgi?query=netintro&sektion=4&apropos=0&manpath=FreeBSD+11.1-RELEASE+and+Ports https://www.freebsd.org/cgi/man.cgi?query=netintro&sektion=4... etc.

deleted 8y ago

[deleted]

qznc 8y ago

The summary is: ifconfig output format does not support new networking features like IP aliases[0]. Changing the output format would break many scripts, so ifconfig will not be changed. [0] It does support "interface aliases" and that seems to be something different

yellowapple 8y ago
Removing ifconfig (the implied end-goal of deprecating it) would also break many scripts.

da_chicken 8y ago

BSD's ifconfig isn't really related to Linux's ifconfig anymore because BSD has continued development and the Linux fork or version (don't remember which it is anymore) hasn't. Linux's ifconfig is a part of net-tools (http://net-tools.sourceforge.net/ 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.

ori_b 8y ago
> BSD's ifconfig isn't really related to Linux's ifconfig anymore because BSD has continued development and the Linux fork or version (don't remember which it is anymore) hasn't. There's a simple solution to the lack of maintenance on ifconfig: Maintain ifconfig. There's no need to break shit.
- da_chicken 8y ago
  It's open source. Feel free. I'd expect there are significant architectural differences between Linux and BSD by this point, though, that would make it quite a challenge. Alternately, it might be like adding major new features to Xorg: possible but extremely challenging. 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. https://lwn.net/Articles/710533/ https://lwn.net/Articles/710533/
  - 8y ago