[Toybox] complaining about 'ifconfig' - better use 'ip'

[Rob Landley]

On 04/04/2013 04:25:03 AM, Bastian Bittorf wrote:
> * Rob Landley <rob at landley.net> [04.04.2013 10:03]:
> > Yup, just pulled up my old Red Hat 9 image under qemu and did
> > ifconfig eth0 10.0.2.15/31 and it worked fine.
> 
> you are right, shame on me.

Sorry for complaining about it in the last email then. (Reading 'em as  
I see 'em...)

> > Heh, it's still up at http://busybox.net/downloads/qemu/ if you'd
> > like to try that yourself.
> >
> > >- aliases + multiple IP's on one interface
> >
> > I did aliases with ifconfig in 2002, there's a colon number syntax  
> or
> > some such...
> 
> ip address add 9.8.7.6/32 dev lo label lo:commentXY
> are labels supported via ifconfig?

There's a label tool somewhere. I haven't bothered with it, I assume  
people will submit one if they need it. I looked into the low level API  
so I could build the functionality into "mdev", actually...

(Looking down in this very email, it's apparently "nameif".)

> > >- correct output of aliases
> >
> > Define "correct".
> >
> > sudo ifconfig lo:0 10.255.255.1/31
> > ifconfig
> >
> > lo        Link encap:Local Loopback
> >           inet addr:127.0.0.1  Mask:255.0.0.0
> >           inet6 addr: ::1/128 Scope:Host
> >           UP LOOPBACK RUNNING  MTU:16436  Metric:1
> >           RX packets:5708561 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:5708561 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:0
> >           RX bytes:3736486922 (3.7 GB)  TX bytes:3736486922 (3.7 GB)
> >
> > lo:0      Link encap:Local Loopback
> >           inet addr:10.255.255.1  Mask:255.255.255.254
> >           UP LOOPBACK RUNNING  MTU:16436  Metric:1
> 
> this is wrong:
> lo:0 is no interface, so why does it show an extra interface?

I note that technically "lo" isn't an ethernet interface in the first  
place, so you could make the same argument there...

> > >- more than one routing table ("policy routing")
> >
> > Never tried, but I've done some fun stuff with iptables and some
> 
> so, because you never tried - it's not needed? 8-)

No, I'm saying I'm scratching my own itch and you complaining about  
ifconfig does not trump other people submitting code to me and  
complaining in email that they would be "very confused" if it was  
removed because it's part of their patched version of toybox that  
they're already using in a product.

> > other fun stuff with containers. http://landley.net/lxc/
> 
> > >- preparing traffic control
> >
> > man tc
> 
> tc belongs to 'ip'.
> so how to you set up an 'ip rule' with ifconfig. 8-)

I don't care.

This is the difference between you and me here. If I implemented "ip",  
it wouldn't use code from iptools. If I implement "rotue" it won't use  
code from net-tools. Your complaints about horrible infrastructure are  
mind-bogglingly irrelevant, it's gonna be a fresh implementation. (At  
least when I get done with it...)

You like the "ip" command being its own swiss-army-knife that sucks in  
route and arp and such, but then tc is an external command rather than  
a flag to the ip monolith and that also makes it better. Right. Fine.  
I'm sure it makes sense to somebody.

> > >- better parseable output (if needed, e.g. ip -oneline link show  
> tun0)
> >
> > Look, I'm not saying that providing an alternate interface to the
> > same functionality for people who are used to and expect the other
> > interface is a bad thing, especially if it's easy to do. But that
> > cuts _against_ your complaints about ifconfig. You're claiming
> > ifconfig is an incapable relic, and so far not showing things that
> > actually require ip. The point of this thread is you said that we
> > should NOT implement ifconfig and friends.
> 
> the idea behind it is:
> dont encourage people to use such old, incomplete, inconsistent tools.

1) cat's older
2) this should (eventually) be a fresh implementation
3) we can add stuff until it's not incomplete
4) you've never explained inconsistent, just asserted it. (No, I'm not  
interested in hearing it at the moment. I'm experiencing topic  
exhaustion.)

