Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

191–200 of 353 posts

Re: Xz: A microcosm of the interactions in open source projects

#191
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

The points you make aren't unreasonable. It is necessary to establish clear boundaries of what can and can't be provided by the maintainers. If not done at an earlier stage of the project, the support burden becomes too much to bear at which point the maintainer transfers ownership, and the project suffers from catastrophic consequences such as the xz backdoor we're talking about here, or other cases where the projec…

> "Mauro, your response is completely unbecoming for a Linux kernel maintainer, and is not in line with the promise of not breaking userspace."

This is just PC corporate speak. Linus is an actual human being who says what he really means.

Re: Xz: A microcosm of the interactions in open source projects

#192
post #65
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

You dont need to wonder. Any long term maintainer of even semi popular open source projects will tell you that engaging with the peanut gallery is completely counter productive. Engage with people that have earned it in your eyes, whether by contributing to your project via code, assets, bug triage, writing a good and effortful bug report, whatever. Just ignore what the larger internet has to say about you and your c…

What form should this ignoring take, in your eyes? I’ve never maintained an open source project but I’d imagine this is the hard part, how to politely decline the peanut gallery’s feedback. Do you disable GH issues? Leave them open and ignore them? Decline with some boilerplate language? How do you stop people from being mad that you’re ignoring them? (IME these types of people are likely to take things personally and start harassing you or complaining loudly in other forums…) These are the kind of things that stress me out just thinking about it, if a project of mine actually got popular.

Re: Xz: A microcosm of the interactions in open source projects

#193

Serious question, but what is your expectations for linux and all these libraries/dependencies after 20-40+ years when most of old school or current devs are retired? How can anyone guarantee reliable continuity by good actors in all these dependencies?

Steve Jobs said that someone needs to be the keeper and maintainer of the vision. I think that’s the key to the making of anything great over the long run: there needs to be a Benevolent Dictator For Life who has the vision, competence, energy, passion, and caring to consistently iterate the thing well.

The best case scenario for a project that loses its BDFL(s) is to hold on maybe as decently as Apple has under Tim Cook. They haven’t done anything truly innovative since Jobs died in my opinion — they just figured out more ways to apply the combination of a multitouch display, compact computer, and sensors; but they’ve iterated well on everything they produce and have held on to their lead in terms of hardware, user experience, and ecosystem cohesion.

In short: someone very competent has to care a lot about the project for the right reasons, and continue driving it forward. If the old guard is rotating out, someone has to step up.

If no one steps up, then leeches of various types will attach themselves to the project and simultaneously milk it for value and kill it.

Re: Xz: A microcosm of the interactions in open source projects

#194
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

Boomer hat: it's just toxic positivity, and the frustrating trend lately of assuming that everyone is equally skilled when writing software. Everyone's input is valid, or else you're just being negative and overly critical.

I'm not saying everyone need to be Linus Torvalds circa 2012, but I do think more people need to be a bit less precious and sensitive, especially when receiving direct communication about their abilities.

You don't need ego-boosting yes men, you just need to work with more experienced folks, and that's okay. But the problem is that there is an army of people online who will take offense to that, and I don't know what the solution is. Best of luck.

Re: Xz: A microcosm of the interactions in open source projects

#195
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

I've been thinking about contributing to some open source projects, and starting a couple of things of my own, and the community aspect is a significant downside for me, and I say that as somebody who was quite active in several open source projects and things like the IETF years ago. I'm not saying the community shouldn't be there, it's just that the barrier to entry is so low, that people can "contribute" with very…

> I think this is why I don't do social media any more

Guess what you’re doing here, buddy.

Re: Xz: A microcosm of the interactions in open source projects

#196
post #97

If I were a chinese hacker trying to do something evil, why on earth would I use a chinese handler/username? Wouldn’t it be better to use an English/European name to gain (even more) trust from open source maintainers? On the other hand, if I were a non-chinese hacker trying to do evil, then using a chinese handler does make more sense (China is evil, blah blah blah)

Seeing an Asian (any part of Asia) name wouldn’t give me any pause in the slightest. I don’t want to start anything here, but aren’t they disproportionately represented in the American software industry as compared to their percentage of the population? What would raise my hackles would be someone with a name that codes western who had grammatical idiosyncrasies common to ESL Asians.

So, a couple of thoughts, this likely be chosen in the event that they wouldn't be caught, not that they were. Thus, them choosing a Chinese sounding name to frame China or to go along with the narrative of China being the evil communist country (etc) doesn't really make sense. Also, even if they did that, only westerners would be fooled as others have pointed out "Tan" is a dialect surname (hokkien may be), pointing to someone in Southeast Asia, not mainland China.

A better assumption imo is they chose their identity first and foremost with the intent to garner trust first with Lasse Collin.

Re: Xz: A microcosm of the interactions in open source projects

#197
post #17

So the first step of this huge mess was: a social engineering attack. Attacking a tired, burnt-out open source project developer and peer pressuring him into giving more control of the repo to the attacker.

The tiredness or other problems of the developer seems an easy narrative, but did anything actually happen that wouldn't in any understaffed open source project? A contributor shows up and does work for 2 years, I feel most projects would have given the person full project developer status by then.

The attacker really did useful work for 2 years, before taking over the project and injecting malware? I wasn't clear on the timeline.

That is pretty hard to defend against. I wonder if they were planning this all along, or if they wound up with a greedy plan later, or what.

Re: Xz: A microcosm of the interactions in open source projects

#198

“Community desires more” At which point if “the community” consists of one guy doing everything and a couple whiners making demands, fuck it.

This line in light of what we know now makes me think that while OP has a point about open source, this thread and others like it definitely were sockpuppets trying to goad Collin into transferring maintainership quickly.

Re: Xz: A microcosm of the interactions in open source projects

#199

Earlier quoted context omitted.

The points you make aren't unreasonable. It is necessary to establish clear boundaries of what can and can't be provided by the maintainers. If not done at an earlier stage of the project, the support burden becomes too much to bear at which point the maintainer transfers ownership, and the project suffers from catastrophic consequences such as the xz backdoor we're talking about here, or other cases where the projec…

> "Mauro, your response is completely unbecoming for a Linux kernel maintainer, and is not in line with the promise of not breaking userspace." This is just PC corporate speak. Linus is an actual human being who says what he really means.

I'm assuming the apology[1] from Linus must have come off on complaints raised to the HR department of companies with active contributions to the Linux kernel. Because this was Linus, this went over relatively smoothly for him, but for another person, this may not have been the case.

There is also no telling if the person is interacting in good faith and just doesn't know, in which case the aggression is a bit rude.

You can tell people to fuck off without saying that explicitly, and it also allows you to save face in case the situation isn't what you expected it to be.

[1] https://arstechnica.com/gadgets/2018/09/linus-torvalds-apolo...

Re: Xz: A microcosm of the interactions in open source projects

#200
post #190
post #179

Earlier quoted context omitted.

Agreed, which is why IMO ssh in production is a terrible idea that reveals even worse problems. A server with ssh generally implies there is a shell, and cli tools, and an administration model that involves humans connecting to servers to manually update them in place like pets. Having a full workstation-optimized distro like ubuntu or debian with hundreds of packages constantly shifting and updating as a critical pr…

> Production servers should be hardened immutable appliance kernels with read only root filesystems that verify and run signed containers, or run a tiny shim init system in a couple hundred lines that spawns a single application specific binary you trust. And then you need to debug something. What do?

Have good logging and virtual machines that can replay those logs offline?
Post reply on HN