Unfortunately the XSettings freedesktop spec is trash and hasn’t been released let alone revised since 2001
this post was submitted on 16 May 2025
95 points (90.6% liked)
Linux
54505 readers
640 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 6 years ago
MODERATORS
This is not a legitimate issue. It’s like complaining that wget
reads proxy settings from /etc/wgetrc. It’s absolutely proper for
programs to read system- or user-level configuration if the
configuration is not specified via environment variables or command
line options.
The typical setting hierarchy goes something like:
- command line options,
- environment variables,
- user-level configuration files and finally
- system-level configuration files.
Before any commenter rushes to condemn the Chaos That Is Linux, please check out OP's posting history to get a clearer picture of their credibility.
(and like they themselves stated, this is a rant and not a PSA)
I don't think it's wrong to bitch about the standards fragmentation in linux. For better or worse, it's a serious issue within linux. Apple, for example has a closed ecosystem which is bad, but they have great ecosystem cohesion which is great for app development and reliable interaction between applications. IMO the cohesion to standards is one of the only good things iOS has going for it.
I am not sure whos advocate i am being here but theres class of vibe coding enthusiasts that get heavily demotivated by being told to do things a certain way.
The trade of for this chaos is. At least they how to code and participate in open source projects and once in a full moon some creative actually designs something nova and inspiring.
Follow the guidelines as mentioned in freedesktop
Which guidelines are you talking about? Searching for "proxy" and "environment variables" didn't pull up anything I saw that would be relevant in this case. I've been using linux for a couple of decades now and I'm not sure what rule is being broken here.
It sounds like you didn't have a proxy set in your environment variables, but you did have one set through another means. It's somewhat standard practice to have fall-through settings, where if settings aren't set in one place, a program looks in another place, then maybe another, etc. Now admittedly it would be nice to have a way to disable functionality entirely, but usually that kind of thing happens with command line flags.
I get that it's frustrating to deal with a problem like this, but ultimately your environment was misconfigured, and that's going to break some software.
Firstly, I agree with your main point.
Just an open thought: I wonder if zscalar are using settings in a heirarchy, ie if no env var is set, then check Gnome - just in case the user's only making changes there...? Dunno...
That is a good point. But I remember launching the application from the terminal where I explicitly set the env variables as null. Still it didn't work.
That's kindof the opposite of what the previous commenter said. Have you tried explicitely setting the env var to a value different than what's in gsettings?
What env var are we talking about btw?
And what freedesktop spec? AFAIK they do not deal much in env vars apart from XDG_*
It's very annoying that the community hasn't standardized on an approach for proxy settings.
In my university (where we used proxy), we had a saying "it's always ~~DNS~~ proxy"
I hear your frustration. It can be annoying. There's a reason for it, and that's because environment variables are limited in their use by scoping: they're only inherited from the parent to children, and they're pass-by-value. This means that, from a child process, you can't influence the variables for any other sibling, or the parent. There's no way to propagate environment variables to anyone except new children you fork.
This is a significant limitation. There is no work around using only environment variables. It's a large part of why applications store scalar values in files: it's (almost) the only environmentally agnostic way to propagate information to other processes.
Herbstluftwm has herbstclient getenv and setenv, because ostensibly every user process is a child of the window manager, and it's a convenient way to communicate scalar changes between processes. tmux has similar commands; in both cases, the source of truth is the parent application, not the environment. gsettings is just Gnome's version; KDE has it's own version. I'd be surprised if Sway didn't.
Environment variables are great, but they're limited, and they are simply unsuitable for purposes. They're also insecure: anyone with the right permissions can read them from /proc. The consequence is that it can be difficult to track down where settings are stored, especially if you're still using some component of a desktop, which tend to manage all of their settings internally.
We do have a global solution for Linux: the kernel keyring. It's secure, and global. It is not, however, automatically persisted, although desktops could easily persist and restore values from the keyring when they shut down or start up. Every desktop I know just keeps it's own version of what's essentially the Windows registry.
It's a mess.
TY for mentioning/explaining scoping.
This is not a distro-specific thing, but a desktop-specific one. It was probably written for Gnome primarily.
Not sure how other software that reads this setting handles it, but imo doing it correctly it should only look at it if the current desktop is Gnome. Plasma has a setting like this too, which probably works similarly.