Nit: Node 17 is the Not Found node. Everything is a node.

Negative. There is no row in our node table with node_id=17. The Not found node is 3544.

In addition, there is vestigial (archeological?) evidence that node 17 was a container-type node, just like the succeeding five nodes. Specifically, perlfaq edit page points to node 17 as its parent. And if you try to edit a perlfaq node, you get a blank page. That's a pretty low-level error! Try it.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

Update: In order to make it possible to edit perlfaq nodes, I modified perlfaq edit page to have fornicator formcontainer (18) as its parent container, rather than 17. That's the specified container for most of the other 'edit' htmlpages.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

Going by what's in the extant nodeballs, the following node IDs never had any node, at least on PM: 17, 38, 103, 104, 105, 108, ...

It appears that gaps naturally arose as a result of loading nodeballs into the database. They would typically be loaded to occupy a sequence beginning at some number "safely" above the current highest node ID.

What's funny is when that would happen, and then some user-generated node would get created, such as a user, and then another nodeball would get loaded, above some small gap.

Regarding Node 111:

As of this writing, node 111 does not exist, and probably hasn't for quite some time.

Interestingly, wombat's The True Catacombs of Perlmonks, written way back in early 2001, has a non-null entry for this node:

111: Guest User: by vroom
A user created on 10/4/99. Again the date! 10/4/99 This ties in with the Bavarians, I just know it. Fnord!

Then chromatic adds this comment:

The date is probably the release date of the Engine vroom used to set things up.

Now here's the interesting thing I just discovered:

If you look at the file nodetype in the Type Tree, you'll see:

Deleters:    [no such node, ID 111]
[download]

My conclusion is that it was indeed a user; and likely a user named Guest User. This is probably the user which was meant to be what we now now as Anonymous Monk. The fact that its intended role was taken over by the latter explains why it was destroyed.

Looking on E2, we see Guest User, created on 1999-10-07 ... a mere three days after our Guest User!

Oddly, its node_id is rather high: 779713. And it's not at all clear that E2's Guest User serves the same role as our Anonymous Monk / Slashdot's Anonymous Coward. It is credited with no writeups on E2.

Should I make any changes?

I could re-create the user node and give it ID 111 and title "Guest User". This would have the effect of making Guest User not a failure and giving the file nodetype a valid Deleters. I don't know that either of these is worthwhile. No one uses the file nodetype; there are no extant nodes of this type.

I could re-assign the Deleters of the file nodetype to Anonymous Monk, as that would fulfill the (probable) intentions of vroom. But again, no one uses that nodetype.

All it would do is crank up the "referential integrity" of the site a bit. But as they say: it ain't broke, so don't "fix" it.

Update:

I fixed it. :-)

I created a user node. Then I posted this note. (Its node ID was one higher than the new user.) Then I reassigned the new user node's ID to be 111. That left a gap in the node id sequence where the new user was. So I reassigned this note's ID to put it in that space. Unfortunately, that left at gap, so I created a file to fill it. ;-D

Update 2:

It turns out that node 111 (Guest User) still existed -- in the tomb! That's where nuked nodes go. And the gods have a function whereby nodes in the tomb can be raised to life again. So I did that for node 111. However, to do that, I had to make room for it at slot 111 (as well as the node title, i.e. the user name). So I changed the node ID of the one I had created to 11100000, and then raised the original Guest User into slot 111. Unfortunately, placing a node at ID 11100000 had the effect of setting the node ID sequence to that value; so all subsequent nodes will start from there. Sadly... This creates a huge gap in the node ID sequence. Mea culpa, mea culpa, mea maxima culpa! :-(

My reflex would have been to remove the unused node type, because I'm reminded of

It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away. (Antoine de Saint Exupéry)

A perfectly valid point. However, deleting stuff in the Everything engine leaves gaps in the node ID sequence. And leaves people with questions. That's exactly what happened with Guest User. The general attitude amongst the developers has been to leave things where they are, and mark them as "unused" or something like that. Who knows - maybe some day we'll have a need for a 'file' nodetype...