Slashdot Mirror


Red Hat Nears $1 Billion In Revenues, Closing Door On Clones

darthcamaro writes "Red Hat is almost at its goal of being the first pure-play open source vendor to hit $1 billion in Revenues. Red Hat reported its fiscal 2011 revenues this week which hit $909 million. Going forward, Red Hat has already taken steps to protect its business by changing the way it packages the Red Hat Enterprise Linux 6 kernel, making it harder for Oracle to clone. 'We are the top commercial contributor to most of the components of the Linux kernel and we think we have a lot of value and we want to make sure that, that value is recognized,' Red Hat CEO Jim Whitehurst said. 'In terms of competition, I don't think we necessarily saw anything different from before but I'd say better to close the barn door before the horses leave than afterwards.'"

161 of 201 comments (clear)

  1. Clones around, it's "enhanced clones" with trouble by Anonymous Coward · · Score: 5, Informative

    CentOS and Scientific Linux are still workable, it's the "enhanced clones" like Oracle and Novell that are cherrypicking RHEL's best customers and not giving back to the open source community with development in open source filesystems, X, authentication, and genuine hardware support that are messing up the business.

    It's just too bad CentOS has lost its way with one of its developers, Johnny Hughes, telling people to not let the door hit them in the ass on the way out if they don't like how late everything is and then ignoring attempts to help. I just switched to Scientific Linux and and am quite happy.

  2. What about CentOS? by PixetaledPikachu · · Score: 2

    Will I still be able to get the clone in the form of CentOS? I use CentOS a lot in our development environment and less critical infrastructure, just to make sure that I'll be able to upgrade it to RHEL if the system requires more professional support.

    1. Re:What about CentOS? by MrClever · · Score: 5, Informative

      Under the GPL, my understanding is that RedHat need to make the source code available. This then allows CentOS to grab the source (RPMs) and re-badge/recompile it into a new distribution. So I don't think this distro is going away any time soon.

    2. Re:What about CentOS? by petermgreen · · Score: 3, Informative

      Straight clones should still be possible as long as redhat complies with the GPL, the main things their changes to kernel packaging will do it

      1: make it harder for unrelated distros (e.g. debian) to pigyback of redhats long term support work for kernel releases
      2: make it harder for anyone else to provide high quality support for redhats patched kernels by making it much harder for them to answer the question when something goes wrong of "what did redhat change and why".

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    3. Re:What about CentOS? by F.Ultra · · Score: 5, Informative

      It means exactly nothing for CentOS. CentOS clones the RH kernel 100% anyways and is not interested in the individual patches. This is only to stop Oracle from selling support contracts for Red Hat installations. So it has exactly nothing to do with cloning and everything to do with support (in order to support RH systems, Oracle would need to know which patches RH has and more importantly: why).

    4. Re:What about CentOS? by doomy · · Score: 4, Informative

      Straight clones should still be possible as long as redhat complies with the GPL, the main things their changes to kernel packaging will do it

      1: make it harder for unrelated distros (e.g. debian) to pigyback of redhats long term support work for kernel releases 2: make it harder for anyone else to provide high quality support for redhats patched kernels by making it much harder for them to answer the question when something goes wrong of "what did redhat change and why".

      Debian does not use Redhat kernels. Two different distributions, packing systems and philosophies.

      --
      ...free your source and the rest would follow...
    5. Re:What about CentOS? by rajafarian · · Score: 1

      Holy stuff, you have a very low /. ID number!

      I switched to Debian from Red Hat way back when Red Hat started going commercial. I send them a check every once in a while. Debian and the packaging are sublime compared to my experience with RPMs. I assume file dependency hell has been fixed. I still get newbies going on Kubuntu, though...

    6. Re:What about CentOS? by rk · · Score: 2

      Holy stuff, you have a very low /. ID number!

      Does he? I hadn't noticed. ;-)

    7. Re:What about CentOS? by Yuioup · · Score: 3, Funny

      Slashdot: The only place where guys brag about having something SMALLER than the other.

    8. Re:What about CentOS? by Dimes · · Score: 1

      Ahahahahah, you said "Debian piggybacking Redhat" ahhahahahahaha

    9. Re:What about CentOS? by ModMeFlamebait · · Score: 1

      Debian does not use Redhat kernels. Two different distributions, packing systems and philosophies.

      Debian admins, however, do cherry-pick relevant fixes backported by RedHat to older kernels. Or rather used to do.

      --
      Pavlov. Does this name ring a bell?
    10. Re:What about CentOS? by Spirilis · · Score: 1

      Neither did I!

      --
      the real at&t mix
    11. Re:What about CentOS? by petermgreen · · Score: 1

      Indeed but IIRC they have with some releases deliberately picked the same version as redhat so they can cherry pick redhats fixes rather than having t do the backporting themselves.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    12. Re:What about CentOS? by Da+w00t · · Score: 2

      What's going on here?

      --

      da w00t. mtfnpy?
    13. Re:What about CentOS? by Troy+Roberts · · Score: 1

      Me either

    14. Re:What about CentOS? by makomk · · Score: 1

      Debian does not use Redhat kernels. Two different distributions, packing systems and philosophies.

      They do, however, both use 2.6.32-based kernels. All the non-RedHat distros are cooperating to maintain a handful of kernel releases as long-term support releases and 2.6.32 is one of them. Red Hat's move to hide what patches they've included in their own kernel is hindering this effort and increasing the inevitable divergence between Red Hat 2.6.32 and the official upstream 2.6.32 releases.

    15. Re:What about CentOS? by Jailbrekr · · Score: 1

      Haha, you funny. Not Signal 11 funny, but funny.

      --
      Feed the need: Digitaladdiction.net
    16. Re:What about CentOS? by S.O.B. · · Score: 1

      That's if you only use your modifications internally. If you read past the first paragraph you would see the condition that actually applies here:

      But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.

      Thanks for once again proving that Anonymous Coward often also means Anonymous Short Attention Span.

      --
      Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
    17. Re:What about CentOS? by Kjella · · Score: 1

      I guess you haven't seen the MacBook Air....

      --
      Live today, because you never know what tomorrow brings
    18. Re:What about CentOS? by cloudmaster · · Score: 1

      Isn't it past your bedtime, Grandpa?

    19. Re:What about CentOS? by McKing · · Score: 1

      Mine's smaller, heh heh heh.

      --
      If only "common" sense was actually that common...
  3. Re:Oh no... by Enderandrew · · Score: 4, Informative

    CentOS is fine, because they're a 100% clone of Red Hat. Red Hat is putting their kernel patches together instead of separate. If you wanted to pick and choose which ones you used and make something different, it would be *slightly* more difficult. But considerate the last release was broken out. You know what they were starting with. Take a diff of the new patchset against the old one, and you should have an idea of what they've changed or added.

    --
    http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
  4. Re:Here goes last supporter of open-source by Enderandrew · · Score: 4, Insightful

    Goatse, again.

    Man, you are hilarious. No one in history has ever done that before. And you've created a couple accounts today just for that. When you look back on your life, I'm sure you'll feel content and fulfilled.

    --
    http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
  5. Re:Here goes last supporter of open-source by twilightzero · · Score: 1

    ...is it bad that seeing a goatse makes me wax nostalgic?

    --

    "Christ what a design! I could eat a handful of iron filings and PUKE a better emergency pump than that!"
  6. Re:Here goes last supporter of open-source by mister_playboy · · Score: 2, Informative

    Had you clicked on the link, you would know the GP is a troll who has been posting goatse links on throwaway accounts.

    UID over 2 million + link to blog.com = troll.

    --
    Do what thou wilt shall be the whole of the Law ::: Love is the law, love under will
  7. Re:Here goes last supporter of open-source by twilightzero · · Score: 1

    I rest my case.

    --

    "Christ what a design! I could eat a handful of iron filings and PUKE a better emergency pump than that!"
  8. Well that's ominous by subreality · · Score: 4, Interesting

    TFA doesn't specify what this actually means, so let me speculate. They're not going to go closed-source; they'd be lynched. I think this is a reference to the fact that they're distributing their source prepatched now, to make it harder to just take their patches and apply them to other distros.

    IMO that's kind of sleazy. They got where they are standing on the shoulders of giants. The deal was: here, have this free stuff, build on it, make money with it, but you have to keep giving back. And they got their value out of it, but now they're trying to give back only the minimum they're contractually obligated to do. It's legal and not purely evil, but still moderately scummy.

    I don't really see it being that good for them, either. Oracle isn't going to have much trouble reverse-engineering the patches back out, but RedHat now ends up in a more difficult position: fewer of their patches will be incorporated upstream, so they have to spend more work porting them into each new release; they'll have less community review and bugfixes in their patches; and they're going to alienate the community.

    On the other hand RH users won't end up in the worst scenario: stuck using RH's buggy crap and unable to do anything about it. The source will still be there; they can still dive in to figure out what's wrong and fix it instead of dealing with a black box. I know I had to more than a few times when supporting RHEL systems.

    1. Re:Well that's ominous by h4rr4r · · Score: 5, Informative

      RedHat employs Kernel devs, their patches go directly into upstream. This is for patches that will never make it into upstream for that kernel. Basically all the stuff RedHat backports to the old crusty kernels they use.

    2. Re:Well that's ominous by Trufagus · · Score: 5, Insightful

      As far as I can tell RH does give back. They give back a lot. And it must get kind'of annoying for them that other companies - some of whom give back nothing - copy RH Linux and significantly undermine RH's ability to earn revenue from their distro.

      There are tons of companies out there that violate the GPL, give nothing back, or even actively undermine open source. I would suggest that your disapproval is better directed at them.

    3. Re:Well that's ominous by diegocg · · Score: 2

      fewer of their patches will be incorporated upstream

      Red Hat already submits all their stuff to mainline. They do it themselves, and they do it in advance, before they incorporate it to their product. How they pack their .SRPMs does not affect to how they upstream their code.

      Oracle isn't going to have much trouble reverse-engineering the patches back out,

      I doubt it.

    4. Re:Well that's ominous by kmdrtako · · Score: 5, Informative

      ...fewer of their patches will be incorporated upstream, so they have to spend more work porting them into each new release; they'll have less community review and bugfixes in their patches; and they're going to alienate the community.

      I guess it's not well known, even though it's not a secret. Red Hat pushes their fixes upstream first. After, and only after, they are accepted upstream are they then incorporated into the RHEL kernel.

    5. Re:Well that's ominous by Kjella · · Score: 4, Insightful

      I don't really see it being that good for them, either. Oracle isn't going to have much trouble reverse-engineering the patches back out, but RedHat now ends up in a more difficult position: fewer of their patches will be incorporated upstream, so they have to spend more work porting them into each new release; they'll have less community review and bugfixes in their patches; and they're going to alienate the community.

      I very much doubt Red Hat has any plans to change the way they work on the kernel master branch. This seems to be about their cherrypicking and backporting of patches to RHEL kernels. They want other distros - particularly Oracle it seems - to either do that work themselves or admit they are just rebranding Red Hat's work. For example in that big mega-patch they can simply add a few whitespace changes, if the same changes show up in Unbreakable Linux you know they started with the Red Hat kernel and worked from there. To be honest, I'm somewhat ambivalent about the whole thing. Making it a bit harder to cooperate is bad but making sure credit goes where credit is due is important so that people do the "invisible" work too.

      --
      Live today, because you never know what tomorrow brings
    6. Re:Well that's ominous by kangsterizer · · Score: 1

      can hardly agree more.
      but i also fear that open source success is going toward this kind of crap: make it hard to get the source / changes properly, inserting as many BSD-licensed-and-don't-give-anything-back code etc etc. Not counting all the lets-use-GPL-closed-source-its-unlikely-we-get sued (RedHat of course will never do that, but SO many small companies do)

      Oh well, human nature & stuff.

    7. Re:Well that's ominous by subreality · · Score: 1

      That's a good point. And a lot of their work is in backporting new features into old kernels, to which my criticism is less valid.

    8. Re:Well that's ominous by Daniel+Phillips · · Score: 1

      it must get kind'of annoying for them that other companies - some of whom give back nothing - copy RH Linux and significantly undermine RH's ability to earn revenue from their distro.

      But never forget that the vast majority of what Red Hat packages was created for free by others. Yes, Red Hat pays the most open source developers of any company with the possible exception of IBM, but that still amounts to just a small fraction of what they bundle up and sell as theirs.

      To be clear, I have absolutely no problem with Red Hat bundling up tons of free software and selling support for it. I do have a problem with Red Hat whining and playing sneaky tricks with source distribution, just because somebody else turned around and did the same thing. Red Hat sells support, not software, they would do well to remember that.

      --
      Have you got your LWN subscription yet?
    9. Re:Well that's ominous by falconwolf · · Score: 1

      TFA doesn't specify what this actually means, so let me speculate. They're not going to go closed-source; they'd be lynched. I think this is a reference to the fact that they're distributing their source prepatched now, to make it harder to just take their patches and apply them to other distros.

      One problem I see with this is that current installations of RHEL have to be patched too. Businesses relying on RHEL who can't get patches will possibly switch. If Red Hat wants to grow more it can't treat it's customers like MS does, like shit.

      Falcon

    10. Re:Well that's ominous by Anonymous Coward · · Score: 1

      > copy RH Linux and significantly undermine RH's ability to earn revenue from their distro.

      In case you had missed the headline, RH are earning nearly a billion dollars in revenue. Why do they need to earn more than that?

      Why would ANY company need to earn more than a billion dollars in revenue? There is no rational reason to want to grow any bigger.

    11. Re:Well that's ominous by subreality · · Score: 1

      RHEL customers don't need the individual patches. They just download and install the updated RPMs from RedHat.

      Or do I misunderstand what you're saying?

    12. Re:Well that's ominous by rtfa-troll · · Score: 1

      Red Hat sells support, not software, they would do well to remember that.

      Both; to be honest; their Release CD images are still valuable. The fact that they limit access to the open access to the support forums is a complete pain even when we are fully paid up because most of our internal users aren't registered with RedHat and so we will never give direct access to all the people who might need it.

      I'm not yet at all sure that this RedHat thing is a big problem; if it really is, then the correct solution is a license change at the kernel level. If RedHat can do this, then so can anyone else. That means that the Linux kernel people have to initiate, support and get involved in a GPLv4 update, using their "diplomatic skills" to persuade the FSF they are a partner worth working with. They have to concentrate on getting most known kernel developers to agree to a future license update and eliminating those that don't.

      In the meantime, the key thing is to make sure that upstream of RedHat, more of these patches get merged in more effectively. This will have the benefit for RedHat of taking work off RedHat; will put more work into a better condition, will make the upstream old kernels more valuable and will provide wider hardware support for all Linux based on old kernels.. Oracle could put a bunch of kernel developers and testers on the case. If nobody is willing to do this, then, to be honest, RedHat is doing the right thing

      In the meantime; even if you are a RedHat customer, concentrate on putting answers you find to problems onto Linux Questions Wiki or forums where they will be available under the CC-SA for everyone.

      --
      =~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
    13. Re:Well that's ominous by aztracker1 · · Score: 1

      What are you talking about... redhat customers will get patches... it's just the source for back-ported patches will e a little harder for Oracle to rip & apply

      --
      Michael J. Ryan - tracker1.info
    14. Re:Well that's ominous by drinkypoo · · Score: 1

      You call "not releasing their change set as a patch" sneaky? Because I don't. If Oracle wants to do the work of a distribution for real then they can do that. Otherwise they can stop putting their name on shit. If they were smart they'd get someone to create and release a branded Linux for them. They're not smart, they're just powerful. Who goes Oracle on purpose?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    15. Re:Well that's ominous by Desler · · Score: 1

      and significantly undermine RH's ability to earn revenue from their distro.

      Boohoo? If they don't want people to be able to do so they shouldn't gave built their business on GPL code. Secondly, why SHOULDN'T their customers be able to switch to Novel or Oracle for support if they want to? They supposedly claimed to believe in that according to their supposed values:

      when customers are unhappy with one vendor, they can choose another

      Well that seems to be unless those customers choose not to get support from Red Hat anymore because then Red Hat will do whatever it takes to lock you into their support. Oh and don't dare exercise your GPL rights because then that means you lose your support contract. What fucking hypocrites.

    16. Re:Well that's ominous by falconwolf · · Score: 1

      RHEL customers don't need the individual patches. They just download and install the updated RPMs from RedHat.

      And what's to stop other from doing the same if they have Redhat under another name? If Oracle repackages RHEL who's to stop Oracle customers from installing updated RPMs too?

      That is what I meant.

      Falcon

  9. CentOS followers: Just switch to Debian by Anonymous Coward · · Score: 1, Funny

    Yep you heard it right. CentOS followers: Just switch to Debian!

  10. Diff? by 3vi1 · · Score: 1

    Someone educate me: Why are people incapable of running the diff command between Red Hat and the pure kernel sources in order to get just the patches?

    1. Re:Diff? by sirlatrom · · Score: 2

      Well, that would give you one very large diff and not several specific ones that you could pick and choose between.

    2. Re:Diff? by TheUni · · Score: 2

      "just the patches" would be nice. But a diff doesn't give you that. It gives you a monolithic patch with no history or context.

    3. Re:Diff? by Anonymous Coward · · Score: 1

      Uhmmm, and doing a quick shell script or even command line to peal this off on individual files and patches? Stick a GUI on things and people get lazy!

    4. Re:Diff? by kmdrtako · · Score: 1

      As Carl Sagan used to say: "You have to do the experiment."

      You could diff the two source trees yourself to answer this question.

      After you've done it, I think you'll better understand why it's not particularly useful.

    5. Re:Diff? by Chris+Burke · · Score: 4, Insightful

      That only gives you the patch broken up in space, not in time.

      The idea is that Red Hat has patches for specific issues that are developed at different points in time. These patches may modify the same files as previous ones, or even the same blocks of code. By having all patches applied at once, the singular diff does not tell you which component of the patch fixed which issue.

      This is really only relevant for providing commercial support. Previously, by having patches associated with known issues applied sequentially, it was much easier for another company to say "Oh you're having Issue X? Well Patch Y will fix it." Now their options are to reverse-engineer the monolithic .diff to find the part that fixes a specific issue, or tell their customers they have to apply the entire patch. Again, that's not something you'd care about if you're a desktop end-user, but in a corporate IT environment it makes a difference.

      --

      The enemies of Democracy are
    6. Re:Diff? by VortexCortex · · Score: 2

      I somewhat agree. RHEL's pre-patched kernel doesn't affect upstream. If you want upstream patches broken up by time, checkout the kernel from its git repository & browse away... Hint: The commit messages describe what each group of changes addresses.

      Of course, I still think its a shitty thing to do. What if Red Hat's upstream (Linux) made it harder for RHEL devs to support their custom selected kernel code... If it Red Hat suddenly couldn't pick and choose which Linux mainline patches to apply to their long-term-support releases because the commit logs were obliterated via rebase, I'm sure everyone would be singing a different toon -- You put the shoe on the other foot and suddenly it's bizzaro land?

      It's not like RHEL writes the whole damn distro itself. The least they could do is make it as easy for downstream devs as their upstream makes it for them. To do otherwise, while not illegal, is a major dickhead move which I'll no longer be supporting with my hard earned dollars (or recommending others do either).

      Again, that's not something you'd care about if you're a desktop end-user, but in a corporate IT environment it makes a difference.

      Way to go RHEL team... Keep pissing people off for the sake of the almighty dollar -- It may come back to bite you in the ass someday...

      That only gives you the patch broken up in space, not in time.

      The idea is that Red Hat has patches for specific issues that are developed at different points in time. These patches may modify the same files as previous ones, or even the same blocks of code. By having all patches applied at once, the singular diff does not tell you which component of the patch fixed which issue.

      This is really only relevant for providing commercial support.

      ... P.S. I work in the corporate IT environment. We do a lot of our own internal maintenance. We don't upgrade very often, and when we do so the sheer amount of adjustments to changes and testing that must be performed dwarfs the decision of which distro gets chosen as the upgrade target -- Guess which distro (and support contract) won't be on the list come next upgrade? You guessed it: The distro that's actively making it harder for us (downstream) to maintain it ourselves -- RHEL.

    7. Re:Diff? by Burdell · · Score: 3, Interesting

      The only "downstream" of RHEL that is significantly affected is Oracle, a company that rebuilds RHEL, sells it as their own "Unbreakable Linux", and then tells database customers that they really shouldn't run RHEL, they should run Unbreakable instead. A bunch of those customers run Oracle DB on RHEL from when Oracle was a Red Hat partner (before they started trying to poach the big DB customers). Oracle does much less for Linux (and Open Source in general) than Red Hat. Oracle throws a little bit of code over the wall when they have to, while Red Hat has bought other companies closed-source software and Open Sourced it.

      I haven't looked yet (because I rarely need to see individual patches; I mostly just care about the end result), but Red Hat has said that customers will have access to the patch information, so cutting Red Hat out because they restrict that would be dumb (since as a customer you'd get it anyway). A lot of work in making the Linux kernel "enterprise-ready" has been (and continues to be) done by Red Hat.

      Basically, Red Hat forks the kernel for each major RHEL release and then maintains it on their own. They backport patches from upstream as well as develop patches for their kernel (which they submit upstream). Do you think LibreOffice should be required to distribute every individual patch they've made to OpenOffice, or X.org vs. XFree86?

    8. Re:Diff? by Xtifr · · Score: 3, Interesting

      Red Hat has said that customers will have access to the patch information

      So what's to stop Oracle from becoming a customer? :)

    9. Re:Diff? by Ancantus · · Score: 1

      Larry Ellison's giant ego.

      --
      Violence is the last refuge of the incompetent. -- Isaac Asimov
  11. Do not panic by stikves · · Score: 5, Insightful

    I believe they have no beef against CentOS, actually I've seen at least one Red Hat employee encouraging the use of CentOS, since Red Had is the "de facto upgrade path" (not the exact words, but something along this way). So you freely enlarge the customer base, which will go to Red Hat when they need higher level commercial support. And for the free ones, even Microsoft has recognized they cannot sell to students, and are giving away the software anyways.

    However Oracle is another deal. They just slap Oracle logo on Red Hat, do not acknowledge the source, and sell is as "unbreakable Linux". This would make a regular person ashamed of himself. They benefit a lot from open source but not giving back much in return. Do not start me with what they're doing to Solaris, Java, and OpenOffice...

    So I'm with Red Hat on this one, at least until they do something directly bad to CentOS.

    1. Re:Do not panic by Anonymous Coward · · Score: 1

      Which I can't see them doing. CentOS is huge for RedHat; it trains admins in their own linux and it gets companies hooked on their brand of linux.

      No, I can't seriously see them jepardizing CentOS. Were this Oracle, then yes. They appear more than willing to sacrifice customers for the almighty ego. But RH has consistently made sound decisions.

    2. Re:Do not panic by nzac · · Score: 1

      I would think that CentOS users would chose is primarily because its free and stable rather than its RH and has the added advantage of being free. I would imagine that if CentOS was killed off that instead of using RH they might switch to (guessing) openSUSE with stable options, sending them to Novel. For minimal investment CentOS is free trail for RH, not being a monopoly this is an added advantage against competitors.

    3. Re:Do not panic by David+Gerard · · Score: 1

      In practice, we're about to switch from Solaris 10 on SPARC to Ubuntu Server in x86 VMs. Coulda been RHEL 5, wasn't. (We had no need of commercial support and the hosting company had Ubuntu as a standard offering. I have my qualms, but it should be possible to beat into robustness.)

      CentOS is Red Hat for almost all practical purposes except if you're running proprietary software that lists RHEL as supported.

      In my experience, Red Hat's actual tech support is shit. OTOH, buying a licence does help pay for all their work.

      --
      http://rocknerd.co.uk
    4. Re:Do not panic by nzac · · Score: 1

      Not that i have much enterprise knowledge im curious as to why you chose Ubuntu (LTS?) for a server was as good as any other distro and you want to run Ubuntu VM off it or was the server actually considered better than other alternatives.

      I would have thought that Cent or SUSE would make better severs. I guess the Ubuntu server disk does come ready made.

    5. Re:Do not panic by Jon+Stone · · Score: 1

      They just slap Oracle logo on Red Hat, do not acknowledge the source and sell is as "unbreakable Linux"

      I think you'll find Oracle have to do it that way thanks to Redhat's trademark licensing. Oracle have to completely rebrand RHEL, and have to be very careful when referencing Redhat in any way.

      Have you never noticed how CentOS never states it's derived from RHEL, only from source from a "prominent North American Enterprise Linux vendor"? Redhat's trademark licensing...

    6. Re:Do not panic by GrBear · · Score: 1

      I believe they have no beef against CentOS, actually I've seen at least one Red Hat employee encouraging the use of CentOS, since Red Had is the "de facto upgrade path"

      Actually I just migrated our servers from RHEL to CentOS being as RH jacked up the prices for support by a fair amount. My $350/yr per server included limited support AND updates, and now it's only updates.

      RH can pound sand, I still get the same benefits of a "RHEL distro" w/o the $350/yr charge.

    7. Re:Do not panic by David+Gerard · · Score: 1

      Personal preference: because it's close enough to Debian, pretty much ;-) Most of what we'll be using it for is to run Java (and Sun^WOracle Java at that, not even the distro OpenJDK). So we can do that and treat it as an almost-sane operating system.

      --
      http://rocknerd.co.uk
  12. Re:Clones around, it's "enhanced clones" with trou by ustolemyname · · Score: 2, Informative

    I'm confused. How on earth do you think Novell is cloning RHEL? They are a significant contributer to linux, 3rd from the top, and non-trivial user ecosystem (they supplied the devs who got alot of the new AMD graphics stuff going, as I recall.) Big contributers to KDE and libre office. If they contribute less then redhat, that would only be because they have less staff (I think... at least the suse part of them does, for sure).

    Suse is as different from RHEL as debian is. Yes, they both use rpms. That's about it.

  13. Re:First google, now redhat, then... by h4rr4r · · Score: 2

    GOATSE LINK.

    By the way kiddo, find something new to shock us with. Slashdotters are pretty much immune to that one.

  14. Re:First google, now redhat, then... by kvvbassboy · · Score: 1

    !!!!!!!!!!!!Dont click that link!!!! It shows the anus of a guy or something. Mod it down!!!

  15. Re:First google, now redhat, then... by Sparx139 · · Score: 2

    Links to goatse, don't click

    --
    Our culture doesn't get smarter, it just finds new ways of being retarded.
  16. Re:First google, now redhat, then... by Chris+Burke · · Score: 2

    Okay, wait, goatse link threads are not something I would normally post in, but I have to ask.

    By "or something" do you mean that you didn't look at it long enough to really be sure what it was (and I pray for your sake that this is the case), or are you just giving voice to that little, terrified piece in the back of your brain that insists that cannot be human?

    --

    The enemies of Democracy are
  17. Re:LOL, people still use Linux? by JonJ · · Score: 4, Funny

    Why don't you last 3 linux users just swallow your pride and buy a mac like everyone else with more than 2 brain cells has done in the last few years?

    I know you're just a troll but I can't resist. First of all, Linux and RHEL in particular, runs on actual servers. You know, those computers Apple slowly are phasing out? Xserve is gone, and Mac Pro server is soon to follow. And, Linux pisses on Mac OS X when it comes to market share on servers. Lastly, it's Mac users that are used to swallow other guys 'pride', so just stick to what you're best at: Sucking cock.

    --
    -- Linux user #369862
  18. Scientific Linux 6 by KainX · · Score: 5, Informative

    Scientific Linux 6 is already out. See http://ftp1.scientificlinux.org/linux/scientific/6.0/x86_64/os/sl-release-notes-6.0.html for their detailed release notes. If there was any doubt in your mind that the direct rebuild projects are unaffected by this move, there shouldn't be any longer.

    It's pretty clear they're trying very hard this time around to stay in lock-step with upstream (what they call TUV and what CentOS calls PNAELV) and add fewer packages into the mix directly. They're also funded to do this work full-time by the US government, and since many universities and national labs rely on SL, it's not going away any time soon.

    If you've never tried it before, I encourage you to do so. To quote the old tagline, it's already ready already.

    --
    Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    1. Re:Scientific Linux 6 by CFD339 · · Score: 1

      Thanks for that. I've been using CENTOS and been quite happy with it. For what I do, I don't need to be (and will never really be) up to the minute with versions anyway -aside from keeping up with security patches to the extent I can. Are there good reasons, other than speed of the release cycle, to move from CENTOS to SL?

      --
      The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
    2. Re:Scientific Linux 6 by jonescb · · Score: 1

      The developers of CentOS are pricks.

      I wrote a bit about a recent experience on my blog. http://casey-jones.org/blog/19/
      Basically, the CentOS developers believe "CentOS is for the community, not by the community". And they really don't want you know how they put their distro together.

    3. Re:Scientific Linux 6 by KainX · · Score: 1

      I have a number of them, but those are my reasons, and they're driven by my experiences and my needs as a user (and, as a sysadmin, the needs of my customers and colleagues). You have to draw your own conclusions.

      My advice would be to do your homework. Look at what others are saying about the various options you have: about the projects, about the people behind them...about quality and community and all those things that matter.

      Then go with whatever project fits your needs and makes you proud to be part of it. It really is that simple.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
  19. Scummy is taking without giving back by msobkow · · Score: 4, Insightful

    If you want scummy, look to companies like Oracle which just take, repackage, and rarely give back. They're the real problem, not RedHat.

    RedHat's patches still get submitted upstream for inclusion in the main kernel, which very often does happen.

    I have no sympathy whatsoever for leeches that were taking RedHat patches and rolling their own distributions without contributing enough back on their own.

    I fail to see how this affects seperate distros like Debian, which aren't based on RedHat-patched source in the first place.

    --
    I do not fail; I succeed at finding out what does not work.
    1. Re:Scummy is taking without giving back by subreality · · Score: 1

      I actually don't have a problem with that. RedHat does not have an exclusive right as a distributor. My personal belief is that if the world gets better use of the software by distributing it more in this manner, that net good is being done.

      The GPL ethos is you sell support, not software. The playing field is supposed to be level for the software, and you make a name by being the best at support. What RH is doing here is pushing for the software itself to be the feature they're selling, and that's going to rub a lot of people the wrong way - it wasn't the deal intended when they GPLed their code.

    2. Re:Scummy is taking without giving back by Desler · · Score: 1

      If you want scummy, look to companies like Oracle which just take, repackage, and rarely give back.

      But isn't the whole point of the GPL so anyone CAN take what you've released and repackage it as long as you release your changes to that product? Why is this somehow "scummy" just because Oracle does it? Because they dare to compete with Red Hat? If Red Hat doesn't want to have to compete with others they shouldn't have released their code as GPL or built their business on GPL.

    3. Re:Scummy is taking without giving back by Desler · · Score: 1

      Oh and let's not even get into the fact that Red Hat will cancel your support contract if you dare to exercise your GPL rights:

      Distributing the Software or any portion of the Subscription Services to a third party or using any of the Subscription Services for the benefit of a third party is a material breach of the Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages.

      How is THAT not scummy? They tout all the "freedoms" of open source and the GPL on their website and then lock you in from being able to actually use those freedoms by saying that if you do it's a breach of your support agreement. What fucking bullshit.

    4. Re:Scummy is taking without giving back by mikechant · · Score: 1

      Redhat is fully compliant with the GPL before and after this change and is still releasing its changes, just in a format that is less convenient to Oracle. What you seem to be implying is that they should be happily doing extra things *beyond* what the GPL requires, effectively just to make their competitors more profitable, which is a bit bizarre.
      However, there was nothing 'scummy' about what Oracle was doing, they were fully entitled to do what they do and are also compliant with the GPL. They will just have to do a bit more work themselves now.

    5. Re:Scummy is taking without giving back by Daniel+Phillips · · Score: 1

      If you want scummy, look to companies like Oracle which just take, repackage, and rarely give back. They're the real problem, not RedHat.

      Oracle may be scummy, but that is not the reason. Oracle actually backs a pretty impressive range of open source project, among them Btrfs and OCFS2.

      And as everybody knows, a goodly number of the more significant projects have already fled Mordor, err, Oracle in the interest of freedom. However, you can't accuse Oracle of not giving back to open source, Larry gets that part. Other parts of the community contract he fails to get at all, big time.

      --
      Have you got your LWN subscription yet?
    6. Re:Scummy is taking without giving back by Registered+Coward+v2 · · Score: 1

      I have no sympathy whatsoever for leeches that were taking RedHat patches and rolling their own distributions without contributing enough back on their own.

      I disagree with your application of the term leech here. There is no obligation to give back unless you modify the code. You may not like that business model but that does not make it wrong. The key is for people to support those who give back by buying their support offerings. One of the arguments we hear is "companies can make money off of support so" so giving their code away is not an issue. It appears there is a limit to that model when a big enough competitor decides to offer support without expending developer resources. So to me the issue is "how scalable is the OSS support model?" It may be self limiting because once the market is big enough the lower barriers to entry can attract significant competitors.

      --
      I'm a consultant - I convert gibberish into cash-flow.
  20. Red Hat Did 12.8% of the 2.6.20 Kernel by seifried · · Score: 4, Informative

    http://lwn.net/Articles/222773/. Red Hat plays very well with others. Part of the problem is the logistics, with Git and new Kernel development you're looking at literally thousands of source code patches (which would make for a completely unwieldy SPEC file) because Red Hat back ports stuff to keep a stable Kernel in the Enterprise Linux..

  21. well done! by mrphoton · · Score: 1

    putting the centos stuff aside. Redhat are doing a great job and contributing great code to the open source community. They uphold open source ideals by keeping fedora free of closed source code. I have been using Redhat/Fedora for years through my undergraduate degree, PhD and now in my job want to say what a great big thanks to you guys and wish you the best for the future!

    1. Re:well done! by Antique+Geekmeister · · Score: 1

      And RedHat _directly_ pushes their upgrades back to the linux kernel and numerous other projects. The original poster has _no_ idea what they're talking about. This is not a change to general RHEL packaging, it's only a few abused packages, such as the kernel, which Oracle modifies heavily in their repackaging for this "Unbreakable Linux", which frankly isn't "Unbreakable", it's merely tuned for Oracle, which is typically very fragile.

  22. Re:Clones around, it's "enhanced clones" with trou by Anonymous Coward · · Score: 4, Interesting

    Take a look at Novell's "RHEL support" offering. It's turned out to be complete crap, repackaging RHEL packages and alleging to offer one-stop support for SuSE customers, and blaming any problems on RHEL to convince customers to switch to SuSE.

    http://www.novell.com/promo/suse/free-30days-expanded-support.html

    It's complete bait and switch.

  23. Re:Clones around, it's "enhanced clones" with trou by larry+bagina · · Score: 3, Informative

    oracle is funding btrfs development.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  24. Re:Clones around, it's "enhanced clones" with trou by somenickname · · Score: 4, Interesting

    I'm really surprised that this comment was modded up. Oracle is responsible for btrfs (negating the "filesystems" argument), Novell was the catalyst for the modern linux composited desktop with compiz/Xgl (negating the X argument), and if I thought about it for more than 10 seconds, I'm sure I could come up with a shitload of other examples where these two companies that you've "cherrypicked" have been a driving force for good in the linux world. I do agree with your sentiment but, you sound bitter for these companies not having contributed to technologies that you don't realise you are using. But, most likely, the have. And in a big way. I'm all for hating companies like Oracle but, hate them for the right reasons.

  25. Not good for the future of Linux by 2Bits · · Score: 3, Insightful

    If every distro is doing the same thing, this is not going to be very good for the future of Linux. Engineers at every distro are going to waste a lot time trying to figure what other distros had been patching, which part of the code had been changed while a specific issue was fixed, etc. Everyone is going to end up wasting a lot of time, and creating a lot of confusion.

    Even though Linux distros are quite fragmented, but the current kernel development has been working quite well, because every distro is playing by the rule (more or less), which is quite transparent. Now, with this kind of one time big change by RH, even though you can still diff on all the source codes, it's not going to be easy to figure what has bee done (and why). And I think it's going to trigger other distros to behave similarly.

    And it will be even harder for the users. As a user, if we have in-house-built applications that rely on specific version of a library or module, we might not want to have a giant patch on basically everything, we probably want only small, concise, specific patch for some critical security problems. I'm starting to wonder how are we going to manage that.

    1. Re:Not good for the future of Linux by Anonymous Coward · · Score: 2, Informative

      It wont be a problem because all the patches/fixes end up in git form upstream first, before they even hit a shipping RHEL kernel. Because of this, there is no confusion. I don't think you even use Red Hat Enterprise Linux as a product as you can't pick and choose patches and still remain in support for that modified package. You may as well just build upstream and port back those security fixes you need, which you can do because the fixes are pushed there first.

      If this is the case, and I'm just imagining out loud, you don't use a Red Hat product or understand what they offer.

    2. Re:Not good for the future of Linux by Anonymous Coward · · Score: 1

      I intend to manage the problem you describe using the "switch to Debian" strategy. The set of patches RedHat applies to the stock kernel is pretty large. Losing the ability to use bisection to narrow down the individual patch that breaks something--or cherry-pick a patch known to provide a useful fix--is a serious step backwards in trouble resolution, for companies that want the ability to fix problems themselves. I'm really sick of companies executing a strategy intended to hurt their competitors in a way that makes life more difficult for their paying customers.

    3. Re:Not good for the future of Linux by int69h · · Score: 2

      If you're "companies that want the ability to fix problems themselves", then why are you using RHEL to begin with? Certification and support only apply to binaries provided by Redhat.

    4. Re:Not good for the future of Linux by buchanmilne · · Score: 2

      If every distro is doing the same thing, this is not going to be very good for the future of Linux.

      If every distro were doing as much (proportionally) upstream work as Red hat, it would be very good for the future of Linux.

      Engineers at every distro are going to waste a lot time trying to figure what other distros had been patching, which part of the code had been changed while a specific issue was fixed, etc.

      But, they shouldn't be. They should be tracking *upstream*, putting their effort into *upstream*, instead of following other forks of the kernel.

      Even though Linux distros are quite fragmented, but the current kernel development has been working quite well, because every distro is playing by the rule (more or less), which is quite transparent.

      But, this has nothing to do with upstream kernel development, to which Red Hat is still contributing directly. This only has to do with development of Red Hat's Linux-based kernel (which is actually a fork).

    5. Re:Not good for the future of Linux by matt007 · · Score: 1

      BTW real distro are going the opposite way : http://www.debian.org/News/2011/20110318

    6. Re:Not good for the future of Linux by makomk · · Score: 1

      It wont be a problem because all the patches/fixes end up in git form upstream first, before they even hit a shipping RHEL kernel.

      Except that no distro uses the raw, bleeding-edge upstream git version of the kernel that RHEL's sending their patches to. They all use an older release with backported patches. If every distro was to maintain their own version of the kernel and keep it a secret which backported patches they were including like Red Hat is doing, there'd be a huge duplication of effort as everyone had to figure out for themselves which patches needed backporting in order to fix specific bugs. What's more, users would encounter far more bugs because there'd inevitably be some issue that affected them that had only been spotted by other distros and not their own.

    7. Re:Not good for the future of Linux by McKing · · Score: 1

      For the (hopefully) last time, THEY ARE NOT KEEPING ANYTHING SECRET. They are just providing the backports and bug fixes to their kernel as one big patched tarball instead of as a vanilla kernel with a series of possibly dozens of small patches that have to be applied in a certain order. That's it! Nothing will change for anyone except Oracle. Redhat is still within their rights to do this, Oracle is still within their rights to piggyback their "Unbreakable Linux" off of Redhat, they just have to work a tiny bit harder on it if they want to back out any of the changes that Redhat made to the kernel.

      --
      If only "common" sense was actually that common...
    8. Re:Not good for the future of Linux by m50d · · Score: 1

      But, they shouldn't be. They should be tracking *upstream*, putting their effort into *upstream*, instead of following other forks of the kernel.

      That'd be fine if upstream provided a reliable, stable kernel. But it doesn't, and hasn't for some time now; Linus has explicitly said if you want that you should go for one of the big distro's kernels. So I wouldn't blame e.g. slackware (a one-man distro) for following the red hat kernel rather than the kernel.org one - if you need a stable, tested kernel, the kernel.org one doesn't cut it, unless you have the resources to test it yourself.

      --
      I am trolling
  26. Speaking of RHEL clone... by Browzer · · Score: 1

    just found out a new RHEL clone (thanks to distrowatch.com News 03.21.2011) - PUIAS http://puias.math.ias.edu/ is an RHEL clone "... started long before CentOS or other projects were available."

    The question is: if CentOS fizzles for whatever reasons, how many will switch to one of the less than 5, one-man-show RHEL clone, how many will dig in and pay for RHEL, and how many will switch to non-RHEL?

    1. Re:Speaking of RHEL clone... by danbuter · · Score: 1

      Why don't you just say that the CentOs devs (and many, many other Linux devs) are whiny primadonnas and get it over with? At least then you'd be telling the truth.

    2. Re:Speaking of RHEL clone... by KainX · · Score: 1

      Actually, they are mistaken. CentOS came out of the cAos Foundation and was started immediately after the announcement of the cessation of Red Hat Linux. Furthermore, cAos and CentOS have origins in the Vermillion project, which was a rebuild of RHL 7 (before RHEL even existed), and which in turn can trace its own lineage back to "Red Hat Linux with VA Linux Enhancements," or RH-VALE, a rebuild and customization of RHL begun in the late 90's at VA Research/VA Linux.

      So they got their history a bit wrong. :-)

      Reading their web page, if they build RPMs the way they tell everyone else to build them (in their documentation and presentations), I'd be wary of using their packages. Proper distribution building and packaging involves controlled, reproducible, well-defined builds inside jails or other similar constructs, not "Joe User building in his ad-hoc home directory build tree." Just my opinion, of course. :-)

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
  27. Re:BUT INFORMATION WANTS TO BE FREEEEE. by 0racle · · Score: 1

    Proved? One person suggested it, no one else verified. RH also still distributes all of their source.

    --
    "I use a Mac because I'm just better than you are."
  28. Re:BUT INFORMATION WANTS TO BE FREEEEE. by Anonymous Coward · · Score: 1

    It was just a month ago that FBI proved they had 10-years worth of Backdoors in Theo De Raadt's BSD operating system without his knowledge.

    Actually, an audit was done, and the opposite was proven - that there are no secret backdoors. I hope that doesn't strain your reality too much. OpenBSD is still the supreme overlord of security, even from the over-zealous security crowd.

  29. Red Hat certification classes cost a small fortune by sparkeyjames · · Score: 1

    I'm sure most of their revenue is from support contracts but...
    I wonder how much of their revenue is from their rather sky high pricing of
    classes to get a cert. To a small business or an individual their prices
    seem a bit out of line for actual value received. They sure do seem to
    have some really nice and costly mailers for those classes too. Last one
    I got was 42 pages. Their class track structure seems to have more
    tiers than a Chinese rice paddy.

    To get decent grounding in RHEL to get a cert or two for it you could spend upwards
    of 5 grand and that's without the cost of travel/hotel.

    If you went full bore and took all the classes and exams one after the other your
    costs would top 20 grand easily. Each class is only 5 days (with cert testing).

    Seems a might steep don't ya think?

  30. RH is neither all good nor all bad - examples by Anonymous Coward · · Score: 1

    Yes, RH currently contributes quite a bit. This is good.

    But, RH has a history of really stupid stuff:

    Shipping gcc cvs head as the next stable version, so they could be, "first to market". This broke things for their users (couldn't compile a kernel for example [hmmm QA much RH?]. Worse, their users misdirected their anger at the gcc devs. Finally gcc just skipped this release version so there would be no more confusion.

    Refusing to incorporate patches for RieserFS that Hans Rieser, himself tried to get them to accept. The issue was just that their customers were risking _losing all their data_!

    Modifying KDE to get it to fit better with their distro, and breaking it [again, where is the QA?]. RH users again misdirected their anger at the KDE team, who stepped up, and fixed RH's mess.

    RH years ago, bought some X servers for hardware that wasn't supported in xfree86. They, initially, kept it closed, as a value add for their distribution, rather than contributing it back. Yup, they are a for profit, but, at the time, RH didn't really contribute much back.

    RH also seems to live by the motto not invented here. Great stuff from other distros (mainly Debian), they refuse to incorporate, and usually end up with something moderately to very inferior for more effort.

      RH requires a ridiculous support contract for access to patches.

    Finally, RH has only 4.8% of the packages Debian has, in a comparison of official stable repositories-- This was RH vs Debian Etch, so comparable vintage. I don't have anything newer RH around to repeat the test with, doubt it is much different, though.

    up2date --show-available | wc -l
    1125

    apt-cache search '.*' | wc -l
    23310

      echo 1125/23310 | bc -l .04826254826254826254

    So, RH is only 4.8% the distribution that Debian is

    1. Re:RH is neither all good nor all bad - examples by rtfa-troll · · Score: 1

      a couple of small nits.

      RH requires a ridiculous support contract for access to patches.

      Patches (as in source) are available for free; That's what CentOS bases off. It's the updates (as in binaries) which you pay for. If RedHat ceases to do this then I, and many like me, will start releasing them myself.

      Finally, RH has only 4.8% of the packages Debian has, in a comparison of official stable repositories

      Your comparison really isn't fair for several reasons. You are comparing only the core repositories of RH which are at a higher quality level than Debian's default repository precisely because they are more filtered. Try doing the same comparison with EPEL and/or RPMForge (which is where "community" packages are) included and you will see a more even story.

      --
      =~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
    2. Re:RH is neither all good nor all bad - examples by Compaqt · · Score: 1

      How many packages does EPEL have? I was unable to get a number.

      Debian seems to have between 20 and 30k.

      Many EPEL/Rpmforge packages I've found need to use have been low quality: E.g,. by installing collectd, a server monitoring package, I also had to install X plus a desktop environment (nutty on a server).

      --
      I'm not a lawyer, but I play one on the Internet. Blog
  31. Re:Here goes last supporter of open-source by danbuter · · Score: 1

    Fuck. I did click. Now I know. I hope the bastard rots in hell.

  32. Business as Predicted by mwasham · · Score: 1

    They took other people's "altruistic" work. Used it as the basis for their billion dollar business and cut off the "free" part of free software. But I'm sure the people that donated lots of man hours for free feel better because RedHat's owners are loaded.

  33. Re:CentOS by angus77 · · Score: 1

    The CentOS people themselves have stated that it won't affect them at all.

  34. Re:Here goes last supporter of open-source by Sulphur · · Score: 1

    Power corrupts, and absolute power corrupts absolutely. Even in open source.

    Power corrupts, and absolute power is kind of interesting. John Lehman

  35. What? by CheerfulMacFanboy · · Score: 2

    No jokes about "Begun, the Clone War has"? I'm so disappointed.

    --
    Fandroids hate facts.
    1. Re:What? by Celarent+Darii · · Score: 1

      Actually that movie was a disappointment.

  36. Re:Clones around, it's "enhanced clones" with trou by CAIMLAS · · Score: 2

    The one that interests me the most (because it impacts me most directly) is XenServer. It's supposedly based on RedHat as well, and they do a degree of kernel hackery to get all their Xenery to work. I'd be curious to see where that will go, given that XenServer development isn't exactly what you'd call cutting-edge in many regards: Citrix seems to just cut and release, with little regard for many important things like documentation being up to date or full hardware support.

    --
    ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
  37. Re:Clones around, it's "enhanced clones" with trou by QuantumRiff · · Score: 2

    I installed Oracle Linux 6 this week to test. Besides the blinding red color of everything, I was a bit annoyed to see how many times I saw the word "RedHat" in the installer and the boot process.. I mean, if your going to rebrand it, then freaking re-brand it!

    --

    What are we going to do tonight Brain?
  38. This is hurting Debian too by GPLHost-Thomas · · Score: 1

    Maximilian Attems, one of the 5 persons maintaining the Linux kernel in Debian, already stated that he believes it is a bad move, that will make his life more complicated. We are talking here about one of the most open and free distribution in this world, with no company to backup the operation. RedHat can go to hell with there billion USD, they now deserve the disrespect of all the community for their greediness.

  39. Who cares? by ALeader71 · · Score: 1

    I went Debian, then Ubuntu years ago and I've never been happier.

    --
    Only the dead have seen the end of War. - Plato
  40. Re:BUT INFORMATION WANTS TO BE FREEEEE. by Narcocide · · Score: 1

    I seem to recall seeing a statement by Theo himself who basically said that it was true that said government contractor had been hired and paid to write some stuff for OpenBSD some years ago but the code they handed over was never actually used because it was of such poor quality. Nobody even noticed it was loaded up with backdoors on its way to the trash can.

  41. Nonsense by msobkow · · Score: 1

    Red Hat submits their patches upstream for inclusion in the main Linux kernel.

    According to earlier posts, they even submit them upstream before they include them in the RHEL kernel.

    Those upstream submissions are not monolithic/merged, so distros which build from the Linux source instead of a distro's source should not have a problem. That includes Debian.

    --
    I do not fail; I succeed at finding out what does not work.
    1. Re:Nonsense by GPLHost-Thomas · · Score: 1

      The issue isn't that they don't send back to the kernel for upstreaming (in fact, you are right, they do...). The issue is that, in Debian, we keep patches of the stable kernel as separate files. This includes: bug fixing, new drivers, etc. These are *not* included in the kernel version that the Stable Debian has picked-up. Having patches as separate files in RedHat makes it easy to port them to the Debian kernel, without having to look around in the kernel Git, where there's multiple thousands of entries to look for, with possible fixes that may come later on. Also, some (hardware) vendors send patches to the RedHat kernel with older versions (like, the 2.6.18 kernel, which is still in use in many servers), so they can add them to their specific kernels, and these patches are sometimes very different from the newer kernel release. See how much the WiFi stack changed between 2.6.26 and 2.6.27 for example, and you will understand what I mean (and Debian Lenny is still using 2.6.26, and would need some patches for supporting some WiFi cards like iwlagn for example...).

      In sort: yes, patches are upstream. No, this doesn't change the fact that what RedHat is doing is very annoying for others.

    2. Re:Nonsense by gmack · · Score: 1

      One of the major reasons the Linux Kernel people moved to shorter releases is so that distros would stop back porting features. Debian should either be basing it's distro on a long term supported kernel (bug fixes but no new features) or periodically updating to something known stable.

    3. Re:Nonsense by GPLHost-Thomas · · Score: 1

      Which is exactly what happened with Squeeze. In Lenny, 2.6.26 was really an unfortunate choice. But with Squeeze, Debian runs 2.6.32, which almost all modern recent distributions are using as well.

  42. Re:Red Hat certification classes cost a small fort by atomic-penguin · · Score: 3, Informative

    If you round off their 2010 income numbers, subscription income totals to $639 million (85.3%), and training service income totals to $110 million (14.6%). That is all on page 40 of their 2010 Annual SEC (10-K) filing. The subscriptions had a 93% profit margin, and the training had a 36% profit margin this year. Which makes sense, I imagine training services cost quite a bit, you would probably have equipment and training material costs, as well as trainer's salaries. Then, at least some of the time, there would be travel and hotel costs incurred for the trainers themselves, anytime they are training groups.

    According to page 48 of the same report, they spent $272 on sales and marketing, which the fancy training mailer pamphlets would fall under. However, that would also include expenses from sponsoring Open Source conferences under the same line item (its not all wasted on those fancy pamphlets).

    Research and Development I imagine covers salaries for Kernel and subsystem developers. R&D costs total $148 million. Administrative costs were $104 million. According to the 10-K report, they have 3,000 employees globally.

    Total operating expense for 2010 was $534 million, once you have tacked on taxes the Net income comes to $87 million.

    There is a lot of boring stuff in SEC filings, most always something interesting to learn from them though. If you really want to find out what a company is all about, there are some interesting details, a lot of it is in there. It explains in brief detail what each line item in the Balance Sheets and Income Statements actually mean in mostly plain English. Plus, the executive summary gives you some insight into their management's frame of mind, business model, and strategies.

    --
    /^([Ss]ame [Bb]at (time, |channel.)){2}$/
  43. Re:First google, now redhat, then... by Frosty+Piss · · Score: 1

    What I find interesting, Chris, is that the parent has apparently never seen Goatse before. "Or something".

    --
    If you want news from today, you have to come back tomorrow.
  44. Re:Clones around, it's "enhanced clones" with trou by judeancodersfront · · Score: 2

    shhhhhhh you'll mess with slashdot group think

  45. Re:Oracle? Well, ya don't say... by judeancodersfront · · Score: 1

    Why was this modded down? Screw reality?

  46. Re:Clones around, it's "enhanced clones" with trou by _Shad0w_ · · Score: 1

    You appear to be ignoring the bit where Oracle is developing btrfs and CRFS.

    --

    Yeah, I had a sig once; I got bored of it.

  47. Re:Clones around, it's "enhanced clones" with trou by _Shad0w_ · · Score: 3, Interesting

    I think the bit of Oracle Linux which bemused me was the fact that installing Oracle 11g on it is is still non-trivial; it requires you to install a bunch of packages and tweak kernel settings. If you're going to distribute your own brand of Linux, you could at least have an installer option for "This is going to be an Oracle RDBMS server, please install everything I need and configure the kernel as needed". Giving you a script to run as root part way through the RDBMS install process doesn't really cut it.

    --

    Yeah, I had a sig once; I got bored of it.

  48. Re:Clones around, it's "enhanced clones" with trou by Anonymous Coward · · Score: 1

    Well said. Companies have no emotions and cannot be offended. Only people can be. When you hate companies, you push the employees of that company away from you, making it more difficult for them to adopt your view. If you criticize actions, and explain your view, then you might persuade the employees in that company, changing the direction it takes.

    In other words; positive feedback when they do good, and negative feedback when they do bad. Hating companies means your view is always negative, meaning that your opinion is worthless.

  49. Re:redhat support is very expensive by buchanmilne · · Score: 1

    we recently were stunned by the very high cost of redhat support. Its more expensive than microsoft.

    I suspect you were comparing licensing (MS) to support (RH), not support to support.

  50. Re:Oh no... by OeLeWaPpErKe · · Score: 1

    I wonder how this squares with the GPL. I mean, the GPL clearly specifies Redhat has to release the source
    1) in machine-readable form
    2) "The source code for a work means the preferred form of the work for making modifications to it."

    It seems to me it would certainly be a reasonable demand to state the second implies "the source" is the internal Redhat git reposity ... That certainly is redhat's preferred way of modifying it.

  51. Re:Oh no... by Builder · · Score: 1

    Well, CentOS are AGES behind their original schedule on the CentOS 6 release. 5.6 is well behind as well. That's not a basket I'd be putting eggs in right now.

  52. Re:BUT INFORMATION WANTS TO BE FREEEEE. by ppanon · · Score: 1

    just short of a recent upgrade to a chip in everybody's hand.

    The chip isn't the problem. The real problem comes when the LED attached to the chip starts glowing when you reach thirty years old. Then everyone expects you to submit to your death at Carousel.

    --
    Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
  53. Re:Here goes last supporter of open-source by Inda · · Score: 1

    There's an option to mod new users down, or there used to be. I cannot check on this PC as it only has IE7 installed and the slashcode is trying to be clever but it doesn't display the forms /rant

    --
    This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
  54. Re:Clones around, it's "enhanced clones" with trou by Anonymous Coward · · Score: 1

    CentOS is a free product that the CentOS team (and me personally) have spent 8 years building and releasing. I am tired of people complaining that a free product that saves them $2500.00 a pop every time they use it on a server is not being completed fast enough for their liking. It is if they think they are owed something and are paying thousands of dollars to the CentOS team for the product. They are not. I have never made one thin dime from the production of CentOS. If CentOS meets your need, use it. If you want a product with SLAs and firm deadlines buy something else that has it (like the products from Red Hat). Or offer to pay the salary for 1 or more of the CentOS team members for a year (or more) so that we can make CentOS their only job.

  55. Re:Oracle? Well, ya don't say... by moonbender · · Score: 1

    Are you new here? Anonymous Cowards start at Score: 0.

    --
    Switch back to Slashdot's D1 system.
  56. Debian 1 RedHat 0 by matt007 · · Score: 1

    Its really funny, this just a few days after Debian announce that they will ease co-operation with derivatives :

    "The Debian Project has taken another important step towards better collaboration with its more than 300 derivative distributions by launching the Debian dErivatives eXchange project (DEX). The core idea behind DEX is to reduce the technical differences (informally called "delta") between Debian and its derivatives. This is mainly accomplished by easing the integration of patches from derivatives. Making available the patches from all derivatives results not only in a better system for all involved parties, but also eases the workload of the derivatives by reducing the differences derivatives have to maintain themselve"

    The guys at redhat are going the wrong way.

  57. Re:Oh no... by C0vardeAn0nim0 · · Score: 1

    they're not denying the source. they're just bundling togheter the vanilla kernel AND their own patches, nothing wrong with that from a GPL perspective, there's nothing in the license that says your changes have to come in the form of patches.

    --
    What ? Me, worry ?
  58. The Letter instead of the Spirit of FOSS by wisnoskij · · Score: 1

    So basically Red Hat is telling us because they cannot legally change to be a fully closed source project they will just try to go against the spirit of FOSS as much as possible without breaking the letter of it?

    --
    Troll is not a replacement for I disagree.
  59. Re:Clones around, it's "enhanced clones" with trou by bsDaemon · · Score: 1

    I suspect that's just so they can make sure that the plebs use it and only their customers can have ZFS on Linux without a bunch of hassle.

  60. Re:Clones around, it's "enhanced clones" with trou by bsDaemon · · Score: 1

    If they made that easy, companies wouldn't need Oracle DBA staffs whose primary job is to deal with Oracle Support, so their support and training business would take a hit. I don't think they really want to make it easy.

  61. Re:Oh no... by makomk · · Score: 1

    CentOS is unaffected, right up until the point you start running into problems... at which point Red Hat's source-hiding antics will make it a real pain to dignose and fix the issue, especially if it's most easily solved by reverting one of the patches.

  62. Re:Clones around, it's "enhanced clones" with trou by hesaigo999ca · · Score: 1

    I agree, however RH fails to realize that whatever code they are applying to the kernel does not belong to them, it belongs to the open source community of Linux, which is an open distribution that everyone is allowed to code for and as such deploy, but can not directly make money from, and this business model that RH says they are using, is supposed to be only for the service and support they offer with their packaged distro, however, keeping code secret, and making it that now what you pay for is the extra code that they are keeping to themselves, that only works on the linux kernel, so you can not say it was developed for anything else, means they are breaking the open license agreement, however, 1 billion dollars can grease a lot of palms, unless of course Linus gets involved...

  63. Re:Clones around, it's "enhanced clones" with trou by S.O.B. · · Score: 1

    I know it doesn't drown out all the whiners but please accept my thanks for all your hard work.

    I use CentOS on my server and I have nothing but praise for it. Some people like to live on the bleeding edge but for a server OS I appreciate the stability of CentOS.

    Don't let the vocal minority get you down.

    --
    Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
  64. Re:Oh no... by Enderandrew · · Score: 1

    If there is a problem introduced with a Red Hat patch, it will be fixed upstream. And since CentOS promises binary compatibility with Red Hat, they tend to just take the Red Hat sources and compile them as is.

    And Red Hat isn't hiding their source. They're just not listing kernel patches as broken out. Any kernel developer should be able to look at their existing patch set, compare it to new kernel patches floating around and figure it out. It isn't rocket surgery. Don't make a mountain out of a red hat-rack.

    --
    http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
  65. Stupid Kernel Question by wytcld · · Score: 1

    As a user of Linux since Slackware was on 13 floppies, here's what I don't understand about the distros: Instead of sticking with an old kernel release and backporting patches, why not move forward to the latest kernel? Coming from the days were it was more common than not to compile your own kernel from vanilla source for whatever distro you were using, I've never gotten in trouble doing that. A few times I've left out an option and had to recompile. But I've never had a new vanilla kernel break other aspects of the distro. I used to do this on Slack, Red Hat (years back when their patched versions were often broken), Debian and Gentoo. I still do it when I need recent kernel features on Ubuntu, although when business requires something on CentOS I stick with the RH-patched version there. My experience with Ubuntu: 10.04 and 10.10 run fine with the most recent vanilla kernels, although YMMV, I guess.

    Seriously, why do the distros backport to old kernels rather than roll the kernels forward? What they don't backport is often good stuff, which your machine will run happier with. I can see hanging back a few point releases to make sure the kernel version has no major bugs or regressions reported against it, but all the distros allow their kernels to get far too stale, with RH being the worst over time - and to know what your kernel really has in it, you then become dependent on RH rather than kernel.org. Has the policy long been to take the more obscure road to "earn" the support contracts?

    --
    "with their freedom lost all virtue lose" - Milton
    1. Re:Stupid Kernel Question by Chirs · · Score: 1

      Instead of sticking with an old kernel release and backporting patches, why not move forward to the latest kernel?

      Money.

      Suppose you have some embedded hardware that you paid the hardware vendor $$$ to provide support for version X of Redhat. As long as Redhat keeps version X alive, you're happy. If Redhat jumps to version Y with a new kernel, you now need to pay $$$ again for support of that embedded hardware. Or maybe the hardware vendor paid $$$ to Redhat, and if Redhat jumps to version Y they're contractually obligated to rewrite the support for that hardware.

      Alternately, as long as a product stays on Redhat X the managers may not think it needs to be regression-tested, but if Redhat stops maintaining version X and forces everyone to jump to version Y then the whole product needs to be regression-tested from scratch. This costs money.

    2. Re:Stupid Kernel Question by Anonymous Coward · · Score: 1

      Because customers use drivers that see their configurations change willy-nilly even in patchlevel releases of the official kernel. A day's worth of downtime in your datacenter because someone decided to shuffle ioctls around could cost you your business, but certainly your job. Yes, you could do the kind of due diligence yourself and track down every change, but there's a reason you're buying an OS and not writing one.

      User-mode software isn't particularly safe either: It's even less likely to get recompiled, and every new version of the kernel uncovers new bugs and idiosyncrasies in glibc.

  66. Re:Clones around, it's "enhanced clones" with trou by McKing · · Score: 3, Interesting

    Redhat is allowed to do exactly what they are doing. Nothing in the GPL requires them to make their changes available upstream (although they usually do), it requires them to make any changes available to their customers. They still release their changes to the kernel source code, but they changed the way those changes are distributed to their customers.

    They used to make these changes available as a patch set that could be applied to the vanilla source from kernel.org. "Enhancers" like Oracle and others would take the vanilla source, cherry pick the patches that they wanted to apply out of Redhat's patch set, and compile the kernel, possibly adding in their own patches. Now Redhat is making the changes available in a single large pre-patched tarball, which means that if Oracle doesn't want to apply all of the patches, then they have to hunt down the changes themselves which is more time consuming and error-prone.

    Say Redhat comes up with a patch that tweaks the filesystem code in a way that in some cases makes an Oracle DB 10% slower. In the past, Oracle would just apply all RH patches except that one. Now they have to take the vanilla source, diff it against Redhat's patched source, hunt down all the changes related to that filesystem patch, back those changes out manually, and hope that they got it right.

    --
    If only "common" sense was actually that common...
  67. Umm.. No, its simple. by Stone316 · · Score: 2

    To the other guy who responded to this comment: If your DBA has to call Oracle support to figure out how to install it on Linux then you need a new DBA. It takes 10 minutes to prep a RedHat OS to install Oracle, its not complicated.

    As for Oracle Linux, there is a package you can download which will install the pre-reqs called oracle-validated. From the links below:

    Named after, and derived from Validated Configurations, oracle-validated also creates an oracle OS user and an oinstall and dba group. Kernel parameters are also set properly, ensuring that the Oracle Universal Installer will proceed without complaints. Very nice!

    http://blogs.oracle.com/sergio/2008/08/revisiting_the_oraclevalidated_1.html
    http://blogs.oracle.com/AlejandroVargas/2008/10/the_oraclevalidated_rpm_is_ava.html

    Pretty simple.

    --
    "Thanks to the remote control I have the attention span of a gerbil."
  68. Re:Clones around, it's "enhanced clones" with trou by McKing · · Score: 2

    The Linux kernel doesn't belong to you or me or "the community", it belongs to the copyright holders, with Linus as the arbiter of their rights. Redhat isn't closing the source or keeping anything secret, you've misunderstood both how Redhat works and also how the GPL works.

    Nothing in the GPL says that you can't make money directly from GPL'ed software. You're free to take any GPL'ed software, compile it, put it on a CD, and sell it as-is. In fact, that is how Redhat and a lot of others got started. What you can't do is take credit yourself for all of this software (you must attribute the copyright holders) and you can't provide binaries without providing the source as well, including your changes. You also pass along the same rights you have when selling GPL'ed software, which is why CentOS and Scientific Linux can download the source RPM's for RHEL from Redhat and run them through a build script that changes the Redhat logo to something else, builds all of the free bits (about 99% of the distro).

    Actually, Redhat could go one step further, and instead of providing the source RPM's to everyone, they could just put them on the DVD with the OS and not make them freely downloadable. They only have to provide source to their customers, not the general public. They know the anyone could buy a DVD and repost the source RPM's, so they just go ahead and make them available to everyone.

    --
    If only "common" sense was actually that common...
  69. Red Hat is not being evil by walterbyrd · · Score: 1

    Linux-Mag covers the Rat Hat decision much better

    http://www.linux-mag.com/id/8414/

    Increasingly, Red Hat’s major competition is just saying “hey, we’ll let Red Hat do the engineering work and just provide support.” This is true of Oracle, and Novell to a lesser extent. Oracle has been riding on Red Hat’s coattails for years and has said it would do just that, saying that companies should compete “purely on the support side of the business.”

    Novell still does its own very fine Linux distro, but if you look carefully, the amount of new features and energy put into its Linux distro the past few years has waned a bit. The company has ramped up support offerings for RHEL in the meantime, and put a lot more energy into things like SUSE Studio.

    Oracle is just content to leech off of Red Hat. While Novell is trying to woo customers over to SLES by supporting RHEL as a bridge to SLES, Oracle just freeloads off of Red Hat’s distribution.

    It’s a good thing that the GPL and other open source licenses allow companies to jump in and provide support for competitor’s products. But this trend isn’t healthy for the larger community — and it’s not something that can or should be solved by licensing. Companies in the market for Linux services should exercise a little forward thinking and reward the companies that are doing the most to maintain the ecosystem. Here’s a hint: It ain’t Oracle. Even if that Oracle support contract is a bit cheaper than Red Hat’s right now, what do you think Oracle’s going to charge if it manages to marginalize Red Hat?

    Bottom line: If you want to snipe at Red Hat for its admittedly community unfriendly change, at least recognize that the company is still doing more than its share of the work.

  70. What are you talking about... by falconwolf · · Score: 1

    Copy and paste:

    And what's to stop others from doing the same if they have Redhat under another name? If Oracle repackages RHEL who's to stop Oracle customers from installing updated RPMs too?

    Falcon

  71. redhat customers can still see broken-out patches by Chirs · · Score: 1

    There is/will be a web interface for RedHat customers with formal support to see the individual broken-out patches. This move just makes it so that they're not available to non-paying customers. (i.e. Oracle)

  72. Re:Clones around, it's "enhanced clones" with trou by hesaigo999ca · · Score: 1

    >Nothing in the GPL says that you can't make money directly from GPL'ed software

    Have you read any of the forms when you try to create a new software and apply for any of the said possible GPL options out there....clear as day, about making money being a no,no....black and white, there are many forms, some partial, some full, but the one that RH is using for Linux seems to me to fall under the one that they can not charge for the said code or the corrections...

    Of course, I know nothing about programming, and nothing about computers, and binary to me is just all about
    011101010010000001110010001000000111011101110010011011110110111001100111

  73. Re:Clones around, it's "enhanced clones" with trou by hesaigo999ca · · Score: 1

    Sounds a lot different then your first claim, but will allow it, say they do offer the full package as a tarball because they are required to upload it and make it available, then that tarball becomes the patch, not a batch of patches.

    As you say, Oracle cherry pciks what they want and leaves the rest, but as a customer i am allowed to pick which patches i download and install, and which i do not want, because xyz reason i think something is unstable in my work environment,
    just because RH needs something fixed, does not mean i am ready to create a situation in my environment, which is why rpms allow you to select which to install and which to leave behind....

    Based on your description, you are claiming, that RH is forcing users to install all that is part of their package, I would say this would hurt their customer base, more then anything....they managed to make 1billion dollars even with Oracle doing what they do, I would say leave it as is, and keep doing what your doing, as soon as you do fix something that aint broke, you play with fire....i guess only time will tell....

    -- There are many types of people in the world, those who work for RH and those who don't

  74. Re:Oh no... by makomk · · Score: 1

    If there is a problem introduced with a Red Hat patch, it will be fixed upstream.

    Maybe. Eventually. If it affects a paying Red Hat customer out there somewhere enough. Also note that pre-release kernel source packages are now only available to Red Hat customers - they were taken offline at around the same time as the broken-out patchsets - so you'll probably be waiting a while.

  75. Re:Clones around, it's "enhanced clones" with trou by burnin1965 · · Score: 1

    I am tired of people complaining that a free product that saves them $2500.00 a pop every time they use it on a server is not being completed fast enough for their liking.

    Just ignore them, keep up the good work, and thanks.

  76. Red Hat's statement is quite a few clicks away, cf by D4C5CE · · Score: 1

    http://press.redhat.com/about/news/blog/commitment-to-open/ for the information right from the hacker's mouth.

  77. anti-open by v(*_*)vvvv · · Score: 1

    making it harder for Oracle to clone.

    = more proprietary.

  78. GPL by Art+Deco · · Score: 1

    The revenue model of the Free Software Foundation was basically give away software and charge for media and support (ok, with the Internet nobody really needs media). There is no requirement in GPL to donate any specific number of lines of code, the only requirement is if you distribute its software you have to give away the source. If Red Hat wants to be able to close the door to cloners than they should switch to the BSD kernel and be done with it. Everything Red Hat does to make it difficult for other entities to use their code goes against the spirit if not the letter of the GPL. Instead of licensing their distribution Red Hat shoulld give away the software then charge for support. That is how it worked before RHEL and is the way it should work today. Red Hat should be happy that other people are using their contributed code rather than feeling violated.

  79. Re:Clones around, it's "enhanced clones" with trou by jomcty · · Score: 1

    AC, I too want to personally thank you for your efforts and the efforts of the entire CentOS team. I run CentOS at home on my personal server for various tasks.

  80. Its a business by pythagoreanmetronome · · Score: 1

    I feel the same way about Canonical and Red Hat, which is this: once they have enough value built into their product they will stop offering it for free. As it stands right now they are just building their customer base and using free software as a way of doing that.

  81. Re:Clones around, it's "enhanced clones" with trou by laurelraven · · Score: 1

    Based on your description, you are claiming, that RH is forcing users to install all that is part of their package, I would say this would hurt their customer base, more then anything....they managed to make 1billion dollars even with Oracle doing what they do, I would say leave it as is, and keep doing what your doing, as soon as you do fix something that aint broke, you play with fire...

    From my understanding, they are still releasing the individual patches to their subscribed customers; it's the public patchset that is now being released as a single patch. Also, their subscribers, while they can pick and chose their patches, are not allowed per their license agreement with RedHat to redistribute the individual patches in the form that they get as subscribers. They could, of course, redistribute the single patches that RedHat is already making available, however.

    All of the changes they are making are being made available as per the GPL, and they are still one of the biggest and most active corporate contributers to Linux. I'm not sure about all of the ramifications of what they are doing here, and there may be some reasons why what they are doing is not as open as the community would like, but on the whole, I see what they do as a very positive force in the open source/free software movement. Linux would likely not be where it is today without them.

    --
    RTFA is Known to the State of California to cause cancer.
  82. Re:Clones around, it's "enhanced clones" with trou by jon3k · · Score: 1

    I didn't realize it was based on RedHat at all. My understanding is Xen doesn't even use a Linux kernel and it's based on Nemesis. I'm very poorly educated on the subject, but if you've got some more information I'd like to check it out. We're VMWare customers in the datacenter but I use Xen personally (on CentOS).