I got a pull request from "tea.xyz" related individual and unraveled a mess of a disappointing project.
Yet another "brilliant" scheme from a cryptobro. Naturally this caused a gold-rush for scammers who outsourced random people via the gig economy to open PRs for this yml file (example)
It's hilarious that PR author in that example has monkey profile pic. I guess what people are saying about never trusting people with monkey pfp is true.
Actually, I only want to add one file, tea.yml, to your repository. Because I have a job that requires uploading the file and I also don't know what it is used for.
So you want me to merge a file you use on your job and you don't know what it does?
He's probably interested in blocking these kinds of PR's.
He is now that people are spamming the high profile projects he used as examples in his "get paid" cryptobro scam videos and it's pissing people off in the FOSS communities hes trying to worm the project into.
Hilariously, he stated that he would be really unhappy if people were doing this to his actual FOSS projects, which makes me wonder why he didn't use them in his examples instead of the completely unrealted Node.js and ghost projects.
Its almost like he made himself getting rich someone else's problem. Totally unlike crypt bro behaviour, of course.
Lol classic reply from the monkey pfp "I didn't know, I'm sorry, please don't ban me, sir". These fuckers know exactly what they're doing seeing from how they obfuscated the pr purpose, and act all ignorant when caught. It's exactly the same behaviour game cheaters exhibit when caught red handed
Honestly doesn't sound like a terrible idea on paper, but this spam outbreak could kill it before it gets off paper in a real way. Giving devs a bad taste will stay around a long while.
Edit: and of course the well-earned general attitude toward cryptocurrency as scammer playgrounds is automatically putting it way in the red too.
Dude also used a LLM to generate descriptions for the packages he's serving from his package manager. And of course, it got them wrong, creating a headache for the actual package maintainers
I do like the idea of streamlining donations to open source projects directly through a package manager, and crypto seems like a good fit for that (decentralized, uncensorable). The issue here seems similar to knowing what charities are properly using funds; making a system to make decisions about how to spend money is hard when there's so many people looking to misdirect it to themselves, and the point of this would be to relieve the people who would be donating the money from putting effort into doing the research themselves, so that big problem has to be solved.
Why does the tea project not have users claim ownership of GitHub profiles. That way it could be retroactively applied with no effort on the user or maintainer.
I assume it's because they don't just want to count owners but also maintainers. How do you count maintainers? Does one accepted PR count? If not, how many? Counting owners only that would be fine though.
It's sad that a lot of the username come from Vietnam (my country). I remember when the Stellar airdrop announced there were people trying to buy GitHub account for 3-5$ for "their company's project". Many people do the thing that called "MMO" like that here, that doesn't realistically provide any value. They just want to get rich as fast as possible with only simple jobs such as copy and paste.
I greatly respect the way Vietnam has put things like stable rice prices over Western money. As far as I understand it, this allows for a society where nobody lives in abject poverty. But it also prevents people from getting rich quick by milking their own people. So if I got all of this right, it's not surprising that some people encountered the idea of getting rich quick through the Internet and try that now.
Ive seen an uptick in twitch users offering graphics packs for streamers.
I presume some company has figured out the prompts to get AI generated emote packs, and now hire people to offer this service randomly to small/medium streamers.
I kept re-reading this line and it made no sense. All I need to do to claim ownership of a project is merge a pull-request? Do I own Laravel because I've gotten a pull request merged? (emphasis mine)
Merging a pull request and having a pull request merged are two completely different things, and one very much requires you to own the project or have contributor rights to it. Which is exactly what the scammer is looking for proof of.
How was the author confused by this? Or am I somehow the dummy here?
@CrayonRosary having a pull request merged is in no way a proof of ownership of the repo, or a sign that the owner wants to participate in this scheme. There are better ways to prove ownership. It's relatively easy to slip in some file unnoticed, or falsely explain during the PR process what the file represents. So choosing this way of validation is a huge red flag about the whole scheme. It motivates people to falsely claim ownership of popular repos.
"Oh no! All of these configuration file formats are complicated. I want to make things simpler!"
(Years go by)
"...I have made things more complicated, haven't I?"
YAML is generally good if it's used for what it was originally designed for (relatively short data files, e.g. configuration data). Problem is, people use it for so much more. (My personal favourite pain example: i18n stuff in Ruby on Rails. YAML language files work for small apps, but when the app grows, so does the pain.)
originally designed for (relatively short data files, e.g. configuration data)
This I can get behind. But because it’s not bad in those spaces folks think it’ll be a good idea in all spaces. Anchors do neat things, but organizing large files with YAML’s weird rules around quoting, & no support for tab indentation rub me the wrong way.
What? I love having 20 ambiguous ways to express the same data with weird and unexpected conversion rules. JSON is so much worse - if data types are explicit and obvious, how can I properly express my feelings when writing a config file?
Depends on the use case but XML is good for markup—especially if you need extensibility.
For config, Nickel & Dhall take the cake for being typed & having LSPs so the configuration writer can get immediate feedback about possible options (while eliminating invalid states) without requiring the manual—with configuration readers not needing to mess around with marshaling their types. Both these configuration languages let you import files & write little loops to make your config more DRY & makes maintaining large files (like say Kubernetes) easier.
YAML 1.2 was released 15 years ago and fixed this issue. The problem is not YAML but the libraries people are using to parse it being a decade and a half out of date.
Btw, "cryptobro" is a sexist term that excludes women.
I'm usually that person getting downvoted for insisting on inclusive language so I totally get you, but girl I've never met a cryptobro who wasn't a man.