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."
Re:malware... (Score:4, Informative)
Not really a surprise though. All the things I've read about Prevx come to just marketing their shit, somewhat like Symantec is. Not really a surprise they'll make shit statements like this and then just 'sorry' afterwards.
Re:Is that any better excuse? (Score:5, Informative)
DId you rad the link? this is not being reported by very many people at all.
And in fact, it isn't their problem.
Actually yes (but no). OS X is an excellent model (Score:5, Informative)
What do you want them to replace it with? hundreds of .conf files scattered randomly about the filesystem, with no standard format?
After having used Linux and Windows and OS X systems for years, OS X does this right.
Yes there are "hundreds of conf files". But they are not scattered around, they are all in ~/Library/Preferences.
And they are usually named via the company name + app convention, like com.apple.mail.
And as opposed to being in "no standard format", they are all plist files (which are basically XML).
So it's easy to find where they are, easy to figure out what plist file belongs to what, and easy to edit or remove them as needed. If there is corruption (which I have never actually seen in practice) it would be limited to a single file - and an app encountering a preference file it could not read would simply replace it with a new default version. You would at worst lose a few custom settings for one app - and even then only as long as it took you to pull a backup of that single file out of Time Machine, since it's easy to restore the preferences for a single application from any backup.
However, I have to add that even if you went with a Linux system where the conf files are scattered all over in many different forms, I can say with confidence it is still 100% better than the nightmare of the registry. In practice the files are very easy to edit regardless of format, it's really only the question of the location that gets annoying.
Re:System Registry (Score:0, Informative)
This is already how it is. This particular key exists in HKLM, for which you need Administrator access to write to.
Re:System Registry (Score:5, Informative)
Maybe one day Microsoft will get rid of the Windows Registry. It's like putting port holes on the bottom of your boat. Sure, they let you see the fish, but sooner or later one is going to break and sink your ship.
The Windows registry has always been a bane of Windows use since it's inception.
Because Malware would clearly have trouble modifying the config files that would be used instead?
Re:malware... (Score:2, Informative)
Re:Easy fix, or fixed easily? (Score:2, Informative)
It's not really the registry per se; it's the fact that the Win32 API uses NULL-terminated strings while the underlying NT API uses Pascal strings. You can run into similar problems with the file system for the same reason. This dilemma can't really be fixed due to backward compatibility concerns, so this problem will continue to exist in all versions of Windows into the foreseeable future.
Comment removed (Score:5, Informative)
Re:malware... (Score:1, Informative)
To be fair to Obama, George W. Bush was a really horrible president.
Re:malware... (Score:3, Informative)
Unless you make above 500k a year, then he was the best president ever.
Re:System Registry (Score:1, Informative)
This is what they have. HKLM for important stuff, HKLU for stuff the user can screw around with.
Oh, you mean you always run as administrator in Windows so malware can screw with HKLM? Well, running as root on Linux will allow malware to screw with your x.conf and you'll have the same problem.
Re:Really? (Score:3, Informative)
Does the sudo part really matter anyway? The most important files on my system are those in my home directory and they're owned by my own user account, thus no privilege escalation is required to touch them.
Furthermore, running with no special privileges you can still:
- Start a process on an unprivileged port (>1024)
- Establish a connection to another system.
- Put a process in the background so it'll still run after you've logged off.
- Subject to permissions, write to network-mounted filesystems.
- (depending on cron configuration) Set up a process to run periodically without leaving anything tell-tale to the casual observer in the output of ps unless by sheer blind luck they hit ps when your process is executing. So it would still run on reboot (though it'd be really easy to find if you ever edited your own crontab, a lot of people simply don't bother checking such things).
All of which are quite enough to set up a system as a node on a hypothetical botnet somewhere. Now all you have to do is spread (easy, you've got enough power in that list to email something to everyone you can think of and stick a copy on a fileserver) and persuade people to run you - either intentionally (Click here for pictures of Britney nekkid!) or unintentionally (bug in email application).
Re:Its the users, not the OS (Score:4, Informative)
When performing a Windows 2000 or XP install, it prompts you to name a user, which is an administrator account.
So it is designed by default to log you in as an administrator.
Re:Really? (Score:5, Informative)
Re:Really? (Score:3, Informative)
In fact, that's one of the main advantages of *nix over Windows. The reason that you have to re-boot windows so much during installations is that you can't delete / replace files while a process is accessing them.
In *nix you can delete a file while a process is accessing the file, and the process continues to see the file until it finishes, while other, new processes can't see the file.
Of course, once I started a five-hour database export job, then deleted the target file without realizing it, and after the export finished successfully (since it could still "see" the file it was writing into) the export file was gone.
Re:malware... (Score:1, Informative)
To be fair to Ron Paul, all politicians are really horrible, except for Ron Paul.
Re:Easy fix, or fixed easily? (Score:1, Informative)
If you remove the Win32 API, EVERY WINDOWS APPLICATION EVER WRITTEN breaks. Assuming we don't want to do that, the only other option would be to remove the NT API. Unfortunately, this is the API that allows user-mode applications to communicate with the kernel. I don't think you could write a very useful application that has no ability to access the registry, files, network, hardware, etc, all of which require calls to the kernel. You were right, that *was* easy!
Obviously you don't know the first thing about the architecture of Windows NT (and judging by many other comments I've read you are not alone). If anybody cares to educate themselves, I highly recommend Windows Internals [microsoft.com].
Re:Really? (Score:2, Informative)