The best replacement for the keyboard would be a keyboard without key lock. I hate it when key lock happens. It makes me wonder why my MSX computer could have no key lock whatsoever and current PC keyboards still have trouble getting this done. I don't have the desk space nor the money to buy a keypad specifically for games, but I would happily pay 10$ extra for a keyboard without key lock.
Permanent is relative. It may be permanent compared to the time ISS will stay in space from the moment they install the node. In the end, of course, nothing is completely permanent compared to the time left to the universe - unless it disappears suddenly.
This is about US passport card. Real passports don't have an easy to read out serial number - or at least the country should have disabled the default serial number. The RFID tag (used as identification and for anti-collision with other cards) is set to random instead.
While the ECC problem is more and more analyzed, which means it is starting to be *more* reliable. Chances of a solution "falling out of the sky" are pretty low. Also, it is not said that if something like a solution is found it does not mean that key size is the important factor. It might well be that it doesn't matter or even that the problem only is specific to certain domain parameters.
Also notice that the difference between 112 bit ECC and 163 bit ECC (the NIST standard curves are 163 bit) is much larger than say a 1024 bit RSA key and a 1792 bit one as the security of the keys scales linearly instead of in a curve as with RSA.
As you rightly notice, it does not protect against any other attacks than the standard mechanism. I do think you need to read the conclusion only as relevant with their method of analysis.
Which means it is usable in case you run into problems when you are on a (very) limited device and have to implement a sorting algorithm yourself. How likely is that to happen? Only in the case where you are studying for a degree where embedded devices are used.
If it says that it doesn't understand anything about developing and we might as well regard the entire article as trash. The one difference between Eclipse is the AST which enables model-oriented programming and refactoring. This has been in there since 2.0 at least (which is when I started to use Eclipse). Of course it already had debugging abilities build in (duh). Java (with its relatively small set of keywords and complexity) and Eclipse make for a very fine development environment, imho paling MS VS. MS still does not seem to understand that adding features is not always progress.
In my live I've only seen two or three (extremely cheap) power supplies fail. All the others have outlived the systems they were originally put into. The reason seems to be that power supplies don't fail that often. A power supply that fails and brings everything down with it seems even rarer. Separate power supplies may make sense for server applications, but I don't see many reasons to surge protect the rails, because chances are there wont be anything to protect against.
Some remarks: - quantum key distro is not safe from side channel attacks, in other words, you can get around quantum cryptography as well - key management is much more important than key distribution - RSA 2048 is now considered to provide minimum security, not "high end" security - using a single key for an unbounded conversation is not safe - the key distro does not cover authentication, so some sort of authentication (e.g. asymmetric crypto) is still needed
Because it does not hold all my contacts (at my work, it doesn't even use one) Because my cellphone won't remember who I've called when using the landline Because using wires sucks (we've got VOIP, no DECT possible - that's progress to you) Because I've got a contract with a large number of minutes left Because I don't want other people to call the landline in return Because the cellphone will drain anyway
SHIFT instead of CAPS faster? That's certainly not true for me. I use it for Java constants. You can change the caps using the "clean" command within Eclipse, but I would rather have my text correctly formatted right away. Sometimes I type Java or pseudo code in normal text editors as well.
SL300 here. Cheap laptop but with 6 cell battery pack. Gets 3.5 hours with Wifi enabled and some CPU intensive stuff running now and then. Gets up to 4.5 otherwise, as advertised. It's not a netbook (heavier) and it has some slightly cheap components (compared to A-brands), but I love it.
How do YOU know that you didn't sincerely like it when you were young? The problem with tickling is is that the ticklee is not in control. If you are susceptible to tickling there's little you can do but laugh. If the tickler abuses this, it is very easy to get annoyed pretty fast. I'm not into child psychology much, but I can only presume that babies don't hate their mother because she's in control. At least I haven't got any hateful tickling memories of my years before 4 years old.
That said, I've had a pretty fun youth. And yes, tickling was a fun part of it, including the slight agitation you get with it; I'm pretty much defenseless against a good tickler even now (which my nephew of 6 of course uses to his advantage, fortunately I've got longer arms).
I'm generally a Java advocate, but you have to take into accounts when Java *is* slow. This is mostly where Java has to get down to the nitty gritty of the bare metal. Examples are cryptography (lots and lots of low level operations on bytes, 32 and 64 bit words) and processor based instructions. In those cases it makes sense to use a well defined C library (avoiding C++ if possible) and interface with that. These are also the places where it makes sense to really optimize the hell out of an application or library.
But for general business logic this arguement is indeed long gone. I do believe that my Java applications are normally faster than their C++ counterparts for the simple reason that I've got more time to design my classes well. Even if it's slower then it's offset by the much lower maintainance cost. And it's way faster than most specialized languages. Then again, specialized languages can make sense if they are delivering lower maintainance cost. Lets just say that not choosing Java because is it slower *per se* is absolutely wrong.
With C++ there is always a way to get (around) a feature. The trick is to let these tricks play nice with the rest of your pogram including the used libraries and different runtime environments.
Amazingly boring? Jeez, there is a lot of ways of doing garbage collection. You can mix GC types, have multiple levels of GC, heap sizes to tweak for these levels etc. Java has got an upper limit to the amount of memory the process uses, but I can think of other schemes that dont. Then you can do a lot of multithreading stuff, but you cannot break code anytime, because in that case the whole VM can die unexpectedly. Then you have to choose when and how long to garbage collect, if you only do so if CPU utilization is high or low. Weak references and such can also play a role etc.
If it's really boring to people they aren't trying hard enough.
The first one is about the Wako Siege, which even all the more informed people here in the Netherlands will remember. It was interesting reading up on it again. I can remember browsing the few US news channels for it when the news was fresh. IMHO, the only reason to leave this little piece of information out was to obscure the fact that people actually do know about this incident. Also, blandly claiming that the lives of these people were all taken by the FBI is taking it way too far.
For me that's enough of a troll to not look at the others.
What kind of application are you running? Niagara is designed for application servers with many connections. Hence the build in ethernet and crypto support and adequate memory support. It's foolish to run anything on it that does not have multiple threads yes, and it's single thread performance is low (unless you are using the cryptographic coprocessor of course). I've torched the use of Niagara processors in my company for a specific application server as well; it was used to receive large XML data sets from a particular client and calculate large data sets. Yes, it's was an application server, but since there was only one client, it would have seriously added to the latency - buying a cheaper Xeon based system was both cheaper and more flexible. It hurt me a bit though, I would have loved playing around with one of these machines. Maybe next time, we've got some applications coming that require a large database with many distributed accesses; it will rock for that application.
Niagara is build with one thing in mind: handling multiple connections well (preferably using SSL or other forms of crypto), where those connections themselves don't require oodles of CPU. Check out the benchmarks for those applications and Niagara should fare pretty well, especially in operating costs.
Slashdot Mirror
The best replacement for the keyboard would be a keyboard without key lock. I hate it when key lock happens. It makes me wonder why my MSX computer could have no key lock whatsoever and current PC keyboards still have trouble getting this done. I don't have the desk space nor the money to buy a keypad specifically for games, but I would happily pay 10$ extra for a keyboard without key lock.
Yep, I've already got a stack of thousands rolls of toilet paper stacked up here, just in case.
By swearing and trying other spam filters mostly :)
Astronauts finally don't have to use that shaky GPRS on their iPhones. I've heard the reception is really bad over there.
Permanent is relative. It may be permanent compared to the time ISS will stay in space from the moment they install the node. In the end, of course, nothing is completely permanent compared to the time left to the universe - unless it disappears suddenly.
This is about US passport card. Real passports don't have an easy to read out serial number - or at least the country should have disabled the default serial number. The RFID tag (used as identification and for anti-collision with other cards) is set to random instead.
Also notice that the difference between 112 bit ECC and 163 bit ECC (the NIST standard curves are 163 bit) is much larger than say a 1024 bit RSA key and a 1792 bit one as the security of the keys scales linearly instead of in a curve as with RSA.
As you rightly notice, it does not protect against any other attacks than the standard mechanism. I do think you need to read the conclusion only as relevant with their method of analysis.
Python instead of Java? No way. Not until the language and tool support gets oodles better than it is now.
Which means it is usable in case you run into problems when you are on a (very) limited device and have to implement a sorting algorithm yourself. How likely is that to happen? Only in the case where you are studying for a degree where embedded devices are used.
If it says that it doesn't understand anything about developing and we might as well regard the entire article as trash. The one difference between Eclipse is the AST which enables model-oriented programming and refactoring. This has been in there since 2.0 at least (which is when I started to use Eclipse). Of course it already had debugging abilities build in (duh). Java (with its relatively small set of keywords and complexity) and Eclipse make for a very fine development environment, imho paling MS VS. MS still does not seem to understand that adding features is not always progress.
In my live I've only seen two or three (extremely cheap) power supplies fail. All the others have outlived the systems they were originally put into. The reason seems to be that power supplies don't fail that often. A power supply that fails and brings everything down with it seems even rarer. Separate power supplies may make sense for server applications, but I don't see many reasons to surge protect the rails, because chances are there wont be anything to protect against.
Some remarks:
- quantum key distro is not safe from side channel attacks, in other words, you can get around quantum cryptography as well
- key management is much more important than key distribution
- RSA 2048 is now considered to provide minimum security, not "high end" security
- using a single key for an unbounded conversation is not safe
- the key distro does not cover authentication, so some sort of authentication (e.g. asymmetric crypto) is still needed
Why is this flamebait? Is it wrong? I can see an "Inside deep throat" documentary, maybe there's one named "deep throat" as well.
- cycle and/or walk to your (new) job
Why not use the landline?
Because it does not hold all my contacts (at my work, it doesn't even use one)
Because my cellphone won't remember who I've called when using the landline
Because using wires sucks (we've got VOIP, no DECT possible - that's progress to you)
Because I've got a contract with a large number of minutes left
Because I don't want other people to call the landline in return
Because the cellphone will drain anyway
Mod parent up, it is one of my main pet peeves of my thinkpad, although I am able to even get accustomed to that stupid layout, apparently.
SHIFT instead of CAPS faster? That's certainly not true for me. I use it for Java constants. You can change the caps using the "clean" command within Eclipse, but I would rather have my text correctly formatted right away. Sometimes I type Java or pseudo code in normal text editors as well.
SL300 here. Cheap laptop but with 6 cell battery pack. Gets 3.5 hours with Wifi enabled and some CPU intensive stuff running now and then. Gets up to 4.5 otherwise, as advertised. It's not a netbook (heavier) and it has some slightly cheap components (compared to A-brands), but I love it.
IMHO it's not as much as an echo chamber as a minority viewpoint. Most people don't care (period). They've got other things to worry about.
How do YOU know that you didn't sincerely like it when you were young? The problem with tickling is is that the ticklee is not in control. If you are susceptible to tickling there's little you can do but laugh. If the tickler abuses this, it is very easy to get annoyed pretty fast. I'm not into child psychology much, but I can only presume that babies don't hate their mother because she's in control. At least I haven't got any hateful tickling memories of my years before 4 years old.
That said, I've had a pretty fun youth. And yes, tickling was a fun part of it, including the slight agitation you get with it; I'm pretty much defenseless against a good tickler even now (which my nephew of 6 of course uses to his advantage, fortunately I've got longer arms).
1) Java is slow.
I'm generally a Java advocate, but you have to take into accounts when Java *is* slow. This is mostly where Java has to get down to the nitty gritty of the bare metal. Examples are cryptography (lots and lots of low level operations on bytes, 32 and 64 bit words) and processor based instructions. In those cases it makes sense to use a well defined C library (avoiding C++ if possible) and interface with that. These are also the places where it makes sense to really optimize the hell out of an application or library.
But for general business logic this arguement is indeed long gone. I do believe that my Java applications are normally faster than their C++ counterparts for the simple reason that I've got more time to design my classes well. Even if it's slower then it's offset by the much lower maintainance cost. And it's way faster than most specialized languages. Then again, specialized languages can make sense if they are delivering lower maintainance cost. Lets just say that not choosing Java because is it slower *per se* is absolutely wrong.
With C++ there is always a way to get (around) a feature. The trick is to let these tricks play nice with the rest of your pogram including the used libraries and different runtime environments.
Amazingly boring? Jeez, there is a lot of ways of doing garbage collection. You can mix GC types, have multiple levels of GC, heap sizes to tweak for these levels etc. Java has got an upper limit to the amount of memory the process uses, but I can think of other schemes that dont. Then you can do a lot of multithreading stuff, but you cannot break code anytime, because in that case the whole VM can die unexpectedly. Then you have to choose when and how long to garbage collect, if you only do so if CPU utilization is high or low. Weak references and such can also play a role etc.
If it's really boring to people they aren't trying hard enough.
The first one is about the Wako Siege, which even all the more informed people here in the Netherlands will remember. It was interesting reading up on it again. I can remember browsing the few US news channels for it when the news was fresh. IMHO, the only reason to leave this little piece of information out was to obscure the fact that people actually do know about this incident. Also, blandly claiming that the lives of these people were all taken by the FBI is taking it way too far.
For me that's enough of a troll to not look at the others.
What kind of application are you running? Niagara is designed for application servers with many connections. Hence the build in ethernet and crypto support and adequate memory support. It's foolish to run anything on it that does not have multiple threads yes, and it's single thread performance is low (unless you are using the cryptographic coprocessor of course). I've torched the use of Niagara processors in my company for a specific application server as well; it was used to receive large XML data sets from a particular client and calculate large data sets. Yes, it's was an application server, but since there was only one client, it would have seriously added to the latency - buying a cheaper Xeon based system was both cheaper and more flexible. It hurt me a bit though, I would have loved playing around with one of these machines. Maybe next time, we've got some applications coming that require a large database with many distributed accesses; it will rock for that application.
Niagara is build with one thing in mind: handling multiple connections well (preferably using SSL or other forms of crypto), where those connections themselves don't require oodles of CPU. Check out the benchmarks for those applications and Niagara should fare pretty well, especially in operating costs.