Microscopic black holes disappear quickly due to Hawking radiation. So if your goal is to destroy the earth, creating a microscopic black hole is not the way you want to go.

The bigger a black hole is, the more slowly it evaporates. So if you want your black hole to do any damage, it'll have to be more than a certain threshold size. Turns out that minimum-size black hole you'll need to destroy Earth is roughly the mass of Mt Everest.

If we take the density of such a black hole to be 3 * 10^18 kg/m^3, then our black hole will look like a ball with a radius of about 12 cm, i.e. it looks like a soccer ball.*

See here for more details.

* no idea if my density assumption is reasonable. I'm not a physicist -- I got the number from 20 seconds of googling. The volume of your black hole may vary.

> As a hiring manager, I can tell you that I almost never have the time to go dig through a prospective candidate's open source code

I also have had the responsibility for hiring people from time to time. And OMG you are hiring a *programmer*. This is the *primary* thing they are going to be doing after you hire them. Their code is their main work product. The information is available to you and you're just going to *ignore* it? Who cares how charming and articulate they are if their code is crappy?

You could assess these things in 15 minutes in a 13kLOC code base. Did they write clear and useful comments? Is the code well organized? Is the high-level structure obvious? It's an excellent second- or third-pass method, and I've always found it pretty weird that it's not a more common practice.

Okay, maybe you have some reason to doubt that they actually wrote it or whatever. And of course they will be showing you the awesomest, cleanest little gem they ever wrote. Weigh it appropriately. But don't weigh it at 0%!

I want programmers who can write code AND are articulate and charming. Someone who is articulate and charming but cannot write code should not be hired as a programmer.

OTOH someone who can write code but is not particularly charming can still be a great contributor if they are not a total asshole, and can explain their code clearly in comments or in small meetings.

Probably the reason most hiring managers don't want to review candidates' code is because they are not particularly skilled at reading code quickly and making a useful judgment about its quality. This just means that the hiring manager isn't qualified to judge the candidate on this critical dimension. They should admit this limitation and farm out the task to someone else in their company whom they trust. (If there is no such person in their company then their company is pretty well fucked anyway.)

> Not to mention, most of the time open repositories like that are blocked from my work network anyway

Okay, but this is not a statement about the objective predictive utility of a hiring process that involves code reviews. It's just a statement that your company is toopid. :-) And you can always have the candidate email you the code. They key problem here is that *you* do not believe that reviewing people's code adds a lot of value, and on that point I believe you are quite mistaken.

> can the candidate speak, in detail, to their resume. Many can't, by the way

Totally agree with you on this point. It's amazing how many people just blatantly lie on their resume. In my experience it's, like, way more than half.

This makes it frustrating for people who are honest on their resumes, since managers have to take steps to weed out the significant population of liars out there.

"So what's the difference between TCP and UDP?"

"I have been writing network protocol stacks for 138 years. I sleep with a printed copy of the TCP state machine under my pillow, and all night little synsies and finsies dance through my dreams. I hang out with Vint Cerf every weekend. It says so right on my resume. Why don't you believe me?"

"Because 95% of people who say that cannot articulate a reasonable answer to my question. :-("

I guess until we can get most people to stop lying on their resumes, that will just be a fact of life.

It would have been even better if it were not wildly incorrect. You can't cancel an order once it has been executed. The grandparent sounds super confident, but is largely making stuff up.

My personal programming hero, D. Richard Hipp, works with a very small team on SQLite (which you may have heard of). He uses his own, home-grown SCM called fossil. It probably doesn't scale to a zillion contributors but, like all of Hipp's work that I'm aware of, it's super clean and easy to use. Sounds pretty great for your use case.

And, as other people on this thread have already said: your habit of throwing stuff into production without testing it is similar to playing Russian Roulette with your company. Stop that. Stop that right now.

And thus, with the exit of half a dozen of the highest level Microsoft department heads, there is nobody at MS that can take over Ballmer's seat as CEO if the board of directors decides to fire him. He's made it much harder to fire him now.

1. Install your own wireless hub and 3G station in your store.
2. Actively inject fake higher prices into competing web pages' HTML as it flies through your local router. Customer thinks the price in your store is the best one.
3. Profit!

Informative?! This post is so, so terribly wrong.

Wrong. We're not on the wrong track. Databases don't only handle "homogeneous data" sets. You just don't know how to use them flexibly.

Wrong. Databases abstract away I/O primitives and file formats, making creating/accessing your data much simpler than using (e.g.) flat text files.

