Well you finally said what I have been trying to get through the thick skulls of the NT defenders: "If you want to argue about where the case-matching should be implemented". That is precisely what I am trying to argue.
The problem with NT, etc, is that they assign meaning to those bits stored in the directory at a very low level. This prevents usage of those bits for more general purposes, and prevents smarter assignment of meaning at higher levels. If NT had stored raw 8-bit data like Unix does, they could have supported Unicode with NO CHANGES TO THE FILE SYSTEM (this would be done by using UTF-8, which also has the advantage of being upwardly-compatable with 8-bit names).
I totally agree that Unix user-level programs are written by lazy programmers who think that making it hard to use is kool. It is amazing that case-independent filename completion has taken so long and is still not the default for these shells. But for too long everybody has attacked this with equally lazy and very wrong ideas where this is stuffed into the file system.
Your terminology is wrong. Unix is case-preserving. The systems you are talking about (and also some Unix filesystems like AFS) are case-preserving + case-independent. Old MSDOS file systems were only case-independent but not case-preserving.
I also find it interesting that you are so enamored of an NT feature that is useless except for command line programs. The "overwhelming majority" of people click on files and would never notice if there were several files with the same name, and are not going to be bothered because both "Buffalo" and "buffalo" exist.
You can name the files with any of these letters, yes. But I was talking about the case-independence. At the file system level they only map case between the first 255 characters that are ISO-8859-1. This is a very smart decision, as the exact mapping for the rest of Unicode is not defined yet!
Actually Unix is "case-preserving", you mean case-independent plus case-preserving. This is probably the most common system, even some Unix systems (AFS) follow this model, too.
I believe they all are wrong, as I would prefer the assignment of meaning to these bytes be moved out of the file system and into user space. The reason is that there is far more complex matching rules (such as spelling correction and full UTF-8 case independence) that need to be done as well, and a partial solution like this is worse than none at all.
I have followed this for years, in the hope that something reasonable will replace X. However I don't see the Berlin people really trying to produce what is needed, nor do I see anybody else doing so.
First, we do not need another toolkit. We need an environment that makes it easy to write toolkits. If we have this, GTK and Qt will be ported quite quickly, and maybe new toolkits simple enough to be programmed by mere mortals will appear.Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows", but conversely you should be able to easily (ie with no setup before the drawing function) do full PostScript and OpenGL graphics into these, and anti-aliased fonts, full UTF-8 formatting of text, and high speed placing of images with arbitrary linear transformations from user memory onto the screen.
(The problem with Berlin and the other projects like it is that is is really trivial to write a toolkit compared to writing what powerful antialiased graphics or asynchronous communication interfaces, and writing toolkits appeals to the programmer's desire to control how others use his/her system, so the programmers get diverted to this useless bloat that actually makes their stuff less likely to be used.)
Berlin has to have an Xlib emulation library so that X11 programs (and remote X clients) can display on the Berlin server. Fortunately this is easier than it used to be because the emulation library only has to pretend that a TrueColor visual exists (a few years ago emulating an 8-bit colormap was mandatory to get some of the awful X clients to work, but these have disappeared). This emulation is absolutely necessary so that people can migrate to Berlin. There is no need to be able to run X window managers.
Conversely, Berlin programs must work on X11. The graphics can be lousy, very slow, and plenty of functionality can be missing (don't crash, but leave blanks in the output). This requires an implementation of the Berlin interface that works atop Xlib. Without this people will not write new applications for Berlin.
Finally Berlin must be easy to program. It should be absolutely clear to someone without a PHD exactly what you do to create a window and draw into it, and to get events, by reading the manual in sequential order. The set of calls should be reduced as much as possible, there should be as few arguments as possible, and none of the arguments should be structures or pointers to structures. Use a static graphics state like OpenGL. And there should not be gratuitous objects, colors are identified by rgb numbers, not "color objects", fonts are identified by names, not "font objects", etc. Use integer ID's for the canvases.
The library has to be C rather than C++ or any other language to make the Gnome/GTK people happy.
Actually, no. This form of file completion (show then entire first match) is what was first done by the csh shells. They used ESC to trigger filename completion (due to lameness in the Unix tty drivers this was the only sequence detectable).
Everybody realized pretty quickly that partial completion is far better. Of course MicroSoft is pretty far behind (for mysterious reasons, certainly there was somebody there who had used Unix file completion, and could have told them how to do it right...)
Re:There's a debate like this for NT users:
on
To Z Or Not To Z
·
· Score: 2
Actually nobody in their right mind uses those.
All of these shells have been ported to NT, so in fact you get exactly the same question there as well.
Next time you use a filename to start a sentence, please tell me. And I was unaware that you could not use a proper noun to name a file.
I do think there is a legitimate complaint that the user level programs do not do more to help people with case-insensitve searches. They also don't handle spelling errors very well either.
However there is no reason to put case-insensitive rules into the file system itself. It is actually counter-productive for real case insensitivity since it often precludes making smarter front ends since it hides information (NT has some difficulty here). Also the rules for Unicode/UTF-8 are FAR too complex to rely on in code like a filesystem which security relies on.
My personal preference is for partial case-insensitivity: lower-case that I type in matches both upper and lower case, but upper case matches only upper case. This was the rules for the Final Word word processor I worked on in 1985, but for some reason these rules have totally disappeared from modern software. It worked great because it would find words at the start of sentences, but you could search for proper names (or sentence starts), and we didn't need a "case insensitive" switch.
In any case, no matter what the ideal user experience is, it definately should be moved out of low-level things like the file system. NT has got to fix this or they are going to get killed with security problems, especially in a hetrogenous environment of shared file systems.
You are talking about the ISO-8859-1 subset, not Unicode.
NT does not accurately transform letters between case for Unicode at the filesystem level. They have decided (quite rightly) that doing this is an enormous security hole (because of different systems getting the rules differently and thus failing to notice that a program is going to clobber an existing file).
The proper place to do anything complex like this is at the user level. Unfortunately NT is forced to be back-compatable with their case-insensiteve file system so the case matching is rather complex and spread between two systems.
Unix design is in fact correct, where the filenames are a stream of bytes. The interpreteation of these bytes should be left for the user level.
A legitimate complaint would be that the Unix programmers keep neglecting to put such stuff into the user level. That is true. But the NT file system is wrong, and the engineers at MicroSoft are well aware of this fact.
Last time I checked, Visual C++ is case-sensitive for the variable names. Gee, even C# is. I dunno about VB, though.
Putting a user-interface preference into the file system is a really stupid thing to do and NT should be blasted for it. However I would agree that Unix shells and file choosers could make the assumption that people may mistype the case of their filenames and it should be fixed. While they are at it they could do spelling correction and other such stuff (I bet you think the file system should do spelling correction too, since you think the case-insensitive parts of it are a big win, huh?)
However a couple things he suggested are not GUI. In particular file associations. These are assummed to be "GUI" because they first appeared on the Mac and then on Windows. However it should be pretty obvious that a CLI shell could be written that took any filename typed in, looked up the association, and ran the program. Thus these associations are no more "GUI" than $PATH is.
A common utility program (and easily replaced) to pop up a file chooser, wait for the user to pick a file, and then exits printing the result to stdout, would also be useful. It could greatly reduce bloat of programs by eliminating a large chunk of the toolkit they need to link. Adding some standard programs to display a message, ask the user a question, etc, would allow even scripts to have a "GUI".
Correct, it appears that Netscape is in the minority.
Most new Unix programs use the PRIMARY selection for both the "copy" command and select-this-text. Netscape uses the SECONDARY selection for the copy & paste command. So only middle-mouse-click works to it. This may be true of all Motif programs.
I discovered this quite quickly when I foolishly tried to make fltk use SECONDARY in the same way. It fixed Netscape but broke everything else.
Only using PRIMARY is also good when you have programs like xterm, or ported Windows programs, that only have one way to paste.
I agree. Why is this all built into a big application.
Sure the thing looks great, but I want to be able to write a program that does this:
FILE* f = fopen("http://www.slashdot.org","r");
And it should work! I should not have to create objects or link with some huge GUI/Corba/COM monster. And I should get FULL SPEED if I open a local file, without using if statements to decide what library I want to use to read it. In fact I think this functionality should be built into the system (as fs drivers, of course), this would match the Unix design where you write to serial ports using the same code as for files. In a lot of ways these new giant shared libraries are introducing the bad designs that K&R threw out 30 years ago!
Although it would be difficult to get computer novices used to it, it may make sense to always append. The clipboard is cleared by copying data that cannot be appended, or by "pasting" to the trash, and maybe there is a keyboard shortcut.
The pure stack suggested here is probably not good because it disallows multiple copies. But something like Emacs M-Y would be good: it indicates that you wanted an earlier cut and replaces the one you just did with another.
I think it should paste the filenames (or "url"s) to the text window, with spaces between them and quotes if needed. Of course it doesn't, instead the clipboard seems to return the last cut of the requested type, ie you get the text you last cut.
This also means that a paste much later can move a file you copied long ago, which is kind of strange. Most users learn to always copy & paste immediately.
I don't think the semantics are bad, really. The big problem is that "cut" does not remove the item from the display. It probably should (without deleting the real file). Further cut commands should append to the list. And if you cut anything other than a file, or you paste to anything other than a file browser that can actually move the files to a safe location, the files reappear back where they were as though nothing happened.
The bits are part of the file format. Not reading them and doing what they say is the same as saying it should ignore the command that makes text bold.
If these are removed I would expect the code and knowledge of how to read these bits to disappear, through code rot. That is not good, all information about the file should be available.
Also several people have pointed out legitimate uses of these bits, to at least make people think a bit before they do something that the author does not want. A good reason for not allowing printing is to force people to always read the up-to-date online version (preventing paper waste is better handled by the printing system, though).
Comon, it's trivial to bypass. If it requires recompiling the code, well then you can look l33t because you can do it while your coworkers cannot.
It could be a switch to the program, or attempts to do illegal things could pop up an error box and perhaps let you turn it off. But don't just ignore the bits.
NeWS was a great deal more efficient with bandwidth than X.
One reason is the widgets resided on the server. However I have said a few times here, and still feel, that this is a very very bad idea and should be avoided at all costs.
Ignoring that, NeWS was still faster and used less bandwidth, and here is why I think it did:
The stream was a simple encoding, not a library, and not structured. Basically it was PostScript, but all the bytes with the high bit set were equivalents of common PostScript tokens, small numbers like 0 and 1, and they introduced packed arrays of float, int, or char.
The commands to create and map windows, to pick windows to draw into, and all the graphics, were entirely asynchronous. In fact synchronous communication was completely left out of NeWS design. Therefore no blocking or sync indicators had to be put into the stream.
The graphics were quite high-level. In particular compared to X it was easy to select a font and draw in it at any size and transformation. You could also draw an image with arbitrary transformation, so a small image could be blown up and this could take much less bandwidth.
You could download small graphics primitives as PostScript procedures, to make the graphics even "higher level"
DPS is not a good solution because it does not replace the window mapping and color management code of X. This is a significant part of the bandwidth.
Yet another reason why the horrid Xlib interface has got to go (and why the proposed XRender interface is also no good).
We cannot have information about how the display renders in user-visible structures that are required as arguments to graphics calls. It prevents exactly the type of behavior wanted.
This means any concept of "graphics context" must be provided by static state and not by arguments to the calls. These internal structures can have device-specific information in them because they are hidden and no user code depends on their contents not changing (though I would prefer to push it all to the server).
This is very commonly suggested, and I think it is completely wrong. We do not want the toolkit to reside on the server. I worked on NeWS, which was an excellent system, but I think this approach resulted in the system being unusable for outside programs.
The main problem is that toolkit widgets quickly bloat up to have a huge amount of data that describes them. I think it is very likely that the amount of data will exceed the few rectangles sent to draw the widget. This is true of the ICCCM protocols for window managers: I have written a toolkit and a window manager, and I believe the code I need in the toolkit is about 3 times larger than the code I would need if I could just draw the window borders and handle drag + resize myself. Meanwhile I estimate the window manager is 85% communication code and only a tiny portion of actual drawing and event handling.
The other, and far more serious, problem, is that you will lock the interface into current toolkit design ideas. If X had been designed like this we would be forced to use the very early Athena widgets, and they would never have been changed due to the above-mentioned interface complexity. Because X was not designed like this, despite it's problems, it is able to emulate interfaces developed 15 years later with no problem!
Re:queing is implemented in X but...
on
Low-Bandwidth X
·
· Score: 2
Excellent analysis, this is exactly what is wrong. It is even the problem with local X servers. Unfortunately too many people think the problem is that it is a server, or that a serial pipe is used, or other things that are actually good.
The problem is the bad aspects of XLib, where huge amounts of work cannot be done without doing synchronouse reqests for information.
I think the X protocol was designed for asynchronous message flow, aspects of how damage events and window mapping are handled show that they planned this. All the synchronous messages are from the bad stuff that was added in X11, when they started quickly bloating it to provide the features (like color) people were insisting on, and were unable to do things correctly.
I see no way to get true low bandwidth unless the Xlib protocol (and thus all programs that use Xlib) is scrapped and replaced.
Do you know that your idea would deprive software engineers of income? The writer of the software can release it under multiple licenses, you know. Releasing useful code under the GPL and then charging for commercial use is actually quite possible, and the GPL version provides useful publicity and familiarity to increase sales. I think Troll Tech is doing ok with this model..
If I wanted you to be able to make money off my hard work, I would have relased under a different license.
He said: "they DON'T giver her a pile of CD's, the IT department does the work".
Look up the word "don't" in the dictionary in case you are confused.
In your terms, what he said is "they DON'T give you a pile of car parts, instead a handy company does the hard work of putting the car together for you."
A lot of configuration should be possible from a normal logged-in user.
When you click "apply" it should pop up a box that says "enter the root password" and the user types it in.
For security the program that popped up the box would be a very small suid one that used no toolkit, and is passed the shell script to execute on stdin. It would also have a button to display the shell script to the user, in case they are suspicious. This does mean the user has to type in the root password over and over as they try changes, but it removes the need for any user-level program to remember the root password and removes the need to have a command to drop suid privledges.
Slashdot Mirror
The problem with NT, etc, is that they assign meaning to those bits stored in the directory at a very low level. This prevents usage of those bits for more general purposes, and prevents smarter assignment of meaning at higher levels. If NT had stored raw 8-bit data like Unix does, they could have supported Unicode with NO CHANGES TO THE FILE SYSTEM (this would be done by using UTF-8, which also has the advantage of being upwardly-compatable with 8-bit names).
I totally agree that Unix user-level programs are written by lazy programmers who think that making it hard to use is kool. It is amazing that case-independent filename completion has taken so long and is still not the default for these shells. But for too long everybody has attacked this with equally lazy and very wrong ideas where this is stuffed into the file system.
Your terminology is wrong. Unix is case-preserving. The systems you are talking about (and also some Unix filesystems like AFS) are case-preserving + case-independent. Old MSDOS file systems were only case-independent but not case-preserving.
I also find it interesting that you are so enamored of an NT feature that is useless except for command line programs. The "overwhelming majority" of people click on files and would never notice if there were several files with the same name, and are not going to be bothered because both "Buffalo" and "buffalo" exist.
You can name the files with any of these letters, yes. But I was talking about the case-independence. At the file system level they only map case between the first 255 characters that are ISO-8859-1. This is a very smart decision, as the exact mapping for the rest of Unicode is not defined yet!
I believe they all are wrong, as I would prefer the assignment of meaning to these bytes be moved out of the file system and into user space. The reason is that there is far more complex matching rules (such as spelling correction and full UTF-8 case independence) that need to be done as well, and a partial solution like this is worse than none at all.
First, we do not need another toolkit. We need an environment that makes it easy to write toolkits. If we have this, GTK and Qt will be ported quite quickly, and maybe new toolkits simple enough to be programmed by mere mortals will appear.Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows", but conversely you should be able to easily (ie with no setup before the drawing function) do full PostScript and OpenGL graphics into these, and anti-aliased fonts, full UTF-8 formatting of text, and high speed placing of images with arbitrary linear transformations from user memory onto the screen.
(The problem with Berlin and the other projects like it is that is is really trivial to write a toolkit compared to writing what powerful antialiased graphics or asynchronous communication interfaces, and writing toolkits appeals to the programmer's desire to control how others use his/her system, so the programmers get diverted to this useless bloat that actually makes their stuff less likely to be used.)
Berlin has to have an Xlib emulation library so that X11 programs (and remote X clients) can display on the Berlin server. Fortunately this is easier than it used to be because the emulation library only has to pretend that a TrueColor visual exists (a few years ago emulating an 8-bit colormap was mandatory to get some of the awful X clients to work, but these have disappeared). This emulation is absolutely necessary so that people can migrate to Berlin. There is no need to be able to run X window managers.
Conversely, Berlin programs must work on X11. The graphics can be lousy, very slow, and plenty of functionality can be missing (don't crash, but leave blanks in the output). This requires an implementation of the Berlin interface that works atop Xlib. Without this people will not write new applications for Berlin.
Finally Berlin must be easy to program. It should be absolutely clear to someone without a PHD exactly what you do to create a window and draw into it, and to get events, by reading the manual in sequential order. The set of calls should be reduced as much as possible, there should be as few arguments as possible, and none of the arguments should be structures or pointers to structures. Use a static graphics state like OpenGL. And there should not be gratuitous objects, colors are identified by rgb numbers, not "color objects", fonts are identified by names, not "font objects", etc. Use integer ID's for the canvases.
The library has to be C rather than C++ or any other language to make the Gnome/GTK people happy.
Everybody realized pretty quickly that partial completion is far better. Of course MicroSoft is pretty far behind (for mysterious reasons, certainly there was somebody there who had used Unix file completion, and could have told them how to do it right...)
All of these shells have been ported to NT, so in fact you get exactly the same question there as well.
I do think there is a legitimate complaint that the user level programs do not do more to help people with case-insensitve searches. They also don't handle spelling errors very well either.
However there is no reason to put case-insensitive rules into the file system itself. It is actually counter-productive for real case insensitivity since it often precludes making smarter front ends since it hides information (NT has some difficulty here). Also the rules for Unicode/UTF-8 are FAR too complex to rely on in code like a filesystem which security relies on.
My personal preference is for partial case-insensitivity: lower-case that I type in matches both upper and lower case, but upper case matches only upper case. This was the rules for the Final Word word processor I worked on in 1985, but for some reason these rules have totally disappeared from modern software. It worked great because it would find words at the start of sentences, but you could search for proper names (or sentence starts), and we didn't need a "case insensitive" switch.
In any case, no matter what the ideal user experience is, it definately should be moved out of low-level things like the file system. NT has got to fix this or they are going to get killed with security problems, especially in a hetrogenous environment of shared file systems.
NT does not accurately transform letters between case for Unicode at the filesystem level. They have decided (quite rightly) that doing this is an enormous security hole (because of different systems getting the rules differently and thus failing to notice that a program is going to clobber an existing file).
The proper place to do anything complex like this is at the user level. Unfortunately NT is forced to be back-compatable with their case-insensiteve file system so the case matching is rather complex and spread between two systems.
Unix design is in fact correct, where the filenames are a stream of bytes. The interpreteation of these bytes should be left for the user level.
A legitimate complaint would be that the Unix programmers keep neglecting to put such stuff into the user level. That is true. But the NT file system is wrong, and the engineers at MicroSoft are well aware of this fact.
Putting a user-interface preference into the file system is a really stupid thing to do and NT should be blasted for it. However I would agree that Unix shells and file choosers could make the assumption that people may mistype the case of their filenames and it should be fixed. While they are at it they could do spelling correction and other such stuff (I bet you think the file system should do spelling correction too, since you think the case-insensitive parts of it are a big win, huh?)
A common utility program (and easily replaced) to pop up a file chooser, wait for the user to pick a file, and then exits printing the result to stdout, would also be useful. It could greatly reduce bloat of programs by eliminating a large chunk of the toolkit they need to link. Adding some standard programs to display a message, ask the user a question, etc, would allow even scripts to have a "GUI".
Most new Unix programs use the PRIMARY selection for both the "copy" command and select-this-text. Netscape uses the SECONDARY selection for the copy & paste command. So only middle-mouse-click works to it. This may be true of all Motif programs.
I discovered this quite quickly when I foolishly tried to make fltk use SECONDARY in the same way. It fixed Netscape but broke everything else.
Only using PRIMARY is also good when you have programs like xterm, or ported Windows programs, that only have one way to paste.
Does anybody have documentation on that image format xv uses? Or is it considered standard to put any image format there now?
Sure the thing looks great, but I want to be able to write a program that does this:
FILE* f = fopen("http://www.slashdot.org","r");
And it should work! I should not have to create objects or link with some huge GUI/Corba/COM monster. And I should get FULL SPEED if I open a local file, without using if statements to decide what library I want to use to read it. In fact I think this functionality should be built into the system (as fs drivers, of course), this would match the Unix design where you write to serial ports using the same code as for files. In a lot of ways these new giant shared libraries are introducing the bad designs that K&R threw out 30 years ago!
The pure stack suggested here is probably not good because it disallows multiple copies. But something like Emacs M-Y would be good: it indicates that you wanted an earlier cut and replaces the one you just did with another.
This also means that a paste much later can move a file you copied long ago, which is kind of strange. Most users learn to always copy & paste immediately.
I don't think the semantics are bad, really. The big problem is that "cut" does not remove the item from the display. It probably should (without deleting the real file). Further cut commands should append to the list. And if you cut anything other than a file, or you paste to anything other than a file browser that can actually move the files to a safe location, the files reappear back where they were as though nothing happened.
If these are removed I would expect the code and knowledge of how to read these bits to disappear, through code rot. That is not good, all information about the file should be available.
Also several people have pointed out legitimate uses of these bits, to at least make people think a bit before they do something that the author does not want. A good reason for not allowing printing is to force people to always read the up-to-date online version (preventing paper waste is better handled by the printing system, though).
Comon, it's trivial to bypass. If it requires recompiling the code, well then you can look l33t because you can do it while your coworkers cannot. It could be a switch to the program, or attempts to do illegal things could pop up an error box and perhaps let you turn it off. But don't just ignore the bits.
One reason is the widgets resided on the server. However I have said a few times here, and still feel, that this is a very very bad idea and should be avoided at all costs.
Ignoring that, NeWS was still faster and used less bandwidth, and here is why I think it did:
The stream was a simple encoding, not a library, and not structured. Basically it was PostScript, but all the bytes with the high bit set were equivalents of common PostScript tokens, small numbers like 0 and 1, and they introduced packed arrays of float, int, or char.
The commands to create and map windows, to pick windows to draw into, and all the graphics, were entirely asynchronous. In fact synchronous communication was completely left out of NeWS design. Therefore no blocking or sync indicators had to be put into the stream.
The graphics were quite high-level. In particular compared to X it was easy to select a font and draw in it at any size and transformation. You could also draw an image with arbitrary transformation, so a small image could be blown up and this could take much less bandwidth.
You could download small graphics primitives as PostScript procedures, to make the graphics even "higher level"
DPS is not a good solution because it does not replace the window mapping and color management code of X. This is a significant part of the bandwidth.
We cannot have information about how the display renders in user-visible structures that are required as arguments to graphics calls. It prevents exactly the type of behavior wanted.
This means any concept of "graphics context" must be provided by static state and not by arguments to the calls. These internal structures can have device-specific information in them because they are hidden and no user code depends on their contents not changing (though I would prefer to push it all to the server).
The main problem is that toolkit widgets quickly bloat up to have a huge amount of data that describes them. I think it is very likely that the amount of data will exceed the few rectangles sent to draw the widget. This is true of the ICCCM protocols for window managers: I have written a toolkit and a window manager, and I believe the code I need in the toolkit is about 3 times larger than the code I would need if I could just draw the window borders and handle drag + resize myself. Meanwhile I estimate the window manager is 85% communication code and only a tiny portion of actual drawing and event handling.
The other, and far more serious, problem, is that you will lock the interface into current toolkit design ideas. If X had been designed like this we would be forced to use the very early Athena widgets, and they would never have been changed due to the above-mentioned interface complexity. Because X was not designed like this, despite it's problems, it is able to emulate interfaces developed 15 years later with no problem!
The problem is the bad aspects of XLib, where huge amounts of work cannot be done without doing synchronouse reqests for information.
I think the X protocol was designed for asynchronous message flow, aspects of how damage events and window mapping are handled show that they planned this. All the synchronous messages are from the bad stuff that was added in X11, when they started quickly bloating it to provide the features (like color) people were insisting on, and were unable to do things correctly.
I see no way to get true low bandwidth unless the Xlib protocol (and thus all programs that use Xlib) is scrapped and replaced.
Maybe you should complain to MicroSoft about how much money you are losing because you can't use their code either!
Don't come back until you show at least the slightest indication that you know what you are talking about!
Do you know that your idea would deprive software engineers of income? The writer of the software can release it under multiple licenses, you know. Releasing useful code under the GPL and then charging for commercial use is actually quite possible, and the GPL version provides useful publicity and familiarity to increase sales. I think Troll Tech is doing ok with this model..
If I wanted you to be able to make money off my hard work, I would have relased under a different license.
He said: "they DON'T giver her a pile of CD's, the IT department does the work".
Look up the word "don't" in the dictionary in case you are confused.
In your terms, what he said is "they DON'T give you a pile of car parts, instead a handy company does the hard work of putting the car together for you."
Got it?
When you click "apply" it should pop up a box that says "enter the root password" and the user types it in.
For security the program that popped up the box would be a very small suid one that used no toolkit, and is passed the shell script to execute on stdin. It would also have a button to display the shell script to the user, in case they are suspicious. This does mean the user has to type in the root password over and over as they try changes, but it removes the need for any user-level program to remember the root password and removes the need to have a command to drop suid privledges.