308 Matching Annotations
  1. Last 7 days
    1. We didn’t watch a few seconds of a TV show and then click a remote and watch a few seconds of another.

      This is overall a good piece, although it does contain some errors, but this claim is probably the weirdest and wrongest.

    1. See also a lightly differing follow-up (billed as a crosspost): https://www.w3.org/People/Berners-Lee/1991/08/art-6692.txt

    2. real or virtual

      interesting taxonomy; useful for communicating about a concerted effort towards a more document-oriented correction to the modern Web?

    3. 6484@cernvax.cern.ch
    1. This information was previously posted to <alt.hypertext> and to <comp.sys.next>, but popular request prompts this cross-posting.
    1. over Years
    2. in toe

      "in tow"

    3. Cornel


    4. It also typically goes hand in hand with another concept known as scratching your own itch. Building a product or service or website that you yourself would like to see in the world.

      Lots of punctuation mistakes in these two "sentences"—one being that this isn't really two sentences, since the second is a fragment, but it could be fixed by swapping the period for a colon or em dash.

    5. it;s


    1. 1'-"'+,..._:h'v~ ...-·~/...-1..-.f ... ;~ ~ fS f.v(. .;.. bt ~t-tno..;..,· .... ) ~ tv fA. '"""V"o-..1 t,..;-{_ ea.... ~# ;.r ,.; ~ !vl ., ue......~ 1 ~;lk...) g~~t. "\ '""'"~""<

      Actually reads:

      I like the browsing style this should make possible. Intuitively right and potentially user-friendly. But it could be frustrating—how do we know we can get it right? Demo of existing systems? Invaluable tool for services

    2. Content also available (including the original word processor file) from https://www.w3.org/History/1989/proposal.html

    1. Other versions which are available are:

      From CERN, a PDF scan of the original (includes the infamous handwritten note "Vague but exciting...": https://cds.cern.ch/record/1405411/files/ARCH-WWW-4-010.pdf

    2. The original document file (I think - I can't test it)

      Referenced in an HN thread:


      In the thread, William Woodruff mentions that LibreOffice is capable of displaying this file.

    1. I might as well note that I'm forced to link to a special pseudo bboard system from here as a workaround for the moronic robots.txt standard.


    1. while still holding tab down

      Alt, you mean? (No Windows here; can't test, but it seems like that would be the right way to do it.)

    1. I'm partial to the "Principle of Least Power" in the Axioms of Web Architecture document cited in the bibliography. (The language there better captures the thought and presents it more convincingly, in my opinion.)

      Shortcut: https://www.w3.org/DesignIssues/Principles.html#PLP

    1. Most users crave pleasant UX

      I don't even think that's it. Plenty of people are willing to do with poor UX. (Look at GitHub.) The overriding factor is actually a consistently familiar interface. (Look at GitHub.)

      Related: https://www-archive.mozilla.org/unity-of-interface.html

    2. In the end, nobody came.

      Makes sense. As I've said before, you should not fool yourself—"you have to create a compelling product before you can ever realistically even start thinking about selling people on a general platform".

      The thing that most of these projects' fans think that these projects have going for them is the technology, but that's not really interesting to anyone except enthusiasts who spend all their time talking amongst themselves.

    1. “But how can I automate updates to my site’s look and feel?!”

      Perversely, the author starts off getting this part wrong!

      The correct answer here is to adopt the same mindset used for print, which is to say, "just don't worry about it; the value of doing so is oversold". If a print org changed their layout sometime between 1995 and 2005, did they issue a recall for all extant copies and then run around trying to replace them with ones consistent with the new "visual refresh"? If an error is noticed in print, it's handled by correcting it and issuing another edition.

      As Tschichold says of the form of the book (in The Form of the Book):

      The work of a book designer differs essentially from that of a graphic artist. While the latter is constantly searching for new means of expression, driven at the very least by his desire for a "personal style", a book designer has to be the loyal and tactful servant of the written word. It is his job to create a manner of presentation whose form neither overshadows nor patronizes the content [... whereas] work of the graphic artist must correspond to the needs of the day

      The fact that people publishing to the web regularly do otherwise—and are expected to do otherwise—is a social problem that has nothing to do with the Web standards themselves. In fact, it has been widely lamented for a long time that with the figurative death of HTML frames, you can no longer update something in one place and have it spread to the entire experience using plain ol' HTML without resorting to a templating engine. It's only recently (with Web Components, etc.) that this has begun to change. (You can update the style and achieve consistency on a static site without the use of a static site generator—where every asset can be handcrafted, without a templating engine.) But it shouldn't need to change; the fixity is a strength.

      As Tschichold goes on to say of the "perfect" design of the book, "methods and rules upon which it is impossible to improve have been developed over centuries". Creators publishing on the web would do well to observe, understand, and work similarly.

    1. and free of globals

      Ah! This remark highlights a fundamental difference in understanding between two camps, which I have been (painfully) aware of, but the source of this confusion has eluded me until only just right now. (Really, this is a source of frustration going back years.)

      In one camp, the advice "don't use global variables" is a way of attacking a bunch of things endemic to their use, most notably unnecessary coupling to spooky state. In another camp "no global variables" is taken literally, so you can have as much spookiness as you like, and so long as the value is not visible (accessible) from, say, another given piece of code appearing at the top-level ("global") context, as with the way i is bound to the activation record in this example but is not accessible outside the scope of getGetNext, then you're good.

      That is, there are two aspects to variables: scope and extent, and the first interpretation seeks to avoid the negative effects on both dimensions, while the second is satisfied by narrowly avoiding only those things effecting scope.

      I find the latter interpretation bizarre and completely at odds with the spirit of the exhortation for avoiding globals in the first place.

      (What's worse is the the second interpretation usually goes hand in hand with the practice of making extensive use of closures, which because they are propped up as being closely associated with functions, then leads people to regretfully refer to this style as functional programming. This is a grave error—and, to repeat, totally at odds with the spirit of the thing.)

    1. [Huh? Pass-by-reference ALWAYS requires passing a reference by value. That's how it works. The question is whether the referenced object is a COPY of the caller's object, or an ALIAS for the user's value. Most modern languages pass by reference for non-primitive types.]

      This person is confused, though it's obvious and understandable to those who've been down the road before how it happens. Most mainstream languages that are taught to be "pass by reference" are actually of the "pass by reference value" sort. Lack of exposure to languages that actually implement pass by reference is the culprit. Of course if your experience is limited to C, C++, Java, and others that use the "pass by reference value" approach, then you'll come away thinking that "pass by reference value" is what "pass by reference" means and this is what any and every language "ALWAYS requires" when setting out to implement "pass by reference"—you just don't have the appropriate frame of reference to see how it could be otherwise.

    1. body script, body style {

      This doesn't work well with scripts (and style elements) injected by the Hypothesis bookmarklet or the Wayback Machine's toolbar. On that note, it's pretty poor hygiene on their part to (a) inject this stuff in the body to begin with, and (b) not include at the very least a class attribute clearly defining the origin/role of the injected content. As I described elsewhere:

      set the class on the injected element to an abbreviated address like <style class="example.org/sidebar/2.4/injected-content/">. And then drop a page there explaining the purpose and requirements (read: assumptions) of your injected element. This is virtually guaranteed not to conflict with any other class use (e.g. CSS rules in applied style sheets), and it makes it easier for other add-ons (or the page author or end user) to avoid conflicts with you.

    2. * Monospace fonts always render at 80% of normal body text for some * reason that I don't understand but is still annoying all the same.

      Dealing with it this way is a mistake. The only reasonable thing to do is to tell the user to adjust their browser's default font settings or deal with it. (This seems to only affect Firefox's default UA stylesheet/preferences, not Chrome.)

      Check out how the most recent iteration of the w2g streamline "client" https://graph.5apps.com/LP/streamline approaches styling.

    1. It comes down to "what is the work?"Take one of Ray Charles' records..Is it just the music itself? Does it include the physical media and its condition?

      This is important. See for example, the recent revelation that even with all the book digitization efforts, archive.org does not necessarily have imagery for a given volume's spine, even if the front cover and back cover were photographed!

  2. greggman.github.io greggman.github.io
    1. One other thing is that many libraries seem bloated. IMO the smaller the API the better. I don't need a library to try to do 50 things via options and configuration.
    1. 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).

    1. put people first

      Putting people first or persons first (i.e. egos first)? Because the latter is what you get under the current social paradigm.

    2. we have discovered a game-changing way of structuring cyberspaces: the Social Web, where content orbits the author like planets orbit a star

      I've also articulated this point, but in a negative context. This piece speaks of actor-indexed content in a positive light. I maintain that actor-indexed content is on the whole negative. It's a direct and indirect cause of the familiar social media ills and has wide-reaching privacy implications, which is bad in and of itself, but especially so when you realize that this in turn leads to a chilling effect where people simply opt not to play because it's the only remedy.

      We'd do well socially to abandon the "game-changing" practice of indexing based on actor and return to topic-based indexing, which better matches the physical world.

    3. The real threat comes with giant closed cyberspaces that disguise themselves as public spaces.

      Useful analysis.

    1. they don't get counted towards the total amount of friction in the system

      You can say the same for any number of things that GitHub natives usually put their thumb on scale for in order to not count it among the costs of using GitHub. This type of "blindness" is a recurring issue that has come up every time I've tried to have a discussion about the costs of GitHub.

    1. "I don't want to interact with anyone who uses GitHub" is developer-hostile

      In fact, the reverse ("I won't interact with anyone who isn't using GitHub") is the default for many (most?) projects hosted on GitHub.

    1. I see way too many projects that have a mess of unwrapped (or purely auto-wrapped) wall of text for commit messages.

      You can blame "GitHub-Flavored" "Markdown" for that.

  3. Jul 2021
    1. being provably terminating is a problem dealing with the full body of C programs written in the world. The OP is dealing with their own self-published content. That's a different problem

      Far too few programmers understand this, which creates a conversational nuisance. I'm not sure why, though. Charged with writing out explicitly the explanation for why it's true, you might come away thinking it's so because the issue is deceptively nuanced.

      ... but it's not that nuanced.

      This should really not pose as big of a problem as it does, and yet I see the "cache miss" occur way too often.

    1. I mean, over 40M devs from over 41 countries on GitHub? Pretty amazing.

      Is it, though? From where I'm sitting, GitHub has been good for exactly two things. Getting the uninteresting one out of the way first: free hosting. Secondly, convincing the long tail of programmers who would not otherwise have been engaged with the FOSS scene to free their code, by presenting a shimmering city on the horizon where cool things are happening that you'd be missing out on if you were to remain stuck in the old ways that predate the GitHub era's collective mindset of free-and-open by default. That is, GitHub strictly increases the amount of free software by both luring in new makers (who wouldn't have created software otherwise, free or not) and rooting out curmudgeons (who would have produced software of the non-free variety) with social pressure.

      I'm less convinced of the positive effects on "the choir"—those who are or were already convinced of the virtues of FOSS and would be producing it anyway. In fact, I'm convinced of the opposite. I grant that it has "changed the way [people] collaborate", but not for the better; the "standard way of working" referred to here by my measures looks like a productivity hit every time I've scrutinized it. The chief issue is that undertaking that level of scrutiny isn't something that people seem to be interested in...

      Then you have GitHub's utter disregard for the concerns of people interested in maintaining their privacy (by not exposing a top-level index of their comings and goings to anyone who asks for it —and even those who don't—in the way that GitHub does, again, whether you asked for it or not).

    1. Let the browser vendorskeep developing forever more.

      Odd choice of a pairing between context and link destination. Again, this seems to come down to a misconception (or—less charitably, a misrepresentation—of how Web standards progress).

      CADT most aptly describes the NPMers on GitHub, not the rudiments of the Web platform. (Or if anything, the types of folks pushing such misguided efforts as Gemini, ironically enough...)

    2. set up a website

      Something which should be standardized, by the way. Signing up for an account on Neocities or Netlify should be just as readily available over a neutral, non-HATEOAS client as their bespoke APIs for updating content. (Their APIs, for that matter, should be deprioritized where vanilla HTTP would suffice.)

      Furthermore, it's nice that reading from DNS is standardized, but proprietary control panels are anathema to the general accessibility (that is, to the general public) of this aspect of Internet infrastructure. The mechanisms for writing/editing DNS records should be just as standardized as the ones for doing lookups.

    3. But stable standards are incredibly important.

      Right. Which is why the folks working on Web standards have endeavored to make stability a goal up to this point and beyond; the Web is one of (if not the) most stable piece of widely adopted computing infrastructure that exists. The author's conception of Web standards is at odds with reality.

    4. it is impossible to build a new web browser

      Perhaps it's not possible. (Probably not, even.) It would be very much possible to build a web browser capable of handling this page, on the other hand, and to do so in a way that produces an appreciable result in 10 minutes of hacking around with the lowliest of programming facilities: text editor macros—that is, if only it had actually been published as a webpage. Is it possible to do the same for if not just this PDF but others, too? No.

    5. Taking my own advice, this document was written in the world’s greatestweb authoring tool: LibreOffice Writer.

      Great. This is something that I advocate for technical people to put forth as a "serious" solution more often than I see today (which is essentially never). But next time, save it as HTML. (And ditch the stylistic "rubbish"; don't abuse "the sanctity of the written word by coercing it to serve the vanity of a graphic artist incapable of discharging his duty as a mere lieutenant".)

    6. Eh, they look alright to me.

      I have a rule that any response that begins with someone having typed out "Eh" is empty and/or junk. (The response here is no proof by contradiction.) In other words, one is free—or perhaps obligated—to meet the zero-effort dismissal with a similarly dismissive response.

    7. weshould use PDF/A instead, which forbids interactive content

      (The author purports to address the following, but just uses some rhetorical flourishes and misdirection. In an effort to not let that go unnoticed and to hold his or her feet to the fire...)

      How does this type of "we should" differ at all from saying "we should use HTML 4 with no JS" or "we should use EPUB"?

    8. There used to be an internet middle class, of non-commercial users whowere not overtly technical, but were still able to self-publish.

      This is probably the least flawed claim in the entire piece.

    9. Overall, I'm pretty happy with the level of scrutiny the claims here are being subjected to over on HN. https://news.ycombinator.com/item?id=27880905

      (One of the rare times on HN in recent memory where a potentially attractive position on what could have been a contentious issue involving techno-pessimism related to the Web seems to thankfully be overwhelmingly opposed, in recognition that the arguments are not sound.)

    10. fake plastic human-interest

      The formatting of this link is messed up.

    11. PDFs used to be large, and although they are still larger thanequivalent HTML, they are still an order of magnitude smaller than thetorrent of JavaScript sewage pumped down to your browser by mostsites

      It was only 6 days ago that an effective takedown of this type of argument was hoisted to the top of the discussion on HN:

      This latter error leads people into thinking the characteristics of an individual group member are reflective of the group as a whole, so "When someone in my tribe does something bad, they're not really in my tribe (No True Scotsman / it's a false flag)" whereas "When someone in the other tribe does something bad, that proves that everyone in that tribe deserves to be punished".


      I'm pretty sure the combination of those two is 90% of the "cyclists don't obey the law" meme. When a cyclist breaks the law they make the whole out-group look bad, but a driver who breaks the law is just "one bad driver."¶ The other 10% is confirmation bias.


    1. I deliver PDFs daily as an art director; not ideal, but they work in most cases. There's certainly nothing rebellious or non-commercial about them

      It reminds me of The Chronicle's exhorting ordinary people to support the then-underway cause intended to banish Uber and Lyft from Austin, on ostensibly populist grounds, when in reality the cause was aimed at preserving the commercial interests of an entrenched, unworthy industry. I saw a similar thing with the popular sentiment against Facebook's PATENTS.txt—a clever hack on par with copyleft which had the prospect of making patent trolls' weapons ineffective, subverted by a meme that ended with people convinced to work against their own interests and in favor of the trolls.

      Maybe it's worth coining a new term ("anti-rebellion"?) for this sort of thing. Se also: useful idiot

    1. It's great to enhance the Internet Archive, but you can bet I'm keeping my local copy too.

      Like the parent comment by derefr, my actual, non-hypothetical practice is saving to the Wayback Machine. Right now I'm probably saving things at a rate of half a dozen a day. For those who are paranoid and/or need offline availability, there's Zotero https://www.zotero.org. Zotero uses Gildas's SingleFile for taking snapshots of web pages, not PDF. As it turns out, Zotero is pretty useful for stowing and tracking any PDFs that you need to file away, too, for documents that are originally produced in that format. But there's no need to (clumsily) shoehorn webpages into that paradigm.

      If you do the print-to-PDF workflow outlined earlier in the thread, you'll realize it doesn't scale well, requiring too much manual intervention and discipline (including taking care to make sure it's filed correctly; hopefully you remember the ad hoc system you thought up last time you saved something), that it's destructive, and that it ultimately gives you an opaque blob. SingleFile-powered Zotero mostly solves all of this, and it does it in a way that's accessible in one or two clicks, depending on your setup. If you ever actually need a PDF, you can of course go back to your saved copy and produce a PDF on-demand, but it doesn't follow that you should archive the original source material in that format.

      My only reservation is that there is no inverse to the SingleFile mangling function, AFAIK. For archival reasons, it would be nice to be able to perfectly reconstruct the original, pre-mangled resources, perhaps by storing some metadata in the file that details the exact transformations that are applied.

    1. it seems that most of these links are rehash of ES6 spec, which is pretty technical

      Yes. The problem also with relying on programmers' blogged opinions for advice and understanding is that a lot of the material is the result of people trying to work things out for themselves in public—hoping to solidify their own understanding by blogging—and it's not expert advice. Aspiring programmers further run the risk of mistaking any given blogger's opinion for deep and/or widely accepted truths. (And JS in particular certainly has lots of widely accepted "truths" that aren't actually true. Something about intermediate JS programmers has led to an abundance of bad conventional folk wisdom.) Indeed, spot-checking just a few of the links collected in the list here reveals plenty of issues—enough to outright recommend against pointing anyone in its direction.

      On the other hand, the problem with the ECMAScript spec is that it has gotten incredibly complicated (in comparison to the relative simplicity of ed. 3). There is a real need for something that is as rigorously correct as the spec, but more approachable. This was true even in the time of the third edition. In the early days of developer.mozilla.org, the "Core JavaScript Reference" filled this hole, but unfortunately editorial standards have dropped so low in the meantime that this is no longer true. Nowadays, there is not even any distinction between what was originally the language reference versus the separate, looser companion for learners that was billed as the JavaScript guide. The effect that it has had is the elevation of some of the bad folk wisdom to the point of providing it with a veneer of respectability, perhaps even a "seal of approval"—since it lives on MDN, so it's gotta be right, right?

    1. this._figureElement = this._page.querySelector("script");

      Better to use querySelectorAll and then filter based on figure designation (e.g. nodeValue.startsWith(" (Fig. 1) ")).

    2. document


      (Caller should also probably look more like:

      let system = new SystemB(document);

      ... where the querySelectorAll return value's role is to act as a list of document figures, for the reasons described elsewhere https://hypothes.is/a/-n-RYt4WEeu5WIejr9cfKA.)

    1. something called federated wiki which was by ward cunningham if anyone knows the details behind that or how we got these sliding panes in the first place i'm always interested

      it looks like my comment got moderated out, and I didn't save a copy. Not going to retype it here, but the gist is that:

      • Ward invented the wiki, not just the sliding panes concept.
      • Sliding panes are a riff on Miller columns, invented by Mark S. Miller
      • Miller columns are like a visual analog of UNIX pipes
      • One obvious use case for Miller columns is in web development tools, but (surprisingly) none of the teams working on browsers' built-in devtools at this point have have managed to get this right!

      Some screenshots of a prototype inspector that I was working on once upon a time which allowed you to infinitely drill down on any arbitrary data structures:



      Addendum (not mentioned my original comment): the closest "production-quality" system we have that does permit this sort of thing is Glamorous Toolkit https://gtoolkit.com/.

    2. if you have any doubts about a plug-in use the most popular ones because

      Possibly true, but dubious.

  4. www.dreamsongs.com www.dreamsongs.com
    1. changing the base code can be expensive and dangerous
    2. The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.
    3. mistake

      Should be "mistakes".

    1. I only allowed smaller closures in the code and refactored the rest into separate top-level functions. This is a deliberate move against the common practice of js programmers. Why? Because I noticed closures make code harder to read.
    1. as a more experienced user I know one can navigate much more quickly using a terminal than using the hunt and peck style of most file system GUIs

      As an experienced user, this claim strikes me as false.

      I often start in a graphical file manager (nothing special, Nautilus on my system, or any conventional file explorer elsewhere), then use "Open in Terminal" from the context menu, precisely because of how much more efficient desktop file browsers are for navigating directory hierarchies in comparison.

      NB: use of a graphical file browser doesn't automatically preclude keyboard-based navigation.

    1. object-orientation offers a more effective way to let asystem make good use of parallelism, with each objectrepresenting its own behavior in the form of a privateprocess

      something, something, Erlang

    2. Functional programming implies much more thanavoiding goto statements, however.It also implies restriction to localvariables, perhaps with the excep-tion of a few global state variables.It probably also considers the nest-ing of procedures as undesirable.
    1. although it probably needs a longer essay with more worked examples and better explanations of the various moving parts to really work for that
    1. http://weblog.infoworld.com/udell/gems/ju_mynewgig.mp3
    2. http://weblog.infoworld.com/udell/gems/ju_mcgraw.mp3
    3. http://weblog.infoworld.com/udell/gems/ju_burbeck.mp3
    4. http://weblog.infoworld.com/udell/gems/ju_gemignani.mp3
    5. http://weblog.infoworld.com/udell/gems/ju_rosenfeld.mp3
    6. http://weblog.infoworld.com/udell/gems/ju_frost.mp3
    7. http://weblog.infoworld.com/udell/gems/ju_idehen.mp3
    8. http://weblog.infoworld.com/udell/gems/ju_HillMcFarland.mp3
    9. http://weblog.infoworld.com/udell/gems/ju_linqMay06.mp3
    10. http://weblog.infoworld.com/udell/gems/ju_singleton.mp3
    11. http://weblog.infoworld.com/udell/gems/ju_martinez.mp3
    12. http://weblog.infoworld.com/udell/gems/ju_rodgers.mp3
    13. http://weblog.infoworld.com/udell/gems/ju_rayhill.mp3
    14. http://weblog.infoworld.com/udell/gems/ju_dcstat.mp3"
    15. http://weblog.infoworld.com/udell/gems/ju_hudack.mp3
    16. http://weblog.infoworld.com/udell/gems/ju_glushko.mp3
    17. http://weblog.infoworld.com/udell/gems/ju_patrick.mp3
    18. http://weblog.infoworld.com/udell/gems/ju_mayfield.mp3
    19. http://weblog.infoworld.com/udell/gems/ju_xbrl.mp3
    20. http://weblog.infoworld.com/udell/gems/ju_suber.mp3
    21. http://weblog.infoworld.com/udell/gems/ju_fielding.mp3
    22. http://weblog.infoworld.com/udell/gems/ju_windley.mp3
    23. http://weblog.infoworld.com/udell/gems/ju_navizon.mp3"
    24. http://weblog.infoworld.com/udell/gems/ju_fahlberg.mp3
    25. http://weblog.infoworld.com/udell/gems/ju_ullman.mp3
    26. http://weblog.infoworld.com/udell/gems/ju_ericson.mp3
    27. http://weblog.infoworld.com/udell/gems/ju_liu.mp3
    28. http://weblog.infoworld.com/udell/gems/ju_schneider.mp3
    29. http://weblog.infoworld.com/udell/gems/ju_russell.mp3
    30. http://weblog.infoworld.com/udell/gems/ju_securent.mp3
    31. http://weblog.infoworld.com/udell/gems/ju_wilkin.mp3
    1. You can use LibreOffice's Draw

      Nevermind LibreOffice Draw, you can use LibreOffice Writer to author the actual content. That this is never seriously pushed as an option (even, to my knowledge, by the LibreOffice folks themselves) is an indictment of the computing industry.

      Having said that, I guess there is some need to curate a set of templates for small and medium size businesses who want their stuff to "pop".

    1. it is also clear that there would be no need for copyleft licences to govern the exercise of copyright in software code by third-party developers at all if copyright did not guarantee rightsholders such a high degree of exclusive control over intellectual creations in the first place

      This is simply not true. The unique character of software under the conventions that most software is published (effectively obfuscated, albeit not for the purpose obfuscation itself, but for the purposes of producing an executable binary) means that reciprocal licenses like the GPL are very much reliant on the existing copyright regime. Ubiquitous and pervasive non-destructive compilation would be a prerequisite for a world where copyright's role on free software were nil.

    1. Simply select some text on this page and make a comment!

      Nope, doesn't work:

      Loading failed for the <script> with source “http://assets.annotateit.org/annotator/v1.2.10/annotator-full.min.js”. annotatorjs.org:242:1

      (assets.annotateit.org is unreachable, and the annotateit.org landing page contains a farewell message "July 14, 2019. The service has now been fully shut down.")

      It would be nice if these were still functional, for historical reasons.

    1. I’m not confident I’ll be able to keep a server running to serve up my notes, so I bundled them up into an archive of pregenerated HTML, which anyone who has a copy can unpack and read, without requiring any online resources.
    1. The array prototype is syntax sugar. You can make your own Array type in pure JavaScript by leveraging objects.

      At the risk of saying something that might not now be correct due to recent changes in the language spec, this has historically not been true; Array objects are more than syntax sugar, with the spec carving out special exceptions for arrays' [[PutValue]] operation.

    1. Of course not. Reading some copyrighted code can have you entirely excluded from some jobs

      There is a classic mistake being committed here. Private policy does not the law make.

      The Wine project wants to exclude you if you've seen laid eyes on Windows sources? That's fine; that's their right. But the Wine devs are neither writing legislation nor issuing binding opinion.

      We see this everywhere. Insurance company wants to have their adjusters follow some guideline when investigating/settling claims? Again, that's fine, but their stance may or may not have anything to do with actual law. Shop proprietor wants to exclude you from the store if you are (or are not) wearing a mask? Okay, just don't infer that this necessarily has any bearing on what is law in the eyes of the courts. Imposing keto on yourself except one cheat meal on Sundays? Fine again, but not law.

    1. it could make sense for it to start a completely new browser based on WebKit

      Indeed. I've argued for awhile that WebKit is an excellent basis for a new, community-developed browser, both strategically and technically. That is, it makes sense to start a browser project based on WebKit even now, whether Hachette exists or not.

    2. The repository software has to be released under a libre license.

      An alternative, don't create a service. Let the Web be the platform.

      If I'm a contributor to the project, then the extension's about.html (or whatever) should both credit me and at my option include a link to the place where I publish or link to useful scripts. This goes for all contributors. The way to share would be to (a) publish their scripts somewhere online and (b) contribute to the project and add their entry to about.html. Alternatively, for people not interested in contributing (and to maintain code quality and avoid poorly aligned incentive structures), the project itself can keep a simple static page up to date, linking to various others' pages as the requests to do so come in.

  5. Jun 2021
    1. They are artifacts of a very particular circumstance, and it’s unlikely that in an alternate timeline they would have been designed the same way.

      I've mentioned before that the era we're currently living in is incredibly different from the era of just 10–15 years ago. I've called the era of yesterdecade (where the author of this piece appeared on Colbert a ~week or so after Firefox 3 was released and implored the audience to go download it and start using it) the "Shirky era", since Shirky's Here Comes Everybody really captures the spirit of the times.

      The current era of Twitter-and-GitHub has a distinct feel. At least, I can certainly feel it, as someone who's opted to remain an outsider to the T and G spheres. There's some evidence that those who haven't aren't really able to see the distinction, being too close to the problem. Young people, of course, who don't really have any memories of the era to draw upon, probably aren't able to perceive the distinction as a rule.

      I've also been listening to a lot of "old" podcasts—those of the Shirky era. If ever there were a question of whether the perceived distinction is real or imagined these podcasts—particularly shows Jon Udell was involved with, which I have been enjoying immensely—eliminate any doubts about its existence. There's an identifiable feel when I go back and listen to these shows or watch technical talks from the same time period. We're definitely experiencing a lowpoint in technical visions. As I alluded to earlier, I think this has to do with a technofetishistic focus on certain development practices and software stacks that are popular right now—"the way" that you do things. Wikis have largely fallen by the wayside, bugtrackers are disused, and people are pursuing busywork on GitHub and self-promoting on social media to the detriment of the things envisioned in the Shirky era.

    1. The Future's Here, But Unevenly Distributed

      The title here is a reference to the William Gibson quote "The future is already here — it's just not very evenly distributed."

    1. This piece is syndicated here from its original appearance as a post in Wired Insights https://www.wired.com/insights/2013/02/rebooting-web-comments-wire-them-to-personal-clouds/.

      Jon's followup is here http://jonudell.net/tpc/28.html.

    2. Some of the best customers of such a service will be academics.

      Indeed. Web literacy among the masses is pitifully low. Browsermakers are certainly to blame for being poor stewards. Hot Valley startups are responsible as well. (See https://quoteinvestigator.com/2017/11/30/salary/.)

    3. But here's the twist. That edit window is wired to your personal cloud. That's where your words land. Then you syndicate your words back to the site you're posting to.

      This is more or less how linked data notifications work. (And Solid, of course, goes beyond that.)

    4. If they did I think there would actually be some quality of discussion, and it might be useful

      I used to think this. (That isn't to say I've changed my mind. I'm just not convinced one way or the other.)

      Another foreseeable outcome, relative to the time when the friend here was making the comment, is that it would lead to people being nastier in real life. Whether that's true or not (and I think that it might be), Twitter has turned out to be a cesspool, and it has shown us that people are willing to engage in all sorts of nastiness under their real name.

    1. For some reason, this page doesn't link back to the item's overview/collection entry. It can be found here:


    1. There’s an old saw about how you carve a statue of an elephant – you start with a big block of stone and remove all the stone that doesn’t look like an elephant. Easy!

      You Just Chip Away Everything That Doesn’t Look Like David

      (Found while looking into this, since it's said to be an "old saw" here, but I'm much more familiar with the draw the rest of the fucking owl from the modern meme-o-sphere.)

      It's an instructional sketch for "How to draw an owl" in two steps.  The first step contains some roughed-in ovals, an is labelled "Draw some circles".  The second step shows a completed artistic rendering of an owl perched on a branch, and it is labeled "Draw the rest of the fucking owl".

    1. I tried all the different static site generators, and I was annoyed with how everything was really complicated. I also came to the realization that I was never going to need a content management system with the amount of blogging I was doing, so I should stop overanalyzing the problem and just do the minimum thing that leads to more writing.

      Great way to put it. One thing that I keep trying to hammer is that the "minimum thing" here looks more like "open up a word processor, use the default settings, focus on capturing the content—i.e. writing things out just as you would if you were dumping these thoughts into a plain text file or keeping it to, say, the subset of Markdown that allows for paragraph breaks, headings, and maybe ordered and unordered lists—and then use your word processor's export-to-HTML support to recast it into the format that lets use their browser to read it, and then FTP/scp/rsync that to a server somewhere".

      This sounds like I'm being hyperbolic, and I kind of am, but I'm also kind of not. The process described is still more reasonable than the craziness that people (HN- and GitHub-type people) end up leaping into when they think of blogging on a personal website. Think about that. Literally uploading Microsoft Word-generated posts to a server* is better than the purpose-built workflows that people are otherwise coming up with (and pushing way too hard).

      (*Although, just please, if you are going to do this, then do at least export to HTML and don't dump them online as PDFs, a la berkshirehathaway.com.)

    2. I could write something to do that for me, but then I'd just end up with a static site generator anyway.

      I'm not sure this is true! The intended use has a lot more influence over how people do things than people think!

    3. I've looked at GitHub Pages/Jekyll, all the cool kids seem to be doing that? It seemed kind of complicated

      I can't wait for the people pushing GitHub Pages and building products/integrations on top of it to realize this, but I'm not sure they ever will.

    1. Why do people start smoking? Surely they know it's addictive, expensive, and bad for you

      Because of of the responses that this got, this makes for a great example of people's inability to get the question right before trying to get the answer right.

    1. Avoid 'global magic' or things that are defined outside of scope where they are not visible.

      From the commentary in the video "Workflow: Universal project folder structure"

      "I can intuit that this has something to do with[...]"

      "I look at this folder[...] and I get some sense[...]"

      "It's got this package dot bin thing, oh okay, so that means there's also a special command that I can run with this[...] you understand there is a command here"

    1. it's more convenient to to just write down the properties that you have right next to the class as you write it
    1. This would be good as a bookmarklet--when viewing an image, you invoke it, and it writes over the image with the details of the underlying structure.

      See also: "Select a window, click the 'flip' button to see what is 'behind' the window, as a metaphor to see what the application is doing"

  6. May 2021
    1. select * from users

      We can preview the data, and since that looks good, let's add a table to the canvas to display it. When we do this, it helpful pre-fills the data from our last query.

    1. many people have attached sensors

      This differs from LDN, where the the annotation service is squarely under the control of the document author. This is also using sensor attachment in a different sense that the way it first appears above. The application is more akin to RSS. With RSS, the links exist in some other "document" (or something like it; generall can be modeled as OPML, even if it's really, say, an sqlite store).

    2. So she writes an explanatory note for Jack, links the note to the Parallel Compiling report, and then links the note to Jack's mailbox: in this open hypertext system, a mailbox is simply a publicly readable document to which the owner has attached a sensor.

      Okay, so this is back to looking like LDN, except the (novel?) idea that after sending the annotation to the annotation service responsible for annotations to the report, her final annotation gets sent to that that annotation service corresponding to a different document—Jack's mailbox. Interesting!

      (Maybe this is explicitly laid out as a possibility in one of the several pieces associated with LDN and I just never noticed?)

    3. a hypermedia server might use sensors to alert users to the arrival of new material: if a sensor were attached to a document, running a new link to the document would set off the sensor

      Linked data notifications?

      (I like the "sensor" imagery.)

    1. Surely RDF already has something like this...? I tried looking around briefly but couldn't find it.

    1. transformative

      Conjecture: (almost?) every instance of reimplementation by anyone should be considered fair use on the basis that it is ipso facto transformative.

    2. consistent withthat creative progress that is the basic constitutional objective of cop-yright itself
    1. Bonus points if it can walk the user through the upstream contribution process

      I've done absolutely no actual work in this part, but this is what the third part (the C) in the "ABCs of triple scripts" is supposed to be about.

    2. that involves looking up where to find Guix's source code, `git clone`ing it, finding the Guix revision I'm currently on with `guix describe` so I can check out the same one for consistency's sake, `make`ing it, `guix environment guix`, using `pre-inst-env`, etc

      This is a direct response to the question, so it makes sense to write it out, but Spitz's piece (linked earlier) Open source is not enough describes the problem adequately.

    1. This is eventually supposed to be the default client on graph.5apps.com.

      TODOs, bugs, and ongoing development notes are organized in a semi-private Hypothesis group—invitation is required, but invitations open to anyone with the link. That includes you; here's the link to join the group: https://hypothes.is/groups/y6v5zd8n/streamline-w2g-client

    1. A w2g <cite> tag identifies/distinguishes itself in css by have a w2gid propert

      If you look at the incomplete graph.js implementation, you can see that it's actually using a class instead. This is good! However, I advocate for class names that happen to also be a hostname + resource (i.e., like URL, but omitting the http:// part).

      (I suppose that, alternatively, if someone wanted to use a shorter class name, such as "w2g-tag", then graph.js could be configured to allow for that, but it would need to be explicit configuration on the author/publisher's part.)

    1. _parseDefinition

      Revisiting this some months later while thinking about programming in general, I realize that that what I want from a nextgen magic development environment are are live comments.

      Take this _parseDefinition method, for example, and now compare it to the RSCAssembler's getRR method. The latter has a comment (with an interesting diagram), and the former does not. Suppose even that there were a comment for the _parseDefinition method—it might contain a snippet that's meant to be sample input to help visualize what the method is doing—there would still be the matter of needing to simulate the program in your head. Really, what I want is to be able to write out a snippet and then while reading the code here, anyone can mouse over each statement in the method definition and see what effect it has—say a caret moves along, pointing at the scanner "tip", and visually chunking the tokens.

      One should also be able to dynamically modify that snippet—let's say they wanted to "link" the live, scrubbable execution to a particular point in Fig. 1 (the fixT entry instead of fixP, for example)—in this case that snippet should "take over" the live comment, so we can concretely visualize execution of it instead. We should go further than that, even, and not even require the reader know which part of Fig. 1 is actually handled by this section of the code. We should be able to dynamically discover, based on the Ctrl+Space activation, that _parseDefinition is used to handle the fixP, fixD, and fixT lines, and then then reader can point to them (like the difference between a command-line interface where you have to know what you're allowed to do and how to say it, compared to a graphical interface that visually communicates the program's affordances).

      The closest I've seen to this are the Moonchild editor :https://harc.github.io/moonchild/ and REPLugger :https://github.com/Glench/REPLugger.

    1. Here's a novel(?) way to explain it that should appeal to those who claim that the host revealing the goat behind door #3 doesn't "matter":

      You are given the choice of 3 doors to pick from. Someone else is given the compulsory opportunty to "bet" against your pick. (Stop here and think of your odds of getting it right compared to their odds of beating you.)

      Now, the host reveals door #3. Your adversary originally had 2/3 odds of winning, and indeed this is where the door #3 revelation doesn't "matter": your adversary's odds that you were wrong are still 2/3. Let's mix up the game, though: suppose the host gives you the opportunity to switch places with the person betting against you—so if you switch then your adversary gets stuck with whatever your original guess was, and in the event that your original guess was wrong, then you actually win the game. This is exactly the balance of odds presented to you in the original formulation.

    1. What do we know that no-one else does? What’s a non-obvious controversial true fact? How does our system exploit this?

      Widely relevant questions beyond even the selected topic.

    1. there’s an ancient and powerful technology at work here
    2. It’s more productive to work with fewer but larger documents that bundle many bits and pieces together. If I send you a link to a section called out in the TOC, it’s as if I sent you a link to an individual document. But you land in a context that enables you to find related stuff by scanning the TOC.
  7. Apr 2021
    1. it is so because nobody owns it, we all own it. It can't go bankrupt, it can't pivot to be something else, it can't lose all its best features when a new product manager is promoted and wants to make a statement. Things that every proprietary system will do and eventually disappear.
    1. Documents should offer the same granularity.

      That neither content creators nor browser vendors are particularly concerned with the production and consumption of documents, as such, is precisely the issue. This is evident in the banner that the majority of the work has occurred under over the last 10+ years: they're the Web Hypertext Applications Technology Working Group.

      No one, not even the most well-intentioned (such as the folks at Automattic who are responsible for the blogging software that made Christina's post here possible), see documents when they think of the Web. No, everything is an app—take this page, for example; even the "pages" that WordPress produces are facets of an application. Granted, it's an application meant for reading the written word (and meant for occasionally writing it), but make no mistake, it's an application first, and a "document" only by happenstance (i.e. the absence of any realistic alternative to HTML & co for application delivery).

    1. You can do less with media that’s merely digitized than with the real thing
    2. Though its format can be copied and manipulated, HTML doesn’t make that easy.

      In fact, HTML makes it very easy (true for the reasons that lead Mark to write that it can be copied and manipulated). It's contemporary authoring systems and the typical author-as-publisher and the choices they make that are what makes this difficult.

      The future of rich media lies in striving to be more like dead media (or at least mining it for insights by better understanding it through thoughtful study), rather than the misguided attempts we've been living inside.

      (This is something that I've done a 180 on in the last year or so.)

    3. It’s designed so that whoever produced the video controls how it appears, and how it’s used.

      It is exactly that "timid" ("tepid"?) attempt at dynamism that has led to these circumstances.

    1. Ideally, GitHub would understand rich formats

      I've advocated for a different approach.

      Most of these "rich formats" are, let's just be honest, Microsoft Office file formats that people aren't willing to give up. But these aren't binary formats through-and-through; the OOXML formats are ZIP archives (following Microsoft's "Open Packaging Conventions") that when extracted are still almost entirely simple "files containing lines of text".

      So rather than committing your "final-draft.docx", "for-print.oxps" and what-have-you to the repo, run them through a ZIP extractor then commit that to the repo. Then, just like any other source code repo, include a "build script" for these—which just zips them back up and gives them the appropriate file extension.

      (I have found through experimentation that some of these packages do include some binary files (which I can't recall offhand), but they tend to be small, and you can always come up with a text-based serialization for them, and then rework your build script so it's able to go from that serialization format to the correct binary before zipping everything up.)

    1. Edit

      Why does the Edit link point to /contact/edit, but the Unpin link point to /derp/contact/unpin?