Using 100% of your RAM can easily make your computer slower. Firstly, if a page is "dirty", it needs to be saved to disk before it can be used for another activity. This causes a write to disk before a read, automatically making the read slower. To combat this, sometimes the data is automatically written to disk when the computer is idle, thus creating a pool of non-dirty pages. Under Windows XP, the pool of non-dirty pages includes data from previous disk reads (the read disk cache), and pages of program memory (virtual memory). The problem is "which page do you overwrite next?" If a program is about to read from a portion of its program memory, or is about to read data sitting in the disk cache, you don't want to delete that page. It is just that the operating system doesn't know which piece of data the program will need next.
The result is that having empty RAM is almost always beneficial. Blindly swapping program memory to disk is not a good idea. It never really was. RAM is much less expensive than it used to be. For many problems, current computers have vast amounts of RAM for the algorithms and software they implement.
On today's computers, a memory leak can effectively stop/bring down the computer. The real function of the page file is to soften this problem. Instead of dying relatively quickly, today's computers will slow to a crawl, and then die. The page file causes this.
If you have good, well behaved software, and 4 GB of RAM, you will likely experience better system performance under Windows XP by turning the page file off.
Tell a bridge engineer that he has no absolutely control over the hardware he has to work with and that it may have a billion variations, and see if he signs his name to it.
A civil engineer can be disciplined for not checking that a building is built to his/her specifications. The engineer is responsible for ensuring that the general contractor and the trades actually build what was intended. As such, many engineering contracts run for 60 or 90 days after project completion, allowing enough time to ensure all trades have been paid, and all work done to standard.
An exception is a "design only" contract, in which case you certify nothing, because you have absolutely no idea how someone might interpret the plans.
You might be forgetting acceleration and deceleration. At the high-Gs required to make the tin-can idea work, the tin-can would quickly become flattened. Of course, given usual design margins, the people inside would be flattened before the tin-can collapsed...
Also, I think the mass-dilation effects of traveling that close to the speed of light would probably have practical consequences that would not be pleasant. Any nearby object would have the mass of a black hole (or at least something very heavy). It would be difficult to fly straight. The total accelerated mass would be well in excess of the mass of the space ship. You would destabilize orbits of comets, which would not be nice either.
When I even think some major problem exists with either data on the hard drive, or the hard drive itself, I just replace the hard drive.
This permits data recovery of any salvageable data on the old hard drive. It also quarantines the virus infection to the old hard drive.
A new hard drive is worth $50-$100. If you find any important files on the old hard drive, then the new one has paid for itself. Also, it does much to preserve your chain of evidence if the problem requires forensics.
proper propane tanks have pressure release valves that vent the excess pressure.
Propane is heavier than air. Heat rises. If you have a fire under the propane tank, and the tank vents, then you have an even bigger fire. Maybe not quite a full scale BLEVE explosion, but it is really spectacular.
What type of contingency you are planning for? - Do you need employees? At least where I work, you can't make employees work in the dark. You have to evacuate the building. As such, your diesel generator must be sized to power the lighting, not just the server room.
- Do your servers need heat? or cooling? Do your employees need heat? The diesel generator must be sized to handle heating and cooling.
- Does your ISP have a diesel generator? The local telco? Are your running an internet site? If your internet connection goes down when the power dies, keeping your servers running might not help much.
- Do you have old-style phone lines? Do you need phones? Old-style phone lines work when the power is out. Otherwise, you might be out of business when your internet connection dies.
- Are you running an industrial plant? Either you have your own generating station, or you are unlikely to purchase a big enough diesel generator to keep operating,
- Are you running a shipping department? Does the entire shipping chain, including labelling, EDI, UPS, FedEx, Truck Carriers, workers (with lighting), all run when the power is out?
- Are you running a hospital? All hospitals should have backup power, and all medical equipment emergency batteries built-in.
The best contingency plans assume: your office/factory is gone. How do you stay in business? You should have a contingency to get every critical business function operating again, quickly. In reality, the failure will be less severe. For instance, a significant fire/theft requiring all computers to be replaced. If your contingency plan handles starting over from ground-zero, then just look at the section on what to do when all the computers are missing.
Always remember: The worst failures are unexpected. My hardest emergency contingency, was keeping a factory working and shipping when all data communications were lost. The saving factor was that the old-style telephone voice lines kept running, and I was able to purchase a significant quantity of old-fashioned modems on an emergency basis.
Actually, I despise programmers that depend on exceptions. If you are trying to work on any kind of hardened system, like a real-time system, or a system that "just has to work", or a system that must work in fixed memory, exceptions are nightmares. You have to prove that every single exception either can't happen or can be safely handled. Even "safe" handling can be a challenge. For instance, if an error occurs, the control system must keep running, otherwise more errors occur. In some contingencies, the software must just "keep handling errors". It is amazing how many functions can't handle a constant stream of errors without leaking memory, pausing for long periods of time, or pausing for operator input when no operator is present.
One project involved complex mechanical automation. The system performance was defined solely by the rate exceptions to the normal process occured. It was vital to have software that just works. If the mechanical exceptions caused exceptions in the computer software, then everything stopped working. It was impossible to keep track of all the complexities involving all the exceptions.
The only solution was simple software that had very few error cases, and each error case clearly exposed the error handling. As such, all error cases could be checked. Curiously, this was the same system that worked much better when ported from.NET to C. For low-level code, C is a much better language, no matter how trendy.NET is.
Originally, TPM intended to let you know that your computer is working in the "trusted manner." Usually, the "trusted manner" would be defined either by the corporate IT department; or by a generic secure profile from Microsoft if you are a typical home user; or by yourself if you are a skilled programmer/systems administrator.
The DRM people saw this technology and said: "This will be the best DRM ever."
The practical problem is that you can only trust one of:
a) your own configuration,
b) your corporate IT department,
c) the vendor of some big software system that needs protection (like AutoDesk for example),
d) your operating systems vendor (Microsoft),
e) Sony's DRM approved configuration,
f) Universal Music's DRM approved configuration,
... and so on, listing every major big DRM company in the market.
Fundamentally, you can only trust one vendor. One proprietary vendor will never trust another, and none of them will trust either you or your corporate IT department. Theoretically, the DRM vendors could form an alliance, through the likes of Macrovision. However, who would trust such an alliance? Even a neutral party, like the U.S. government, has been suggested and repeatedly vetoed as "the master of all trust."
Who do you want to trust? Who controls all the secrets on your computer?
It would not stop you if you put your foot on the main brake pedal, either. The brakes in cars aren't designed to overcome the engine.
What? Please don't make sarcastic jokes that people might believe. There are people whom, crazily enough, believe that to be true.
I've been in a truck with a stuck accelerator pedal, in snow conditions. The BRAKES DID NOT STOP THE ENGINE, and the BRAKES DID NOT STOP THE REAR WHEELS FROM SPINNING.
I think you might be comparing 4 brakes on 4 wheels on dry pavement, possibly with no ABS effects, to two brakes trying to stop an very powerful engine. The two brakes do not stand a chance. In fact, the ABS might actually detect the wheel slip, and incorrectly release the wrong brakes, particularly with that particular pick-up truck's RWAL (Rear Wheel Anti-Lock) braking system. The function of ABS is to reduce power to the locked wheels, which is precisely the opposite of what is desired when a runaway engine condition is encountered.
The only thing that saved me in the situation is the snow caused so much wheel slip, the rear wheels had no traction. The front wheels stopped solid on the first piece of dry pavement. Also, the front wheels had no ABS, so they locked solid. At first, I couldn't work out what was going on. In the end, I replicated the experiment 3 times. It didn't matter how hard I pressed the brake pedal, and even with full brake assist, those rear wheels would spin. If it wasn't for the fact the front wheels were on dry ground, the truck would have lurched forward, quickly.
Sadly, some microcontrollers implement index registers rather unusual fashions. The memory map may not be the same memory map as for direct moves, because of things like "access RAM". Also, the low order 8-bits may not roll over into the high order 8-bits. The ISRs may not consistently save the state of the index registers. There can be two index registers, one for program memory and one for data memory. Additionally, if the system is controlling high di/dt, high dv/dt loads, aberrant program behaviour can trigger fast moving reset line glitches and power line glitches that scramble fast changing registers, like the index register, but not program memory or I/O registers. This plays havoc with code using an index register. While technically all of this may be deterministic behavior, unless you are very very careful: one subtle non-obvious mistake can cause pseudo-random behavior.
Actually, your position dovetails with mine. I use C++ whenever practical. C++ has a number of features that make for much more readable code.
Unfortunately, some of the little microcontrollers have rather flawed compilers. When implementing tight loops and ISRs, you really need to count every line of generated assembly, and make sure it is the assembly that you intended. With a flawed compiler, correctness and reasonableness of the compiled code cannot be rashly assumed. My preferred approach is to uplink the data from the microcontroller to a higher level platform (ie: a PC), where I can do significant work with a "real" compiler. Code correctness, proper high-level language support and O/S support are very useful features.
Sadly, some of these microcontrollers implement index registers rather unusual fashions. The memory map may not be the same memory map as for direct moves, because of things like "access RAM". Also, the low order 8-bits may not roll over into the high order 8-bits. The ISRs may not consistently save the state of the index registers. There can be two index registers, one for program memory and one for data memory. While technically this may be deterministic behavior, unless you are very very careful: one subtle non-obvious mistake can cause pseudo-random behavior.
I use the small microcontrollers because they are good at what they do. They do the low-level data acquisition and control effectively, and operate in environments that would destroy many other devices.
That's ridiculous. C++ is just as predictable in a system as C is. C++ memory allocation is completely deterministic as to WHEN the allocation/deallocation occurs, as is object life-time (unlike Java and its ilk).
The fact that you are talking about memory allocators shows that you may be thinking about this problem on a much to high level.
It is very common for some of the problems involving real-time embedded systems to require "creative" low-level uses of the C compiler, that would scar high-level programmers for life. Low-level code is where you operate with maxims like:
"If you call malloc(), your code is broken (too slow.)"
"If you use strings, your code is broken (too slow.)" "Use a code generator, array lookups don't work."
"Your fired. You called new() inside an interrupt handler."
For a high-level programmer, the concept of writing code without using indirection is a foreign concept. Indirection is vital to advanced programming techniques, including malloc, _vtables, arrays, strings, and linked lists! However, on certain embedded architectures, significant speed gains result from having deterministic memory accesses. If it takes writing code without access to malloc, _vtables, arrays, strings, etc., then that is what you do to get the system working and shipped. Some of embedded code needs to execute without an operating system, or before the operating system loads, and sometimes before the "stack" is set up. "Heaps", in certain embedded applications, you wish such a thing existed...
Sometimes I wonder how much we have forgotten. The advantage of a good computer keyboard is that a secretary, and even a programmer, should be able to touch type. They can type a long passage of text, without looking at the keys. If you can do this, your typing speed is way faster than someone that has to look at notes, and then look back at the keyboard.
Further, the advantage of handwriting was that you could write far faster than you could type. That was the whole point of script and shorthand. With shorthand, you can write as fast as someone speaks, and people can speak very fast. Today, no one teaches shorthand, and many schools omit cursive script.
In a few more years, someone will patent writing with a pen on a tablet with special symbols that makes handwriting faster. Only, it won't be called shorthand...
I'm definitely no expert on x86, but my impression was that precisely because of this trick that everyone does, modern CPUs still do xor reg,reg at least as fast as moving 0.
You are correct. XOR reg,reg was such a common instruction on the x86, that essentially it became the special case CLR instruction. Essentially, if you see a CLR instruction on an x86 assembly printout, it is the XOR instruction in disguise. The x86 has no CLR instruction.
Ok well that's changed now. Our more complex modern CPUs have special logic for clears, and doing a move to the register with 0 is faster. So it was a time limited trick, useful back when he started doing it, but no longer something worth trying.
Essentially, all current "simple" CPU instructions execute with the same speed. However, the XOR instruction is still faster than the MOV instruction because of instruction bandwidth and cache effects. Most code today is limited by cache and bandwidth limits, like the need to load instructions into the instruction decode pipeline immediately after a jump instruction. The MOV reg, 0 immediate move instruction is a two-byte instruction, and the XOR reg, reg instruction is a one-byte instruction. As such, in real code, the XOR instruction is usually slightly faster, because it results in smaller code.
Additionally, all of the modern x86 CPU implementations special case the XOR reg,reg instruction into a MOV reg, 0 immediate move instruction inside the instruction decode stage anyway. As such, no significant functional difference exists. The only case where a move instruction is quicker is when the condition codes are propagating a side-effect via the condition code registers. Thus, in theory:
ADD AL, AH
MOV CL, 0
JC somewhere
should execute quicker with a MOV instruction as opposed to a XOR instruction. However, in practice, this piece of code:
XOR CL, 0
ADD AL, AH
JC somewhere
executes with exactly the same speed, because the out-of-order execution units inside the x86 automatically optimize the code and make it equivalent. As such, you are best with the "short small" code, which means that the XOR reg, reg instruction is still the fastest way to do a register clear.
If one was as likely of winning the lottery as being falsely sent to prison because of DNA error, then it'd take quite a few million trials before no one wins. That's what I call "a very high probability".
Firstly, if the odds of a false conviction happening are 1 in a million, then 50% of the time the first false conviction will happen within the first 700,000 people.
Secondly, you don't know the probability of being falsely sent to prison is in fact one in a million, because no one has done the experiment to measure it. In fact, most applied scientists wouldn't ever claim such a thing about a PCR DNA analysis, because of the contamination problem. With a practical experiment, you will measure the highest fault rate for the lab.
I special in statistical analysis of gauges. It is very very tough to build any device that repeats to one in a million given practical real-world problems. You hit major practical issues, like the probability of people misunderstanding a gauges output is greater than one in a million. Seriously, if you have 3 people repeat the same simple observational test, the odds of all three people making the exact same mistake are often greater than one in a million. We inadvertently replicated this test on a system I worked on. Humans are a massive source of defects in any gauging system, and a well-known source of error in PCR DNA testing.
And even if tens of millions play the lottery every week, it still happens once in a while that no one wins.
Think of two probabilities:
1. The probability of a double lottery winner occurring, ie: the probability that someone wins the lottery grand prize twice inside their lifetime.
2. The probability of no one winning the grand prize of any lottery in North America.
I think you will find the probability that in any given week, (1) occurs much more often than (2). Even if you do some work to compensate for massive numbers of lotteries in North America, and assume that everyone plays in the same lottery (which isn't true), and only once (which isn't true), the first probability is still greater than the second, often by many orders of magnitude.
Statistics when dealing with large sample sizes are strange. Lay people don't comprehend them well, and even statistics people frequently make mistakes. One mistaken assumption about the dominant statistical failure rate, and the analysis is thrown. Additionally, when dealing with very large numbers, the statistics result in surprising conclusions.
How it really works? Imagine that you already identified several suspects. If you take DNA samples of these few people and one of them matches the DNA from the hair from the scene, you can still conclude that given your knowledge, with a very high probability the person in question was present at the crime scene.
While true, this statement is yet another example from the trap of misleading statistics. Individually, your statement is likely true. However, collectively, for all the tests the FBI lab is likely doing, then it is likely false.
Look at it this way: "The probability of me, as a random individual, winning the lottery today is near zero." From this, it is tempting to conclude that: "no random individual in North America will win the lottery today." However, this is clearly not true. Multiple random strangers will almost certainly win the lottery today.
The statement "no random individual will win the lottery today" is false, because a huge number change occurred. There are millions of people in North America. A similar problem happens with the FBI genetic testing. They do a great deal of testing. Proving an individual test is likely correct is very different than proving large numbers of tests are all correct.
From a statistical analysis point of view, you would be better matching any given DNA profile against everyone else's in North America. Then you would know exactly how many random matches occurred, and if lab contamination occurred, because the sample would match the lab techs and the police officers DNA too. This is the test the FBI is arguing against. Nevertheless, this is the validation test that needs to be done, because modern PCR DNA techniques should detect significant numbers of people connected with the location and/or sample access path, over significant periods of time.
Next time I travel I'm bringing my gieger counter.
Safety equipment in Carry-On??? You will get stopped searched, strip searched, arrested, interrogated, re-arrested, re-interrogated, and charged with mentioning something you shouldn't at an airport.
Parachutes are banned from flights, and I think life preservers are too. Tools are also banned, stuff like screw drivers, allen keys and multi-meters. This is what happened when an MIT student showed up at the airport terminal with a circuit on her shirt. This is what happened when a traveller dropped an iPod into an airplane toilet.
Good luck with a Gieger Counter. It will start a minor terrorist incident.
Essentially, your argument applied in Canada, was used in Canada, and the people won at the Supreme Court. As a result, downloading files for personal use is largely legal in Canada. Uploading of files is still a grey area.
Then some artists pointed out that the Canadian music industry hasn't been properly paying royalties on some of the CDs it has been selling. In fact, they have been selling CDs without a proper contract in place at all. As such, a bunch of the large Canadian record companies are on the hook for billions in liabilities.
Effectively, in Canada, the recording industry has been violating it's own anti-copying laws. Things are very different in Canada, as opposed to the U.S. The recording companies are being chased by the musicians! For non-payment of royalties!!!
It was real, but hyped. None of us seriously expected 747s to invert on crossing the International Date Line, as some more fevered commentators speculated, nor did we expect nuclear power stations to destabilize.
The 747 has the significant advantage of being a relatively old plane, thus most of its systems were date immune. Also, a 747 won't fly inverted, or at least I don't know anyone that has tried to fly a 747 inverted. Nuclear power stations are another example of old equipment designed largely without date information in the critical systems.
In Canada, Mattel decided to sue Barby's Restaurant for the "Barbie" trademark. Barby's Restaurant was a Barbecue restaurant, and hence had nothing to do with Mattel's Barbie Dolls. The case went all the way to the Supreme Court, and Mattel lost.
The brief blurb I read, indicated the restaurant gave up in the U.S. case, as it couldn't afford the litigation. The cost of litigation was an issue in the Canadian case too. I think it was quite touch and go for the restaurant. Mattel, obviously, could afford the legislation.
Trademark law encourages companies to stop other companies from infringing on their trademarks. Specifically, you may lose control of your trademark if it enters common speech, or if you allow other people to infringe on it. This results in companies being much more vexatious than otherwise necessary, because they do not want to lose control of trademarks.
At least in Canada, results of these lawsuits are mixed. At this point, numerous American companies have accused Canadian companies of infringing on American Trademarks, even though the business in question had a valid Canadian Trademark before the American company moved to Canada and noticed. On the whole, a non-infringing or pre-existing trademark is always given priority. As such, Canadian companies with a pre-existing registered trademarks win against American Multinationals.
The issue is the cost of the lawsuit. However, in Canada, the lawsuits are not completely one sided. Specifically, in Canada we have a "loser" pays rule. Additionally, sometimes the small companies count counter-sue the multinational for damages. As such, the smart multi-nationals buy out small Canadian businesses, rather than lose the lawsuits in court. To use a WalMart example:
If (a) you have a pre-existing store called "Wal-Mart" where you sell wool, and
(b) "WalMart" moves to Canada, and
(c) "WalMart" sells wool,
then WalMart must pay damages to the pre-existing store "Wal-Mart". I use the WalMart example because something like that actually happened in Canada.
Take a careful look at what your Java program is actually doing, in whatever example applications that you have. If you then rewrote the same program in C++, to do exactly the same things, then it would be dead slow too. In fact, when certain widely encouraged programming practices are used, it can cause C++ to be very slow too.
If you sit down and rewrite the Java program so it doesn't do all the "idiotic" things that no normal C programmer would do, then Java is surprisingly fast. Hence the variability between different peoples opinions of speed in Java. Personally, I don't like the way Java makes it difficult to get an assembly printout. As such, I don't know when the Java compiler is making fast code or slow code. I think that is the real problem with Java is that it is so abstracted from real hardware that few programmers have any idea of what it is the average Java program really does.
I have done projects like this, and received massive speedups and performance increases. The issue is that you need to understand the real reasons why rewriting a program in C and/or assembly gives a massive performance increase. Inevitably, the reason why the C program is so much faster, is that a programmer has went through and rethought the application. The programmer eliminated string copies, string manipulations, data communication overheads, and data manipulation/translation overheads by rethinking the programs design.
For example, imagine a very simple application designed to take a digital input, and display a red/green indicator to a user depending on the input state. Count every time a major string overhead, data communication overhead, or data translation overhead occurs in each of the proposed solutions.
Web Solution 1. Input digital input via PLC (Data Overhead #1)
2. Upload data from input via PLC communications protocol to PC (Data Overhead #2)
3. Make data available to other programs, for example RSSQL makes real-time I/O appear as SQL database queries (Data Overhead #3)
4. Use PHP or ASP to generate a web page based on a SQL query for the real-time input (Data Overhead #4)
5. Use a web browser to query the relevant web page. (Data Overhead #5)
Web Solution performance: it might be able to update the display screen every 1/5 second.
Embedded C Solution 1. Input a data point using real-time I/O
2. Paint a computers display screen accordingly. (Data Overhead #1)
C Solution Performance: 1/60 second, limited by the refresh rate of the monitor.
Assembly / Microcontroller Solution 1. Input the data point, with INP , AX
2. Output the data point to a Red/Green LED, with OUT AX,
Note: the assembly implementation doesn't have any string manipulation, so it doesn't have any significant data overhead.
Assembly Execution Time: Less than 1 micro-second.
The crucial concept from the above example is that the programmer reduced overhead and execution time, by simplifying program operation. The problem was solved in 3 different ways, and the fastest solution wiped out all the communication/string/data management overhead. If you want to make a computer program very fast, it is necessary to reduce data communication, string manipulation, and complex data structure overhead.
Which languages do this and why:
Level 1 - Simplest: Assembly is the best at wiping out string overhead, because engineers willingly migrate complex functionality to hardware before implementing it in assembly. In this case, the display screen was eliminated in favour of a direct output to an LED.
Level 2 - Low-Level: C is remarkably quick at string manipulation programs, because programmers minimize the amount of string manipulation. String manipulation in C sucks, and is difficult to get correct. As such, programmers attempt to minimize it, or use optimized tools like lex/flex or yacc/bison that automate the difficult problems.
Level 3 - Garbage Collected: Java and.NET encourage carefree string use and data structure use. The have automatic garbage collection. As such, minimal penalties exist for the programmer to use strings.
Level 4 - Scripted: PHP, Perl, Python are higher level languages focused on easy programming for high-level tasks. They pretty much assume the programmer doesn't care about the overhead of processing strings or complex data structures. Instead, they make it easy for the programmer to program the complex data structures.
An application like FaceBook has to have some complex data structures to do its job. In that case, a migration from PHP to C will likely not produce great benefits, because the C program still has to do all the same work the PHP program does. The old rule was that interpreters were very slow. With modern techniques, just about any language can be sufficiently compiled to
Slashdot Mirror
Using 100% of your RAM can easily make your computer slower. Firstly, if a page is "dirty", it needs to be saved to disk before it can be used for another activity. This causes a write to disk before a read, automatically making the read slower. To combat this, sometimes the data is automatically written to disk when the computer is idle, thus creating a pool of non-dirty pages. Under Windows XP, the pool of non-dirty pages includes data from previous disk reads (the read disk cache), and pages of program memory (virtual memory). The problem is "which page do you overwrite next?" If a program is about to read from a portion of its program memory, or is about to read data sitting in the disk cache, you don't want to delete that page. It is just that the operating system doesn't know which piece of data the program will need next.
The result is that having empty RAM is almost always beneficial. Blindly swapping program memory to disk is not a good idea. It never really was. RAM is much less expensive than it used to be. For many problems, current computers have vast amounts of RAM for the algorithms and software they implement.
On today's computers, a memory leak can effectively stop/bring down the computer. The real function of the page file is to soften this problem. Instead of dying relatively quickly, today's computers will slow to a crawl, and then die. The page file causes this.
If you have good, well behaved software, and 4 GB of RAM, you will likely experience better system performance under Windows XP by turning the page file off.
A civil engineer can be disciplined for not checking that a building is built to his/her specifications. The engineer is responsible for ensuring that the general contractor and the trades actually build what was intended. As such, many engineering contracts run for 60 or 90 days after project completion, allowing enough time to ensure all trades have been paid, and all work done to standard.
An exception is a "design only" contract, in which case you certify nothing, because you have absolutely no idea how someone might interpret the plans.
You might be forgetting acceleration and deceleration. At the high-Gs required to make the tin-can idea work, the tin-can would quickly become flattened. Of course, given usual design margins, the people inside would be flattened before the tin-can collapsed ...
Also, I think the mass-dilation effects of traveling that close to the speed of light would probably have practical consequences that would not be pleasant. Any nearby object would have the mass of a black hole (or at least something very heavy). It would be difficult to fly straight. The total accelerated mass would be well in excess of the mass of the space ship. You would destabilize orbits of comets, which would not be nice either.
When I even think some major problem exists with either data on the hard drive, or the hard drive itself, I just replace the hard drive. This permits data recovery of any salvageable data on the old hard drive. It also quarantines the virus infection to the old hard drive.
A new hard drive is worth $50-$100. If you find any important files on the old hard drive, then the new one has paid for itself. Also, it does much to preserve your chain of evidence if the problem requires forensics.
Says someone who has never had a user bring a giant crane crashing down on top of their head.
The sequence of events was so convoluted that everyone concerned said: "He actually did that?!"
Propane is heavier than air. Heat rises. If you have a fire under the propane tank, and the tank vents, then you have an even bigger fire. Maybe not quite a full scale BLEVE explosion, but it is really spectacular.
Not properly maintained propane storage/transfer sites have be known to explode. For instance: the 2008 Toronto explosions, the 2006 explosion, and the Feyzin disaster. Propane is highly vulnerable to a BLEVE - Boiling Liquid Expanding Vapour Explosion. Many more smaller propane exposions have occured, they just did not make the news.
I've seen what happens when Propane explodes. I would think twice about using it for an emergency backup fuel source.
What type of contingency you are planning for?
- Do you need employees? At least where I work, you can't make employees work in the dark. You have to evacuate the building. As such, your diesel generator must be sized to power the lighting, not just the server room.
- Do your servers need heat? or cooling? Do your employees need heat? The diesel generator must be sized to handle heating and cooling.
- Does your ISP have a diesel generator? The local telco? Are your running an internet site? If your internet connection goes down when the power dies, keeping your servers running might not help much.
- Do you have old-style phone lines? Do you need phones? Old-style phone lines work when the power is out. Otherwise, you might be out of business when your internet connection dies.
- Are you running an industrial plant? Either you have your own generating station, or you are unlikely to purchase a big enough diesel generator to keep operating,
- Are you running a shipping department? Does the entire shipping chain, including labelling, EDI, UPS, FedEx, Truck Carriers, workers (with lighting), all run when the power is out?
- Are you running a hospital? All hospitals should have backup power, and all medical equipment emergency batteries built-in.
The best contingency plans assume: your office/factory is gone. How do you stay in business? You should have a contingency to get every critical business function operating again, quickly. In reality, the failure will be less severe. For instance, a significant fire/theft requiring all computers to be replaced. If your contingency plan handles starting over from ground-zero, then just look at the section on what to do when all the computers are missing.
Always remember: The worst failures are unexpected. My hardest emergency contingency, was keeping a factory working and shipping when all data communications were lost. The saving factor was that the old-style telephone voice lines kept running, and I was able to purchase a significant quantity of old-fashioned modems on an emergency basis.
Actually, I despise programmers that depend on exceptions. If you are trying to work on any kind of hardened system, like a real-time system, or a system that "just has to work", or a system that must work in fixed memory, exceptions are nightmares. You have to prove that every single exception either can't happen or can be safely handled. Even "safe" handling can be a challenge. For instance, if an error occurs, the control system must keep running, otherwise more errors occur. In some contingencies, the software must just "keep handling errors". It is amazing how many functions can't handle a constant stream of errors without leaking memory, pausing for long periods of time, or pausing for operator input when no operator is present.
One project involved complex mechanical automation. The system performance was defined solely by the rate exceptions to the normal process occured. It was vital to have software that just works. If the mechanical exceptions caused exceptions in the computer software, then everything stopped working. It was impossible to keep track of all the complexities involving all the exceptions.
The only solution was simple software that had very few error cases, and each error case clearly exposed the error handling. As such, all error cases could be checked. Curiously, this was the same system that worked much better when ported from .NET to C. For low-level code, C is a much better language, no matter how trendy .NET is.
No, you were right the first time.
Originally, TPM intended to let you know that your computer is working in the "trusted manner." Usually, the "trusted manner" would be defined either by the corporate IT department; or by a generic secure profile from Microsoft if you are a typical home user; or by yourself if you are a skilled programmer/systems administrator.
The DRM people saw this technology and said: "This will be the best DRM ever."
The practical problem is that you can only trust one of:
... and so on, listing every major big DRM company in the market.
a) your own configuration,
b) your corporate IT department,
c) the vendor of some big software system that needs protection (like AutoDesk for example),
d) your operating systems vendor (Microsoft),
e) Sony's DRM approved configuration,
f) Universal Music's DRM approved configuration,
Fundamentally, you can only trust one vendor. One proprietary vendor will never trust another, and none of them will trust either you or your corporate IT department. Theoretically, the DRM vendors could form an alliance, through the likes of Macrovision. However, who would trust such an alliance? Even a neutral party, like the U.S. government, has been suggested and repeatedly vetoed as "the master of all trust."
Who do you want to trust? Who controls all the secrets on your computer?
People constantly scan internet ports to find something open and worth hacking.
Linux servers are useful as command and control servers for bot-nets.
I've been in a truck with a stuck accelerator pedal, in snow conditions. The BRAKES DID NOT STOP THE ENGINE, and the BRAKES DID NOT STOP THE REAR WHEELS FROM SPINNING.
I think you might be comparing 4 brakes on 4 wheels on dry pavement, possibly with no ABS effects, to two brakes trying to stop an very powerful engine. The two brakes do not stand a chance. In fact, the ABS might actually detect the wheel slip, and incorrectly release the wrong brakes, particularly with that particular pick-up truck's RWAL (Rear Wheel Anti-Lock) braking system. The function of ABS is to reduce power to the locked wheels, which is precisely the opposite of what is desired when a runaway engine condition is encountered.
The only thing that saved me in the situation is the snow caused so much wheel slip, the rear wheels had no traction. The front wheels stopped solid on the first piece of dry pavement. Also, the front wheels had no ABS, so they locked solid. At first, I couldn't work out what was going on. In the end, I replicated the experiment 3 times. It didn't matter how hard I pressed the brake pedal, and even with full brake assist, those rear wheels would spin. If it wasn't for the fact the front wheels were on dry ground, the truck would have lurched forward, quickly.
Sadly, some microcontrollers implement index registers rather unusual fashions. The memory map may not be the same memory map as for direct moves, because of things like "access RAM". Also, the low order 8-bits may not roll over into the high order 8-bits. The ISRs may not consistently save the state of the index registers. There can be two index registers, one for program memory and one for data memory. Additionally, if the system is controlling high di/dt, high dv/dt loads, aberrant program behaviour can trigger fast moving reset line glitches and power line glitches that scramble fast changing registers, like the index register, but not program memory or I/O registers. This plays havoc with code using an index register. While technically all of this may be deterministic behavior, unless you are very very careful: one subtle non-obvious mistake can cause pseudo-random behavior.
Determinism isn't always about speed.
Actually, your position dovetails with mine. I use C++ whenever practical. C++ has a number of features that make for much more readable code.
Unfortunately, some of the little microcontrollers have rather flawed compilers. When implementing tight loops and ISRs, you really need to count every line of generated assembly, and make sure it is the assembly that you intended. With a flawed compiler, correctness and reasonableness of the compiled code cannot be rashly assumed. My preferred approach is to uplink the data from the microcontroller to a higher level platform (ie: a PC), where I can do significant work with a "real" compiler. Code correctness, proper high-level language support and O/S support are very useful features.
Sadly, some of these microcontrollers implement index registers rather unusual fashions. The memory map may not be the same memory map as for direct moves, because of things like "access RAM". Also, the low order 8-bits may not roll over into the high order 8-bits. The ISRs may not consistently save the state of the index registers. There can be two index registers, one for program memory and one for data memory. While technically this may be deterministic behavior, unless you are very very careful: one subtle non-obvious mistake can cause pseudo-random behavior.
I use the small microcontrollers because they are good at what they do. They do the low-level data acquisition and control effectively, and operate in environments that would destroy many other devices.
The fact that you are talking about memory allocators shows that you may be thinking about this problem on a much to high level.
It is very common for some of the problems involving real-time embedded systems to require "creative" low-level uses of the C compiler, that would scar high-level programmers for life. Low-level code is where you operate with maxims like:
For a high-level programmer, the concept of writing code without using indirection is a foreign concept. Indirection is vital to advanced programming techniques, including malloc, _vtables, arrays, strings, and linked lists! However, on certain embedded architectures, significant speed gains result from having deterministic memory accesses. If it takes writing code without access to malloc, _vtables, arrays, strings, etc., then that is what you do to get the system working and shipped. Some of embedded code needs to execute without an operating system, or before the operating system loads, and sometimes before the "stack" is set up. "Heaps", in certain embedded applications, you wish such a thing existed ...
Sometimes I wonder how much we have forgotten. The advantage of a good computer keyboard is that a secretary, and even a programmer, should be able to touch type. They can type a long passage of text, without looking at the keys. If you can do this, your typing speed is way faster than someone that has to look at notes, and then look back at the keyboard.
Further, the advantage of handwriting was that you could write far faster than you could type. That was the whole point of script and shorthand. With shorthand, you can write as fast as someone speaks, and people can speak very fast. Today, no one teaches shorthand, and many schools omit cursive script.
In a few more years, someone will patent writing with a pen on a tablet with special symbols that makes handwriting faster. Only, it won't be called shorthand ...
You are correct. XOR reg,reg was such a common instruction on the x86, that essentially it became the special case CLR instruction. Essentially, if you see a CLR instruction on an x86 assembly printout, it is the XOR instruction in disguise. The x86 has no CLR instruction.
Essentially, all current "simple" CPU instructions execute with the same speed. However, the XOR instruction is still faster than the MOV instruction because of instruction bandwidth and cache effects. Most code today is limited by cache and bandwidth limits, like the need to load instructions into the instruction decode pipeline immediately after a jump instruction. The MOV reg, 0 immediate move instruction is a two-byte instruction, and the XOR reg, reg instruction is a one-byte instruction. As such, in real code, the XOR instruction is usually slightly faster, because it results in smaller code.
Additionally, all of the modern x86 CPU implementations special case the XOR reg,reg instruction into a MOV reg, 0 immediate move instruction inside the instruction decode stage anyway. As such, no significant functional difference exists. The only case where a move instruction is quicker is when the condition codes are propagating a side-effect via the condition code registers. Thus, in theory:
ADD AL, AH
MOV CL, 0
JC somewhere
should execute quicker with a MOV instruction as opposed to a XOR instruction. However, in practice, this piece of code:
XOR CL, 0
ADD AL, AH
JC somewhere
executes with exactly the same speed, because the out-of-order execution units inside the x86 automatically optimize the code and make it equivalent. As such, you are best with the "short small" code, which means that the XOR reg, reg instruction is still the fastest way to do a register clear.
Firstly, if the odds of a false conviction happening are 1 in a million, then 50% of the time the first false conviction will happen within the first 700,000 people.
Secondly, you don't know the probability of being falsely sent to prison is in fact one in a million, because no one has done the experiment to measure it. In fact, most applied scientists wouldn't ever claim such a thing about a PCR DNA analysis, because of the contamination problem. With a practical experiment, you will measure the highest fault rate for the lab.
I special in statistical analysis of gauges. It is very very tough to build any device that repeats to one in a million given practical real-world problems. You hit major practical issues, like the probability of people misunderstanding a gauges output is greater than one in a million. Seriously, if you have 3 people repeat the same simple observational test, the odds of all three people making the exact same mistake are often greater than one in a million. We inadvertently replicated this test on a system I worked on. Humans are a massive source of defects in any gauging system, and a well-known source of error in PCR DNA testing.
Think of two probabilities:
1. The probability of a double lottery winner occurring, ie: the probability that someone wins the lottery grand prize twice inside their lifetime.
2. The probability of no one winning the grand prize of any lottery in North America.
I think you will find the probability that in any given week, (1) occurs much more often than (2). Even if you do some work to compensate for massive numbers of lotteries in North America, and assume that everyone plays in the same lottery (which isn't true), and only once (which isn't true), the first probability is still greater than the second, often by many orders of magnitude.
Statistics when dealing with large sample sizes are strange. Lay people don't comprehend them well, and even statistics people frequently make mistakes. One mistaken assumption about the dominant statistical failure rate, and the analysis is thrown. Additionally, when dealing with very large numbers, the statistics result in surprising conclusions.
While true, this statement is yet another example from the trap of misleading statistics. Individually, your statement is likely true. However, collectively, for all the tests the FBI lab is likely doing, then it is likely false.
Look at it this way: "The probability of me, as a random individual, winning the lottery today is near zero." From this, it is tempting to conclude that: "no random individual in North America will win the lottery today." However, this is clearly not true. Multiple random strangers will almost certainly win the lottery today.
The statement "no random individual will win the lottery today" is false, because a huge number change occurred. There are millions of people in North America. A similar problem happens with the FBI genetic testing. They do a great deal of testing. Proving an individual test is likely correct is very different than proving large numbers of tests are all correct.
From a statistical analysis point of view, you would be better matching any given DNA profile against everyone else's in North America. Then you would know exactly how many random matches occurred, and if lab contamination occurred, because the sample would match the lab techs and the police officers DNA too. This is the test the FBI is arguing against. Nevertheless, this is the validation test that needs to be done, because modern PCR DNA techniques should detect significant numbers of people connected with the location and/or sample access path, over significant periods of time.
Safety equipment in Carry-On??? You will get stopped searched, strip searched, arrested, interrogated, re-arrested, re-interrogated, and charged with mentioning something you shouldn't at an airport.
Parachutes are banned from flights, and I think life preservers are too. Tools are also banned, stuff like screw drivers, allen keys and multi-meters. This is what happened when an MIT student showed up at the airport terminal with a circuit on her shirt. This is what happened when a traveller dropped an iPod into an airplane toilet.
Good luck with a Gieger Counter. It will start a minor terrorist incident.
Essentially, your argument applied in Canada, was used in Canada, and the people won at the Supreme Court. As a result, downloading files for personal use is largely legal in Canada. Uploading of files is still a grey area.
Then some artists pointed out that the Canadian music industry hasn't been properly paying royalties on some of the CDs it has been selling. In fact, they have been selling CDs without a proper contract in place at all. As such, a bunch of the large Canadian record companies are on the hook for billions in liabilities.
Effectively, in Canada, the recording industry has been violating it's own anti-copying laws. Things are very different in Canada, as opposed to the U.S. The recording companies are being chased by the musicians! For non-payment of royalties!!!
The interesting thing is that the international date line really does cause severe code problems. For instance, a squadron of F-22 Raptors was taken out by the date line.
The 747 has the significant advantage of being a relatively old plane, thus most of its systems were date immune. Also, a 747 won't fly inverted, or at least I don't know anyone that has tried to fly a 747 inverted. Nuclear power stations are another example of old equipment designed largely without date information in the critical systems.
In Canada, Mattel decided to sue Barby's Restaurant for the "Barbie" trademark. Barby's Restaurant was a Barbecue restaurant, and hence had nothing to do with Mattel's Barbie Dolls. The case went all the way to the Supreme Court, and Mattel lost.
The brief blurb I read, indicated the restaurant gave up in the U.S. case, as it couldn't afford the litigation. The cost of litigation was an issue in the Canadian case too. I think it was quite touch and go for the restaurant. Mattel, obviously, could afford the legislation.
Trademark law encourages companies to stop other companies from infringing on their trademarks. Specifically, you may lose control of your trademark if it enters common speech, or if you allow other people to infringe on it. This results in companies being much more vexatious than otherwise necessary, because they do not want to lose control of trademarks.
At least in Canada, results of these lawsuits are mixed. At this point, numerous American companies have accused Canadian companies of infringing on American Trademarks, even though the business in question had a valid Canadian Trademark before the American company moved to Canada and noticed. On the whole, a non-infringing or pre-existing trademark is always given priority. As such, Canadian companies with a pre-existing registered trademarks win against American Multinationals.
The issue is the cost of the lawsuit. However, in Canada, the lawsuits are not completely one sided. Specifically, in Canada we have a "loser" pays rule. Additionally, sometimes the small companies count counter-sue the multinational for damages. As such, the smart multi-nationals buy out small Canadian businesses, rather than lose the lawsuits in court. To use a WalMart example:
If (a) you have a pre-existing store called "Wal-Mart" where you sell wool, and
(b) "WalMart" moves to Canada, and
(c) "WalMart" sells wool,
then WalMart must pay damages to the pre-existing store "Wal-Mart". I use the WalMart example because something like that actually happened in Canada.
Take a careful look at what your Java program is actually doing, in whatever example applications that you have. If you then rewrote the same program in C++, to do exactly the same things, then it would be dead slow too. In fact, when certain widely encouraged programming practices are used, it can cause C++ to be very slow too.
If you sit down and rewrite the Java program so it doesn't do all the "idiotic" things that no normal C programmer would do, then Java is surprisingly fast. Hence the variability between different peoples opinions of speed in Java. Personally, I don't like the way Java makes it difficult to get an assembly printout. As such, I don't know when the Java compiler is making fast code or slow code. I think that is the real problem with Java is that it is so abstracted from real hardware that few programmers have any idea of what it is the average Java program really does.
I have done projects like this, and received massive speedups and performance increases. The issue is that you need to understand the real reasons why rewriting a program in C and/or assembly gives a massive performance increase. Inevitably, the reason why the C program is so much faster, is that a programmer has went through and rethought the application. The programmer eliminated string copies, string manipulations, data communication overheads, and data manipulation/translation overheads by rethinking the programs design.
For example, imagine a very simple application designed to take a digital input, and display a red/green indicator to a user depending on the input state. Count every time a major string overhead, data communication overhead, or data translation overhead occurs in each of the proposed solutions.
Web Solution
1. Input digital input via PLC (Data Overhead #1)
2. Upload data from input via PLC communications protocol to PC (Data Overhead #2)
3. Make data available to other programs, for example RSSQL makes real-time I/O appear as SQL database queries (Data Overhead #3)
4. Use PHP or ASP to generate a web page based on a SQL query for the real-time input (Data Overhead #4)
5. Use a web browser to query the relevant web page. (Data Overhead #5)
Web Solution performance: it might be able to update the display screen every 1/5 second.
Embedded C Solution
1. Input a data point using real-time I/O
2. Paint a computers display screen accordingly. (Data Overhead #1)
C Solution Performance: 1/60 second, limited by the refresh rate of the monitor.
Assembly / Microcontroller Solution
1. Input the data point, with INP , AX
2. Output the data point to a Red/Green LED, with OUT AX,
Note: the assembly implementation doesn't have any string manipulation, so it doesn't have any significant data overhead.
Assembly Execution Time: Less than 1 micro-second.
The crucial concept from the above example is that the programmer reduced overhead and execution time, by simplifying program operation. The problem was solved in 3 different ways, and the fastest solution wiped out all the communication/string/data management overhead. If you want to make a computer program very fast, it is necessary to reduce data communication, string manipulation, and complex data structure overhead.
Which languages do this and why: .NET encourage carefree string use and data structure use. The have automatic garbage collection. As such, minimal penalties exist for the programmer to use strings.
Level 1 - Simplest: Assembly is the best at wiping out string overhead, because engineers willingly migrate complex functionality to hardware before implementing it in assembly. In this case, the display screen was eliminated in favour of a direct output to an LED.
Level 2 - Low-Level: C is remarkably quick at string manipulation programs, because programmers minimize the amount of string manipulation. String manipulation in C sucks, and is difficult to get correct. As such, programmers attempt to minimize it, or use optimized tools like lex/flex or yacc/bison that automate the difficult problems.
Level 3 - Garbage Collected: Java and
Level 4 - Scripted: PHP, Perl, Python are higher level languages focused on easy programming for high-level tasks. They pretty much assume the programmer doesn't care about the overhead of processing strings or complex data structures. Instead, they make it easy for the programmer to program the complex data structures.
An application like FaceBook has to have some complex data structures to do its job. In that case, a migration from PHP to C will likely not produce great benefits, because the C program still has to do all the same work the PHP program does. The old rule was that interpreters were very slow. With modern techniques, just about any language can be sufficiently compiled to