That is a well known one. You have a couple options:
1. Ask your network guys to move off the proprietary Cisco concentrators and use a standards based VPN server. Then you can use the Windows VPN client, and it will 'just work'.
2. Tell your Cisco rep to get off their asses and upgrade the client.
FWIW, the cisco vpn client has a history of problems on windows. I dont think whoever cisco farms that work out to is very good, at least not on that platform.
What specific legacy problems are you referring to?
I'm not aware of any significant ones still remaining.
MS has really made the break with past legacy security issues on Vista, and almost completely on x64 versions of Vista and server 2008. Thats where MS has chosen to draw the line to a degree.
'Shatter' style of attacks are no fixed as an entire category of attack. Kernel data structures are now hardened and locked down to a degree (though of course kernel level drivers can access these in nearly all operating systems, including windows). You cant control, message, or inject from a lower privileged window to a higher privileged window, even if they're operating on the same real or virtual desktop.
Services can now run MAC (Mandatory Access Control) style, where the service is only allowed to modify/access very restricted parts of the file system and registry.
There arent alot of big holes left, at least that I'm aware of.
The vast, vast majority of successful attacks on windows nowadays are either run by the user (ie, convinced to install that new code to view that porn) or off unpatched vulns (usually by people who have chosen not to patch).
This again proves why open source development methods are better - you're not locked into one vendor providing a driver and saying "stuff you". This is definitely a case where open source model works much better in practice.
The open-source drivers tend to be simple, stable, and tend to work for many products. And they get updated (mostly) with kernel updates.
There is a flip side though, in that generally the open source drivers work well for the common functionality, but dont work for some of the advanced features. Printers and scanners particularly, less so for some sound cards with fancy features.
Some hardware vendors have started getting smart about this. Intel and Nvidia have a small number of drivers that work across many of their products. HP even has universal printer drivers that work (at least with base functionality) across a great deal of their printer lines.
why should I pay $60 for support for a bug fix? So you read enough to get that, but not the immediately followed response from the MS guy that SP1 support calls are FREE. There is no charge to get SP1 install support from MS.
nd remember a lot of these are (a) early adopters and (b) technically proficient enough to post on the blog Are you kidding? How could you read those posts and think any of them (including the MS guy) are technically proficient. They're almost all idiots, at least based on their postings.
Cant anyone bother to read what they're posting about?
There are NO problems with ANY hardware.
There are certain OLDER versions of drivers for certain hardware that if present, will stop sp1 from installing, to prevent bluescreens and the like from shoddy drivers.
Surely, Microsoft could make their service pack update more modular, and install everything else other than the problematic driver related software? I dont think you understand the situation.
The problem is not, at least in some of these cases, with windows. The problem is that the driver software relies on a specific and exact in-memory kernel data structures. It assumes that they're always in the exact same place.
These structures and layout change in sp1, so some of these drivers would literally instantly and completely clobber the OS.
In a situation like this, the driver software is basically broken malware, written by shoddy developers. MS cant do anything in that case except block the drivers.
You do understand that there's no problem with any of the hardware listed and SP1, right?
The problem is with older versions of the drivers.
Just scan your machine for all of the files listed in the KB article, then check the version on each. If any are too old, get the newer versions.
There are reportedly some of these that arent supported or updated by the OEMs anymore, but there's not much MS can do about this. At least some of these blocked drivers are doing terrible, terrible things like accessing and modifying in-memory kernel data structures. These data structures are changed in sp1, and MS gives strong and specific guidance to never, never do that.
Then we can get into the argument that a flakey driver should not be able to send your OS packing in fear. This is true of any kernel level driver on all mainstream operating systems. They all have direct access to kernel memory structures.
If you mean whether a driver is signed or not, then yes, there is a small amount of money ($200) to purchase a code-signing cert. But that money doesnt go to MS, it goes to Verisign, Thawte, Comodo, etc.
There are some programs, like the WHQL that do require (iirc) payment for certification.
But even that isnt paying microsoft, its paying one of several other companies to do the certification.
I shouldn't have to re-elevate each time if I'm deleting cruft out of the program folders. Trouble is, if they made it simple, people would just setup explorer to run with elevation, elevate once after login, and then malware would ride on all these computers running with an elevated explorer by default. If you're doing something like this, launch a new explorer.exe as admin, or launch cmd.exe as admin, and do your stuff from there.
You're actually protected from malware crossing from the non-admin explorer.exe to the admin explorer.exe. There are significant protections in Vista to block exactly that scenario. You cant do message or IPC from a lower priv'd window to a higher priv'd one.
But why is it that a device that was supported under Vista isn't supported under Vista SP1? Because of any number of things:
1. The driver writer was doing something that was specifically not supported in windows, but for some reason didnt actually fail in the RTM version, but did fail in the SP1 version, as things are tightened up. The driver writer did something wrong, should MS continue to support broken drivers?
2. The driver writer was relying on an implementation bug in Vista RTM, which was fixed in SP1.
3. The driver writer was directly modifying kernel data structures in memory. These data structures can change with new service packs. If allowed to continue, they would basically clobber other random memory structures.
It just goes on like that. This is software business 101 stuff, that Microsoft has been dealing with for over a decade.
The reality is, most driver authors (and most ISVs in general) are utterly and completely incompetent. They dont read or follow the guidance MS puts out on how to make an application or driver function correctly in windows. They dont follow best practices.
In the bad old days, MS used to put hacks and special cases in their operating systems to support buggy applications. With Vista, and especially with the x64 version of Vista, they've been alot less lenient.
This is good in the long run because it forces IHVs and ISVs to clean up their act. But it can cause some pain in the short run.
Are you saying that Ubuntu can have 'part' of the kernel at 2.6.12 and 'part' of the kernel at 2.6.14? (I'm just making up numbers, but the point stands)
In every case that I've seen, the problem isnt with any hardware, but with certain versions of the drivers.
So for example, Realtek Audio driver rtkaud.sys version 1.9.1 and older wont work. But newer versions of the drivers will, if your hardware vendor will release them.
Because they've put a huge amount of pre-install checks, scans, and analysis to try to prevent SP1 from breaking things.
Go read the notes up on microsoft.com about this.
It scans your whole machine for known drivers that cause problems. It scans the registry for known corruptions that cause install failures.
It will often install 3 rounds of software, including sp1, to round out all the potential issues.
Basically, they're doing their due diligence here and have the installer and windows update take a bunch of trouble and try very very hard not to cause any known breakage. The cost for this is the time and disk thrashing.
You may or may not like microsoft, but this kind of thing is unavoidable where you have third party driver and software creators who dont always have much of an incentive to do the right thing. I dont even think having windows be open source would help here, and may hurt, as long as driver authoring is being done by third parties.
If it was, then the driver creators would be very tempted to peek inside the code, and do terribly bad things like make assumptions and rely on internal non-exposed data structures, or other bad hacks. This kind of thing is enough of a problem with windows as closed source (due to debuggers). It could be worse.
I couldn't even install a AV update (daily) without having to approve it several times. You do realize that is a problem with your choice of A/V vendor, right?
I'm using Sophos here, and both standalone and in the centrally managed version, there's an auto-update service that runs as its own user identity, and deals with updates by itself, requiring no user interaction whatsoever.
Heck, it even happens when no one is logged in.
When you run into situations like what you're experiencing, its because the vendor was lazy or sloppy, and did things the easy way, rather than the right way.
PAE has been in windows since at least NT4, maybe earlier.
On the XP desktop (x86 version), MS made a support choice to not support PAE, due to (their claim) driver issues. If you'll remember, early versions of XP supported PAE on the desktop, but then was shut off around XP SP2. MS claim is that a large percentage of drivers for consumer hardware were not built to handle both PAE and non-PAE environments, and so caused system crashes. Therefore, as a tradeoff between scalability and reliability, they chose the latter.
You've got it backwards. A design like this is intended to be almost perfectly resilient to crashing individual processes and the like.
It's not clear to me by the reading I've done what the parallel is to explorer.exe in Singularity, but given the micro-kernel approach, I feel pretty confident saying that it would not bring down the whole machine.
No one wants this to run in the real world. Thats not what its for.
It's a research project. It's there to test and prove some new ideas in operating systems.
My guess is that they used a.net language variant (C#/Spec#/Sing#) due to productivity gains possible. Also, the Spec#/Sing#, at least as I understand it, provides a great deal of language level contracts, verifiability, and provability.
Again, for a research project, that stuff is important.
To your more general point... people go to new runtimes/languages/platforms because of the tradeoffs. What is commonly called 'managed code' helps to eliminate several entire classes of bugs, but also has a cost. The common cost is in performance, or at least potential performance.
For certain types of projects, having a platform that allows contracts as first-class-citizens, and is more inherently verifiable, or provable, can be quite nice. Other types of projects do better with a looser language, like a modern scripting language, Python or Ruby, etc.
I am appalled at how many people dont get this, but I'll say it again.
The US California non-profit organization OSI does not own, copyright, or hold a trademark on the term 'open source'.
They are also not a government or dictionary in that they get to arbitrarily redefine words and mandate that they are the new definition for the entire human race.
The term 'open source' has been around alot longer than the OSI org, and had the same meaning then as it does now. It means the source is availble to read/view.
For a pretty substantial portion of our industry, the term 'open source' used in this context is accurate.
The term 'open source' is a descriptive phrase that to most folks will mean the source is viewable or available.
But you're confusing whether the source is open or available, with whether it has an OSI approved open source license.
The two are not the same. OSI does not own the term 'open source'.
And only a tiny, tiny, extremely miniscule fraction of the population is so caught up in these near-religious issues to be confused by this.
'open source' != software licensed under an OSI approved license
They're not the same thing.
And neither of those are the same thing as the broader community and set of principles generally labelled FOSS. Though even that is so broad and ripe for different interpretations as to be specifically meaningless.
And as others have posted several times so far in response to you and this same silly meme: a non-profit group based in california doesnt 'own' the two words used together: 'open source'.
It's a descriptive phrase that has perfectly valid and understandable meaning without your religious overtones.
Let me repeat it again, so that its clear: OSI does not own, copyright, or have the trademark to the phrase 'open source'. In addition, that group is not in a position to unilaterally re-define what those two words mean for the entire human race, and thereby trump all other definitions.
If you cannot tell the difference between a descriptive phrase like 'open source' and a voluntary label used by a california non-profit that people can use as a marker that a software's LICENSE meets a certain agreed upon criteria... then you probably shouldnt be commenting on it. Particularly not in such a self-righteous tone.
Why are so many on/. struggling with this sentence today. It's clear as day.
The sentence clearly states that 75-80% of php developers develop on windows. But then 2 sentences later it says that the majority deploy to unix or linux.
Anybody think the real agenda here is for Zend to better monetize PHP? You do know that Zend PHP Core is free, right? You can pay Zend money if you want, but its only for support.
There is also Zend Framework, which is a big set of value-added packaging and large-deploy/enterprise features. That costs, but you're paying for the integrated packaging and support, not that you cant do those features any other way for free.
Slashdot Mirror
That is a well known one. You have a couple options:
1. Ask your network guys to move off the proprietary Cisco concentrators and use a standards based VPN server. Then you can use the Windows VPN client, and it will 'just work'.
2. Tell your Cisco rep to get off their asses and upgrade the client.
FWIW, the cisco vpn client has a history of problems on windows. I dont think whoever cisco farms that work out to is very good, at least not on that platform.
What specific legacy problems are you referring to?
I'm not aware of any significant ones still remaining.
MS has really made the break with past legacy security issues on Vista, and almost completely on x64 versions of Vista and server 2008. Thats where MS has chosen to draw the line to a degree.
'Shatter' style of attacks are no fixed as an entire category of attack. Kernel data structures are now hardened and locked down to a degree (though of course kernel level drivers can access these in nearly all operating systems, including windows). You cant control, message, or inject from a lower privileged window to a higher privileged window, even if they're operating on the same real or virtual desktop.
Services can now run MAC (Mandatory Access Control) style, where the service is only allowed to modify/access very restricted parts of the file system and registry.
There arent alot of big holes left, at least that I'm aware of.
The vast, vast majority of successful attacks on windows nowadays are either run by the user (ie, convinced to install that new code to view that porn) or off unpatched vulns (usually by people who have chosen not to patch).
The open-source drivers tend to be simple, stable, and tend to work for many products. And they get updated (mostly) with kernel updates.
There is a flip side though, in that generally the open source drivers work well for the common functionality, but dont work for some of the advanced features. Printers and scanners particularly, less so for some sound cards with fancy features.
Some hardware vendors have started getting smart about this. Intel and Nvidia have a small number of drivers that work across many of their products. HP even has universal printer drivers that work (at least with base functionality) across a great deal of their printer lines.
And what drivers for what hardware are those, Mr. Coward?
I've looked at the list of specifically blacklisted drivers, and there are no MS drivers listed there.
Cant anyone bother to read what they're posting about?
There are NO problems with ANY hardware.
There are certain OLDER versions of drivers for certain hardware that if present, will stop sp1 from installing, to prevent bluescreens and the like from shoddy drivers.
It doesnt.
Post as plain text, and it comes out fine (like this post).
You can even use simle HTML codes in plain old text posting, like Microsoft.
The problem is not, at least in some of these cases, with windows. The problem is that the driver software relies on a specific and exact in-memory kernel data structures. It assumes that they're always in the exact same place.
These structures and layout change in sp1, so some of these drivers would literally instantly and completely clobber the OS.
In a situation like this, the driver software is basically broken malware, written by shoddy developers. MS cant do anything in that case except block the drivers.
The problem is with older versions of the drivers.
Just scan your machine for all of the files listed in the KB article, then check the version on each. If any are too old, get the newer versions.
There are reportedly some of these that arent supported or updated by the OEMs anymore, but there's not much MS can do about this. At least some of these blocked drivers are doing terrible, terrible things like accessing and modifying in-memory kernel data structures. These data structures are changed in sp1, and MS gives strong and specific guidance to never, never do that. Then we can get into the argument that a flakey driver should not be able to send your OS packing in fear. This is true of any kernel level driver on all mainstream operating systems. They all have direct access to kernel memory structures.
How do you figure?
If you mean whether a driver is signed or not, then yes, there is a small amount of money ($200) to purchase a code-signing cert. But that money doesnt go to MS, it goes to Verisign, Thawte, Comodo, etc.
There are some programs, like the WHQL that do require (iirc) payment for certification.
But even that isnt paying microsoft, its paying one of several other companies to do the certification.
You're actually protected from malware crossing from the non-admin explorer.exe to the admin explorer.exe. There are significant protections in Vista to block exactly that scenario. You cant do message or IPC from a lower priv'd window to a higher priv'd one.
That exists. Its called the standalone installer.
The standalone doesnt care if you have incompatible drivers. You're assumed to have figured it out and accept the risks if you install it that way.
So if you want to risk it, use the standalone installer. If you dont, use windows update.
1. The driver writer was doing something that was specifically not supported in windows, but for some reason didnt actually fail in the RTM version, but did fail in the SP1 version, as things are tightened up. The driver writer did something wrong, should MS continue to support broken drivers?
2. The driver writer was relying on an implementation bug in Vista RTM, which was fixed in SP1.
3. The driver writer was directly modifying kernel data structures in memory. These data structures can change with new service packs. If allowed to continue, they would basically clobber other random memory structures.
It just goes on like that. This is software business 101 stuff, that Microsoft has been dealing with for over a decade.
The reality is, most driver authors (and most ISVs in general) are utterly and completely incompetent. They dont read or follow the guidance MS puts out on how to make an application or driver function correctly in windows. They dont follow best practices.
In the bad old days, MS used to put hacks and special cases in their operating systems to support buggy applications. With Vista, and especially with the x64 version of Vista, they've been alot less lenient.
This is good in the long run because it forces IHVs and ISVs to clean up their act. But it can cause some pain in the short run.
I'm not real clear on your statements.
Are you saying that Ubuntu can have 'part' of the kernel at 2.6.12 and 'part' of the kernel at 2.6.14? (I'm just making up numbers, but the point stands)
Somehow I doubt if that is actually possible.
Update your drivers if the vendor has new ones.
In every case that I've seen, the problem isnt with any hardware, but with certain versions of the drivers.
So for example, Realtek Audio driver rtkaud.sys version 1.9.1 and older wont work. But newer versions of the drivers will, if your hardware vendor will release them.
Because they've put a huge amount of pre-install checks, scans, and analysis to try to prevent SP1 from breaking things.
Go read the notes up on microsoft.com about this.
It scans your whole machine for known drivers that cause problems. It scans the registry for known corruptions that cause install failures.
It will often install 3 rounds of software, including sp1, to round out all the potential issues.
Basically, they're doing their due diligence here and have the installer and windows update take a bunch of trouble and try very very hard not to cause any known breakage. The cost for this is the time and disk thrashing.
You may or may not like microsoft, but this kind of thing is unavoidable where you have third party driver and software creators who dont always have much of an incentive to do the right thing. I dont even think having windows be open source would help here, and may hurt, as long as driver authoring is being done by third parties.
If it was, then the driver creators would be very tempted to peek inside the code, and do terribly bad things like make assumptions and rely on internal non-exposed data structures, or other bad hacks. This kind of thing is enough of a problem with windows as closed source (due to debuggers). It could be worse.
I'm using Sophos here, and both standalone and in the centrally managed version, there's an auto-update service that runs as its own user identity, and deals with updates by itself, requiring no user interaction whatsoever.
Heck, it even happens when no one is logged in.
When you run into situations like what you're experiencing, its because the vendor was lazy or sloppy, and did things the easy way, rather than the right way.
PAE has been in windows since at least NT4, maybe earlier.
On the XP desktop (x86 version), MS made a support choice to not support PAE, due to (their claim) driver issues. If you'll remember, early versions of XP supported PAE on the desktop, but then was shut off around XP SP2. MS claim is that a large percentage of drivers for consumer hardware were not built to handle both PAE and non-PAE environments, and so caused system crashes. Therefore, as a tradeoff between scalability and reliability, they chose the latter.
You've got it backwards. A design like this is intended to be almost perfectly resilient to crashing individual processes and the like.
It's not clear to me by the reading I've done what the parallel is to explorer.exe in Singularity, but given the micro-kernel approach, I feel pretty confident saying that it would not bring down the whole machine.
No one wants this to run in the real world. Thats not what its for.
.net language variant (C#/Spec#/Sing#) due to productivity gains possible. Also, the Spec#/Sing#, at least as I understand it, provides a great deal of language level contracts, verifiability, and provability.
... people go to new runtimes/languages/platforms because of the tradeoffs. What is commonly called 'managed code' helps to eliminate several entire classes of bugs, but also has a cost. The common cost is in performance, or at least potential performance.
It's a research project. It's there to test and prove some new ideas in operating systems.
My guess is that they used a
Again, for a research project, that stuff is important.
To your more general point
For certain types of projects, having a platform that allows contracts as first-class-citizens, and is more inherently verifiable, or provable, can be quite nice. Other types of projects do better with a looser language, like a modern scripting language, Python or Ruby, etc.
I am appalled at how many people dont get this, but I'll say it again.
The US California non-profit organization OSI does not own, copyright, or hold a trademark on the term 'open source'.
They are also not a government or dictionary in that they get to arbitrarily redefine words and mandate that they are the new definition for the entire human race.
The term 'open source' has been around alot longer than the OSI org, and had the same meaning then as it does now. It means the source is availble to read/view.
For a pretty substantial portion of our industry, the term 'open source' used in this context is accurate.
The term 'open source' is a descriptive phrase that to most folks will mean the source is viewable or available.
But you're confusing whether the source is open or available, with whether it has an OSI approved open source license.
The two are not the same. OSI does not own the term 'open source'.
And only a tiny, tiny, extremely miniscule fraction of the population is so caught up in these near-religious issues to be confused by this.
'open source' != software licensed under an OSI approved license
They're not the same thing.
And neither of those are the same thing as the broader community and set of principles generally labelled FOSS. Though even that is so broad and ripe for different interpretations as to be specifically meaningless.
And as others have posted several times so far in response to you and this same silly meme: a non-profit group based in california doesnt 'own' the two words used together: 'open source'.
... then you probably shouldnt be commenting on it. Particularly not in such a self-righteous tone.
It's a descriptive phrase that has perfectly valid and understandable meaning without your religious overtones.
Let me repeat it again, so that its clear: OSI does not own, copyright, or have the trademark to the phrase 'open source'. In addition, that group is not in a position to unilaterally re-define what those two words mean for the entire human race, and thereby trump all other definitions.
If you cannot tell the difference between a descriptive phrase like 'open source' and a voluntary label used by a california non-profit that people can use as a marker that a software's LICENSE meets a certain agreed upon criteria
Why are so many on /. struggling with this sentence today. It's clear as day.
The sentence clearly states that 75-80% of php developers develop on windows. But then 2 sentences later it says that the majority deploy to unix or linux.
There is also Zend Framework, which is a big set of value-added packaging and large-deploy/enterprise features. That costs, but you're paying for the integrated packaging and support, not that you cant do those features any other way for free.
They've actually struck a good balance, I think.