Lots of second panel thinkers in these comments. Great case study.

So make your application document-driven (i.e. actually RESTful).

It's interesting that we have Web forms and that we call them that and yet very few people seem to have grokked the significance of the term and connected it to, you know, actual forms—that you fill out on paper and hand over to someone to process, etc. The "application" lies in that latter part—the process; it is not the visual representation of any on-screen controls. So start with something like that, and then build a specialized user agent for it if you can (and if you want to). If you find that you can't? No big deal! It's not what the Web was meant for.

So don't.

I'm going to guess this is CSP-related breakage and guess further that the bookmarklet does not really do any work except inject script element that tries to load a Pinboard-hosted script.

There are ways around this, but no one seems that interested...

What a shame that they went with Python, rather than something that can already run directly in everyone's reader app.

I've mused about how installing a server-backed Web app (or server-side support for a given protocol) might be made as simple as saving a copy of a Word document or a copy of a PDF that someone has emailed you.

Consider MediaGoblin, which is the original context where I wrote this down.

The thing is is that MediaGoblin is written in Python; if you want to "deploy" MediaGoblin, you must deploy a Python app. I don't like that. Imagine instead of you "deployed" an app by installing its set of manuals

The idea is that you have a document that describes the MediaGoblin application—the software manual. Now imagine that manual were sufficiently detailed so that a person reading it were able to independently re-implement it. If you actually wanted someone to re-implement it, you could do worse than to give them a copy, with the expectation that they'd study it and it would be sufficient for them to learn how to go about making a MediaGoblin clone.

Suppose you didn't give it to a person, though, but you wanted to "teach" your server how to act like a MediaGoblin instance. Shouldn't we aim to make it as straightforward as being able to give your server a copy of the manual?

Prior art: - Rob Pike's talk about the Go compiler, and the way he references the ability to ingest PDFs of vendors' manuals and grow a new backend for the compiler - The VPRI/STEPS approach to a TCP stack - Literate programming

Aral Balkan's personal (single-user) Mastodon instance costs him ~50 EUR per month to run.

This list is missing https://smol.pub

I've mentioned before (most recently, I think, in a response to the Postcard creator) that it feels a little scummy to demand people pay to be able to use custom domains. It's like holding someone hostage and demanding ransom for their release.

I've thought about alternatives. I won't mention past ones here. Instead I'll sketch out a new one.

1. Sell support billed at a realistic rate, considering the costs (e.g. a flat price of something like $125 for up to ~2 hours), where buyer pays upfront

2. Maybe throw in a domain for "free" (i.e. included), so if the buyer isn't already bringing their own, they'll have one by the end

3. Any unused balance (e.g. completion of support task only took half an hour) gets credited to the account

4. Set up a wiki (a real wiki—not a GitHub-style anti-wiki) for the documentation; point out that it's in folks' best interests to help each other out and keep it up to date and even record their own notes for their own setup here if they want to avoid paying the support fee

The idea is to charge a high enough upfront fee for something that may not immediately consume up to its budget cap—such that you can, over time, recover own investment while making it feel like the buyer is getting all the value out of their payment.

Pretty bang-on.

Try https://katelynlemay.com/

You're looking for https://artifex.org/~bonnie/InvisibleW.html

Although, notably, that process, if very involved, can be captured in a separate document.

The big takeaway—in a world increasingly obsessed with apps (to the point that even things that originally were and still should be documents end up being conceptualized as apps—and all the downsides that comes with re mental guardrails).

See also: gradual typing

This particular example is pretty sleight-of-handy; there's a double standard being applied here.

And here's why https://guzey.com/follow-up/.

There are lots of people who think the way that Alexey Guzey does: "A story: when I wanted to meet with a really busy friend of mine in SF, I first sent him 2 twitter DMs, then 2 emails, and then 3 text messages, letting him know that I will keep sending one text a day, until an email from him finally landed in my inbox letting me know that he would love to get lunch."

There are also lots of people who think they way that Heather Arthur does: that simply not replying is an adequate signal.

I find both to be contemptible.

Great metaphor.

contradictory sequence of words

Use of Docker makes for immediate negation of "easy". At best you can say that it's easier than some other, more difficult thing, but it's not "easy". If you do, then you've got your thumb on the scale, you're doing some Hollywood-style accounting, etc.