Wrong. A great many things beat flat text files, under a great many use cases. The capabilities of (e.g.) a sqlite database are a strict (and much larger) superset of those of flat text files, while usually being *less* burdensome to their users.

You can always dump your db contents to a flat ascii format if you need to (like to send the data to gnuplot).

Just because *you* don't know how to properly use a db doesn't mean you should shoot down the very idea in such broad strokes.

Others have already mentioned SQLite. Let me briefly expound on the features that are likely the most important to you, assuming (if you'll permit me) that you don't have much experience with databases:

1. 0. The basic idea here is that you are replacing this whole hierarchy of files and directories by a single file that will contain all your data from an experiment. You figure out ahead of time what data the database will hold and specify that to SQLite. Then you to create, update, read, and destroy records as you see fit--pretty much as many records as you want. (I personally have created billions of records in a single database, though I'm sure you could make more.) Once you have records in your database, you can with great flexibility define which result sets you want from the data. SQLite will compute the result sets for you.
2. 1. SQLite is easy to learn and use properly. This is as opposed to other database management systems, which require you to do lots of computery things that are probably overkill for you.
3. 2. Your entire data set sits in a single file. If you're not in the middle of using the file, you can back up the database by simply copying the file somewhere else.
4. 3. Transactions. You can wrap a large set of updates into a single "transaction". These have some nice properties that you will want:
   1. 3.1. Atomic. A transaction either fully happens or (if e.g. there was some problem) fully does not happen.
   2. 3.2. Consistent. If you write some consistency rules into your database, then those consistency rules are always satisfied after a transaction (whether or not the transaction was successful).
   3. 3.3 Isolated. (Not likely to be important to you.) If you have two programs, one writing a transaction to the database file while the other reads it, then the reader will either see the WHOLE transaction or NONE of it, even if the writer and reader are operating concurrently.
   4. 3.4. Durable. Once SQLite tells you the transaction has happened, it never "un-happens".
   5. These properties hold even if your computer loses power in the middle of the transaction.
5. 4. Excellent scripting APIs. You are a physical sciences researcher -- in my experience this means you have at least a little knowledge of basic programming. Depending on what you're doing, this might greatly help you to get what you need out of your data set. You may have a scripting language that you prefer -- if so, it likely has a nice interface to SQLite. If you don't already know a language, I personally recommend Tcl -- it's an extremely easy language to get going with, and has tremendous support directly from the SQLite developers.

Good luck and enjoy!

A G5 tower is a monstrous waste of electricity with trivial performance in return compared to a modern machine. Its primary use these days is as a space heater.

The ARM core has nothing to do with graphics. The graphics accelerator is a discrete logic unit chosen by the SOC maker to integrate into the chip. This part uses the standard AHB/AXI (ARM Host Bus) interface. A major architecture license is not required to do this.

CLR acceleration, on the other hand, seems like a possibility. They could replace the Jazelle (Java) mode. More likely, though, they will extend the ARMv7 ThumbEE mode, which is designed for this sort of thing. Here's the synopsis of ThumbEE from the Cortex reference manual:

The impact of the TRIM command is vastly overrated. It is effective on "naive" devices that don't allocate a reserve block pool and therefore have to erase before doing every write. On a modern SSD, the disk controller reserves 5-10% of the physical blocks (beyond those that the host can see) as an extended block pool. These blocks are always known to be free (since they're out of the scope of that OS) and are therefore preemptively erased. So, when your OS overwrites a previously written data block, one of these pre-erased blocks is actually written to and the old block is put in the reserve pool for erasing later at the device's leisure.

The one case where this isn't true is if you're constantly writing gigs of data to an empty drive. With TRIM commands, most of your drive may have been pre-erased, whereas without it you may overrun the reserve pool's size and then will be waiting on block erase. For normal desktop users, this is a pathological case. In servers and people who do a lot of heavy video editing it may matter a lot more.

My god. What are the moderators thinking?

I've been playing the game for 23 years, was trained by world-class coaches, and I'm here to tell you that you don't know what you're talking about.

It's part of the joy of the game, part of the culture of the game to wish and hope for your team to win. But just because a fan thinks something doesn't make it so.

If that were true, a group of randomly-chosen people would have a similar chance of winning the world cup as e.g. Germany. Which is, of course, ridiculous.

Obviously the game has a lot of problems, and some of those topics are hot today. The game arguably needs to be refined in a couple ways.

But it is absolutely *not true* soccer "isn't about making the best team win" or that it's "mostly luck". The overwhelming majority of the time, the best team *does* win. It's just that when that happens, it isn't big news.