Comment by PunchyHamster
1 day ago
it's weird that both lsof and ss defaults are so awful
Like, ss without any options shows such arcane, rarely needed details as send/receive queue size but not the application socket belongs to.
And omits listening sockets which is main use for such tools.
I know picking the right defaults is hard ask but they managed to pick all the wrong defaults.
Completely agreed. Not sure what the historical reasons for lsof and ss are, but unix tools are structurally in a hard place when it comes to having sensible defaults over the long term.
Generally speaking, you can only have sensible defaults over time if you're able to change the defaults over time. New users and new use-cases come with time, and so what constitutes a "sensible default" changes.
However (and this is a drum I like to bang[0]), because unix tools only deal in usually-text bytestreams without any higher level of abstraction, consumers of those tools end up tightly coupled with how output is presented. Without any separation between data and its representation, the (default) representation is the tool's API. To change the default representation is to make a backwards-incompatible API change. A good example of this is how ps aux truncates longer than like 7 characters.
[0] https://www.cgl.sh/blog/posts/sh.html
Hah yes, I've come to unashamedly - by muscle memory since the 1990's - find myself always typing 'ps auxw[w...]', where [w...] is some arbitrary number of w's depending on how heavy my index finger feels at the moment of typing.
> change the defaults over time
however this breaks backward compatibility, as you noted. in the golden age of unix it was critical to maintain backward compatibility so that local tooling didn't magically break.
HP-UX seems to have an env var UNIX95 that affects XPG4 compliance in operation/output. Solaris always had a /usr/xpg[46] path (and /usr/ucb). GNU tools have POSIXLY_CORRECT. and so on.
I never liked using any of those because then you're on some other system, or in a break glass situation, and none of the tooling works as you expect. In the today world of a near monoculture of linux, it's fine I guess. And there's no reason today that complex commands like `ss` shouldn't be controllable via env var.
love your blog, thanks for the link.
> love your blog, thanks for the link.
Thank you!
Configuring configuration via env var is a good historical example. I think that especially works nicely when you Buy An Operating System. You know, one that is created and provided by A Vendor. In principle, the vendor can architect a unified metaconfiguration system, e.g. one or several env vars that align behavior to a standard.
But I dunno if it would work so well to to hypothetically apply that tactic to a modern bazaar-based OS like Linux. Distros do amazing, valuable work to unify things, but modern Linux is basically a zillion software packages in a trench coat. So either the distro carries a zillion patches to have a few env vars, or the distro carries no patches and there are a zillion env vars. Either way, total cost of maintenance explodes.
Maybe when people say "text is the universal interface," they really mean that once you've released a textual interface, the interface becomes universal, unchanging for all time.
> I know picking the right defaults is hard
I think we understand that UX problem much better now than developers did back in the 70s. In general, not just for ss/lsof
I think the same applies for many of the new breed of command line applications like fd and ag/rg.
Being able to use them intuitively trumps ubiquity, speed or features.
But it's not tradeoff! You can make default view useful without trading versatility.
Another annoying part is not supporting json or even CSV. Some tools got modernized with it (like iproute2 tool set), but for these you might as well do /proc scraping yourself...
That's true in general. But default view is still subjective. The challenge probably lies in recognizing the larges subset of your user base that would like it to be a certain consistent way.
Depends on the use case.
If used in scripts, ubiquity and speed can be important. Then again, the output of ss is not ideal for script processing.
That's the problem, it's not good for humans, it's not great for scripts
Very curious what is wrong about the rg defaults.
The only one I change is to add `--no-ignore`.
Don’t “netstat -utan” and “ss -utan” show basically the same thing?
"utan" means "without" in Swedish, so I use the more flowery "-tulpan" as my mnemonic. It means tulip.