3 ms·
This complaint about df/mount/etc. recurs with noticeable frequency. Another ugly spot is iproute2's ip link/addr. Between containers and VMs and their virtua
by topspin 2y ago
This complaint about df/mount/etc. recurs with noticeable frequency. Another ugly spot is iproute2's ip link/addr. Between containers and VMs and their virtual interfaces, link bonding, virtual bridges, macvlan/tap, etc., the list of "interfaces" proliferates. Trying to find an actual physical interface is difficult, and interpreting what is there is a challenge.
Improving this stuff isn't happening because no one is funding the work. A hobbyist or gainfully employed contributor stealing time from "real" work can't manage this anymore: complexity is too high now and the gatekeepers aren't -- for good reason -- going to tolerate naïve contributions.
There is very little money in the Linux world for anything a Linux distributor or hardware manufacturer doesn't care about. The former care only about the high value features people pay license/subscription/support fees for, and the latter just get drivers working, and maybe rework a kernel subsystem when absolutely necessary, and leave the rest.
The money exists. The Linux Foundation collects a quarter billion a year, for example. But they've found a long list of better priorities to spend it all on.
I don't know about the "trainwreck design" concept. There is nothing here that can't be solved given some hard headed refinement. It's just that no one is doing that.
- gsich 2y agoA single \n would improve ip link/addr. There is no easy way to visual grep the right interface. ifconfig is much better in this regard, but has obvious downsides.
- nottorp 2y agoBut... you have to use systemd tools to parse the output these days. Why are you even looking at this with the naked eye?
- gsich 2y agoI would gladly switch to a systemd command. What should I use?
- topspin 2y ago> Why are you even looking at this with the naked eye? My first instinct was to answer your question with a question. I'll avoid that. In the real world of devops, whatever you might have in mind as not "naked eye," fails. Deeply isolated systems, embedded systems, development environments, headless systems, virtualized systems, etc., don't have working GUIs, complex input devices or other high fidelity tools. You get a terminal. The terminal tools are the ground truth when all else has failed. They need to work. And when they work in a usable manner they're wonderful: you can deal with complex tasks and issues over absurdly slow connections, tunneled and bounced through a endless chain of hosts, with no client side capability beyond a terminal emulator. This is one of the key benefits of the UNIX legacy and a reason it has proliferated to nearly every application. Having answered your question directly, I'll ask mine: what, pray tell, do you recommend that meets every requirement stated or implied above?
- nottorp 2y agoYeah, I keep forgetting HN needs explicit sarcasm tags.
- hinkley 2y agoPeople knew sarcasm doesn’t translate on the internet a decade before Poe’s Law was named.
- hinkley 2y agoAlso the point of the article is that all of this stuff used to work just fine. Abandoning tools people used just fine for decades is a cop out wrt to the context of this conversation.
- huem0n 2y ago> It's just that no one is doing that. There's a new wave of Rust based tools. Things like sd instead of sed, and fd instead of find. I think they have an opportunity to fix these things. They're not built in right now, and probably won't be anytime soon. But maybe eventually they will be. Although, on a different note, I don't think they follow the hive or cathedral design that this author discusses so maybe they will end up with their own lack of cohesion.
- anal_reactor 2y ago> Things like sd instead of sed, and fd instead of find. I really wish we'd stop naming things `a`