I have used 3D molecular modeling tools for years. You can get by just fine with a 3-button mouse. 3 single buttons, 3 2-button combinations = all the axes you need to translate/rotate/zoom, all continuous. You don't need a mouse wheel at all, just button combinations and intelligent movement of the mouse while the combinations are held. It's really quite intuitive and easy to use.

However, you are correct in that I was never able to zoom, translate, and rotate all in a single gesture. However, 3 separate smooth gestures is no problem at all, and (to me at least) preferable. For fine positioning, it is much better to limit movement to only one of these axes at a time, so that you do not accidentally mess up one of your axis positions while you are adjusting another to get it just right.

Wouldn't this be a sea of cautious *disrespect*?

Google Scholar brings up a PDF file I can obtain without a subscription. So, I searched for "flav" to see what's going on here. Table 1 gives stats for "Total flavanols". The only other hits are in the references, where there are 3 references with flavonoid(s) in their title, and 2 more with flavonol(s). Now, I haven't tried to hunt down and read over these 5 cited articles, but given their titles, I think it highly likely that they do indeed cover flavonoids and not flavanoids.

Now, could flavanoid information have been taken from other citations that don't have flavanol in their title? Sure. But, since they cite 5 papers that appear to be solely dedicated to flavonol/flavonoids, and nowhere mention flavonol/flavonoids in the rest of their manuscript, I'm guessing that "flavanol" really is a typo and that they really did measure, report, and meant to talk about flavonols.

So, the criticism does appear to be valid. The only mention of flavanols in the entire manuscript does appear likely, at least to me, to be a typo meant to convey information about flavonols. Now, whether this was an intentional dishonest typo, or an honest accidental typo, I'm not going to speculate. I'm just confirming that the claim of misreporting flavonols as flavanols appears to have merit.

I feel the need to defend PNAS here, since I actually consider it to be one of the better journals -- *IF* the manuscript has been accepted via the non- Academy of Sciences peer review process. PNAS has two (maybe three?) submission tracks: A) You are a member of the Academy of Sciences, and this results in your manuscript getting accepted more easily than usual. B) You get a friend who is an Academy member to submit your paper for you, which also lowers the bar. I'm not sure if this is really part of track A) or not, so it may or may not count as a separate track. Track C), however, is where someone who is NOT associated with the Academy submits a manuscript. Papers that come in from "external" submissions and make it past the Editor, and then all the peer review, are actually generally quite good.

So, PNAS is a mixed bag. Manuscripts from Academy members can be a bit on the sketchier side due to how the submission/review process works for them, but manuscripts from non-Academy members are often, IMHO, a good bit better than average. As with all scientific manuscripts, you must read them over carefully and determine if they have sufficiently proved their point or not.

Unfortunately, you may have a point about this particular article, since it was "Contributed by Bruce D. Hammock", who a quick Google search shows to be an Academy member.... I have not actually read the TFA, though, so I can't comment on whether it is any good or not.

From TFA (and the summary):

How likely is it that a control system vendor would have the usernames and passwords of their client, used in the actual production system? Maybe they actually do, as part of some sort of remote support agreement, but if this is the case, that's already a bad security practice.

It seems more likely to me that the vendor has a list of default usernames and passwords, and THIS is what was obtained. Perhaps what Weiss *really* meant to say would be be something like: "Someone got ahold of the default usernames and passwords that our vendor uses. Since we never changed them from the default values, it's our own damn fault."

After seeing SO many stories like this, it's usually a case of not changing default passwords. Given that Weiss's statement *could* be read as I have read it, this seems the most likely scenario to me. I'm going to write this one up as stupidly bad security policies until I have sufficient evidence contradicting this assumption.

Wouldn't a digital millennium be 1024 years?

No, that would be a mellibinnium.

I looked it up at www.tbauto.com. Said car is a reproduction 1770 Fardier de Cugnot. From the website:

"The original Fardier de Cugnot has been in the collection of the Le Conservatoire de Arts et Metiers, Paris, France since 1801. Currently on display is one reproduction Fardier on loan from the Deutsche Ban Museum in Nuremberg, Germany, as well as a completely functional, faithful reproduction that was created from the ground-up by The Tampa Bay Auto Museum."

So, the oldest car is on display in Paris (I have not investigated whether it works or not), and the one(s) in St. Petersburg are replicas, so nothing has yet to disprove that the car in TFA is the world's oldest working car.

Not notable? I may be confusing itracker with another tracker of that era, but wasn't itracker the one with the built-in Worm mini-game? It even had 2-player support. I have fond memories of playing 2-player Worm with others in my dorm in the mid 90's.

Aside from Worm, it was actually a very nice tracker, and had a high compatibility rate with playback of other MOD formats. I'd certainly put itracker on the list of notable trackers that advanced the then- state-of-the-art. I think I used it a lot for adding BPM events to the beginning of a lot of my old Amiga mods so that they'd play at the correct tempo on a PC, which used a different NTSC/PAL vertical scan rate timer setting or something like that to determine the beats per minute. It was the old NTSC vs. PAL Amiga problem for MOD file tempos. Or maybe it was whichever tracker used .XM as the native format, my memory is a bit hazy on that.

