Thanks for the link. Might put me off Nix a bit. I may look into comparing some of the other immutable distros like Fedora’s. Idk I avoided them early on, but I’ve had to spend a lot of time fixing shit lately and was considering a change.

Stuff like ydotool, wtype exist and presumably there are others for this. Search on automation testing on Wayland and see.

Since it is a niche I'm not surprised if it wasn't a critical path for Wayland adoption but clearly there are solutions that work for certain compositors and I assume people working on a more robust solution. But allowing one piece of software to sniff or inject input, or capture its content is an obvious security flaw and Wayland devs are right to put it front and centre. If a desktop is to allow those things then it should be through a security model instead of in the absence of one.

They could have been two commands that call a single parent command with different options. For example, imagine if cat had an option -N to restrict the number of lines that was printed, and also an option -t to start from the end. head would just proxy to cat -N and tail would proxy to cat -N -t. Combining the three into a single implementation reduces total LoC and opportunity for bugs. Also reduces total maintenance burden.

I believe busybox is like this actually - a ton of Unix commands in a single package. It's used by Alpine Linux, a tiny and performance linux distro commonly used by docker containers.

I initially agreed with your take there but I actually think they're a great argument for their point. head and tail are the exact same abstraction. Their implementations will be quite different, but they both serve "provided this data, give me these lines". Consider instead that these are simply operations on arrays and actually they map perfectly to Python slices: data[:10] and data[-10:]. This abstraction mapping also shows that, imo, the tool should provide data[n:m] and it would still be entirely consistent with the Unix philosophy. In fact, this tool exists in the Unix toolkit: sed -n n,mp. Three tools then are currently required for the simple concept of "slice lines". I also think it's a bit of a mess. You could replace head with sed fairly easily: sed -n '1,10p' but not tail (it is possible, but quite slow and very opaque)

As an aside I actually found this quite frustrating myself because I don't like reaching for sed in the n:m case (I always forget and end up piping head to tail) and ended up writing my own tool for essentially this style of slicing input, also replacing probably my least favorite use of my least favorite Unix tool, dd, to slice arbitrary byte sequences. The tool doesn't feel overloaded and I use it quite often.

(I'm sure many people have written this same tool. There is probably a widely known open source option that I've just never come across)

Really completely different? Do they not print first / last lines of text from a file into the terminal?

GUI certainly has its place.

But that's not what either of the guys complained about

If your favorite thing is being ruined and you can't stop it, I can understand frustration being displayed as anger.

That's the joy of open source though: you can stop it. You are free to use another init system, fork projects, etc. With Windows, you can't do any of that. Since it's closed source, workarounds that may be temporary are all you can do.

your favorite thing is being ruined and you can't stop it,

Hardly a 'favourite thing'; it's like making a water slide out of a river : Wantonly wrecking something simple, effective and usable for this mishmash isn't ruining something sacred as much as it is destroying something for no reason to dramatically create something lesser the world didn't need. Except with more hype, payola, ageism, strong-arm adoption and cult worship.

How is GNOME integrated with systemd?

I may have written that in a confusing way. I'm saying systemd's job is service management. Systemd-resolved is an unnecessary bit of scope creep.

Even systems that use text logs, compress logs using logrotate and you have to uncompress before you can read them. Also since the compressed tar.gz logs are a bunch of separate files, if you don't have an exact date of what you're looking for, you have to uncompress and search through all of them. I much prefer just using journalctl

You can't read a text file without a program either.

Downvoting is a legitimate tool of expressing your disagreement.

Maybe the people who downvoted didn't think the points were cogent or well-written.

Palestine

Well, perhaps Palestine is not controversial at all?