13 Matching Annotations
  1. Jan 2023
    1. Software should be a malleable medium, where anyone can edit their tools to better fit their personal needs. The laws of physics aren’t relevant here; all we need is to find ways to architect systems in such a way that they can be tweaked at runtime, and give everyone the tools to do so.

      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)

  2. Dec 2022
    1. It feels weird to say this in 2020, when the idea was presented as fait accompli in 1997, but an enabling open source software movement would operate more like a bazaar than a cathedral. There wouldn’t be an “upstream”, there would be different people who all had the version of the software that worked best for them. It would be easy to evaluate, compare, combine and modify versions, so that the version you end up with is the one that works best for you, too.
  3. Jul 2022
    1. People only really contribute when they get something out of it. When someone is first beginning to contribute, they especially need to see some kind of payback, some kind of positive reinforcement, right away. For example, if someone were running a web browser, then stopped, added a simple new command to the source, recompiled, and had that same web browser plus their addition, they would be motivated to do this again, and possibly to tackle even larger projects.
  4. Jun 2022
  5. May 2022
  6. Apr 2022
    1. A big cause of complex software is compatibility and the requirement to support old features forever.

      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.

  7. www.research-collection.ethz.ch www.research-collection.ethz.ch
    1. Ihavelearnttoabandonsuchattemptsofadaptationfairlyquickly,andtostartthedesignofanewprogramaccordingtomyownideasandstandards

      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

    1. 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.

    1. work-around

      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`).

    2. Apparently there is a CSP ability to stop inline scripts from executing. I have not come across any sites that use that feature and/or the browser I am using does not support it.

      There're lots.

  8. Mar 2022
    1. To realize this potential, we must provide a medium that can be mastered by a single individual. Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be changed or that is not sufficiently general is a likely source of impediment.
    1. Whether to inject behavior into a Web page is my choice. How I do so is nobody's business. If a need that can be met with a bookmarklet instead requires a set of browser-specific extensions, that's a tax on developers.