Traveller:

You may benefit from this link, instead https://www.w3.org/History/1991/HTRejected.wn/WNDocument.wn

(Not sure if it's actually the same as what's supposed to be available here.)

Note that as of this writing, the site at that link now identifies the same file as "Word for the Macintosh document (v4.0)". I think the MacWrite II diagnosis is more plausible. No idea what changed.

Also: computing generally.

Good and sensible.

This could* pretty trivially be converted into a triple script.

* and should be

A good(?) case study in why these "papers" should be... papers (and not six-pagers* with directories of source code that exist "over there").

cf https://www.colbyrussell.com/LP/debut/

* 19 in this case

Chris (incl. his intuition) isn't wrong—static sites really do exist and are special. Consider: - files "served" from the local filesystem, i.e. what you get if you access a collection of resources saved to disk and opened in your browser - how much can be captured by a crawler (e.g. Wayback Machine) - bounded limits of computation: serving an HTML artifact (or some other static resource) is guaranteed to terminate

See also:

So, time to update the website, but the first wall I hit was that I:

1. Forgot how my over-engineered SaaS was supposed to be used (no documentation because I built it myself and was lazy)
2. Forgot how to follow the esoteric Hugo conventions (has documentation, but it's not easy to parse at a glance)

I was pretty annoyed with myself for having fallen for the trap of not documenting my own systems, but not sure how I could have remembered all of the Hugo-isms, especially since I don't update this site very often and don't do static site generator work outside of this.

https://web.archive.org/web/20210331182731/https://corytheboyd.com/posts/2020-03-09

(Previously: https://hypothes.is/a/U742AodQEeu5T2dEN4YdWQ)

Nope (re: offline). You're confusing "browser-based" and "Web-based" (sort of the way people confuse statically typed" versus strongly typed*). They're different. You can have a fully offline browser-based interface. Most common browsers are every bit as amenable as being used as simple document viewers as Preview.app or Microsoft Word is. The browser's native file format is just a different sort—not DOCX, and not PDF (although lots of browsers can do PDF, too; you can't write apps in PDF, though—at least not in the subset supported by typical browsers). Instead of Office macros written in VBA, browsers support scripting offline documents in JS just like online documents. You can run your offline programs using the browser runtime, unless they're written to expect otherwise.

This is:

Wang, April Yi, Andrew Head, Ashley Ge Zhang, Steve Oney, and Christopher Brooks. “Colaroid: A Literate Programming Approach for Authoring Explorable Multi-Stage Tutorials.” In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems, 1–22. Hamburg Germany: ACM, 2023. https://doi.org/10.1145/3544548.3581525.

This is an error/defect on the part of the author.

This misses the point of LP—the true "fundamental theorem of LP" is basically that the compiler should be made to accept the preferred form.

Should be "there"

The server isn't redirecting requests at the apex domain to www..

"Fixing" the RSS-vs-Atom problem: brand Atom as "RSS3" (sexy)—and make sure there are accommodations (read: plenty of RFC 2119-style MUSTs, MUST NOTs, etc) for podcasts while you're at it.

The "Standard Ebooks toolset" should just be... an ebook. That your browser can execute. (Because it's a ubiquitous runtime target that requires no setup...)

Question: what even is the "NPM hypothesis"? I.e. what is the value proposition, stated in the form of a falsifiable claim?

Should be "crannies"

What if console services (i.e. services offered by the system software for hardware game consoles) offered an asset cache?

Notice the total lack of addressability of this piece of content (in re the submission "The GMP library's repository is under attack by a single GitHub user" at <https://news.ycombinator.com/item?id=36380325>)

picolog.blue is missing

... because the server is configured like that.

(This is not a property of the language.)

Dynamic languages are not a prerequisite to this.

Good example of how when people are talking about a thing, they're often not really talking about it—they're saying something about themselves, their environment, how they do things, etc.

See also xkcd 1172: Workflow

This looks to be imagined.

This is the basis of the article. It would be nice if, in all the words here, it were actually substantiated.

Okay, now this is the problem statement(s). I don't see that the notice is doing these things (telling someone otherwise or "actively misinform[ing] their patrons"). It looks like it's totally in step with what is actually true.

Who—outside of this article—is saying anything like that?

I missed the part where the writer established that this was the case. What law are they referring to?

wat

You upend your values before attaining the near-infinite money (in order to attain it).

This is exemplary and deserves to be more fashionable than it is in 2023.

This is so weird; why isn't the Etherpad project wiki an Etherpad instance?

This is:

Wright, Alex. Cataloging the World: Paul Otlet and the Birth of the Information Age. New York, NY: Oxford University Press, 2014.

Nice turn of phrase—"platitudinous proclamations" (p. 88)

Remember: forms are just forms.

If they don't provide a form that is sufficiently "inert", then anyone (including FSF) can create their own.

"ChatGPT will say things that aren't true" seems perfectly adequate. I don't understand why this dumb debate—over the definition of the word lie—is even happening (to the extent, if any, that it actually is...)

Not even close.

JS succeeded because it was well-designed, period. There were many, many contenders in the early days—despite popular historical revisionism to the contrary. All of them failures.

This is:

Hilse, Hans-Werner, and Jochen Kothe. Implementing Persistent Identifiers: Overview of Concepts, Guidelines and Recommendations. London: Consortium of European Research Libraries, 2006.

It would be even worse if no such error message appeared: a URL may also be unstable in that it now points to a different resource that has replaced the earlier one.

Since this is yet another piece of journalism that covers a set of cases before the courts with citing the cases in question by name, here they are: - Students for Fair Admissions v. Harvard - Students for Fair Admissions v. University of North Carolina

Language runtimes that don't ship by default on Windows have historically been harder to install than utilities like gzip in my experience.

You can swap "lawyers" here for just about anyone—including (or "especially"?) software developers.

See also: cars.

My last comment here, the this hate, along with the fetishization of === over ==, is one of the most overblown aspects (and arguably: outright just incorrect stances) about language design when it comes to JS.

This has nothing to do with JS. It's not a language-level concern; the same would be true with any other language. Python, Ruby, Scheme, C#... pick literally any other language. It's a totally orthogonal issue.

Weird. TraceMonkey and JagerMonkey are just codenames for different approaches for fast execution/evaluation of JS in SpiderMonkey. They're not holistic JS language implementations unto themselves in the vein of, say, CPython vs IronPython.

In other words, the "problem" is the opposite of "fragmented runtimes"—it's that JS runtimes are so strictly committed to compatibility at the language level (to a degree not seen in any other widely deployed tech that I can think of). There are clear downsides (such as the sentiment expressed here), but there are also massive upsides. On net, the alignment is a huge win.

This is true, but also pretty huge non-issue. The only way it could possibly be an issue is for someone who just objects to the notion of function-valued expressions generally (fans of Pascal, maybe? I dunno) or someone who against all good sense believes that a pair of parens should result in the introduction of a new scope (weird).

You already know why: the semipredicate problem. (In other words, for a similar reason why you might want a number type to be nullable even though you already have 0.)

This criticism is not just ignorant. It's stupid.

A passive failure to make a special case ("optimise") for array operands in binary expressions with + is not the same thing as actively optimizing for "two comma-seperated[sic] strings without a comma in the middle".

Mmm... no. It often is—to the world's peril—but it's not the architecture that makes this so. It is a choice of node operators to return some resource X when a given identifier is referenced on day d[0] and to return resource Y on day d[1].

On the contrary. It is the lack of stability that makes (reliably) linking virtually impossible. How do stable links make linking more difficult...?

They already are.

It doesn't. It leads to no more (or fewer) resources than otherwise. It does lead to an "explosion" of identifiers.

Think about the silliness of casting aspersion on the notion of "[many] resources, each with its own distinct identifier". The fundamental premise of the Web is that this is a good thing; if you have a slew of resources, you should be able to (unambiguously) refer to them by identifier.

Response: the question is malformed. The problem lies in the belief that it's possible for content to change. It can't. If it appears to, then it is only because the server is returning a different resource than whatever was previously available. Don't reuse identifiers for different resources. Mint a new identifier.

This is:

Evans, M.P., and S.M. Furnell. “The Resource Locator Service: Fixing a Flaw in the Web.” Computer Networks 37, no. 3–4 (November 2001): 307–30. https://doi.org/10.1016/S1389-1286(01)00204-3.

It's my contention that this is a matter of people misusing the URL (and the Web, generally); Web pages should not be expected to "update" any more than you expect the pages of a book or magazine or a journal article to be self-updating.

We have taken the original vision of the Web -- an elaborately cross-referenced information space whose references can be mechanically dereferenced -- and rather than treating the material as imbued with a more convenient digital access method and keeping in place the well-understood practices surrounding printed copies, we compromised the entire project by treating it as a sui generis medium. This was a huge mistake.

This can be solved by re-centering our conception of what URLs really are: citations. The resources on the other sides of a list of citations should not change. To the extent that anything ever does appear to change, it happens in the form of new editions. When new editions come out, nobody goes around snapping up the old copies and replacing it for no charge with the most recent one while holding the older copies hostage for a price (or completely inaccessible no matter the price).

not an example of something gone wrong with DNS

I don't understand this criticism at all.

There are a lot of papers cited in this presentation that aren't cited explicitly and in detail in the associated "transcript": https://web.archive.org/web/19980215203333/http://www.parc.xerox.com/spl/projects/oi/towards-talk/transcript.html

(E.g. Wirth "On the Design of Programming Languages" @25:00.)

It would be nice/useful to go through the video, grab the moments where these are referenced (incl. screenshots of the slides), and collect them into an orderly works cited rider doc.

Hey, traveler. Try this instead:

https://web.archive.org/web/19980215203333/http://www.parc.xerox.com/spl/projects/oi/towards-talk/transcript.html

Not sure why this is detached from the thread it belongs to, but it appears to be this one:

https://mastodon.social/@shriramk/110556924858987180

By a reasonable guess, no matter what the actual (vs stated) requirements are, they'll be overstated.

Do they? (This is almost certainly a coordination problem, right?)

Isn't that just drawing from another exhaustible resource? Think end game. Don't we converge on an equilibrium where we are no longer able to exploit the outsized gains?

Related: see the "web of documents" tag on Hypothesis.

Again: we're way past that—and it's not broadly accessible simulated word processors that got us there. (It's actually Web developers themselves.)

I think that's a good thing, for the reasons described here: https://hypothes.is/a/TF6N6AxHEe6qM_dG0VlZzw. We should stop treating the Web as a sui generis medium and elevate it to the same status as material that appears as written word made for print.

I don't even think that these arguments are that compelling. In the first place, URLs are explicitly stated to be unreliable indicators of content—they are opaque. https://hey.look.a.verylegit.link/filehost392index-ip-stealer!.xlsx.docm.exe is as valid a URL as any PURL, or the URL to this very blog post.

Most of the other points come across like more application of the double standard.

We're past this, though, even in the world of "proper" Web development. Look at anything you consider to be "of" the Web. Take this blog post as an example. There's a double standard at play, considering that if you peer at the page source, it's by and large worse than the sort of thing that you'd have gotten out of Frontpage, Dreamweaver, etc. 20 years ago. And this isn't even an SPA or other Google Docs-like creation of the sort that this post focuses on.

I think the key here is "[...] published on Google Docs". Consider instead: "Something radical can be prepared with Google Docs". There's nothing stopping anyone from using Google Docs in the same way that traditional desktop word processors are used—by working on your stuff and then saving a copy to your own disk (using Google Docs's "File" menu). Pick your own format—DOCX, ODT, etc., but note that HTML mostly works quite well...

In fact, it being on your own disk is beside the point; you can put the thing anywhere—it doesn't have to stay "on" (read: in) Google Docs. Put it online if you want. (I refer again to https://crussell.ichi.city/food/inauguration/.))

I'm not entirely sure that's true. I'd wager that's incidental; the main goal seems to be to give people access to a word processor in the form of a Web app, and the fact that they've figured out a way to make money on it is... not coincidental, but certainly "serendipitous" or "fortunate" (in the way that it's fortunate to be able to make money off any kind of software created for some other reason than to make money).

I dislike the use of "doc" as nomenclature here. "Document" works perfectly fine.

See also: Zawinski's Law.

The writing here is super obscure. I don't like it.

See also:

Google Docs is one of the best ways to make content to put on the Web.

https://crussell.ichi.city/food/inauguration/

I feel, in some circumstances, the opposite way.

The problem, as Feynman pointed out, is that it's very easy to fool yourself.

So much of software development practices are driven by people loosely (read: unrigorously) reasoning about things. Few people form hypotheses for which we can articulate some means of proving or disproving what is being claimed.

This is a very useful but underutilized property. It allows you to e.g. announce in advance that a resource will exist at some point in the future, and thereby effectively receive "updates" to the linking document without requiring changes to the document itself.

By and large, this is what 23 years of software trends in browser-based development have given us, unfortunately.

Another good jumping off point for why document mutability should be considered harmful. https://hypothes.is/a/N_gPAAmQEe6kvXNEm10s7w

This is:

Fielding, Roy T., and Richard N. Taylor. “Principled Design of the Modern Web Architecture.” In Proceedings of the 22nd International Conference on Software Engineering, 407–16. ICSE ’00. Limerick, Ireland: Association for Computing Machinery, 2000. https://doi.org/10.1145/337180.337228.

This is a good launching point for my contention about Modification Considered Harmful.

I'll go further and say that, wrt the original goals of the Web—and the principles we should continue to strive for today, despite widespread practice otherwise—Modification (should be) Considered Harmful.

Git has the right idea. Hypermedia collections should also be append-only (not different resources masquerading under the same name).

This is highly dubious—you're talking about two completely different resources at that point.

If I send you a link to a page on a dynamic site written in PHP like standardebooks.org, and then I send you a link to the GitHub repo showing the source of the script responsible for intercepting the request and responding with the page that you actually see when you visit the first URL, are those really two different representations of the same resource? Or two different resources? It's the latter.

There is a desire to rectify/reconcile this with WebDAV, because you want to be able to "address", say, cart.php—which is in principle not a bad thing (it's very much a good thing, really)—but merging two resources into the same namespace is not the solution, and bad hygiene should not be excused.

This appears to be among the only uses of this phrase wrt AJAX.

This is:

Fielding, Roy T., Richard N. Taylor, Justin R. Erenkrantz, Michael M. Gorlick, Jim Whitehead, Rohit Khare, and Peyman Oreizy. “Reflections on the REST Architectural Style and ‘Principled Design of the Modern Web Architecture’ (Impact Paper Award).” In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, 4–14. ESEC/FSE 2017. Paderborn, Germany: Association for Computing Machinery, 2017. https://doi.org/10.1145/3106237.3121282.

A thought: this kind of support should be in the purview of the Wikimedia Foundation. They have an ample endowment, and in 2021, their revenue was $162 million vs $111 in expenses. They could outright pay for every copy that the World Book sells, or cover the costs of a give-one-get-one program.

Some ways that this could work out to enrich the commons: a licensing deal where the photographs in World Book become available under CC-BY-NC-ND (i.e. gratis to share) two years after publication and then CC-BY-SA (sufficiently permissive so that it would allowed to be imported into Wikimedia Commons) after, say, five years following initial publication.

See also: emerging from the theater when there's still daylight, or pulling off your skates and walking around in your own shes when leaving the rink.

I've revisited this post a lot. Here's a relevant link to discussion between the author of this post and Mark Adler:

https://github.com/madler/sunzip/issues/7

In light of Mark's insistence of certain things, Greggman's hedging seems more reasonable. I'm still of the opinion that Mark is wrong, though; Greggman had it right the first time.

This is "MSC:CV RESPONSE TO MOTION FOR NEW TRIAL Defendants' Opposition to Plaintiff's Motion for Trial Setting"

awful

Terrible name choice! EscapeText (or EscapeTextForHTML if you want to be really verbose) is the most correct (and less footgun-y) way to refer to this.

I wonder how many security problems the name EscapeHtml will lead to...

The Web, you mean.

NB: This refers to the the musical artist, not the (non-existent) Madonna, Texas.

This is an ordinary bug and not worthy of note in a document about the relative strengths and weaknesses of WebDAV (or any other protocol); it's not an inherent consequence of WebDAV as designed...

should have been "[...]a=23189,00.asp"

should have been http://www.pcmag.com/print_article/0,3048,a=23189,00.asp

i.e., s/1=/a=/

should be "IETF"

should be "IETF"

This page is dense with references. It's an excellent candidate for marking up and connecting to the other documents it references, Xanadu-style

what the FSF (GPL) calls "preferred from for modification"

should be "W3C"

except TBL did imagine them -- browsermakers (outside CERN) didn't

that's a feature (not a bug)

should be "HTTP"

should have been "[...]a=23189,00.asp"

should be "IETF"

Files which render themselves when published (e.g. templates or other scripts) will be rendered when accessed from a mounted WebDAV volume. This is because WebDAV clients issue a GET (it's an extension of HTTP, after all) to hand you your data. You can't simply mount a WebDAV share and start editing PHP files, for example. Until a data type is provided for source code-based documents, this will remain a problem.

This is a node-/organization-level information architecture problem.

If /foo.php is a script that generates a Web page, then separate identifiers need to be assigned for each resource (one for the document itself, and one for the script that generates it). It is a failure of the node not to distinguish between the two. A separate content type would not solve this problem—it would just appear to cover it up (as well as create new ones).

Traveler,

Try https://web.archive.org/web/20021019234705/http://www.pcmag.com/print_article/0,3048,a=23189,00.asp

Locking: Locking protects web team members from overwriting each other’s changes. When two or more people are working on the same file, WebDAV ensures that they compare or merge changes before writing to the file.

Git solved this problem in a much cleaner and respectable way: it's an append-only log. The only thing left is to "flatten" the two namespaces into a single one. On first inspection, this seems like it would re-introduce the need for rewrites (and locking?), but this can be cleverly solved by preregistration of forward references. Locating the current "head" can be resolved in log2(n) time wrt number of "revisions" (and can also be avoided in many cases, besides).

How does WebDAV work? Each of your colleagues — whether they’re in Bangalore or Bangor — mounts a WebDAV volume located on the shared web server to his or her desktop. They can then access its files as they would any other networked volume.

This is a pretty unsatisfying description of what WebDAV (and the underlying spirit) actually offers.

Mounting a remote host like a local disk is not without its (limited) use and convenience, but it's neither the intent nor the extent behind the spirit of WebDAV.

I think there's a category error here.

See https://hypothes.is/a/V5kHYvpDEe2ilbsFpHmKKg

See https://hypothes.is/a/V5kHYvpDEe2ilbsFpHmKKg

See https://hypothes.is/a/V5kHYvpDEe2ilbsFpHmKKg

There are several points where there is a gesture/reference to something on the screen ("This is a headline", "Here is a talk"...) where what's shown on the screen is doing the heavy lifting.

Don't just say, "here [it is]", though. Mention the presentation and author by name when speaking. The screen is a complement.

Consider: there's no reason in principle why this entire presentation couldn't be a "blogcast" (a blog post in audio form).

This accounts for ~all programmers. It's not just a matter of people presenting themselves as having credentials that are just backed up by monkey-see-monkey-do IT cargo cultism. Programmers write bugs.

It's not really clear what this section has to do with the overall talk. How is this (specifically the part about all programmers creating bugs) mitigated or addressed by the contents of this talk?

There's a hard transition after this point, but it comes in such a way that makes it seem like what's next is something that will expound in some detail upon this point.

This def. needs to be more fully developed.

Maintaining access to past works due to any number of reasons including file format lock-in (even when the software in question is open source) is actually a huge deal.

(It is my contention that this accounts majorly for a bunch of the problems in e.g. the NPM ecosystem.)

This whole thing could stand to be more fully developed. I don't have any specific advice, it just seems unclear and feels like a nonsequitur upon reaching the end and moving on to the next topic.

I have a lot to say about this, but I'll be succinct and just say, "don't conflate a language with a particular community that uses that language—even if that community has achieved culturally dominance".

What does this mean, though? Concretely, I mean. (Could stand to qualify/quantify this.)

I was surprised to find about a ~month ago that LÖVE is written in C++. Its scripting support is Lua-based.

Not sure that this is a good argument. The fact that someone is using $LANG in such a way (for "conquest") doesn't have any bearing on how you have to use the language.

Coming from a place of evaluating an argument on soundness and rationality, the conclusion/advice given (use Lua) is only about half a step removed from PL hipsterism—at least when evaluating the reasons actually stated. (There may be a stronger argument here, but it's obscured by this one.)

Maybe not necessary for the intended audience but might benefit from distinguishing between bonafide forks vs what GitHub has done to the word.

Isn't that a contradiction?

Note that these two things are at odds. Literate programming (to a high standard—higher than Knuth's standards, viz [1]) is probably the single best thing that enables the former, but it works against the latter.

1. http://akkartik.name/post/literate-programming

huh?

lame

See also: http://www.ariadne.ac.uk/issue/31/web-focus/

Try https://www.w3.org/Provider/Style/URI

In a book? Yes.

You mean price guide books? If so, yes.

Yes.

Yes.

Yes.

rsync.net would be really great for repo hosting if you could trivially pair it with something else to get public repos. You can't, though.

This pretty much the basis for Kartik's criticism in Literate Programming: Knuth is doing it wrong.

Thought experiment: what if you elevated the documentation to first-class status rather than as low-stakes generated artifacts that can be blown away and regenerated? What if you modified your compiler to consume the documentation and produce the same binary as the one produced by what you now consider to be your source code?

See https://hypothes.is/a/QZJW9PPLEe2LeiNwpwbj6A

In other words, it risks undermining the intent of the API design.

Cox published a copy of this text on his homepage:

https://web.archive.org/web/20021109120553/http://www.virtualschool.edu/cox/pub/92ByteWhatIfSilverBullet/index.html

Confusingly, he labels it there "What if there's a Silver Bullet... And the Competition Gets it First?"—which seems to be the title of an ~~entirely different article (... and which itself is confusingly named 92ByteWhatIfSilverBullet, even though it is described as "An editorial for the Journal of Object-oriented Programming in June 1992. Republished in Dr. Dobb's Journal in Oct 1992.")~~

Huh?

One of the recurring things that needed to be pointed out in the fab (still does), is that Samsung is not in the business of selling workers who will suck it up and show that they're willing to ignore all the broken things around them while doing a bunch of dumb day-in-and-day-out stuff undeterred in order to not look lazy* and plausibly prove that they're badass It's in the business of fabbing chips.

* Side note: everyone who needed this pointed out was, in reality, lazy; the entire mode of attack came from obvious self-loathing.

More accurately: incentivized to make the browser runtime accommodate apps that assume a Web platform rich in APIs not dissimilar to mobile app platforms

Except not, because the domain after the @ sign is part of your handle, and it's not "creating" any challenges that weren't already a thing with email...

This definitely needs to be corrected.

Ibid. There is nothing about HTTP which makes your URIs unstable. It is your organization.

There's nothing in principle that makes blogging untrustworthy. It comes down to, as Elavsky says just a bit later, "higher [or lower] standards" for longevity. But there's a sleight of hand here. The people who are receptive to the proposal in this paper are already almost by definition selected for those who have high standards. So this is not a robust argument that there's anything superior to this approach vs "Just put it on your blog and take the same amount of care that you would when following the archival advice in this paper."

This is just a misuse of HTTP.

Prior art to the (surprisingly late entry) rel=canonical link introduced by Google.

See also: Linked Data Notifications

It's embarrassing that this isn't supported by freedesktop.org-affiliated environments.

Related: w2g/graph.global

And if you have to look up API docs to write a plugin to publish to a given service, then you have lost, too.

Things like Neocities's out-of-band WebDAV gateway are some of the most pointless things in the world. WebDAV is HTTP! Just allow a PUT to the intended URL!

There's more going on in the quoted requirements than these comments suggest.

Server-side processing for view control is gross—it's a conceptual abomination.

Consider the phenomenon of people screwing others over as as matter of course in what they consider ways small enough to be acceptable—on the assumption that the other person seems to be positioned in such a way that they can absorb the shock.

This is: Berners-Lee, Tim. “World-Wide Computer.” Communications of the ACM 40, no. 2 (February 1997): 57–58. https://doi.org/10.1145/253671.253704

See also: the brains in Futurama's Infosphere.

The Web does not yet meet its design goal as being a pool of knowledge that is as easy to update as to read. That level of immediacy of knowledge sharing waits for easy-to-use hypertext editors to be generally available on most platforms. Most information has in fact passed through publishers or system managers of one sort or another.

Apart from being a place of communication and learning, and a new market place, the Web is a show ground for new developments in information technology.

The eternal tyranny of the milieu of the Web

It is important that it work on Windows, but three-quarters of all PCs do not run Windows. Three-quarters of all traditional laptops and desktops? Sure, but most personal computers these days are mobile phones.

@17:11

The idea of portability is that you take a fully running system that is compliant with the expectations of that host system, pick it up, put it on the other platform, and it takes care of all the problems associated with living on that new platform and just works.

Presages containerization in the 2010s.

@17:03

The idea of portability is not that you take your C code and recompile it and hope it compiles and hope the compilers have the same bugs in them.

Echoes of Darwin.

@54:06:

Host: So in a way it's a regulation to drive change, or...

Anderson: Or, regulation to stop change that would upset existing safety standards social expectations, social norms.

This could be trivially solved by extending the syntax to include some notation that has the semantics of a well-defined reference but the ergonomics of a quoted string. So if the notation used the sigil ~ (for example), then ~"Bob" could denote an implicitly defined entity that is, through some type-/class-specific mechanism associated with the string "Bob".

Ugh. This is the real problem, I'd wager. Nobody wants to derp around configuring the Xresources to make xterm behave acceptably—i.e. just to reach parity with Gnome Terminal—if they can literally just open up Gnome Terminal and use that.

I say this as a Vim user. (Who doesn't do any of the suping/ricing that is commonly associated with Vim.)

It is worth considering an interesting idea, though: what if someone wrote a separate xterm configuration utility? Suppose it started out where the default would be to produce the settings that would most closely match the vanilla Gnome Terminal (or some other contemporary desktop default) experience, but show you the exact same set of knobs that xterm's modern counter part gives you (by way of its settings dialog) to tweak this behavior? And then beyond that you could fiddle with the "advanced" settings to exercise the full breadth of the sort of control that xterm gives you? Think Firefox preferences/settings/options vs. dropping down to about:config for your odd idiosyncrasy.

Since this is just an Xresources file, it would be straightforward to build this sort of frontend as an in-browser utility... (or a triple script, even).

@~8:00 one quote says:

With web articles, I think the biggest problem is that it is hard to create interactive elements in it. Some people are able to make very fancy web articles. But it takes efforts you know.

Related to ho-hoism? Or at least the Torvaldsian sentiment about not being "big and professional like gnu[sic]".