Sun's Java implementation does compile to native code. It just happens to do so on-the-fly. (This is what just-in-time compilation is all about.) To call a language "compiled" or "interpreted" is a waste of time. That's just an implementation detail.
Compiling to native code before executing instead of executing directly is just an implementation detail. It only speeds up execution. To state that this blurs the division between compiled and interpreted is "utter tripe".
Interpreted: "if you have the VM installed and the necessary (mostly platform-independent) libraries, your program will run out-of-the-box". Java, Perl, Python, Lisp, C# with Mono, whatever. Of course there are often glitches and it doesn't, but it could and it should.
Compiled: "if you have the correct compiler chain, the program is very system-agnostic, and your libraries are standard-like, then you can rebuild the binary from source and execute it". C, C++, Pascal, and the like.
The parent is either clueless or trolling when he states that C was supposed to be portable and multiplatform when it started off as well.
Multiplatform "as in Java" ("write once, run anywhere") is impossible for compiled languages such as C, because once in binary format, any change in architecture or underlying OS will break the program. In interpreted languages, the VM is there to translate to the intended hardware/OS.
The other type of "multiplatformity" would be the "write once, compile anywhere" type. For that, C is still multiplatform - provided that the necessary system libraries are available in all intended platforms, and enough care has been taken to avoid hard dependencies on the hardware (for instance, word size).
Oops - I guess he was trolling and I swallowed the hook. Mmm, nutritious...
Please explain what the Comp-Sci department grad students can do about creating an e-voting system where you can vote from any PC, anywhere, and that is resistant to
DoS attacks (SERVE's webpage says that they have something up their sleeves, but the experts in the article don't buy it)
Trojans/Malware in the voter's computer
Man-in-the-middle attacks
Insider attacks once the system has been verified
(Acknowledged: having widely-reviewed source by academics across the globe would help guard against program backdoors -- but all the above still apply)
In fact, if you read the article -or, even better, the full review- (ouch! forgot this was Slashdot!), they say that *no* system can do the job of providing good voting from *any* internet-connected PC.
I think there are two problems here, and the only way about it is to drop requirements. First, "any internet-connected PC" opens itself to all kinds of man-in-the-middle and local malware attacks. Why not place a few trusted PCs connected by secure tunnels under supervision of ellection officials in the voting areas? This would fix [D]DoS, man-in-the-middle attacks, vote buying, and evil software in the voting end.
Second, as noted in the review (and other articles about secure e-voting), the voter-verified audit trail: unless there is something tangible and hard-to-tamper (like ordinary ballots, even the printed sort), mass fraud is way too easy. So have these overseas voting stations do printed ballots, and ship them after the encrypted votes in a secure fashion. When the ballots reach the homeland, check that everything matches - and if not, beleive the ballots and find the electronic fraudsters. This would make insider attack much more difficult
Of course, the only advantage of this is that you get a not-so-secure e-vote from controlled stations, speeding up initial vote count; a count that will need to be re-checked once the overseas ballot boxes arrive back home.
If a computer is well programmed to do something, and the inputs are inside the expected ranges, fine - it will outperform any of us. I would rather trust a good autopilot than a pilot for staying on course.
But without "real AI" (whatever that is), computers cannot react to things they have not been programmed to. If things really go weird, then hard-coded algorithms will not get you very far. It's human problem-solving all the way.
I don't wanna be mean here or anything, but you have to realize that the percentage of the population that actually thinks, creates, innovates and so on, is incredibly small. You don't get a million Nietzsche's from eliminating mundane jobs.
Humm, maybe because they didn't get the opportunities? Doesn't it strike you how (for instance) many great things are being invented this century in comparison to the last? May this have to do with said scientists not having to work their backs off at coal mines or 19th century sweatshops?
Saying that *some* jobs may become obsolete has little to do with having half the population on welfare. There will be different jobs, probably less demanding (anyone heard of 35 hours?). And certainly more rewarding for those who have them.
The idea of shelving all the unemployed to state-run concentration camps makes no sense. From an economical standpoint, it would be much better to keep them as consumers, and integrate them into the mainstream economy.
In developed countries, the percentages of population working in agriculture have dropped to 10%, while almost everybody was working there few centuries before. Industry has yielded to services, and now 70% of the workforce is there. The type of services is also changing: the second largest US export is entertainment, IIRC.
So, yes, maybe there will be less clerks and waiters and construction workers. And the future will have an entertainment industry as we've never seen before, the economy will keep growing, and the sun will keep coming over the horizon every day.
Truthfully, and effective and fair DRM system just might be what is truly needed.
You now have the moral duty to suggest how such a system would behave.
The problems are pointed in the article and in previous posts:
no computer system, short of AI, will ever get the "fair" part right (exceptions, changing legislation, potential for loophole abuse...)
effective DRM is a moving target, as has been repeatedly proven. Probably the only way to achieve it is by tuning the incentives in such a way that, at least for a majority of users, it is not worth the effort of breaking.
I am not against the concept of DRM itself, but I can't think of a way of implementing it that matches your description.
Slashdot Mirror
Compiling to native code before executing instead of executing directly is just an implementation detail. It only speeds up execution. To state that this blurs the division between compiled and interpreted is "utter tripe".
Interpreted: "if you have the VM installed and the necessary (mostly platform-independent) libraries, your program will run out-of-the-box". Java, Perl, Python, Lisp, C# with Mono, whatever. Of course there are often glitches and it doesn't, but it could and it should.
Compiled: "if you have the correct compiler chain, the program is very system-agnostic, and your libraries are standard-like, then you can rebuild the binary from source and execute it". C, C++, Pascal, and the like.
C was supposed to be portable and multiplatform when it started off as well.
Multiplatform "as in Java" ("write once, run anywhere") is impossible for compiled languages such as C, because once in binary format, any change in architecture or underlying OS will break the program. In interpreted languages, the VM is there to translate to the intended hardware/OS.
The other type of "multiplatformity" would be the "write once, compile anywhere" type. For that, C is still multiplatform - provided that the necessary system libraries are available in all intended platforms, and enough care has been taken to avoid hard dependencies on the hardware (for instance, word size).
Oops - I guess he was trolling and I swallowed the hook. Mmm, nutritious...Please explain what the Comp-Sci department grad students can do about creating an e-voting system where you can vote from any PC, anywhere, and that is resistant to
(Acknowledged: having widely-reviewed source by academics across the globe would help guard against program backdoors -- but all the above still apply)
In fact, if you read the article -or, even better, the full review- (ouch! forgot this was Slashdot!), they say that *no* system can do the job of providing good voting from *any* internet-connected PC.
I think there are two problems here, and the only way about it is to drop requirements. First, "any internet-connected PC" opens itself to all kinds of man-in-the-middle and local malware attacks. Why not place a few trusted PCs connected by secure tunnels under supervision of ellection officials in the voting areas? This would fix [D]DoS, man-in-the-middle attacks, vote buying, and evil software in the voting end.
Second, as noted in the review (and other articles about secure e-voting), the voter-verified audit trail: unless there is something tangible and hard-to-tamper (like ordinary ballots, even the printed sort), mass fraud is way too easy. So have these overseas voting stations do printed ballots, and ship them after the encrypted votes in a secure fashion. When the ballots reach the homeland, check that everything matches - and if not, beleive the ballots and find the electronic fraudsters. This would make insider attack much more difficult
Of course, the only advantage of this is that you get a not-so-secure e-vote from controlled stations, speeding up initial vote count; a count that will need to be re-checked once the overseas ballot boxes arrive back home.
If a computer is well programmed to do something, and the inputs are inside the expected ranges, fine - it will outperform any of us. I would rather trust a good autopilot than a pilot for staying on course.
But without "real AI" (whatever that is), computers cannot react to things they have not been programmed to. If things really go weird, then hard-coded algorithms will not get you very far. It's human problem-solving all the way.
Humm, maybe because they didn't get the opportunities? Doesn't it strike you how (for instance) many great things are being invented this century in comparison to the last? May this have to do with said scientists not having to work their backs off at coal mines or 19th century sweatshops?
Saying that *some* jobs may become obsolete has little to do with having half the population on welfare. There will be different jobs, probably less demanding (anyone heard of 35 hours?). And certainly more rewarding for those who have them.
The idea of shelving all the unemployed to state-run concentration camps makes no sense. From an economical standpoint, it would be much better to keep them as consumers, and integrate them into the mainstream economy.
In developed countries, the percentages of population working in agriculture have dropped to 10%, while almost everybody was working there few centuries before. Industry has yielded to services, and now 70% of the workforce is there. The type of services is also changing: the second largest US export is entertainment, IIRC.
So, yes, maybe there will be less clerks and waiters and construction workers. And the future will have an entertainment industry as we've never seen before, the economy will keep growing, and the sun will keep coming over the horizon every day.
Yes, I'm an optimist.
You now have the moral duty to suggest how such a system would behave.
The problems are pointed in the article and in previous posts:
- no computer system, short of AI, will ever get the "fair" part right (exceptions, changing legislation, potential for loophole abuse...)
- effective DRM is a moving target, as has been repeatedly proven. Probably the only way to achieve it is by tuning the incentives in such a way that, at least for a majority of users, it is not worth the effort of breaking.
I am not against the concept of DRM itself, but I can't think of a way of implementing it that matches your description.