You can follow the assignments of such "socket numbers" for NCP in RFCs 349, 433, 503, 739, 750, and 755. RFCs 758, 762, 770, 776, and 790 address both socket numbers for NCP and port numbers for TCP/IP simultaneously. RFCs 820, 870, 900, 923, 943, 960, 990, 1010, 1060, 1340, 1700 continue that work for port numbers only and RFC 3232 finally switches it to an online database.

RFC 349:

        Socket          Assignment
           1            [Old] Telnet
           3            [Old] File Transfer
           5            Remote Job Entry
           7            Echo
           9            Discard

RFCs 349, 433, and 503 also provided a list of conflicting socket numbers used on specific hosts.

There's absolutely no proof in this.

The fact that a request with a TTL smaller than 12 does not trigger a response does not mean the responder is the host after 12 hops. Assuming none of the previous hosts misbehaves (they could be increasing or at least not decreasing the TTL) you can only conclude that it is none of the later hosts, but it can still be any of the previous ones.

That leaves you with Comcast AND China Unicom hosts and, considering that the replies you see in the traceroute results can easily be spoofed, it can be any third party as well.

Possible scenarios include (I don't say they are more likely):

1. Comcast is producing the responses, but only does so if the request TTL is large enough to make you blame China Unicom.

2. China Unicom hands the packets over to a third party after just a few hops in their backbone. The third-party sends ICMP Time exceeded messages looking like they are from other China Unicom hosts to make you blame China Unicom.

Conclusion: This is either an obvious attack from within the China Unicom backbone OR a more sophisticated attack where the attacker wants to a) hide his identity and b) blame China Unicom for it (I can't think of a scenario where b) would be a by-product and not on purpose).

Just saying. The sentences in the post that include the words "prove" and "proven" are simply wrong.

For me it's the RSS feed

Yeah, copying GitHub URLs sucks. You cannot actually select it with your mouse, since some creepy JavaScript interferes and selects it for you. the result is that it's selected, but not copied to PRIMARY, as you'd expect. I fall into this trap every single time.

Being pissed off as I always fall into the trap, last week I wrote a userscript that adds a 'clone' button to gh webs.

Combined with xdg-open, I clone the repos locally just clicking the 'Clone' link.

http://i.imgur.com/AiTFm2R.png

Userscript itself in: https://github.com/kidd/org-protocol-github-lines/blob/clone...

PhpStorm and RubyMine subscription renewals during Doomsday sale. :D

GCC can eliminate tail recursion, so does that make C functional?

I don't think the author is seriously of the belief that C is a functional language. This is just a fun little example of writing C in a functional style.

GCC can even eliminate non-tail recursion, such as with this piece of black magic:

    int factorial(int x) {
       if (x > 1) return x * factorial(x-1);
       else return 1;
    }

will be optimized by GCC to

    int factorial(int x) {
       int result = 1;
       while (x > 1) result *= x--;
       return result;
    }

(http://ridiculousfish.com/blog/posts/will-it-optimize.html)

That's a very weird definition. Eliminating tail calls is fun, and useful. But not all that essential in, say, a lazy language.

Having first-class function values in the first place strikes me as way more important. Purity helps, too.

How do you write a function to sum a list of a billion elements in Haskell?

What would happen without tail call elimination?

With foldl', of course. If you don't have tail recursion elimination, foldl' would have to be provided as a built-in.

Summing up numbers is inherently strict, so you'd want tail call elimination for that. But functional mainstains, like say, map or filter are usually not implemented with tail recursion in Haskell, because that would be too strict and would break on infinite lists.

That's not a very good definition. It means that GHC-flavoured Haskell isn't functional: http://www.haskell.org/haskellwiki/Tail_recursion

I think you might have misinterpreted the contents of that page. As someone who has worked on GHC, I can assure you that it does perform tail call optimisation.

I believe I have. Thank you for correcting me.

Not necessarily. The Scheme spec requires tail-call elimination, and I think the same may be true of some other functional-ish languages.

Not using Unity?

I quite like Unity once I've tweaked it. The only thing I still don't like is the global menus (a UX abomination), and I can live with that.

  sudo apt-get autoremove appmenu-gtk appmenu-gtk3 appmenu-qt

That works on 12.04; you might need to remove a slightly different set of packages on 12.10 but it's certainly possible to change.

Many of the universities around here (Munich) got an edu domain (tum.edu (e. g. www.cs.tum.edu), hm.edu).

Really US-restricted TLDs, as far as I know, are mil, gov and pro.

.pro is not US restricted.

The commit details are back now. :)

*BSDs have (=> OS X probably too).

Solaris, HP-UX and OpenServer have not.

AIX is weird:

> -r Searches directories recursively. By default, links to directories are followed.

> -R Searches directories recursively. By default, links to directories are not followed.

Isn't the AIX behavior the one POSIX specifies?

Looking at MattJ100's link (http://pubs.opengroup.org/onlinepubs/009695399/utilities/gre...), it seems like POSIX grep actually does not have any recursion.

Hence, only lubutu's comment ("-R is the recursion flag for ls, cp, rm, etc") is true, while _delirium ("-R is the POSIX-standard flag for recursive grep") is wrong, which means AIX is free to do whatever it wants with both the -r and the -R flags.

That would be kind of perverse given how cp behaves for -r and -R