Yep, I eventually uninstalled Snap & I’m much happier with my Ubuntu 20.04 now.
Who cares about operating systems anymore? Microsoft’s recent moves toward Linux, along with their emphasis on Azure, should make it clear that OS’s are diminishing in importance. (cf. Red Hat on Azure, SQL Server on Linux, Bash on Windows) Breaking with Steve Ballmer’s (misbegotten) approach to Linux, Nadella’s Microsoft realizes that Windows isn’t the center of their universe anymore (and can’t be considering their inability to convert desktop dominance to mobile devices).
Developer sentiment is another indicator. Fewer and fewer developers care about the OS. OS just doesn’t matter as much in a world of Ruby, Python, Node, MEAN, etc. This trend will accelerate as PaaS providers continue to improve their offerings.
OS’s aren’t going away, but their importance or mind-share is waning broadly.
We wanted to tinker with the Windows 8 Release Preview, so we tried to install it on our tinkering box. Having two tinkering boxes, we started with the trashable tinkering box — a Dell Dimension from mid-2005. Admittedly, we attempted this installation to see if “it will set the drive on fire.” We tend to throw crazy things at this Dimension, but it keeps on tickin’! Its spec are:
- Dell Dimension 4700
- CPU: Pentium 4 @ 3.0 GHz
- RAM: 4 GB (physical)
- Disk: 1 TB; > 750 GB free space
- Arch Linux; Kernel: 3.4.6-1-ARCH #1 SMP PREEMPT
- VirtualBox 4.1.18_OSE r78361
We created a new VM and hooked it up to the 32-bit ISO for Window 8 Release Preview. After starting the VM, VBox presents an error dialog stating:
VT-x/AMD-V hardware acceleration is not available on your system. Certain guests (e.g. OS/2 and QNX) require this feature and will fail to boot without it.
This dialog gives the user a choice of closing the VM or continuing. It’s the tinker box, so we chose to continue! Next the Windows logo appeared, so we got excited that this just might work. But, after just a couple of minutes, the installer died and gave this message:
Your PC needs to restart. Please hold down the power button. Error Code: 0x0000005D Parameters: 0x030F0304 0x756E6547 0x49656E69 ox6C65746E
Well, that’s clearly a bad result. We had no interest in even attempting to push past this kind of problem. Installing Windows 8 on our tinkering server (Windows 2008 R2, Hyper-V).
After some discussion, we decided that this configuration probably should not work. So, chalk this up to “Yep, we have demonstrated that what should not work actually does not work.” Hopefully no one else will be tempted to try Win8 on this kind of config, but maybe this will save them some time if they do.
We haven’t needed to implement a Windows Service in a while, but certainly have experienced the pain of debugging them when run by Service Control Manager (SCM). Here are a couple of links to good tools and discussion on the topic:
Run Windows Service as a Console Program by Einar Egilsson provides a good example of how to debug your service easily as a console app. It also includes some good discussion of single- and multi-service hosting services, various ways to end or break out of the service process when running as console app, etc.
Windows Service Helper on CodePlex is a SCM replacement which provides for F5 debugging from Visual Studio. The UI it provides gives you the SCM-esque start, stop, pause capabilities to facilitate debugging the associated functionality in your service.
Hopefully these may be useful to you, but if nothing else, this will be a good reminder for the next time we do a Windows Service.
I recently posted about Keeping SysInternals Up-To-Date. Since then I’ve had trouble getting it to work on any of our Windows Server machines. I couldn’t find much info on this online, so maybe it’ll be helpful to raise the problem here.
There is a problem with Get-Sysinternals.ps1 that prevents it from working on Windows Server platforms. The problem is due to its dependence on WebClient – the service that provides the ability to treat a URN on the web as a local drive. The specific line in Get-Sysinternals is:
New-PSDrive -Name SYS -PSProvider filesystem -Root \\live.sysinternals.com\tools
When WebClient is active, this line successfully creates a local drive called SYS that points to \\live.sysinternals.com\tools. When WebClient is not active, this line causes an error:
New-PSDrive : Drive “\\live.sysinternals.com\tools” does not exist or it’s not a folder.
At …\Get-Sysinternals.ps1:26 char:15
+ New-PSDrive <<<< –Name SYS -PSProvider filesystem -Root \\live.sysinternals.com\tools
+ CategoryInfo : ReadError: (SYS:PSDriveInfo) [New-PSDrive], IOException
+ FullyQualifiedErrorId : DriveRootError, Microsoft.PowerShell.Commands.NewPSDriveCommand
Is the solution to simply turn on the WebClient service? Unfortunately not. The official method for installing WebClient is to turn on the Desktop Experience feature. Microsoft does not offer another way (see Installing WebClient Service without Desktop Experience?) Desktop Experience also includes (reference Desktop Experience Overview, TechNet):
- Windows Media Player
- Desktop themes
- Video for Windows (AVI support)
- Windows SideShow
- Windows Defender
- Disk Cleanup
- Sync Center
- Sound Recorder
- Character Map
- Snipping Tool
Hmmm. We don’t want any of these running on our servers. Not only do they violate the Least Required Principle, many of them are CPU hogs (Themes, SideShow, Aero), others may execute at unknown times (Disk Cleanup, Sync Center), etc. Which of these involve installing drivers (Video for Windows?)
No, Desktop Experience is far from appropriate for gaining the functionality of WebClient (which we would only run temporarily anyway).
So, back to the drawing-board. What are others doing to update SysInternals on Windows Servers? Is anyone interested to collaborate on adapting the Get-SysInternals script to work for servers?