Agreed. The range of human ailments is probably beyond what the vast majority of humans can really understand; this means that, in all likelihood (and I know this *is* true, as well, from surveying a number of patients with uncommon conditions) there are lots of doctors who will see a set of symptoms that are a textbook case of an uncommon disease and still mis-diagnose it. Doctors are taught to act confident in front of patients, for the simple reason that patients *do* tend to fare better if they trust their doctors. However, I have seen too many doctors over-extend this to arrogance in the form of not investigating symptoms that they are unfamiliar with: if they have forgotten something important from medical school, they won't say, "I'm not sure---let me refer you to a specialist." Instead, they'll say, "There's really nothing wrong. You have nothing to worry about." When the patient returns in a few months, even sicker, that particular doctor is of course still too arrogant to admit wrongdoing or lack of expertise and will continue to dismiss the patient's concerns. This situation is what leads to the majority of malpractice situations, from what I have read on many online forums (thus, I cannot say for sure that my opinion is right, but it's based off of more than just a few anecdotes).

If doctors only got paid when they were able to help a patient, this wouldn't be the case. However, how do you determine, _precisely_, if a doctor has "helped" a patient?

Oh, so you mean, in the same place? ;)
[Note to mods: if you haven't read Asimov's Foundation series, or at least Foundation and Empire, just skip to the next post.]
All humor aside, I've often wondered about 'psychohistory.' It seems to have a decently solid basis in sci-fi theory, which in the context of "good sci-fi," means that it's at least *plausible.* However, without good models and the necessary empiricism to evaluate them, we don't really know _anything_ for sure---everything is really just speculation, even if plausible.
The first person to provably (by that, I mean beyond reasonable doubt, rather than beyond unrestricted skepticism---if there is a dispute, it will either go up before a committee or multiple people may be considered [I may restrict a "time will tell!" period in that case as a verifier of the model, but not beyond 50 years, and should I die, I will leave the decision to a subcommittee of peers]) develop a working model (it doesn't have to yet be a solid theory) of psychohistory by analyzing this planet's history in detail, and using simulations of periods N-X thru N-1 to predict period N, where X is a large number and the length of a period is something reasonable for human scale (let's say anything in the 10--200 year range, but other periods can be suggested, of course) will win a small monetary prize from me (depending on my income, but I'll guarantee at least $50), and probably (though I can't speak for the Nobel prize committee) a Nobel peace prize and substantial mention in history books for centuries to come.
[Yes, I do realize that though I have skirted around the "pronoun is missing an antecedent" in the previous statement, I would need to re-write the statement to prevent the "generic noun missing specifier antecedent" problem---readers are welcome to do that for me, if they really feel my statement is thusly ambiguous.)

Finally, my sig is relevant!

But, seriously, graphene (and some lab-precision equipment... well, *reliable* lab-precision equipment---a 20-year-old tube electrometer thrown out by a university lab for being flukey doesn't count) would be terribly fun to experiment with (at least for me). Measuring material properties is one of my interests.
In terms of semiconductor experimentation at home, there's always copper oxides, but, meh... it's been over-done.

"The danger of being sued." Exactly! And the first critical lesson in copyright school is... Don't upload anything involving Metallica in any way, shape, or form.

Exactly--that's the second thing that popped into my head---land a fuel factory before sending humans. (The first thing was to land a few solid rockets that could be attached to the humans' rocket once the humans landed to enable them to return, but then I thought a fuel factory would be a better use of rocket launches, since it could be used for many go-there-and-come-back missions.)

It's funny to me that the author of the article didn't consider how we launch rockets off of the earth in the first place (by manufacturing fuel) before writing the article.

Missing comma and missing word. Try this:
"They paint a picture of a Zuckerberg more sinister than portrayed in the movie The Social Network, actively out to sucker his investors that the site had, including Ceglia."
Comma after "Network", and "had" after "site".

Oh, I do remember that the network name was plotted in roughly the centerpoint of the area where the network was available... that just came back to me.

I did something a bit like that before by walking around with a laptop, pair of headphones, and a clipboard (I didn't have a GPS unit at the time, so I marked each intersection's corner-points as I passed them and used interpolation; the laptop played a musical sequence through the earphones to give me the data to mark on the clipboard). If I find the map images I made, I'll link to them... of course, I was tracking the number of networks, since that was a better number to use in a highly-network university town.
here (9/22/2004) is one of the images generated from the data; I know I had other things, but I'm not sure where the datafiles and scripts are, now.
I don't remember what the color coding on the map means, other than the green dots are probably where an open network was available. *shrug*
That particular map includes network names, and I don't remember how I recorded those without a GPS (using festival to output a number corresponding to a sequence point that I could notate on the clipboard where I tracked my location, and saving iwlist scan's output to a corresponding numbered file?)

(Before I get started on my rant, I want to point out to anyone who wants to reply before reading my whole comment that I realize my experience is limited and my needs probably differ from yours. That being said, here I go...)

That's actually my experience with most easy-admin tools. They expect config files to follow very specific (and undocumented!) forms; they never have the parsing flexibility of the programs that actually read those configfiles. So, it's hands-off /etc---either do it with the easy-admin tool, or don't do it at all, because once you touch the file manually in a way the easy-admin tool doesn't expect (though it might be a perfectly valid way according to the manpages of the corresponding programs), you'll be reverting your config. Run into a limit of the easy-admin tool? No more easy administration for you---either you can try to patch the easy-admin tool (most I've seen suffer from a lack of documentation), or you can remember to never, ever use the easy-admin tool to modify certain things again, lest you hose the hand-edited config (thank god for chattr-immutable, at least).

