gaxun

Sure.

- On page 715 of Volume 4A, he had something like \`a when he meant to have just à.

- In Volume 1, Fascicle 1, there is a convention that the "main" entry point of an MMIX program begins at LOC #100. The convention is established early on and repeated throughout the text. However, at no point is it explained why LOC #100 was chosen (instead of LOC #0, LOC #80, or whatever). It could be gleaned through careful study -- LOC #0-#80 are reserved for trip/trap handling and one more location before #100 is reserved for a special second entry point -- but you basically had to read the entire fascicle to find /all/ of these. A naive user would be likely to try writing a program beginning at LOC #0 and wonder why it didn't seem to behave correctly. My suggestion was to just add a note explaining why LOC #100 was used. He agreed and you can find the added note in the latest errata for Volume 1, Fascicle 1.

Nice to see multiple of us are on here.

> I imagine most of these checks (definitely all $7 of mine)

The 0x$2.00 check I got from 10 Feb 2020 was for one typographical item in Volume 4A and one pedagogical improvement in Volume 1, Fascicle 1. So it is certainly possible to still get checks for material that is already published.

Since it is now 2020, anyone with bug reports from the typography stuff should send them in soon, wouldn't want to miss the deadline.

> when's the last time Knuth wrote a check for TAOCP?

Pretty recently. I just got one in the mail today.

The author should have written to Donald Knuth with an interview request for this piece. It would have added something special beyond just repeating what's already visible on his website.

I wrote to Professor Knuth about a project I did a year or two ago and was pleasantly surprised to receive a two page handwritten note in response. So it seems like the no-email filter is probably still working well for him.

Indeed.

Web browsers are generally free to use and there are several serious contenders and many less popular ones.

So the main thing they should be competing on is user experience.

But it seems to me that browsers frequently fail to deliver a user-first experience.

The browser should only take actions specifically requested by a user, as his agent. Everything about the experience needs to be reframed from that perspective.

Some browsers lately seem to be doing a little better at this, but just adding "advanced flag" features on to an existing product isn't going to help mainstream users at all.

> hurdle of setting up team repositories with safe credential management...like for any kind of collaboration

Identity continues to be the key selling point of keybase. I'm excited by this.

I can keep clones of my private repositories here. Things like dotfiles and configurations. That sounds like a good start. And I can also easily share code to people who need to see it.

I spent some time attempting to work with the W3C Web Annotation Data Model. That data model is serialized as JSON-LD.

After spending about 50 hours reading the documents and attempting to implement some of it, I have a general idea what JSON-LD is.

I wasn't really trying to achieve anything, so I basically quit once something seemed opaque enough I couldn't figure it out in a short period of time. When I visited the JSON-LD Test Suite page to see what implementations are expected to do [0], I found:

> Tests are defined into compact, expand, flatten, frame, normalize, and rdf sections

I had a hard time figuring out what each of these verbs meant, and they were about all that the various implementations I found did. For example, the term normalize doesn't even appear in the JSON-LD 1.0 specification [1]. shrug I'm sure I could have figured out more if I spent the time to actually read the whole thing and all the related documents.

[0]: https://json-ld.org/test-suite/

[1]: https://www.w3.org/TR/json-ld

I've been trying out this extension for a few days.

What I would really like to see from this extension is a 1-click way to sign any message I'm writing, anywhere on the internet. Along with that would be the ability to verify that a keybase signature found in the wild belongs to a particular keybase user. Then I can initiate out-of-band discussions with the author of a comment on someone's blog, not just with a Reddit or Hacker News poster.

Having the keybase chat button appear next to posts on sites like Reddit, HN, etc. seems like a great step toward a "metaweb" platform as well. For example, I could let someone know about the typo in their post via keybase chat, rather than polluting the public comment stream.

Very excited.

> Really, what a robust commentary system needs is to map many comments to many units of text

This is actually built into this specification. From the Web Annotation Data Model [0]:

  - Annotations have 0 or more Bodies.
  - Annotations have 1 or more Targets.

So one "Annotation" object can have multiple bodies (descriptions) attached to multiple targets.

> 3. Relationships between comments

This sounds more like an implementation detail of a client than part of the protocol or data model put forth by the W3C group.

However, I believe this can kind of be done server-side with the Web Annotation Protocol [1]'s idea of Annotation Containers. Your server can map a single annotation to multiple containers. So perhaps you have an endpoint like `http://example.com/a/` and you want to arrange a hierarchy of comments. You could provide a filtered set of the annotations at `http://example.com/a/romeo/consonance/`, and similar endpoints.

So basically what I'm saying is it seems like the protocol here isn't going to get in your way, it's just incentive to use this particular model for storing and transferring your data.

[0]: https://www.w3.org/TR/annotation-model/#web-annotation-princ...

[1]: https://www.w3.org/TR/annotation-protocol/#container-retriev...

I have posted a couple things related to this but never finished a complete summary of my thoughts. These two attempts come close:

