"I have made no nonsense claims, and even if I had, you have no reason to be rude."
What are you talking about? I am not being rude, do you have a persecution complex or something?
"For Linus's stand on the issue, please read a post he made on this issue. In fact, skip the rest of this post and just read that thread, Linus is a much better teacher than I ever will be."
Uh, just because he points out that using strlcpy where its not needed is dumb doesn't mean he thinks strlcpy is bad. HE HAS IT IN THE KERNEL. How much more clear can this get?
"However, you blithely ignore the fact that truncating strings based on length likely covers a bug more effectively than the security problem the buffer overflow is."
No, I don't. Instead of telling me what I am doing, how about you read what I wrote. To quote me, in the post you are replying to:
"And strlcpy doesn't randomly truncate strings, it truncates strings that are too long, and then tells you it truncated them in case that matters (which it sometimes does)."
This is very simple, and people who pretend this is an issue are either repeating nonsense because they don't know C, or they are making up the nonsense because they have an agenda (Drepper). See below where I point out how your code is nonsense.
"I'd say the BSD version is the worse security risk, or at least, the one that is hardest to detect"
A single if statement is actually quite simple.
"Yes, they happen, because like it or not, most people prefer a good function over a portable one, and nothing you or I can do will change this"
Why do you think I care? I am simply pointing out the fact that the poster starting this thread is wrong, software is in fact targeted for linux. I know why, and I don't need help fixing it. I am just pointing out the fact to the "insightful" but completely wrong poster.
"Finally, I must declare I am tired of your baseless insults, and will only respond to polite posts from this point on. I can accept shit from great programmers that have illustrated their worthiness, but not from someone who obviously still have a lot to learn."
I didn't insult you in the last post, baseless or otherwise. And given the code you just posted, you have no ability to judge how much I or anyone else needs to learn.
"P.S: Ulrich Drepper's code is incorrect (even if ugly) unlike the code you wrote, at least in the general case. So I think it is taken out of context, as I don't see Drepper making that sort of mistake."
I posted the link for you, its taken directly from his post. And its not incorrect, just ugly and a gnuism.
"The only case strlcpy is valid is if you really want to copy & truncate a string."
Uh huh.
So if strlcpy was renamed to strcptr(dst,src,n), I think it might be accepted.
Why? strncpy truncates too, that's what its modelled after, hence the name.
"Though it is a relatively rare usecase, and might be better placed in another library."
No, its a ordinary use case, not rare. Its a replacement for strncpy because strncpy is stupid and doesn't guarantee to NULL terminate, is slow, and is so frequently misused leading to exploitable holes. Anywhere that has strncpy should have strlcpy, there is absolutely no reason to have strn but not strl.
As for your code, where to begin. First of all, in your example case you would know the max length of table names, and so you would use that instead of 51 as your buffer size. Second, in a case where truncation matters, you test for it, duh?
if (strlcpy(input, getValidatedSqlFromUser(), sizeof input) > 51) do_whatever_you_want_to_handle_truncation();
Third, your ifdef ULRICH strcpy won't compile, strcpy doesn't take a length. You want strncpy. And you just end up with a slower version of strdup, which is what you should have used in your nonsense made up example that has nothing to do with strlcpy at all. Notice how all the examples strlcpy haters come up with are ridiculous and nonsensical?
"Hey, I don't really have a problem with it, and I resent your language. Learn to talk nice, even if disagree, please"
Learn not to make nonsense claims with nothing to back them up.
"As I said, it is the glibc team (and yes, Ulrich among them) and Linus that spearheaded rejection of that patch. (I found this out via searching the group with google; I'm sure you can do the same since you seem to care so much)"
As I said, Linus does use it, its in the linux kernel because Drepper was too big of a douche to accept it in glibc, grep for yourself.
"they are unneccessary (as you should always keep track of how long your string is and realloc as neccesary strcpy or memcpy will do as well. Randomly truncating of stings are not really any better than overflowing. (I disagree about this)."
Obviously this is silly, of course you keep track of how long it is, that's why you pass it a length argument. strcpy and memcpy will not due, as they will gladly overflow that fixed length buffer. strncpy will not due because it fails to NULL terminate strings all the time and is slow. And strlcpy doesn't randomly truncate strings, it truncates strings that are too long, and then tells you it truncated them in case that matters (which it sometimes does).
"They invite the use of fixed buffers of strings, which are unfortunate design in any case where the string length cannot be known beforehand, such as a file name and input"
Yes, lets just keep strlening everything new we get and reallocing our buffer to fit that new size. All machines have infinite RAM, and realloc takes no time, so why bother keeping strings to a reasonable length.
"They bloat glibc, if even just by a tiny amount, making every program in linux (near enough) just that much slowly launch. (and yes, glibc is already way too bloated, everyone agrees in this. That does not adding more stuff any better). "
This is the funny one, as if a 25 line function is going to bloat glibc up, when its got thousands and thousands of lines of bloat already. It won't make anything launch any slower at all, what a pathetic excuse.
"As you yourself say, writing the function out and including them around a configure check is pretty much mandatory anyway."
Pretty much mandatory because Ulrich Drepper is a tard and thinks: *((char *) mempcpy (dst, src, n)) = '\0'; is nicer than: strlcpy(dst, src, n); If it were in glibc, then standardization attempts would succeed because of it being in all the most used unixes (BSDs, OSX, solaris and linux) and then it would end up everywhere and wouldn't need configure checks.
"Yes, valgrind helped in Z/Os, not that you can run it there, as I well know, but the bugs that appears in one system tends to be hidden on other systems as well... but for various, the bugs aren't triggered."
Existing bugs are not part of a linuxism though. Valgrind helps be a very slow version of just developing on openbsd to start with, yes. But those bugs are there on linux too, they just don't trigger reliably. I wasn't saying software is buggy (which is obviously the case) I was saying that its written for linux.
Being large projects has nothing to do with it. Suse's patches are for making it fit their desktop setup. OpenBSD doesn't have anything like that, its just gnome or KDE as is. These patches are just to function correctly, not to add icons and setup default apps and such. If you need alot of patches to work on non-linux systems, then you have linux software. Pretty straight forward. Please stop trying to spread misinformation, we've got plenty enough unportable software without you trying to convince everyone that it is in fact portable and they can keep writing linuxware and it will work everywhere.
First of all, strlcpy/cat are very well thought out. If you have a problem with them, say what it is. Second, they are not in glibc because Ulrich Drepper is a moron with a severe case of NIH syndrome. Third, it IS in the linux kernel, Linus accepted it just fine. He had to put it in the kernel so he could use it because Ulrich Drepper is too dense to let it into glibc. And fourth, nobody writes software that relies on strlcpy without also including a configure check and strlcpy, making it portable. Duh?
Clearly you haven't done the porting you claim you have, or you would realize valgrind is linux only, and thus does not help you porting to other systems. Valgrind isn't going to do jack for you on z/os.
"It's like complaining that there's more Windows software than OS X, or Solaris software vs. AIX, and complaining alone won't get you anywhere."
No its not, its like saying "yes, McDonald's does sell hamburgers" to someone who says "I don't think McDonald's really concentrates on selling hamburgers". I didn't complain, I pointed out that the "insightful" post that started this thread is in fact completely incorrect. I know linux sofware is written because there's so many linux users. That in fact proves my point, people are writing linux software.
"First, GNU is not Linux. I agree that there is awfully lot of software that relies on gnu. But that does not tie the software to Linux."
That's why I mentioned both linuxisms and gnuisms. There's both. The bizzare linux/proc is not gnu anything, its part of linux. Software that expects that is relying on a linuxism.
"AFAIK Solaris ships with Gnome desktop."
Yes, and they had to spend a lot of time and effort correcting the code so it would work properly because Gnome is developed by linux users, for linux users, on linux. It is linux software. The fact that 3rd parties are required to port Gnome to unix OSs means its not unix software, its linux software.
"One of the main ideas of free software is that you can take any damn thing that only compile on some obscure version of Red Hat, edit the damn code, write a good makefile or configure script, and make it run on whatever common or exotic system you use. If there is an application you care about that does not compile with your cc, fix it and submit the patches."
This doesn't change the fact that many people do in fact write linux software instead of unix software. I could spend my entire life fixing people's unportable code, and having them ignore the patches, or worse yet accept them, then in 2 months have re-broken it all. That's not the point though. The point is the thread was started by a linux user making the false assertion that open source software is portable and not linux-centric because he's never used anything but linux. This is incorrect, tons of open source software is linux software, and much of what does work elsewhere works elsewhere because of other people, the software is still linux centric and forcing other people to constantly patch it to work.
KDE and Gnome require a great deal of effort to be ported to other OSs besides linux. They are written for linux, and then people who use other OSs have to port it themselves if they want it to run anywhere else. On a reasonably current openbsd system:
First of all, they come with very little GNU stuff, pretty much just the compiler/toolchain. And that is maintained as a patched version for the OS in question. Of course, I didn't say anything about GNU software, I said most open source software. Download some random software from sourceforge, half of it won't compile on anything but linux, and even then often only i386 or i386 and amd64. And the stuff that does compile is often subtly broken because of linuxisms or gnuisms in it. Hell, I've seen plenty of stuff that won't even work on all popular linux distros. Assuming broken glibc behaviour, or stupid GNU extensions is very common in open source software since most people writing it have never tried unix before, so they assume the entire world is just like their distro or choice.
Try using a BSD or solaris and see just how standards compliant most open source software is. There's tons of linuxism and gnuisms in not just the software, but also their configure and build setups. And glibc is not a standard. If you mean one of the C standards like C99, then no, lots of people write gnu/C.
Why would you want the horrible mess of GNU bloatware and random crap that is a debian or gentoo userland? Just try one of the BSDs, they have much nicer userlands already on their own, no need for Debian/ or Gentoo/ at all.
Nice mozillascript there, almost as good as slashdot's. If you write mozilla only code, it will only work on mozilla. This is not suprising or unexpected.
"Do you really need - should you actually have! - the right to find out my most intimate secrets, which harm absolutely no one else, and publish them in public?"
If you were acting out those secrets in public, then yes I do have that right, and yes I should. Of course, this is a red herring, as there's no secrets involved here The most hated company that pretends to be a person in the entire "game" got flying penised, there's no secrets involved, just hilarity.
No, just because pompous dimwits (why are they always ruby users) make up new (stupid) names for old things, doesn't mean we have to play along and give them the attention they crave.
"It does only check if a method for a given signature exists while real strong typing, dynamic or not would also check if that method is inherited from the correct superclass or implemented from the correct interface."
You are confused about what strong typing means. You are talking about structural typing vs nominative typing, which is completely orthogonal to dynamic vs static and strong vs weak.
Both ruby and ocaml are strongly typed languages. You can't coerce one type to another, defeating the type system. Ocaml is static, it checks types at compile time, and thus forbids you from assigning a different type to the same variable. Ruby is dynamic, checking types at run time, so you are allowed to make x be a string here, and then a float there.
They are both structurally typed, meaning object types are considered equivilent if they have the same signature. Nominally typed languages require explicit inheritance to be considered equivilent. Just because java is static, strong and nominative, doesn't mean you have to be nominative to be strong. Or that being nominative makes you strong. You can have strong and structural, or weak and nominative.
It was never in favor, pretty hard to fall out. Its fairly obvious that ruby is more productive, go try it. Its a higher level language with more high level abstractions. This isn't taking anything away from smalltalk, which has better development tools and unlike ruby is actually fast enough to be used for non-trivial tasks. But ruby is more productive.
Microsoft is not a user, your xbox example is about preventing users from using their own system. And while I am sure they didn't go the.net route specifically to degrade performance, the choice does degrade performance, jit compilation does not make it as fast as native. For what its worth, you can do the same thing with native code if you want, using the OS to restrict access. You could make an OS that will only execute "trusted" executables normally, and everything else gets limited access where many syscalls are denied. You could do this with selinux or any other similar system. None of this requires a VM at all, its just things that have been implimented in existing VMs. That does not preclude them from being implimented without a VM.
You already have to trust the compiler and the VM. What user is getting what benefit? The programmer already relies on the compiler and VM and libs, relying on just the compiler and libs is no different. The person running the code gets no guarentees either way, a VM doesn't protect him at all, unless he compiles the VM and the bytecode himself. He would get the same protection from the theoretical machine code compiler.
That still has nothing to do with a VM though. What is wrong with a compiler generating the same runtime checks in the machine code it outputs? Just because languages that do this are typically bytecode compiled languages, doesn't mean it can't be done in machine code compiled languages too.
Neither runtime safety checks nor a logical standard library have anything to do with a VM though. A native compiler can insert safety checks just fine when producing machine code.
Duck typing is a retarded name for something that does not exist. Its just plain old strong dynamic typing. And that does not lead to productivity gains. It just leads to runtime type errors and long term maintainance headaches. This ridiculous notion seems to be because people compare static typing as implimented in java to dynamic typing as implimented in ruby or python. Try haskell or ML before blindly repeating nonsense.
Most of the productivity gains of high level languages come from having advanced data types available, and extensive libraries to do things you have to do by hand in lower level languages. It has nothing to do with static vs dynamic typing, or smalltalk style dynamicism vs compile time metaprogramming. Either can be used in a productive language, just because ruby uses dynamic smalltalk inspired design and is a productive language, doesn't mean only dynamic smalltalk inspired languages can be productive. You'll notice that smalltalk obviously has the same smalltalk dynamicism ruby does, yet ruby is more productive. Why? Because ruby provides more high level abstractions to save you time.
CoH/V has no challenge at all, bland boring repetative gameplay, and developers that actually despise their customers. "Its not a nerf, its diversification". Yeah, that's some impressive listening to the players and enacting a good change. Impliment a massive nerf, across the board so its not even for balance, lie about it, have everyone quit, and then admit it was just a nerf because "players were too powerful".
Obviously if I can sniff your http traffic, then I can also sniff the http traffic going to you but generated by me spoofing your IP. If I can sniff your traffic then I am between you and the server. If I am between you and the server, I can send packets from your IP, and then look at the responses coming back. I can even decide not to let the responses get to you, so you wouldn't even be able to tell it was happening even if you were watching.
Slashdot Mirror
"I have made no nonsense claims, and even if I had, you have no reason to be rude."
What are you talking about? I am not being rude, do you have a persecution complex or something?
"For Linus's stand on the issue, please read a post he made on this issue. In fact, skip the rest of this post and just read that thread, Linus is a much better teacher than I ever will be."
Uh, just because he points out that using strlcpy where its not needed is dumb doesn't mean he thinks strlcpy is bad. HE HAS IT IN THE KERNEL. How much more clear can this get?
"However, you blithely ignore the fact that truncating strings based on length likely covers a bug more effectively than the security problem the buffer overflow is."
No, I don't. Instead of telling me what I am doing, how about you read what I wrote. To quote me, in the post you are replying to:
"And strlcpy doesn't randomly truncate strings, it truncates strings that are too long, and then tells you it truncated them in case that matters (which it sometimes does)."
This is very simple, and people who pretend this is an issue are either repeating nonsense because they don't know C, or they are making up the nonsense because they have an agenda (Drepper). See below where I point out how your code is nonsense.
"I'd say the BSD version is the worse security risk, or at least, the one that is hardest to detect"
A single if statement is actually quite simple.
"Yes, they happen, because like it or not, most people prefer a good function over a portable one, and nothing you or I can do will change this"
Why do you think I care? I am simply pointing out the fact that the poster starting this thread is wrong, software is in fact targeted for linux. I know why, and I don't need help fixing it. I am just pointing out the fact to the "insightful" but completely wrong poster.
"Finally, I must declare I am tired of your baseless insults, and will only respond to polite posts from this point on. I can accept shit from great programmers that have illustrated their worthiness, but not from someone who obviously still have a lot to learn."
I didn't insult you in the last post, baseless or otherwise. And given the code you just posted, you have no ability to judge how much I or anyone else needs to learn.
"P.S: Ulrich Drepper's code is incorrect (even if ugly) unlike the code you wrote, at least in the general case. So I think it is taken out of context, as I don't see Drepper making that sort of mistake."
I posted the link for you, its taken directly from his post. And its not incorrect, just ugly and a gnuism.
"The only case strlcpy is valid is if you really want to copy & truncate a string."
Uh huh.
So if strlcpy was renamed to strcptr(dst,src,n), I think it might be accepted.
Why? strncpy truncates too, that's what its modelled after, hence the name.
"Though it is a relatively rare usecase, and might be better placed in another library."
No, its a ordinary use case, not rare. Its a replacement for strncpy because strncpy is stupid and doesn't guarantee to NULL terminate, is slow, and is so frequently misused leading to exploitable holes. Anywhere that has strncpy should have strlcpy, there is absolutely no reason to have strn but not strl.
As for your code, where to begin. First of all, in your example case you would know the max length of table names, and so you would use that instead of 51 as your buffer size. Second, in a case where truncation matters, you test for it, duh?
if (strlcpy(input, getValidatedSqlFromUser(), sizeof input) > 51) do_whatever_you_want_to_handle_truncation();
Third, your ifdef ULRICH strcpy won't compile, strcpy doesn't take a length. You want strncpy. And you just end up with a slower version of strdup, which is what you should have used in your nonsense made up example that has nothing to do with strlcpy at all. Notice how all the examples strlcpy haters come up with are ridiculous and nonsensical?
What kind of bizzare non sequitur is that? None of the BSD userland tools are part of a totalitarian regime, they are just software.
"Hey, I don't really have a problem with it, and I resent your language. Learn to talk nice, even if disagree, please"
s g00061.html so I have no need to google it.
Learn not to make nonsense claims with nothing to back them up.
"As I said, it is the glibc team (and yes, Ulrich among them) and Linus that spearheaded rejection of that patch. (I found this out via searching the group with google; I'm sure you can do the same since you seem to care so much)"
No, it was just Ulrich, and I know this because I found so much humour in this particular post: http://sources.redhat.com/ml/libc-alpha/2000-08/m
As I said, Linus does use it, its in the linux kernel because Drepper was too big of a douche to accept it in glibc, grep for yourself.
"they are unneccessary (as you should always keep track of how long your string is and realloc as neccesary strcpy or memcpy will do as well. Randomly truncating of stings are not really any better than overflowing. (I disagree about this)."
Obviously this is silly, of course you keep track of how long it is, that's why you pass it a length argument. strcpy and memcpy will not due, as they will gladly overflow that fixed length buffer. strncpy will not due because it fails to NULL terminate strings all the time and is slow. And strlcpy doesn't randomly truncate strings, it truncates strings that are too long, and then tells you it truncated them in case that matters (which it sometimes does).
"They invite the use of fixed buffers of strings, which are unfortunate design in any case where the string length cannot be known beforehand, such as a file name and input"
Yes, lets just keep strlening everything new we get and reallocing our buffer to fit that new size. All machines have infinite RAM, and realloc takes no time, so why bother keeping strings to a reasonable length.
"They bloat glibc, if even just by a tiny amount, making every program in linux (near enough) just that much slowly launch. (and yes, glibc is already way too bloated, everyone agrees in this. That does not adding more stuff any better). "
This is the funny one, as if a 25 line function is going to bloat glibc up, when its got thousands and thousands of lines of bloat already. It won't make anything launch any slower at all, what a pathetic excuse.
"As you yourself say, writing the function out and including them around a configure check is pretty much mandatory anyway."
Pretty much mandatory because Ulrich Drepper is a tard and thinks:
*((char *) mempcpy (dst, src, n)) = '\0';
is nicer than:
strlcpy(dst, src, n);
If it were in glibc, then standardization attempts would succeed because of it being in all the most used unixes (BSDs, OSX, solaris and linux) and then it would end up everywhere and wouldn't need configure checks.
"Yes, valgrind helped in Z/Os, not that you can run it there, as I well know, but the bugs that appears in one system tends to be hidden on other systems as well... but for various, the bugs aren't triggered."
Existing bugs are not part of a linuxism though. Valgrind helps be a very slow version of just developing on openbsd to start with, yes. But those bugs are there on linux too, they just don't trigger reliably. I wasn't saying software is buggy (which is obviously the case) I was saying that its written for linux.
Being large projects has nothing to do with it. Suse's patches are for making it fit their desktop setup. OpenBSD doesn't have anything like that, its just gnome or KDE as is. These patches are just to function correctly, not to add icons and setup default apps and such. If you need alot of patches to work on non-linux systems, then you have linux software. Pretty straight forward. Please stop trying to spread misinformation, we've got plenty enough unportable software without you trying to convince everyone that it is in fact portable and they can keep writing linuxware and it will work everywhere.
First of all, strlcpy/cat are very well thought out. If you have a problem with them, say what it is. Second, they are not in glibc because Ulrich Drepper is a moron with a severe case of NIH syndrome. Third, it IS in the linux kernel, Linus accepted it just fine. He had to put it in the kernel so he could use it because Ulrich Drepper is too dense to let it into glibc. And fourth, nobody writes software that relies on strlcpy without also including a configure check and strlcpy, making it portable. Duh?
Clearly you haven't done the porting you claim you have, or you would realize valgrind is linux only, and thus does not help you porting to other systems. Valgrind isn't going to do jack for you on z/os.
"It's like complaining that there's more Windows software than OS X, or Solaris software vs. AIX, and complaining alone won't get you anywhere."
No its not, its like saying "yes, McDonald's does sell hamburgers" to someone who says "I don't think McDonald's really concentrates on selling hamburgers". I didn't complain, I pointed out that the "insightful" post that started this thread is in fact completely incorrect. I know linux sofware is written because there's so many linux users. That in fact proves my point, people are writing linux software.
"First, GNU is not Linux. I agree that there is awfully lot of software that relies on gnu. But that does not tie the software to Linux."
/proc is not gnu anything, its part of linux. Software that expects that is relying on a linuxism.
That's why I mentioned both linuxisms and gnuisms. There's both. The bizzare linux
"AFAIK Solaris ships with Gnome desktop."
Yes, and they had to spend a lot of time and effort correcting the code so it would work properly because Gnome is developed by linux users, for linux users, on linux. It is linux software. The fact that 3rd parties are required to port Gnome to unix OSs means its not unix software, its linux software.
"One of the main ideas of free software is that you can take any damn thing that only compile on some obscure version of Red Hat, edit the damn code, write a good makefile or configure script, and make it run on whatever common or exotic system you use. If there is an application you care about that does not compile with your cc, fix it and submit the patches."
This doesn't change the fact that many people do in fact write linux software instead of unix software. I could spend my entire life fixing people's unportable code, and having them ignore the patches, or worse yet accept them, then in 2 months have re-broken it all. That's not the point though. The point is the thread was started by a linux user making the false assertion that open source software is portable and not linux-centric because he's never used anything but linux. This is incorrect, tons of open source software is linux software, and much of what does work elsewhere works elsewhere because of other people, the software is still linux centric and forcing other people to constantly patch it to work.
KDE and Gnome require a great deal of effort to be ported to other OSs besides linux. They are written for linux, and then people who use other OSs have to port it themselves if they want it to run anywhere else. On a reasonably current openbsd system:
/usr/ports/x11/kde/ -name patch-* | wc -l /usr/ports/x11/gnome -name patch-* | wc -l
$ find
115
$ find
92
Do you really think software that requires ~100 files to be patched if you aren't running on linux isn't linux centric?
First of all, they come with very little GNU stuff, pretty much just the compiler/toolchain. And that is maintained as a patched version for the OS in question. Of course, I didn't say anything about GNU software, I said most open source software. Download some random software from sourceforge, half of it won't compile on anything but linux, and even then often only i386 or i386 and amd64. And the stuff that does compile is often subtly broken because of linuxisms or gnuisms in it. Hell, I've seen plenty of stuff that won't even work on all popular linux distros. Assuming broken glibc behaviour, or stupid GNU extensions is very common in open source software since most people writing it have never tried unix before, so they assume the entire world is just like their distro or choice.
Try using a BSD or solaris and see just how standards compliant most open source software is. There's tons of linuxism and gnuisms in not just the software, but also their configure and build setups. And glibc is not a standard. If you mean one of the C standards like C99, then no, lots of people write gnu/C.
Why would you want the horrible mess of GNU bloatware and random crap that is a debian or gentoo userland? Just try one of the BSDs, they have much nicer userlands already on their own, no need for Debian/ or Gentoo/ at all.
Nice mozillascript there, almost as good as slashdot's. If you write mozilla only code, it will only work on mozilla. This is not suprising or unexpected.
"Do you really need - should you actually have! - the right to find out my most intimate secrets, which harm absolutely no one else, and publish them in public?"
If you were acting out those secrets in public, then yes I do have that right, and yes I should. Of course, this is a red herring, as there's no secrets involved here The most hated company that pretends to be a person in the entire "game" got flying penised, there's no secrets involved, just hilarity.
"But it does exist, unfortunately"
No, just because pompous dimwits (why are they always ruby users) make up new (stupid) names for old things, doesn't mean we have to play along and give them the attention they crave.
"It does only check if a method for a given signature exists while real strong typing, dynamic or not would also check if that method is inherited from the correct superclass or implemented from the correct interface."
You are confused about what strong typing means. You are talking about structural typing vs nominative typing, which is completely orthogonal to dynamic vs static and strong vs weak.
Both ruby and ocaml are strongly typed languages. You can't coerce one type to another, defeating the type system. Ocaml is static, it checks types at compile time, and thus forbids you from assigning a different type to the same variable. Ruby is dynamic, checking types at run time, so you are allowed to make x be a string here, and then a float there.
They are both structurally typed, meaning object types are considered equivilent if they have the same signature. Nominally typed languages require explicit inheritance to be considered equivilent. Just because java is static, strong and nominative, doesn't mean you have to be nominative to be strong. Or that being nominative makes you strong. You can have strong and structural, or weak and nominative.
It was never in favor, pretty hard to fall out. Its fairly obvious that ruby is more productive, go try it. Its a higher level language with more high level abstractions. This isn't taking anything away from smalltalk, which has better development tools and unlike ruby is actually fast enough to be used for non-trivial tasks. But ruby is more productive.
Microsoft is not a user, your xbox example is about preventing users from using their own system. And while I am sure they didn't go the .net route specifically to degrade performance, the choice does degrade performance, jit compilation does not make it as fast as native. For what its worth, you can do the same thing with native code if you want, using the OS to restrict access. You could make an OS that will only execute "trusted" executables normally, and everything else gets limited access where many syscalls are denied. You could do this with selinux or any other similar system. None of this requires a VM at all, its just things that have been implimented in existing VMs. That does not preclude them from being implimented without a VM.
You already have to trust the compiler and the VM. What user is getting what benefit? The programmer already relies on the compiler and VM and libs, relying on just the compiler and libs is no different. The person running the code gets no guarentees either way, a VM doesn't protect him at all, unless he compiles the VM and the bytecode himself. He would get the same protection from the theoretical machine code compiler.
That still has nothing to do with a VM though. What is wrong with a compiler generating the same runtime checks in the machine code it outputs? Just because languages that do this are typically bytecode compiled languages, doesn't mean it can't be done in machine code compiled languages too.
Neither runtime safety checks nor a logical standard library have anything to do with a VM though. A native compiler can insert safety checks just fine when producing machine code.
Duck typing is a retarded name for something that does not exist. Its just plain old strong dynamic typing. And that does not lead to productivity gains. It just leads to runtime type errors and long term maintainance headaches. This ridiculous notion seems to be because people compare static typing as implimented in java to dynamic typing as implimented in ruby or python. Try haskell or ML before blindly repeating nonsense.
Most of the productivity gains of high level languages come from having advanced data types available, and extensive libraries to do things you have to do by hand in lower level languages. It has nothing to do with static vs dynamic typing, or smalltalk style dynamicism vs compile time metaprogramming. Either can be used in a productive language, just because ruby uses dynamic smalltalk inspired design and is a productive language, doesn't mean only dynamic smalltalk inspired languages can be productive. You'll notice that smalltalk obviously has the same smalltalk dynamicism ruby does, yet ruby is more productive. Why? Because ruby provides more high level abstractions to save you time.
CoH/V has no challenge at all, bland boring repetative gameplay, and developers that actually despise their customers. "Its not a nerf, its diversification". Yeah, that's some impressive listening to the players and enacting a good change. Impliment a massive nerf, across the board so its not even for balance, lie about it, have everyone quit, and then admit it was just a nerf because "players were too powerful".
Its "tearing" not "tairing", and it has nothing to do with syncing input and output. Its from trying to convert interlaced to progressive.
"Does Slashdot have any insight to offer?"
No.
Obviously if I can sniff your http traffic, then I can also sniff the http traffic going to you but generated by me spoofing your IP. If I can sniff your traffic then I am between you and the server. If I am between you and the server, I can send packets from your IP, and then look at the responses coming back. I can even decide not to let the responses get to you, so you wouldn't even be able to tell it was happening even if you were watching.
If I can sniff your http traffic, I can also spoof your IP. All your plan will do is break your site for people who are behind a proxy pool.