There's a lot of merit in this story I think, but ultimately it muddies the waters. Certainly, it's claim that government-funded research played a less than key role in the development of internetworking seems to be just plain false.

First of all, the work Xerox did that most resembles the Internet protocols was not Ethernet, but PARC Universal Packet (PUP), which is indeed quite directly comparable to the IP in TCP/IP. Ethernet, while a terrific piece of work, mostly served to facilitate networking within a single site.

The article also says implies that the Government-funded ARPANET wasn't really the precursor of the Internet. I think that's an over-simplification. Arpanet wasn't the very first packet switching network (see the work of Baran and Davies), and it certainly wasn't an Internet (network of networks), but it really was the direct antecedent of the Internet as we know it. Arpanet connected universities and other research establishments. It proved the viability of a packet-switching network with all the application smarts at the periphery of the network. In almost all cases, what had been Arpanet connections among the early sites evolved (sometimes by way of NSFnet) to TCP/IP Internet connections, running essentially the same applications and services. So, in all those ways, Arpanet was a crucial step on the way to our TCP/IP-based Internet, and of course, ARPANET was government funded.

A much less sensationalist but much more balanced history of all this can be found at: http://www.nethistory.info/History%20of%20the%20Internet/origins.html . The record there strongly suggests that Bob Kahn and Vint Cerf were discussing approaches to internetworking (connecting networks) in spring of 1973. Interestingly, the official PARC Research Report on PUP actually cites the Internet work of Cerf and Kahn, specifically their 1974 A Protocol for Packet Network Intercommunication.

So, the government-funded work on internetworking seems to have started before the Xerox work, and the Xerox research time explicitly cited Cerf and Kahn as sources of inspiration for the Xerox work on internetworking. Wouldn't it be nice of the WSJ article made all that clear before everyone started using these over simplifications to prove the futility of government-funded research?

Another reason...though somewhat unusual. 40 years ago, I printed on photosensitive cloth a family picture, and it was sewn with backing to make a cover for a throw pillow. The family still has it (and yes, you could get "photo linen" and similar alternatives to printing paper back then). Seriously, for some pictures, people like the look when canvas is mounted. It gives just a bit more of a reminder of a traditional painting I think.

You really, really want offsite backup in addition to whatever you do at home/office. If "the cloud" works for you, fine, but for many the bandwidth issues are a big problem

One option is to have, in addition to whatever drives you run live, enough extra drives to back up your data twice. Keep one set at home, and another in a safe deposit box. Depending on your risk tolerance, you can use packaged drives, or carefully swap bare drives in eSata enclosures or the like. Backup as often as you can on the set at home. Then every few weeks/months whatever meets your needs, do a swap; put the up-to-date backups in the safe deposit box; take the other set home and use it for new fresh backups. With that as a base, you can usually use cloud-based solutions to make sure there are daily or immediate offsite backups of truly critical data that's changing often.

Trust me: disasters do happen. You can lose a lot if you haven't prepared.

I'll add another "second". It's a terrific little book. What the Elements of Style does for English, Doug does for Javascript. Yes, like many languages (certainly C++), JavaScript has a bunch of features that are poorly designed. Crockford shows a subset that's flexible and powerful.

What you don't want to do is try to make JavaScript into C/C++. They are different languages, optimized for different things. If you're going to program in a dynamic language like JavaScript or Ruby, don't spend all your time wishing it was static. The advantages are different, but if you're going to use JavaScript, use it in a style that exploits what it's good at. Crockford provides an excellent start.

For a more comprehensive reference, I like JavaScript: The Definitive Guide from O'Reilly.

This posting quotes an unreliable news report, and claims that IETF HTTP working group head Mark Nottingham, "called for it [SPDY] to be included in the HTTP 2.0 standard". Nonsense. It's easy enough to find the actual announcement from Mark which says, in part:

I've put together a charter proposal (see attached) that has us going to WGLC shortly (something that I want to see us do regardless), and starting work on HTTP/2.0. Note that it does NOT call out a starting point; rather, we'll start by asking for proposals, considering them and selecting one based upon the traditional IETF criteria of rough consensus and running code.

Indeed, the proposed formal charter for the new work that's included in Mark's note doesn't mention SPDY at all. I've been in meetings with Mark about this, and SPDY is no doubt at or near the top of the list in terms of interesting candidate technologies to look at, but it's incorrect to say that Mark is calling for its use in HTTP 2.0. At the very least, the Slashdot post on which this is a comment would do a much better service to the community if it linked and quoted Mark's actual announcement, rather than some hyped up misinterpretation from the press. All the conspiracy theorists should calm down a little while, and subscribe to the IETF working group mailing list if they really want to see how this plays out.

A good citation on buffer bloat is Jim Getty's ACM Queue article on Buffer Bloat, in which he says:

Proper solutions for Web browsers can improve access-link behavior. These include HTTP/1.1 pipelining and Google's SPDY, both of which can achieve better performance, reduce the total number of packets and bytes transferred, and enable TCP to function better.

I've also spoken with Jim about this, and he definitely views SPDY as potentially part of the solution, not part of the problem. In fact, he was the person who first pointed out the existence of SPDY to me.

BTW: the reason SPDY does relative well with respect to bufferbloat is that it multiplexes a lot of traffic over a single TCP stream, and most lower level TCP software and hardware, including routers, tends to bound the number of packets they'll queue from a single stream. Trouble comes when the same application opens a ton of parallel streams, each of which gets to queue several packets; the result is that together they clog the buffers, add to latency, and prevent other application streams from progressing.

