It's nice that this is a PURL (by virtue of the DOI system), but we can do better than this.

This is for:

Abramson, D.A. and Sosic, R. "Relative Debugging using Multiple Program Versions", Key Note Address, 8th Int. Symp. on Languages for Intensional Programming , Sydney, 3-5th May, 1995. In Intensional Programming I, World Scientific, ISBN 981-02-2400-1.

(From https://web.archive.org/web/19970504170226/https://www.cit.gu.edu.au/~davida/guard.html.)

Linked to archived paper: https://web.archive.org/web/19970504170226/https://www.cit.gu.edu.au/~davida/papers/islip.ps.Z

This is for:

Abramson, D.A. and Sosic, R. "A Debugging Tool for Software Evolution", CASE-95, 7th International Workshop on Computer-Aided Software Engineering, Toronto, Ontario, Canada, July 1995, pp 206 - 214. Also appeared in proceedings of 2nd Working Conference on Reverse Engineering, Toronto, Ontario, Canada, July 1995.

(From https://web.archive.org/web/19970504170226/https://www.cit.gu.edu.au/~davida/guard.html.)

Linked to archived paper: https://web.archive.org/web/19970504170226/https://www.cit.gu.edu.au/~davida/papers/case95.ps.Z

The voice associated with the narrator is so buffoonish in this piece, it reads like it was written by someone who found themselves in the role of the layperson and was deliberately (and a bit unfairly) caricaturizing the professional. But it's not.

The author comes across as really obnoxious, with no willingness to provide arguments/rationale to his hypothetical interlocutor, just vibes—very "That's just not how it's done."

It would be great if businesses and individuals took seriously the matter raised in this post, but the irony of this statement is that it doesn't align with what you generally find on independently created-and-run websites; getting the info unadorned is usually best found the big platforms, because Facebook, etc. control the site design, and the userbase has to contend with just providing the information. And even if you find, say, the visual design of a platform's look and feel to be unappealing, it is at least uniform.

The professional developer class strikes again, obscuring the fact that creating a website is just desktop publishing—document preparation with URLs—and not any more complicated than that (but for the fact that there's an entire industry of folks making it so in their own self-interest).

Still true now.

Great example of why "The Web" is really about, as TBL says, URLs, and not HTTP-and-HTML (and/or CSS, JS, etc., i.e. "WHATWG-flavored hypertext").

This is like how early works in math and physics don't use recognizable mathematical notation (because it didn't exist yet) and instead defined and described things prosaically.

Not surprising to see here. RFC 1738 hadn't happened yet.

Hey, traveller.

You're looking for https://www.w3.org/History/1992/ENRAP/Article_9202.pdf

samsquire is user chronological on the halfbakery.

HTTP at least has a provision for specifying URLs with Basic Auth credentials. It's interesting that sqlite's file-scheme URL parser didn't adopt an extension to the standard in that vein (RFC 8089 Appendix E, Section 1), instead of putting the key in the query string (which is another non-standard extension—not mentioned in the RFC at all).

Should be "apply".

Should be "copies".

Perversely, the quote here and emphasis in the content, is a fabrication.

Some observations:

• While it isn't easy, it is at least as easy as getting into a good school, and going to class and making good grades for four years. And with that said:

• Isn't this (the guarantee here—"guarantee"!) basically the same as the beliefs corresponding to the aforementioned bubble?

I think what Boodman failed to grasp at the time he first wrote this was that (b) many of those in his audience were persons who, having just invested four years into going to college with a reasonable expectation that it would pay off, weren't in a position (read: didn't have the resources) to suspend life for another 2-to-4 years trying to follow a plan like this (step #4 here—"Repeat[ing] steps 2 and 3 about 50 times"—is landing a patch to fix a new Chrome bug every two weeks) on the promise of an even more uncertain payoff, and—more perniciously—(b) a subset of those in his audience would have been those who were (more or less) already as capable as needed by the requirements of this process, but were in his audience nonetheless because, despite being so, it wasn't enough to "get them a good job" due to the stochastic nature of the market (incl. the fickle humans who are often gatekeepers in the "find a good job" process).

Elite overproduction

Another way of approaching the implementation versus abstraction issue when it comes to misconceptions about programming languages and their toolchains/runtimes is to make "[programming languages are notation, and] notation is not machinery" something of a catchphrase.

This passage is something like an ideal target (case study is misapprehension).

Hey, traveler. You're looking for https://www.cs.ucf.edu/~leavens/FoCBS/.

Geez. What a villainous combination of sentences.

I wonder where on the scale of "waste of emotional energy" this person puts getting worked up about what other people are criticizing.

Commenters on HN https://news.ycombinator.com/item?id=45896130 have mostly been critical of Camlistore/Perkeep in terms of whether or not it's a fully baked app, and then go on to talk about alternatives like Linkding, Zotero, or the (confusingly, similarly) named Karakeep. I think that gets it wrong.

The right way is to think of all those as all having backends that are all deficient in their bespoke ways and as being potential frontends for your Camlistore data.

The right question to ask is, "Why are projects like Shiori and Timelinize their own thing instead of better ways to interact with Perkeep?"

Git's "stupid content tracker" strategy of just snapshotting everything and treating storage/compression as a separate concern strikes me as the not-obvious-and-not-obviously-better-but-still-better approach and recording deltas as the obvious "solution" that turns out to be folly.

On the other hand, people have complained about Git stretched to other use cases, like with git-annex, being really slow.

This is worthy of close study.

A nice knock on of getting unzip working in love2d is I'm now able to load ods files (Libre Office's Calc format for sheets) directly.

Meaning I am able to hotload constants during runtime on file save without having to run an export from Calc.

Imagine if LibreOffice took table-editing and interoperability+sharing seriously and its native format for really simple tables like this were as simple as a plain text file with an HTML table in it.

(Or imagine if Web browser makers woke up and realized that, "People shouldn't need a copy of Excel or one of its clones to create/share/work on files with data like this.")

This would be much cooler if the TUI was a semi-general-purpose Web browser that happened to work really, really well with a certain highly opinionated, HTML-first frontend framework and that is what constituted the wire protocol from server-to-client.

The dearth of modern TUI-based Web browsers is a big disappointment.

Or you could not. Put a badge in the UI that indicates, "Hey, this thing was deleted. We still have a copy, though, and that's what you're seeing here. Pinafore is working for you."

This is the prime example I use to illustrate implicit step zero.

This is a well-known passage by Yegge explaining why GeoWorks didn't attain success with their object-oriented assembly, and why their object-oriented assembly is the reason for not doing so.

A pithier and more succinct analogy of the bigger picture that Yegge is trying to communicate here—something like what Engelbart struggled to get people to understand resulted in his metaphor of a pencil taped to a brick—would be, "There's a reason why programmers aren't writing code on punch cards anymore (and it's not just because the market for the equipment and, accordingly, the equipment itself, all but vanished and is no longer available)."

So document the process for updating the site in an SOP, making sure they're written in sufficient detail to be executable (by an agent—a user agent—sans LLMs), and then host the documents that detail those procedures on your site, as first-class content.

"Updating the site" then entails 1. consulting the SOP, and 2. carrying out the procedure there (either manually, or having your agent do it).

This is all achievable on a static site, provided there are Web-accessible (and, ideally, CORS-enabled) endpoints to control what content appears there (like the GitHub API, to name one example).

It's nuts that no mainstream browser has incorporated basic native table-editing controls by now. (They wasted no time adding JSON pretty-printers—unsurprising, really, given that their main actual concern is propping up the JS–industrial complex and the professional developer class and not real users, which they don't actually give a shit about, contra the Priority of Constituencies.)

