Slashdot Mirror
Linux Should Be Shunned
esimp writes: "In the August issue of CFO magazine, their tech report on servers goes on to say,
"Linux has a passionate following among the tech-savvy, and mainstream support from such hardware and application vendors as IBM,Compaq, Hewlett-Packard, Dell, SAP, and others. But not everyone is a fan. Meta Group Inc. analyst Peter Firstbrook goes so far as to say that 'Linux should be shunned. It should not be a part of the business process.' Firstbrook objects to the very feature that most tout as Linux's number one asset--the fact that anyone can tweak the code--because it creates a situation in which an IT staffer may
make changes that no one else knows about, and that probably go undocumented." That's right, because if someone you hired doesn't have proper documentation skills, it's all Linux's fault.
In open source, who do you sue when the bug loses you money?
I would be very interested to see a documented case of Microsoft or Sun being sued and having to pay consequential damages for a bug in their software. Every license and contract I have seen from these folks SPECIFICALLY excludes responsibility for such.
That's OK. a quick re-installation of the OS should clear up the problem.
Linux is not the only operating system which can be tweaked. As a former IBM mainframe systems programmer I've done lots of local modifications via 'user exits', the key of course is to have a solid change control system and provide a proper documentation. Note: you scan screw up the whole system via those controlled exits as well, no different from tweaking the source.
In open source, who do you sue when the bug loses you money?
How about don't waste time suing in the first place? It seems a rather naive idea, not coming from someone in the business world, but I wonder whatever happened to the concept of "fix the problem, buck up, and move the fsck on." Losing money for various reasons is a fact of life that individuals deal with their entire lives, and unless that money is illegally taken from them, most people don't go to court to get it back. It doesn't surprise me that a corporation doesn't work this way, but that doesn't make me feel any better about the reality.
Want to really show the offending company/programmer your displeasure? Write 'em a nice letter explaining why you won't be using any of their software and/or going with a competitor's solution in the future.
Assuming that companies do try to sue for faulty software...I wonder how much cheaper it would be to forgo a legal route, send the bloody letter, and spend time making up for lost money rather than pissing more away in the courtroom whining about "lost profits". I can see where a small, struggling company might want to go this route in the event of a great disaster, but don't most licenses preclude legal action, anyway?
In any event, the suing angle is a straw man. In open source, you fix the bug - or get the programmer to - because you have the source.
Just tell your boss "...and if it fails, we can fix it right away and get back on our feet in short order. We don't have to bother threatening the programmer, because his code is right here for us to fix ourselves." Eh, it's worth a shot.
Someday, you're going to die. Get over it.
Well, according to the business plans of Red Hat and VA Linux, the real revenue was supposed to come from providing such support services to enterprise customers. Whatever happened to that?
your post boils down to the fact that an admin can fuck up a box. "playing with your home machine" does not translate to "hosing the company mail server."
i work at a telco/financial company. most of our major money making systems have a linux component - in fact in several cases they're all linux. our admins understand the need for 24x7 uptime and the need for planning ahead when things go wrong (disk on fire for instance). our linux boxes, admined incorrectly could fuck us over. which is why we use rcs for config files, kickstart for box installs, documentation for inhouse software and mailman based mailing lists for communication. because the power that allows one to do bad things also allows us to do great things if we're responsible and keep our heads out of our asses.
scalpels can kill people, safety scissors probably can't. what do you want to see in a surgeon's hands?
US Citizen living abroad? Register to vote!
Summary of Firstbrook's points:
/does/ mean then!
1) Linux has source, so you can change the source, and recompile without documenting it. On the other hand, when you use OSes like Solaris and Windows, changes you make to the system are magically written down in your logbook, without you having to ever lift a finger.
2) Software itself doesn't cost that much compared with labor. And since we all know that Linux admins are all clueless bastards who spend most of their time wondering what the su utility does, while MCSEs are all highly-trained professionals with impeccable credentials and a top-notch knowledge base, using linux means hiring hundreds of admins to administer a cobbled-together, bloated OS running on excessive hardware, while using NT means hiring only a tiny handful of well-trained Microsoft puppets to run that lean, mean, tidy OS.
3) Did I mention how NT admins are invariably well-trained? And highly knowledgeable? While most Linux and other Unix admins are still dithering over the difference between "Enter" and "Return" on their keyboards?
Oh wait, that _wasn't_ what he meant? I'd love to hear what he
Since when does a classicly-organized company ever trust its employees? How many organizations have you worked for that tracked your telephone usage, your hours (even for salaried people), your attendence every day?
Ever work for a place that didn't require a "weekly report" or equivalent, even at the manager, director, and even the VP level?
How about expense reports? I was once gigged for "spending too much" when I picked up the tab for a dinner for 12 where the publisher of the magazine I worked for splurged on wine -- the tab went on my AmEx card, and the publisher red-flagged the expense until he was "reminded" about who really made the charge...
Ever get screwed out of compensatory time off because the manager that offered it at the time the "overtime" was necessary to meet schedule goals "wasn't authorized to offer comp time?" I got nailed with that twice (in two different companies) before I learned to check with the policy people before accepting the tradeoff.
Speaking of time, I have yet to see any in-house IT project come on time, on target, and on budget. Indeed, in the early days my consulting business was built on implementating the disasters that an IT department (it wasn't called IT back then) spawned. What amazed me was how simple it was to bring in what the bosses wanted, dumping the frills that IT layered on that weren't on target to the job.
Reminds me of a very old story: a car company's data processing department had screwed up an order generation program that takes car orders and determines when and how much of parts need to be ordered to build the cars on the schedule. A consultant was hired, and he wrote the program on the plane on his way to Detroit. He had the thing keypunched, and it ran right out of the box, at a rate of one car order per second. The MIS department said "Well, our program can run at 150 cars per second." The consultant said "OK, I can beat that" and wrote a 10-line program that read order cards as fast as the card reader would feed them. "But, but, but, that program doesn't do anything!"
The consultant responded, "but neither does yours -- that's why I was hired."
First, this is a human issue, not a technical issue. The same can (and should) be said for any other operating system. One is able to tweak NT's registry, or Novell's set parameters, and fail to document the changes.
Second: This supposes that one did not make a full image backup of the system. As an administrator, I would discharge anyone that did not take this elementary and common precaution. . This is a trivial exercise in Unix, almost impossible in NT, and somewhat difficult in Novell.
I timed initiating a complete restore for the following systems:
1. AIX - 15 minutes (mostly waiting for the tape to finish booting) Extra software purchase required at unknown cost.
2. SCO - 5 minutes (2 diskettes to boot, insert tape, press 1) Extra software purchase required at $300 US per system
3. Linux - 20 minutes to configure partitions and format, then restore Used native software only at no extra cost
4. BSDi - 20 Minutes to configure partitions and format, then restore Used native software only at no extra cost
5. Novell - 1 hour 50 minutes to load OS and restore application software. Extra software purchase required at $1000 US per system Full restore from backup not possible because some files were open during backup and not backed up. Some manual intervention was required during the restore process.
6. NT - over a day to load OS and restore software, configure same. Not able to completely restore tape as some files were open and not backed up, system repeatedly locked up during restore. Manual intervention during restore process needed many times. Extra software purchase required at $1000 US per system.
NOTE: Only time spent actually completing tasks to start the backup is included in these times. This also included the time needed to configure the restore software, add the restore media device to the OS including drivers and software. The time required to actually complete the restore is not included as this is a function of the amount of data on the system and the speed of the restore media device, drivers and hardware.
Third: Gartner Groups analysis of NT shows that it takes 33% more time to administrate NT as opposed to Novell and Unix system, requiring more administrator time and cost.
Firstbrook also takes issue with Linux's most famous feature--the fact that it is free. "Our analysis says that the cost of the operating system is only 3 percent of the total cost of ownership of the server," he says.
And I suppose that once you buy a car, one never need buy gas? Only a complete idiot thinks that the purchase is the end of expenditure of any item.
Labor is a far more significant proportion of IT costs, and the very cost that is likely to be affected if employees spend time tinkering with Linux.
Or playing Quake, or Arena, or Flight Simulator. My experience is that my peers tend to tinker at home, where interruptions are at a minimum. Again, this isn't an issue of the operating system, this is a management issue. Bad management is possible in any operating system environment.
"Linux is out there and people are using it, but it is mostly because of the cool factor," he says.
And it's likin' to be seein' the survey that got those numbers I'd be.
As a class, systems people tend to ignore hype and look to the heart of the matter. "Is this the appropriate technology? Will it do what I need? Will the total cost be reasonable? Is it dependable, and will it run on equipment we can maintain?" are all questions my peers and I ask of any product being deployed. Mr. Firstbrook implies that my peers and I are idiots and will use any cool tool that comes along. My response is that most of us choose the tool best suited for the task as best we're able and given to understand that task.
A survey of over eighteen million web sites by www.netcraft.net shows that Linux is running 35.73%, Microsoft is running 21.32%.Source: www.netcraft.net/survey Further, studies show that Linux/Apachie are gaining market share from almost everyone.
"Having somebody who can screw around with my operating system would make me very, very nervous," he says. --T.R.
Mr. Firstbrook must live in terror or only hire incompetent help. It is possible to "screw around" with all operating systems more complex than the one to run a toaster, and even that has an adjustment for how brown you want your toast. NT has registry settings, configuration files, and so on. Novell has it's set commands, configuration files, .NLM's. Unix has programming, configuration
files, and many many other ways to "tweak" it.
My suggestion to Mr. Firstbrook is that he look for another line of work, as he is ignorant of how and why computers work, what it takes to run them, and how to choose what to run.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
Firstbrook's objection is mostly crap, but not entirely. One of the problems with the Linux community is that it does tend to undervalue aspects of software engineering besides straight-out coding. People who concentrate on writing good code rather than more code, or who test the hell out of their code, or who do a good job of documenting what they've done, get a lot less recognition than the people who crank and crank and crank, even if what the people in the latter group crank is mostly garbage. This "bad culture" is directly related to the bad example set by Linus himself, who has some attitudes that most serious software engineers would regard as eccentric at best (e.g. his well-publicized disdain for debuggers). The net result is a huge number of people who think they're hot stuff because they've learned a few nifty tricks, but who lack any deep background or self-discipline because they've never been rewarded for those things.
Which brings us back to Firstbrook. Many people have suggested that the problem is not with Linux but with the lack of things like change logs, but my point is that they're not unrelated. People who have become steeped in Linux knowledge have also been steeped in Linux tradition, and that's a tradition that devalues some of the things that matter in a mission-critical environment. That puts employers and customers in a bad spot if they rely on Linux systems, with the most technically savvy people often being professionally "immature" and often too arrogant to admit that the customer's modus operandi may be valid even if it's not "the Linux way". Employers and customers get tired of that BS real fast, and may well find themselves longing for the days when the people who knew the most about their OS weren't obnoxious little punks.
What has made Linux a very good OS is the amount of youthful enthusiasm that has gone into its development, but in a way that's also what prevents Linux from being a great OS. The Linux community is inseparable from Linux itself, and the skewed reward system in the Linux community has revealed the dark side of youthful enthusiasm - hubris, lack of discipline, and a large dose of "Not Invented Here" syndrome.
Slashdot - News for Herds. Stuff that Splatters.
Your Linux admin is much more likely to play with settings, recompile the kernel, and do other major things. The source availability is part of it. The culture of Linux is another.
You can't risk that. If the NT machine is screwy, redoing the installation actually isn't such a bad option. If you have reasonable documentation, you can get the box back up in an hour. Good luck keeping as good docs with a Linux box. I use both systems in my company, and it is impossible to keep a Linux doc, you make too many changes. A NT box is really straightfoward and has less tweaking.
This is a REAL issue. Whining about NT's problems doesn't fix it.
It would appear that you are holding a biased view here; The same problem as in the article. A tech making unauthorised changes to a production environment is not the fault of the software, hardware or any other inanimate object. It is a people issue. The solution is Change Control. It amazes me that people who are ostensibly professionals make this kind of fundamental error. Then again, it's why I have a job.
And why on earth is it more difficult to document one particular OS vs. another? Unless you decide to document one in esperanto and the other in ancient hebrew, I don't see the problem. Documentation needs to be done no matter what the system. If you're changing things so much that you can't keep the documentation up to date, then you're making too many changes. Change Control again. Documenting changes is part of the process.
This comment was simply more anti-Linux FUD. More disturbing is the insight it gives into the mind of the author. I shudder to think of someone like this being let loose in an HA environment, because they have no appreciation for the processes required. Actually, no... They have an appreciation, but only know enough to be dangerous. The 'culture' you refer to above is not limited to linux. I see it everywhere. They're called cowboys and companies spend a lot of money on people like me to clean up after them.
Just because you're paranoid doesn't mean they're NOT after you.
In open source, who do you sue when the bug loses you money?
The same people you sue when you run commerical software; You sue no one.
I have never heard a case where some one sued a software company because the software had bugs. This is what the EULA is for, protection of the software maker.
Linux O Muerte!
As little respect I have for the financial community when it comes to making technical statements, I have to assume that he has more reasons that the two listed for feeling that Linux should be shunned.
Both of his arguments are completely illogical at any rate. They are both functions of a poor IT staff rather than a poor OS. He states that "undocumented tinkering" is a drawback of Linux. I've worked at a great many Windows shops in which "undocumented tinkering" was a huge problem. It's the staff, not the OS.
He also says that a problem is the expensive IT staff "spending time playing with the OS because it's cool" makes Linux cost-prohibitive. That's rediculous. The staff that does that would be just as likely to do so with Windows or anything else. They'll be the ones "playing" with routing tables, "playing" with the registry, or "playing" with software settings. They'll be the ones running TweakUI on their PDC to make it faster, killing it in the process. This isn't a Linux problem, it's a staffing problem.
I hope that either these were just two of the more idiotic comments from a larger frame of good comments. If not, I'd hope that any relatively intelligent IT manager would understand the flaws in the argument.
Apple was sued some time ago for dropping software support for the Lisa. As I understand it, the case was settled out of court. Whether the settlement included consequential damages, I don't know. The settlement wasn't exactly top news.
Which points up a critical fact: there have been, to the best of my recollection and the limits of my research capabilities, no viable software vendor hauled before a judge because of non-support because no company is stupid enough to let the situation get to that stage. Software vendors knows that it's far cheaper to pay money on technicians, developers, gurus, and consultants to fix the problem than it is to pay lawyers even more money to dismiss the complaint. The fix-the-problem route usually results in a satisfied customer, while the fix-the-law results in a pissed-off customer.
Besides, it's rather easy to see who has the $100,000 required to press such a suit, and sidetrack the legal action. Joe Six-Pack won't have that kind of money, and District Attornies have a high enough case load without taking on "petty problems."
The real problem is not with lawsuits, but the underlying statutes that regulate commercial transactions. The Uniform Commercial Code (UCC) doesn't work well with software and data collections. So there is a push to create a UCC-like statute in the 50 states that does for software and data what the UCC does for tangible products. Unfortunately, the proposed model statute (liked only by the SIIA, formally the Software Publishers Associaton, and hated by a long list of others) is flawed; see CPSR's fact page for more details. From the horse's mouth, the summary by the Uniform Acts Commissioners, as well as a Q&A page on the NCCUSL site.
Ok, I've heard just about enough of all of the TCO nonsense.
When people talk about the higher price of kepping Linux maintained, this makes me cringe. Low-level NT techs are not much cheaper to hire, they generally got their MCSE from a 2 week cram course that did not cover Event Viewer, and do stupid things like put an NTFS C: drive on a print server.
Low-level linux techs on the other hand are generally people who like to tinker with computers (that's why they got linux in the first place), learned their skills from trying to get work done on their computer, and do stupid things like over-partitioning their hard drives.
The last three MCSE's that our companies hired honestly did not know what Event Viewer was. Mind you, we are not one of the better paying industries, but... We have also hired in an ex-photographer who was learning Linux, after 2 years he is one of our best employees. (And one of our better NT techs)
The hidden cost of deploying NT is the cost of hiring unqualified people to maintain it. We have almost three times the staffing for NT as we do for *nix and NT is used as a file server and print server only. Unix does DB hosting, app hosting, achiving, etc.... We have 34 more *nix servers than NT servers as well. Three times the staffing.... *sigh*
The sad truth is that our *nix department experiences better uptime by far, is better run, is better documented, and runs for less doing more. Our NT department always looks busy at least... when they're not over here asking us to take a look at something.
~Hammy
"Windows 2000, based on NT technology"
NT = New Technology (really)
"Windows 2000, based on new technology technology"
So bloated they have to say technology twice!
(Before I start, I want it made clear that I'm a Linux user, and prefer Linux and OpenBSD to proprietary operating systems of any stripe: MacOS, Windoze, BeOS, AmigaDOS, HP/UX, Ultrix -- you get the idea.)
From the non-technical business perspective, Peter Firstbrook does have some legit concerns here, even if he dances around the core of the complaint. A businessperson "betting the farm" on technology either has to have a great deal of trust in his/her technologists or in the vendors supplying the infrastructure software.
For the Fortune 5000, trust in support technologists is hard to find -- even in those companies that sell technology, such as HP and IBM. Remember, revenue-generating technology is monitored by a pyramid of management and a gaggle of process, while non-revenue technology doesn't have the same money thrown at it. Frankly, IT-based development for internal use just doesn't have the management oversight that a vendor would provide, and the business people know it.
That's why there is a tendency for business to buy infrastructure solutions from vendors who have "thrown money" at the management of technology, and is willing to take responsibility for the gaffs and fix them. (The fallacy here is that the erring vendor -- think Microsoft -- will indeed fix the problems right and right now.) As a side benefit, repair and upgrade costs can be controlled and predicted, with the vendor taking the risk. The business person will pay for 24/7 if s/he feels that level of support is necessary, but wants a definite cap on the costs. That's why service contracts are such an easy sell to Fortune 5000 types -- the contract may be expensive, but it represents a known expense that can be factored into the financial model.
Contrast that with the unknowns with in-house solutions. They may be cheaper to start, but the chance for "surprises" is very high, very frustrating to business types, and makes for an unworkable financial model for the company. How many projects have you worked on that came in on time and under budget?
Now consider the Open Source model. On the one hand, you have a peer review of the code that can't be equaled in proprietary software -- everyone who uses the system can look under the covers and see what's going on. Something not right? Either fix it and provide a patch, or report the problem and let someone else (on their own time) figure out a fix and patch.
In open source, who do you sue when the bug loses you money? There isn't just "one place" you can aim your lawyers to recoup the lost revenue when something goes very wrong. Even Red Hat isn't a very good target, because they just package Linux, they don't take responsibility for bugs in the kernel.
How about that "tinkering" argument? I believe the argument is in fact a red herring, another boogieman to scare non-technical types. Yes, it can happen. In reality, most IT types don't have the background to even attempt it, let alone make it work. The very few that can pull it off may in fact improve matters, if they are supervised properly. So, let's drop that lame claim.
It's not a question of feasibility, or of "goodness."
It's a question of responsibility, of fixing the blame.
Follow several easy steps
1. Find file/program/data file you wish to "modify"
2. Get past the header information and say get into say the half way mark of the file
3. Bang randomly on the keyboard
4. Save
5. Run and Hide
6. Wait for the screams and swearing
Respond to s