Don't let the spin fool you. Microsoft have agreed to extend the "end of shelf-life" date for Windows XP for another 5 months because people are just not buying into Vista in the way they hoped.
This is an embarassing climb-down for Microsoft, and one that I think has been forced by OEMs and resellers who are worried at slow sales of new hardware. This priceless quote from the head of PC World, a large UK retailler, sums it all up perfectly: "Gross margins have been materially impacted as a result of increased
promotional activity to reduce one-off hardware stock levels that
resulted from lower than expected demand for Vista products." Bit of a mouthful, but fairly clear anyway: Vista just ain't selling, and stores are left full of unsold kit that they expected to shift off the back of the Vista release.
Some of you may recall this has cropped up before, with my previous post about Dell taking the decision to start selling XP again after initially shifting their efforts onto selling just Vista systems outlining much of the problems that are just cropping up now. I've met very few people who have much good to say about this operating system. Some of this criticism is undeserved, with a lot of complaints based on believing everything slashdot claims or on an unwillingness to try and learn new things, but there is no doubt that Vista does have problems. Driver support remains erratic, performance is awful in terms of "desktop experience" for the user no matter how well it performs in benchmarks, compatability is a crapshoot, and Linux and OSX just keep looking better and better all the time.
In his excellent book, "In Search of Stupidity", Merrill Chapman talks about the mistakes IBM made with the release of OS/2. I won't reprise the entire chapter here because that's probably illegal and I regard the money I spent on the book as money very well spent so I think you should buy a copy too. But to cut a long story short he talks about the mistakes IBM made that ceded the PC OS market to Microsoft Windows. Let's see now, he talks about dropping and adding features that offer no obvious advantage to the end-user, horrible delays and re-engineering of the project due to muddy thinking, and a bloated operating system that performed very badly on the hardware that was around when it was first released.
Hmmmm. It's deja-vu all over again!
The question is, what will you do when your home computer or your business needs an upgrade. I think everyone who reads the archives on this site can figure out my opinion pretty quickly so I won't keep repeating it, I'm more interested in what you are going to do. Is Windows Vista the victim of bad press and people who won't give it a chance, or will it soon have to be renamed "Windows ME harder"? Will Leopard finally herald Apple Mac returning to the "mainstream" PC landscape? Can the Linux community even give away an alternative to Vista?
Whatever happens, it's pretty clear that a few old established orders are under attack at the moment, and possibly from the worst possible direction too: from within.
As you can maybe see, the time was spent wisely upgrading to the newest version of the blog software.
I'd love to pretend this was a planned upgrade, but the incentive to get this done was a stupid mistake on my own part that led to the site being knocked off line. I just figured that while it was off anyway I might as well make the best of it.
As ever, thanks to the wonderful and patient support team at WebHost4Life for putting up with my idiocy and helping me get this fixed, and thanks also to the community server team who have produced a nice and very pretty upgrade to their blogging software
In the cases below I’m talking about commands that can either be run natively by the operating system, or (in the case of Windows at least) are available as free addons.
Windows
Remember that Windows commands are case INsensitive, e.g. "PING" and "ping" are the same command.
pathping –
Effectively performs a tracert from your current computer to the destination computer specified in the command line, notes all the nodes found in the tracert and performs a ping on each one of them, allowing you to assess the speed of the connection you are using and spot which nodes are slowing things down. This can be considered an implementation of the Linux mtr command, which sadly isn't listed in the section below because it isn't natively a part of the UNIX tools in OS X.
nslookup –
Allows you to query a DNS server from your workstation. Very useful for modern TCP/IP networks where you need to see how a workstation finds things in its little world or how things in this world might find it! A classic command that has been around forever in UNIX circles, and the fact that this was such a relatively recent addition to the windows CLI underlines how much of a joke the Windows shell has been up to now when compared to... well... just about anything else really.
NET –
A very powerful command, if somewhat clunky to use, that provides access to quite a lot of the way a Windows machine manages its own user security and its relationship to the rest of a domain network.
Using variations of the NET command you can
- Create and manage user accounts, add your newly user accounts to groups and set properties such as passwords (NET USER, NET LOCALGROUP, NET GROUP).
- Mount network drives (NET USE)
- View and manage shares on the workstation (NET SHARE)
- ... and many more! The NET command is often a difficult command to use once you get beyond the basics, but it really is shocking the amount of times I've had some obscure NET command that was written for LAN Manager years ago pull my butt out of the fire on a modern server!
netdom –
Allows you to join a domain from the command line, manage trusts between domain member workstations and domain controllers and between domains. Part of the Windows server support tools. On the one hand this is a really boring command, on the other it's probably utterly vital to anyone building workstations for a domain-based network who needs to script the building process rather than use the automated options in the OS setup.
Note the lack of space between NET & DOM; netdom is not a subset of the NET command above.
netdiag –
Allows you to view a quick snapshot of the state of basic network settings and network configuration on a PC in a domain and is very useful for those “Can’t see the network” type of calls. Part of the Windows server support tools. Note the lack of space between NET & DIAG, this is not a subset of the NET commands above.
dcdiag –
Allows you to view a quick snapshot of the state of basic domain settings and domain configuration in a Windows Server 2000 (or higher) domain. Very useful for those “I can see the network but it takes half-an-hour to login” calls or when you suspect one of your domain controllers is in the pouts and is refusing to talk to the other domain controllers because they’ve had a falling-out over their MySpace page comments or something.
mstsc –
Arguably a bit of a silly little command to have in a list like this but I find myself frequently running it from the command line rather than from my start menu. This is partially because I always have a command line window open at work and typing “MSTSC <ENTER>” is quicker than navigating to the shortcut (yes, it’s pinned to my start menu shortcut area before you ask!) and partially because I tend to use some of the more useful parameters for terminal server such as /span to match up desktop sizes or /console to grab the console window on the server rather than create a new session.
mstsc /console, grabbing the console window on a server or workstation is especially useful, in particular with some applications and desktop interfaces to server services that just don't want to play nicely with multiple terminal sessions open on one machine.
Apple Mac / UNIX
These are all UNIX type commands based on Mac OSX 10.4.10. As always, you should double-check what you’re doing before running any of these commands on any other kind of Unix. (Actually, I hope you’d make sure you understood what was being suggested before you followed any advice you read on my site, or pretty much anywhere else on the Internet for that matter.)
Remember that UNIX commands are case sensitive, e.g. "PING" and "ping" are not the same command.
top –
top presents a dynamic view of running processes on your system ordered by CPU use, together with a summary of the resources being consumed. This is incredibly useful if you want to see if a process is active, or (probably more likely actually) you want to see which process has decided to crash and consume all your CPU cycles and free memory, in order that you might kill (see below) it. For a non-dynamic list of running processes, consider the ps command instead.
kill –
This is how you force a process to quit in UNIX. Most often associated with forcing a hung program to quit (kill -9), kill is a signal to a process to quit which has a number of levels from forcing a quit (-9) to asking the process to stop what it’s doing and bring things to a halt as soon as it can do so in a tidy manner (-15).
Those of you who have actually been reading my past ramblings may remember that I mentioned these commands in the article I wrote after getting my first Mac. Something had hung on my new iBook and I was unaware of the Mac-specific methods of finding and force-quitting the hung process, so I actually used both the commands above to find and kill the faulty process. I think it was called “Finder” and I was quite surprised at what happened when I killed it.
rsync –
A command that is very useful for copying data from one computer to another in a very efficient way, and to keep these multiple locations synchronised so that actions that take place in one location are mirrored to the other location. Also see psync if we’re talking Mac-specific. Also see scp and rcp.
dig –
The replacement for nslookup on modern Unix (nslookup still works fine on my mac though). I tend to prefer the way dig formats its replies to queries compared to nslookup but at the end of the day this is really a matter of personal preference for most people.
One thing that might dictate your choice is if you plan to 'pipe' the output of your DNS query into another command, obviously you'd want to use the command that produced the most suitable output for the command you want to send the DNS information to.
alias –
A way of creating a “shortcut” to a command, including adding the default parameters that you always want to use with a command. Let’s say that you’ve heard about my BOFH style habit of tricking people into doing bad things with the ‘rm’, ‘cp’ and ‘mv’ commands to delete, copy or move files in Unix and you want to make sure that you don’t get caught out by this while playing around with a Unix or Apple tip suggested by me, you might specify an alias for the rm command that automatically turns on the interactive prompt mode (e.g. asking “are you sure” before deleting a file) with the alias command: alias rm=’rm –i’.
Many people would argue that this is a very good idea when doing just about anything at the command line if you’re logged in as root.
Remember, alias means never having to say “I’m very sorry boss but I appear to have deleted the irreplaceable files containing vital financial information.”
lsof –
Trying to find which process has locked a file? lsof is your friend, generating a list of open files by process that is holding them open. Now this is where it gets interesting; to appreciate just how powerful lsof is in unix you need to remember that just about everything on Unix is represented as a file... Including directories, open network ports and so on!
Try the command lsof –i|grep TCP to run the lsof command and to use the grep command to search the output of the lsof –i command for entries containing the line TCP to get a list of open TCP port connections on a machine, repeat with lsof –i|grep UDP to do the same for UDP connections.
Or to search for references to a folder, say /usr/bin, try lsof |grep /usr/bin – remember the grep command and the pipe character “|”, while not part of my list here these are very important parts of working with Unix at the command line.
man –
Shows the manual page for many UNIX commands. Arguably a bit of a lame end to my list of UNIX commands but then this is an important tool where the options and switches for some commands can be far too numerous to possibly remember. Remember, closing your eyes and guessing only looks cool in the movies, out here in the real world planning what you need to do then doing what you’ve planned to do is what wins the day.
It seems to be some kind of universal rule that the moment I describe a post here as "Part One" intending it to start a series, something happens to drag my attention away or make the issue irrelevant *sigh*. Still after a long time waiting, this is part 2 of my comments and thoughts about disk fragmentation and the defraggers that just love to tame it.
In part one, I talked about how you can't measure how well defraggers work against one another very easily. Claus Valca wrote a nice article about defraggers over on Grand Stream Dreams where he talks about ways the process can still be valuable and asks about ways of evaluating the different products. I can think of one way of comparing different products, but while it's honest and fair in terms of what it tests, it probably doesn't answer all the questions you should be asking on the subject. Still it's a start right?
Just to make things clear, I'm using the definitions of File System Fragmentation and Defragmentation found on Wikipedia. I'm not claiming those definitions are perfect but they're at least as good as any I could write myself and they already exist.
The Test
Pick a 'neutral' program to measure the level of fragmentation. For the purposes of this test, the results of analysing the disk with this program will be the only results that are used to compare one product to another.
Decide if you want to do a file-system 'performance' test. If you do, I suggest copying lots of files of varying sizes onto the disk or partition you are using for your tests for this part of the test regime. Try to make sure that the source medium that you grab the files from is fast (because you don't want it to be the slowest point of the test, because you're not testing the speed of the source) and performs consistently (because you want a fair test, right?). Yes, this will be quite difficult to achieve.
Some drive imaging programs allow you to take a "raw" backup image of a disk partition or even of an entire hard disk. I'm linking to Acronis True Image's FAQ here as an example of a product that I'm comfortable with and which offers the facility, though there are other choices out there.
Using such an imaging system, you can create a backup of a test computer's hard disk after you've set it up in such a way as to leave it fragmented enough for your tests.
If you're performing this test on Windows Vista, disable the built-in defragmentation routines NOW, before you do anything else.
For such a test I'd suggest using a relatively small hard disk and creating fragmentation by installing lots of programs and copying large files (got a couple of Linux ISOs doing nothing in your archives?) around the disk, then un-installing some of the programs and deleting some of the images. Considering that NTFS does try to avoid disk fragmentation in the first place you may actually find this bit to be the most difficult part ;-)
Once this is done, ensure that things are set up how you want them, and then disable any 'automatic update' routines for the OS, applications, antivirus, etc. This is very important because you want to ensure as much as possible that what you're measuring in these tests are changes made by the defragger and not by anything else; it's hardly a fair test if windows update downloads and installs an extra 100Mb of patches halfway through one of your test rounds, or if the virus scanner decides that now would be a great time to open up every single zip, rar and jar archive on your disk and do a deep scan of their contents.
If the partition / disk you're testing does not include the operating system you're running the tests from, you will need to 'clean' the OS between each test to remove one defragger before you test the next. The only reliable way to do this would be with taking an image of the operating system before the start of the tests and replacing the OS between each test round.
I suggest two rounds for each product - A simple dumb "file defragmentation" pass where the simple basics are compared, a "like for like" comparison of the basic ability of each product to shuffle a pack of files on your hard disk - this round will probably be rather boring as you'd expect competent products to all perform to a high standard with the simple stuff. I'd then suggest another pass where each product gets to strut its stuff with all the fancy options turned on.
What are you testing? Ensure you understand the products you are testing. If a particular product works in a substantially different way from others (AShampoo's Magic Defrag and Vista's own built-in defrag spring to mind here) then how can you compare it to other products in a meaningful way? If you test a product by a set of rules that don't suit it then you've tested your own ability to evaluate these products and failed badly.
That seems like a lot of work. Is it worth it?
My personal feelings are that for most people, all that stuff above is far more effort than it's worth. Without all that and probably a few other things too, you're not doing a fair comparison of different defrag tools. To be honest, unless you've got specialist needs then you probably don't need to defragment your disks too often these days, as Claus says, it's still important but no longer vital, as it used to be.
Given my previous poor record for following up posts in a timely manner I may be tempting fate saying this, but in a 3rd part to this series I'm going to try and address a few final points, in particular specialist defragmentation requirements.