BTW, If you ever want to convert MOD/IT/XM/S3M/etc. to MIDI, check out the -OM output mode of TiMidity++. It does a pretty good job of it (disclaimer: I wrote a lot of the mod->midi code a long time ago).

unless it involves cats and cheezburgers

How about equivarogue?

This is why we are upset at Apple. They should not be writing it down somewhere. While the subpoena itself may not be considered an invasion of privacy, the act of Apple recording your location (which is now being subpoenaed) most certainly is. Is this hard to grasp?

Actually, you have things reversed here. The fine *was* for releasing a butt-load of patient records, not for refusing to release patient records. What happened is that they refused for a while, then got snarky and sent them like 50 boxes of thousands of records, with the few records originally requested buried in the thousands of other records just to make life difficult for the agency requesting the original documents. I assume that the agency requesting the original documents was authorized to receive those original documents, but not authorized to receive the thousands of others that came along with them (I work in healthcare research -- trust me, getting approval to receive personally identifiable information is extremely non-trivial, they would have only been authorized to receive those documents originally requested). Bam! -- massive HIPPA fine due to the thousands of extra patient records that were released.

The original slashdot submission tried to spin it as a fine for refusing to release records, but if you RTFA you will see that it was quite the opposite. If you repeatedly obstruct an agency that can fine you, then give them the finger by burying them in 50-some boxes of unrequested documents in violation of HIPPA, you sure as Hell are going to be fined for releasing those documents.

I sense a lot of hate and rant here. Let me try to address some of these issues based on my own experience:

I'm a biophysicist, did a 3-year post-doc in a biology lab, and have been doing disease-related data analysis professionally for the past several years. I can attest that there are a lot of off-the-shelf solutions that ALMOST, but not quite, fit whatever problem you are tackling. If I wasn't a good programmer, I simply would not be able to get any good data analysis done, since the tools to do it properly often don't exist and I have to write them myself (or modify existing ones if I have source code). And file format conversions, parsing, and merging of data are a never ending nightmare, especially with public data sets.

Your uncle does have a point here. While I wouldn't necessarily say that biologists need to be able to program -- we can't all be good at all things -- it is definitely advantageous to have someone on staff with a firm grasp of both biology and programming, either to serve as an interpreter between the hardcore biologists (Biology department) and the hardcore programmers (CS, Engineering), or to code up solutions themselves. Biologist generally don't have the programming background to produce useful programs, and CS/engineers generally don't have enough biological background to produce useful programs (not applicable to real-world noisy data and biological constraints). You need someone with good knowledge of both.

I used to use recursion in C as well, until I fed an algorithm too large of a problem and it segfaulted. Why? Because it recursed too deep and blew stack. The correct solution is indeed to implement it as a loop and use your own allocated array for your recursion stack, so that you will never run out of "stack" during your recursion. I still often prototype an algorithm with recursive functions on small test data to make sure it works correctly, but then I go and reimplement it as a loop so that it can then be used on arbitrarily large/complex data (and verify my results against the simpler to understand/debug recursive function version). Again, your uncle has a valid point here.

He may be stuck using his old archaic technology, but he does have 40 years of experience in his field, and along the way has encountered and learned from many pitfalls. Don't discount his rants (at least not all of them) just because he's using old stuff. A lot of it is still relevant today, you just may not have experienced the reasons for why it is relevant yet.

Matlab and FORTRAN both have their strengths and weaknesses, just as any other language. I've not used Matlab much, since it costs money, and academic labs generally don't have much of that. I've not used FORTRAN much (other than to compile/fix old scientific code), because until the early 2000's or so, there wasn't a free FORTRAN compiler that supported anything beyond F77 (I believe F90 introduced dynamic memory allocation?), and by that time I was already proficient in C. So, both of these languages may have less uptake/use than they "should" due to monetary factors.

That said, I know a lot of mathematicians who do great stuff in Matlab. It has a lot of libraries that do a lot of powerful nice stuff, which can greatly reduce development time. FORTRAN has a *ton* of well vetted high performance scientific and mathematical libraries out there. Don't trash a language just because it's not your favorite or it's old. Often times they still work very well if used for the right purposes. Those purposes just may not be the same as your current purposes/applications.

"and we'll be saying a big hello to all intelligent life forms everywhere... and to everyone else out there, the secret is to bang the rocks together, guys."

Mice. Microsoft has always (I'm thinking all the way back to my first IBM compatible in 1993) made very good mice. Especially ergonomic mice. While not a gaming mouse, my Microsoft Natural Wireless Laser Mouse 6000 is the most comfortable mouse for office use that I have ever used, and has one Hell of a good battery life. In the early days of laser gaming mice, I bought one that had higher precision and better response times than the then-current Logitech offerings. Logitech makes fine mice now too (I currently have a very comfortable MX500 gaming mouse at home), but it seems like historically they tended to lag a little bit behind Microsoft.

Microsoft mice are just about the only product they make that I have always had a positive opinion of, and still do. Their keyboards generally aren't too bad (damn Windows keys, give me back my 101 !!), but it's still mice I think of when it comes to a product I can respect out of Microsoft. I love to bash Microsoft as much as the next guy here, but I have to give them credit for their mice.