There is and has been for a long time a huge opportunity for a "Photopea for CSV (and JSON)" to show up and take off.

No, this was never the case.

now a property of the program

To re-iterate: that's how it's always been. Programming languages and compilers are two different things. To conflate them is a category error.

Sure it is:

It's not really a debate, HTML is a markup language [1], not a programming language

This is a false dichotomy, and untrue on two points (a) that HTML is "not a programming language", and (b) that the stance you have taken is not up for debate.

You're using the term "programming language" as shorthand to refer to the subset of languages more rigorously referred to as Turing-complete general-purpose programming languages.* There are programming languages outside this subset that no less have set membership with the larger "programming language" superset.

A programming language is a programming language in the sense that they have come to exist with the advent of the stored program computer. Though HTML and other markup languages are not** Turing-complete general-purpose programming languages, they are used every bit as much to describe a stored program as a language you might encounter when opening a file containing G-code "instructions" for controlling a CNC machine.

* We had a similar (but not the same) silly recurring argument in the 90s where people, at a loss for words to accurately capture their thoughts and grasping at whatever came to mind, argued that there were two distinct classes: "programming languages" and "scripting languages"—a category error arising from the same phenomenon of mistaking loose, off-the-cuff shorthand for The Real Idea Behind the Thing That's Involved Here

