Maybe this is a delayed reaction to the bribery scandal from a few weeks ago over the OOXML adoption and the screwup of the OOXML adoption itself. I can see where a bribery scandal that could be traced back to high-level executives could pose serious problems for MS in Europe.
More specifically, I am saying that the study has been mistitled if anything. It claims to be measuring uptime when it is really measuring administration efficiency. The study is flawed in that it is attempting to equate the two jobs when the Linux admin job = 1.5 Windows admin jobs. Since it takes more work to administer Linux, the ultimate result of the study is correct in that one person administrating Linux will be less efficient than one admin working on Windows. When an equal number of administrators (euqal number of man hours) are used in both scenarios, the Linux environment should have less uptime since there is 50% more work that needs to be done in order to achieve the same results as on the Windows side. Note however that this does not necessarily equate to one OS being "better". At some point, that extra 50% effort on the Linux side must be paid for on the Windows side as well. This may be reflected in the 3rd party software being cheaper on Linux than on Windows, or updates come to market faster on the Linux version (assuming equal effort by the vendor for both platforms).
I would say this would still hold true regardless of the number of patches released for both platforms. The author makes some correlation between the number and variation of patches to the uptime of the system. My experience with RPM and apt-get suggest that for patches to ordinary modules in Linux, these tools work as well as Windows Updates for applying patches (and takes about the same amount of effort on both platforms). It is the one-off modules and applications that require the Linux administrator to go beyond the update tools and do development work that my point above comes into play.
A more fair comparison would be a small organization that writes the ecommerce code in-house while supporting the ecommerce web sites. In this scenario, you may end up adding an extra 1.5 Windows developers to every 1 Linux developer since the Linux admin shares some of the roles that would otherwise belong to the Windows developer. It would be interesting to see where the corporate "pain" lies in this case.
Personally, I would say so. At least I would say that in an app server scenario (not just an out of the box setup), a Linux admin needs to understand their system better than a Windows admin performing the same function. In the grand sceme of things, I would say that the Linux admin will be more knoweldgeable, but due to the extra complexity of their system, they will not be as efficient in making changes to their environment.
One of the most striking things I believe the experiment shows is that not only are the operating systems different, but the administrator's job requirements are different as well.
On a Linux system, an administrator (especially a "successful" one) is expected to know how and perform compilations of software on a regular basis. This not only includes knowing how to work a compiler, but also what components to include when compiling a piece of software.
In contrast, in the Windows world, compiling and finding components is the job of the software developer. A product is not considered "finished" if an administrator needs to do something besides double-clicking on setup.exe.
In comparison, would it not be more fair to compare a Windows admin with 5 years experience to a Linux admin with 8 years of experience?
There are many products in WinWorld that do the exact same thing. They are so ubiquitous that every company of any size is expected to already have some sort of solution like this. Altris has a mature product, if you are an IBM shop, they have a propriatary product that does the same for free, and even MS has come up with 3 separate flavors of this same technology (RIS with scripts, a feature pack for SMS, and a more recent stand-alone product).
I think the "easier to deploy" angle comes from how all commerical Windows applications are expected to come in an.MSI package with command-line switches that are so common that an administrator could guess what they are without using "/?" (like "--help" for you *nix people).
Ease of deployment has very little to do with quality of overall code. I would argue that a dummy-proof point and click GUI setup for packaging will tend to be superior to a heavily scripted installation when admins are in a hurry (and who isn't these days). Case-in-point, how many typos can you count in this thread? Now extrapolate these typos to a script or set of scripts that install multiple packages. Sure, you will eventually get all of the bugs worked out of your script, but how much more productive could you have been if debugging was not necessary?
Instead of "Graduating from high school" at grade level 12, have students leave high school with:
Grammer - level 7
math - level 10
history - level 12
science - level 11
etc.
Some basic level of each subject should be presented at the lower (K - 6) levels, but high school should more accurately reflect what the student has learned. This information can then be used as either a starting point to craft a college education or an indication of compentency in future endevors and career choices.
Not long ago, we released a contractor because she put a number of things and places on her resume that other contractors in this company could verify/deny by using their contacts at previous jobs.
Apparently, one of them even said "I wish you would have asked me this before you hired her so I could have saved you the trouble." It has not been ten years, but bad impressions can last a lifetime.
I work for a company that believes that a manager does not need to know anything about the subject he is managing. The result is: technicians who produce must be salesmen, as well as highly technical.
Since the manager does not know what his people are doing, he relies on the best pitch proposed by his subordinates.
In one particualr case I know of, the manager defers a lot of decisions to the director who is technical and has much more experience than the manager does. This frustrates the subbordinates and has led to a number of his people simply bypassing him and going directly to the director for a decision.
One advantage I see to this is that non-technical managers, in an effort to not make a career-ending-move, tend to be much more politically savy. This leads to the group as a whole to getting more money for projects and better customer feedback than the technical managers who make the correct technical decisions themselves without consulting anyone.
There is more to this than the slip of a date on a single product.
The journaling file system has been dropped as a feature. Exchange has dropped plans to move to a new database (and I believe its release date slipped as well).
I guess the relevant question is: Does a shift in priorities from "getting new products out the door ASAP" to "get it right before release" translates into death of a company?
The way it works is it compares my finger print to a mapped print stored in its database. If there is a match, it fills in the password for me. The reader software is context sensitive, so I can use my finger print to respond to multiple password challenges.
In addtion to convience, this also allows me to use a very complicated password that I do not necessarily need to remember. If something goes wrong with this system (lose a finger or the database file used by the reader gets corrupted) I can still have my password changed through normal means as a backup plan.
I deal with a number of areas within IBM as a customer of theirs. I see two things working against their moving platforms internally.
First, I work in a Microsoft shop. IBM suplies a good deal of software to us (3270 emulator, Rational Robot, PC migration tools, etc.) and I expect IBM to support them and be experts in those areas. It would be difficult for them to provide the level of service we require while their people are trying to do their primary functions on a linux box. As an administrator, I have tried switching to a linux desktop to administer a Windows environment. With the help of Citrix, I was able to perform a great deal of my job function, but no where near all of it. I have no doubt that they are in the same boat.
In a slightly related situation, I know a few of their subject experts who have taken years to get where they are. I am sure they would not like to see all of their hard work washed away and being returned to a novice status by having their support area replaced.
Second, I see this as simple matter of time and money. Sure a mainframe support person could switch his desktop from Windows to Linux if all of his tools were available, but who has time for that? He has critical tickets to remediate. Something as trivial as switching desktops is probably not very high on his priority list. It does not matter that a high ranking offical stated that they would like to see him switch platforms. What manager wants to pay for the down-time it is going to take to make the cut-over and re-educate the user? As long as his job performance is based on other metrics, he is going to ignore the directive until it is convenient for him to follow it.
I agree that leadership is the ultimate in management. However, there is one thing that Maxwell, etc. seems to leave out. While leadership will eventually win the day in the in the general marketplace, at any given company a deft political manager will be more successful than a leader who is leading his people and trying to rise above the politics.
A railroad I know of had to manually route trains for about two to three weeks because of a couple of missed Y2K parameters. Had it not been for a few old-timers who were still around from when that was done a couple of decades ago, all of the predictions about crashes and whatever would have come true for this particular company.
The company covered up the problems in order to protect their stock price. I imagine a few other companies had similar results.
I heard on the radio that in the city where I live, a couple of prison inmates were mistakenly released due to the Y2K bug. At first I thought that was a bogus cover story, but then I remembered that I had worked with the contractor who was supposed to be in charge of the Y2K clean-up at the prison system. He was working multiple projects at that time. Appearently, he could not handle the pressure and he had a nervous breakdown in late 1999. If he did not finish (and I always assumed he did not because he was really falling behind when I was working with him, which of course increased his stress level), I could easily see this story being true.
Do I have to support it with native tools only, or are there decent third party tools to choose from?
Rather than trying to find ultra generic benchmarks that apply to all computers, try identifying benchmarks specific to the primary and secondary markets the product is targeting.
Include comparisons (briefly) to this product and other products in its secondary target market who are major players in that market. For example, if I am primarily looking at server consolidation products, blade servers might come to mind. However, an 8-way server running VMware might consider the server consolidtation market as a strong secondary market. I would like to see how they compare.
I see some potential use in specific corporate environments for specialized applications.
We are looking into putting our trouble-ticket system on a palm for PC support and we are looking at another solution for users who travel within small campus areas who need to do inventory/damage reporting on merchandise.
This would be similar to the way doctors use these things in hospitals to look up patient information.
Slashdot Mirror
Maybe this is a delayed reaction to the bribery scandal from a few weeks ago over the OOXML adoption and the screwup of the OOXML adoption itself. I can see where a bribery scandal that could be traced back to high-level executives could pose serious problems for MS in Europe.
More specifically, I am saying that the study has been mistitled if anything. It claims to be measuring uptime when it is really measuring administration efficiency. The study is flawed in that it is attempting to equate the two jobs when the Linux admin job = 1.5 Windows admin jobs. Since it takes more work to administer Linux, the ultimate result of the study is correct in that one person administrating Linux will be less efficient than one admin working on Windows. When an equal number of administrators (euqal number of man hours) are used in both scenarios, the Linux environment should have less uptime since there is 50% more work that needs to be done in order to achieve the same results as on the Windows side. Note however that this does not necessarily equate to one OS being "better". At some point, that extra 50% effort on the Linux side must be paid for on the Windows side as well. This may be reflected in the 3rd party software being cheaper on Linux than on Windows, or updates come to market faster on the Linux version (assuming equal effort by the vendor for both platforms).
I would say this would still hold true regardless of the number of patches released for both platforms. The author makes some correlation between the number and variation of patches to the uptime of the system. My experience with RPM and apt-get suggest that for patches to ordinary modules in Linux, these tools work as well as Windows Updates for applying patches (and takes about the same amount of effort on both platforms). It is the one-off modules and applications that require the Linux administrator to go beyond the update tools and do development work that my point above comes into play.
A more fair comparison would be a small organization that writes the ecommerce code in-house while supporting the ecommerce web sites. In this scenario, you may end up adding an extra 1.5 Windows developers to every 1 Linux developer since the Linux admin shares some of the roles that would otherwise belong to the Windows developer. It would be interesting to see where the corporate "pain" lies in this case.
Personally, I would say so. At least I would say that in an app server scenario (not just an out of the box setup), a Linux admin needs to understand their system better than a Windows admin performing the same function. In the grand sceme of things, I would say that the Linux admin will be more knoweldgeable, but due to the extra complexity of their system, they will not be as efficient in making changes to their environment.
One of the most striking things I believe the experiment shows is that not only are the operating systems different, but the administrator's job requirements are different as well.
On a Linux system, an administrator (especially a "successful" one) is expected to know how and perform compilations of software on a regular basis. This not only includes knowing how to work a compiler, but also what components to include when compiling a piece of software.
In contrast, in the Windows world, compiling and finding components is the job of the software developer. A product is not considered "finished" if an administrator needs to do something besides double-clicking on setup.exe.
In comparison, would it not be more fair to compare a Windows admin with 5 years experience to a Linux admin with 8 years of experience?
There are many products in WinWorld that do the exact same thing. They are so ubiquitous that every company of any size is expected to already have some sort of solution like this. Altris has a mature product, if you are an IBM shop, they have a propriatary product that does the same for free, and even MS has come up with 3 separate flavors of this same technology (RIS with scripts, a feature pack for SMS, and a more recent stand-alone product).
I think the "easier to deploy" angle comes from how all commerical Windows applications are expected to come in an .MSI package with command-line switches that are so common that an administrator could guess what they are without using "/?" (like "--help" for you *nix people).
Ease of deployment has very little to do with quality of overall code. I would argue that a dummy-proof point and click GUI setup for packaging will tend to be superior to a heavily scripted installation when admins are in a hurry (and who isn't these days). Case-in-point, how many typos can you count in this thread? Now extrapolate these typos to a script or set of scripts that install multiple packages. Sure, you will eventually get all of the bugs worked out of your script, but how much more productive could you have been if debugging was not necessary?
Instead of "Graduating from high school" at grade level 12, have students leave high school with:
Grammer - level 7
math - level 10
history - level 12
science - level 11
etc.
Some basic level of each subject should be presented at the lower (K - 6) levels, but high school should more accurately reflect what the student has learned. This information can then be used as either a starting point to craft a college education or an indication of compentency in future endevors and career choices.
Yes, but Bank of America only charges $25 for bouncing a check. Vinnie takes out a knee cap!
Granted, Vinnies clients will tend to be more careful with their finances.
Imagine if MS's honeypot became owned by a bot that brough down another company. Imagine the look in their lawyers' eyes...
I understand India is trying to develop a space program...
HR will be very busy firing all of the people thinking about porn.
Not long ago, we released a contractor because she put a number of things and places on her resume that other contractors in this company could verify/deny by using their contacts at previous jobs.
Apparently, one of them even said "I wish you would have asked me this before you hired her so I could have saved you the trouble." It has not been ten years, but bad impressions can last a lifetime.
So you can be too embarrassed to make a phone call?
I work for a company that believes that a manager does not need to know anything about the subject he is managing. The result is: technicians who produce must be salesmen, as well as highly technical.
Since the manager does not know what his people are doing, he relies on the best pitch proposed by his subordinates.
In one particualr case I know of, the manager defers a lot of decisions to the director who is technical and has much more experience than the manager does. This frustrates the subbordinates and has led to a number of his people simply bypassing him and going directly to the director for a decision.
One advantage I see to this is that non-technical managers, in an effort to not make a career-ending-move, tend to be much more politically savy. This leads to the group as a whole to getting more money for projects and better customer feedback than the technical managers who make the correct technical decisions themselves without consulting anyone.
You mean like the French?
There is more to this than the slip of a date on a single product.
The journaling file system has been dropped as a feature. Exchange has dropped plans to move to a new database (and I believe its release date slipped as well).
I guess the relevant question is: Does a shift in priorities from "getting new products out the door ASAP" to "get it right before release" translates into death of a company?
I use a fingerprint reader for a similar purpose.
The way it works is it compares my finger print to a mapped print stored in its database. If there is a match, it fills in the password for me. The reader software is context sensitive, so I can use my finger print to respond to multiple password challenges.
In addtion to convience, this also allows me to use a very complicated password that I do not necessarily need to remember. If something goes wrong with this system (lose a finger or the database file used by the reader gets corrupted) I can still have my password changed through normal means as a backup plan.
Passwords are pillow talk for you?
I deal with a number of areas within IBM as a customer of theirs. I see two things working against their moving platforms internally.
First, I work in a Microsoft shop. IBM suplies a good deal of software to us (3270 emulator, Rational Robot, PC migration tools, etc.) and I expect IBM to support them and be experts in those areas. It would be difficult for them to provide the level of service we require while their people are trying to do their primary functions on a linux box. As an administrator, I have tried switching to a linux desktop to administer a Windows environment. With the help of Citrix, I was able to perform a great deal of my job function, but no where near all of it. I have no doubt that they are in the same boat.
In a slightly related situation, I know a few of their subject experts who have taken years to get where they are. I am sure they would not like to see all of their hard work washed away and being returned to a novice status by having their support area replaced.
Second, I see this as simple matter of time and money. Sure a mainframe support person could switch his desktop from Windows to Linux if all of his tools were available, but who has time for that? He has critical tickets to remediate. Something as trivial as switching desktops is probably not very high on his priority list. It does not matter that a high ranking offical stated that they would like to see him switch platforms. What manager wants to pay for the down-time it is going to take to make the cut-over and re-educate the user? As long as his job performance is based on other metrics, he is going to ignore the directive until it is convenient for him to follow it.
I agree that leadership is the ultimate in management. However, there is one thing that Maxwell, etc. seems to leave out. While leadership will eventually win the day in the in the general marketplace, at any given company a deft political manager will be more successful than a leader who is leading his people and trying to rise above the politics.
A railroad I know of had to manually route trains for about two to three weeks because of a couple of missed Y2K parameters. Had it not been for a few old-timers who were still around from when that was done a couple of decades ago, all of the predictions about crashes and whatever would have come true for this particular company.
The company covered up the problems in order to protect their stock price. I imagine a few other companies had similar results.
I heard on the radio that in the city where I live, a couple of prison inmates were mistakenly released due to the Y2K bug. At first I thought that was a bogus cover story, but then I remembered that I had worked with the contractor who was supposed to be in charge of the Y2K clean-up at the prison system. He was working multiple projects at that time. Appearently, he could not handle the pressure and he had a nervous breakdown in late 1999. If he did not finish (and I always assumed he did not because he was really falling behind when I was working with him, which of course increased his stress level), I could easily see this story being true.
Do I have to support it with native tools only, or are there decent third party tools to choose from?
Rather than trying to find ultra generic benchmarks that apply to all computers, try identifying benchmarks specific to the primary and secondary markets the product is targeting.
Include comparisons (briefly) to this product and other products in its secondary target market who are major players in that market. For example, if I am primarily looking at server consolidation products, blade servers might come to mind. However, an 8-way server running VMware might consider the server consolidtation market as a strong secondary market. I would like to see how they compare.
I understand that the company I am contracting with was virtually given their IBM mainframes for free.
But they spent in the low double digit millions for support.
More like...
Zoom in on large building and cue sinister music.
Switch to close-up of the eeevile chopper about to make its attack run.
Suddenly, the chopper swoops in with death defying speed!
And then keeps swooping until it hits the ground!
It was launched from across the street and ran out of power before it could reach its target.
I see some potential use in specific corporate environments for specialized applications.
We are looking into putting our trouble-ticket system on a palm for PC support and we are looking at another solution for users who travel within small campus areas who need to do inventory/damage reporting on merchandise.
This would be similar to the way doctors use these things in hospitals to look up patient information.
How will I know who will use the data in the US-Visit database?
When you start receiving a hugh volume of US mail-order catalogs and other junk mail, then you will know. ;-)