Slashdot Mirror
Latest Windows 10 Update Has Yet Another File-Managing Issue (gizmodo.com.au)
An anonymous reader quotes Gizmodo:
When it was discovered earlier this month that the 1809 build of Windows 10 was deleting user files just because, Microsoft halted the update until the problem was fixed. Shame, then, that another not-as-bad-but-still-bad file overwriting bug has now reared its head. in 1809, overwriting files by extracting from an archive using File Explorer doesn't result in an overwrite prompt dialogue and also doesn't replace any files at all; it just fails silently. There are also some reports that it did overwrite items, but did so silently without asking.
Ars Technica speculates that there's a larger program with Microsoft's testing process: [M]any of the preview builds had a bug wherein deleting a directory that was synced to OneDrive crashed the machine. Not only was this bug integrated into the Windows code, it was allowed to ship to end users. This tells us some fundamental things about how Windows is being developed. Either tests do not exist at all for this code (and I've been told that yes, it's permitted to integrate code without tests, though I would hope this isn't the norm), or test failures are being regarded as acceptable, non-blocking issues, and developers are being allowed to integrate code that they know doesn't work properly...
Microsoft's new development process has, proportionately, a greater amount of time spent writing new features, and a reduced amount of time stabilizing and fixing those features. That would be fine if the quality of the features were higher to start with, with the testing infrastructure to support it and higher standards before new code was integrated. But the experience with Windows 10 thus far is that Microsoft hasn't developed the processes and systems needed to sustain this new approach.
Ars Technica speculates that there's a larger program with Microsoft's testing process: [M]any of the preview builds had a bug wherein deleting a directory that was synced to OneDrive crashed the machine. Not only was this bug integrated into the Windows code, it was allowed to ship to end users. This tells us some fundamental things about how Windows is being developed. Either tests do not exist at all for this code (and I've been told that yes, it's permitted to integrate code without tests, though I would hope this isn't the norm), or test failures are being regarded as acceptable, non-blocking issues, and developers are being allowed to integrate code that they know doesn't work properly...
Microsoft's new development process has, proportionately, a greater amount of time spent writing new features, and a reduced amount of time stabilizing and fixing those features. That would be fine if the quality of the features were higher to start with, with the testing infrastructure to support it and higher standards before new code was integrated. But the experience with Windows 10 thus far is that Microsoft hasn't developed the processes and systems needed to sustain this new approach.
Wow, that's Microsoft quality!
"Everybody's naked underneath" -- The Doctor
... computing. To turn PC's into locked down devices like phones. The masses are too stupid to understand what is happening and keep feeding all these companies money. Watching PC software freedom and games being literally stolen and turned into "services" because the average person on our planet is fucking chimp level intelligence is pretty fucking disgusting.
During the April update this year, I had 3 W10 installations to get through the process. None of them worked, although one in particular went spectacularly wrong and wiped out files on the system's hidden boot partition, basically resulting in the system attempting to reboot and crashing out. There was no choice left but to perform a clean installation, then let that fresh image update.
In all my years of using Linux, 20 now, I have never once been forced to do a reinstall. I actually have one system that was continuously upgraded from Debian potato in 2003 through to Stretch today and is still running, having worked its way through three or four hard disks, one of which was a head crash salvaged by ddrescue. Some of the version upgrades were a little exciting in the old days in the sense that manual intervention was sometimes required even to the point of hand editing apt db files. It pretty much just automagically worked for the last dozen years or so, e.g., edit sources.list from Stretch to Buster, apt update then apt dist-upgrade.
I guess Windows users have a hard time imagining anything so reliable. BTW, the longest uptime for that server was about three years at one point. And it was 32 bit all that time, still is. Finally migrated all the services to a NUC running 64 bit Debian, but that old system, a Pentium M, is still running as a storage backup server. It runs KDE by the way, for the rare occasions I hook a monitor to it. Works perfectly well, that's something for the Gnome trolls to meditate on. Today, that machine is probably less powerful than my thermostat.
When all you have is a hammer, every problem starts to look like a thumb.