On 04/04/2013 04:25:03 AM, Bastian Bittorf wrote:
* Rob Landley <[email protected]> [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
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
