Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Oracle Linux

The Real Truth About Oracle's 'New' Kernel 177

An anonymous reader writes "Yesterday at OpenWorld, Oracle announced a 'new' Enterprise kernel for its so-called Unbreakable Linux. What's the real truth? The company is simply sticking a 2.6.32-based kernel on top of its re-branded Red Hat Enterprise Linux clone and trying to spin it as a new and innovative development."
This discussion has been archived. No new comments can be posted.

The Real Truth About Oracle's 'New' Kernel

Comments Filter:
  • by Anonymous Coward on Tuesday September 21, 2010 @11:20AM (#33650642)

    People may want to check the LWN discussion on the topic, which includes comments from Chris Mason and others concerning their improvements over vanilla 2.6.32:

    http://lwn.net/Articles/406242/

  • Re:So what? (Score:3, Informative)

    by sprag ( 38460 ) on Tuesday September 21, 2010 @11:27AM (#33650776)

    Not a troll, but a pointing out the obvious. The "major" announcement was nothing more than 2.6.18+patches -> 2.6.32.

    What doesn't get mentioned is that the oracle kernel would invalidate any ISV certifications that oracle's linux might have "inherited" from RHEL...

  • Nope. (Score:1, Informative)

    by Anonymous Coward on Tuesday September 21, 2010 @11:45AM (#33651148)

    We bought the support from them. No penguin.

  • by Kludge ( 13653 ) on Tuesday September 21, 2010 @12:00PM (#33651394)

    This could be glossing over quite a bit of useful work for Oracles customers.

    You are glossing over the point of the article.
    1. Redhat writes lots of great Linux stuff that make the kernel better (11.6% of the kernel).
    2. Oracle passes it off as their own. (They only contribute 1.3%, less that 1/10 that of Red Hat).

  • Oracle support sucks (Score:3, Informative)

    by mangu ( 126918 ) on Tuesday September 21, 2010 @12:28PM (#33651850)

    Anecdotal evidence, but where I work there were some people using pro*fortran to access Oracle databases from Fortran. pro*fortran was dropped between Oracle 8 and 8.1

    It took six months of digging for the Oracle support people to finally tell us they had dropped pro*fortran from their product. Everyone kept saying "sure, we support Fortran, but that's not my specialty, let me get an expert for you"

    When the technical support people don't know their own product, what worth is it paying for that it?

  • by blitzkrieg3 ( 995849 ) on Tuesday September 21, 2010 @01:08PM (#33652394)

    "Fine tuning" could be anything from tweaking some compiler settings to actually patching things in the kernel.

    They patched quite a few things, but at the same time thought it important to be as close to mainline as possible. Here's the lowdown from Chris Mason [lwn.net] over at LWN:

    Hi everyone,

    One of the goals of this kernel was to stay as close to 2.6.32.stable as we could. The sources are here in git, they won't be rebased:

    http://oss.oracle.com/git/?p=linux-2.6-unbreakable.git;a= [oracle.com]...
    git://oss.oracle.com/git/linux-2.6-unbreakable.git
    The main differences from mainline:

    *) semtimedop optimizations. I posted these to the list a while ago, and Manfred took things in a less complex direction. He was waiting for me to fully benchmark the less complex version, but we ran out of time in the release cycle and had to focus on other things. Oracle hammers on the IPC lock, so these made a big difference, and now I finally have time to properly benchmark his approach against mine.

    *) Ocfs2
    *) Small lock contention fixes
    *) Receive packet steering
    *) A large update to RDS (this is in a different package)
    *) A patch to list msi irqs for each device in sysfs. A modified irqbalance uses this to keep irqs on numa local cpus.

    There are other bits and pieces, but we resisted the urge to pile things in.

    The solid state disk access number came on a huge machine, and the improvements came from getting rid a lock in the driver and enabling it for softirq affinity code without taking any of the request locks.

    Over the next 12 months we'll be getting an update prepared to a new mainline version, and trying to hammer on upstream kernels as much as we can to reduce our patch count even more.

    -chris

  • by blitzkrieg3 ( 995849 ) on Tuesday September 21, 2010 @01:20PM (#33652576)
    Full Disclosure: I work for Red Hat, but these opinions are my own and not representative of RHT.

    The Kernel is the only thing in there that ISN'T from RedHat

    This is wildly misleading. Almost everything Red Hat ships in Enterprise Linux is not from Red Hat. Projects like GCC, RPM package manager, Gnome, Glibc, KDE are all too big for Red Hat to develop on its own. The only things I can think of that are completely from Red Hat are layered products like Directory Server or projects where Red Hat has maintainership and majority contributions, like NetworkManager.

    Having said that, I can't think of a kernel contribution report in recent years where Red Hat was not #1.

    Apparently to call it a "new" kernel TFA feels they should have started entirely from scratch.

    To call it a "new" kernel it has to be something less than nine months old [kernel.org].

Happiness is twin floppies.

Working...