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.
The last Windows OS I ran was XP, prior to migrating to Mac. I didn't run anti-virus, never had any malware problems, and never had it slow down. I ran CCleaner maybe once a month and/or after installing / uninstalling an app or installing OS updates.
XP was fast as hell until you patched it up to SP3. Microsoft borked the hell out of that OS. Windows 7 I have not had the gradual slowdown problem at all.
Do not look at laser with remaining good eye.
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.
The SxS assembly backups have a vital role, and they don't actually use as much disk space as you think, due to hard linking --- Windows Explorer gives you an impression that more disk space is consumed by this folder than actually is.
The reason is... various installed files throughout the system will be hardlinked here, causing an appearance that a lot of space is in use here, but in reality --- these hard links are just a second Zero-usage copy of files that are installed elsewhere.
Only a couple gigabytes worth of files that have been updated and no longer have other hard links here, should actually be considered usage of the SxS system.
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!
NO!
http://en.wikipedia.org/wiki/B...
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.
Except that "modern mobile devices" get messed up and bogged down exactly the same way - even if the apps are supposed to be sandboxed.
There is one million os wide settings , or system apps and services that can get screwed up and their internally stored data will start causing issues.
Is the battery drain on your android the same as it was after factory reset ? Didn't think so.
Android doesn't sandbox apps.
iOS does, and it doesn't suffer from this problem. All software is given a directory that they can read from/write to. There are a few places outside that which can be read, but virtually nothing has write access (except for a few cases where a system app will expose access to it's data via inter-app communication. Calendar for example has this).
When you uninstall the app, that directory is deleted. There is no trace at all that the app ever existed.
Config files go either under
* /etc/app - system wide, distribution provided /opt/app - foreign applications, system wide
* $HOME/.config/app - user specific, don't just dump to $HOME
*
Then you have 3 places. Maybe 4 for legacy $HOME/.app stuff
Why is this not the same as "The Registry"? Because it's filesystem level and there is no stupid GUUIDs for keys. Imagine if some application installed their config files under unreadable with GUUID paths. Then the under does not know WTF those things ever suppose to be.
But that's a system that COM and COM+ invented. It works great until someone does not follow the rules, which turns out to be quite a few users and vendors.
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.
I'm well aware of the hardlinking that Microsoft does. I've also done some actual analysis measuring the real disk usage of WinSxS by using tools that count the hardlink references. On my Windows 7 installation that had a 16GB WinSxS folder, 14GB of that was unique to WinSxS with no other hardlinks. It isn't as efficient as Microsoft claims it to be.
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.
For batch file and CLI use, %appdata% will do. Unless you're looking for local, non-roaming stuff. Then it's %localappdata%.
If you're developing in .Net, be sure to use Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) or Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) unless you want to clutter your code with calls to Environment.ExpandEnvironmentVariable().
Any of these will avoid the ambiguity you have in your post.
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
Windows changes a lot of its behavior as soon as you change that radio button from "Workgroup" to "Domain". Before you even get to the log in prompt, Windows has to connect to a domain controller to download Group Policy settings and the like. Having to run login credentials through a DC and load config from it as well will add at least a slight amount of lag - possibly a lot, depending on how responsive the network and the DC are. Then, there's the matter of which Group Policy settings the admins have chosen, many of those can slow down the computer on their own.
If IT "had their way" with it, they might have also loaded it up with antivirus or some other bloatware.
I know it is a database, and slightly optimized. "A few records" would not affect query time, especially if they were not in the query path.
What about a lot of records? And how about a lot of records that are in the query path?
It's a database. IIRC it uses B* trees. Search time is proportional to the logarithm of total number of records. Even "a lot" of records may not cause the height of the tree to increase. You generally need to *square* the number of records to double to search time.
At the same time, the registry hives are really, really robust. Windows keeps to redundant copies and even protects writes through the kernel transaction manager as well as the journal of the file system. Corruption is virtually impossible until the hard drive decays to a state where even the redundancy cannot make up for it anymore. Unlike text files, both metadata *and* data are guaranteed to either succeed in an atomic transaction.
(compare to the Unix way, where config files can be corrupted if the system/power fails during a write: File system do not guarantees *data* consistency for regular files, only *metadata* consistency, i.e. the fs guarantees that its internal structures will not cause it to go haywire on your files afterwards)
I suspect that this is actually the reason why there's a myth about corruption of the registry: With all of the redundancy, the registry is often the last component to fail when a drive succumbs. At the same time, Windows will refuse to start *if* the registry is corrupted. At that point the drive is in such a bad state, that even restoring/repairing the registry corruption will not save the drive.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*