Hasn’t the problem of Windows updates being partially installed been solved?
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
What was it doing all that time? Some kind of solver?
I noticed the same thing you describe on Windows 7 by the way.
"Windows 7 uses Component-Based Servicing [1], which means Windows Update has to work ridiculously hard to determine file and component dependencies/inter-dependencies, maintain side-by-side versions of older files/components, while still making it possible to uninstall individual updates/components but without breaking any other updates/components, all the while taking into account supercedence and god knows what else. The code that does all this must be hellishly complex."
[1] https://technet.microsoft.com/en-us/library/cc756291(v=ws.10...
It's extremely annoying and not related to Vista particularly, nor specific types of hardware as far as I can tell.
Today, after about 3h it found the updates.
1. Manually check for updates. This took forever and thrashed the hard disk, every time.
2. Select, download, and install the updates.
3. Goto 1 until Windows couldn't find any more updates.
In some cases, step 2 would fail with various unknown errors and hex codes. The only way to fix this is to run a Windows diagnostic that "resets Windows Update components", which makes Step 1 take even longer than it would have otherwise.
All in all, I think the update cycle took me about 4 hours before I gave up on the third reboot and decided to just let Windows figure itself out. Compare this to an 'apt-get update && apt-get upgrade' or the OS X Software Update, and it's a wonder people update Windows at all.
There was a major update to Arch recently - due to GCC 5 changing the standard C++ library with binary interface changes. Basically every package written in C++ and compiled with GCC needed re-compiling and updating.
Mine took about an hour to update (6 year old machine) - with over 500 packages updated. Of course everything kept running, but I chose to reboot since it was such a major change and everything worked flawlessly. Kudos to the whole Arch team.
But take a minute to think about that - it's a major percentage of the whole system updated.
Updating my Windows machines in comparison is terrible - the amount of time and effort is so variable, plus having to be careful to avoid or remove the dreaded tracking updates backported from Windows 10.
Nostalgia much? How many times did e.g. .NET updates force XP computers into endless loops, or just killed the OS?
Windows Update has always been a barely functional, embarrassing mess. It's just that seems to be stuck in 2001, while others finally managed to sort their crap out.
Those others do not include Apple as anyone who's been indefinitely waiting for "installing" OSX updates can confirm - and the OSX fixes needed have the same weird incantation like qualities as the fixes for Windows updates (i.e. remove update, then restart, then run again, then panic, redo-sequence). No particular hate meant for Apple or MS.. but seriously, learn how to write a basic update mechanism that do not include random-fail-over.
> OS X fixes needed have the same weird incantation like qualities as the fixes for Windows updates
I find your statement inaccurate. Even if the update operations are fairly similar in Windows and OS X, the latter's update system seems fairly efficient. OS X doesn't have the libraries and dependences hell that windows does. The update model fits well in to the OS X environment, not well at all in Windows.
Also, Mac updates that update system files are 'rare' and usually only require one reboot. Windows often requires 2 or 3 reboots. Again, I believe this is because of the dependancies and libraries Windows is forced to maintain and keep up to date.
Mac's don't hang on update or install, frankly, Ever, unless there is something very wrong.
No linux system that I ever used worked that way. The only system I've seen that did that was solaris, and that patching software was a disaster.
Systems like dpkg and rpm replace the entire contents of a package when there is an update. The benefit of this is that if things are very out of date or a package is corrupted, the only thing you need to do to get things up to date is (re)install the latest package.
Packages on linux are fairly granular, so in practice doing full individual package updates is not a huge problem. I have 2300 packages or so installed on my laptop and all but 100 or so are under 10M.
Google did a lot of work optimizing chrome package updates, but I'm not sure if most distributions are prioritizing this sort of thing anymore.
They seem to pull down the updated bits, merge them with what is currently on the system to reconstruct the new package, and then install that.
That would save bandwidth, but not make the actual operation of installing the new package any faster.
Personally I would have preferred it not perform the Windows Update and allow me to connect to my client's network considering that's one of the requirements of getting paid by the client.
This is exactly why I keep a Windows 7 VM ready.
Compare the time it takes to remove or install a component (application or library) and you will be very disappointed in Windows. No matter how fast your disk or cpu is, Windows finds a way to make you wait half a weekend. This is unacceptable, but nobody complains loud enough for Microsoft to reconsider.
Windows software management is a total mess and it got worse with newer Windows versions.
But other parts of Windows get better with each release and it's mostly the kernel land. This seems to be a case of different teams having different culture (Windows kernel, Windows shell, Windows installer, ...). Take Windows 2003's desktop, put it on Window's 10's kernel, and you have a nice system.
The alternative is just Windows style software distribution: find a random exe on the internet and run it.
For example, in LTS releases, major versions are frozen but perpetually updated and patched for the lifetime of the distro. In more bleeding edge rolling release distros, you receive (or compile) sometimes major version updates of software within a short time after their public release. In those distros you can still freeze your packages at certain versions, but it's not quite the same as making sure every library and component in the system is getting the same treatment.
Try manjaro (https://manjaro.github.io/). It uses pacman (like Arch) and yaourt (for AUR, building from source). Their driver and kernel management makes switching between free/non-free drivers or different kernels easy. And they're pretty close to bleeding edge; I've been running kernel 4.2 with Xorg 1.17 (released 2015/02) for months, and up to kernel 4.4rc4 and Xorg 1.18 are available in the repos.
But when the distributor is also the author – like Microsoft is for everything that is delivered via Windows Update – that is no longer a concern. We can compare the solutions by technical merit alone… and Windows doesn't come off too well.
Just regular things from Linux.
On Linux systems, often most or all of the software being used is installed from the distro packages using the distro's package manager. Usually things go smoothly in this context.
On Windows systems, often most or all of the software being installed is installed using third party installers, which may have their own versions of various dependencies. The Windows infrastructure has to cope with this much less predictable context, and much of the time it does so reasonably effectively.
If you need to build third party software from source on Linux, or do more tricky things like cross-compiling to run on some embedded device, things are often far less pretty. Often you are just trusting that someone's makefile running under sudo won't dump junk all over your system, and that if it does, the uninstall target will tidy up properly -- which, in my experience, is not a safe bet on either count. Even building something from source in the first place on Linux typically depends on system-provided compilers and probably standard libraries, which as we saw with some relatively recent GCC changes can switch ABIs in non-backwards-compatible ways, potentially causing serious problems of their own.
In short, things look much better on Linux as long as you stay within the walled garden of your distro's own package management system. As soon as you need to go beyond that, you're probably in the Wild West.
Been there, got the video, in less exalted company.
Is the book simply a repackaging of the blog posts or would it provide a more coherent view of the history of the Windows project?