I had a similar emotional outburst where after contributing hundreds of hours to Stack Overflow, when I asked a question of my own, instead of answering an objective yes/no question people just argued with me in the comments about why I could possibly want to do whatever prompted me to ask my question. I delete my account and quit ever contributing to that site right then and there. I think I was just looking for an out and it was ultimately a good thing.
No idea if this is the case here, but I hope the author sticks with this decision. Although, looking at https://github.com/nvim-treesitter/nvim-treesitter/graphs/co... , it doesn't look like he started this project, so I'm not sure it's his place to archive it.
> doesn't look like he started this project, so I'm not sure it's his place to archive it.
This is a very valid point. It indeed looks like it was done in affect rather than after careful discussion with the (at least) ten members of the nvim-treesitter org.
This is a common issue with tooling used by open source.
Either you alone own the repo but then you're a single point of failure. Or you give those perms to others but then any one of them can abuse it (or get hacked).
I'd like to see tooling which requires consensus or voting to make certain changes such as archiving a repo or publishing a new release.
If you had the option to also delete all your contributions to the side, would you have done it?
If you had the option to exclude only certain people (e.g. those who argues with you) from seeing/using your contributions, would you have done it instead of deleting your account?
I am asking because I've too been burned and it's very commonly how an open source contributor's journey ends. So I've been toying with the idea that contributors should be able to exclude certain people or perhaps even groups of people from using their work.
Basically "I give away my work for free for anyone to use and build upon but if you don't appreciate it, if you treat me like shit, if you do any of X Y Z which hurts me or other people, then you're no longer allowed to use it".
i understand the sentiment, but the nature of FOSS is that i can't really prevent anyone from using it. i'd have to police it, and that would just lead to more misery.
i too contributed to stackoverflow and eventually stopped because it didn't feel worth the effort. i never asked a question though, so i didn't have the experience GP made, but i doubt i would want to delete everything, at least not without moving all my answers to another location.
once or twice when searching for the solution to a specific problem i was lead to a stackoverflow question and had to discover that the answer that solved my problem was my own from a decade earlier. so i too benefit from posting answers. deleting them would reduce that benefit.
> the nature of FOSS is that i can't really prevent anyone from using it
That's my point - maybe FOSS isn't the absolute good we've been lead to believe.
It was a response to locked down proprietary software which increasingly became hostile to its users. And it is (from a user's perspective) better that that for sure. But from a dev perspective, it's not as good as it could be.
> my answers
Exactly, those are your answers, your work. We've spent a lot of our limited time working for other people's benefit because we believed in it or sometimes because it was fun. But ultimately, it's becoming clear other people don't care and will throw us under the bus as soon as we're no longer useful. And then there's people who are just looking for a way to take advantage of us.
And I want to exclude both from benefiting from my work.
We should strive to find methods to make good, productive, pro-social people to benefit while keeping anyone who wants to exploit us away.
Profiling[1] your own repository and tweaking as necessary (possibly
disabling auto-status refresh) will likely yield significant
performance improvements.
I use magit with a very large repository (100k files, millions of
commits) it's still not lightning fast like it is with smaller
repositories, I'm still finding it an improvement over the CLI.
My config notes this saves me ~13 seconds in git-status
Facebook is running the same kind of engagement-maximization algorithm on Marketplace postings, so half of my suggested postings when I open Marketplace is girls posing in the clothes they're selling.
Mr. Superintelligence increasing Nick Bostrom's life expectancy to a trillion years but killing everyone else would as well. Why is he showing us the grace of letting us tag along with him into The Singularity in this fantasy just because we happened to be alive at the same time? Is it because he needs someone to do the actual work?
In my experience from the couple of times I clicked an IPFS link years ago, it loaded for a long time and never actually loaded anything, failing the first "I wish we could serve static content" part.
If you make it possible for people to donate bandwidth you might just discover no one wants to.
I think that many are able to toss a almost permanently online raspberry pi in their homes and that's probably enough for sustaining a decently good distributed CAS network that shares small text files.
The wanting to is in my mind harder. How do you convince people that having the network is valuable enough? It's easy to compare it with the web backed by few feuds that offer for the most part really good performance, availability and somewhat good discovery.
That remaining 1% are then actually the most advanced species, since they can continue their billion year existence through a blip of a couple thousand years when the environment became a bit more radioactive. We're so fragile that we're effectively biologically unstable, they're so advanced that they don't even need to know what happened.
Would've made more sense to add a grey "Edited" to edited releases. Releases are not actually immutable, GitHub could change them. I don't know why you need to use sciency words to say "editing disabled".
They are immutable! The releases are signed with an attestation from a trusted third party that Github can't forge! Also these attestations are public and anyone can verify that the signing third party isn't misbehaving.
> Release attestations let you verify that an artifact is authentic and unchanged, even outside GitHub. Attestations use the Sigstore bundle format, so you can easily verify releases and assets using the GitHub CLI or integrate with any Sigstore-compatible tooling to automate policy enforcement in your CI/CD pipelines. For instructions on how to verify the integrity of a release, see our docs on verifying the integrity of a release.
They are using Sigstore, which is pretty standard in this space.
No idea if this is the case here, but I hope the author sticks with this decision. Although, looking at https://github.com/nvim-treesitter/nvim-treesitter/graphs/co... , it doesn't look like he started this project, so I'm not sure it's his place to archive it.
reply