4 ms·

Ifconfig is not part of the shell. Whatever your grudges with ifconfig are, however justified, they have nothing to do with how the shell works. BTW, I don't

Ifconfig is not part of the shell. Whatever your grudges with ifconfig are, however justified, they have nothing to do with how the shell works. BTW, I don't know of any distro wit LTS releases that didn't yet expire that doesn't ship with iproute2. In my opinion, iproute2 has done a very good job, given the circumstances to organize and systematize information about networking. So, if you don't like ifconfig, today you most likely have a better alternative.

nailer 4y ago
Your comment seems to have f the point. I know ifconfig isn’t part of bash and I’m aware of ip addr but the point stands: people don’t update tools because it breaks scraping. If fact if they did ip addr wouldn’t exist: we’d be able to update ifconfig.
- crabbone 4y ago
  > people don’t update tools because it breaks scraping. What people are you talking about? Anyone who's on a payroll is liable if they don't upgrade systems when they go out of support. It doesn't happen because of someone's whims... If some individual user chooses to stick with an outdated system: it's on them, and they have no ground to stand on if they complain about it... > we’d be able to update ifconfig. No we wouldn't. "ip a" is a tiny fraction of what this command does. The reason it came to be was not that ifconfig needed replacement, but because Linux utilities are a zoo of halfbaked projects, most of which have huge flaws in their design, especially when it comes to extensibility. Did ifconfig foresee bridge interfaces, bond interfaces, vLANs etc? What about IB? What about sr-iov etc.? -- Nope, and since there wasn't a single structured and systematic tool, that could've been extended by the authors of eg. bridge drivers, they were forced to come up with their own tools, eg. brctl. iproute2 wasn't an improvement on top of ifconfig. It was an aggregation and systematization of various tools and configurations that dealt in a very partial way with various aspects of networking. There would've been no way to keep any kind of backwards compatibility with ifconfig, so there was no reason to keep the name. It's not an evolution of ifconfig, it's an entirely different thing.
  - nailer 4y ago
    > What people are you talking about? People that maintain software. > Anyone who's on a payroll is liable if they don't upgrade systems when they go out of support. Yes. Let's make that process easier. > Did ifconfig foresee bridge interfaces, bond interfaces, vLANs etc? No, that's precisely why I wrote the comment you're replying to. Yet people still use ifconfig, and wonder why the results don't make sense with their vlanned bonded interface. > It's not an evolution of ifconfig, it's an entirely different thing. Yes, agreed completely. But if we got away from scraping we could have added them a lot more gently. > There would've been no way to keep any kind of backwards compatibility with ifconfig Disagree. We can come up with a design here but I don't feel like you're actually responding to anything I write so I don't wish to do so. > there was no reason to keep the name To this day people are still scraping ifconfig and wondering why the results are bad.
  - deleted 4y ago
    [deleted]

nailer 4y ago

Your comment seems to have f the point. I know ifconfig isn’t part of bash and I’m aware of ip addr but the point stands: people don’t update tools because it breaks scraping. If fact if they did ip addr wouldn’t exist: we’d be able to update ifconfig.

crabbone 4y ago
> people don’t update tools because it breaks scraping. What people are you talking about? Anyone who's on a payroll is liable if they don't upgrade systems when they go out of support. It doesn't happen because of someone's whims... If some individual user chooses to stick with an outdated system: it's on them, and they have no ground to stand on if they complain about it... > we’d be able to update ifconfig. No we wouldn't. "ip a" is a tiny fraction of what this command does. The reason it came to be was not that ifconfig needed replacement, but because Linux utilities are a zoo of halfbaked projects, most of which have huge flaws in their design, especially when it comes to extensibility. Did ifconfig foresee bridge interfaces, bond interfaces, vLANs etc? What about IB? What about sr-iov etc.? -- Nope, and since there wasn't a single structured and systematic tool, that could've been extended by the authors of eg. bridge drivers, they were forced to come up with their own tools, eg. brctl. iproute2 wasn't an improvement on top of ifconfig. It was an aggregation and systematization of various tools and configurations that dealt in a very partial way with various aspects of networking. There would've been no way to keep any kind of backwards compatibility with ifconfig, so there was no reason to keep the name. It's not an evolution of ifconfig, it's an entirely different thing.
- nailer 4y ago
  > What people are you talking about? People that maintain software. > Anyone who's on a payroll is liable if they don't upgrade systems when they go out of support. Yes. Let's make that process easier. > Did ifconfig foresee bridge interfaces, bond interfaces, vLANs etc? No, that's precisely why I wrote the comment you're replying to. Yet people still use ifconfig, and wonder why the results don't make sense with their vlanned bonded interface. > It's not an evolution of ifconfig, it's an entirely different thing. Yes, agreed completely. But if we got away from scraping we could have added them a lot more gently. > There would've been no way to keep any kind of backwards compatibility with ifconfig Disagree. We can come up with a design here but I don't feel like you're actually responding to anything I write so I don't wish to do so. > there was no reason to keep the name To this day people are still scraping ifconfig and wondering why the results are bad.
- deleted 4y ago
  [deleted]