content: rename articles to reinforce convention of short URLs

The Go blog started out on Blogger
(http://web.archive.org/web/20100325005843/http://blog.golang.org/).
Later, we moved to the current self-hosted blog server
with extra Go-specific functionality like playground snippets.

The old Blogger posts have very long URLs that Blogger chose
for us, such as "go-programming-language-turns-two" or
"two-go-talks-lexical-scanning-in-go-and", predating
the convention of giving posts shorter, more share-friendly,
typeable names.

The conversion of the old Blogger posts also predated
the convention of putting supporting files in a subdirectory.

The result is that although we've established new conventions,
you wouldn't know by listing the directory - the old Blogger
content presents a conflicting picture.

This commit renames the posts with very long names
to have shorter, more share-friendly names, and it moves
all supporting files to subdirectories. It also adds a README
documenting the conventions.

For example, blog.golang.org/go-programming-language-turns-two
is now blog.golang.org/2years, matching our more recent birthday
post URLs, and its supporting files are moved to the new 2years/ directory.

The old URLs redirect to the new ones.

Change-Id: I9f46a790c2c8fab8459aeda73d4e3d2efc86d88f
Reviewed-on: https://go-review.googlesource.com/c/blog/+/223599
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

1 files changed, 0 insertions, 66 deletions

diff --git a/content/debugging-go-code-status-report.article b/content/debugging-go-code-status-report.article
deleted file mode 100644
index 7881bc5..0000000
--- a/content/debugging-go-code-status-report.article
+++ /dev/null
@@ -1,66 +0,0 @@
-# Debugging Go code (a status report)
-2 Nov 2010
-Tags: debug, gdb
-Summary: What works and what doesn't when debugging Go programs with GDB.
-
-Luuk van Dijk
-
-##
-
-When it comes to debugging, nothing beats a few strategic print statements
-to inspect variables or a well-placed panic to obtain a stack trace.
-However, sometimes you’re missing either the patience or the source code,
-and in those cases a good debugger can be invaluable.
-That's why over the past few releases we have been improving the support
-in Go’s gc linker (6l,
-8l) for GDB, the GNU debugger.
-
-In the latest release (2010-11-02), the 6l and 8l linkers emit DWARF3 debugging
-information when writing ELF (Linux,
-FreeBSD) or Mach-O (Mac OS X) binaries.
-The DWARF code is rich enough to let you do the following:
-
-  - load a Go program in GDB version 7.x,
-  - list all Go, C, and assembly source files by line (parts of the Go runtime are written in C and assembly),
-  - set breakpoints by line and step through the code,
-  - print stack traces and inspect stack frames, and
-  - find the addresses and print the contents of most variables.
-
-There are still some inconveniences:
-
-  - The emitted DWARF code is unreadable by the GDB version 6.x that ships with Mac OS X.
-    We would gladly accept patches to make the DWARF output compatible with
-    the standard OS X GDB,
-    but until that’s fixed you’ll need to download,
-    build, and install GDB 7.x to use it under OS X.
-    The source can be found at [http://sourceware.org/gdb/download/](http://sourceware.org/gdb/download/).
-    Due to the particulars of OS X you’ll need to install the binary on a
-    local file system with `chgrp procmod` and `chmod g+s`.
-  - Names are qualified with a package name and,
-    as GDB doesn't understand Go packages, you must reference each item by its full name.
-    For example, the variable named `v` in package `main` must be referred to
-    as `'main.v'`, in single quotes.
-    A consequence of this is that tab completion of variable and function names does not work.
-  - Lexical scoping information is somewhat obfuscated.
-    If there are multiple variables of the same name,
-    the nth instance will have a suffix of the form ‘#n’.
-    We plan to fix this, but it will require some changes to the data exchanged
-    between the compiler and linker.
-  - Slice and string variables are represented as their underlying structure
-    in the runtime library.
-    They will look something like `{data = 0x2aaaaab3e320, len = 1, cap = 1}.` For slices,
-    you must dereference the data pointer to inspect the elements.
-
-Some things don't work yet:
-
-  - Channel, function, interface, and map variables cannot be inspected.
-  - Only Go variables are annotated with type information; the runtime's C variables are not.
-  - Windows and ARM binaries do not contain DWARF debugging information and, as such, cannot be inspected with GDB.
-
-Over the coming months we intend to address these issues,
-either by changing the compiler and linker or by using the Python extensions to GDB.
-In the meantime, we hope that Go programmers will benefit from having better
-access to this well-known debugging tool.
-
-P.S. The DWARF information can also be read by tools other than GDB.
-For example, on Linux you can use it with the sysprof system-wide profiler.