Vista as a multiple-user system?
My friend has recently become the proud new owner of a Windows Vista "Ultimate" box. Naturally, I have been getting him to let me try a lot of different things to see whether it's good enough for me to make the switch.

There are some interesting ideas floating about in vista, but it's still not even *close* to being a secure, multi-user operating system. (note that it may be possible to make vista into a secure, or multi-user system, but I doubt you can do both at the same time)


The statements below are my justification for reaching the above conclusion:

1) It's only a single-user-at-a-time system.
-- It has "remote desktop", but by default, it only lets one user on at a time. There are hacks available which let more than one user log in at the same time, but I expect they're illegal. He set up one of those hacks for me, so that I could play about with his computer and find more things that are crap about it.
-- On most unices, "ssh" lets you optionally specify a user limit, but it defaults to letting infinite users connect concurrently.

2) It is very difficult to do things as a non-administrator user.
-- I was trying to install python in my user's home directory, and it seems that the .msi installers will run up to a point, and then a dialogue box comes up asking for an administrator password in order to run untrusted programs(or something). While this is probably good for large companies, in that it reduces the number of random games that can get installed, it makes no sense that the authorisation message was not displayed as soon as the installer started. It also seems to mean that all untrusted programs end up being run as an administrator (thereby making the system less, rather than more secure).
-- On unix systems, any file can be made executable by changing its permissions to include "execute". It is possible on unix systems to stop users creating executable files (The way you do this varies from system to system, but in the worst case, removing/changing any programs that change permissions will work). In most cases, it is good enough to know that anything your user's program does can only affect his own files (which brings me on to my next point).

3) The file permissions and layout is shit by default
-- I was (I think) able to create a folder called C:\python25\ (the computer went down before I got round to checking it). If this is the case, then this is a Bad Thing. Imagine if everyone on the system decided to add folders to C:\. You could fill it up to such an extent that the administrator would have to wade through hundreds of irrelevant junk folders in order to find anything. Also, "Program Files" is a really shit name for a place to put things. Not only does it have a space in the name(which makes the automated creation of links in msn a complete pain in the ass), it's also suitably ambiguous that it invites itself to become a dumping ground of all the rubbish that any developer wants to install. In fairness, at least Alex's Dell has C:\Users\David\Documents rather than C:\Documents and Settings\David\My Documents. Seems they've taken a leaf out of Apple's book on that count.
-- There exist unix specifications including a recommended set of locations for files and folders. They also tend to specify that users by default only have write permissions to their home directory and /tmp (which can be safely deleted each time the computer restarts). This means that all executable files are placed somewhere sensible (one of 4 locations for commonly used applications, so users can always find the application they're looking for). It also means that a user of the system can't be malicious to anyone but himself (see point 2 about executable programs).

4) You are encouraged to be administrator to develop programs.
-- Even the MS official development environment won't work as a normal user! One in three items on the "known bugs list" translates to "Sorry: you can't do that as a normal user" (see http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx for details). This basically destroys any attempts to make Vista into a multi-user operating system, because program developers will always have to make their programs as an administrator. Yes, it's possible to *test* programs as non-administrator, but that's extra effort for the developer. It also means that you can't have multiple developers on the same system, because if one person does something dramatically stupid: it is done as an administrator, and therefore has the potential to create chaos for all other users of the system.
-- On Unix systems, many developers who have root access to their own machines create new users for any large project they work on. This is the suggested development model for the KDE project (see http://wiki.kde.org/tiki-index.php?page=KDE3To4 for details) as all unrelated projects can then be completely isolated from one another, on what looks like an untouched system. It is therefore very difficult to completely destroy a system by accident. It also makes it easy to track what software needs to be installed as a dependency for each project. Obviously, there are still some projects which need to access hardware directly (like Xorg, and the Linux kernel), and these do sometimes end up with computers needing a reboot, but these are the exception rather than the rule. Also, these are the kinds of projects which simply don't exist as "enthusiast's projects" for commercial systems, because the OS/hardware vendor is responsible for ensuring that such things work.

I think this is all I have to say. I'm sure that people will post work-arounds for each point, and eventually, it may be possible to generate a single executable shell script which will turn a stock vista system into a usable multi-user operating system, but until then, I think we're stuck with either one-user-per-machine, and spending the necessary sums of money on hardware, software and power for each distinct machine, or sticking to unix-based machines like linux.pwf and pip.srcf, which are secure, multi-user systems by default.