Sheesh. Yes, I was purposefully exaggerating the odds for humorous effect. You're only the eightieth person to note that, starting with the very first reply to my post.
You're right that I've never run memtest86 at all. I hadn't regularly worked with any hardware based on an Intel architecture until about two years ago, and haven't experienced any RAM problems in that relatively short period. That is the sole valid criticism in your post, and even that was redundant. The rest of your post consists of you putting words in my mouth that I did not say.
Regarding point A., many Linux systems do perform at least rudimentary RAM checks. What I said was that it is remotely possible that it got lucky and detected the problem during such screening, then flagged that page of physical RAM as defective. I never said anything about checking every write to RAM. That was you putting words in my mouth, and completely ludicrous words that I'd have to know almost nothing about hardware to say, at that. NIce straw man.
Regarding point B., that's not a baseless troll argument by any stretch of the imagination. First, running a lean Linux distro will almost certainly thrash pages around far less than 64-bit Vista simply because the OS uses far less RAM. Second, last time I used it, Linux wired down a -lot- of pages down in the kernel. All of those pages are just going to sit there. If anything, this was a criticism of Linux's tendency to wire too many pages, not any sort of "pro-Linux" comment. Maybe it might be taken to mean that Linux is less likely to eject pages belonging to one process in favor of another process---indeed, my experience has been that it does seem to do so less frequently than some other operating systems, though this can either be good or bad depending on the workload in question---but that was in no way implied by my previous comment, nor certainly was there any value judgment on my part as to whether such behavior is good or bad.
Likewise on point C., I was actually being harshly critical of Linux's power management, albeit without coming right out and saying it. Nowhere in my statement did I in ANY way insinuate that failing to switch into the lowest power states was in any way a good thing. It isn't. Poor power management leads to diminished battery life in portables and increased electric bills from computers of all types.
Before you go painting me as a pro-Linux troll, you need to learn some reading comprehension skills and stop trying to put words in my mouth. It only makes you look like a troll yourself.
Umm... given that you're talking about CCDs, odds are most of what you saw was thermal noise from the equipment itself and/or tiny fluctuations in the power rails, not cosmic rays. Also, you're talking about radically different voltages here---a device with an open face designed specifically to detect single photons versus a device inside a sealed package designed to reject outside interference operating at much higher threshold levels that has to swing by a volt or two to change states....
Thanks for clarifying that about memtest86. I was thinking of a different memory tester that basically does an mmap of gigabytes of RAM and beats on it. I forget the name of that one, not that it matters.
The reason for my confusion was that the original post says that in Ubuntu, "it ran fine for days". The problem is that the antecedent of the word "it" is unclear and could refer either to the computer and Ubuntu combination itself or to memtest86 running in Ubuntu. Without that critical piece of information about memtest86, it wasn't at all clear which of these was the intended meaning.
Ethernet uses a variable packet size that can be up to 1500 bytes. I don't think it gets padded out to 1500 bytes. I could be wrong, though. I am not that familiar with what happens down at that layer in Ethernet, and I had to look up the packet size/constancy even for ATM to confirm that I was remembering that correctly....
I should clarify that it would converge towards a couple of orders of magnitude for typical data, i.e. data fields containing just a few bytes apiece. That's why I said MIME should only be used if you are uploading large binary data blobs.
It doesn't really make sense to use MIME encoding until the overhead of URL encoding (two extra bytes per binary byte) exceeds the total length of all of the boundaries (including the extra copy at the start where the boundary is being defined) plus the total length of all of the content-length/disposition/type noise, so probably on the order of sixty or seventy bytes of binary data per field on average plus an extra fifty or sixty bytes for good measure. (This is all half-asleep math, so take it with a grain of salt.)
The amount of expansion depends on the size of the data elements, but it wouldn't be at all surprising to see MIME encoding waste a hundred bytes or more to store a one or two digit number. MIME encoding increases the size of the data itself by a relatively small amount. The problem is that it also adds field boundaries between each data field that are usually HUGE relative to the size of the data. By contrast, the field boundary for a GET or URL-encoded POST message is a single byte containing the ampersand character....
GET request (59 bytes total, 13 bytes for data fields):
GET http://www.example.com/x.cgi?name=Phil&score=3 HTTP/1.0
POST request (373 bytes total, 326 bytes for data fields):
POST http://www.example.com/x.cgi HTTP/1.0
Content-Type: multipart/form-data; boundary=-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-323947234702342374243
Content-Length: 209
Phil
-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3
23947234702342374243
Content-Disposition: form-data; name="score"
3
(Added bogus spaces in URLs so Slashdot wouldn't try to create links out of them. Oh, and apologies for the extra spaces in the middle of the boundaries that Slashdot adds for line wrapping purposes. There's nothing I can do about them.)
The boundary value used here is entirely made up, but it is in the same ballpark length-wise as some that I've seen generated by actual web browsers. I couldn't use a real one because Slashdot says it contains too many "junk" characters.... Yeah, that's kind of my point.:-):-):-)
So no, I was not exaggerating when I said it can balloon by orders of magnitude. In this case, it would be more than two orders of magnitude if you only look at the form data portion of the request. Thus, as the number of fields grows relative to the URL and initial protocol negotiation (which make up a significant portion of this trivial request), the bloat would tend to converge towards that limit, give or take....
The probability of a cosmic ray at precisely the right angle and speed to cause a single bit error and cause an app to crash is somewhere on the same order as your chances of getting hit by a car, getting struck by lightning, getting torn apart by rabid wolves, and having sex in the back of a red 1948 Buick convertible at a drive-in movie theater on Tuesday night, Feb. 29th under a blue moon... all at the same time.... Sure, given enough bits, it's bound to happen sooner or later, but it isn't something I'd worry about.:-)
The probability of RAM just plain being defective---failing to operate correctly due to bugs in handling of certain low power states, having actual bad bits, having insufficient decoupling capacitance to work correctly in the presence of power supply rail noise, etc---is probably several hundred thousand orders of magnitude greater (probably on the order of a one in several thousand chance of a given part being bad versus happening to a given part a few times before the heat death of the universe).
Memory test failures (other than mapping errors) are pretty much always caused by hardware failing. If running memtest86 in Linux works correctly for days, this probably means one of three things:
A. Linux is detecting the bad part and is mapping out the RAM in question.
B. The Linux VM system doesn't move things around RAM as much as Windows. Thus, random chunks of code don't end up there, and the few that do are in rarely used parts of background daemons or unused kernel modules so you don't notice the problem.
C. Linux power management isn't as rough on the RAM or CPU as Windows. Dodgy RAM/CPUs are most likely to fail when you take them through power state changes like putting the machine to sleep or switching the CPU into or out of an idle state. If Linux is making power state changes less frequently, is not using some of the lowest power states, is not stepping clock speeds, is not dropping the RAM refresh rate in sleep mode, etc., then you are less likely to see memory corruption. Similarly, power state changes can increase the rate of crashes due to a defective CPU or memory controller (northbridge).
I couldn't tell you which of these is the case without swapping out parts, of course. You should definitely take the time to replace whatever is bad even if it seems to be "working" in Linux. In the worst case, you have a few bad bits of RAM, they're somewhere in the middle of your disk cache in Linux, and you are slowly and silently corrupting data periodically on its way out to disk.... You definitely need to figure out what's wrong with the hardware and why it is only failing in Windows, and it sounds like the only way to do that is to swap out parts, boot into Windows, and see if the problem is still reproducible in under a couple of days, repeating with different part swaps until the problem goes away. Don't forget to try a different power supply.
Handing out copies of pages from a book that you own. Let's be clear. If you were ripping the pages out of your legally-purchased copy of a book, no one would complain.
I'm not assuming that fine-grained locks cause contention. I'm asserting that excessively fine-grained locks usually have very low contention and therefore often waste too many cycles handling the lock machinery relative to the amount of work you're actually getting done. Remember that at minimum, taking a mutex is going to require pulling in data from RAM unless it was recently touched. Therefore, there is a sizable hit for touching a lock that has no contention. With enough thrashing of even all non-contended locks, that penalty can be sizable. The sweet spot is in the middle somewhere, though the details do vary from architecture to architecture.
The best solution, of course, is to architect your code in a way that minimizes data dependencies and data sharing in general. This isn't always possible, but when it is, such a re-architected code base should perform much better than one built using mutex locks or even STM.
And even with the wink, this still got initially moderated "Interesting" instead of "Funny".... *sigh*
To clarify the joke for those who don't "GET" it, in HTTP, POST requests are either encoded the same way as GET requests (with some extra bytes) or using MIME encoding. If you use a GET request, the number of bytes sent should differ by... the extra byte in the word "POST" versus "GET" plus two extra CR/LF pairs and a CR/LF-terminated Content-length header, IIRC.... And if you use MIME encoding for the POST content, the size of the data balloons to orders of magnitude larger unless you are dealing with large binary data objects like a JPEG upload or something similar.
So basically, a POST request just hides the URL-encoded data from the user but sends almost exactly the same data over the wire.
Depending on your network type, you may not get any benefit from shorter URLs at all. Many networking protocols use fixed-size frames, which then get padded with zeroes up to the end of the frame. For example, in ATM networks, anything up to 48 bytes is a single frame, so depending on where that URL occurs relative to the start of a frame, it's possible that it would take a 48 byte URL to cause even one extra frame to be sent.
Either way, this is like complaining about a $2 budget overrun on a $2 billion project. Compared with the benefits of compressing the text content, moving all your scripts into separate files so they can be cached (Facebook sends over 4k of inline JavaScript with every page load for certain pages), generating content dynamically in the browser based on high density XML without all the formatting (except for the front page, Facebook appears to be predominantly server-generated HTML), removing every trace of inline styles (Facebook has plenty), reducing the number of style sheet links to a handful (instead of twenty), etc., the length of URLs is a trivial drop in the bucket.
No, but if you always handed out the first page, it might. You'd probably need to show some reasonable purpose for doing so, though, e.g. scholarly research and criticism. I don't think BitTorrent will pass even such a low bar. And the fact that you'd be handing out every page, merely handing out different ones to different people, makes this defense prima facie laughable, IMHO. Hope they have some more subtle arguments that I'm not seeing. Otherwise, that seems like a really weak defense to me.
The key is to find the right balance of granularity in locking. A big giant mutex is always a bad idea, but having tens of thousands of little mutexes can also be bad due to footprint bloat and the extra time needed to lock all those locks. The right balance is usually somewhere in the middle. Each lock should have a moderate level of contention---not too little contention or else you're wasting too much time in locking and unlocking the mutex relative to the time spent doing the task---not too much contention or else you're likely wasting time waiting for somebody else that is doing something that wouldn't really have interfered with what you're doing at all. Oh, and reader-writer locks for shared resources can be a real win, too, in some cases.
And this, friends, is a prime example of why government should NEVER under ANY CIRCUMSTANCES attempt to legislate a solution to a technical problem, no matter how tempting it will be. We're on track to have all vehicles be electric or hybrid within probably a decade. At that point, heating systems will be electric and will drain power just like air conditioning systems.
Once we are mostly electric, for every day when you would have used your heat, you are losing just as much extra energy from the extra reflection as you saved during the time when you would have used your A/C. For much of California, this change would be a net loss at that point. And this, of course assumes that every vehicle uses a reversing heat pump for the heating. For vehicles that don't come with an A/C at all, the heat would be in the form of resistance heating, which would make it a HUGE net loss to block the sun.
It's just like the notion of saving energy by forcing everyone to stop selling incandescent light bulbs, and for precisely the same reason. (Not to mention lots of other reasons.)
Seems like it would be more useful for people to query the database about other people in certain other African countries... which you would send about ten seconds after you get this message:
Hello, you may find this letter surprising as we have not met yet. My name is [name], and I am the executor of the estate of [name], the exiled Prime Minister of [country]. I have in my bank's possession the sum of one million ($1,000,000) USD dollars, but we cannot transfer it to the family because it would be confiscated....
Just a guess, but those questions are probably designed as some sort of a baseline to gauge the level of expected inconsistency among other answers. For example, if you answer "yes" to "I like mechanical magazines" but answer "no" to "I like repairing a door latch," then they can expect a greater level of inconsistency in your other answers, as it indicates your answers to the questions are more nuanced than average and so some seemingly contradictory answers may have explanations other than the obvious "this person is lying".
I didn't think anything would prevent the constant production of a net positive of rabbits, provided that the number of rabbits of each gender is at least 1....
My experience is the opposite. Open source projects are either alive or dead. If they are dead, don't bother trying to get support or fixes. It's just like a company that has dropped the project. If they are active, you can usually submit patches or bug reports and get at least a semi-timely fix.
With closed source, at least if you're talking about software targeted at end users, I have complained about major (as in "won't install" at all) failures in major products by Adobe, MakeMusic, etc. that haven't been fixed after anywhere from six months to two years.
In my experience, unless hundreds of people are screaming about a problem, closed source developers can't be bothered to fix it, and sometimes even then. They spend as little time as possible on bug fixes and focus exclusively on features because that's what sells products. You could have 1000 customers complaining about lack of support for case-sensitive filesystems and it still wouldn't be a big enough percentage of their installed base for them to care. People started complaining about this in Photoshop CSS2. CSS4 is out and it still won't install on case-sensitive HFS+. Their answer is to reformat your hard drive. After all, you can't possibly have anything more important to do with your computer than use their application. They are the center of the universe.
I can't see much chance that such a trivial set of bug fixes would get punted for two major releases in ANY open source project. With open source, bug reports like that usually get a quick response from developers, assuming the project is active. If they cannot test on such a setup, they will at least offer to let you fix it and submit patches. Either way, those sorts of bugs usually get fixed in open source very rapidly, while they usually get punted for several releases in hopes the problem will magically go away in closed source....
You can't compare an essentially dead open source app to an actively developed commercial app. That's just not a fair comparison. If you want to use a dead open source app as your open source example, you need to use something like OpenDoc as your closed source example....
If the companies are not complicit, they will yank the server offline the moment they get a couple of spam complaints from the recipient. That usually translates to about 3-5 minutes after their client sends me spam. It takes about that long for me to do the whois lookup of their ISP and compose an appropriately worded email message.... Thus, it is unlikely that spammers will pay for real servers unless the hosting providers are well aware of what is going on and merely do not care.
Slashdot Mirror
Sheesh. Yes, I was purposefully exaggerating the odds for humorous effect. You're only the eightieth person to note that, starting with the very first reply to my post.
You're right that I've never run memtest86 at all. I hadn't regularly worked with any hardware based on an Intel architecture until about two years ago, and haven't experienced any RAM problems in that relatively short period. That is the sole valid criticism in your post, and even that was redundant. The rest of your post consists of you putting words in my mouth that I did not say.
Regarding point A., many Linux systems do perform at least rudimentary RAM checks. What I said was that it is remotely possible that it got lucky and detected the problem during such screening, then flagged that page of physical RAM as defective. I never said anything about checking every write to RAM. That was you putting words in my mouth, and completely ludicrous words that I'd have to know almost nothing about hardware to say, at that. NIce straw man.
Regarding point B., that's not a baseless troll argument by any stretch of the imagination. First, running a lean Linux distro will almost certainly thrash pages around far less than 64-bit Vista simply because the OS uses far less RAM. Second, last time I used it, Linux wired down a -lot- of pages down in the kernel. All of those pages are just going to sit there. If anything, this was a criticism of Linux's tendency to wire too many pages, not any sort of "pro-Linux" comment. Maybe it might be taken to mean that Linux is less likely to eject pages belonging to one process in favor of another process---indeed, my experience has been that it does seem to do so less frequently than some other operating systems, though this can either be good or bad depending on the workload in question---but that was in no way implied by my previous comment, nor certainly was there any value judgment on my part as to whether such behavior is good or bad.
Likewise on point C., I was actually being harshly critical of Linux's power management, albeit without coming right out and saying it. Nowhere in my statement did I in ANY way insinuate that failing to switch into the lowest power states was in any way a good thing. It isn't. Poor power management leads to diminished battery life in portables and increased electric bills from computers of all types.
Before you go painting me as a pro-Linux troll, you need to learn some reading comprehension skills and stop trying to put words in my mouth. It only makes you look like a troll yourself.
Umm... given that you're talking about CCDs, odds are most of what you saw was thermal noise from the equipment itself and/or tiny fluctuations in the power rails, not cosmic rays. Also, you're talking about radically different voltages here---a device with an open face designed specifically to detect single photons versus a device inside a sealed package designed to reject outside interference operating at much higher threshold levels that has to swing by a volt or two to change states....
Thanks for clarifying that about memtest86. I was thinking of a different memory tester that basically does an mmap of gigabytes of RAM and beats on it. I forget the name of that one, not that it matters.
The reason for my confusion was that the original post says that in Ubuntu, "it ran fine for days". The problem is that the antecedent of the word "it" is unclear and could refer either to the computer and Ubuntu combination itself or to memtest86 running in Ubuntu. Without that critical piece of information about memtest86, it wasn't at all clear which of these was the intended meaning.
The word you're looking for here is "hyperbole". :-)
Ethernet uses a variable packet size that can be up to 1500 bytes. I don't think it gets padded out to 1500 bytes. I could be wrong, though. I am not that familiar with what happens down at that layer in Ethernet, and I had to look up the packet size/constancy even for ATM to confirm that I was remembering that correctly....
I should clarify that it would converge towards a couple of orders of magnitude for typical data, i.e. data fields containing just a few bytes apiece. That's why I said MIME should only be used if you are uploading large binary data blobs.
It doesn't really make sense to use MIME encoding until the overhead of URL encoding (two extra bytes per binary byte) exceeds the total length of all of the boundaries (including the extra copy at the start where the boundary is being defined) plus the total length of all of the content-length/disposition/type noise, so probably on the order of sixty or seventy bytes of binary data per field on average plus an extra fifty or sixty bytes for good measure. (This is all half-asleep math, so take it with a grain of salt.)
The amount of expansion depends on the size of the data elements, but it wouldn't be at all surprising to see MIME encoding waste a hundred bytes or more to store a one or two digit number. MIME encoding increases the size of the data itself by a relatively small amount. The problem is that it also adds field boundaries between each data field that are usually HUGE relative to the size of the data. By contrast, the field boundary for a GET or URL-encoded POST message is a single byte containing the ampersand character....
GET request (59 bytes total, 13 bytes for data fields):
GET http: //www.example.com/x.cgi?name=Phil&score=3 HTTP/1.0
POST request (373 bytes total, 326 bytes for data fields):
POST http: //www.example.com/x.cgi HTTP/1.0
Content-Type: multipart/form-data; boundary=-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-323947234702342374243
Content-Length: 209
-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3 23947234702342374243
Content-Disposition: form-data; name="name"
Phil
-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3 23947234702342374243 Content-Disposition: form-data; name="score"
3
(Added bogus spaces in URLs so Slashdot wouldn't try to create links out of them. Oh, and apologies for the extra spaces in the middle of the boundaries that Slashdot adds for line wrapping purposes. There's nothing I can do about them.)
The boundary value used here is entirely made up, but it is in the same ballpark length-wise as some that I've seen generated by actual web browsers. I couldn't use a real one because Slashdot says it contains too many "junk" characters.... Yeah, that's kind of my point. :-) :-) :-)
So no, I was not exaggerating when I said it can balloon by orders of magnitude. In this case, it would be more than two orders of magnitude if you only look at the form data portion of the request. Thus, as the number of fields grows relative to the URL and initial protocol negotiation (which make up a significant portion of this trivial request), the bloat would tend to converge towards that limit, give or take....
The probability of a cosmic ray at precisely the right angle and speed to cause a single bit error and cause an app to crash is somewhere on the same order as your chances of getting hit by a car, getting struck by lightning, getting torn apart by rabid wolves, and having sex in the back of a red 1948 Buick convertible at a drive-in movie theater on Tuesday night, Feb. 29th under a blue moon... all at the same time.... Sure, given enough bits, it's bound to happen sooner or later, but it isn't something I'd worry about. :-)
The probability of RAM just plain being defective---failing to operate correctly due to bugs in handling of certain low power states, having actual bad bits, having insufficient decoupling capacitance to work correctly in the presence of power supply rail noise, etc---is probably several hundred thousand orders of magnitude greater (probably on the order of a one in several thousand chance of a given part being bad versus happening to a given part a few times before the heat death of the universe).
Memory test failures (other than mapping errors) are pretty much always caused by hardware failing. If running memtest86 in Linux works correctly for days, this probably means one of three things:
I couldn't tell you which of these is the case without swapping out parts, of course. You should definitely take the time to replace whatever is bad even if it seems to be "working" in Linux. In the worst case, you have a few bad bits of RAM, they're somewhere in the middle of your disk cache in Linux, and you are slowly and silently corrupting data periodically on its way out to disk.... You definitely need to figure out what's wrong with the hardware and why it is only failing in Windows, and it sounds like the only way to do that is to swap out parts, boot into Windows, and see if the problem is still reproducible in under a couple of days, repeating with different part swaps until the problem goes away. Don't forget to try a different power supply.
Handing out copies of pages from a book that you own. Let's be clear. If you were ripping the pages out of your legally-purchased copy of a book, no one would complain.
I'm not assuming that fine-grained locks cause contention. I'm asserting that excessively fine-grained locks usually have very low contention and therefore often waste too many cycles handling the lock machinery relative to the amount of work you're actually getting done. Remember that at minimum, taking a mutex is going to require pulling in data from RAM unless it was recently touched. Therefore, there is a sizable hit for touching a lock that has no contention. With enough thrashing of even all non-contended locks, that penalty can be sizable. The sweet spot is in the middle somewhere, though the details do vary from architecture to architecture.
The best solution, of course, is to architect your code in a way that minimizes data dependencies and data sharing in general. This isn't always possible, but when it is, such a re-architected code base should perform much better than one built using mutex locks or even STM.
And even with the wink, this still got initially moderated "Interesting" instead of "Funny".... *sigh*
To clarify the joke for those who don't "GET" it, in HTTP, POST requests are either encoded the same way as GET requests (with some extra bytes) or using MIME encoding. If you use a GET request, the number of bytes sent should differ by... the extra byte in the word "POST" versus "GET" plus two extra CR/LF pairs and a CR/LF-terminated Content-length header, IIRC.... And if you use MIME encoding for the POST content, the size of the data balloons to orders of magnitude larger unless you are dealing with large binary data objects like a JPEG upload or something similar.
So basically, a POST request just hides the URL-encoded data from the user but sends almost exactly the same data over the wire.
Depending on your network type, you may not get any benefit from shorter URLs at all. Many networking protocols use fixed-size frames, which then get padded with zeroes up to the end of the frame. For example, in ATM networks, anything up to 48 bytes is a single frame, so depending on where that URL occurs relative to the start of a frame, it's possible that it would take a 48 byte URL to cause even one extra frame to be sent.
Either way, this is like complaining about a $2 budget overrun on a $2 billion project. Compared with the benefits of compressing the text content, moving all your scripts into separate files so they can be cached (Facebook sends over 4k of inline JavaScript with every page load for certain pages), generating content dynamically in the browser based on high density XML without all the formatting (except for the front page, Facebook appears to be predominantly server-generated HTML), removing every trace of inline styles (Facebook has plenty), reducing the number of style sheet links to a handful (instead of twenty), etc., the length of URLs is a trivial drop in the bucket.
No, but if you always handed out the first page, it might. You'd probably need to show some reasonable purpose for doing so, though, e.g. scholarly research and criticism. I don't think BitTorrent will pass even such a low bar. And the fact that you'd be handing out every page, merely handing out different ones to different people, makes this defense prima facie laughable, IMHO. Hope they have some more subtle arguments that I'm not seeing. Otherwise, that seems like a really weak defense to me.
The key is to find the right balance of granularity in locking. A big giant mutex is always a bad idea, but having tens of thousands of little mutexes can also be bad due to footprint bloat and the extra time needed to lock all those locks. The right balance is usually somewhere in the middle. Each lock should have a moderate level of contention---not too little contention or else you're wasting too much time in locking and unlocking the mutex relative to the time spent doing the task---not too much contention or else you're likely wasting time waiting for somebody else that is doing something that wouldn't really have interfered with what you're doing at all. Oh, and reader-writer locks for shared resources can be a real win, too, in some cases.
And this, friends, is a prime example of why government should NEVER under ANY CIRCUMSTANCES attempt to legislate a solution to a technical problem, no matter how tempting it will be. We're on track to have all vehicles be electric or hybrid within probably a decade. At that point, heating systems will be electric and will drain power just like air conditioning systems.
Once we are mostly electric, for every day when you would have used your heat, you are losing just as much extra energy from the extra reflection as you saved during the time when you would have used your A/C. For much of California, this change would be a net loss at that point. And this, of course assumes that every vehicle uses a reversing heat pump for the heating. For vehicles that don't come with an A/C at all, the heat would be in the form of resistance heating, which would make it a HUGE net loss to block the sun.
It's just like the notion of saving energy by forcing everyone to stop selling incandescent light bulbs, and for precisely the same reason. (Not to mention lots of other reasons.)
Seems like it would be more useful for people to query the database about other people in certain other African countries... which you would send about ten seconds after you get this message:
Hello, you may find this letter surprising as we have not met yet. My name is [name], and I am the executor of the estate of [name], the exiled Prime Minister of [country]. I have in my bank's possession the sum of one million ($1,000,000) USD dollars, but we cannot transfer it to the family because it would be confiscated....
Just a guess, but those questions are probably designed as some sort of a baseline to gauge the level of expected inconsistency among other answers. For example, if you answer "yes" to "I like mechanical magazines" but answer "no" to "I like repairing a door latch," then they can expect a greater level of inconsistency in your other answers, as it indicates your answers to the questions are more nuanced than average and so some seemingly contradictory answers may have explanations other than the obvious "this person is lying".
That's what I was thinking of, too. Then Bullwinkle accidentally pulls a lion out. "Whoops. Must have been the wrong tank."
I didn't think anything would prevent the constant production of a net positive of rabbits, provided that the number of rabbits of each gender is at least 1....
Where I come from, they're called potheads.
If they pull a rabbit out of a deuterium tank, that's going to be one seriously pissed off rabbit.
My experience is the opposite. Open source projects are either alive or dead. If they are dead, don't bother trying to get support or fixes. It's just like a company that has dropped the project. If they are active, you can usually submit patches or bug reports and get at least a semi-timely fix.
With closed source, at least if you're talking about software targeted at end users, I have complained about major (as in "won't install" at all) failures in major products by Adobe, MakeMusic, etc. that haven't been fixed after anywhere from six months to two years.
In my experience, unless hundreds of people are screaming about a problem, closed source developers can't be bothered to fix it, and sometimes even then. They spend as little time as possible on bug fixes and focus exclusively on features because that's what sells products. You could have 1000 customers complaining about lack of support for case-sensitive filesystems and it still wouldn't be a big enough percentage of their installed base for them to care. People started complaining about this in Photoshop CSS2. CSS4 is out and it still won't install on case-sensitive HFS+. Their answer is to reformat your hard drive. After all, you can't possibly have anything more important to do with your computer than use their application. They are the center of the universe.
I can't see much chance that such a trivial set of bug fixes would get punted for two major releases in ANY open source project. With open source, bug reports like that usually get a quick response from developers, assuming the project is active. If they cannot test on such a setup, they will at least offer to let you fix it and submit patches. Either way, those sorts of bugs usually get fixed in open source very rapidly, while they usually get punted for several releases in hopes the problem will magically go away in closed source....
You can't compare an essentially dead open source app to an actively developed commercial app. That's just not a fair comparison. If you want to use a dead open source app as your open source example, you need to use something like OpenDoc as your closed source example....
Obviously the company should confirm that the complaints are legitimate, but that usually doesn't take long.
If the companies are not complicit, they will yank the server offline the moment they get a couple of spam complaints from the recipient. That usually translates to about 3-5 minutes after their client sends me spam. It takes about that long for me to do the whois lookup of their ISP and compose an appropriately worded email message.... Thus, it is unlikely that spammers will pay for real servers unless the hosting providers are well aware of what is going on and merely do not care.