True enough. I did have to type it from my head on the internet PC (ugh):). On my development environment, it's automatically inserted. You forgot one thing I forgot as well. If there are any exceptions thrown before the variable is initialized, it does not hurt to check for a null reference either. Oh well, better take it from a book or an internet reference somewhere.
Those kind of cars are pretty much used by joy-drivers and sometimes by homeless people to sleep in (and sometimes to do more than just sleep). I've got two friends whose old cars were stolen and used by joy-riders (without the use of keys). And one whose expensive merc was stolen by a joy rider using the keys stolen from his house (actually, he was featured on slashdot). The merc was pretty damaged, the two other cars were total-loss (though you could buy ~ 10 old cars to fix the merc).
So just having an old car does not keep you from harm.
"All encryption (that I know of) use mathematical problems that just take a long time to solve."
One time pad. Unbreakable. Useless because of the danger of repeats? Just encrypt a challenge with a random number stored in your car and on a cheap 128 MB memory stick, in order. Only other thing is something to keep track and something to XOR. Of course, there should be a way for the dealer to break in as well.
"In essence, all crypto algorithms are security through obscurity."
Nope. The term security through obscurity is about hiding the scheme, not so much as the keys. It can help a bit, but for professional thieves, it only takes one person to bribe. The keys should be the only things you should have to guess.
"The long promised quantum computing can supposedly squash all known crypto algorithms due to its speed and ability to solve these problems. Thus, problems will have to be created that take quantum computers a long time to solve."
AES-256, and some other AES contestants with the same key sizes, are probably resistant against an attack by quantum computers. Random pads are resistant by their very nature (as you noted). There is just no way of checking that a message you find is indeed the one you are looking for.
"The only "advances" in crypto is finding harder and harder problems to solve. That's it. That's cryptography."
Well, the problems should be usable in the right context, provable secure (if possible), use maintainable key sizes and then there are things as key generation, random number generation, time keeping, distribution, using correct protocols (paddings, session counters etc)... But yes, essentially hard problems are the *base* of cryptography:)
"The *only* algo that I know of that doesn't rely on mathematical properties like factorization is the one-time pad."
Well, only if you take factorization in a *very* broad context. Symetric ciphers are pretty different from asymetric ones. You may as well include the XOR function used for one time pads as well.
"So it's not a weakness in public/private key, per se, but in crypto in general."
No. There are scheme's possible with *much* better protection. Most of these scheme's are so bad (or, to be more precise, *cheap*) that cryptoanalysis and breaking the algorithm can be done by anyone that can be bothered to look hard enough.
"(IANA cryptographer, but that's my understanding of it all and I more than welcome any corrections.)"
I am a practicing cryptographer. I've analized protocols and even created - or better, changed - some for special uses. So I understand the basic premisses and uses of cryptography. I hope you can do something with my "corrections". Try wikipedia or practical cryptography from Bruce Schneier for more information (his monthly newsletter is also an eye opener).
A real casino? No way. I don't play any games online (anymore), but I know that I would find casino games terribly *boring* in relation to online role playing games. Of course, if you look at the online casino's, many other people think different.
I've been sick and tired of these "simple examples". I don't care if you can do such a thing with less characters. What I do care about is readability and robustness for larger applications.
I've been programming Java for some time now, and even in Java it is possible to write ugly code. That said, most of my C++ colleagues have no trouble at all reading my code, or understand the error messages (nicely including a stack trace even on the production platform). They always create applications that get stuck "for some reason or other" or generate very helpfull general protection errors. And I am always guessing what it does.
Sometimes I hate Java for trying to get too complicated as well, but in the end you are left with robust code. The only thing I really hate is the exception handling. Then again, if you let all your methods throw a general exception, you can forget about all that required exception handling. Of course, just like those languages, if anything goes wrong you are probably in a tight spot.
final INFILE = "foo.in"; try {
final FileReader fileReader = new FileReader(INFILE);
final BufferedReader in = new BufferedReader(fileReader);//... do stuff here... } catch(IOException e) {
throw new IOException(String.format("Could not open %s", INFILE)); } finally {
try { fileReader.close() } catch(IOException e) {/* OK, we cannot close the file */ } }
Sounds complicated? Look at the messages you get from C++ if anything goes wrong. Most of the people I know do not even use the STL because of the level of understanding you need to use that. Anyway, try and use any language and you will find things are not as easy as they seem. If you think that new BufferedReader(new FileReader("foo.in")); is complicated: well, think again.
"Of course, any equivalent app in Java would have more lines of opaque XML configuration than the "POS LAMP application" has code. It will also be slower, eat several times as much memory, and depend on specific versions of two dozen frameworks."
Opaque XML configuration? Most of the time you only see opaque XML configuration if you are a) creating something out of the ordinary and b) not using a tool to generate the XML configuration. And even then it depends on your framework. And I've never seen an implementation rely on more than one framework for equivalent functionality.
Calling Eclipse bloatware completely makes your argument moot. For it's functionality, you could even call it sleek. I've tried ruby, and after trying that, I went crying back to Java. IMHO, ruby is currently the buzz, but it will never replace something as robust as a Java enterprise app. I don't see many corporations switching to ruby either (even though these people are generally slow switchers). Maybe for single web-developers, but for teams...
Lisp has been around for long. So long that I cannot see it gain much market dominance (for web applications) at this day and age.
Hmm, I currently use Java command line tools for multiple applications. Although you would notice slight speed downs if you use these applications in a loop, performance is not an issue at all. Some GUI's took some time to speed up, although even that has improved a lot for the last couple of years.
With the default classes nicely compiled and cached, a lot of performance improvements have been made in 1.5. With 1.6, there is a new VM for x86 architectures that is better in utilizing registers. There is also a new, much more advanced verifier underway (Java has build in security, takes some time and memory as well). I've seen performance improvements of about 40%.
Still, I would applaud an Open Source JVM, as long as Sun is able to provide a nice, consistent platform to work with. This will allow others to improve the VM and build in some interesting features. Previously, I was very afraid that there would be too many splits from the platform, but the JVM is so established nowadays that that should hardly be an issue anymore. Especially now MS has disappeared from the Java radar.
Of course, third party JVM's have been around since - well - forever?
Azureus already uses SWT as underlying library, so this argument is a bit moot. SWT *is* using the underlying Windows functions for drawing. Nevertheless, Java will always use some more memory than a comparative (well written) C++ program, due to the class meta information that is included. You get a lot back in readability and in descriptive error messages, and several runtime advantages because of reflection (e.g. plugins). You need C# with.NET to get the same in a Windows only environment, and I wonder if such a program compares favourably.
No, since the disk, while in use, would be on all the time. It does not go from spinning to non-spinning within the second or something like that. Maybe there is a small difference because of the head moving or not moving, but that's about it.
Due to higher density disks, the throughput had advanced quite a lot faster than just the rotating speed. So what you are saying is - to be honest - a load of bunk.
Wouldn't it be easier to do the cooling on the chip and use something that conducts heat very good on the chip? I mean, I would rather have lanes of some conductive, non moving material instead of some liquid running through my CPU, if you don't mind.
Yeah, I agree with all that, but it's just a warning that people should not use too simple passwords on things that can be brute forced. You're better off generating a stronger password for such uses. I've created some scripts myself (in Java) to generate passwords. It is pretty amazing sometimes which scheme's generate passwords with more or less entropy. Fortunately, there are quite a lot consonants in your scheme. Schemes with many vowels will be much less effective.
Be warned that there are about 37 bits of entropy in the passwords generated by this program. A completely random pattern of 8 characters will normally generate over 50 bits of entropy (if you include special characters). It's a good idea to take some measures against checking too many passwords per second anyway, but 37 bits may be a bit too little. And if you let the users use the application directly, they may change passwords until they find an easy to use one (which may be more easy to crack).
Hey, all of you, I was noting that I did not find his examples very good. That's why I posted. If your arguments can be easily rebuked, they don't have much use. Obviously you are all correct in noting that it would be pretty hard for a writer to earn a living that way, unless he was a great narator;) Allthough some of them might be able to live pretty decently on signing sessions alone.
"1280x768 , is that some kind of ultra ultra wide screen ?:p"
Well, obviously it is 1280:768, or after division by 256, 5:3, or 15:9. So it is almost regular wide screen as in 16:9. Does not seem overly wide to me. But don't take this from me, this is typed on a screen with 16:10 resolution.
By the way, there is such a thing as a SHIFT key. You can find two rather largish keys on both sides of the alphanumeric part of most keyboards. Try and use them once in a while before posting something completely uninteresting.
"Let's say I write THE song of the century and go on tour as "The Opportunist". Now, Phony Records puts up some studio gang and has them go on tour as "The REAL Opportunists", puts a load of hype behind it, slanders me and makes sure that everyone believes that I'm the imposter. The only thing I could do is write statements myself, trying to tell the truth (Prior art? Original artist? Doesn't matter without copyrights)."
If the original opportunist was any good, there would not be much of a problem. Furthermore, this is a bit of a movie scenario, which I don't think very likely in the real world. There would be a problem though: the artists that don't do live appearences would lose a lot. Not that I would mind that too much, there a very few artists I like that are no good at live performances.
"Next scenario: Software. Without copyrights, what would keep MS from taking Linux and running with it? Stuff their marketing and GUI guys behind it, create a flashy and squeaky colorful GUI for it, then "embrace and extend" until it's no longer compatible with ordinary Linux. Oh, it is, but it has "additional features" that people will enjoy and use, thus making sure that it's not really compatible with the old stuff anymore."
You mean like Apple did with BSD? BSD is obviously dead as a can of spam now.
I don't mind your argument. I would even go as far as support it. But I do think these examples are "out of balance". Maybe even "Completely":)
Bwah, I've never believed too much of the idea that these artists are that much against file sharing themselves. I would not be surprised if it is a simple ploy by the music industry: get the big players to say it and the cattle will listen. Unfortunately for them, the cattle does not listen and some artists are actually promoting file sharing as well.
All that said, there is Paul McCartney proposing to extend copyright to over 90 years. A BBC-world talking head commented (in complete dead serious voice) that artists were afraid they would not "have bread on the table" if copyright was not extended. But maybe this was also influenced by the music industry.
Obviously, all this money is needed to promote new artists...
I've got a GX270 at work, and I heard from the engeneer that came to replace the motherboard that 7/10 of these motherboards will give out during their lifetime due to shoddy capacitors. We've also got some expensive Lattitude laptops, but the batteries and the power supplies are always giving out. These (somewhat older) laptops are not top of the class in design either. They are heavy, short battery life, keyboard/touchpad problems, keys press into the screen etc. Fortunately, the hard drives they use seem to be fine. But to say that they aren't error prone...
I think big was about the size of the project, not about the size of the failure. And I don't doubt that Bill thinks that the advantages by far outweighed the disadvantages. He probably won't admit the opposite to her anyway:)
Of course, these things are NOT seen as three different monitors. This means that you have to have support from the game to put the side views on the single monitor. I doubt many flight sims are capable of that, although there are so many add-ins for MS flight sim that this may just be that one exception.
Uh, I just bought a 600 euro screen from Dell that does 1680x1050. I prefer it over the two 17" screens at work because of video and games - also my development environment still works better on just one screen instead of two (even though it IS optimized for two screens). You cannot split lines of text over two screens, it's that simple. All this said, I really don't see this having to much to do on this topic, so we'll probably be modded down:)
This means that the thing is useless to me. I do not look at my two screens at work as one single screen. I see them as two seperate screens. If I put an application on one screen, I expect it to open on that screen. If I maximize a window, I expect it to maximize on one monitor, not over two monitors. I don't want to see the task bar stretched over the whole two screens (ok, with KDE/Gnome this is no problem). I don't want new applications to be centered on the screen. Well, you catch my drift by now. Maybe for some applicications this is no problem, but for many others, it is.
Slashdot Mirror
Ah, ok. There are so many people that state things like that - for real - that my auto-defense mechanisms were triggered.
True enough. I did have to type it from my head on the internet PC (ugh) :). On my development environment, it's automatically inserted. You forgot one thing I forgot as well. If there are any exceptions thrown before the variable is initialized, it does not hurt to check for a null reference either. Oh well, better take it from a book or an internet reference somewhere.
Those kind of cars are pretty much used by joy-drivers and sometimes by homeless people to sleep in (and sometimes to do more than just sleep). I've got two friends whose old cars were stolen and used by joy-riders (without the use of keys). And one whose expensive merc was stolen by a joy rider using the keys stolen from his house (actually, he was featured on slashdot). The merc was pretty damaged, the two other cars were total-loss (though you could buy ~ 10 old cars to fix the merc).
So just having an old car does not keep you from harm.
"All encryption (that I know of) use mathematical problems that just take a long time to solve."
:)
One time pad. Unbreakable. Useless because of the danger of repeats? Just encrypt a challenge with a random number stored in your car and on a cheap 128 MB memory stick, in order. Only other thing is something to keep track and something to XOR. Of course, there should be a way for the dealer to break in as well.
"In essence, all crypto algorithms are security through obscurity."
Nope. The term security through obscurity is about hiding the scheme, not so much as the keys. It can help a bit, but for professional thieves, it only takes one person to bribe. The keys should be the only things you should have to guess.
"The long promised quantum computing can supposedly squash all known crypto algorithms due to its speed and ability to solve these problems. Thus, problems will have to be created that take quantum computers a long time to solve."
AES-256, and some other AES contestants with the same key sizes, are probably resistant against an attack by quantum computers. Random pads are resistant by their very nature (as you noted). There is just no way of checking that a message you find is indeed the one you are looking for.
"The only "advances" in crypto is finding harder and harder problems to solve. That's it. That's cryptography."
Well, the problems should be usable in the right context, provable secure (if possible), use maintainable key sizes and then there are things as key generation, random number generation, time keeping, distribution, using correct protocols (paddings, session counters etc)... But yes, essentially hard problems are the *base* of cryptography
"The *only* algo that I know of that doesn't rely on mathematical properties like factorization is the one-time pad."
Well, only if you take factorization in a *very* broad context. Symetric ciphers are pretty different from asymetric ones. You may as well include the XOR function used for one time pads as well.
"So it's not a weakness in public/private key, per se, but in crypto in general."
No. There are scheme's possible with *much* better protection. Most of these scheme's are so bad (or, to be more precise, *cheap*) that cryptoanalysis and breaking the algorithm can be done by anyone that can be bothered to look hard enough.
"(IANA cryptographer, but that's my understanding of it all and I more than welcome any corrections.)"
I am a practicing cryptographer. I've analized protocols and even created - or better, changed - some for special uses. So I understand the basic premisses and uses of cryptography. I hope you can do something with my "corrections". Try wikipedia or practical cryptography from Bruce Schneier for more information (his monthly newsletter is also an eye opener).
A real casino? No way. I don't play any games online (anymore), but I know that I would find casino games terribly *boring* in relation to online role playing games. Of course, if you look at the online casino's, many other people think different.
I've been sick and tired of these "simple examples". I don't care if you can do such a thing with less characters. What I do care about is readability and robustness for larger applications.
// ... do stuff here ... /* OK, we cannot close the file */ }
I've been programming Java for some time now, and even in Java it is possible to write ugly code. That said, most of my C++ colleagues have no trouble at all reading my code, or understand the error messages (nicely including a stack trace even on the production platform). They always create applications that get stuck "for some reason or other" or generate very helpfull general protection errors. And I am always guessing what it does.
Sometimes I hate Java for trying to get too complicated as well, but in the end you are left with robust code. The only thing I really hate is the exception handling. Then again, if you let all your methods throw a general exception, you can forget about all that required exception handling. Of course, just like those languages, if anything goes wrong you are probably in a tight spot.
final INFILE = "foo.in";
try {
final FileReader fileReader = new FileReader(INFILE);
final BufferedReader in = new BufferedReader(fileReader);
} catch(IOException e) {
throw new IOException(String.format("Could not open %s", INFILE));
} finally {
try { fileReader.close() } catch(IOException e) {
}
Sounds complicated? Look at the messages you get from C++ if anything goes wrong. Most of the people I know do not even use the STL because of the level of understanding you need to use that. Anyway, try and use any language and you will find things are not as easy as they seem. If you think that new BufferedReader(new FileReader("foo.in")); is complicated: well, think again.
"Of course, any equivalent app in Java would have more lines of opaque XML configuration than the "POS LAMP application" has code. It will also be slower, eat several times as much memory, and depend on specific versions of two dozen frameworks."
Opaque XML configuration? Most of the time you only see opaque XML configuration if you are a) creating something out of the ordinary and b) not using a tool to generate the XML configuration. And even then it depends on your framework. And I've never seen an implementation rely on more than one framework for equivalent functionality.
Calling Eclipse bloatware completely makes your argument moot. For it's functionality, you could even call it sleek. I've tried ruby, and after trying that, I went crying back to Java. IMHO, ruby is currently the buzz, but it will never replace something as robust as a Java enterprise app. I don't see many corporations switching to ruby either (even though these people are generally slow switchers). Maybe for single web-developers, but for teams...
Lisp has been around for long. So long that I cannot see it gain much market dominance (for web applications) at this day and age.
Hmm, I currently use Java command line tools for multiple applications. Although you would notice slight speed downs if you use these applications in a loop, performance is not an issue at all. Some GUI's took some time to speed up, although even that has improved a lot for the last couple of years.
_ machines
With the default classes nicely compiled and cached, a lot of performance improvements have been made in 1.5. With 1.6, there is a new VM for x86 architectures that is better in utilizing registers. There is also a new, much more advanced verifier underway (Java has build in security, takes some time and memory as well). I've seen performance improvements of about 40%.
Still, I would applaud an Open Source JVM, as long as Sun is able to provide a nice, consistent platform to work with. This will allow others to improve the VM and build in some interesting features. Previously, I was very afraid that there would be too many splits from the platform, but the JVM is so established nowadays that that should hardly be an issue anymore. Especially now MS has disappeared from the Java radar.
Of course, third party JVM's have been around since - well - forever?
http://en.wikipedia.org/wiki/List_of_Java_virtual
Azureus already uses SWT as underlying library, so this argument is a bit moot. SWT *is* using the underlying Windows functions for drawing. Nevertheless, Java will always use some more memory than a comparative (well written) C++ program, due to the class meta information that is included. You get a lot back in readability and in descriptive error messages, and several runtime advantages because of reflection (e.g. plugins). You need C# with .NET to get the same in a Windows only environment, and I wonder if such a program compares favourably.
No, since the disk, while in use, would be on all the time. It does not go from spinning to non-spinning within the second or something like that. Maybe there is a small difference because of the head moving or not moving, but that's about it.
Due to higher density disks, the throughput had advanced quite a lot faster than just the rotating speed. So what you are saying is - to be honest - a load of bunk.
Wouldn't it be easier to do the cooling on the chip and use something that conducts heat very good on the chip? I mean, I would rather have lanes of some conductive, non moving material instead of some liquid running through my CPU, if you don't mind.
Yeah, I agree with all that, but it's just a warning that people should not use too simple passwords on things that can be brute forced. You're better off generating a stronger password for such uses. I've created some scripts myself (in Java) to generate passwords. It is pretty amazing sometimes which scheme's generate passwords with more or less entropy. Fortunately, there are quite a lot consonants in your scheme. Schemes with many vowels will be much less effective.
Be warned that there are about 37 bits of entropy in the passwords generated by this program. A completely random pattern of 8 characters will normally generate over 50 bits of entropy (if you include special characters). It's a good idea to take some measures against checking too many passwords per second anyway, but 37 bits may be a bit too little. And if you let the users use the application directly, they may change passwords until they find an easy to use one (which may be more easy to crack).
Hey, all of you, I was noting that I did not find his examples very good. That's why I posted. If your arguments can be easily rebuked, they don't have much use. Obviously you are all correct in noting that it would be pretty hard for a writer to earn a living that way, unless he was a great narator ;) Allthough some of them might be able to live pretty decently on signing sessions alone.
"1280x768 , is that some kind of ultra ultra wide screen ? :p"
Well, obviously it is 1280:768, or after division by 256, 5:3, or 15:9. So it is almost regular wide screen as in 16:9. Does not seem overly wide to me. But don't take this from me, this is typed on a screen with 16:10 resolution.
By the way, there is such a thing as a SHIFT key. You can find two rather largish keys on both sides of the alphanumeric part of most keyboards. Try and use them once in a while before posting something completely uninteresting.
Please do not make jokes about cancer like that. Cancer is not in the slightest way funny.
"Let's say I write THE song of the century and go on tour as "The Opportunist". Now, Phony Records puts up some studio gang and has them go on tour as "The REAL Opportunists", puts a load of hype behind it, slanders me and makes sure that everyone believes that I'm the imposter. The only thing I could do is write statements myself, trying to tell the truth (Prior art? Original artist? Doesn't matter without copyrights)."
:)
If the original opportunist was any good, there would not be much of a problem. Furthermore, this is a bit of a movie scenario, which I don't think very likely in the real world. There would be a problem though: the artists that don't do live appearences would lose a lot. Not that I would mind that too much, there a very few artists I like that are no good at live performances.
"Next scenario: Software. Without copyrights, what would keep MS from taking Linux and running with it? Stuff their marketing and GUI guys behind it, create a flashy and squeaky colorful GUI for it, then "embrace and extend" until it's no longer compatible with ordinary Linux. Oh, it is, but it has "additional features" that people will enjoy and use, thus making sure that it's not really compatible with the old stuff anymore."
You mean like Apple did with BSD? BSD is obviously dead as a can of spam now.
I don't mind your argument. I would even go as far as support it. But I do think these examples are "out of balance". Maybe even "Completely"
Bwah, I've never believed too much of the idea that these artists are that much against file sharing themselves. I would not be surprised if it is a simple ploy by the music industry: get the big players to say it and the cattle will listen. Unfortunately for them, the cattle does not listen and some artists are actually promoting file sharing as well.
All that said, there is Paul McCartney proposing to extend copyright to over 90 years. A BBC-world talking head commented (in complete dead serious voice) that artists were afraid they would not "have bread on the table" if copyright was not extended. But maybe this was also influenced by the music industry.
Obviously, all this money is needed to promote new artists...
I've got a GX270 at work, and I heard from the engeneer that came to replace the motherboard that 7/10 of these motherboards will give out during their lifetime due to shoddy capacitors. We've also got some expensive Lattitude laptops, but the batteries and the power supplies are always giving out. These (somewhat older) laptops are not top of the class in design either. They are heavy, short battery life, keyboard/touchpad problems, keys press into the screen etc. Fortunately, the hard drives they use seem to be fine. But to say that they aren't error prone...
Yes, with "Ludwig van" music playing all the time.
I think big was about the size of the project, not about the size of the failure. And I don't doubt that Bill thinks that the advantages by far outweighed the disadvantages. He probably won't admit the opposite to her anyway :)
Of course, these things are NOT seen as three different monitors. This means that you have to have support from the game to put the side views on the single monitor. I doubt many flight sims are capable of that, although there are so many add-ins for MS flight sim that this may just be that one exception.
Uh, I just bought a 600 euro screen from Dell that does 1680x1050. I prefer it over the two 17" screens at work because of video and games - also my development environment still works better on just one screen instead of two (even though it IS optimized for two screens). You cannot split lines of text over two screens, it's that simple. All this said, I really don't see this having to much to do on this topic, so we'll probably be modded down :)
This means that the thing is useless to me. I do not look at my two screens at work as one single screen. I see them as two seperate screens. If I put an application on one screen, I expect it to open on that screen. If I maximize a window, I expect it to maximize on one monitor, not over two monitors. I don't want to see the task bar stretched over the whole two screens (ok, with KDE/Gnome this is no problem). I don't want new applications to be centered on the screen. Well, you catch my drift by now. Maybe for some applicications this is no problem, but for many others, it is.