Honestly, it seems like the common denominator for all this confusion is Haskell, and specifically its IO system, not the monad interface itself. E.g., lots of languages have something like an "Iterable" interface, which - while it may be non-trivial for beginners to learn - absolutely does not require tortured metaphors to explain it. No one has ever needed burritos to explain Result::and_then [1].
As the the comment you're replying to just said, A) it's qualitative and B) it's perfectly fine to glaze the subject a bit in journalistic writing. It gives the article a quick hook to get readers interested, and if you actually read the article it becomes the least interesting thing about it.
And now that I've said that: I'd argue that if you consider the full "embodied complexity" of this machine's product lifecycle, it's hard to think of much else that compares to it. E.g., consider not just the machine itself, but also all of the R&D needed to get it to this point, and the amount of field experience necessary to make maintainable and reliable, and the engineering and supply-chain work necessary so that you can reliably ship them to customers around the world? While still being far, far ahead of all your competitors?
Right? Canonical wanted (still wants?) to use a coreutils implementation where "rm ./" would print "invalid input" while silently deleting the directory anyway.
I don't really care that some very amateur enthusiasts wrote some bad code for fun, but how in the world did anyone who knows anything about linux take this seriously as a coreutils replacement?
> The root cause of some of the bugs seems to be the opaque nature of some of the Unix API.
Some, maybe, but if you've decided to rewrite coreutils from scratch, understanding the POSIX APIs is literally your entire job.
And in any case, their test for whether a path was pointing to the fs root was `file == Path::new("/")`. That's not an API problem, the problem is that whoever wrote that is uniquely unqualified to be working on this project.
Interestingly, it looks like the `file == Path::new("/")` bit was basically unchanged from when it was introduced... 12 (!) years ago [0] (though back then it was `filename == "/"`). The change from comparing a filename to a path was part of a change made 8 months ago to handle non-UTF-8 filenames.
> That's not an API problem, the problem is that whoever wrote that is uniquely unqualified to be working on this project.
To be fair, uutils started out with far smaller ambitions. It was originally intended to be a way to learn Rust.
> Some, maybe, but if you've decided to rewrite coreutils from scratch, understanding the POSIX APIs is literally your entire job.
Yes, it is. But still such traps in API just unacceptable. If you design API that requires obscure knowledge to do it right, and if you do it wrong you'll get privilege escalation, it is just... just... I have no words for it. It is beyond stupidity. You are just making sure that your system will get these privilege escalations, and not just once, but multiple times.
So yeah, their implementation of chmod checked if a path was pointing to the root of the filesystem with 'if file == Path::new("/")'.
How the f** did this sub-amateur slop end up in a big-name linux distribution? We've de-professionalized software engineering to such a degree that people don't even know what baseline competent software looks like anymore
There's a big difference between a war between two somewhat equivalent things that make different choices (editor wars, language wars, etc.) vs pointing out that certain things are really fundamentally ... not good. IMO we all need to be much louder and clearer about how bad things are, and how much better they could be.
This is, in fact, on topic: github actions seemed to me like a bad idea from the start, to me, but I let my co-workers and "network effects" convince me that I was being grumpy and that it was fine, and so we've adopted it. And now ... here we are. It was exactly as bad I thought it was, and it reflected a broken engineering culture.
It is certainly possible that you are brilliant and your co-workers and the industry writ large are all morons. That you were right all along, and chickens roosting and all that, though it seems at least equally as likely that this is not the case.
If you think it requires "brilliance" to figure out that Github Actions is really bad, and/or that "the industry writ large" always makes good decisions, you might be the problem!
> $25,000 to the first true universal jailbreak to clear all five questions.
Now, laws vary from place to place, but I'm pretty sure "a small chance to earn money after the work is completed" is not equivalent to "payment" in most jurisdictions.
reply