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)
For context, Tea (the cli tool) was created by the author of homebrew. But for some reason he changed the name to pkgx and made tea into the crypto thing: From the creator of Homebrew, Tea raises $8.9M to build a protocol that helps open source developers get paid
He’s probably interested in blocking these kinds of PR’s.
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.
which should prevent idiots like @onedionys from being able to figure out how to create the file.
Wow, slow down @mxcl. Calling people names is not constructive not warranted here.
Lmao fuck off
I’ve heard that one so many times it’s not even funny.
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.
I’ve seen video ads claiming to show you a way towards passive income from other people’s videos somehow. Now it’s coming to open source projects…
Am I stupid? How is this in any way confusing?
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?
The easy red flag here is YAML. It’s a hideous, overly-complex format for anything so of course a scam would choose it.
That’s a patently ridiculous statement
Have you read the spec? It’s a total mess
I have read the 1.2 spec (I’m trying to make a round trip parser for JS, and I do maintainance on a fork of the rumel yaml python package). I actually think its very well thought out, with things I hadn’t considered like future extensibility, streaming applications, and data-corruption detection.
The diagrams, color coding, and less-formailty of the spec was much appreciated. Especially compared to something like the ECMA Script spec, which reads like a math textbook had a child with a legal document.
I’m not saying YAML is perfect; round trip (the thing I’m working on) is nearly impossible because it wasn’t a design goal. It has a few too many features (I’ve never seen a declaration in the wild), but it does a good job at accomplishing the creators goals, and the additional features basically only slow down parser-implementers like me. I often pick it because of the tag support, which I’ve struggled to find an equivalent for in other serialization languages. I use anchors in recursive data structures, and complex keys for serializing complex data structures (not human readable). The “document end” marker has been nice when I’m worried about detecting partial-writes. And the merge key is nice for config files.
The application/perspective matters. Yaml might be bad for you but its not bad for everyone.
Even if anchors are pretty novel… I’ve watched myself & others fail for things that seem like they should be simple like scalars, quoting, & indentation rules all for being confusing (while failing to understand how/why the tab character isn’t supported).
That sounds like a skill issue. Something isn’t bad because you don’t understand it. Suggesting quoting is an issue for yaml is beyond the pale; it happens to be an issue everywhere.
Despite my love of yaml. I actually think he has a small point with unquoted strings. I teach students and see their struggles. Bash also does unquoted strings and basically all students go years and years without realizing
cat --help cat "--help" # ^ same thing cat * cat "*" # ^ not same thing cat $thing cat "$thing" # ^ similar but not the sameTo know the difference between special and normal-but-no-quotes you have to know literally every special symbol. And, for example, its rare to realize the
--in --help, isn’t special at a language level, its only special at a convention level.Same thing can happen in yaml files, but actually a little worse I’d say. In bash all the “special” things are at least symbols. But in yaml there are more special cases. Imagine editing this kind of a list:
js_keywords: - if - else - while - break - continue - import - from - default - class - const - var - let - new - async - function - undefined - null - true - false - Nan - InfinityThree of those are not strings. Syntax highlighting can help (which is why I don’t think its a real issue). But still “why are three not strings? Well … just because”. AKA there isn’t a syntax pattern, there’s just a hardcoded list of names that need to be memorized. What is actually challeging is, unless students start with a proper yaml tutorial, or see examples of quotes in the config, its not obvious that quotes will solve the problem (students think
"true"behaves like"\"true\""). So even when they seetrueis highlighted funny, they don’t really know what to do about it. I’ve seem some try stuff like \true.Still doesn’t mean yaml is bad, every language has edge cases.
While the subjective assessment that quote handling in yaml is worse than bash is understandable, it is really just two of many many cases where quotes complicate things. And for a pretty good reason. They are used to isolate strings in many languages, even prose. They, therefore, always get special handling in lexical analysis. Understanding which languages use single quotes, double quotes, backticks, heredocs, etc and when to use them is really just part of the game or the struggle I guess.
Most languages require you to put quotes around strings as the norm… breaking that is part of what causes all of the confusion in the first place. Better design upfront would lead to less common errors. I have way more quoting issues in YAML than I do JSON, Nix, Nickel, Dhall, etc. because they aren’t trying to be cute with strings.
When you’re editing yaml, why not just always write JSON?
Almost all nix attr keys are unquoted strings. Maybe I’m missing the point list, but I kinda wouldn’t expect it to be on the list.
Its easy for me to say “just start writing JSON in the yaml. It doesn’t get more simple than JSON”, but actually I do think there’s a small point with the unquoted strings.
Back before I knew programming, I was trying to change grammar settings sublime 2, which uses yaml. I had no idea what yaml was. The default setting values used unquoted strings fot regex. I knew PCRE regex and escapes, but suddenly they didnt work, and when I tried to match a single quote inside of regex that also didn’t work. I didn’t know I was editing yaml file (it had a
.tmLanguageextension). Even worse, if I remeber correctly, unparsable settings just silently fail. Not only did I have no errors to google, I didn’t have any reason to believe the escapes were the cause of the problem (they worked in the command line). Sometimes I edited the regex and it was fine, and other times it just seemed to break. I didn’t learn about quoting in YAML until years later.For me that was an unfortuate combination, which was exacerbated by yaml unquoted weirdness. But when you’re talking about “did you read the spec” that’s a whole other story.
.nanfor nan, tabs vs spaces, unquted string weirdness, etc should just be one error message+google away. I think they’re a small hiccups with what is overall a great format.
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?
{"foo":true,"bar":{"baz":1}}is valid YAML; better throw it out.I have no issues with using a strict and unambiguous subset of YAML :)
And what would your ideal, legible, general-purpose data markup language be? XML?
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.
XML is great if the (de-)serialization is already implemented. Otherwise traversing the document is a massive pain.
True. Something like XPath can really help & there are use cases where that is more concise but requires loading XPath into your head like Regex (which tends to get unloaded). The extensibility shines tho as seen by XMPP continuing to this day with very good backwards compatibility with 2 decades of updates since everything in an extension to the base.
RON (Rusty Object Notation). Its like JSON but better.
as a rustacian i cannot thank you enough for notifying me of this
Do you remember CSON? CoffeeScript Object Notation was a cute way to make JSON readable before CoffeeScript kinda died.
I see you get downvoted a lot. But as a norwegian that repeatedly have run into the norwegian problem when trying to use some program… i see you.
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.
