TRSP Desirable Characteristics The basic services of PID registration and resolution SHALL have no cost to end users.

Counterpoint: the judicious use of abstraction is/can be, in some instances, the solution to giving users agency and reconfigurability.

Software that has to be torn down is the result of software built upon bad abstractions. Abstractions are not ipso fact bad. They just need to be chosen on the criteria of whether or not they solve a problem.

This comment is close, but it's also about control.

It's clear that gklitt is referring to the ability of extensions to augment the browser, but: * it's not clear that he has applied the same thought process to the extension itself (which is also software, after all) * the conception of in-browser content as software tooling is likely a large reason why the perspective he endorses here is not more widespread—that content is fundamentally a copy of a particular work, in the parlance of US copyright law (which isn't terribly domain-appropriate here so much as its terminology is useful)

From a gradual enrichment standpoint I understand but from a data entry standpoint this seems like more work.

Previously: Open Source Is Not Enough and Free software is not enough: on practical user freedom.

See also: "Even GNU's philosophy has a few puzzle pieces missing from the box."

See also: The Pinocchio Problem

See also; plugging these: * A new publishing discipline * plain.txt.htm (An assembler)

This is an excellent piece, even though the writing is (probably intentionally) in places too obscure.

See also An app can be a home-cooked meal along with this comment containing RMS's remarks with his code-as-recipe metaphor in the HN thread about Sloan's post:

some of you may not ever write computer programs, but perhaps you cook. And if you cook, unless you're really great, you probably use recipes. And, if you use recipes, you've probably had the experience of getting a copy of a recipe from a friend who's sharing it. And you've probably also had the experience — unless you're a total neophyte — of changing a recipe. You know, it says certain things, but you don't have to do exactly that. You can leave out some ingredients. Add some mushrooms, 'cause you like mushrooms. Put in less salt because your doctor said you should cut down on salt — whatever. You can even make bigger changes according to your skill. And if you've made changes in a recipe, and you cook it for your friends, and they like it, one of your friends might say, “Hey, could I have the recipe?” And then, what do you do? You could write down your modified version of the recipe and make a copy for your friend. These are the natural things to do with functionally useful recipes of any kind.

Now a recipe is a lot like a computer program. A computer program's a lot like a recipe: a series of steps to be carried out to get some result that you want. So it's just as natural to do those same things with computer programs — hand a copy to your friend. Make changes in it because the job it was written to do isn't exactly what you want. It did a great job for somebody else, but your job is a different job. And after you've changed it, that's likely to be useful for other people. Maybe they have a job to do that's like the job you do. So they ask, “Hey, can I have a copy?” Of course, if you're a nice person, you're going to give a copy. That's the way to be a decent person.

Interesting that this is written by a BSD guy.

similar to my strawman for language skins

Why is Standard Ebooks sending content-security-policy: default-src 'self';? This is not an appropriate use. (And it keeps things like the Hypothesis sidebar from loading.)

Kartik made a similar remark in an older version of his mission page:

Open source would more fully deliver on its promise; are the sources truly open if they take too long to grok, so nobody makes the effort?

https://web.archive.org/web/20140903010656/http://akkartik.name/about

I don't think so. I think it's rather the opposite. Churn is one of the biggest causes for what makes modifying software difficult. I agree, however, with the later remarks about making it easy to delete code where it's no longer useful.

I have learnt to abandon such attempts of adaptation fairly quickly, and to start the design of a new program according to my own ideas and standards

Feature request (implement something that allows the following): 1. From any page containing a bookmarklet, invoke the user-stored bookmarklet בB 2. Click the bookmarklet on the page that you wish to be able to edit in the Bookmarklet Creator 3. From the window that opens up, navigate to a stored version of the Bookmarklet Creator 4. Invoke bookmarklet בB a second time from within the Bookmarklet Creator

Expected results:

The bookmarklet from step #2 is decoded and populates the Bookmarklet Creator's input.

To discriminate between invocation type II (from step #2) and invocation type IV (from step #4), the Bookmarklet Creator can use an appropriate class (e.g. https://w3id.example.org/bookmarklets/protocol/#code-input) or a meta-based pragma or link relation.

Bookmarklets and the JS console seem to be the workaround.

For very large customizations, you may run into browser limits on the effective length of the bookmarklet URI. For a subset of well-formed programs, there is a way to store program parts in multiple bookmarklets, possibly loaded with the assistance of a separate bookmarklet "bootloader", although this would be tedious. The alternative is to use the JS console.

In FIrefox, you can open a given script that you've stored on your computer by pressing Ctrl+O/Cmd+O, selecting the file as you would in any other program, and then pressing Enter. (Note that this means you might need to press Enter twice, since opening the file in question merely puts its contents into the console input and does not automatically execute it—sort of a hybrid clipboard thing.) I have not tested the limits of the console input for e.g. input size.

As far as I know, you can also use the JS console to get around the design of the dubious WebExtensions APIs—by ignoring them completely and going back to the old days and using XPCOM/Gecko "private" APIs. The way you do is is to open about:addons by pressing Ctrl+Shift+A (or whatever), opening or pasting the code you want to run, and then pressing Enter. This should I think give you access to all the old familiar Mozilla internals. Note, though, that all bookmarklet functionality is disabled on about:addons (not just affecting bookmarklets that would otherwise violate CSP by loading e.g. an external script or dumping an inline one on the page`).

There're lots.

What is End User Computing (EUC)? Thanks to the progressive introduction of DevOps, attention to the role of the end user in software development and testing has increased significantly. It is now important to think like an end user when we develop and test software. After all, that's what we're all doing it for.

Accessibility is more important, after all, than Kartik says it is (elsewhere; cf recent Mastodon posts).

How to get remote control over the Hypothesis sidebar (one way, at least):

1. Use the bookmarklet to open the sidebar
2. Click the sidebar's "Help" icon in the top right
3. Right click the "Help topics" link and select "Inspect" in the context menu to open the element in the browser devtools
4. Remove "noopener" from the link (easiest way is to just delete the element's "rel" attribute)
5. Change the link target to something other than "_blank" (e.g. "foobar")
6. In the sidebar, click the now-modified "Help topics" link
7. For good measure, in the new tab that opens, navigate to the same URL loaded in the sidebar (should be something like https://hypothes.is/app.html with a site-specific URL fragment; you can get the actual URL from the devtools JS console with document.documentURI, or right-clicking the sidebar and selecting "View Frame Info")

From the secondary tab ("foobar" opened by click in step #6) you should now have unrestricted, scriptable access to the DOM of the original sidebar iframe, using e.g. the JS console in devtools instance or a bookmarklet applied to the secondary tab—access it as window.opener.

Ungar, around @1:00:00:

I try to explain to people that the notion of compiler is broken. Of course I learned this from Smalltalk, but what we want to build is experiences--artificial realities that convince you that your source code is real. It's directly executed. There's no lag between editing and running[...] The environment stresses things in your program, not tools--which is another rant I have. It's this whole idea that we want to put you in an artificial reality--I got that from Randy [Smith]--in which it's easy and natural and low-cognitive-burden to get the computer to do what you want it to do, rather than running language translators that turn weird strings of text into bits the machine can run

Good. Don't. The number of people who think this is a virtue is frightening. The rationale is usually not well-reasoned and whatever values they pretend to hold can almost always be shown to be hollow.

The world could benefit from a curated set of bookmarklets in the style of Smalltalk ("doIt", "printIt", etc buttons) that you can place in your bookmarks bar (or copy into a bookmarks document and open in it in your browser), where the purpose would be to allow you to:

1. access a new scratch area (about:blank) for experimentation
2. make it editable, or make any given element on a page editable
3. let you evaluate any code written into the scratch space

scratch.js aims for something something similar, and though laudable it falls short of what I actually crave (and what I imagine would be be most beneficial/appreciated by the public).

This is what I'm aiming for with triplescripts.org. Initially, I'm mostly focused on the reproducibility the build process for software. In principle, it can encompass all kinds of use, and I actually want it to, but for practical reasons I'm trying to go for manageable sized bites instead of very large ones.

The word "technical" in this sentence doesn't seem to belong or to clarify anything. I think it would be clearer without it.

But I think I understand what he's saying, which is that technical details don't matter to the end user. They only know/see/care if it works or not.

"A multi-dimensional erector set that will go on forever..."

No, unfortunately not forever.