One Reason I now Feel that the Linux Update Process is Stable

Back in past years, the habit I had had with my Linux computers was such, that I would not do a complete upgrade of all installed packages. Instead, I would often tell my package manager to install some new packages, and view the message it generated, according to which many packages were to be held back and not updated, as part of the new installation. I used to acknowledge this in general, and allow it to happen.

By contrast, I did notice how often Windows Update does its job, and how my Windows computers were never or seldom broken by a Windows Update. However, it had happened to me on occasion, that the Linux computers could get into some sort of stability issue, over upgrades I had done. And so I had reached the vague conclusion, that Windows Update was somehow better, than the habit of doing complete upgrades under Linux.

What I now have is two computers, on which all the packages I have installed are at their most recent version, due to the ‘unattended-upgrades‘ package which I have installed, and which I wrote before in This Earlier Posting.

What I now find, is that my Linux computers that are up-to-date, are at least as stable as my Windows 7 and Windows 8.1 machines, if not more stable. And so advice which I was once given but had ignored, seems to have been accurate, according to which my earlier practice of only upgrading a minimum of libraries, was a bad practice, and according to which doing so, introduced stability problems of its own.

Having said that, If we are given a Debian / Linux machine which requires upgrades to a large number of packages, let us say to more than 20 packages, then we effectively need to do a ‘dist-upgrade‘ to achieve that most reliably, and even then, this one-time action can fail, and can leave us with an unstable or broken system.



Windows Update no longer allows us to skip MRT.exe

When performing monthly updates, my Windows 7 computer ‘Mithral’, and my Windows 8.1 laptop ‘Maverick’, are also programmed by Microsoft, as usual, to run the “Malicious Software Removal Tool”, aka ‘MRT.exe’ . On ‘Mithral’, this scan takes more than 40 minutes, while on ‘Maverick’, this only takes less than 10 minutes. So what I used to do on ‘Mithral’, was to kill the actual process, ‘MRT.exe’, in the Task Manager, in order to speed along the update, while not doing so on ‘Maverick’, where I allowed the scan to complete.

I do not really need to be told once per month, that my computers are free of malware.

But starting with the most recent update, Microsoft no longer allows us to do this. When I killed the process ‘MRT.exe’ on ‘Mithral’ today, as part of an update that was a few weeks past due, my doing so was logged as an official Failure, of one of the components, in the Update History Log. This does not yet hinder operation of the computer, and we are allowed to run ‘MRT.exe’ ourselves whenever we feel like doing so. Thus, in order to make it up to the updater, for having killed the process prior to the restart, I ran ‘MRT.exe’ as an administrative user.

AFAIK, This move by Microsoft is part of an honest effort, to make our computers more secure.

But when I ran ‘MRT.exe’ manually, I discovered why the scan took 45 minutes on ‘Mithral’, that only takes 10 minutes on ‘Maverick’.

Apparently, when ‘MRT.exe’ does its Fast Scan, it finds issue with a software installation on ‘Mithral’, that is named “Crystal Space”. Crystal Space is an Open-Source 3D Game Development SDK, which should not contain any malware, and which I do not make active use of in practice. I custom-compiled it. But for some reason it triggers ‘MRT.exe’ into an alarm. In response to this alarm, ‘MRT.exe’ next proceeds to do an In-Depth Scan of the Crystal Space folder, which is what takes so long.

And then as a result of the In-Depth Scan, ‘MRT.exe’ actually determines that no threat was found. I know this because when we run ‘MRT.exe’ manually, it displays a nice little GUI, in which we can see its progress. It first thinks it finds infected files, but after the In-Depth Scan it displays that “No Malicious Threats (sic) Were Found.”

I have an observation about this behavior. The Crystal Space version I have installed on ‘Mithral’ is an old, archaic coding example. And sometimes, the way old code is compiled and linked can set off anti-malware software, without being malware.

In any case the GUI has answered a long-standing question to me, as to why this scan was always taking so long. Apparently, ‘MRT.exe’ was doing exactly the same thing, in past cases when I allowed it to complete.

And I do not have Crystal Space installed on ‘Maverick’.