GNOME, Wayland, and environment variables [LWN.net]

By Jonathan Corbet
December 21, 2016

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.

to post comments

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 3:42 UTC (Thu) by neilbrown (subscriber, #359) [Link] (8 responses)

https://opensource.com/article/16/12/yearbook-9-lessons-2...
Lesson 5.

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 12:55 UTC (Thu) by em (subscriber, #91304) [Link]

To be fair the kernel has the huge advantages of having almost no dependencies and of being quite far from the end user, which helps a lot in defining rules like that. :)

GNOME, Wayland, and environment variables

Posted Dec 23, 2016 10:08 UTC (Fri) by liam (guest, #84133) [Link] (6 responses)

Good point, but hard to do with such a user facing product. Especially one where you can choose how you wish to define regression ("that's not a bug, it's part of the designers vision").

GNOME, Wayland, and environment variables

Posted Dec 23, 2016 22:23 UTC (Fri) by jani (subscriber, #74547) [Link]

https://xkcd.com/1172/

GNOME, Wayland, and environment variables

Posted Dec 23, 2016 23:58 UTC (Fri) by neilbrown (subscriber, #359) [Link] (4 responses)

> Good point, but hard to do with such a user facing product.

The kernel is a user-facing product too, though it has a different set of users.

> Especially one where you can choose how you wish to define regression ("that's not a bug, it's part of the designers vision").

It's a bug if I notice a reduction in functionality before I'm told about it. I certainly agree that forward progress is important, and that sometimes means breaking things that used to work. We do that in the kernel too, but we make sure people don't notice or don't care. We provide an alternate solution, encourage people to use the alternate solution, fix any bugs or other issues that arise for people using the alternate solution. Then, after the alternate solution has been in use for a while, in all major distros, and people are happy with it, we remove the old legacy support. And nobody notices (or if they notice, they don't care).

In this case, assuming the article is accurate (which I don't doubt), there wasn't just a lack of a transition period, there was no alternate solution *at* *all*.

GNOME, Wayland, and environment variables

Posted Dec 27, 2016 10:16 UTC (Tue) by ovitters (guest, #27950) [Link] (3 responses)

> there was no alternate solution *at* *all*.

Wayland sessions aren't started via a shell. As such, there wasn't a reduction in functionality. Moreover, a shell is still used for X11 so there's no reduction in functionality in that. If you compare an X11 session with a Wayland session, things work differently; but then that already gives away that there's a clear alternative.

GNOME, Wayland, and environment variables

Posted Dec 27, 2016 23:15 UTC (Tue) by roc (subscriber, #30627) [Link] (2 responses)

When Fedora 25 switched from X11 to Wayland by default, stuff broke. That's a regression and it doesn't matter to the affected users which part of the system was responsible.

GNOME, Wayland, and environment variables

Posted Dec 28, 2016 16:38 UTC (Wed) by ovitters (guest, #27950) [Link] (1 responses)

You're changing goal posts. I clearly quoted that someone complained about the lack of an alternative. There _is_ an alternative. Aside form the goal post change, I never claimed that behavioural change is good or acceptable because there's an alternative.

I do find the whole discussion of environment variables limited; not every distribution starts/started GNOME in this way. I wouldn't call this a breakage. There are various bugs which need to be fixed. E.g. "hanging" control and letters. There's an actual breakage in not being able to start something as root.

GNOME, Wayland, and environment variables

Posted Dec 29, 2016 17:29 UTC (Thu) by johannbg (guest, #65743) [Link]

"There's an actual breakage in not being able to start something as root."

Well ain't the fundamental flaw here that you have to or need to be starting something as root in the first place.

What is your usecase having to start something as root in the first place?

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 5:45 UTC (Thu) by grawity (subscriber, #80596) [Link] (1 responses)

I suspect one of the reasons just patching gnome-session isn't enough is that it would still have to manually push that environment to systemd --user and dbus-daemon,

But, for that matter, my own reasons for preferring a PAM module date a good decade before systemd. One of my *biggest* gripes regarding Lunix has always been the lack of truly account-wide environment setting – the exact same problem has existed in sshd and cron for many years before systemd even existed. Want your cronjobs to see your $PATH? Manually source .profile in every damn one of them. Want "ssh myhost myapp" to pick up the same? Now you have to use "ssh myhost '. ~/.profile && myapp'". Isn't that the most convenient thing ever.

(Before you rush to compose a reply saying that "ssh myhost env" has always worked fine for you – well, yes, that's true as long as your default shell is bash *and* it has the right compile-time options set. So as I've found out the hard way, it's not only dependent on the shell on the server, it even depends on which distro it runs on!)

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 7:57 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

To source variables from a cron job, chroot, Docker startup file etc. I just pass -l flag to the shell when executing command or in the #! headers. It works at least with bash and dash.

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 6:27 UTC (Thu) by eru (subscriber, #2753) [Link] (5 responses)

Well, they could always copy Windows here: There is an obscure dialog box somewhere under Control Panel->System, where you can set "system variables" (if you have admin rights), and "user variables" that apply only to your processes. Naturally modifiable only via a small, non-resizable text field. Great fun for long values like PATH.

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 6:58 UTC (Thu) by shruggy (guest, #94695) [Link] (4 responses)

TBH, they changed it in Windows 10, at last. It's not "a small, non-resizable text field" anymore, but a list with each PATH element on its own line.

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 7:28 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

That was annoying, but fixable by using an external editor. Did they fix the problem where the dialog needs Administrator rights, but then you end up editing the user variables of the Administrator you elevated to rather than your own, leaving you no way to do it using that dialog for non-privileged users?

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 11:59 UTC (Thu) by peter-b (guest, #66996) [Link]

No, they didn't fix it. You'll need to use PowerShell (posh) to set persistent per-user environment variables:

> [Environment]::SetEnvironmentVariable("TestVariable", "Test value.", "User")

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 17:50 UTC (Thu) by zlynx (guest, #2285) [Link] (1 responses)

I don't think I've ever run into that one. I would have to assume you're running with non-standard settings, like UAC disabled, or as a limited user account.

Running limited user accounts requires a _lot_ of detailed Windows administrator knowledge.

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 22:03 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Yeah, it's a non-admin user. It's the account that our buildbots build and run tests on, so running as a limited user is preferred.

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 7:10 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (4 responses)

I'm not a fan of macOS-style dedicated environment initialization files. In addition to being brittle (What if I want an environment that varies by time of day or by machine?), environment files are single-purpose and don't allow me to do things like set resource limits or ad-hoc execution wrappers. Performance shouldn't matter either: the shell can be made very fast.

I'm a fan of Turing-complete configuration languages generally. The shell gives users unlimited power. I'd prefer not reducing this power for the sake of elegance.

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 12:12 UTC (Thu) by ovitters (guest, #27950) [Link] (1 responses)

That's a side-effect as previously a shell was _usually_ used to start the session. There's been various bugreports in the past where some distribution did not use such a shell, leading to questions why GNOME didn't parse ~/.bash_*. I assume eventually all those distributions switched to starting the session via a shell. For me there's not much of a problem as I only want specific things for when I work in a terminal and that (of course) works fine.

It seems you can tweak things to get the session started via a shell. The next GNOME will allow the desktop icons setting to work again. Hopefully a solution for the environment variables can be found as well. This all together with mpv window size sometimes being super tiny (my biggest annoyance!)

GNOME, Wayland, and environment variables

Posted Dec 23, 2016 13:55 UTC (Fri) by Felix (subscriber, #36445) [Link]

> The next GNOME will allow the desktop icons setting to work again.

Assuming you mean "desktop icons on Wayland" then it is already available in GNOME 3.22 (e.g. Fedora 25) as the workaround was backported (it's just a one-liner).

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 17:37 UTC (Thu) by k3ninho (subscriber, #50375) [Link] (1 responses)

>I'm a fan of Turing-complete configuration languages generally. The shell gives users unlimited power. I'd prefer not reducing this power for the sake of elegance.

The alternative is domain-specific languages with clear workflows for their use, tied to the problem that they're trying to solve . These have advantages in terms of complexity which has you trading a lower exposed attack surface and lower maintenance costs for (intentionally) limited ability to express yourself and a higher-than-usual need for good documentation/training.

K3n.

GNOME, Wayland, and environment variables

Posted Dec 29, 2016 13:35 UTC (Thu) by phred14 (guest, #60633) [Link]

I have a pet belief that every domain-specific language aspires to be Turing-complete, and is eventually extended to get there. With that end-point in mind, you're just better off starting with something Turing-complete in the first place. Yes, there may be security issues, but the end result may be better from realizing all of that in the first place and taking appropriate action (restricted shells, etc) than from a whole stack of incremental Turing-inspired extensions.

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 8:06 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

That trick from bug's comment https://bugzilla.gnome.org/show_bug.cgi?id=736660#c49 does not work on Fedora as gnome-session is run to show the login dialog when $SHELL is /bin/nologin. The simplest solution for those who stick with bash as their shell is to replace #!/bin/sh on the first line of /usr/bin/gnome-session with:

#!/bin/bash -l

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 10:40 UTC (Thu) by SLi (subscriber, #53131) [Link]

I don't know if the problem is the use of environment variables or the way they're inherited, but the current model does cause seemingly unnecessary pain in many situations when using shells. For example, consider the fact that a screen or tmux session inherit the DISPLAY environment variable that screen had when started (or, at best, it could inherit the value the resuming screen session had at the time the window was created). This clearly can lead to using an incorrect DISPLAY, when apart from the current model there seems to be no good reason why the current DISPLAY (where screen or tmux was resumed) could not be used. I have seen a few usually terrible hacks around this, but they invariably have interesting faillure modes and are just that, hacks around a design problem.

Wayland breakage

Posted Dec 22, 2016 10:57 UTC (Thu) by Seegras (guest, #20463) [Link] (15 responses)

There are some more problematic things with Wayland

- Primary Selection. (cut & paste via mouse alone): This seems to be nonexistent, but apparently has been reimplemented on the compositor/window manager level within mutter. No idea whether this works in non-gnome applications, and from/to applications running under Wayland and XWayland. And no idea whether this work under any other compositor/window manager other than mutter.

- Sloppy focus and autoraise. This might be a problem on the compositor/window manager level alone. It's clear that this won't work with "Unity" or other global-menu-style desktop environments, but depending on which supports what, you might end up with only half the features you need.

- Accelerated 3D graphics not working with proprietary drivers.

- Preferred window manager (or even window managing paradigm) not available.

Of course, they're probably not exactly problems of Wayland itself, but of other components. Still, for people to work with it, these have to be fixed.

Wayland breakage

Posted Dec 22, 2016 12:02 UTC (Thu) by ovitters (guest, #27950) [Link] (8 responses)

The middle button mouse works under GNOME 3.22. Exactly where this is done I don't care about. It works for me. If it doesn't work for Qt then it should be made to work for Qt as well.

Within Mageia they keep trying to ensure that everything works in the 10+ window manager / desktop environments they package. Thereby often adding hacks, hacks upon hacks, hacks relying on poor workarounds. etc. Any problem in any of the display manager and a desktop treated as a blocker. It's just loads of bugs, hacks and no progress.

http://svnweb.mageia.org/packages/cauldron/pulseaudio/cur...

The "startgnome_classic" was a hack because some DM couldn't start GNOME classic. Instead of either fixing that DM a hack is added. Then this pulseaudio has some kind of hack, whereby that now relies on the GNOME classic hack. I'm calling this all hacks because stuff has broken before due to all of these messy things and it's pretty apparent that things will break.

The various things you list as problematic with Wayland seem not really caused by GNOME on Wayland. E.g. proprietary nvidia driver does work (unfortunately IMO), window manager already couldn't be changed, etc. Saying 'these have to be fixed', why? Window manager cannot be chosen already, nvidia does work, etc. Your list is a bit strange.

Wayland breakage

Posted Dec 22, 2016 18:49 UTC (Thu) by mgraesslin (guest, #78959) [Link] (1 responses)

> Exactly where this is done I don't care about. It works for me. If it doesn't work for Qt then it should be made to work for Qt as well.

This is a custom Wayland protocol used between GTK and GNOME-Shell. It's not yet part of wayland-protocols and thus the chances that Qt implements it are pretty low. I just looked at it this week as I got a bug report for KWin about it ;-)

If it gets added to wayland-protocols I could implement it. But custom protocols of other toolkits - that could result in a mess, so better not.

It shows that we are still in the time where things need to be standardized.

Wayland breakage

Posted Dec 23, 2016 11:02 UTC (Fri) by ovitters (guest, #27950) [Link]

> It shows that we are still in the time where things need to be standardized.

hmm, thanks for educating me. I didn't know this was a custom bit. Assume the custom protocol was done because it's way easier to test things out and use that experience to propose a good standard. Wayland is a bit opaque to me; I'm not following those mailing lists. This obviously should be a standard.

Wayland breakage

Posted Dec 22, 2016 23:23 UTC (Thu) by gutschke (subscriber, #27910) [Link] (5 responses)

It's fine for you, if you like the choices made by the built-in window manager. It's pretty much unworkable, if you rely on different options that are not available with that window manager.

I heavily rely on having a tiling window manager. I have been using "awesome" for many years now. It's customized to only offer a very limited stream lined window layout. And while I keep the old-school GNOME menu and taskbar (combined into a single bar at the top of the screen), I eliminated almost all other decoration.

Half the time, it looks as if my apps are running fullscreen without any windows at all.

This turns out to be super productive for me. I see exactly what I need to see. Nothing more and nothing less. And I can control navigation without moving my mouse from the keyboard.

This is great for a power user, but I would never expect it to become mainstream. Most users are better served by less powerful but more intuitive, verbose and self descriptive user interfaces.

Allowing a choice of window managers makes it easier to accommodate both groups of users

Wayland breakage

Posted Dec 23, 2016 0:16 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> Allowing a choice of window managers makes it easier to accommodate both groups of users

I don't think a choice of arbitrary window managers is necessary there. You can have a base that is extensible

https://extensions.gnome.org/extension/657/shelltile/

Wayland breakage

Posted Dec 23, 2016 0:31 UTC (Fri) by gutschke (subscriber, #27910) [Link] (1 responses)

I agree with you that in principle the concept is sound. And yes, you can probably achieve what I want without requiring complete freedom of choice in window managers.

In practice though, I tried various different options a while ago -- including the one that you linked to. And none of them even came close to doing what I needed. The GNOME Shell extension always felt very much like an afterthought, and at all times you could tell GNOME Shell was fighting any attempt to make such a drastic change to the windowing paradigm.

So, unless you can convince the developers to a) make tiling a first class citizen, and b) embed a rich scripting language that allows heavy modification, you'll never really replace the need for alternative window managers. I don't know enough about GNOME Shell to tell whether #b is already solved by its extension mechanism. But #a doesn't seem to be there, as far as I can see.

Wayland breakage

Posted Dec 23, 2016 0:51 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

> I don't know enough about GNOME Shell to tell whether #b is already solved by its extension mechanism. But #a doesn't seem to be there, as far as I can see.

#b might be solved in terms of the framework even if the extension I pointed to isn't suitable for your needs. I don't know that anyone has really tried.

Wayland breakage

Posted Dec 23, 2016 10:58 UTC (Fri) by ovitters (guest, #27950) [Link] (1 responses)

The window manager concept is just one solution to this. There's already a tiling compositor for Wayland: http://swaywm.org/. Further, the functionality of Weston is being put into a library. Not exactly sure what this allows, but I assume that most of the compositor logic is in this libweston, thereby reducing the complexity creating a different Wayland compositor.

Technically not really a window manager, but practically it could be.

Wayland breakage

Posted Dec 28, 2016 12:59 UTC (Wed) by daniels (subscriber, #16193) [Link]

> Not exactly sure what this allows, but I assume that most of the compositor logic is in this libweston, thereby reducing the complexity creating a different Wayland compositor.

Correct. The idea is to let people write window managers and desktop environments without having to worry about the details of DRM/KMS/GBM, EGL, dmabuf, the Wayland protocol itself, and whatever other plumbing. It's not there yet, but hopefully in the next year or so it'll become a really solid viable alternative.

Wayland breakage

Posted Dec 22, 2016 19:25 UTC (Thu) by niner (guest, #26151) [Link] (5 responses)

3D graphcis does work with AMDs proprietary drivers. It's just nvidia which doesn't support Linux all that well.

Wayland breakage

Posted Dec 24, 2016 23:17 UTC (Sat) by flussence (guest, #85566) [Link] (4 responses)

3D is only half of the problem; Wayland also throws away all the accumulated 2D wisdom in the AMD/Nouveau/Intel X drivers, and the replacement requires a fast 3D card.

It's not a problem for the first two, but Intel GPUs aren't cheap to replace when the rest of the system is soldered to them.

Wayland breakage

Posted Dec 25, 2016 8:54 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (3 responses)

This isn't even slightly true - see the compositor that was written for the Raspberry Pi, for instance, that uses its hardware compositing features to give much better performance than X on something that is certainly not a fast 3d gpu

Wayland breakage

Posted Dec 25, 2016 22:29 UTC (Sun) by flussence (guest, #85566) [Link] (2 responses)

For real? Okay, I hope Intel can get their act together so I don't have to start budgeting for replacements for half the devices my family's using but I'm glad I was wrong there.

Wayland breakage

Posted Dec 28, 2016 21:12 UTC (Wed) by tao (subscriber, #17563) [Link] (1 responses)

What exactly is it you want us to get our act together about? The i915 kernel modesetting driver supports (admittedly to a varying degree) every chipset from i830 and forward.

Wayland breakage

Posted Dec 29, 2016 0:45 UTC (Thu) by flussence (guest, #85566) [Link]

Everyone tells me xf86-video-intel is a dead end and modesetting+glamor is the way forward, but that isn't an option for the 945 or older.

The only thing keeping them from becoming landfill right now is "AccelMethod SNA", and I'm unable to find anything to suggest that it has (or will have) an equivalent in Wayland.

Environment variables = global variables

Posted Dec 22, 2016 12:33 UTC (Thu) by yaap (subscriber, #71398) [Link]

After having been bitten by environment variables (old ones once useful, forgotten, then creating odd effects ; different versions needing different settings) I now prefer using them only as "local variables": when needed I just create a wrapper script that set the needed environment for the application, and exec it. It uses a bit more CPU each time the script is run, but nowadays that's not a problem. It's also easy to create desktop files for those scripts. Each application can then have its own custom local environment, in as many versions as needed.
Now this won't solve all problems, but for desktop launched GUI apps it should work fine (at least it does for me).

GNOME, Wayland, and environment variables

Posted Dec 22, 2016 22:37 UTC (Thu) by ksandstr (guest, #60862) [Link] (1 responses)

>The problem, it seems, is that shells and environment variables (not to mention xrdb) are seen as how our grandparents ran their computers.

Perhaps the GNOME of 2016 is implemented without understanding what environment variables are and how they work. The expected outcome would be fingers crammed into ears and very loud humming on one end, and on the other, many hacks that're all worse than simply doing as before: global root-only settings, alternate NIH-tastic syntaxes, layering violations, architecture by afterthought.

If such a great big feat of ignorance is what actually happened (and not just the most consistent hypothesis), there'll certainly be other surprises undiscovered beyond the well-trodden path. However, getting one's hopes up wrt a desktop that's constantly rewriting and discarding anything that came before (including its own prior achievements) seems like a wish that, contrary to a 15 years' experience, the technological underdog will one day quit sucking ass deliberately.

GNOME, Wayland, and environment variables

Posted Dec 23, 2016 2:03 UTC (Fri) by robclark (subscriber, #74945) [Link]

> If such a great big feat of ignorance is what actually happened (and not just the most consistent hypothesis), there'll certainly be other surprises undiscovered beyond the well-trodden path. However, getting one's hopes up wrt a desktop that's constantly rewriting and discarding anything that came before (including its own prior achievements) seems like a wish that, contrary to a 15 years' experience, the technological underdog will one day quit sucking ass deliberately.

well, I mean you *could* actually read the comments in the bz linked by parent article, rather than inventing bogus theories. But what fun would that be.

GNOME, Wayland, and environment variables

Posted Dec 23, 2016 13:39 UTC (Fri) by jmclnx (guest, #72456) [Link] (2 responses)

Interesting, but I wonder how the new config (~/.config/environment.d) will interact with /etc/profile.d/ ? Right now, package specific environment variables seem to be retrieved from /etc/profile.d/ using scripts sourced during login.

GNOME, Wayland, and environment variables

Posted Dec 23, 2016 18:42 UTC (Fri) by ovitters (guest, #27950) [Link]

I assume it'll work like usual: First parse something in /usr (=distribution), then /etc (=sysadmin/host), then ~/.config. Latter overriding the previous ones.

GNOME, Wayland, and environment variables

Posted Dec 24, 2016 12:07 UTC (Sat) by Jandar (subscriber, #85683) [Link]

I hope there is a way to invoke scripts to generate dynamic content of environment variables. If these new config files only allow static content it would be a major reduction in functionality. At work my .profile adapts to different distributions, different ranges of installed software and other resources like nfs-mounts, RAM, CPUs and so on to get me the best environment. A static environment doesn't cut the mustard.

The reason why we need to create yet another way to specify environment variables eludes me. The config file parser doesn't have to be a big and slow bash (<0.01 seconds for bash -l /dev/null) it could be a leaner and quicker kind of shell. If you don't want to use the shell directly to start something the shell could dump the resulting environment variables like gcc -dM dumps defines. Even better, you can do this now: dash -l -c 'exec /usr/bin/env --null'.

This ~/.config/environment.d seems to be a solution in search of a problem. But what the heck, it could simply create a problem: inconsistent environment between GUI-login and ssh-login. In the future I have a new line in my .profile: eval `read_new_and_shiny_config --shell`.

Hopefully the Christmas presents are nicer surprises ;-)

A merry Christmas to all.

GNOME, Wayland, and environment variables

Posted Dec 24, 2016 16:48 UTC (Sat) by anton (subscriber, #25547) [Link] (7 responses)

The problem, it seems, is that shells and environment variables (not to mention xrdb) are seen as how our grandparents ran their computers.

That is the problem? These people should switch to MacOS or Windows where you get a shiny new user experience along with a need to relearn much of what you knew and which worked well (or as well as expected in this kind of setup) every few years.

I see it as a major benefit of Linux/GNU/X that I can still use the setup that I have used for 25 years, with minor changes now and then (e.g., I finally switched from using plain .Xdefaults to using xrdb a few months ago).

If they don't have a technical reason for avoiding established setup mechanisms, they should support these mechanisms. And not providing a replacement mechanism adds insult to injury.

Wikipedia tells me that Wayland does not support network transparency. Any news on that? Without network transparency it's definitely no competition to X for my uses.

GNOME, Wayland, and environment variables

Posted Dec 25, 2016 15:40 UTC (Sun) by micka (subscriber, #38720) [Link] (6 responses)

> These people should switch to MacOS or Windows where [...]

These systems won't provide the property of "being linux", though.

> If they don't have a technical reason for avoiding established setup mechanisms [...]

Well apparently the article specifies that there _are_ technical reasons.

> Wikipedia tells me that Wayland does not support network transparency. Any news on that?

I think it just waits for someone (anyone) to scratch their own itch and write this support. The way to do it is documented for anyone to do it and AFAIK it was prototyped.

GNOME, Wayland, and environment variables

Posted Dec 25, 2016 16:37 UTC (Sun) by Jandar (subscriber, #85683) [Link] (4 responses)

> Well apparently the article specifies that there _are_ technical reasons.

It may appear to you there are technical reasons given, to me it doesn't. The main reason given was:

> 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.

The "technical" reason boils down to: there are some young, dynamic and disruptive people who want something new and shiny not the old grandfatherly.

The people who have carelessly ripped out the current working system to set the environment have put no thought into a replacement. Only after bug reports are coming in they are constructing some incompatible solution.

Why?

$ time dash -l -c 'exec /usr/bin/env --null' >/tmp/env
real 0m0.009s
user 0m0.000s
sys 0m0.000s

The time to load and extract the old and working environment is negligible, even on my 9 year old desktop pc.

GNOME, Wayland, and environment variables

Posted Dec 25, 2016 22:27 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

I have a system that runs systemd+Wayland without any shell on it. It's nice to be able to do that - it reduces the attack surface and is generally interesting.

Rolling stuff back to the X11 status quo is not a problem, but it's nice to be able to experiment and see what can be done without resorting to login shells.

GNOME, Wayland, and environment variables

Posted Dec 25, 2016 23:24 UTC (Sun) by Jandar (subscriber, #85683) [Link]

Of course it's nice, even essential, to experiment and explore new ways. I'm eager waiting that openSUSE declares KDE+Wayland ready for mainstream use so I can justify using it at work.

If /etc/shells is empty, no effort to load an old shell environment is necessary. Your setup without any shell wouldn't be disturbed by loading the environment for any user whose command interpreter from /etc/passwd is found in /etc/shells.

GNOME, Wayland, and environment variables

Posted Dec 26, 2016 13:13 UTC (Mon) by anton (subscriber, #25547) [Link] (1 responses)

A system without shell is an interesting experiment, and maybe something will come out of it that somebody wants to use, like Android. It just will not be anything I (and I expect many others) will consider as continuation or replacement of our current Unix/Linux user experience, just like Android.

Concerning the reduced attack surface: You are running a complicated init system like systemd and a number of components (including Wayland) that make up the graphical part, and on top of that graphical applications, each with it's own configuration and scripting language (or several of them, e.g., HTML, CSS, and JavaScript for the web browser), and you think you have reduced the attack surface?

GNOME, Wayland, and environment variables

Posted Dec 26, 2016 16:31 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

This particular device doesn't have a browser...

Anyway, removing user-controlled shell from the boot sequence would allow to secure it a little bit more. It's one less place for persistent malware to hide or for bugs to hang the boot.

GNOME, Wayland, and environment variables

Posted Dec 25, 2016 16:44 UTC (Sun) by jem (subscriber, #24231) [Link]

Take a look at a map of Massachusetts. Start from Wayland, drive through Weston and continue east until you arrive in... Waltham!

GNOME, Wayland, and environment variables

Posted Dec 30, 2016 9:24 UTC (Fri) by sourcejedi (guest, #45153) [Link]

It would be nice if Fedora Workstation's update tool linked to the release notes & common bugs, even indirectly. And if the release notes linked to the list of common bugs. As a user upgrading to F25, I had to know that there was a list of known bugs, and really hunt for it. I wouldn't blame anyone for failing to match my own level of anxiety about such things and insist on reading them first.

GNOME, Wayland, and environment variables

Posted Jan 5, 2017 12:57 UTC (Thu) by callegar (guest, #16148) [Link] (3 responses)

I expect that the sole effect of this and other breakage of behavior/expectations is that it will slow significantly the Wayland adoption, by making it much harder to try Wayland and alternate its usage with X11, without providing any tangible benefit capable of compensating the cost of delayed adoption. Add that to the fact that X11 is still "good enough" to many users and usage scenarios, and that one major distro has a competing approach (btw, is there a login shell in it?) and be prepared to huge huge fragmentation ahead.

GNOME, Wayland, and environment variables

Posted Jan 5, 2017 17:06 UTC (Thu) by zlynx (guest, #2285) [Link] (2 responses)

I think that anyone who cares deeply about their environment variables as defined in customized shell profiles has already found one of the four or five ways to solve the problem in Wayland. It isn't particularly difficult, so I take a very small exception to your phrase "making it much harder"

GNOME, Wayland, and environment variables

Posted Jan 6, 2017 8:39 UTC (Fri) by muep (subscriber, #86754) [Link] (1 responses)

I kind of care about those, but since the X11 session is still easily available and the situation for Wayland sessions seems to be kind of complicated and changing, I am just using the X11 session for now. I might pretty quickly switch to the Wayland one, though, if I come across a mechanism for setting environment variables that fulfills these requirements:

Works with many GNU/Linux distributions. At the very least, these:
- CentOS
- Debian
- Fedora
- Ubuntu

Works with at least all of these sessions:
- Local virtual terminal
- Local X11 session
- Local Wayland session
- Remote SSH session

Works with many ways of launching applications:
- From terminal emulator
- From desktop environment launchers

The traditional way of using ${HOME}/.profile allows me to have a single file that I can reuse on various kinds of hosts. Currently it fills all of the above, except (unless my impression is outdated) Wayland sessions. If I am to switch mechanisms, it sounds like a bad deal to lose any of those other use cases just to get the Wayland use case that currently behaves almost identically to the X11 one.

But if someone can suggest a workaround that gets me all of the above with a single place to maintain common environment variables for multiple hosts I use, I'd be happy to try out the Wayland session again.

GNOME, Wayland, and environment variables

Posted Jan 6, 2017 21:51 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

It'd be pretty easy to set up a systemd user service which reads a key/value file and set environment variables in the systemd session. The wayland.target could then Requires= and After= it. And .profile could do the same in shell code.

Personally, I have units for different environment variables that get pulled in by the relevant services and then I dump the systemd --user environment to a shell script which I then source after logging in over SSH to get access to my session's environment. It'd be possible to also just have .bashrc or whatever do that work as well for SSH.

But that's assuming that Wayland is triggered through a systemd unit and not a direct startx analogue (I've converted by setup to a systemd --user session, but login managers don't use it properly, so I log in on a TTY).

GNOME, Wayland, and environment variables

Posted Jan 20, 2017 12:08 UTC (Fri) by ssokolow (guest, #94568) [Link] (5 responses)

I worry that the "proper fix" could end up being another "X11 configuration through dbus+HAL" moment.

GNOME, Wayland, and environment variables

Posted Jan 20, 2017 13:30 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (4 responses)

For me, the issue is fixed with systemd user units. I have an environment.target and x11-environment.target which are used as the interesting points for After/Before and Requires of the various service files. I'm currently using an xorg.target, but the setup would work for a wayland.target or even mir.target just as easily.

GNOME, Wayland, and environment variables

Posted Jan 21, 2017 1:16 UTC (Sat) by ssokolow (guest, #94568) [Link] (3 responses)

Oh, I'm definitely looking forward to systemd user units. (I've been too consistently busy to put up with the uncertain time requirements to upgrade from my Lubuntu/Kubuntu 14.04 LTS hybrid and then shake the inevitable regressions back out of my desktop, so I'm still on Upstart.)

I'm just worried that their official solution will be embarassingly over-engineered and ill-fitted to purpose.

GNOME, Wayland, and environment variables

Posted Jan 21, 2017 2:33 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

Why speculate when the patches have already been pushed and linked from the bug report?

GNOME, Wayland, and environment variables

Posted Jan 21, 2017 10:20 UTC (Sat) by ssokolow (guest, #94568) [Link] (1 responses)

The impression I got from the article was that the current solution is just a stop-gap until something else could be formulated.

I commented on my hopes for that "something else".

GNOME, Wayland, and environment variables

Posted Jan 21, 2017 12:45 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

The patches were posted after the article was written.

GNOME, Wayland, and environment variables

Posted Nov 7, 2017 23:13 UTC (Tue) by oconnor663 (guest, #119484) [Link] (2 responses)

It looks like systemd 233 (March 2017) did standardize on ~/.config/environment.d/*.conf. See the environment.d man page and the discussion that led to the feature on the preliminary PR linked in the article and the followup PR that ultimately landed.

GNOME, Wayland, and environment variables

Posted Nov 9, 2017 16:45 UTC (Thu) by nix (subscriber, #2304) [Link]

And since the thing is read by a generator, if you need computationally-generated environment variables it is trivial to do so (and the manpage has multiple examples of just that).

GNOME, Wayland, and environment variables

Posted Nov 9, 2017 18:24 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Huh, neat. Now I can remove my foo-env.service units it seems :) . It seems that the environment is rebuilt from scratch on every daemon-reload too.