I don't think this is right. From the Wikipedia page:

> In August 2022, the U.S. Department of the Treasury blacklisted the service, making it illegal for US citizens, residents and companies to use.

A lot of thoughts in this thread on what academic papers are or should be, let me give my own opinion as a person who tries to write papers.

Papers should be structured like fractals - that is, they should be "self-similar". The main text of the paper after the introduction should go into all the necessary details demonstrating the origins of the idea and proving that it has value. Then the introduction section should summarize all this, and take a less rigorous tone. The abstract should be a summary of the introduction. And then the title should summarize the abstract. If you really have a lot of technical work to do, maybe you can write a super long appendix and have the main body summarize that.

I myself probably spend as much time reading paper introductions as I do reading paper bodies, which means that probably 90% of the papers I read, I only read the introduction. I do this because I enjoy it more - I like new ideas, and the intros are a great way to get a lot of them. This blog post reads like a great paper introduction to me. It's easy to trick yourself into believing something is easy though, so an academic paper would have to back this up with an experiment.

He says in the very first paragraph:

> I lost a series of pitched battles against Pytorch and biblatex, so I figured I’d just write a blog post instead.

So I think your accusation of his burying the lede on the lack of experiment is unwarranted.

What rubs me the wrong way about the mhils Github response is that it fails to answer the question that the commenter asked: Is there or is there not a target date for the next release (and if so, what is it)? It's fine to charge money to move the date up, but it seems like if you are going to make that offer, you should try to tell the person how much time they would actually be buying.

> What rubs me the wrong way about the mhils Github response is that it fails to answer the question that the commenter asked: Is there or is there not a target date for the next release (and if so, what is it)?

Why exactly do you expect him to answer that? It’s not like he is working for the guy. He can do whatever he wants.

Reading this discussion I’m starting to understand why so many open source maintainers end up calling it quit.

Yeah, back to what my grandma would say “if you don’t have anything nice to say…”.

Either…

This is something I, as someone spending some time on a passion or hobby project, don’t want to deal with and I’ll just ignore it.

Or

It’s a business transaction and I’ll at least try and explain what services I can provide, not just “lol pay me”. “We don’t have a release schedule. Except in the case of actual critical vulnerabilities making our users vulnerable, releases are tagged when we have enough functional changes to warrant them. If you would like to get in touch to discuss a support contract and us tagging a release just for you and your customers you can contact me at X.”

Refusing to engage on the question or how you can work together and just saying “lol pay me” definitely comes across as “fuck off” to me. And if that was the intent… better to not say anything at all.

He explained it already: the requested change is purely for regulatory purposes and has no functional value. He would release once enough functional changes accumulate.

You can hardly say that they switched to a private channel because they knew "that they would get blasted for such a response in a public forum" when the comment they were responding to was the one that suggested the switch to email.

The comment suggested email for payment, not an extortion accusation (i know accusation is bit too much of a strong word, i couldnt find anything better)

Plus, they did get blasted just because the email was made public. To me, that shows that they wanted a more private channel.

I disagree that this would have been the right thing to do. There's nothing wrong with explaining why something could be useful in an open source project - if the reason seems like something important that a lot of other users of the software would also need, the maintainers of the software might want to know about it so that they can add the feature or fix the bug sooner. It can also help if there's some way of working around the problem.

Calling the developer extortionate was unreasonable, but I don't think there's anything wrong with the first message.

Fun how you can hear the diffraction spikes.

For searching using search terms for theorems in mathlib, there is the mathlib documentation page (for Lean 3 https://leanprover-community.github.io/mathlib_docs/ and Lean 4 https://leanprover-community.github.io/mathlib4_docs/). To find theorems by type, I find the best way is to use the `library_search` tactic from inside Lean itself.

They address this at the end of the article

> Our calculations account for air drag and the effects of gravity.

> While the return velocity is dependent upon a number of factors, firing angle is extremely important. Bullets fired at an angle maintain their angular ballistic trajectory and are less likely to tumble, allowing them to pick up more speed on the way down.

You make a good point about the infographic showing a cartridge being fired, but as far as I can tell there is only one infographic on the page that actually shows this. These factors make me suspect that you didn't actually read the article to the end before criticizing it. "Intellectual rigor" indeed.

This is why I think network fees are a good metric. As long as anyone can become a block creator, you can’t pump it without losing money.

Only works on congested networks, or those that burn fees: in original bitcoin style, without congestion, generating dummy transactions is free for miners (the fees come back in block reward).