Having an AIO installer is a nice thing. On Windows, the Microsoft recommended way is the install-docker-ce.ps1 script without an ability to do an actual upgrade other than with full uninstall/reinstall.
I personally don’t understand overall situation of software development that we ended up at. Why do we need third parties to package software products? I think it’s made so complicated for devs when you have to take care of million different platforms and each of them makes it so painful to package for.
Maybe an unpopular opinion, but I am missing the old Microsoft these days. How did we end up in the world where technologies like Windows Installer are replaced with PowerShell scripts that downloads software from the Internet?
Writing a script has always been simpler than making a proper installer, because you need to adhere to various transactional rules, implement a proper rollback mechanism, worry about making your components have correct keys that still work after an upgrade. And e.g. if you need to install a Windows service, most of the standard options (even those provided by Wix) don't cover all cases out of the box. So to some extent using a script means replacing a more complex, but complete solution with an ad-hoc thing that may work in general, but fails a lot of corner cases.
Also it takes quite a lot of effort to understand how windows installers work because it’s far from intuitive and you get to learn all those tools that make no sense. This is not something that a person working on project like docker itself for example would want to spend their time on. They’d rather make a script than an MSI.
One quite convenient thing is that Windows Installer packages can be installed via Group Policy, making deployment for new nodes work like a charm. How is a sysadmin supposed do this with scripts?
What has changed since these days of Microsoft? I’m pretty sure when it came to setting up complicated systems, you had to follow a 158 pages document with all dialogs you had to click to (if you’re lucky enough to have a document like this)
In this sense a predictable powershell script is IMO an improvement
Our management console (the client) is integrated into MMC, so it's limited to running under .NET Framework. While e.g. StreamJsonRpc can be used in this environment, it would also result in an awful amount of dependencies (Nerdbank.Streams, Microsoft.VisualStudio.Validation, Nerdbank.Streams, MessagePack, etc.), all of which are kind of tricky to bundle.
So we decided that in the long run, a simple custom IPC implementation would actually be more maintainable.
As far as I remember, in that case you still will be able to get a directory handle (with appropriate permissions), but calling FlushFileBuffers() on it is going to fail.
So you can test for that in advance before the restore and switch to syncing each file individually. Or accept that the approach only works locally and do nothing more, since durability over SMB is a questionable thing.
As far I remember NAND/NOR memory (used for SSD) is very slow to *erase*. The erase operation can be performed only by big chunks, requires higher voltage etc.
SSD vendors circumvent this by adding several layers of write buffers to achieve good test results.