Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project Communication and User Relations #13350

Closed
mutech opened this issue Jan 26, 2024 · 1 comment
Closed

Project Communication and User Relations #13350

mutech opened this issue Jan 26, 2024 · 1 comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@mutech
Copy link

mutech commented Jan 26, 2024

Problem

Background

I posted this comment on an issue about ~/.cargo: #1734 (comment)

The result of this comment was a - for me surprisingly - vivid reaction and a flood of comments which eventually resulted in the issue being locked 13hrs after the post, which is an hour before I first saw the responses.

I would have liked to have the opportunity to respond at least once to these reactions, part of which would have been an apology to @epage personally, whom I did not intend to attack, neither do I believe that this was actually inappropriate if controversial.

The Problem

In this issue (the one I opened here) I would like to abstract from the original problem (XDG vs ~) but use it as an example to clarify or explain my point.

MY problem is more social or political, than it is technical, but it expresses itself in the form of a technical issue, here the fact that cargo writes into my home directory without my consent and against both my intentions and expectations. Let me explain:

I wanted to look at a gemini browser, because I wanted to see what Gemini looks like. So I ran an ephemeral distrobox (basically a podman image of arch, because that usually is the easiest and fasted way to do that kind of thing for me), installed one of the terminal clients which in turn showed me a Gemini page.

The result of this process was that I have a ~/.cargo folder that among other things contains a cache of some repository. My backup process will dutifully protect this cache of data for the next year and make sure it will be around even if the office and my home burns down.

There will be a day when I will happily use cargo, I will then read its documentation and set CARGO_HOME appropriately or just make an entry in my backup ignore list. That's because I plan to learn rust unless I first look at zig, but that's not now. I am not a rust developer yet and I don't want to be bothered by cargo.

Now that raises the question, am I a cargo user (because I find .cargo at $HOME) or am I a cargo victim? How does the answer to that question affect your responsibility towards me, that is if there is any responsibility. You may think that it's up to your real users - rust developers - to make sure that they take care of their users. But the author or that Gemini browser did not create ~/.cargo, that was paru. And hey, actually it was my fault, because if I use paru, of course there will be stuff installed in my home directory. That's how it works, right? So paru is the culprit? But paru does not know about cargo. So it's people who want to look at Gemini, who have to read cargo's documentation to understand that they have to update their backup procedure when they want to browse Gemini space?

This network of responsibilities is what I meant with the problem being social in nature. What we do as developers, packagers and users has effects that are hard to predict. There is very often "a right thing to do", in this particular example, it's to honor platform conventions, more concretely the XDG directories. This is objectively the right thing to do, not just an opinion, because doing so allows users to choose the behavior they expect (and because they own their home directory they have the right to control its contents). It does not prevent users to choose letting cargo write to ~/.cargo, because CARGO_HOME can still be used. It's not a big effort to implement.

If you agree with me, that XDG is "the right thing" to do (at least for Linux), then the next question is of course why it wasn't done. And there is no surprise here. There are always more attractive and more important things to do. I mean nobody dies from ~/.cargo, there are no security implications, no performance hits and most people really don't care what's in these dotfiles. These are all valid and understandable points of view. I mean it.

But the consequence is, that your convenience trumps my right to decide what stuff is being written to or read from my home directory. When I spoke of a violation of trust, I meant the principle. If a program uses my CPU to mine crypto currency without my consent, that's criminal. If they upload my photo library, my address book or the pin code from my bank account without my consent, that's also criminal. This is not just a violation of trust, it's a crime. But technically, what they do is to use my resources for their purposes without my consent. I can hardly enforce how programs use my resources, that's somewhere between unfeasible to impossible, so whenever I use any kind of software, I have to trust that they behave, and the the tools they use transitively also behave.

So this is really a slippery slope argument here. The problem is not what cargo does in this particular case, the problem is that cargo believes it has a valid choice. And this is what I called a lack of respect. Not the malicious kind of disrespect, more a lack of awareness. Much like we called pseudo terminals masters and slaves before codes of conduct and linters convinced us that this is not inclusive and thus git will not accept a racist commit. I don't think that linters contributed much to the improvement of social justice or that they will anytime soon.

But I really think that it's important to make it perfectly clear what any piece of software is allowed to do, and I mean that as a matter of principle, not just in the concrete case.

Cargo is not a gemini browser, some obscure tool that somebody wrote after work. If some malicious code makes it into cargo, it can affect the whole world with incalculable potential for damages. Because of that, you have to be held to higher standards than some random rust program.

Please do not misunderstand this as another rant. From all I know, you are doing an awesome job. I'm not a Rust developer, so I have to rely on what I hear about rust and cargo and that's uniformly positive.

