Black Screen of Death Not Microsoft's Fault 583
Barence follows up to the ongoing Black Screen of Death Saga by saying "Microsoft says reports of 'Black Screen of Death' errors aren't caused by Windows Updates, as claimed by a British security firm. The software giant claims November's Windows Updates didn't alter registry keys in the way described by Prevx, which said that the Microsoft Patches caused PCs to boot with just a black screen and a Windows Explorer window. Microsoft is now blaming the problem on malware. Prevx has issued a grovelling apology on its own blog."
Easy fix, or fixed easily? (Score:4, Interesting)
TFA says a piece of malware can knock out the null-terminator in a required string, which Explorer relies on to load properly.
While it's good to know that a simple problem can be solved quickly (and the root cause discovered, damn you malware), and it's also good to see that Prevx can apologize when the make a mistake-- but I have to wonder if Microsoft would have been attended to as quickly as they had had Prevx not complained as loudly as they did.
KB976036 has conflict with Comodo Firewall (Score:2, Interesting)
We have a bunch of machines that can't properly shut down after this update (time zone update) is applied. It takes me few hours to isolate this thanks to some instant recovery software.
Re:Really? (Score:1, Interesting)
Re:Easy fix, or fixed easily? (Score:4, Interesting)
Historically speaking? no.
That said, MS is actually changing.
Of course, the root of this problem is the registry.
Re:System Registry (Score:1, Interesting)
"What do you want them to replace it with?"
Two registries. Number 1 for the system settings. Locked down. Number 2 for apps. This also makes it backwards compatible.
Re:" Microsoft is now blaming the problem on malwa (Score:2, Interesting)
I asked for them to get rid of the BSOD, they got rid of the BSOD -- that's Windows 7.
Re:System Registry (Score:3, Interesting)
And /usr/local/etc /usr/local//etc, /usr/local//conf, /usr/local//data...
and
Re:System Registry (Score:5, Interesting)
The reason why the registry exist is that the filesystems on Windows OS' have historically been lock on read (more than one program using the same file at the same time is a no-no.) Meaning that having a place where this was not the case was VERY meaningful to lessen access bottlenecks, thus enter the registry.
Having hundereds of conf files in /etc or having them in a registry "hive" is "same same but different" that's ALL. Gnome has a form of registry hive as well... organizing data whether being direct in the filesystem or special filesystem (DB or what have you) is the same.
I have to say that it is easier to edit a config file with vi/edit/ed/sed IF one knows where to go. Regedit command line tools sure... GUI... not efficient... Gnome registry either conf-editor or command line... I personally stick to CLI.
I agree that Windows should "drop the registry..." but only because they should drop the ancient approach of their locking behavior on the filesystem... this would also cure the reboot till you drop at update times. Later OS-X versions have started to reboot machinery after updates just to be more like Windows because that's what users EXPECT. It is painful!
Crock of shit (Score:2, Interesting)
How is malware not microsoft's fault? (Score:2, Interesting)
Perhaps if their operating system properly separated and sandboxed applications, malware
would have a harder time crashing the whole OS?
Just a thought. Last time I checked my watch, it was 2009, and we've known how to do
that sort of OS design for probably two decades now.
Well, no registry cleaning to begin with (Score:5, Interesting)
I have 700-800 plist files in my Preferences directory. All those widgets I tried, apps I installed, removed, run one time.
It must be like 1 line of command on Terminal or basic "Finder" order by date to find the old/unneeded ones and delete them but I don't bother. Why? Because it has zero effect on OS X. OS X wouldn't really care if there were 1000000 pref files there since it is not its business to maintain them let alone read them.
On Windows, while I hate the idea from the beginning, if you don't clean up your registry, OS will do it for you. Last time it was like 20% overhead required to clean it up at boot. If you get enough junk on that already huge, complex file, it will effect the entire performance of system. Windows _has to read_ that gigantic database to function and find its way in it.
ps: Now you understand why Windows technical user switchers insist on having "uninstall tool" or be amazed at "no add remove programs" on OS X? They generally think having redundant, old files, needless files will somehow effect their system. You can even add "universal binary haters" to that camp. I don't blame them, I blame Windows.
As if that makes it any better..... (Score:2, Interesting)
Re:Easy fix, or fixed easily? (Score:3, Interesting)
Citation needed.
There is no problem with the registry in principal. Acting like their is just shows your ignorance.
There have certainly been implementation issues with the libraries to access it. There almost certainly will be more in the future.
This is no different than any library that provides the same sort of functionality.
The problem could be the same if we used ini files, or xml files, or some random file format.
The only thing the 'registry' actually is, is a set of defined API calls to access data. The backend is irrelevant, and you can in fact remap just about any part of the registry into ini files if you know how.
So once you've flipped the bit to map to an ini file, are you going to now say that ini files are bad? You could put some effort into hooking the registry code so it used xml files if you really wanted, whats the problem now. If you're implying that the problem is entirely in the library behind the API that allows you to access the registry than I challenge you to show me a library that has never had any bugs that can be exploited. You can do it, but you're going to have to use a library thats either never been seen by anyone or has no useful purpose.
Bad code can not be prevented, it happens and will happen until humans are perfect, which is unlikely.
You can change the API, but you'll just create a new set of bugs and problems that manifest themselves in a new and exciting way.
Implying the registry is 'bad' is like implying stdin/stdout/stderr are bad. You realize these have had their implementations exploited as well right?