Oracle Acquires K-splice For an Undisclosed Amount

drspliff writes "Oracle today announced it's completed the acquisition of K-Splice, dropping support for Redhat, CentOS, and SUSE, and closing doors to new customers. Unless of course you want to become an Oracle Linux Premier Support subscriber — then it comes as standard."

Comments

Thanks a lot, douchebags.

[Anonymous Coward]

On July 21, 2011, Oracle announced they acquired Ksplice, Inc. At the time of the company was acquired, Ksplice, Inc. claimed to have over 700 companies using the service to protect over 100,000 servers. While the service had been available for multiple Linux distributions, it was stated at the time Ksplice, Inc. was acquired that "Oracle believes it will be the only enterprise Linux provider that can offer zero downtime updates."

Re:Thanks a lot, douchebags.

[h4rr4r]

Oracle failed to read the license I think.

RedHat, please fork ksplice today.

Re:Thanks a lot, douchebags.

[PCM2]

RedHat, please fork ksplice today.

The really shitty thing is that Oracle Enterprise Linux is essentially a fork of Red Hat Enterprise Linux, in the same sense that CentOS is. Oracle has already been distributing a version of Linux that gives back nothing to the company that does most of the hard work to make it enterprise-ready. Now it's adding new components to Oracle Enterprise Linux in such a way as to tell the rest of the community it can't have them anymore. If Red Hat wants to fork K-Splice, that's possible under the license, but again Red Hat will have to do all of the work, and Oracle will contribute nothing.

Re:Thanks a lot, douchebags.

[Anonymous Coward]

Ksplice don't own any patents. Microsoft's patent application on a similar technique was rejected - due to clear prior art dating back to the PDP-11.

Ksplice's value was in smart engineers, but it's time for a distro - a proper distro, that is - to merge this as part of their normal update cycle, and possibly finally implement usplice() as well.

Damn, they were kind of cool until this. Now they got bought by Oracle. Everyone knows what happens when you get bought by Oracle. I'm kind of annoyed. I'm a Ksplice customer. Or was a Ksplice customer, in any case; unless I can get a very clear answer about future support and pricing in writing, we're done professionally.

Re:Thanks a lot, douchebags.

[vbraga]

The kernel patches. Over a vanilla kernel, RedHat applies a lot of patches: backporting features and drivers, incorporating solutions that haven't been accepted into upstream yet, and so on. Oracle cherry picks RedHat patches and offer their own. Now RedHat offers just a single "merged patch" which makes way harder for Oracle to cherry pick wherever it wants to. It doesn't matter to CentOS (and SE, probably) because they just rebuild wherever RedHat delivers.

Anyway, given the amount of resource Oracle has and the slow release schedule of RHEL, I doubt they will not be able to keep track of wherever changes RedHat made.

Search slashdot for this, it was posted here few months ago.

So much for K-splice

[etymxris]

Well, I imagine what will happen is what's happened to other open source products Oracle got its hands on. Redhat and SUSE will likely step up to the plate and support kernel splicing without the help of K-Splice. Oracle is trying to give customers a reason to use their version of Linux rather than Redhat's or SUSE's. However, stuff like this just pisses customers off.

Honestly, I can't understand why anyone continues to use Oracle products any more than is absolutely necessary. It's said that companies only care about the money and don't care about how evil their vendors are. But Oracle time and time again dicks over their customers, and in ways that cost the customers extra money. Eventually executive golf games with the marketing guys aren't going to be enough to keep the sales coming in.

Which I guess is why they continue to buy established firms and fuck over the existing customer base with price hikes, poorer service, and more restrictive licensing terms.

Re:Sellouts

[JaredOfEuropa]

Reminds me of that South Park episode:
"What's a sellout?"
- "If you work in the entertainment industry and you make any money, you're a sellout".


Seriously, these guys created K-Splice and they should keep their business going as is, instead of selling to Oracle for (probably) an ass-load of money? For you? Or should they be free to do with their business and their product as they please?

You, of course, are free to create your own version of K-Splice. Except of course that Oracle will have tied up the idea with patents and a pack of blood-thirsty lawyers.

Re:Sellouts

[h4rr4r]

There is a difference between selling your company to another one and selling it to Oracle. This would be like selling your gefilte fish factory to Hitler.

Re:Sellouts

[PCM2]

The thing with a false dilemma is that it doesn't afford you the possibility of having morals.

FTFY.

Worth it?

[Junta]

The problem I have with kSplice is it is a solution to a problem that most everyone stopped caring about years ago. People with real work to do stopped treating the output of uptime as a sacred cow and started putting the resiliency at the application layer in multi-server environments. Relatively low outage of a component for scheduled maintenance is nice, but reducing that to zero is well beyond the point of diminishing returns since the app better not care if that server goes down anyway (or else for all your efforts an uncorrectable ECC error will come and just ruin your day).

It's been a while since I read up on it, but if I recall it worked kind of like a rehook of system calls as the opportunity arises. This means you don't have a particularly strong assurance that a security or bug fix actually is in effect for all running instance of an application, and it also limited the sorts of updates that could go in. It's kind of like how you could update glibc without explicitly restarting any daemons, but you won't actually see the benefit of that update until you actually take the hit to let the application exit and restart to induce load of the better code into ram.

Hate to admit it, as much as MS got made fun of for rebooting after every update, it really is the way to go in a practical perspective if you don't want to be bitten by some kernel/glibc vulnerability even after you *think* you've updated.

Re:obfuscate the build and/or other meta-programs

[bill_mcgonigle]

so maybe Redhat just introduces a few interesting little tweaks to some meta-portion of their system

They already do this - that's why CentOS 6 took nearly a year to arrive.

"Go build libfoo.so.7 under Fedora 13 using an old version of mock and then link it again the bar object files" to get a binary-compatible RPM. RHEL's build process isn't self-hosting.

Oracle is cheerfully pissing in the well. At some point that's gonna cost them.

Re:obfuscate the build and/or other meta-programs

[bill_mcgonigle]

And yet Scientific Linux was able to release months ahead of CentOS from the same RH source....

Right, they built it all as self-hosted and did not achieve binary compatibility. Different goals.