Why is it that no one ever defines their criteria in those articles? Once you do that, it becomes easy to evaluate the current apps. Here's my list.
#1. Shared email folders. I should be able to share a folder with anyone else in the company. (Totally amazing would be the ability to do so, securely, with anyone on the Internet).
#2. Shared calendars. Same as #1.
#3. Send appointments/meeting requests to people via #2.
#4. Delegation. I should be able to assign various rights to my email to other people so they can check the business crap when I'm on vacation.
#5. Alias/Roles. I should be able to send items as "webmaster" and "postmaster" and myself.
Okay, those are my 5. Anyone got anything I missed or any reason why one of those should not be there?
This is absolutely correct. Treat Linux as if it were Windows, or vice versa, and you are asking for real pain.
Which is why the only decent way to do any "study" is to set the objectives, the budget and let each team take its own approach.
Examples: 1) Build/maintain a web server that can handle 10,000 static pages a minute on a budget of $5,000.
2) Build/maintain a web server that can handle 10,000 dynamic pages a minute on a budget of $10,000.
3) Build/maintain a database server that can handle 10,000 transactions per minute on a budget of $20,000.
Then extend the maintenance of those over 2 years, 3 years, 4 years, etc. Include hardware/software upgrades.
Each team will come up with different approaches. I'm sure everyone here knows about the MindCraft "study" where a single Windows box with 4 processors and 4 NIC's was setup as a web server. But the logical approach would have been to setup 4 smaller, less expensive, boxes with better redundancy.
Yes, they should've allowed for the upgrading. The configuration control was overly stringent and caused undue breakage.
But they DID allow for upgrading.
In fact, it was part of the requirments.
But they did NOT let them upgrade when any normal person would have. They REQUIRED them to stay on SLES 8 and backport patches from SLES 9... and then later they required them to upgrade to SLES 9.
Any intelligent person would have skipped the backport process, done the upgrade when it became necessary and bypassed all the "problems" that were "found" in this "study".
If you think he's lying, then be a man and say it, don't hide behind the "MS funded it" fallacy.
He doesn't have to be lying. The fact that Microsoft funded the "study" means that you MUST look at the assumptions and process.
In the "study" in question, the Linux sysadmins were, for some reason, backporting patches from SLES 9 to SLES 8 due to the requirements of this "study".
So, no lies required, but because of the criteria chosen, Linux is far more difficult to maintain than ever in my experience.
In the original test, no non-Microsoft patches were applied on the Windows boxes.
Yet the Linux sysadmins were downloading mysql code from the mysql site and attempting to backport patches from SLES 9 to SLES 8.
From TFA today:
After the experiment, the administrators were asked on both sides if this kind of evolution of systems met with their real-world experience. They said yes, with the caveat of if they were asked to install a component that required an upgrade of GLIBC that they would likely upgrade the operating system as long as their configuration control policy allowed it.
In every one of these "studies" there is always something that the "study" requires that no intelligent person would do.
I don't care WHO the "researcher" is. Once they participate in one of those "studies", I have no respect for them anymore.
#1. Scalability. Otherwise, all of your addresses have to be searched. With.com/.org/.net, at least they can be somewhat sub-divided.
#2. Non-exclusivity. If someone in England registers a domain name for their business which only operates in England, why shouldn't someone in the US also be able to register that name under the.us TLD?.com and such were fine when the Internet was new and small and less important. But they don't scale very well. Removing them completely would reduce the scalability even more.
There are a limited number of ways to stuff a ballot box.
With a paper ballot, the easiest way to prevent that is to count the number of people who voted there (you have to give your name to vote) against the number of ballots.
In theory, the state should know who is registered to vote and it should be easy to identify that person as appearing at this station at this time. So the number of registered voters appearing at that station should equal the number of ballots collected at that station.
Which leave the ballot stuffers with the problem of getting their person to appear at multiple stations to vote. And that is solved with technology. It should be very simple to check the database of registered voters and mark off the people as they vote.
Any questionable situation (person doesn't appear in database or person's info doesn't match) can be solved by allowing them to cast a provisional ballot and giving them time to fix their data in the system. Hopefully, the number of provisional ballots would be lower than the difference in votes between the candidates so they wouldn't matter anyway.
The paper ballot doesn't have to be scanned or read.
But a percentage of the machines will have their claimed results compared to the paper ballots to verify their results.
The paper ballot is the final ballot. The paper ballot is the ballot used to verify the machines. The paper ballot is the ballot counted in a re-count.
All a computer can really do is make the initial count quicker (and possibly more accurate) and print a paper ballot that the voter can check easier (ie, prints out "YOU ARE VOTING FOR PERSON X" instead of just seeing a dot by a name).
If you cannot get a paper ballot out of the machine, the machine is worthless. You'd do better sticking to regular paper ballots.
In the specific case of this specific "study", the criteria were such that the SuSE sysadmins were required to download and install code from the mysql site and back-port patches from SLES 9 to their SLES 8 systems, themselves.
Without being allocated the time to correctly test those systems.
Meanwhile, no non-Microsoft patches were installed on the Windows boxes.
It isn't the number of patches, it is the patches themselves. I can apply a hundred patches (or more) to my Ubuntu box quickly and easily. And because 99.9% of them do not require a system reboot, I can easily test them.
This "study" was setup so that SuSE would fail. That's all there is to it.
Where did you find that information? The PDF at the website seems to be a completely different study.
The problems start at page 25. Here's the beginning:
For SLES 8, all required and recommended security patches were applied to the system. The same criteria was applied for Windows patches. These patches were applied in 1 month increments to the system. On the SuSE side, during the one year period under study, patches were released for the core components from multiple sources spanning package developers, individual contributors in the open source community, individuals and corporations. In this analysis, we only consider those patches issued by the operating system vendor (Novell/SuSE). From an enterprise management standpoint, this is the most common scenario given that the chief benefits of using an enterprise Linux distribution is the compatibility testing done by that Linux vendor on patches and the support extended to administrators. By going outside this channel for patches, both benefits are forfeited. In the period from July 1st, 2004 to June 30th 2005 there were 187 patches that were applied to the system. Of these patches, 13 affected the kernel. While kernel patches did not require an immediate reboot during installation, the majority of them need a system restart to immunize the system against a specific vulnerability. In general, patch application on SuSE proceeded well and most patches installed without error or conflict. Beginning at Milestone 1 however, some upgraded components were out of support from SLES 8 and updates for those components had to be obtained from the package distribution sites. As of Milestone 1, MySQL patches were obtained from the MySQL distribution site and as of milestone 2, glibc and directly related packages were maintained through manually applying SLES 9 patches. 3rd party component installations were performed according to the installation procedures specified by those vendors.
Get a copy of Win2K3 on your box. Create a directory that's 3 directories below the root.
Put 200,000 files in that directory (size of each file does not matter).
Now, watch the application that reads and writes files to that directory get slower and slower over time. Until you need to reboot the box.
For an instant problem, open that directory in Explorer. All of your processor speed will be eaten by the "system" process. Even after you close Explorer. Rebooting is the only thing that will clear the problem.
The key, as always with these "studies", is to find the portion where it deviates from Reality. That is, where it uses some strange definition or where the sysadmins choose some bizarre action.
In this "study", that step into UnReality begins where all systems are required to stay on the same time-line for upgrades.
This means that what would otherwise be a normal upgrade from SLES 8 to SLES 9 instead becomes a strange mix of back-porting patches from SLES 9 to SLES 8. In other examples, the sysadmins are downloading code from the glibc and mysql sites and applying it to those server WITHOUT TESTING. So, over time, the SLES systems become unstable.
Meanwhile, no non-Microsoft supplied code is applied to the Windows boxes.
Of course, the one who commissions the "study" gets to choose the criteria...
Seriously, how much "easier" will it be at the cluster level? With Linux, you don't even have to install the OS on the hard drive. It can run off of a CD.
At this level, the extra wizards and such just don't matter.
The longer your project is in the pipeline, the more likely it is that it will fail. Over time, the problem that your project is supposed to solve will mutate or become irrelevant itself and/or other "problems" will suddenly "need" to be "solved" by your project.
I am reminded of the Win9x bug that caused a failure every 49 days.
If your system is not "up" long enough to trigger a bug, is it "stable"?
If "yes", then at what point does a system become "unstable"? If I have to reboot every year? Month? Week? Day? Hour? Minute?
Or is "stable" defined in terms of "unexpected crash" and discounts any "crash" that is avoided by rebooting the system?
This is one of the reasons I like Linux. Because the system doesn't require reboots except to replace the kernel, it is easier to identify apps that are unstable AND GET THEM FIXED.
Slashdot Mirror
http://www.huhcorp.com/
"Ballistic Trajectory" is what happens when an object is given an initial thrust and completes it's motion only under the influence of gravity.
Toss a ball up and you'll see "Ballistic Trajectory" as it comes crashing to Earth at 32 feet per second squared.
Really.
I see online games that seem very "interactive". I see online stores that interact with me. What is the difference between now and "Web 2.0"?
Why is it that no one ever defines their criteria in those articles? Once you do that, it becomes easy to evaluate the current apps. Here's my list.
#1. Shared email folders. I should be able to share a folder with anyone else in the company. (Totally amazing would be the ability to do so, securely, with anyone on the Internet).
#2. Shared calendars. Same as #1.
#3. Send appointments/meeting requests to people via #2.
#4. Delegation. I should be able to assign various rights to my email to other people so they can check the business crap when I'm on vacation.
#5. Alias/Roles. I should be able to send items as "webmaster" and "postmaster" and myself.
Okay, those are my 5. Anyone got anything I missed or any reason why one of those should not be there?
There are two types of "patching".
... and opened a whole other category of exploits FOR THE OS.
1) Patches to fix code flaws in an otherwise sound security model.
2) Band-aids for a flawed security model (anti-virus updates are in this category).
Microsoft focused on "user friendly" and "easy of use" for so long to the detriment of security. And security cannot be retro-fitted to a system.
When they merged IE with the OS, just to be able to beat Netscape, they opened the OS to a whole new category of exploits.
And then ActiveX made web app programming so much easier
Personally, I wish they'd whitelist javascript the same as they whitelist pop-ups.
In the meantime, just grab the NoScript extension and do it yourself.
FireFox 1.5, filled with extensionable goodness!
Examples:
1) Build/maintain a web server that can handle 10,000 static pages a minute on a budget of $5,000.
2) Build/maintain a web server that can handle 10,000 dynamic pages a minute on a budget of $10,000.
3) Build/maintain a database server that can handle 10,000 transactions per minute on a budget of $20,000.
Then extend the maintenance of those over 2 years, 3 years, 4 years, etc. Include hardware/software upgrades.
Each team will come up with different approaches. I'm sure everyone here knows about the MindCraft "study" where a single Windows box with 4 processors and 4 NIC's was setup as a web server. But the logical approach would have been to setup 4 smaller, less expensive, boxes with better redundancy.
In fact, it was part of the requirments.
But they did NOT let them upgrade when any normal person would have. They REQUIRED them to stay on SLES 8 and backport patches from SLES 9
Any intelligent person would have skipped the backport process, done the upgrade when it became necessary and bypassed all the "problems" that were "found" in this "study".
It's all about the criteria. Why was the criteria such that the Linux sysadmins were backporting patches?
He doesn't have to be lying. The fact that Microsoft funded the "study" means that you MUST look at the assumptions and process.
In the "study" in question, the Linux sysadmins were, for some reason, backporting patches from SLES 9 to SLES 8 due to the requirements of this "study".
So, no lies required, but because of the criteria chosen, Linux is far more difficult to maintain than ever in my experience.
The OS upgrade was already part of the "evaluation".
Why not allow the sysadmins to upgrade from SLES 8 to SLES 9 instead of REQUIRING them to backport the glibc patches from 9 to 8?
Yet the Linux sysadmins were downloading mysql code from the mysql site and attempting to backport patches from SLES 9 to SLES 8.
From TFA today:
In every one of these "studies" there is always something that the "study" requires that no intelligent person would do.
I don't care WHO the "researcher" is. Once they participate in one of those "studies", I have no respect for them anymore.
First off, they admit that they don't know what the UNITS are, just the revenue (and they admit that Windows costs more than Linux).
THEN they go off about WHY Microsoft moves more units than Linux, even though they admit that they don't know that Microsoft DID move more units.
You'd think that "cooltechzone" might be a bit suspicious that units are not mentioned. Just a bit suspicious.
#1. Scalability. Otherwise, all of your addresses have to be searched. With .com/.org/.net, at least they can be somewhat sub-divided.
.us TLD? .com and such were fine when the Internet was new and small and less important. But they don't scale very well. Removing them completely would reduce the scalability even more.
#2. Non-exclusivity. If someone in England registers a domain name for their business which only operates in England, why shouldn't someone in the US also be able to register that name under the
Combination voting machine, Lotto machine. Get your Lotto tickets here!
THEN you'd see people sit up and demand 100% accountability.
There are a limited number of ways to stuff a ballot box.
With a paper ballot, the easiest way to prevent that is to count the number of people who voted there (you have to give your name to vote) against the number of ballots.
In theory, the state should know who is registered to vote and it should be easy to identify that person as appearing at this station at this time. So the number of registered voters appearing at that station should equal the number of ballots collected at that station.
Which leave the ballot stuffers with the problem of getting their person to appear at multiple stations to vote. And that is solved with technology. It should be very simple to check the database of registered voters and mark off the people as they vote.
Any questionable situation (person doesn't appear in database or person's info doesn't match) can be solved by allowing them to cast a provisional ballot and giving them time to fix their data in the system. Hopefully, the number of provisional ballots would be lower than the difference in votes between the candidates so they wouldn't matter anyway.
The paper ballot doesn't have to be scanned or read.
But a percentage of the machines will have their claimed results compared to the paper ballots to verify their results.
The paper ballot is the final ballot. The paper ballot is the ballot used to verify the machines. The paper ballot is the ballot counted in a re-count.
All a computer can really do is make the initial count quicker (and possibly more accurate) and print a paper ballot that the voter can check easier (ie, prints out "YOU ARE VOTING FOR PERSON X" instead of just seeing a dot by a name).
If you cannot get a paper ballot out of the machine, the machine is worthless. You'd do better sticking to regular paper ballots.
In general, you are correct.
In the specific case of this specific "study", the criteria were such that the SuSE sysadmins were required to download and install code from the mysql site and back-port patches from SLES 9 to their SLES 8 systems, themselves.
Without being allocated the time to correctly test those systems.
Meanwhile, no non-Microsoft patches were installed on the Windows boxes.
It isn't the number of patches, it is the patches themselves. I can apply a hundred patches (or more) to my Ubuntu box quickly and easily. And because 99.9% of them do not require a system reboot, I can easily test them.
This "study" was setup so that SuSE would fail. That's all there is to it.
The link posted in the story is not correct.
m l
Just click through and don't give them any info. You can still download it.
http://www.securityinnovation.com/reliability.sht
The problems start at page 25. Here's the beginning:
Whitepaper location:
http://www.securityinnovation.com/reliability.sht
Weekly reboots.
Get a copy of Win2K3 on your box. Create a directory that's 3 directories below the root.
Put 200,000 files in that directory (size of each file does not matter).
Now, watch the application that reads and writes files to that directory get slower and slower over time. Until you need to reboot the box.
For an instant problem, open that directory in Explorer. All of your processor speed will be eaten by the "system" process. Even after you close Explorer. Rebooting is the only thing that will clear the problem.
The key, as always with these "studies", is to find the portion where it deviates from Reality. That is, where it uses some strange definition or where the sysadmins choose some bizarre action.
...
In this "study", that step into UnReality begins where all systems are required to stay on the same time-line for upgrades.
This means that what would otherwise be a normal upgrade from SLES 8 to SLES 9 instead becomes a strange mix of back-porting patches from SLES 9 to SLES 8. In other examples, the sysadmins are downloading code from the glibc and mysql sites and applying it to those server WITHOUT TESTING. So, over time, the SLES systems become unstable.
Meanwhile, no non-Microsoft supplied code is applied to the Windows boxes.
Of course, the one who commissions the "study" gets to choose the criteria
Seriously, how much "easier" will it be at the cluster level? With Linux, you don't even have to install the OS on the hard drive. It can run off of a CD.
At this level, the extra wizards and such just don't matter.
This is related to the scope creep rule.
The longer your project is in the pipeline, the more likely it is that it will fail. Over time, the problem that your project is supposed to solve will mutate or become irrelevant itself and/or other "problems" will suddenly "need" to be "solved" by your project.
I am reminded of the Win9x bug that caused a failure every 49 days.
If your system is not "up" long enough to trigger a bug, is it "stable"?
If "yes", then at what point does a system become "unstable"? If I have to reboot every year? Month? Week? Day? Hour? Minute?
Or is "stable" defined in terms of "unexpected crash" and discounts any "crash" that is avoided by rebooting the system?
This is one of the reasons I like Linux. Because the system doesn't require reboots except to replace the kernel, it is easier to identify apps that are unstable AND GET THEM FIXED.