LWN.net Weekly Edition for December 22, 2016

GNOME, Wayland, and environment variables

Your editor, who is normally not overly worried about operating-system upgrades, approached the Fedora 25 transition on his laptop with a fair amount of trepidation. This is the release that switches to using Wayland by default, pushing aside the X.org server we have been using for decades. Such a transition is bound to bring surprises, but the biggest surprise this time around was just how little breakage there is. There is one exception, though, that brings back some old questions about how GNOME is developed.

The problematic change is simple enough to understand. While X sessions are started by way of a login shell in Fedora (even though the user never sees that shell directly), Wayland sessions do not involve a shell at all. As a result, the user's .bash_profile and .bashrc files (or whichever initialization files their shell uses) are not read. The place where this omission is most readily noticed is in the definition of environment variables. Many applications will change their behavior based on configuration stored in the environment; all of that configuration vanishes under Wayland. It also seems that some users (xterm holdouts, for example) still run applications that use the old X resources configuration mechanism. Resources are normally set by running xrdb at login time; once again, that doesn't happen if no login shell is run.

In your editor's case, this issue manifested itself in commands that should have been in $PATH not being found, and other programs misbehaving because the necessary environment variable definitions were not present. Commands run from a terminal emulator window work well enough (assuming the necessary definitions are in .bashrc rather than .bash_profile), but anything run directly from the session manager does not. Irritation ensues.

This particular problem, it seems, is not a surprise to anybody except those of us who update Fedora without reading the "common bugs" list first. It was first reported to the GNOME developers in 2014. Since then, discussion of the issue has gone back and forth, but no fix has been applied.

There's no end of possible ways to work around or fix this particular issue. One can, for example, make a simple tweak to the gnome-session script to cause it to run the user's shell of choice as part of starting up the session. This fix has not been applied, though, and it is not clear what solution the GNOME project will choose, if any, in the end.

The problem, it seems, is that shells and environment variables (not to mention xrdb) are seen as how our grandparents ran their computers. If one deals only with graphical applications, there is almost no scope for a shell to make an appearance at all, so it seems strange, to some, to involve the shell at login time. Environment variable definitions in shell startup files have been a common Unix customization method since the earliest days but, evidently, there is no easy place for that method in 2016.

So what should replace it? The conversation in the bug report covers a number of possibilities. Environment variables can be defined in a file added to /usr/share/gdm/env.d, but that, of course, requires privilege and sets those variables globally for all users. The pam_env authentication module can read variables from ~/.pam_environment, but only if the module is given the user_readenv=1 option — which is not the case on Fedora. The syntax of that file is also charmingly described as "a bit icky" in the discussion. One can run commands at startup by putting together a "desktop file"; that would be useful for commands like xrdb but not for the setting of environment variables, and even xrdb is tricky because it may not set the relevant resources before the applications using those resources are started.

Yet another approach is, naturally enough, to solve the problem in systemd. Red Hat's Ray Strode has put forward patches that do this by creating a new ~/.config/environment.d directory to hold user-specific environment-variable definitions. That takes the shell out of the picture, reducing flexibility, but it does solve the problem that (probably) affects the most users. The discussion on that patch set is long, and it touches on some legitimate security concerns. There may be an eventual solution in this direction, but no such thing has been merged into systemd as of this writing.

That leaves an increasing number of Fedora users, many of whom, it might be guessed, will not peruse the bug list before upgrading, who will run into this problem. Strode, for all that he wants to move on to a "modern" solution for environment variables, is clearly feeling the pressure that comes from wider exposure of a broken system. Thus, his most recent comment on the bug, as of this writing, reads: "Yea, I'm considering caving on this." So Fedora 25 is likely to see an update that restores the login shell to the login process; a "proper fix" will wait for later.

It is easy to write this episode off as another example of the GNOME developers happily breaking setups that have worked for years in the pursuit of some vision of a better way of doing things. And there is some truth to that. But there may also be truth to the idea that the mechanism used to customize the environment decades ago may no longer be ideal. Evolving the system toward a current understanding of the best and most secure approach makes a lot of sense. But it would be nice if we could get there without breaking large numbers of desktop setups.

That said, it's worth pointing out that the move to Wayland is a huge transition; we are moving away from a display manager that has been in place since before Linus Torvalds got his first computer. If that move brings about a seemingly unnecessary bit of breakage, we are surely entitled to grumble about it. But if that is all that goes wrong (and it seems that little else has gone wrong) then, once we've gotten the grumbling out of our system, we should recognize that such an easy change doesn't happen by chance. A lot of effort has gone into layers like XWayland and at the distribution level to keep applications working; that effort should be recognized and appreciated. A few glitches notwithstanding, this would appear to be a job well done.

Comments (68 posted)

A 2016 retrospective

This is the final LWN Weekly Edition for 2016; we will, as usual, not publish in the final week of the year. Over the many years that LWN has been in operation, we have developed a quaint tradition of using this last edition to look back over the year that has passed and, in particular, to poke fun at the predictions we made back in January. So, without further ado, it is time to look at what seemed plausible twelve months ago.

What was predicted

The first prediction was that GPL enforcement would become a hotter topic in 2016. That certainly happened, though the filing of another high-profile infringement suit, also predicted, did not. Indeed, rather than filing more suits, the community spent a lot of time talking about when we should not go to court. The disclosure of the McHardy lawsuits drew attention to one way in which things can go wrong, while the dismissal (for now) of the infringement suit against VMware highlighted a different sort of hazard. The extensive discussion before the Kernel Summit raised questions about the desirability of litigation in almost all situations. The community as a whole remains unhappy about the extent to which the GPL seems to be ignored with impunity, but there is little consensus on what we should do about it.

