Just finished looking at Ink here.. frontend world has no shame. Love the gloating about 40x less RAM as if that amount of memory for a text REPL even approaches defensible. "CC built CC" is not the flex people seem to suggest it is.
Frontend losers not realizing the turds they are releasing. An LLM client fits under netcat+echo+awk+jq runnable under a 486 if there's no SSL/TLS on its way, Pentium II could drive fast TLS connections like nothing and under 32MB of RAM with NetBSD for a simple terminal install, maybe with X and a simple WM with RXVT if you care.
Can you explain to me why either of these is useful?
I've somehow gotten by never really needing to pipe any commands in the terminal, probably because I mostly do frontend dev and use the term for starting the server and running prodaccess
Pipelines are usually built up step by step: we run some vague, general thing (e.g. a `find` command); the output looks sort of right, but needs to be narrowed down or processed further, so we press Up to get the previous command back, and add a pipe to the end. We run that, then add something else; and so on.
Now let's say the output looks wrong; e.g. we get nothing out. Weird, the previous command looked right, and it doesn't seem to be a problem with the filter we just put on the end. Maybe the filter we added part-way-through was discarding too much, so that the things we actually wanted weren't reaching the later stages; we didn't notice, because everything was being drowned-out by irrelevant stuff that that our latest filter has just gotten rid of.
Tricks like this `\#` let us turn off that earlier filter, without affecting anything else, so we can see if it was causing the problem as we suspect.
As for more general "why use CLI?", that's been debated for decades already; if you care to look it up :-)
It goes beyond what I was able to do with git settings alone. Specifically stripping the headers/padding/decorative and it doees it across all output (or well a lot of it).
wlroots is self-described as "about 60,000 lines of code you were going to write anyway." It's also a moving target and you'll probably have to retool when wlroots updates.
That seems like a huge burden to carry around, considering that a minimal X11 window manager can be a few thousand lines of code and probably still compiles after 15 years.
I think that's actually the biggest real criticism that can reasonably be made about Wayland: they ought to have produced something like wlroots from the start.
Weston was only ever intended to be an example, and its monolithic nature meant that it wasn't particularly useful as a platform on which others could build (and this was even more true early on, before libweston).
As a result, GNOME and KDE both did their own implementations - and from that seed grew a host of complaints about things not working in one or the other, when on xorg they had worked more or less the same. The lack of a common entry point for "plumbing" also hurt, and can probably take much of the blame for the initial pain that many faced when first moving to a wayland-based DE.
But, of course, that's only obvious in retrospect. I don't think it was at all clear at the time those decisions were being made originally - in other words, it was a mistake rather than malice.
That helps, but you still have to - at a bare minimum - wire up all the functionality. My pet example is trying out a new wlroots compositor and discovering that it has no way to change keyboard layout because it doesn't use that code from the library yet.
reply