Wandering Thoughts archives

2019-06-30

Understanding why 'root window' X under Wayland may matter

In a comment on my entry on how the X death watch has probably started, Christopher Barts said:

There is XWayland, and apparently it will support handling the root window, not just application windows: <link>

The missing piece of the puzzle is Xweston, which apparently allows you to run window managers for X on Wayland: <link>

When I read this, at first I was puzzled about how this could work and why this was interesting, because I couldn't imagine that an X window manager could manage Wayland windows (a view I've had for some time). Then I actually read the Xweston README and a little light turned on in my head. The important bit from it is this:

[...] Xweston should allow one to run Xwayland as a bare X server (i.e. taking over the root window) hosted by Weston.

What this would allow you to do is to use Wayland as the graphics driver for the X server. Provided that the Wayland protocol and API stay sufficiently static, this would mean that people wouldn't have to write or update graphics drivers for X, and that changes in the Linux (or Unix) graphics environment wouldn't require changes in X. Both of these would be handled purely by updates to Wayland compositors.

(Wayland would also serve as the input driver for X, and hopefully that side of things would also require fewer or no updates.)

At one level this is not too much different than how X sometimes works today. For instance, for Intel's graphics hardware the X server normally outsources most of this to OpenGL via glamour and modesetting (as I found out). However, specific X drivers can still be better than glamour and this still leaves the modesetting driver to keep up with any changes in kernel modesetting, DRM setup, and so on. Outsourcing all of that to Wayland gets X a stable interface that hopefully performs well in general, which obviously matters a bunch if there's no one really left to keep updating X's graphics and modesetting drivers (which seems to be part of the problem).

This doesn't deal with the other half of the problem of the X death watch, which is the quality of support for X in toolkits like GTK and programs like Firefox. Also, you'd (still) be restricted to X programs only; as far as I can see, you wouldn't want to try to run Wayland programs in this environment because they wouldn't integrate into your X session (and there might be other problems). If there start to be Wayland-only programs and toolkits, that could be a problem.

PS: Xweston hasn't seen any development for a long time, so I suspect that the project is dead. Probably a modern version would be built on top of wlroots in some way, since that seems to have become the Wayland compositor starting point of choice.

