Here's a serious question which has me totally baffled. As the parent says, it's pretty well agreed upon that neutrinos have some mass. Then how do they travel at light speed (let alone possibly faster)? I thought it would take infinite energy for a body with mass to get to light speed?

I remembered this anecdote from the great book "Expert C Programming" by Peter Van der Linden. See the bottom of page 61, and page 62: google books.

I have trouble believing one would do 0.7%.

Oh, they still exist. You just have to look around. I've been using Lee County Bank & Trust's reward checking account for 2 or 3 years now. They started out paying 4.5% or so on balances up to $25K. Now they "only" pay 2.5%. (I do expect this deal, and others like it, to evaporate once the new restrictions on debit card fees go into effect, since the "catch" with these deals is you have to use your debit card at least 10 or so times per month, so that the banks can earn their $0.40 per transaction or whatever it is they earn).

Link: Lee County Bank (warning , terrible flash site). There are more such banks cataloged at sites like bankrate.com, I think.

Sigh, you've missed the entire point of the "Primary Keyvil" articles (Part 1, Part 2, Part 3), and many similar ones. Let's go through your drivel point by point.

Wrong, wrong, wrong. A surrogate key, like "student ID", actually is an acceptable "primary key" for a table, but only if you have a real way to tell apart your users, something based on an understanding of an answer to the question "what defines a unique student, and how am I going to verify that?".

VERY WRONG! From the database's point of view, and the "primary keyvil" syndrome, it doesn't matter if you fill in the "student ID" using, say, a database function called SYS_GUID(), or whether you generate this GUID on the client side. Read Part 1 of the Primary Keyvil syndrome articles for another example. But let's take our example of a table of students and run with it. You, the database application developer and schema designer, have created a table of students where the only unique key is a "student ID". Let's pretend you're smart, and you only assign new student IDs to new students coming through the gate on admission day. So far, so good, right?

Well, you're sitting in your office when a freshman comes in and says "Hey, I lost my ID. How do I get a new one". Now you're in a tough spot. You could say "what's your student ID number?", and if the student knows it, then you print off a new student ID for him, since you know who he is based on his ID number, right? Uh oh, you've just opened a door to students impersonating other students. But let's ignore that problem for now... what do you do if the poor kid doesn't know his ID number? Well, you ask him..... his name? Right? What if it's "Joe Smith", and you have fifty of those in your giant state school? Uh, I guess you ask him his name, and his street address, right? That's got to be unique, right? Or maybe his current SSN, those can never change, right? And how do you prove that the student in front of you is really who he says he is?

The frantic grasping around in the above paragraph is why you need to have a good answer to the question "what distinguishes a unique student?" before you go designing a table like this. There are several ways to answer this question: in practice, you might enforce unique constraints on (full name + home phone number), or maybe just a unique key on SSN if you're daring. But either way, relying solely on some arbitrary identifier like "Student ID" with no actual anchor in reality opens all sorts of paths to trouble. (Incidentally, the social security administration has the same problem, they've just thought through and been through the consequences. They have elaborate, formal answers to the question "how do we distinguish unique people, regardless of SSN", for scenarios like assigning new SSNs, changing SSNs, replacing lost social security cards to people who don't remember their SSN, etc etc.)

Another major problem I didn't even touch on, is how your model would prevent a user from getting two student IDs, either intentionally or accidentally. If you haven't answered these fundamental questions, you will have a database full of garbage. Kind of like the No Fly List.

Privacy concerns aside, DNA would actually be a totally reasonable way to distinguish unique students -- student comes in to your office, you take a cheek swab, and issue him his replacement ID card. (Hrm, I guess this is ignoring the issue of genetic clones..)

Tangentially related article which it sounds like you need to read, in addition to getting a basic understanding of "surrogate keys": Falsehoods programmers believe about names.

I wish professors would do their jobs, and split hairs about issues like this. Then we'd have fewer cocksure fools on Slashdot. Sigh, one can dream.

