171–180 of 270 posts
Earlier quoted context omitted.
The man page is good. `ip` takes a --oneline arg to make it more parseable.
A --json arg would be much more parseable. I wonder if they'd be against that?
Not all subcommands support it though.
I'm trying hard to fight my old muscle memory to use ip instead of ifconfig on Linux. I have a few issues though: * "ip" is useless as a keyword if you're looking for help online. It's extremely frustrating and probably my main issue actually learning how to use the damn thing. * ifconfig's output is simply more readable IMO: https://svkt.org/~simias/up/20180525-113825_ip-vs-ifconfig.p... . It's pretty weird that a b…
I think google is smart enough that you search with "ip command" (maybe plus "linux", it'll get relevant results. It's better that the command you type often is short, (you can certainly alias ifconfig as "ifg" or anything too).
Take for instance a very simple query: "ip show default route":
https://duckduckgo.com/?q=ip+command+show+default+route&t=ff...
There are a few obviously relevant matches in the first page but also a bunch of completely irrelevant results. Adding "command" doesn't improve that much. And that's for a very simple query that's probably been asked hundreds of times before.
Meanwhile if I search "ls sort date" I get mostly relevant results immediately because even though it's also a 2 letter identifier it's not quite as ambiguous: https://duckduckgo.com/?q=ls+sort+date&t=ffab&ia=qa
TIL: iproute2 has a color, a brief/human mode, and a one-line mode. I think I am going to be aliasing ip -color to ip from now on. $ ip -br -c a # ip -brief -color address lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 DOWN wlan0 UP 192.0.2.1/24 2001:db8::1/64 fe80::1/64 $ ip -br -c l # ip -brief -color link lo UNKNOWN 00:00:00:00:00:00 eth0 DOWN 00:12:34:56:78:9a wlan0 UP 12:34:56:78:9a:bc
This is a good reminder that defaults should be simple and human readable. Advanced options should be behind flags for power users, not the other way around.
That said, a new alias that does trigger these new behaviors as defaults would be a sane compromise.
Earlier quoted context omitted.
> "Old does not mean bad" It doesn't automatically mean "good" either. > "in its pursuit to be Windows" Would you please elaborate?
Windows subsumes a lot of small network daemons into a monolithic process called SVCHOST.EXE. Systemd does a similar thing.
Earlier quoted context omitted.
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.
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 ar…
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...
etc.
Earlier quoted context omitted.
I'm not sure "terse" is the right adjective. It presents basically the same amount of information as ifconfig (minus the packet counters) and actually adds a few more flags. It's all about the formatting really. Simply adding an empty line between each interface would go a long way. Also starting the line with the interface name instead of the index. Adding more punctuation to delimit the fields (, : etc...) would be…
Huh, does "ip" also support "tc" (traffic control) commands - qdisc is a queueing discipline... tc seems to be the an earlier thing from the people who brought us ip. tc must have the worst command line interface and documentation ever - it is very hard and very frustrating to use, like no other command line interface I've ever seen. I once tried to use tc and gave up after more than a day of trying, that is how bad…
Earlier quoted context omitted.
the help gets more specific the more complete your command gets. Try "ip link add type vlan help" for example. While i agree it does nothing to explain what the various switches do, if you know what you are trying to achieve this is most of the time enough. However i do not agree about the man pages the switches are explained there in enough detail in my opinion...
The switches are useless until you have an idea about what the command can do. And yet the 'IP - COMMAND SYNTAX' section has text like ' link - network device'. What the hell does that mean? So 'ip link' does what exactly? Could the developers have typed more than just two words to try to explain this command (action?) Good luck to anyone who decides to RTFM.
You have to read the manual too ;)
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 d…
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/ ) 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 Lin…
Earlier quoted context omitted.
A bird in the hand is worth two in the bush. The article speaks of old software but, instead of fixing what it has and being standards compliant, it chooses to break away and do its own thing along with the new bugs and other issues which will surely arise.
> "instead of fixing what it has and being standards compliant, it chooses to break away and do its own thing along with the new bugs and other issues which will surely arise." Well, people are still free to maintain and improve those older tools and bring them up to par with newer standards, if they want to. Others would argue it's time to start phasing out code and so-called "standards" we've had since the early 90…
When choosing platforms, how communities weigh this balance is a very important consideration. You want to associate with people and groups who value essentially the "reasonable breeze" mode that keeps life flowing through extant systems. "Natural disasters" may sometimes be justified to help clear out the way-too-old (e.g. systemd or SMF), but they should be rare; systems can only tolerate major disruptions like that once or twice a decade.
Linux has an "anything goes" approach, which is usually more symptomatic of the age/maturity of the crowd it draws in than a reasoned decision about where to fall on this balance. That's not necessarily bad, but it makes more of an experimental atmosphere than something reliable, trusted, and stable.
Earlier quoted context omitted.
Are they really "terrible" with "awful usability"? In my day-to-day debugging, I do find `journalctl` much better. Let's see a couple of quick examples: - Show logs for the current boot: $ journalctl -b - To get all errors that are of priority level ERROR and worse: $ journalctl -b -p err - Show me logs for a given binary: $ journalctl /usr/sbin/libvirtd - Or via its unit file: $ journalctl -u libvirtd -l - Want to q…
Yes that is an awful soup of switches that should either be separate commands or usages of existing Unix tools.