After I wrote this I realized that mv reverts to cp behavior when there are two different file systems. I would assumme that on the same file system it really does mv the resource fork as well. This is because mv really works by making a hard link and getting rid of the old file, and it has been stated here already that hard links work and the resources are visible through them.
Perhaps it would cause trouble, but I would recommend that Apple actually replace cp and mv with their versions that can do this, so that attempts to use Unix tools won't destroy data that a Mac user may be relying on. A harder solution, but perhaps better, is to make read() and write() to HFS actually read the resource fork, by making the data start with a special code followed by the resource data as a stream, then followed by the file data (is this binhex?). This would allow files to be copied and stored by Unix tools without losing the resource fork.
Also they have to fix open() so it follows the "alias" links. It does not matter if only experts use the Unix tools, at some point a "novice" is going to create an alias, and then run some convienent program somebody gave them that uses open() and it will fail in a mysterious way. This is NOT user friendly.
Should copy the good stuff from 4DWM
on
What Happened to 5dwm?
·
· Score: 3, Interesting
I don't think we need another window manager, but having used Irix for many years, and then switched to Linux, there are a few things that it did that I really miss, and I seriously think they should be put into modern Linux window managers:
One is MWM style raise/drag behavior. Even though I thought it was strange when I first encountered it, I quickly learned to use it, and it is obvious from trying to use modern systems how much superior it was. The rules were simple: the only thing that raised a window was a quick click in the window border. If you dragged or resized the window, it did not raise! Also (vitally important) if you clicked inside the window it did not raise.
Basically if windows raise on clicks it makes it impossible to use overlapping windows. The real horror of today's designs is that nobody seems to realize this, and think all kinds of actually retro ideas ("tiled" windows, "dockable" windows, and "MDI") are "innovations" and not just work-arounds for this bug. If tiled windows were so great they would have been adopted from the Andrew system (or the first Windows systems) for the entire screen. The truth is that the human mind is not set up to deal with objects that change size based on stuff other than the contents of the objects, and this is very unfriendly and makes it hard to spacially locate things. The other scary thing is that every time this is proposed somebody says "but that will be user-unfriendly because it is not EXACTLY like Windows!!!". I believe these are the same Whiners who keep saying "Linux does not innovate".
Another thing is to stop locking "parent" and "child" windows together. This is really the same complaint, but there are NO modern window managers that don't have this bug. What happens is that if you raise a child window, they raise the parent as well, rather than leaving the parent where it was. The parent/child relationship should specify an order but does not mean they have to be next to each other. Again this bug prevents overlapping windows, unless you make all of the windows children of some large and useless parent window.
Also Irix's terminal emulator was a lot better. Especially the methods use to select text and end-of-line. On xterm, kterm, and gterm and the OS/X Terminal app I have to be really careful when trying to select text, and I almost always get it one character off on the end. For some reason the algorithim used by Irix worked perfectly.
Re:well, for one thing it kinda sucked
on
What Happened to 5dwm?
·
· Score: 3, Insightful
You were correct, up to a point.
Both KDE and Gnome use XDND and you can drag & drop. (Gnome also supports some older protocols but I believe it uses XDND even when you go between two Gnome programs).
The problem is not the protocol, but the data being dragged. About the only things you can drag are text (and recently some url's). But in fact XDND has a type identifier very much like Windows for the type of data. In theory the ability to drag different types of data is identical in both systems. However I can list a few advantages Windows has:
First and foremost is that they list in their header file a simple enumeration of types of data. Yes in many ways the set is stupid and based on 1985 technology (for instance URLs are not specified), but at least the list is there and easy to find. The Linux design suffers greately because the people writing XDND try to be correct and admit that somebody else probably knows how to select the data types better than they do. Unfortunately what happens is nobody does.
Second, for some data types (particularily Bitmap) Windows has a simple method to get it on the screen. So an app that just wants to draw what was dropped on it and not think about it much, it is pretty easy. Compare this to X where it is a total nightmare to draw an image (again caused by engineers who don't want to risk doing it wrong and so only provide low level stuff that describes how the screen works). I would think if you had to do a different call for each letter to draw it you would not drag & drop text either.
I am not sure what the problem is with the Xlib designers. I think a lot of it is paranoia about back compatability, and a lot of it is the inability to see that their interface is not understandable, and that an understandable and simple interface is much more important that the maximum-speed interface.
Yes, the total blocking is really a pain and stupid.
Here is a solution that should cost the bank almost nothing. It does not require them to "support all browsers" or change the code on their pages at all (except to remove any detection tests):
Run your normal test for a browser, and if it fails put up a warning "Hey we only support IE 4.18.9.fnord. Your browser is not one of these, so there may be errors in the following pages and we cannot provide phone support. Click here to try anyway.". And if they click, go on and deliver your content as though it was the browser you expected. If Mozilla fails then people can blame MicroSoft for obfuscating things, but they can't blame you at all. And if Mozilla does not fail, then suddenly you have another customer who can use your site!
Encryption experts have not relied on obscurity for a very long time. Even the oldest encryptions told you the algorithim. They key was kept secret, but that is kept secret in modern systems too.
Also your argument applies to BSD or Public Domain code, which most people here assumme are the only alternatives to GPL for the government-produced code. All the options are open to examination.
From what I have heard, the federal goverment must BSD or public domain any code it produces itself entirely. This is because it is not allowed to copyright anything it produces, and the lack of copyright makes the GPL irrelevant (since it simply grants a few exceptions to the copyright but less than making there be no copyright).
However the government should be allowed to use GPL code and modify it. The result is then GPL, because that is part of the rules of the GPL, which even the government cannot break (the government is also allowed to use Windows in their solution but that does not make Windows suddenly free). For that reason I very much oppose this idea, as it's entire purpose is to outlaw the use of GPL software in government.
Under the provision, those who supported the GPL could still use the code in their own work. However, the code would
not be "poisoned" such that businesses and individual programmers would lose their own work, and the rewards from it, if
they used it.
BZZZT! Wrong! You have just stated that the government has the ability to violate copyright law and public-domain something that was copyrighted. This is not true.
You have to realize that the GPL is a granting of additional rights. It lets you do more than you normally can with a copyrighted work. Therefore somebody cannot take GPL code and turn it into BSD code because they are violating copyright and not using one of the exceptions the GPL allows.
Also for this reason I think any code produced by the government must be BSD, becasue apparently the government cannot copyright anything, therefore they do not have the ability to put any of the restrictions on the code allowed by copyright but not by the GPL. However if the government uses GPL code and modifies it, the result must be GPL, since doing that is the only right they have to use the GPL code. They could also go to the original author and ask for the right to BSD it.
Since the GPL is only grants additional rights not granted by copyright, if copyright law was changed so that stuff goes into the public domain after a certain time, then so will the GPL stuff, since the rights granted by the GPL (and also a lot of other rights) are granted by it being public domain.
Therefore, if the FSF is lobbying for a limited term for copyright, they are by definition lobbying for a matching limited term for the GPL. Therefore it is physically impossible for them to be hyprocrites on this subject, despite your claims.
This either would require all shell processing to be removed, or some more complex interface to transmit which words were quoted.
Removing all shell processing is what Windows does. The main benifit of this is you can do a command like "rename *.a *.b" which is considered a much better argument than the one you presented for this design. However there are serious deficiencies, mostly that there is no way for a shell to do scripting-like things and change the arguments. Solving this usually results in worse scripting than even Unix has, because you must now "quote the quotes" so they are passed through, or your sample commands cannot be sent.
Also there is no easy way to name a file with spaces in it. This is usually solved by having a library routine in the program to strip the quotes. If this is done after switches are identified then it will work like you like, but you quickly run into nastiness like trying to make a C-compiler switch like -I"file with spaces" where you must mix the switch removal and quoting. Most results I have seen are exactly like the Unix shell and do not allow the commands you typed in to work either.
The alternative solution would be to pass a "quoted" flag with the words in argv, does anybody know of any system that does that?
It may be possible with a timeout. Either the window does not change until about 1 second after the mouse enters it, or (my preference) the menu bar does not change for about 1 second after the focus window changes and moving the cursor into it changes the focus back to the window the menubar is for.
I can understand cp not working (as the classic implementation is to open the file, read data, and write it, and thus cannot copy anything that is not returned by read()), but are you sure mv does not work for the Resource fork? This would seem to be a serious mistake in the implementation of HFS. Just renaming a file would cause the resources to be lost.
They probably should replace cp with their own program that copies all the data on an HFS disk, but I can at least understand why it does not work.
I'm just guessing, but perhaps not, there may still be knowledge of which one of the files is the original, so if you delete the file you get something like a broken symlink, but moving it acts like a hard link.
Is this correct? It does seem like a good idea.
They really should fix the Unix library to obey them, or this is going to be a big pita for people writing scripts.
I would agree that their current format is too much of a mess. However I suspect they will not learn from this and will make a.NET interface rather than publishing low-level details of the file format. They will not do this because of some evil plan, but because of an actual misguided belief that they are making things easier with the high-level interface. Eventually the implementation in.NET will become such a mess that they will have to replace it again.
I do find it shocking how myopic the MicroSoft defenders who post here are. They are convinced that a.NET or VB interface that runs only on Windows somehow makes the file format "open" and thus fail to see anything wrong with these.NET solutions. Sorry, if that was true then the fact that you can run Word on Windows and read the file would also define it as "open".
"open" means I can interpret the bits without any proprietary software. If they want to provide some convinience routines to make it easier, that is fine, but there should not be a requirement to use these routines.
Upgrading the system should be much easier than installing it. The new system can read the configuration of the old one. Unless MicroSoft is idiots (they are not) then this should not be difficult.
I agree with the earlier poster. Nothing is going to change unless Linux is available pre-installed on consumer machines. If all the machines at Walmart had Linux on it, even if it completely sucked, and MicroSoft gave away a free "upgrade to Windows today" kit in the mail, there would be about 20 to 40 times as many users of Linux as there are today.
why would Microsoft bother creating an XML file format if it was just an "encapsulation of binary, proprietary, encrypted file formats"? What would be the point? A PR move to say that they use XML?
YES! Now you are starting to get it!
I can't think of any reason to adopt an XML format if it wasn't at least a little more open then the binary file formats they've been using.
How about for a "PR move to say they use XML". In addition it is obvious how to make an XML that is exactly as obscure, by putting the entire contents of the old format into a binary block.
Also, how would a "binary, proprietary, encrypted file format" fit into everything else Microsoft is doing with.NET? Wouldn't Microsoft want the content of a document to be open enough so that it could be read and processed by applications using.NET's XML libraries?
No, of course not. You would only read Word documents with the special "read a Word document" interface. It might use the XML libraries underneath, but big deal. Be assurred you will be unable to reconstruct all the contents of the document by any kind of perverted arrangement of calls to the "read a Word document interface". (though not just a complaint abount MicroSoft, I think.NET, DCOM, CORBA, KCOP, etc all pervert the idea of "object orientation" by making elaborate communcation protocols which are only "object oriented" because they call some part of the protocol an "object". Real object-orientation means there is some commonality of functionality, and the only instances I can think of that really work are the original Unix where everything known then (terminals, printers, tapes, disks) used the same read/write/seek calls, and Plan9 which tries to extend this to networks and file systems).
Explain to me why Microsoft would want to prevent you from sending your self-generated Word documents to another computer? What possible sense does this make? Is it because they hate their customers and want to piss them off so they won't use Microsoft products any more? Has RedHat paid Microsoft to include technology that will piss off all Windows users?
Ha ha, very funny. Of course you will be able to send a Word document to another computer. It will still be an unreadable Word document. If they can obfuscate things so that the destination computer also has to be running Windows, all the better. You seem to be under the weird delusion that "other computer" meant "other computer running Windows" when in fact I'm sure every other poster here knew it meant the exact opposite, ie "other computer not controlled by MicroSoft".
The GPL cannot expose somebody to anything worse than copyright violations. Governments Xerox stuff all the time and don't worry about such lawsuits. If you are going to use this as an argument against the GPL you will also have to say that government employees should not be allowed to read any copyrighted books.
Actually raw disk access requires privledges in Linux, and I suspect it is true in the newer versions of Windows. So although this was a threat at one time it seems to be less now.
Easy: MicroSoft makes their modified version part of Windows. It does not matter whether the modified one is better or worse, it is not possible to use Windows without using the modified standard.
The original work is now worthless, as it cannot be used to interoperate with the new standard.
Since the BSD grants more rights than the GPL does, this will not work. It would be irrelevant whether the GPL is on the code or not.
What a lot of people are missing here is that this requirement would outlaw the use of GPL code in government research. This is because any derivative of GPL code has to be GPL (or not distributed, so GPL could still be used inside of government agencies).
This is exactly as nasty as the laws that are being attempted that say that all government code must be based on open-source, just from the opposite end. In both cases huge amounts of potential solutions are being outlawed by a group that wants to force everybody to user their solutions.
That's a silly argument. Of course many states will forget to publish the source code. This is irrelevant until somebody actually wants the source code. Most likely this will be one of those agencies that wants to modify the code futher. Is the state going to say "no because we want to screw that communist RMS and our modification to the duck-counting is valuable intellectual property which we might sell if our state constitution is modified, and besides we have lots of high-paid eager software engineers here already who are anxious to modify the code for you".
No, what is going to happen is it will get to somebody who says "oh here it is in this email. Now go away". And the GPL will be obeyed.
It still does not require Palladium/TCPA hardware support. The site administrator needs a password that only they know and the employees do not know. Palladium/TCPA is entriely designed so that MicroSoft alone knows the password. If the site administrator knew the password they could defeat DRM, so they will not be allowed to, so the site administrator would have to do the same thing they do now.
How, exactly, would that prevent 'root' from making, or allowing others to make, copies of the latest DVDs?
It won't. However it will "prevent viruses" and do other "security" things that MicroSoft is claiming, as a smoke-screen to cover the real purposes of Palladium.
Slashdot Mirror
Perhaps it would cause trouble, but I would recommend that Apple actually replace cp and mv with their versions that can do this, so that attempts to use Unix tools won't destroy data that a Mac user may be relying on. A harder solution, but perhaps better, is to make read() and write() to HFS actually read the resource fork, by making the data start with a special code followed by the resource data as a stream, then followed by the file data (is this binhex?). This would allow files to be copied and stored by Unix tools without losing the resource fork.
Also they have to fix open() so it follows the "alias" links. It does not matter if only experts use the Unix tools, at some point a "novice" is going to create an alias, and then run some convienent program somebody gave them that uses open() and it will fail in a mysterious way. This is NOT user friendly.
One is MWM style raise/drag behavior. Even though I thought it was strange when I first encountered it, I quickly learned to use it, and it is obvious from trying to use modern systems how much superior it was. The rules were simple: the only thing that raised a window was a quick click in the window border. If you dragged or resized the window, it did not raise! Also (vitally important) if you clicked inside the window it did not raise.
Basically if windows raise on clicks it makes it impossible to use overlapping windows. The real horror of today's designs is that nobody seems to realize this, and think all kinds of actually retro ideas ("tiled" windows, "dockable" windows, and "MDI") are "innovations" and not just work-arounds for this bug. If tiled windows were so great they would have been adopted from the Andrew system (or the first Windows systems) for the entire screen. The truth is that the human mind is not set up to deal with objects that change size based on stuff other than the contents of the objects, and this is very unfriendly and makes it hard to spacially locate things. The other scary thing is that every time this is proposed somebody says "but that will be user-unfriendly because it is not EXACTLY like Windows!!!". I believe these are the same Whiners who keep saying "Linux does not innovate".
Another thing is to stop locking "parent" and "child" windows together. This is really the same complaint, but there are NO modern window managers that don't have this bug. What happens is that if you raise a child window, they raise the parent as well, rather than leaving the parent where it was. The parent/child relationship should specify an order but does not mean they have to be next to each other. Again this bug prevents overlapping windows, unless you make all of the windows children of some large and useless parent window.
Also Irix's terminal emulator was a lot better. Especially the methods use to select text and end-of-line. On xterm, kterm, and gterm and the OS/X Terminal app I have to be really careful when trying to select text, and I almost always get it one character off on the end. For some reason the algorithim used by Irix worked perfectly.
Both KDE and Gnome use XDND and you can drag & drop. (Gnome also supports some older protocols but I believe it uses XDND even when you go between two Gnome programs).
The problem is not the protocol, but the data being dragged. About the only things you can drag are text (and recently some url's). But in fact XDND has a type identifier very much like Windows for the type of data. In theory the ability to drag different types of data is identical in both systems. However I can list a few advantages Windows has:
First and foremost is that they list in their header file a simple enumeration of types of data. Yes in many ways the set is stupid and based on 1985 technology (for instance URLs are not specified), but at least the list is there and easy to find. The Linux design suffers greately because the people writing XDND try to be correct and admit that somebody else probably knows how to select the data types better than they do. Unfortunately what happens is nobody does.
Second, for some data types (particularily Bitmap) Windows has a simple method to get it on the screen. So an app that just wants to draw what was dropped on it and not think about it much, it is pretty easy. Compare this to X where it is a total nightmare to draw an image (again caused by engineers who don't want to risk doing it wrong and so only provide low level stuff that describes how the screen works). I would think if you had to do a different call for each letter to draw it you would not drag & drop text either.
I am not sure what the problem is with the Xlib designers. I think a lot of it is paranoia about back compatability, and a lot of it is the inability to see that their interface is not understandable, and that an understandable and simple interface is much more important that the maximum-speed interface.
Here is a solution that should cost the bank almost nothing. It does not require them to "support all browsers" or change the code on their pages at all (except to remove any detection tests):
Run your normal test for a browser, and if it fails put up a warning "Hey we only support IE 4.18.9.fnord. Your browser is not one of these, so there may be errors in the following pages and we cannot provide phone support. Click here to try anyway.". And if they click, go on and deliver your content as though it was the browser you expected. If Mozilla fails then people can blame MicroSoft for obfuscating things, but they can't blame you at all. And if Mozilla does not fail, then suddenly you have another customer who can use your site!
Also your argument applies to BSD or Public Domain code, which most people here assumme are the only alternatives to GPL for the government-produced code. All the options are open to examination.
From what I have heard, the federal goverment must BSD or public domain any code it produces itself entirely. This is because it is not allowed to copyright anything it produces, and the lack of copyright makes the GPL irrelevant (since it simply grants a few exceptions to the copyright but less than making there be no copyright).
However the government should be allowed to use GPL code and modify it. The result is then GPL, because that is part of the rules of the GPL, which even the government cannot break (the government is also allowed to use Windows in their solution but that does not make Windows suddenly free). For that reason I very much oppose this idea, as it's entire purpose is to outlaw the use of GPL software in government.
not be "poisoned" such that businesses and individual programmers would lose their own work, and the rewards from it, if
they used it.
BZZZT! Wrong! You have just stated that the government has the ability to violate copyright law and public-domain something that was copyrighted. This is not true.
You have to realize that the GPL is a granting of additional rights. It lets you do more than you normally can with a copyrighted work. Therefore somebody cannot take GPL code and turn it into BSD code because they are violating copyright and not using one of the exceptions the GPL allows.
Also for this reason I think any code produced by the government must be BSD, becasue apparently the government cannot copyright anything, therefore they do not have the ability to put any of the restrictions on the code allowed by copyright but not by the GPL. However if the government uses GPL code and modifies it, the result must be GPL, since doing that is the only right they have to use the GPL code. They could also go to the original author and ask for the right to BSD it.
Therefore, if the FSF is lobbying for a limited term for copyright, they are by definition lobbying for a matching limited term for the GPL. Therefore it is physically impossible for them to be hyprocrites on this subject, despite your claims.
Did you really propose that air traffic should rely on security through obscurity? I don't want to be within 10 miles of any airports if that happens!
Removing all shell processing is what Windows does. The main benifit of this is you can do a command like "rename *.a *.b" which is considered a much better argument than the one you presented for this design. However there are serious deficiencies, mostly that there is no way for a shell to do scripting-like things and change the arguments. Solving this usually results in worse scripting than even Unix has, because you must now "quote the quotes" so they are passed through, or your sample commands cannot be sent.
Also there is no easy way to name a file with spaces in it. This is usually solved by having a library routine in the program to strip the quotes. If this is done after switches are identified then it will work like you like, but you quickly run into nastiness like trying to make a C-compiler switch like -I"file with spaces" where you must mix the switch removal and quoting. Most results I have seen are exactly like the Unix shell and do not allow the commands you typed in to work either.
The alternative solution would be to pass a "quoted" flag with the words in argv, does anybody know of any system that does that?
It may be possible with a timeout. Either the window does not change until about 1 second after the mouse enters it, or (my preference) the menu bar does not change for about 1 second after the focus window changes and moving the cursor into it changes the focus back to the window the menubar is for.
They probably should replace cp with their own program that copies all the data on an HFS disk, but I can at least understand why it does not work.
I'm just guessing, but perhaps not, there may still be knowledge of which one of the files is the original, so if you delete the file you get something like a broken symlink, but moving it acts like a hard link.
Is this correct? It does seem like a good idea.
They really should fix the Unix library to obey them, or this is going to be a big pita for people writing scripts.
That's a description of XML itself, not of how Word will use XML to store files.
I do find it shocking how myopic the MicroSoft defenders who post here are. They are convinced that a .NET or VB interface that runs only on Windows somehow makes the file format "open" and thus fail to see anything wrong with these .NET solutions. Sorry, if that was true then the fact that you can run Word on Windows and read the file would also define it as "open".
"open" means I can interpret the bits without any proprietary software. If they want to provide some convinience routines to make it easier, that is fine, but there should not be a requirement to use these routines.
I agree with the earlier poster. Nothing is going to change unless Linux is available pre-installed on consumer machines. If all the machines at Walmart had Linux on it, even if it completely sucked, and MicroSoft gave away a free "upgrade to Windows today" kit in the mail, there would be about 20 to 40 times as many users of Linux as there are today.
file formats"? What would be the point? A PR move to say that they use XML?
YES! Now you are starting to get it!
I can't think of any reason to adopt an XML format if it wasn't at
least a little more open then the binary file formats they've been using.
How about for a "PR move to say they use XML". In addition it is obvious how to make an XML that is exactly as obscure, by putting the entire contents of the old format into a binary block.
Also, how would a "binary, proprietary, encrypted file format" fit into everything else Microsoft is doing with .NET? Wouldn't Microsoft .NET's XML libraries?
want the content of a document to be open enough so that it could be read and processed by applications using
No, of course not. You would only read Word documents with the special "read a Word document" interface. It might use the XML libraries underneath, but big deal. Be assurred you will be unable to reconstruct all the contents of the document by any kind of perverted arrangement of calls to the "read a Word document interface". (though not just a complaint abount MicroSoft, I think .NET, DCOM, CORBA, KCOP, etc all pervert the idea of "object orientation" by making elaborate communcation protocols which are only "object oriented" because they call some part of the protocol an "object". Real object-orientation means there is some commonality of functionality, and the only instances I can think of that really work are the original Unix where everything known then (terminals, printers, tapes, disks) used the same read/write/seek calls, and Plan9 which tries to extend this to networks and file systems).
Explain to me why Microsoft would want to prevent you from sending your self-generated Word documents to another computer? What possible sense does this make? Is it because they hate their customers and want to piss them off so they won't use Microsoft products any more? Has RedHat paid Microsoft to include technology that will piss off all Windows users?
Ha ha, very funny. Of course you will be able to send a Word document to another computer. It will still be an unreadable Word document. If they can obfuscate things so that the destination computer also has to be running Windows, all the better. You seem to be under the weird delusion that "other computer" meant "other computer running Windows" when in fact I'm sure every other poster here knew it meant the exact opposite, ie "other computer not controlled by MicroSoft".
The GPL cannot expose somebody to anything worse than copyright violations. Governments Xerox stuff all the time and don't worry about such lawsuits. If you are going to use this as an argument against the GPL you will also have to say that government employees should not be allowed to read any copyrighted books.
Actually raw disk access requires privledges in Linux, and I suspect it is true in the newer versions of Windows. So although this was a threat at one time it seems to be less now.
Easy: MicroSoft makes their modified version part of Windows. It does not matter whether the modified one is better or worse, it is not possible to use Windows without using the modified standard.
The original work is now worthless, as it cannot be used to interoperate with the new standard.
What a lot of people are missing here is that this requirement would outlaw the use of GPL code in government research. This is because any derivative of GPL code has to be GPL (or not distributed, so GPL could still be used inside of government agencies).
This is exactly as nasty as the laws that are being attempted that say that all government code must be based on open-source, just from the opposite end. In both cases huge amounts of potential solutions are being outlawed by a group that wants to force everybody to user their solutions.
The original is worthless if the secret modification is the standard. His fear is not irrational in any way. You are irrational.
Absolutely false. The government publishes stuff with copyrights. Therefore the GPL is allowed.
No, what is going to happen is it will get to somebody who says "oh here it is in this email. Now go away". And the GPL will be obeyed.
It still does not require Palladium/TCPA hardware support. The site administrator needs a password that only they know and the employees do not know. Palladium/TCPA is entriely designed so that MicroSoft alone knows the password. If the site administrator knew the password they could defeat DRM, so they will not be allowed to, so the site administrator would have to do the same thing they do now.
It won't. However it will "prevent viruses" and do other "security" things that MicroSoft is claiming, as a smoke-screen to cover the real purposes of Palladium.