User experience. Now that I've spent time on the Tex learning curve, and I can typically get it to do what I want, why would I want to get on another learning curve?
I've written hundreds of pages in Tex including an undergrad thesis, and I still run across things that are hard to do, or even impossible. Want to float an image to the side and have text wrap around it? Good luck. There are a couple packages out there for doing it, but I haven't had much luck in getting them to behave reasonably. For instance, with floatfig you have to figure out how much text will fit on the line preceding the figure, then put the figure at that point in the source, and it still won't typeset it entirely correctly because the line above won't be justified. And if you want to change what you say? Now you have to reposition the figure. This is something that Word has been able to do "good enough" and definitely far easier for long over a decade. Tables is something else that I always think are a PITA in LaTeX (and, FWIW, HTML) since oftentimes you can't really line up the columns in any sort of WYSIWYG form, which means that you often have to count "this is the 5th column, so I need to go past four &s in this row.
(Of course, there are a ton of things that LaTeX is better at. Math, overall typography, programmability, cross references, bibliographies. My point is that there are different tools for different jobs, and Word would be a more reasonable one for some tasks.
Our seventh sense is proprioception, derived from muscle feedback all over the body.
"Proprioception" is one of my favorite words (I'm disappointed to see it's not in the Firefox spell checking dictionary). I even coined the term "vehicular proprioception" for the "sense" of knowing how close you are to hitting stuff when you're driving around in a car. (I got pretty refined vehicular proprioception at my last apartment when it often took 3 or 4 drivereverse transitions to get out of my parking space because of short distances between cars.)
Because most of them would take most competent software engineers about 5 minutes to think up themselves if presented with the problem that the patent claims to be a solution to.
Sometimes, though, figuring out what the problem is, or even that there is a problem in the first place, is decidedly non-trivial.
I'm not nearly as anti-patent as most people around here are, and this patent is borderline at best IMO, but I do think it falls into this category.
I think you misunderstand his point... the 'size' parameter isn't the number of bytes in either buffer, it's the number of bytes you want to move. Obviously this has a lot to do with the size of either allocated buffer, but it's not the same thing.
That's right, but that doesn't change my argument. In the general case, if you wanted to use memcpy in a manner I would consider secure, you still need the min in there with memcpy and not with memcpy_s....but that's really not the language's responsibility to enforce...
We have a bit different ideas of what the language should do. And even if the language doesn't actually enforce that you don't run out of bounds (which even memcpy_s doesn't do), it can still make it easier to use correctly and harder to use incorrectly.
My take is that memcpy_s probably does that, and I think that's a worthwhile step to take, especially when it's almost free.
Let's say, If I only want to copy the first 3 bytes of src to dest, do I put in "3" for the source length or the destination length?
I would say that depends on the motivation. If it's because you only want the first 3 bytes of src, it should go in the source length. If it's because the destination buffer is only 3 bytes, it goes into the dest size.
(Of course, you'll probably do some testing before calling memcpy_s in the first place, because of what your sibling post said about there really being 3 sizes involved. To be completely defensive, you'll at least need to test it against whichever buffer size 3 replaces.)
And I'd better test that against the length of both first, because if the function fails, was it because there's only 2 bytes available in dest, or because there's only 2 available in src?
I would say that if you need to do those tests with memcpy_s, you need to do those tests before calling plain memcpy anyway, for almost any definition of "need".
OR, if I'm starting at byte 2 of src to dest, do I put "1" in for srcLength, because that's alll that's left in the array, or "3," because that's how big the array is? I know it probably should be the first one, but the people who don't know better, the people this function is theoretically trying to engineer against, probably will make the wrong choice, because they have it in their head the array is length "3" and this function wants to know the length of the array, right?
I can sort of see where you're coming from, in that the terminology we're using has shifted a little bit (from bytes-to-copy to sizes of buffers). However, I don't think this is that much of a greater issue than with plain memcpy. Also, the MS documentation for memcpy_s, while it uses a really crappy name for the second parameter, the name and description of the last one are about the same as for memcpy -- the number of bytes to copy. (It says "characters", but 1 char = 1 byte.)
This would definitely be somewhat reasonable, but I think that going from memcpy to memcpy_s gets you most of the benefit of your memcpy_s_s, for two reasons. First, it seems easier to maintain the invariant that the amount you're copying is smaller than the buffer its in then ensuring that the destination buffer is large enough, since the first two pieces of information (the size of the source buffer and the size of the data) are much more tightly coupled than the latter two pieces of information (the size of the data and the size of the destination buffer) often are.
Second, it's very often the case that the size of the source buffer and the size of the data are actually the same -- more common I'd wager than the size of the data and size of the destination buffer are.
I don't have a lot of development experience, but I do have some (including some kernel hacking). Forbidding use of memcpy seems like a good idea to me, but I'm not terribly confident in that. I'm much more confident that the article I was originally replying to makes an incredibly bad case for why it's not a good idea.
This is a really good point, but I still think that dropping pure memcpy has benefits.
In particular, what percentage of security bugs out there are caused by buffer overflows? I don't actually know, but it sure seems like a very large proportion. It seems reasonable to think that having a bug where you incorrectly overwrite memory (like what you have if you're using memcpy incorrectly) is much more likely to result in a security vulnerability than one where you stop copying partway through.
I'm not saying that the guy is wrong in his opinions, just that he expressed them incredibly poorly in that post.
The argument basically boils down to "there's already a size argument, so why do you need another one", but completely ignores the somewhat obvious reason why having another one might actually be a good idea. It doesn't present any additional arguments, and it doesn't refute mine.
And if you argue with a creationist, you'll accept their definition of "theory" just because that's what their dictionary says?
No, I would point out that the definition being used is the "a coherent group of general propositions used as principles of explanation for a class of phenomena" definition, not the "a proposed explanation whose status is still conjectural, in contrast to well-established propositions that are regarded as reporting matters of actual fact" definition.
I wouldn't argue that "theory" can't mean that, just that it doesn't in that case.
In the same way I'm not arguing that "hacker" can't mean "computer enthusiast" instead of "malicious cracker", just that it obviously doesn't in this thread.
That article is poorly written and poorly thought out.
If one length parameter is insufficient to prevent muppets from screwing up, what makes you think that adding more of the same is going to have any real effect.
There are two arrays to overflow, so passing in one length parameter requires (in the general case) taking the min first. In other words, this change turns 'memcpy(buf1, min(size1, size2), buf2)' into 'memcpy_s(buf1, size1, buf2, size2)'. Slightly simpler (IMO).
The more important step is that it will encourage programmers to actually attempt to track both size1 and size2. With memcpy, you have to go the extra mile to be safe because you have to actually include the call to min instead of just passing one of the parameters -- in other words, it's easier to be unsafe than it is to be safe. With memcpy_s, if you have both length parameters around, it's as easy to pass both as it is to not. If you don't, you have to make something up -- and just about every "something" I can think of will stand out pretty strongly as a sore thumb.
I think everybody in the Linux and MS-DOS-prompt community knows what a hacker is. However, I will supply you with a formal definition:
Why's that the definition we should be using? Are we in the Linux and MS-DOS community? Hell, even/. doesn't fall into that camp; last I heard (which was admittedly a good while ago) the majority of visitors here were using IE.
And I can also supply the definition for a hacker, from a bit more authoritative sources than uncyclopedia. One of Random House's definitions is "a microcomputer user who attempts to gain unauthorized access to proprietary computer systems." Or the American Heritage Dictionary: "One who uses programming skills to gain illegal access to a computer network or file."
Sure, both of these have the "computer enthusiast" definition preferred by ESR too, but that's my point -- words have more than one meaning. And unless you're not very familiar with English, stupid, or deliberately being obtuse, it's pretty clear which one is intended here.
And unless there's something big that Jamie Zawinski's wikipedia page leaves out, one of those applies to adolph (the poster I was responding to originally).
Because after all, we know that words only have one meaning, so if someone uses the word "hacker" one way, it must mean the same thing as when everyone uses the word hacker.
FF's memory usage patterns seem to be very dependent on the user and his luck.
I'm running FF 3.0.10 on Linux, and this is what top says:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17663 evaned 15 0 560m 311m 37m S 19.3 10.7 448:30.96 firefox-bin
(I'm so glad slashcode collapses spaces like that. Point being, FF is taking multiple hundreds of megs. This is with 20 tabs open. (Part of this could be flash's fault). Also, FF has been behaving very poor lately in general, so I'm often restarting it.)
The descent engine and ascent engine were entirely separate, since the entire descent stage of the LM was discarded on the moon for return. There were no interconnections between the two.
This doesn't surprise me at all. Nevertheless, I thought that maybe they kept a hookup in case they needed to burn a little longer on descent or something like that.
Thanks for the info.
That does not mean they couldn't have burned the DPS to exhaustion, staged, and then burned the APS for as long as required.
Since you seem to know something about this, was there anything else critical in the stage that was to be left on the moon? Any O2 tanks or anything like that, or was it just fuel?
Changing Apollo 13's course from what it was originally to a free-return course requires the merest nudge compared with the fuel required to change orbital planes like what would be required here.
Also, consider that the LEM had enough fuel in its descent engine to slow its descent and keep from smashing into the moon and an ascent engine to get it back up (though I don't know if the ascent engine fuel is usable by the descent engine).
It's been on the front page of CNN.com since the afternoon. Here's the story.
Searching "shuttle" on msnbc.com and foxnews.com shows that both of them are carrying the story too, though neither site has it "above the fold" right now.
It's not just the casting, though that was part of it. It was the fact that Java was occupying this weird (and to me, annoying) place that was mostly statically-typed, but you couldn't rely on that because whenever you had collections involved it ceased to be that way around the collections because if you had a Vector that was intended to hold Strings, you could put an Integer or something into it and it wouldn't be detected until (1) runtime (2) at the place you tried to pull out the integer.
I use collections enough that this became quite annoying. Even after 1.5 there are still vestages of the old dynamic ways. (In the Map class, the get() method takes an object instead of something of the Key's type. This actually caused a bug for me a bit ago; the program was small enough that figuring that out was the largest single part of programming it.)
Bascially, I saw Java (and see old Java) as occupying a niche taking the traditions of a C-like, statically typed, Simula-like class-based OO language and moving toward a dynamically typed language enough that you lost a lot of benefit of static typing while at the same time gaining nothing of the rapid-prototyping nature and general terseness that most dynamically-typed scripting languages have, and in fact making it worse over basically any language out there.
IMO Java's almost sole redeeming factors over C++ are that (1) it's memory-safe (encompasses bounds checking and GC), (2) a little more easily cross-platform, and (3) simpler. With use of the STL and things like smart pointers instead of native C concepts as much as you can I think (1) is a somewhat minimal benefit, (2) can be dealt with with a bit of care in when you compile on different platforms and use libraries like Qt or WxWidgets, and (3) is a real benefit -- but I'm already pretty versed in the intricacies of C++ so the simplicity doesn't benefit me a whole lot, especially if I'm working alone. For me, these benefits are rather outweighed by what I view as Java's heavy-handedness about what is good or bad programming practice (or at least what things they want to support), it's annoyingly verbose syntax, and other similar features.
What it comes down to is if I want a language that will result in programs that behave quickly, I'll choose C++ over Java for most things. If I don't care about performance, I'll choose a language like Lisp or Python which is easier, more fun, and terser to develop in than either of them.
Some of us are way more familiar with Java than you give us credit for, and still have a pretty strong aversion to the language.
The only people who this bothers are those still scared of Java 1.1 and Applets. Java moved past that point long, long ago.
IMHO the watershed moment in Java was 1.5, courtesy of generics which made the collections at least somewhat usable without constant swearing.
Re:Solution looking for a problem.
on
Cone of Silence 2.0
·
· Score: 3, Insightful
I wouldn't say that learning ASL exactly counts as simple. (Fun though... I took a semester of it in college just for the hell of it and it was pretty neat.)
But you could easily substitute "write what you want to say on paper, then shred it".
I see Ballmer chair jokes around here quite a bit, and between not being all that funny in the first place and going on for years(?), they have just become stupid. But yours actually works for some reason... I laughed a little. If I still had my last mod point that expired sometime in the last day, I'd have modded you up.
No company is allowed to mail to an address other than the Billing address on a credit card
First: I and the other people who have replied to you have bone it before, so even if it's prohibited by the CC agreement or whatever, it's pretty regularly violated
Second: You definitely can add additional, alternate shipping addresses to your card
Third: There's no excuse (other than "we're actively evil and are trying to screw you to save us a few bucks") for not giving that information instantly
With out a person to person sale there is no way to check I.D.
It's also the case that CC-merchant agreements prohibit vendors from checking your ID, so what good is having a physical person there going to do? (Barring violations of said agreement.)
Slashdot Mirror
User experience. Now that I've spent time on the Tex learning curve, and I can typically get it to do what I want, why would I want to get on another learning curve?
I've written hundreds of pages in Tex including an undergrad thesis, and I still run across things that are hard to do, or even impossible. Want to float an image to the side and have text wrap around it? Good luck. There are a couple packages out there for doing it, but I haven't had much luck in getting them to behave reasonably. For instance, with floatfig you have to figure out how much text will fit on the line preceding the figure, then put the figure at that point in the source, and it still won't typeset it entirely correctly because the line above won't be justified. And if you want to change what you say? Now you have to reposition the figure. This is something that Word has been able to do "good enough" and definitely far easier for long over a decade. Tables is something else that I always think are a PITA in LaTeX (and, FWIW, HTML) since oftentimes you can't really line up the columns in any sort of WYSIWYG form, which means that you often have to count "this is the 5th column, so I need to go past four &s in this row.
(Of course, there are a ton of things that LaTeX is better at. Math, overall typography, programmability, cross references, bibliographies. My point is that there are different tools for different jobs, and Word would be a more reasonable one for some tasks.
Our seventh sense is proprioception, derived from muscle feedback all over the body.
"Proprioception" is one of my favorite words (I'm disappointed to see it's not in the Firefox spell checking dictionary). I even coined the term "vehicular proprioception" for the "sense" of knowing how close you are to hitting stuff when you're driving around in a car. (I got pretty refined vehicular proprioception at my last apartment when it often took 3 or 4 drivereverse transitions to get out of my parking space because of short distances between cars.)
Cops do get in trouble, just like normal citizens do, if they lie under oath
Ah, but there are lots of things (like obstruction) that you can get charged with if you lie to a cop while not under oath.
The novelty of the problem IS part of the novelty of the solution though.
Because most of them would take most competent software engineers about 5 minutes to think up themselves if presented with the problem that the patent claims to be a solution to.
Sometimes, though, figuring out what the problem is, or even that there is a problem in the first place, is decidedly non-trivial.
I'm not nearly as anti-patent as most people around here are, and this patent is borderline at best IMO, but I do think it falls into this category.
I think you misunderstand his point... the 'size' parameter isn't the number of bytes in either buffer, it's the number of bytes you want to move. Obviously this has a lot to do with the size of either allocated buffer, but it's not the same thing.
That's right, but that doesn't change my argument. In the general case, if you wanted to use memcpy in a manner I would consider secure, you still need the min in there with memcpy and not with memcpy_s. ...but that's really not the language's responsibility to enforce...
We have a bit different ideas of what the language should do. And even if the language doesn't actually enforce that you don't run out of bounds (which even memcpy_s doesn't do), it can still make it easier to use correctly and harder to use incorrectly.
My take is that memcpy_s probably does that, and I think that's a worthwhile step to take, especially when it's almost free.
Let's say, If I only want to copy the first 3 bytes of src to dest, do I put in "3" for the source length or the destination length?
I would say that depends on the motivation. If it's because you only want the first 3 bytes of src, it should go in the source length. If it's because the destination buffer is only 3 bytes, it goes into the dest size.
(Of course, you'll probably do some testing before calling memcpy_s in the first place, because of what your sibling post said about there really being 3 sizes involved. To be completely defensive, you'll at least need to test it against whichever buffer size 3 replaces.)
And I'd better test that against the length of both first, because if the function fails, was it because there's only 2 bytes available in dest, or because there's only 2 available in src?
I would say that if you need to do those tests with memcpy_s, you need to do those tests before calling plain memcpy anyway, for almost any definition of "need".
OR, if I'm starting at byte 2 of src to dest, do I put "1" in for srcLength, because that's alll that's left in the array, or "3," because that's how big the array is? I know it probably should be the first one, but the people who don't know better, the people this function is theoretically trying to engineer against, probably will make the wrong choice, because they have it in their head the array is length "3" and this function wants to know the length of the array, right?
I can sort of see where you're coming from, in that the terminology we're using has shifted a little bit (from bytes-to-copy to sizes of buffers). However, I don't think this is that much of a greater issue than with plain memcpy. Also, the MS documentation for memcpy_s, while it uses a really crappy name for the second parameter, the name and description of the last one are about the same as for memcpy -- the number of bytes to copy. (It says "characters", but 1 char = 1 byte.)
This would definitely be somewhat reasonable, but I think that going from memcpy to memcpy_s gets you most of the benefit of your memcpy_s_s, for two reasons. First, it seems easier to maintain the invariant that the amount you're copying is smaller than the buffer its in then ensuring that the destination buffer is large enough, since the first two pieces of information (the size of the source buffer and the size of the data) are much more tightly coupled than the latter two pieces of information (the size of the data and the size of the destination buffer) often are.
Second, it's very often the case that the size of the source buffer and the size of the data are actually the same -- more common I'd wager than the size of the data and size of the destination buffer are.
I don't have a lot of development experience, but I do have some (including some kernel hacking). Forbidding use of memcpy seems like a good idea to me, but I'm not terribly confident in that. I'm much more confident that the article I was originally replying to makes an incredibly bad case for why it's not a good idea.
This is a really good point, but I still think that dropping pure memcpy has benefits.
In particular, what percentage of security bugs out there are caused by buffer overflows? I don't actually know, but it sure seems like a very large proportion. It seems reasonable to think that having a bug where you incorrectly overwrite memory (like what you have if you're using memcpy incorrectly) is much more likely to result in a security vulnerability than one where you stop copying partway through.
I'm not saying that the guy is wrong in his opinions, just that he expressed them incredibly poorly in that post.
The argument basically boils down to "there's already a size argument, so why do you need another one", but completely ignores the somewhat obvious reason why having another one might actually be a good idea. It doesn't present any additional arguments, and it doesn't refute mine.
And if you argue with a creationist, you'll accept their definition of "theory" just because that's what their dictionary says?
No, I would point out that the definition being used is the "a coherent group of general propositions used as principles of explanation for a class of phenomena" definition, not the "a proposed explanation whose status is still conjectural, in contrast to well-established propositions that are regarded as reporting matters of actual fact" definition.
I wouldn't argue that "theory" can't mean that, just that it doesn't in that case.
In the same way I'm not arguing that "hacker" can't mean "computer enthusiast" instead of "malicious cracker", just that it obviously doesn't in this thread.
That article is poorly written and poorly thought out.
If one length parameter is insufficient to prevent muppets from screwing up, what makes you think that adding more of the same is going to have any real effect.
There are two arrays to overflow, so passing in one length parameter requires (in the general case) taking the min first. In other words, this change turns 'memcpy(buf1, min(size1, size2), buf2)' into 'memcpy_s(buf1, size1, buf2, size2)'. Slightly simpler (IMO).
The more important step is that it will encourage programmers to actually attempt to track both size1 and size2. With memcpy, you have to go the extra mile to be safe because you have to actually include the call to min instead of just passing one of the parameters -- in other words, it's easier to be unsafe than it is to be safe. With memcpy_s, if you have both length parameters around, it's as easy to pass both as it is to not. If you don't, you have to make something up -- and just about every "something" I can think of will stand out pretty strongly as a sore thumb.
I think everybody in the Linux and MS-DOS-prompt community knows what a hacker is. However, I will supply you with a formal definition:
Why's that the definition we should be using? Are we in the Linux and MS-DOS community? Hell, even /. doesn't fall into that camp; last I heard (which was admittedly a good while ago) the majority of visitors here were using IE.
And I can also supply the definition for a hacker, from a bit more authoritative sources than uncyclopedia. One of Random House's definitions is "a microcomputer user who attempts to gain unauthorized access to proprietary computer systems." Or the American Heritage Dictionary: "One who uses programming skills to gain illegal access to a computer network or file."
Sure, both of these have the "computer enthusiast" definition preferred by ESR too, but that's my point -- words have more than one meaning. And unless you're not very familiar with English, stupid, or deliberately being obtuse, it's pretty clear which one is intended here.
And unless there's something big that Jamie Zawinski's wikipedia page leaves out, one of those applies to adolph (the poster I was responding to originally).
Yeah, with rsync you could backup one server to your other server. Surely that would be enough.
(I'm being a bit facetious, but I'm just trying to say that you have to be a bit careful about what you mean by "use rsync".)
Because after all, we know that words only have one meaning, so if someone uses the word "hacker" one way, it must mean the same thing as when everyone uses the word hacker.
FF's memory usage patterns seem to be very dependent on the user and his luck.
I'm running FF 3.0.10 on Linux, and this is what top says:
(I'm so glad slashcode collapses spaces like that. Point being, FF is taking multiple hundreds of megs. This is with 20 tabs open. (Part of this could be flash's fault). Also, FF has been behaving very poor lately in general, so I'm often restarting it.)
The descent engine and ascent engine were entirely separate, since the entire descent stage of the LM was discarded on the moon for return. There were no interconnections between the two.
This doesn't surprise me at all. Nevertheless, I thought that maybe they kept a hookup in case they needed to burn a little longer on descent or something like that.
Thanks for the info.
That does not mean they couldn't have burned the DPS to exhaustion, staged, and then burned the APS for as long as required.
Since you seem to know something about this, was there anything else critical in the stage that was to be left on the moon? Any O2 tanks or anything like that, or was it just fuel?
Don't know much about orbital mechanics, do you?
Changing Apollo 13's course from what it was originally to a free-return course requires the merest nudge compared with the fuel required to change orbital planes like what would be required here.
Also, consider that the LEM had enough fuel in its descent engine to slow its descent and keep from smashing into the moon and an ascent engine to get it back up (though I don't know if the ascent engine fuel is usable by the descent engine).
I read some article that said it was the latter -- putting it into a suicide path into the ocean.
See this AP article:
It's been on the front page of CNN.com since the afternoon. Here's the story.
Searching "shuttle" on msnbc.com and foxnews.com shows that both of them are carrying the story too, though neither site has it "above the fold" right now.
It's not just the casting, though that was part of it. It was the fact that Java was occupying this weird (and to me, annoying) place that was mostly statically-typed, but you couldn't rely on that because whenever you had collections involved it ceased to be that way around the collections because if you had a Vector that was intended to hold Strings, you could put an Integer or something into it and it wouldn't be detected until (1) runtime (2) at the place you tried to pull out the integer.
I use collections enough that this became quite annoying. Even after 1.5 there are still vestages of the old dynamic ways. (In the Map class, the get() method takes an object instead of something of the Key's type. This actually caused a bug for me a bit ago; the program was small enough that figuring that out was the largest single part of programming it.)
Bascially, I saw Java (and see old Java) as occupying a niche taking the traditions of a C-like, statically typed, Simula-like class-based OO language and moving toward a dynamically typed language enough that you lost a lot of benefit of static typing while at the same time gaining nothing of the rapid-prototyping nature and general terseness that most dynamically-typed scripting languages have, and in fact making it worse over basically any language out there.
IMO Java's almost sole redeeming factors over C++ are that (1) it's memory-safe (encompasses bounds checking and GC), (2) a little more easily cross-platform, and (3) simpler. With use of the STL and things like smart pointers instead of native C concepts as much as you can I think (1) is a somewhat minimal benefit, (2) can be dealt with with a bit of care in when you compile on different platforms and use libraries like Qt or WxWidgets, and (3) is a real benefit -- but I'm already pretty versed in the intricacies of C++ so the simplicity doesn't benefit me a whole lot, especially if I'm working alone. For me, these benefits are rather outweighed by what I view as Java's heavy-handedness about what is good or bad programming practice (or at least what things they want to support), it's annoyingly verbose syntax, and other similar features.
What it comes down to is if I want a language that will result in programs that behave quickly, I'll choose C++ over Java for most things. If I don't care about performance, I'll choose a language like Lisp or Python which is easier, more fun, and terser to develop in than either of them.
Some of us are way more familiar with Java than you give us credit for, and still have a pretty strong aversion to the language.
The only people who this bothers are those still scared of Java 1.1 and Applets. Java moved past that point long, long ago.
IMHO the watershed moment in Java was 1.5, courtesy of generics which made the collections at least somewhat usable without constant swearing.
I wouldn't say that learning ASL exactly counts as simple. (Fun though... I took a semester of it in college just for the hell of it and it was pretty neat.)
But you could easily substitute "write what you want to say on paper, then shred it".
I see Ballmer chair jokes around here quite a bit, and between not being all that funny in the first place and going on for years(?), they have just become stupid. But yours actually works for some reason... I laughed a little. If I still had my last mod point that expired sometime in the last day, I'd have modded you up.
No company is allowed to mail to an address other than the Billing address on a credit card
First: I and the other people who have replied to you have bone it before, so even if it's prohibited by the CC agreement or whatever, it's pretty regularly violated
Second: You definitely can add additional, alternate shipping addresses to your card
Third: There's no excuse (other than "we're actively evil and are trying to screw you to save us a few bucks") for not giving that information instantly
With out a person to person sale there is no way to check I.D.
It's also the case that CC-merchant agreements prohibit vendors from checking your ID, so what good is having a physical person there going to do? (Barring violations of said agreement.)
You just have to find a seller who knows that the computer's value is crap.
I bought a (yes, used) 2000-era laptop a year or two ago for $20. Where am I to get a new laptop for that price?