I really want to write more often, I'm not sure if it's that I don't know what to write about or that the idea of blogging doesn't come to mind easily when I'm doing things that I could blog about.
It helped me to make it really easy to get stuff out their: I just type a paragraph into Notion and it’s published automatically. Also, don’t think you need to publish long, polished pieces. Short texts to help build a habit. That one also helped me:
I used to have a Garmin running the Simply Late[0] watch face to achieve a similar goal. I wish there was something better on a more everyday-looking watch.
> Me: What are some questions you cannot answer?
> FastGPT: I apologize, but I do not actually have the ability to determine what questions I cannot answer. I am Claude, an AI assistant created by Anthropic.
The issue is, people think that connecting an LLM to the internet = unlimited information. In reality, it = an LLM treating a webpage as another sources of information. It is no better or worse than literally copying and pasting the information into the text box. If it goes beyond the token limit, you are going to get swiss cheese responses.
Bing is okay, ChatGPT 4 with browe tool is okay and Bard is pretty good, but tends to not use its browse tool enough, and hallucinates mightily.
Rest client is great, but a lot of the cool (emacs) kids have moved over to verb-mode [1]. To be fair, you can probably achieve something similar with org-mode and rest-client, but the verb-mode integration is very nice.
Ah! Yes, thanks for sharing. I should've guessed this existed for Emacs as well. I played around with implementing a similar concept like this in Vim, in 2019 (link: https://github.com/sharat87/roast.vim). Unfortunately, while I love Vim as an editor, I couldn't do a lot of features that I wanted. So I moved to the browser and built Prestige :)
Plugin historically referred to NPAPI (Netscape Plugin API), and later PPAPI (Pepper Plugin API) which were used for Flash, Silverlight and such. This historical reason was what distinguished between plugin and extension. The practice still continues today with H264 and Widevine even though they no longer uses NPAPI/PPAPI.
I'm still bitterly sad that Widevine has almost ended up as part of the spec de facto. I always turn off DRM compatibility in FF, and wish the other browsers would give me the choice. For me, that battle has been lost but the war may yet be won. I hope that this move of extension standardisation is actually a net boon for the end user, and not another silent, slippery path like WV and HTML 5 DRM have been.
"Plugin" generally refers to adding custom code to the browser itself, as a dynamic library or something, with the full ability to do anything the browser can do (i.e., it's equivalent to downloading an application). Plugins are usually written in a language like C.
"Extension" generally refers to code given limited access to certain APIs, a bit more generous than the access given to an individual web page but much closer to that model. Extensions are usually written with web languages like JS and HTML.
The multi-decade security trainwreck that was Flash was possible because it was a plugin - both in that bugs that corrupted the code could let an attacker run unrestricted code on your machine as if they'd gotten you to run a malicious application, and in that Flash was on its own for implementing rules like "can this website download files from this other website," so it was often possible to break the web's security model via Flash. Extensions go through the browser core to do all their work, just like JS on a website.
Conversely - Flash allowed doing a whole lot of cool things back when the web platform was nowhere near as capable. An extension can't directly access, say, the clipboard; it has to go through a browser API to do that. But back when there was no browser API, Flash could access the clipboard just like any other program on your computer.
Yes, I think you've captured the difference: An "extension" is written in an extension language like JavaScript, in a browser that's intended to be extended in that language. A "plugin" is a more independent piece of code written in a compiled language, plugged into a host that doesn't necessarily have its own extension language like JavaScript or Visual Basic.
But I think that may be largely an after-the-fact rationalization (like retronyming "YAML" from "Yet Another Markup Language" to "YAML Ain't Markup Language") and it's mainly a historical artifact that two different generations of browser extension technology have different names, because they're not precisely mathematically defined categories of computer science.
At the time that NSAPI came around, JavaScript wasn't really much of a thing, and DHTML didn't exist, so not many people would have seriously thought of actually writing practical browser extensions in it. JavaScript was first thought of more as a way to wire together plugins, not implement them. You were supposed to use Java for that. To that end, Netscape developed LiveConnect.
Microsoft eventually came out with "ActiveX Behavior Components" aka "Dynamic HTML (DHTML) Behaviors" aka "HTML Components (HTCs)" that enabled you to implement ActiveX controls with COM interfaces in all their glory and splendor, entirely in Visual Basic Script, JavsScript, or any other language supporting the "IScriptingEngine" plug-in interface, plus some XML. So you could plug in any scripting language engine, then write plug-ins in that language! (Easier said than done, though: it involved tons of OLE/COM plumbing and dynamic data type wrangling. But there were scripting engines for many popular scripting languages, like Python.)
NETSCAPE SHIPS LIVECONNECT BETA. By CBR Staff Writer 30 May 1996.
>Netscape Communications Corp, Mountain View, California, this week released its LiveConnect SDK development kit in beta which enables live objects in Web pages – such as Java applets, JavaScript scripts and plug-ins – to communicate with each other. Netscape will deliver a pre-release version of Java user interface component and application programming interfaces acquired through its acquisition of Netcode Corp earlier this year. Netscape will release a beta version of its Java-enabled Navigator 3.0 client for Windows 3.1 in June.
LiveConnect enables communication between JavaScript and Java applets in a page and between JavaScript and plug-ins loaded on a page. This chapter explains how to use LiveConnect in Netscape Navigator. It assumes you are familiar with Java programming.
Use JavaScript to access Java variables, methods, classes, and packages directly.
Control Java applets or plug-ins with JavaScript.
Use Java code to access JavaScript methods and properties.
For reference material on the Netscape packages, see the JavaScript Reference.
For the HTML syntax required to add applets and plug-ins to your web page, see the Applet and Plugin objects in the JavaScript Reference.
For information on using LiveConnect with server-side JavaScript, see Writing Server-Side JavaScript Applications.
For additional information on using LiveConnect, see the JavaScript technical notes.
You can use WASM in extensions. WASM qualifies for independent pieces of code written in a compiled language. Does that make extensions plugins?
I really don't see how "compiled" versus "script" makes a difference. The are both independent pieces of code written to interact with an API to add functionality.
Extension, add-in, add-on, plug-in are all words describing the same thing.
Yeah, that's why I gave the definition above upthread. It's not compiled vs. script - it's whether it runs alongside the browser's own code, with the same OS access that the browser does, or whether it runs inside the browser, with a bit more access than web pages do.
By convention, "plug-in" means the former and "extension" means the latter. There is a big difference.
Yes, that's what I meant by "after-the-fact rationalization" and "it's mainly a historical artifact" and "they're not precisely mathematically defined categories of computer science." It's just a fuzzy descriptive convention, not a strict prescriptive category.
The terms are just historical accidents. There is no official definition that "plugin means compiled code" and "extension means interpreted code". There is no well defined dichotomy, and the boundaries are fuzzy, and there are many other synonymous terms like "add-in", "add-on", "library", "package", "module", "customization", "mod", "XP/COM Component", "ActiveX Component", "OLE Control", "COM Object", "Windows Scripting Component", "Dynamic HTML Component (HTC)", "Scriptlet", "Binary Behavior", "Browser Helper Object (BHO)" etc.
And technologies like Mozilla XP/COM and Microsoft ActiveX purposefully blur the compiled/interpreted dichotomy by letting you implement components as either compiled code or interpreted scripts.
The whole point of ActiveX/COM/OLE/ActiveScript/Windows Scripting Engine (and Mozilla XP/COM) is to hide the implementation language of components, and transparently enable components implemented in interpreted and compiled languages to interoperate seamlessly.
>OLE Scripting is Microsoft's mechanism for incorporating Visual Basic Script and scripts created in other interpreted programming languages, such as Java or JavaScript, within DocObjects. Get the details from http://www.microsoft.com/intdev/inttech/olescrpt.htm. This sounds quite interesting: a way to plug extension languages in as components, via the COM IScriptingEngine interface.
>First there were VBXs. Then there were OCXs. Then, Microsoft wanted us to call them OLE Custom Controls, but we persisted in calling them OCXs. So they must have figured that we wouldn't accept any control technology that didn't have a name ending in X. -Curt Hagenlocher
For example, here are pie menus implemented in compiled C++ as a binary ActiveX control, which can plug into the browser, but can also be used by any OLE container like Microsoft Word or an arbitrary MFC app, so they don't depend on the browser or JavaScript:
And here are pie menus implemented in text JavaScript+XML source code as a Dynamic HTML Behavior Control, which can only run in the browser, but can leverage browser technology like Dynamic HTML and CSS for rendering:
Both of those are COM Objects/OLE Components/ActiveX Controls, implemented in different languages, and dependent on the host implementing different interfaces. It doesn't make sense to classify one as a plug-in and one as an extension based on whether they're compiled or not, but the JavaScript one does have a lot of dependencies on the browser that hosts it, while the C++ one does not. But the HTC doesn't get its JavaScript interpreter directly from the browser, it gets it from the scripting engine interface, which exists independently from the browser, and it could as well have been written in Python or Visual Basic Script.
Plugins were native code, usually running under NPAPI.
Extensions or Add-ons running with WebExtensions API are HTML/JS/CSS and have way less access to your machine. They run in a sandbox with very specific fine-grained control over permissions and capabilities.
It's mostly a historical term of art: Browser plugins refers to NSAPI plugins (and could also refer to OLE/ActiveX plugins), which is older and now obsolete, and is based on plugging native code in compiled binary dynamic libraries into the existing browser app (or OLE control container), without necessarily requiting an extension language like JavaScript / Visual Basic.
Browser extensions refer to more recent JavaScript centric extension techniques (like the older Firefox XUL extensions, and more modern Chrome/etc extensions), using JavaScript as a browser extension language, throwing in some XML and CSS, and coding most if not all of the plugin in JavaScript, instead of linking compiled binary code.
Python makes a distinction between "embedding" and "extending", that doesn't map directly into the browser plugin/extension dichotomy, but is kind of similar -- it's a question of "who's on top", and embedding usually implies some extending:
Extending Python means building modules that Python code can import to access the features the modules supply. Embedding Python means executing Python code from an application coded in another language. For such execution to be useful, Python code must in turn be able to access some of your application’s functionality. In practice, therefore, embedding implies some extending, as well as a few embedding-specific operations. [...]
>This document describes how to write modules in C or C++ to extend the Python interpreter with new modules. Those modules can not only define new functions but also new object types and their methods. The document also describes how to embed the Python interpreter in another application, for use as an extension language. Finally, it shows how to compile and link extension modules so that they can be loaded dynamically (at run time) into the interpreter, if the underlying operating system supports this feature.
It's best to define these words with feelings, and I feel like plugins are like a little box that is free to do "plugin" things within the box, but is otherwise merely co-existing within the browser, rather than integrating. Things like Flash, Silverlight, Java, etc. always did their own thing. Extensions are often tightly integrated into browser functionality, with interactions potentially happening in both directions. Custom buttons on the toolbar or context menu, with extensive access to your browser profile and perhaps cross-cutting concerns.
Another way to think of it is something you just plug in and use, like a vacuum cleaner. But an extension needs access to the browser API and may entangle itself.
I'm sure there are exceptions to those boundaries, such as Javascript being enabled to interact with Flash applications, but a plugin might operate without any real crossover with the browser functionality beyond existing in a window.
I was always explaining this on our local community forums in the early years of Firefox presence like this: extension extends the program on functionality, while plugins allows you to use other piece of software or its part within the browser
So Flash is an extension because it extends the browser's functionality to also be able to display Flash content, and an advert blocker is a plugin because it allows you to use the advert blocking software within the browser... right?
Yes, there's a different kind of debit card. I usually use a different term that's country-specific (like the cards themselves).
For Germany, a German debit card (the "other sort", as you put it) isn’t the same as any other. It doesn’t have Visa or MasterCard co-branding like other countries’ debit cards, nor a 16 digit number, so it can’t be used online. I might also use the term "bank card" for this, because there are actual debit cards with Visa/MC co-branding which are available in Germany, but less common than other types.
It's also common for Germans to use "Kreditkarte" to mean anything with Visa/MC co-branding, which probably spills over into English. This also leads to the hilarious term "echte Kreditkarten" (real credit cards) for cards that actually have a rolling line of credit attached (these are rarely offered).
However, in the UK I recall that people are usually specific about whether they mean a credit card or a debit card.
Something somewhat similar already happened: Stellar gave away XLM to Keybase after Keybase added an integrated Stellar wallet. Many people didn’t like it[0], even I was not too impressed despite working in the Stellar ecosystem. Some people didn’t like the mix of cryptography and cryptocurrency (at least, I certainly didn’t)
