Microsoft resumes rollout of Windows 10 version 1809, promises quality changes
zdnet.com
zdnet.com
To hear the recent stories of updates causing issues is surprising, but with so many supported configurations for Windows, I find it a lot more excusable than MacOS or ChromeOS.
That doesn’t mean things like this shouldn’t be caught in QA, it just means it’s not always easy.
I've had some problems, but then again, I expect my computer to do weird things sometimes, I guess that's expected if you're a software engineer :p
This is the very same problem I had with the 1st gen clickwheel iPod. When I first connected one to a new computer, iTunes asked me if I wanted to 'initialize' the device. Oblivious of its meaning I went with 'yes' and wiped a borrowed iPod clean. Friendship ruined forever.
Sounds like Apple just doesn't learn some lessons.
However this behavior is really out of the line for MS since they've got a good track record on backwards compatibility and data preservation. Previously during in-situ upgrades the installer would back up gigabytes of data in a special folder on the off chance that they might be needed again in the event of a rollback, and somehow they managed to drop the ball this time round.
If so, that's not a UX problem. That's a flat-out bug. In short, there was an option to migrate files from folder A to B. Months later, in the update, folder A was accidentally deleted. The migration would decrease the damage, but not prevent it, and saying 'no' is not a mistake.
There have been plenty of reasons to bitch about it since it was released.
It's 2018 and updates are still slow to apply and/or break computers... what a strange world.
Baseless speculation: I suspect that they were referring to Apple making use of the ability to spin up a new temporary APFS volume to store the Update packages + Staging environment and blessing it for boot.
It makes a certain amount of sense to push out a static staging environment to then run the requisite OS updates and firmware updates from that controlled environment. That way you can reboot as many times as is required for the updates in the point release and still come back to the staging environment ready to go to the next stage - only needing to touch the User Data Volume when absolutely necessary.
While not nearly as 'clean' as an atomic update on a read only root filesystem, this method could be significantly more controllable and more 'clean' than doing it live on the User's Data Volume.
I suspect with iOS Software updates - it's a transactional atomic update as those machines all use read only root filesystems regardless.
But the ideal solution would be a copy-on-write filesystem supporting snapshots, rather than A/B partitions.
NTFS is already that via Volume Shadow Copy. They just don't use it in the way we're discussing, but the tech is there.
I assumed it WinSxS related as the other reply mentions, and upon investigation found that it is 9GB alone! I don't run Windows outside of work so I've just never really bothered looking into it, but if it continues to balloon I guess I'll have to.
I know in the past, any Windows updates would be cached in your windows directory forever and there was no safe way to remove them. That would gradually grow the windows directory size forever. Also, it seems there are a lot of files that get thrown in there when you start installing multiple versions of SQL Server or Visual Studio.
Disk Clean-up.
Clean-up System Files.
Windows Update Clean-up (and Temporary Windows installation files).
Ok. Ok.
Enjoy.
That doesn't sound like how much Windows is actually using for itself. How much of it is \Windows\Installer\?
On the flip side, with WSL windows 10 can now pretty much run any POSIX compliant code anyway.
Microsoft never needed to buy into that; Microsoft set its own standards with MS-DOS long before that, and Windows further cemented Microsoft's position. Where all the UNIXes and UNIX clones were in dire need of standardisation, MS-DOS and Windows were and still are the Microsoft standard.
Even in modern times, POSIX compliance doesn't necessarily mean much when a lot of recent software is being designed Linux-first, with support for other POSIX systems sometimes relegated to third-party or distribution-specific patches. Not to mention all the various implementations of POSIX compliance come with their own little quirks that make things different enough to still require manual checking for this or that.
Additionally, there are plenty of libraries that are compatible with both POSIX-compliant and non-POSIX platforms. Targeting these libraries produces perfectly usable software.
Therefore, POSIX compliance isn't the be-all and end-all of computing. Somehow or other we've managed to muddle through the years without it in Windows, and Nazis aren't riding dinosaurs on blood-soaked streets just yet.
You're making fun of unicorns, but treating 'POSIX' like a magic word.
So it doesn't help you if you want to, say, write a cross-platform library in C that needs threads, and that can be used from both Unix console apps and Win32 desktop apps. For that, you actually need a cross-platform threading API. In C++, that actually exists, in form of std::thread and friends. In C, you have to rely on third-party libraries, and those libraries have to wrap the various platform-specific APIs - so your program is only as portable as those third-party libraries. If you could just #include <pthread.h> everywhere, it would have been so much easier.
Because of fork() you will never be able to arbitrarily use NT objects unconstrained in WSL apps, but there are lots of options. You can launch both windows and Linux programs arbitrarily from the shell now so the decision to choose one or the other is slowly coming down to preference.
This has always been a problem. Check out a really big git or SVN repo on the native box using native windows tools and compare to a native Linux install on ext4. Ext4 can take 10% of the time to complete.
ReFS suffers the same fate too.
I can’t say anything more than walk away.
Using a VM is orders of magnitude faster.
Of course it's absolutely fair if you find WSL poor for your use case. But performance is not really the main thing that makes it "usable for developers", IMO.
It just so happens that the version of Windows these customers are asking for already exists, as an actively-supported product. But you can't buy it. I can't describe this behavior as anything but anti-customer.
This is similarity bias affecting your judgment.
I believe the way windows 10 currently runs update is wrong for me, and for most tech users, by far. I'm glad it takes 10 second to fix it to allow delayed updates again, but still I would like it to come out of the box easier to manage.
On the other hand, for the very very vast majority of windows users, this is superior to the end result they experienced before (updates never installed, and not by choice).
What's wrong here is a clear case of "one size fits all", they apply the same system they made for the majority to everyone, and it end up not work for some users for a variety of reason, but it's (imho) wrong of you to think this is not exactly what most users want: "do it like my phone/tablet, I don't care about updates"
The amount of people asking for something like LTSC is large enough that Microsoft really, really ought to make that version more widely available. IMO, Microsoft's refusal to do so says a lot about their values as a company.
FTFY. I'm not talking about the improvements underneath the hood, but just the way things looked and acted under Windows 7.
I switched over to the "Semi-Annual Channel" in Windows Updates advanced options. The "Semi-Annual Channel" is for "widespread use in organizations" versus the "Semi-Annual Channel (Targeted)" which is "ready for most people."
Also, the updates can be deferred for up to 365 days, but I'm not sure if that would slow the updates down rather than just delay them.
Disclosure: Microsoft employee
That being said, Microsoft's month-to-month patch reliability has been absolutely terrible. While not causing data loss, the monthly updates have been regularly show-stopping of late, and anything that gets Microsoft to realize it made a mistake on axing it's testers (and removing the ability to cherry-pick security fixes) is something I can stand behind.
[1] Complete aside, I have actually heard of someone applying version control to the folder that contains the Windows registry, and being upset at Microsoft that it broke their PC.
[2] Linux is not a company, and truly open source platforms do some amazing things for long term support. I think they just dropped support for 386 processors a couple years ago.
Did it now? afaik if you only had one drive, and one partition, and had Windows installed there, and you didn't have enough free space, you lost everything. That's not exactly niche
Note that the reason that Microsoft failed to address it is because while a Feedback submission had been made, it didn't have any upvotes, because it was so niche that almost none of the Insiders experienced it. Despite the fact that Insiders are the sort of power users most likely to have fiddled with weird features like folder redirection.
Details are here: https://blogs.windows.com/windowsexperience/2018/10/09/updat...
But maybe you're referring to another bug.
Searching around for some sort of source, I found this article[1], which says "...some of my readers told me their hard drives were corrupted and thus were unable to roll back the update." Of course this may be hearsay and false information in times of panic, so I take the statement with a grain of salt.
[1]https://www.forbes.com/sites/jasonevangelho/2018/10/06/micro...
I seem to recall reading that the "improper use" in this case could also consist of using a program that hard-coded paths and was not aware of folder redirection.
These are one set of steps to be effected by the bug.
1. Have a primary hardrive that is nearly full.
2. Get a second hard drive to store more pictures to your machine.
3. Change My pictures folder location to save on the new hard drive. (The least likely step but not super unlikely if your searching ways to stop your primary hard drive filling up)
4. Click no when asked if you want to copy everything across to the new location (ignoring it saying it's recommended (but only so you can see your older photos easier))
5. Have the update roll out and delete all of the old photos you had.
Losing those old photos (perhaps of passed loved ones) you may not have anywhere else can be heartbreaking. The fact that a very small percentage of users is effected does not change the fact that as we're talking about a massive user base, the absolute number of users is always going to be high.
I am certainly not undervaluing the consequences. Data loss is always huge, but I would say, comparatively, the likelihood of losing your data to this Windows bug pales in comparison to say, getting locked out of your Google Photos account and having no way to appeal. (I have a friend who is unable to get into a Google account with correspondence from a deceased family member.) I don't feel like Microsoft is even close to the industry worst in putting your data at risk because of this bug.
And with regards to the massive user base, bear in mind, this was caught in the very early stages of a slow, phased rollout process, explicitly for this sort of reason. So it was a small percentage of a very small rollout to begin with.
All up, I think data loss was probably uncommon, but not rare. And data loss of such things is always severe.