More than lawyers, programmers have to design and create things. When starting
a project, a pessimist is likely to think that it will require a lot of
work, that there are many hard problems to overcome, and that the product
may still not end up being useful. Linus has said that if he knew how long
Linux would take, he never would have started! The ability to jump in
seeing the opportunities not the obstacles is valuable in programming, so I
don't think that pesimism is beneficial overall. However, you are probably
right that it aids in debugging and designing for reliability.
The thing about lawyers and pessimism is interesting. There is some
research behind it, but it's not as strong as you might like. Actually, I
believe they only studied law students and their performance on certain
tests, not actual lawyers and professional proficiency. More careful
research is warranted, and I think Seligman makes too much of the current
results. (He talks about it in one of his books, and you can find more if
you google "Seligman lawyers pessimism".) It is a provocative idea, though,
especially since it does correlate with lawyers scoring high on unhappiness
metrics (eg, divorce) and the perception of lawyers as cynics.
All of it. My beef with the unit testing craze is the suggestion that only individual "units" (whatever the hell a unit is) need to be tested automatically. If you design your application well, you should be able to simulate everything up to the multi-step transactions a user would go through. Instead of your code being 75% testable, make it 95% testable. You'll always need people to test that last bit that can't be automated (since the only true test is end-to-end), but the more bugs you can find before it gets to them, the better (cheaper, faster).
When it comes down to human testing, I'd say hire someone to be the "user from hell". Even if your automatic testing finds all the real bugs, this user should be able to find unanticipated use cases, annoying interfaces, performance problems, etc.
I would discourage the use of DNSBLs that reject everyone with a dynamic IP address (fortunately, not many people seem to use these), but singling out those known to be malicious or negligent is certainly fair game. There is a huge difference, your mocking disagreement notwithstanding, between imposing limited and targeted restrictions, and rejecting by default, accepting only from a few privileged hosts.
All this does is add accountability, and that is a Good Thing(tm).
Accountability is great, but put it in the ends, not in the network. Yes, it will be more work this way, but we will not have devalued the network in the process.
I wasn't going to post, but you made the point so well that I want to add my support. Not only does SPF put the least burden on those (large corporations and ISPs) with the most resources, it actively punishes everyone for whom SPF is a burden: either they expend the great effort to make all their systems and users SPF-compatible, or they receive a greater share of the joe-job brunt. And it breaks end-to-end in doing so: only "approved" hosts can make direct SMTP connections. SPF is not in the spirit of the internet, and I'd encourage everyone--even those who could easily deploy SPF in their domain--to resist SPF in favor of more equitable solutions.
Note that one definition of "pump" is "a device that raises water."
I have trouble believing that an English-speaking reporter could see or even hear a description of a rope and bucket device and call it a "pump". Sure, it's possible, but simple exaggeration or misunderstanding (maybe it was 20 feet?) sounds more plausible to me. Yes, I was being a smart-ass, but I haven't heard a better explanation.
As I asked another respondant (and this was the point of my original post), which of those methods do you think is being employed in undeveloped Afghanistan on solar power? Serious question. Your reference itself said that deep-well pumps are difficult to maintain; I bet they're also expensive and hard to install.
Duh, there are ways to lift water more than 10 meters. Now which of those ways is this guy employing on deep wells in undeveloped Afghanistan, with only solar power? My dollar says he's got a suction pump, and the report was exaggerated. What's yours say? (I'd seriously love to be humbled here; I've already learned lots from other respondants.)
In 1996, he developed a solar-powered pump powerful enough to lift water from wells up to 20 metres deep. His invention is widely used in his home province of Wardak and the neighbouring province of Logar as well.
One atmosphere of pressure is about 10 meters of water. You can't pump water any higher than that. I smell exaggeration.
Re Camram, while I love the hashcash idea, I can't see a path to making it effective because there are so many obstacles, the biggest of which is that corporations and ISPs don't want the burden. (That's why they love SPF, ugh.)
But what I want to know is why none of the current anti-spam approaches uses a web of trust or reputation system. I know--PGP has been around and hasn't caught on. But we could build the web on things other than--or in addition to--personal digital signatures. For example, host signatures and IP addresses. We would learn over time which sites effectively police their users, and which are run--or taken over by--spammers. It wouldn't be perfect--you could build a good reputation, then turn bad, or hijack a site with a good reputation (which would quickly go down), but I think it would hit the monetary incentive for spamming pretty hard.
This would take a while to become effective, but there are no real barriers to adoption, it doesn't require changing end-user behavior or client software, it's not obnoxious, and it retains all the decentralized, end-to-end flexibility of email.
American Express's one-time card number system was called Private Payments, but they cancelled it just a few weeks ago. I'm guessing because not enough people used it. I used it for all my on-line purchases, because even if I'm not liable for fraud, the trouble of generating a one-time number (and their site was a bit of a pain) is worth avoiding the hassle of the fraud recovery process. As a bonus, nobody could automatically renew any subscriptions I bought.
I actually agree with the grandparent here. It seems that his original objection was in relying completely on science to the point of exclusion of artistry, not in the use of science as part of the art of cooking.
Yes, it's fun to construct replies to fabricated positions.
There, he had sound scientific knowledge (milk + acid + heat = curdled milk) which he combined with artistry (use curdling to me advantage) to produce a "super buerre blanc." The perfect marriage of science and art.
You have it completely mixed up. The mock beurre did not curdle. His "scientific knowledge" was unsound, which is why the observed behavior was a surprise. A more complete scientific model explains that behavior, as well as the other properties the poster noted (that the sauce did not break even when overheated or frozen and thawed). No amount of art is going to account for that.
In short, this example scores a point for science in cooking, not art.
That's a strangely unscientific attitude for someone who calls himself a "real chemist": My experiment didn't agree with my theory, therefore theory is useless. If this were a chemistry experiment, obviously you would seek to refine your theory and conduct more experiments. It sounds that you are wilfully excluding science from your cooking--which is fine if you are happy to conduct replicable experiments devised by others.
As for your particular case, it happens that even Alton Brown explained it in the yogurt expisode, which I'll leave you to read or watch at your leisure.
This summary made no sense to me. What the hell is a record? I searched around and found Senator Figueroa's page about the bill, which rambles all over the map before finishing with the proposal prohibiting "scrutinizing of e-mail messages... for direct marketing" without the consent of both sender and recipient. Not only would this knock Gmail flat, it depends upon the absurd claim (supported by some specious reasoning above) that merely being shown a targeted ad is a privacy violation.
However, this apparently describes an earlier draft, because this somewhat better article says the bill is about amassing personal information (ie, keeping email that's been deleted) and sharing it with third parties. Which are much more legitimate concerns, but have nothing to do with the targeted ad and search features of Gmail.
So what's the real story? It almost sounds like the revised bill is just a cover for Senator Figueroa's embarrassing early draft.
This is not about a chain of trust. Nobody is expected to verify the identity or trustworthiness of anyone else.
This is not about preventing unauthorized submissions. There is no process for checking the provenance of code.
This is not about marketing. I'm sure Linus doesn't care if this helps some manager sleep at night.
What is it about? It's about putting information that was already mostly available (by scrounging in mail archives) in a structured form. So that the next SCO doesn't waste so much developer time, and (as a bonus) so that Linus can figure out which maintainer sent some code when debugging.
Now, when you are going up a hill you are constantly pushing hard on the pedal. For each pedal revolution each foot has to push for 1/2 the revolution. So not only are you pedaling harder to fight the hill, but you get less relaxation time between revolutions.
I bet you're onto it. I think it's not just that you can't relax, but that you have to push during the whole revolution, in both strong (when pushing down) and weak positions (when coming over the top). Those of us who haven't trained riding uphill haven't developed the muscles used at the top of the cycle.
I think I'll buy the book and see what it says.:-)
A smaller gear requires smaller force per pedal stroke, but the distance it travels is thus smaller,
Actually, the distance here is the distance over which the force is applied, ie the distance covered by the pedal. Thus, in theory, by using a lower gear, you can make the energy required for one pedal revolution arbitrarily low. Sure, you aren't going very fast, but it should be easy.
Physics explanation: You are carrying your weight to a higher altitude, thereby raising your potential energy. Conservation of energy dictates that you've gotta put equivalent kinetic energy in there yourself.
Yes, I have to expend energy to go uphill. But the whole point of gears is mechanical advantage: I can spread out the energy cost over a greater distance (ie, a greater number of pedal revolutions), so I can apply less force (energy = force * distance). According to a simple model, by picking the appropriate gear, I should be able to pedal with the same force and frequency (and thus power) going uphill or flat, so I should get just as tired either way. I want to know why this doesn't seem to hold true.
it can tell me why it's always hard to pedal uphill, no matter how low a gear I'm in.
There's a possible psychological explanation: I'm too impatient and competitive to relax and let the gears do the work. But I think there's something more, maybe the force is distributed over the pedal cycle in a way that's less efficient....
A crap review, but at the root of it there is an underlying flaw in the philosophy of the GNOME designers. They have been seduced by abstract principles of UI design (in this case, the "object oriented" model), so that they don't give enough consideration to how specific decisions will affect real users. A related problem is their minimalism in configuration options, reflecting an arrogant belief that they can derive the correct interface without respect to the vagaries of individual user preferences.
As trashy as that review was, I think GNOME needs some backlash against the current trends in their UI approach.
Where do the free competitors stand now?
on
Bitkeeper News Redux
·
· Score: 3, Interesting
Larry used to like to joust with the would-be bitkeeper challengers. I'd like to know what he thinks of them today. My guess is that he still thinks arch is limited by its "diff&patch" foundation, but I wonder what he thinks about darcs", which has some novel algorithms for distributed revision control (I admit I don't understand them all, not being a physicist).
You should seperate the syntax of pipes with the implementation of calling pipe().
Absolutely--that's what I had in mind with the term mini-OS. You're pointing out the logical consequence: that the mini-OS pipe operation needn't even call unix pipe(2) at all. It could use temporary files, named pipes, or some other IPC.
Regarding the use of internal variables, it wasn't clear to me whether they were stored in memory, or used named pipes. I suspect the former, in which case this isn't really an acceptible implementation of pipes.
And, unsupprisingly, the throw/catch type error detection is just as buggy as real error detection.
Yeah, fault handling is hard. That's why I mentioned Erlang, which was designed with error containment as a core feature.
Slashdot Mirror
The thing about lawyers and pessimism is interesting. There is some research behind it, but it's not as strong as you might like. Actually, I believe they only studied law students and their performance on certain tests, not actual lawyers and professional proficiency. More careful research is warranted, and I think Seligman makes too much of the current results. (He talks about it in one of his books, and you can find more if you google "Seligman lawyers pessimism".) It is a provocative idea, though, especially since it does correlate with lawyers scoring high on unhappiness metrics (eg, divorce) and the perception of lawyers as cynics.
When it comes down to human testing, I'd say hire someone to be the "user from hell". Even if your automatic testing finds all the real bugs, this user should be able to find unanticipated use cases, annoying interfaces, performance problems, etc.
I would discourage the use of DNSBLs that reject everyone with a dynamic IP address (fortunately, not many people seem to use these), but singling out those known to be malicious or negligent is certainly fair game. There is a huge difference, your mocking disagreement notwithstanding, between imposing limited and targeted restrictions, and rejecting by default, accepting only from a few privileged hosts.
Accountability is great, but put it in the ends, not in the network. Yes, it will be more work this way, but we will not have devalued the network in the process.
I wasn't going to post, but you made the point so well that I want to add my support. Not only does SPF put the least burden on those (large corporations and ISPs) with the most resources, it actively punishes everyone for whom SPF is a burden: either they expend the great effort to make all their systems and users SPF-compatible, or they receive a greater share of the joe-job brunt. And it breaks end-to-end in doing so: only "approved" hosts can make direct SMTP connections. SPF is not in the spirit of the internet, and I'd encourage everyone--even those who could easily deploy SPF in their domain--to resist SPF in favor of more equitable solutions.
An English-speaking reporter has to consult his dictionary on the word "pump"? Now you're trolling me. ;-)
I have trouble believing that an English-speaking reporter could see or even hear a description of a rope and bucket device and call it a "pump". Sure, it's possible, but simple exaggeration or misunderstanding (maybe it was 20 feet?) sounds more plausible to me. Yes, I was being a smart-ass, but I haven't heard a better explanation.
As I asked another respondant (and this was the point of my original post), which of those methods do you think is being employed in undeveloped Afghanistan on solar power? Serious question. Your reference itself said that deep-well pumps are difficult to maintain; I bet they're also expensive and hard to install.
Duh, there are ways to lift water more than 10 meters. Now which of those ways is this guy employing on deep wells in undeveloped Afghanistan, with only solar power? My dollar says he's got a suction pump, and the report was exaggerated. What's yours say? (I'd seriously love to be humbled here; I've already learned lots from other respondants.)
One atmosphere of pressure is about 10 meters of water. You can't pump water any higher than that. I smell exaggeration.
But what I want to know is why none of the current anti-spam approaches uses a web of trust or reputation system. I know--PGP has been around and hasn't caught on. But we could build the web on things other than--or in addition to--personal digital signatures. For example, host signatures and IP addresses. We would learn over time which sites effectively police their users, and which are run--or taken over by--spammers. It wouldn't be perfect--you could build a good reputation, then turn bad, or hijack a site with a good reputation (which would quickly go down), but I think it would hit the monetary incentive for spamming pretty hard.
This would take a while to become effective, but there are no real barriers to adoption, it doesn't require changing end-user behavior or client software, it's not obnoxious, and it retains all the decentralized, end-to-end flexibility of email.
American Express's one-time card number system was called Private Payments, but they cancelled it just a few weeks ago. I'm guessing because not enough people used it. I used it for all my on-line purchases, because even if I'm not liable for fraud, the trouble of generating a one-time number (and their site was a bit of a pain) is worth avoiding the hassle of the fraud recovery process. As a bonus, nobody could automatically renew any subscriptions I bought.
Yes, it's fun to construct replies to fabricated positions.
You have it completely mixed up. The mock beurre did not curdle. His "scientific knowledge" was unsound, which is why the observed behavior was a surprise. A more complete scientific model explains that behavior, as well as the other properties the poster noted (that the sauce did not break even when overheated or frozen and thawed). No amount of art is going to account for that.
In short, this example scores a point for science in cooking, not art.
As for your particular case, it happens that even Alton Brown explained it in the yogurt expisode, which I'll leave you to read or watch at your leisure.
However, this apparently describes an earlier draft, because this somewhat better article says the bill is about amassing personal information (ie, keeping email that's been deleted) and sharing it with third parties. Which are much more legitimate concerns, but have nothing to do with the targeted ad and search features of Gmail.
So what's the real story? It almost sounds like the revised bill is just a cover for Senator Figueroa's embarrassing early draft.
What is it about? It's about putting information that was already mostly available (by scrounging in mail archives) in a structured form. So that the next SCO doesn't waste so much developer time, and (as a bonus) so that Linus can figure out which maintainer sent some code when debugging.
I bet you're onto it. I think it's not just that you can't relax, but that you have to push during the whole revolution, in both strong (when pushing down) and weak positions (when coming over the top). Those of us who haven't trained riding uphill haven't developed the muscles used at the top of the cycle.
I think I'll buy the book and see what it says. :-)
Actually, the distance here is the distance over which the force is applied, ie the distance covered by the pedal. Thus, in theory, by using a lower gear, you can make the energy required for one pedal revolution arbitrarily low. Sure, you aren't going very fast, but it should be easy.
I think he meant 20 atm feels solid in your hand. I certainly can't judge by hand over 40.
There's a possible psychological explanation: I'm too impatient and competitive to relax and let the gears do the work. But I think there's something more, maybe the force is distributed over the pedal cycle in a way that's less efficient....
As trashy as that review was, I think GNOME needs some backlash against the current trends in their UI approach.
Larry used to like to joust with the would-be bitkeeper challengers. I'd like to know what he thinks of them today. My guess is that he still thinks arch is limited by its "diff&patch" foundation, but I wonder what he thinks about darcs", which has some novel algorithms for distributed revision control (I admit I don't understand them all, not being a physicist).
Actually, I was referring to the dictionary entry.
Giving something a (ridiculous) name does not explain it.
Absolutely--that's what I had in mind with the term mini-OS. You're pointing out the logical consequence: that the mini-OS pipe operation needn't even call unix pipe(2) at all. It could use temporary files, named pipes, or some other IPC.
Regarding the use of internal variables, it wasn't clear to me whether they were stored in memory, or used named pipes. I suspect the former, in which case this isn't really an acceptible implementation of pipes.
Yeah, fault handling is hard. That's why I mentioned Erlang, which was designed with error containment as a core feature.