Every life is important. Just because it's not possible to prevent deaths everywhere , doesn't mean you should be ok with unnecessary slaughter of innocent people.
In the real world, resources are limited. If spending 50 billion dollars on anti-terrorism saves 4000 lives, and spending 50 billion dollars on food aid saves 1 million lives, then the latter is clearly a better decision, notwithstanding the fact that every life is important.
Of course, in the real world, what we actually ended up doing is spending 1 trillion dollars fighting two deadly wars with heavy civilian casualties.
Yes, price fixing is bad, but seriously "victimized" consumers? Yeah, they overpaid for an LCD, but they -chose- to pay that amount for an LCD.
You're missing some basic knowledge of economics here. The victims are not the consumers who actually overpaid for an LCD. The victims are the potential consumers who would have bought an LCD had they been fairly priced, but who couldn't afford to pay the inflated price. This category of "lost potential purchases" is known as "deadweight loss" in economics.
Unfortunately, our legal system provides no way for the true victimized class to receive compensation.
Your examples of DNS hijacking are legitimate but extreme. There is a large middle ground of ISP behavior where using third party DNS is beneficial. In addition, if widespread adoption of Google DNS leads to increasingly extreme DNS hijacking on the part of ISPs, at least we'll have some concrete evidence of ISP misbehavior to cite in net neutrality debates and the like. (ISPs can hijack DNS, but they can't do so in secret.)
Its funny how the Google hype is driving so much talk about something like DNS, a service which probably 95% of non-tech people don't know exists. Most people wouldn't care about DNS normally, but since its Google it must be something to get excited about.
I'm not normally a fan of Google, but if they spark some sort of increased public awareness on the issue of DNS, that can only be a good thing. DNS receives far too little public attention relative to its importance.
I doubt really that any significant number of people will switch to using 8.8.8.8, but I worry that if they do, one of the the original goals for DNS will be lost. That its distributed.
DNS stopped being distributed when people started abusing domain name registration. The resulting collapse of DNS into, effectively, a single level hierarchy meant that the original design goals (including the goal of distributed lookups) were already unachievable long ago. This is not really Google's fault.
IP anycast to Google's DNS servers is not any worse than the situation that exists today with respect to our reliance on the root name servers.
Just ask yourself one question, if you don't trust your internet provider enough to do DNS correctly, should you trust them at all?
This is a good question, for which there are two legitimate responses. One is that, in practice, it is often impossible to change ISPs (there may be only one broadband provider in an area). In such cases, using a third party DNS, especially one that defaults to accurate responses (unlike OpenDNS), is often the least bad option out of all the (worse) alternatives. The second point is that there are cryptographic protocols like ssh and SSL which guarantee (or, in the case of SSL, are supposed to guarantee) session integrity, regardless of ISP interference. So, for most important tasks, you don't need a high level of trust in your ISP. For DNS, however, there is no cryptographic protocol to guarantee integrity (DNSSEC doesn't count). It is thus perfectly logical to trust an ISP for ssh/SSL but not for DNS.
Real geeks won't bother with third party DNS; they'll just set up their own recursive nameserver. But for less technically savvy internet users, Google DNS does fulfill a need that was being left unserved. The old Level3 servers at 4.2.2.* fill this role as well, but they were never (to my knowledge) advertised for public use.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly.
Did you try Aaron Stebner's.NET cleanup tool? It's not an official MS product but it's written by an MS dev. I had a system with the same problem, and the cleanup tool fixed it.
The policy previously allowed users who were logged in to the local console to install signed packages from a repository.... Users who have physical access to a computer can compromise it far more easily than waiting for a vulnerability to be found in a package that isn't installed, installing that package before an update is issued, and exploiting the vulnerability.
You are incorrect in equating local console logins with physical access. I pointed this out several times on the bugzilla, but it seems that the myth persists.
There exist OS-level tools such as x11vnc or x0rfbserver whose entire purpose is to provide remote users with the ability to manipulate the local console. These tools do not require root privileges to run. An attacker who gains remote access illicitly can compile or copy over an x11vnc binary and subvert the local console.
Of course, an attacker who has remote access is already very bad news for you, but that doesn't mean they have root, and it's no excuse for making it any easier for them to gain root.
What boggles my mind is that Richard Hughes was apparently aware of the existence of tools like x11vnc and their effects, and yet he advocated in favor of this change anyway. I don't want anybody with this attitude to be even in the same room as any discussion on security policy. This is not a personal attack on Richard Hughes, it's just a simple fact. Security engineering requires a certain mindset, and if you don't have that mindset, then get out of the discussion.
The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago.
Let's be clear here. They discussed modifying PackageKit to allow an administrator to create such configurations. Nowhere in the entire thread did anyone mention "Oh by the way, let's also make this the default configuration for the F12 release."
Your claims are so wrong that I think you're being deliberately obtuse just to provoke replies.
In fact, since depleted uranium contains about half as much U235 as natural uranium, we can say that there is a practical limit of 700 million years for fission power in the solar system since we won't bother with uranium that is depleted by half.
Depleted uranium can still be used as a source of U235, it's just an expensive source for which there is no reason to use it right now. Do not confuse expensive with impossible. (Or, in your case, stop deliberately trying to confuse the two.)
A half life of 700 million years means that, in 5 billion years, 99.3% of the U235 will be gone (seven half lives = 127/128). But as I already explained (and you deliberately ignored), we only need one atom of U235 to convert U238 into plutonium. We will have single atoms available for a long time. Separating out such small quantities of U235 will be expensive, but not impossible, especially considering we only have to do it once.
Plutonium 239 has a half life of 24000 years. That's not long enough for long term storage, but it sure is long enough to sustain breeder reactors. You don't need 24000 years to take plutonium out of one nuclear reactor and use it to start another. Once you start a second nuclear reactor, you have another source of plutonium, good for another 24000 years. And so on. This is so obvious that I feel like I'm explaining things to a child.
There is a practical limit of about 50 years on Earth since we are not going to use breeders and the practical ore will be gone.
The whole argument since the great-great-great-great-grandparent post that started this entire thread is that we are going to use breeders, so for you to waltz in and proclaim unilaterally that we are not going to use breeders is, well, a bit presumptuous, but feel free to continue living in your own bubble.
Where do the neutrons come from to convert U238? U235.
The whole point of a chain reaction is that the fission of a single atom of U235 can convert multiple atoms of U238. Once you have some Pu-239, you can use the Pu-239 as a source of free neutrons. No U235 is necessary after that point.
Pu-239 has a higher probability for fission than U-235 and a larger number of neutrons produced per fission event, so it has a smaller critical mass.
These facts are really not in dispute by anyone who knows even the least bit about nuclear reactions, and you make yourself look really ignorant by contesting them.
Wow! statements like this are really really sad. It is U235 that is used, and U235 that is discussed in the article.
You are wrong. Well, you are partly right. You are correct that the article discusses only U235, but you are wrong about U235 being used for plutonium. Plutonium is most definitely generated from U238, not U235. Quote from Wikipedia:
Pu-239 is synthesized by irradiating uranium-238 with neutrons in a nuclear reactor, then recovered via nuclear reprocessing of the fuel.
The reason why the article discusses only U235, is because the article chooses to ignore the energy available from plutonium and U238.
How long will billions of years of uranium last? 250 years? 300? (I haven't run the numbers, but what I can tell you is that the emeritus professor from Stanford is wrong (or irrelevant) because his starting assumptions are wrong)
If you run the numbers then 1 billion years' supply under present consumption rates lasts for 635 years under 3% growth. But, your numbers are just as wrong and irrelevant as those of the calculation that you are accusing, since there is absolutely no reason why historical growth trends must continue to be the case indefinitely into the future.
For comparison, the entire mass-energy resources of the observable universe will be depleted in 5000 years under the (plainly untenable) assumption of perpetual 3% growth.
You should be calculating the amount of uranium in the surface of the earth, not the volume. Deep mining is less realistic than asteroid mining; it's unlikely to ever happen. Practically speaking, at current demand and growth rates, with enrichment, u238 buys us only a couple hundred years. ("Only.")
But hey, eventually we'll switch to the thorium cycle, and then fusion, and scarcity will actually vanish.
If you actually read the calculations, they are done using only uranium in the crust (in fact, using only uranium in seawater). There is no deep mining, or indeed any sort of mining, required.
The growth rate concern is unrealistic, as it has been mentioned already that no constant growth rate is sustainable indefinitely, under any energy technology. The amount of uranium we lose from natural radioactive decay (half life of 4.5 billion years for U238) exceeds any amount that we are likely to consume for fuel.
Do that calculation again, and instead of assuming zero growth. Do it assuming 3% growth, because that's the average.
No energy source whatsoever in the physical universe can accommodate perpetual 3% growth. Therefore the demand to accommodate 3% perpetual growth is unreasonable.
The problem is that plutonium is a man-made material. We make it from uranium by bombarding it with high energy particles. So if you run out of uranium, you also run out of plutonium. This is of course dependant on us not discovering alchemy in the next 10 years. To be honest, that would be pretty awesome, if watching TV has taught me anything.
You're right, but also wrong. Plutonium is made from U238 (emphasis on 238). The nuclear fuel that we're using right now is U235. There is one hundred and fifty times more U238 in the ground than U235. So, by switching to plutonium, we expand the available supply of uranium by a factor of 150.
The whole debate about uranium fuel reserves is totally ludicrous. An utterly simple back of the envelope calculation demonstrates that the Earth contains sufficient uranium to supply fission power for billions of years. Uranium fuel will last literally longer than solar power (since the sun's remaining lifetime is only 5 billion years). Yet periodically we see attention whores showing up in Slashdot articles and crying that we will run out of uranium, a statement which is so obviously wrong that it is hard to explain by incompetence and bordering on the realm of malice.
Remember, 486 machines predate the advent of DMA transfers, so you'll be sucking up all of your (already very limited) CPU just to manage disk activity.
This is a total load of crap. Even of the 8088 IBM compatible computers, most (if not all) had DMA chips.
They had DMA chips on the motherboard, but hard drives did not support DMA transfers stably until well into the Pentium era. Why do you think Windows did not include DMA drivers? Hell, Linux distributions didn't even default to DMA drive transfers until 2001 or so. DMA at the time was used for things like sound cards.
About using a 486 and X: you obviously know nothing about this. I used a 100MHz 486 with 16MB of RAM from 1996 to about 2000 or 2001, and it ran X okay. When I say "okay", I mean okay for me. Current "fast" computers with KDE or Gnome are not okay for me: they run slow.
This is the same thing that a lot of other commenters have suggested. "Run an older distro with an older X" or something. That will indeed result in acceptable performance (if you ignore the human factor of the crappy 640x480 passive matrix LCD screen). But you'll be running a trivially insecure machine with who knows how many exploits. X in particular is a large program that needs suid root privileges (not true anymore on very recent setups with KMS, but that is not going to help the submitter). Those old linux/X versions that could run with limited resources did so at the price of insecurity. All that stuff today that you perceive as "slow" is the price of security engineering. This is especially the case for critical components like the kernel, the web browser, and yes, the X server. I'm not talking about KDE/GNOME here. Updating the X server alone from X11R6 to X11R7.5 (by which I mean, the protocol, not the actual server codebase) would cripple a 486. I would never run any version of any system software (such as X) dating from 1996 or 2001 on a machine accessing the internet today.
It may require using an older X binary (better lock it out of the internet with -nolisten tcp and such), it will probably also require compiling a custom 2.4 kernel, but I don't see the big problem. What is with all the naysayers?
The naysaying is because the submitter clearly doesn't know what he's getting into, and what you describe (while possible) is very hard to get right. Even if you configure X not to listen to any ports, a security hole in your (custom) kernel or your web browser means one more zombie bot on the internet, and although one more makes no difference, I wanted to do what I can.
When you add on top of that the fact that the machine has a 640x480 and likely passive matrix display, you have to ask: what's the point.
Thrash has a very specific meaning, which you seem not to understand.
My slashdot ID is lower than yours. I understand full well what thrash means, and I meant thrash.
You're not going to be doing heavy multimedia, or running a major database server, so it's unlikely you'll be doing enough disk access that you'll care.
The mere act of administering a system (to install security updates, say) is already more disk access than a normal person would care to endure.
Perhaps you missed the part where the submitter mentioned that the machine's display resolution was 640x480.
That's almost DVD resolution. It's not that bad.
It's 2009. 640x480 for a graphical display is bad, and no amount of scaling or font size tweaking will fix it. But even if we totally ignore this and grant everything you said, you're still ignoring huge issues that make the idea of using this laptop totally unworthwhile. For example, laptops from the 486 era had passive matrix displays. They are positively painful to look at for long periods of time. There's a reason why passive matrix displays dropped out of the marketplace despite their low cost.
Besides, if you factor in either the extra time required for setting up and using such a slow machine (at minimum wage)
You're making an awful lot of false assumptions...
Minimum wage is if anything an extremely conservative estimate of the time value of money in any developed country. If the submitter wants to provide additional information then by all means go ahead.
That's nonsense. Boot times might not be fast (most services can be
disabled) but there's no reason a 486 wouldn't smoke at the console.
If you're using the 486 as a console, and nothing else, then it
will work. I mentioned this in my original post. However, text consoles
by themselves aren't very interesting these days. It's not like the
average person has a machine lying around that lacks a display console.
If you try to do anything else on the 486, such as use the
disk, then the machine will thrash. Remember, 486 machines predate the
advent of DMA transfers, so you'll be sucking up all of your
(already very limited) CPU just to manage disk activity.
I really can't see a 486 being useful, even in console mode, unless you literally need a console for some reason.
X11 with a lightweight window manager like Blackbox would work just
fine on an old CPU...
I really doubt it. I've used Blackbox when the occasion calls for it,
and although Blackbox is great, it's not fast enough for a 486. An AMD
Socket 7 K6 is about the slowest machine I can tolerate, even with
Blackbox.
And again, even if the X server runs, what would you do with
it? Perhaps you missed the part where the submitter mentioned that the
machine's display resolution was 640x480. I mean, 640x480, are you
kidding? It's also a laptop machine, which means that upgrading the
video card is not an option, not that it would be worth it anyway. You
mentioned running out of RAM, but you forgot to consider video RAM
(which is not easy to upgrade).
It'll take a good 4 years before the cost of electricity pays for
your ShevaPlug.
4 years is not that long a time in this context. I certainly wouldn't
want to go through setting up a low end machine any more often than once
per four years. Besides, if you factor in either the extra time
required for setting up and using such a slow machine (at minimum wage)
or the risk of future energy price shocks, the time to
break even is much closer to 2 years than 4 years. And finally, the
SheevaPlug was just one example. Plenty of other commenters have
mentioned that you can get Pentium 3 machines for free these days, which
won't save any electricity, but will be a lot more pleasant to use.
Fedora provides Appliance OS spins for recent versions (F10 and up), which are highly stripped down Fedora images, coming in at 100-200 MB of disk. The OS is shipped as an ext3 image, not an ISO image.
However, it's still pointless to do what the submitter is attempting. 486 machines weren't even interesting targets 9 years ago. Any recent version of Fedora won't boot on a 486, since Fedora is now compiled for i686 and up. Even if you got it to boot, it would be too slow for a modern X, and nearly too slow even for a console.
The only modern-day task that a 486 machine can still perform acceptably is IP routing. Most people still have "slow" (by networking standards) DSL or cable connections. An old machine is perfectly capable of handling such speeds. But it's still a very bad idea. Energy costs are so high these days that buying a new low-power router machine is much cheaper than running a 486 even in the medium term (1-2 years), and the new machine will be much more capable and featureful. For $99 you can get a SheevaPlug which comes with Ubuntu and consumes 5 watts.
If I was setting up a 486 machine anyway, my distribution of choice would be Voyage Linux. Voyage is just a very small Debian Lenny installation with a few additional (small) packages for embedded environments. It doesn't ship as an ext2 image, but rather as a tarball that you untar, which is just as good. The kernel is compiled for 486, so (unlike Fedora) it will actually boot. In theory, you can apt-get anything in the Debian repositories (including X, GNOME, etc.), but in practice it won't work on a 486. There are just too many differences between modern X11R7.5 and contemporary versions to the 486 like X11R5 or X11R6. I've done this before, and I can tell you that you won't be happy with the GUI even if you get it to run.
A lot of commenters have suggested running an old distribution. This is a bad idea on any machine that you plan to connect to the internet. Even if there's a firewall in between, old versions of Linux have so many security holes that they represent an unacceptable risk. Old Linux versions are just as insecure as old Windows versions. Don't make the spambot problem worse. As a side note, distributions that provide no mechanism for in-place security upgrades are also insecure. This rules out most mini-distros like DSL or Puppy Linux.
Basically, there's no way to run X securely on such old hardware. Just forget about it. If you intend to use it as a text terminal, then it might be worth setting up. Even then, don't leave it on all the time, or your electricity bill will dwarf any savings. (If you're not paying for the electricity, still, do the rest of us a favor, and save the planet from global warming or something.)
These handheld electronics bans are completely absurd and have no basis in reality or in science whatsoever. Why? Well, I am glad you asked. This bill states that a handheld cell phone is bad, but a hands-free one is ok. Well, science has shown again and again that the problem with using a cell phone while driving in the TALKING part, not holding the phone. If holding the phone were the problem, the ban would be on driving one handed. Having a conversation with a passenger would create the same distraction.
All correct, except for the last sentence. Having a conversation on a cell phone is no way whatsoever the same as having a conversation with a passenger. The cell phone conversation is much, much worse.
A passenger in the same car has the same situational awareness as you. They can see other vehicles, hear outside traffic, feel your vehicle's motion, and so on. When road conditions become dangerous, the passenger will automatically prompt the driver to watch the road. This can take the form of either explicit warnings to pay attention to driving, or even seemingly insignificant (but in fact significant) social cues such as brief holds on conversation. In many cases, the passenger actually contributes to vehicle safety in a positive way, by doing things such as watching for cars in the other lane, or alerting the driver to hazards that the driver otherwise would have missed. All of these benefits can persist during conversation, and in fact communication during driving, far from being detrimental, is actually required in order to realize these benefits.
When you're talking to someone on your cell phone, these positive benefits are absent. On a cell phone, you only have the distraction of holding a conversation with someone, and the person on the other end provides none of the offsetting safety benefits that a passenger in the same car would normally provide.
In fact, even if the passenger in the car is a toddler or someone incapable of contributing to safety, it's still less dangerous than a cell phone conversation (although very much more dangerous than talking to a competent adult). At least you can respond to challenging road conditions by stopping the conversation automatically, without having to explain yourself later on.
grab a second hand thin-client from ebay then reflash it with a linux image and use it as a server. They're cheap. Typically they are fanless Via c7 or Geodes; so, they're low power. Do your research first, some use CF cards but others have flash on the circuit board, which makes reflashing them harder. I've found some of them actually have a 44pin ide header and use a CF card adapter; so, you can plug in a cheap laptop harddrive. In either case, most of the newer ones will have 4-6 usb ports.
I've actually done this, and while it's an awesome fit for my needs (I'm typing from it right now), I'm not convinced that it would work well for the poster. In particular, the poster seems to be looking for a file server, and the thin clients aren't very good for that.
If the flash is built-in to the circuit board, the flash is likely an obsolete DiskOnChip, which had driver patches only for linux 2.4.18. Those drivers are now unavailable on the net anyway, and in any case the DoC is very slow. IDE is a better fit -- most of the devices will have an IDE header on the motherboard, whether or not it's used for flash. Even so, disk I/O is one of the major weak points of thin clients, and the slow CPU does not help either. In most cases, you will need a 44-pin IDE cable to connect a hard drive to the IDE header, and nobody makes 80-wire 44-pin IDE cables, which means you're limited to UDMA/33 speeds. RAID is also out of the question since it only supports one drive. The only way it makes sense as a file server is if the device supports USB 2.0 (not all of them do), and you have a USB 2.0 drive enclosure. But if you use USB, it'll suck up most of your CPU to fully utilize that USB link.
Where the thin clients really shine is in networking. They are great as low-power fanless IP routers, with plenty of CPU to handle whatever complex routing tasks you throw at it. If you use encryption, the ones with VIA CPUs have hardware AES instructions, absolutely ideal for encrypted transfers: VPN (IPsec, OpenVPN), sftp, scp, sshfs, and so on. A single thin client serving multiple sshfs/VPN clients completely kicks the tar out of even a very high end Intel/AMD server, and for far less power and noise. For example, on my 800MHz C3, I get 1.2 GB/s of AES throughput, which is literally faster than an 8-way 2.4GHz Opteron server using all 8 cores (the latter coming in at 1.1 GB/s). For serious networking, you'll need a PCI riser for a second ethernet card, although I find that even with one ethernet card the hardware encryption instructions more than make up for the single link.
If you want a diskless setup, all except the very oldest thin clients can boot from USB flash. The ones with USB 1.x will be slow to boot, but they run fine from a RAM disk. A CF-IDE adapter is another option.
Still wondering why ? A 6th grader with a good pair of eyes can understand and control a paper vote. The more people you gather to keep watch, the better, no training necessary. It would take you, with all your intelligence and experience, weeks of efforts to verify an e-system implementation, and you'd be one of a handful able to do so. And all it would take to rig the system would be to outsmart your small lot of scientists. Just *imagine* for a second the source code is mathematically correct and you verified it. How about the compiler ? Do you know if the system really runs on the bare metal or is it trapped in a VM ? Are you per chance a computer scientist as well as a cryptologist ? How many scientists would it take to screw that light bulb in the end ? How long would it take ?
Thanks, but I am neither a computer scientist, nor am I still wondering why. I figured out what you said a long time ago. Some computer scientists have also figured it out. That's why a lot of voting research these days is in the area of non-cryptographic voting schemes that still provide secret ballot end-to-end security. No such scheme is known today, but significant progress has been made, for example ThreeBallot by Ron Rivest.
I, and many researchers, are well aware that no solution to the voting problem can ever involve a system, or a compiler, or source code, or any sort of bare metal hardware. The solution has to be non-cryptographic. Unfortunately, the politicians and legislators have not realized this yet (or they have, and are committing intentional sabotage), and most importantly, the general public has not realized this yet. The general public still thinks that voting machines are the way to go.
As a matter of due diligence, I will look up your "David Chaum's blind signature" (I may have already). I'm certain it will have a fatal flaw, as has every system I've examined thus far. It doesn't matter how many people jump up and down in support of their ideologies or how vigorously. Nobody has shown me a secret ballot, end-to-end verifiable voting system. I do not believe one exists. (I would like to be proven wrong, but I don't think anybody can.)
Disclaimer: I am a cryptographer, and I have done research on topics related to electronic voting in the past.
As a matter of simply stating a fact, regardless of your due diligence, the fact is that blind signatures and their application to electronic voting is a subject which is about 15 years old by now. If you didn't already know about this concept, then you are clearly not an expert in electronic voting or even in any related field of cryptology. Cryptographic electronic voting is a highly technical subject involving many different areas and subfields of cryptology, some of them heavily number theoretic and mathematical. You are probably not technically knowledgeable enough to pass judgment on such heavily technical subjects in which you are uninformed (or worse, prejudiced against, as evidenced by your choice use of words such as "ideologies").
Even if I'm wrong about you, and you are technically knowledgeable enough to correctly evaluate cryptographic voting systems, it doesn't matter. For every one of you, there are thousands of other voters who are not technically knowledgeable, but who think that they are.
The problem with voting systems is not mathematical. It is not cryptographic. From the point of view of cryptography, secret ballot, end-to-end verifiable voting systems do exist, and have been known for decades. Either a mix net or the Benaloh cryptosystem together with threshold secret sharing delegation of trust is all that is required. The problem with cryptographic end-to-end voting systems is that for every one cryptographer in the world, there are thousands of uninformed members of the general public who don't understand the math, and who think that the scheme is either untrustworthy or that they have found a flaw. For this reason, even if there is a secret ballot, end-to-end verifiable voting system (which there is), it will never be accepted by the general public. As a research scientist, I have had far too much experience in dealing with such obstacles. The public does not trust scientists, even when the scientists clearly know more than they do.
I shouldn't be able to verify my own vote. If I can verify my vote, I can prove to myself after the fact how I voted, and therefore I can prove it to somebody else.
I am a cryptography researcher, and I have to correct this information.
What you wrote is absolutely not true, even though naively it seems obviously true. Modern cryptography is much much better than you think it is, to the point where things that seem impossible to an average layperson are actually possible. In particular, there are techniques like deniable authentication which allow you to verify your own vote while being unable to prove to anyone else how you voted. Read up on it, or at least make yourself aware of the state of the art of current research, so that you don't spread false statements.
Definitely agree to disagree, and yes, interesting discussion. The way I see it, if Amazon started selling instant PDF downloads of books, without tying them to the Kindle, I think the response would be tremendously positive, and the money they stand to gain would dwarf their profits from the Kindle. So, from the point view of what could have been, e-ink displays are not the largest driver of customer interest. (Right now, they are the largest market segment, but that's because Amazon only sells ebooks in Kindle format.)
What I described will never happen, but only because the publishers are deathly afraid of piracy. It's certainly not because of a lack of market demand for PDF format ebooks.
Slashdot Mirror
Every life is important. Just because it's not possible to prevent deaths everywhere , doesn't mean you should be ok with unnecessary slaughter of innocent people.
In the real world, resources are limited. If spending 50 billion dollars on anti-terrorism saves 4000 lives, and spending 50 billion dollars on food aid saves 1 million lives, then the latter is clearly a better decision, notwithstanding the fact that every life is important.
Of course, in the real world, what we actually ended up doing is spending 1 trillion dollars fighting two deadly wars with heavy civilian casualties.
Yes, price fixing is bad, but seriously "victimized" consumers? Yeah, they overpaid for an LCD, but they -chose- to pay that amount for an LCD.
You're missing some basic knowledge of economics here. The victims are not the consumers who actually overpaid for an LCD. The victims are the potential consumers who would have bought an LCD had they been fairly priced, but who couldn't afford to pay the inflated price. This category of "lost potential purchases" is known as "deadweight loss" in economics.
Unfortunately, our legal system provides no way for the true victimized class to receive compensation.
Your examples of DNS hijacking are legitimate but extreme. There is a large middle ground of ISP behavior where using third party DNS is beneficial. In addition, if widespread adoption of Google DNS leads to increasingly extreme DNS hijacking on the part of ISPs, at least we'll have some concrete evidence of ISP misbehavior to cite in net neutrality debates and the like. (ISPs can hijack DNS, but they can't do so in secret.)
Its funny how the Google hype is driving so much talk about something like DNS, a service which probably 95% of non-tech people don't know exists. Most people wouldn't care about DNS normally, but since its Google it must be something to get excited about.
I'm not normally a fan of Google, but if they spark some sort of increased public awareness on the issue of DNS, that can only be a good thing. DNS receives far too little public attention relative to its importance.
I doubt really that any significant number of people will switch to using 8.8.8.8, but I worry that if they do, one of the the original goals for DNS will be lost. That its distributed.
DNS stopped being distributed when people started abusing domain name registration. The resulting collapse of DNS into, effectively, a single level hierarchy meant that the original design goals (including the goal of distributed lookups) were already unachievable long ago. This is not really Google's fault.
IP anycast to Google's DNS servers is not any worse than the situation that exists today with respect to our reliance on the root name servers.
Just ask yourself one question, if you don't trust your internet provider enough to do DNS correctly, should you trust them at all?
This is a good question, for which there are two legitimate responses. One is that, in practice, it is often impossible to change ISPs (there may be only one broadband provider in an area). In such cases, using a third party DNS, especially one that defaults to accurate responses (unlike OpenDNS), is often the least bad option out of all the (worse) alternatives. The second point is that there are cryptographic protocols like ssh and SSL which guarantee (or, in the case of SSL, are supposed to guarantee) session integrity, regardless of ISP interference. So, for most important tasks, you don't need a high level of trust in your ISP. For DNS, however, there is no cryptographic protocol to guarantee integrity (DNSSEC doesn't count). It is thus perfectly logical to trust an ISP for ssh/SSL but not for DNS.
Real geeks won't bother with third party DNS; they'll just set up their own recursive nameserver. But for less technically savvy internet users, Google DNS does fulfill a need that was being left unserved. The old Level3 servers at 4.2.2.* fill this role as well, but they were never (to my knowledge) advertised for public use.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly.
Did you try Aaron Stebner's .NET cleanup tool? It's not an official MS product but it's written by an MS dev. I had a system with the same problem, and the cleanup tool fixed it.
The policy previously allowed users who were logged in to the local console to install signed packages from a repository. ... Users who have physical access to a computer can compromise it far more easily than waiting for a vulnerability to be found in a package that isn't installed, installing that package before an update is issued, and exploiting the vulnerability.
You are incorrect in equating local console logins with physical access. I pointed this out several times on the bugzilla, but it seems that the myth persists.
There exist OS-level tools such as x11vnc or x0rfbserver whose entire purpose is to provide remote users with the ability to manipulate the local console. These tools do not require root privileges to run. An attacker who gains remote access illicitly can compile or copy over an x11vnc binary and subvert the local console.
Of course, an attacker who has remote access is already very bad news for you, but that doesn't mean they have root, and it's no excuse for making it any easier for them to gain root.
What boggles my mind is that Richard Hughes was apparently aware of the existence of tools like x11vnc and their effects, and yet he advocated in favor of this change anyway. I don't want anybody with this attitude to be even in the same room as any discussion on security policy. This is not a personal attack on Richard Hughes, it's just a simple fact. Security engineering requires a certain mindset, and if you don't have that mindset, then get out of the discussion.
The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago.
Let's be clear here. They discussed modifying PackageKit to allow an administrator to create such configurations. Nowhere in the entire thread did anyone mention "Oh by the way, let's also make this the default configuration for the F12 release."
Don't believe me? See for yourself.
Boy, that's what I love about you nuclear nuts. Your childish Rube Goldberg scheme is like a Keystone Cops film. Dated, but amusing.
It is to be expected that you will have to resort to amusing yourself with insults once you run out of substantive criticisms.
In fact, since depleted uranium contains about half as much U235 as natural uranium, we can say that there is a practical limit of 700 million years for fission power in the solar system since we won't bother with uranium that is depleted by half.
Depleted uranium can still be used as a source of U235, it's just an expensive source for which there is no reason to use it right now. Do not confuse expensive with impossible. (Or, in your case, stop deliberately trying to confuse the two.)
A half life of 700 million years means that, in 5 billion years, 99.3% of the U235 will be gone (seven half lives = 127/128). But as I already explained (and you deliberately ignored), we only need one atom of U235 to convert U238 into plutonium. We will have single atoms available for a long time. Separating out such small quantities of U235 will be expensive, but not impossible, especially considering we only have to do it once.
Plutonium 239 has a half life of 24000 years. That's not long enough for long term storage, but it sure is long enough to sustain breeder reactors. You don't need 24000 years to take plutonium out of one nuclear reactor and use it to start another. Once you start a second nuclear reactor, you have another source of plutonium, good for another 24000 years. And so on. This is so obvious that I feel like I'm explaining things to a child.
There is a practical limit of about 50 years on Earth since we are not going to use breeders and the practical ore will be gone.
The whole argument since the great-great-great-great-grandparent post that started this entire thread is that we are going to use breeders, so for you to waltz in and proclaim unilaterally that we are not going to use breeders is, well, a bit presumptuous, but feel free to continue living in your own bubble.
Where do the neutrons come from to convert U238? U235.
The whole point of a chain reaction is that the fission of a single atom of U235 can convert multiple atoms of U238. Once you have some Pu-239, you can use the Pu-239 as a source of free neutrons. No U235 is necessary after that point.
To quote again Wikipedia:
These facts are really not in dispute by anyone who knows even the least bit about nuclear reactions, and you make yourself look really ignorant by contesting them.
Wow! statements like this are really really sad. It is U235 that is used, and U235 that is discussed in the article.
You are wrong. Well, you are partly right. You are correct that the article discusses only U235, but you are wrong about U235 being used for plutonium. Plutonium is most definitely generated from U238, not U235. Quote from Wikipedia:
The reason why the article discusses only U235, is because the article chooses to ignore the energy available from plutonium and U238.
How long will billions of years of uranium last? 250 years? 300? (I haven't run the numbers, but what I can tell you is that the emeritus professor from Stanford is wrong (or irrelevant) because his starting assumptions are wrong)
If you run the numbers then 1 billion years' supply under present consumption rates lasts for 635 years under 3% growth. But, your numbers are just as wrong and irrelevant as those of the calculation that you are accusing, since there is absolutely no reason why historical growth trends must continue to be the case indefinitely into the future.
For comparison, the entire mass-energy resources of the observable universe will be depleted in 5000 years under the (plainly untenable) assumption of perpetual 3% growth.
You should be calculating the amount of uranium in the surface of the earth, not the volume. Deep mining is less realistic than asteroid mining; it's unlikely to ever happen. Practically speaking, at current demand and growth rates, with enrichment, u238 buys us only a couple hundred years. ("Only.")
But hey, eventually we'll switch to the thorium cycle, and then fusion, and scarcity will actually vanish.
If you actually read the calculations, they are done using only uranium in the crust (in fact, using only uranium in seawater). There is no deep mining, or indeed any sort of mining, required.
The growth rate concern is unrealistic, as it has been mentioned already that no constant growth rate is sustainable indefinitely, under any energy technology. The amount of uranium we lose from natural radioactive decay (half life of 4.5 billion years for U238) exceeds any amount that we are likely to consume for fuel.
Do that calculation again, and instead of assuming zero growth. Do it assuming 3% growth, because that's the average.
No energy source whatsoever in the physical universe can accommodate perpetual 3% growth. Therefore the demand to accommodate 3% perpetual growth is unreasonable.
The problem is that plutonium is a man-made material. We make it from uranium by bombarding it with high energy particles. So if you run out of uranium, you also run out of plutonium. This is of course dependant on us not discovering alchemy in the next 10 years. To be honest, that would be pretty awesome, if watching TV has taught me anything.
You're right, but also wrong. Plutonium is made from U238 (emphasis on 238). The nuclear fuel that we're using right now is U235. There is one hundred and fifty times more U238 in the ground than U235. So, by switching to plutonium, we expand the available supply of uranium by a factor of 150.
The whole debate about uranium fuel reserves is totally ludicrous. An utterly simple back of the envelope calculation demonstrates that the Earth contains sufficient uranium to supply fission power for billions of years. Uranium fuel will last literally longer than solar power (since the sun's remaining lifetime is only 5 billion years). Yet periodically we see attention whores showing up in Slashdot articles and crying that we will run out of uranium, a statement which is so obviously wrong that it is hard to explain by incompetence and bordering on the realm of malice.
Remember, 486 machines predate the advent of DMA transfers, so you'll be sucking up all of your (already very limited) CPU just to manage disk activity.
This is a total load of crap. Even of the 8088 IBM compatible computers, most (if not all) had DMA chips.
They had DMA chips on the motherboard, but hard drives did not support DMA transfers stably until well into the Pentium era. Why do you think Windows did not include DMA drivers? Hell, Linux distributions didn't even default to DMA drive transfers until 2001 or so. DMA at the time was used for things like sound cards.
About using a 486 and X: you obviously know nothing about this. I used a 100MHz 486 with 16MB of RAM from 1996 to about 2000 or 2001, and it ran X okay. When I say "okay", I mean okay for me. Current "fast" computers with KDE or Gnome are not okay for me: they run slow.
This is the same thing that a lot of other commenters have suggested. "Run an older distro with an older X" or something. That will indeed result in acceptable performance (if you ignore the human factor of the crappy 640x480 passive matrix LCD screen). But you'll be running a trivially insecure machine with who knows how many exploits. X in particular is a large program that needs suid root privileges (not true anymore on very recent setups with KMS, but that is not going to help the submitter). Those old linux/X versions that could run with limited resources did so at the price of insecurity. All that stuff today that you perceive as "slow" is the price of security engineering. This is especially the case for critical components like the kernel, the web browser, and yes, the X server. I'm not talking about KDE/GNOME here. Updating the X server alone from X11R6 to X11R7.5 (by which I mean, the protocol, not the actual server codebase) would cripple a 486. I would never run any version of any system software (such as X) dating from 1996 or 2001 on a machine accessing the internet today.
It may require using an older X binary (better lock it out of the internet with -nolisten tcp and such), it will probably also require compiling a custom 2.4 kernel, but I don't see the big problem. What is with all the naysayers?
The naysaying is because the submitter clearly doesn't know what he's getting into, and what you describe (while possible) is very hard to get right. Even if you configure X not to listen to any ports, a security hole in your (custom) kernel or your web browser means one more zombie bot on the internet, and although one more makes no difference, I wanted to do what I can.
When you add on top of that the fact that the machine has a 640x480 and likely passive matrix display, you have to ask: what's the point.
Thrash has a very specific meaning, which you seem not to understand.
My slashdot ID is lower than yours. I understand full well what thrash means, and I meant thrash.
You're not going to be doing heavy multimedia, or running a major database server, so it's unlikely you'll be doing enough disk access that you'll care.
The mere act of administering a system (to install security updates, say) is already more disk access than a normal person would care to endure.
Perhaps you missed the part where the submitter mentioned that the machine's display resolution was 640x480.
That's almost DVD resolution. It's not that bad.
It's 2009. 640x480 for a graphical display is bad, and no amount of scaling or font size tweaking will fix it. But even if we totally ignore this and grant everything you said, you're still ignoring huge issues that make the idea of using this laptop totally unworthwhile. For example, laptops from the 486 era had passive matrix displays. They are positively painful to look at for long periods of time. There's a reason why passive matrix displays dropped out of the marketplace despite their low cost.
Besides, if you factor in either the extra time required for setting up and using such a slow machine (at minimum wage)
You're making an awful lot of false assumptions...
Minimum wage is if anything an extremely conservative estimate of the time value of money in any developed country. If the submitter wants to provide additional information then by all means go ahead.
That's nonsense. Boot times might not be fast (most services can be disabled) but there's no reason a 486 wouldn't smoke at the console.
If you're using the 486 as a console, and nothing else, then it will work. I mentioned this in my original post. However, text consoles by themselves aren't very interesting these days. It's not like the average person has a machine lying around that lacks a display console. If you try to do anything else on the 486, such as use the disk, then the machine will thrash. Remember, 486 machines predate the advent of DMA transfers, so you'll be sucking up all of your (already very limited) CPU just to manage disk activity.
I really can't see a 486 being useful, even in console mode, unless you literally need a console for some reason.
X11 with a lightweight window manager like Blackbox would work just fine on an old CPU...
I really doubt it. I've used Blackbox when the occasion calls for it, and although Blackbox is great, it's not fast enough for a 486. An AMD Socket 7 K6 is about the slowest machine I can tolerate, even with Blackbox.
And again, even if the X server runs, what would you do with it? Perhaps you missed the part where the submitter mentioned that the machine's display resolution was 640x480. I mean, 640x480, are you kidding? It's also a laptop machine, which means that upgrading the video card is not an option, not that it would be worth it anyway. You mentioned running out of RAM, but you forgot to consider video RAM (which is not easy to upgrade).
It'll take a good 4 years before the cost of electricity pays for your ShevaPlug.
4 years is not that long a time in this context. I certainly wouldn't want to go through setting up a low end machine any more often than once per four years. Besides, if you factor in either the extra time required for setting up and using such a slow machine (at minimum wage) or the risk of future energy price shocks, the time to break even is much closer to 2 years than 4 years. And finally, the SheevaPlug was just one example. Plenty of other commenters have mentioned that you can get Pentium 3 machines for free these days, which won't save any electricity, but will be a lot more pleasant to use.
However, it's still pointless to do what the submitter is attempting. 486 machines weren't even interesting targets 9 years ago. Any recent version of Fedora won't boot on a 486, since Fedora is now compiled for i686 and up. Even if you got it to boot, it would be too slow for a modern X, and nearly too slow even for a console.
The only modern-day task that a 486 machine can still perform acceptably is IP routing. Most people still have "slow" (by networking standards) DSL or cable connections. An old machine is perfectly capable of handling such speeds. But it's still a very bad idea. Energy costs are so high these days that buying a new low-power router machine is much cheaper than running a 486 even in the medium term (1-2 years), and the new machine will be much more capable and featureful. For $99 you can get a SheevaPlug which comes with Ubuntu and consumes 5 watts.
If I was setting up a 486 machine anyway, my distribution of choice would be Voyage Linux. Voyage is just a very small Debian Lenny installation with a few additional (small) packages for embedded environments. It doesn't ship as an ext2 image, but rather as a tarball that you untar, which is just as good. The kernel is compiled for 486, so (unlike Fedora) it will actually boot. In theory, you can apt-get anything in the Debian repositories (including X, GNOME, etc.), but in practice it won't work on a 486. There are just too many differences between modern X11R7.5 and contemporary versions to the 486 like X11R5 or X11R6. I've done this before, and I can tell you that you won't be happy with the GUI even if you get it to run.
A lot of commenters have suggested running an old distribution. This is a bad idea on any machine that you plan to connect to the internet. Even if there's a firewall in between, old versions of Linux have so many security holes that they represent an unacceptable risk. Old Linux versions are just as insecure as old Windows versions. Don't make the spambot problem worse. As a side note, distributions that provide no mechanism for in-place security upgrades are also insecure. This rules out most mini-distros like DSL or Puppy Linux.
Basically, there's no way to run X securely on such old hardware. Just forget about it. If you intend to use it as a text terminal, then it might be worth setting up. Even then, don't leave it on all the time, or your electricity bill will dwarf any savings. (If you're not paying for the electricity, still, do the rest of us a favor, and save the planet from global warming or something.)
These handheld electronics bans are completely absurd and have no basis in reality or in science whatsoever. Why? Well, I am glad you asked. This bill states that a handheld cell phone is bad, but a hands-free one is ok. Well, science has shown again and again that the problem with using a cell phone while driving in the TALKING part, not holding the phone. If holding the phone were the problem, the ban would be on driving one handed. Having a conversation with a passenger would create the same distraction.
All correct, except for the last sentence. Having a conversation on a cell phone is no way whatsoever the same as having a conversation with a passenger. The cell phone conversation is much, much worse.
A passenger in the same car has the same situational awareness as you. They can see other vehicles, hear outside traffic, feel your vehicle's motion, and so on. When road conditions become dangerous, the passenger will automatically prompt the driver to watch the road. This can take the form of either explicit warnings to pay attention to driving, or even seemingly insignificant (but in fact significant) social cues such as brief holds on conversation. In many cases, the passenger actually contributes to vehicle safety in a positive way, by doing things such as watching for cars in the other lane, or alerting the driver to hazards that the driver otherwise would have missed. All of these benefits can persist during conversation, and in fact communication during driving, far from being detrimental, is actually required in order to realize these benefits.
When you're talking to someone on your cell phone, these positive benefits are absent. On a cell phone, you only have the distraction of holding a conversation with someone, and the person on the other end provides none of the offsetting safety benefits that a passenger in the same car would normally provide.
In fact, even if the passenger in the car is a toddler or someone incapable of contributing to safety, it's still less dangerous than a cell phone conversation (although very much more dangerous than talking to a competent adult). At least you can respond to challenging road conditions by stopping the conversation automatically, without having to explain yourself later on.
grab a second hand thin-client from ebay then reflash it with a linux image and use it as a server. They're cheap. Typically they are fanless Via c7 or Geodes; so, they're low power. Do your research first, some use CF cards but others have flash on the circuit board, which makes reflashing them harder. I've found some of them actually have a 44pin ide header and use a CF card adapter; so, you can plug in a cheap laptop harddrive. In either case, most of the newer ones will have 4-6 usb ports.
I've actually done this, and while it's an awesome fit for my needs (I'm typing from it right now), I'm not convinced that it would work well for the poster. In particular, the poster seems to be looking for a file server, and the thin clients aren't very good for that.
If the flash is built-in to the circuit board, the flash is likely an obsolete DiskOnChip, which had driver patches only for linux 2.4.18. Those drivers are now unavailable on the net anyway, and in any case the DoC is very slow. IDE is a better fit -- most of the devices will have an IDE header on the motherboard, whether or not it's used for flash. Even so, disk I/O is one of the major weak points of thin clients, and the slow CPU does not help either. In most cases, you will need a 44-pin IDE cable to connect a hard drive to the IDE header, and nobody makes 80-wire 44-pin IDE cables, which means you're limited to UDMA/33 speeds. RAID is also out of the question since it only supports one drive. The only way it makes sense as a file server is if the device supports USB 2.0 (not all of them do), and you have a USB 2.0 drive enclosure. But if you use USB, it'll suck up most of your CPU to fully utilize that USB link.
Where the thin clients really shine is in networking. They are great as low-power fanless IP routers, with plenty of CPU to handle whatever complex routing tasks you throw at it. If you use encryption, the ones with VIA CPUs have hardware AES instructions, absolutely ideal for encrypted transfers: VPN (IPsec, OpenVPN), sftp, scp, sshfs, and so on. A single thin client serving multiple sshfs/VPN clients completely kicks the tar out of even a very high end Intel/AMD server, and for far less power and noise. For example, on my 800MHz C3, I get 1.2 GB/s of AES throughput, which is literally faster than an 8-way 2.4GHz Opteron server using all 8 cores (the latter coming in at 1.1 GB/s). For serious networking, you'll need a PCI riser for a second ethernet card, although I find that even with one ethernet card the hardware encryption instructions more than make up for the single link.
If you want a diskless setup, all except the very oldest thin clients can boot from USB flash. The ones with USB 1.x will be slow to boot, but they run fine from a RAM disk. A CF-IDE adapter is another option.
Still wondering why ? A 6th grader with a good pair of eyes can understand and control a paper vote. The more people you gather to keep watch, the better, no training necessary. It would take you, with all your intelligence and experience, weeks of efforts to verify an e-system implementation, and you'd be one of a handful able to do so. And all it would take to rig the system would be to outsmart your small lot of scientists. Just *imagine* for a second the source code is mathematically correct and you verified it. How about the compiler ? Do you know if the system really runs on the bare metal or is it trapped in a VM ? Are you per chance a computer scientist as well as a cryptologist ? How many scientists would it take to screw that light bulb in the end ? How long would it take ?
Thanks, but I am neither a computer scientist, nor am I still wondering why. I figured out what you said a long time ago. Some computer scientists have also figured it out. That's why a lot of voting research these days is in the area of non-cryptographic voting schemes that still provide secret ballot end-to-end security. No such scheme is known today, but significant progress has been made, for example ThreeBallot by Ron Rivest.
I, and many researchers, are well aware that no solution to the voting problem can ever involve a system, or a compiler, or source code, or any sort of bare metal hardware. The solution has to be non-cryptographic. Unfortunately, the politicians and legislators have not realized this yet (or they have, and are committing intentional sabotage), and most importantly, the general public has not realized this yet. The general public still thinks that voting machines are the way to go.
As a matter of due diligence, I will look up your "David Chaum's blind signature" (I may have already). I'm certain it will have a fatal flaw, as has every system I've examined thus far. It doesn't matter how many people jump up and down in support of their ideologies or how vigorously. Nobody has shown me a secret ballot, end-to-end verifiable voting system. I do not believe one exists. (I would like to be proven wrong, but I don't think anybody can.)
Disclaimer: I am a cryptographer, and I have done research on topics related to electronic voting in the past.
As a matter of simply stating a fact, regardless of your due diligence, the fact is that blind signatures and their application to electronic voting is a subject which is about 15 years old by now. If you didn't already know about this concept, then you are clearly not an expert in electronic voting or even in any related field of cryptology. Cryptographic electronic voting is a highly technical subject involving many different areas and subfields of cryptology, some of them heavily number theoretic and mathematical. You are probably not technically knowledgeable enough to pass judgment on such heavily technical subjects in which you are uninformed (or worse, prejudiced against, as evidenced by your choice use of words such as "ideologies").
Even if I'm wrong about you, and you are technically knowledgeable enough to correctly evaluate cryptographic voting systems, it doesn't matter. For every one of you, there are thousands of other voters who are not technically knowledgeable, but who think that they are.
The problem with voting systems is not mathematical. It is not cryptographic. From the point of view of cryptography, secret ballot, end-to-end verifiable voting systems do exist, and have been known for decades. Either a mix net or the Benaloh cryptosystem together with threshold secret sharing delegation of trust is all that is required. The problem with cryptographic end-to-end voting systems is that for every one cryptographer in the world, there are thousands of uninformed members of the general public who don't understand the math, and who think that the scheme is either untrustworthy or that they have found a flaw. For this reason, even if there is a secret ballot, end-to-end verifiable voting system (which there is), it will never be accepted by the general public. As a research scientist, I have had far too much experience in dealing with such obstacles. The public does not trust scientists, even when the scientists clearly know more than they do.
I shouldn't be able to verify my own vote. If I can verify my vote, I can prove to myself after the fact how I voted, and therefore I can prove it to somebody else.
I am a cryptography researcher, and I have to correct this information.
What you wrote is absolutely not true, even though naively it seems obviously true. Modern cryptography is much much better than you think it is, to the point where things that seem impossible to an average layperson are actually possible. In particular, there are techniques like deniable authentication which allow you to verify your own vote while being unable to prove to anyone else how you voted. Read up on it, or at least make yourself aware of the state of the art of current research, so that you don't spread false statements.
What I described will never happen, but only because the publishers are deathly afraid of piracy. It's certainly not because of a lack of market demand for PDF format ebooks.