|Home » News » Roundups » 29 Reasons to Not Get Vista
29 Reasons to Not Get Vista
Microsoft Windows Vista hits (assaults) consumers on 30 January 2007. Starting with New Years Day that gives you twenty nine days to think about the big mistake you're about to make.
Every day of January 2007 until Microsoft Windows Vista is released you can read yet another good reason why it's not a good idea to get it.
11 January 2007 Reason #11: It's a 'standalone' system.
As Eric Raymond so eloquently pointed out in his study of comparative operating systems, Windows per se isn't really an operating system at all - it was originally called a 'disk operating system' instead. Because all it did was operate disks, not users, processes, or anything else.
This of course stands in stark contrast to what were originally called 'operating systems' but today are often referred to as 'server operating systems' to differentiate the quality products from the rubbish.
Once upon a time - before Microsoft - all operating systems were server operating systems. People didn't have 'local intelligence' on their desktops. They had 'dumb terminals' with maybe 2 KB of RAM - just enough to feed a screen.
Keyboard commands fed into the computer itself which was normally located in another room behind a locked door and the replies came back along the same wire.
Because everyone connected to the same physical computer it was necessary to establish a modicum of order on that computer. Everyone would be running programs at the same time, for example.
[It's not uncommon for IBM mainframes to have several thousand users logged in at the same time running programs. That takes a lot of order.]
Contingencies like this require a whole different way of thinking - a way of thinking which once upon a time permeated the industry. Resources such as printers and tape stations had to be shared; requests for access to these resources had to be queued; processes waiting for one of the CPUs had to be queued; processes had to be 'sliced' in and out of the CPUs continually; and so forth.
It was also necessary to apportion parts of the physical disk to the different users and different system tasks. Users who logged in would find themselves placed in their very own home area with little opportunity to venture beyond and poke their noses into what other users were doing.
And the system itself would make sure that no user - and very few system processes - would be able to poke around in areas used by the system - after all, the welfare of the system and its users hung in the balance.
You can't exactly have a badly hacked program run by one user suddenly bringing everyone else crashing down, can you?
It was this kind of thinking - coupled with the reminder that these computers were being used primarily by business and science and so therefore must be extremely stable - that led to the failsafe foolproof policies used in creating 'server operating systems'.
Unix is such a server operating system, and from a user's perspective has meant a lot for personal computer users almost from the get-go. But Unix retains key elements of 'server operating system' architecture, a few of which can be used to illustrate the gaping difference between what is and what should be on Windows.
The original authentication file for Unix was /etc/passwd. It contained all the information the login process needed to figure out what to do with people attempting to attach from a terminal.
www:*:70:70:World Wide Web Server:/Library/WebServer:/noshell
sshd:*:75:75:sshd Privilege separation:/var/empty:/noshell
Each line is an entry for a (potential) user on the system. The fields of each record are delimited by a colon (':'). There are seven fields all told.
|Username||Actual account name (used to log in).|
|Password||DES-encrypted password (actual password is never stored on disk).|
|User ID||User's unique user ID (as number).|
|Group ID||User's unique group ID (as number).|
|GECOS||Field used for arbitrary descriptive information.|
|Home||File system path for user's home area.|
|Shell||Path to user's 'shell' (command interpreter).|
It's the last two fields - 'Home' and 'Shell' - which are significant. For on any server operating system worth its name each login user has a specific area to go to - an area that is proprietary to that user and that user alone.
A Windows login by contrast, although it will lead you to your own 'desktop' (which is really your 'own' desktop normally) doesn't drop you in a proprietary area. On Windows there are no user proprietary areas - Windows is a 'standalone' system.
By 'standalone' is meant a system - a computer - that is meant to 'stand alone' - a computer that by design is not ready to be connected to other computers or used by multiple users - where in essence the computer's resources cannot be properly shared.
It's no coincidence that the IBM mainframe interactivity facility is called 'TSO' - 'time sharing option' - or that Unix first was described in the famous Thomas J Watson paper as a 'time sharing system'.
But Windows was originally MS-DOS - 'Microsoft Disk Operating System'. It was a disk operating system: it managed the disks in a computer and no more. It didn't handle interaction with other users and other computers. You were the computer's only user but simultaneously anyone was the computer's user.
All server operating systems of course have means of letting you into your own proprietary disk area and keeping others out. The Unix system is perhaps easiest to explain.
File attributes (modes) which apply both to ordinary files and directories describe read, write, and execute rights for file owners, groups, and everyone else.
They're normally expressed in three groups of three characters with a 'r' for read access, a 'w' for write access, and an 'x' for execute access.
Thus the header above - 'rwxrwxrwx' - gives full access to everyone for the item to which it refers.
But if you wanted to lock other users out from one of your files, you'd simply change the access rights to 'rwx------' - where the six trailing dashes mean 'no rights for anybody else'.
You could also let your friends in your special group read your file (but disallow anyone outside your group access to it). In such case you'd use the access rights 'rwxr-----'.
And so forth. And what pertains to you the user also pertains to the system. And here too is an important difference between a real (server) operating system and something like Windows: for the system itself - in perhaps several incarnations - can 'own' parts of the file system and effectively keep even you locked out.
If you look again at /etc/passwd you can see two users which potentially can be regarded as part of the system proper: root (the superuser) and daemon. And yet these two 'users' are not equivalent. And between them there is a tangible security granularity.
Windows & VMS
Windows is based today on an operating system from Digital Equipment Corporation called VMS. VMS was a true server operating system but Windows is not. Why?
Despite its heritage Windows is not and can never be the true server operating system VMS was because Windows must cater to 'legacy' issues dating back to the days of MS-DOS. The most prevalent file system used on Windows today is still the archaic 'standalone' file system used with MS-DOS and it has no means of limiting access at all.
[The 'read-only' file flag is mere 'speed bump' that can be removed without authentication; the MS-DOS file system cannot prevent anyone from just 'reading' a file.]
Windows & NTFS
Windows does offer a new file system called 'NTFS' - 'NT File System' - but even if this file system is used instead - which it isn't more often than not - it can't afford the same ease of use in setting proprietary boundaries for file access.
The NTFS security system is deliberately 'opaque' (hard to get at and manage) and was originally designed for use on a 'file server' where an administrator could set things up in peace and quiet - it's not meant for use in an active user workstation environment.
The goal for an ordinary user of both assessing file privileges on a per-file basis for thousands of proprietary files and maintaining an effective overview of the overall security situation is unattainable.
Where Calamity Hits
Microsoft products such as Internet Explorer and Outlook are often cited as the cause of the countless inexcusable miseries Windows users suffer through today. Malfeasant software attacking Windows systems attacks these programs.
But even though this is evidence of substandard software production on the part of Microsoft, it's not here the fault lies.
For any software product may have a 'bug' which can be turned by a hacker into an 'exploit'. What matters is what the hacker is able to do once the exploit is running.
That's where calamity really hits on Windows - because Windows is 'standalone' your computer is 'wide open'.
This would never work on a real operating system. Exploiting a software bug would net you very little (if anything at all). But because Windows has no internal barriers (defenses) anything goes - and it goes anywhere.
Over the years Microsoft have paid a lot of money (millions) to get 'security classifications' for their Windows - 'Orange Book' classifications - primarily so they could sell to government offices.
But those classifications deceive. On each and every one (if you read the fine print) you'll see that the tests preclude the presence of interlopers - in other words the tests by definition do not consider the possibility that trojans, worms, viruses, or spyware can attack the computer.
And considering that an estimated 90+% of all Windows computers are running with an average of thirty (30) trojans, worms, viruses, and spyware programs at any one time, that's a heck of an assumption.