fogof

Do you think there is a tradeoff in this case? If so, what is the best counterargument against making PACER records free? I think it's important to note, as the article does, that these records are already "public" (that's what the "P" stands for) what's at issue is whether you should be charged a fee to access them.

I recently saw an interesting criticism of this paper: That by the end stages of the disassembly of Mercury, the amount of heat generated would be so much as to melt the surface, calling into question whether the mass driver system could work at such a high rate.

The title of this post seems wrong: seems they are claiming five thousand kilograms of gold per year in a Gigawatt scale plant.

> power plants can generate five thousand kilograms of gold per year, per gigawatt of electricity generation

Very funny to me that lecture 21 is one of the only lecture titles that doesn't reference the name of the originator.

I am looking at the last image in the article, captioned "The encrypted message instructs the viewer to appease the gods with offerings". The picture shows ... a person kneeling in front of a throned figure, offering something with both hands. Is something about this message supposed to be hidden?

Not sure I agree with the comment you're responding to. But the article discusses some of their funding troubles, and the main mage of arxiv.org itself has a donate link. So I think perhaps the media presence might be motivated by a desire to fundraise (and IMO they absolutely deserve funding because of the important work they do).

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.

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.

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.