Slashdot Mirror

← Back to Stories (view on slashdot.org)

Red Hat Becomes First $2 Billion Open-Source Company (zdnet.com)

Posted by BeauHD on from the playing-upon-the-gullibility-of-venture-capitalists dept.

An anonymous reader quotes a report from ZDNet: Red Hat just became the first open-source company to make a cool 2 billion bucks. Not bad considering Red Hat became the first billion dollar Linux company only four years ago. Red Hat did it the old-fashioned way: They earned the money instead of playing upon the gullibility of venture capitalists. Red Hat's total revenue for its fourth quarter was $544 million. That's up 17 percent in U.S. dollars year-over-year, or 21 percent measured constant currency. Subscription revenue for the quarter was $480 million, up 18 percent in U.S. dollars year-over-year, or 22 percent measured in constant currency. Subscription revenue in the quarter was 88 percent of total revenue. Analysts estimated Red Hat would make $534 million. Looking ahead for its 2016 FY Red Hat expects to see between $2.380 billion to $2.420 billion. At this rate, Red Hat should easily become the first $3 billion open-source company.
While Red Hat's president and CEO Jim Whitehurst credits the "hybrid cloud infrastructures," Red Hat's subscription revenue can largely be ascribed to Red Hat's flagship product: Red Hat Enterprise Linux. Still, RHEL, which is now available on Microsoft Azure, is becoming a prominent cloud operating system.

