You do acclimate to caffeine, though. Caffeine blocks adenosine receptors, which would normally absorb the adenosine released into the brain, and as a consequence your body releases adrenaline when it tries to make you tired and fails. That's the real 'caffeine crash', the big bottoming out after an adrenaline rush. Keep ingesting enough caffeine, and your nerve cells respond by creating more adenosine receptors; that means you need more caffeine to block out the same amount of adenosine. It's not huge, since you are only talking about the tiny amount that gets into the brain, as the rest of the nerves don't respond quite the same, so 'addiction' isn't the giant issue that it is with other drugs.

This is not to justify the Mormon position about drugs, as my thoughts on the matter are "could I see the list of those available?", but to dismiss the idea that caffeine is somehow different from other drugs.

The article mentions sandbox tools that allow admins to test applications and see what the code and the libraries are really doing, but doesn't name any of them. Any /.ers know if there are FOSS or BSD tools of this sort? Or even cheap proprietary ones? I read the code for any library I use, and I try to add some assert() like statements where the lib dev might have felt them unneeded to be certain that nothing gets past memory boundaries. But everyone misses something now and then, and just look at the IOCCC to spot how code that looks like it does one thing can do something else.

As someone who has written a few apps (none for sale, just local use) I feel like the article was taunting developers, "We know how to tell if you've been duped by your library code, and while we'll bash on developers who don't read the code they use, we won't help out those are writing in a new language and might get tricked by some language specification (or in C's case, unspecified compiler-dependent behavior). We'll even tell you that tools exist, but we won't name even one of them." Sure, I can spend all day trying to guess what type of sandbox tool I'm looking for, and install and test 30 or so of them, but that opens up the same can of worms of trusting code that I haven't read.

How many tons is that 6000 spent rods? Then remember exactly how big the Pacific Ocean is and how large, comparatively, a microgram is. A microgram is only 10^-12 of a ton, area crossed is a square fall off rate.

Could it immediately pollute the ocean and cause problems? Sure! Would the fall-out in the ocean cause a long term problem? Not unless there is way more than I expect from those fuel rods; the ocean is huge! One third of the Earth's surface, over half of the salt water on Earth; and you are worried about the toxins that humans failed to plan for when a volcano that's been dormant for a long history suddenly might be a little closer to eruption? Be worried about the loss of life from the volcano going off, and the loss of life from the climate change that a large eruption would cause (famine, loss of utilities, etc).

Or, if you must be scared of nuclear stuff, be scared of the fall out from all the nuke warheads and fuel stored close enough to Yellowstone that would be vaporized in the expected eruption.

We don't know what the OP is attempting to compile. It might be just some code to run inside the Arduino bootloader, or it might be a whole muLinux and a local GCC for the target. Heck, the Debian distro for the BBB might not have a binary for the target muC, which means compiling GCC before compiling the code (worst case). There is also the possibility of OPs chips not being supported in GCC. For example, I just picked up some Cypress PSoC boards; the tools for them are only available right now on Windows. Not ideal, but writing some C so GCC could mangle the analog portions of the PSoC would be more uncomfortable imho.

Unknown target devices, unknown tools, leaves me suggesting something a little more capable than a embedded device. While a windows x86 device might not be ideal for all folks, it might be necessary for some target device's toolchain. I have a several year old quad-core i7 with a geforce 560 and spinning drives that runs on less than 100 watts; one could use an older second hand laptop like that, or a newer even lower power one with an SSD. It's not what the OP asked about, but the OP also didn't provide enough information to presume that they knew what their target embedded muC might always be. And for the general case of other readers who are reading this, I think a small laptop is still the best choice.

Sorry for all the mu, I can't seem to get the html for μ to work

This, 100 times this.

Even an old 100 watt laptop will compile your code many times faster than something like the Black or Ras Pi will. A gig of RAM and swap space, something that embedded systems don't normally have, will make a huge difference. Just throw a small SSD (or boot from USB stick) in an old 2-code i3 with a crap graphics card, and what your code compile faster than a 5 watt embedded device will even launch your IDE or get through the first source code file.

He's a maths Ph.D. not a Computer Science or IT Bs.

