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!

Hey, we hippies love you too!

Seriously, insofar as he's doing this to get work done or make some contribution, well OK, but he also crows loudly about running all over the world just for fun. Is this something we want to celebrate?

An anonymous warehouse in Richmond, CA is the new Library at Alexandria. Is this progress? Anyway, kudos to Brewster Kahle for doing something very, very important.

Seriously.

It really depends on the individuals and what you're trying to do, but too many organizations fool themselves into thinking: this virtual team stuff better be cheap and not involve much travel, because I'm counting on it being cheap. For some teams, what you'll gain spending full days in the same place together regularly, including going to meals, etc., will be tremendously more valuable than what you can ever achieve remotely. For others, where everyone is on the same page and easily understands each other and the job's needs, well fine not so much travel is needed, maybe none.

My point is: don't count on not needing contact just because you don't want to budget for it. If you need it, whether to get your actual group planning right, or to build trust, or just to take the measure of who can do what and work with whom, then something big is likely to be lost of you don't arrange for it. BTW: just sending just a manager doesn't always do it either. Sometimes teams need to really spend time with each other.

And yes, the carbon footprint for travel like this is awful. But then again, that's one of the reasons for building a team that's centralized in the first place. You don't have to tradeoff face-to-face contact for travel time, cost, expense and pollution.

This is an important debate, but Neil McAllister's article suffers from a number of problems. For example, it references the recently popular Webkit Comparison Table along with Peter-Paul Koch's claim that there is no “WebKit on Mobile”. The article didn't point out that some people like Alex Russel have dug deeper and have found that the facts don't support PPK's conclusions as strongly as one might think. Yes, if you include lots of older devices, there's quite a divergence in Webkit deployments, but what PPK and Neil McAllister don't say is that compatibility is much better on devices that ship recent versions, it's especially good for core features, and it's improving all the time.

McAllister also implies that the mobile Web is in trouble because "On my BlackBerry, JavaScript performance is abysmal". Using that argument, I can prove that Windows will never be successful, because I could in the early days show you PC's that ran it with abysmal performance. The potential of technologies like Javascript needs to be evaluated using the best implementation you can find; that shows what's possible. He does go on to say: "And even when a handset vendor does improve JavaScript performance, as Apple did with iPhone OS 3.0, it's a relative increase." Aren't they all? "You're still dealing with a poky handheld processor (and in Apple's case, one that developers speculate is too feeble for Flash or Java)." Uh, so now the reason that the HTML and Javascript will fail is that ARM processors are too slow to run Java? What's the connection I'm missing? The fact is, that there are some pretty good AJAX sites for mobile, so we know the ARM processors are good enough to run that Javascript. Try, for example, going to http://www.gmail.com using Safari on your iPhone. Not a usable experience? Even works offline using HTML 5 local storage (not Gears). Also, even if Javascript performance were somehow related to Java performance, I bet the Android folks would like to hear that Java doesn't run right on ARM processors, since the entire upper level infrastructure of Android, including user applications, is built on just that combination (as optimized using the Dalvik VM).

Unfortunately, articles like this can do real damage. Many people who are not expert in these things are struggling to figure out which mobile application development models are going to be workable. I happen to believe that the Mobile Web will, like the desktop embodiment of the Web, grow as disruptive technologies tend to: from something that's a bit shaky at first to the model that dominates? Why? Because unlike Mr. McAllister, I believe that the underlying processors and system technologies are capable of running it, and the value of a model that is fully cross-platform, can support zero install operation (you might want to install a mapping application to find a restaurant, but you almost surely don't want to install the restaurant's application to read menus or get discount coupons), can also scale to support installable applications (Widgets) and offline operation, is compelling. Furthermore, as has been the case for years, the Web has the unique value of allowing you to link to the over 1 trillion Web pages, without jumping out from some proprietary application container to a Web browser. Whether I'm right about the likely success of the mobile Web or not, this whole question deserves a much more careful analysis than McAllister's article provides. Unfortunately, there will be many people who read it and jump to the conclusion that the mobile Web is failing. A shame.

At the server.