Dietrich Schmitz, writing for the Linux Advocates website, posted an article yesterday about how Red Hat's adherence to the Linux Standards Base (LSB) guarantees stability and reduces costs in the enterprise. While I agree with Mr. Schmitz wholeheartedly, from my perspective the reasons by Red Hat Enterprise Linux remains both the leader and the best choice in business, government and non-profit spaces goes far beyond the LSB.
I've been a professional UNIX/Linux systems administrator for 18 years now. I've had to implement, maintain and support servers from all of the enterprise distributions and a few distributions not generally used in the enterprise as well for my employers and customers over the years. I'm a big advocate for Red Hat and the various free clones (CentOS, Scientific Linux and Springdale Linux) as the best solution for most organizations. First, it's exceptionally stable as Mr. Schmitz points out. Second, it offers the longest support period at 10 years. Third, they have excellent and professional support.* Fourth, they do the best job at insuring compatibility with both FOSS and commercial apps during the full 10 year release cycle.
My big issue with SUSE Linux Enterprise (SLES/SLED) is that they do push major version changes of the kernel, tool chain and apps in what they euphemistically call Service Packs. The Service Packs are actually major releases recently and have been known to cause major breakage and pain. My experience with their support organization here in the U.S. has been less than satisfactory, particularly the time needed to respond to and resolve issues.
Canonical (Ubuntu) has much shorter support periods than either Red Hat or SUSE. They also don't backport additional hardware support or patches into their kernel, forcing you to either do the SUSE style update gamble even more frequently than with SUSE or else to run without needed support and/or vulnerabilities.
The free clones of Red Hat Enterprise Linux I mentioned earlier are not permitted to name their source, referring merely to "the upstream provider," but pretty much everyone in the Linux community knows precisely what they mean. They represent a real advantage to Red Hat (the distribution if not the business) in that they allow businesses to try before they buy. They provide the opportunity to run a test bed or non-critical system at reduced cost. The clones also allow non-profits and cash strapped small businesses to forgo commercial support, at least for a time, and still use software that is entirely compatible with the leading enterprise Linux distribution. As organizations grow and their needs change converting a server or workstation running a clone to a genuine, supported Red Hat system is a simple process.
Finally, I'm sure fans of Debian and Slackware packaging will disagree with me, but keeping to standards, specifically the LSB, also goes a long way to insure application compatibility. I think it's vital that all enterprise distros follow standards.
*= Disclaimer: I was part of the support team for seven months as a consultant in 2005. I no longer am affiliated with Red Hat in any way, shape or form.
[NOTE: This article originally appeared as a comment on LXer.com in abbreviated form.]
Great article, thanks.
ReplyDeleteI have been using both Fedora and CentOS and find them to be both excellent choices. CentOS for the stability and Fedora for the incredible innovation. They are both very easy to work with and provide solid systems.
I disagree. When you look at what happened with RHELAS 3, where Red Hat backported the new thread architecture into their 2.4 kernel, that was a huge risk. Much more so than anything SUSE has done. When RHAS 4 came out there were many issues, but the most glaring one was lack of a hypervisor. RHEL 5 introduced many incompatibilities forcing RHEL 4.5 which included Xen support (something they laughed at SUSE for including at the time). To make matters worse, they defaulted the install to use Xen... I can't tell you how many people "think" they installed Linux, but really installed Xen. Then in RHEL 6 they recinded their support for Xen and said that only kvm would be supported. Also in RHEL 6 we saw a switch to upstart, instead of SysV init. And we now know that in RHEL 7 they are going to switch (again) to systemd.
ReplyDeleteNo sir. I can't believe you actually had to support both in an enterprise situation. Nobody supporting both would ever agree with your position.
You know, you were making some arguments that made some degree of sense but in your last paragraph you blew away any credibility you might have had. Red Hat is dominant in server space market share while SUSE, by comparison, has a miniscule presence. Yes, they are a distant second in the enterprise, but the operative word is distant. The bottom line for me is that a Service Pack shouldn't cause major breakage and in SLES it does, almost every time.
DeleteYes, Red Hat (and SUSE and Ubuntu) do major changes and switch to newer technology when they do a major release every three or four years. It's called progress. There is a reason there are no in place upgrades between major releases in any of the enterprise distros: major changes are to be expected. Also, since when is Xen virtualization not Linux?
Also, I'm not a "sir". Have you ever heard of a man named Caitlyn? Nope, me neither. No sales on all points.
This had me in TEARS!....too funny "Ma'am"!.....Hope he's not too offended..LOL!
DeleteFunny that you got the links right to all the distros, except for Slackware, Caitlyn. Still trying to suggest that Slackware is dying? You suggest that Debian and Slackware are not LSB-compliant, but give no details to back it up. This seems nothing more than a corporate, Red Hat suck-up piece.
ReplyDeleteFirst, a one character typo on the Slackware link isn't exactly something sinister, is it? I've corrected that now. Second, if you bothered to actually read I gave a reason why Slackware and Debian are NOT LSB compliant: the only LSB compliant packaging system is RPM. Neither Slackware nor Debian use RPM. I should have thought that was blindingly obvious.
DeleteSlackware isn't dying. However, it isn't appropriate in any way, shape or form for enterprise server use. It lacks security tools needed in the enterprise, like PAM, which is required for multiple authentication methods. It has nothing like either SELinux or AppArmor offered by the major enterprise distros. It also lacks really basic functionality like automated dependency resolution offered by every major distro except Slackware. Considering IT staff and budget cuts over recent years overworked systems administrators have no time for hunting down dependencies and building lots of lots of packages which aren't included.
Corporate suck up? How about a real analysis from a business perspective? Huge clue: without commercial enterprise-level support a distro will not merit any consideration in enterprise space.
Blindingly obvious? Only if you are a Red-Hat shill maybe. As-if RPM is an albatross hanging around all of Red-Hat's competitors since it is not used much of anywhere else, and it is a "standard". As-if that wins an argument. No, I would not have expected a pot-shot from a IT consultant. Maybe you should open up your eyes a little more, because you are coming off as a shill. Here are a few reasons.
DeleteIf RPM was included for standardization reasons, then what does it achieve? It is yet just another tool? Compatibility reasons? You as anyone know that among RPM distros, that doesn't mean you can mix and match RPMs, even from the same vendor. Is it better than other solutions?
In my "corporate" IT experience, I have installed and managed software on top of my Red Hat system using a local version of the Slackware package manager. Why? Because it simply works. RPM does not. RPM makes dependency management a monstrosity, but Slackware's pkgtools doesn't treat IT as budget constrained idiots. I got it to work, it was easy. Easier than the IT idiots I've that don't know scripting.
Also, the enterprise level software we have to install never comes in RPM form. They even say they support RHEL. I wonder why. So much for LSB promoting a "standard" package tool.
"Huge clue: without commercial enterprise-level support a distro will not merit any consideration in enterprise space."
What budget constrained company would pay for enterprise-level support? Huge clue: None. None of them want to spend any money if they can help it. If that means that install a "free" OS and don't pay for RHEL, so be it. Your points are irrelevant.
Also another ironic point. Slackware does have RPM. You can install RPM packages all you want. But I'll proudly be called non-LSB compliant to show how pointless it is. You can even do automated dependency tracking in Slackware.
Actually, every company I've done work for is budget constrained in some way, as are the two state governments I've contracted for. None would ever consider a distro without commercial support, period. I respectfully suggest that your real world experience is extremely limited if you claim support is somehow irrelevant.
DeleteRPM isn't used much of anywhere? Really? Red Hat and SUSE dominate enterprise space and they both use it. Yes, rpm is included in Slackware but it's not native to the distribution. pkgtools, OTOH, are not used in ANY enterprise grade distributions. Nada. None. Yes, you can add anything you want to Slackware, including PAM and SELinux. It isn't included in the distro and requires using third party tools not supported by the distributor. Once again, no IT manager worth their salt would permit that in their shop.
Regarding standards, one of the main bits of FUD used to discourage businesses from migrating to Linux is a supposed lack of standards. If you claim that LSB is irrelevant and you are "proudly" LSB non-compliant then you really aren't functioning in the real enterprise world.
A Slackware fan throwing around pot shots under the name "Anonymous". Hmmm... not much credibility there. You know what is really irrelevant in the enterprise? Slackware and all the other hobbyist distros.
The actual LSB specification does not dictate the package format the system must use for its own packages. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43781
DeleteThe PDF you linked is behind a pay wall so I can't confirm that one way or another. Having said that, I believe you are incorrect. In any case, as I already pointed out in another comment, neither Debian nor Slackware is certified compliant against any version of the LSB so my point stands. See: https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb Any organization that wants a standards compliant Linux distribution will NOT choose Debian or Slackware.
DeleteOK, make that you're definitely incorrect. RPM is specified in LSB 4.1. See: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/pkgformat.html
DeleteSeems confusing to me - Debian, SUSE, REDHAT maybe big names in the server markets. AFAIK - their equivalents in the Opensource Desktop markets are (respectively): Ubuntu, OpenSuse and Fedora.
ReplyDeleteAll the six big names above have many clones that IMO include non-opensource addons, so are generally used by non-commercial end-users, who might dare look at Youtube, etc.
In Distrowatch of the last few months, I have tried to publish my opinions, including the above ones - sometimes successfully. In their eyes, Android is not a Linux distribution; perhaps because it is not optimized for the 8-core CPU that it now has?
@Greg Zeng: The article is focused on the server room, not the desktop. Linux is, according to Forrester Research, just 9% of the corporate desktop market. Like it or not, Microsoft still dominates that space. In addition, openSUSE and Fedora are both test beds for their respective enterprise distributions and have made no significant inroads into enterprise space on their own. As far as the OpenSource enterprise desktop market, in my experience whatever is in the server room is also on the desktop so that companies have a single source for support and so that their internal maintenance is simplified. I think you'll find that in enterprise space the desktop and workstation editions of Red Hat are dominant, not Ubuntu or the others you've listed. The consumer market is entirely different, of course, and that is where Ubuntu is out ahead of all other distributions other than Android and ChromeOS.
DeleteSUSE Linux Enterprise has no clones whatsoever. Novell did all they could to make sure of that. openSUSE is very significantly different from SLED and really needs to be considered separately.
Finally, of course Android is a Linux distribution. I can't answer as to why Ladislav Bodnar has decided not to include it on DistroWatch. I can tell you that it doesn't have a server edition and isn't optimized for conventional desktops at all. It's main uses in the enterprise market are the same as it's main uses in the consumer market: Smartphones and tablets. Chromebooks, OTOH, are being purchased by businesses and ChromeOS does bear watching to see how it does in enterprise space.
Agreed. Certainly while Ubuntu is comfortable (sort of) on the desktops of home users, Enterprise does not need radical shifts in interface, infrastructure and ideology in the OS. Linux systems aiming to be bleeding edge leave users users with a bloody nose, as I have rediscovered when I reluctantly upgraded from a stable and fast Ubuntu 10.04. If my home experience was replicated in industry i am sure the CIO would be looking for another job.
ReplyDeleteI'm not a Large Company IT/IS professional, nor am I a developer. I am a SMALL BUSINESS IT/IS manager. I work for a factory employing around 125 people and maintain 4 servers and around 80 PCs. It is from that prospective that I offer my comment. IT is looked at as "non-value added" and a "necessary evil". I need to offer high end solutions at next to no cost to maintain my job. My only complaint about RHEL/CentOS (vs. Debian/Ubuntu) is that there is a clear fork between "server" and "workstation" versions in the RHEL camp. That makes good sense at the enterprise level, but for us guys in the trenches, the line is often blurry as we struggle to come up with low cost high yield solutions. I can create a PC that is both workstation and server or host and virtual machine in under an hour. I read these high end flame session by your folks that are clearly smarter than me, and I say you all miss the real deficiency in ALL LINUX DISTROS: Give us a Desktop Shell we can sell to our boss! I am getting Win8 crammed down my throat and I can't sell switching our mainstream PC's because we can't get a common USABLE desktop. That is my cry from the trenches. Help!
ReplyDeleteMost of the consulting work I do is in medium sized and smaller businesses though I certainly have plenty of large enterprise experience. When I write about the enterprise I am writing about all different sizes of businesses, not just large ones.
DeleteWith all due respect, combining a server and a workstation is a recipe for disaster in most cases. It usually means non-technical people working directly on a server, which in turn means a mistake can take down a whole office. That's an incredibly bad idea. I would also say that the server edition of the enterprise distributions can easily have workstation packages added and vice versa since they share common repositories. This is equally true for Red Hat, SUSE Linux Enterprise and Ubuntu.
Finally, Linux has several desktops that are much more usable than Windows 8. For a "common desktop" within an organization you end up setting the common standard. For shops migrating from Windows I usually recommend KDE as it is highly configurable and looks the most familiar out of the box.
However, if you are crying out for one common desktop across Linux distributions that can NEVER happen due to the nature of FOSS and open licensing. The only reason Microsoft and Apple have a common desktop is because they are single companies that can dictate. There is no single entity in control of anything in the various and sundry Linux distributions.
I happen to believe that competition among desktops is a good thing for Linux, not a detriment. Competition is vital to innovation and progress in all businesses and in all fields. I really, really doubt you are being forced into Windows 8 due to the lack of a good desktop. If so you aren't marketing the strengths of Linux from a business perspective.
I would say peer to peer file sharing and client PC's using Web services on a workstation PC is not a bad idea if administrated correctly. As for a common desktop solution, I couldn't disagree more. I fully understand the FOSS issue and I fight for it's adoption with my employer on a daily basis. However, the disparity between Gnome 3 (who has lost their recipe) and KDE (who also has lost their way) prevents me from moving forward. I cannot find an easy to use interface that meets both business needs, and still has an intuitive, easy to use look and feel so as to allow for adoption. I find Linux better for absolutely everything I do, but I am a technology insider (for the most part). My employer is not, nor are the minions in his employ who do various tasks throughout the plant. Please, nothing I said should be taken to the extreme that I am suggesting competition is bad. It's what makes Linux great. But can we get at least one desktop shell that meets my employers LTS and usability requirements? As for being force into windows 8, get a clue. I'm forced to but it because you CAN'T PURCHASE A WINDOWS 7 MACHINE ANY MORE. Until the desktop shell is resolved, major vendors of things like ERP/MRP systems etc. will stay in the MS camp. It's just easier for them. And worse for us.
DeleteI've been working with Linux on different environments for 10 years; I've used distributions like Suse, Open Suse, Red Hat, Slackware, ArchLinux, Debian, Ubuntu, Fedora and CentOS.
ReplyDeleteIn my current job I was the one who suggested the use of Red Hat on the servers but mainly because I saw interest of the company on getting support from the company, other than the support they give (LTS and technical support over their tools), I haven't noticed any real advantage of Red Hat over Debian at the enterprise servers environment, we have recently migrated all our cloud servers to Debian for stability and performance reasons.
Btw, RPM and DPKG systems are both part of the LSB
As we all know, each distribution have their specific target and, for example, using Ubuntu on servers might represent a risk or loss of time doesnt matter it is a certified LSB distribution too; and even when I loved Slackware or ArchLinux I wouldn't recommend them for Servers neither.
First, let me start by saying that Debian is most definitely an enterprise quality distribution from a purely technical standpoint. So long as you stick with the stable branch it adheres to the same principles as the major enterprise distributions. However, the lack of commercial support from the distributor and the lack of corporate backing is a no-go for management in most cases. That is a reflection of what management demands from IT, not a reflection on the quality of the distribution.
Deletedpkg (Debian packaging) is NOT part of the LSB unless the standard has changed very recently. Can you provide a source for your claim that it fits the standards?
Finally, like it or not, a false claim of a lack of standards is a major FUD point used against Linux to management. It's not true and that is where the LSB and compliant distributions are incredibly important.
Good article! Thanks a lot!
DeleteCaitlyn, In your opinion, what is currently the best clone of Redhat Enterprise? Recently there have been changes in CentOS (CentoOS more "Redhat investments").
And we have the Oracle Linux and Linux Springdale!
Thanks again!
Many people know Red Hat for its Operating System. But now RH has more that RHEL. Gluster, rhev, cluster suite, manageIQ etc. That makes RH a leader.
ReplyDeleteGood article Caitlyn.
ReplyDeleteI started my Linux journey with SLS in 1993, and have used and supported a lot of distros since then. I currently support RHEL, SLES and Debian servers and like them all. I will say that IMHO SLES was superior to RHEL at one time, but the situation has evolved to where RHEL and/or clones are the best fit for virtually any server scenario.
Hello Caitlyn:
ReplyDeleteI found your article when I was searching for various articles on enterprise workstation distributions. As an avid fan of stable distributions, I enjoy using RHEL and Slackware both. However, while there are plenty of reasons one might try to claim Slackware is not LSB compliant, from my limited reading of the RPM situation, I do not think Slackware can be considered non-compliant because of RPM. Specifically, my understanding of the LSB is that software should be distributed with a specific RPM subset of features, but not that distributions are required to use that format as their native format. Slackware provides at least two means of supporting such RPMs: it can install them using the RPM(1) program itself, but this lacks distribution integration; it can convert LSB compliant RPMs to its native packaging format, which does support integration into the system.
There are plenty of reasons you might want to avoid Slackware on the Enterprise at scale, or even perhaps in mission-critical applications, (though I wouldn't rule it out either, depending on the enterprise or application), but lack of standards-compliant support for RPM is not one of them.
Thanks for an interesting article; the smoldering comments (I won't call them a flame war outright) were also quite enjoyable.
OK, let me clarify the LSB issue and (hopefully) put it to bed. The Linux Foundation maintains a list of LSB compliant products including Linux distributions at: https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb Red Hat Enterprise Linux, SUSE Linux Enterprise, Oracle Linux, Mandriva Enterprise Server, Asianux Server, Linpus Lite and a number of other distributions are certified LSB compliant. Debian and Slackware are not. Even if Slackware meets the packaging requirements (and I am perfectly willing to accept that it might) it has not been certified as LSB compliant. Organizations looking for standards compliant Linux distributions won't choose either Slackware or Debian.
DeleteAaron, the Slackware fans forced the issue and I went and read the relevant sections of LSB 4.1 again. RPM format is most definitely specified. Please see: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/pkgformat.html
DeleteSlackware and Red Hat appeal to different sorts of security consciousness. Red Hat appeals to the sort of security consciousness found in business: Is there somebody I can sue if things go wrong? If I get sued, can I blame somebody else? Will the due-diligence reports look good to Risk Management, the CFO, legal counsel, and so on?
ReplyDeleteSlackware appeals to the sort of person who starts to worry any time they cede any control to anyone other than themselves: Do I have to trust some package management system designed by somebody else? Do I have to worry about bugs and security holes in that package management system? Or am I in complete control of which packages are installed? Most enterprise clients would fear a sysadmin with the sort of control Slackware provides.
I've read this sort of comment from Slackware users before and I honestly don't get it. As someone who has used both distros my question is this: what can I control with Slackware that I can't control with Red Hat or CentOS or openSUSE or any other distro?
DeleteI find it edging into tinfoil-hat / lock up your food levels of security consciousness, myself. That's one reason why I took the trouble to compare and contrast with the sort of security consciousness one finds prudent in a business environment. (Something I should have added: If/when it goes down, how soon will the experts have it back up? Time IS money, after all.)
DeleteMy best understanding is that Slackers regard the presence of a big, complex dependency resolution system controlling software installation on their system as a a giant bug source and a security risk in and of itself. Anyone aware of how bad dependency hell could get back in the early days of Red Hat should be able to understand how such an attitude could develop, if not how it could survive the current reliability offered by APT, zypp, and yum. But you are better off asking Patrick Volkerding (alternately, his disciples at linuxquestions.org) than me. It is his project after all, and that is how he has run it from the beginning.
As to your comment on commercial support below: I am reminded of http://xkcd.com/979/
The xkcd cartoon does hit the mark in terms of what peer/community support can be like at times. Commercial support is an insurance policy on two levels. The first is when you have a complex problem that you can't solve easily and where time is money. The second, the big one for management, is what happens if the system administrator(s) leave suddenly and you just don't have a top notch Linux person on site.
DeleteI really, really hope more companies and systems administrators take your attitude on security, as in it's not that important and treat it as "tin foil hat" paranoia. Why? I make really good money cleaning up after security incidents and then hardening the systems. I can use the business. Seriously, considering all that's going on nowadays there is no such thing as too much security.
One comment I received on LinkedIn by Alvin Sylvain probably sums up why many of the comments that don't take commercial support into consideration are so very far off the mark:
ReplyDelete"Caitlyn is absolutely correct about the commercial support. That's one reason why so many businesses go Windows vs. Linux and/or Paid Product vs. Open Source.
And to a large extent, it's a perfectly rational way to go. You hear a lot of advocates of Open Source claim that any time you have a problem, you can look up the solutions online, which is true. But this takes TIME, and not always a small, predictable amount of time. TIME while you're paying your SysAdmin $120/hour or more.
Plus, many of the "solutions" found online need to be used with a grain of salt. Sometimes, they're just plain wrong.
I've had experience where, the only "solutions" I found to my question was other people asking the same question! And no answers.
With a commercial solution, you're paying for support. You're paying to have somebody come over and solve your issue NOW. That very often can be the most cost-effective way to handle things.
That's why businesses are going Redhat. When they buy it, they pay for support. If they have a question or an issue, they call them up on the phone and get the correct answer immediately. No worries, no issues, no wondering if a download should have been virus-scanned. "
Ladies and Gentlemen,
ReplyDeleteI would highly suggest you try and switch to FreeBSD based servers.
What on earth do you base this recommendation on? FreeBSD is NOT well supported by OEMs at all. It's market share is minuscule. The number of people who have that skill set as compared to Linux is also minuscule. To me that's a terrible recommendation, one I completely disagree with.
DeleteGood article - With regards to support, when you wear multiple hats like mine; part time sys admin, part time Oracle dba, in addition to the "day job", it is vital to have support when things go wrong. Over the years I've used both Red Hat and SuSE and my personal experience has been better with Red Hat.
ReplyDeleteWe are a Dell shop, and I find that while Dell supports both Red Hat and SuSE, they seem to be biased more to Red Hat. Their system tools such as Open Manage - are only designed for these two distro's, which is another reason to stay supported. Lastly when I call Oracle to open a tar (support ticket) one of the first questions is always "are you running on a supported O/S.
I will mention that one of my coworkers prefers SuSE because YAST bundles all the day to day support tools in an easy to use GUI.
Great article "Sir" (that was a funny comment). Written two years ago and still relevant. I have been involved in both Redhat/CentOS/Oracle Linux and SLES and have noticed a few things, mostly anecdotally.
ReplyDeleteRedhat plusses:
* huge market share/user base: this means that you will find a lot of resources out there for when you run into issues. This also means it is a very viable skillset to have in your resume.
* well developed online knowledgebase: the redhat online support/knowledgebase is also well built
Redhat minuses:
* tech support: I have actually NOT had good experience with redhat support calls. Most of the time when I do have to make a call it is a pretty in-depth problem (since the on-line and community support is well developed for everything that is not as in-depth), and I usually have a difficult time getting the issue escalated. I think I have even had one ticket closed on me before it was resolved
* operating system setup/stability: I have actually had issues on and off over the years, especially with the integrated cluster all the way back to redhat 5 and even today. Especially with clustering. To me I almost want to chalk it up to trying to throw too much into the OS and not "finishing" strong so to speak. Like they did a great job with 95% of it, but the last 5% was not done well. Two examples: the redhat 5 cluster setup, I couldn't get it going. We even paid for a redhat engineer to come out and help us and he even admitted that it was not easy. We never got the cluster setup and abandoned it. Even today, I have found that many redhat cluster (I'm talking about using the integrated luci/ricci) setup instructions will advise against using a quorum disk because it is too hard to get the timings set up right and will result in many false positive fences, instead opting to not use cluster disks and have the two nodes race. No other cluster software does this: not cman (integrated with SLES), HACMP, Windows. Another example, I have trouble setting up NTP with Redhat and using google you will find that the default ntp.conf out of the box does not work and it is easier to delete it and just copy a clean config in.
(Sorry this is a long comment)
SLES plusses:
* clean stability: I know this argues against your main point. I have found no upgrade issues with any of the applications we are using and we have used since SLES 9. I can only think that your issue came at a bad time because that upgrade is about when SLES broke off from Novell and that is I think when they broke their one year cycle of development, likely due to the purchase of Novell and then the break-off of SUSE from Novell. I'm guessing a lot of new developers were brought in, a lot of old ones were gone. We did have some issues with SLES 9 and hardware drivers, but that's it. Something else anecdotal: our inhouse team has a highly customized LAMP stack, and it compiles clean on SLES (since SLES 9, through SLES 11). They still have a lot of issues when compiling on Redhat (6.1 through 6.4)
* Great tech support: especially when I had my cluster issues, it was very easy to get to someone quickly and they stayed on the phone with me a long time, even getting other engineers involved, as I had a very in-depth issues
SLES minuses:
* smaller market share, mostly popular in Europe, not the OS. So it is harder to find resources for not-as-advanced problems. Fortunately there are a lot of general linux resources which helps. But this does mean fewer online resources, as well as a skillset that won't be as popular on your resume in the United States
Just my take.
I really like your article and hope my comments contribute to the discussion/comment thread!
"Caitlyn Very Nice information, and enjoyed the Comments."
ReplyDelete