On Mon, 3 Dec 2001, Chris Howells wrote:
It always irritates me when I have to use a system on which the user interface has been locked down in the interests of 'security'. This is, as far as I can tell, a practice that originates from the days of Windows 95, when you had to lock down the user interface simply because the underlying system didn't provide any security itself. This is not the case with Linux; even if you leave the full user interface exposed there is very little that users can do that will affect anything beyond their own personal settings. Absolutely true. But would you really want users changing their personal settings (and possibly making a mess -> wasted time for the administrator) when they could be doing more productive things?
I have no problem with people customising their desktop. In fact, one of our primary schools uses this as the "introduction to the computer suite" lesson: the students are shown how to log on and how to play around with their wallpaper etc. It's a good way for them to get familiar with the interface without being distracted by anything extraneous (typing exercises, etc.). Out of well over 1000 users of systems that I have configured, used by ages 5 to 60, I have yet to have any of my time wasted by users making a mess by changing their personal settings.
We have had no problems with providing "unlocked" user interfaces to both primary- and secondary-age students on both Linux and WinNT platforms. Not a single issue has yet arisen due to students playing around with settings, in over four years. I personally find that very interesting -- and I doubt it would be that simple in most places. Certainly from my experience, just leaving it like that would be a recipe for disaster.
My experience has taught me otherwise. In addition, I have heard many more tales of problems caused by locked-down systems than I have heard tales of problems caused by systems left 'open'. (Obviously I'm talking about just the user interface here, not the underlying system security). It's probably worth noting that I try very, very hard to ensure that users are never forced to deal with any setup or configuration issues themselves. For example, at one large WinNT/2000 site we have made it possible for users to transparently move between Netscape 4 and Netscape 6. This is something that the Mozilla authors don't seem to have envisioned - NS6 provides only a one-way migration path from NS4 - but it's necessary for this site because there are several hundred roaming users and we don't want to upgrade all 200 workstations simultaneously (even using Ghost). It took about a day to hack round the various incompatibilities, but now users can simply start Netscape and have all their mail folders, bookmarks, settings etc. available without worrying about which version it is. My view is that if users have to do anything other than (double-)click to start up an application, then this should be viewed as a bug. This is one of the major gripes I have with programs such as KDevelop that go through an extensive setup routine the first time the user runs the program. A user interface that requires you to just repeatedly click on "Next" shouldn't be there!
For the record, and because it's mildly relevant to this discussion, we are currently creating a policy-type configuration tool. The idea is that you don't bother to configure any individual computers on the network (even servers); instead you create configuration rules from which every computer can derive their configuration. For example, you create a rule that says "the proxy server is SERVER1". From this, SERVER1 knows that it must install and start up Squid. Simultaneously, all the other computers on the network know that they must set SERVER1 as the proxy server for all installed browsers. Please note *all* computers and *all* browsers: this rule would apply to Konqueror, Netscape, Galeon, Opera, MSIE, lynx, etc. - the same configuration rule applies to multiple different pieces of software across multiple platforms. Sounds like a very interesting project. I look forward to trying it out :)
I'll send a single mail to the list when something is uploaded. The base functionality is already there, including a very neat trick that correctly resolves circular references between configuration rules[1]. I'm now thinking about the problem of how machines (in particular newly-installed machines) could identify themselves in order to work out which parts of the rule sets should apply to them. Harder than it sounds... [1] Note: "resolves", not "detects". It's easy to detect a circular reference and just abort: the trick is in working out how to abort only when the circular reference doesn't have a valid, stable solution. (i.e. "x=x" can have a solution whereas "x=!x" cannot). Michael