Java will have those incorporated in short order, i'm sure.
The point is that, IMO, Java trails.Net in terms of design. I know of nothing that I would consider an advantage in language design to Java over C#, and many advantages to C#. Some are at the level of syntactic sugar (like properties or operator overloading), some are much deeper (like delegates).
Getter/Setter methods are easy to generate and offer the exact same functionality.
At the cost of (arguably) reduced readability in many cases.
You know, I'm a huge fan of Emacs... I use it as my primary editor, I'm running Emacs 22 from CVS with the Emacs Code Browser. But it might just be because I'm new at using ECB and Semantic and those types of tools, but I'd take a full-fledged IDE any day. I like being able to right click on an identifier and go right to its definition, and not have to worry that TAGS didn't understand what was going on, or that it was in a file that's almost the same but in a different directory. I haven't even figured out how to click on an include file and jump to it. (BTW, like I said, I'm new at this, and I haven't really found a good "here's how to set up this tool" page. It's mostly along the lines of a lot of Unix documentation where it almost seems like to understand what it says you already have to know what it's talking about. So if you know how to set it up so that I can do these things, please let me know. If you want, give me an email and I can give you more information about my setup.)
Let alone the other things that a good IDE will give you like refactoring support.
In the limit you're of course right, but it's not too hard to find something that's a lot easier to generate than interpret. Like it's possible you'd have reasonable (by that I mean better than 50/50, though not much better) success in the current context by picking a random noun, doing a Google image search for it, and picking one of the top few hits. This would be easy to implement, and if it worked, would be nigh impossible to reverse most of the time.
No, you can't, not if the libraries are GPLed. If you don't accept the Sun commercial license and only accept the GPL, you can't use non-GPLed code with the Java libraries. The FSF has made it pretty clear that linking with a GPLed library requires GPLed code. You can't link a non-GPLed program with GPLed libraries, even as an end-user. It's not legal.
The FSF has ALSO made it pretty clear that you don't need to accept the terms of the GPL in order to use the software or make modifications yourself if you don't distribute it.
Also, it's not like there will likely be a "GPL" version and a "commercial" version of the code itself, it'll just be dual-licensed. Which means that you can just say "oh, I was using it in accordance to the commercial license, not the GPL".
Interesting... I've used dcraw from the command line, and I think I tried UFRaw as a stand-alone app, but somehow I think I missed the Gimp plugin. Thanks for the links; I'll have to check them out next time I'm in Linux.
Many point-and-shoot cameras don't have full manual control, which does restrict your artistic options a lot of the time. (Want a slightly blurred image? Not all cameras let you set exposure time.)
No point-and-shoot camera I've ever seen -- digital or film -- has a lens that will give you anywhere the lens zoom range that you can get with an SLR and even cheap lenses. I spent about $1500 on my outfit, and I've got a Rebel XT and four lenses. A 50 mm prime lens ('cause it was cheap), the 18-55mm stock lens, a 28-105mm one that I use most of the time, and a 70-300mm telephoto. That's almost a 17x range of zooms. (Sure, I have to change lenses to get it, but even 28-105 is 3.75x, which is better than many POS cameras.) Your SD700 doesn't go quite as wide-angle or anywhere near as telephoto as my setup. (140mm equivalent vs. 480 on the long end; 29 vs 35 on the short.) Granted, the 28-105 lens is what "lives" on my camera, and what I use for the majority of my pictures. But I do have many pictures that you couldn't have gotten with a shorter lens. (Both shots of distant subjects and macro photos.)
Yes, I'll agree that the range is narrowing, but I think you're fooling yourself if you think that DSLRs are going lose enough ground to be any worse off than film SLRs were before digital became popular.
(In favor of your argument though, I also plan to get a small POS camera soonish too. I want something that's small enough for my pocket. Because I have missed many good shots since carrying around anything larger than pocket-sized is prohibitive.)
One thing I found amusing on one of the new cameras (the Nikon maybe?) was that it supported multiple exposures. Why the hell would I want to do that on the camera when I can do it in photoshop?
Why not? If done well, it should be easier to do in-camera than with Photoshop. You can see what it'll look like immediately, so if you decide you want to re-frame the picture or something like that after seeing the result, you can. Besides, what if you don't have Photoshop? (Don't say The Gimp -- it can't edit RAW images.)
Well, the point I was trying to make was that figuring out who you voted for requires use of your memory as to who was on which side of the ballot. Though in retrospect this is sorta stupid, because remembering who you voted for is probably easier anyway...
No it doesn't not for elections that are conducted on anything but DREs.
In any system where there are physical ballots, there are three steps: 1. Produce a ballot 2. Scan the ballots and determine who and what the voter voted for 3. Add 1 to the totals of each of the things and people the voter voted for
This system splits step 2 into two substeps: 2a. Determine which ovals are marked 2b. Determine who those ovals correspond to
This system "ensures" that step (2a) is done correctly. Outside of DREs, this is the only way that I've seen to ensure this that doesn't appear to compromise voter secrecy. It's certainly not the case that (2a) is satisfied with our current system... see Florida, 2000 and trying to figure out voter intent based upon the number of chad corners that were severed.
I'm not sure how big of a problem (2a) is in relation to other systems, and DREs eliminate it as a problem essentially entirely, so I don't know if the Punchscan system is worth the complexity or not. I'm also still not fully convinced of its secrecy. But, if it does what it appears to, it DOES HELP.
So why do this again if the voter can't verify it?
The voter CAN verify it, at least in part. The voter CAN'T prove it to anyone who isn't Vulcan (and thus able to do a mind meld). As a voter, you can remember "Zaphod Beeblebrox" was the second candidate listed, I voted for Zaphod Beeblebrox, look at the site and see that it recorded that you voted for the second candidate. But if someone else asks "which spot was Zaphod Beeblebrox, you didn't vote for him, did you?" you can say "no, Zaphod was the first candidate listed; I voted for the second."
See now?
This doesn't get you anything in precincts that use DRE equipment, but it would in places that have and use physical ballots. In those locations, there's the potential that they are scanned incorrectly. This provides a mechanism for you to verify that your vote was scanned correctly.
Believe me, it can be done. Before this, I didn't believe it was possible (besides some external enforcement, like "verify your vote in this room after we check your ID with 100% accuracy"), and I nearly posted a comment about it, but then I decided to look at the actual method. And actually, to some extent, it works.
It CAN'T be used to prove that you voted a certain way. (At least to non-Vulcans or other telepaths. Or people with polygraph machines.) It also can't be used to verify that your vote was associated with a particular candidate, but it CAN be used to verify that the machine read your ballot correctly in a totally non-traceable way.
You're right of course, but there IS one thing that this would detect, which is scanning errors. It wouldn't detect the computer counting "left" as "Zaphod Beeblebrox" when it should have said "Yooden Vranx" (let's stay away from real politics), but it would detect the computer counting "left" as "right".
If the counting software could be otherwise verified correct, that would give a higher assurance that votes are counted correctly than is presently possible.
But wait, what have you really verified? Only you know what B corresponded to... for all we know, thanks to a bug in the software (malicious or otherwise), the computed tally counted your vote B as a vote for Pepsi. We have to trust that the computer actually tallied the vote properly. We have to trust that the computer correctly recorded the ballot's mapping from letter-choice to candidate.
Exactly. This system is useless for identifying fraud.
HOWEVER, if there were a scanning mistake, rather than a bug in the software or something malicious, it would detect it.
Electronic voting is an answer in search of a problem.
I don't know if this is totally true. To say that something is in search of a problem usually implies that the problem that it supposedly solves doesn't actually exist. There is a problem. Electronic voting is one solution to the problem; your proposal is another. Either, if done well, is better than what we have now.
Personally, I think that either a fully-electronic system (with a VVPT that is randomly audited each election) or one in which there is a machine similar to current DREs but whose sole purpose is to produce ballots readable by the actual counter, then have the counter separate, is the best way. (Essentially the second option is the same as your proposal with the caveat that the "regular paper ballots" aren't hand-produced. (Preferably aren't even ever touched by the voter, though this may be hard to de well.)
The use of an electronic machine to produce ballots (with a backup method if they should fail) has a couple advantages. One, it carries the biggest benefit of current DREs, which is that it's a good solution to allow blind people to vote. Two, there's much less possibility for "questionable" ballots. It adds complexity, but I think it's very possible that the benefits are worth it. (At least to have a couple per precinct for the disabled vote.)
Going with the separate ballot-producer and counter though, as opposed to just a DRE with VVPT, I think has much less advantage than adding the ballot-producer or going with either of these schemes over current systems. The only advantage I see is that if the ballot-counter fails, but the ballot-producer works, the election can continue uninterrupted. With just a DRE, the method of voting has to change. (To provisional ballots or another backup.)
Once something's GPL'd, it can't be un-GPL'd. I don't think the Linux community at large would be foolish enough to incorporate Suse tech that wasn't under the GPL, so I don't think MS could make that stick.
How can you tell the difference between things that are patent encumbered and things that aren't?
Just because it comes with something that says "this is released under the GPL" doesn't mean that it IS actually under the GPL. If the distributer had no legal rights to distribute it under the GPL, then it is effectively not under the GPL. Third parties could plead ignorance and probably have a reasonable case, but they would have to cease distribution.
Reading it again I think you were clear, I just misread it. I'm sorta making a fool out of myself in this thread.;-)
Also, I doubt that Novell will knowingly incorporate anything into Suse that's patented without a formal agreement, especially if the patents are MS-owned.
because usually you either license patents or you do not, going after one company that has not licensed the patent but not going after another is pretty questionable, and I reckon a court would see it as strange too (although of course IANAL)
No it isn't; licensing patents to just a limited number of clients happens ALL THE TIME.
But back to the subject, do you think that Novell's lawyers are just going to be like "oh, MS promised they wouldn't sue us. Go to it!"? They aren't exactly stupid either...
Saying "this is a dumb decision and I wish they hadn't made it" is a far cry from "I'm gonna have to go buy a new clock because of it." The latter is at least as nonsensical as the former...
None of my clocks (except the computer) adjust the time at all when it's time to switch. I have to do it manually. You'd have to do it four times a year instead of two, but big deal? It takes what, 30 seconds to go all the way around? Even four times a year, that's a whopping 0.000095% of your time.
Well, the TV industry would say that your direct payments only cover part of the costs, the rest of which come from advertising.
Perhaps you haven't noticed, but there ARE channels that have no commercials, but you pay more to get them. If anything, this would support the TV industry's arguments. (There's also PBS, but there you also pay through taxes.)
I'm not sure why this concept is so hard to grasp. You need a lot more than "I'm giving Comcast/Cox/Time Warner/whoever money already, isn't that enough?" You need "What I'm giving Comcast/whoever should be enough to cover the costs on their own, and here's why, so why are they also making me deal with ads?"
Of course, the other reply "because we can" is a large part as well, but I'm sick of seeing "I'm already paying for it" whines.
Did you read the link? That wasn't really what he was suggesting... most of his suggestions went beyond things that the type system provides for you.
(And it also got started in BCPL, which didn't do typechecking at all. So there something like iSomeInt or dSomeDouble would be very helpful if not essential.)
Slashdot Mirror
Java will have those incorporated in short order, i'm sure.
.Net in terms of design. I know of nothing that I would consider an advantage in language design to Java over C#, and many advantages to C#. Some are at the level of syntactic sugar (like properties or operator overloading), some are much deeper (like delegates).
The point is that, IMO, Java trails
Getter/Setter methods are easy to generate and offer the exact same functionality.
At the cost of (arguably) reduced readability in many cases.
You know, I'm a huge fan of Emacs... I use it as my primary editor, I'm running Emacs 22 from CVS with the Emacs Code Browser. But it might just be because I'm new at using ECB and Semantic and those types of tools, but I'd take a full-fledged IDE any day. I like being able to right click on an identifier and go right to its definition, and not have to worry that TAGS didn't understand what was going on, or that it was in a file that's almost the same but in a different directory. I haven't even figured out how to click on an include file and jump to it. (BTW, like I said, I'm new at this, and I haven't really found a good "here's how to set up this tool" page. It's mostly along the lines of a lot of Unix documentation where it almost seems like to understand what it says you already have to know what it's talking about. So if you know how to set it up so that I can do these things, please let me know. If you want, give me an email and I can give you more information about my setup.)
Let alone the other things that a good IDE will give you like refactoring support.
In the limit you're of course right, but it's not too hard to find something that's a lot easier to generate than interpret. Like it's possible you'd have reasonable (by that I mean better than 50/50, though not much better) success in the current context by picking a random noun, doing a Google image search for it, and picking one of the top few hits. This would be easy to implement, and if it worked, would be nigh impossible to reverse most of the time.
No, you can't, not if the libraries are GPLed. If you don't accept the Sun commercial license and only accept the GPL, you can't use non-GPLed code with the Java libraries. The FSF has made it pretty clear that linking with a GPLed library requires GPLed code. You can't link a non-GPLed program with GPLed libraries, even as an end-user. It's not legal.
The FSF has ALSO made it pretty clear that you don't need to accept the terms of the GPL in order to use the software or make modifications yourself if you don't distribute it.
Also, it's not like there will likely be a "GPL" version and a "commercial" version of the code itself, it'll just be dual-licensed. Which means that you can just say "oh, I was using it in accordance to the commercial license, not the GPL".
'Cause if it's a protest to bring attention to the total failure of tags to accomplish anything useful -- I'm all for it.
I think it is, but more specifically I suspect it's a protest that for about a week every single MS story got an itsatrap tag.
Interesting... I've used dcraw from the command line, and I think I tried UFRaw as a stand-alone app, but somehow I think I missed the Gimp plugin. Thanks for the links; I'll have to check them out next time I'm in Linux.
Not just DOF...
Many point-and-shoot cameras don't have full manual control, which does restrict your artistic options a lot of the time. (Want a slightly blurred image? Not all cameras let you set exposure time.)
No point-and-shoot camera I've ever seen -- digital or film -- has a lens that will give you anywhere the lens zoom range that you can get with an SLR and even cheap lenses. I spent about $1500 on my outfit, and I've got a Rebel XT and four lenses. A 50 mm prime lens ('cause it was cheap), the 18-55mm stock lens, a 28-105mm one that I use most of the time, and a 70-300mm telephoto. That's almost a 17x range of zooms. (Sure, I have to change lenses to get it, but even 28-105 is 3.75x, which is better than many POS cameras.) Your SD700 doesn't go quite as wide-angle or anywhere near as telephoto as my setup. (140mm equivalent vs. 480 on the long end; 29 vs 35 on the short.) Granted, the 28-105 lens is what "lives" on my camera, and what I use for the majority of my pictures. But I do have many pictures that you couldn't have gotten with a shorter lens. (Both shots of distant subjects and macro photos.)
Yes, I'll agree that the range is narrowing, but I think you're fooling yourself if you think that DSLRs are going lose enough ground to be any worse off than film SLRs were before digital became popular.
(In favor of your argument though, I also plan to get a small POS camera soonish too. I want something that's small enough for my pocket. Because I have missed many good shots since carrying around anything larger than pocket-sized is prohibitive.)
One thing I found amusing on one of the new cameras (the Nikon maybe?) was that it supported multiple exposures. Why the hell would I want to do that on the camera when I can do it in photoshop?
Why not? If done well, it should be easier to do in-camera than with Photoshop. You can see what it'll look like immediately, so if you decide you want to re-frame the picture or something like that after seeing the result, you can. Besides, what if you don't have Photoshop? (Don't say The Gimp -- it can't edit RAW images.)
Well, the point I was trying to make was that figuring out who you voted for requires use of your memory as to who was on which side of the ballot. Though in retrospect this is sorta stupid, because remembering who you voted for is probably easier anyway...
Which makes it useless for PRACITCAL purposes.
No it doesn't not for elections that are conducted on anything but DREs.
In any system where there are physical ballots, there are three steps:
1. Produce a ballot
2. Scan the ballots and determine who and what the voter voted for
3. Add 1 to the totals of each of the things and people the voter voted for
This system splits step 2 into two substeps:
2a. Determine which ovals are marked
2b. Determine who those ovals correspond to
This system "ensures" that step (2a) is done correctly. Outside of DREs, this is the only way that I've seen to ensure this that doesn't appear to compromise voter secrecy. It's certainly not the case that (2a) is satisfied with our current system... see Florida, 2000 and trying to figure out voter intent based upon the number of chad corners that were severed.
I'm not sure how big of a problem (2a) is in relation to other systems, and DREs eliminate it as a problem essentially entirely, so I don't know if the Punchscan system is worth the complexity or not. I'm also still not fully convinced of its secrecy. But, if it does what it appears to, it DOES HELP.
So why do this again if the voter can't verify it?
The voter CAN verify it, at least in part. The voter CAN'T prove it to anyone who isn't Vulcan (and thus able to do a mind meld). As a voter, you can remember "Zaphod Beeblebrox" was the second candidate listed, I voted for Zaphod Beeblebrox, look at the site and see that it recorded that you voted for the second candidate. But if someone else asks "which spot was Zaphod Beeblebrox, you didn't vote for him, did you?" you can say "no, Zaphod was the first candidate listed; I voted for the second."
See now?
This doesn't get you anything in precincts that use DRE equipment, but it would in places that have and use physical ballots. In those locations, there's the potential that they are scanned incorrectly. This provides a mechanism for you to verify that your vote was scanned correctly.
RTFA
Believe me, it can be done. Before this, I didn't believe it was possible (besides some external enforcement, like "verify your vote in this room after we check your ID with 100% accuracy"), and I nearly posted a comment about it, but then I decided to look at the actual method. And actually, to some extent, it works.
It CAN'T be used to prove that you voted a certain way. (At least to non-Vulcans or other telepaths. Or people with polygraph machines.) It also can't be used to verify that your vote was associated with a particular candidate, but it CAN be used to verify that the machine read your ballot correctly in a totally non-traceable way.
You're right of course, but there IS one thing that this would detect, which is scanning errors. It wouldn't detect the computer counting "left" as "Zaphod Beeblebrox" when it should have said "Yooden Vranx" (let's stay away from real politics), but it would detect the computer counting "left" as "right".
If the counting software could be otherwise verified correct, that would give a higher assurance that votes are counted correctly than is presently possible.
But wait, what have you really verified? Only you know what B corresponded to... for all we know, thanks to a bug in the software (malicious or otherwise), the computed tally counted your vote B as a vote for Pepsi. We have to trust that the computer actually tallied the vote properly. We have to trust that the computer correctly recorded the ballot's mapping from letter-choice to candidate.
Exactly. This system is useless for identifying fraud.
HOWEVER, if there were a scanning mistake, rather than a bug in the software or something malicious, it would detect it.
Electronic voting is an answer in search of a problem.
I don't know if this is totally true. To say that something is in search of a problem usually implies that the problem that it supposedly solves doesn't actually exist. There is a problem. Electronic voting is one solution to the problem; your proposal is another. Either, if done well, is better than what we have now.
Personally, I think that either a fully-electronic system (with a VVPT that is randomly audited each election) or one in which there is a machine similar to current DREs but whose sole purpose is to produce ballots readable by the actual counter, then have the counter separate, is the best way. (Essentially the second option is the same as your proposal with the caveat that the "regular paper ballots" aren't hand-produced. (Preferably aren't even ever touched by the voter, though this may be hard to de well.)
The use of an electronic machine to produce ballots (with a backup method if they should fail) has a couple advantages. One, it carries the biggest benefit of current DREs, which is that it's a good solution to allow blind people to vote. Two, there's much less possibility for "questionable" ballots. It adds complexity, but I think it's very possible that the benefits are worth it. (At least to have a couple per precinct for the disabled vote.)
Going with the separate ballot-producer and counter though, as opposed to just a DRE with VVPT, I think has much less advantage than adding the ballot-producer or going with either of these schemes over current systems. The only advantage I see is that if the ballot-counter fails, but the ballot-producer works, the election can continue uninterrupted. With just a DRE, the method of voting has to change. (To provisional ballots or another backup.)
And do you think Oracle's thing just came into some exec's head a few days ago?
Or do you not think that there's as much corporate espionage going on as military?
Once something's GPL'd, it can't be un-GPL'd. I don't think the Linux community at large would be foolish enough to incorporate Suse tech that wasn't under the GPL, so I don't think MS could make that stick.
How can you tell the difference between things that are patent encumbered and things that aren't?
Just because it comes with something that says "this is released under the GPL" doesn't mean that it IS actually under the GPL. If the distributer had no legal rights to distribute it under the GPL, then it is effectively not under the GPL. Third parties could plead ignorance and probably have a reasonable case, but they would have to cease distribution.
Reading it again I think you were clear, I just misread it. I'm sorta making a fool out of myself in this thread. ;-)
Also, I doubt that Novell will knowingly incorporate anything into Suse that's patented without a formal agreement, especially if the patents are MS-owned.
Hmmm, thanks for the correction. I've been under a misconception for quite some time.
because usually you either license patents or you do not, going after one company that has not licensed the patent but not going after another is pretty questionable, and I reckon a court would see it as strange too (although of course IANAL)
No it isn't; licensing patents to just a limited number of clients happens ALL THE TIME.
RMS is indeed a wise man.
If a bit crazy at times.
But back to the subject, do you think that Novell's lawyers are just going to be like "oh, MS promised they wouldn't sue us. Go to it!"? They aren't exactly stupid either...
The GPL v2 doesn't contain patent provisions. So you could GPL code that's protected by patents and release it still be able to sue users.
Hence the debate over how best to add protections in the GPL v3, all the OSI licenses that aren't GPL compatible because of patent restrictions, etc.
Saying "this is a dumb decision and I wish they hadn't made it" is a far cry from "I'm gonna have to go buy a new clock because of it." The latter is at least as nonsensical as the former...
Um, can't you just change the time yourself?
None of my clocks (except the computer) adjust the time at all when it's time to switch. I have to do it manually. You'd have to do it four times a year instead of two, but big deal? It takes what, 30 seconds to go all the way around? Even four times a year, that's a whopping 0.000095% of your time.
Well, the TV industry would say that your direct payments only cover part of the costs, the rest of which come from advertising.
Perhaps you haven't noticed, but there ARE channels that have no commercials, but you pay more to get them. If anything, this would support the TV industry's arguments. (There's also PBS, but there you also pay through taxes.)
I'm not sure why this concept is so hard to grasp. You need a lot more than "I'm giving Comcast/Cox/Time Warner/whoever money already, isn't that enough?" You need "What I'm giving Comcast/whoever should be enough to cover the costs on their own, and here's why, so why are they also making me deal with ads?"
Of course, the other reply "because we can" is a large part as well, but I'm sick of seeing "I'm already paying for it" whines.
Did you read the link? That wasn't really what he was suggesting... most of his suggestions went beyond things that the type system provides for you.
(And it also got started in BCPL, which didn't do typechecking at all. So there something like iSomeInt or dSomeDouble would be very helpful if not essential.)