In EXT3, if it crased during those 5 seconds, this bug did NOT happen!!!!
In EXT4, the fact that the time is 150 seconds or whatever is irrelevant. Even if shortened to 5 seconds, if the system crashed, the bug DOES happen!
Adding fsync to "fix" this will actually make EXT4 *slower* than EXT3. Fsync is NOT what is needed. What is needed is for rename(A,B) to insure that A's blocks are on disk before the rename happens. Note that the rename can happen 150 seconds later, or year later. It is the order that is important, and the order is what EXT4 breaks.
It is not "important that this data get onto disk now"
What is important is that when I rename(A,B) that "B either has it's old contents or has been replaced by the contents that were in A". This can happen a YEAR in the future, and the important criteria has been met.
And on modern filesystems your criteria is slow to implement, while the second one (because it can happen far in the future) can be batched with others and is fast.
The commit delay was short on ext3 (5 seconds), but a *lot* can happen in 5 seconds, and a lot of data can still be lost in that time period.
I need to keep correcting this misconception:
The bug did NOT happen on EXT3, even if the machine crashed during those 5 seconds. Making EXT4 commit in 5 seconds will not fix it, the time delay has nothing to do with it.
The other mistake you are making is the typical one of thinking what is needed is fsync(). Yes that "fixes" the problem, but only by slowing the whole system down considerably. This is because it enforces a much stronger requirement than is actually necessary to fix the bug.
The fix, as mentioned about a dozen times above, is to have rename(A,B) enforce ordering so that all the blocks of A are committed to disk before the rename is committed to disk. Note that the rename can happen a year later if you want, and the bug will be fixed.
The filesystem *IS* that "centralized database using a standardized API". The filename is the key, the file contents are the value.
The Windows registry, INI files, and the majority of files in/etc that store more than one thing, are simply symptoms of the misdesign of file systems so that many small files are inefficient.
The files don't have to "litter" anything. Put them in damn subdirectory.
This bug (and the Windows registry) indicates that people just don't get it and still don't get it. Even attempts for Unix to make many files keep doing stupid things like making the file contents be XML or have comments. The "value" should be the bytes in the file!
Yea, one of the biggest proponents killed his wife, but it does not mean the idea is wrong. It is correct.
The problem is not the speed of the write, it is the order.
If a system with EXT3 crashed inside those 5 seconds, the result is NOT as bad as this.
In EXT3, a program doing rename(A,B) while the system crashed would result in either B having it's old contents, or the rename having completed and thus having A's contents.
In EXT4 the crash could result in B being a partially-written version of A. Thus the old contents of B are lost, and so are the contents of A.
The reason this is critical is that the usual method of changing one of the fields in file B is equivalent to this:
sed -e s/Foo/Bar/ <B >A
mv A B
After a crash it would be nice if B was exactly the same as before, except maybe it contains "Bar" or maybe it contains "Foo". People are confusing this with some requirement that it always contain "Bar", which is impossible (you can always pick a point at which the system crashes where this won't happen). The problem with EXT4 is it can result in B containing *nothing*, not "Foo" or "Bar"!
The correct solution, as pointed out by about 10 intelligent posters above, is for EXT4 to make rename force the blocks of A to be put on disk before the rename is committed. Note that this could happen a week later!
There are some very intelligent posters above who have pointed out that the desired result is not achievable with EXT4. fsync fixes the symptom but is NOT the solution! fbarrier is also not right. And POSIX was not written by omnipotent oracles and can be ignored when it is obviously wrong. EXT4 is broken and needs to be fixed!
I'm going to try my own explanation:
If a program starts the call rename(A,B) and then the system crashes, and you reboot and you look at B (not A!!!!), you should either see the contents of A and A does not exist, or the contents of B and YOU DO NOT CARE WHAT IS IN A!!!!!
However as EXT4 is implemented currently, you can get another result: B will contain a partially-written version of A (typically an empty file) and A does not exist. This is VERY BAD, as most likely there was interesting information in B that was copied to A but now both are lost.
fsync as suggested will ensure that the contents of A are correct before the rename(). This is a stronger requirement. It is also dreadfully slow because it has to flush the disk.
fbarrier would be similar. Not as strong as fsync, but it does guarantee that the contents of A are correct before the rename() is committed to disk.
As a side effect of A being correct, fsync and fbarrier reduce the possible results in B of the rename on EXT4 to the desired set, so it does fix the symptoms.
However there are problems with this. By far the most important one is that there are probably ten million programs (including ones written in scripting languages) that assume rename() works as stated above and that it is IMPOSSIBLE to add the fsync/fbarrier call to every one of them. And fsync is dreadfully slow as it really forces the disk to be written right then. fbarrier is better but it is enforcing a slightly stricter limit and thus can still be slower for no actual useful gain.
A pile of locking options on files is not what is needed, despite Windows and VMS doing this. The Unix designers got it RIGHT, 30 years ago, with a correct and very small set of file operations that do what is really wanted (though I would add some sort of atomic create where the file does not appear until closed). Modern designers in OSS and at Microsoft should start showing a little humility and stop throwing all their highschool-level ideas into the designs without some research.
NFS does, but it may require the host to support atomic renames.
Atomic rename is a HUGE part of POSIX so breaking it in a commonly used system like NFS would be bad and was certainly supported in original implementations. However I would not be suprised if NFS support on Windows or some filesystems just implements it with a non-atomic rename.
It is a complete mystery why Windows refuses to add an atomic rename, since it is REALLY useful. My suspicion as to why this and a few other quite easy things are never fixed (like newlines) is that ther is a concerted effort to make sure that code cannot be too easily ported between Windows and Unix.
It certainly IS the intention of rename in any program I have ever seen that just wrote the file!
I agree with the GP, a rename should force the file's contents to be up to date before the rename is committed. This is not going to impact the performance of anything that does not rename a file or anything that renames a file that is just sitting flushed on the disk.
I'm quite certain the GPL is violated all the time. People install GPL software on other's computers and don't bother giving them the source code or providing enough information that the source code can be located. They modify the software (generally small tweaks) and install it and don't give the source code, so it is impossible to recover. They post tweaked versions on the internet for anybody to download and don't include the source, or include incorrect and useless source. Plenty of router manufacturers probably put incorrect or outdated source code on their web sites. And the number of manufacturers caught is probably dwarfed by 10:1 by the number who are violating the GPL, some of them knowingly. Technically the GPL is violated millions of times per second in the use of computers, networks, and bittorrent as binaries are copied without including the source code.
The only cases where the GPL has been enforced is when people sold the resulting product for money. I think everybody can agree that a record company can and should go after an individual selling copies for money, especially if that individual claims they performed the music themselves or otherwise have rights to it. That is similar to the cases where people are upset about GPL violations.
There is a HUGE gap between the cases where people are upset about GPL violations and the record companies are upset. I tried to give an equivalent of what the record companies are doing: if a government mandate that all computer systems be designed so it is impossible to copy a binary without copying the source code was used to enforce the GPL, then maybe there would be some equivalence. I hope you can see how silly that is, or how scary it would be if it was true (and also I tried to explain why that would actually *hurt* GPL). But the difference between DRM and GPL is so vast that it is totally silly to try to compare them.
I understand we cannot build a wooden sailing warship anywhere near as good as the ones we had in the early 1800's either. For one thing all the big oak trees and that tall straight trees for the masts have been cut down.
Yes you must comply with both the copyrights on the GPL and the copyrights on music. They are exactly the same.
The music one is simpler: you cannot redistribute the music to anybody.
The GPL grants you the ability to redistribute, if you follow some rules Don't like the GPL's rules? Well then don't redistribute. The result is identical to the music case, you cannot redistribute at all!
I think the complaint is more about DRM. GPL proponents are not forcing computer systems to somehow enforce the GPL. I guess they could force designing the system so you cannot copy the binary somewhere without also copying the source, which you could imagine would be very detrimental to the usability of a computer as caching and encryption and code signing and an awful lot of other things would be impossible or at least very slow, and thus would make binaries where hackers have defeated the GPL attachement (maybe by fooling it into using hello_world.c as the source) more valuable and everybody would use that instead, thus actually defeating the entire purpose of the GPL.
That is what DRM is doing, it is attempting to enforce copyright through technical means, along with annoying side effects that is encouaging everybody to break it.
You are confusing "distribution" with redistribution
I can say "I will give you some code I wrote with a GPL license in exchange for $20". If you don't give me the $20, you don't get the code, and the fact that it is GPL licensed does NOTHING. In fact I could even say "I'll give you this code and put it in the public domain for $20". But unless I get the $20 you will not see the code, it is totally irrelevant what license I plan to put it under!
However once you have it, if I really have granted you the GPL license to violate the copyright, you can go ahead and do so. And this means you can give it to other people and they won't have to pay me $20. That is redistribution.
The record companies, with no changes to copyright or any license or EULA at all, can say "you can't give this music to somebody else because you are violating copyright law", ie it is just like the GPL except there are no exceptions that let you violate copyright law.
You are still not getting it. The GPL does not "restrict" you in any way, copyright law restricts you. The GPL says "you can violate copyright law if you do this special step". You are free to take advantage of that, but it the special step is too painful for you, then just ignore it, and the GPL is doing nothing, and certainly not restricting you at all. And you get the source code to look at and/or modify for your own use, if you care.
The finder should instead, internally, try to do the do the operation it was asked to do. If it then gets a "permission denied" it then runs a special setuid program that is basically "should the administrator be allowed to do this? If so, the setuid program does it, and returns 0. If not it returns 1 and the finder then reports the error.
The result will be the same to the user, but the user (and programs they are running) will not be able to mess with/Applications without sudo. The fact that an Administrator account can do a system call that is the same as "mv ~/virus/Applications/Terminal" sounds really bad to me.
I believe that is true of Unix as well. However I think both systems have a way for program A to run program B *without* the privledges. If it does not do that, it is program A's fault.
NT has always been able to handle, say, multiple users telnetted in
This is absolutley false. At Digital Domain this was a huge problem with running the render farm machines using NT. The machines had multiple processors which were much more efficiently utilized by running a different job per processor (mutlithreading was somewhat primitive back then). This was trivial on Linux but an absolute pain in the ass on NT, I believe the final solution was to run everything as a single "render farm user".
Enormous amounts of stuff about the "current user" was written to fixed locations in the file system, so it really was impossible for multiple users to use the machine at once.
They did fix this in Win2K. But don't lie when there are people here who know the truth, it does not help your arguments.
I was completely unaware that on OSX a non-administrator can do things like change the time. I thought it was prevented completely, so therefore I created all the accounts as administrator ones. So they need to at least improve their documentation, I did not waste time making a non-administrator to test this.
I still think the adminstrator allowing system calls to do things that don't seem to be allowed, like modifiy/Applications, looks like a Microsoft-sized blunder and is probably a shamefully huge security hole. It really should mean "sudo works" (or the apparent thing from above that "sudo works with this users' password rather than another one").
It does appear that an "administrator" has the file system privledges to modify the/Applications directory, and thus commands typed at the shell will work (so will the system calls to mess with those files so any program can mess it up, but running prorams in/bin from the shell is the easiest way to do it).
For some reason they decided to instead have the Finder do a "is this guy Administrator?" test before doing things that the Finder decided were illegal.
I agree this sounds stupid. The user should not be able to do thise things without sudo! And the Finder should simply get those permission-denied errors from the system and use them to decide if sudo is needed, rather than having to keep it's own model of how system permissions are laid out.
Almost certainly they did this so that applications could be installed/removed, but it does seem like there are better ways. Perhaps if you tried to drag an application to/Applications, the Finder could not do it, but it could recognize the attempt and run a setuid program that refuses to allow overwrite but will add the file.
Huh? I don't get it, and I don't have a Vista machine to really check this out.
My impression was that UAC was a way to allow a non-administrator account to do things that programs want, so that everybody does not have to be administrator.
But it sounds instead like "administrator" and "normal" are the same thing now.
Actually this might make sense if they have to import previous Windows setups where people made all the accounts "administrator". This makes sense. But then they should add an "avoid UAC account" (perhaps called "superuser"?) that does avoid UAC. To prevent the end users making all their accounts be superuser, remove something important from the GUI so they don't want to do it, perhaps the entire start menu and desktop (they can only run file managers, a shell, and the control panels?).
Yes, the EU decision is so that OEM's can include Firefox (or maybe another browser) without Microsoft punishing them by changing the terms of their OEM contact for copies of Windows.
Most will probably leave IE on there as well, I think. This whole thing is just a Microsoft attempt to confuse and distract the issue. It is nice that an OEM can completely remove IE, but no big deal.
I would like to see proof that OEM's are now allowed to sell a machine where Firefox is the default browser.
Slashdot Mirror
You are wrong.
In EXT3, if it crased during those 5 seconds, this bug did NOT happen!!!!
In EXT4, the fact that the time is 150 seconds or whatever is irrelevant. Even if shortened to 5 seconds, if the system crashed, the bug DOES happen!
Adding fsync to "fix" this will actually make EXT4 *slower* than EXT3. Fsync is NOT what is needed. What is needed is for rename(A,B) to insure that A's blocks are on disk before the rename happens. Note that the rename can happen 150 seconds later, or year later. It is the order that is important, and the order is what EXT4 breaks.
No you do not understand.
It is not "important that this data get onto disk now"
What is important is that when I rename(A,B) that "B either has it's old contents or has been replaced by the contents that were in A". This can happen a YEAR in the future, and the important criteria has been met.
And on modern filesystems your criteria is slow to implement, while the second one (because it can happen far in the future) can be batched with others and is fast.
Make a new file, fill it up, rename it over the other file.
This is EXACTLY what KDE is doing, and this is EXACTLY what EXT4 is breaking!
The commit delay was short on ext3 (5 seconds), but a *lot* can happen in 5 seconds, and a lot of data can still be lost in that time period.
I need to keep correcting this misconception:
The bug did NOT happen on EXT3, even if the machine crashed during those 5 seconds. Making EXT4 commit in 5 seconds will not fix it, the time delay has nothing to do with it.
The other mistake you are making is the typical one of thinking what is needed is fsync(). Yes that "fixes" the problem, but only by slowing the whole system down considerably. This is because it enforces a much stronger requirement than is actually necessary to fix the bug.
The fix, as mentioned about a dozen times above, is to have rename(A,B) enforce ordering so that all the blocks of A are committed to disk before the rename is committed to disk. Note that the rename can happen a year later if you want, and the bug will be fixed.
I respecfully disagree.
The filesystem *IS* that "centralized database using a standardized API". The filename is the key, the file contents are the value.
The Windows registry, INI files, and the majority of files in /etc that store more than one thing, are simply symptoms of the misdesign of file systems so that many small files are inefficient.
The files don't have to "litter" anything. Put them in damn subdirectory.
This bug (and the Windows registry) indicates that people just don't get it and still don't get it. Even attempts for Unix to make many files keep doing stupid things like making the file contents be XML or have comments. The "value" should be the bytes in the file!
Yea, one of the biggest proponents killed his wife, but it does not mean the idea is wrong. It is correct.
The problem is not the speed of the write, it is the order.
If a system with EXT3 crashed inside those 5 seconds, the result is NOT as bad as this.
In EXT3, a program doing rename(A,B) while the system crashed would result in either B having it's old contents, or the rename having completed and thus having A's contents.
In EXT4 the crash could result in B being a partially-written version of A. Thus the old contents of B are lost, and so are the contents of A.
The reason this is critical is that the usual method of changing one of the fields in file B is equivalent to this:
sed -e s/Foo/Bar/ <B >A
mv A B
After a crash it would be nice if B was exactly the same as before, except maybe it contains "Bar" or maybe it contains "Foo". People are confusing this with some requirement that it always contain "Bar", which is impossible (you can always pick a point at which the system crashes where this won't happen). The problem with EXT4 is it can result in B containing *nothing*, not "Foo" or "Bar"!
The correct solution, as pointed out by about 10 intelligent posters above, is for EXT4 to make rename force the blocks of A to be put on disk before the rename is committed. Note that this could happen a week later!
There are some very intelligent posters above who have pointed out that the desired result is not achievable with EXT4. fsync fixes the symptom but is NOT the solution! fbarrier is also not right. And POSIX was not written by omnipotent oracles and can be ignored when it is obviously wrong. EXT4 is broken and needs to be fixed!
I'm going to try my own explanation:
If a program starts the call rename(A,B) and then the system crashes, and you reboot and you look at B (not A!!!!), you should either see the contents of A and A does not exist, or the contents of B and YOU DO NOT CARE WHAT IS IN A!!!!!
However as EXT4 is implemented currently, you can get another result: B will contain a partially-written version of A (typically an empty file) and A does not exist. This is VERY BAD, as most likely there was interesting information in B that was copied to A but now both are lost.
fsync as suggested will ensure that the contents of A are correct before the rename(). This is a stronger requirement. It is also dreadfully slow because it has to flush the disk.
fbarrier would be similar. Not as strong as fsync, but it does guarantee that the contents of A are correct before the rename() is committed to disk.
As a side effect of A being correct, fsync and fbarrier reduce the possible results in B of the rename on EXT4 to the desired set, so it does fix the symptoms.
However there are problems with this. By far the most important one is that there are probably ten million programs (including ones written in scripting languages) that assume rename() works as stated above and that it is IMPOSSIBLE to add the fsync/fbarrier call to every one of them. And fsync is dreadfully slow as it really forces the disk to be written right then. fbarrier is better but it is enforcing a slightly stricter limit and thus can still be slower for no actual useful gain.
A pile of locking options on files is not what is needed, despite Windows and VMS doing this. The Unix designers got it RIGHT, 30 years ago, with a correct and very small set of file operations that do what is really wanted (though I would add some sort of atomic create where the file does not appear until closed). Modern designers in OSS and at Microsoft should start showing a little humility and stop throwing all their highschool-level ideas into the designs without some research.
That has been false for a very long time, and not just on Linux.
Do NFS and AFS support atomic renames?
NFS does, but it may require the host to support atomic renames.
Atomic rename is a HUGE part of POSIX so breaking it in a commonly used system like NFS would be bad and was certainly supported in original implementations. However I would not be suprised if NFS support on Windows or some filesystems just implements it with a non-atomic rename.
It is a complete mystery why Windows refuses to add an atomic rename, since it is REALLY useful. My suspicion as to why this and a few other quite easy things are never fixed (like newlines) is that ther is a concerted effort to make sure that code cannot be too easily ported between Windows and Unix.
It certainly IS the intention of rename in any program I have ever seen that just wrote the file!
I agree with the GP, a rename should force the file's contents to be up to date before the rename is committed. This is not going to impact the performance of anything that does not rename a file or anything that renames a file that is just sitting flushed on the disk.
I'm quite certain the GPL is violated all the time. People install GPL software on other's computers and don't bother giving them the source code or providing enough information that the source code can be located. They modify the software (generally small tweaks) and install it and don't give the source code, so it is impossible to recover. They post tweaked versions on the internet for anybody to download and don't include the source, or include incorrect and useless source. Plenty of router manufacturers probably put incorrect or outdated source code on their web sites. And the number of manufacturers caught is probably dwarfed by 10:1 by the number who are violating the GPL, some of them knowingly. Technically the GPL is violated millions of times per second in the use of computers, networks, and bittorrent as binaries are copied without including the source code.
The only cases where the GPL has been enforced is when people sold the resulting product for money. I think everybody can agree that a record company can and should go after an individual selling copies for money, especially if that individual claims they performed the music themselves or otherwise have rights to it. That is similar to the cases where people are upset about GPL violations.
There is a HUGE gap between the cases where people are upset about GPL violations and the record companies are upset. I tried to give an equivalent of what the record companies are doing: if a government mandate that all computer systems be designed so it is impossible to copy a binary without copying the source code was used to enforce the GPL, then maybe there would be some equivalence. I hope you can see how silly that is, or how scary it would be if it was true (and also I tried to explain why that would actually *hurt* GPL). But the difference between DRM and GPL is so vast that it is totally silly to try to compare them.
iso9960?
Maybe. Some other posters mentioned UDF.
I'm not sure if Windows will recognize and read those systems when they are what it thinks is a USB flash disk, though.
I understand we cannot build a wooden sailing warship anywhere near as good as the ones we had in the early 1800's either. For one thing all the big oak trees and that tall straight trees for the masts have been cut down.
Yes you must comply with both the copyrights on the GPL and the copyrights on music. They are exactly the same.
The music one is simpler: you cannot redistribute the music to anybody.
The GPL grants you the ability to redistribute, if you follow some rules Don't like the GPL's rules? Well then don't redistribute. The result is identical to the music case, you cannot redistribute at all!
I think the complaint is more about DRM. GPL proponents are not forcing computer systems to somehow enforce the GPL. I guess they could force designing the system so you cannot copy the binary somewhere without also copying the source, which you could imagine would be very detrimental to the usability of a computer as caching and encryption and code signing and an awful lot of other things would be impossible or at least very slow, and thus would make binaries where hackers have defeated the GPL attachement (maybe by fooling it into using hello_world.c as the source) more valuable and everybody would use that instead, thus actually defeating the entire purpose of the GPL.
That is what DRM is doing, it is attempting to enforce copyright through technical means, along with annoying side effects that is encouaging everybody to break it.
You are confusing "distribution" with redistribution
I can say "I will give you some code I wrote with a GPL license in exchange for $20". If you don't give me the $20, you don't get the code, and the fact that it is GPL licensed does NOTHING. In fact I could even say "I'll give you this code and put it in the public domain for $20". But unless I get the $20 you will not see the code, it is totally irrelevant what license I plan to put it under!
However once you have it, if I really have granted you the GPL license to violate the copyright, you can go ahead and do so. And this means you can give it to other people and they won't have to pay me $20. That is redistribution.
The record companies, with no changes to copyright or any license or EULA at all, can say "you can't give this music to somebody else because you are violating copyright law", ie it is just like the GPL except there are no exceptions that let you violate copyright law.
You are still not getting it. The GPL does not "restrict" you in any way, copyright law restricts you. The GPL says "you can violate copyright law if you do this special step". You are free to take advantage of that, but it the special step is too painful for you, then just ignore it, and the GPL is doing nothing, and certainly not restricting you at all. And you get the source code to look at and/or modify for your own use, if you care.
It can't even run the program to pop up that bubble!
There has to be FAT (or NTFS) on that internal disk or Windows will not run any program off of it.
I think you misunderstood.
The finder should instead, internally, try to do the do the operation it was asked to do. If it then gets a "permission denied" it then runs a special setuid program that is basically "should the administrator be allowed to do this? If so, the setuid program does it, and returns 0. If not it returns 1 and the finder then reports the error.
The result will be the same to the user, but the user (and programs they are running) will not be able to mess with /Applications without sudo. The fact that an Administrator account can do a system call that is the same as "mv ~/virus /Applications/Terminal" sounds really bad to me.
I believe that is true of Unix as well. However I think both systems have a way for program A to run program B *without* the privledges. If it does not do that, it is program A's fault.
NT has always been able to handle, say, multiple users telnetted in
This is absolutley false. At Digital Domain this was a huge problem with running the render farm machines using NT. The machines had multiple processors which were much more efficiently utilized by running a different job per processor (mutlithreading was somewhat primitive back then). This was trivial on Linux but an absolute pain in the ass on NT, I believe the final solution was to run everything as a single "render farm user".
Enormous amounts of stuff about the "current user" was written to fixed locations in the file system, so it really was impossible for multiple users to use the machine at once.
They did fix this in Win2K. But don't lie when there are people here who know the truth, it does not help your arguments.
I was completely unaware that on OSX a non-administrator can do things like change the time. I thought it was prevented completely, so therefore I created all the accounts as administrator ones. So they need to at least improve their documentation, I did not waste time making a non-administrator to test this.
I still think the adminstrator allowing system calls to do things that don't seem to be allowed, like modifiy /Applications, looks like a Microsoft-sized blunder and is probably a shamefully huge security hole. It really should mean "sudo works" (or the apparent thing from above that "sudo works with this users' password rather than another one").
It does appear that an "administrator" has the file system privledges to modify the /Applications directory, and thus commands typed at the shell will work (so will the system calls to mess with those files so any program can mess it up, but running prorams in /bin from the shell is the easiest way to do it).
For some reason they decided to instead have the Finder do a "is this guy Administrator?" test before doing things that the Finder decided were illegal.
I agree this sounds stupid. The user should not be able to do thise things without sudo! And the Finder should simply get those permission-denied errors from the system and use them to decide if sudo is needed, rather than having to keep it's own model of how system permissions are laid out.
Almost certainly they did this so that applications could be installed/removed, but it does seem like there are better ways. Perhaps if you tried to drag an application to /Applications, the Finder could not do it, but it could recognize the attempt and run a setuid program that refuses to allow overwrite but will add the file.
The programs being downloaded and executed do not get the rights so if they try anything they will pop up UAC.
Huh? I don't get it, and I don't have a Vista machine to really check this out.
My impression was that UAC was a way to allow a non-administrator account to do
things that programs want, so that everybody does not have to be administrator.
But it sounds instead like "administrator" and "normal" are the same thing now.
Actually this might make sense if they have to import previous Windows setups where people made all the accounts "administrator". This makes sense. But then they should add an "avoid UAC account" (perhaps called "superuser"?) that does avoid UAC. To prevent the end users making all their accounts be superuser, remove something important from the GUI so they don't want to do it, perhaps the entire start menu and desktop (they can only run file managers, a shell, and the control panels?).
Yes, the EU decision is so that OEM's can include Firefox (or maybe another browser) without Microsoft punishing them by changing the terms of their OEM contact for copies of Windows.
Most will probably leave IE on there as well, I think. This whole thing is just a Microsoft attempt to confuse and distract the issue. It is nice that an OEM can completely remove IE, but no big deal.
I would like to see proof that OEM's are now allowed to sell a machine where Firefox is the default browser.