So am I the only one worried about this system creating salty rains?
If a cloud created by these ships passes over land and turns into rain, all the salt in the cloud will end up in the soil. We've had trouble with acid rains killing our forests already (which was blamed on cars / industry, iirc) so it does not seem too far fetched...
As for the consequences, most plants, in particular those we use for food, don't like salt. If this is done on a large enough scale to have an effect on the global weather, won't it also have a global effect on our cultures? (Not to mention the wildlife's ecosystems) Or did the scientists study this *non-climate* issue?
I don't see why, a priori, scheduling onto a single core will be more cache efficient. If my threads are working on separate data (and that's essentially the goal of all parallel compute intensive software)
For the special case of parallel compute intensive software yes it's better to schedule each thread on a separate core and Linux is supposed to do so. But this is a special case and since you did not provide this information before I had to envision all possibilities (and I did cover both cases).
Anyway, as I said before this is not the place to discuss this...
I can see that Wine handles multiple threads within a process (it quite clearly has to), but somehow they don't get scheduled concurrently onto different processors.
If they don't max out one core, then Linux will schedule them all on one core because that will be more efficient (cache sharing). However if each thread could use 100% of the CPU, then they should clearly be spread to multiple cores and, as far as I know, it's what happens normally. If so, then it would be worth investigating why it's not happening in your case. Maybe post on wine-users or the new Wine forum giving details about your application, workload and setup so others can hopefully help you diagnose more precisely what's happening.
Wine was a great idea in its day but now with multi-core CPUs and excellent VMs (VMWare, VirtualBox, etc.) do you still see the need for Wine?
Well, besides the purely practical reasons like: Wine is cheaper than paying for a VM application (some are free) plus a Windows license (never free), provides better performance (or should), is better integrated with your Linux environment, etc.
So besides these purely practical reasons, Wine is very important for the big picture: with Windows being on >90% of the computers, our society depends on Windows. Take away Windows and lots of things stop working (from travel agencies to airports and administration) until you can find a replacement. But there is no replacement because no other system is capable of running Windows applications. Wine is the only Windows replacement (ReactOS uses Wine), it is the only alternative supplier of a system that can run Windows applications. Thus, independently of practical aspects, Wine has a very high strategic importance for our society as a whole.
Wine isn't known to reliably run ANY version of Office with anything that would be called reliability. [...] Would outside contributions that removed these limitations from Wine even be merged?
Yes. The most important criterion for deciding whether a patch gets in Wine or not, is whether it makes Wine behave more like Windows or not.
[...] What would be the point of me (me taken as generic) considering looking at Wine with an eye to contributing unless I am first a Crossover Office customer?
That would not be an issue at all. Most Wine developers work on Wine and are not CodeWeavers customers.
Because the odds are good that any particular missing feature in Wine is already implemented in CX, so one would first want to test there to avoid reinventing a wheel
The chances of you reinventing the wheel are very small to inexistent. Yes I think that CrossOver is better than Wine for regular users, but that's not because it has a set of hidden extra Wine wheels somewhere <g>. By the way don't just trust me. Grab our source code (anyone can get it) and compare it to Wine's.
that probably wouldn't get merged anyway.
As I said, if your code is correct and reasonably well written, then it will get merged.
Is this any plan to make it more native in the look & feel?
There is the start of support for themes but it needs to be extended to more controls (e.g. buttons, scrollbars, etc). Also it would be real cool if it could directly use the current KDE/Gnome theme (maybe by converting to a Windows XP theme on the fly or something like that).
However I guess most people consider this to be lower priority than getting Windows applications working in the first place because nobody is currently actively working on it. But that could change. All it would take is a couple of motivated developers...
Will the WINE project try to implement the Windows Vista APIs or will the project aim only for the Windows XP APIs?
Wine does not target any specific Windows version. It does not matter whether the latest Windows version from Microsoft is 2000, XP or Vista.
All that matters is the Windows applications. So let's say World Of Warcraft is very popular. Then people will fix up Wine to make sure all the APIs it uses, for instance Direct3D 9, have a good enough implementation in Wine (and that's exactly what happened). So it does not matter that Microsoft released Vista because that has no bearing on whether WoW will run in Wine or not.
The day popular applications depend on Vista-only APIs, or are shipped for Win64 only, that is the day the corresponding functionality will appear in Wine.
I just wanted to thank the team, on behalf of everyone in the/. crowd, for making sure Notepad.exe was one of them. It was the first Windows program I tried to use under WINE and it performed flawlessly, making me feel a little more at home on Linux.
I know it's a joke, but it's actually worth explaining. Wine's notepad implementation serves (at least) two purposes:
First, a lot of Windows application installers call it to let the user view the readme or release notes. So we need something that's called 'notepad' and can properly display a text file with DOS's CR/LF line endings.
And second, notepad is a good test environment for the edit control (for once we have the application source) and various other aspects like the file open/save dialogs, printing, etc.
The same reasons lead to the addition of wordpad two years ago.
And more importantly, why do they require a minimum top speed of 100 MPH? 80 MPH would be more than sufficient for 99.99% of roads worldwide. I'm glad to learn that France and Germany, to cite just those two, represent less than 0.01% of the roads worldwide. Even if that's the case, I don't see why they would be so much less important than the 0.04% represented by the US roads.
See in France the highest speed limit is 80.8mph and people routinely drive at that speed, even normal people who are neither thieves running from the police, nor cops running after them. And in Germany large swaths of the motorways have no speed limit at all. So in either case a car that can barely reach 80mph for a few minutes and only in ideal conditions is not going to cut it.
I'd be happy with 100 MPG even if I could never get it over 75 MPH. Right, that would be fine for a city car, great even. But then people would have to have a second car for longer trips and that's no good for the environment (due to waste and energy expanded to build the second car), impractical for anyone living in densely populated areas due to limited parking, too expensive for a good portion of the population, etc. In other words it would be a fine achievement, but one with applicability limited to a small part of the market. It's also a niche that's easier to serve with all-electric vehicles for instance, so it's kind of half-solved already. And it's clearly the target of the 'alternative cars' category anyway.
If 99% of CodeWeavers updates go directly to wine, what is the incentive to purchase their product instead of just using wine?
CrossOver has a lot of improvements in the areas around Wine. More specifically:
CrossOver will install our set of supported Windows applications out of the box. We achieve that by configuring Wine just right for each application, knowing which prerequisites each needs, etc. You can do the same thing with plain Wine but you will have to figure out the exact recipe by yourself (or by trying somewhat contradictory advice from the web).
CrossOver is tested against our list of supported Windows applications so you know they will work now and in the future. In contrast, Wine does not try to support any specific application and is still in beta so regressions are still quite common. An application may work this week and not next week.
CrossOver has much better integration with the KDE / Gnome environments. For instance you'll find the Windows applications directly in the KDE/Gnome 'Start Menu'. You can also click on a file or email attachment and have it open in a Windows application, etc.
CrossOver works on the Mac which is not quite the case of Wine yet. Again this has much to do with the stuff surrounding Wine.
Finally, we provide support for those cases where things are not working just right.
Is there a benefit to using Cadega?
Heh, they're competitors so take this with a grain of salt... Imho, no there's no benefit to using Cedega. CrossOver and Wine can already run games almost as well if not better. The reason is that TransGaming forked Wine years ago and made almost no contribution back (so funding them does not help Wine either). So now they're on a mostly separate, years old, code base and it shows...
But the focus needs to be on improving compatibility with all programs. If all this is going to do, is make Photoshop run better, it would be better to spend the money improving the performance of the Gimp and other open source programs.
There is no way to improve compatibility with Photoshop (or any other Windows application) without also improving compatibility with at least some other Windows applications. That's because the only kind of patches that are accepted in the Wine repository are those that make its behavior closer to that of the Windows API, and that's good for all applications.
Unfortunately, trying to coerce Photoshop into running well on Linux is not exactly the right path to go down. [...] Linux needs more NATIVE software if it is to be stronger in the long run.
You cannot have more native applications if you don't have more users. But you cannot have more users if you don't have the applications they want. It's a vicious cycle. Wine has the potential to break that cycle by making 99% of the world's existing applications Linux-compatible. Improve one piece of software, get a hundred thousand applications Linux-compatible.
Then Windows and Native applications, commercial and open-source, can duke it out on a level playing field. Well... almost level, the native open-source Linux applications will be free (as in beer) and are likely to come pre-installed (e.g. Firefox, Open Office, etc). Does that remind you of something?
All the work we did for Google was committed straight to the Wine repository.
But that's just business as usual for us: we already submit 99% of the changes we make to Wine. The remaining 1% are those hacks that are rejected as too ugly by Alexandre (the Wine leader) but which we keep as a temporary fix / workaround.
See, the thing is that improving Wine is so central to our business that it's just part of our mission statement:
Mission
To transform Mac OS X and Linux into Windows®-compatible operating systems.
To help our customers leverage Windows technology on non-Windows operating systems. To promote the growth of Free Software by supporting and extending the Wine Project.
While I agree that we are spending too much money in iraq, but the defense budget is not necessarily a bad thing. Throughout history the most prosperous nations have usually been the ones with the most powerful military. Make sure you have your cause and effects in order before spending hundreds of billions on defense. Other nations who had first order military: URSS during the cold war, Irak, fourth military power in 1990 according to the US. So these must be, or have been, very prosperous countries.
Your conclusion, that solar and wind power is unsuitable for either base or variable load generation, seems to imply they are essentially useless. But that's wrong because your analysis is static, not dynamic.
So let's say the base load is 1000MW (not a real figure of course), and the max load is 2000MW. So you build 1000MW worth of nuclear plants for the base load, and 1000MW worth of gas power plants for the variable load. And then you would build 600MW worth of 'extra' wind and solar power.
So let's say at a given time the power load is 1500MW and the wind and solar plants produce 400MW. Then it means your variable load power plants have to provide the missing 100MW by idling away at 10% of their maximum power, thus putting out little CO2. For as long as the conditions don't change you're saving close to 80% on the CO2 emissions (because the gas-turbine runs at 10% instead of 50%, minus inefficiencies).
Then if the wind falls and there's a solar eclipse at the same time so wind and solar power fall to 0MW, no problem, you ramp up the variable load power plants to 50% of their capacity to handle the extra load. That's exactly what they are here for. But until these freak conditions occur you're saving a lot on CO2 emissions, and that's the whole point. And it works even without energy storage.
If the ATM had a firmware upgrade that reported a hash of your bank account number with the vote, that would be sufficient to verify uniqueness and avoid double voting. Right. One bank account, One vote. That's one of the main tenets of democracy. Maybe we should push it a bit further:
One dollar, One vote!
2: EFF and the rest of the American White hats get together and develop an Open Voting system, that are freely implementable by any state, that can withstand public scrutiny and peer review. Does not work: on election day you have no way to make sure that the machine you vote on is running the EFF's public, reviewed and trusted software rather than a hacked version.
According to our forefathers, the right to vote is worth your life.
Logically, you're not capable of voting if you're dead - your statement is patriotic but makes no sense. You're reading this too literally. What this really means is that your right to vote is worth risking your life to defend it, and by extension to defend the right of others to vote too.
I would have much more confidence in a cryptographic scheme that makes it effectively impossible for a voting machine to cheat. This is not all that difficult to accomplish and the necessary design criteria are widely available in the literature. A paper trail doesn't really help.
If you do away completely with any tangible ballot, like a paper ballot, please tell me how the voter is to determine by himself that what is displayed on the screen corresponds to the real vote, which is a tiny electric charge deep down in the machine. Until you've solved that issue, all the rest is moot.
1) You go to vote. You are shown a voter ID number on the screen. You are welcome to write it down if you wish.
2) You select your candidate of choice. If you wish, you are given a paper receipt providing cryptographic proof that the voter ID you were shown in step 1 voted for the candidate you chose.
Wow, you are able to compute cryptographic hashes like sha1 in your head? If not, how are you going to complain immediately in step 3?
'Voter id' is also a pretty bad choice of words. I will just assume you meant 'ballot id' as anything that would tie a voter to a ballot would be real bad.
3) If anything goes wrong in steps 1 or 2, complain loudly and immediately.
Right. And doing so you will have to reveal to everyone whom you intended to vote for: 'See I selected candidate X but the cryptographic hash ad56e5dcb46f88d95df5ac6d459493dd clearly means candidate Y'.
This is equivalent to you not being allowed to enter the voting area
No, with a 100% paper based election you never have to reveal whom you intend to vote for. It's only when you have an electronic machine that you have to show what you did, and thus reveal who you intended to vote for, to prove they're not working right.
4) If you wish, you may opt to receive copies of paper receipts of other votes for other candidates too. (So that someone can't demand to see your receipt to prove you voted for a particular candidate, since you can get a receipt of someone else who voted for any candidate.)
5) When the results are publicized, the total number of votes is checked against the total number of voters. Any voter with a paper receipt not on the final tally knows their vote wasn't counted. (Though they can't prove it was their vote, of course, they can prove that *a* valid vote wasn't counted.)
So I can vote for candidate X, ask for a receipt for candidate Y, and then get the election cancelled because clearly my vote for candidate Y has not been counted? Or can one identify my candidate Y receipt as 'fake' and thus deny my request? And if so, then what is going to prevent my boss from identifying that candidate Y receipt as a fake?
6) The receipts can be scannable with barcode
Again, good for you if you can read barcodes but I (and >99% of the population) can't. So I would have no way to know if the barcode says 'Candidate X' or 'Candidate Y', so if the barcode is the authoritative piece of information the receipt means nothing to me. And if the barcode is not authoritative then there's no point for it being there in the first place.
I think it's time for you to go back to the drawing board (or stop oversimplifying something so much that it's full of holes, although you also claim it's not very hard to start with).
(I think you mean spelling checker, not spell checker. Unless you are Harry Potter or one of his friends, you don't need a spell checker). Hehe. Good point. Lame excuse: Slashdot's title made me do it!
For example, there is no dictionary in the world containing all German words. It is not possible, because words can be constructed from other words. For example, what you wrote would be a Wörterbuchrechtschreibeprüfungsunbrauchbarkeitshyp othese and is both false and not present in any dictionary.
A spelling checker checks whether a word is written correctly or incorrectly. The rest is implementation detail.
Still, all those that exist are based on a list of allowed words, together with algorithms for generating valid prefixes and suffixes to reduce the size of that list. But that is an implementation detail. And yes, for some languages taking into account composed words is one of those necessary optimizations.
But composed words are easy. The hard thing is abbreviations because they should not be flagged as errors... unless you want to make your programmers crazy. How will a spelling checker know that 'ofs' (old file size), ptb (a pointer to data in the Teb), pfdesc (poll file descriptor), uaddrlen (length of the Unix structure containing an ip v4 address) are all valid, but pfildesc or uadrlen is not? Making this determination requires understanding the meaning of the abbreviations which is not something computers are capable of doing (yet anyway).
So you'll be forced to use heuristics which will either have tons of false positives and be rejected by programmers, or which will have tons of false negatives, at which point I would not consider it a true spelling checker anymore.
I'm not sure spell-checking can really be made to work because, by definition spell-checkers flag anything that is not in the allowed list (also called dictionary) as an error. But source code always contains tons of identifiers that are not real words, like pid, ret, req, riid, etc. The problem is that there are hundreds if not thousands of them in a large project and that you get a ton of new ones making the maintenance of a custom directory a pain.
But I've been annoyed by spelling errors too and what I noticed is that the same errors come over and over again. So what I did is write a script that specifically checks for common typos. And I've very imaginatively called it 'typos'.
What's great with this approach is that, no matter whether you're writing a C, Perl, PHP or HTML file, 'seperate' is never going to be a real word. So we can identify these with no cumbersome custom dictionary, and a very very low false positive rate.
Typos is open-source (GPL) and has no dependency that I know of (besides perl). So you can try it out just by downloading it, making the script executable, and running it with no argument on your source:
It's basically the perfect hibernate cache that doesn't require power to maintain it's state, and will give near instant uptimes. Oh, so now Windows users are complaining that Windows uptimes are too long. They would rather have their computer crash instantly as it comes up. Weird. I will really never understand Windows users. Better stick to my 3months+ Linux uptimes.
;-)
even with paper ballots, boxes of them can get lost, they can be scanned improperly, etc.
As I understand it, in the US the ballots are moved to a central location before being counted. This alone ensures that no one can guarantee the integrity of the elections: who knows what happens in the van while the ballot boxes are out of view...
But this cannot happen in France. That's because the ballots are counted on the spot. The ballot boxes and the ballots themselves stay in the same room, in full view of the official staff, party representatives and interested citizens, until all the ballots have been counted.
Once the ballots have been counted and the result sheets signed (in many copies), the ballots are no longer authoritative and are soon discarded (article R68 of the Electoral Code). That's because after the ballots leave that room they become the weakest link in the election integrity.
As for scanning the ballots, four people are involved in counting every single ballot, plus all the party representatives and regular citizens watching over their shoulders. No scanning machines so far.
Slashdot Mirror
So am I the only one worried about this system creating salty rains?
If a cloud created by these ships passes over land and turns into rain, all the salt in the cloud will end up in the soil. We've had trouble with acid rains killing our forests already (which was blamed on cars / industry, iirc) so it does not seem too far fetched...
As for the consequences, most plants, in particular those we use for food, don't like salt. If this is done on a large enough scale to have an effect on the global weather, won't it also have a global effect on our cultures? (Not to mention the wildlife's ecosystems) Or did the scientists study this *non-climate* issue?
Because, ideally, all four cores should be running at 100% -- the idea is to make maximal use of your available resources, right?
Right. If your code is not maxing out the CPU, then start a few extra threads running 'while (1);'. Your resource usage will be much improved!
Remember: 100% CPU usage be the sign that the code is awfully inefficient. And <100% CPU usage may be the sign that your I/O handling is inefficient.
I don't see why, a priori, scheduling onto a single core will be more cache efficient. If my threads are working on separate data (and that's essentially the goal of all parallel compute intensive software)
For the special case of parallel compute intensive software yes it's better to schedule each thread on a separate core and Linux is supposed to do so. But this is a special case and since you did not provide this information before I had to envision all possibilities (and I did cover both cases).
Anyway, as I said before this is not the place to discuss this...
I can see that Wine handles multiple threads within a process (it quite clearly has to), but somehow they don't get scheduled concurrently onto different processors.
If they don't max out one core, then Linux will schedule them all on one core because that will be more efficient (cache sharing). However if each thread could use 100% of the CPU, then they should clearly be spread to multiple cores and, as far as I know, it's what happens normally. If so, then it would be worth investigating why it's not happening in your case. Maybe post on wine-users or the new Wine forum giving details about your application, workload and setup so others can hopefully help you diagnose more precisely what's happening.
Wine was a great idea in its day but now with multi-core CPUs and excellent VMs (VMWare, VirtualBox, etc.) do you still see the need for Wine?
Well, besides the purely practical reasons like: Wine is cheaper than paying for a VM application (some are free) plus a Windows license (never free), provides better performance (or should), is better integrated with your Linux environment, etc.
So besides these purely practical reasons, Wine is very important for the big picture: with Windows being on >90% of the computers, our society depends on Windows. Take away Windows and lots of things stop working (from travel agencies to airports and administration) until you can find a replacement. But there is no replacement because no other system is capable of running Windows applications. Wine is the only Windows replacement (ReactOS uses Wine), it is the only alternative supplier of a system that can run Windows applications. Thus, independently of practical aspects, Wine has a very high strategic importance for our society as a whole.
For more details, see Why Wine is so important.
Wine isn't known to reliably run ANY version of Office with anything that would be called reliability. [...] Would outside contributions that removed these limitations from Wine even be merged?
Yes. The most important criterion for deciding whether a patch gets in Wine or not, is whether it makes Wine behave more like Windows or not.
[...] What would be the point of me (me taken as generic) considering looking at Wine with an eye to contributing unless I am first a Crossover Office customer?
That would not be an issue at all. Most Wine developers work on Wine and are not CodeWeavers customers.
Because the odds are good that any particular missing feature in Wine is already implemented in CX, so one would first want to test there to avoid reinventing a wheel
The chances of you reinventing the wheel are very small to inexistent. Yes I think that CrossOver is better than Wine for regular users, but that's not because it has a set of hidden extra Wine wheels somewhere <g>. By the way don't just trust me. Grab our source code (anyone can get it) and compare it to Wine's.
that probably wouldn't get merged anyway.
As I said, if your code is correct and reasonably well written, then it will get merged.
Is this any plan to make it more native in the look & feel?
There is the start of support for themes but it needs to be extended to more controls (e.g. buttons, scrollbars, etc). Also it would be real cool if it could directly use the current KDE/Gnome theme (maybe by converting to a Windows XP theme on the fly or something like that).
However I guess most people consider this to be lower priority than getting Windows applications working in the first place because nobody is currently actively working on it. But that could change. All it would take is a couple of motivated developers...
Will the WINE project try to implement the Windows Vista APIs or will the project aim only for the Windows XP APIs?
Wine does not target any specific Windows version. It does not matter whether the latest Windows version from Microsoft is 2000, XP or Vista.
All that matters is the Windows applications. So let's say World Of Warcraft is very popular. Then people will fix up Wine to make sure all the APIs it uses, for instance Direct3D 9, have a good enough implementation in Wine (and that's exactly what happened). So it does not matter that Microsoft released Vista because that has no bearing on whether WoW will run in Wine or not.
The day popular applications depend on Vista-only APIs, or are shipped for Win64 only, that is the day the corresponding functionality will appear in Wine.
What plans do you have for better multi-threading support?
Multi-threading works just fine as far as I know. If you are aware of any issues I'd suggest to report them to the wine-devel mailing list.
I just wanted to thank the team, on behalf of everyone in the /. crowd, for making sure Notepad.exe was one of them. It was the first Windows program I tried to use under WINE and it performed flawlessly, making me feel a little more at home on Linux.
I know it's a joke, but it's actually worth explaining. Wine's notepad implementation serves (at least) two purposes:
The same reasons lead to the addition of wordpad two years ago.
CrossOver has a lot of improvements in the areas around Wine. More specifically:
- CrossOver will install our set of supported Windows applications out of the box. We achieve that by configuring Wine just right for each application, knowing which prerequisites each needs, etc. You can do the same thing with plain Wine but you will have to figure out the exact recipe by yourself (or by trying somewhat contradictory advice from the web).
- CrossOver is tested against our list of supported Windows applications so you know they will work now and in the future. In contrast, Wine does not try to support any specific application and is still in beta so regressions are still quite common. An application may work this week and not next week.
- CrossOver has much better integration with the KDE / Gnome environments. For instance you'll find the Windows applications directly in the KDE
/Gnome 'Start Menu'. You can also click on a file or email attachment and have it open in a Windows application, etc.
- CrossOver works on the Mac which is not quite the case of Wine yet. Again this has much to do with the stuff surrounding Wine.
- Finally, we provide support for those cases where things are not working just right.
Is there a benefit to using Cadega?Heh, they're competitors so take this with a grain of salt... Imho, no there's no benefit to using Cedega. CrossOver and Wine can already run games almost as well if not better. The reason is that TransGaming forked Wine years ago and made almost no contribution back (so funding them does not help Wine either). So now they're on a mostly separate, years old, code base and it shows...
There is no way to improve compatibility with Photoshop (or any other Windows application) without also improving compatibility with at least some other Windows applications. That's because the only kind of patches that are accepted in the Wine repository are those that make its behavior closer to that of the Windows API, and that's good for all applications.
You cannot have more native applications if you don't have more users. But you cannot have more users if you don't have the applications they want. It's a vicious cycle. Wine has the potential to break that cycle by making 99% of the world's existing applications Linux-compatible. Improve one piece of software, get a hundred thousand applications Linux-compatible.
Then Windows and Native applications, commercial and open-source, can duke it out on a level playing field. Well... almost level, the native open-source Linux applications will be free (as in beer) and are likely to come pre-installed (e.g. Firefox, Open Office, etc). Does that remind you of something?
Both of course!
All the work we did for Google was committed straight to the Wine repository. But that's just business as usual for us: we already submit 99% of the changes we make to Wine. The remaining 1% are those hacks that are rejected as too ugly by Alexandre (the Wine leader) but which we keep as a temporary fix / workaround.
See, the thing is that improving Wine is so central to our business that it's just part of our mission statement:
MissionTo transform Mac OS X and Linux into Windows®-compatible operating systems.
To help our customers leverage Windows technology on non-Windows operating systems.
To promote the growth of Free Software by supporting and extending the Wine Project.
Your conclusion, that solar and wind power is unsuitable for either base or variable load generation, seems to imply they are essentially useless. But that's wrong because your analysis is static, not dynamic.
So let's say the base load is 1000MW (not a real figure of course), and the max load is 2000MW. So you build 1000MW worth of nuclear plants for the base load, and 1000MW worth of gas power plants for the variable load. And then you would build 600MW worth of 'extra' wind and solar power.
So let's say at a given time the power load is 1500MW and the wind and solar plants produce 400MW. Then it means your variable load power plants have to provide the missing 100MW by idling away at 10% of their maximum power, thus putting out little CO2. For as long as the conditions don't change you're saving close to 80% on the CO2 emissions (because the gas-turbine runs at 10% instead of 50%, minus inefficiencies).
Then if the wind falls and there's a solar eclipse at the same time so wind and solar power fall to 0MW, no problem, you ramp up the variable load power plants to 50% of their capacity to handle the extra load. That's exactly what they are here for. But until these freak conditions occur you're saving a lot on CO2 emissions, and that's the whole point. And it works even without energy storage.
If you do away completely with any tangible ballot, like a paper ballot, please tell me how the voter is to determine by himself that what is displayed on the screen corresponds to the real vote, which is a tiny electric charge deep down in the machine. Until you've solved that issue, all the rest is moot.
1) You go to vote. You are shown a voter ID number on the screen. You are welcome to write it down if you wish.2) You select your candidate of choice. If you wish, you are given a paper receipt providing cryptographic proof that the voter ID you were shown in step 1 voted for the candidate you chose.
Wow, you are able to compute cryptographic hashes like sha1 in your head? If not, how are you going to complain immediately in step 3?
'Voter id' is also a pretty bad choice of words. I will just assume you meant 'ballot id' as anything that would tie a voter to a ballot would be real bad.
3) If anything goes wrong in steps 1 or 2, complain loudly and immediately.Right. And doing so you will have to reveal to everyone whom you intended to vote for: 'See I selected candidate X but the cryptographic hash ad56e5dcb46f88d95df5ac6d459493dd clearly means candidate Y'.
This is equivalent to you not being allowed to enter the voting areaNo, with a 100% paper based election you never have to reveal whom you intend to vote for. It's only when you have an electronic machine that you have to show what you did, and thus reveal who you intended to vote for, to prove they're not working right.
4) If you wish, you may opt to receive copies of paper receipts of other votes for other candidates too. (So that someone can't demand to see your receipt to prove you voted for a particular candidate, since you can get a receipt of someone else who voted for any candidate.)5) When the results are publicized, the total number of votes is checked against the total number of voters. Any voter with a paper receipt not on the final tally knows their vote wasn't counted. (Though they can't prove it was their vote, of course, they can prove that *a* valid vote wasn't counted.)
So I can vote for candidate X, ask for a receipt for candidate Y, and then get the election cancelled because clearly my vote for candidate Y has not been counted? Or can one identify my candidate Y receipt as 'fake' and thus deny my request? And if so, then what is going to prevent my boss from identifying that candidate Y receipt as a fake?
6) The receipts can be scannable with barcodeAgain, good for you if you can read barcodes but I (and >99% of the population) can't. So I would have no way to know if the barcode says 'Candidate X' or 'Candidate Y', so if the barcode is the authoritative piece of information the receipt means nothing to me. And if the barcode is not authoritative then there's no point for it being there in the first place.
I think it's time for you to go back to the drawing board (or stop oversimplifying something so much that it's full of holes, although you also claim it's not very hard to start with).
A spelling checker checks whether a word is written correctly or incorrectly. The rest is implementation detail.
Still, all those that exist are based on a list of allowed words, together with algorithms for generating valid prefixes and suffixes to reduce the size of that list. But that is an implementation detail. And yes, for some languages taking into account composed words is one of those necessary optimizations.
But composed words are easy. The hard thing is abbreviations because they should not be flagged as errors... unless you want to make your programmers crazy. How will a spelling checker know that 'ofs' (old file size), ptb (a pointer to data in the Teb), pfdesc (poll file descriptor), uaddrlen (length of the Unix structure containing an ip v4 address) are all valid, but pfildesc or uadrlen is not? Making this determination requires understanding the meaning of the abbreviations which is not something computers are capable of doing (yet anyway).
So you'll be forced to use heuristics which will either have tons of false positives and be rejected by programmers, or which will have tons of false negatives, at which point I would not consider it a true spelling checker anymore.
I'm not sure spell-checking can really be made to work because, by definition spell-checkers flag anything that is not in the allowed list (also called dictionary) as an error. But source code always contains tons of identifiers that are not real words, like pid, ret, req, riid, etc. The problem is that there are hundreds if not thousands of them in a large project and that you get a ton of new ones making the maintenance of a custom directory a pain.
But I've been annoyed by spelling errors too and what I noticed is that the same errors come over and over again. So what I did is write a script that specifically checks for common typos. And I've very imaginatively called it 'typos'.
What's great with this approach is that, no matter whether you're writing a C, Perl, PHP or HTML file, 'seperate' is never going to be a real word. So we can identify these with no cumbersome custom dictionary, and a very very low false positive rate.
Typos is open-source (GPL) and has no dependency that I know of (besides perl). So you can try it out just by downloading it, making the script executable, and running it with no argument on your source:
It's basically the perfect hibernate cache that doesn't require power to maintain it's state, and will give near instant uptimes. Oh, so now Windows users are complaining that Windows uptimes are too long. They would rather have their computer crash instantly as it comes up. Weird. I will really never understand Windows users. Better stick to my 3months+ Linux uptimes.
;-)
As I understand it, in the US the ballots are moved to a central location before being counted. This alone ensures that no one can guarantee the integrity of the elections: who knows what happens in the van while the ballot boxes are out of view...
But this cannot happen in France. That's because the ballots are counted on the spot. The ballot boxes and the ballots themselves stay in the same room, in full view of the official staff, party representatives and interested citizens, until all the ballots have been counted.
Once the ballots have been counted and the result sheets signed (in many copies), the ballots are no longer authoritative and are soon discarded (article R68 of the Electoral Code). That's because after the ballots leave that room they become the weakest link in the election integrity.
As for scanning the ballots, four people are involved in counting every single ballot, plus all the party representatives and regular citizens watching over their shoulders. No scanning machines so far.