I think it's generally agreed that, especially with typical instruments being made primarily of wood, even seemingly identical instruments have significant variation in tone, and sometimes in playability as well. I would not, for example, expect two Musicman Stingrays to sound exactly the same, even if they were made within days of each other, had exactly the same type of finish, neck shape etc., and were strung with supposedly identical strings. It's not impossible they'd sound about the same, but it certainly would be common for them to sound or feel different somewhat different, and perhaps significantly different. (That's among the reasons that it's still nice to have brick-n-mortar music stores, with good selections of instruments.)

Yes, Lotus Notes is one for the few environments in which I've seen large communities routinely encrypt and/or digitally sign their mail.

There's a reason this is more practical in Notes, and that's because Notes is designed for use primarily in corporations, where centralized or hierarchical management of keys and certs naturally fits the operational structure for the organization. The real trick in Notes is that every user has a public/private key pair; indeed, without that you don't have an identity in Notes. When a new user is authorized into a Notes domain, a certificate is signed by the domain owner, and automatically entered into the same name and address book that's used for expanding abbreviations while names are composed, and for routing mails once their sent. In other words, whenever you're sending mail to another user in your organization using Notes, the system likely has an appropriate certificate in hand for him/her, and a private key for you. So, whether to encrypt or sign then becomes, mostly, a matter of policy.

Indeed, although Notes does have support or S/MIME, so that Notes users can communicate securely with non-Notes users on the Internet, that support is in my experience rarely used. As others have noted, it takes two to tango, and as in other mail systems, individually registering S/MIME certs for your friends is just about as painful in Notes as in other systems.

> So my advice is first figure out which group you fall into.

Pretty good advice, but also figure out what you want to learn, and there are two groups there too, I think:

1. People who want to take better and better pictures, but who would really be just as happy not to learn about the underlying mechanics or theory. This is a perfectly legitimate path, and whether DSLR or point and shoot, you'll want one with terrific automatic function that's good enough to handle the situations you intend to deal with. E.g. if you're mostly taking those pictures of people you know outside, or up close inside, a point and shoot may be just fine. If you'll be taking them in dim light, or larger rooms inside, then you'll need a camera with some kind of flash arrangement that's both powerful and automatic. That might move you toward a DSLR, possibly with good automated flash attachment.
2. People who are happy to learn about exposure, focus, and the other building blocks that give you more control over how an image looks, and that let you take pictures in more challenging situations (e.g. on a tripod in low light without flash). For someone with those goals, make sure the camera has controls that make it easy to override automatic exposure, focus, ISO, and other such settings, one that lets you look at histograms of your completed exposures, etc. (Yes, some of this won't make sense if you're a novice, but a good camera store can help).

Also, one other dimension: how much do you care about the quality of the final image. The small sensors used in cheaper point & shoot cameras get pretty mealy looking in low light, and often have such limited range that highlights get blown out on sunny days or with flash. (Check out things like the bright spots on a subject's cheeks or forehead). For snapshots and Web-photos, you may not care; for better quality, the absolute smallest sensor you'd want is a micro-4/3, or a DX size, which is better yet. Pros tend to go for full-frame, but for anyone who's not very serious and experienced, that's likely overkill. The size of the sensor is a characteristic of the camera: you can check reviews and specs to see how big the sensor is in a particular camera. Panasonic, for example, has a line of micro 4/3, whereas Nikon's smallest DSLR sensor is DX (somewhat bigger).

If you want a light camera to carry everywhere and don't care so much about the most beautiful images, then go for something smaller; smaller sensors tend to wind up in smaller cameras

There's an area in the Idaho deserts where even the roadside rest stops have radiation counters. It's an area in which much of the US's early nuclear reactor experimentation was done. I've only driven through, and it's a very stark area (my first hint that something weird was going on: how come the cell phone system has such terrific 3G coverage out here in the middle of nowhere?) Anyway, a Web search suggests that there's a museum in honor of all this: http://www.inl.gov/ebr/d/ebr-i-brochure.pdf No clue whether it's still open or worth the trouble, but if you're anywhere close it might be worth checking out. Bring your lead outerwear.

http://www.exploratorium.edu/ Located in San Francisco, near the Presidio, which is a bit east of the entrance to the Golden Gate bridge. I haven't been there in years, but it's a wonderful, creative science learning space, aimed somewhat at children.

Highly recommended. As best I can tell from the Web site, it's open these days. An excellent collection of old computers and related "artifacts".

Umm. I think it's univerally acknowledged to be a paywall. In fact the New York Times itself refers to it as a paywall. <irony>Um, following that link I just gave will itself count against your NYT paywall limit</irony> What is true is that you get up to 20 articles free each month, but clicking on a link such as the one on nuclear safety counts against your 20. Where did you see the free for 7 days? My clear understanding is that it's 20 free per month (modulo some weirdness about trying to make links from social networking sites free...though the detailed rules for that aren't documented as far as I know.)

Regarding moto's point about cookies: yes, I'm aware that deleting cookies can reset your count, at least in some cases, but I presume that doing so violates the permissions provided by the NYT on use of the content. Granted, slashdot readers are more likely than others to know how to do stuff like this, and maybe or maybe not some of them consider it appropriate, but one of the bad things about the paywall is that at least for novice users or those experts who choose not to cheat, just doing something as "innocent" as clicking a link can wind up eating through your monthly quota. YMMV.

This /. posting does indicate that what's linked is a NYT article, but it fails to remind that following the link costs you one of your 20 free NYT accesses/month. It would be helpful if the posting were updated with a [paywall] marking, or some such, after the link. Otherwise, thanks for the interesting post!