You must log in or register to comment.
In some open source projects there is a lot of leeching and little contributions.
In 2020 the sole developer of Invidious stepped away from development because of burn out. https://omar.yt/posts/stepping-away-from-open-source
Also in 2020 developer Raymond Hill archived the uMatrix browser add-on https://news.ycombinator.com/item?id=24532973
I will never hand over development to whoever, I had my lesson in the past – I wouldn’t like that someone would turn the project into something I never intended it to become (monetization, feature bloat, etc.). At most I would archive the project and whoever is free to fork under a new name. For now I resisted doing this, so people will have to be patient for new stable release.
What would actually help is that people help to completely investigate existing issues instead of keep asking me to add yet more features. Turns out people willing to step in the code to investigate and pinpoint exactly where is an issue (or that there is no issue) is incredibly rare.
For anyone wondering, here is the difference between uMatrix and uBlock Origin: https://news.ycombinator.com/item?id=24533329
That last sentence rings true of most software engineers. Everyone wants to work on a glamorous new feature that’s going to wow users or let them think about problems they want to think about. No-one wants to hunt down the difficult-to-repro bug in an old but critical section of someone else’s code.
When I stepped away from my own (mildly successful) Free software project, I had the same concerns: it’s about the reputation.
The project had earned a decent amount of trust when I was running it, and presumably people were installing new updates without going over the changes. If I handed off the project to someone new, I wasn’t just handing over the work, but that trust as well.
So rather than handing over the project to someone new, I archived it and someone else (thankfully someone not-evil) forked it. Anyone installing the fork immediately understood that the relationship was new. They’d have to decide whether to trust this new maintainer or not.
For my money, this is the way. If you’re burning out, remember that your reputation is tied to your project name, and that it has considerable value. If you don’t want to continue, the disruption of a fork is better/safer than the smooth-but-risky hand-off.
More people need to operate like Linus Torvalds. Call people on their shit. Respectfully of course.
Thing is, much of what Linus says is respectful; even though it reads harsh. Phrases like “you keep doing this” and “your code is shit” and “I will bar you from committing code until you can get better” and similar stuff, is respectful to the person, as he is still just focusing on the code : the product. Mostly.
Sure it comes off as aggressive ultimatums, but when I worked on New Jersey I saw numerous arguments between passionate coders who really cared about their work and spoke on these loud voices with aggressive gesticulations and gestures, and it was frightening. But, when you took apart the arguments, it was all about “the code” this, and “the standard” that, and very little “you suck” and “you’re dumb”. And, when the argument was settled, these passionate people were still friends.
Of all the people I’ve been yelled at by in my career, the harsh-sounding ones who kept it on the work and not the worker ended up with the most loyalty and trust in the end.
Give me a dozen Linus who care about their work. Sure he’s slipped up a few times, but on balance he’s been very good. Even before the “let’s all hug” sensitivity training.
“You’re dumb” is disrespectful, but “your code is shit” isn’t? How does the latter not reasonably imply the former?
Being respectful is taking the time to moderate “your code is shit” to something like “your code is not acceptable”. You might even go a modicum further into kindness with “there are aspects of your code I need you to improve”.
All express the same idea, some will leave the listener more open to internalizing the criticism.
How does the latter not reasonably imply the former?
I’m not dumb and I write shit code all the time. Bad code only implies that the author is dumb if you assume only dumb people can make mistakes.
Bad code, yes, calling it ‘shit’, no.
Stuff like this is a big part of why software circles are seen as so hostile and unwelcoming to outsiders.
You can be completely clear and frank without resorting to insult, mild though it may be. Just because you and people most like you understand that calling their work ‘shit’ doesn’t reflect on them personally, doesn’t mean it’s not significantly exclusionary.
Now, obviously you can get to know your reports well enough to understand whom would take ‘shit’ well, but that doesn’t mean it’s not generally important to temper criticism with kindness. Kindness never has to mean holding back criticism, just avoiding stooping to insult.
Mimimi
Sure it comes off as aggressive ultimatums, but when I worked on New Jersey I saw numerous arguments between passionate coders who really cared about their work and spoke on these loud voices with aggressive gesticulations and gestures, and it was frightening. But, when you took apart the arguments, it was all about “the code” this, and “the standard” that, and very little “you suck” and “you’re dumb”. And, when the argument was settled, these passionate people were still friends.
I used to work for a guy like that. He was aware of how a lot of people perceived him and was working on it but it never really bothered me when he slipped because like you said it wasn’t a personal attack, he was just trying to make us get the work done to his standards. There were multiple times he would come to me and apologize after we finished something and I was just like “well you were right so I’m not really worried about it”.
Respectfully of course.
Like “Fuck you Nvidia”?
I vote on an exception for big corps. Fuck you nvidia.
Lol, you don’t already operate this way in life?
Someone trying to guilt or pressure you has an agenda and isn’t concerned with what’s best for you.
Easy to say… Not so easy to just do it, specially if you’re burned down…
This very comment could be very dismissed with the attitude.
Anyone pushing you to do something you don’t understand, or understand poorly. I could see an actual security researcher pushing for a code update to fix a vulnerability.
Heck, even as an occasional contributor I take some pride in seeing my fixes etc make it into the mainline codestream.
But yeah, you definitely need to be wary of somebody you only know from online pushing a change that doesn’t make sense or you don’t understand.
Anyone pushing you to do something you don’t understand, or understand poorly.
This was taught to me in my bank teller training back in 19-dickety-two. Don’t let someone try to rush you or to obfuscate/over-complicate things.
I’ve always been a fan of “pull requests welcome” when someone asks me for something.
The problem is when people then open huge PRs and expect you to take time to review them, then eventually merge them.
Especially when it’s something you don’t want in your codebase because it introduce a big unnecessary “refactoring” or a feature that you don’t want to have to maintain forever.
That doesn’t apply as a solution here. After all Jia Tan did make pull requests, the pressure came later.
as a non developer myself, to my understanding, the vulnerabilities were implemented in test binaries?
If so, i question why those were shipped to the client. Unless they were built into the package itself on the mirror, in which case, still curious as to why that would be. I would think tests are entirely benign and do nothing. Seems like it would be incredibly bad practice to do otherwise?
Seems like an obvious vector to shutdown any potential fuckery. But what do i fucking know.
They were not shipped to the client. They were shipped to the build system, executed there after deobfuscation, and they inserted an additional, opaque program file into the build process.
that much i picked up on, though i didn’t make it very clear. I did mention that alternative though.
The guy was from Hong Kong, they probably threatened to throw his family in jail.
he was using a singapore VPN and had access to multiple sockpuppets. we know literally nothing else about them and anything you’ve heard to the contrary is baseless rumor.
leading theory is that it was a state-sponsored actor, but frankly even that much is speculation and which state is still way up in the air.
It seems I’m out of the loop, how do we know about hongkong and singapore?
we know about the singapore VPN because they connected to IRC on libera chat with it. the only reason I can think people would believe they’re from hong kong is because of the pseudonym they used, but it’s not like that proves anything.
see link posted in another user’s reply: https://boehs.org/node/everything-i-know-about-the-xz-backdoor#irc
we know about the singapore VPN because they connected to IRC on libera chat with it.
Hmm.
I don’t know if the VPN provider is willing to provide any information, but I wonder if it’s possible to pierce the veil of VPN in at least approximate terms?
If you have a tcpdump of packets coming out of a VPN – probably not something that anyone has from the Jia Tan group – you have timings on packets.
The most immediate thing you can do there – with a nod to Cliff Stoll’s own estimate to locate the other end of a connection – is put at least an upper bound and likely a rough distance that the packets are traveling, by looking at the minimum latency.
But…I bet that you can do more. If you’re logging congestion on major Internet arteries, I’d imagine that it shouldn’t take too many instances of latency spikes before you have a signature giving the very rough location of someone.
Some other people pointed out that if they used a browser, it may have exposed some information that might have been logged, like encodings.
I don’t foresee anyone with the kind of data needed to do more investigation releasing it to the public, so I doubt we’re going to be getting any satisfying answers to this. Microsoft may have an internal team combing through github logs, but if they find anything they’re unlikely to be sharing it with anyone but law enforcement agencies.