If the machine is clearly showing the check mark going wrong, it's a bug, not a conscious attempt to manipulate the vote.
Exactly right. Any competent programmer who is implementing a biased count would show the actual vote on the screen. The code would then, with some probability (perhaps just a counter) would add certain votes to the wrong candidate in the internal sum. Those sums aren't shown to the voter, of course, so they'll never suspect.
It's a bit trickier if there's some sort of paper trail or other scheme to do a recount. The code has to come up with the same "mistakes" in a recount. Doing this is more of a technical challenge. But I suppose we have lots of people here who would be (or have been) up to the task.
This case was probably some sort of incorrect lookup table, off-by-one indexing, or similar simple coding error.
The problem: we're the only Western democracy that allows for partisan election commissions.
Nah; we're just the only one that encourages election commissioners to publicly state their bias.
In the others, if you're a partisan who wants to be an election commissioner, you just learn enough of your opponent's buzz phrases to fool the interviewers. Then, once you're on the commission, you can look for ways to implement your bias without being noticed.
When it comes to such matters as election outcomes, you should never assume that people are telling you the truth.
You might have also added the report's authors comments that their methods and assumptions were generally "conservative". Combine this with their openness about the size of their sample and the error bars. We would expect that their errors are biased towards an underestimate, and when they publish their followup study with more data, it will probably turn out that the number of fatalities is even higher.
Of course, we don't know that yet. Getting good data out of a war zone is traditionally rather difficult.
One of my favorite bits of advice to scientists is that the most important part of any paper is the paragraph near the end that says "More research is needed..."
Unlike most other sources of numbers in Iraq, this group is fairly open about their methods, limits and accuracy. So their numbers are inherently more credible than most that you'll read.
It'll be interesting to see if they'll be able to collect data for a followup paper. There's gotta be a number of people with weapons who want to stop them.
... i would be happy to give the benefit of the doubt - if it wasn't for that 2000 election BS
But this is hardly anything new. If you've been paying attention in previous US elections, you'll have noticed many cases like this. Thus, in the 2000 election here in Boston, there was a news story of the discovery of 20,000 "missing" ballots in one precinct. Similar stories pop up all over. The attitude of the people running the election is basically "Oops; sorry about that." It's hard to avoid the impression of "Well, we were caught, so we'll have to count that batch."
The obvious question is "How many others are never discovered?" Hard to tell. But when I read about blocks of thousands of ballots that were somehow "misplaced", it's hard to avoid the obvious suspicion. Is it really true that only 50% or 60% of the people actually vote? Or are 30% to 40% of the ballots "lost" and never counted?
In Florida, they seem to be openly thumbing their noses at the voters by having so many ballots disappear. It's like they don't even need to pretend any more. They know that the worst that can happen is that they'll have to "discover" and count a few of the votes. But nobody will ever be punished for such things.
[Hemp] seed is very high in proteins, tasty and nutty--you can buy these at some health food stores as nut butters etc. (local restrictions may apply!).
You can also buy hemp seen in most pet stores in the US. Our cockatiels love it. Actually, they prefer millet, but they will eat a good amount of hemp seed for variety.
Unfortunately for potential human growers, the seed sold in pet stores is generally sterilized, now mostly be being irradiated. But this is better for your bird, since it kills off most disease organisms and insect eggs.
Heh. That one did always strike me as a sign of some sort of perverse humor inside IBM. After, all, the page obvious wasn't blank...
But then, I've always liked statements like "This statement is false."
The main problem with most documentation, of course, is the extreme difficulty of finding an answer to the question you have at hand. I've always like the the observation that most computer documents are good at answering questions of the form "I'd really like to use the foo command; I wonder what it does." But hardly anyone ever asks questions in that form. They ask "How do I get this machine to do bar?", where it turns out that bar is equivalent to foo. But the two use totally different keywords, so the lookup tools can't tell you that you want the foo command.
IBM has always supplied copious documentation. But you can hardly ever find the answer to your question. You know that it's probably somewhere in those N shelves of documents, but you can't find it.
Which reminds me of a clever remark someone made a few years ago: By now, chances are that anything you want to know is somewhere on the Web - but you can't find it.
Yeah, google helps - a little. If you guess the right keywords. And if there's no other topic that uses the same keywords.
IBM was in a fortunate position of being a major hardware vendor and therefore capable of switching revenue stream focus.
True, perhaps, but it's not the full story. IBM has always made a major portion of its income from customer support. They have often given away software, or sold it at a low, nominal cost, and offered support contracts. They figured out long ago that this is the best way to make money with software.
(It helps if your documentation is crappy. Then your customers can't make much sense of it, and have to hire an expert to make it work. But Microsoft and the Open Source community are both there already.;-)
This is, of course, how the commercial linux vendors make their money. It's hardly a new idea. Microsoft is already making a lot of money from support. It really wouldn't be that much of a stretch for them to start offering support contracts for "free" software.
"Hey, you can get a very popular web server at apache.org that's simpler than IIS (and, frankly, doesn't have as many security holes, but don't tell my boss I said that). We can install and support it for you if you'd like. Shall we add it to the purchase order?"
...; it's almost as if the distro with the highest price tag does the best in the biz market.
Yup. Of course, this happens in the retail market, too, with a great many products (including computers). It goes along with the oft-heard claim that "You get what you pay for." This is another way of saying that if something costs more, it must be better. The fashion industry is very familiar with this fallacy, and they make a lot of money off it, as does Microsoft (and IBM) with their office products.
I've long thought that, if the linux crowd really wants to crash the office-software party, distributers like Red Hat, Suse, etc. should charge more than Microsoft. When people question the price for what is supposed to be "free" software, just say that you can get it all for free off the company's web site, but you don't get support with that. And point out that you can get Microsoft's software for free too. It's called "piracy". Nearly everyone does it, and you don't get support with that software either.
What might be the clincher is to point out that, when you pirate MS software, you have to worry about them suing you when they find out. When you pirate linux software, you get it from the vendor's site, with their blessing. If you want support, you'll have to pay for it in both cases. The difference is that the linux crowd doesn't make legal threats against their customers. What's the same is that, if you pay, what you're paying for is future support if you need help.
Of course, if you want to charge a higher price than MS, you should provide better support. But anyone who has tried to deal with MS's support people knows that you don't actually have to be very good to do this.
(I've also had a few dealings with Apple's customer support, and I'd say that, while they may be better than Microsoft, it would still be pretty easy to be better than them, too.;-)
Become an electrician or a plumber. That's where the real money is made.
There's an old joke about a doctor who hired a plumber to do some work on his bathroom. When the job was done, the plumber handed the doctor the bill for his services.
The doctor looked at the bill in shock. "I don't make this much per hour and I'm a doctor."
The plumber replied: "I didn't, either, when I was a doctor."
- it's dark over there right now and all the programmers are all tucked away in bed dreaming dreams of python function calls.
Um, if they were Real Programmers, they'd consider working at 2 am totally normal.
The problem with programmers in the US is that, during "normal" working hours (especially the afternoon), they're almost totally non-productive, because that's their usual sleep time.
The password will be sent in from that keystroke logger that was installed a few months ago.
(You just aren't paranoid enough. Your Windows box probably has 5 or 6 such loggers already, not counting the ones that came pre-installed. That's why your keyboard response has gotten so slow.;-)
From the fact that they're using IE. Of course, it used to be that you had to trick them into opening an attachment to get your code run on their machine. Now, it seems, all you need to do is send them a JPEG file.
A few will be up to date with their patches, so none of this will work. But probably not enough of them to skew the statistics significantly, if history is any guide.
..., but now that the Windows floodgates are open, I suspect that they will put an end to this very quickly.
Note especially the comment that "GMail Drive... enables you to save and retrieve files stored on your GMail account directly from inside Windows Explorer.
It's only a matter of time until a message is developed that, when sent to a gmail account, installs software that lets remote software use the account as a relay. Soon thereafter, all those gmail accounts of Windows users will become the Net's biggest anonymizing spam relay.
It'll be fun to watch the gmail developers try to program their way out of this one...
Sounds like you made the bigger error.... Your post only illustrates the fact that developers cause a substantial part of the disconnect between themselves and management.
Well, I can see why you'd read it that way. But I don't think this is really accurate. One reason is that I'd merely mentioned the idea of a second server, as a "throwaway" comment. Nobody reacted, so I mentally shrugged, and Just Did It.
Another reason that I didn't mention was that the project had earlier had a relevant problem: The management had decreed that we were to use a specific web server (which shall remain nameless here). This shows that they were aware that a web server is software. But the group was unable to make the server work properly. It's config GUI was just too ornate, and we couldn't get it right. One day I nabbed a copy of apache, compiled and configged it, and 20 minutes later we had a functioning web server that never failed us. So again, a "web server" was a piece of software that I'd installed on the machine. The managers was well aware of this, and eventually went with apache (though not happily). So there was no reason to suspect any difference in terminology within the team. We regularly used "the web server" to mean the copy of apache running on our test machine.
Given that this was (mostly) a software-development project, there was every reason to believe that we had a common understanding of our common terms. The misunderstanding over whether "web server" was software or hardware came as a surprise to most of us.
If anything, this is mostly an example of how a misunderstanding can arise without anyone suspecting. Then someone does something that just doesn't make sense, until you realize that there's a difference in how some people understand a bit of jargon.
And recall that the original comment here was suggesting that managers should listen with mouth shut. I was giving an example where that failed. Actually, it didn't quite fail, because someone opened their mouth soon enough, and I corrected the misunderstanding. But it's still a useful example of why you should at least talk a little, to make sure that you are really talking the same language.
In any case, a quick google for "shielded wallet" turned up several that are for sale now. Here's a site that sells them and assorted items of shielding clothing. The wallet is down the page a bit.
This has all been available for some years, actually. As mentioned in this site's blurbs, there are a lot of environments where one might want your wallet's contents to be shielded from the sort of EM fields that can damage things like magnetic stripes. The same shielding will prevent anyone from reading RFID tags embedded in your cards.
I don't have any association with this site, and didn't even know it existed until now. It does give you a clue that people have been thinking of this sort of problem for some time, and for several reasons. But it's not new at all. Back in the 70's, I knew some CS people for several computer vendors who had shielded clothing. They worked around a lot of equipment that produced stray magnetic fields, which could have unpleasant effects on things like a mag tape in your pocket.
One problem with this: By listening with your mouth closed, you run a very real risk of misunderstanding what you're hearing. Without feedback to verify that you're understanding, you are highly likely to do things completely wrong.
Funny example: A few years ago, I was implementing an interactive web site, and we had a nice test server machine in the lab. In one discussion with The Mgt, I casually mentioned that for testing, I thought we needed to run another server.
I didn't hear any response, so I went ahead and cloned the apache server that we were using, and fired it up on a different port. 10 minutes work, and we proceeded to test.
A while later, I discovered just in time that the managers had heard me say that we needed a second server machine, and were ordering another one. After a bit of discussion, I realized that to them, a server is a piece of hardware, while to us software guys, it is a piece of software.
I managed to explain to them that, no, we didn't need a new machine. I'd already set up a second web server on the old machine, and it was working fine. There was still time to cancel the hardware order.
But still, they had done a bunch of unnecessary work, and had almost spent a good sum of money unnecessarily, all because they had listened carefully without asking questions. If they had asked what hardware the new server needed, I'd have realized quickly that there was a misunderstanding, and we could all have saved a bit of time.
Listening without interacting, and acting on your understanding of what you heard, can lead to a lot of serious problems.
you want the tests written by people who *didn't* write the code.
Correct in theory. But in practice, I always write a test suite while writing the main code. It's the fastest way to get the job done. When the inevitable change requirements come along, I have a regression test suite that helps make sure I haven't broken the earlier cases.
And, when it comes time for the QA people to write tests for my stuff, their tests are always a proper subset of mine. Over several decades of software development, I've yet to see a single case of the QA folks testing something that I'm not already testing.
This shouldn't be a surprise, since I know more about the code (and usually the task) than any of them do. This is because they're madly trying to come up to speed on the requirements, while juggling the testing of N other pieces of code, and not enough time to do the job right. I've been there ahead of them so of course I know more about it.
What usually happens is that the QA folks quickly realize this, and they start asking me for a copy of my test suite. I tell them I'd be happy to hand it over, if they'll also give me any new tests they devise. As a result, I tend to get along with the QA people better than most of the other developers.
Frankly, the QA people have a very difficult job, and all the worlds' wonderful management theories don't do much to help them. Sensible developers will short-circuit the task by cooperating with the testers.
Now if there were only some practical way to automate GUI tests. I've used a number of packages that claim to do this. I wonder if there are any that actually work for more than the most trivial cases? Short of an AI-enabled robot, it's hard to imagine how one might test responses to the things that humans actually do with keyboards, mice, trackpads, etc.
Nope; not strange at all. Of course, it would be more accurate to say that birds (Aves) are a clade of the Dinosauria, but that would probably be a bit picky for/.'s style.
While the evidence that firmly established this was only found in the past couple decades, it's perhaps worth noting that it's not at all a new idea. It was suggested by Charles Darwin, among others, that those fossilized bones of huge creatures that were being found in the early 1800's were remarkably similar to bird skeletons. Then, when the Archaeopterix fossils were found (in the Fraunhofer limestone formation in Germany), the connection was even more likely.
But that wasn't really much evidence, and the idea was kicked around without much more information until the 1970's when a small gang of paleontologists led by John Ostrom started talking it up again. He pointed out that there were a number of other small dinosaurs, classified as Theropoda, that had been found, and they were remarkably similar to Archaeopterix, though they had arms rather than wings. Ostrom also pointed out that, although Archaeopterix was primitive in many respects (teeth, bony tail, denser bones than modern birds), it had fully modern feathers. He suggested that feathers were developed for insulation long before they were used for flight, and we should expect to find that many small dinosaurs had feathers.
It didn't take long after that for small, feathered dinosaur fossils to turn up. The critical event was the opening up of China to academic and scientific work again after the decades of Mao's rule. There are formations in northwest China of fine-grained silt and limestone, 100-150 million years old, that preserve fine details of fossils. There are fossils of a number of early birds there, and also of other small non-flying dinosaurs. Many of the latter show feathers of various sorts.
So, 150 years after Darwin suggested it, the conventional cladogram now has the birds as an offshoot of the theropod dinosaurs, and feathers are considered a primitive characteristic of an unknown portion of the dinosaurs. Mainly the smaller ones, of course, since the biggiest wouldn't have needed the insulation. Even the big ones may have had feathered crests, and their babies may have had feathers until they grew out of them.
Due to my wife's allergies to cats and dogs, we share our house with four birds. We like to refer to them as our pet dinosaurs. Some people know what we're talking about. For the rest, we can say something like "Oh, didn't you hear? The dinosaurs weren't wiped out after all. Some of them survived; they're called 'birds'."
And the cockatiels are moulting now, dropping feathers all over the place. The feathers mostly go into the compost. They sure don't fossilize very well.
I find it a great shame that the best the American Left get is Michael Moore and the Right get P.J. O'Rourke, 1000 times more funny and more intelligent.
Oh, I dunno about that. The left has people like Molly Ivins. I think that any sensible American of any persuasion would be reading both Ivins and O'Rourke. All the more fun, she offends and embarrasses the Left about as often as he does the Right. Both of them can rip apart your favorite candidate in a way that leaves you laughing.
Not that "left" and "right" have any real meaning in American politics these days. A friend recently made the bemused observation that these days, all it takes to qualify as a leftist is to be against torture.
Anyone else have favorite writers that they'd list alongside these two?
The first thing that occurred to me was "I wonder who they had to bribe to get it banned?"
This should be even better than an X rating. I'll bet they're shipping out lots of copies to the "underground" dealers right now.
(Here in the US, there are open discussions in the media of the lengths that producers sometimes go to in order to get an R rating, which is the minimum that will bring in most adults. Sometimes they have to add a nude/sex scene that has nothing to do with the plot, just to get that all-important rating.;-)
On which platforms does exit() return an error? I thought exit() returned void.
Well, I don't rightly recall; it's been a few years. And, of course, the man pages all tell you that exit() and _exit() don't return. In my experience, you shouldn't believe this. I've seen it happen too many times, and muttering "That can't happen" doesn't change things. When it does return, I have found that I can assign its value to an int variable. If the conditions are reproducible, I get the same return value from exit() each time, implying that the value may be meaningful. So on a few systems, exit() simply isn't implemented correctly. Griping doesn't fix it; paranoid programming does.
You should return EXIT_SUCCESS or EXIT_FAILURE.
Hey, I've actually seen this! Not often, granted.
One problem with EXIT_FAILURE: How do you specify the exit status? Now, we both know that the actual status isn't always meaningful. But if you're working on an app that contains a flock of separate programs that call each other, it can be very useful to produce a meaningful exit status, so the parent has a clue about the failure. 8 bits isn't enough for all cases, of course, but it suffices in a surprisingly-large fraction of the cases. You can augment it with a stderr message in the remaining cases.
Anyway, one of my ongoing gripes with a lot of unix software is that the exit status usually is just binary, so the parent process can't give many clues about why a subprocess died. The EXIT_SUCCESS and EXIT_FAILURE syms merely encourage people to write software that "doesn't work and doesn't tell me what's wrong". We need less of that, not more.
Slashdot Mirror
I think the stories about the GEMS county level counting machines are much scarier. The county offices will all have no problem altering totals.
Yeah, but where are they gonna find all the trained chimps to do the job?
If the machine is clearly showing the check mark going wrong, it's a bug, not a conscious attempt to manipulate the vote.
Exactly right. Any competent programmer who is implementing a biased count would show the actual vote on the screen. The code would then, with some probability (perhaps just a counter) would add certain votes to the wrong candidate in the internal sum. Those sums aren't shown to the voter, of course, so they'll never suspect.
It's a bit trickier if there's some sort of paper trail or other scheme to do a recount. The code has to come up with the same "mistakes" in a recount. Doing this is more of a technical challenge. But I suppose we have lots of people here who would be (or have been) up to the task.
This case was probably some sort of incorrect lookup table, off-by-one indexing, or similar simple coding error.
The problem: we're the only Western democracy that allows for partisan election commissions.
Nah; we're just the only one that encourages election commissioners to publicly state their bias.
In the others, if you're a partisan who wants to be an election commissioner, you just learn enough of your opponent's buzz phrases to fool the interviewers. Then, once you're on the commission, you can look for ways to implement your bias without being noticed.
When it comes to such matters as election outcomes, you should never assume that people are telling you the truth.
You might have also added the report's authors comments that their methods and assumptions were generally "conservative". Combine this with their openness about the size of their sample and the error bars. We would expect that their errors are biased towards an underestimate, and when they publish their followup study with more data, it will probably turn out that the number of fatalities is even higher.
..."
Of course, we don't know that yet. Getting good data out of a war zone is traditionally rather difficult.
One of my favorite bits of advice to scientists is that the most important part of any paper is the paragraph near the end that says "More research is needed
Unlike most other sources of numbers in Iraq, this group is fairly open about their methods, limits and accuracy. So their numbers are inherently more credible than most that you'll read.
It'll be interesting to see if they'll be able to collect data for a followup paper. There's gotta be a number of people with weapons who want to stop them.
... i would be happy to give the benefit of the doubt - if it wasn't for that 2000 election BS
But this is hardly anything new. If you've been paying attention in previous US elections, you'll have noticed many cases like this. Thus, in the 2000 election here in Boston, there was a news story of the discovery of 20,000 "missing" ballots in one precinct. Similar stories pop up all over. The attitude of the people running the election is basically "Oops; sorry about that." It's hard to avoid the impression of "Well, we were caught, so we'll have to count that batch."
The obvious question is "How many others are never discovered?" Hard to tell. But when I read about blocks of thousands of ballots that were somehow "misplaced", it's hard to avoid the obvious suspicion. Is it really true that only 50% or 60% of the people actually vote? Or are 30% to 40% of the ballots "lost" and never counted?
In Florida, they seem to be openly thumbing their noses at the voters by having so many ballots disappear. It's like they don't even need to pretend any more. They know that the worst that can happen is that they'll have to "discover" and count a few of the votes. But nobody will ever be punished for such things.
[Hemp] seed is very high in proteins, tasty and nutty--you can buy these at some health food stores as nut butters etc. (local restrictions may apply!).
You can also buy hemp seen in most pet stores in the US. Our cockatiels love it. Actually, they prefer millet, but they will eat a good amount of hemp seed for variety.
Unfortunately for potential human growers, the seed sold in pet stores is generally sterilized, now mostly be being irradiated. But this is better for your bird, since it kills off most disease organisms and insect eggs.
Heh. That one did always strike me as a sign of some sort of perverse humor inside IBM. After, all, the page obvious wasn't blank ...
But then, I've always liked statements like "This statement is false."
The main problem with most documentation, of course, is the extreme difficulty of finding an answer to the question you have at hand. I've always like the the observation that most computer documents are good at answering questions of the form "I'd really like to use the foo command; I wonder what it does." But hardly anyone ever asks questions in that form. They ask "How do I get this machine to do bar?", where it turns out that bar is equivalent to foo. But the two use totally different keywords, so the lookup tools can't tell you that you want the foo command.
IBM has always supplied copious documentation. But you can hardly ever find the answer to your question. You know that it's probably somewhere in those N shelves of documents, but you can't find it.
Which reminds me of a clever remark someone made a few years ago: By now, chances are that anything you want to know is somewhere on the Web - but you can't find it.
Yeah, google helps - a little. If you guess the right keywords. And if there's no other topic that uses the same keywords.
IBM was in a fortunate position of being a major hardware vendor and therefore capable of switching revenue stream focus.
;-)
True, perhaps, but it's not the full story. IBM has always made a major portion of its income from customer support. They have often given away software, or sold it at a low, nominal cost, and offered support contracts. They figured out long ago that this is the best way to make money with software.
(It helps if your documentation is crappy. Then your customers can't make much sense of it, and have to hire an expert to make it work. But Microsoft and the Open Source community are both there already.
This is, of course, how the commercial linux vendors make their money. It's hardly a new idea. Microsoft is already making a lot of money from support. It really wouldn't be that much of a stretch for them to start offering support contracts for "free" software.
"Hey, you can get a very popular web server at apache.org that's simpler than IIS (and, frankly, doesn't have as many security holes, but don't tell my boss I said that). We can install and support it for you if you'd like. Shall we add it to the purchase order?"
...; it's almost as if the distro with the highest price tag does the best in the biz market.
;-)
Yup. Of course, this happens in the retail market, too, with a great many products (including computers). It goes along with the oft-heard claim that "You get what you pay for." This is another way of saying that if something costs more, it must be better. The fashion industry is very familiar with this fallacy, and they make a lot of money off it, as does Microsoft (and IBM) with their office products.
I've long thought that, if the linux crowd really wants to crash the office-software party, distributers like Red Hat, Suse, etc. should charge more than Microsoft. When people question the price for what is supposed to be "free" software, just say that you can get it all for free off the company's web site, but you don't get support with that. And point out that you can get Microsoft's software for free too. It's called "piracy". Nearly everyone does it, and you don't get support with that software either.
What might be the clincher is to point out that, when you pirate MS software, you have to worry about them suing you when they find out. When you pirate linux software, you get it from the vendor's site, with their blessing. If you want support, you'll have to pay for it in both cases. The difference is that the linux crowd doesn't make legal threats against their customers. What's the same is that, if you pay, what you're paying for is future support if you need help.
Of course, if you want to charge a higher price than MS, you should provide better support. But anyone who has tried to deal with MS's support people knows that you don't actually have to be very good to do this.
(I've also had a few dealings with Apple's customer support, and I'd say that, while they may be better than Microsoft, it would still be pretty easy to be better than them, too.
Become an electrician or a plumber. That's where the real money is made.
There's an old joke about a doctor who hired a plumber to do some work on his bathroom. When the job was done, the plumber handed the doctor the bill for his services.
The doctor looked at the bill in shock. "I don't make this much per hour and I'm a doctor."
The plumber replied: "I didn't, either, when I was a doctor."
- it's dark over there right now and all the programmers are all tucked away in bed dreaming dreams of python function calls.
Um, if they were Real Programmers, they'd consider working at 2 am totally normal.
The problem with programmers in the US is that, during "normal" working hours (especially the afternoon), they're almost totally non-productive, because that's their usual sleep time.
"We are eating our seed corn."
;-)
But then, how many Americans (or Europeans) these days could explain this sentence?
"Huh? Whuddayamean? All corn has seeds."
Ah; so like the original Sherpas, you do most of the "heavy lifting", and in the end, its the others who get credit for accomplishments.
(How often do you read that Tenzing Norgay was the other first person to climb Mount Everest?)
Hey, an easy one!
;-)
The password will be sent in from that keystroke logger that was installed a few months ago.
(You just aren't paranoid enough. Your Windows box probably has 5 or 6 such loggers already, not counting the ones that came pre-installed. That's why your keyboard response has gotten so slow.
So what's a Computer Sherpa?
From the fact that they're using IE. Of course, it used to be that you had to trick them into opening an attachment to get your code run on their machine. Now, it seems, all you need to do is send them a JPEG file.
A few will be up to date with their patches, so none of this will work. But probably not enough of them to skew the statistics significantly, if history is any guide.
..., but now that the Windows floodgates are open, I suspect that they will put an end to this very quickly.
... enables you to save and retrieve files stored on your GMail account directly from inside Windows Explorer.
...
Note especially the comment that "GMail Drive
It's only a matter of time until a message is developed that, when sent to a gmail account, installs software that lets remote software use the account as a relay. Soon thereafter, all those gmail accounts of Windows users will become the Net's biggest anonymizing spam relay.
It'll be fun to watch the gmail developers try to program their way out of this one
Sounds like you made the bigger error. ... Your post only illustrates the fact that developers cause a substantial part of the disconnect between themselves and management.
Well, I can see why you'd read it that way. But I don't think this is really accurate. One reason is that I'd merely mentioned the idea of a second server, as a "throwaway" comment. Nobody reacted, so I mentally shrugged, and Just Did It.
Another reason that I didn't mention was that the project had earlier had a relevant problem: The management had decreed that we were to use a specific web server (which shall remain nameless here). This shows that they were aware that a web server is software. But the group was unable to make the server work properly. It's config GUI was just too ornate, and we couldn't get it right. One day I nabbed a copy of apache, compiled and configged it, and 20 minutes later we had a functioning web server that never failed us. So again, a "web server" was a piece of software that I'd installed on the machine. The managers was well aware of this, and eventually went with apache (though not happily). So there was no reason to suspect any difference in terminology within the team. We regularly used "the web server" to mean the copy of apache running on our test machine.
Given that this was (mostly) a software-development project, there was every reason to believe that we had a common understanding of our common terms. The misunderstanding over whether "web server" was software or hardware came as a surprise to most of us.
If anything, this is mostly an example of how a misunderstanding can arise without anyone suspecting. Then someone does something that just doesn't make sense, until you realize that there's a difference in how some people understand a bit of jargon.
And recall that the original comment here was suggesting that managers should listen with mouth shut. I was giving an example where that failed. Actually, it didn't quite fail, because someone opened their mouth soon enough, and I corrected the misunderstanding. But it's still a useful example of why you should at least talk a little, to make sure that you are really talking the same language.
In any case, a quick google for "shielded wallet" turned up several that are for sale now. Here's a site that sells them and assorted items of shielding clothing. The wallet is down the page a bit.
This has all been available for some years, actually. As mentioned in this site's blurbs, there are a lot of environments where one might want your wallet's contents to be shielded from the sort of EM fields that can damage things like magnetic stripes. The same shielding will prevent anyone from reading RFID tags embedded in your cards.
I don't have any association with this site, and didn't even know it existed until now. It does give you a clue that people have been thinking of this sort of problem for some time, and for several reasons. But it's not new at all. Back in the 70's, I knew some CS people for several computer vendors who had shielded clothing. They worked around a lot of equipment that produced stray magnetic fields, which could have unpleasant effects on things like a mag tape in your pocket.
1. Listen ...
2. Close your mouth
One problem with this: By listening with your mouth closed, you run a very real risk of misunderstanding what you're hearing. Without feedback to verify that you're understanding, you are highly likely to do things completely wrong.
Funny example: A few years ago, I was implementing an interactive web site, and we had a nice test server machine in the lab. In one discussion with The Mgt, I casually mentioned that for testing, I thought we needed to run another server.
I didn't hear any response, so I went ahead and cloned the apache server that we were using, and fired it up on a different port. 10 minutes work, and we proceeded to test.
A while later, I discovered just in time that the managers had heard me say that we needed a second server machine, and were ordering another one. After a bit of discussion, I realized that to them, a server is a piece of hardware, while to us software guys, it is a piece of software.
I managed to explain to them that, no, we didn't need a new machine. I'd already set up a second web server on the old machine, and it was working fine. There was still time to cancel the hardware order.
But still, they had done a bunch of unnecessary work, and had almost spent a good sum of money unnecessarily, all because they had listened carefully without asking questions. If they had asked what hardware the new server needed, I'd have realized quickly that there was a misunderstanding, and we could all have saved a bit of time.
Listening without interacting, and acting on your understanding of what you heard, can lead to a lot of serious problems.
you want the tests written by people who *didn't* write the code.
Correct in theory. But in practice, I always write a test suite while writing the main code. It's the fastest way to get the job done. When the inevitable change requirements come along, I have a regression test suite that helps make sure I haven't broken the earlier cases.
And, when it comes time for the QA people to write tests for my stuff, their tests are always a proper subset of mine. Over several decades of software development, I've yet to see a single case of the QA folks testing something that I'm not already testing.
This shouldn't be a surprise, since I know more about the code (and usually the task) than any of them do. This is because they're madly trying to come up to speed on the requirements, while juggling the testing of N other pieces of code, and not enough time to do the job right. I've been there ahead of them so of course I know more about it.
What usually happens is that the QA folks quickly realize this, and they start asking me for a copy of my test suite. I tell them I'd be happy to hand it over, if they'll also give me any new tests they devise. As a result, I tend to get along with the QA people better than most of the other developers.
Frankly, the QA people have a very difficult job, and all the worlds' wonderful management theories don't do much to help them. Sensible developers will short-circuit the task by cooperating with the testers.
Now if there were only some practical way to automate GUI tests. I've used a number of packages that claim to do this. I wonder if there are any that actually work for more than the most trivial cases? Short of an AI-enabled robot, it's hard to imagine how one might test responses to the things that humans actually do with keyboards, mice, trackpads, etc.
What's Kerry's Bacon number?
For that matter, is Osama bin Laden's number still 3?
Nope; not strange at all. Of course, it would be more accurate to say that birds (Aves) are a clade of the Dinosauria, but that would probably be a bit picky for /.'s style.
While the evidence that firmly established this was only found in the past couple decades, it's perhaps worth noting that it's not at all a new idea. It was suggested by Charles Darwin, among others, that those fossilized bones of huge creatures that were being found in the early 1800's were remarkably similar to bird skeletons. Then, when the Archaeopterix fossils were found (in the Fraunhofer limestone formation in Germany), the connection was even more likely.
But that wasn't really much evidence, and the idea was kicked around without much more information until the 1970's when a small gang of paleontologists led by John Ostrom started talking it up again. He pointed out that there were a number of other small dinosaurs, classified as Theropoda, that had been found, and they were remarkably similar to Archaeopterix, though they had arms rather than wings. Ostrom also pointed out that, although Archaeopterix was primitive in many respects (teeth, bony tail, denser bones than modern birds), it had fully modern feathers. He suggested that feathers were developed for insulation long before they were used for flight, and we should expect to find that many small dinosaurs had feathers.
It didn't take long after that for small, feathered dinosaur fossils to turn up. The critical event was the opening up of China to academic and scientific work again after the decades of Mao's rule. There are formations in northwest China of fine-grained silt and limestone, 100-150 million years old, that preserve fine details of fossils. There are fossils of a number of early birds there, and also of other small non-flying dinosaurs. Many of the latter show feathers of various sorts.
So, 150 years after Darwin suggested it, the conventional cladogram now has the birds as an offshoot of the theropod dinosaurs, and feathers are considered a primitive characteristic of an unknown portion of the dinosaurs. Mainly the smaller ones, of course, since the biggiest wouldn't have needed the insulation. Even the big ones may have had feathered crests, and their babies may have had feathers until they grew out of them.
Due to my wife's allergies to cats and dogs, we share our house with four birds. We like to refer to them as our pet dinosaurs. Some people know what we're talking about. For the rest, we can say something like "Oh, didn't you hear? The dinosaurs weren't wiped out after all. Some of them survived; they're called 'birds'."
And the cockatiels are moulting now, dropping feathers all over the place. The feathers mostly go into the compost. They sure don't fossilize very well.
I find it a great shame that the best the American Left get is Michael Moore and the Right get P.J. O'Rourke, 1000 times more funny and more intelligent.
Oh, I dunno about that. The left has people like Molly Ivins. I think that any sensible American of any persuasion would be reading both Ivins and O'Rourke. All the more fun, she offends and embarrasses the Left about as often as he does the Right. Both of them can rip apart your favorite candidate in a way that leaves you laughing.
Not that "left" and "right" have any real meaning in American politics these days. A friend recently made the bemused observation that these days, all it takes to qualify as a leftist is to be against torture.
Anyone else have favorite writers that they'd list alongside these two?
The first thing that occurred to me was "I wonder who they had to bribe to get it banned?"
;-)
This should be even better than an X rating. I'll bet they're shipping out lots of copies to the "underground" dealers right now.
(Here in the US, there are open discussions in the media of the lengths that producers sometimes go to in order to get an R rating, which is the minimum that will bring in most adults. Sometimes they have to add a nude/sex scene that has nothing to do with the plot, just to get that all-important rating.
On which platforms does exit() return an error? I thought exit() returned void.
Well, I don't rightly recall; it's been a few years. And, of course, the man pages all tell you that exit() and _exit() don't return. In my experience, you shouldn't believe this. I've seen it happen too many times, and muttering "That can't happen" doesn't change things. When it does return, I have found that I can assign its value to an int variable. If the conditions are reproducible, I get the same return value from exit() each time, implying that the value may be meaningful. So on a few systems, exit() simply isn't implemented correctly. Griping doesn't fix it; paranoid programming does.
You should return EXIT_SUCCESS or EXIT_FAILURE.
Hey, I've actually seen this! Not often, granted.
One problem with EXIT_FAILURE: How do you specify the exit status? Now, we both know that the actual status isn't always meaningful. But if you're working on an app that contains a flock of separate programs that call each other, it can be very useful to produce a meaningful exit status, so the parent has a clue about the failure. 8 bits isn't enough for all cases, of course, but it suffices in a surprisingly-large fraction of the cases. You can augment it with a stderr message in the remaining cases.
Anyway, one of my ongoing gripes with a lot of unix software is that the exit status usually is just binary, so the parent process can't give many clues about why a subprocess died. The EXIT_SUCCESS and EXIT_FAILURE syms merely encourage people to write software that "doesn't work and doesn't tell me what's wrong". We need less of that, not more.