The main problem with X is not "asynchronous" communication, but actually the opposite, "synchronous" communication. Thought the underlying protocol is async, far too many calls "return" some value, which in effect makes it synchronous. Windows has this same problem, perhaps far worse, as there are drawing calls there that return values (both X and Windows attempt to fix this by keeping the return values local in the app but this introduces other problems). OpenGL actually gets it mostly right and that is the main reason drawing with it is much faster than with Xlib.
In the early state of mainframes and terminals (which you described pretty accurately) there was little concern for async, because latency was a tiny issue compared to throughput. Nobody questioned adding a return value to an xlib call even if the majority of users would not need it.
The client/server architecture of X actually helps a huge deal, even on the same machine, because it forces the communication through a single api where (if it was async enough) and thus enables buffering. You are discouinting the overhead of context switches, which on modern machines is *huge*. The X design allows hundreds of thousands of context switches to be replaced with a single one due to buffering. Windows does this too, and so would any plausable X replacement. However every sync call breaks this.
I would agree the calls to Xlib itself, besides all the ones that return values, are a big problem, and this should be addressed by adding a new api with sensible drawing (like Cairo) and window manipulation. It does seem that replacing X is impossible but instead of kludging in methods to work with the existing api, a new and sensible one on the side would be better.
X window managers have had 'maximize vertically only' for years and years now. Usually done by clicking the maximize button with something other than the left mouse button.
What happened to "exit without saving? yes/no". There are only two buttons. To save & exit you say no, then save, then exit. In the real world this usually works because in most cases if you did not save you realize you also did not finish editing either.
Vast amounts of software worked this way before the 3-button ones started appearing. Those 3-button ones certainly caused me a lot of pain because the yes/no were somewhat reversed from previous experience and I lost a lot of data by hitting no. However this also means that switching back to the 2-button version is going to cause a lot of pain for modern users used to the 3-button one.
The "patch" method to evade the GPL restrictions on redistribution seems possible, but nobody really seems to be trying it for anything. I can think of two problems:
1. The source code is still readable, so if the reason is to keep your implementation secret, the patch is useless for that. This probably eliminates the majority of people who want to redistribute something without obeying the exceptions to copyright the GPL allows.
2. The "-" lines in the patch (or whatever the equivalent are in any scheme you come up with) can be considered derived works of the GPL code.
Then a catalyst that happened to be there for some other reason got leaked into the chamber holding the chemical and made it stronger and thus beetles with the leak were more fit to survive.
Further descendents with more of the catalyst then were even more fit to survive.
Eventually it evolved until the catalyst was the same volume as the original chemical. And the chemical since it was not used without the catalyst, had no reason to remain useful by itself and devolved until it was useless without the catalyst.
1) Abiogenesis is not evolution and is irrelevant.
2) There are no examples of irreducable complexity, unless you make the bogus assumption that complexity can only increase. If you allow more complex intermediate forms then all the "proofs" fail.
3) Apparently "species evolution" (and "macro evolution") mean "evolution larger than what has been observed directly". Oh aren't you clever, as by definition this will never have "evidence" since you continously redefine it to exclude anything which there is evidence for.
In your example, say you scribbled all your math down, and then A won and wiped out B. You have falsified your premise with your experiment.
The fact that B wins means you did not succeed in falsifiying it. But it does not mean it is not falsifiable! Maybe there is some other arrangement of math you could do that would violate your premise.
ID cannot be falsified, because ANYTHING that you observe can be said to be "god did it".
There appears to be a concerted effort to confuse "nobody has proved it false" with "not falsifiable" here, in an attempt to say that "evolution is not falsifiable either!" Of course these people have such tiny brains that they fail to realize that they are also saying "gravity is not falsifiable" or "the sky is blue is not falsifiable!".
That whales evolved from hippos is TRIVIAL to falsify. All you have to do is show that the DNA in whales does not seem to have descended from a common ancestor of hippos, perhaps by having far too many differences.
You seem to be thinking that "nobody has shown it to be false" is the same as "not falsifiable". You do not have a clue what you are talking about, do you.
I think the point is that when a user gets the box that does NAT, they get a firewall for free. If NAT did not force them to buy the box they would probably not be running a firewall, or running one on the same machine they are running their software and thus much more vulnerable.
Just to be accurate: it is a method of storing a long filename into a disk format that could only store 8.3 filenames.
Now the obvious solution is to add a file called 'filenames' and put the stuff there, and if there was a way to "hide" the file from old software (there was) then use that so it does not appear in the lists.
The "innovation" (and you can argue true/false over whether it is or not) was to use a whole lot of directory entries to store the filenames instead. It just happens that there was a different way in the 8.3 disk format to make a directory entry "hidden" (a flag that indicated that the directory entry was the name of the disk itself) and the vast majority of existing software apparently ignored a whole lot of these files (they are lucky the software did not crash if there was more than one, however...).
The advantage of this scheme is that if you deleted all the files with an "old" piece of software, that software would really think the directory was empty. If there was a real hidden file the software would probably not think the directory was empty and would refuse to delete it. I'm sure there are some other advantages to this scheme but I am having a hard time figuring them out.
I may not have explained it right. What fsync would do it cause the currently-written file to appear at the name, but it would remain open and writable. Doing creat() immediately followed by fsync() would be like creat() is today.
The reason is that otherwise the fsync() is useless. Nobody else can see the file you are writing, and if the system crashes the file you are writing had better be completely gone when it is brought up (the previous file with that name would still appear). So calling fsync() unless it makes your file appear would serve no purpose.
If you open file A and write some data to it, then close it, it does make sense that if it crashes and you look at the disk, you might see A as being zero length. It was zero length at one time, so this is an expected state to see it in.
However if you then rename A to B, it in effect does the rename before finishing the data. So now B can be a zero-length file.
This is really unexpected, and not good, because most programs doing this actually copied a lot of interesting and useful data from B to A, changing just a little bit (imagine a configuration file where one flag is switched, or a text editor saving the new version). All previous Unix systems when they crashed (if you ignore ones where the disk was left uselessly trashed) would have B either be it's old version or with the full data that was written to A, and programs relied on this. It is a very very useful to rely on this.
People saying "fsync!" do not understand the problem, and their solution will make performance dreadful, as bad as EXT2 or worse. The desire is to have *either* the old or new data. If the old data is still on the disk, well then a configuration or some editing was lost, which seems quite understandable considering your machine just crashed. But not the whole file including data that was correctly on the disk for possibly a year before the crash!
As about 6000 people have tried to point out to all you clueless "fsync!" posters, fsync() will kill performance unacceptably. It forces far more to happen then the programmer wants. We only want the order preserved, it is ok if the data write is delayed for a long time.
The fact that "POSIX allows this" is completely bogus. POSIX allows the file to be deleted when you read() it, as long as it is written back when the disk is unmounted. That does not mean that programs should all call unmount all the time just because such stupid behavior is possible!
Yes I would like that as well. It would remove the annoying need to figure out a temp filename and to do the rename.
One suggestion was to add a new flag to open. I think it might also work to change O_CREAT|O_TRUNC|O_WRONLY to work this way, as I believe this behavior is exactly what any program using that is assuming.
f = creat(filename) would result in an open file that is completely hidden to any process. Anybody else attempting to open filename will either get the old file or no file. This should be easy to implement as the result should be similar to unlinking an already-opened file.
close(f) would then atomically rename the hidden file to filename. Anything that already has filename open would keep seeing the old file, anything that opens it afterwards will see the new file.
If the program crashes without closing the file then the hidden file goes away with no side effects. It might also be useful to have a call that does this, so a program could abandon a write. Not sure what call to use for that.
Calling fsync(f) would act like close() and force the rename, so after fsync it is exactly like current creat().
It probably should flush data on a rename even if the target of renaming does not exist. This way after a crash the target file if it exists always contains the expected data. I'm pretty certain that if it exists but is zero length, some programs are going to screw up.
You misunderstand the problem. The behavior of EXT3 is POSIX compliant.
If Microsoft broke back-compatibility and it made no difference to how POSIX compliant they were, they would not be anybody defending them here!
The other annoying thing to me is people acting like POSIX is some sort of flawless commandments from god. It has mistakes and oversights, and saying "it conforms to the spec" is a total whitewashing of this situation. Microsoft could claim their changes obey all the MSDN documentation and that is equally bogus.
No you are misunderstanding the problem. It has nothing to do with the time, it has to do with the order things are happening.
Writing data to a and then doing rename(a,b), and a VAST amount of software assumes that after a crash, b will either have it's old contents, or have what was written to a before the rename. This is perfectly logical, was true on virtually every Unix filesystem, and is also a useful operation that has no equivalent in POSIX (fsync does not count because it forces far more to happen than the programmer wanted).
It is perfectly ok if both the data and rename are delayed until next week. All that is needed is that atomically the file b is either the old or new version. It can be the old one for a long time.
ARRGH! This has nothing to do with the data being written "soon".
The problem with EXT4 is that people expect the data to be written before the rename!
Fsync() is not the solution. We don't want it written now. It is ok if the data and rename are delayed until next week, as long as the rename happens after the data is in the file!
Arrgh it is annoying to keep having to fix people here.
KDE is already fixed exactly as you suggest. It writes a temp file and then renames it over the original. The problem with EXT4 is that this produces a totally unexpected result if it crashes (ie the result is that the destination is neither the old or new file, but garbage).
The people saying "fsync!" do need the cluebat. They are saying this should be done even if the rename is done exactly like you suggest. That is really slow, just like you say.
I do agree KDE should be fixed to not attempt to write any of it's files except when they really change. Rewriting all of them on startup is stupid!
You are wrong when you say EXT3 has this problem. It does not have it. If the EXT3 system crashes during those 5 seconds, you either get the old file or the new one. For EXT4, if it crashes, you can get a zero-length file, with both the old and new data lost.
The long delay is irrelevant and is confusing people about this bug. In fact the long delay is very nice in EXT4 as it means it is much more efficient and will use less power. I don't really mind if a crash during this time means I lose the new version of a file. But PLEASE don't lose the old one as well!!! That is inexcusable, and I don't care if the delay is.1 second.
...some Firefox fan has told me it's superior because it has addins and IE doesn't. I hate FUD, no matter who's spreading it
This has annoyed me no end but it is probably hopeless to ever fix, just like "hacker".
"FUD" is supposed to mean "fear, uncertainty, and doubt". For some reason it has ended up meaning "lie", which is the wrong use.
Saying "IE does not support plugins" might be a lie, but is not FUD. Saying "Microsoft plans to stop supporting plugins" is an example of FUD. It has nothing to do with whether it is true or false, but with it being some future, negative, unknown.
Slashdot Mirror
Actually you are mistaken on some points.
The main problem with X is not "asynchronous" communication, but actually the opposite, "synchronous" communication. Thought the underlying protocol is async, far too many calls "return" some value, which in effect makes it synchronous. Windows has this same problem, perhaps far worse, as there are drawing calls there that return values (both X and Windows attempt to fix this by keeping the return values local in the app but this introduces other problems). OpenGL actually gets it mostly right and that is the main reason drawing with it is much faster than with Xlib.
In the early state of mainframes and terminals (which you described pretty accurately) there was little concern for async, because latency was a tiny issue compared to throughput. Nobody questioned adding a return value to an xlib call even if the majority of users would not need it.
The client/server architecture of X actually helps a huge deal, even on the same machine, because it forces the communication through a single api where (if it was async enough) and thus enables buffering. You are discouinting the overhead of context switches, which on modern machines is *huge*. The X design allows hundreds of thousands of context switches to be replaced with a single one due to buffering. Windows does this too, and so would any plausable X replacement. However every sync call breaks this.
I would agree the calls to Xlib itself, besides all the ones that return values, are a big problem, and this should be addressed by adding a new api with sensible drawing (like Cairo) and window manipulation. It does seem that replacing X is impossible but instead of kludging in methods to work with the existing api, a new and sensible one on the side would be better.
X window managers have had 'maximize vertically only' for years and years now. Usually done by clicking the maximize button with something other than the left mouse button.
What happened to "exit without saving? yes/no". There are only two buttons. To save & exit you say no, then save, then exit. In the real world this usually works because in most cases if you did not save you realize you also did not finish editing either.
Vast amounts of software worked this way before the 3-button ones started appearing. Those 3-button ones certainly caused me a lot of pain because the yes/no were somewhat reversed from previous experience and I lost a lot of data by hitting no. However this also means that switching back to the 2-button version is going to cause a lot of pain for modern users used to the 3-button one.
The "patch" method to evade the GPL restrictions on redistribution seems possible, but nobody really seems to be trying it for anything. I can think of two problems:
1. The source code is still readable, so if the reason is to keep your implementation secret, the patch is useless for that. This probably eliminates the majority of people who want to redistribute something without obeying the exceptions to copyright the GPL allows.
2. The "-" lines in the patch (or whatever the equivalent are in any scheme you come up with) can be considered derived works of the GPL code.
This is trivial:
The beetle sprayed a single chemical first.
Then a catalyst that happened to be there for some other reason got leaked into the chamber holding the chemical and made it stronger and thus beetles with the leak were more fit to survive.
Further descendents with more of the catalyst then were even more fit to survive.
Eventually it evolved until the catalyst was the same volume as the original chemical. And the chemical since it was not used without the catalyst, had no reason to remain useful by itself and devolved until it was useless without the catalyst.
Because the current theory of gravity can be shown to be false at very small scales. Therefore there are holes to poke.
So far nothing has shown evolution to be false in any situation.
1) Abiogenesis is not evolution and is irrelevant.
2) There are no examples of irreducable complexity, unless you make the bogus assumption that complexity can only increase. If you allow more complex intermediate forms then all the "proofs" fail.
3) Apparently "species evolution" (and "macro evolution") mean "evolution larger than what has been observed directly". Oh aren't you clever, as by definition this will never have "evidence" since you continously redefine it to exclude anything which there is evidence for.
You don't seem to understand "falsifiability".
In your example, say you scribbled all your math down, and then A won and wiped out B. You have falsified your premise with your experiment.
The fact that B wins means you did not succeed in falsifiying it. But it does not mean it is not falsifiable! Maybe there is some other arrangement of math you could do that would violate your premise.
ID cannot be falsified, because ANYTHING that you observe can be said to be "god did it".
There appears to be a concerted effort to confuse "nobody has proved it false" with "not falsifiable" here, in an attempt to say that "evolution is not falsifiable either!" Of course these people have such tiny brains that they fail to realize that they are also saying "gravity is not falsifiable" or "the sky is blue is not falsifiable!".
That whales evolved from hippos is TRIVIAL to falsify. All you have to do is show that the DNA in whales does not seem to have descended from a common ancestor of hippos, perhaps by having far too many differences.
You seem to be thinking that "nobody has shown it to be false" is the same as "not falsifiable". You do not have a clue what you are talking about, do you.
I think the point is that when a user gets the box that does NAT, they get a firewall for free. If NAT did not force them to buy the box they would probably not be running a firewall, or running one on the same machine they are running their software and thus much more vulnerable.
Just to be accurate: it is a method of storing a long filename into a disk format that could only store 8.3 filenames.
Now the obvious solution is to add a file called 'filenames' and put the stuff there, and if there was a way to "hide" the file from old software (there was) then use that so it does not appear in the lists.
The "innovation" (and you can argue true/false over whether it is or not) was to use a whole lot of directory entries to store the filenames instead. It just happens that there was a different way in the 8.3 disk format to make a directory entry "hidden" (a flag that indicated that the directory entry was the name of the disk itself) and the vast majority of existing software apparently ignored a whole lot of these files (they are lucky the software did not crash if there was more than one, however...).
The advantage of this scheme is that if you deleted all the files with an "old" piece of software, that software would really think the directory was empty. If there was a real hidden file the software would probably not think the directory was empty and would refuse to delete it. I'm sure there are some other advantages to this scheme but I am having a hard time figuring them out.
He's blaming it on "a bill with no obvious save-the-children type support introduced by the minority party".
If this was introduced by a Republican in New York, it would have the same problem!
I may not have explained it right. What fsync would do it cause the currently-written file to appear at the name, but it would remain open and writable. Doing creat() immediately followed by fsync() would be like creat() is today.
The reason is that otherwise the fsync() is useless. Nobody else can see the file you are writing, and if the system crashes the file you are writing had better be completely gone when it is brought up (the previous file with that name would still appear). So calling fsync() unless it makes your file appear would serve no purpose.
If you open file A and write some data to it, then close it, it does make sense that if it crashes and you look at the disk, you might see A as being zero length. It was zero length at one time, so this is an expected state to see it in.
However if you then rename A to B, it in effect does the rename before finishing the data. So now B can be a zero-length file.
This is really unexpected, and not good, because most programs doing this actually copied a lot of interesting and useful data from B to A, changing just a little bit (imagine a configuration file where one flag is switched, or a text editor saving the new version). All previous Unix systems when they crashed (if you ignore ones where the disk was left uselessly trashed) would have B either be it's old version or with the full data that was written to A, and programs relied on this. It is a very very useful to rely on this.
People saying "fsync!" do not understand the problem, and their solution will make performance dreadful, as bad as EXT2 or worse. The desire is to have *either* the old or new data. If the old data is still on the disk, well then a configuration or some editing was lost, which seems quite understandable considering your machine just crashed. But not the whole file including data that was correctly on the disk for possibly a year before the crash!
As about 6000 people have tried to point out to all you clueless "fsync!" posters, fsync() will kill performance unacceptably. It forces far more to happen then the programmer wants. We only want the order preserved, it is ok if the data write is delayed for a long time.
The fact that "POSIX allows this" is completely bogus. POSIX allows the file to be deleted when you read() it, as long as it is written back when the disk is unmounted. That does not mean that programs should all call unmount all the time just because such stupid behavior is possible!
Yes I would like that as well. It would remove the annoying need to figure out a temp filename and to do the rename.
One suggestion was to add a new flag to open. I think it might also work to change O_CREAT|O_TRUNC|O_WRONLY to work this way, as I believe this behavior is exactly what any program using that is assuming.
f = creat(filename) would result in an open file that is completely hidden to any process. Anybody else attempting to open filename will either get the old file or no file. This should be easy to implement as the result should be similar to unlinking an already-opened file.
close(f) would then atomically rename the hidden file to filename. Anything that already has filename open would keep seeing the old file, anything that opens it afterwards will see the new file.
If the program crashes without closing the file then the hidden file goes away with no side effects. It might also be useful to have a call that does this, so a program could abandon a write. Not sure what call to use for that.
Calling fsync(f) would act like close() and force the rename, so after fsync it is exactly like current creat().
It probably should flush data on a rename even if the target of renaming does not exist. This way after a crash the target file if it exists always contains the expected data. I'm pretty certain that if it exists but is zero length, some programs are going to screw up.
You misunderstand the problem. The behavior of EXT3 is POSIX compliant.
If Microsoft broke back-compatibility and it made no difference to how POSIX compliant they were, they would not be anybody defending them here!
The other annoying thing to me is people acting like POSIX is some sort of flawless commandments from god. It has mistakes and oversights, and saying "it conforms to the spec" is a total whitewashing of this situation. Microsoft could claim their changes obey all the MSDN documentation and that is equally bogus.
No you are misunderstanding the problem. It has nothing to do with the time, it has to do with the order things are happening.
Writing data to a and then doing rename(a,b), and a VAST amount of software assumes that after a crash, b will either have it's old contents, or have what was written to a before the rename. This is perfectly logical, was true on virtually every Unix filesystem, and is also a useful operation that has no equivalent in POSIX (fsync does not count because it forces far more to happen than the programmer wanted).
It is perfectly ok if both the data and rename are delayed until next week. All that is needed is that atomically the file b is either the old or new version. It can be the old one for a long time.
And now EXT4 performs WORSE than EXT3. You have sucessfully removed all the advantages of it!
ARRGH! This has nothing to do with the data being written "soon".
The problem with EXT4 is that people expect the data to be written before the rename!
Fsync() is not the solution. We don't want it written now. It is ok if the data and rename are delayed until next week, as long as the rename happens after the data is in the file!
Arrgh it is annoying to keep having to fix people here.
KDE is already fixed exactly as you suggest. It writes a temp file and then renames it over the original. The problem with EXT4 is that this produces a totally unexpected result if it crashes (ie the result is that the destination is neither the old or new file, but garbage).
The people saying "fsync!" do need the cluebat. They are saying this should be done even if the rename is done exactly like you suggest. That is really slow, just like you say.
I do agree KDE should be fixed to not attempt to write any of it's files except when they really change. Rewriting all of them on startup is stupid!
You don't understand the problem.
You are wrong when you say EXT3 has this problem. It does not have it. If the EXT3 system crashes during those 5 seconds, you either get the old file or the new one. For EXT4, if it crashes, you can get a zero-length file, with both the old and new data lost.
The long delay is irrelevant and is confusing people about this bug. In fact the long delay is very nice in EXT4 as it means it is much more efficient and will use less power. I don't really mind if a crash during this time means I lose the new version of a file. But PLEASE don't lose the old one as well!!! That is inexcusable, and I don't care if the delay is .1 second.
Is writing a new file, and then renaming it over an existing file really a 'typical workload'???
YES!!!!!!
...some Firefox fan has told me it's superior because it has addins and IE doesn't. I hate FUD, no matter who's spreading it
This has annoyed me no end but it is probably hopeless to ever fix, just like "hacker".
"FUD" is supposed to mean "fear, uncertainty, and doubt". For some reason it has ended up meaning "lie", which is the wrong use.
Saying "IE does not support plugins" might be a lie, but is not FUD. Saying "Microsoft plans to stop supporting plugins" is an example of FUD. It has nothing to do with whether it is true or false, but with it being some future, negative, unknown.