I think that, had DF been programmed in a language that was more maths friendly, and less "write it like algebra on paper and let the compiler do magic" C then it might drastically increase the code efficiency. But the times he's been offered help with someone else writing a UI, he grasps that the UI needs a stable game API to make calls to, or a means to pass messages, and the game is not in that state nor is he going to re-do the UI each major version to keep it up to date. The same applies to pathing, it's not his field of maths (go read his thesis, it's very far from code related). A threaded pathfinding library has been offered to him, but since the objects change and the map representation changes, he presented some past problems that libraries couldn't cope with and the coders reading the discussion (myself included) wanted to launch kitten and whale rail guns.

Hell, tiles of his maps already store so much data, that it would make almost as much sense to use a memory intense pathfinding and allow each tile to determine the closest (gem/food/water/workshop of each type/etc) than to have each dward parse the map tree each turn to avoid running into each other.

360 degrees of phase every 1/60th of a second. 120 degrees is 1/3rd that, so minimum of 1/3 of 1/60 or 1/90th of a second....that would be common knowledge to anyone in the USA who hears 60 cycle hums on electrical lines or as line noise. Whether that would be how long the breaker would need to be off to get the generator that far out of phase, I don't know. But I really want to dig through this paper and see if the person I know who does know how long it takes, and warned the DOE and DHS about it, is mentioned by name.

What ever you do, if you think you are under legal duress, DO NOT DO THIS!

The first thing even the local cops are trained to do is to make an image of a volume. They do this for two reasons. The first is the legal: don't destroy evidence that the defense may call into question, and keep a chain of custody. The second is because people have tried exactly what you suggest. If you gave them a password that destroyed evidence, then even if they still had the original drive you have "attempted to destroy evidence" and interfered with the investigation, and probably a few other things that will add to your sentence and provided the evidence of the crime just by doing it in front of the police!

The TrueCrypt 'two encrypted areas in a single visible area' is fine if the police can not prove, through digging through windows, that you regularly keep two encrypted drives mounted (say X and Y). If you always mount both as drive X: and don't have other OS signs that it is used for multiple objects (drive UUIDs are unfortunately telling) then you are safer. But if you normally keep X and Y mounted, they'll want proof of what Y is; saying it's a USB stick, letting them plug it in and seeing it automount to G and not having other ids match would be . . . unpleasant.

Destruction of evidence, hindering a police investigation, and so on. And unless it is done at the flash memory chip level, they could get an image of the data.

What might be useful is something like an old article I read on randomly changing 'root's password on a *nix system, so it was next to impossible to log in as root. A user with permission could still use sudo to do what was needed, and "sudo -i" would be available for a single admin. Or the practice of changing the encryption key to /tmp or the swap partition on reboots; the user has no way to recover the data from those locations once a reboot has occurred. A secure encryption method that keeps even the intended user from using it would be a very had thing to sell, unfortunately.

I read it as just barely changing the vector of the light, not the velocity. All photons travel at c, but gravity could make the path of travel curve more than previously thought.

Neutrinos have virtual particle interactions as well. Only low energy photons seem not to (that I remember diagrams for, maybe they do too).
So ALL THINGS are made by the devil except for infrared light and AM radio. Seems to explain why looking at things makes you question stuff (visible light is a lie!) and only AM radio tells the truth.

I'd correct the photon "zig-zagging".
The guy is saying that we know photons can very quickly turns into an electron and it's friend a positron. They almost instantly turn back, but since the electron and it's friend are bigger and heavier than a photon of light they are affected by gravity more.
So, if the author is right, the light we saw took a different path to get to us. Just a little bit different, enough to add an hour over the course of 163,000 years.

Yup, it only affects a small percentage of photons for a very brief time. Schrodinger's equation and the rest of QED let you work out how many photons in a given burst over X amount of time. For most of our observations, in laser labs and other 'short' distances the effect shouldn't even be noticeable. But it might change astronomical measurements by a good bit. (well, 1.7 hours over 168,000 years, 1x10^-9; more or less, since light-years traveled and years traveled aren't identical at that distance due to expansion effects)

And if it affects photons, it will affect other particles as well. Maybe it explains the two neutrino bursts; if one burst traveled in a straight line and the other had a virtual particle interaction.

c doesn't get corrected. Our measurement of the path that the light took gets corrected, as the virtual particle pairs interact with all the forces that photons are less affected by because of speed.

That's what the article seems to suggest, yes. And that the virtual particle pair, if they exist for real time, would move at less than c for their short life-span. But the major change from Earth's perspective is that the gamma rays we saw did not travel in the straight line that the neutrinos did.

That might also explain the second neutrino burst (maybe, wild guess from a programmer). If some of the neutrinos went through a virtual particle state (Z boson, I think?) then they would also arrive at a different time. That would account for neutrinos that made the trip with no virtual particles, those that slowed down due to the mass of Z boson interactions, and, according to the research summarized in the article, all the gamma rays that went through a virtual particle phase and dealt with gravity. If it all works that way, it would be beautiful science explaining more things we thought we understood. Ahh, science!