Using Debian in Commercial Environments? 506
sydb asks: "I am currently persuading my employer to try out Linux. We are heavily dependent on IBM software technologies just now, and it's a very conservative operations organization. As a challenge, I am trying to persuade them to use my preferred distro but there are hurdles: IBM doesn't officially support Debian as a platform, though I have anecdotal evidence that most of it can be persuaded to work (with alien etc). Does Slashdot have experience shoe-horning Debian into this kind of scenario? Most importantly, how have things gone getting IBM support? My rationale for pushing Debian boils down to its vast array of packages available to apt-get, easy upgrades, apt-get itself, and the overall quality and consistency of the system."
Conservative and don't like Debian? (Score:5, Funny)
Re:Conservative and don't like Debian? (Score:5, Funny)
Re:Conservative and don't like Debian? (Score:3, Interesting)
just kidding. You can get away with a compiled kernel and KDE desktop in 24 hours on a 1.8 ghz p4. I've only bootstrapped on a 500mhz k6-2. It took several weeks until KDE was finished.
I wouldn't see Gentoo as a bad solution for a small company as long as the guy doing it was familiar with gentoo. Once you configure a few systems, you get an idea of how the install process should go. It's not difficult, it's just a learning experience.
Re:Conservative and don't like Debian? (Score:3, Informative)
*distcc Knoppix for the initial install
Re:Conservative and don't like Debian? (Score:3, Interesting)
Re:Conservative and don't like Debian? (Score:5, Insightful)
You have a working system. What is your rationale for wanting to change ANYTHING, much less your OS?
You've paid (if my own workplace is any indicator) at least tens of thousands of dollars just for the IBM support (which is superb, if you're running approved software).
You probably are using other software, all of which you've paid support contracts on.
All these contracts will become null and void if you should do something completely insane, like switching your DE to a distro that is not supported.
Well, go for it, it's your career. I'll say this, however. If you were employed at my workplace, and suggested such an insane course of action, you wouldn't be working here for long.
Re:Conservative and don't like Debian? (Score:5, Informative)
The only IBM software we need to use in "production" is a DB2 client and probably a TSM agent. We could avoid the TSM agent.
We would probably want to run WebSphere on it for testing purposes - testing of scripts before they reach the environments our developers use.
My concerns are more about persuading management that an "unsupported" distribution could be a goer, and what I expect to be a small number if contacts with IBM support.
So I understand your thinking, but in this case it's misplaced.
Re:Conservative and don't like Debian? (Score:4, Informative)
Call IBM Global services. You'll be surpised what they support.
For the right price, they happily support Oracle [from a competitor] running on Solaris [from a competitor] and Ingres [from a competitor] running on NT [from a competitor].
I think you may be talking to the wrong group in IBM. If you guys have the cash to pay them, they'll gladly support Debian (though possibly through a partner company).
Re:Conservative and don't like Debian? (Score:4, Informative)
http://www.ibm.com/linux
Re:Conservative and don't like Debian? (Score:3, Insightful)
What you folks see to be missing is that its not just a question of supporting Linux, but a very specific case of supporting DB2 client (and possibly Websphere and Tivoli). It takes time and money to certify these products for a platform, and given all the variations between distributions they'll get the best "bang for the buck" by picking the most popular distribution (which was Red Hat at the time) and concentrate on that.
The author gave NO reasons why Red Hat wa
Re:Conservative and don't like Debian? (Score:4, Insightful)
Looking at it from management's point of view, I'd still be very skeptical. A promise that you'd be personally responsible for maintenance, fixes, patches and "surprises" might do the trick, although I know (from personal experience) that I would not be allowed to do it in spite of those reassurances. For good reason...I have responsibilities other than patching an experimental system, and could find myself in over my head very quickly.
The end result would be...mission not accomplished. And that's an unacceptable outcome to management. Plus, those developers...you give them a bad environment and you'll never hear the end of it.
Good luck.
Re:Conservative and don't like Debian? (Score:5, Insightful)
You might be able to convince them based on the licensing [suse.com] and service [novell.com] costs. Try making it a business case, exposing how much would it cost to have inhouse support for Debian vs Novell support for Suse. Be realistic, don't be quick at dismissing the costs of inhouse support for Debian. If you can, get some of the folks at IBM to back the feasability of the case, telling that, though unsupported, they dont forsee any trouble.
Depending on how critical the production end of your environment, you might be able to pull it off. Always bear in mind if for any reason the tested scripts will not run on the production end, the excrement will be flying your way. This decision might come to haunt you later if you keep your current employer.
Why try for Debian? You will fail. (Score:4, Insightful)
Debian is the most _stable_ distro. (Score:4, Insightful)
Re:Debian is the most _stable_ distro. (Score:3, Informative)
I think your numbers are low. The current consensus seems to be that the old version of stable will be supported for one year after a new version of stable is released. If the release cycle stays the same, it's more like 3 to 4 years total.
Re:Why try for Debian? You will fail. (Score:5, Insightful)
Um, no, Not even a little bit. It doesn't matter if you think Debian is the greatest thing in the world, or something you found at the bottom of your garbage can, there's one key difference.
Imagine some updated package broke all your applications. And your quarterly statements are due tomorrow. And the CEO is touring your server farm. And the planets are aligned infavorably. And it's Friday the 13th. Let me show two different scenarios:
And the alternative:
Re:Why try for Debian? You will fail. (Score:4, Insightful)
I myself have had to wait SEVEN MONTHS for a single line of code to be fixed in a piece of geophysical software with enormous subscription fees and not a large pool of customers (ie. we are a major chunk of their income) - that is after seven months after I pointed out that the two output variables should be zero so that the software could plot out charts. The entire piece of software was designed to generate and output charts, but it was broken in a way that meant it took another twenty minutes per plot (third party GUI software, plus someone to trim the charts) for around fifteen plots a day for seven months before a single line of code (which was printing some variables to a file as ASCII) was fixed.
There are plenty of other stories like this, everywhere.
You are as unlikely to get sacked for using debian as you are for using linux in the first place.
But you are - you have no business using any breed of *nix in a production environment is you cannot do a kernel upgrade - a solaris admin that hasn't installed a patch is the a work experience guy. If it needs redhat libraries you can use them on whatever breed of intell linux it is, and often on other platforms as well. Even gnome, initially written with no thought of portablility in mind, happily compiles on Solaris - and here you are saying that something with the same kernel and libraries is too much of a risk?Re:Why try for Debian? You will fail. (Score:3, Insightful)
It is better to take responsibility for your own actions than point fingers - keeping things going is far more important than blame. You take a calculated risk every time you use new software, but any professional makes sure they have the old configuration to fall back on. If you can't do it, you don't take the job - you either learn how to do it or get someone in who can do it.
Even though it is not the most popular l
What have you been smoking? (Score:5, Insightful)
Either you live in some alternate universe in which vendors work on bugs for individual users, or you've been smoking some exceptionally strong weed. Or, possibly, you don't have a clue.
I don't believe in alternate universes.
Re:What have you been smoking? (Score:3, Informative)
Naturally, we paid money for this service, and we were a 'partner', but practicly everyone could become one of them by using their software, and asking nicely.
In the end, it turned out the bug was in the CTOs fancy string classes, but still - we had excellent support from the vendor. (Who happened to be Microsoft, not that that matters)
I have worked on bugs for individual custome
Re:What have you been smoking? (Score:3, Funny)
No, but I live in the universe where, for a large sum of money in the form of yearly support contract, a vendor will fix a bug that's screwing over a large company if you hound them enough.
Re:Why try for Debian? You will fail. (Score:5, Interesting)
Employee: Um, look harder please, remember we're paying you all this money for [Operating System]
[Any Vendor At All]: Ah, ok, I think we've found the problem. You're running software we don't support. Now go fix it yourself and stop bothering me.
How about this instead?
CEO: What's going on here?
Employee: I unwisely installed a new package on our production server without testing it first. I'm just in the process of removing it and going back to the old version. Everything should be back up by the end of our maintenance window.
CEO: Good. Let me know how it turns out and why this won't happen again.
Paying a lot of money for a support contract is no excuse for being careless. If your server absolutely has to be running tomorrow, then keep it running. I don't care if you use a cold spare, restore from a backup or try to fix it yourself, but I do know that if I told my boss that I couldn't be bothered to find a solution and was sitting in my butt waiting for a vendor to fix it for me instead, I would soon be out of a job. And I would have earned it.
Being a sysadmin means you always have a backup plan. Having someone to point your finger at does _not_ constitute a plan.
Has nothing to do with redhat... (Score:3, Insightful)
If your the kind of person who does things haphazard then your asking for trouble. Debian won't make you a better sysadmin.
The OS is only as secure and stable as the person managing it.
No, Debian is the ultimate conservative distro (Score:5, Informative)
Comparing Debian to Mandrake, Suse, Slackware or even RHEL I think you will find that Debian it the most cautious about adopting new versions of core libraries, graphics system or the kernel.
Re:No, Debian is the ultimate conservative distro (Score:3)
It's great that you can apt-get install just about every piece of software. Too bad the stable tag uses versions of software that were old when woody was marked stable.
I bit the bullet and bought RHEL licenses for the last round of upgrades. It works great, other than the realization that it's basically paying through the nose for what RH8.0 gave you for free. Well, that and it uses
Re:No, Debian is the ultimate conservative distro (Score:5, Insightful)
Sys Admin Rule #1... (Score:3, Funny)
Why do so many people stay with Microsoft? Here is your answer.
Re:Conservative and don't like Debian? (Score:5, Insightful)
Partly on the basis of that experience, I moved from running RH on my workstation to running Debian, and I've never been sorry about that, either.
Our migration from IRIX to Debian was a complete success because of two things:
1) We had, collectively, a lot of talent on Linux;
2) The sysadmin put in charge of the project had a lot of talent and experience on Debian; the rest of us had most of our experience in Solaris, BSD, and Red Hat. The IRIX guy had moved to another department by then.
What was the difference? Not lack of talent, I think. It sounds like you know what you are doing. Perhaps a matter of choosing appropriate hardware, though. We didn't screw around with ATA RAID (this was in the pre-SATA days, but that wouldn't have mattered) or anything that was less than server grade. This was a mission-critical system, and we used only server-grade hardware that was known to be very well supported.
The hosts we used were six dual-CPU rackmount cases running SCSI disks (RAID 1) for the OS install, and all the important stuff was on SAN (RAID 5 there).
Everything was absolutely bulletproof. How bulletproof? We installed Woody, with the 2.2 kernel (this was the late 1990s, and 2.4 was still experiencing some growing pains) and it worked perfectly right out of the box.
As I noted at the top, they are still at 100% mail system uptime to this day, to the best of my (fairly good) knowledge. They are still running Debian Stable.
Many other people can tell you stories just like this. Debian most certainly has a place in a shop that needs to get things done, a place that can perhaps only be taken by FreeBSD (with the possible exception of Slackware, Debian Stable is the only Linux distro I've ever used that can match FreeBSD for stability, or at least come very close).
I'm not saying you don't know what you're doing, I'm sure you do. You're probably a better sysadmin than I am. However, I do see one thing that you did wrong. You chose (or perhaps the customer's budget chose for you) what some people would call "toy hardware." Debian Stable often isn't the best fit on the block with that stuff. But if you had been using a proper server box with SCSI (or at the least parallel ATA; I *still* don't like SATA support under Linux much), I think it would have been all right.
One other thing I would have done differently is this: as soon as I found that I had problems with the hardware and the distro I had chosen, one or the other would have been jettisoned. For a server application, it would have been the hardware if I had the latitude to make that decision. Even today, a server you need to depend on should use SCSI disks (I'm still partial to Adaptec adapters) and known top-quality parts.
With all due respect, while building an identical machine in your lab was the smart way to do it, investing hundreds of hours into making Debian work with that hardware was not. It would have been cheaper to *buy* a proper box and just *give* it to the customer. Alternatively, if that hardware was cast in concrete, early on you should have chosen a different distro, one that is focused on a single hardware platform and that places more emphasis on supporting the bleeding edge than on rock-solid stability for tried and true equipment. Debian is not that distro (not to say it doesn't work fine on most stuff; I install Debian Sid on Frys' sale-quality hardware regularly without incident).
I would advance the idea that Frys sale-quality hardware (such as SATA-RAID) has no place in a shop that needs to get things done. You probably won't ex
Re:Conservative and don't like Debian? (Score:3, Insightful)
I'd agree 100% with you - ATA or SATA RAID is the consumer desktop version of RAID. It has no business in production systems (production to me means 24/7/365, anything less is pretty much experimental or in test mode until it becomes "serious";). When setting up production hardware, you spec the hardware to the software you're going to use, not the other way around, and certainly not to be able to state "we're using SATA RAID, we're better than those old SCSI RAID setups, so we're worth the extra $10 you sp
Dear slashdot (Score:5, Funny)
Re:Dear slashdot (Score:4, Funny)
Re:Dear slashdot (Score:4, Interesting)
Now that we have switched our servers to Linux they wished we could move more.
Re:Dear slashdot (Score:5, Insightful)
Whatsmore, the overhead of a highly regimented IT operations organisation is more and more apparent. There is a balance to be struck between every technology meeting the corporate checklist, rubber stamped by all and sundry, sticking to the tried and test, and actually being able to implement change quickly enough to keep up with business realities.
Please don't answer my question so tritely. I think it is a reasonable one.
Re:Dear slashdot (Score:5, Informative)
This machine will need:
* A DB2 client
* Maybe run WebSphere for the testing of in-house scripts
* A Tivoli Storage Management agent. Or maybe not, there are other ways to have backups, like syncing to another machine.
The question is about adjusting management mindsets and dealing with IBM in what I expect to be a very small number of support calls. It's not about choosing the right technical solution, because I have ample justification for Debian being the right technical solution.
Re:Dear slashdot (Score:5, Insightful)
IBM doesn't officially support Debian as a platform, though I have anecdotal evidence that most of it can be persuaded to work (with alien etc).
to
It's not about choosing the right technical solution, because I have ample justification for Debian being the right technical solution.
So, your anecdotal evidence is now ample justification? I would say Mike (great-grandparent post) is right on the mark with his comments.
Re:Dear slashdot (Score:3, Interesting)
Then install Debian on an X86 server and show them it works.
It's often hard to see the potential of something that's not running. It's also hard to argue with a running system.
Re:Dear slashdot (Score:5, Insightful)
1) An installation needs to be supportable. This does not mean that you can get tech questions answered quickly via IRC or mailing lists. This may or may not mean the availablity of a hotline to call when everything hits the fan, and you are loosing big bucks every hour. It most definetly means that you can get install third-party software, and when that software hickups, you can call the vendor and have them help you, and not tell you they don't support your installation choice. Support also includes an assurance that someone has a _financial incentive_ to provide timely security updates and bug fixes for the product.
2) An installation needs to be repeatable. Which means that installing a distro that doesn't baseline their releases won't cut it. What I mean is, some distributions come out with a version, say 11.2, and will put out a series of fixes in the form of a couple updated package files every week or so. Thus, if you set up a server today with versin 11.2 and all current fixes, then next week if you do the same thing you will get a slightly different install. So what is needed is for the distro to have the concept of maintance levels, or patch levels, which defines a line in the sand so that you can at any time install 11.2 patch-level 13 and it will always be the same. (This also makes it easier for patches to be reviewed and signed off on by your patch-review board).
3) An installation needs to have a good chance of being maintanable by someone off the street. There are more enterprise-class unix admins out there than enterprise linux admins (that is, at least 5 years experience supporting a minimum of 50 systems that are in use 24x7 with stirct uptime requirements). And since most enterprises and their vendors are going with one or two linux flavors, a shop has a better chance of getting an admin in a pinch if they go with one of those two major linux players. And just knowing how to troubleshoot and upkeep linux in general isn't enough for a production system. Any linux distro has it's particulars that you don't want someine learning about during a crisis.
Unfortunately, most distributions fail one or more of these tests (or other tests that I didn't mention). For example, with Redhat Enterprise, their only supported methods of updating are to use up2date, which grabs the latest patches for all installed packages (which means you can't baseline), or you have to grab the patches one-by-one. If you download their update CD's, they don't provide an easy way to apply all the fixes (rpm --freshen doesn't cut it, cause sometimes you run across a patch that has prerequisites that the previous version didn't have, and rpm doesn't automatically resolve dependancies. Of course, there is always autorpm, autoupdate, apt, and yum, but these aren't part of the base distro, so you aren't guaranteed of it always working with that distro).
Re:Dear slashdot (Score:5, Insightful)
As a linux 'advocate' working in a large IBM customer (top 20), I feel your pain. However, give up on debian.
Seriously. If you try to run this stuff on anything other than an IBM-supported distro will start to refuse your support calls, charge extra for incidents and basically make pricks of themselves.
Your best bet is either:If you're already paying for DB2, Websphere *and* tivoli, you're looking at a few million a year. What does redhat cost, ~1k, just pay it. From there you can advocate JBoss/Tomcat instead of websphere, Postgresql instead of DB2 etc. etc.
If you run IBM stuff on another distribution, who do you think will be up against the wall when your fixed price call out suddenly becomes a ~$1k/hr (lab rates) fix?
Re:Dear slashdot (Score:3, Informative)
Re:Dear slashdot (Score:5, Insightful)
There are plenty of good business reasons to want to use Debian... the very same reasons you or I use it.
1) Security updates are done quicker than recompiling/manually installing (The competition is catching up).
2) Software installation to a new machine will take less time on a Debian system because it will update to the latest versions automatically instead of applying patches over the original install (competition is catching up).
3) More software packages prepackaged means that there are fewer custom compilations/installs, which means installing/upgrading client machines will take less time.
4) Setting up your own APT server means you can distribute your own upgrades internally, and even package non-standard software yourself. This means you can write one install/setup/upgrade script for oracle, and have it automatically propogate through the network instead of installing it on a per machine basis.
Every one of these points saves time. If a company is under pressure right now to save money, applying some of that presure on IBM might be a good way to get the ball rolling toward getting support for Debian. IBM only supports SuSE and RedHat because that's what everyone else uses. There is enough room in the market for another supported distro, especially one as easy to support as Debian.
I wouldn't sacrifice support, because that would put your job on the line, but I would lobby them to ask IBM to support Debian. If enough people in your position do, they'll add it to the supported list. You might want to have them run a test on the next server upgrade/install by installing Debian on it. If that means that IBM doesn't get service fees for that server, and you tell them so, then they'll start paying attention. You're company can always switch a single, not-so-critical system to a supported platform at any time without a significant loss. You just have to convince them that the potential economical gains are significant enough. If that server sits in the corner doing it's job without anyone touching, they'll start to see the wisdom. If you suggest something like a single server as a test bed, they'll see it as more of an experiment to try to save money, and if it fails, it probably won't be your job, but if it succeeds, and you implement it company wide and save a lot of money, then you will probably have eliminated a need for your job, and your boss will get a raise from the portion of your no longer needed salary.
Re:Dear slashdot (Score:5, Insightful)
First of all if you are using stable (and a corporation should) the chances of apt get going wrong are just about null.
Secondly you could buy a support contract. Just like you could buy a support contract from MS.
Finally this is OSS. You can get support even though you didn't buy it. The debian community is especially clueful and helpful. Chances are you'll get better support for free then the first or second level droid at your other company. In most cases you should solve your problem in less time then it would take to escalate it with MS.
"new one has no support contract, and the new one goes wrong, it's all YOUR FAULT. If you use the existing system, with a support contract, and it goes wrong, it's the fault of the contractors, or whoever installed it, not you."
Maybe where you work you can simply say "it's Microsoft's fault" and go home. Not where I work. Your ass is on the line when the server goes down. No ifs, ands or buts about it.
Put Debian on my ThinkPad (Score:2, Interesting)
simple (Score:3, Insightful)
just goolge the name and you will find his website with the paper links..
Or the hard way.. start your own business and demand it as per your ceo status.. I went the hard way
Getting what you pay for (Score:5, Insightful)
If they support your environment.
The gains you might think you'll get by using Debian are absolutely not worth losing your service contract, which you've likely already paid for. There's nothing horribly wrong with SuSE or Redhat, both generally supported IBM environments. If you succeed in getting your boss to install Debian, you're on the process of going up a river without the proverbial paddle.
Re:Getting what you pay for (Score:5, Insightful)
If your company, as it appears, uses IBM software/hardware, it prefers to pay some (ok, a LOT;) extra $$$ to have the peace of mind of having a large, monolithic corporation a phone call away:). As a hacker, you'll adapt easily to SuSE or RedHat (sure, we all raise hell about the differences, but let's be honest here;). As a company though, and especially a "conservative" one, they'll have -much- harder time adapting to a different model of doing things. In all honesty, sounds like you might be doing them a disservice by offering what is, in the end, an officially unsupported OS. Do you want to be the one who inadvertently nullifies their support contracts (no matter how unreasonable their requirements may be)?
You need to think beyond what you would like to play with, and extend your viewpoint to all the possibilities and risks your company might encounter in the years ahead. If they're more comfortable knowing somebody is guaranteeing, supporting, and in the end, taking the blame for their software/hardware, then it's a strategic policy you should follow.
There's little other then deception to persuade them to use Debian, if they are the type of company you describe.
Re:Getting what you pay for (Score:5, Insightful)
Not always the way it is (Score:5, Insightful)
But there's places where I can see Linux boxes excelling where other software falls short. One of them is our Spam "solution." It was very expensive and it doesn't work for shit. 80% accuracy, maybe. Lots of false positives. In 2002, it was really cool shit. But that's the problem - things change fast when it comes to certain things like Spam and when you pay $50,000 for a license to filter spam you don't want to upgrade or change softwares every six months.
Enter OSS - My (*gasp*) spamassassin+dspam+amavisd-new is easily doing 99.99% of the spam with extremely low occurances of false positives. Is it supported? Nope. Wait, yes it is. I SUPPORT IT.
Some companies are all about support, support, support. They don't trust their IT staff, they consider them expendable. I don't work at a company like that. They put weight in our abilities. If you can make a good case for an OSS solution, one where you can support it yourself and train others, it will be seriously considered. Apparently there's other companies like this too, since a lot of places are running Linux now and not all of them use RedHat Enterprise.
Support (Score:5, Informative)
However, it sounds like your Enterprise has already standardized around IBM. As good as Debian is, I can't see how it's good enough to lose an enterprise support agreement, even if it's just a few machines.
Maybe you can threaten the sales people to go to HP if they don't amend the support contract to include Debian. They probably will know you're bluffing, but it might help.
I know! (Score:5, Funny)
Your rationale vs. their rationale (Score:5, Insightful)
They want to run IBM solutions because they can trust that the few apps that they actually want to run on the system will run with no trouble.
The trouble here is that you want Debian on the systems for your own selfish reasons. They want to run their systems as reliably as possible. Since this is a business and not a college dorm room, the business case will always win out.
Debian is a fine distribution. But no company in their right mind would go through a migration just so you can install the latest and greatest software via apt-get. You see, they've already got the software they need running on the system.
Except Debian is only REAL OSS (Score:5, Interesting)
It's truely free and fully open source, support is just about as good as Red Hat or Suse [again unless you're willing to paybig bucks], forward and backward releases are supported fully...no pressure to upgrade on a company's timetable, and software compatiblity is of the highest level... In a nutshell Debian IS Linux!
What's needed in the general OSS movement is to get more corperate interest in the grassroots OSS movements... Personally, I'm a Suse fan...because they have some great IBM hardware ports [like iSeries/AS400!] but realistically, distros like Gentoo and Debian are the future of software...companies like RH & Suse are attempts to strap "traditonal" lock-in software business to OSS/Linux... they are bound to fail...and leave you holding the bag. The beauty of Gentoo and Debian is that anybody can bolt anything they want on to the very stable bases...and when the base changes it's easy to work the changes into your custom software...they are DESIGNED to do just what most companies need!!!
As far as stability and compatibility, isn't it an open joke that the current version of Debian Stable is pushing 3 years old...I'd call that a pretty reliable standard base...better than ANY of the corperate Linuii.
Debian - harder to support (Score:5, Interesting)
what do you mean? (Score:4, Informative)
If you're simply saying that it does things differently from RedHat, then who says that the way RedHat does things is "the standard"? As for "special config tools", etc, why are Debian's config tools "special Debian config tools", and RedHat's config tools not "special RedHat config tools"?
It seems to me that your either saying that Debian doesn't adhere to standards (such as FHS), which would be a good criticism (even though sometimes standards are wrong), but in which case I'd want some examples; or you're saying that it doesn't do things the "RedHat" way, which is like complaining about it because all of its programs aren't in C:\Program Files.
PS: Personally, I use Gentoo.
Re:what do you mean? (Score:3, Insightful)
As with many others here, I use Debian at home and love it. However, if you have to tie yourself up in knots to get Major App A to work on Debian, then jump through all sorts of hoops to get support for Major App A from the vendor because the vendor doesn't support Debian, then from a business perspective I'd have grave doubts about choosing Debian in the first place.
Yep it's great for all sorts of r
Re:he means what he says (Score:3, Insightful)
As noted in the above message, I don't use Debian, but Gentoo (and I probably wouldn't recommend Gentoo to a corporation, due to lack of big-company support, unless there were special circumstances that hyperbolized the benefits of Gentoo).
I'm
Why dont (Score:5, Insightful)
Re:Why dont (Score:3, Informative)
The round hole is our operations organisation. The square peg is the task we are trying to complete. I see Debian as the sledgehammer that might get it all to work.
Our only issue here is support. That's it. In practice, I have no doubt Debian will live up to our requiremen
Move First, Change Later (Score:2, Insightful)
And like others said before, once he's hooked, the rest is history
It's difficult enough as it is to convince PHB switching to Linux, and I wouldn't try jumping over two hurdles at once.
if it's just apt.... (Score:5, Interesting)
I went through this same discussion at my company, as Debian is my preferred distro as well. The thing is, beyond the distribution scheme, I really don't get to experience the true differences between the distros, as I'm usually running an unstable release anyways.
The link above also documents creating an apt RPM repository - we did this at my company, and to be honest, 99.9% of my gripes with RedHat went away completely.
I'd suggest looking into apt for RPM, it fixes a lot of the problems, and doesn't introduce those posed by a totally new distro on your production boxes.
Re:if it's just apt.... (Score:5, Informative)
It's also about the number of packages in the release. Debian is several times the size of either RedHat or Suse. We don't want to spend time compiling software and building RPMs, we just want to get on with doing our job.
What are you actually installing? (Score:3, Insightful)
Debian + Commercial (Score:5, Funny)
Keep the Debian all Open and you're fine (Score:4, Informative)
Debian Philosophy says: "Just recompile your app from source"
Commercial interests says: "Just use a supported distribution for our application"
The best thing you can do is keep the Debian box all stuff that complies with the Debian Free Software Guidelines (DFSG) and you'll be fine. If you need something that's no in Stable or not a late enough version in Stable, check out http://backports.org for expanded/updated packages. My last job used an old dual proc P3 running Woody to host our development "all-in-wonder" box - CVS, Bugzilla, CVSZilla, Wikki, development intranet web pages and some supporting tools. We used an rsync via ssh to a Solaris box w/ tape for nightly backups. It worked like a champ for a small team (4 devs, 1 manager & an occasional tester) without blinking. I'm sure would have scaled up at least 5 times that before the hardware we were running it on became the bottleneck.
demo (Score:5, Interesting)
When it comes time to decide on an actual rollout they have to make a decision to go with a distro that they know is proven in their environment, or go with what IBM pitches.
But in either case, what you're doing is making the haters defend on two fronts: the vendors pushing for one linux and you pushing for another. With the debate being "which Linux" it stops being "why Linux". It's a win-win.
I can't agree with you. (Score:2, Interesting)
Re:I can't agree with you. (Score:5, Insightful)
Re:I can't agree with you. (Score:3, Interesting)
1-If it ain't broke, don't fix it. People are lazy and upgrading apps is alot of work.
2-They are afraid they are going to fsck something up. Either its a complex environment or they don't trust their knowlege of the system enough to do it. ie, not many people in the real world stick their necks out if they don't have to, especially if htey have families at home.
Go HP! (Score:5, Informative)
PS: No, I am not an HP employee.
Let's use something unsupported.. that'll go over (Score:5, Insightful)
Here's my take .
If it's not supported/approved by IBM and you are dealing with IBM then find out what they support and use that.
Why?
Because 1) it's easier, and 2) you want to succeed.
Your job is not to move the organization. Your job is to make your boss look good. IBM is very very talented at making their customers look good at very reasonable prices. You will make your boss look better with IBM's willing help than by trying to fly it yourself.
Apt-get is nice and all, but frankly, support is nicer. If you don't understand that, btw, then you are not experienced enough to be making the decission on what to move forward with. I'm not saying this to be an ass . . . but simply because it's true. Moving them to Linux is smart, but moving them to something the hardware vendor doesn't support is stupid
RedHat is more appropriate (Score:5, Insightful)
The core differences between distros are package management, the version of the kernel, and the version of libc. Debian might work fine for what you want it to do, but a subtle problem might occur that you didn't catch during testing, due to a version difference. I've found that shoehorning, as you mentioned, is generally a bad idea. Shoehorn too much, and your feet will hurt.
Given your conservative environment, I think RedHat's Enterprise Linux product line is more appropriate. RedHat can sell you a commercial support contract, and they promise software updates for 5 years. Also, future Linux admins are more likely to be familiar with RedHat, which avoids needing to learn Debian's quirks. Also, IBM or other commercial software (like Oracle) is more likely to be supported on RedHat.
Support? (Score:3, Interesting)
IBM? Support? Ha! My company (a large multinational financial corp) made the mistake of outsourcing all the technologies through IBM. Some of the stuff works, but their websphere Host-On-Demand system for terminal emulation is crap. The support angle of it is absolutely awful. I have a job thanks to their miserable support of anything they don't provide to us at astronomical costs. My team supports everything they don't. Their policy is, "If we didn't provide it then 1) we don't give a damn about it, and 2) we won't even attempt to help you integrate it into the environment we provided for you." Good luck. It took us years of badgering them before they would clear the way for installling Apache on a workstation to provide automatic updates of image processing. And on top of that, they didn't even try to give us a solution - it was just plain no. When we want to do something now, we just do it. Then hell with 'em. If you can wean your company off of their teat, then my hat is not only off to you, but also covered in mustard as I will be happy to eat it.
Re:Support? (Score:3, Informative)
I think you are confusing who you are getting support from. If you buy "shrink wrap" (albeit expensive) software from IBM - or anyone else - there is a level of support that comes with it.
"Outsourcing" has a completely different connotation. If means, beyond the shrink wrap software, installing it, configuring it, and potentially a huge amount of customizations. Does the solution they provided conform to the spec that you gave them at the beginning? You seem to think "support" means "free work after the co
IBM has helped us out... (Score:5, Informative)
They won't support the software, but they will support their hardware running it.
Re:IBM has helped us out... (Score:4, Insightful)
Conversley, if there's a bug in the default xfs setup in the default redhat kernel, IBM calls up redhat and says "fix it" and redhat says "sir yes sir I love you sir would you like coffe with that".
It doesnt get thrown onto some mailing list, argued about for a few days, crammed into somebodys bugzilla or wiki, opened and closed three times, moved catagories, sit through a developer moving appartments, ignored by an irc channel with 60 idling people, dissapear into usenet, etc.
99% of someone saying they "offer support" is just the fact they they have the balls to say "we're so sure this works we're prepared to accept the dent supporting it will make in our budget". For instance with redhat, the very fact that nearly all their customers can file a support request with them now, means that if they didn't have a damn good product, they would lose all their money to support costs. Plus, when there are genuine fixes to be made, they can use their margins to hire full time programs to fix exactly what their customers need fixed pronto... not when some package maintainer gets around to it. You'll notice this is why a metric fuckton of open source projects have @redhat.com email accounts on their credits page. You'll also notice that redhat's commitment to the GPL is near debian like, they even buy other software products and gpl them. When you're paying redhat to support your linux, you're actually in a large part paying them to improve linux to a point where it needs less support.
I didn't mean to turn this into redhat praising, but merely to counter the insane, annoying, and far far to prevalant attitude around here that redhat is "screwing" anybody with their pay model or "turning their backs on the community". If anything paying for redhat is the easiest way I can think of to support linux development (especially the kernel).
Distro fights (Score:3, Interesting)
It eventually boiled down to a single point: SuSE had commercial backing from Novell. Debian is purely a community-maintained distro. If we built a server for a customer, and then that customer decided they wanted to buy support for it, the only safe answer was to use SuSE or Redhat... and frankly, none of us (including the management) liked Redhat a whole lot.
At the end of the day, you need to ask yourself a few questions:
1) Are you happy supporting %DISTRO linux?
2) Are your management types going to be happy with it?
3) Are your customers going to be content with it?
4) Is it compatible with commercial packages? (Really important... although you might be able to shoehorn say, Chilisoft onto Debian, do you really wanna do that across a couple of hundred servers, and then end being responsable for manual updates or whatever?)
Easy answer... (Score:3, Insightful)
Regards,
Steve
sandbox it (Score:5, Insightful)
RHCE's aren't going to do what we can do with *our* distro's, it's more than just LInux to us.
CB
Why? (Score:5, Insightful)
If you have a stable working enviroment, why change?
Is this move going to be cost effective?
Is the distro I use going to be the proper one?
Why am I really using this distro? If you say, because it is the one I use at home, then you need stop this project right in its tracks.
How easy is it to manage this distro in my enviroment. Running "apt-get upgrade" on 500 servers is not do-able.
Is there proper management software out there for my distro/platform of choice?
Does my software I need even run on my distro/platform of choice?
What about support for my software on my distro/platform of choice?
Can I keep my system software in sync across all servers?
Can I easily manage the distro install process?
Can I trim down the install time?
Can I make the install process automated?
These are just the basic questions you need ask. Don't get stuck on one distro. Be flexable and look around. Redhat or Gentoo or something might be better choices.
Notes from a former IBM employee. (Score:5, Informative)
I used to work for IBM in the division that developed DB2 for Windows, OS/2, Linux, and various Unicies (but not OS/400 or other "big iron" systems) three years ago, and worked on code for DB2 v6 through to v8.
At that time, our Linux testing was primarily against Red Hat and a few others (from hazy memory, Turbo Linux, Red Flag, and one other I don't recall at the moment). Debian was not tested at all for any of their products. Red Hat was their primary focus, and seemed to be the Linux platform most of the developers ha on their desktop systems (although a lot of the Unix development was actually done through AIX-based systems).
Things may have changed since this time, but I haven't seen any outside evidence of this. Do you really want to try running these applications on platforms and with packages that the original vendor hasn't done any testing with? The IBM products you mention are not cheap -- why risk having them break by running them on an unsupported platform?
If you're a big account, talk to your IBM account rep and tell them you'd like to move to Debian. You'd be suprised how much IBM will do for a big account (or, at least, would do when I was there).
Yaz.
Notes from a current IBM employee who uses Debian (Score:4, Informative)
If you get a chance to talk to anyone from IBM, make it clear that you'd really like Debian support. Then use a supported distro. Really, this is the best advice you're going to get.
I like and use Debian on all of my computers, including my company-provided T40 laptop. I do it because I like it and because I'm willing to put in the extra time it takes to make it all work. And it does all work, including DB/2 and Websphere and Lotus Notes and bunches of other stuff.
But I still wouldn't recommend it.
Why do I do it then? When I started using Linux on my laptop (my primary workstation), the only officially-supported desktop operating system in IBM was Windows 95. Given that there was no official IBM Linux distro, I picked what I liked, and I struggled through all of the issues to make it work. I stick with Debian because (a) I like it and (b) it's not clear that migrating to the internal (Red Hat) distro would save me any time, 'cause my system works great.
However, if I had to install a new Linux image for work right now (instead of just migrating my old Debian image), I'd go with the standard build, mainly so that I'd get support, and so that every non-Free app I have to install wouldn't be such a pain. I've always run unsupported desktops ever since I worked at IBM -- the OS/2 load they gave me when I started back in 1997 lasted two days -- but it has of late become more and more painful in direct proportion to the amount of internal Linux support, ironically enough.
So my current opinion is that if you're running commercial software on production systems, you should use a supported distro, which means Red Hat or SuSe, pretty much -- and not just with IBM software. Those are the platforms that are supported by all the vendors of commercial Linux software.
Never thought I might say this... (Score:3, Insightful)
There's plenty of help on the internet at large, but they arent paid to have an answer to you in any amount of time. They don't even have to answer your questions at all. In fact they could simply call you a tart and a fop and go frig yourself or something strange like that instead.
Evangelize Linux, to be sure. But stick with what's supported. You'd rather have IBM or RedHat to point a finger at when it doesn't work rather than sitting on your thumbs and trying to explain to your boss once again why Debian was the superior choice.
Some advice (Score:3, Interesting)
Go with a flavor of Linux that IBM supports, then later when you're feeling adventurous introduce a Debian box or two. Making the Linux transition any more difficult than it has to be seems utterly pointless, especially inside a conservative organization. Make sure they take the right lessons away from this, not some ambiguous point confused by distro issues.
Muddying the waters with unsupported distro complications is just bad judgement.
Shoehorning (Score:5, Insightful)
This isn't a PHB issue, either. Anyone with a real production system should be scared off by language like that.
Two hurdles instead of one (Score:3, Insightful)
What would Linux be used for? desktop or server room? Debian makes more sense for the latter (stability, consistency and good response time to security issues) than for the former (unease of install, antiquated desktop on Debian Stable, lots of work needed to maintain essentially your own desktop-ready distribution, obvious support issues with IBM, look on the management people face when you tell them your wonderful distro is based on "Debian Unstable", etc).
Maybe you can make the pill easier to swallow if you go to a more commercial version of Linux first, e.g. SuSE or RedHat? This way you only have to clear the first hurdle of making Linux acceptable in your company. It will still come with support contracts, releases, and other things management can cope with. Not to mention that these distros and others have to some extent caught up with Debian, using apt themselves or yum.
If your setup is Linux for the desktop, how much experience do you have with managing more than a handfull of machines and a couple of users under Debian Linux ? Debian currently makes a fine meta-distribution but don't make the mistake of assuming it will be as easy to maintain as your own machine. You'll have to cope with more user demands than just your own and a wider array of hardware.
Simple question (Score:3, Informative)
Doing something like this is just like trying to use Perl or Python (or Java or whatever) in an all-C/C++ shop for the first time. It may be the best solution for the problem you happen to be solving. But if the company doesn't consciously maintain a knowledge base in the "new" technology, any of the new work is essentially dead once the author leaves. Same thing applies to a new OS, a new third-party app, or whatever.
The best technology solutions are maintainable, extendable, and reusable. And the most common error is to overlook maintainability.
I am experiencing this as well (Score:3, Insightful)
It is true that Debian does not have much commercial support, beyond Progeny and a few others.
However, it is the easiest linux distro to support, hands down. It is far more deterministic, more polite to it's user base, and far easier to support your commercial software on that anything else (provided you do it right). Why debian is not more popular with big houses is a topic up for grabs, but it has more to do with psychology, intertia and plain ignorance than anything else.
and to those who are saying "shut up and go with what's there" I might remind you that the reason they're using linux in the first place is because users (in this case admins) wanted to use it. The demand came before the supply, OK?
I believe Debian is so far superior to the other distros that wide support for it is inevitable. It makes too much sense. I think partly the reason is isn't widely commercially supported is because Debian spent the first years of it's existence more concerned with infrastructural matters than anything else, without much concern for usability. Now that they are very actively working on usability issues and other assorted superficialities, look out. they have a solid, modular architecture supported by well designed political process.
Lastly I might add Debian is not a company that can be bought or influenced by money; it is a non-profit with protected legal status. It is very politically stable and is the only software producing organization I know of that has a social contract with it users. Gentoo or FreeBSD (both being somewhat "cathedral like" in their organization) may have the quality of Debian, but they can't match the political stability, and neither can any commercial company.
We've Actually Done It (Score:4, Interesting)
The other Debian box we built for this application was for running Tomcat with the Sun JDK pushing a web-based reporting tool. We were able to demonstrate how Debian supported removing all unrelated packages (including compilers) and lowered the security profile lower than their Solaris boxes. (They still used telnet, God help them) The demonstration worked and the server is running Debian in production on the [redacted] government network.
Don't push it. We recommend Debian because of access to the build/distribution system and the ability to craft custom loads for specific purposes (point-of-sale, thin client, rich client, etc.). Controlling the build/distribution environment is a bigger issue than many people realize. But we really support anything because after a certain point, Linux is just Linux.
Comment on DebianPlanet about how we do it [debianplanet.com]
We use it in our business and support it for our customers. No problems here! Go Debian!
shoe horning is part of the problem (Score:3, Interesting)
You find yourself using terms like shoe-horn, this should be an indication to you that the shoe doesn't fit.
I have done exactly what you want to do (Score:5, Informative)
First, the install on Debian isn't smooth. I tried the latest stable Debian as well as some updated packages that I knew I'd need. I installed Websphere and had some problems. Stuff worked, eventually, but it was a pain that I wasn't willing to deal with on an ongoing basis (fixpacks and such). Java GUIs were particularly troublesome, although the web console is really all you ever need. Java problems worried me a lot.
I tried Suse and Red Hat's enterprise offerings, which I had been given demo disks for, as well as their free counterparts. One major hurdle with Red Hat was that there are some major Java threading issues with RHEL 3.0 and Red Hat 9 and above, so I'd be stuck with RHEL 2.1 or RH 8. I decided to go with Suse 8.2, which is supported as a development platform (no free Linux is supported for production use).
What I found on my distro adventures is that IBM supports anything, but they do complain about it. For instance, even our old environment had RH 7.3 while only 7.2 is supported. During my Debian install it was IBM who helped me get it working. When supporting these distros they constantly question the Java version and go through a checklist of software versions to make sure everything's ok. But like I said, they will support it.
While I have gotten bad support from IBM before, overall they are much better than any other company I've had to deal with on an ongoing basis. They really do try to help out. A couple times I've had some idiot at their help desk so I asked to be transfered to someone else, but other than that they've been great.
Please contact your IBM sales rep (Score:5, Interesting)
SuSE or RedHat... (Score:3, Informative)
With that said, use SuSE. The last thing we need is more RedHat customers. Competition is vital to keep Linux from turning into a RedHat-only proposition (in the enterprise). Support SuSE, at least keep it a duopoly between Novell and RedHat - they'll beat each other up and keep things fair.
Debian Release Cycle (Score:3)
I've picked Debian for an embedded systems project we're working on.
The problem with the distros out there is that some are updated 2-3 times per year (stable release to stable release) and then the old releases are supported for maybe another year.
We wanted something with a longer release cycle. Sure, we could have picked RHEL, but the client is cheap, and didn't want to pay big bucks for support.
So we're going with Debian Sarge. It should go stable well before the project has finished development, and with any luck (i.e. Debian again takes forever to push out another release), we'll still get security updates for 3 years or so.
But this is an embedded application without a lot of external software dependancies. We're using a free database, for example.
I've experimented with several distros, but I've stuck with Debian for our servers and workstations. Our main fileserver, for example, has never, never ever crashed. I'd have 4 years of continuous uptime if it wasn't for various office moves and OS upgrades. I attribute it to very solid, somewhat expensive hardware, a good UPS, and Debian. It first ran 2.2, and now runs 3.0. And in a few months, it will probably run sarge (3.1)... or be retired because it really doesn't have that much free disk space left. :-)
Are you crazy? (Score:3, Insightful)
Stick to standards, and things you can duplicate exactly, or you're asking for a world of trouble.
-Todd
Similar situation (Score:3, Informative)
Now contact all parties involved and tell them you need support. Oh yeah, my distro is Debian. Everyone from IBM hardware to IBM Software to SteelEye will tell you to go suck rocks and come back with a supported distro.
When we did our TSM install, we had an issue with RedHat 2.1 and the 3582 Tape Library Driver. We called IBM and they provided a driver but it only worked on RedHat 3.
What did we do? We upgraded the box. What good is our nice shiny infrastructure if there's no backup?
Now everyone will bitch and moan that you shouldn't lock yourself in like this or that you should just run whatever distro you want. We designed everything about our enterprise app to be portable. If we get tired of Websphere, we move to Tomcat which is our development platform anyway. If we get tired of DB2, we move to Oracle or Postgres or some other database. We aren't using any DB2 SQL.
But until that time, I like the fact that I can make one call and get the support I need. It's IBM hardware running IBM software. The only non-IBM stuff is the OS and SteelEye LifeKeeper. IBM actually worked with SteelEye for us on a DB2 issue with our SAN.
Having said all that, we do use a few unsupported configurations. Our app uses CUPS for server-side printing. Those boxes are Gentoo. Our datawarehouse is mysql running on Gentoo. The interesting part is that I've actually gone unsupported in one area and that's the warehouse. I had to do a bit of engineering to get Gentoo and my two Fiber Cards to recognize the SAN properly. That and I did a custom ebuild of TSM for backup purposes.
All of this leads me to say one thing, if you value your job, stay supported and keep distro zealotry out of the way. If the company is willing to spend on IBM hardware and software then the cost of a SELS or RHAS license is nothing. It will pay off the first time you call DB2 or WAS support about an issue that, while not having ANYTHING to do with the underlying OS (other than it's Linux), they won't help you because you decided to go unsupported. Explain that to your boss as you're being escorted out the door.
Waste of time (Score:3)
Managers do not reach decision-making levels in large organisations by listening to rational arguments. They get there through a host of means including but not limited to back-covering, buck-passing, palm-greasing and politics-playing.
Whenever presented with an argument their first reaction will be to do the updside/downside caculation, which goes roughly "If my name is on this and it goes right, how much kudos do I get vs if it goes wrong, do I get the blame"? Nobody to whom the blame sticks progresses up the pole.
If they choose GNU/Linux and it goes right, there will be some bottom-line benefit. A million people will claim that the small bottom-line effect was not due to the choice of GNU/Linux but better outsourcing, maintenance contracts, management or whatever it was that THEY are responsible for.
If there is a single significant failure, EVERYONE will point to the hapless decision-maker and say "See, told you so, this free software is crap and there is the idiot who selected it, no wonder we fsked-up / lost money / had downtime.
Now, put yourself in the position of the person you are arguing with. You are pressing the wrong buttons.
IF however you can pass the blame AND save money, there is a slim chance of getting the argument through, but trust me, the argument will revolve 80% around blame and 20% around cheaper/better/whatever.
Who is your principal software maintenance company (can't see the parent post whilst replying). Was it IBM? IF you can get them to guarantee to support the software and carry the blame, you have solved one of the blockers. Problem is, they only support RedHat and SuSE/Novell.
Unsupported Debian? Forget it, it is a waste of time. Appeals to rationality, quality, goodness of fit are not the issue. Should some remarkable turnaround occur and (say) EDS suddenly announce support for Debian you have the slimmest of chances, but if EDS or whomever aren't already involved in big contracts in your outfit, the supply-chain people will find reasons not to start negotiations with them (risk again) instead of sticking with the existing known supplier (much less 'risk').
Your only hope is to find a friend in the maintainer/supplier and convince those people first. Then they take your manager person out to dinner/golf and start telling him/her why Linux is so good for your business and that might stand a chance of winning.
You don't like what I have said above? Your choice, but I do this stuff for a living. I know the reality.
IBM DB2 support (Score:3, Interesting)
I work in Italy. A company that produces an accounting package was interested in bundling their solution with our Debian-based server product.
Their solution uses DB2 for its database. It was important to them and their clients that IBM supported the DB2 installs back-ending their software. IBM only certifies DB2 installs (at least in Italy) on RedHat 7.X and a flavour of SUSE I don't recall now... Yes, in 2004 they will insist upon RedHat 7.X if you want IBM's support. Yes, I pointed out that RedHat doesn't support 7.X any more so essentially they were asking their clients to choose a lack of support for their DB or lack of support for their OS.
I'm sure there are countless examples where heavy-hitting software vendors have been able to cajole support from IBM for other distros but small software companies haven't got a hope.
In a last-gasp effort, I adapted the IBM installation and update scripts to use alien and dpkg and demonstrated that they worked flawlessly. The accounting package developers were happy, we were happy... IBM refused to budge.
Running Debian (Score:3, Insightful)
The colo machines are running Woody (stable), but in the office, I'm running Sarge (testing) and Sid (unstable) on my desktop, just because it includes the latest KDE. Usual story: needed just one package; tried backports, hit snags; decided what the hey. No problems as yet. Remember, Debian is always more stable than Fedora -- and packages won't get updated unless people actively test out the newest versions and give decent feedback. Also, in Debianese, "unstable" refers not to the behaviour of the software, but to the level of development activity. If you want a really unstable operating system from Debian, try experimental
To summarise, I recommend: Stable for remote servers; Testing for servers you can physically get to and other people's desktops to which you can get root access; and Unstable for your own desktop.
15+ debian servers for 4+ years (Score:4, Informative)
We're mostly developers, which is probably what made us attracted to debian in the first place. We have a developer in our group that wears the sysadmin hat (ducks) but he is both a black-belt problem solver and a good admin. I enjoy the anal-retentiveness of debian-devel and its great to see so many minds focusing on a project.
We put a lot of faith into Debian. Our servers run all of our models and our execution platform, which trades enough securities every day to put my face on MSNBC if something goes horribly wrong.
We do use 3rd party libraries in our software development, and as far as they know, we're running Redhat like we're supposed to. I have yet to have a conversation with someone in tech support that is really a Linux guru. I'm not going to claim to be one, either; however, the code I support is only used by my group. The people I usually talk to in support are usually developers, too. If our group had to support 3rd party executables, then Debian probably wouldn't work so smoothly.
All these negative comments about Debian have suprised me a little bit. Perhaps I don't read /. often enough. And no, I probably wouldn't recommend Debian to any of my peers outside my company. But I don't think "Using Debian in Commercial Environments?" is a ridiculous question, either. It can work without a headache for a troop of coder monkeys writing in-house software.
It's the certifications (Score:3, Interesting)
The thing that keeps Red Hat and SuSE on the top is certifications, validations and things like that, which aren't free.
Is Debian enterprise ready? Yes.
Would I recommend it to enterprise customers? No.
First, very few application vendors explicitly support it. I've had bad experience with Red Hat 8 (a vendor who "supported it" until we run into a RH8-specific bug they couldn't fix, then they recommended RH Enterprise Server) so I would be very very careful about that. This has nothing to do with "skillz" - sometimes to make things work you'd need to change the application or do something which isn't possible.
Second, if you happen to need to connect it to SAN or such hardware (or install Oracle on it), you'll be in big trouble - not because it can't be installed (it can) but because the customer would kill if they knew their 100K of h/w or s/w has been rendered unsupported because you've used an unsupported OS.
Third, in many situations, OS cost is about 1% of total TCO, so why bother?
Debian needs certifications and h/w vendor support. I hope some big Linux user will donate this money to Debian to get couple of important certifications for enterprise h/w and software.
Re:Good Luck (Score:3, Interesting)
In years past, I introduced more than a few people to linux when we brought in cvs for source code control, bugzilla for issue tracking, apache for our intranet, etc.
Some of these apps can be run on Windows, but we got it running much easier on linux.
If you bring the right (read USEFULL) applications in, linux will sail right in.. because you weren't bringing in linux, you were solving a problem.