Windows and Linux are not the same

We like to think that operating systems are commodities, that Windows performs just as well as mac OS, and they both perform as well as Linux. I'm not sure about mac OS, but I can think of one significant difference between Windows and Linux, and that difference may affect the lifespan of the hardware.

Specifically, the difference in Windows and Linux may affect the hard disk drive, when it is an SSD (solid state disk). SSDs have a limited lifespan, in the number of reads and writes. This is important because Windows and Linux show different behavior with disk activity.

My experience is that Linux has minimal disk activity. Linux loads, creates a login session, does a few more things (I suspect that it runs 'apt' for an update) and then sits and waits. No disk activity.

Windows is quite different. It loads and creates a login session (just like Linux). But then it keeps doing things. Computers with disk activity lights show this activity. (Is Windows downloading updates from Microsoft servers? Checking for malware? I don't know. But it's doing something.) And it does this for at least 30 minutes.

That's before I log in to Windows, and before I launch any applications, or check my e-mail, or visit web sites.

After I log in, Windows does more. One can see the disk activity (on PCs that have status lights). When I check the CPU usage (as shown by Task Manager), I see lots of different tasks, many with vague names such as "Local Service".

Not all of this is caused by Microsoft. My work client has supplied a laptop that runs Splunk, McAfee, and a few other third-party applications (all installed by my client) and they wake up and do things every few minutes or so. All day long.

The immediate thought from this disk activity is: this cannot be good for SSDs. Each read operation and each write operation chips away at the lifespan of the SSD. (Old-style spinning hard disks are much less susceptible to this effect.)

The constant activity in Windows means that Windows will "consume" an SSD much quicker than Linux.

I certain that Microsoft is aware of this issue. I'm guessing that there is not much that they can do about it. Windows was designed to run lots of tasks on start-up, and throughout the day. (Also, it's not really Microsoft's problem. The fact that Windows "burns out" SSDs means that people will replace the disks, or possibly replace the whole PC. People will view this problem as a problem of hardware, not a problem with Windows.)

I tend to keep computers for a long time. For computers that run Windows, I look for systems that use the older hard disks and not SSDs. That's my strategy. Let's see how it works!

To fragment or not fragment, that is the question

First there were punch cards, and they were good. They were a nice, neat representation of data. One record on one card -- what could be easier?

Except that record sizes were limited to 80 bytes. And if you dropped a stack, and cards got out of sequence.

Then there were magtapes, and they were good too. Better than cards, because record sizes could be larger than 80 bytes. Also, if you dropped a tape the data stayed in sequence. But also quite similar to cards, data on magtapes was simple a series of records.

At first, there was one "file" on a tape: you started at the beginning, you read the records until the "end-of-file" mark, and you stopped. Later, we figured out that a single tape could hold multiple files, one after the other.

Except that files were always contiguous data. They could not be expanded on a single tape, since the expanded file would write over a portion of the next file. (Also, reading and writing to the same tape was not possible on many systems.)

So we invented magnetic disks and magnetic drums, and they were good too. Magtapes permitted sequential access, which meant reading the entire file and processing it. Disks and drums allowed for direct access which meant you could jump to a position in the file, read or write a record, and then jump somewhere else in the file. We eventually moved away from drums and stayed with disks, for a number of reasons.

Early disks allocated space much like tapes: a disk could contain several files but data for each file was contiguous. Programmers and system operators had to manage disk space, allocating space for files in advance. Like files on magtapes, files on disks were contiguous and could not be expanded, as the expansion would write over the next file.

And then we invented filesystems. (On DEC systems, they were called "directory structures".) Filesystems managed disk space, which meant that programmers and operators didn't have to.

Filesystems store files not as a long sequence of disk space but as collections of blocks, each block holding a number of bytes. Blocks added to a file could be from any area of the disk, not necessarily in line (or even close) to the original set of blocks. By adding or removing blocks, files could grow or shrink as necessary. The dynamic allocation of disk space was great!

Except that files were not contiguous.

When processing a file sequentially, it is faster to access a contiguous file than a non-contiguous file. Each block of data follows its predecessor, so the disk's read/write heads move little. For a non-contiguous file, with blocks of data scattered about the disk, the read/write heads must move from track to track to read each set of blocks. The action of moving the read/write heads takes time, and is therefore considered expensive.

Veteran PC users may remember utility programs which had the specific purpose of defragmenting a disk. They were popular in the 1990s.

Now, Windows defragments disks as an internal task. No third-party software is needed. No action by the user is needed.

To review: We started with punch cards, which were contiguous. Then we moved to magtapes, and files were still contiguous. Then we switched to disks, at first with contiguous files and then with non-contiguous files.

Then we created utility programs to make the non-contiguous files contiguous again.

Now we have SSDs (Solid-State Disks), which are really large chunks of memory with extra logic to hold values when the power is off. But they are still memory, and the cost of non-contiguous data is low. There are no read/write heads to move across a platter (indeed, there is no platter).

So the effort expended by Windows to defragment files (on an SSD) is not buying us better performance. It may be costing us, as the "defrag" process does consume CPU and does write to the SSD, and SSDs have a limited number of write operations in their lifespan.

So now, perhaps, we're going back to non-contiguous.

Tennis, anyone?