The general feeling in any kind of journalism that tries to take a complex subject people know little about (e.g., just about any kind of science or engineering) is that it's necessary to inject some everyday, human-interest details into the story to keep people reading. And I have the feeling, readers like you aside, that overall they're right. If you want Just The Facts, read the journals where the more detailed descriptions are published.
As someone who reads journals all the time, I enjoy the breezy, slice-of-life style of science reporting. It's nice to be reminded that weird little things happen in everybody's workday, not just mine...
I do understand that. Of course Oracle has features MySQL (or MS SQL, or PostgreSQL) lacks. And if my company ever reaches the point where we need those capabilities, I may well recommend a switch. But "real database work" IMNSGDHO isn't just about the number of rows your server can handle. Any monkey can write "select * from hugetable" and then brag about the size of his result set. (Compensation for something else, perhaps?) "Real database work" to me means writing tight, well-crafted architectures and queries that store and deliver the information the user needs, work reliably and handle weird cases, scale well, and execute fast. That's real DB dev, and if you're doing it on Oracle or MySQL or anything else, your work is no less real than anyone else's.
[wearily] My site runs the entire business flow of the company I work for, everything from lead management to financials to supply chain to shipping. We ship some pretty damn complex stuff, which requires managing a great deal of data to get the product out the door. If you think what I do is playing with toys because of my choice of platform... y'know, I have to wonder how many mainframe programmers there were, back in the day, who sneered at people who wrote software for those little "toy" PC's.
If you're using MySQL, people who work on Oracle will consider you as NOT doing "real database work".
Oh, I'm well aware of that. They are, of course, wrong.
I've worked on Oracle databases. My decision is an informed one: I prefer MySQL, I don't use it because it's the only thing I know. There are plenty of Oracle (and MS SQL, and PostgreSQL, and for that matter Access <shudder>) bigots out there who refuse to accept that this is possible. They're assholes, and not shy about proving it.
Yes, exactly. Specifically, MySQL-driven Web sites with a great deal of "real database work" going on in the background. What offended me was his strong implication that the two -- PHP/MySQL programming and real DB development -- are mutually exclusive. It's an attitude that I see a lot on Slashdot, and it pisses me off.
If I were a bit more of a tinfoil hat wearing man, I'd be Slashdot makes some of these "Ask Slashdot" topics up because the ensuing flamewar will cause more page hits than usual.
Based on the sentence preceding the one I'm quoting, I'd say the main flamebait here is your post. How do people like me, who develop corporate LAMP sites with a great deal of "real database work" going on behind the scenes, fit into your neat little conception of who is and is not a real DB developer? Asshole.
What I say about working conditions at Microsoft is based on the experiences of a couple of friends of mine who were both recruited by them right out of college. They got much bigger salaries than any of the other offers they received, as well as the legendary Microsoft benefits package, and full relocation expenses paid -- naturally they were thrilled and jumped at the offer. A few years later, at different times, both of them quit, burned out. (One of them left programming entirely, he says, as a result of the experience.) This was early-to-mid-Nineties, BTW; take that for what it's worth.
It wasn't just the long hours, which are, as you say, no worse than a lot of other companies. It was the way they were expected to live in Microsoft-approved neighborhoods, spend all their off-hours socializing with other Microsoft employees (often at Microsoft events) and, most of all, never ever ever talk to anyone outside Microsoft about their jobs. I don't just mean not revealing trade secrets. I mean not saying things like "I'm working on the next version of Windows," or "I do bug fixes for Excel." Basically all they were supposed to say was, "I'm a software developer at Microsoft, and if I told you any more, I'd have to kill you."
Okay, no, it's not company-town in the sense of only being able to shop at the company store with company scrip until you're so in debt to the company that you're effectively a serf. But it's pretty over the top.
Oh yeah, that's a good site, and I've found some useful stuff there. It just seems kind of... unstructured compared to CPAN. The bigger flaw is that I can't type "vex install PACKAGE" at the command line and have it happen automagically. CPAN takes a lot of flak, but it's damn easy to use.
The device you're thinking of is an AED, Automated External Defibrillator. Basically what it does is read the patient's EKG, compare it against a list of known arrhythmias, and decide whether it should deliver a jolt. I was skeptical about them at first -- being an EMT-D, i.e. an EMT with additional training to use manual defibs (and years of ER experience, not just a four-week class) I had been taught that human judgement was the gold standard -- but the fact is they've saved a lot of lives, and their judgement is often better than that of stressed-out emergency personnel.
I'm with the other posters who point out that adverse side effects aren't all that likely -- but the truth is, even if there are long-term effects, the fact of the matter is, the people who are getting these devices are folks who are unlikely to live a whole lot longer anyway. If it's a choice between certain death in a few months, or possible death a few years down the road from unknown complications, which option are you going to take?
Microsoft is a good place to work like the upper reaches of the Soviet bureaucracy were a good place to work. Yes, they take care of you. They also own your life. It's classic company-town stuff, updated with a high-tech gloss.
I'm not selling this short. Some people are very happy with such an arrangement. But, after almost ten years in the service, I'm happy to be working for a small company that doesn't have that attitude -- independence has its risks, but greater rewards.
Well, what I'd like to see first would be a Python equivalent to CPAN existing in the first place. (Name suggestion, since CPAN is taken: CYAN, the Comprehensive pYthon Archive Network.) Languages such as PHP with PEAR, and R with CRAN, have done very well following the same model, even if these archives aren't nearly as big or comprehensive as CPAN. Give it time, give it time...
And for those who say "do it yourself" -- I don't have the resources. However, I will say, that if CYAN existed, I would happily put some of my own time into porting CPAN (or, for that matter, PEAR and CRAN) modules I've found useful.
I'm not saying that voting machines should run exactly the same way as ATM's; I am fully in favor of voter anonymity, and I understand that the requirements of an anonymous system are different from the requirements of a system in which -- as you say -- identification is of paramount importance. But my point is that secure, stable, reliable, and speedy electronic transactions of enormous complexity are possible, and that the electronic financial system proves it... so we should be able to apply that technology to voting, which is really much simpler, and achieve similar performance. And the only reason we haven't done so, that I can see, is that the people tasked with creating the systems don't want them to work. Or rather, they want them to work a certain way...
The Nazis did just such things in Germany. In the US, the main fear is bribery or less violent but no less effective means of coercion. The biggest problem here is probably corporate malfeasance -- bosses can, and have often been know to, tell their employees how to vote. There are all kinds of pressure that can fly under the radar of any reasonable voter-protection laws; anonymous ballots alone offer protection.
I think part of the problem is that there is just so much to learn before you can make meaningful new contributions in just about any field that becoming a "universal scientist" these days would require more time than most people get. It generally takes a minimum of ten years of university experience -- four years undergrad, four to five years grad, one or two years postdoc -- to start a scientific career in any one, specialized field. People can, and sometimes do, get two PhD's in different fields (usually closely related ones, e.g. math and physics) but realistically, if you want to have any time left for research after that, that's about it. Being a "natural philosopher" who makes great advances in, say, math, physics, astronomy, chemistry, biology, and engineering -- all in one lifetime -- is pretty much impossible these days, because most of the work that's possible for gifted amateurs has already been done.
Well, there are a few issues with hand-marked ballots, although I agree that they're better than the e-voting systems we currently have. But making sure that voters' marks are made properly would require someone standing over their shoulder, which of course is a Bad Idea. And pencil results, particularly, can become smudged -- not to mention the problems if someone incompletely erases one choice and fills in another; then you get to the whole "determining voter intent" mess that made Florida such a nightmare. Finally, once again, there's the problem of accomodating physically disabled voters; a properly designed voting machine can accomodate a wide range of disabilities. Using an electronic screen to make your choices, then having a durable, properly printed ballot to put into the box seems like the best of all.
I'm assuming that Canadian elections have procedures in place to deal with these problems; do you know what they are?
BTW there should be TWO tickets, one for the voter and one for the official record.
No there shouldn't, for the reasons I cited above. It would be nice if we lived in a world where people's votes couldn't be used against them, and where people could be counted on to bring back proper receipts... but we don't.
Hmmm. I'm not sure about the viewing window; I think it's really important to know that your ballot goes into the box, and not one that you saw behind a sheet of glass. It would be easy enough to build a machine that shows you a ballot, shreds it, and deposits another ballot with the "right" votes. And again, there's the problem of Braille ballots for blind voters, which is significant.
I think taking the ballot out of the machine and putting it in the box would work fine. People might still try to take the ballots out with them, but they'd be hurting their candidate of choice, since the paper ballots would be the final authority in a recount. And anyone who tried to bribe or coerce them on this basis would know it.
Actually, I think the paper ballots should be the final authority, period -- make them so they can be electronically scanned, for quick vote counting, but they'd also be human-readable for recounts, and the actual voting machines would be dumb printers.
Re:What about a crash during an election?
on
How To Lose An Election
·
· Score: 4, Insightful
Millions -- tens or hundreds of millions? billions? -- of financial transactions are conducted electronically every day. These transactions are stored on RAID and other redundant error-correcting systems that are as near to foolproof as any data storage system ever devised by hand of man, and yes, that includes handwritten paper records. Very, very few of these transactions fail, and when they do, there are some pretty serious laws about what has to be done to correct them. Most of these transactions are conducted by businesses that have far fewer resources to throw at the problem than does the US government, or even any state government.
It is entirely possible to produce a reliable e-voting system... just not if that system is produced by the current crop of voting machine companies. I'm a big fan of "never attribute to malice what can properly be attributed to incompetence," but in this case, malice -- i.e., a desire to produce insecure, unreliable machines that can easily be rigged to produce the "right" electoral outcome -- really is the simplest explanation.
Yep, that's the solution. It is mind-bogglingly simple and obvious to anyone who has any interest in fair elections. It follows, therefore, that the voting machine companies, which usually answer such demands with bullshit excuses like "the printer would jam" (that gem comes from Diebold, which also makes ATM's which surely print out many more receipts than any voting machine would be likely to, and do so day after day) do not have such an interest.
One quibble: the voters should not keep their receipts. Voter-held receipts are useless in the event of a recount -- how do you know that the receipt the voter brings in is actually the one he got on Election Day? -- and are actively dangerous, in that they provide a means for influencing elections through threat or bribery. ("Vote for candidate X or I'll break your kneecaps" / "Vote for candidate Y and I'll give you a raise"). The best sequence of events is to get the receipt, look it over to verify that it says what you want it to say -- and there's no reason receipts couldn't be printed in Braille for blind voters; some ATM receipts already are -- and deposit it in a ballot box.
For those who say, "But ballot boxes can be stuffed or stolen!" -- yes, this is true, and no election method yet devised is foolproof. But this would be a hell of a lot better than what we've got now.
Slashdot Mirror
The general feeling in any kind of journalism that tries to take a complex subject people know little about (e.g., just about any kind of science or engineering) is that it's necessary to inject some everyday, human-interest details into the story to keep people reading. And I have the feeling, readers like you aside, that overall they're right. If you want Just The Facts, read the journals where the more detailed descriptions are published.
...
As someone who reads journals all the time, I enjoy the breezy, slice-of-life style of science reporting. It's nice to be reminded that weird little things happen in everybody's workday, not just mine
I do understand that. Of course Oracle has features MySQL (or MS SQL, or PostgreSQL) lacks. And if my company ever reaches the point where we need those capabilities, I may well recommend a switch. But "real database work" IMNSGDHO isn't just about the number of rows your server can handle. Any monkey can write "select * from hugetable" and then brag about the size of his result set. (Compensation for something else, perhaps?) "Real database work" to me means writing tight, well-crafted architectures and queries that store and deliver the information the user needs, work reliably and handle weird cases, scale well, and execute fast. That's real DB dev, and if you're doing it on Oracle or MySQL or anything else, your work is no less real than anyone else's.
Since it isn't obvious to you, you're not a real DB developer.
Good thing I have people who can't sign their names to let me know this!
Yes, that was my point. I do real database work with the platform, something the original poster seems not to regard as possible.
[wearily] My site runs the entire business flow of the company I work for, everything from lead management to financials to supply chain to shipping. We ship some pretty damn complex stuff, which requires managing a great deal of data to get the product out the door. If you think what I do is playing with toys because of my choice of platform ... y'know, I have to wonder how many mainframe programmers there were, back in the day, who sneered at people who wrote software for those little "toy" PC's.
If you're using MySQL, people who work on Oracle will consider you as NOT doing "real database work".
Oh, I'm well aware of that. They are, of course, wrong.
I've worked on Oracle databases. My decision is an informed one: I prefer MySQL, I don't use it because it's the only thing I know. There are plenty of Oracle (and MS SQL, and PostgreSQL, and for that matter Access <shudder>) bigots out there who refuse to accept that this is possible. They're assholes, and not shy about proving it.
Yes, exactly. Specifically, MySQL-driven Web sites with a great deal of "real database work" going on in the background. What offended me was his strong implication that the two -- PHP/MySQL programming and real DB development -- are mutually exclusive. It's an attitude that I see a lot on Slashdot, and it pisses me off.
If I were a bit more of a tinfoil hat wearing man, I'd be Slashdot makes some of these "Ask Slashdot" topics up because the ensuing flamewar will cause more page hits than usual.
Based on the sentence preceding the one I'm quoting, I'd say the main flamebait here is your post. How do people like me, who develop corporate LAMP sites with a great deal of "real database work" going on behind the scenes, fit into your neat little conception of who is and is not a real DB developer? Asshole.
What I say about working conditions at Microsoft is based on the experiences of a couple of friends of mine who were both recruited by them right out of college. They got much bigger salaries than any of the other offers they received, as well as the legendary Microsoft benefits package, and full relocation expenses paid -- naturally they were thrilled and jumped at the offer. A few years later, at different times, both of them quit, burned out. (One of them left programming entirely, he says, as a result of the experience.) This was early-to-mid-Nineties, BTW; take that for what it's worth.
It wasn't just the long hours, which are, as you say, no worse than a lot of other companies. It was the way they were expected to live in Microsoft-approved neighborhoods, spend all their off-hours socializing with other Microsoft employees (often at Microsoft events) and, most of all, never ever ever talk to anyone outside Microsoft about their jobs. I don't just mean not revealing trade secrets. I mean not saying things like "I'm working on the next version of Windows," or "I do bug fixes for Excel." Basically all they were supposed to say was, "I'm a software developer at Microsoft, and if I told you any more, I'd have to kill you."
Okay, no, it's not company-town in the sense of only being able to shop at the company store with company scrip until you're so in debt to the company that you're effectively a serf. But it's pretty over the top.
Oh yeah, that's a good site, and I've found some useful stuff there. It just seems kind of ... unstructured compared to CPAN. The bigger flaw is that I can't type "vex install PACKAGE" at the command line and have it happen automagically. CPAN takes a lot of flak, but it's damn easy to use.
The device you're thinking of is an AED, Automated External Defibrillator. Basically what it does is read the patient's EKG, compare it against a list of known arrhythmias, and decide whether it should deliver a jolt. I was skeptical about them at first -- being an EMT-D, i.e. an EMT with additional training to use manual defibs (and years of ER experience, not just a four-week class) I had been taught that human judgement was the gold standard -- but the fact is they've saved a lot of lives, and their judgement is often better than that of stressed-out emergency personnel.
I'm with the other posters who point out that adverse side effects aren't all that likely -- but the truth is, even if there are long-term effects, the fact of the matter is, the people who are getting these devices are folks who are unlikely to live a whole lot longer anyway. If it's a choice between certain death in a few months, or possible death a few years down the road from unknown complications, which option are you going to take?
Microsoft is a good place to work like the upper reaches of the Soviet bureaucracy were a good place to work. Yes, they take care of you. They also own your life. It's classic company-town stuff, updated with a high-tech gloss.
I'm not selling this short. Some people are very happy with such an arrangement. But, after almost ten years in the service, I'm happy to be working for a small company that doesn't have that attitude -- independence has its risks, but greater rewards.
Yeah, no shit. "Poor Don Corleone, all he wanted was to give his kid a nice wedding ..." Yeah, well, life's rough, huh?
Well, what I'd like to see first would be a Python equivalent to CPAN existing in the first place. (Name suggestion, since CPAN is taken: CYAN, the Comprehensive pYthon Archive Network.) Languages such as PHP with PEAR, and R with CRAN, have done very well following the same model, even if these archives aren't nearly as big or comprehensive as CPAN. Give it time, give it time ...
And for those who say "do it yourself" -- I don't have the resources. However, I will say, that if CYAN existed, I would happily put some of my own time into porting CPAN (or, for that matter, PEAR and CRAN) modules I've found useful.
Aaargh. I've been on the publisher about that for months. Aaargh again.
... and a Harry Turtledove blurb.
If you want, please check out my father/coauthor's site, which has more information
I'm not saying that voting machines should run exactly the same way as ATM's; I am fully in favor of voter anonymity, and I understand that the requirements of an anonymous system are different from the requirements of a system in which -- as you say -- identification is of paramount importance. But my point is that secure, stable, reliable, and speedy electronic transactions of enormous complexity are possible, and that the electronic financial system proves it ... so we should be able to apply that technology to voting, which is really much simpler, and achieve similar performance. And the only reason we haven't done so, that I can see, is that the people tasked with creating the systems don't want them to work. Or rather, they want them to work a certain way ...
The Nazis did just such things in Germany. In the US, the main fear is bribery or less violent but no less effective means of coercion. The biggest problem here is probably corporate malfeasance -- bosses can, and have often been know to, tell their employees how to vote. There are all kinds of pressure that can fly under the radar of any reasonable voter-protection laws; anonymous ballots alone offer protection.
I think part of the problem is that there is just so much to learn before you can make meaningful new contributions in just about any field that becoming a "universal scientist" these days would require more time than most people get. It generally takes a minimum of ten years of university experience -- four years undergrad, four to five years grad, one or two years postdoc -- to start a scientific career in any one, specialized field. People can, and sometimes do, get two PhD's in different fields (usually closely related ones, e.g. math and physics) but realistically, if you want to have any time left for research after that, that's about it. Being a "natural philosopher" who makes great advances in, say, math, physics, astronomy, chemistry, biology, and engineering -- all in one lifetime -- is pretty much impossible these days, because most of the work that's possible for gifted amateurs has already been done.
Well, there are a few issues with hand-marked ballots, although I agree that they're better than the e-voting systems we currently have. But making sure that voters' marks are made properly would require someone standing over their shoulder, which of course is a Bad Idea. And pencil results, particularly, can become smudged -- not to mention the problems if someone incompletely erases one choice and fills in another; then you get to the whole "determining voter intent" mess that made Florida such a nightmare. Finally, once again, there's the problem of accomodating physically disabled voters; a properly designed voting machine can accomodate a wide range of disabilities. Using an electronic screen to make your choices, then having a durable, properly printed ballot to put into the box seems like the best of all.
I'm assuming that Canadian elections have procedures in place to deal with these problems; do you know what they are?
BTW there should be TWO tickets, one for the voter and one for the official record.
... but we don't.
No there shouldn't, for the reasons I cited above. It would be nice if we lived in a world where people's votes couldn't be used against them, and where people could be counted on to bring back proper receipts
Hmmm. I'm not sure about the viewing window; I think it's really important to know that your ballot goes into the box, and not one that you saw behind a sheet of glass. It would be easy enough to build a machine that shows you a ballot, shreds it, and deposits another ballot with the "right" votes. And again, there's the problem of Braille ballots for blind voters, which is significant.
I think taking the ballot out of the machine and putting it in the box would work fine. People might still try to take the ballots out with them, but they'd be hurting their candidate of choice, since the paper ballots would be the final authority in a recount. And anyone who tried to bribe or coerce them on this basis would know it.
Actually, I think the paper ballots should be the final authority, period -- make them so they can be electronically scanned, for quick vote counting, but they'd also be human-readable for recounts, and the actual voting machines would be dumb printers.
Millions -- tens or hundreds of millions? billions? -- of financial transactions are conducted electronically every day. These transactions are stored on RAID and other redundant error-correcting systems that are as near to foolproof as any data storage system ever devised by hand of man, and yes, that includes handwritten paper records. Very, very few of these transactions fail, and when they do, there are some pretty serious laws about what has to be done to correct them. Most of these transactions are conducted by businesses that have far fewer resources to throw at the problem than does the US government, or even any state government.
... just not if that system is produced by the current crop of voting machine companies. I'm a big fan of "never attribute to malice what can properly be attributed to incompetence," but in this case, malice -- i.e., a desire to produce insecure, unreliable machines that can easily be rigged to produce the "right" electoral outcome -- really is the simplest explanation.
It is entirely possible to produce a reliable e-voting system
Yep, that's the solution. It is mind-bogglingly simple and obvious to anyone who has any interest in fair elections. It follows, therefore, that the voting machine companies, which usually answer such demands with bullshit excuses like "the printer would jam" (that gem comes from Diebold, which also makes ATM's which surely print out many more receipts than any voting machine would be likely to, and do so day after day) do not have such an interest.
One quibble: the voters should not keep their receipts. Voter-held receipts are useless in the event of a recount -- how do you know that the receipt the voter brings in is actually the one he got on Election Day? -- and are actively dangerous, in that they provide a means for influencing elections through threat or bribery. ("Vote for candidate X or I'll break your kneecaps" / "Vote for candidate Y and I'll give you a raise"). The best sequence of events is to get the receipt, look it over to verify that it says what you want it to say -- and there's no reason receipts couldn't be printed in Braille for blind voters; some ATM receipts already are -- and deposit it in a ballot box.
For those who say, "But ballot boxes can be stuffed or stolen!" -- yes, this is true, and no election method yet devised is foolproof. But this would be a hell of a lot better than what we've got now.
I agree that canoes are what we have now have -- but the Polynesians crossed the Pacific in such craft.