Now, I haven't surveyed many of these tools, nor have I kept up to date on them. What I describe is what was shipping with major linux distros a few years back. It's quite possible that there's a tool out there that:
(1) is designed from the start to notice inconsistencies between its own set of config data and the files it's modifying in /etc, aborting before anything gets hosed;
(2) implements flexible and tweakable parsing strategies that are well-documented, so you know what you can and cannot do when hand-editing things in /etc;
(3) has well-commented, modular code, with every script, file, and interface detailed carefully and explicitly in an organized, well-written set of manpages; and,
(4) provides a solid cross-reference of every admin-tool-config-variable versus what it tracks in /etc.

IBM's AIX had its own approach to preventing hosed configs: on system startup and reconfigure, lots of /etc was simply overwritten by SMIT. No need to worry about confusing SMIT by hand-editing anything---hand-edits would just be reverted to the data in SMIT's database. Early versions of SMIT were notoriously inflexible, causing a multitude of headaches for AIX3/4(?) admins.

Speaking of SMIT, I should point out that SMIT and other tools (such as HP's SAM and IRIX's config toolsets) were based on easy-admin-interfaces that sat on top of a scriptable engine, so you could still use rsh/ssh, crond, and all the regular approaches to en-masse administration, provided your own scripts called the underlying engine rather than modifying things in /etc directly. You could simply look at the logs produced by SMIT/SAM/etc to make a template for your own scripts. This was a failing point of early linux easy-admin tools---the menu-driven systems didn't spit out a log of all the calls made to the underlying admin-tool scripts, the scriptable CLI engine was poorly documented, or (worse yet) the CLI call syntax was inconsistent from version to version. I did notice improvements in that over time in the linux easy-admin tools.

I have heard some good things about YaST, but I've never looked seriously into using it. For what I do with my systems, slackware's mostly-stays-out-of-your-way approach suits my needs. No, I don't admin a datacenter, just a small very-heterogeneous network, so I do realize that what works well for me isn't often going to be the best choice for others. (And, for those of you who haven't configured a slackware system in a few years, do note that the init-scripts rarely need much editing, as they source most needed info from rc.${whatever}.conf files for each rc.${whatever} script, and most everything that starts a non-trivial daemon has a init.d-style start|stop|status|restart script to facilitate straightforward/clean init-scripts.)

Or:
"LOAFER, the World's Laziest Telescope, Is Finally Up and Out of Bed... Oh, Wait, it went back to bed. Never mind!"

As some other commenters have noted, C++ and its plethora of features give something comparable to a write-only language like COBOL (remember that debugging is part of reading the code).
I wouldn't retrofit things like polymorphism onto C, if I were to start over (something the guys at digital mars probably agree with). IMHO, you end up with kludginess without the brevity (sometimes called "elegance", but that's a bit debatable) of perl. Hey, we could be doing worse---at least it's not PL/I! *g*

I'm just surprised nobody has parroted the oft-quoted "obscenity is the crutch of inarticulate motherfuckers" yet ;)
captcha: innuendo

There are multiple species of hummingbird. A few of them are common in north america, but there are less-common species, as well. Hummingbirds are rather remarkable, being the most maneuverable group of birds (ever seen a bird fly backwards?)

You're still amazed? I'm not! We know that:
1. Some people rarely have the chance to call during normal business hours. This eliminates some call volume.
2. Some problems seem to sort themselves out after a few hours. This eliminates some call volume during the business hours of the following day.
3. People who are inconvenienced late at night, when they're trying to relax before bed, are going to get irritated easily and vent all the frustrations they garnered during their work-day. If you force them to only call during the business day, they're apt to be more polite (after all, they've now had a night's rest) as well as take up less time on the phone (less venting). This shortens call time.

It's a lot like how, at big universities, some professors have their required office hours from 7-8:30am, because they know just how few students will come during this period.

It's more navigable in dillo than before---that's what counts for me!