(A really energetic person could of course skip trying to turn wlroots into an X server backend and simply implement their favorite X window manager for Wayland using wlroots and then manage individual windows from X programs in parallel with windows from Wayland programs. Note that I don't know if all of the things that X window managers can do are possible in Wayland.)

(This is one of the entries that I write because I finally worked something out in my own head and I don't want to forget it later. Hopefully I worked it out correctly and I'm not missing something.)

WhyRootedXOnWayland written at 22:23:32; Add Comment

2019-06-26

The death watch for the X Window System (aka X11) has probably started

I was recently reading Christian F.K. Schaller's On the Road to Fedora Workstation 31 (via both Fedora Planet and Planet Gnome). In it, Schaller says in one section (about Gnome and their move to fully work on Wayland):

Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is.

I have no idea how true this is about X.org X server maintenance, either now or in the future, but I definitely think it's a sign that developers have started saying this. If Gnome developers feel that X.org is going to be in hard maintenance mode almost immediately, they're probably pretty likely to also put the Gnome code that deals with X into hard maintenance mode. And public Gnome statements about this (and public action or lack of it) provide implicit support for KDE and any other desktop to move in this direction if they want to (and probably create some pressure to do so). I've known that Wayland was the future for some time, but I would still like it to not arrive any time soon.

(I'm quite attached to my window manager, and it is very much X only. I am not holding my breath for anything very much like it, especially not as far as something like FvwmIconMan.)

Gnome's view especially matters here because of GTK, which is used as a foundation by a number of important desktop programs such as Firefox (but not Chrome, which apparently has its own toolkit system). If X support decays in GTK, a lot of programs will start being affected, and I don't know how receptive the Gnome developers would be to fixes if they consider X support to be in hard maintenance mode.

(But a lot of this is worries, rather than anything concrete.)

PS: I have no idea what non-Linux Unixes are going to do here, especially for NVidia hardware where driver support is already lacking and often at the mercy of NVidia's corporate priorities and indifference.

XDeathwatchStarts written at 23:25:36; Add Comment

2019-06-19

How Bash decides it's being invoked through sshd and sources your .bashrc

Under normal circumstances, Bash only sources your .bashrc when it's run as an interactive non-login shell; for example, this is what the Bash manual says about startup files. Well, it is most of what the manual says, because there is an important exception, which the Bash manual describes as 'Invoked by remote shell daemon':

Bash attempts to determine when it is being run with its standard input connected to a network connection, as when executed by the remote shell daemon, usually rshd, or the secure shell daemon sshd. If Bash determines it is being run in this fashion, it reads and executes commands from ~/.bashrc, [...]

(You can tell how old this paragraph of the manual is because of how much prominence it gives to rshd. Also, note that this specific phrasing about standard input presages my discovery of when bash doesn't do this.)

As the result of recent events, I became interested in discovering exactly how Bash decides that it's being run in the form of 'ssh host command' and sources your .bashrc. There turn out to be two parts to this answer, but the summary is that if this is enabled at all, Bash will always source your .bashrc for non-interactive commands if you've logged in to a machine via SSH.

First, this feature may not even be enabled in your version of Bash, because it's a non-default configuration setting (and has been since Bash 2.05a, which is pretty old). Debian and thus Ubuntu turn this feature on, as does Fedora, but the FreeBSD machine I have access to doesn't in the version of Bash that's in its ports. Unsurprisingly, OmniOS doesn't seem to either. If you compile Bash yourself without manually changing the relevant bit of config-top.h, you'll get a version without this.

(Based on some digging, I think that Arch Linux also builds Bash without enabling this, since they don't seem to patch config-top.h. I will leave it to energetic people to check other Linuxes and other *BSDs.)

Second, how it works is actually very simple. In practice, a non-interactive Bash decides that it is being invoked by SSHD if either $SSH_CLIENT or $SSH2_CLIENT are defined in the environment. In a robotic sense this is perfectly correct, since OpenSSH's sshd puts $SSH_CLIENT in the environment when you do 'ssh host command'. In practice it is wrong, because OpenSSH sets $SSH_CLIENT all the time, including for logins. So if you use SSH to log in somewhere, $SSH_CLIENT will be set in your shell environment, and then any non-interactive Bash will decide that it should source ~/.bashrc. This includes, for example, the Bash that is run (as 'bash -c ...') to execute commands when you have a Makefile that has explicitly set 'SHELL=/bin/bash', as Makefiles that are created by the GNU autoconfigure system tend to do.

As a result, if you have ancient historical things in a .bashrc, for example clearing the screen on exit, then surprise, those things will happen for every command that make runs. This may not make you happy. For situations like Makefiles that explicitly set 'SHELL=/bin/bash', this can happen even if you don't use Bash as your login shell and haven't had anything to do with it for years.

(Of course it also happens if you have perfectly modern things there and expect that they won't get invoked for non-interactive shells, and you do use Bash as your login shell. But if you use Bash as your login shell, you're more likely to notice this issue, because routine ordinary activities like 'ssh host command' or 'rsync host:/something .' are more likely to fail, or at least do additional odd things.)

PS: This October 2001 comment in variables.c sort of suggests why support for this feature is now an opt-in thing.

PPS: If you want to see if your version of Bash has this enabled, the simple way to tell is to run strings on the binary and see if the embedded strings include 'SSH_CLIENT'. Eg:

; /etc/fedora-release 
Fedora release 29 (Twenty Nine)
; strings -a /usr/bin/bash | fgrep SSH_CLIENT
SSH_CLIENT

So the Fedora 29 version does have this somewhat dubious feature enabled. Perhaps Debian and Fedora feel stuck with it due to very long-going backwards compatibility, where people would be upset if Bash stopped doing this in some new Debian or Fedora release.

Sidebar: The actual code involved

The code for this can currently be found in run_startup_files in shell.c:

  /* get the rshd/sshd case out of the way first. */
  if (interactive_shell == 0 && no_rc == 0 && login_shell == 0 &&
      act_like_sh == 0 && command_execution_string)
    {
#ifdef SSH_SOURCE_BASHRC
      run_by_ssh = (find_variable ("SSH_CLIENT") != (SHELL_VAR *)0) ||
                   (find_variable ("SSH2_CLIENT") != (SHELL_VAR *)0);
#else
      run_by_ssh = 0;
#endif

[...]

Here we can see that the current Bash source code is entirely aware that no one uses rshd any more, among other things.

BashDetectRemoteInvocation written at 22:50:11; Add Comment

2019-06-02

I haven't customized my Vim setup and I'm not sure I should try to (yet)

I was recently reading At least one Vim trick you might not know (via). In passing, the article divides Vim users (and its tips) into purists, who deliberately use Vim with minimal configuration, and exobrains, who "stuff Vim full of plugins, functions, and homebrew mappings". All of this is to say that currently, as a Vim user I am a non-exobrain; I use Vim with minimal customization (although not none).

This is not because I am a deliberate purist. Instead, it's partly because I've so far perceived the universe of Vim customizations as a daunting and complex place that seems like too much work to explore when my Vim (in its current state) works well enough for me. Well, that's not entirely true. I'm also aware that I could improve my Vim experience with more knowledge and use of Vim's own built in features. Trying to add customizations to Vim when I haven't even mastered its relative basics doesn't seem like a smart idea, and it also seems like I'd make bad decisions about what to customize and how.

(Part of the dauntingness is that in my casual reading, there seem to be several different ways to manage and maintain Vim plugins. I don't know enough to pick the right one, or even evaluate which one is more popular or better.)

There are probably Vim customizations and plugins that could improve various aspects of my Vim experience. But finding them starts with the most difficult part, which is understanding what I actually want from my Vim experience and what sort of additions would clash with it. The way I've traditionally used Vim is that I treat it as a 'transparent' editor, one where my interest is in getting words (and sometimes code) down on the screen. In theory, a good change would be something that increases this transparency, that deals with some aspect of editing that currently breaks me out of the flow and makes me think about mechanics.

(I think that the most obvious candidate for this would be some sort of optional smart indentation for code and annoying things like YAML files. I don't want smart indentation all of the time, but putting the cursor in the right place by default is a great use of a computer, assuming that you can make it work well inside Vim's model.)

Of course the other advantage of mostly avoiding customizing my Vim experience is that it preserves a number of the advantages that make Vim a good sysadmin's editor. I edit files with Vim in a lot of different contexts, and it's useful if these all behave pretty much the same. And of course getting better at core Vim improves things for me in all of these environments, since core Vim is everywhere. Even if I someday start customizing my main personal Vim with extra things to make it nicer, focusing on core Vim until I think I have all of the basics I care about down is more generally useful right now.

(As an illustration of this, one little bit of core Vim that I've been finding more and more convenient as I remember it more is the Ctrl-A and Ctrl-X commands to increment and decrement numbers in the text. This is somewhat a peculiarity of our environment, but it comes up surprisingly often. And this works everywhere.)

PS: Emacs is not entirely simpler than Vim here as far as customization go, but I have a longer history with customizing Emacs than I do with Vim. And it does seem like Emacs has their package ecology fairly nailed down, based on my investigations from a while back for code editing.

VimMinimalCustomization written at 00:23:58; Add Comment

By day for June 2019: 2 19 26 30; before June; after June.

Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.