The LGPL has some weird extra conditions about allowing the end user to "relink the software with a new version of the library". The only practical way to do this is to make the library a shared library. Maybe that is fine for libc (which seems to be what RMS was thinking about when the LGPL was created). But it is lousy for me and anybody else trying to create an OSS library with the express purpose of trying to popularize a new standard for an api or implementation, as it discourages any programs from using the library because it will mean "DLL hell" for users of the software. It also means there should be binary compatabilty between revisions, which is not something I want to waste time on when I know damn well I will make mistakes in the design that I will want to be able to fix.
The desired "exception" (which basically removes this relinking requirement by saying you can use the library in any way you want as long as you don't modify the library itself), if added to the LGPL, results in exactly the same thing as the GPL plus the exception. This is because the exception completely eclipses all differences between the LGPL and GPL. Originally people added it to the LGPL because the LGPL was a bit closer to what they wanted. However since the GPL3 discussion and the indication that LGPL3 would be an "exception" to GPL3, there seems to be a lot more interest in just putting the exception on the GPL.
Yet when asked why Apple does not open-source their code (or otherwise allow others to make machines using it), the response is "Apple makes money on hardware, not software!"
Brilliant! Apparently you can use that reasoning to argue for anything
No it has no effect on them, even if they use the newer GPL Java. This is due to the "GNU Classpath exception" which pretty much means applications are free to do anything they want.
Um, no, the GPL does not magically remove the rights people already have. Ballmer/Gates/etc want you to believe this, but it is a lie.
Apple already has a license to Java and can continue working with it the way they are doing so. Now Sun could stop releasing any version other than the GPL one, in which case Apple is stuck with the current one unless they want to start using the GPL one. But that is not any worse of a position than they are in right now.
it does raise the question of why the FSF is muddying the waters by having two licences that do the same thing.
The "Classpath exception" is not from the FSF, so they are not responsible for the confusion.
The only trouble the FSF is causing is that the LGPL does not really do what many people want or expect, so many people have come up with alternative licenses which are all LGPL/GPL with an "exception".
In my own library software, I pretty much license it as "the library code and modifcations you make to the library *itself* must be released when you distribute it, however you are free to do anything you want with code you write that links with the library, including statically-linking it and releasing the binary only". I assumme this is the main purpose of the "Classpath exception", and also for dozens of other exceptions.
It would be nice if the FSF or somebody came up with an official version of such a license with a short and clever name so we could all use that and it would be clear and easy to say we are using it.
Yes, indeed, the fact that nothing can be disproved may actually be a worse problem. All close results are in doubt, even if nobody tried to do anything. This may be more damaging to effective government than actual fraud would be, as everybody can claim anybody they don't like may have "stolen" the election.
Um, because some Democrats tried to fix the elections?
Or because some Republicans tried to fix it, but didn't do a good enough job?
Or because both sides tried to fix it and the Democrats were a bit more successful?
The paperless electronic machines have to go, because all the above scenariors are possible, and NONE of them can be disproved in areas that used those machines.
Wait a second. You are claiming that people mad about the Republicans not outlawing abortion and gay marraige retaliated by voting for Democrats? That's ridiculous.
I don't think any of those make it look like a disk to Windows. Yes you can make a program that will show the contents and copy the files to your Windows disk, but not a program that makes Microsoft Word directly open and read/write a word document stored on the Linux fs.
Huh? If the Advertising department loses money (because they pay for ads) does that mean they are a failure?
The original poster claims SCO was a success in that it did exactly what Microsoft intended. Maybe not as well as intended but it certainly worked for many people I know.
In fact the "shim" is Linux itself. You can run proprietary applications on Linux just fine. You might say it's because of the LGPL libc, but it is legal to write a closed-source executable that uses no libraries and just uses system calls.
Dvorak is being an itiot or a shill. He has once again perpetuated the myth that the GPL is some sort of "virus" that "infects" code and makes it all GPL. That is nonsense. Nothing has happened to your code. If you remove the GPL portions, you can do anything you want with the part you write.
In Los Angeles they are using the Inkavote system, which seems to be a slight modification of the punch-card system that seems pretty good to me. There is a pen chained to the voting device that makes a really circular and very black dot that is quite obvious, and you do have to push it down to make a dot, as the inkhead is a plunger inside the metal tube of the pen, and just touching it to a surface does not seem to leave a circle or other mark. I really cannot see how it can be unclear whether you voted or not.
This year they also added an optical reader to the ballot box input slot. According to the pollworker it just checks for and rejects overvoted ballots. The voter puts the ballot in, not a pollworker. However it may also be counting the vote, in which case I sure hope they are going to also count all the ballots by hand. In any case it seems to be a good addition.
One problem I saw was a slight misalignment of the arrows printed in the books and the holes in the machine, so that you might get confused and vote one lower hole than wanted. I hope the machine rejects ballots where dots are filled in that don't correspond to anything. A useful fix I think would be a "fill in this dot" entry to make sure the user has the ballot aligned correctly, the machine should reject ballots without that dot filled in. And put one blank dot between each yes/no question.
Another problem is that the card was 2/3 filled, mostly due to the ballot measures requiring a lot of text next to the yes/no things, so there were many unused dots. They should change the rules so that only the number and title need to be in the book, put the other text on a piece of paper on the wall of the booth.
You are certainly right about the margin of error problem. The 2000 thing in Florida really was well inside the margin of error. They could have kept recounting several times and gotten a different result each time. In many ways it was lucky the first two recounts came out the same (for Bush) so they quit doing this. If they were different they would have done another recount, and another, and it would get worse, since it really was pretty much random who won the recount, and as more and more of them were done it would get closer to 50% of the recounts for each of them.
I'm not sure I agree with the news problem. I don't think the news media will control the election, I can't see any scenario where the outcome of the election would be overridden by an incorrect news prediction. However the demand to know the *official* results quickly is a problem.
Uh, no you havn't. What you are describing is encryption. Encryption *may* be used by DRM, but is not necessary.
"DRM" means that somehow (magic) a person is able to observe the data but not copy it.
This is in fact impossible, however you can approach it by trying to prevent high-quality copies by making it difficult to attach a device that can copy the data at a point that the high-quality data is available. A common solution is to use encryption and try to very tightly couple the decryption portion with the conversion to low-quality data and as late in the process as possible. This is however completely different than any type of real encryption, as the hostile party, by definition, has in their possession the entire decryption mechanism and the keys.
That's just stupid. The only excluse for that is to claim that the callee's may only know the Democrat's name, but then a fair thing to do would be to say "I'm calling with informaion about why you may prefer to vote for [republican] instead of [democrat]".
The number you voted for could be a secret if N "nobody" dots were added, coloring them in would have no effect on the vote, and you were required to always color in N dots. Confusing, however...
Most terminal applications take some key combination to do cut & paste. If it were not for Microsoft (and maybe CDE?) deciding that Ctrl should be the menu shortcut key then it is likely cut & paste in terminals would be easy as well. (I never figured out why or how this happened, as all DOS programs used Alt for this, and the Macintosh used a key that was at the same location as Alt, and Unix, if it used anything, used a "Meta" key and certainly not Alt). In any case I don't see how you can remove it and still have it work in a terminal program, sometimes (often) you want to copy to a non-terminal. Also I certainly use it ALL the time and seriously miss it when using OS/X or Windows. I do recommend that everybody merge it with drag & drop, ie selecting anything and then clicking the middle mouse somewhere else should execute *EXACTLY* the same result as though you dragged that selected thing and let go at the point you middle-clicked.
3. The problem with the context paramenter is that most people use toolkits. If the toolkit was written before the graphics api, or for a different graphics api, there is no easy way to create, manage, or pass that context parameter around. It actually becomes impossible if the toolkit does not provide a reliable "I am destroying this" callback that is done before anything needed by the context is destroyed. Also *EVERY* intermediate function or object needs to be modified to pass that extra context parameter. Normal solution is to stuff it in a static variable, which results in the exact same result as a context-less graphics api, but you lose multithreaded safety and lots of efficiency. I think also it is pretty obvious that there is Glut and GLX and Inventor and lots of other OpenGL libraries that are actually usable by software, but no Xlib graphics libraries, and I fully blame the context parameter for this.
3A. Your complaint about the insane Xlib "context" paramenter, which is usually some combination of display, window id, and gc parameters (but woe to you if you actually use an arbitrary combination, they better all match!). I agree that it is incredibly stupid. Windows does reduce it down to 1, although whether a HWND or HINSTANCE or GC is needed is still a mystery. If we can't get rid of "context", we can at least make exactly one type. The display and root window and a "gc" to draw into the root window should all be interchangable.
4. No I am proposing no built-in mutex for the image. If you write over the image memory while it is still being transferred to the graphics card, you may not get what you expect. There should by a sync-up call that waits until all pending transfers are done. What I want to do is send an image I have in *MY* memory to the card without any intermediate objects. All those intermediate objects do is mean that I must create even more intermediate objects to keep track of them and confuse programmers into making extremely complex api's (since it is often very hard to figure out if creating/destroying these intermediate objects is expensive or cheap).
5/6. What I am requesting is that nothing happen to my window until my program knows about it. In particular I need to stop them from raising on clicks, and raise/open/close other windows at the same time. This will allow multiple windows to be used again, we have lived for 20 years of tiled "mdi" windows because of raise-on-click making efficient use of overlapping windows impossible. It would also make it trivial to enforce arbitrary rules about window sizes and positions. The only reason your terminal resizes in character multiples is that somebody in the ICCCM long ago thought this was a good idea and added an interface for *specifically* that.
My personal belief is that getting rid of the window manager and requiring borders to be drawn by the windows is the easiest and most powerful way to go. Currently it requires far *more* code (in my estimate 10 times if you discount code to draw rectangles that the toolkit needs anyway) to talk to a window manager than
No, the "single clipboard" is exactly what screwed up all the cut & paste on X beforehand.
It is best to think of the select + middle mouse click as a more advanced version of drag & drop, where you can rearrange windows and open and close them between when you start to drag and when you drop. Then it makes a lot of sense. However you certainly would not want the last thing you dragged to also replace the contents of the clipboard, right? In reality, X originally had drag & drop only. Macintosh had cut & paste and a lot of people got confused and mangled the X drag & drop to also emulate this cut & paste. It was not until about 10 years ago that this was straightened out and the two seperated (into SELECTION and CLIPBOARD).
Of course *still* nobody gets it, and X drag & drop is a third thing, when it could easily be combined with SELECTION. (think about it: it is quite impossible to drag text without selecting a piece of text first, and it is quite impossible to change the selection while you are dragging, so there is no need to store this in different places).
Most of the rest of your comments I agree with. The X progress has been severely hurt by bad desings and an obsessive fear of incompatability. Some of the problems:
1. Fonts, as you said. It is INEXCUSABLE that they did not change the old font api to draw the antialiased fonts. Microsoft managed to do this, you know. I really don't care if it is incompatable with some software because you cannot xor letters anymore.
2. Kill all support for colormaps, they are obsolete. All displays must advertise a *single* true color visual. Programs that don't work without a colormap are obsolete and must be rewritten.
3. Like you said, a new graphics api. And stop having to create a "context" object! The graphics api should be XDrawInThis(drawable), followed by XDrawACircle(center, radius) (or whatever). The second call DOES NOT TAKE A "context". Comon, get it right. There is a reason why there are hundreds, or thousands, of OpenGL helper libraries, but none for Xlib or Cairo or even DirectX. It has nothing to do with quality of the implementation or power of the library. It has to do with the simple fact that OpenGL does not need a "context" argument.
4. Add a call that will draw an image that is sitting in my memory, without me creating an "image object". I should be able to specify 1,3, or 4 channels of 8 bit data, and a delta between pixels and between lines (allowing a subrange of an image to be drawn). I should NEVER care what the "visual" of the display is. If shared memory is the way to go, then share it for me without any setup or delay, I can assure you that if I write over that memory I really don't care if the new or old data appears on the screen!
5. Window management sucks. I would scrap it all. Programs should be 100% responsible for drawing every bit of their window, including the border. And don't give me any of this bullshit about the user being "confused" because the UI is not "consistent". You know that is a lie, everybody else does too. Users are confused by *BAD* ui, not by "inconsistent". X would drag and resize windows amazingly fast and smoothly if window managers were eliminated. Try any of those media players or other gizmos that override the window manager to avoid borders.
6. Since the above will never fly, because people will cry and wail about all the masses of "confused users", at least fix the window manager api so that any attempt to resize or raise the window is communicated to the program, so the program can decide what to do.
I think you missed the point. The entire database *is* available and *must* be available, so that anybody can check that it adds up to the claimed vote totals, otherwise, like you said originally, there is no real check at all.
However the database is "voter number -> vote". There is no mapping from person to voter number, which at least prevents easy harvesting of the information about how everybody voted. The numbers are allocated and assigned at the moment the voter votes. Any voter that knows their number could check that their number is in the database and that the vote for that number is correct. A second database of assigned voter numbers could be used to make sure the sets of voter numbers are identical so there are not fake votes stuck in there, and any other checks that can be thought of to make sure the size of the database is not inflated.
Such a system would make it incredibly difficult to fix the vote. That is why it is immediately suggested whenever this comes up. The big problem with it is that if a person can prove how they voted then it allows vote buying. That is probably the biggest problem.
You also need access to the entire database to make sure it adds up to the claimed sums and does not have non-existent voters on it. Then it would be very safe.
This does allow vote buying, however, which is a problem.
The system of checking your own vote would work to prevent cheating. The entire database would have to be available, of all the serial numbers and how they voted. Anybody could check that the database added up to the actual vote. Anybody checking their vote would notice if their serial number was not there or had the wrong vote. And the database could not have any unassigned serial numbers (ie more votes in it than there were voters). I would think it would be very hard to fix such an election even if you had the ability to completely rewrite the database, as the risk of detection would be extreme.
The huge problem with this idea is that it allows vote buying.
Being able to show a local directory in a browser window does not require "embedding in the OS". Take a look at Konqueror or, actaully, any other browser, even IE.
Slashdot Mirror
The LGPL has some weird extra conditions about allowing the end user to "relink the software with a new version of the library". The only practical way to do this is to make the library a shared library. Maybe that is fine for libc (which seems to be what RMS was thinking about when the LGPL was created). But it is lousy for me and anybody else trying to create an OSS library with the express purpose of trying to popularize a new standard for an api or implementation, as it discourages any programs from using the library because it will mean "DLL hell" for users of the software. It also means there should be binary compatabilty between revisions, which is not something I want to waste time on when I know damn well I will make mistakes in the design that I will want to be able to fix.
The desired "exception" (which basically removes this relinking requirement by saying you can use the library in any way you want as long as you don't modify the library itself), if added to the LGPL, results in exactly the same thing as the GPL plus the exception. This is because the exception completely eclipses all differences between the LGPL and GPL. Originally people added it to the LGPL because the LGPL was a bit closer to what they wanted. However since the GPL3 discussion and the indication that LGPL3 would be an "exception" to GPL3, there seems to be a lot more interest in just putting the exception on the GPL.
Yet when asked why Apple does not open-source their code (or otherwise allow others to make machines using it), the response is "Apple makes money on hardware, not software!"
Brilliant! Apparently you can use that reasoning to argue for anything
No it has no effect on them, even if they use the newer GPL Java. This is due to the "GNU Classpath exception" which pretty much means applications are free to do anything they want.
Um, no, the GPL does not magically remove the rights people already have. Ballmer/Gates/etc want you to believe this, but it is a lie.
Apple already has a license to Java and can continue working with it the way they are doing so. Now Sun could stop releasing any version other than the GPL one, in which case Apple is stuck with the current one unless they want to start using the GPL one. But that is not any worse of a position than they are in right now.
it does raise the question of why the FSF is muddying the waters by having two licences that do the same thing.
The "Classpath exception" is not from the FSF, so they are not responsible for the confusion.
The only trouble the FSF is causing is that the LGPL does not really do what many people want or expect, so many people have come up with alternative licenses which are all LGPL/GPL with an "exception".
In my own library software, I pretty much license it as "the library code and modifcations you make to the library *itself* must be released when you distribute it, however you are free to do anything you want with code you write that links with the library, including statically-linking it and releasing the binary only". I assumme this is the main purpose of the "Classpath exception", and also for dozens of other exceptions.
It would be nice if the FSF or somebody came up with an official version of such a license with a short and clever name so we could all use that and it would be clear and easy to say we are using it.
Okay, how many GCC's are there?
How many Qt's are there?
How many versions of Perl, or Python, or TCL?
Truth is, your fear does not happen.
Yes, indeed, the fact that nothing can be disproved may actually be a worse problem. All close results are in doubt, even if nobody tried to do anything. This may be more damaging to effective government than actual fraud would be, as everybody can claim anybody they don't like may have "stolen" the election.
Um, because some Democrats tried to fix the elections?
Or because some Republicans tried to fix it, but didn't do a good enough job?
Or because both sides tried to fix it and the Democrats were a bit more successful?
The paperless electronic machines have to go, because all the above scenariors are possible, and NONE of them can be disproved in areas that used those machines.
Wait a second. You are claiming that people mad about the Republicans not outlawing abortion and gay marraige retaliated by voting for Democrats? That's ridiculous.
I don't think any of those make it look like a disk to Windows. Yes you can make a program that will show the contents and copy the files to your Windows disk, but not a program that makes Microsoft Word directly open and read/write a word document stored on the Linux fs.
Huh? If the Advertising department loses money (because they pay for ads) does that mean they are a failure?
The original poster claims SCO was a success in that it did exactly what Microsoft intended. Maybe not as well as intended but it certainly worked for many people I know.
In fact the "shim" is Linux itself. You can run proprietary applications on Linux just fine. You might say it's because of the LGPL libc, but it is legal to write a closed-source executable that uses no libraries and just uses system calls.
Dvorak is being an itiot or a shill. He has once again perpetuated the myth that the GPL is some sort of "virus" that "infects" code and makes it all GPL. That is nonsense. Nothing has happened to your code. If you remove the GPL portions, you can do anything you want with the part you write.
In Los Angeles they are using the Inkavote system, which seems to be a slight modification of the punch-card system that seems pretty good to me. There is a pen chained to the voting device that makes a really circular and very black dot that is quite obvious, and you do have to push it down to make a dot, as the inkhead is a plunger inside the metal tube of the pen, and just touching it to a surface does not seem to leave a circle or other mark. I really cannot see how it can be unclear whether you voted or not.
This year they also added an optical reader to the ballot box input slot. According to the pollworker it just checks for and rejects overvoted ballots. The voter puts the ballot in, not a pollworker. However it may also be counting the vote, in which case I sure hope they are going to also count all the ballots by hand. In any case it seems to be a good addition.
One problem I saw was a slight misalignment of the arrows printed in the books and the holes in the machine, so that you might get confused and vote one lower hole than wanted. I hope the machine rejects ballots where dots are filled in that don't correspond to anything. A useful fix I think would be a "fill in this dot" entry to make sure the user has the ballot aligned correctly, the machine should reject ballots without that dot filled in. And put one blank dot between each yes/no question.
Another problem is that the card was 2/3 filled, mostly due to the ballot measures requiring a lot of text next to the yes/no things, so there were many unused dots. They should change the rules so that only the number and title need to be in the book, put the other text on a piece of paper on the wall of the booth.
Anybody know anything about Inkavote?
You are certainly right about the margin of error problem. The 2000 thing in Florida really was well inside the margin of error. They could have kept recounting several times and gotten a different result each time. In many ways it was lucky the first two recounts came out the same (for Bush) so they quit doing this. If they were different they would have done another recount, and another, and it would get worse, since it really was pretty much random who won the recount, and as more and more of them were done it would get closer to 50% of the recounts for each of them.
I'm not sure I agree with the news problem. I don't think the news media will control the election, I can't see any scenario where the outcome of the election would be overridden by an incorrect news prediction. However the demand to know the *official* results quickly is a problem.
That sort of ballot is actually illegal in California, for exactly the reasons you state.
Uh, no you havn't. What you are describing is encryption. Encryption *may* be used by DRM, but is not necessary.
"DRM" means that somehow (magic) a person is able to observe the data but not copy it.
This is in fact impossible, however you can approach it by trying to prevent high-quality copies by making it difficult to attach a device that can copy the data at a point that the high-quality data is available. A common solution is to use encryption and try to very tightly couple the decryption portion with the conversion to low-quality data and as late in the process as possible. This is however completely different than any type of real encryption, as the hostile party, by definition, has in their possession the entire decryption mechanism and the keys.
Unfortunatly, Democrats and Republicans were both involved in making your "do not call list" and thus both managed to make themselves exempt from it.
That's just stupid. The only excluse for that is to claim that the callee's may only know the Democrat's name, but then a fair thing to do would be to say "I'm calling with informaion about why you may prefer to vote for [republican] instead of [democrat]".
The number you voted for could be a secret if N "nobody" dots were added, coloring them in would have no effect on the vote, and you were required to always color in N dots. Confusing, however...
Most terminal applications take some key combination to do cut & paste. If it were not for Microsoft (and maybe CDE?) deciding that Ctrl should be the menu shortcut key then it is likely cut & paste in terminals would be easy as well. (I never figured out why or how this happened, as all DOS programs used Alt for this, and the Macintosh used a key that was at the same location as Alt, and Unix, if it used anything, used a "Meta" key and certainly not Alt). In any case I don't see how you can remove it and still have it work in a terminal program, sometimes (often) you want to copy to a non-terminal. Also I certainly use it ALL the time and seriously miss it when using OS/X or Windows. I do recommend that everybody merge it with drag & drop, ie selecting anything and then clicking the middle mouse somewhere else should execute *EXACTLY* the same result as though you dragged that selected thing and let go at the point you middle-clicked.
3. The problem with the context paramenter is that most people use toolkits. If the toolkit was written before the graphics api, or for a different graphics api, there is no easy way to create, manage, or pass that context parameter around. It actually becomes impossible if the toolkit does not provide a reliable "I am destroying this" callback that is done before anything needed by the context is destroyed. Also *EVERY* intermediate function or object needs to be modified to pass that extra context parameter. Normal solution is to stuff it in a static variable, which results in the exact same result as a context-less graphics api, but you lose multithreaded safety and lots of efficiency. I think also it is pretty obvious that there is Glut and GLX and Inventor and lots of other OpenGL libraries that are actually usable by software, but no Xlib graphics libraries, and I fully blame the context parameter for this.
3A. Your complaint about the insane Xlib "context" paramenter, which is usually some combination of display, window id, and gc parameters (but woe to you if you actually use an arbitrary combination, they better all match!). I agree that it is incredibly stupid. Windows does reduce it down to 1, although whether a HWND or HINSTANCE or GC is needed is still a mystery. If we can't get rid of "context", we can at least make exactly one type. The display and root window and a "gc" to draw into the root window should all be interchangable.
4. No I am proposing no built-in mutex for the image. If you write over the image memory while it is still being transferred to the graphics card, you may not get what you expect. There should by a sync-up call that waits until all pending transfers are done. What I want to do is send an image I have in *MY* memory to the card without any intermediate objects. All those intermediate objects do is mean that I must create even more intermediate objects to keep track of them and confuse programmers into making extremely complex api's (since it is often very hard to figure out if creating/destroying these intermediate objects is expensive or cheap).
5/6. What I am requesting is that nothing happen to my window until my program knows about it. In particular I need to stop them from raising on clicks, and raise/open/close other windows at the same time. This will allow multiple windows to be used again, we have lived for 20 years of tiled "mdi" windows because of raise-on-click making efficient use of overlapping windows impossible. It would also make it trivial to enforce arbitrary rules about window sizes and positions. The only reason your terminal resizes in character multiples is that somebody in the ICCCM long ago thought this was a good idea and added an interface for *specifically* that.
My personal belief is that getting rid of the window manager and requiring borders to be drawn by the windows is the easiest and most powerful way to go. Currently it requires far *more* code (in my estimate 10 times if you discount code to draw rectangles that the toolkit needs anyway) to talk to a window manager than
No, the "single clipboard" is exactly what screwed up all the cut & paste on X beforehand.
It is best to think of the select + middle mouse click as a more advanced version of drag & drop, where you can rearrange windows and open and close them between when you start to drag and when you drop. Then it makes a lot of sense. However you certainly would not want the last thing you dragged to also replace the contents of the clipboard, right? In reality, X originally had drag & drop only. Macintosh had cut & paste and a lot of people got confused and mangled the X drag & drop to also emulate this cut & paste. It was not until about 10 years ago that this was straightened out and the two seperated (into SELECTION and CLIPBOARD).
Of course *still* nobody gets it, and X drag & drop is a third thing, when it could easily be combined with SELECTION. (think about it: it is quite impossible to drag text without selecting a piece of text first, and it is quite impossible to change the selection while you are dragging, so there is no need to store this in different places).
Most of the rest of your comments I agree with. The X progress has been severely hurt by bad desings and an obsessive fear of incompatability. Some of the problems:
1. Fonts, as you said. It is INEXCUSABLE that they did not change the old font api to draw the antialiased fonts. Microsoft managed to do this, you know. I really don't care if it is incompatable with some software because you cannot xor letters anymore.
2. Kill all support for colormaps, they are obsolete. All displays must advertise a *single* true color visual. Programs that don't work without a colormap are obsolete and must be rewritten.
3. Like you said, a new graphics api. And stop having to create a "context" object! The graphics api should be XDrawInThis(drawable), followed by XDrawACircle(center, radius) (or whatever). The second call DOES NOT TAKE A "context". Comon, get it right. There is a reason why there are hundreds, or thousands, of OpenGL helper libraries, but none for Xlib or Cairo or even DirectX. It has nothing to do with quality of the implementation or power of the library. It has to do with the simple fact that OpenGL does not need a "context" argument.
4. Add a call that will draw an image that is sitting in my memory, without me creating an "image object". I should be able to specify 1,3, or 4 channels of 8 bit data, and a delta between pixels and between lines (allowing a subrange of an image to be drawn). I should NEVER care what the "visual" of the display is. If shared memory is the way to go, then share it for me without any setup or delay, I can assure you that if I write over that memory I really don't care if the new or old data appears on the screen!
5. Window management sucks. I would scrap it all. Programs should be 100% responsible for drawing every bit of their window, including the border. And don't give me any of this bullshit about the user being "confused" because the UI is not "consistent". You know that is a lie, everybody else does too. Users are confused by *BAD* ui, not by "inconsistent". X would drag and resize windows amazingly fast and smoothly if window managers were eliminated. Try any of those media players or other gizmos that override the window manager to avoid borders.
6. Since the above will never fly, because people will cry and wail about all the masses of "confused users", at least fix the window manager api so that any attempt to resize or raise the window is communicated to the program, so the program can decide what to do.
I think you missed the point. The entire database *is* available and *must* be available, so that anybody can check that it adds up to the claimed vote totals, otherwise, like you said originally, there is no real check at all.
However the database is "voter number -> vote". There is no mapping from person to voter number, which at least prevents easy harvesting of the information about how everybody voted. The numbers are allocated and assigned at the moment the voter votes. Any voter that knows their number could check that their number is in the database and that the vote for that number is correct. A second database of assigned voter numbers could be used to make sure the sets of voter numbers are identical so there are not fake votes stuck in there, and any other checks that can be thought of to make sure the size of the database is not inflated.
Such a system would make it incredibly difficult to fix the vote. That is why it is immediately suggested whenever this comes up. The big problem with it is that if a person can prove how they voted then it allows vote buying. That is probably the biggest problem.
You also need access to the entire database to make sure it adds up to the claimed sums and does not have non-existent voters on it. Then it would be very safe.
This does allow vote buying, however, which is a problem.
The system of checking your own vote would work to prevent cheating. The entire database would have to be available, of all the serial numbers and how they voted. Anybody could check that the database added up to the actual vote. Anybody checking their vote would notice if their serial number was not there or had the wrong vote. And the database could not have any unassigned serial numbers (ie more votes in it than there were voters). I would think it would be very hard to fix such an election even if you had the ability to completely rewrite the database, as the risk of detection would be extreme.
The huge problem with this idea is that it allows vote buying.
Being able to show a local directory in a browser window does not require "embedding in the OS". Take a look at Konqueror or, actaully, any other browser, even IE.