Comment by Crysstalis | Hacker News Reader

Comment by Crysstalis | Hacker News Reader

Parent Full thread

>And second system syndrome too probably

In my opinion, Wayland has avoided this by deliberately being simpler than X11.

> I'm using $DISTRO because I trust them enough to not package spyware/malware in their repos

>but holy hell my OSS desktop is not a proprietary smartphone OS loaded with random closed-source apps from god knows who that tries to steal my data for profit

I think it is not reasonable for you to ask them to never plan for a day when that could happen, if that is what you are suggesting anyway.

>You'd assume there's an equivalent tool for Wayland

Not if you were aware of the current issues with Xrandr and why it is a poor target.

>But mumble mumble security, you cannot do that, so we got the same f#+ing situation as with screen recording again, every WM/compositor comes up with their own solution to something absolutely trivial. GNOME/Mutter have a dbus-API, wlroots-based ones have "wlrandr" via some protocol extension, KWIN I didn't even bother checking. But it's only 15 years since the project started right, why should something trivial as this have been settled upon yet?

It is absolutely not trivial, and there are security/usability issues with it. To do this "the right way" would be more or less duplicating the entire KMS API into every implementation. Even XRandr is still missing features compared to that, so it is not an adequate solution either.

> I think it is not reasonable for you to ask them to never plan for a day when that could happen, if that is what you are suggesting anyway.

Then plan for it, architecturally, so that you can add or enable these features later on, or when you need it. Start with something sensible, appropriate for real-world usage. Wayland was everything but. With X11 the ship has sailed in that regard, but if you start over, don't create something that doesn't even offer these features in the name of security and then let the community come up with 10 different solutions to the same problems in the most uncoordinated way possible.

> Not if you were aware of the current issues with Xrandr and why it is a poor target.

xrandr works exactly fine for setting up your screens. You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way. It's a great example for a trivial real-world tool that should just exist.

> It is absolutely not trivial, and there are security/usability issues with it. To do this "the right way" would be more or less duplicating the entire KMS API into every implementation. Even XRandr is still missing features compared to that, so it is not an adequate solution either.

This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those. Done. X11 does it, Windows does it, macOS does it.

>Then plan for it, architecturally, so that you can add or enable these features later on, or when you need it. Start with something sensible, appropriate for real-world usage.

This is exactly what Wayland has done though. Few have a reason to run command line tools to change the screen configuration, real world usage is to use a GUI as is common on every other graphical OS.

>You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way.

A major problem here is because of the way the API works, technically any X11 client can do that at any time. The tool may seem trivial but the way it is implemented has great potential for misuse. It does not even have to be malware for this to cause problems, for example a typo in a random script could seriously screw up your screen. Or another common problem in X11 is with applications setting the resolution to something weird, crashing and then leaving the screen in a weird state.

>This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those.

If this was second system syndrome, then it would be in the kernel, not in X or Wayland. Because the kernel is where all the new KMS features happened. Again, the display server is not actually driving this feature. They are relaying information to and from KMS, which is the actual API that configures the screen.

> Few have a reason to run command line tools to change the screen configuration, real world usage is to use a GUI as is common on every other graphical OS.

But those few gravitate around OSes using X11. Any other graphical OS has way more users that use the computer they are given to perform the task they are given. No questions asked, no fiddling with settings. When you develop for people that use a system specifically because it allows fiddling, you must not take away functionality. If you do, prepare for criticisms.

But you can still fiddle. Unless I missed something, the only complaint here is that the method of fiddling has changed.

And somehow, I doubt that even the most fervent of fiddlers really enjoy typing obscure command line incantations just to configure their laptop when they connect it to a projector.

Are you arguing against the value of a command line interface in the Linux world? Command line is appreciated because of its simplicity and composability. The ability to automate and integrate with a huge ecosystem of compatible tools. Is this really a debate still worth having?

>The ability to automate and integrate with a huge ecosystem of compatible tools

What you are thinking of is an API, not a command line interface. That still exists, and it can be used to build a command line interface. Command line interfaces by themselves are actually very poor for automation and integration, as they force you to do lots of unnecessary formatting and parsing in and out of text strings at every step.