** No overlooking the fact that HTML is a proper superset of CSS, a provably Turing-complete (though not general-purpose) programming language—and JS, which is, of course, a true general-purpose programming language

(Originally drafted in response to https://news.ycombinator.com/item?id=46747778)

The state of { journalism, the Web–industrial complex, and understanding about the fundamentals of research and scholarship } are so poor that the staff actually had to justify something as simple as citing your sources.

(In 2010, but still… 2010!)

https://github.com/solbjorg/oberon-riscv

The complainants' comments here are pure occupational psychosis.

See also: déformation professionnelle.

With these words, you might expect that programs that target the Wren reference implementation are faster than those written in Lua. But (again), languages are not language implementations, and the language implementation matters; while Wren programs written for the reference implementation available here are generally faster than programs that run on lua.org's Lua implementation, they're not faster than programs that run on LuaJIT.

No. Languages are neither fast nor slow. Only language implementations.

If only it weren't 25+ years later (and the PowerShell folks hadn't regressed on Windows).

... for people who have uvx installed.

... for people who have uvx installed.

k, but why not Oberon (with curly braces, of course)? It's both small and real/complete.

Right. Okay.

Good.

This is what I would expect, slop generators or not. "Q3" includes summer and the start of the fall semester. "Q4" includes Thanksgiving and winter break.

"…on GitHub" (as with all things from people who speak myopically about "open source" but run all their projects on GitHub). They're talking about the GitHub userbase.

"I'm not signing your CLA" is my position, and I'm not the only one who takes that stance. My contribution is available to upstream under the same license available to everyone else: the one that the project leaders chose to attach to the project. Take it or don't.

(They've settled on "don't". That's fine.)

Why do people who should be in-the-know make this mistake? This is one of the weirder variations—usually it's people thinking that Chrome is based on WebKit.

In this instance, they seem to be aware that Chrome isn't using WebKit, but do think that Safari is using "Chromium" (which is neither WebKit, nor Blink, i.e. the browser engine that Chrome is using—Chromium is an open source browser, not a browser engine…).

Electric blankets account for over 5000 fires a year in the home

http://www.fireservice.co.uk/safety/electric-blankets

@45:27

Blow: games for a while was known as the place where there were still a lot of really good programmers because we were forged in this fire of really difficult stuff, and I think that's become increasingly untrue. I think game programmers are reverting to the mean.

Or superinferior, even:

• https://hypothes.is/a/0aJmbia_Ee2UcD9QSXCpVA
• https://hypothes.is/a/zPdzGCaeEe6XyvOHOHZBcQ

@21:25

Blow: Maybe I should ship— I mean I would have to dig it out of source control and compile it again, which… OMG. Compiling a C++ program from 15 years ago is difficult.

Muratori: Mm-hmm.

This is confusingly worded. The author is saying it is only the professionals (experts) who can "afford" the latter—not that only a small number of them can.

In 2021, I tried to convince Matt Baer, who was planning on creating a comments platform to accompany write.as, that this is what people would prefer someone to build instead.

Because it doesn't take a high-end chip like an Nvidia GPU to play streaming audio/video.

This post may or may not have been partially motivated by the OnlyOffice stated license requirements where they insist that the AGPLv3 does not permit removal of the original logo (and that it must appear in a certain location). See https://isitreallyfoss.com/projects/onlyoffice/

Krzysztof does couch his explanation by saying that he's talking about the GPLv3's ALNs, but it's easy to confuse in proximity to the previous mention of GPLv2 (not least of all by folks who seem perpetually committed to misunderstanding what the FSF/GNU puts out—even when it has been painstakingly refined to be clear and unambiguous due to excruciatingly bad takes about what the FSF does or doesn't say about something).

The full text of GPLv2 Section 2(c) reads:

If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

This obviously covers a lot more than the elements of a copyright notice.

Note that the full text of GPLv2 Section 2(c) is quite a bit longer than the subsequent quote, and it's very clear that the requirement is not limited only to the legal notices.

I mention this, because based on what Krzysztof goes on to say about the specific elements of copyright notices, one might get the wrong idea.

