If the machine costs ~$10M to build and they need to dedicate it for a year for each key they want to crack, that's secure enough for me. How much would it cost to kidnap me and torture either the original data or the keys out of me? $25K maybe? Plenty secure.
Now, bring that 5 orders of magnitude forward and we might have a problem. But for how many years does my data have to stay safe? If for more than 15, you can count on the fact that no currently available key-based cryptography will be secure enough. Period. Don't count on your key to protect you from attacks over that kind of time span.
I now it's not political around here to ask, but who cares what OS it runs?
I care what OS I can manage the contents of the device from. But the thing is an appliance. The OS it runs is completely irrelevant.
The stability of the appliance matters, and that will drive some design decisions for the hardware. But linux vs. everything else will not be the consideration.
Re:I Cancelled My Earthlink Account
on
Disconnecting
·
· Score: -1
Hmm. I'm surprised you had so much trouble with Earthlink. Twice in the last few years I've been without broadband access for short periods before and after moves.
During those windows, I've signed up for Earthlink dialup access service. Both times I kept the service for less than 2 months, and both times I had no trouble disconnecting service ( 10 minutes on the phone, talking to only one person. The hold sucked, but my expectations are _so_ low...).
For what it's worth, that ease of disconnection will play heavily in my thoughts the next time I need a dialup provider. Never mind that they probably lose money on a 2-month subscriber and probably don't want that business anyway...
Beware STL implementations. Some things I've come across in the past:
Microsoft's STL implementation's std::string is thread unsafe, and you can't make it threadsafe at the application layer. Their reference counting has a race condition that can lead to memory corruption.
Certain versions of the STL that come with GCC have thread-unsafe memory allocation routines.
I strongly recommend using STLPort for cross-platform consistency, thread-safety, and standards conformance.
I think the best thing that STL has going for it is that it is a standard, you should expect it on any C++ platform. Given that, why use (and pay for) third party libraries?
STL is not easy to learn, but it is a high-value skill. I hope I've written my last list...
Slashdot Mirror
Now, bring that 5 orders of magnitude forward and we might have a problem. But for how many years does my data have to stay safe? If for more than 15, you can count on the fact that no currently available key-based cryptography will be secure enough. Period. Don't count on your key to protect you from attacks over that kind of time span.
I now it's not political around here to ask, but who cares what OS it runs?
I care what OS I can manage the contents of the device from. But the thing is an appliance. The OS it runs is completely irrelevant.
The stability of the appliance matters, and that will drive some design decisions for the hardware. But linux vs. everything else will not be the consideration.
Hmm. I'm surprised you had so much trouble with Earthlink. Twice in the last few years I've been without broadband access for short periods before and after moves.
During those windows, I've signed up for Earthlink dialup access service. Both times I kept the service for less than 2 months, and both times I had no trouble disconnecting service ( 10 minutes on the phone, talking to only one person. The hold sucked, but my expectations are _so_ low...).
For what it's worth, that ease of disconnection will play heavily in my thoughts the next time I need a dialup provider. Never mind that they probably lose money on a 2-month subscriber and probably don't want that business anyway...
Beware STL implementations. Some things I've come across in the past:
Microsoft's STL implementation's std::string is thread unsafe, and you can't make it threadsafe at the application layer. Their reference counting has a race condition that can lead to memory corruption.
Certain versions of the STL that come with GCC have thread-unsafe memory allocation routines.
I strongly recommend using STLPort for cross-platform consistency, thread-safety, and standards conformance.
I think the best thing that STL has going for it is that it is a standard, you should expect it on any C++ platform. Given that, why use (and pay for) third party libraries?
STL is not easy to learn, but it is a high-value skill. I hope I've written my last list...