62 of 116 comments (clear)

  1. Good for them! by Rinikusu · · Score: 2

    I've long switched to debian-based distributions, but I remember buying boxed distros in the 90s to help support the commercialization of Linux. I'm still waiting for LOTD*, but a win's a win.

    --
    If you were me, you'd be good lookin'. - six string samurai
    1. Re:Good for them! by bluefoxlucid · · Score: 2, Interesting

      I'm not so nice: I switched to Ubuntu because, as much as I dislike their politics (Mir vs Wayland, Unity vs Gnome-3, etc.), they provide software *correctly*.

      RHEL will suddenly break your shit mid-release. They won't ship an out-of-tree kernel module or a patch to a kernel driver to save your life, so good luck with RHEL 6 and Intel e1000e NICs (get the -lt kernel from ElRepo; but you can't remove RH Kernel or you break LSB, so have fun managing your bootloader as it keeps switching back to the broken one and then dropping network entirely on a kernel OOPS). They freeze the distro at a point release (6.7, 6.8, 6.9...) as they publish security patches, while ripping out some configuration subsystems and throwing in new ones (what has worked last week no longer works today, and you can freeze your release and not get further support!).

      It's not even about being 9 years out-of-date on dot-zero release day--that's what Ubuntu over Debian is about. It's about having a zero-length support cycle on system-breaking changes. It's like if Microsoft upgraded Windows 2003 to Windows 2008 but kept calling it Windows 2003, and told you you could avoid all the major system changes by turning off all updates before that patch cycle--and suddenly the configuration files, registry entries, and supported features change or are outright deprecated and removed out from under you.

      In Debian policy, you don't break things during release unless you have an extreme circumstance. If it worked on release day, it will work on EOL day. The software may be ass-old and out-of-date, but it's going to be the same software all throughout release, with the same configuration, the same features, and the same behavior. They might break something if that's the only way to remove a critical security vulnerability, but not if they can find another way around. Ubuntu turns this into a 6-month release cycle with 3 months to get your shit together after each release, or you can have a 2 year release cycle with 5 year support (LTS).

      I never use RHEL-style distributions if I can avoid it.

      --
      Support my political activism on Patreon.
    2. Re:Good for them! by hawaiian717 · · Score: 2

      Your complaints seem to match my experience, though it might be that we use the system differently. Fedora was great for breaking changes, but RHEL (CentOS in my case) is generally rock solid. Yes, newer stuff can take a while to get supported.

      The main reason I wanted to reply is that there is a fix for your problem with the kernel updates switching back to the default kernel. Unfortunately I'm not sure it's covered in the RH documentation, but if you were to change the value of the DEFAULTKERNEL setting in /etc/sysconfig/kernel to your alternative package name (kernel-lt to use your example), grub should continue to use the kernel you want when yum updates the kernel. Oracle actually documents this for people who want to change from the their UEL kernel to the Red Hat kernel: https://docs.oracle.com/cd/E37...

      --
      End of Line.
    3. Re:Good for them! by hawaiian717 · · Score: 1

      And that's what I get for failing to proofread until after I submit. The first sentence should read "Your complaints don't seem to match my experience,...".

      --
      End of Line.
    4. Re:Good for them! by Etcetera · · Score: 1

      RHEL will suddenly break your shit mid-release. They won't ship an out-of-tree kernel module or a patch to a kernel driver to save your life, so good luck with RHEL 6 and Intel e1000e NICs (get the -lt kernel from ElRepo; but you can't remove RH Kernel or you break LSB, so have fun managing your bootloader as it keeps switching back to the broken one and then dropping network entirely on a kernel OOPS). They freeze the distro at a point release (6.7, 6.8, 6.9...) as they publish security patches, while ripping out some configuration subsystems and throwing in new ones (what has worked last week no longer works today, and you can freeze your release and not get further support!).

      I never use RHEL-style distributions if I can avoid it.

      Yeah, this doesn't match my experience at all either. Larger than "normal" changes do happen at the X.n, X.n+1, etc points, of course, but I've hardly ever had *anything* break that wasn't well documented in the notes and usually forced by some sort of outside issue. (Breaks if we change it, breaks if we don't change it.)

      About the only thing that really comes to mind was the cluster manager software somewhere between 6.2 and 6.4. Virtually everything else I can think of back to the 4.1/4.2 days has been just the addition of features, moving things from Tech Preview to fully supported, or adding hardware support.

      Frankly, I wish the RH/RPM side of the market was structured more like the Debian/dpkg side, where Debian sets long-term stability base and Ubuntu builds on it. If Fedora were built from RHEL/CentOS, it might not have made so many dumb choices over the past 6 years.

      --
      Hire a Linux system administrator, systems engineer,
    5. Re:Good for them! by bluefoxlucid · · Score: 1

      I've had RedHat break multiple subsystems during a point release. Once, they removed an entire configuration system (crmsh) and replaced it with a completely different configuration system. They outright removed the packages. I've seen them do major upgrades of sever software on a point release and put n the release notes that certain deprecated features are now non-features and your configuration won't work if you used them.

      The weirdest one was when I upgraded httpd and Apache broke because you need to load a module to have ifenv, but the version that shipped in the prior point release had that module enabled by default. yum update resulted immediately in a broken web server, and the same config file that worked before didn't work anymore. I did that on three servers, though only the first one caught me off guard.

      --
      Support my political activism on Patreon.
  2. Revenue != earnings by JoeyRox · · Score: 1

    $2B in revenue and $288M in earnings for the year. Still nothing to sneeze at.

    1. Re:Revenue != earnings by Junta · · Score: 1

      Payroll, capital assets, power bills, etc etc.

      ~15% margin is respectable, a *touch* on the lean side for the industry.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:Revenue != earnings by PackMan97 · · Score: 1

      Well, they do give all their software away for FREE! In that respect, earning $2 billion and a 15% margin is a miracle ;) They have also been growing 20% year over year for some time so a lot of those potential earnings are reinvested into the company/aquisitions.

    3. Re:Revenue != earnings by rudy_wayne · · Score: 2

      Would be interesting to know where the other $1.7B goes.

      Lot's of highly paid employees. Lots of them. Far more than they actually need, and hence the $1.7 Billion in overhead.

    4. Re:Revenue != earnings by david_thornley · · Score: 1

      You can get the same software for free quite easily, and many people do. People pay to have it selected and packaged and supported by people they trust, and so what Red Hat provides is labor-intensive.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  3. "open source" by iggymanz · · Score: 1, Informative

    closing access to the security/bug repositories except to paying customers isn't the open source spirit. RedHat forgets who made them great, it was us in the 90s that could install and try it out, and became sold on it so we introduced it at work by buying the full support.

    That's why a lot of us have tossed RH over the side at work now for alternatives. Using Fedora, an alternative distro that makes the users test rats for RH brain farts, is making us 2nd class citizens.

  4. Red Hat introduced systemd? by Futurepower(R) · · Score: 1, Troll

    My understanding is that Red Hat is strong enough that the company was able to force systemd on the Linux community, and did that because the unfinished, poorly documented systemd brings in more money for Red Hat support.

    Any sense in that?

    1. Re:Red Hat introduced systemd? by Anonymous Coward · · Score: 3, Funny

      Spell it "SystemD" not "systemd"

      That way it looks like an ASCII penis.

    2. Re:Red Hat introduced systemd? by wardrich86 · · Score: 1

      So you're saying it's the System's D.

    3. Re:Red Hat introduced systemd? by sherr · · Score: 5, Insightful

      Red Hat made the decision to go with systemd for their own operating system. They didn't "force" it on anyone else. If you're unhappy with Debian / whoever else's decision to use systemd you'd better to talk to those maintainers. Obviously they see value in it or they wouldn't be using it.

    4. Re:Red Hat introduced systemd? by Anonymous Coward · · Score: 1

      As the 800-lb gorilla, they forced it via inertia. In the real world you don't just broadcast "change to this" and assume everything will follow, it never works. You don't use a hammer to move things, you use your weight to push things around.

      Unless you're Microsoft or Oracle of course. They just simply squeeze your balls harder, no need for finesse.

    5. Re:Red Hat introduced systemd? by sconeu · · Score: 1

      I thought it was the grade Lennart got on the project....

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    6. Re:Red Hat introduced systemd? by cfalcon · · Score: 2

      Why? Debian doesn't source from Red Hat. You're saying that because Red Hat does it, EVERYONE has to? Come on!

    7. Re:Red Hat introduced systemd? by Anonymous Coward · · Score: 3, Informative

      They really did not. Especially not on Debian. Everyone had their say, publicly, and the majority of Debian maintainers chose systemd over sysvinit/OpenRC.

    8. Re:Red Hat introduced systemd? by westlake · · Score: 1

      My understanding is that Red Hat is strong enough that the company was able to force systemd on the Linux community, and did that because the unfinished, poorly documented systemd brings in more money for Red Hat support.

      Then systemd should also be bringing in more money for those supporting Debian, SUSE, Ubuntu, etc., etc. The saner argument for REHLs success is that support costs are lower, not higher.

    9. Re:Red Hat introduced systemd? by Etcetera · · Score: 1

      Red Hat made the decision to go with systemd for their own operating system. They didn't "force" it on anyone else. If you're unhappy with Debian / whoever else's decision to use systemd you'd better to talk to those maintainers. Obviously they see value in it or they wouldn't be using it.

      The Fedora community (which includes a number of Red Hat employees) made the decision. A not-insignificant chunk of the Red Hat Enterprise *users* are not happy about that, but by the time EL 7.1 came out and anyone really cared the decision was long-since past.

      In regards to Debian (and other distros) this is the bandwagon effect (or slippery slope, if you prefer). Debian did it because Fedora was already doing it and resistance seemed futile. The remaining distros even moreso.

      If the overall linux community could call a do-over and revisit 2010-2011 knowing what we know now, there's no way the community would have stood for it. It *barely* was accepted then (and caused a mini-exodus then) when it could still call itself an "init system" with a straight face. The behemoth of interconnected components and lock-in designed to make it really inconvenient to resist or switch away from would never have been approved. I'd like to think that's "would never have been approved, even by RH EL engineers", but it's hard to say.

      What I *can* say, though, is that enterprise sysadmins want predictability and determinism, and value unpredictable dynamic-ness and boot times far less. Incremental improvements on the initscripts package, following Debian's lead and switch /bin/sh to /bin/dash, a few added features to xinetd, and the addition of a couple of optional service managers (daemontools, or whatever you like) launched from an rc-init script of its own, would have meant far less churn and far less mess.

      --
      Hire a Linux system administrator, systems engineer,
    10. Re:Red Hat introduced systemd? by Etcetera · · Score: 1

      If you really feel that sysvinit was something that should be kept around, [a] you're in the substantial minority; even OpenRC is mostly written in C (check their GitHub page if you don't believe me), and [b] you're welcome to maintain it -- and you should, because no one else is willing to.

      There's less point NOW, but that's due to the land grab that systemd's developers performed, not due to technical evaluation... and certainly not in the Fedora 15 days. Anyone who's ever been in a large, political org with management trying to gain control of systems and services in such a way that no one objects strenuously enough at any given step, but that makes them difficult to remove at the end, should be that pattern. Or anyone who's ever been a boiled frog.

      There was some guy on here complaining that people didn't get enough use out of the actual sysv init's abilities (i.e. things provided by inittab). He was absolutely right. inittab does such a bad job of managing services that practically no one used it -- certainly not for anything important. So people rewrote init functionality into their own scripts. And then they duplicated it, for each script. Sometimes better than other times. For thirty years.

      And... what exactly was wrong with that? A core /sbin/init that does very little but reap zombies and for all important actions hands things off to userland scripts? This model works fine for many other aspects of many OS's... A core micro kernel that's simple, auditable, secure, and trusted, and user-level code to do everything else?

      A typical argument in favor of systemd was that people writing scripts to imperatively handle startup was somehow wrong, without clearly explaining why. I'll admit that Ubuntu's scripts were a little messy, but (ironically, given how it spread), in RedHat-land things were quite nice. If you didn't want to have a startup script, you could use one of several service managers to deal with the startup and tear down (xinetd, for example). If you wanted one, it was extremely simple to write one.

      1) Cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScript#Initscript_template
      2) Replace 2 or 3 variables
      3) Customize further as or if needed.

      Done. That's not hard.

      It's distinctly possible that had OpenRC been more mature, it could have had more uptake. What is completely certain is that sysvinit needed a stake put through its heart, and even though they have (moved a great deal of code into C libraries, added dependency resolution, cgroup support, and parallel startup, and generally) cleaned up the codebase quite a bit, I still don't think they have the right balance. You can put a lot of lipstick on a pig (daemontools, or whatever you like), but most of the time, providing half of the features you really need is worse than providing none at all. Even in OpenRC, the init process either does too much (even for a small codebase there's still stuff in there no one uses), or too little (e.g. without process tracking it has no idea if the services it starts are still running).

      Mu.

      Seriously, you're begging the question here. If I want a service manager, I should use one. If I want something to hold sockets open for me, I should use a supervisor (inet, xinetd, etc). These all functioned (and function!) perfectly well as independent subsystems. There's very little that MUST be handled in pid1, and very little reason why some-random-administrative-task MUST be handled by something from the systemd-* project vs what was already out there.

      What it sounds like you're saying is that you like the way things are broken right now, as opposed to the different broken that some other system provides. That's great for you, but I wouldn't lump anyone else into that box. Especially if you're pining for ye olde init scripts; those aren't

      --
      Hire a Linux system administrator, systems engineer,
    11. Re:Red Hat introduced systemd? by Holi · · Score: 1

      Exactly how does systemd on Debian bring in any revenue for Red Hat? Until you can intelligently explain that you sound like a conspiracy theorist.

      --
      Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
    12. Re:Red Hat introduced systemd? by david_thornley · · Score: 1

      By that reasoning, Debian is using RPM for package management. In fact, having one generally used system for package management would be a good thing in itself.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  5. Re:"open source" by sherr · · Score: 5, Informative

    The free version of RHEL is CentOS or Scientific Linux, not Fedora. Fedora is, as you note, a upstream, fast-moving, bleeding-edge, "test" OS. If that's not what you want then you're using the wrong thing.

  6. Re:"Open Source" by Anonymous Coward · · Score: 1, Interesting

    Redhat's success really has little to do with open source, other than they could take advantage of the fact that someone else created the Linux kernel for them and they could build on that.

    Redhat doesn't make money selling Linux. They make money selling support contracts. When you buy RHEL that's what you are actually paying for.

    No different than buying the "Enterprise" version of Windows.

  7. Re:"open source" by Junta · · Score: 1

    They are open source, but if you want to run big-R 'RedHat', you need a goofy rhn subscription/satellite to get updates and such, instead of it just working.

    CentOS is a lot more *convenient* to use as a consequence. Of course there is a more steep promise associated with 'if I installed it from RHEL repoes, RH will answer about it. RH is a careful company that doesn't make such a promise lightly. It would rather not get caught unable to reasonably support software it was the authoritative download for.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  8. Re:Idiot submitter by Junta · · Score: 1

    It's a particular sort of statement. When they said '$2B company', that *usually* refers to market cap (which can indeed be exaggerated by unfounded confidence).

    To refer to a '2B company' meaning 'company that pulled in 2B of revenue in a year, that's a bit different.

    Hence the errant comparison of revenue to overvalued startup unicorns.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  9. RHT is a 13 billion dollar company... by Junta · · Score: 4, Interesting

    Generally, when you say 'an X dollar company', people are referring to market cap, or the aggregate consensus value believed in by your investors.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:RHT is a 13 billion dollar company... by KirillSolovey · · Score: 1

      Generally, when you say 'an X dollar company', people are referring to market cap, or the aggregate consensus value believed in by your investors.

      Red Hat was founded back in 1993, which means it took them twenty years on the up to the billion in revenue. The company was something like twenty years old when it made the first billion. Soon after Red Hat made second billion, so the question remains: how long will it take to get to its third? Among the others new control panels for Red Hat, there are some worthy: https://serversuit.com/communi... [serversuit.com]

  10. Re:"open source" by StormReaver · · Score: 1

    Closing access to the security and bug repositories to all but paying customers is understandable in Redhat's case, and isn't a factor for my workplace dumping Redhat. We have a few reasons (in no particular order):

    1) License tracking is license tracking, regardless of whether it's Redhat, Microsoft, or Oracle. The major appeal of Free (and Open Source) software is not having to report to anyone.

    2) We don't use Redhat support for anything other than software updates. The few times we used Redhat support for problem solving, the support personnel knew less about the problem space than we did. This is typical of most paid support.

    3) With Redhat, there is no freedom to fire up a new virtual (or physical) server without significant additional cost, just like with non-Free software.

    We're migrating everything over to Debian.

    Debian's structure is more sane and consistent, is easier to manage, allows us to retain our freedom, and allows for unrestricted flexibility, including the ability to scale services up and down as we see fit. Not to mention, every issue we've ever had with Debian was answered on a public forum.

    I think it's great that Redhat has become so successful, and wish them the best of luck in the future. I hope the door doesn't hit them on their way out.

  11. Re:"open source" by iggymanz · · Score: 1

    those lag behind redhat of course, CentOS a month for last release, SL two months

    which isn't too bad compared to past

  12. Re:"open source" by iggymanz · · Score: 1

    You would have to build binaries yourself and hope you get the settings for compilation "correct"

    worth noting the binaries are NOT identical between redhat and centos and scientific linux

    http://community.redhat.com/ce...

  13. Re:RHEL licensing by Junta · · Score: 1

    The issue being that if you break it, you have no one to reasonably point the finger at. This is a big deal in most commercial settings.

    I have seen first hand a user of open source software sing the praises, but ultimately couldn't find another company to support *precisely* what they were using, and had to scrap it and frankly have a much worse experience for lack of commercial support. It's a big deal. Whether it should be or not.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  14. Re:"Open Source" by Archangel+Michael · · Score: 3, Interesting

    Most Products and Services in the IT world are that way. Dell Computers are more expensive not because they are better, but rather because you get "Enterprise" support. Do not underestimate the power of "Enterprise Support" in the world of CIOs and Directors of IT. They have a distinct aversion to taking the blame for bad decisions, and that "Enterprise" label allows them to shift blame to the vendors.

    When you build the solution yourself, and it doesn't work, you get the blame. When you have Dell or someone else "Enterprise" build it, and it doesn't work, you can blame the vendor. That difference is worth the price for the people that care.

    --
    Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
  15. Re:"open source" by iggymanz · · Score: 1

    not understandable at all when they're spitting in the face that made them a success. the money is for official redhat phone support, hot fixes, etc.

    note the binaries are different between redhat and centos and scientific linux, the compilation environment isn't perfectly duplicated

    oh well, we've removed hundreds of redhat at work. good luck with the empty suits when us tech people won't specify you, redhat. of course, you depend on the oracle and ibm wares that list supported distros, but realize even there are alternatives to RH and there is big push to remove the domino, websphere and even oracle in many business sectors.....

  16. Re:"Open Source" by paulatz · · Score: 5, Informative

    Redhat's success really has little to do with open source, other than they could take advantage of the fact that someone else created the Linux kernel for them and they could build on that.

    Who funds Linux development? RedHat: 11.2%

    --
    this post contain no useful information, no need to mod it down
  17. Re:"Open Source" by rudy_wayne · · Score: 1

    Most Products and Services in the IT world are that way. Dell Computers are more expensive not because they are better, but rather because you get "Enterprise" support. Do not underestimate the power of "Enterprise Support" in the world of CIOs and Directors of IT. They have a distinct aversion to taking the blame for bad decisions, and that "Enterprise" label allows them to shift blame to the vendors.

    Exactly right. There's an old saying in business: "When something goes wrong, there better be someone you can blame".

  18. Re:"Open Source" by Anonymous Coward · · Score: 4, Insightful

    As an actual Director of IT, aversion to taking the blame for things that are my responsibility has nothing to do with it.

    I have a limited team of people to work with, and I have a lot of things to manage, including the phone system, the data center, our office network connections, security, desktop support, and the list goes on.

    What I don't have the time to do is take my small team and build brand spanking new solutions myself. I pay someone to provide 4 hour support so that when my tired ass needs to show up in the data center at 4am, there is a disk or even a whole new box waiting for me that I know is going to work. And often a technician to put it in for me.

    One time, I remember mentioning looking at the price tag for some service that would cost me $10K a year and thinking I could totally do that myself. I mentioned that to someone else and he pretty much said, there is no way that you can do that for ten thousand dollars if you actually add up the costs of building and maintaining that. He reminded me of a rule I have: Only do something yourself if you know you are the best person to do it. In the end, I might save $10K only to cause myself sleepless nights and reduce the availability of my systems.

    Yes, people get ripped off all the time. You won't see me touch Oracle with a ten foot pole unless I absolutely, positively, need the high end features it provides. I will use an open source DB or a cheaper commercial one. But I will still throw down money for support, because they know this stuff better than I do and can get it to work faster than I can. That makes my company able to make money and the people at it able to do their jobs. Enterprise support is not something you buy just because of the label, but if they really do provide good Enterprise support, you put that shit on your budget and you don't look back.

  19. Re: Why do the rulers of /. Have to... by cfalcon · · Score: 1

    I shit talk Microsoft all the time, never seen one of my posts go away.

  20. ... Debian maintainers chose systemd... Why? by Futurepower(R) · · Score: 1

    "... the majority of Debian maintainers chose systemd... "

    But why? Were there reasons other than good management? Was it difficult to ignore something Red Hat did?

    1. Re:... Debian maintainers chose systemd... Why? by Holi · · Score: 1

      Ask the Debian maintainers, but blaming Red Hat for their choices is fucking stupid.

      --
      Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
  21. Re:"open source" by cfalcon · · Score: 1

    I think part of it depends on what you are doing with your Red Hats, and what the expectation is. If you are running a bunch of internal servers for computing tasks or network tasks, I think that many Linuxes have serious strengths there, and a cost benefit analysis is a pretty big deal. At my work, we've been married to Solaris, and any Linux we use would have to have the blessing and backing of an entity like Red Hat- and hopefully we'll be switched soon.

  22. Re:"open source" by tnk1 · · Score: 1

    Unfortunately, the FedGov lurves its Red Hat. It also loves Windows too. Expect that the growth in government services will keep increasing the revenues of both companies for the foreseeable future.

  23. Re:"open source" by Wycliffe · · Score: 2

    The free version of RHEL is CentOS or Scientific Linux, not Fedora. Fedora is, as you note, a upstream, fast-moving, bleeding-edge, "test" OS. If that's not what you want then you're using the wrong thing.

    CentOS was created without Redhat's help when Redhat discontinued and tried to kill the open source version of their product. The gave everyone fedora so they could technically be in compliance with the open source license but they had enough glue that was not open source so that centos and fedora had to jump thru a bunch of hoops to be usable at all. So, no, CentOS is not the officially sanctioned open source version of Redhat. Redhat tried (and luckily failed) to kill off the open source version of their product.

  24. Re:RHEL licensing by tnk1 · · Score: 1

    If you have a certain sized organization, you will find that paying for RHEL support is sort of silly. You literally have hundreds of SA's and developers on your staff, many of them experts, and some even contributors. At that point, you're *better* than their support.

    However, that is only true for organizations over a certain size or competence level. There are a lot of small shops who run Linux who could use the help. There are also a lot of... less capable... large shops that could use the help too.

    I've been involved in a few RHEL to CentOS migrations and they mostly go well if we've been running RHEL for awhile and you have the right people. With the wrong people, you just have a lot of people confused about what is going on, despite the fact that its like 99.9% the same code. Of course, most of the confused people are the business people, so there is some truth that the value of RH is the fact that a business person has heard of it.

  25. Re:"Open Source" by ShanghaiBill · · Score: 1

    Red Hat also received plenty of VC money, so I don't know why the summary brings that up ... and VC money is not "earnings", it is equity.

  26. RHAT IPO by lfp98 · · Score: 1

    I remember well the Red Hat IPO. It was supposedly open to the public on E*trade and I was at work waiting to buy in, but turns out it was only available for an instant, not sure how long exactly, but anyway I and many others missed the boat and were pretty angry, especially when it rocketed from IPO price of $14 to $300. Some even complained to the SEC. It split 2:1 but then fell below $5 so I bought a bunch then, it's certainly done better than most of the tech bubble stocks.

    1. Re:RHAT IPO by ebvwfbw · · Score: 1

      I bought as much as I could. It was open to the public, however you had to have some involvement in the company. Even if you were just contributing to bugtrack you were in. I fully support that. Why should we let those that have no involvement make a bunch of money. My lesson is I learned the difference between a market order and a limit order when it was around $300/share. Don't worry, I made plenty.

  27. Re:"Open Source" by Archangel+Michael · · Score: 3, Interesting

    We recently bought a set of servers from ___, Enterprise VMWare destined servers, and the SSDs? LiteOn. Which failed to deliver the performance needed for the job. Flat out didn't work. Granted, the company _____ replaced the drives, eventually, after we proved they were not capable. The problem I have, is I would NEVER have spec'ed LiteOn Drives for anything even close to "Enterprise".

    And in the end, we wasted nearly 4 Man Months of time trying to fix the problem.

    And my boss, buys Enterprise, even when I can PROVE that they are exactly the same, off the shelf consumer products, for twice the price. Me, I would buy two for the price of "Enterprise" and keep one on the shelf as a Spare. Knowing where you can get the perfomance you need, at a price that isn't "Enterprise" often allows you to stretch your IT budget AND provide the support your organization needs.

    I'll pay for support, I'll even pay a lot for support. But I won't pay for "Enterprise" that is only "consumer" with a new label.

    Here is BACKBLAZE's article on Drives t hat kind of supports my view ... https://www.backblaze.com/blog...

    --
    Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
  28. Re:RHEL licensing by RabidReindeer · · Score: 1

    RHEL licensing fees are precisely why my organization is migrating to Windows.
    A Windows SA Site license makes it cheaper to run Windows Servers than RHEL.

    Depends on the number of servers. If you've got lots of Windows servers, then you'll be spending the money on extra system administrators.

  29. They wanted something easy to maintain by Tenebrousedge · · Score: 5, Informative

    The mailing list is public, go and check it. Alternately, this site was put together as a summary of the various positions and options. If I can characterize it, there was a strong desire to move away from sysvinit due to lack of features, bugs, and difficulty of maintenance. Systemd at the time was seen as the best of the alternatives, offering more features and easier maintenance, at the cost of compatibility with non-Linux systems.

    Not that I have any great insight into the minds of developers, but I suspect that the decision might have gone otherwise if it were re-held today. I think there would be a stronger consensus against sysvinit, as even fewer people are interested in maintaining those scripts. OpenRC has had more time to mature, and as far as I know Upstart development has basically ended. Interestingly, OpenRC and systemd share a number of features, particularly in their heavy use of C libraries, for which OpenRC receives no criticism and systemd no end to criticism. Either way it looks like that, dependency resolution, cgroup support, and parallel startup have made everybody's minimum feature list. I'm sure it would have been an even more different story if cgroups/process tracking had been a part of sysvinit/POSIX to begin with, but as I understand they were mostly codifying existing practices rather than trying to actually create a good standard.

    In any case, Debian moving away from sysvinit wasn't any more influenced by Red Hat than it was by Canonical. All options were on the table, and each of them had their proponents. There was somewhat more backlash against systemd than other options, but I don't think politics played much of a hand in the decision -- politics didn't have to maintain the code afterwards. And despite the popular clamor for sysvinit, most everyone else seems to have dropped it happily, so ignoring the populace seems to have been the right decision in that respect.

    --
    Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
    1. Re:They wanted something easy to maintain by jrumney · · Score: 1

      Upstart development ended because Debian made the decision to move to systemd, and Ubuntu subsequently decided to follow them, since numerous packages were suddenly going to start depending on systemd, and it was too much effort to fight the combined momentum of Debian and Red Hat on that. Upstart was Ubuntu's answer to moving away from sysvinit - limited in scope to the init functionality, and still with text files for configuration and syslog for logging. A much less radical change, but similar performance gains and dependency management for the startup phase.

    2. Re:They wanted something easy to maintain by Tenebrousedge · · Score: 1

      Upstart never had the contributors it needed. The Debian discussion/wiki I linked has a number of critiques. It solved little or no problems of sysvinit, introduced many of its own, and wasn't portable to other systems. Upstart had a head start on the other init replacements, and while social/political concerns may have contributed to its demise, its technical issues were what stood in the way of its success, and ultimately doomed it.

      --
      Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
  30. Re:"open source" by iggymanz · · Score: 1

    well certain parts of the federal governments operations also have Scientific Linux (RH based free of cost), SLES (some supercomputers), and Cray Linux

  31. Re:"open source" by Anonymous Coward · · Score: 2, Informative

    All of what you say is accurate, however, RH don't paywall the code, just the binaries. This is how CentOS and friends exist - RH publish the source RPMs to comply with the GPL, and from the beginning ensured everyone knew they were there. They also announced that if you wanted to use them to build your own products, you would have to strip out all of RH's logos and other IP (hence the "prominent North American Enterprise Linux vendor" of CentOS).

    CentOS is now pretty tight with RH as well, as they've directly sponsored CentOS since 2014 and have hired the project leaders.

  32. Re:"open source" by Etcetera · · Score: 1

    those lag behind redhat of course, CentOS a month for last release, SL two months

    which isn't too bad compared to past

    Speaking of the past, it hasn't been like that in forever. CentOS is usually same-day, sometimes a day or two later. The only exception is usually full-point releases, which might be a week or so if something drastic changed in the ISO building/installing process.

    RHEL6 > CentOS 6 was a one-off issue, although it did prove that having two downstream distros (one varying, one trying to be a completely binary compatible rebuild) is a good thing.

    --
    Hire a Linux system administrator, systems engineer,
  33. Re:RHEL licensing by Etcetera · · Score: 1

    The issue being that if you break it, you have no one to reasonably point the finger at. This is a big deal in most commercial settings.

    I have seen first hand a user of open source software sing the praises, but ultimately couldn't find another company to support *precisely* what they were using, and had to scrap it and frankly have a much worse experience for lack of commercial support. It's a big deal. Whether it should be or not.

    CentOS for your development and cloud systems, RHEL for your "important" systems or where it scales directly with revenue generation.

    A $300/box license fee per year for commercial support is trivial for large enterprise systems, where the server might be handling $50,000 of annually recurring revenue and probably cost over $10K to begin with.

    CentOS and RHEL are functionally identically in everything not involving 'yum' and rhn deployment, and if you're doing anything at the scale of a couple of hundred servers or more the expertise in your SA/SysEng department should be completely transferable.

    --
    Hire a Linux system administrator, systems engineer,
  34. Re:"open source" by Wycliffe · · Score: 2

    Bullshit

    There needs to be a mod option for "dumbass" but troll will do.

    There is nothing in the GPL that demands that RH do anything other than what they are doing for RHEL.

    You can paywall GPL code, idiot.

    Fedora is the test version.

    If RHEL is out of license compliance, Fedora would do nothing to solve that.

    shh

    I never said it wasn't within their rights nor did I say they are out of compliance. They release the source of the parts of their OS that they are required to do so. The average user is not going to have the skills nor desire to compile their own OS. Nothing that you said negates the fact that where previously they were releasing a free open source version of redhat in parallel with their commercial version, when they switched and no longer released a free open source version that the open source community who was used to using redhat had to scramble to get something usable again. redhat went one step further than most companies and even makes them stripe out any reference to the name redhat which is probably considerable work. CentOS is fine now but it was a rough at the very beginning. I actually switched to mandrake/mandriva when they did that and have since switched to ubuntu. Previously I had owned purchased copies of redhat but I don't trust them anymore.

  35. Re: "open source" by buchanmilne · · Score: 2

    1) License tracking is license tracking, regardless of whether it's Redhat, Microsoft, or Oracle. The major appeal of Free (and Open Source) software is not having to report to anyone.

    It's not a licence, it's support. Depending on whether you have signed a contract that restricts you further (at your own choice) or not, you can install as many copies as you like (but you would need to do some work to get updates to more instances, like run reposync on an instance that has a subscription).

    2) We don't use Redhat support for anything other than software updates. The few times we used Redhat support for problem solving, the support personnel knew less about the problem space than we did. This is typical of most paid support.

    We, a linux-centric team within a big telco, also only use RH support for updates for the same reason (we can almost always resolve issues quicker than it would take to get a ticket escalated to soneone with skils. However, in a few instances RH support has identified issues where someone on our team made a mistake which then alloeed a quicker resolution.

    However, other less-experienced teams in the rest of the company need RH support more than we do.

    Also, when dealing with other vendors (server, storage etc.), it helps to be able to tell them 'Red Hat has vetted our config, your solution claims to be certified on Red Hat on this hardware combination, our support contract now requires you to fix our stirage issue'

    3) With Redhat, there is no freedom to fire up a new virtual (or physical) server without significant additional cost, just like with non-Free software.

    For VMs, that depends on the subscription. You could easily buy unlimited VM subs and run 10 VMs for less in subs than the 5 VM sub.

    In fact, Red Hat Smart Virtualisation (RHEV, aka supported ovirt, plus unlimited VM subs) is cheaper than the cheapest way to get vSphere Enterprise (VSPP), and you get supported VMs for free.

    Who are you paying for your vietualusation infrasructure software? Did you factor his in to your comparison?

    For non-production physical machines, we spin up RHEL instances in minutes (via kickstart), and only take out a sub if it ends up being a permanent installation or requiring support or updates. However we are busy phasing out the use of physical servers wherever possible and replacong them with VMs on RHEV.

  36. Re:Wait huh? by coolsnowmen · · Score: 1

    What have you had trouble finding? https://github.com/ansible/ans... http://vault.centos.org/ http://www.jboss.org/downloads... https://github.com/wildfly/wil...