Unfortunately, some companies and governments don't understand how to respond to failure analysis. Rather than dismissing a once in 1000 year flood or a 9.8 rated earthquake, they must design the system to fail safe in that event. For example, there are nuclear reactor designs that continue to cool the fuel even when all power is lost. Or, if the pressure vessel is breached, there should be an intentional weak spot which will direct radioactive steam and fuel through a known path to minimize radiation release and mix the fuel with materials to slow/stop the nuclear reaction.
Look around and you'll see a mix of responses to failure analysis. The Space Shuttle was poorly designed in that it didn't provide a method for the crew to escape easily and quickly. The Apollo system had an emergency tower rocket that would pull the whole capsule and crew off and away from the giant bomb beneath it.
Commercial airliners can continue to fly when all engines have failed or have run out of fuel.
Our huge dams will fail catastrophically because it is hard to cost effectively build something that can withstand a 10.0 rated earthquake while holding back all that water. Smaller dams would be one response.
Can you build something like the Dubai tower that will fail safe? The fact is that safety is a choice. We choose to build skyscrapers because land in specific cities is very expensive. Are they as safe as a sine story building? No.
People need to balance cost and safety. But too often a relatively small cost which would improve safety is dismissed. What would it have cost to move the diesel generators at the nuclear plant? What did it cost to put airbags and seatbelts in cars? What about having seats face backwards in a plane? Little things can increase survivabity, yet we still don't do them.
Every security process ever invented will have weaknesses which can be exploited. The techniques may involve social engineering, mechanical adjustment, software hacking, etc. The object shouldn't be to rely fully upon a single security process, but to have several in place.
In the case of a bus system not reporting usage immediately, you just have it record the card id and value when it is used and then dump the data at night. When you detect a card is being misused, you update the software on the bus to flag that card as invalid.
With physical access to the card, a hacker can change anything about it. The scanner on a bus could contain a list of valid cards when it left the garage, but then how do we deal with cards sold that day? The answer is to put "trip wires" into the card -- things which a hacker wouldn't recognize as being important. For instance, all valid card numbers will always be a multiple of 3, or that the 4th and 15th digit always add up to 7. The U.S. $100 bills have a number of such traps built in to fight counterfeiters.
No card has an immutable ID. No card can be made to increment a value each time it is used. And even if you do physical damage to a card (blow an electrical link) each time it is used, I can always clone a card or in some other way fake out the reader.
The answer is to limit a card to being valid for at most 3 months and changing the trip wires often. The time limit also allows you to react more appropriately when some black hat conference blows out one of your (many) security measures.
Admittedly I've only used this to connect to Sonicwall firewalls, but I found the interface clean and it worked for me where other VPN solutions wouldn't even connect.
Without someone else to lead you through the code set, the best option is to go make a small change that is desired by someone. That person becomes your customer and has a vested interest in confirming that your change works. Don't try to understand the whole code set -- just study the section(s) you think need to change to fulfill the request. Repeat. You'll build an understanding over time.
Add unit tests as you make changes to demonstrate how a section of code is used and to capture existing behavior. When you feel comfortable, begin refactoring sections which you found obtuse. If someone complains that you have broke something, add a test to make sure it doesn't happen again.
English is far more expressive than any computer language. A computer requires a precise set of instructions and therefore any language interpreted to machine code must match that requirement. The most efficient way to express an algoritm to a computer is likely not the most efficient for a human.
English lets you to articulate the nuances of the code that might be missed in the harsh structured environment of Java. Comments allow you to draw outside the lines!
I see several responses questioning the reliability of comments. Code can have bugs, why not comments? If the code has a bug I fix it. If a comment isn't "right", I fix it too. Just as you should look at all code with a bit of suspicion, do the same for comments.
Sure, programmers can and do write bad comments -- and they're probably the ones that write bad code. We all grow. I no longer write one comment on each line of assembly code but instead use a paragraph or two to describe a section of C++ code.
Writing self-documenting code is nice, but have you ever tried to interpret uncommented, templated C++ code? It isn't pretty. Thank goodness we have debuggers that will step through the layers and layers of indirection to finally get you to an invocation of some real code!
Code is useful for describing what you are doing. Comments are for explaing why (e.g. "I'm calling the xxxx routine because there is a bug in the.NET framework v1.2 which will hopefully be fixed in the next version but this call should work in either case.")
All the above options appear to be analog. Where is the digital connection? It looks like the set-top box/decoder receives a digital signal, but then must convert it to an analog signal for the display device. That just doesn't make sense for my plasma/lcd/oled/electro-luminescence displays. How long do we have to wait for a digital option?
VMS clustering *IS* the best implementation. But Windows clustering is nothing like the VMS version. Microsoft got Dave Cutler to reimplement the core VMS internals, but they failed to hire the cluster and file system people from DEC.
My experience is with Windows NT 4 Server Enterprise Edition. MS chose to use a "shared nothing" implementation - which, IMHO, means they don't do clustering. There is no cluster-wide locking, software runs on one node at a time, there was a limit of two nodes, and it required a shared disk.
Slashdot Mirror
Unfortunately, some companies and governments don't understand how to respond to failure analysis. Rather than dismissing a once in 1000 year flood or a 9.8 rated earthquake, they must design the system to fail safe in that event. For example, there are nuclear reactor designs that continue to cool the fuel even when all power is lost. Or, if the pressure vessel is breached, there should be an intentional weak spot which will direct radioactive steam and fuel through a known path to minimize radiation release and mix the fuel with materials to slow/stop the nuclear reaction.
Look around and you'll see a mix of responses to failure analysis. The Space Shuttle was poorly designed in that it didn't provide a method for the crew to escape easily and quickly. The Apollo system had an emergency tower rocket that would pull the whole capsule and crew off and away from the giant bomb beneath it.
Commercial airliners can continue to fly when all engines have failed or have run out of fuel.
Our huge dams will fail catastrophically because it is hard to cost effectively build something that can withstand a 10.0 rated earthquake while holding back all that water. Smaller dams would be one response.
Can you build something like the Dubai tower that will fail safe? The fact is that safety is a choice. We choose to build skyscrapers because land in specific cities is very expensive. Are they as safe as a sine story building? No.
People need to balance cost and safety. But too often a relatively small cost which would improve safety is dismissed. What would it have cost to move the diesel generators at the nuclear plant? What did it cost to put airbags and seatbelts in cars? What about having seats face backwards in a plane? Little things can increase survivabity, yet we still don't do them.
Every security process ever invented will have weaknesses which can be exploited. The techniques may involve social engineering, mechanical adjustment, software hacking, etc. The object shouldn't be to rely fully upon a single security process, but to have several in place.
In the case of a bus system not reporting usage immediately, you just have it record the card id and value when it is used and then dump the data at night. When you detect a card is being misused, you update the software on the bus to flag that card as invalid.
With physical access to the card, a hacker can change anything about it. The scanner on a bus could contain a list of valid cards when it left the garage, but then how do we deal with cards sold that day? The answer is to put "trip wires" into the card -- things which a hacker wouldn't recognize as being important. For instance, all valid card numbers will always be a multiple of 3, or that the 4th and 15th digit always add up to 7. The U.S. $100 bills have a number of such traps built in to fight counterfeiters.
No card has an immutable ID. No card can be made to increment a value each time it is used. And even if you do physical damage to a card (blow an electrical link) each time it is used, I can always clone a card or in some other way fake out the reader.
The answer is to limit a card to being valid for at most 3 months and changing the trip wires often. The time limit also allows you to react more appropriately when some black hat conference blows out one of your (many) security measures.
In regards to the comment about Cisco's clunky VPN client, a better option can be found at http://www.lobotomo.com/products/IPSecuritas/
Admittedly I've only used this to connect to Sonicwall firewalls, but I found the interface clean and it worked for me where other VPN solutions wouldn't even connect.
Add unit tests as you make changes to demonstrate how a section of code is used and to capture existing behavior. When you feel comfortable, begin refactoring sections which you found obtuse. If someone complains that you have broke something, add a test to make sure it doesn't happen again.
English lets you to articulate the nuances of the code that might be missed in the harsh structured environment of Java. Comments allow you to draw outside the lines!
I see several responses questioning the reliability of comments. Code can have bugs, why not comments? If the code has a bug I fix it. If a comment isn't "right", I fix it too. Just as you should look at all code with a bit of suspicion, do the same for comments.
Sure, programmers can and do write bad comments -- and they're probably the ones that write bad code. We all grow. I no longer write one comment on each line of assembly code but instead use a paragraph or two to describe a section of C++ code.
Writing self-documenting code is nice, but have you ever tried to interpret uncommented, templated C++ code? It isn't pretty. Thank goodness we have debuggers that will step through the layers and layers of indirection to finally get you to an invocation of some real code!
Code is useful for describing what you are doing. Comments are for explaing why (e.g. "I'm calling the xxxx routine because there is a bug in the .NET framework v1.2 which will hopefully be fixed in the next version but this call should work in either case.")
All the above options appear to be analog. Where is the digital connection? It looks like the set-top box/decoder receives a digital signal, but then must convert it to an analog signal for the display device. That just doesn't make sense for my plasma/lcd/oled/electro-luminescence displays. How long do we have to wait for a digital option?
VMS clustering *IS* the best implementation. But Windows clustering is nothing like the VMS version. Microsoft got Dave Cutler to reimplement the core VMS internals, but they failed to hire the cluster and file system people from DEC.
My experience is with Windows NT 4 Server Enterprise Edition. MS chose to use a "shared nothing" implementation - which, IMHO, means they don't do clustering. There is no cluster-wide locking, software runs on one node at a time, there was a limit of two nodes, and it required a shared disk.