It's not. The Hypothesis sidebar loaded from a bookmarklet is a Hypothesis client, ergo it is possible to create a hypothesis client that lives in a single file (say client.html with all scripts inlined) that can be loaded directly from the disk (or dumped onto a host that offer simple, static Web space), and even opened up in a text editor to be read/edited by hand.

That's a good reason to make sure it's verified by the compiler (or, if you prefer, that the project source code is validated against the documentation)—not dissimilar from the way compilers' typecheckers already work.

See above https://hypothes.is/a/YInIGFvMEe2Z3G-_AAsduQ

On the other hand, those features may have actually sent us back.

See https://news.ycombinator.com/item?id=11381716:

if I can't make sense of it and be productive in it with just vim, grep, and find, your code is too complex

I'd be willing to relax the requirements (or should that be "tighten" in this context?) and say that even grep and find should not be necessary, either. That's one of the worst parts about working with C or Go codebases—having to resort to each just to figure out where stuff lives. The circumstances that lead to "A lot of engineering is looking for things" are something that we should be trying to rectify, not accommodate.

See below https://hypothes.is/a/sSSKKFvNEe2UV99rNBoV0Q

One of the most important questions (if not the most important question) to keep in mind when writing code comments. This is what you should be seeking to answer.

This project gets it backwards.

We should not be writing in compiled languages with inline type annotations a la TypeScript and generating documentation from that (the same thing javadoc did 20+ years ago). We should be writing ordinary docs and working with tools that can ingest those, extract the information contained there, and validate the codebase+docs combo for coherence.

If you are seeing this message, try joining the triplescripts.org Hypothesis group.

Related: * https://hypothes.is/a/p6VM5rswEeyqyks2ynu8Bg * https://hypothes.is/a/vcKzHElbEeuSGo9Gi3k3Ng

You need to be in the triplescripts.org group to see this annotation.

Membership is semi-private, but only as a consequence of current limitations of the Hypothes.is service.

A copy of this annotation has been published in the Hypothes.is Public stream, which explains in detail that anyone is permitted to join.

Not so dissimilar to today (minus the taunting). Despite the ubiquity of what is loosely called the Web platform (i.e. the world accessible through ubiquitous, roughly W3C-/WHATWG-compliant browsers), the Web fundamentals that TBL originally wrote about in the early 90s has still yet to be embraced.

The error lies in the decision to alias /resource access to the contents of /resource.html. That's something that should not happen. It's as straightforward as that.

This is the key. It follows that the same results, then, could be seen if we devised a way to communicate the same desires to the machine when we're dealing with JS. (My preferred thought experiment: imagine a docs/ directory in the repo where these sorts of things are documented for the benefit of other programmers—alongside any other rationale that you would naturally hope to communicate as well—and that the computer itself were made to be able to read and act upon the very same documentation to guide its behavior.) See http://cr.yp.to/qhasm/literature.html

I have referred to this in the past as an emphasis on actor-based indexing, versus topic-based.

Why are people so seduced by this dumb argument—to the point that they almost seem proud of it?

First, it's presumptuous. Who says we're even using glibc instead of some other libc—which I just might choose to include in the projects I work on? Who says we're even using Linux, for that matter?

Secondly, even if we were, let's assume that we're not, and then see if that teaches us anything about the overall line of reasoning. The original comment was about NPM. NPM is used a fair bit for not just backend stuff but for managing packages used in the browser, too. Let's assume, for simplicity, that our program is entirely a browser-based JS+HTML+CSS app with no backend to speak of. Would the same people argue that, among other things, the Web browser sources would need to be included? Does it even make sense to argue that? Asking the system software question betrays a failure to accurately grapple with the classes of software artifacts we're dealing with, their role in the overall project, and our responsibility for them.

I think this is a terrible choice for "another example" (that is presumably supposed to be easier to follow in order to communicate what the curse of knowledge is). This whole paragraph should have been cut (or at least replaced with something better).

There's the honest part. It's a rhetorical sleight of hand meant to confer an advantage to the person rewriting the others' actual words—which, to repeat, would not be necessary if the two were actually "n[o]t significantly different" in the first place.

There's now a "long, 50+ comment chain" attached to the false quote. If this isn't sufficient to catch the eye and serve as a flag that the thing that you're saying they said isn't actually what they said, then there's no hope for agreement.

Once again: have some self-awareness.

