US carriers have been routinely sunk by canadian, australian, dutch and english subs. As another commentator mentioned, aircraft carriers are great for projecting power against an inferior enemy, not as much when facing a sophisticated foe.
Having used both name/password, electronic tokens etc. to access my financial data, I would like to see an objective analysis of their security. I personally prefer the electronic tokens used by several Dutch banks (ING, Rabobank, ABN AMRO), above the name/password features used by American banks (BofA, Wells Fargo, Chase, JP Morgan, Credit unions, etc.). But the main question is: how do they perform in real-life? Which schemes lose more money to scamming or phishing?
Evaluating the performance of my parents (70+) with modern authentication schemes, does not bode well. My parents are generally unable to distinguish phishing mail from real mail - how should banks balance the convenience of email against the requirements for safety?
Can anyone point to objective evaluations of bank security and authentication schemes?
The market is anonymous, unless you and our 'friend' agree on which product to trade you have no way of identifying the other party. On popular products, i.e. Google or Apple, this is impossible. On other products liquidity (trade volume) is so small that such transactions would stick out like a sore thumb.
On top of that, it will take a lot more than two lines of code to defeat all the checks and balances in trading code. These checks and balances usually trace their origin to things having gone wrong in the past. I would expect all trading firms to have good source code management systems, your 'enhancement' will not go unnoticed.
Thank you for your post, and thank you for your jury service.
Without access to all the evidence and testimony presented in court, I am still stuck with one question: Was justice served?
Based on your comments I concluded that Terry Childs did violate the law, and that in your opinion the whole situation was handled badly by all parties involved. Since law only exists within the context of human society, I find it dissatisfying that the human context was removed when you were instructed to apply only the law. By your own comments you were unhappy with the conduct of both parties in this trial, but what in your opinion would be a just outcome, in other words, how would justice be best served?
I for one am sick and tired of these types of attack. Whoever, in their right mind thought it was a good idea to expose SQL query inputs on the Web?
Ever heard of input sanity checking? It was very popular in the say, 60's, 70's and 80's. It means you reject fields you don't expect to be there, instead of arbitrarily passing them onto the backend database. These types of attacks illustrate what is wrong with web security: developer convenience trumps common sense everytime...
Next time we see Ballmer hopping along shouting developers, maybe could he please add the words 'SECURITY BY DESIGN', please, pretty please?
SQL injection attacks are asinine because they are so prevalent, easy for the hackers AND easy to fix. We should name and shame every site, and every web-application stack that allows these attacks to take place.
Not to forget that the business unit manager sold non-existent capacity in an effort to lock-in his bonus...
Data-centers are businesses, even if they are wholy owned by the company. The business of a data-center is delivering reasonable service at minimum cost. When you think long and hard about it, you can only conclude that a data-center is in the commodity business. The past ten years have clearly shown what happens to commodity businesses... The main problem however is that data-center competition and customer demand lead to the same end-result: shitty service at an acceptable price. In the end, large data-center screw-ups are rare and most companies do try to make an educated guess on their risk.
For data-center management to be fun again, we need: better tools, less proliferation of half-baked OSes, standardization of management APIs etc... Is it likely to happen: no, because it is a commodity and not enough people care....
To make you feel better: when cars where new and exciting, most people knew how to change a flat, check the oil, fix a bulb and manually crank the car, becuase cars would break down. Nowadays the average person may know how to check the oil and change a flat, but only if their dashboard warns them.... The same is true for data-centers, technology is amazingly more robust and easier to manage, to the point that most users don't care or know any better....
I second that, study what you enjoy and see where your interest takes you. I struggled with statistics when I studied for my masters, but my current job is steep in statistics and I am much better at it. Funny how that goes.... It's a lot easier to learn a Math subject when there is a real need to understand it present, otherwise it can remain abstract and obtuse.
The other piece of advice: do your homework, everyday, and don't give up. Seriously, I was a B+ student until my math teacher started checking my homework - I told him that there were other students more deserving of his attention. Within a few weeks I was an A-student...
As for making a choice, I would do both, but take the easier one first.
noise generated in the camera is a statistical fluctuation (0-aT) T exposure time, a is temperature dependent noise coefficient, cosmic particle hits act like a stuck pixel. Cosmic rays definitely do not streak in digital devices. They most commonly dissipate their energy in one cell only.
Not in favour of SSD drives for long term storage. I use RAIDz2 too in my setup. FreeBSD/OpenSolaris/Solaris/MacOS X, all doesn't matter to me, as long as it is ZFS (or something comparable).
The SSD drives are not immune to data corruption in the long term (older technologies actually fare better than newer high density SSDs), unless you 'respin' them once in a while.
I hear you, my biggest worry isn't fire itself, its fire after earthquake. In addition to my backup solution described above, I keep rotated drives with snapshots at work.
If my house burns down completely and all data is unretrievable I will have lost at most 6 months of data. Not all.
Even quality DVD surfaces (on DVDs you can burn yourself) degrade quickly over a period of time (in my experience 2-4 years). Doing a re-backup every 3 years is too risky, it would have to be every two. In my case, with close to 1.6 TB of personal data (video, pictures, the works) it is not even practical, it would mean doing a re-backup of a DVD every two-three days.
Actually Flash/memory drives are sensitive to radiation. Long term storage without regularly accessing the drive can lead to situations where blocks go bad beyond the ECC/CRC capabilities of the drive to fix. If you intend to store valuable data on memory devices for the long term you should (a) use multiple redundant drives (b) use a file-system with block-level ECC/CRC error correction and redundancy (like ZFS) (c) write each block to the device twice in different location (i.e. an mirror on the drive).
The future of Flash memory is such that unless they extend the ECC/CRC capabilities of the controller, the susceptibility of these devices for radiation will increase when the cells get smaller.
In case anybody doubts the impact of radiation on electronic devices, here is an interesting experiment you can do: take your digital camera, put the lens cap on and do timed exposure with increasing exposure times (1,2,4,8,... seconds). Then analyse these pictures for bad-pixels, or better, subtract the pictures from each other. The random bits scattered around on these frames are impacts of cosmic rays. Now apply the same principle on memory devices with much longer exposure times...
To cut my somewhat rambling post short: use memory devices as long term storage? No. Not without thought about the required data reliability.
I recently built my own cheap backup server using OpenSolaris and ZFS. I used my old SATA drives (6x400GB), a $75 motherboard and AMD Athlon X2 combo, 4GB of DRAM ($69) and an old tower case. I did add two SATA 5-bay hot-swappable disk bays ($110 each) so that I can easily replace/upgrade my disks. Once a week I update data from my main server (also Solaris) to the backup server using ZFS incremental snapshots.
My PC's and Mac's all mount their user directory from my main server, and I rsync my laptop every day. The main server also serves as a SunRay server so I do most of my daily chores on a SunRay. I run Windows inside VirtualBox and I rarely ever turn on my windows PC anymore (the Windows instance in VBox also mounts from my main server). Inside my main server I have 2x 1TB drives, in a ZFS mirror setup, for the user directories and 2x400GB for the OS and scratch directories (all drives are SATA).
I'm very confident in this setup, also because I can yank out my drives in under 30 seconds in case of fire. The only thing I still have to do is put my backup server in a different room from the main server - that is a todo project for the near future.
Care to provide some proof? I don't believe for a second that an SSD drive can intelligently copy bits from a hard-drive. It would violate the way storage drivers work. The system does this, not the drive.
You are correct, RAID controller chips are more efficient in doing the parity calculations. But that is also their limitation - the point I was trying to get across is that using a CPU for ZFS is a trade-off with respect to functionality (higher levels of protection against errors, with more data movement) versus the RAID 5/6 capability of a controller (less functionality at greater data-efficiency).
The problem with anecdotal references is exactly that, they are anecdotal. You can trawl through any number of Slashdot discussions to find opinions that support, oppose, ridicule, pontificate, or elevate to religion any point of your choosing.
When it comes to making engineering decisions these anecdotal references have zero value.
Actually, when you take into account that most processors will be multi-core in the future, it makes more sense. RAID controllers are not scaling as fast as processors, so the performance gap will close pretty soon, without noticeable impact on your desktop. Giving ZFS more memory will speed it up even more (and memory is pretty cheap too at around $25/ GB).
Slashdot Mirror
Sinking a US carrier by being undetected has been demonstrated. see http://www.dutchsubmarines.com/boats/boat_walrus2.htm
US carriers have been routinely sunk by canadian, australian, dutch and english subs. As another commentator mentioned, aircraft carriers are great for projecting power against an inferior enemy, not as much when facing a sophisticated foe.
Having used both name/password, electronic tokens etc. to access my financial data, I would like to see an objective analysis of their security. I personally prefer the electronic tokens used by several Dutch banks (ING, Rabobank, ABN AMRO), above the name/password features used by American banks (BofA, Wells Fargo, Chase, JP Morgan, Credit unions, etc.). But the main question is: how do they perform in real-life? Which schemes lose more money to scamming or phishing?
Evaluating the performance of my parents (70+) with modern authentication schemes, does not bode well. My parents are generally unable to distinguish phishing mail from real mail - how should banks balance the convenience of email against the requirements for safety?
Can anyone point to objective evaluations of bank security and authentication schemes?
The market is anonymous, unless you and our 'friend' agree on which product to trade you have no way of identifying the other party. On popular products, i.e. Google or Apple, this is impossible. On other products liquidity (trade volume) is so small that such transactions would stick out like a sore thumb.
On top of that, it will take a lot more than two lines of code to defeat all the checks and balances in trading code. These checks and balances usually trace their origin to things having gone wrong in the past. I would expect all trading firms to have good source code management systems, your 'enhancement' will not go unnoticed.
Thanks, I now appreciate the dilemma faced by the jury when interpreting and judging the actions of all parties involved.
It's a sad case, I hope he gets sentenced to time served. He will be punished more than enough whilst trying to put his life back together again.
Thank you for your post, and thank you for your jury service.
Without access to all the evidence and testimony presented in court, I am still stuck with one question: Was justice served?
Based on your comments I concluded that Terry Childs did violate the law, and that in your opinion the whole situation was handled badly by all parties involved. Since law only exists within the context of human society, I find it dissatisfying that the human context was removed when you were instructed to apply only the law. By your own comments you were unhappy with the conduct of both parties in this trial, but what in your opinion would be a just outcome, in other words, how would justice be best served?
I for one am sick and tired of these types of attack. Whoever, in their right mind thought it was a good idea to expose SQL query inputs on the Web?
Ever heard of input sanity checking? It was very popular in the say, 60's, 70's and 80's. It means you reject fields you don't expect to be there, instead of arbitrarily passing them onto the backend database. These types of attacks illustrate what is wrong with web security: developer convenience trumps common sense everytime...
Next time we see Ballmer hopping along shouting developers, maybe could he please add the words 'SECURITY BY DESIGN', please, pretty please?
SQL injection attacks are asinine because they are so prevalent, easy for the hackers AND easy to fix. We should name and shame every site, and every web-application stack that allows these attacks to take place.
nuf said.
Not to forget that the business unit manager sold non-existent capacity in an effort to lock-in his bonus...
Data-centers are businesses, even if they are wholy owned by the company. The business of a data-center is delivering reasonable service at minimum cost. When you think long and hard about it, you can only conclude that a data-center is in the commodity business. The past ten years have clearly shown what happens to commodity businesses... The main problem however is that data-center competition and customer demand lead to the same end-result: shitty service at an acceptable price. In the end, large data-center screw-ups are rare and most companies do try to make an educated guess on their risk.
For data-center management to be fun again, we need: better tools, less proliferation of half-baked OSes, standardization of management APIs etc... Is it likely to happen: no, because it is a commodity and not enough people care....
To make you feel better: when cars where new and exciting, most people knew how to change a flat, check the oil, fix a bulb and manually crank the car, becuase cars would break down. Nowadays the average person may know how to check the oil and change a flat, but only if their dashboard warns them.... The same is true for data-centers, technology is amazingly more robust and easier to manage, to the point that most users don't care or know any better....
I second that, study what you enjoy and see where your interest takes you. I struggled with statistics when I studied for my masters, but my current job is steep in statistics and I am much better at it. Funny how that goes.... It's a lot easier to learn a Math subject when there is a real need to understand it present, otherwise it can remain abstract and obtuse.
The other piece of advice: do your homework, everyday, and don't give up. Seriously, I was a B+ student until my math teacher started checking my homework - I told him that there were other students more deserving of his attention. Within a few weeks I was an A-student...
As for making a choice, I would do both, but take the easier one first.
The point is that the thermal filter cannot adjust for cosmic radiation because the cosmic ray hit is far above the thermal noise level.
True, thermal noise is uniform over the detector (N=aT), N= noise level, a=Temperature dependent noise coefficient, T exposure time. Cosmic particle hits act like stuck pixels
noise generated in the camera is a statistical fluctuation (0-aT) T exposure time, a is temperature dependent noise coefficient, cosmic particle hits act like a stuck pixel. Cosmic rays definitely do not streak in digital devices. They most commonly dissipate their energy in one cell only.
Not in favour of SSD drives for long term storage. I use RAIDz2 too in my setup. FreeBSD/OpenSolaris/Solaris/MacOS X, all doesn't matter to me, as long as it is ZFS (or something comparable).
The SSD drives are not immune to data corruption in the long term (older technologies actually fare better than newer high density SSDs), unless you 'respin' them once in a while.
I'm married...
nuf said.
I hear you, my biggest worry isn't fire itself, its fire after earthquake. In addition to my backup solution described above, I keep rotated drives with snapshots at work.
If my house burns down completely and all data is unretrievable I will have lost at most 6 months of data. Not all.
Even quality DVD surfaces (on DVDs you can burn yourself) degrade quickly over a period of time (in my experience 2-4 years). Doing a re-backup every 3 years is too risky, it would have to be every two. In my case, with close to 1.6 TB of personal data (video, pictures, the works) it is not even practical, it would mean doing a re-backup of a DVD every two-three days.
Actually Flash/memory drives are sensitive to radiation. Long term storage without regularly accessing the drive can lead to situations where blocks go bad beyond the ECC/CRC capabilities of the drive to fix. If you intend to store valuable data on memory devices for the long term you should (a) use multiple redundant drives (b) use a file-system with block-level ECC/CRC error correction and redundancy (like ZFS) (c) write each block to the device twice in different location (i.e. an mirror on the drive).
The future of Flash memory is such that unless they extend the ECC/CRC capabilities of the controller, the susceptibility of these devices for radiation will increase when the cells get smaller.
In case anybody doubts the impact of radiation on electronic devices, here is an interesting experiment you can do: take your digital camera, put the lens cap on and do timed exposure with increasing exposure times (1,2,4,8, ... seconds). Then analyse these pictures for bad-pixels, or better, subtract the pictures from each other. The random bits scattered around on these frames are impacts of cosmic rays. Now apply the same principle on memory devices with much longer exposure times...
To cut my somewhat rambling post short: use memory devices as long term storage? No. Not without thought about the required data reliability.
I recently built my own cheap backup server using OpenSolaris and ZFS. I used my old SATA drives (6x400GB), a $75 motherboard and AMD Athlon X2 combo, 4GB of DRAM ($69) and an old tower case. I did add two SATA 5-bay hot-swappable disk bays ($110 each) so that I can easily replace/upgrade my disks. Once a week I update data from my main server (also Solaris) to the backup server using ZFS incremental snapshots.
My PC's and Mac's all mount their user directory from my main server, and I rsync my laptop every day. The main server also serves as a SunRay server so I do most of my daily chores on a SunRay. I run Windows inside VirtualBox and I rarely ever turn on my windows PC anymore (the Windows instance in VBox also mounts from my main server). Inside my main server I have 2x 1TB drives, in a ZFS mirror setup, for the user directories and 2x400GB for the OS and scratch directories (all drives are SATA).
I'm very confident in this setup, also because I can yank out my drives in under 30 seconds in case of fire. The only thing I still have to do is put my backup server in a different room from the main server - that is a todo project for the near future.
Not according to the Intel X25-E specs...
Care to provide some proof? I don't believe for a second that an SSD drive can intelligently copy bits from a hard-drive. It would violate the way storage drivers work. The system does this, not the drive.
You should use a mix of SLC and MLC. MLC for the frequent read, infrequent write, SLC for the frequent write.
There is more underneath the covers than meets the eye.
Real magic would have been demonstrating a move between ANY processor architecture - Power, SPARC, x86_64 etc..
Between x86 processors is nice, but not unexpected.
You are correct, RAID controller chips are more efficient in doing the parity calculations. But that is also their limitation - the point I was trying to get across is that using a CPU for ZFS is a trade-off with respect to functionality (higher levels of protection against errors, with more data movement) versus the RAID 5/6 capability of a controller (less functionality at greater data-efficiency).
Your mileage may vary...
LOL,
good luck....
The problem with anecdotal references is exactly that, they are anecdotal. You can trawl through any number of Slashdot discussions to find opinions that support, oppose, ridicule, pontificate, or elevate to religion any point of your choosing.
When it comes to making engineering decisions these anecdotal references have zero value.
Actually, when you take into account that most processors will be multi-core in the future, it makes more sense. RAID controllers are not scaling as fast as processors, so the performance gap will close pretty soon, without noticeable impact on your desktop. Giving ZFS more memory will speed it up even more (and memory is pretty cheap too at around $25/ GB).