Slashdot Mirror
Will Windows 10 Finally Address OS Decay?
colinneagle (2544914) writes The real question on my mind is whether Windows 10 will finally address a problem that has plagued pretty much every Windows OS since at least 95: the decay of the system over time. As you add and remove apps, as Windows writes more and more temporary and junk files, over time, a system just slows down. I'm sure many of you have had the experience of taking a five-year-old PC, wiping it clean, putting the exact same OS on as it had before, and the PC is reborn, running several times faster than it did before the wipe. It's the same hardware, same OS, but yet it's so fast. This slow degeneration is caused by daily use, apps, device drive congestion (one of the tell-tale signs of a device driver problem is a PC that takes forever to shut down) and also hardware failure. If a disk develops bad sectors, it has to work around them. Even if you try aggressively to maintain your system, eventually it will slow, and very few people aggressively maintain their system. So I wonder if Microsoft has found a solution to this. Windows 8 was supposed to have some good features for maintaining the OS and preventing slowdown. I wouldn't know; like most people, I avoided Windows 8 like the plague. It would be the most welcomed feature of Windows 10 if I never had to do another backup, disk wipe, and reinstall.
Sadly the way updates work with MS they become the far bigger problem. You can easily see this by installing a "clean" system, examine its timing (please don't even think about using system internal benchmarks...), then patch it and notice just how much speed you suddenly miss.
That's a problem you probably won't solve quickly...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Likewise. I've got a Windows 7 gaming rig that has seen LOTS of installs and uninstalls, driver updates and Windows updates and have seen zero performance reduction.
Maybe this was a thing in Windows 95, but I'm not sure it's a thing now as long as you're not getting infected with malware.
You are welcome on my lawn.
for their business model to function...and they won't break it.
Everything in the Universe sucks: It's the law!
Not really. It's just bad design.
Your server isn't getting games installed on it, which put all kinds of settings in the registry, then removed later when the game is old and tired, leaving behind cruft (including DRM bullsit) in the registry.
When a program is UNinstalled, all traces of it should be gone. Apple took a different approach, which arguably works far better. Even if stuff is left behind, it just takes up a bit of disk space, and doesn't affect the system at all.
Yes it is bad design. It is bad design by the people who create applications. The level of incompetence is staggering and this includes all the big name vendors.
Funny you should mention Apple. The Windows version of iTunes (the shittiest piece of software ever written) installs support files for 34 different languages. There is no option to only select the language you want at install time and the user is completely unaware that iTunes has just dropped approximately 4,400 un-needed files onto his hard drive.
But wait! It gets better! iTunes also creates a registry entry FOR EVERY SINGLE FUCKING FILE!! I am not making this up. ~4,400 files AND registry entries that can be deleted with absolutely no effect on the functioning of iTunes.
Microsoft went further than just having a bad registry, they essentially forced developers to use it if they wanted to get the approved sticker (ie, to say "works with Windows 95" or such).
Android does sandbox apps. The default internal directory for each app can only be read/written by itself. Prior to version 4.2, the SD card was public and could be read/written by anyone. 4.2 and later, only parts of the SD cared are publicly readable and only parts are publicly writable.
In both cases before and after 4.2 uninstalling will remove the private directory. It will also remove any private directory on the SD card, so long as the app used the default location. Some apps don't, purposely, so their data will persist if reinstalled.
I still have more fans than freaks. WTF is wrong with you people?
Then again, winsxs is only one of several directories that often have people asking, "can I delete this?" See also C:\Windows\SoftwareDistribution, System Restore, and Windows.old, and c:\windows\installer. They are a mix of necessary and junk. From end to end, Windows is designed to keep everything, forever, just in case, instead of keeping track of things properly in the first place.
Android doesn't sandbox apps.
Er.... Yes it does. Absolutely it does, it's right there in the docs.
http://source.android.com/devi...
Each app gets a separate Linux user, so it's data is separate and inaccessible to other apps.
This means that a WinSxS folder that is 6GB costs around .90 Cents, and uses slightly more than 1 Percent of the drive.
I think you just don't understand what WinSxS is, how it works, and what the problem is that it is designed to address, suggest you start reading a bit more.
The reason the old Sxs assemblies need to be kept, is that installed software may require the usage of an old assembly.
Just because an update has superceded a certain library version, does not mean that all applications that still rely on it should be broken.
When you've got a 19 GB Win SxS folder on a 40 GB HDD (which is plenty for a server and expensive on Tier 0 SSD's) it's a serious issue. 19 GB is not ridiculous, it's not even usual for a 2 yr old server that's been updated regularly. 19 GB across 250 virtual servers is a serious waste of space. Even 6 GB is a massive costs in infrastructure. Not every update needs to keep dozens of updates. Fortunately Microsoft has addressed this problem (as of April this year, so relatively quick in Microsoft time) so that the WinSxS folder can be cleaned up.
Calling someone a "hater" only means you can not rationally rebut their argument.
make uninstall Also compiling from source should rarely be necessary. Most modern distributions will include a ports like system that will allow you to compile source into a fake root, use the information gathered to build a package, and then install the package with your package manager. This ensures everything is cleaned up properly upon package removal. Of course even building a package for the software is probably unnecessary as it's very likely someone has already done it for you. Linux' package management is vastly superior to both Windows and osx (don't you just drag a folder into the garbage can? Give me a break). You just have to know what you're doing.
If it ain't broke, don't fix it.
Android doesn't jail() apps (where the application cannot see outside the space it sits in), but it does sandbox apps. Apps get their own UID, and by default, they cannot get into other apps spaces. /system is usually root owned and the whole volume is read-only, for example.
Recent versions of Android use SELinux, so if an app does get access it shouldn't have, it still is stuck in the role it was assigned. For example, some app getting root will still be constrained even with UID 0, so it couldn't remount /system read-write, for example.
Android 4.3 adds onto that by adding SELinux rules onto the external SD card, limiting its use. If you have root, you can use a utility like NextApp SD fix to change SELinux rules back to how they were previously, or SELinuxModeChanger to entirely disable SELinux on your device. Disclaimer: SELinux is a good thing overall, and killing it does weaken security.
iOS's security model is weakened by a jailbreak, while Android's is unaffected if the user has root (assuming the user didn't use the su app to give a rogue app root [1].)
Of course, Android's model has its issues... the all or nothing aspect [2] (where one can choose what stuff an app has access to in iOS), for example.
[1]: Newer apps have a special permission on install which shows the user that it might want root, and the su binary will warn or not allow access to any apps that don't declare that permission in their manifest.
[2]: Cyanogen's privacy features help, as well as XPrivacy. XPrivacy gives extremely fine grained control to what an app can use or cannot use. However, I'd not consider this part of Android proper, though it should be.
As a counterpoint to this; I had a reasonable machine for work. Win7 Pro, then IT got hold of it and connected it to the new domain etc; now it is much slower. Booting, shutting down, launching programs...everything is slower then the day before.
Well known problem. Once attached to a domain, Windows attempts to do all kinds of stupid things. One of the most common problems is the open/save file dialog. The OS attempts to display it, then blocks until it contacts the domain servers to look up the user's actual name. Then there are similar delays that happen as it goes out and probes each drive, which is a problem if they are mapped network drives as the display waits until everything is built before the UI appears.
On a machine that is disconnected from the domain, perhaps a laptop away from the office, it gets even worse. Internally there is a 45 second delay on each of the network probes, and between Windows 2000 through Windows 7 they all fired sequentially. So if you had your own friendly name plus three mapped drives, that's three minutes of waiting for network connections to time out. It is somewhat faster under Windows 8, but in bad cases can still take ages.
For these specific issues they will not fix the root problems of the shell blocking until after data is loaded or probing the domain for security settings as it would break many shell plugins. It can be made partially better by disabling some of the features; they include disabling certain group policies on shell extensions, turning off certain domain security and SCAPI settings, and disabling drive mappings whenever possible. When disconnected, removing all VPN lookups and disabling proxy detections can also help. Even with those improvements, attaching a machine to a domain introduces an immediate performance penalty on everything shell-related.
Another similar set of problems is apps that try to probe the MRU file list when files are on the network. Many parts of the OS try to cache things based on prior use, and once you're wired in to the corporate network these probes (which stupidly are often blocking tasks) can take seconds to run while on the network, or minutes to run when they time out when off the corporate network.
//TODO: Think of witty sig statement