Hacker News Reader

> XDG comes from the GNOME and KDE crowd, meaning Red Hat/IBM, Trolltech, and maybe Canonical or a few other token companies. Notice the complete lack of real community input or control?

You're completely erasing the community involvement in KDE and GNOME. Moreover, it's grassroots that push utilities to follow the basedir-spec.

> Three, kind of a nitpick, but they adopted the Contributor Covenant CoC which is problematic for people who respect compartmentalization of social spheres. I don't care if there's a dipshit bigot on a dev team as long as he or she keeps it out of the work environment.

Again a misrepresentation. The CoC says to be tolerant of all contributors, and not doxx folks. Hardly burdensome. These are rules which nobody would ban an eyelid in a professional context.

> You're completely erasing the community involvement in KDE and GNOME. Moreover, it's grassroots that push utilities to follow the basedir-spec.

What community involvement in KDE and GNOME? The GNOME guys tend to be dismissive of anything not fitting into their grand vision. I'm not sure what distinction you're trying to make on the grassroots comment. If a project has a majority of paid devs on it, it's de facto controlled by a company. The users don't really have a choice or an influence in those two projects.

They also don't have a choice if a bunch of people come together to force their idea of proper standards on the greater ecosystem. It's simply toxic social behavior.

> Again a misrepresentation. The CoC says to be tolerant of all contributors, and not doxx folks. Hardly burdensome. These are rules which nobody would ban an eyelid in a professional context.

Firstly, not a misrepresentation:

> This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.

Look at that little wiggle room -- when you're representing the project. When does that apply? Who decides that? What's stopping FD.o and other CC CoC consumers from declaring that all contributors represent the project at all times?

This precise verbiage has been used to cause ruckus and harass people, because there are different customs and expectations between contributors as to where the line is on when you are representing the project.

Morally speaking, a project has little justification for punishing or ousting a contributor for any conduct that occurs outside of its infrastructure or community.

I don't care what the professional context is. That's another word and concept that means different things to different people, and is better used as a bat to shame people with than to form any reasonable standards of behavior that respect personal liberties and variety of expression. "Professional" people care far more about appearances and prefer to deliver their poison in etiquette-approved containers.

How often does one see behavior or words labeled as "unprofessional", without any logical or rhetorical backing? Personally, I see it every time it's accused.

I'm interested in reading about any community-driven features or standards that XDG has collaborated with the community on in good faith. i.e. something that was added without the need for a company to sponsor or approve it.

Your criticisms of XDG are criticisms of the process used to build the solution, not the solution itself.

This is particularly strange in light of number 3, which basically says "I don't care about process; only the final result".

I think both are worthy of criticism. No project out there is able to separate technical and social concerns, any more than you can separate the logical and emotional parts of a person. Every project has social and technical standards. It's the pure focusing on one or another that skews peoples values on making software.

I am against the solution because it requires yet more environment variables that need setting if you don't want a bunch of Windows-looking folders in your $HOME.

There are a great many things 'well-intentioned' in this world. I'm simply less convinced and more aloof to efforts that steer the way we compute.

The article and discussion have already shown that even proponents or adherants to XDG can't decide where things go. Data and cache get used interchangeably, and if I or a group of hackers want to improve or influence the standard, we will be stopped by the big desktop makers.

Usually, adopting standards comes with great benefits for everyone. The big guns win control if we capitulate to their way of building software.

I honestly see little reason we can't have competing 'standards' on file paths. That practice would encourage software to simply make its config path changeable at runtime.

There are too many people trying to turn GNU/Linux into one monolithic thing that's the same for everyone, and that defeats the moral point of free software. If I was required to follow these standards to get my software into a distro, I'd have moved on a long time ago.

The 'problem' with freedom is it lets you keep the pieces if things break. What you do with the pieces -- lean to XDG, switch OSes, make your own hierarchy -- is up to you.

Maybe the culture and community needs to be forked. There's clearly a group of hackers that loves bureaucracy and consensus before code is written, and another that doesn't really care for either of those things.

If others choose to look solely at the technical, then they will be led on like fools by the socially-targeting people, who aren't just looking to solve technical problems.

So what was the point of claiming I have no problem with the solution when I've not communicated that?

Wrt point 3, it's how one is supposed to act while in a group. You don't know them outside of the group, and it's none of your business what they do outside of the group. Some may claim that's overly tolerant, but in my opinion if a bigot behaves while working, it shows they know their ideas are unpopular and they have the tact and decorum to not bring it up. How they act outside the group is not up to the group.

> It's the same social approach that PulseAudio and systemd used.

To the people not getting that reference: Check out who is the third-listed author's name https://specifications.freedesktop.org/basedir-spec/latest/

Indeed that is part of the concern. Lennart was an influential person while at Red Hat. When you see the same few people coalescing around 'standards' forming and everything they peddle happens to involve them or be written by them...

The guy works at Microsoft now. That ought to tell you where his values were for free software this whole time.

> I have sidestepped the issue (in my mind) by putting all personal files in a `~/me` subdirectory, and create symlinks in `$HOME` to point to the relevant files in `$HOME/me`. It keeps things separate, and anything that's put inside an XDG folder that I want to hold onto can be migrated to ~/me and symlinked. I keep a short bash script that I use to (re)create the symlinks for me, as needed.

You or interested readers could use GNU stow to do that.

https://www.gnu.org/software/stow/

It's interesting, Stow is great if you're symlinking single locations to many symlinks, or merging directories, but I had a hard time generating stand-alone, relative symlinks in $HOME with stow that didn't also mess with things in other ways.

I use Stow myself to source music files from multiple root directories, it's a great piece of software that I simply could not wrangle to pull off what I was after.

Here's a link to the hacky script: https://git.zlg.space/linkfarm/tree/linkfarm.sh

Thanks for mentioning Stow, though; it doesn't get enough love and if you're smart with it, you can do some crazy things that, manually, would take hours or days.

> XDG comes from the GNOME and KDE crowd, meaning Red Hat/IBM, Trolltech, and maybe Canonical or a few other token companies

Trolltech has very little control over KDE. KDE is about as decentralized as they come.