> especially if you make something new, this is the chance to enforce
> people to use/learn the new interface.

No. No it isn't. There are existing users. I'm trying to serve the  
userbase.

> sooner or later they need to learn "ip" anyway,

No, they don't. You keep saying that, and I see no reason it would ever  
be true.

> so why not doing it right? is there any distro
> not shipping 'ip' (iproutw2)?

People made this argument for udev. I wrote mdev. This is the same  
argument people are making right now for "systemd". I'm not doing that  
one.

> > >- you can rename interfaces
> >
> > man nameif
> >
> > >- multicast working
> >
> > I'm fairly certain multicast was around in the 90's. I remember
> > people bemoaning its failure even then. (How is the mbone doing?
> > Netflix streaming making extensive use of that, then? Skype?
> > Youtube?)
> 
> multicast makes more sense in the ipv6 world

No it doesn't. I was working for a set top box manufacturer in 2001, we  
were doing movies on demand and DVR and all that long before there was  
a _market_ for it. (It never shipped because the rights were tied up  
and before Tivo and iTunes and Hulu and Netflix it was REALLY HARD to  
get any content providers to budge from the closets where they cowered  
in terror from the internet. Heck, this predated _youtube_. We had a  
project to try to clone the RTSP server because realplayer was still a  
thing, that's how long ago this was.)

And we _studied_ multicast. We looked into making it work, and why it  
wasn't more widely deployed. And it boils down to "television and radio  
exist, the internet isn't that". The user access patterns just _aren't_  
bulk access to exactly the same data at exactly the same time. A decade  
ago akamai was pioneering geographic distribution, then bittorrent came  
along (and got blamed for bufferbloat ala  
http://gettys.wordpress.com/2010/12/07/bufferbloat-and-network-neutrality-back-to-the-past/  
but that wasn't the problem), and these days if google, youtube, and  
netflix can't benefit from multicast there is _no_point_ to it.

Now maybe https://youtu.be/GuqmKg6QQTw returns this to relevance, but I  
really think http://nielsenhayden.com/makinglight/archives/010186.html  
is going to free up the bandwidth that was misallocated to television  
before too much longer. Maybe not to  
http://www.newamerica.net/files/nafmigration/archive/Pub_File_1555_1.pdf  
levels but things like http://en.wikipedia.org/wiki/Ultra-wideband  
might work around that...

But then I'm not a developer in the network world, what do I know? Feel  
free to tell me about the future of multicast. Starting with maybe  
answering my objection that when multicast was invented, ifconfig was  
all we had, so multicast _has_ to work with ifconfig?

> > Look, I asked "What can you do with ip that you can't do with
> > ifconfig/route?" You didn't come up with anything actually
> > _requiring_ ip yet, that I've noticed.
> 
> you negated a lot of arguments, but there are some left.
> but the killer-arg is the existing ifconfig in androids toolbox,
> so ifconfig is needed, ip is optional 8-(
> 
> hopefully the person which implements 'ifconfig' will also do:
> 
> arp
> ipmaddr
> iptunnel
> route
> nameif
> netstat

Or _I_ could do them. Ifconfig was always on my todo list, it was just  
down below a lot of other stuff.

I note that things I want to do tend to get bumped behind cleaning up  
commands people submit to me. So the fact that I could do sed or mount  
fairly easily (they're time consuming, but not _hard_ since I already  
did busybox versions of both)... I haven't done them and am not likely  
to do them any time soon because of the giant pile of stuff in the  
"pending" directory and things like "cut.c" and "login.c" elsewhere in  
the tree that need cleanup before I have the luxury of implementing new  
features.

(I care more about quality of the code than rapidly increasing the  
feature set. All these commands already exist elsewhere, toybox needs  
to be _better_ code. I get spontaneous contributions of new commands. I  
hardly ever get spontaneous cleanups of existing code.)

Rob