Live data from Hacker News

There are real reasons for Linux to replace ifconfig, netstat, etc

utcc.utoronto.ca

231–240 of 270 posts

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#231
post #185

Earlier quoted context omitted.

You do realize Solaris implemented a service management system (which is also superior to systemd; and was also created prior to systemd's conception), right ? They switched away from legacy SysV init scripts BEFORE systemd existed.

SMF was quite nice. Solaris was incredible in a lot of ways. I always wonder why it never took off.

Because nobody were interested?

Damn it, Apple have a similar thing going in OSX (or whatever their greasy marketing wants to call it this year) but when it was basically offered to the BSDs on a silver platter they didn't want it.

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#232

Earlier quoted context omitted.

I'm not sure what the point you are making here is. The developers behind "ifconfig" on Linux could support the new API (iproute2) just as the developers behind "ifconfig" on OpenBSD updated their software to support the new kernel API as they became available.

The point is that in the BSDs, ifconfig is developed and released together with the kernel. See, for example, https://svnweb.freebsd.org/base?view=revision&revision=31237... , where the author added support for hardware packet pacing. The commit touches ifconfig, socket header files, and various parts of the kernel all in one atomic change.

Nothing stops anyone from offering patches to multiple projects to sync development. Hell, some of the biggest changes crossing the kernel/userspace divide have just that.

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#233
post #185

Earlier quoted context omitted.

SMF was quite nice. Solaris was incredible in a lot of ways. I always wonder why it never took off.

Because nobody were interested? Damn it, Apple have a similar thing going in OSX (or whatever their greasy marketing wants to call it this year) but when it was basically offered to the BSDs on a silver platter they didn't want it.

Implying that launchd and SMF are similar shows how little you know about both systems.

Launchd is mostly crappy, obtuse plist files, a semi-broken DAG, socket activation that spins your machine to death.

SMF was an access point to many things, it was clean, concise and pointed you towards the actual things that the OS provided. (like; log files) It was a pleasure to work with.

The only problem was that service definitions were configured with XML, I have never been a fan of XML.

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#234
post #18

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…

If only ifconfig was standardized on the output... it's output has changed over time

Let alone the non-conformity of other OS's like Solaris, HP-UX which really might not matter now. I'm sure FreeBSD matters to someone... just not me

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#235

Earlier quoted context omitted.

This is ridiculous. I would love to know their justification for using single dash for long options. When did that become the "old way"?? Very old X11 commands and many Solaris commands use a single dash, but nearly all modern commands use double dash. And I agree that this syntax makes it hard to combine single-character options. They must have had a very compelling reason to use a non-standard option syntax.

The Golang flag [0] package uses a single dash for long options. The flags that a UNIX command uses can sometimes used to carbon-date that command. For example, dd(1) doesn't use a dash at all, uses long args, and uses an equals-sign to connect a flag with its argument (e.g. `dd if=/dev/null`). It's because dd(1) was written in the dawn of UNIX, before a convention was established for flags. I believe the first step…

Re: Go, it describes the flags with a single dash, but it will accept them with a double dash and a more traditional style (both --string "foo" and -string="foo" are accepted, for instance)

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#236

Earlier quoted context omitted.

> whereis Thanks for this! After 14+ years of using Linux almost daily, I had never heard of this command. I learned something new today, so now it's time to go home!

Yeah, I recently "discovered" the commands 'whatis' [0] and 'apropos' [1] and my experience learning Linux improved quite a bit. [0] https://linux.die.net/man/1/whatis [1] https://linux.die.net/man/1/apropos

Thanks for passing those on as well!

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#237

I've never understood the purpose of IP aliases like the "secondary em0" the author is setting up with systemd.networkd. These aliases are practically useless, you cannot bind() to them without knowing the IP, you cannot use them in firewall rules, you cannot setup dhcp for them etc. What are people using them for? I'm not sure what the low level difference is between an alias like in the article, or a "eth0:1" type…

In many cases, the IP is the thing that comes first and foremost. You'll put it in DNS, you'll bind services to it (often because that's what the DNS is pointing to) or use it for outgoing traffic, and so on. Any interface name for it is simply an implementation detail, and you can live without it and even simplify your life if you don't have to come up with and keep track of those names.

(This is especially the case if you may at some point shift an IP alias between systems in order to move traffic from one to the other.)

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#238
post #227

Earlier quoted context omitted.

They won't. In fact it is already implemented. Try `ip -json addr`. Not all subcommands support it though.

Which version has implemented this? It's not available here. rascul@coyote:~$ ip -json addr Option "-json" is unknown, try "ip -help". rascul@coyote:~$ ip -V ip utility, iproute2-ss160111

Looks like it was added in August of last year. Obviously newer than what my distribution has.

https://git.kernel.org/pub/scm/network/iproute2/iproute2.git...

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#239

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.

What are you talking about? Systemd (pid 1) just does socket activation, it has no high level functionality. Yes, there are related programs like systemd-timesyncd, but they are completely separate processes, and can be managed separately and even omitted altogether.

Now, traditional BSD inetd had discard, chargen, echo, ... protocol support, which means that it was actually more integrated that systemd.

Re: There are real reasons for Linux to replace ifconfig, netstat, etc

#240
post #176

Earlier quoted context omitted.

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…

MegaCLI (lsi hw raid control) sees your tc and raised you a few million awful flags.

I see your MegaCLI and raise you certutil: https://docs.microsoft.com/en-us/windows-server/administrati...
Post reply on HN