In [0], I shared some really basic thoughts about how this could be done by users of a particular VCS package, git. Two line summary:

  You run `git announce [name] [tracker]` to tell a git tracker
  that you've got your own fork. If you host your repository
  in a public place, the tracker just checks your repo for
  updates so other users can stay informed.

At [1], I describe a similar system with a specific type of frequently-forked software (GPL'd tools). This seems less tied to using git. This software is available from diverse sources in multiple VCS systems and may be wildly divergent. Comparing the sources seems valuable, but difficult.

Alternatively, Fossil does "distributed version control and issues", but it's really just meant to be one central location for a particular project.

Thought I'd share. I'm on board with everything you're saying. There are clearly some issues as well, though. The biggest one I see is related to the "paradox of choice" -- when there are four forks all just one commit different from each other, how do you know which one(s) to use? This is why we usually just follow the leader (maintainer) and use the one true source. End users don't have the ability to quickly know which patches to accept and reject. Even a reputation system wouldn't necessarily provide clean signals, due to bandwagon type effects.

Unfortunately, I already have enough trouble picking between `iron` and `nickel` as a Rust web framework.

[0]: https://www.gaxun.net/ideas/git-announce/

[1]: https://news.ycombinator.com/item?id=13028079

Thank you for the explanation. This has been my only experience with the W3C system and as an outsider it was very intimidating. I'm certainly willing to accept the idea that I wasn't going about things the right way or understanding what I was reading!

> there's nothing in the spec that prohibits extensions to the set of fields

Correct. But since it has all this "JSON-LD" stuff baked in, you need to also carefully define and publish the extra fields.

I tried emailing two of the names listed at the time, for two different purposes. I got a little bit of a response from one, nothing from the other.

I read the "rules" for W3C groups and in order to actually participate you need to be a member of a big organization and all this other stuff. I'm not sure anyone would have listened.

As I mentioned in another comment, these tests can be trivially passed. You just paste in some JSON data. To pass "all" the tests you actually only need to implement a small handful of the fields. The rest of the tests are qualified by something like "if present" -- so you pass those by just not having anything present in your test case.

When I use the hypothes.is extension, I see queries in my browser's developer console that do not look anything at all like they are querying annotation collections as defined in the spec.

The data returned from these queries is close to the spec but includes many fields that aren't in it. These extra fields seem to be conveying important information for their application.

Edit: I ran one of their annotations through the W3C tests. Five failed tests. Including one of the most important fields:

       {
          "name": "1:2 Implements **Annotation _id_ key** which has a **single value** that is a **string of format uri** - [model 3.1](https://www.w3.org/TR/annotation-model/#annotations)",
          "status": "FAIL",
          "message": "assert_true: ERROR: Annotation is missing id key or its value is not a single string of format uri.; expected true got false"
        },

This is why I said I'm not confident they are actually using it.

There is no built-in detection of content changes in the standard, but it is designed to be potentially robust to changes.

It depends what type of specifier you use. The data model provides a number of specifier types. A "text position selector" would lock in the annotation at a certain point in the text like the 142nd character. An "xpath selector" would use a DOM-like notation to place the annotation.

If your annotation is a "highlight" then you would need to use these selectors within a "range selector" with a specified start and end point.

If you want your annotations to be robust to content changes, you will probably need to use multiple specifier types. This is allowed by the specification but it felt very clumsy to me to implement.

If the target is available at multiple URLs, there is something available to handle it, but the hosts of the content need to add links to the canonical URL so your annotation software can use that.

That would be up to the endpoints hosting annotations. They would need to build anti-spam or reputation into their server system. Not part of the specification.

> Is anyone using these? The blog post is put out by a company I've never heard of

I spent time trying to figure out if hypothes.is even uses the protocol and data model in their own software. I'm not confident enough in my analysis to say they absolutely aren't, but I'm also not convinced they are really using it. They would probably counter that it wasn't even a standard yet, but I'm not even sure how close their current model is to this.

They did have some of their employees in the W3C working group. Several of the others seemed to be in the "library" field.

I'm not sure where else to complain so I will just leave this example here. I was frustrated reading the specification because it contradicts itself.

The data model has a required field called `id` which is an IRI (like a URI) that is basically a globally unique identifier.

The protocol allows an annotation to be transmitted without the `id` field attached.

Why? Is the field required or not.

In my toy implementation I had my browser client attach a v4 UUID as the `id` field before sending it to my server. But it would have still been valid without it.

Read the W3C Recommendations for the protocol and data model. Neither has any mention whatsoever of a notification or alert:

https://www.w3.org/TR/annotation-protocol/

https://www.w3.org/TR/annotation-model/

Any type of notification would be an extra feature performed by annotation software, but is not a part of the specification.

Your annotation client could query the annotation server at a known endpoint for new annotations. The results should be ordered and paginated, but the order and pagination used seem to be at the discretion of individual implementations.

I spent about 40 hours in December and January implementing a browser extension for Chrome and a server that speak the web annotation protocol and use the web annotation data model in this specification.

It was very easy to pass the tests the W3C working group used to verify that they had two working implementations of the data model and protocol. Most of the test default to passing if the specified tag is not present. Basically, it's not clear whether a serious, real attempt to use this has been made. I'm unconvinced that the specification is robust enough to be useful without ending up with a lot of vendor lock-in.

The toy extension was playing around with using these annotations to alert publishers and potentially other users of typos in their articles and pages. It would be nice to have a side channel to report typos other than just using the comment section or trying to find an email address. Will the "meta web" ever catch on?

I never published it but I still might add a page about my experience on my website. I have posted about the idea there before.

I have been drafting an 'Ideas' post about the following idea, but it's not done yet and this looks like as good a place as any to look for some early feedback. This might not have as much clarity as I'd like.

The general idea is to have a site that can track various projects that release their own copy of GPL (especially, but other licenses as well) software. So Apple ships their version of {bash, etc.}, and so does your router, and someone else's refrigerator. And this site ("GPL Hub?") just links to all the places that are hosting their own version of {bash, etc.}. Maybe it could even show how they've diverged, although that might not be so easy.

Recently it has become very trendy to host all code in one centralized location like GitHub. But GitHub isn't really that great at showing you the "forks graph" anyway. Many companies that ship GPL code have archives like this available on their own websites. This could help increase visibility and give users an easier time finding the source code. I'd love to know how many copies of different GPL projects are out in the wild. Maybe for the companies that don't publicly host their GPL code, someone who makes a successful GPL request could share the code on this same site.

Those are some of the ideas, I'd still love to finish the post sometime but it's a bit too vague for me to say anything concrete yet. Any direction to related works or explanations of why this is a bad (or good) idea would be much appreciated!

I'm reading the page on how the distributed bug tracking works. I've heard of Fossil before but never dug too deeply.

> But if a timestamp on a ticket change artifact is off by months or years, it can seriously confuse the replay algorithm for determining the current ticket state.

I understand the simplicity of merging all the ticket comments by timestamp, but couldn't they at least include a reference to one or more recent comments to help establish order when clocks are off? Still wouldn't avoid intentional bad actors, but there are bound to be people with misconfigured clocks.

If I'm working on a Fossil repository and I want to see what bugs everyone else has reported, where do I go to get a list of other copies of the repository so I can query them for new bug reports? Is there some kind of tracker that lists all the people currently publishing the same Fossil repository, so I can connect to each one and ask for updates?

I wrote a post [0] on my site about this concept recently. It's not really polished, I think the thoughts were incomplete. It was written in the context of git due to its ubiquity these days, but the concept should apply the same to other DVCS. I know I'm full of a lot of questions and few answers, but questions help me learn.

[0] https://www.gaxun.net/ideas/git-announce/

You can also call me a hypocrite. My MX records point to Google and my A record points to gitlab.com's GitLab Pages.

I'm actually not brave enough to open a few public ports on a server I own and manage and drive traffic there. It's a mix between "scared" and "it only took an hour to set up the entire thing the easy way."

But I can sleep soundly knowing that if any of the providers I'm currently using become incompatible, I can move things very quickly to a new location.

Just to be clear up front, my site is actively trying to be a demonstration of the ideas I outlined in the above post, in addition to being an actual site. It's still a work in progress and I'm letting it evolve piece by piece. There are many unanswered questions.

> But only after consent from your the sender, right?

I'm struggling to decide the right way to handle this. So far, if the message is substantial and I want to reply for follow-up, I also ask directly for permission. If it is a small message or I otherwise don't end up with consent, I'll remove any personally identifying information and/or paraphrase the message. You can see this in action at [0].

I'd love to know where most people think the proper line is. I usually consider direct email to be a rather private communication channel.

[0] https://www.gaxun.net/commentary/knuth-challenge/comments/

My "social network" is the internet. I can control where my domain resolves and I can serve content over HTTP and handle email via SMTP.

Anyone can link to my site from whatever social network they use.

I may or may not be able to link to everyone else, though. So far, I have no external links on my site. They're too likely to be broken in a year or three. If I get email related to my site, I often post it to the site.

I hope I can continue to interoperate with other people like this. I have tried a couple other social networks like Hacker News and Twitter, but if they disappeared or acted in a way I didn't like, I could abandon them without much loss.

Do I have any reason to be scared that my current setup might become "closed" in the future? Not trying to be paranoid, just wondering.

> simpler hardware that an individual could completely understand

Our hardware now is so much more complex, what has it gained us? The quick answer is performance, but is it true? What about correctness? Hard to prove either way, but my guess is we've gained a little bit on performance and lost on correctness.

You've just made my day. I've had some ideas brewing on this topic for years. It is now at the top of my reading list....along with the other suggestions in this topic.

> Would love to see Knuth's Challenge setup in a repo for collaboration.

Go for it!