For graphical tasks such as this, the command line is indeed obsolete. The main usage for remaining with the command line in modern times is for manual administration of a remote server, but that is not relevant here as the whole problem space is about administering the local machine as a GUI.

I did document administrative procedures as click here, click there, check that box, click there again. I also document them as commands that can be copy / pasted, even on my laptop. I'd say that GUI administration of a local machine is nice for casual tssks, but a waste of time for repetitive tasks and when I feel that I might need to do it again in future. A command line is much more reproducible. It's dconf vs gsettings.

But that is where you hit impedance mismatch. Some things that are easy to represent in a GUI (because they are graphical tasks) cannot be easily represented in a command line tool. XRandr is probably the worst example of a scriptable tool because you have to manually type in the coordinates and screen sizes which is at odds with how you would configure a graphical screen. If you want to set them based on some logic or calculations, you are better off reaching for a python script or something that is actually pleasant to write code in, and then use that to invoke the real API, not command line tools.

I didn't touch xrandr much in my life (I'm not the OP) and I don't know which APIs are available so I don't know if they are pleasant or not, but wouldn't I write coordinates and screen sizes in Python too?

Anyway, xrandr is already there and Google and stackoverflow are full of examples. I'm not surprised that people would invest half an hour copy pasting code from there instead of identifying and learning the underlying API. I don't see why that should be a problem.

Command-line interfaces do not have to be text-stream based.

It is not true that command-line interfaces are not used to remotely administer GUI desktops. This is actually a huge and very common problem space.

Making a command line interface that outputs binary is even worse than a text stream, because then it cannot be used interactively at all, and that defeats the whole purpose of a command line user interface. At that point you are making tools for programmers, and are better off letting them reach for a real programming language and an API.

See my other comment about impedance mismatch for an explanation of the challenges with using command lines to remotely administer GUI desktops. It can be something that complements GUI administration, but can never possibly supplant it, because if you do that then you're intentionally trying to route around the problem space.

I had specifically Powershell in mind, which is object-oriented and absolutely can be used interactively.

> It can be something that complements GUI administration, but can never possibly supplant it,

There are probably tens of thousands of people whose daily lived experience is that command-line administration of GUI desktops is all they've ever needed and yes, in fact, totally supplants the alternative. I am really struggling with this thread; it's my impression that you've a very narrow view of what people are doing with their computers.

> Or another common problem in X11 is with applications setting the resolution to something weird, crashing and then leaving the screen in a weird state.

Common problem? I’ve never heard of this happening. I suppose hypothetically random applications could trash my X settings but in 20 years they haven’t.

On Windows I have observed random applications do have this power and sometimes exercise it, but the worst it’s ever done is mess up my desktop icon arrangement, by some mechanism I know not the OS reverts the resolution change if the application crashes.

Sure, you may not have heard of it. But it is a thing that can happen and is not possible to fix without changing (i.e. breaking) the API. X11 does not have a mechanism to fix it, that was never added.

> In my opinion, Wayland has avoided this by deliberately being simpler than X11.

Wayland is not really simpler than X11 unfortunately. The core protocols are very poorly documented, and a lot of practically important stuff is left to be implemented in unspecified ways by the compositor. Like a lot of freedesktop.org stuff historically, it's hard to tell what's prototype-quality from what's actually ready for daily-driver production use.

>Wayland is not really simpler than X11 unfortunately.

I would say it is. All the things you said are also true of X11 and are worse there, which is another reason why it has been so impractical to develop additional X11 servers, and why everybody always just used X.org despite its shortcomings. And by the way, freedesktop.org has for the most part merged with X.org now. It is the same group of people doing the same work.

> The core protocols are very poorly documented,

Any examples? I found it much easier to grasp than X11. I have worked on libraries that have both X11 and Wayland backends and X11 code was always an impenetrable pile of workarounds that could break from looking at it, while Wayland code was usually relatively simple and easy to understand.

Reply on news.ycombinator.com