Windows 10: First Laptop
As anyone that has read my previous postings, or talked to me on the topic, my general dislike of Windows 10 should be obvious. Despite that, I recently started using it regularly.
It was time to get a new laptop, and I decided it was more effort then it was worth to NOT get one with Windows 10. Which meant I found myself in the position of setting up a Windows 10 system for my own usage. While mostly the same as setting it up for someone else, a task I have done enough times, it is also slightly different. These differences led to some learning experiences. In particular, I learned more about three things: updates, encryption, and networking.
Updates
While I go into more detail elsewhere, put simply I find a system that changes (ie updates) itself on it’s own to be an unacceptable usage environment. I need to be able to know things are stable (or at least known in their instability) in order to get work done. Thus, with Windows 10 I needed a way to stop updates, indefinitely. Through the TinyWall firewall I was able to do that.
And to be clear, updates are a good thing (generally speaking at least). It’s more of a stability issue. Updates happening at unexpected times will break things (see below). So the solution is to take control of the updates, stopping them until it is an appropriate time.
Having my own Windows 10 system gave me the opportunity to put theory and ideas into practice, to find what actually works.
Encryption
For a variety of reasons, I encrypt my hard drives. If nothing else, so that I know the data on them is safe if they were to ever ‘walk off’ without me. On Windows 10, I use VeraCrypt for this. I am aware of BitLocker, but Microsoft has shown they consider me a product, not a customer, so I can’t count on them to protect my data. Veracrpt on the other hand, is open source, has been audited, so is more likely to be trustworthy.
Where I learned something was when I did an update and it broke the system. Some part of the update clashed with VeraCrypt, and it wouldn’t mount the system. So I stuck in the Rescue Disk and used that to start it up. Which is why you follow the directions when encrypting your drive, and actually make the Rescue Disk.
The actually process was straightforward enough, just something I hadn’t done before. Used the recovery option to get back into the system, then told it to decrypt the drive. Followed by applying the update to Windows, and re-encrypted the system. Problem solved, less learned. Allocate a day or two for updates (just to be safe), so do them infrequently. Which was the plan anyways (see above).
Copying
I have a large amount of data, or at least large enough copying it from the ‘old’ system to the ‘new’ one was an issue. And while the regular Windows copy option is nice, and has it’s uses, I decided it wouldn’t have worked well here. So I used Robocopy. And in the process, found a limitation it had.
On the setup I had, Robocopy was only using ~20% of the available bandwidth. While I didn’t find a conclusive answer as to why that was, I did find a work around. In particular, the /MT flag. This tells Robocopy to use multiple threads. In other words, copy more then one file at a time. So while each file was limited to ~20%, if it’s doing 5 (or more) it would use it all.
I’ve since used this in a variety of other places. Has definitely been useful knowing.
Learning
While none of the above is that amazing, they were all good things to learn. And goes to show, that as much as any of us may know, there is always more that can be learned.