This GPLv3 link actually links to "A Quick Guide to GPLv3": https://www.gnu.org/licenses/quick-guide-gplv3.html.

The appropriate URL is https://www.gnu.org/licenses/gpl-3.0.html.

(Note that the guide at the first URL is linked from page containing the GPLv3 at the second URL, and the link appears immediately below a "Skip to license text" link. My guess is that Krzysztof's aim was off and meant to copy the skip-to-section link but inadvertently landed on the link to the guide.)

So you want people to let you run code on their machine that makes it answer to you—some random nobody—instead of the person who is using, and very likely owns and paid for, the device in question.

Perhaps you would next like to see your neighbor to just give you their car and convince some local businesses to let you take over their employees, shops, cash registers, and other equipment to put them work for you as well.

Right. No great reason not to just extract the DOCX/XLSX/whatever before checking it in, just like you would with any other ZIP (and good reason to: not doing so is going to unnecessarily bloat your repo, given the way Git works by keeping whole copies of files in the .git directory—not by storing diffs—why does that myth persist?)

This is why the solution* to the question, "How do I deal with my project's Office documents wrt the Git repo (i.e. check it in, track history, diff across versions)?" is "Unzip it; check in the contents."

* sort of—you'll find that some of these formats include a binary properties file, for which you need to use/run a disassembler before committing, so the contents of it, too, are best stored and tracked as text

It's this one:

https://news.ycombinator.com/item?id=17249693

Don't edit (as in "replace"—which is not really possible, anyway Just publish a retraction/followup. (Separately—different URL.)

Exactly!

The contents of this page are a great candidate for smart documentation.

The fact that the reference implementation from Grendel ("Javagator") is in Java should make it straightforward to create port to mostly readable JS (limited mainly to the readability of the original).

Why/how do these make for a line-item criterion in a list of concerns for things necessary or useful to a compiler?

https://news.ycombinator.com/context?id=46746879

(Start here: https://news.ycombinator.com/item?id=46743683.)

Java's inverted DNS-inspired package-naming sucks. Everyone invents domains that don't exist. And of course, some people don't even have a domain.

JSON isn't a solution to needing to write parser. It's a solution that means you don't need to write a lexer.

You have just reinvented twtxt, except now you have to name each post (mint/allocate a separate URL for it).

Right. You wouldn't. Which means you can embed the author information there—because you're not going to go through and change them.

You can (and should) just leave them alone.

Author profiles on hardcover dustjackets don't change when the author changes affiliation or relocates or dies. Their forwards and prefaces don't change when available information on the subject evolves. This is all not just perfectly fine, but desirable.

Huh? Regular, ordinary elements in the W3C/WHATWG object model don't have a node "value".

So what does the SetValue method here even do?

I don't see why this would be surprising—or described as "obtuse". WebDAV is HTTP. Of course the headers matter.

It's almost as if subverting the VCS isn't actually a good thing…

(The author's point notwithstanding, you don't strictly need a .js file. Browsers don't care about file extensions or even content types when it comes to <script> elements—which is probably what the author was referring to. In reality, you can shoot whatever you want—even HTML, served as text/html—through the browser's JS parser and it will attempt to execute it, so long as it's crafted in a way not to produce a syntax error under ECMA 262-compatible runtimes.)

This is not a very sensible claim. Take it in the context of the author's previous remarks:

This makes questions like “how fast is WebAssembly” a bit hard to answer. You don’t ask how fast algebraic notation is—it’s not a very sensible question.

Taken in the context of something like JavaScript, the language is only as fast as the engine running it.

There's nothing inherent to JavaScript that demands (or even whispers suggestively) that you should ignore the advice of the sort in the linked article, "my own talks often boil down to Hulk-style «ONE TYPE GOOD. TWO TYPE BAD!!!»"

This links to tesseract.js, which is an Emscripten-compiled project that predates WebAssembly by several years.

Good.

I've probably read this post half a dozen times over the last 10 years.

This is the first time that I've noticed (and—now—am able to appreciate) that this paragraph is deliberately crafted to, in part, have the same effect as what it's actually describing.

s/JS/NPM/

It was "e18e" https://e18e.dev.

See commit 03edd03c3268.

For comparison, ANPD—describing a static site generator as an LP doc that I published in response to Jared's Show HN thread for md2blog, is 126KB. It requires no compiler, because it uses the browser's JS runtime to execute (unlike md2blog, which requires you to download Deno or a binary with Deno embedded to run it).

Note also that the numbers here also differ from the ones Jared had at the time of publication, where he had originally written:

• It's ~270 KB (static binary + templates for this site, gzip compressed)
• It builds my ~140 page site in ~150 ms (wall clock time, on an 11-year-old old laptop)
• It performs acceptably on a 28-year-old laptop, running NetBSD (Pentium 166 MHz)
• It's trivial to compile, requiring only a C compiler, make, and sed

This appears to be an error, as doi:10.1145/234286.1057836 today leads to a chapter in HOPL II for "A history of C++: 1979–1991" (and indeed the authors have linked to it under the appropriate entry elsewhere in the works cited section of this paper).

This is:

Cox, Brad J., Steve Naroff, and Hansen Hsu. 2020. “The Origins of Objective-C at PPI/Stepstone and Its Evolution at NeXT.” Proceedings of the ACM on Programming Languages 4 (HOPL): 82:1-82:74. https://doi.org/10.1145/3386332.

by which the author means the types of wikis that aren't wikis.

This perhaps puts things "in perspective", but somehow in a way that the author avoids attaining the (or, if you prefer, demonstrating) the corollary self-awareness that one would expect (having had things put into perspective, and all).

Now that's some solipsism.

I wish people's works were more online—more accessible (preferably, with stable, citable URLs). But to say that the people themselves should be more public in the sense that the author means here is just a continuation-without-lessons-learned of the modern (Facebook and onwards) social networking era.

It's great if all of a person's contributions to, say, mailing lists are preserved and available—and aren't just holes, missing from the record.* That's different from whether or not it's great to be able to click on that person's name, find a profile page for them, and then encounter an exhaustive, reverse chronological feed of all of their activity across all mailing lists. Mailing lists rarely enable this, but virtually every modern social network does, and they're actually built around it.

The former is topic-based indexing, and the latter is actor- (person-) based indexing. Actor-based indexing is bad, and we know that it's bad.

Actor-based indexing is like running into someone you know (or a stranger, even) at the post office and then, through some mechanism where their physical presence wired to some metaverse data source, being able to perform some tap/gesture at the virtualized floating bubble over their heads that lets you see all the public places where you would have seen them earlier that day if you had been at any one of those, and then having a log of every interaction for the day prior, and the day before that, and so on, stretching back over their entire life, including the grocery store, the restaurant, the houseparty they were at, their work, etc. This would be bad. That means it's not good. And it's not good "online", either, for the exact same reasons.

* as unfortunately, many Mastodon (and other ActivityPub-powered) interactions turn out; Mastodon happens to achieve the worst of both worlds!

This is available at UT PCL:

https://search.lib.utexas.edu/permalink/01UTAU_INST/3307f/alma991020623129706011

That's "garbage-collected language implementations" (or, in this context, just "garbage collection").

Programming languages are languages. They're notation. They're inert. They can't have garbage collectors.

The presence of GC is a memory management implementation strategy—a choice—of a given programming language implementation. C, for example, is neither a "garbage-collected language" nor a "non-garbage-collected language".

GCC doesn't have a garbage collector for C programs, and neither does Clang, but GCC and Clang are not "C"; C is a programming language, and GCC and Clang are programming language implementations. You could write a C implementation in the vein of SpiderMonkey or the compiler/runtime from the golang.org toolchain (one designed to parse and run programs written C instead of JS or Go) if you wanted to.

I mentioned Rhesus ladders in another comment (https://hypothes.is/a/gvP9DmJfEeyj-zfV0Z4Zsw) and also the relationship to Chesterton's fence in reply to a comment from someone else (https://hypothes.is/a/r7YFemJgEeymEnOBlFNH5A), but this captures the spirit of my comments elsewhere about false diagnoses perfectly.

Suggestion:

Given a URL, check whether a page (specified by another URL or by file upload) links to that URL, and if so where/how.

Not quite.

You can, you just can't easily do it with with clang or GCC.

This is a long-standing problem with compilers that the Zig folks and the Go folks have thankfully recognized as silly and decided to approach in a different way within their respective ecosystems.

NB: "davidy123" is vid

Crenshaw's humility notwithstanding, I'm frequently caught off guard by frequent interactions with people whose conversational posture reveals that they have a similar conception of software like, say, Windows—their comments a manifestation of a seemingly total unwillingness to confront the fact that, no, some observable behavior in software isn't just how computers work, but that someone—a human programmer—sat down and decided to make it work that way—that it isn't just some natural property of computers that someone has coaxed out of one, and that other instances of software creation are not mere parlor tricks. They're procedures. They have to be conceived of and then worked out and (ideally) made airtight against a whole range of conditions.

It's rather more a testament to the durability of W3C standards generally—something that is now under attack by WHATWG member orgs.

This entire section is plagiarized from Eliason. Bizarre.

This doesn't follow.

It's way easier for a mediocre programmer to tune the naive implementation of a program in order to sidestep some of the GC costs than it is for the same programmer to pick up and capably wield a "lower-level language" that requires manual memory management. Anyone with the skills to do the latter is going to be capable of the former.

It's recursion:

https://hypothes.is/a/nxL8dNRmEfCKiQNmvuH9VQ

Note that in addition to the followup that the author has added to this article (in Feb 2025), he has written a subsequent Tutorial on CWEB article.

Does it defeat the purpose, or is it a form of redundancy?

Same.

I'm amazed by the number of programmers who, having already written down how the problem gets solved, attempt to document/comment their code and don't realize that this is what should be their fundamental concern—what problem does this solve?

huh?

It's common enough to wonder about function behavior on null, undefined, etc., so consider "an LSP" (read: editor plugin) that could synthesize these annotations and insert the appropriate disclosure/disclaimer at the head of the function like this.

Sheon Han proposes something similar in Wired in February 2023: Software Criticism. https://www.wired.com/story/software-criticism/

The problem with this page is that the author is playing fast and loose with the words "parser" and "parsing". It's also not totally honest (or is yet again confused) about e.g. what the IETF RFCs say about parsing high precision numbers.

It doesn't. No one should be relying on archive.is to fill this role today. It's like never putting a passcode on your phone and just treating it accordingly—as an insecure/untrustworthy device—or proactively working to revoke a leaked API key as soon as you discover that it has been leaked and just assuming that a malicious actor has already come across it and is planning to put it to use even if they haven't already done anything.

Pre-emptive note: it seems logical that the very next paragraph references Paul Graham directly; my very next move was going to be to connect the writer's self-reported experiences here with Graham on writing, had it not been the case that that job was already done.

As I've said before: I'm not in the same boat with Graham on the writing-is-thinking stance. The difficulty with seeing my own thoughts fixed in words after an initial pass is not in their inadequacy or their being a source of illusory and fleeting comfort with said illusion now made stark for everyone to see, but a mixture of (a) a lack of "punch", and/or (b) the places where a dishonest broker could exploit the yet-to-be shored up wording to suggest/assert the presence of some weakness in thought regarding the thing being argued for, where such purported weakness would be the real illusion.

The lack of satisfaction I feel when trying to capture my thoughts in English (my first language) isn't too far off from the lack of satisfaction at being able to comprehensively express a simple declarative in another language only because of the fact that don't know, say, the right word for the noun in that language. It doesn't lead me to agonize about how well-supported my observations about a backhoe are just because I've never been introduced to the word for backhoe in that language.

Following the demise of botsin.space (cf https://muffinlabs.com/posts/2024/10/29/10-29-rip-botsin-space/), the author evidently has the bot now posting to https://mas.to/@SecretlyPublicDomain instead.

Traveller:

You are looking for https://mas.to/@SecretlyPublicDomain.

I find it strange that this number differs from the one given on the previous page ("Totals...[…] 21,533").

Point 4.c. does indicate that "102 claims were rejected", but this is not the same the difference observed (which is 92), and it's stated that the 102 rejected claims come from "a survey [i.e. sample] of some 10,000 renewal applications".

This is a curious claim that I cannot substantiate. After looking around, I see the same claim in Wikipedia's article for Copyright renewal in the United States, but the cited source (Fishman, Stephen; 2010. The Public Domain: How to Find & Use Copyright-Free Writings, Music, Art & More) doesn't appear to provide a robust citation. (On page 287 in Chapter 15, Fishman writes, "The Copyright Office estimates that only about 15% of pre-1964 published works were ever renewed", unaccompanied by a footnote.) One also notices that 1961 and 1964 are not the same year.

I stumble across a similar claim ("a 1961 report from the U.S. Copyright Office estimates that 85% of the books never had the copyrights renewed") on lcgsco.org, which disappointingly turns out to be the website for "Larimer County Genealogical Society", with no link to the report in question.

The Copyright Office does make available its historical archive of annual reports at https://www.copyright.gov/history/annual_reports.html. Could its annual report be the one referred to? Searching for the string "renewal" in the 1961 annual report turns up two noteworthy occurrences (out of a reported nine):

1. on page 2, a claim related to renewals mentioning a "15 percent" figure

2. on page 16, a description of "Studies 29–31 [… including …] 31. Renewal of Copyright"

The full sentence on page 2 where the "15 percent" figure appears is actually that "The year's increase in registrations was nearly 3 percent, this was counting a 15 percent decrease in renewal registrations, the result of the corresponding decrease in original regisrations 28 years previously." This is, troublingly, not the same thing as fewer than 15% of copyright registrations until 1961 being renewed. (It is not even the same as only 15% of registrations up for renewal in 1961 being renewed.) It is a 15% decrease in renewals relative to the prior year, i.e., number of renewals in 1961 compared to the number of renewals in 1960. If this is the report that the is meant to be the source for those claims of 85% non-renewal, it then it fails verification.

I have also come across a reference for renewal figures in a 2008 article in D-Lib Magazine (Peter B. Hirtle, "Copyright Renewal, Copyright Restoration, and the Difficulty of Determining Copyright Status"). Footnote 4 there cites the same Study 31 (attributed to a Barbara Ringer). Interestingly, it is not cited as a way to substantiate the 15% claim, but instead that "only 7% of registered copyrighted books" were renewed. It's not clear from context whether that claim is meant to be about the full range of potential renewals up to 1961, or merely the subset of works up for renewal in 1961.

At the time of this comment, I have not yet looked into Study 31 itself. I expect it to contain answers.

I've come across lots of claims online (e.g. https://lcgsco.org/the-majority-of-books-published-before-1964-are-free-of-copyrights/ and the current revision of the Wikipedia article on copyright renewal in the United States) that "A US Copyright Office study in 1961 found that fewer than 15% of registered copyrights had been renewed". I haven't been able to substantiate this claim, however.

Could this passage be the source? It clearly doesn't line up with the claim.

It's nuts that this has to be said.

/u/Choperollo describes something for which we have no name and would not be accurately described as a dogwhistle but still shares some similarities and is now common/prevalent enough that we would perhaps benefit from being able to refer to it by name to discuss it.

This is belied by earlier admission about how he's putting the library to work, at his work (and which even uses the word "professional"!).

I have not come across that. I have only come across an allergy to GPLv3 in particular. And all those companies are seemingly happy to continue shipping GPLv2(+), as the next sentence indicates re Apple.

I dunno. "Is this licensed as GPLv2-or-later (or compatible)?" still works (and is really the same question that was being asked all along)—nothing really has changed (except for the proliferation of projects that are a GPL for which the relevant answer is "no"—but, still, the question didn't change).

This page is a great example of why I don't use GitLab.

WTF.

"settlement"?

Why shouldn't the resolution be available for reading at archive.org?

From an optimistic perspective:

~10 articles per month sounds like the perfect publishing pace for a blog, and more academics should be blogging.

What if the submissions to the aforementioned low-quality journals were just a bunch of 6 pagers that were actually originally intended for syndication to the author's website and also just happened to also get wider distribution in those suck journals?

And a separate question: might it be conceivable that this could turn out to be an effective way to actually bootstrap high-quality research output and a healthy ecosystem of professional/academic blogs (in the vein of the parable of the pottery class https://austinkleon.com/2020/12/10/quantity-leads-to-quality-the-origin-of-a-parable/)?

It would be nice to be able to have good subject lines. I'm thinking that if you register your form, then you should also be able to register a template string that can be used to build a good subject line (like "Riku key request for riku@x.colbyrussell.com"—built from Riku key request for ${email}).

What many analyses fail to highlight is that NPM has been sending a lot of really pushy emails about two-factor authentication settings over the last couple years.

Perversely, this cargo culted best practice led to worse security.

Perhaps the most irresponsible thing of the last week is that among possible mitigations, to give priority to exercising even more features of the poorly conceived package.json-based system, especially where it is redundant (but inferior) to a mitigation scheme that consists of checking the given source code revision into the revision control system.

This omission is especially absurd in relation to stuff like the has-ansi package, which hasn't had a substantial change in years.