First, let me say that I really appreciate the work Stanford put into these online classes, especially the "free for everyone" aspect. They've done a great job pioneering free online classes _done well_, with lecture videos recorded well plus lecture notes plus banks of review questions plus exams. Really a great package overall.

I'm slowly going through the Machine Learning class, and the course is great. The instructor does a great job of easing the student into an otherwise math-heavy topic with graphing and hand-plotting, "Intuition", and simple examples.

However, I want to discourage anyone from investing a bunch of time in the "Introduction to Databases Course". Here's a slightly-edited explanation I sent to a friend, to whom I had at first recommended the course, before I had a chance to go through some of the videos (just a background note, I've worked with RDBMSs for several years, as an application developer, plus occassionally DBA, plus some work on an OSS RDBMS):

After watching two or three of that class's videos I've decided to give up on it. The course seems to have a needless emphasis on XML data storage, which turns out to be basically useless for real-world big data problems. Plus, either the Professor's presentation is unacceptably sloppy or she just doesn't know what she's talking about: lecture video #2 (or #3, I forget) was particularly bad, with imprecise terminology thrown around (row vs tuple) plus highly questionable database design being presented matter-of-factly (table of students flagrantly violates what's known as "Primary Keyvil"). She dove straight into the use of NULLs in this example table, presenting them as perfectly acceptable -- which would be OK for an "intro to MySQL"-type class, but not for a real course on the background of relational theory and RDBMSs (see "SQL and Relational Theory" and its treatment of NULLs).

Not to dissuade you from taking it of course, there is probably some useful information in there.

Seeing the professor present her table of students as a simple cut-and-dried example, with an explanation that "student ID" was an acceptable primary key, and no other unique keys on the table, really gives me a poor opinion of the professor's real-world subject matter knowledge.

I wonder if they train people to be this ignorant? Or could places that sell cables for this price just attract people who buy into the BS?

It is difficult to get a man to understand something when his job depends on not understanding it. - Upton Sinclair

Couldn't Sun just write their JVM in Java, so that it could run on any platform without porting?

You either die a hero or you live long enough to see yourself become the villain.

The SQL standard itself doesn't allow for unsigned integers, that's why.

Hrm, any radio astronomers out there? How hard would it be to rig up a poor man's directional radio antenna powerful enough to send a clear signal to that planet?

Well, that's exactly what I use: T-Mobile pay by the minute, with an old G1 Android phone (the first android phone that came out, I think). The phone was about $100 used on ebay, and I pay about $5-10/month for 50-150 minutes of usage per month (the going rate for a 1000 minute, 1-year card is $90 on eBay). It sure is cheap, but dunno about "wonderful" - no 3G data, for one thing. And the phone is somehow designed to *require* a 3G-capable SIM card when you activate it with your Google account, otherwise it pretends it can't login to your google account via WiFi. So you really need to have a buddy with a T-Mobile SIM card and a 3G plan for this to work. I chose T-Mobile because the per-minute rate was the cheapest I could find that would give me a reasonable phone choice and coverage.

In summary: cheap: yes. good: yes. wonderful: not quite

For six months, I couldn't sleep. With insomnia, nothing's real. Everything's far away. Everything's a copy of a copy of a copy. When you have insomnia, you're never really asleep, and you're never really awake.

Uh-huh. And established in the US Constitution. Great example for the GP's claim that we're not any more socialistic now than 10 years ago.

GP probably just does what I do when I'm on a WoW marathon: pee into an empty 3-Liter of Mountain Dew next to the gaming chair. Don't want to take any risks, right?

(Only problem is sometimes when I get my Dew bottles mixed up.. Yecch!)

It sounds like you want to use PostgreSQL as something like a (non-durable) cache layer. I'm not sure anyone has tried removing WAL entirely from the system, but people have definitely played around with the idea. See e.g. here. With a little tweaking, you should be able to get a large speedup by sacrificing durability/crash recovery.