Your parents don't want you to play violent video games? Buy it with allowance money and play it when they're not around, or go to a friend's house and play it.
And when you find out your kids do that, you can (for some effective amount of time):
stop giving them an allowance,
stop letting them go to the friend's house
hire a babysitter (yes, even for teenagers...)
If your children know they can fight with you and win, you have failed as a parent. Period.
Your job is to convince your kids that they don't want to play those games. The threat of corporeal punishment is an effective way to do this for younger children -- with older children, a combination of reasoning and taking away privileges can be more effective. You can choose to turn a blind eye to certain behaviours, but once you confront your children, you must not lose.
Or, perhaps more importantly, it's your job as a parent to teach your kids, as early as possible, the difference between fact and fiction. Then, when your kids eventually *do* play these games (or watch "that" movie, or read "that" book, or are targeted for recruitment by "that" cult, etc) they will be immune to being influenced by them.
The type of person who blasts multiple sites with automated software isn't likely to spend time building up karma on (multiple) Slashdot accounts for his SpamBot to burn.
Mathematicians try to prove conjectures (thereby making them into theorems) by connecting them logically to a set of other theorems and ultimately to a small set of reasonable assumptions. Also, lawyers try to "prove" (establish) statements of fact.
Scientists, on the other hand, build theories that correspond to existing data. Then, they make predictions ("hypotheses") based on the new theories, and collect additional data. The data itself will either support or refute the theories, or it will do neither.
Regardless, science does not "prove" things with absolute certainty.
It's quite possible that most of the GPL-nitpicking that goes on around here is irrelevant because the judge would find no financial harm and tell the FSF to sod off.
Such as every version of Perl before 6? FSF does not consider the Artistic Licence 1.x to be "free", while 2.0 is.
Hmm. That's an interesting observation. My understanding is that the FSF doesn't so much consider the original Artistic Licence as being non-free in principle, just too vague to be considered free with certainty.
However, Debian's perl-base 5.8.8-4 package says this in its copyright file:
Copyright 1989-2001, Larry Wall All rights reserved.
This program is free software; you can redistribute it and/or modify it under the terms of either:
a) the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version, or
b) the "Artistic License" which comes with Perl.
I doubt that RMS would consider that non-free.:)
However I do feel that uncompromising groups have something to add to society, by maintaining balance against forces pulling in the opposite direction (FSF, ACLU, etc). Thus I try not to misrepresent their interpretations.
As an interesting coincidence, I was reading an article by Marcus J. Ranum today, entitled The Monoculture Hype. Among other things, Marcus criticises bad analogies:
Analogies are dangerous verbal tools. Basically, they treat the listener as a patsy by presenting a carefully constructed world-view that is tailored to explain and prove the analogist's point, while omitting everything that would argue against it. While the concept of "monoculture" is an attractive analogy for a security problem, it ignores the simple truth that we could just as easily talk about the actual problem in its real context without resorting to cute analogies. For example, if you take the CCIA paper and rewrite it into a pure computer security conceptual framework, I think the authors' argument might read something like: "Microsoft's products suck; they are insecure. Everyone keeps buying Microsoft's products anyhow, which makes the situation worse rather than better. There is a very real danger that if everything relied on sucky products then we'd all be vulnerable all the time and some cataclysmic software chernobyl is more likely to happen." It happens I agree with that statement. But if you avoid the analogies and pseudoscience and pose the problem in the terms I did above, then you've avoided intellectually painting yourself into a corner and you can ask the interesting questions such as: "how can we reduce the suckiness?" "are we applying the wrong market forces?" "what alternatives are better?" etc. In fact, these questions are so obvious (and profound) that asking them around most seasoned security experts will generate a tired "well, DUH!" as a response. I think, honestly, that the CCIA authors' reliance on analogy helped them catapult a "well, DUH!" anti-Microsoft whine into a major whitepaper. Professionally it's good for them, but for the industry, intellectual honesty is better in the long run.
Also, a lot of accountants who have very specific roles tend to use Excel as their calendar tool, as their scheduling tool, basically as their desktop.
[Please mod my previous reply down. It's botched.]
There is some information about the algorithms they're using here. That page says that they're using 1024-bit DH to negotiate a 128-bit AES key, then they XOR the output of the AES algorithm with the voice data.
Frankly, I don't trust it.
First of all, neither 1024-bit DH nor 128-bit AES actually give you 128-bit security (i.e. 2^128 complexity). For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about Diffie-Hellman, but it's similar in structure to RSA, and experts have been recommending at least 2048-bit keys for new designs using RSA for years, and that's not even to get a 128-bit security level. For a true 128-bit security level, you need something like 6100 bits (if I remember correctly), which most people don't use because it's very slow to do in software.
The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single repeating AES ciphertext block with the entire plaintext datastream, which would be trivially insecure. We really have no way of knowing.
Additional security and integrity is ensured by a calculated HASH
checksum that is indicated on the display.
There is no mention of what hash function is being used, nor of what is being hashed. Furthermore, people who talk about "HASH" -- in all-caps, as if HASH is an algorithm itself -- clearly don't know what they're doing. It might just be Vecrotel's marketing department messing things up. Or, it could be a more fundamental lack of expertise within the company. Who knows?
VECTROTEL IS BASED ON WHICH SW PLATFORM? IS THERE A SECURITY RISK?
The software is proprietary. There is no security risk.
...
KNOWING AND CHECKING THE SOURCE CODE IS VERY IMPORTANT. IS EVERYBODY ABLE TO REVIEW THIS SOURCE CODE?
No, we do not release the source code. Too much know-how would be at stake.
Totally unacceptable.
If those really are "frequently-asked questions", those responses are simply arrogant. The company has clearly adopted a "trust us" mentality. If I was willing to blindly trust other companies, I wouldn't be looking for a secure phone!
Crypto products are like voting machines. If their operation is not independently verifiable, then they simply cannot be trusted.
As an interesting side note, I don't see any FIPS certifications.
There is some information here. It says that they're using 1024-bit DH to negotiate a 128-bit AES key, then they XOR the output of the AES algorithm with the voice data.
The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single AES ciphertext block with the entire plaintext datastream. We really have no way of knowing.
VECTROTEL IS BASED ON WHICH SW PLATFORM? IS THERE A SECURITY RISK?
The software is proprietary. There is no security risk.
...
KNOWING AND CHECKING THE SOURCE CODE IS VERY IMPORTANT. IS EVERYBODY ABLE TO REVIEW THIS OURCE CODE?
No, we do not release the source code. Too much know-how would be at stake.
Totally unacceptable.
If those really are "frequently-asked questions", those responses are simply arrogant. The has clearly adopted a "trust us" mentality, which just doesn't work with people who want strong security. I also don't see any FIPS certifications anywhere.
My favourite language (right now) for teaching is good old line-numbered BASIC, because it has a structure that parallels assembly language, but lets you do things like PRINT "HELLO WORLD" in one line (which is much more rewarding to beginners).
Didn't MS buy their IDE from some other company? I thought they did but I can't find the link.
On the other hand, you can at least thank them for not totally screwing up their IDE. Not like Internet Explorer, where the best version was probably version 2.0, or maybe 3.0, and it pretty much went downhill from there.
If you can not figure out vi, emacs, or any other cli text editor then why should we trust your programming?
It's an introductory class. I'm not going to trust the programming of people who have only had an introductory class, regardless of the editor they use.
Hell, IDE's don't even pass lint most of the time.
Huh? Nobody's suggesting automatic code generation... I hope.
i want people who know how to program, for whom the IDE is a tool to make their accurate and creative thought process real. instead, i get people who don't know shit and let the IDE do all the thinking for them.
And you think by taking away their IDEs, they'll suddenly become good programmers? Please.
the IDE is a great tool for software development. for learning to program, it creates a handicapp that never goes away.
I'd say that it's more a case of IDEs helping crappy programmers get their projects nominally done, more than anything else. So far, I have yet to see anyone make a convincing case that an IDE actually impedes the work of a good programmer.
What's the purpose of this course? If your goal is to teach the language, then do that; If it's not a "text editors" course, don't try to make it into one.
In my experience (I took an engineering degree, so YMMV), it's largely a myth that students will learn more if you make the course more complicated. Rather, your students probably have a fixed amount of time that they will devote to your course, so you want to make the most efficient use of that time. If you make students spend more time learning how to use the text editor/IDE, then the students will either spend less time learning actual programming, or they'll spend less time on other courses.
I suggest that you let the students use whatever environment they want, but provide them with a suitable option that you're willing to support. Learning a new editor is easy if you're a good programmer, so concentrate your effort on making good programmers!
That said, any time somebody asks you a question, point them to the official specification, not the IDE, not a FAQ, and not some 3rd-party tutorial. Likewise, during exams, the official reference documentation should always be made available. Never encourage your students to pass off code that they aren't convinced is correct!
Slashdot Mirror
And when you find out your kids do that, you can (for some effective amount of time):
If your children know they can fight with you and win, you have failed as a parent. Period.
Your job is to convince your kids that they don't want to play those games. The threat of corporeal punishment is an effective way to do this for younger children -- with older children, a combination of reasoning and taking away privileges can be more effective. You can choose to turn a blind eye to certain behaviours, but once you confront your children, you must not lose.
Or, perhaps more importantly, it's your job as a parent to teach your kids, as early as possible, the difference between fact and fiction. Then, when your kids eventually *do* play these games (or watch "that" movie, or read "that" book, or are targeted for recruitment by "that" cult, etc) they will be immune to being influenced by them.
Right, they'll just hijack old, abandoned accounts to spam from.
Scientists, on the other hand, build theories that correspond to existing data. Then, they make predictions ("hypotheses") based on the new theories, and collect additional data. The data itself will either support or refute the theories, or it will do neither.
Regardless, science does not "prove" things with absolute certainty.
I don't trust any encryption system that isn't open and well-analyzed, regardless of the country of origin.
That said, I'm sure that some Chinese people are capable of developing strong cryptography. They broke SHA-1, after all.
Two words: Injunctive relief.
Hmm. That's an interesting observation. My understanding is that the FSF doesn't so much consider the original Artistic Licence as being non-free in principle, just too vague to be considered free with certainty.
However, Debian's perl-base 5.8.8-4 package says this in its copyright file:
I doubt that RMS would consider that non-free. :)
However I do feel that uncompromising groups have something to add to society, by maintaining balance against forces pulling in the opposite direction (FSF, ACLU, etc). Thus I try not to misrepresent their interpretations.
Agreed.
Clearly, you are the authority on what "most of us" care about.
So? If that's such a bad idea, almost nobody will use it.
They're stars made of dark matter. ;-P
It's a good read.
To be computer literate, one must know how to read computers.
What about CTRL Q?
Sounds familiar.
[Please mod my previous reply down. It's botched.]
There is some information about the algorithms they're using here. That page says that they're using 1024-bit DH to negotiate a 128-bit AES key, then they XOR the output of the AES algorithm with the voice data.
Frankly, I don't trust it.
First of all, neither 1024-bit DH nor 128-bit AES actually give you 128-bit security (i.e. 2^128 complexity). For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about Diffie-Hellman, but it's similar in structure to RSA, and experts have been recommending at least 2048-bit keys for new designs using RSA for years, and that's not even to get a 128-bit security level. For a true 128-bit security level, you need something like 6100 bits (if I remember correctly), which most people don't use because it's very slow to do in software.
The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single repeating AES ciphertext block with the entire plaintext datastream, which would be trivially insecure. We really have no way of knowing.
As for authentication, which is often more important than confidentiality (and which may be required for confidentiality)? This is all I could find:
There is no mention of what hash function is being used, nor of what is being hashed. Furthermore, people who talk about "HASH" -- in all-caps, as if HASH is an algorithm itself -- clearly don't know what they're doing. It might just be Vecrotel's marketing department messing things up. Or, it could be a more fundamental lack of expertise within the company. Who knows?
Have a look at the Vecrotel FAQ:
Totally unacceptable.
If those really are "frequently-asked questions", those responses are simply arrogant. The company has clearly adopted a "trust us" mentality. If I was willing to blindly trust other companies, I wouldn't be looking for a secure phone!
Crypto products are like voting machines. If their operation is not independently verifiable, then they simply cannot be trusted.
As an interesting side note, I don't see any FIPS certifications.
I smell snake oil.
Frankly, I don't trust it.
First of all, neither 1024-bit DH nor 128-bit AES actually give you 2^128 complexity. For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about diffie-hellman, but it's very similar in structure to RSA, and experts have been recommending at least 2048-bit keys for RSA for years now.
The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single AES ciphertext block with the entire plaintext datastream. We really have no way of knowing.
Have a look at the Vecrotel FAQ:
Totally unacceptable.
If those really are "frequently-asked questions", those responses are simply arrogant. The has clearly adopted a "trust us" mentality, which just doesn't work with people who want strong security. I also don't see any FIPS certifications anywhere.
I smell snake oil.
No text.
My favourite language (right now) for teaching is good old line-numbered BASIC, because it has a structure that parallels assembly language, but lets you do things like PRINT "HELLO WORLD" in one line (which is much more rewarding to beginners).
Exactly. Also, it adds overhead to the class, because you'd have to teach the students how to use a debugger.
On the other hand, you can at least thank them for not totally screwing up their IDE. Not like Internet Explorer, where the best version was probably version 2.0, or maybe 3.0, and it pretty much went downhill from there.
Vim 7 was released less than 2 weeks ago. I'd hardly call that outdated.
It's an introductory class. I'm not going to trust the programming of people who have only had an introductory class, regardless of the editor they use.
Hell, IDE's don't even pass lint most of the time.
Huh? Nobody's suggesting automatic code generation... I hope.
And you think by taking away their IDEs, they'll suddenly become good programmers? Please.
the IDE is a great tool for software development. for learning to program, it creates a handicapp that never goes away.
I'd say that it's more a case of IDEs helping crappy programmers get their projects nominally done, more than anything else. So far, I have yet to see anyone make a convincing case that an IDE actually impedes the work of a good programmer.
On the other hand, I use vim...
In my experience (I took an engineering degree, so YMMV), it's largely a myth that students will learn more if you make the course more complicated. Rather, your students probably have a fixed amount of time that they will devote to your course, so you want to make the most efficient use of that time. If you make students spend more time learning how to use the text editor/IDE, then the students will either spend less time learning actual programming, or they'll spend less time on other courses.
I suggest that you let the students use whatever environment they want, but provide them with a suitable option that you're willing to support. Learning a new editor is easy if you're a good programmer, so concentrate your effort on making good programmers!
That said, any time somebody asks you a question, point them to the official specification, not the IDE, not a FAQ, and not some 3rd-party tutorial. Likewise, during exams, the official reference documentation should always be made available. Never encourage your students to pass off code that they aren't convinced is correct!
Ever?
Ever heard of RPM, the Red Hat Package Manager? Granted, Debian's overall package management system is technically superior, but IIRC it's also newer.
Red Hat beat the pants off Slackware in terms of ease-of-use (again, this was years ago).
Hell, ever heard of Alan Cox?
I'm not a fan of Red Hat's Linux distributions, but to say that Red Hat has never done anything innovative is simply wrong.
Ha. Hahahahaha.
You don't quite understand the software patent problem, do you?