That exists for indie sites, HAD was one of those once. It now has corporate backers, who did not mind the original Tektronic article but who seem wary to expend that much defending a suit.
Were they still a small indie LLC, with little to no resources, they could probably get a Pro Bono lawyer and have fun with it. What would be the worst Tektronics could win? The domain, if things were structured well; but not even the content (posts owned by poster, sub-license to a new LLC to set up a clone site, blah blah blah). But that isn't the case anymore. With a real bank roll behind them, and big advertisers, a lawyer is more likely to ask for money and a suit could be pretty damaging. If their advertisers pull out, the site goes away.
What confounds me is that Tek went after HAD in the first place. HAD didn't discover the hack, they just posted a link to someone who had a demo key that they had to return, an EEPROM reader that they hooked up, and the brains to spot a publicly available string and wire up another EEPROM to do the same thing. How did HAD suddenly become the party that needs a suit? Other than them just having deeper pockets that Joe Random Hacker.
And maybe Tektronics is busy with a breach of NDA or some other suit against the guy who tinkered with the EEPROM key that he was being loaned.
Disclaimer: I read HAD daily. I hope to get some hacks up there eventually, so maybe I have a vested interest in defending them.
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
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.
A storage facility near it contains another 6000 spent mox fuel rods. The smoke of the fire is plutonium oxide and chloride which is fatal to humans at doses of 1-10 micrograms.
There is little doubt that if that happens at Fukushima the fallout would be carried by the jetstream over the US and, eventually the entire Northern hemisphere.
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
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.
There is much that is NOT public knowledge.
For example*snip* How many milliseconds on and milliseconds off must I send the command to end up 120 degrees out of phase? What kind of out of phase protection relay is in service?
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.
This kind of thing is where having 2 different keys for an encrypted volume would be good, like a key for personal usage, and another key for usage when under duress.
The normal key would unencrypt the volume for you to use as normal, and the "duress" key would cause the volume to automatically do a secure data wipe of the volume file.
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
Franson's idea, as I understand it, is that during the small window between creation and annihilation, the massive particles are under the influence of gravity, which bleeds off energy. When the pair recombines, it results in a reduced velocity of the photon.
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.
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.
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.