Don't trust it.
What's the catch? I'd always be concerned about some obfuscated lock-in
Oracle’s announced that the version of its GNU/Linux for Arm processors is now generally available and signalled its intentions to help “build out a very viable server/cloud platform for Arm.” Big Red revealed its efforts in November 2017 with the debut of an unsupported developer release of Oracle Linux 7 Update 3. Come …
Still no download available for generic Linux / ARM systems
It was on this very journal that I read stories about Linus T's enswearified rants about ARM devices and non-discoverable buses. I'm guessing that nothing yet has changed in the world of ARM SoCs to change that state of affairs.
Whatever its faults, PCI is discoverable. You can interrogate it to find out what devices are where on the bus, and what resources they expect and so on. Many ARM SoCs have devices that aren't available like that, and you have to infer them from the fact that you have SoC type X, therefore you have devices A, B, C. That's a major obstruction to the construction of a generic ARM kernel for any OS.
"It was on this very journal that I read stories about Linus T's enswearified rants about ARM devices and non-discoverable buses. I'm guessing that nothing yet has changed in the world of ARM SoCs to change that state of affairs." aarch64 is generally somewhat better than 32-bit ARM there. Especially with server-class hardware as opposed to dev boards.
“rants about ARM devices and non-discoverable buses. I'm guessing that nothing yet has changed in the world of ARM SoCs to change that state of affairs.
Whatever its faults, PCI is discoverable.”
ARM servers, if they ever really come to exist at all, will almost certainly use discoverable buses like PCI and USB in much the same way as x86 servers do.
For other devices more tightly coupled to the processor they’ll tend to use ACPI, again in much the same way that x86 servers do.
The nondiscoverable rantyness is largely for devices like phones, tablets, TV boxes etc. and (unfortunately) many of the “hacker” boards that are built using the same chips. The problem should largely go away for server systems.
don't you mean
We’ve asked but aren’t holding our breath as Oracle’s not a charity and it will cost you $$$
Given their recent push for $25/month for Java SE I would not put it beyond them to charge more than RedHat does for its support.
Unsure if that is a fair assessment or not but is the UEK open source and can you see how many lines of code differ from the RHEL default? I've run perfectly legal dummy kernel packages for Red Hat (to fool it into thinking its running Oracle Linux) and they allow the (arguably EULA breaking) preinstall packages for Oracles products that automatically fix all the prerequisites for you but the UEK is a different beast altogether and allows hot patching of the kernel which I think the default RHEL one doesn't. Support for Oracle Linux is an interesting argument, especially depending on which hypervisor it might be sat on. RHEL support is only around $2k so pales into insignificance against most Oracle product (not OS) licensing and support costs.
Yes. All of the SRPMS for the entire distribution are on their public-yum repo site (just like RHEL), and the Unbreakable Kernel source is even on github. They pretty much have to supply the code because of GPL.
While the UEK does provide kSplice, Oracle only provides the updates to people who have premier support, sadly.
While I agree with Oracle bashing, I can honestly say that lagging on updates is one thing I haven't seen them do. Obviously for upstream fixes (eg, ones from RHEL) they can't possibly release them *before* RH does, but their turnaround has always seemed pretty fast.
After the first Intel microcode fiasco, Red Hat stopped providing microcode updates in the distro itself, while Oracle has continued to do so. So in one respect, they're "better" than RHEL for people who are running servers where their vendor has failed to provide updated BIOS releases with newer microcode embedded.
The "Unbreakable" branding currently only applies to their kernel, not the distro itself (which is just simply called 'Oracle Linux'). It IS a stupid name though!
So the company that owns SPARC
Oracle does not own SPARC, SPARC International owns it.
Oracle, like Fujitsu, simply licenses and manufactures SPARC chips, which is much the same model ARM uses.
Oracle recently announced that they are stopping direct development of SPARC over the next few years.
However, they will still sell Solaris on SPARC and SPARC solutions, it's just that Fujitsu will make the boxes. Their website has already been updated to list a load of Fujitsu servers.
Basically, Fujitsu will be the only Serious Money still going into SPARC. This isn't necessarily the end of SPARC, as IBM is the only Serious Money going in to Power and The Z processors, and Power is still chugging along.
Fujitsu's SPARC roadmap actually looks pretty impressive tbh.
Oracle recently announced that they are stopping direct development of SPARC over the next few years.
Did I miss the overt announcement on this? I mean, it's quite obvious that's what they're doing; I just don't remember a formal announcement.
Heh, I just looked at their latest roadmap. It reminds me of the ending to Infinity War.
https://www.oracle.com/assets/sparc-roadmap-slide-2076743.pdf
so adds MySQL, Docker, Java efforts under way too
Oracle adds MySQL, Docker and Java?
MySQL, Docker and Java efforts are under way?
Which is it?
Oh hang on, that "too" confuses the matter further, with the implication that something else has happened in addition to the [whatever] that has happened with MySQL, Docker and Java.
That kind of unparseable headline (in this case subheading) is truly infuriating. Can't someone proofread those things before going to press?