The amount of SPAM hasn't dropped, the amount being DELIVERED has. I get the reports from my SPAM Filter provider, and basically they show that the amount of SPAM hitting all the hosted domains we have is doing way UP not DOWN. Just the amount of that that is getting delivered is going down. The Symantec report is not clear as to what they are actually basing their numbers on, but it is probably just on their install base, and the amount of SPAM REACHING the install base is lower as more providers have things in place to block SPAM before it gets to the servers. So NO the amount of actual SPAM is still rising.Just the amount being delivered to the Inbox is lower. These are not equivalent.
Actually, IBM DID market OS/2 well. OS/2's demise was brought about by MicroSoft, who had signed agreements to help IBM develop OS/2 Warp 4.0.
After getting copies of most of the source code, MicroSoft some how came out on top in a court battle as to who owned the code, (of which most came from IBM) which became the code base for NT.
Take a close look, and you will see lot's of executables relying on things from os2.
Microsoft just had better lawyers, and at the time, deeper pockets.
It seems no one has seriously addressed the question as posted: How to get the three groups of people working together, not how to get the three groups of OS/machines working together.
To manage such a project takes a proliferate understanding of each culture. I don't profess to understand the windows bunch, other than there seems to be a reliance on GUI. When it comes to nuts and bolts: Mainframe world has lots of compiled languages (Cobol, JCL, etc.) These compiled languages are routinely "improved"?upon using assembly. So most Mainframers I know, are very nuts and bolts type people, who dig deeper than is required, so that if something goes wrong, they are prepared to fix it,and are by nature of the beast forced to follow more bureaucratic guidelines. This means, coding, and testing on paper, and forced "TEST" beds. More strict adherence to "best" programming practices, with only a couple of runs needed usually for debugging. Also, it is necessary to be more willing to share info with co-workers, lest your list be the same name as someone else's and you accidentally overwrite there's with yours. There is more of a "team" mentality in the Mainframe world because of the way a mainframe is designed to run.
Mainframes require load libraries for just about everything. Each job, has to have a complete list of files in the main library.
Unix: uses a hierarchal filesystem, in which direct references can be made to the filesystem because the way the OS libraries are set up.
This allows a more interactive approach to the programming debugging process. This also makes it easier to make use of private copies of things, and less likely to "interfere" with a coworkers project. While "open source" promotes sharing of ideas, most Unix people still want to do as much as possible on their own to get credit for their hard work. While sharing of information is crucial here, it is not as required as it is in a mainframe world, so the unix person is not as disciplined in this area. He is more disciplined in follow up though as he is used to having the time to debug on the fly. This often though leads to longer project times, as the design phase is largely neglected by many (not all) unix people. I know, I'm one of them.
My take on windows people: Concepts of design are restricted to what Microsoft tells them is the way to do things, and is already available as a pre-made programming module. Sharing of information is not vital, because it's ok to overwrite someone else's copy and it's the other persons fault if there program doesn't work when you overwrite their dll.
Windows programmers I work with use the SEP field a lot. (Somebody Else's Problem). If the scope of the original project did not include the new feature request, or it doesn't already exist as an easily addable module, then it can't be done.
MicroSoft's mantra is "don't share anything, unless a profit can be made only by us."
True, there are lots of people out there who fit all 3 categories, 2 of the categories, and groups not covered. And these are stereotypes. But if you understand these stereo types, you can understand what kind of things to expect when trying to manage a diverse group as a single coherent team.
Best scenario for a group project: Let the mainframer's specify final data format, and work with Unix Gurus on protocols.
Unix gurus should define protocol and data exchange formats.
Windows people should define UI.They are closer to the end users needs.
Together they should work on how to piece it all together.
Unix guys can be used to translate necessary info from mainframe talk to PC talk and back, since unix takes lots of cues from both worlds.
The filesystem in Windows, is a strange beast. At best it is a flat representation of something that should be hierarchal. This also describes the programming mindset. Not because that is how the people work naturally, but because how they are forced to think to make the problem fit the platform.
Hmmm...even in countries where I don't know the language if the streets are claustrophobic I can find my way around. And most buildings have some sort of directory that both lets you know where you are, and where you need to go. If you don't know that already, call ahead. Hmmm...oh look, someone who new exactly where things were was able to direct me via email within a micrometer of where I needed to be.
WPS...bah. GPS...bah. A jedi needs not these things.
About them: They are making comebacks in stronger strains..do you watch the news at all?
True, the outbreaks are limited currently to areas of the world where immunizations aren't practiced..but the strands investigated have been found to be resistant to current immunization practices. All it will take to spread is for them to be able to jump more species...Not to mention the man made versions that are locked in government labs so far..until someone pisses off a government labrat.
Slashdot Mirror
The amount of SPAM hasn't dropped, the amount being DELIVERED has. I get the reports from my SPAM Filter provider, and basically they show that the amount of SPAM hitting all the hosted domains we have is doing way UP not DOWN. Just the amount of that that is getting delivered is going down. The Symantec report is not clear as to what they are actually basing their numbers on, but it is probably just on their install base, and the amount of SPAM REACHING the install base is lower as more providers have things in place to block SPAM before it gets to the servers. So NO the amount of actual SPAM is still rising.Just the amount being delivered to the Inbox is lower. These are not equivalent.
After getting copies of most of the source code, MicroSoft some how came out on top in a court battle as to who owned the code, (of which most came from IBM) which became the code base for NT.
Take a close look, and you will see lot's of executables relying on things from os2.
Microsoft just had better lawyers, and at the time, deeper pockets.
To manage such a project takes a proliferate understanding of each culture. I don't profess to understand the windows bunch, other than there seems to be a reliance on GUI. When it comes to nuts and bolts: Mainframe world has lots of compiled languages (Cobol, JCL, etc.) These compiled languages are routinely "improved"?upon using assembly. So most Mainframers I know, are very nuts and bolts type people, who dig deeper than is required, so that if something goes wrong, they are prepared to fix it,and are by nature of the beast forced to follow more bureaucratic guidelines. This means, coding, and testing on paper, and forced "TEST" beds. More strict adherence to "best" programming practices, with only a couple of runs needed usually for debugging. Also, it is necessary to be more willing to share info with co-workers, lest your list be the same name as someone else's and you accidentally overwrite there's with yours. There is more of a "team" mentality in the Mainframe world because of the way a mainframe is designed to run.
Mainframes require load libraries for just about everything. Each job, has to have a complete list of files in the main library.
Unix: uses a hierarchal filesystem, in which direct references can be made to the filesystem because the way the OS libraries are set up.
This allows a more interactive approach to the programming debugging process. This also makes it easier to make use of private copies of things, and less likely to "interfere" with a coworkers project. While "open source" promotes sharing of ideas, most Unix people still want to do as much as possible on their own to get credit for their hard work. While sharing of information is crucial here, it is not as required as it is in a mainframe world, so the unix person is not as disciplined in this area. He is more disciplined in follow up though as he is used to having the time to debug on the fly. This often though leads to longer project times, as the design phase is largely neglected by many (not all) unix people. I know, I'm one of them.
My take on windows people: Concepts of design are restricted to what Microsoft tells them is the way to do things, and is already available as a pre-made programming module. Sharing of information is not vital, because it's ok to overwrite someone else's copy and it's the other persons fault if there program doesn't work when you overwrite their dll.
Windows programmers I work with use the SEP field a lot. (Somebody Else's Problem). If the scope of the original project did not include the new feature request, or it doesn't already exist as an easily addable module, then it can't be done. MicroSoft's mantra is "don't share anything, unless a profit can be made only by us."
True, there are lots of people out there who fit all 3 categories, 2 of the categories, and groups not covered. And these are stereotypes. But if you understand these stereo types, you can understand what kind of things to expect when trying to manage a diverse group as a single coherent team.
Best scenario for a group project: Let the mainframer's specify final data format, and work with Unix Gurus on protocols.
Unix gurus should define protocol and data exchange formats.
Windows people should define UI.They are closer to the end users needs.
Together they should work on how to piece it all together.
Unix guys can be used to translate necessary info from mainframe talk to PC talk and back, since unix takes lots of cues from both worlds.
The filesystem in Windows, is a strange beast. At best it is a flat representation of something that should be hierarchal. This also describes the programming mindset. Not because that is how the people work naturally, but because how they are forced to think to make the problem fit the platform.
Do you have GPS in-building?
Hmmm...even in countries where I don't know the language if the streets are claustrophobic I can find my way around. And most buildings have some sort of directory that both lets you know where you are, and where you need to go. If you don't know that already, call ahead. Hmmm...oh look, someone who new exactly where things were was able to direct me via email within a micrometer of where I needed to be.
WPS...bah. GPS...bah. A jedi needs not these things.
True, the outbreaks are limited currently to areas of the world where immunizations aren't practiced..but the strands investigated have been found to be resistant to current immunization practices. All it will take to spread is for them to be able to jump more species...Not to mention the man made versions that are locked in government labs so far..until someone pisses off a government labrat.
Thank God for biohazard lockdowns!