But here is the thing: If cargo, a gem among its peers, can afford to ignore XDG, then everybody else can do so. That makes XDG obsolete and with it, my ability to control the contents of my home folder. I am not ok with that. And I really don't care about ~/.cargo. I can just delete it and spend more effort on isolating my app containers further. I do care for the attitude of the industry towards users, especially those users who know much less about stuff than I do.

And that brings me to the next point, again respect. We are a particular generation of people who shape many aspects of what will be established norms in the future, we software developers. The last Sun CEO said something to the effect that "You guys have no privacy, get over it" (not a correct quote, just from the top of my mind). When I heard that, I thought "And who are you to decide that, it's my privacy, not yours". He was of course right. If I want privacy, I have to take it back from "them" and fight for it. A fight I will most likely loose. How about the ownership of what is in my home directory? Is this also something I lost and have to get over? Does cargo actually have the right to choose whether to honor XDG settings? Is it enough to provide CARGO_HOME if there is a good chance that a user cannot reasonably know about having a choice to set it? I don't think so. For me, this is clearly a breach of trust and the long term result in the slippery slope that already cost me my privacy, might well cost me the ownership of everything that's on my computer.

My generation saw the transition from a world without internet to coffee shops in which people sit at the same table each staring on a small phone, likely talking to each other via chat. As a kid I discussed the role and responsibilities of scientists in school in relation to humanity or society - motivated by the making of the nuclear bomb. That was when we were scared of nukes. Today, it's not so much scientist who shape the future of humanity as it is us, software developers - and that's not only because of AI's we're building. What we do is not to invent exciting technology that can destroy the world, we make it cheap and easily accessible to abuse people, people we call users and that terminology coincides with drug use as if that was intended.

Principles matter, because they are the only effective counter to slippery slopes. If you consider XDG compliance as an optional feature to implement or not, then you invade my property. If you consider the failure to comply with XDG as a bug that doesn't need to be fixed, you disrespect my right to my property. If you think that I am hysterical because I cannot wait 9 years for a fix, then you live in a world very different from mine.

I spend a lot of time writing this thing, because I want you to understand my point. This is not about ~/.cargo or cargo. This is not about your particular ethics, competency or morality. ~/.cargo is not important, you are doing a great job and from the looks of it, you look like good guys. The problem is that I strongly feel that appearances are not enough because we live in one of these periods of time where decisions are made that will define how the next century will be shaped. What we decide today, will be the norm by which our children will have to live, for better or worse. It's not about ~/.cargo, it's about whether people will have something like digital ownership of anything.

If you believe it's your choice, you stole my choice. And you probably didn't know that. Just saying.

Proposed Solution

Cargo is not going to save humanity, my property or XDG. Neither is it going to destroy it. But I think there are some things were cargo could serve as an example for a minor improvement. Here are my suggestions:

Know your users

Cargo is not only used by rust developers. Many users who don't even know they are such have no voice. Please take a step back an consider that at least once.

Reconsider Github Issues

Github became much more than just a git frontend. It is a social network, a job market and much more.

The role of issues is primarily very technical. But it is also the most accessible interface for users to communicate with projects. Communication between humans is messy, emotional and can easily become very unproductive. Something you don't want to have in your development workflow.

But it's probably the only place where you can hear from your users and just because communication is messy or at times impolite, does not mean that it's not valuable.

I got a whole bunch of mail notifications from my original comment. Your mailbox must look much worse. So yes, I see how you don't want to suffer the fallout of every flame war. But that's a technical problem that has potential technical solutions. If I was working in such a project, I would turn off notifications and configure or create a dashboard that makes sure that I get relevant information and filter out the noise.

There is no need to endure insults or abuse from users or colleagues, but I don't think that my comment or the discussion resulting from it reached that level of heat that justifies locking the discussion.

As annoying as casual, social, political or controversial opinionated discussions in issues are, I believe they overall add more value than damage. Most projects tune down the volume of issues as much as possible. I think this is a bad idea. But that's just an opinion.

Please don't lock an issue if it's not absolutely necessary (@epage). Was it really?

(I had more to say, but it's getting late and I don't even know if you are at all interested in this sermon, so I'll leave it at that for now and add the rest if there is any interest.)

Notes

No response

@mutech mutech added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Jan 26, 2024
@epage
Copy link
Contributor

epage commented Jan 26, 2024

Please don't lock an issue if it's not absolutely necessary (@epage). Was it really?

I locked it for social reasons, not technical, as that conversation was going in the wrong direction. As this violates the spirit of that locking, I am going to lock this as well until we feel it is time to open things back up.

I understand you don't see yourself as a Rust user and so its surprising when Rust related things get in your way. This will be a continued problem we need to work on improving (in multiple ways, including a concept called "minimum supported rust version"). I don't want to say too much more because I don't want this viewed as me "getting in the last word" before locking but I want to make sure you understand that I understand the problem, even if not the degree you feel about it.

@rust-lang rust-lang locked and limited conversation to collaborators Jan 26, 2024
@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Jan 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants