More Headaches from Vista Security
Michael Cooney writes to tell us Windows Vista may have some serious headaches in store for corporate users with third-party authentication systems like VPNs. From the article: "ISVs say rewriting their code for the new architecture will produce headaches that will extend to their customers that have deployed strong authentication such as biometrics or tokens, enterprise single sign-on and a number of other systems integrated with the Windows authentication architecture."
As expected the summary on /. is just trying to be inflammatory. The real gist of the article is as follows: Vista will require some programs to be re-written, espcially ones that interfaced closely with the old operating system. Thus many authentication systems will need to be updated. It's not really unexpected or unheard of for new APIs to break old programs. So if you want to bitch about how Vista is going to make you rewrite your code go ahead (I know I am not looking forward to it), but don't pretend it is a security problem.
Philosophy.
Sadly the DRM functions in Vista is more about making the lives of intrusive spyware easier, not harder. This is because Vista has support for drivers untouchable by the users. Microsoft calls it security, i call it rootkits built into the OS. Blizzard and the rest of the pinheads will be using Microsofts DRM to make your computer a real VIP party for everyone byt yourself.
HTTP/1.1 400
The way "Windows authentication architecture" is extended in XP is very limiting - essentially you write DLL (so called GINA) that replaces part of XP log-in system and this DLL is responsible for retrieval of users credentials for Windows. However it was possible to have only single GINA installed at the same time, so if you wanted to have two security products installed - you were in trouble.
Now Vista will support new architecture for security providers with possibility of multiple providers registered at the same time. A definite improvement for users.
In fact the new architecture is not THAT different from the previous one, so the entire article is moot. Then again, it's SlashDot...
Slashdot - free anti-Microsoft propaganda 24/7
It's not "a good thing" when they change how database connection pooling works.
It used to be recommended practice to stick the db connection in the session object at session.start.
Option Pack 4 changed this behaviour. But it didn't show up until the websites you had already deployed started to get "un-reproducable" errors. The unpooled connections hung around for 30 mins after the last request for that session. Once the site got enough traffic it started killing the application. Could be 6 months, could be a year. Took a while to work that one out, much to the annoyance of my customers, and at my expense "you wrote it, it must be a bug in your code, bug fixes are covered in our agreement". Getting off the MSDN treadmill was glorious.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter