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.
- Their tech staff is boldly irresponsible
- Their tech staff is generally against the company
- The smarter an employee is, the more dangerous s/he is
- It makes you sound smart if you say "Linux should not be a part of the business process," as opposed to saying something simpler such as "Don't use Linux."
- Giving employees tools that they prefer causes them to "tinker" instead of developing interesting new methods to improve your business
- Finding the best tool to solve a problem is less important than finding one that keeps your employees at bay
- The "cool" factor is inherently a negative
Now... who put these assholes in charge?--
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.
There is some serious legitamacy there. In a computer company, your staff is all tech focused, and the tinkering is part of the useful business process.
In a financial firm, you care about reliability. You don't care about cool. You don't care about saving OS costs. You're dealing with large sums of money, and the risk of a system going down is huge.
This isn't a NT/Linux thing. It is a pick your OS thing. No financial firm puts important things on NT. Their financial stuff (ya know, the core business) is based on a mainframe. They probably have some Unix servers that do some number crunching by connecting to that mainframe. The NT Servers store people's profiles and handle printers, maybe Exchange. The Windows or NT workstations run Microsoft Office, and more important, a 3270 emulator.
These companies shouldn't want to risk running anything on a box where the tech could have been playing with recompiling the kernel to get a tweak that broke something that he didn't know about.
You buy a reasonable package with a good support contract, and your techs keep the things going.
Can a tech screw up an NT or Solaris machine? Absolutely. Is it as likely as screwing with a Linux box? Not even remotely.
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.
However, why do you care? Does your ability to enjoy Linux depend upon banks and traders print servers running on Linux instead of NT? These are the most conservative companies in the world. That is a good thing. I'd HATE to think that banks were using leading edge machines with the problems. They need reliable systems.
Ripping on NT techs, the usual response to anything critical of Linux staffing, is immature, rude, and irrelevant. If you are hiring bad MCSEs, then fix your staffing problems. Tell HR to look for experience, not courses. Interview people. Having your MCSE certification doesn't mean that you are stupid. In fact, I think you would NOT find a negative intelligence correlation with certification, in fact, it is probably a positive one.
I make a lot of hiring decisions where I am. I few coursework (MCSE classes, Perl classes, etc.) as a negative point. However, I view certifications as a positive. I want people that poke around and learn, not need a $3000 class to learn a new skill.
Studying on your own for your MCSE exam is a good thing. Learning the material (I used the resource kit, not study aids) is a good thing and helps you learn the OS.
The fact that NT has problems doesn't mask Linux's. Furthermore, the choice is never only between NT and Linux. There ARE other OSes, and companies that deal with billions of dollars and depend on IT don't really care about the cost of a Solaris box.
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?
As for different depts running better, if yours is running better, good training and management are responsible for that as well, so compliment intended. If people want good techs, there is no reason they should not be able to grow and train their own. Nobody wants to invest in someone's training anymore it seems. When the employees finally take the steps to train themselves, they are often forced to leave to get "experience". I agree completely about cookie cutter technicians. I'm not even saying that there is a lower TCO one way or another (Something I think is impossible to qualitatively determine).
What I am trying to say is that no tech is "better" than another because they specialize is Sun, NT, Linux or whatever else. To compare a 14 year industry veteran who runs the unix boxes to a 3 year NT admin is never going to a fair comparison. You need to compare based on total experience. I would like to see some of these companies that are complaining about a lack of technicians do something about it.
PS, time to get the HR dept out of the hiring process.
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."
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
Does this guy realize that the entire internet runs on software that has had source available for eons before Internet Explorer even existed? Sendmail, BIND, etc. have always come in source form.
Somehow, the internet grew despite the threat of freely-available source code for the software that power it. Amazing.
- Scott
------
Scott Stevenson
Scott Stevenson
Tree House Ideas
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.
Well, the truth is that for what we pay, and this is the pay that they base TCO's on, we get techs of comparable experience. Are you suggesting that our HR department be better? If so, this has to be figured into TCO.
:)
People are lazy. The defense for HR when they hire an incompetent is "Well, he was an MCSE...".
I work in a backward industry for a company that does not have the resources or savvy to only get the best... There are companies around here that have much better pay and benefits and they get the best techs. But I'm also sure that many companies are the same.
Perhaps I should say that a "Unix Professional" is generally of a higher caliber than an "NT professional" of like station. I'm not sure that this is my point.
The point is that the media will have you believe that the cost to maintain a *nix is prohibitive. This is not the case. The cost to run an IT infrastructure depends on your ability to recruit able staffers which is something that every department has trouble with at every business.
The current cookie cutter become an NT professional in 2 weeks system will be the downfall of NT much as it would be if a similar program was started for Linux, Solaris, etc... The testing for an MCSE is based more around knowing the new features than knowing how to operate a server.
I got my MCSE about 3 years ago, and will not update for 2000. The certification has been made a mockery of by the company that is supposed to guarantee it's sanctity.
I'm not looking for sympathy, only refuting the too often touted TCO that always gets tossed into the fray by journalists that make assinine comments like this one. And our companies hiring policies are the very same ones that hired our *nix group. Why the disparity? Even in management, they were hired to manage.
But hey, if the sucess of our *nix group is due to good training and management, I accept the compliment.
~Hammy, A.K.A. "Boss man"
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.
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!
Firstbrook frets that labor is
Indeed -- since Linux people spend less time on the phone waiting for Microsoft to tell them to re-install, they get more done. And since Linux people have, in general, a much better handle on what their systems are actually doing (because they "tinker" all the time), they can fix problems faster and better. All in all, the labor cost for a Linux system is almost certainly lower than a proprietary one.If you took your car to the auto shop, would you be happier if the place was clean and ordered -- and the mechanics stood around waiting for someone to open the car for them and replace the black boxes -- or if the place was a bit messy, perhaps a bit disordered, but the mechanics obviously knew their stuff because they couldn't help "tinker" with engines, figuring out what was going on?
Firstbrook is essentially a corporate droid. Like all corporate droids he can't understand how anything can be free (in either sense). What he can't understand, he instinctively fears.
Luckily, perhaps, the market is a ruthlessly efficient beast and, as they say, the truth will out...
The Mongrel Dogs Who Teach
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!
That is a problem with busness today...
When your accountent isn't trustworthy you get embeselment. When your managment isn't turstworthy you get mismanagment. When your techs aren't trustworthy you get back doors. When your asembly line workers arn't trustworthy you get sloppy work.
Even fast food needs to turst it's employees. If Taco Bells people aren't turst worthy they will not be able to asemble the food orders very fast at all. As it is Taco Bell prides itself (internally) on speed. It hypes it to the staff. They compeate with other Taco Bells.
But managment gets paranoid the more complex and sensitive the process gets. They start micro managing.. they start snooping in on staff. They start saying "No tinkering with the source". They start setting tech policy when they have no busness doing so. They become paranoid. Paranoia will distory ya...
Looking at all the DotComs that die off and it's no wonder... if the managment can't trust it's own technical experts then where dose managment turn when it needs technical expertise? A software companys sales staff? Oh yeah thats really gona help....
You need to trust your staff. What keeps your accountent from embeslment? You trust him.. what keeps your security staff from stealing secrets? You trust them. Yet... yet.. embeslment and industreal theft happen... a lot...
Techs don't back door employers very often and when they do they don't need source code.
Windows, Back Oraface.... Unix: Hidden account... MacOs: Trojen... Os/2... Trojen
Usually a trojen will do the trick.. if your using a multiuser operating system then a hidden acount works (easyer to discover but it dose provide more access if set up correctly.. like an alternet root)
If you don't trust your techs.. toss your equipment....
Trojen = You accually have to write one. Windows allready has off the shelf trojens such as BO for you to use. It dosn't really ammount to a hill of beans of diffrence in the real world. Trojens are SOO easy to make and deploy... Unix may have an easyer alternitive (hidden account) but it's not that much easyer...
I don't actually exist.
One, you don't need the source code to cause this kind of problem. Ever come in one morning to discover the sysadmins - with the blessings of management - changed the server software during the night? Yeah, sorry your CGIs no longer work, we switched from Web Site Pro to IIS, didn't you get the memo?
Two, the other extreme: some places you can't make ANY unauthorized changes to production code without fifteen signatures. Touching the kernel on a production server would be a firing offense.
In short, if this is likely to be a problem, the IT department has bigger problems - like an inability to control their machines. Seems to me that's a management problem, not a software one, and if the sysadmin is tinkerhappy and won't leave a paper trail, the sysadmin will be tinkerhappy whether he has source code or not. Do you need the source code to make a mess of a running NT server?
So don't leave vmlinuz world writable.
~ radiographite: art by john shepard
(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.
No, you can't say the same thing about MS Outlook and viruses. That would be a valid comparison if someone else could modify the code for your linux machines... MS Outlooks main security problem is that scripts can set themselves up to automatically attatch themselves to all outgoing mail. Other than that, you could do the same type of viruses in bash that people could run using pine. If your administrator changes something (be it code, software versions, configuration files, or even a registry entry on an NT box) and doesn't document it or tell people who need to know, the problem is with the administrator. I don't see any difference in tweaking code as setting a registry entry. Sure, they are two different things, but in either case all the administrator is doing is changing things to suit his needs. The product is not at fault for allowing customization. The administrator is at fault for not following whatever policies are set by his company for documenting it.
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
Yes, it is stupid. You cannot get to the C: drive to fix data corruption with a normal boot disk as with FAT. Especially on print servers where this eems to happen all too often... Ever see the message "Cannot find NTOSKRN.VXD"...
The only reason to configure the system drive on an NT machine as NTFS is if it contains sensitive data that you would not want accessed by a boot disk. But then you would also most likely argue that it should be NTFS on RAID 5....
But then some folks don't mind wasting 500 MB of disk space for their "Paralell Install" of NT...
Your responding to this negates your lame dig at the end.
~Hammy
"Never underestimate the power of stupid people with 90% market share"
P.S. The point of the thing is that print servers are trivial.