Thanks for posting this on my 42nd birthday.

> By pinpointing the location and velocity of around 99 specific points in our galaxy

Isn't that impossible?

Clang's experimental -Wlifetime warning finds the string_view issue:

warning: passing a dangling pointer as argument [-Wlifetime]
note: temporary was destroyed at the end of the full expression

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fgcc.godbolt.org%2Fz%2FbQxC...

The description of the flag says:
"When disabled, the site isolation mode will be determined by enterprise policy or field trial."

The flag is shown as disabled for me, but it's obvious from Chrome's task manager that site isolation is enabled.

FWIW, I wrote up a somewhat in-depth analysis of this SFLC / Conservancy dispute here: http://www.rants.org/2017/11/c...

TL;DR: Software Freedom Conservancy is behaving appropriately, and SFLC is not.

I've had email for at least 4 other people with my name.
When I was invited to a work party, I replied explaining that I'd been getting email for someone else with my name. It turned out that he had an @ymail.com address and people had been misreading it.

a true AI that could pass the Turning Test would itself want a PDA to help it out

Heh. And the converse also! I once overheard a conversation where someone said "If my phone really was smart, it wouldn't want to be my phone in the first place."

This has already been answered here: http://marc.info/?l=openbsd-mi...

+1 on "The Future Does Not Compute". One of my favorite books on this topic; IMHO it didn't get enough notice when it was new -- would be nice to see it get some now.

And Chris Daw, if you're out there: I still have your copy! I bought my own long ago; I've been trying to track you down ever since to return yours.

Do you also like the tree conflicts you get when moving directories around in your project? Those are my favorite thing in SVN. In theory, they've made this better in the new version but I'll believe it when I see it myself. That's something about SVN that just really pisses me off.

Tree conflicts are inherent to any version control system, not just Subversion.

People complain about Subversion's tree conflict handling a lot. I believe this is because development work done so far was only about detection of tree conflicts, leaving many users helpless because tree conflicts can be complex and hard to understand and resolve.

The 1.8 release is taking some steps towards the eventual goal of helping users resolve any tree conflicts instead of merely detecting them. If you move a file or directory in Subversion 1.8, and need to update the working copy before committing the rename, and the update receives edits for the renamed file or directory, you'll now see a menu which allows you to apply the incoming changes to the renamed location:

Tree conflict on 'foo.txt'
> local file moved away, incoming file edit upon update
Select: (mc) apply update to move destination, (p) postpone,
(q) quit resolution, (h) help:

This only works for 'svn update', however. It doesn't work for 'svn merge', yet. That's planned for a future release.

It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk.

This limitation has been lifted in 1.8. As long as you use no merge commands more complex than

svn merge ^/branch/to/merge/from

the merge works in either direction and should never flag spurious conflicts caused by changes being applied more than once.

There were ways to work around deleting a reintegrated branch in 1.7, by the way. But the new 1.8 merging works better. Just forget about --reintegrate, don't use any -r or -c options, and you can always merge in either direction without any need for deleting branches.

I'm a Subversion developer and would like to clarify this bit of the summary:

Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.

The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.

Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete, with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.

a window into the nationwide scope of the FBI's surveillance, monitoring, and reporting on peaceful protesters

Here's another such window:
http://events.ccc.de/congress/2012/Fahrplan/events/5338.en.html
http://mirror.fem-net.de/CCC/29C3/mp4-h264-LQ-iProd/29c3-5338-en-enemies_of_the_state_h264-iprod.mp4