Well it's good for us down here in Texas. Now that they've been down here they know we carry guns. Then you take into account that most people down here view G W Bush as a supreme intellectual.
So RIAA come on and bring some more of those Yankee subpeeners, we got more bullets than you've got paper.
It would be nice if more of the C++ books and name the language would concentrate more on preventing these types of errors.
I thought I had escaped or prevented accidental or intentional SQL Injection from an application when I first started out. Imagine my horror when I found out that users were entering '--' in there input and I didn't realize that it was a comment demarcation in SQL.
So I have been always on the lookout for books that will help me understand the pitfalls. Where are they?
Because it seems like most people end up building these routines by trial and error. I can only recall one book that said this is how you prevent a buffer overflow.
]I happen to have worked in an industry that requires perfect coding. [...] The industry I'm referring to is the chip industry. [...] Hardware companies can't afford a single mistake because once the chip goes to fab, that's it. No patches like software, no version 1.0.1.
I've worked in chip manufacturing also and I know that they sometimes get it wrong. I remember that we had a lot go through and it had zero yield. After we analyzed the photo plates and each step we found that the emitter/base/collectors were not aligned.
I've also seen roughly the same type of problem with CMOS and BiCMOS structures where the photoplates had gates misaligned or other structures at the metal levels.
So there are some version 1.0.1 in programs and there are changes to mask levels to enhance yield.
I don't strictly believe this is the case. Microsoft sells to Educational Institutions at a deep discount. So to them it doesn't make sense to go through the hassle of switching to another OS. Most of the places where I've seen *nix used is in high end computing, not on the servers or desktops. Most of the IT culture (the maintainers) is a MS culture. The *nix systems are maintained by a completely different group.
They wouldn't dare. We have been training our young ones for space battles for over 5 years now. I mean, what country would want to take on a country in space that has 50000 masters of Halo.
You are 100% correct, if you completely ignore corporate America using Windows.
Lets take a large corporation as an example and look at the costs you ignored:
Dozens of in house Windows apps, which would either need to be re-written or at least fully tested again in an emulation environment.
This is ligitimate, but could be dealt with by using an VM environment for minimal cost in a number of cases. Training for the end users for a new OS.
This isn't a problem. Most users don't realize I use Linux and the transition from W2K to XP gave a number of them apoplexy. Training for the end users for a new Office suite.
Once again this is not a real problem. Many are totally confused by Office 2007, so much so that we started uninstalling and replacing with Office 2000 or Office 2003. Training for the end users for any critical applications.
This is going to happen no matter what. We have an accounting department that still uses software that only runs on NT and is no longer supported.
A new desktop management software roll-out for IT.
Any server changes for IT.
Training for IT in the new OS/Suite/Apps/Management software/servers.
This can be handled with classes costing not much more than the classes you are currently sending your IT department to take for MS software. Plus they are more informative. Much more informative.
Time to convert from the old systems to the new ones.
This depends on staff involved and level of planning. But I have seen rollouts to thing like SAS and Oracle and upgrades of MS products which were total fiascos. In some cases these problems were not resolved completely for a year. In one case there were 2 different companies with the same product being rolled out with vendor support. 3 months into it they realized that the vendor couldn't help and the 2 companies teamed up and hired their own experts to resolve the issues. Took a full year to resolve and get back to where they were prior to rollout. So I don't think a rollout of Linux will be that big a disaster, unless you really don't plan it. and a few dozen problems that will spring up during the transition.
Now, after the millions spent on the above, you can wait a few years for the ROI in your new MS free environment.
Yes problems do spring up in the transition, some are unforeseen, but they are usually handled quite quickly, within a few hours, depending on the preparedness of the support staff.
ROI, the cost of planning and testing was cheaper than a new MS license agreement and product rollout. For us it also allowed greater flexibility and options for expansions, because it was much cheaper. Within a year we had recouped our cost. We also decreased our downtime due to patch installation. I don't mean the time for installing patches, but the downtime incurred when unexpected things happen on newly patched systems.
But the applications which ran entirely on Windows were the main headache, but once we got those resolved our customers were satisfied by the outcome. For many of them we put them on a centralized high end server, which allowed their apps to run faster. Now I bet I couldn't get those apps back on desktops.
But I agree there are some apps you just can't move off of a Windows desktop platform, and if you can't find a way to work around these then you are just out of luck.
Currently there is nothing that would indicate that the Samba team is looking to replace the AD server. So far what I have seen is more interoperability of Samba servers with AD.
We are currently looking at a future replacement for our Samba/LDAP PDC's and can't find an open source variant.
So if we have to replace the Samba PDC's with AD servers, we are also probably going to replace our Member servers with MS servers. Because once you get over the initial financial pain of connection licenses, there is very little point in continuing to fight against $300 per server licensees for file servers.
Once you've shelled out $10,000 dollars for AD servers and connections, You might as well shell out another $1,500 for servers licenses to reduce the heterogenous environment cost.
The rest of the cost would end up be swallowed in quarterly costs and would never show up as a cost related to working in a MS environment.
Yes, I would reiterate that there is no way to completely stop this from happening. Part of our security is based on trust. If someone has or is violating that trust then we want to know who and how often.
I think what we want to do now is find out if someone is violating that trust and then deal with it appropriately.
I currently don't trust anyone, and would prefer a solution that can be quietly implemented.
If I do find evidence that documents are leaked, then I would call in other authorities to further investigate.
The document in question had somewhere in the neighborhood of 16 keypoints. I spotted 13 key points. So the document either came from one of 3 sources (companies). Within our company it would have probably only come from an upper level manager, but it is possible that some other people working in the production phase could have released the document.
The release of the document in question probably only has civil issues involved. But we have other documents that if released would carry much heavier penalties. These later documents or proof of dispersion of these later documents would not show up in civilian products.
So what I'm trying to determine is if our documents are being dispersed. What I have discussed with one manager is creating an update to certain documents and see if they do show up somewhere else. What we would like to know is if documents are going out. If they are what type of documents and to where.
Depending on what type of documents involved we would either terminate suspected employee or call in law enforcement for further investigation.
Well it's good for us down here in Texas. Now that they've been down here they know we carry guns. Then you take into account that most people down here view G W Bush as a supreme intellectual.
So RIAA come on and bring some more of those Yankee subpeeners, we got more bullets than you've got paper.
We just retired our last Windows 3.1 box. God knows how many years it had worked. I even forgot we had it until the hardware crashed.
It would be nice if more of the C++ books and name the language would concentrate more on preventing these types of errors.
I thought I had escaped or prevented accidental or intentional SQL Injection from an application when I first started out. Imagine my horror when I found out that users were entering '--' in there input and I didn't realize that it was a comment demarcation in SQL.
So I have been always on the lookout for books that will help me understand the pitfalls. Where are they?
Because it seems like most people end up building these routines by trial and error. I can only recall one book that said this is how you prevent a buffer overflow.
]I happen to have worked in an industry that requires perfect coding. [...] The industry I'm referring to is the chip industry. [...] Hardware companies can't afford a single mistake because once the chip goes to fab, that's it. No patches like software, no version 1.0.1.
I've worked in chip manufacturing also and I know that they sometimes get it wrong. I remember that we had a lot go through and it had zero yield. After we analyzed the photo plates and each step we found that the emitter/base/collectors were not aligned.
I've also seen roughly the same type of problem with CMOS and BiCMOS structures where the photoplates had gates misaligned or other structures at the metal levels.
So there are some version 1.0.1 in programs and there are changes to mask levels to enhance yield.
I don't strictly believe this is the case. Microsoft sells to Educational Institutions at a deep discount. So to them it doesn't make sense to go through the hassle of switching to another OS. Most of the places where I've seen *nix used is in high end computing, not on the servers or desktops. Most of the IT culture (the maintainers) is a MS culture. The *nix systems are maintained by a completely different group.
They wouldn't dare. We have been training our young ones for space battles for over 5 years now. I mean, what country would want to take on a country in space that has 50000 masters of Halo.
We can tell from DNA if microbes were descendants of ones sent by Russia.
What would be really cool though is if they sent some gerbils up there, with there own rover and went and parked it beside one of ours.
I can just see us snapping all these pictures of gerbils. Millions of dollars in equipment to take pictures of gerbils.
You're a perfect botnet host. My hats off to you.
For the CS engineering ladder maybe. But I know of quite a few that have topped over 200k. They work for chip manufacturers.
You are 100% correct, if you completely ignore corporate America using Windows.
Lets take a large corporation as an example and look at the costs you ignored:
Dozens of in house Windows apps, which would either need to be re-written or at least fully tested again in an emulation environment.
This is ligitimate, but could be dealt with by using an VM environment for minimal cost in a number of cases.
Training for the end users for a new OS.
This isn't a problem. Most users don't realize I use Linux and the transition from W2K to XP gave a number of them apoplexy.
Training for the end users for a new Office suite.
Once again this is not a real problem. Many are totally confused by Office 2007, so much so that we started uninstalling and replacing with Office 2000 or Office 2003.
Training for the end users for any critical applications.
This is going to happen no matter what. We have an accounting department that still uses software that only runs on NT and is no longer supported.
A new desktop management software roll-out for IT. Any server changes for IT. Training for IT in the new OS/Suite/Apps/Management software/servers.
This can be handled with classes costing not much more than the classes you are currently sending your IT department to take for MS software. Plus they are more informative. Much more informative.
Time to convert from the old systems to the new ones.
This depends on staff involved and level of planning. But I have seen rollouts to thing like SAS and Oracle and upgrades of MS products which were total fiascos. In some cases these problems were not resolved completely for a year. In one case there were 2 different companies with the same product being rolled out with vendor support. 3 months into it they realized that the vendor couldn't help and the 2 companies teamed up and hired their own experts to resolve the issues. Took a full year to resolve and get back to where they were prior to rollout. So I don't think a rollout of Linux will be that big a disaster, unless you really don't plan it.
and a few dozen problems that will spring up during the transition.
Now, after the millions spent on the above, you can wait a few years for the ROI in your new MS free environment.
Yes problems do spring up in the transition, some are unforeseen, but they are usually handled quite quickly, within a few hours, depending on the preparedness of the support staff.
ROI, the cost of planning and testing was cheaper than a new MS license agreement and product rollout. For us it also allowed greater flexibility and options for expansions, because it was much cheaper. Within a year we had recouped our cost. We also decreased our downtime due to patch installation. I don't mean the time for installing patches, but the downtime incurred when unexpected things happen on newly patched systems.
But the applications which ran entirely on Windows were the main headache, but once we got those resolved our customers were satisfied by the outcome. For many of them we put them on a centralized high end server, which allowed their apps to run faster. Now I bet I couldn't get those apps back on desktops.
But I agree there are some apps you just can't move off of a Windows desktop platform, and if you can't find a way to work around these then you are just out of luck.
Currently there is nothing that would indicate that the Samba team is looking to replace the AD server. So far what I have seen is more interoperability of Samba servers with AD.
We are currently looking at a future replacement for our Samba/LDAP PDC's and can't find an open source variant.
So if we have to replace the Samba PDC's with AD servers, we are also probably going to replace our Member servers with MS servers. Because once you get over the initial financial pain of connection licenses, there is very little point in continuing to fight against $300 per server licensees for file servers.
Once you've shelled out $10,000 dollars for AD servers and connections, You might as well shell out another $1,500 for servers licenses to reduce the heterogenous environment cost.
The rest of the cost would end up be swallowed in quarterly costs and would never show up as a cost related to working in a MS environment.
I think MS, did an excellent job of securing Vista against hackers. I haven't heard of anyone pirating Vista.
Some say Vista sucks, but it was a strategy against piracy that fueled the final product.
Yes, I would reiterate that there is no way to completely stop this from happening. Part of our security is based on trust. If someone has or is violating that trust then we want to know who and how often.
I think what we want to do now is find out if someone is violating that trust and then deal with it appropriately.
I currently don't trust anyone, and would prefer a solution that can be quietly implemented.
If I do find evidence that documents are leaked, then I would call in other authorities to further investigate.
The document in question had somewhere in the neighborhood of 16 keypoints. I spotted 13 key points. So the document either came from one of 3 sources (companies). Within our company it would have probably only come from an upper level manager, but it is possible that some other people working in the production phase could have released the document.
The release of the document in question probably only has civil issues involved. But we have other documents that if released would carry much heavier penalties. These later documents or proof of dispersion of these later documents would not show up in civilian products.
So what I'm trying to determine is if our documents are being dispersed. What I have discussed with one manager is creating an update to certain documents and see if they do show up somewhere else. What we would like to know is if documents are going out. If they are what type of documents and to where.
Depending on what type of documents involved we would either terminate suspected employee or call in law enforcement for further investigation.