There is little evidence that the predicted increase in corporate comfort with the GPL has actually come to pass. If anything, rumors about the McHardy lawsuits and loud calls for more litigation have pushed things in the other direction.

Your editor bravely predicted that attempts to create new, relatively free mobile devices would continue, but cravenly (or, one might say, wisely) said nothing about how successful those efforts would be. We have seen some efforts, such as CopperheadOS, show up during the year. But, as the discouraging news from Cyanogen Inc. shows, this is a hard business to try to succeed in. Until such a time as freedom and security become important points to mainstream device buyers, opportunities are likely to be hard to find and exploit.

The prediction that the year-2038 problem would be mostly solved by the end of the year can be best described as aligning poorly with reality. It was already joyfully mocked at the 2016 Kernel Summit, and perhaps can be allowed to fade slowly into obscurity now. Work is continuing on solving this problem, and there is little danger of a last-minute panic like we saw in 1999, but it feels like some of the urgency has gone out of the efforts in this area.

We heard a lot about blockchains, just like the (obvious) prediction said. The announcement that Apache Software Foundation founder Brian Behlendorf would be heading up the Linux Foundation's "Hyperledger" project is an obvious example. Blockchains were big news, but they have not, yet, transformed the world.

Did the development community begin to act seriously on security, as predicted in January? The answer would have to be a cautious "yes". The kernel hardening efforts have made some progress, we are seeing more focused fuzz-testing of software at all levels, and so on. The seriousness and effectiveness of these efforts is subject to a certain amount of debate, but we are trying to do better. That said, all the evidence suggests that we need to be trying rather harder still.

Your editor predicted a continuation of efforts to ban robust encryption. That may have happened, but they didn't get far in much of the world. Instead, it seems clear that, most of the time, our systems are so vulnerable that encryption tends not to be a big problem for anybody wanting access to our data. That said, one would be wise to keep an eye on the incoming administration in the US, which may yet try to pursue such an agenda.

We predicted that there would be more attention paid to hidden antifeatures in embedded systems. Occasional events, such as the revelation that Nook tablets come complete with pre-installed spyware, raise eyebrows. There was some brief unhappiness about the bricking of Revolv hubs, and there may be more if, as suggested, Pebble smartwatches soon see a centrally imposed "reduction in functionality." But much of the world still seems to pay little attention to such problems.

The prediction that the 4.9 kernel would come out on November 27 was off by two weeks — the actual release happened on December 11. That may look pretty good to those of us who remember the times when it hard to predict which year the next kernel release would happen in, but it could have been better. In truth, the trend toward shorter kernel release cycles ended in 2016. Of the six kernels released this year, four required 70 days for their development cycle, while only 4.5 and 4.6 were done in 63 days.

The final prediction was that non-volatile memory devices would make their presence felt. Something that vague must surely come true in some way. These devices are motivating a lot of changes deep down in the kernel, where the age-old assumption that I/O is devastatingly slow becomes increasingly unwarranted. But there are still relatively few of us who have such devices in hand.

What was not

One thing that your editor should probably have predicted was the increase in the importance of software distribution channels that bypass the traditional Linux distributors. These channels can be language-specific (such as the venerable CPAN), run by a specific project for its own software (the controversy over ownCloud packaging was covered in the same edition that carried the 2016 predictions), tied to container systems like Docker or rkt, or relatively new mechanisms like Flatpak. The role of distributors is changing. Whether that is a good thing remains to be seen; distributors are an important advocate for their users, and we may well find that we miss that role in our new, disintermediated future.

Back in 2001, Microsoft's CEO described Linux as "a cancer that attaches itself in an intellectual property sense to everything it touches". The company's position toward Linux has been changing since then, and perhaps it should have been possible to foresee that 2016 would be the year that Microsoft joined the Linux Foundation — and as a platinum member at that. One might think that the company's conversion to open-source friendliness is complete but, by all accounts, its ongoing software patent activity says that there is still some work to be done.

In 2012, your editor predicted that LibreOffice would leave OpenOffice (which had been recently dumped into the Apache Software Foundation) in the dust. That prediction was accounted as a failure at the end of the year. Four years later, though, it has become clear that that is exactly what has happened. Your editor happily takes credit for having been a bit ahead of his time, while pointing to something shiny to distract you all from the fact that he didn't see the issue coming to a head in 2016.

Until next year...

One other thing your editor failed to predict was the departure of LWN editor Nathan Willis, who is off pursuing other interests. The search for a replacement has proved to be harder than expected and is still underway; we still have an open position and would be most interested in hearing from anybody who would like to write for our exacting readers. We do hope to get back to full strength — and possibly beyond — not too far into next year.

Even though we have been short-handed for the last few months, we have managed to put out 464 feature articles over the course of the year; 91 of those were written by outside authors. Our 2016 conference coverage has articles from 28 separate events. We also ended up replacing an important part of our server infrastructure between deadlines. All told, we have stayed busy and gotten a lot done this year.

The reason we are able to do that, of course, is that we have a dedicated and generous reader base that has been willing to support us for the long haul. LWN will celebrate its 19th birthday in just under one month, and, sometimes, it still feels like we're just getting started. Let us finish the year by expressing our thanks to all of you; we wouldn't be here without you. The best holiday wishes from all of us at LWN, and we'll see you back here early next year.

Comments (8 posted)