51–60 of 109 posts
Earlier quoted context omitted.
Because it's potentially trademark infringement because it could confuse people.
Can you actually trademark a common word? (Serious question)
(With help from Claude completing the list)
go install github.com/karol-broda/snitch@latest
go: github.com/karol-broda/snitch@latest: version constraints conflict:
github.com/karol-broda/snitch@v0.1.8: parsing go.mod:
module declares its path as: snitch
but was required as: github.com/karol-broda/snitchEarlier quoted context omitted.
I immediately thought of that too. The names these people come up with are so embarrassing. And I'm not even talking about the meaning of 'snitch'. But you already have a tool within the same IT area that is basically named the same. Why the hell would you do that? Aren't there other words in the dictionary?
> The names these people come up with are so embarrassing. And I'm not even talking about the meaning of 'snitch'. They should call it "rat" and be done with it. Besides, "snitch" works for Little Snitch -- I've always found it somehow endearing, although the bare word is unflattering.
Earlier quoted context omitted.
Can you actually trademark a common word? (Serious question)
Yes, Apple, Windows, Amazon, Shell, Target, Dove, Ivory, Tide, Polo. (With help from Claude completing the list)
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.
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.
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.
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.
The only one I change is to add `--no-ignore`.
Earlier quoted context omitted.
Are they as accessible as GUI though (genuine question) UI libraries have a lot of features for allowing people with disabilities to “read” and interact with the screen in efficient ways
TUI tools are generally as accessible as the terminal on which they run. GUI apps are much trickier. They require that the developer implement integration with accessibility frameworks (which vary depending on X11/Wayland) or use a toolkit which does this.
When it comes to GUIs, you have a higher level of abstraction than grid-of-glyphs. By using a GUI toolkit with these abstractions, you can get accessibility (relatively) for free.
Open to having my mind changed though.
Earlier quoted context omitted.
Accessibility is a great thing to have and strive for, but it cannot be the number one design principle. Imagine if everything around us would be designed for blind people.
I suspect blind people imagine that a lot. The idea is to design for all (or as many as feasible), it's not a binary either/or.