Yes it does. Shutting down low-effort, Twitter-level dunking built upon made up quotes is worthwhile all on its own. And as a rule that when enforced minimizes confusion and mendacity, it's doubly worthwhile.

It's sorted. There's just a contingent pretending that there's something about it that isn't.

Yes.

Yes.

Yes.

Geez. Have some self-awareness, bud.

There's nothing idiosyncratic about saying that you should distinguish quotes from non-quotes by abstaining from formatting the latter the same way as the former.

Use quotation marks to make it clear you're quoting somebody if you want. If you're not quoting somebody, don't do that. Don't build up a caricature based upon you would have liked for them to have said (so it's easier to pillory) instead of what they actually said.

This shit's easy.

In that case: great! no problem, then—just use the original wording, since by your own argument they are not significantly different; the original is sufficient.

Lots of comments here reminiscent about this restatement of the true purpose of the free software movement:

I know it's socially acceptable[...] to dump on Stallman's "software freedom"—or at least the choice of words to describe it—but this is exactly the kind of thing that it is meant to address. Superficially, Signal might look like it has the right accoutrements, having adopted a FOSS license and all, but it's not free software. Nothing that holds folks' systems and data hostage unless you comply with the program author's whims can be considered FOSS.

See also: Why Open Source Misses the Point of Free Software

When people, in response to some problem, just end up restating the problem factors as if it explains or addresses anything at all.

No.

I don't know why they wrote this; they know this isn't true. It's not just a case of me being a stickler/pedant. This example should have simply never been used.

Perhaps that should be addressed, rather than treating it as bedrock upon which to build.

Having only recently "got" what Wirth originally meant when he wrote about texts in Oberon as abstract data types, I'm sort of partial to something like that.

nit: should be "to roll back" here

The running program, that is (as just described).

Reminiscent of The Pinocchio Problem.

Reminiscent of the distinctions Martin Fowler makes on Projectional Editing.

@1:10:20

With HTML you have, broadly speaking, an experience and you have content and CSS and a browser and a server and it all comes together at a particular moment in time, and the end user sitting at a desktop or holding their phone they get to see something. That includes dynamic content, or an ad was served, or whatever it is—it's an experience. PDF on the otherhand is a record. It persists, and I can share it with you. I can deliver it to you [...]

NB: I agree with the distinction being made here, but I disagree that the former description is inherent to HTML. It's not inherent to anything, really, so much as it is emergent—the result of people acting as if they're dealing in live systems when they shouldn't.

@48:20

I should actually add that the PDF specification only specifies the file format and very few what we call process requirements on software, so a lot of those sort of experiential things are actually not defined in the PDF spec.

See also:

Alas, many things really must be experienced to be understood. We didn’t have much of an experience to deliver to them though — after all, the whole point of all this evangelizing was to get people to give us money to pay for developing the software in the first place! [...] When people ask me about my life’s ambitions, I often joke that my goal is to become independently wealthy so that I can afford to get some work done. Mainly that’s about being able to do things without having to explain them first, so that the finished product can be the explanation. I think this will be a major labor saving improvement.

From http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/

The metadata for this collection are not so great. Have a look here, instead: https://archive.org/details/pub_whole-earth

High fidelity scans are available at the Internet Archive: https://archive.org/details/sim_whole-earth_spring-1987_54/page/n3/mode/1up

This quote is introduced without a clear antecedent. What is it a reference to?

@55:10

Sri: [...] you can think about the possibility that we're actually going to do this with structured data but then properly incentivizing people in order to actually moderate and curate the set of facts about the world—

Will: Yeah, so I was gonna mention that, and I'm glad we're on the same wavelength here. What are the economic incentives that would help encourage the adding of correct, factual data to this knowledge graph and dissuade, I guess, spammers? [...]

Sri: Yeah, I think that there needs to be some compelling reason for people to want to add data to the knowledge graph. [...] I think that, "Can we get a knowledge graph that is expansive—as expansive as Wikipedia—that, you know, says all kinds of facts about the entire world?" Yeah, maybe[...]

Will: There are parts of the Web where people do that without financial incentives. I mean people list like every episode of, I dunno, Game of Thrones and annotate every time that people get killed or [...] all sorts of stuff. Fandom is like [a] huge thing and they just put out these... or like the—if you ever played Minecraft and looked at the Minecraft wiki, it's just so (chuckles) so detailed. Like, "Who spends all their time...?" [...]

Sri: The idea of fandom actually is very relevant here, because [...] I have so far been thinking about the idea that the incentives have to be backed by some type of economic value—

Will: Yeah, for a certain class of things [...] There are some things that are very well-tuned to economic incentives and the other stuff is well-tuned to fandom, right?

Video available here: https://www.youtube.com/watch?v=bjn5jSemPws

For checking which posts are new/updated, this is always the case. The only thing the HTTP cache-related headers can tell is that the feed itself has/hasn't changed.

Huh?

Bluh? This is exactly what looking for link[rel=alternate] is for—these "patterns" listed are arbitrary URLs...

Crazy! This underscores how badly Mastodon—and ActivityPub, generally—need to be revved to enable network participation from low-cost (essentially free) static* sites.

* quasi-static, really—in the way that RSS-enabled blogs are generally considered static sites

⬑ what khinsen calls software collapse

• limit capabilities it depends on (POLA)
• target the World Wide Wruntime (i.e. the browser), which is the only reliable platform that exists and can be expected to exist in the future

⬑ "The Code Rot Problem"

This page has a neat effect, first apparent with this example, where a blur effect is used on most of the text in the code block, except for lines 11–13 which are shown in sharp focus. (You can mouse over the code block to eliminate the blur effect.)

.torchlight.has-focus-lines .line:not(.line-focus) {
        transition: filter 0.35s, opacity 0.35s;
        filter: blur(.095rem);
        opacity: .65;
}

Each line is dumped into a div and the line-focus class set on those which are supposed to be unblurred.

(For ordinary code blocks without any blur/focus effect, the has-focus-class line is simply not used.)

This doesn't need to happen, and wouldn't happen if people treated blog posts for what they are—artifacts—instead of conceptualizing them as live systems.

That's not good.

The phrase "optional dependency" is an oxymoron.

The answer is ZIP and wget/curl and forgetting about sharing dependencies. Disk space is way cheaper than the time spent (often in frustration) trying to get something to work.

Not angling towards that sort of future is a lot like people from the punch card and paper tape era not allowing the computers do the stuff that computers do better than humans when it became cheap enough to let computers do it.

Good response overall, but with respect to this remark, I have been in different but not dissimilar situations where something like this does happen.

E.g. person notices that every time they enter a room (kitchen, let's say) everything looks just like it did the last time they saw it, and they aren't ever interrupted e.g. by my trying to use the space at the same time that they are. They then (incorrectly) conclude that it looks that way because I just never use that space (and it's okay for them to make a mess, or not worry about being mindful of how much time they're using the space for)—rather than registering the thought, "Gee, he really picks up after himself and tries to stay out of the way—a real life example of 'you won't even notice I'm here'. Maybe I should be that considerate."

@35:19

"This is how the working classes are robbed. Although their incomes are the lowest, they're compelled to buy the most expensive articles[...] the lowest priced articles. Everybody knows that good clothes, boots, or furniture are really the cheapest in the end, although they cost more money at first; but the working classes can seldom or never afford to buy good things. They have to buy cheap rubbish which is dear at any price."

@31:25 Robert Noonan's story.

Type-B procrastination accounts for a lot of the junk I see on people's GitHub timelines—and that type of social network-backed gamified gratification is why I've adopted a stance where I impose a huge entry fee on any workflow that routes itself through GitHub's servers.

Every time Bill Maher goes off on a tear about how American society should venerate old people the same way it happens in other countries, I can't help but think, "What 20 year old was Bill trying to fuck this week that led to these hurt feelings?" I'm picking up hints of that here, too.

Is this Paul's way of getting out of responsibilities? "No, I don't need to do that. See? I wrote a piece about it!"

@55:39

I would feel a little bit sad, but at the same time, this is a pattern I've seen happen over and over again. And especially with these big ideas about computing and self-expression and things like that [...] people start with these huge, huge ideas, but I think that they are so different--the diff is so much between where society is now and what some of these people are thinking about--that the most that can be absorbed at one time is like one unit--one meme--from that whole big vision. So, we're just gonna take like one small step at a time, and [...] you kind of just have to accept that, you know, that's success.

Garner, Bryan A. "Celebrating Plain English in Michigan." ABA Journal 107.5 (2021): 36. Business Insights: Global. Web. 7 Oct. 2022. URL http://bi.gale.com.atxlibrary.idm.oclc.org/global/article/GALE|A690034782/c13f1855872f0a231a7139cf729c45b6?u=txshrpub100020

Document Number: GALE|A690034782

This does not bode well for the scope of the project.

Stupid comment. HEB is a South and Central Texas thing.

What about GCC? https://minnie.tuhs.org/pipermail/tuhs/2020-May/021225.html

Boy, this was hard to read. I've noticed a lot of Substack pieces that I've come across are written like this—tenuous, self-contradictory, and written in this voice. Very weird.

NB: the requirement wasn't actually "parsing JSON in C"; it's that for the JSON parsing the machine ultimately executes the same (or similar) instructions that it does when the JSON parsing is written in C and that C is compiled with GCC.

Lame. Esp. since GitHub Pages is a thing.

Current revision of README: https://github.com/t-mart/kill-sticky/blob/124a31434fba1d083c9bede8977643b90ad6e75b/README.md

We're creating a bookmarklet, so our code needs to be minified and URL encoded.

Run the following the project root directory:

$ docker build . -t kill-sticky && docker run --rm -it -v $(pwd):/kill-sticky kill-sticky

Disclaimer: I don't give two shits about the topic that is the subject of this post. However...

It would be feasible to get around this by 1. Separating your existing mobile app cleanly between client and content 2. Converting your client into a general purpose Web browser... that Tumblr (let's say) happens to work really, really well with

(This concludes this special bonus episode of Nathan For You.)

More seriously...

Frankly, we need a lot more opinionated, intelligent user agents that are thoughtfully designed act on the content in a way that fits the user's desires—rather than trying to conform to what other Web browsers feel like today.

It looks like gotostage.com keeps the Wayback Machine from getting a copy as a consequence of two things:

The server sends no real hypertext—it's all part of a JS bundle that builds the (scan) content in-place.

What the server does send is an invisible link to https://www.gotostage.com/honeypot, which the Wayback Machine's crawler will follow. Presumably, this flags it as a bot.

Video link (1:20:04) points to https://cdn.recordingassets.logmeininc.com/1270644358637705220/1204201970482829316/fb820e62-67ca-43c9-bab0-6c765ab5acaf/recording/3230979087624514052/transcode/3230979087624514052.mp4?Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHBzOi8vY2RuLnJlY29yZGluZ2Fzc2V0cy5sb2dtZWluaW5jLmNvbS8xMjcwNjQ0MzU4NjM3NzA1MjIwLzEyMDQyMDE5NzA0ODI4MjkzMTYvZmI4MjBlNjItNjdjYS00M2M5LWJhYjAtNmM3NjVhYjVhY2FmLyoiLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE2NjQ1NjIwMTJ9LCJJcEFkZHJlc3MiOnsiQVdTOlNvdXJjZUlwIjoiMC4wLjAuMC8wIn19fV19&Signature=Cj~BpP90aY6KOiBMeafsYwxPY-UB20vWeNSUqalooCRMOmnmByIZlXVLF-5dG-4J3CfkugZsLA28c6EWd5~QGH9nrpgZRzpn8I2mq7arfUpGER~FSXn-Tbuaqjyw9ObyY06QNNgszdxtSgKjeMA0mswKAZmq2RP4tgJf0ctKwlW8ASEVhfh-dceb-WcedEBaZSeqOyaaTK40wcY2n2EpBKpAKBwnFgST4LTOOmDB60UMvwMhL7dnjzzZTe8fesQgVV52LwOQkPt5A3CNUttt1wnHMiBdoe-M38Z8qCzY~WcyEcirzz0cnneXFpnE~GI4znPyzlHhfAAx7Dj8ud6m~g__&Key-Pair-Id=APKAI2Z3PWL3BWDDZ5IA&response-content-disposition=attachment

(The Wayback Machine has a copy.)

Redirects to https://gato-docs.its.txst.edu/jcr:cd5d535d-4892-4bd5-aa23-009f192d65b8/Civil%20Procedure%20%e2%80%93%20Tricky%20Issues%202020%20Handout%20Update%20.pdf (as of this writing).

Try https://web.archive.org/web/20111102182554/http://adamspitz.com:80/avocado#post-14

Presaging version control systems.

Typo in the tag here; "transculsion" should be "transclusion".

Well, the whole point of the Web was that everything would be given a (world-wide) identifier. Your current list of bookmarks has an identifier, but it's a local one. Once you have a world-wide identifier, it's only short jump to making it resolvable so that your bookmarks list has a URL, and browsing your bookmarks would be as simple as visiting that list.

Or read it here: https://archive.org/details/weavingweb00timb/page/n9/mode/2up

Pssh. 9-780062-515872 isn't the ISBN (which is 006251587X). It's the EAN-13.

No way. HTML is way better suited for it!

The fact that this book is an SPA—instead of just, you know, a bunch of web pages—is very annoying.

Totally screws up my ability to middle click the "links" in the TOC.

It also messes up the browser scroll position when clicking back/forward.

You're looking for https://www.science.org/doi/10.1126/science.98.2557.580.b, probably.

(This DOI, i.e. 10.1126/science.98.2557.580-a, is linked to from https://pubmed.ncbi.nlm.nih.gov/17835862/).

This is a massive failure of infrastructure (and education/"professionalism"—by and large, most people whose careers are in operating or maintaining Web infrastructure don't haven't been inculcated into or adopted the sort of "code of ethics" that sees this as a failure).

The thing might just be for something like the Internet Archive to get into training or selling professional services for handling companies' "Web presence, done the right way". (This is def. take some organizational restructuring, however.) I'd like to see, for example, IA-certified partner organizations that uphold the principles described here and the original vision for the Web, and professional associations that work hard at making sure the status quo improves a lot over what's common today (and doesn't slide back).

Hmm. I'm skeptical of the certainty with which this is said.

Given a series of trials the claim here is that if you took a blockbuster and released it for "free" (supported by ads) on YouTube) then the ad revenue even when multiplied by the greater number of viewers would not only not surpass ticket sales from the subset of the same viewers who'd be willing to pay for tickets, but that it wouldn't even be able to cover the production budget. That's both a strong claim and a claim that I'm not sure is correct. For comparison, Netflix (and even ad-supported streaming services, albeit ones with lower budgets) seem to do pretty well with just a fraction of the <$10-per-viewer take that makes up monthly revenue.

dubious

principle of least (literal) power

The notion of "productive consumption" has, for some people, an almost irresistible appeal.

There's a presumption here (and in the linked article) that those people want to talk to you—that they're just quietly suffering their desire to have some interaction with you, if only it were the case that you'd allow it. This is way more condescending than the thing that the article seeks to correct.

Thankses simply do not belong in a bug report. It's an almost surefire indicator that there's something wrong culturally and that your bugtracker isn't so much being used for bug reports as it is filled with support requests.

In other words, no to the rotten cultural expectations that are by far what you're most likely to encounter on GitHub. I promise—things really were so much better before it came along to try to be Facebook-for-software-development.

I think the default assumption that this is what's going on is a huge part of the problem. I see a similar thing happen on GitHub constantly, where project maintainers try to "upperhand" contributors, because they see the contribution as something deliberately undertaken to benefit the person who is e.g. submitting a bug report. This is a massive shift away from the spirit of the mid-to-late 2000–2010 era characterized by initiatives like Wikipedia (and wikis generally) and essays by Shirky on the adhocracy around the new digital commons.

Directly related to a question I posed a few years ago about who should really be funding open source. My conclusion: professional developers who are are most directly involved with how the source is put to work—and who benefit from this (in the form of increased stature, high salaries and bonuses, etc., in comparison to the case where the FOSS solution hadn't been available). This runs counter to the popular narrative that frames the employer as a "leech" and silent on the social and moral obligations of the employee who successfully captured value for personal gain.

It's like this: the company has some goal (or "roadmap") that involves moving forward from point A to point B. The company really only cares about arriving at the desired destination B. They negotiate with a developer, possibly one who has already signed an employment contract, but someone who is made aware of the task at hand nonetheless. The developer agrees to do the work meant to advance the company towards its goals, which potentially involves doing everything manually—that is, handling all the work themselves. They notice, though, that there is some open source software that exists and that can be used as a shortcut, which means they won't have to do all the work. So they use that shortcut, and in the end their company is happy with them, and they're rewarded as agreed (not necessarily at the end, but rewarded nonetheless with e.g. regular paychecks, but also possibly receiving a bonus), and they advance in their career. Who's extracted value from the work of the open source creator/maintainer here? Is it really just the company?

McQuaid seems to agree with my view, going by the way he (later) identifies both Bob and TechCorp as benefitting from Reem's work; cf https://hypothes.is/a/MBN0aDnuEe2aF8s2kWTPrg

See above.

You can check at uspto.gov. (The search engine is terrible, by the way.)

See below

visible-web-page looks to have been published and/or written on 2022 June 26.

I emailed Omar a few weeks earlier (on 2022 June 7) with with a link to plain.txt.htm, i.e., an assembler (for Wirth's RISC machine/.rsc object format) written as a text file that happens to also allow you to run it if you're viewing the text file in your browser.

(The context of the email was that I'd read an @rsnous tweet(?) that "stuff for humans should be the default context, and the highly constrained stuff parsed by the computer should be an exceptional mod within that", and I recognized this as the same principle that Raskin had espoused across two pieces in ACM Queue: The Woes of IDEs and Comments Are More Important Than Code. Spurred by Omar's comments on Twitter, I sent him a link to the latter article and plain.txt.htm, and then (the next day) the former article, since I'd forgotten to include it in the original email.)

JS engines are good from a technical perspective. The problem with JS is the Node/NPM culture.

Again: mostly enabled by the fact that he was young.

Another key ingredient. Society is participatory.

This is not to be discounted. Mentoring is a big deal generally, but a lot of what made this possible likely came from the novelty of dealing with a child. If you replace Kevin with, say, a 25 year old who is no more or less capable or committed, what changes is others' behavior in their interactions.

This design constraint is exactly what people are so bothered about 30 years later. Generality! Portability! That's why you don't get to exercise full control of the sort that your "native" stack would give you. It's also why the Web has not only endured, but has attained a level of ubiquity that is not matched by any other "platform".

• https://foldoc.org/Compound+Document+Architecture
• https://en.wikipedia.org/wiki/Open_Document_Architecture
• https://www.osti.gov/servlets/purl/5671048
• http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/vms/vax_document/AA-PB6KA-TE_DEC_ODA_Compound_Document_Architecture_Gateway_Users_Guide_199104.pdf
• VMS Compound Document Architecture Manual, Digital Equipment Corporation, Maynard, MA., December 1988

This touches on the subtle, underrated brilliance of Wikipedia's (mostly) flat namespace.

Intertwingularity is inescapable.

Thirty years on, we're still losing stuff. (You could even argue that the Web—as it has been put in practice, at least—has exacerbated the problem.)

Lots of the problems that Hypothesis runs into (incl. those described here in this post!) could be attributed to this. They could probably be neatly described in a volume titled "The Perils of Self-Publishing", in a section dedicated to the consequences of non-uniform practices.

Here's the Anno pitch deck: https://docdrop.org/pdf/Hypothesis_deck_22Aug-4b7ys.pdf/

Taken from Maciej Cegłowski https://idlewords.com/talks/website_obesity.htm.

common misapprehension; only command procedures are commands (not "everything")

helena-lang.org should host a demo in the form of a copy of the "meat" of the project that can run directly in the browser from the open web (ideally launched via a single button here on the homepage) without having to install an extension (or at least anything more complicated than a bookmarklet)

This highlights a problem with the Web: the fusion of document identifiers and the channel through which the (or "an") information/service provider makes it available.

Suppose stakeholder S wants to mirror a document D (published in an HTML-based format) originally distributed by authority A. This will probably involve having to touch D in order to rewrite links to point at S's copies of auxiliary resources instead of A's originals. Simply copying the representation's bytestream is not sufficient.

"[... temporarily]"

Wrong. Here, I'll show you:

Forget about AGI for a moment. Instead, pretend we're talking about pecan pie. Most people probably can't answer the question, "What would I recognize as a pecan pie?" (or a sandwich). And yet thousands of people are able to make (and thousands more people are able to enjoy) pecan pie all the time—probably every day.

This RFC lacks any acknowledgement of the text/uri-list media type.

Also: just don't take photos/videos and reduce your social media "footprint" generally.

Privacy-respecting alternatives don't address the issue raised earlier with the comparison to the celebrity iCloud leaks. Because, to reiterate, privacy and security are different things.

See: Surveillance Camera Man * https://boingboing.net/2012/11/02/surveillance-camera-man-wants.html * https://www.youtube.com/watch?v=X9sVqKFkjiY