Windows in Slow Motion

 I was reminded this last week of why I don't use Windows on my home computers.

Background

I had to get a somewhat older (probably about 6 years old) laptop up and running to be available for a training session at work. This was a laptop which had originally come with Windows 7 Professional (right when it first came out). At the time, however, we did not use Windows 7 in production yet (of course), so we had reformatted the drive and put Windows XP on the machine instead. It was in service as a Windows XP machine for about five years (perhaps a little more).

This machine sports a Core 2 Duo processor, 3 GB of RAM, and AMD graphics. It had a Windows 7 image that was recently put on it by a coworker, but didn't work right (ran very slowly and crashed a lot) and was 32 bit. So instead of trying to re-install that image (remember that our regular use images for this model were XP), I decided to re-install Windows 7 Professional 64 bit from scratch.

Hardware problems first

The first issues I had were no fault of Windows. I installed Windows 7 Professional from disc, using the license key that was included on a sticker on the laptop. It worked with no issues. I had to go out to the Internet to grab drivers for the storage controller, the touchpad, and the extra keyboard buttons (the last one not being critical). All the other important drivers were included with Windows. Just when it seemed all was going well, I got S.M.A.R.T. errors warning me that hard drive failure was imminent.

Back to square one

I now had to locate another suitable hard drive, which was not too much of a problem. There was another drive hanging around the office of the same size which had been removed from another laptop. I re-installed Windows 7 Professional 64 from the same disc I had used before and got back to the point where the old hard drive had begun to fail.

Update issues

Windows seemed to be working rather well. However, my next task was to try and get the updates going. This is where I ended up having issues. Windows 7 gets the updates that our system administrator releases for it, which is generally all the updates that Microsoft releases after they are evaluated and cleared by him for use in our Windows domain. On it's first check for updates, Windows found 224 that had to be installed. I started the updates and left the machine alone.

The machine progressed normally through the updates for quite some time. It took longer than it seemed like it should to someone who is used to updates on a Linux machine, but I was expecting that. Finally, several hours later, it got to 217 updates, and started having issues. It started giving low memory errors (remember that this is with 3 GB of RAM). It stopped making progress, slow as that may have been before, and I ended up asking it to cancel the rest of the updates. It took a long time configuring the updates that did complete, and even rolled back some of them, perhaps because related ones had failed, but I'm not sure.

The next day, when I came in and the machine was behaving normally again, I viewed the available updates. This time there were 222 (these were a few of the ones that had failed plus a lot of additional ones that hadn't been tried yet). I let it start again. It took a long time, but that is normal, for the first 204 updates to install. Then it started giving memory low errors while trying update number 205. I canceled additional updates again and waited for it to stop and give me another chance to reboot. It was the afternoon by now. Twenty-four hours later, it was still trying to finish or cancel (I'm not sure which) update 205.

I ended up having to hard boot the machine. Fearing that I might have to start over again and anticipating trying to let only one hundred or so updates be applied at a time, I waited for it to come up. Fortunately, after only a warning that it had not shut down properly, it came up normally and configured updates for quite some time before giving me the log on screen. I needed it to work the next day, so I prepared it for the training session without approving any more updates.

Sanity returns

As it turned out, our system administrator did not want to take a chance that there was a problem with this machine, and they used another laptop for the training. I took the one I had been building and checked the update status. This time there were only 35 updates waiting (the failed ones plus just a few). That small amount of updates finished without a hitch, and the laptop was fully up to date after a three day ordeal.

I have my suspicions that part of the issue may have been the machine downloading Windows 10 in the background, even though the upgrade offer is disabled by group policy. I'm not sure about this, however. In any case, I don't expect machines that are updating to use all three gigabytes of RAM and hang up every time there are more than 200 updates installed. Even if updates had gone smoothly, it would have taken the better part of two workdays for them all to apply.

I run Linux distributions with an Xfce desktop on both similar and older hardware than this, often with less RAM, and no significant issues. They feel snappy, and updates run well in much less time. After running Linux for a time, Windows generally makes me feel like I'm trying to walk through knee-deep mud. That's why it's so hard for me to go back to. There are nice things about it, but I feel restricted when using it.

Of Android Distributions and Linux Distributions

There seems to be a bit of controversy lately over whether or not Android should be considered "a Linux distribution."  The actual question cannot help but be somewhat a question of semantics.  However, a number of factors seem to be influencing people's opinions that don't really bear directly on the issue.  These factors seem to boil down to one thing really.  And that thing is that some people want positive characteristics of Android to be associated with Linux while others don't want negative characteristics of Android to be associated with Linux.

While I may address positive and negative aspects of Android at some point in the future, this blog entry is going to ignore them as irrelevant to the discussion of whether or not Android is a Linux distribution.  My viewpoint on this is that it is not really appropriate to refer to Android as a Linux distribution, for reasons that should become clear in a moment.

The question really comes down to defining "Linux distribution."  From a technical standpoint there are a few definitions that could make sense.  If that is all you are concerned about, then you can pick your position and be confident that it's supportable.  I'm more concerned about whether calling Android "a Linux distribution" is actually effective communication.

In the past the phrase "Linux distribution" has not referred to the kernel that is properly named "Linux."  If it were referring to the kernel, then it would have been applied to kernel releases themselves and not just whole operating system releases.  It seems pretty clear to me that in the past "Linux distribution" has referred to releases of the entire operating system that people generally refer to as "Linux" rather than simply the kernel.  This operating system has also been called "GNU/Linux" by some.  I'm not here to rehash that discussion.  If I refer to the operating system as "GNU/Linux" at any point, then that is merely to clarify that I am referring to the operating system and not simply the kernel.

Some seem to take the position that Android is not a different operating system than GNU/Linux, but just an additional layer on top of it, just as X is a layer often missing from Linux servers, but not constituting a server system a different operating system than a desktop Linux machine.  This is not the case with Android.  Why not? It is because the two systems are incompatible.  They operate on conflicting sets of libraries.  You cannot run GNU/Linux and Android in the same directory tree.  In order to run both on the same system, even if using the same kernel (which is possible), you have to somehow virtualize a separate environment for one of the systems (using a chroot jail, for example) or boot them separately using different root partitions.

Even if Android didn't run most applications on a virtual machine, applications would not be compatible.  You could theoretically develop a Dalvik virtual machine that would run on GNU/Linux in order to use Android applications (since that's what virtual machines are for), but GNU/Linux applications simply can't run on Android without being ported to it.

That Android is a different thing than GNU/Linux on the fundamental operating system level is reflected by the fact that there are Android distributions, like Cyanogenmod, Paranoid Android, and AOKP.

None of this is a knock on Android, and I don't consider Android a second class open source citizen (though I reserve the right to consider proprietary Android distributions as second class distributions :-) ).