How to install NVIDIA drivers and CUDA on Rocky Linux 8, 9 and 10Pick your version and setup, copy the commands and check that it works.
Getting an NVIDIA GPU working on Rocky Linux takes around a dozen commands, and which ones depends on the Rocky version, whether the machine has a desktop, Secure Boot and containers.
First make sure the system sees the card. If this prints nothing, the problem is in the hardware or the BIOS, and no driver will fix it:
lspci | grep -i nvidia
The packages in this guide use NVIDIA's open kernel modules, which are the ones NVIDIA recommends for GPUs from the Turing generation onwards. That covers data centre cards from the T4 up and the RTX 20 series and later. Older cards such as the P100 or V100 need the proprietary modules, which this guide does not cover.
Then check whether Secure Boot is on:
mokutil --sb-state
If it says enabled, tick Secure Boot in the guide. You will need access to the server console for the next reboot, because the key confirmation screen does not show up over SSH.
Install the driver and CUDA
Choose your Rocky version and tick what applies. The steps update as you go, and each command has its own copy button. If you are setting up several machines, copy the whole thing as a script.
Version
Your setup
Check that it works
After the reboot, nvidia-smi should list your GPUs with the driver version. The CUDA version it shows in the top right corner is the highest one that driver supports, not the toolkit you have installed, which confuses a lot of people.
To see the version of the module actually loaded in the kernel:
cat /proc/driver/nvidia/version
The toolkit goes into /usr/local/cuda and is not on the PATH by default. To use the compiler, add it to your profile and check it:
To update within the same branch, a normal sudo dnf update is enough. When a new kernel comes in, DKMS builds the module for it. It is worth checking before you reboot that it has done so, because otherwise the server will come back without a GPU:
dkms status
On Rocky 8 and 9, moving to another driver branch means switching the module stream:
In both cases only the driver goes. The CUDA toolkit stays until you remove it yourself.
When there is more than one server
On one workstation, all this takes a morning. On a rack of GPU servers it turns into maintenance. Every kernel update has to rebuild the modules on every node, CUDA and PyTorch have to keep matching the driver, and a node that boots without its GPU sits idle until someone notices.
That is the problem RLC Pro AI solves. It is CIQ's edition of Rocky Linux for AI servers, and it ships the data centre driver, CUDA, cuDNN, NCCL and PyTorch installed and tested together with its own kernel. We are a CIQ partner: we deploy it on your servers and support it. The rest of the editions are on our Rocky Linux support page.
Frequently asked questions
Do I need the CUDA toolkit to run PyTorch?
No. The PyTorch packages you install with pip bring the CUDA libraries they need, so the driver is enough. The toolkit is for compiling your own CUDA code with nvcc.
nvidia-smi says it cannot communicate with the NVIDIA driver. What happened?
It is usually a kernel update the module was not built for. Run dkms status, install the headers for the new kernel if they are missing and reboot.
Does this also work on AlmaLinux?
Yes. NVIDIA documents AlmaLinux 8, 9 and 10 with the same commands as Rocky, including the module streams on 8 and 9.
Which driver branch should I use?
The open-dkms stream installs the latest. In production, many teams pin a branch such as 580 so that an update does not bring a new major version without warning.
SIXE
Running GPU servers on Rocky?
Tell us how many servers you have, which GPUs and what you want to run on them, and we will tell you whether RLC Pro AI makes sense and what the move would look like.
SIXE is a CIQ partner: what changes for Rocky and CentOSWhat it means if you run servers on CentOS, RHEL or Rocky.
As of October 2026 we are a partner of CIQ, the company behind Rocky Linux, and we are very pleased about it.
Rocky had been turning up on our customers' servers for a while, and until now we looked after it on our own. From now on we do it with the backing of the people who build it.
Why CIQ
CIQ was founded by Gregory Kurtzer, co-founder of CentOS. When Red Hat announced the end of CentOS Linux in 2020, Kurtzer launched Rocky Linux so that anyone running CentOS could carry on as before, and today CIQ is its main sponsor.
For many of our customers coming from CentOS, Rocky was the obvious next step. What was missing was a company standing behind it with a subscription and support, and that is what CIQ brings.
What changes for our customers
If you want Rocky with support, you no longer have to deal with a vendor in the United States on one side and with us on the other. We set up the subscription, migrate the servers and handle day-to-day incidents.
It is all explained on our Rocky Linux support page. If you already know where you are starting from, one of these guides may be more useful:
RLC Pro, if you need to stay on one release for years or need FIPS 140-3 cryptography.
The agreement also covers CIQ's AI products, and it is the part we were keenest to announce. For a while now we have been building inference infrastructure on Ceph, OpenStack and Kubernetes for companies that would rather keep their data in their own data centre. Now we can also supply the operating system for those GPU servers, RLC Pro AI, with vendor support.
Rocky joins Ubuntu, Red Hat and SUSE
We are still not tied to any one distribution. We are a Canonical partner for Ubuntu and run Red Hat, SUSE and Debian in production. Rocky with CIQ is one more option, and we will suggest it when it suits what runs on each server.
Frequently asked questions
Since when has SIXE been a CIQ partner?
Since October 2026. Since then we can offer CIQ's subscriptions on top of the migration and support work we already did.
What is CIQ?
The company founded by Gregory Kurtzer, co-founder of CentOS, and the main sponsor of Rocky Linux. It sells the enterprise editions of Rocky: RLC Pro, RLC Pro Hardened, RLC Pro AI and CIQ Bridge for CentOS 7.
If I already work with SIXE on Red Hat or Ubuntu, does anything change?
No. We carry on with Red Hat, SUSE, Ubuntu and Debian as before. We will only bring up Rocky if we think it suits you.
SIXE
Running CentOS, RHEL or Rocky?
Tell us what servers you have and what runs on each one, and we will tell you which edition fits and what the move would look like.
IBM already tried this in 1994.Its next mainframe will run ARM alongside z/Architecture. One core speaking two architectures: the idea is thirty years old, and history explains why the chip is the easy part.
Every core of the future mainframe processor will execute ARM and z/Architecture. It is a feat of engineering, and it solves one of the four problems standing between a foreign binary and production.
4contracts
30years of attempts
33public patches
12days of head start
Podcast version
IBM Z is learning ARM
The audio version of this article.
0:00
0:00
IBM has just announced one of the strangest enterprise processors in years, and what stands out is not the engineering but what it leaves unsolved. According to the August 24 announcement, IBM is designing a future processor for IBM Z and LinuxONE in which every physical core can natively execute both ARM and IBM Z instruction streams concurrently: two different architectures inside the same silicon, with no emulation in between.
In plain English, an instruction set architecture, or ISA, is the language and rulebook through which software gives orders to the processor, and ARM and IBM's z/Architecture are two different languages. What IBM wants is for every core to understand both directly, as first-class execution modes, and not as a small ARM bolted onto the mainframe cores nor as emulation dressed up as something else.
And yet, putting two languages in one core is the easy part. Buying a Japanese dictionary does not make you someone who can argue a case before a court in Tokyo, and a multi-architecture processor is no different: executing the instructions is only the first of the four contracts that a foreign binary has to close before it reaches production. When a vendor shows off a multi-architecture chip, it has almost always solved only that first one, which is a quarter of the problem.
That is why the interesting question goes beyond whether this will work: IBM has spent decades building this kind of silicon, so that much is a safe bet. The underlying question shows up the moment you pull on the why:
If adding another ISA fixes compatibility, why stop at two? Why not x86, RISC-V, Power ISA—or every language software still speaks?
And if you pull on that thread, the announcement stops being a processor story and becomes a map of what hardware can solve, what remains the ecosystem's job, and why an application can still be unavailable even when the kernel, the compiler and the source code have been waiting years for it.
The 90-second version
You do not need to design processors to follow this story. Seven terms give you almost everything you need to follow it.
ISA
What it means
The instruction vocabulary and the behaviour promised to software
Why it matters
ARM and z/Architecture are different ISAs
Binary
What it means
A program already compiled for a specific ISA and operating environment
Why it matters
An ARM binary does not turn itself into an x86, Power or Z binary
Native execution
What it means
The processor implements the ISA it exposes to software
Why it matters
It avoids instruction-by-instruction translation, but guarantees neither operating-system nor application support
Virtual machine
What it means
An isolated, simulated computer that the hypervisor presents to software
Why it matters
IBM expects ARM Linux environments to coexist with established Z workloads through virtualization
Host and guest
What it means
The host is the physical machine and its operating system; the guest is each system running inside, isolated, as if it had its own computer
Why it matters
The ARM Linux in the announcement runs as a guest on the Z host
vCPU
What it means
A virtual processor that the host schedules for a VM
Why it matters
An ARM VM may have several vCPUs and is not permanently tied to one hardware thread
KVM and SAE
What it means
KVM is Linux's virtualization framework; SAE stands for Start ARM Execution
Why it matters
KVM manages the ARM guest; SAE is the hardware doorway into ARM execution
IBM is solving the instruction problem in silicon and much of the virtualization path in Linux. The finished platform still needs firmware, virtual devices, migration and distribution support.
That gap between can execute and can operate in production is what the rest of this article is about.
Not here for the history? The section "We have tried to escape architecture before" is context, not a prerequisite: if you are in a hurry, skip it and go straight to "Why put ARM in hardware now?".
A guide, in case a word trips you up
What an ISA is, what an ABI is, and why it is so hard to run a program on another architecture: a twelve-page notebook explains it from scratch, with ten historical case files and the source for each. You do not need it to follow the article; it is here if you want the full ground.
Very few companies can combine a processor running at over 5.7 GHz with huge caches, memory and I/O at scale, inline fault detection, secure key management, cryptography and AI acceleration. And then put it inside a machine expected to stay available under workloads that would flatten an ordinary server.
Then, a few layers above all that engineering, a deployment fails because an installation script says, in essence:
if architecture == amd64 or architecture == arm64:
continue
else:
exit("unsupported architecture")
Years of processor, firmware and operating-system work have just been defeated by a two-item array.
There is something magnificently IBM about answering "we need more binaries" by redesigning the mainframe processor. But the contrast marks the limit: hardware can make a binary executable; it cannot make a vendor compile, test, sign and support it.
What IBM is aiming for with this announcement
IBM's statement describes an 11-core processor built on a 2 nm process in which every core is ready to run both ARM and IBM Z instructions, and on that basis IBM expects ARM-native Linux to run alongside z/OS and Linux on IBM Z. The design also includes AI inference acceleration and an on-chip data processing unit—DPU—integrated into the chip itself. And in case there were any doubt about the intent, IBM and ARM present access to ARM's software ecosystem as the central, stated objective of the whole design.
There is more preliminary detail, and those figures hint at more than they say. The target of the ARM implementation is AArch64 v9.3 with SVE and SVE2 vector extensions, and either of the core's two threads can run either ISA with mode changes IBM puts in the nanosecond range. And most important: IBM's preliminary presentations point to the design reusing much of the Z execution engine to run ARM—prediction, caches, page tables—though the final design is not public. That is where the design's efficiency lives, and also the verification frontier (the limit of what has been verified): the more ARM and Z share the same engine, the more must be proven that one mode does not contaminate the other.
AI, cryptography and the DPU are also presented as available to the ARM environment. What counts is the driver that exposes the accelerator to the guest system (the ARM Linux running inside), well ahead of the megabytes of cache: an accelerator that is "available" only counts when that driver exists—and about that the announcement says nothing.
This is meant to be a platform, with product ambition. But it is conference evidence, not a product specification: IBM has announced a design direction and warns that its plans may change or be withdrawn. What the announcement establishes is what IBM intends to build—not how it will present itself to the systems running inside, the security policy, the migration contract, the performance, the supported operating systems or the catalogue of independent software vendors (ISVs). "An accelerator is available to ARM" becomes useful only when a driver, a library, an error model and a support statement make it real.
30
years without a single compatibility layer persuading a vendor to sign a support contract.
Not one exception in thirty years
The five meanings of "it runs ARM"
IBM describes ARM execution as native, and the word is doing useful work: it means the processor implements the ARM architecture instead of asking an emulator to translate every ARM instruction into Z instructions.
It does not mean every ARM program will run unchanged. It does not promise the performance of a dedicated ARM server processor, support for every optional ARM extension or automatic access to every Z facility. And it certainly does not generate certifications from Red Hat, Canonical, SUSE or commercial ISVs.
Modern CPUs already turn visible architectural instructions into smaller internal operations. "Native" describes the contract exposed to software and takes for granted all the machinery working behind the curtain. IBM's design appears to extend that principle across two public architectures: shared prediction, arithmetic and load/store machinery where possible; separate architectural state where the contracts diverge.
This matters because running foreign software is not one problem. It is five, and marketing language tends to compress them into a single word, though each one acts on a different layer of the stack.
Each mechanism acts on a different layer and does a different job. Note the fourth column: ABI compatibility translates not a single instruction.
Native multi-ISA execution is the core IBM has announced. User-mode translation is Rosetta 2, Prism, FX!32 and PowerVM Lx86. Full-system emulation is QEMU. ABI compatibility—the ABI is the lowest-level contract between a compiled program and the system: how libraries are called, how parameters are passed—is FreeBSD's Linuxulator. Multi-architecture packaging is an OCI image index or an Apple Universal binary. They are not variations on one idea: each stops at a different layer, and that boundary decides which applications work, how fast they run, and who gets the support ticket when they fail.
FreeBSD offers the cleanest explanation
FreeBSD runs many unmodified Linux binaries through an optional compatibility layer called the Linuxulator. The FreeBSD Handbook documents x86 and AArch64 support, and the linux(4) manual page describes a real implementation of the Linux ABI—an operating-system layer that leaves the CPU emulator entirely to one side.
The host processor still has to understand the binary's ISA, so on an x86 machine it is the x86 hardware that executes the instructions while FreeBSD handles the Linux-style system calls, and on an ARM machine exactly the same happens with ARM Linux binaries. What Linuxulator never does is quietly translate x86 into ARM.
Hence the first rule of this story:
Understanding the instructions is not the same as understanding the operating system.
Four contracts, not one
So much for the five ways to run ARM. But running is only the first of a different list: the four contracts a binary must close to reach production. The confusion in this whole field consists of believing that settling the first one settles all four.
Every multi-ISA processor solves the first one and advertises it. The fourth has never been solved by any technology in this article, in thirty years.
IBM's processor tackles the first contract. The v6 arm-on-s390 KVM series sketches much of the kernel-level route to an ARM VM. Linux, the firmware and the virtual-machine monitor still have to complete the platform. Distributions and ISVs still have to complete delivery and support.
A platform can be brilliant at the first contract and commercially disappointing at the fourth.
We have tried to escape architecture before
IBM's design is unusual, but the dream behind it is an old one: preserve the software investment while the machine underneath changes.
Thirty years of attempts have left a pattern, and it surprises almost everyone.
A processor can speak two languages and still have no audience
In the 1990s, IBM reportedly developed a prototype known as the PowerPC 615, capable of executing x86 as well as 32-bit and 64-bit PowerPC. It is, almost exactly, the idea IBM has just announced for Z and ARM—thirty years earlier. The most detailed surviving account is a 1998 report, based on an anonymous IBM engineer; a 1995 sidebar also discussed the never-released device through anonymous sources.
The later account claimed that Minix and a development version of OS/2 demonstrated mixed execution, but that the project lacked a profitable path and could not secure the Windows support it needed. That is an insider's testimony, not established corporate history. What is documented is that Microsoft ended Windows NT development for PowerPC in 1997, citing declining demand.
The lesson does not depend on the disputed details. The silicon worked; the fourth contract was never signed.
Translation works best when it knows where the bridge ends
DIGITAL ran into the same catalogue problem with Alpha, and answered it with the most elegant engineering in this entire history. FX!32 did not translate x86 code in one pass. The first time you ran an application it was emulated, while FX!32 recorded a profile of the paths the program actually took. Afterwards, in the background, it translated only the most frequently used code paths into native Alpha code and cached the result. Every launch was faster than the last.
DEC reported that translated applications on a 500 MHz Alpha could perform comparably with native x86 versions on a 200 MHz Pentium Pro. For 1997, that was extraordinary. Kernel code and drivers stayed outside the model, and results depended on the workload.
Alpha died anyway.
IBM later took a similar route with PowerVM Lx86, translating 32-bit x86 Linux applications on Power and caching the translated code. It solved the problem Part III of this series describes: the catalogue of software nobody compiles for Power. It worked for utilities, installers and modest applications, and broke on direct hardware access, kernel modules and code that processes large amounts of data in parallel (SIMD). IBM's own advice at the time is still the right advice: use translation for less critical software, rebuild natively where the platform demands it. Lx86 was eventually withdrawn.
Transitive, 2008
The technology behind Lx86 was QuickTransit, from a British company called Transitive: the same one Apple licensed for the first Rosetta, the one that translated PowerPC applications onto Intel Macs. The same software, running in opposite directions, for the two companies in this story. IBM bought Transitive in 2008.
Apple's Rosetta 2 is the finest binary translator anyone has shipped: good enough that most users never noticed it was running. Why did it work for Apple and for nobody else? Because Apple controls the chip, the operating system, the application format, the tools, the store and the calendar. It could say "in two years this ends, port your software," and everyone ported. Even so, it remains available through macOS 27, and in macOS 28 it narrows to selected older games. The best translator in history was designed with an expiry date.
Microsoft's Prism is technically accomplished and lacks the one thing that made Rosetta work: Microsoft cannot impose a deadline on thirty years of third-party Windows applications. And the old boundary is exactly where it always was: kernel drivers must be native Arm64.
The universal processor already exists, and it is software
IBM Research's DAISY project asked the most radical question in the field: what if the real processor were an internal VLIW engine (which bundles several operations into one instruction), and every ISA—ESA/390, RS/6000, AS/400, Java—were dynamically translated onto it? Transmeta eventually shipped a version of that idea. Crusoe exposed a perfectly ordinary x86 while its Code Morphing Software translated it for a hidden VLIW core, and it failed twice over: performance was irregular because it depended on how much had already been translated, and Intel simply lowered the power consumption of its own chips.
Intel's IA-32 Execution Layer is the case that runs in the opposite direction, and almost nobody cites it. Itanium carried x86 compatibility in hardware, and it disappointed. Intel replaced it with a software translation layer that turned out to be faster than the dedicated silicon, and later removed the x86 hardware from the processor altogether. Putting compatibility in silicon does not automatically make it better. It makes it harder to fix.
QEMU never promised speed. It promised universality: whole machines or foreign user-space processes, privileged state and devices included, translated in blocks by the Tiny Code Generator. First released in 2003, it is still here, after every commercial product on this list has shut down.
Six patterns from thirty years
Six things recur across every case above.
Translation dies when the incentive dies, not when the technique fails. FX!32 was excellent and Alpha died. Rosetta 2 is excellent and Apple has already announced its end. Lx86 worked and IBM withdrew it. In none of these cases was the cause of death "we could not make it work".
Whoever controls the calendar wins. Apple could tell an entire ecosystem it had two years. That power, far more than the quality of the translator, is what separates Rosetta from every other attempt on this list. Microsoft cannot say it to thirty years of Windows software. Neither can IBM say it to its ISVs.
A bridge is not an address. Every case that worked was a transition with an announced end; the ones that tried to be permanent—Transmeta, Lx86—did not survive.
The kernel is always the boundary: FX!32, Lx86 and Prism all stop at drivers and kernel code, a barrier without a single exception in thirty years.
Hardware buys predictability and software buys flexibility, and the trade is not obvious in advance. Itanium put x86 in silicon and a software layer beat it.
Delivery and support has never once been settled by any of them. In thirty years, no compatibility layer has persuaded a software vendor to sign a support contract. That is the contract that decides whether a platform is usable, and it is the only one on the list that hardware cannot touch.
The real verdict is more nuanced than "translation failed" or "hardware won":
Use native execution where performance, privilege and long support horizons justify it. Use translation as a bridge. Never confuse either mechanism with an ecosystem commitment.
42
percent: how far IBM Z revenue fell two quarters after rising 67%.
Sold by generation
Why put ARM in hardware now?
Dynamic translation brings warm-up time, code caches and a worst case that is hard to bound. Harmless for a desktop utility; much harder to defend for consolidated enterprise workloads with signed service-level agreements. A complete ARM Linux environment also needs privileged architecture—exception levels, page tables, interrupts, translation lookaside buffer (TLB) behaviour—and native implementation makes that full-machine contract more credible than a user-space layer. Then there is longevity: Rosetta was designed to disappear, while an enterprise workload architecture may need support for a decade or more.
Underneath all of it, IBM wants ARM workloads to coexist with established Z environments under the same management, reliability and security model. It cites an ARM ecosystem of more than 22 million developers: a figure that spans many markets and certainly does not mean 22 million future mainframe developers, but does show the scale of the software investment IBM wants to reach.
So ARM in hardware solves a large, expensive problem predictably. What it still does not do is boot an operating system, publish a container, expose an accelerator, interpret a licence or persuade a vendor to accept a production incident.
ARM's own SystemReady programme exists precisely because ISA compliance is not enough. The current programme has a SystemReady Band for systems with standard hardware discovery (ACPI) and a SystemReady Devicetree Band for embedded environments (Devicetree). ARM also maintains SystemReady VE self-declarations for virtual environments.
IBM claimed SystemReady compliance, but stopping at a generic "does it comply?" gets you nowhere: you have to ask IBM for the specific band that applies, the requirements version, the VE self-declaration and the test result. And even then, ARM warns that platform compliance does not mean an operating-system vendor supports that device.
Why ARM, rather than every ISA?
Imagine a processor implementing x86-64, AArch64, Power ISA, z/Architecture, RISC-V, SPARC, MIPS, Alpha and 68000. Plus one more architecture because somebody found an old ERP box behind a cupboard.
It sounds inclusive. It would also be a permanent silicon museum.
Every ISA brings far more than a decoder: registers, exceptions, privilege behaviour and memory-ordering rules, among others. And with all that baggage, each one becomes another validation, security, licensing and long-term support obligation. As if that were not enough, old architectures do not even stay still: x86 carries decades of extensions, AArch64 has evolving profiles and optional features, and RISC-V is extensible by design.
A processor that implemented everything would become QEMU in hardware: new silicon every few years and impossible to patch with a package update.
That's the engineering answer. The commercial one—why now and why ARM—is read in IBM's balance sheet.
The other half is a balance sheet
The technical fit justifies a second ISA, but the choice of ARM and of this moment answers to IBM's revenue structure.
IBM closed 2025 with $67.5 billion in revenue. Infrastructure—the segment that contains the mainframe hardware—accounted for $15.7 billion of it, about 23%. That understates the platform considerably, because the software that exists only because mainframes exist is not counted there. CICS, IMS, Db2 for z/OS and MQ are booked inside the Software segment, under Transaction Processing. IBM reports an 83.5% gross margin for Software as a whole and does not break the figure out by category, so applying it to Transaction Processing is an approximation, not a measurement. The order of magnitude survives the caveat: mainframe software alone appears to generate roughly three-quarters as much gross margin as the entire Infrastructure segment, on about half the revenue. Add IBM Financing, which finances the machines themselves, and the consulting work that lives off modernizing them, and the mainframe's weight in profit runs well ahead of its weight in revenue.
That business is also violently cyclical, because mainframes sell by generation. IBM Z revenue grew 51.7% across 2025—48.4% at constant currency—on the strength of the z17, launched that June, and 67% in the fourth quarter alone. Two quarters later it fell 42%. IBM's CFO attributed the drop to purchase timing rather than abandonment, and produced the number that supports him: the first five quarters of the z17 cycle run nearly 30% ahead of the z16, itself the strongest program in the company's history. Those are two different rulers—year-on-year change measures the quarter, program-to-program measures the cycle—and for a business that sells by generation the second seems the more honest, though IBM has an obvious interest in defending that reading.
Meanwhile the installed base is healthy and growing inward—more capacity at the customers already there, not new customers. According to IBM, 85% of z16 customers maintained or expanded capacity and around 70% of mainframe customers are growing their installed capacity (measured in MIPS). What none of those figures describes is the arrival of new kinds of workload. And that is exactly where the missing binary stops being an engineering nuisance and becomes a leak: a team needs an observability agent, discovers there is no build for s390x (the mainframe architecture), and deploys that piece somewhere else. Then the next one. In five years half the application lives elsewhere.
Read that way, ARM on the mainframe works as a defensive move more than a hunt for new customers: it removes the reason those pieces leave, by going to where the binaries already are instead of persuading thousands of vendors to compile for s390x.
Which also explains the choice of architecture, and the most obvious candidate is, surprisingly, the one left out.
The option that looked ideal
The technically easiest second architecture for IBM is not ARM: it is Power. IBM owns both ISAs, pays nobody a licence for either, and shares much of the design team and physical library between them.
IBM has not explained why it did not go that way, and the reasons—what they say about the mainframe business and the Power ecosystem—deserve an instalment of their own. They are Part III of this series. Here it is enough to note the fact: with the easier architecture in the house, IBM chose the one from outside.
Why not x86?
IBM has not said that it evaluated x86 and rejected it; the public record is enough to see why x86 is another story.
The public facts still explain why x86 is a different proposition. Its implementation rights have historically depended on specific corporate licences, patent cross-licences and commercial relationships. AMD's 2026 Form 10-K, for example, incorporates the AMD–Intel cross-licence by reference. That is evidence of a bilateral legal relationship, not of an open architecture-licensing model available to any implementer.
A useful, modern x86-64 environment would also inherit an enormous compatibility contract. IBM could implement a subset, but the software worth importing might be precisely the software that probes for missing features.
x86 applications could still arrive selectively through QEMU or another translator inside an ARM Linux VM. Windows on ARM already does something similar with Prism, although Microsoft has announced no Windows-on-ARM product for IBM Z. That might suit a utility. It would not be native x86 support.
Why not RISC-V?
RISC-V is the more interesting open-architecture question. RVA23 defines a stronger application baseline, and RISC-V International has ratified a server-platform specification covering firmware, UEFI, ACPI, interrupts, management and security. Which proves the same point again: even an open ISA needs a platform contract before ordinary server software can rely on it.
RISC-V may well become a compelling enterprise target. But IBM's stated objective is access to a catalogue that already exists, and in 2026 that catalogue is ARM's. Openness and breadth are different advantages, and only one of them delivers binaries this decade.
What IBM still needs to explain
The announcement deserves enthusiasm. It also deserves questions aimed at what remains unknown, rather than at what the public record has already answered.
ARM execution on a thread
Already public
IBM says Z and ARM run concurrently; coverage says a thread can use either ISA
Still worth asking
Can sibling threads on the same core run different ISAs under every supported policy, and how are they placed, isolated and billed?
The KVM path on s390
Already public
The public v6 kvm-arm64 series proposes VM/vCPU creation, memory handling and SAE entry
Still worth asking
What completes the firmware, virtual devices, migration, QEMU/libvirt and orchestration?
ARM CPU profile
Already public
Coverage describes AArch64 v9.3, SVE/SVE2 and feature discovery
Still worth asking
Which guest-visible profile stays stable across machines and generations?
Shared machinery
Already public
Prediction, arithmetic, load/store, caches and TLB structures are substantially reused
Still worth asking
How are security domains isolated, and how do mixed workloads get predictable service?
Coexistence with LPARs (logical partitions)
Already public
Nothing public
Still worth asking
How do ARM guests sit alongside the partitioning a customer already uses (PR/SM, z/VM)?
Drivers and firmware
Already public
Nothing public beyond the kernel series
Still worth asking
Who writes and maintains the ARM guest's device model, and for how long?
Production support
Already public
The stated target is ARM-native Linux
Still worth asking
Which distributions, versions, images, ISVs and accelerators are supported?
The last three are the ones history says will decide the outcome. Pattern 4 is why the drivers question matters; pattern 6 is why the support matrix matters more than any benchmark.
The KVM path explains the thread-level mechanism
The tempting question—"can sibling threads on the same core (SMT) run different ISAs?"—is already answered in principle. A userspace virtual-machine monitor creates a VM and its vCPUs through the KVM API; KVM holds each vCPU's ARM state; Linux schedules the host thread driving that vCPU onto a logical CPU; and SAE enters the ARM guest context there. KVM keeps a VM decoupled from any single SMT thread: it provides vCPU contexts that Linux schedules independently.
What the series does not settle is policy. Will IBM always permit different ISAs on sibling threads of the same core, or recommend same-ISA pairing for certain security or performance profiles? How will affinity, entitlement, metering and capacity reporting work across LPARs? What happens to service levels when two unlike workloads share one core?
SAE is not a new idea. It is the mainframe's oldest one
For readers who know z/Architecture, the shape of SAE will look familiar. It is worth pausing on why.
Since the mid-1980s, the mainframe has entered guest execution through one instruction: SIE, Start Interpretive Execution. The host builds a control block called a state description, executes SIE pointing at it, and the processor runs guest instructions and interruptions directly until something arises that requires the host. Then it exits, and control returns. SIE was created to virtualize System/370 and 370-XA, extended through ESA/390, and still sits underneath PR/SM and z/VM. IBM published the architecture as Interpretive Execution (SA22-7095) and described it in the IBM Systems Journal.
SAE follows exactly that shape. It receives the address of a control block, enters accelerated ARM execution, and returns control to the s390 host on exit so that KVM and the virtual-machine monitor can handle the event.
IBM has not described SAE as a descendant of SIE, and the public series does not use that framing. But the resemblance is not decoration. It suggests IBM is extending the most heavily exercised virtualization mechanism it owns to a second architecture, rather than opening a new doorway into guest execution. For a platform whose entire value proposition is that it does not surprise anyone, that is a better sign than a novel design would be.
Shared machinery is the efficiency, and the verification boundary
The design points to substantial reuse of prediction, cache, TLB and execution units, though no final specification is public. The questions that follow are concrete: how, when the architecture changes, the internal tables and caches that speed up the CPU (TLB, prefetchers, branch predictors) get cleared, so that one workload cannot spy on the one beside it through the traces it leaves in that shared hardware (a side-channel attack); how performance counters, tracing and debug are measured; and whether placing unlike ISAs on sibling threads worsens that risk. Most of the design's efficiency comes from that sharing, which is exactly why it needs an explicit answer.
The same goes for the accelerators. IBM says ARM workloads can reach the AI, compression, cryptography, sorting and DPU features; what matters is which of them ship, through what guest-visible interface, with which drivers and with what recovery guarantees. And the benchmark that counts measures whether acceptable ARM performance creates system-level value that a separate ARM server cannot, rather than whether IBM's ARM beats Graviton on a generic test.
Then, a support matrix. Binary execution is a technical property; production support is a commercial agreement.
The clues IBM left before the announcement
Press releases describe intent. Development infrastructure eventually describes the machine.
OSINT—open-source intelligence—means drawing careful conclusions from public evidence. Here, the most useful evidence did not appear under the product's name. The first public arm-on-s390 KVM series arrived on April 2, the same day as IBM and ARM's collaboration announcement. Steffen Eiden of IBM posted it under a subject line no marketing department would have chosen—"KVM: s390: Introduce arm64 KVM"—and by August 12 it had reached v6 with 33 patches. The series was followed publicly from its first revision to the second that same month, and was recorded independently. That is the corroboration a claim like this needs.
The trail was open from April. What did not yet exist was the name to search for.
The latest public proposal before the August 24 announcementAugust 12 · 33 patches
This chronology proves that a named public development effort existed. It does not prove that the patches were merged, production-ready or identical to the eventual product. A patch series is a proposal under review that still has to prove itself.
What the 33 patches reveal
The v6 cover letter describes two KVM implementations coexisting on s390 and introduces a second module named kvm-arm64. The series covers ARM VM and vCPU creation and destruction, control calls (ioctls) for the vCPUs, guest-memory management, page-fault handling, selective reuse of existing ARM KVM code, ARM feature discovery and host/guest register-state handling. It also moves arm64 headers to architecture-independent paths and creates shared code under virt/kvm/arm64/: the kind of refactoring that only makes sense if a second consumer is coming.
That is the plumbing needed to create, run and stop an ARM VM. The patches also expose unfinished work: some register handling and related functions are deferred to later series.
A targeted public search on August 27 found no arm-on-s390 series clearly attributable to IBM for QEMU, libvirt or EDK II. That negative result must stay narrow: it says the public kernel backend is visible while the full public userspace and firmware stack is not yet. It does not prove those layers do not exist privately.
The OSINT lesson is reusable
Searching only for "IBM dual-ISA processor" before August 24 would probably have missed the trail. The productive terms were arm-on-s390, KVM_ARM64, kvm-arm64, Start ARM Execution and SAE.
Engineers name a mechanism long before marketing names a product. Search patches for interfaces, configuration symbols, instructions, control structures, device identifiers and machine types. Then verify authorship, dates, revision history and review replies. Corroborate every finding across two independent sources. An unexplained string points to a lead without yet drawing a roadmap.
Watch three places from here: the KVM and linux-s390 archives for later revisions or merge activity, QEMU and libvirt for a machine type and a migration stream, and EDK II plus ARM SystemReady for firmware and compliance evidence.
A kernel ABI, plus a VMM device model, plus firmware, plus a published compliance result, begins to look like a platform. Until then, what exists is still a construction site on its way to becoming a product.
What this could change, and what it cannot
In the Power and AIX estates we work on, the call almost never starts with the processor. It starts with a deployment that has stopped, and the answer is almost always four layers above the silicon: a package that was never built, a security agent whose vendor supports two architectures and has no plans for a third. The software is one step from existing for that architecture—the kernel, the compiler and the source already support it—and the one missing step is precisely that: someone publishing the binary and committing to maintain it. That is the problem ARM on Z is aiming at, and it is worth marking off how much of it a processor can reach.
The software industry treats architecture support as a secondary detail of the publishing process. amd64 and arm64 appear automatically; s390x and ppc64le (the Power architecture) wait for someone to enable a build, fix a test or add an image manifest. IBM cannot personally port and certify every project, and by adding ARM it gains access to software that vendors already build—which is pragmatic and, with the figures above in view, is also the only lever available on the platform's one real growth constraint.
What it does not do is settle the rest. The virtual platform, operating-system support, the security model and commercial commitments still decide whether a customer can depend on the result. What it does achieve is putting that software next to Z's data without standing up another infrastructure island: a real gain, and rather more modest than "the mainframe now runs the ARM ecosystem", which is how this week has told it.
What is worth noting is where a real workload actually stops: at the instruction set, at the ABI, at the platform, or at the missing package and the support statement nobody is going to sign. Those specific failures, more than the benchmarks, will say whether ARM on Z removes the reason workloads leave.
The question that remains: what about Power?
Power users know this problem first-hand: the architecture is supported top to bottom and, even so, the vendor never publishes the binary.
If a second ISA turns out to be a good idea on Z, it is hard not to ask the same about Power. Asking it seriously—with the history and the numbers on the table—is the job of Part III. First, in a few weeks, comes Part II: the announcement dissected from the public kernel trail.
12
days between the last public patch and the day the product got a name.
A trail open since April
Continues next week
IBM showed its hand months early
Before the official press release, IBM was already pushing the map of what it meant to sell into Linux—in the open, signed with a name. In Part II we reconstruct it patch by patch: what SAE is, why its shape betrays thirty years of lineage, and what can be claimed (and what cannot) about the product from what IBM left public.
If any of this sounds familiar—the package nobody compiles for your architecture, the security agent that supports two platforms and not yours, the deployment stuck four layers above the processor—that is exactly the fourth contract this article is about. And it is where we spend our days: Power, AIX, IBM i and Linux on IBM systems. Tell us about it and we will take a look.
Local LLMs: why companies are building their own AI servers.
Two in three organisations have pulled AI workloads out of the public cloud in the past year. What holds them back is not budget. It is having to document where the data travels before they can switch anything on.
7 min read●Trend●
For years the default answer was "in the cloud". OpenAI, Azure, Bedrock. You pay per token, forget about hardware, it scales on its own. That reasoning has broken in a place nobody had on the spreadsheet: 95% of companies have delayed or cancelled an AI project over data governance, compliance or regulation. Not budget, not talent: knowing what data you hold, where it comes from and who is allowed to touch it.
66%
Have moved AI workloads off the public cloud
95%
Have stalled a project over data governance
+53%
Global spend on AI infrastructure
The first two figures come from The Great AI Re-Architecture, a Cloudera survey run by Wakefield Research among 1,500 architects at companies with over 1,000 employees, published on 11 August 2026. The spending figure is IDC's 2026 forecast: 487 billion dollars on AI infrastructure.
Why now
Legal has learnt to ask
"Where do the American providers process my data?" is the question nobody wanted to ask and everybody now asks, usually the week before an audit.
The underlying problem is not the provider, it is the journey. Moving personal data out of the European Economic Area means holding up the file for an international transfer: assessing the destination country, documenting safeguards, informing the data subject. Processing in your own data centre saves you that file. Mind you, it does not save you the rest of the GDPR, and if the provider of your European hall is a subsidiary of a US parent, the conversation about data access is still open.
The cloud bill does not warn you, it arrives
Paying per token looked cheap until somebody looked at the first month with the pilot already in production. A server has a fixed cost, so past a certain inference volume the maths turns around. Nobody knows in advance where that point sits: it depends on your volume, your model and whether the machine does anything else the rest of the day. Worth working out before you buy, not after.
To be clear, because this industry leans towards absolutes: this does not mean everybody is leaving the cloud. The same survey records organisations that will spend more on cloud and organisations that will spend more on-premise, at the same time. What is dying is the one-size answer.
Latency: you remove the journey, not the thinking
Worth being precise here, because two things get mixed up. Running locally does not make the model reason any faster; it removes the round trip to a data centre that may sit on another continent. If the AI is embedded in a process that is already slow, that journey is the only thing you can cut without touching the model. If your problem is that the model takes its time thinking, moving the machine will not save you.
You no longer need the biggest model
Llama, Mistral, Qwen and Phi publish small versions precisely for this, and for an internal chatbot, classifying documents or summarising minutes, those versions do the job. What is taking hold is the split: the small model takes the bulk of the requests and only the awkward ones escalate to a large one.
What hardware you need
Memory is what rules, and it comes from the model format itself. Quantised to 4 bits it takes around half a gigabyte per billion parameters; in FP16, about two gigabytes. Add the context, which grows with conversation length, and you have your floor.
Model
Weights (4-bit)
Recommended total RAM
What it is for
7B
~4 GB
16 GB on CPU
Internal chatbot, classification, summarising
13B
~8 GB
32 GB on CPU, or a consumer GPU
The above with more nuance and longer context
34B
~20 GB
24 GB VRAM
Reasoning, code, document analysis
70B
~40 GB
48 GB VRAM or several cards
Whatever a small model cannot solve
The weights come from multiplying parameters by bits. The recommended RAM is higher because it also has to hold the context, the operating system and enough headroom that the server is not running at its limit. And it still does not account for how many concurrent requests you will serve, which is the part almost nobody works out.
And there is the expensive mistake. We have seen a data centre card bought to run a model that summarises meeting minutes: it works, in the same way a lorry works for fetching the bread. Model size tells you whether it fits in the machine. Concurrent requests tell you whether it runs.
What usually gets miscalculated
The same machine that serves a 7B comfortably to three users crawls with thirty, because what saturates is memory bandwidth, not cores. If you are going to size for one thing, size for peak concurrency. The demo with one user always goes well.
Of the remaining parts, the most underestimated is storage. The weights load into memory in full at start-up, so a slow disk is paid for on every restart and every model swap. If you are going to handle several models or large datasets, that is where a lone NVMe stops being enough and a distributed system comes in: we compared them in Storage Scale versus Ceph for inference.
For the weights, half a gigabyte per billion parameters if it is quantised to 4 bits. The rule of thumb is to ask for double what they take: a 7B runs comfortably on 16 GB and a 13B on 32 GB. That difference is the context, the operating system and the headroom that keeps the machine off its limit, which is where the surprises start.
Do I need a GPU to run AI locally?
Not always, but let us be clear about what that means. Up to 13 billion parameters runs on CPU with enough memory, and it is fine for batch processes, overnight jobs or a handful of users. In a chat with people waiting in front of a screen, the CPU shows. A GPU stops being optional when concurrent requests or model size go up. We measured it without a graphics card on vLLM on IBM Power.
Is your own server cheaper than paying per token?
Past a certain volume, yes: the server has a fixed cost and the API grows with usage. Exactly where that point sits depends on the model, the volume and whether the machine does anything else the rest of the day. Below that volume, the API still wins.
Is it legal to process personal data with a cloud LLM?
It can be, but it requires a legal basis, an impact assessment and safeguards on international transfers when the provider processes outside the European Economic Area. Processing at home saves you that file, not the rest of the GDPR. And if the provider of your European hall is a subsidiary of a US parent, the conversation about data access is still open.
Which models can run on a business server?
The open families — Llama, Mistral, Qwen, Gemma, Phi — publish versions in several sizes precisely for this. For internal chatbots, document classification or summarising, the small ones do the job without specialised hardware.
Before looking at catalogues you have to size it, and that is three questions: which model you will run, how many concurrent requests, and what response time works for you. Memory, CPU, GPU and storage follow from that, in that order and no other.
That is what we built a server configurator for: you pick the use case, the scale and your priorities, and watch the machine take shape in front of you. No part numbers and no imposed brand. When you finish we call you with a firm proposal.
And if your own team is going to build and run it, we have a three-day local LLM course: choosing the model, serving it with vLLM and measuring what it can handle before buying the server.
Configure it yourself
How much server does your LLM need?
Pick the use case, the scale and your priorities, and watch the machine take shape. No commitment and no endless forms.
AI Act 2 August: what actually applies (and what slid to 2027).
For months, 2 August was "high-risk day". Not anymore: the Digital Omnibus pushed that to December 2027. But it left Article 50 intact — the one that forces your chatbots to identify themselves, your AI-generated content to carry a machine-readable mark, and your deepfakes to be labelled. If your product talks, writes or draws, it's time to land the technical side with EU AI Act compliance consulting.
8 min read●AI Compliance●
Regulation (EU) 2024/1689 — the AI Act — had its schedule moved a month ago and most of the market has yet to notice. The Digital Omnibus, approved by the Council of the European Union on 29 June 2026, pushed the Annex III high-risk obligations from 2 August 2026 to 2 December 2027. But Article 50 — transparency — kept its original date. In EU AI Act consulting we have been preparing this technical side since spring with clients who saw it coming.
The three dates that matter
2 Aug 2026Applies now
Article 50 · Transparency. Chatbots must identify themselves, AI-generated content must be marked machine-readable, deepfakes must be labelled. Fines up to €15M or 3% of global annual turnover.
2 Dec 2026This autumn
Article 5 · New prohibition. AI systems generating non-consensual intimate imagery are banned. Applies to every operator, regardless of the system's risk level.
2 Dec 2027+16 months
Annex III · High risk. HR, credit, biometrics, education, essential services. Deferred from 2 August 2026 by the Digital Omnibus.
01 · Context
What was supposed to happen on 2 August
Until 29 June, the AI Act calendar was known and boring: 2 August 2026 was the day the obligations for the systems under Annex III kicked in — biometrics, HR, credit decisions, formal education, critical infrastructure, law enforcement and essential services.
That meant, for any operator with a system classified as high risk, wiring up in production a nontrivial pile of things: risk management, data quality and bias governance, technical documentation, automatic event logging, user-facing transparency, effective human oversight, accuracy and cybersecurity, and post-market monitoring. All with technical evidence sitting on your own code and your own infrastructure.
None of that applies in August anymore. But part of what was expected — Article 50 — is still exactly on its original date.
02 · Digital Omnibus
What changed on 29 June
The Digital Omnibus is the digital simplification package that the Council of the European Union approved on 29 June 2026. It is an amendment to the AI Act itself. Its declared aim: ease the applicability calendar in the face of clear evidence that neither companies nor competent national authorities were going to arrive in August with the technical and supervisory structures ready.
The most visible measure: the Annex III high-risk obligations, originally due to enter into force on 2 August 2026, are deferred to 2 December 2027. Sixteen more months.
Not an amnesty
It's a deferral, not an exemption. Neither the substance of the regulation nor its obligations change. What changes is when they are enforceable. If your system classifies as Annex III high risk, the technical work is the same — you just have sixteen more months to make it presentable. That margin evaporates quickly once you open the code base.
What did not change with the Digital Omnibus matters just as much: Article 50 transparency keeps its original date. And the new Article 5 prohibition on non-consensual intimate imagery also stays on schedule, for 2 December 2026.
03 · Article 50
The three things that do come into force
Article 50 of Regulation (EU) 2024/1689 imposes transparency obligations on providers and operators (deployers) of AI systems — regardless of whether the system is high risk or not. Three blocks. Specific ones.
50 · 1
Chatbot identifies itself
AI systems designed to interact with people must inform the user that they are talking to an AI, unless it is obvious from context. Applies to customer support chatbots, conversational assistants, IVR with synthetic voice and in-app agents. UI translation: a clear opening message, not a footnote in the footer.
50 · 2
Marking of generated content
Providers of generative AI (text, image, audio, video) must mark their outputs in a machine-readable format so that they can be detected as artificially generated or manipulated. The obligation sits on the model provider, not on the end user asking for an image.
50 · 4
Labelled deepfakes
Deployers using AI to create deepfakes (image, audio or video that falsely resembles a real person, object or event) must label the content as artificially generated or manipulated. There are narrow exceptions for artistic, satirical or law enforcement use — not a blank cheque.
Extraterritorial scope
Article 50 applies to any AI system placed on the market or put into service inside the EU, regardless of when it was placed on the market or whether the provider is established in the EU. A model trained in California and offered via SaaS to European customers is in scope. Living outside the EU does not spare you the fine if your outputs reach us.
04 · Penalties
How much ignoring it costs
The AI Act orders penalties into three tiers (Article 99). Worth not mixing them because the big headline number circulates a lot.
€35M · 7%
Prohibited practices (Article 5)
€15M · 3%
Article 50 and other infringements
€7.5M · 1%
Incorrect information to the authority
Article 50 infringements fall in the second tier: up to €15 million or 3% of the previous financial year's global annual turnover — whichever is higher. Supervision and sanctions are run by the national competent authority in each member state; the specific body (and its readiness) varies country by country.
05 · Quick check
Does Article 50 apply to you?
Three short questions and you will know whether you have work ahead or you can breathe until high-risk hits in 2027.
Three-click check
No telemetry, no cookies, nothing sent anywhere. Everything runs in the browser.
1. Does your product have a chatbot, conversational assistant or IVR with synthetic voice that talks to real people?
2. Does your product generate text, images, audio or video with AI that end users see or download?
3. Does your product create or distribute deepfakes — image, audio or video that resembles a real person, object or place?
Article 50 does apply — and on several fronts.
With two or three blocks ticked, you have obligations around chatbot disclosure, content watermarking and/or deepfake labelling. It's the densest scenario: UI to touch, generation pipeline to touch, auditable logs to leave behind. With focus and priority, a week is enough to land the minimum starting with what's most visible to the user.
You have a clear obligation. If the yes was the chatbot, the heavy lifting is UX: a clear opening message plus a log. If it was content generation, the heavy lifting is technical: C2PA + watermark + logging. If it was deepfakes, the heavy lifting is process: systematic labelling in the publication pipeline.
No chatbot, no user-facing AI-generated content and no deepfakes — this block does not apply. But careful: if your AI falls under Annex III (biometrics, HR, credit, education, critical infrastructure, essential services) you have a date with the high-risk obligations on 2 December 2027. And that, when you get into it, is much more work than a chatbot notice.
Obligation 50(2) — marking AI-generated content in machine-readable format — sounds like a label problem. It isn't. The regulation asks for four properties at once that no known technology satisfies together: imperceptibility (don't degrade the content), robustness (survive compression, editing, screenshots), detectability (verifiable downstream) and traceability (identify generator and version).
The practical approach that serious providers are adopting is layered. Three layers, each covering the failure modes of the previous one.
Layer 1
C2PA metadata
Content provenance standard driven by Adobe, Microsoft, Sony and others. Cryptographically signs metadata that travel with the file: who generated it, with which model, when. Survives compression. Disappears with screenshots or re-encoding without signing — i.e. with almost any social post.
Layer 2
Imperceptible watermark
SynthID (Google DeepMind) for images and audio, similar techniques for text and video. Modifies the output imperceptibly so a detector can recognise it. Survives screenshots, but degrades under aggressive manipulation, heavy cropping or source mixing.
Layer 3
Generator-side logging
Audited log on the provider side: what was generated, when, with which prompt, model and version. The most boring, the most important, and the one that lets you respond to a request even after layers 1 and 2 have evaporated along the way.
SIXE angle
Layer 3 — generator-side logging — is where running AI on-premise becomes a real advantage rather than a marketing line. On your own inference stack you can log every prompt, every output, every model and every version without depending on a SaaS provider's audit trail that they show you when they feel like it. And in RAG with Docling, the traceability of which document fed which answer is part of the architecture by design.
07 · Checklist
The minimum to have in place
If the quiz said Article 50 applies to you, this is the checklist with the essentials. Tick what you already have. What remains unticked is your backlog — and what we build with clients in a kick-off consulting engagement.
Article 50 checklist · 7 items
0/7 done
"You're talking to an AI" notice on your chatbotsClear opening message, not a footnote in small print. Applies to voice assistants and synthetic IVR too.
Chatbot session logDate, system, model version, session ID. If the authority asks, you must be able to show that the disclosure went out.
C2PA on generated outputsCryptographically signed metadata on images, audio and video. Layer 1 of layered watermarking.
Imperceptible watermarkSynthID or equivalent for what C2PA loses when someone takes a screenshot and shares it on social media.
Generator-side loggingAuditable log of prompts, outputs, model and version on your side. Boring to implement, essential when it's time to demonstrate. On on-premise inference over Ceph, OpenStack or K8s it stays inside your perimeter.
Deepfake labelling in the pipelineIf you generate or distribute content that resembles real people, label it inside the publication flow itself. Don't leave it to the editor on duty. With safe AI agents labelling runs as policy, not as a reminder.
Internal conformity documentHalf a page explaining which obligations apply to which systems, who is accountable and where the logs live. This is where ISO 42001 chains naturally with the AI Act.
All seven ticked. If it's real and not vibes, your week is looking good. If any were missing, EU AI Act consulting starts from there.
08 · December 2026
The other date almost nobody is watching
Four months after the Article 50 deadline, on 2 December 2026, a new prohibition added by the Digital Omnibus to Article 5 takes effect: AI systems that generate non-consensual intimate imagery join the regulation's catalogue of prohibited practices.
Because it is a prohibition, it doesn't admit exceptions by size or by prior risk level of the system. It applies to every operator on the European market — providers, deployers, importers, distributors — no exception. No intermediate Annex, no additional grace period. Prohibited.
This hits products and services like generators of real-person imagery without consent, face-swap apps on intimate content and nudify tools that have proliferated in the last two years. General-purpose model providers are affected indirectly through foreseeable uses: if your model can be reasonably used for that, technical safeguards stop being optional.
09 · Architecture
Why on-premise makes the paperwork easier
None of the Article 50 obligations depend on where the AI runs — they apply to providers and deployers regardless of topology. But demonstrating compliance does depend. And that's where deploying on your own infrastructure plays in your favour for very practical reasons:
Generator-side logging (layer 3) lives in your system, with your retention policies, without third-party access agreements or SaaS dashboard export limits.
Technical documentation of the model — which if the risk tier climbs is demanded in detail — is under your control: weights, training data provenance, evaluations, version. Nothing depends on your cloud provider's goodwill.
Data governance is demonstrated on data that never left your perimeter. For healthcare, banking and public sector it is a de facto requirement — the AI Act just puts it in writing.
Auditable agents with OPA, LangChain or CrewAI fit naturally with the effective human oversight that high risk will require in 2027.
FAQ
Frequently asked questions
What comes into force under the AI Act on 2 August 2026?
The Article 50 transparency obligations. Chatbots must let users know they are talking to an AI; AI-generated content (text, image, audio, video) must be marked in a machine-readable format; deepfakes must be labelled as artificially generated or manipulated. Non-compliance is fined up to €15 million or 3% of global annual turnover, whichever is higher (Article 99.4).
Has enforcement for high-risk systems been delayed?
Yes. The Digital Omnibus, approved by the Council of the European Union on 29 June 2026, postponed the Annex III obligations (biometrics, HR, credit, education, critical infrastructure, law enforcement, essential services) from 2 August 2026 to 2 December 2027.
Article 50 has NOT been postponed and still applies on 2 August 2026.
What is the Digital Omnibus?
The digital simplification package approved by the Council of the European Union on 29 June 2026 that delays the applicability of several AI Act obligations and clarifies operational aspects of the regulation. Its most significant measure is deferring the Annex III high-risk obligations to 2 December 2027.
How much does breaching Article 50 cost?
Up to €15 million or 3% of the previous financial year's global annual turnover, whichever is higher (Article 99.4). It is the second tier of penalties. The first tier (€35M or 7%) is reserved for the prohibited practices under Article 5 — a separate matter.
How do you meet the machine-readable marking requirement?
With a three-layer approach: cryptographically signed C2PA metadata in the file; imperceptible watermark like SynthID for what C2PA loses on screenshots; and audited logging in the generator itself. No single layer covers the four requirements the regulation demands — imperceptibility, robustness, detectability and traceability.
What new prohibition comes into force on 2 December 2026?
Article 5 adds a new prohibition: AI systems that generate non-consensual intimate imagery. It applies to every operator regardless of the system's risk level.
Does the AI Act apply if my AI is on-premise?
Yes. The AI Act applies to any system placed on the market or put into service in the EU, regardless of where it is deployed or where the provider is established. Running AI on-premise does not exempt — but it makes the demonstrating side easier: logging, traceability and audit are yours, not a third party's.
Are AI Act, NIS2 and ISO 42001 the same thing?
No, but they support each other. NIS2 is the European cybersecurity directive — it forces you to manage risk and notify incidents. ISO/IEC 42001 is the international standard for AI management systems — a governance framework. The AI Act is European law with specific obligations by risk level. All three overlap in data governance, traceability and logging: doing one properly covers part of the next.
Technical compliance
Does your product talk, write or draw with AI?
We land which Article 50 obligations apply to your systems, review chatbots and generators, set up the inference pipeline with auditable logging and roll out layered watermarking. We handle the technical side; legal interpretation stays with your legal advisors.
Storage for AI and HPC in 2026: Ceph, Storage Scale, Lustre, DAOS and BeeGFS.
You build a GPU cluster that costs as much as a building, and then you decide where the data lives. That decision — the file system — is what determines whether your GPUs compute or wait. We map the five big options, what each is good for, and how not to get it wrong.
12 min read●Technical comparison●
There's a scene that repeats itself whenever we review an AI or HPC platform. The client proudly shows us the shiny new GPU cluster. Impressive TFLOPS figures. And then we ask the boring question: "and where do they read the data from?" Far too often, the answer is an NFS share bolted onto a box in the corner.
Buying eight GPUs that cost as much as a house and feeding them over NFS is the digital equivalent of putting a moped's fuel tank on a Formula 1 car: all the power is there, but it spends the day in the pits. Storage is what decides whether those GPUs work or wait — and getting it right starts with knowing what your options are and what each one is for.
1 & 2
DAOS positions on the IO500 production list (SC25)
×4
Their combined score vs. the next 30 systems
#1
Lustre, the most widely used FS in supercomputing
50+ PB
Ceph deployed at CERN
01 · The vocabulary that shapes the architecture
Four concepts before comparing anything
Distributed storage piles up jargon fast, and marketing labels don't always help. Before we get into it, it's worth pinning down four ideas — they're the ones that actually separate one system from another when it's time to choose.
Parallel POSIX vs. objectA parallel file system (paths, permissions, open()/read()) spreads each file across hundreds of servers that serve it at once: it's what classic HPC software expects. Object storage has no directories, just keys and objects over an S3 API: it's the language of data lakes and modern AI.
Bandwidth vs. IOPSClassic HPC wants sequential GB/s to dump huge checkpoints. AI training often wants the opposite: millions of tiny files read at random, where IOPS and metadata performance rule. Almost no system is king of both.
Metadata rulesThe metadata server (MDS) is what knows where everything lives. In AI workloads with millions of small files, it's usually the first bottleneck, before the disk. Plenty of migrations fail by sizing the disk well and forgetting the metadata.
GPUDirect StorageA direct path between storage and GPU memory, skipping the CPU and any intermediate RAM buffer. Lower latency, less CPU burned shuffling bytes, and GPUs that stop waiting. It's the piece modern AI demands from storage.
The distinction that matters
The best storage is the one that fits your dominant workload. If your day-to-day is simulations writing giant files, you want sequential bandwidth. If it's training models over millions of images, you want fast metadata and IOPS. Mixing the two up is the most expensive design mistake we see.
02 · The five contenders
Who plays in which league?
Here are the five systems that dominate serious storage for AI and HPC. There's no single winner: each has a sweet spot. The bars compare, roughly, two axes that are almost always in tension: the peak performance a system can reach and how easy it is to operate day to day.
Ceph
Unified · object + block + filePeak performance
Versatility / ops
The Swiss army knife
Storage Scale
Parallel POSIX · GPFS · IBMPeak performance
Support / ops
The enterprise workhorse
Lustre
Parallel POSIX · the TOP500 onePeak performance
Ease of operation
The HPC standard
DAOS
Object / KV on NVMePeak performance
Ease of operation
The IO500 rocket
BeeGFS
Parallel POSIX · easy to deployPeak performance
Ease of operation
The quick-deploy one
Indicative bars · the best system is the one that fits your workload, not the one with the longest bar
03 · The table you can show in a meeting
Five systems at a glance
The essentials of each one: what type of storage it is, where it shines, the license it ships under, and which version is in production as of mid-2026.
System
Type
Sweet spot
License
Version (2026)
Ceph
Unified
Hybrid AI + HPC platforms, private clouds, S3 data lakes. Object, block and file from a single cluster.
Open source LGPL
20.2.2 "Tentacle" (Jun 2026)
IBM Storage Scale
Parallel POSIX
Enterprise HPC with support and SLAs, AI on NVIDIA DGX BasePOD/SuperPOD, high performance out of the box.
Commercial IBM
5.2.x
Lustre
Parallel POSIX
Classic max-bandwidth supercomputing. The TOP500 standard when you have a team that knows how to run it.
Open source GPLv2
2.17 (Dec 2025)
DAOS
Object / KV
Extreme performance on pure NVMe. The fastest thing on the IO500, for workloads where latency is everything.
Open source BSD
2.6
BeeGFS
Parallel POSIX
Mid-to-large HPC clusters and research groups that want good performance without a dedicated storage team.
Community + Enterprise
8.3.x
04 · One by one
What each does well (and what it doesn't)
Ceph — the one that does almost everything
Ceph is the Swiss army knife of open source distributed storage: it serves object (S3 via RGW), block (RBD) and file (CephFS) from the same cluster, self-heals, and scales by adding nodes. For AI that means RBD for the training boxes, S3 for the data lake and CephFS for parallel access — with native OpenStack and Kubernetes integration. It isn't the peak-performance king in extreme HPC, but nothing matches its versatility, and deployments like CERN's 50+ PB prove it holds up at serious scale. Version 20.2.2 "Tentacle" (June 2026) brings Crimson for erasure-coded pools and RGW encryption improvements. It's also the natural winner of the gap MinIO left when it went into "maintenance mode" in late 2025. We dig into all of this in our guide to open source storage for AI and HPC. At SIXE we work with it daily: Ceph for AI & HPC and official Ceph training.
IBM Storage Scale (GPFS) — performance with an SLA
Once GPFS, then Spectrum Scale, and today IBM Storage Scale: the same workhorse with three names. It's a mature, POSIX parallel file system with enterprise support that, in version 5.2.x, integrates NVIDIA GPUDirect Storage and certification for DGX BasePOD/SuperPOD and Grace Blackwell platforms. It's the choice when you want the performance of a parallel FS but don't want to depend on your team being able to rebuild a Lustre at three in the morning: you pay for the license, you get the SLA. We build HPC infrastructure with Storage Scale + Spectrum LSF/SLURM and run Storage Scale administration training.
Lustre — the TOP500 standard
Lustre is still, by a wide margin, the most widely used file system in supercomputing: it moves a huge share of the world's largest compute centres. It delivers extremely high sequential bandwidth and scales to exabytes. The price is operations: it's not "install and forget", and it takes real expertise to tune and recover. Version 2.17 (December 2025) continues that line, with 2.18 preparing file-level erasure coding (FLR-EC) and client-side compression. If you're coming from Lustre and want commercial support, we've written about migrating from Lustre to IBM Storage Scale.
DAOS — the rocket that came back
DAOS is the answer to "what if we throw POSIX out and design for NVMe from scratch?" The result: it holds positions 1 and 2 on the IO500 production list (Argonne and LRZ, SC25), and 16 of the top 30 in the full ranking run DAOS. It was born tied to Intel's Optane memory; when Intel killed Optane, many wrote DAOS off too. But since version 2.6 (July 2024) it runs on plain NVMe SSDs and is very much alive. It's now governed by the DAOS Foundation under the Linux Foundation (Argonne, HPE, Google Cloud, Intel), after Intel handed its team to HPE in 2024. It's the top-performance option for anyone with pure NVMe and a workload that justifies it — not a general replacement.
BeeGFS — the easy one to live with
BeeGFS is the parallel FS that prioritises being deployable on a Tuesday afternoon without a PhD in storage. It delivers very good performance for mid-sized clusters and is a favourite of many research groups for its simplicity. Watch out for one important change: since BeeGFS 8 the Community Edition is still free but requires generating a community license (beegfs license), and enterprise features sit behind a paid license. The stable release in 2026 is 8.3.x.
The recurring pattern
Notice the tension: Lustre and DAOS deliver top performance but demand an expert team. Storage Scale buys that performance with a license and support. Ceph and BeeGFS give up a little peak in exchange for an easier life. No option is free: each one trades performance for simplicity, or license cost for support.
05 · The axis that really decides
Is your workload classic HPC or AI?
Before you look at brands, look at your workload. The question that orders the decision isn't "which is best?" — it's what you're going to ask of the storage. Here are the two profiles and what each one needs.
Before looking at products, measure. Do you write a few giant files or read millions of small ones? Is bandwidth or metadata the bottleneck? That single answer already rules out half the options. And don't just plan for today: size for the workload you'll have once the AI project grows.
2
Decide: open source with a team, or support with an SLA
Lustre and DAOS are free to license but expensive to operate: you need people who know them. Storage Scale flips that equation: you pay for the license and buy peace of mind. Ceph and BeeGFS sit in between. The honest question is: do you have — or want to have — a storage team?
3
Look at the ecosystem you already run
Already running OpenStack or Kubernetes? Ceph fits like a glove. Have NVIDIA DGX / BasePOD? Storage Scale is certified. Pure NVMe and thirsty for latency? DAOS. The best storage is usually the one that creates the least friction with what's already in production.
4
Test at scale before you commit
A four-node benchmark won't predict how forty nodes behave. Test with your real workload, not the datasheet's synthetic one, and watch the metadata under concurrency. Experience here saves months — and a six-figure wrong purchase.
Where SIXE comes in
Designing the storage layer of an AI or HPC platform, comparing Ceph, Storage Scale, Lustre, DAOS or BeeGFS for your case, or migrating from one to another without losing data or sleep — at SIXE we've spent more than 15 years at the crossroads of distributed storage, IBM Power and open source. See Ceph support and IBM Storage.
Summary
The essentials in 5 points
To take away from this post
→ Storage decides whether your GPUs work or wait. It's as strategic as the compute cluster itself.
→ There's no "best": there's the best for your workload. Classic HPC wants bandwidth; AI wants metadata, IOPS and GPUDirect.
→ DAOS leads on performance (1st and 2nd on the IO500), Lustre on prevalence, Storage Scale on enterprise support.
→ Ceph is the versatile choice for hybrid AI + HPC architectures; BeeGFS, the easiest to deploy.
→ Before choosing: define the workload, decide open source vs. SLA, look at your ecosystem, and test at real scale.
FAQ
Frequently asked questions
What is better for AI, Ceph or Lustre?
It depends on the workload. Lustre delivers more sequential bandwidth and is the standard in classic supercomputing, but it takes real expertise to operate. Ceph is more versatile: it serves object (S3), block and file at once, integrates with OpenStack and Kubernetes, and its object storage fits AI data lakes. For large-scale training with huge checkpoints, choose Lustre or Storage Scale; for hybrid platforms and data lakes, Ceph.
Is DAOS ready for production?
Yes, in its niche. It holds positions 1 and 2 on the IO500 production list (SC25) and is governed by the DAOS Foundation under the Linux Foundation. Since version 2.6 (July 2024) it runs on plain NVMe SSDs, without Optane. It's the top-performance option, but it needs NVMe hardware and a skilled team; it's not a general replacement for Lustre or Ceph.
Is Storage Scale the same as GPFS or Spectrum Scale?
Yes. It's the same IBM product under different names: GPFS, then IBM Spectrum Scale, and today IBM Storage Scale. In 2026 it's on 5.2.x and supports NVIDIA GPUDirect Storage and DGX BasePOD/SuperPOD certification.
Is BeeGFS still free?
The Community Edition is still free, but since BeeGFS 8 you have to generate a community license with beegfs license. Enterprise features sit behind a paid license. The stable release in 2026 is 8.3.x.
Can you use Ceph for serious HPC?
Ceph appears on the IO500 production list and there are massive deployments (CERN runs over 50 PB), but for extreme-performance HPC it usually doesn't replace Lustre, Storage Scale or DAOS. Its strength is hybrid HPC + AI architectures: object, block and file from a single cluster, integrated with OpenStack and Kubernetes.
AI / HPC storage · Open Source
Do your GPUs compute or wait?
Tell us what workload you're moving, how many GPUs, and what you run today. We'll get back to you within 24 hours with a storage architecture sketch and a realistic idea of effort. If Ceph fits, we'll tell you. If yours is Lustre, Storage Scale or DAOS, we'll tell you that too.
IBM QRadar makes G2 Leader in four categories at once.
SIEM, UEBA, Network Traffic Analysis and Incident Response. We walk through what each category actually measures, what it means for a real SOC, and which QRadar 7.6 courses we have on the shelf — so the badge doesn't just end up living on a slide deck.
8 min read●Technical analysis●
On 10 July, IBM announced that QRadar SIEM has again been named a G2 Grid Leader in four categories: SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) and Incident Response. The official post is short — it tells you about the medals and moves on.
We'll take them one at a time. What G2 actually measures in each of the four, what it means for a SOC that has to run them day to day, and which version of QRadar our training covers (all three courses are on 7.6, the current release).
01
The four G2 wins, one at a time
G2 scores software from verified reviews left by people running it in production. Being a Leader in all four categories at once is a specific signal: these are four capabilities that used to come as separate products, and here they live inside the same platform.
Category 01SIEM
Security Information and Event Management. Collects logs from systems, network, applications and cloud, normalises them, correlates them and detects patterns that point at incidents.
QRadar's home turf. Banks, telcos and government have been running it here for more than a decade. The surprise isn't this one — it's that QRadar also comes out on top in the other three.
Category 02UEBA
User and Entity Behavior Analytics. Analyses the behaviour of users and assets, builds a baseline of "what normal looks like" and raises an alarm when something drifts off it.
This is what spots a user who's never moved more than 200 MB suddenly pulling down 300 GB at three in the morning. It used to require a separate UEBA product; in QRadar it ships as an integrated app.
Category 03NTA · Network Traffic Analysis
Network traffic analysis. Looks at flows (NetFlow, IPFIX and equivalents) to detect lateral movement, exfiltration or command-and-control chatter that doesn't show up in logs.
The QRadar Network Insights module. Logs tell you what happened on the boxes; NetFlow tells you what went over the wires. Skip the second half and you're watching half the film. Particularly useful for teams who had NetFlow analysis living in a separate console.
Category 04Incident Response
Response to incidents. Detection is half the job. The other half is orchestrating the response: playbooks, tickets, containment and coordinated comms between teams.
This is QRadar SOAR (formerly Resilient), which ranks as a G2 Leader in its own right, separate from the SIEM. It's the piece gaining the most weight in Europe since NIS2 started requiring incident notification within 24 hours — a window that gets tight quickly if your playbook lives on a Post-it note.
02
What a G2 Leader ranking actually certifies
G2 is, if you'll indulge the analogy, the TripAdvisor of enterprise software. And like TripAdvisor: if four hundred users all agree the paella was good, something's being done right. It still doesn't make it a Michelin guide.
Translated to QRadar: the reviews confirm that the people running it in production rate it well on satisfaction, integration ecosystem and ability to scale. What they don't confirm is that it's equivalent to a Gartner Magic Quadrant or a Forrester Wave, which are analyst assessments. Two different signals, both useful.
The same reviews also flag what the official post skips over: QRadar has a learning curve, initial tuning is demanding, and EPS/FPI licensing can grow faster than expected if the sizing isn't done properly. None of that is a product weakness — it's a familiar list of things we've seen up close, and all three tend to sort themselves out with training and planning.
03
Why the G2 wave lands at a useful moment
The European calendar has been busy. NIS2 has been in force since 2024 and 2026 is the year of inspections and enforcement against essential and important entities. DORA requires financial firms to demonstrate ICT operational resilience, including the ability to detect, notify and respond to incidents within measurable timings. Either way, having a SIEM installed isn't enough: you need a tuned SIEM and a SOC that knows how to run it.
Which is where the G2 wins earn their keep: as a hint of what's worth learning. If those four categories are the ones users rate highest on satisfaction — SIEM, UEBA, network traffic and response — then training your team on QRadar covers all four layers in one go. One course, four capabilities: the sort of ratio that tends to survive a training budget review.
04
Three courses aligned to the latest QRadar (7.6)
The three SIXE IBM QRadar training courses are aligned to the latest product release, 7.6. They can be taken standalone or as a pathway. On-site or remote, delivered in English, Spanish or French, with proprietary material and labs on QRadar 7.6 — the real product, quirks and all.
Which G2 categories is IBM QRadar a Leader in for 2026?
Four critical security categories: SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) and Incident Response. Recognition is based on verified customer reviews and market presence, not on independent analyst evaluation.
Is a G2 Leader ranking equivalent to a Gartner Magic Quadrant?
No. G2 collects verified reviews from real users; Gartner and Forrester rely on their own analysts. They're different, complementary signals: a product that scores well on both is usually a safer bet than one that only stands out on one.
Which QRadar version do the SIXE courses cover?
All three courses (Fundamentals, Deployment & administration, Advanced operations) are aligned to IBM QRadar SIEM 7.6, the current product release. Labs run on real 7.6 environments.
Are the QRadar courses delivered on-site or remotely?
All three courses can be delivered on-site at the client's premises or remotely in a virtual classroom, in English, Spanish or French. They adapt to the client's schedule and to the team's level, from L1 analysts up to senior administrators.
IBM QRadar 7.6 training · On-site or remote
So — how do we get from headline to production?
Tell us how many people need training, what roles they cover (analyst, administrator, architect) and which version you're on. We'll come back with a tailored proposal — syllabus, format, dates and language — in less time than a proper tuning pass.
EDR beyond Windows: protecting Linux, AIX and IBM i.
We map how far today's leading EDR solutions actually reach across your estate — including the servers CrowdStrike and SentinelOne have no agent for. Where the radar reaches, where the blind spots are, and how to close them with open source.
11 min read●Technical analysis●
There's a conversation that comes up every time we review a client's detection strategy. They walk us through their coverage: Windows protected, Linux mostly there, macOS depending on the case. All reasonable. Then we ask: "What about the AIX servers? And the IBM i?" What usually follows is a brief silence.
It isn't an oversight. It's that most EDR solutions on the market — CrowdStrike, SentinelOne, Microsoft Defender — have no agent for AIX or IBM i. And in banking, insurance or logistics, those are precisely the systems running the organisation's most critical transactions.
44%
Of breaches involve ransomware
0
Leading EDR agents for AIX
10M+
Annual Wazuh downloads
24h
Alert deadline under NIS2
01 · Clearing up the acronyms
EDR, XDR, MDR: three letters that aren't the same thing
The industry stacks up acronyms fast, and the lines between products aren't always clear. Before we go further, it's worth pinning down what each one means — because the difference matters when it's time to protect a server that isn't Windows.
EDREndpoint Detection & ResponseDetects threats on endpoints by analysing behaviour, not signatures. It catches the malware that leaves no file behind — exactly what traditional antivirus never sees.
XDRExtended Detection & ResponseCorrelates telemetry from endpoints, network, identity, email and cloud to detect threats from a single platform. It extends visibility beyond the individual endpoint.
MDRManaged Detection & ResponseNot a technology — a service. Someone runs your EDR/XDR 24/7. It makes sense without an in-house SOC; less so if you already have a team but lack the tooling.
The distinction most people miss
Antivirus looks for known signatures: files that match a malware database. If an attack is new or leaves no file (fileless, living-off-the-land), it won't see it. EDR will — because it doesn't look at files, it looks at behaviour.
02 · The coverage map
How far does your EDR's radar actually reach?
Here's the exercise that rarely happens in a security review: mapping the real EDR coverage of the leading commercial solutions across every kind of system you run in production. Not the datasheet version — the real one.
Windows
x86_64
Full coverage
Linux x86
RHEL · Ubuntu · Debian
Full coverage
macOS
Apple Silicon · Intel
Partial coverage
Linux on Power
ppc64le
Partial coverage
AIX
IBM Power · Unix
Blind spot
IBM i
IBM Power · AS/400
Blind spot
Leading commercial EDR covers it Limited or vendor-dependent No agent available
The last two tiles are the problem. CrowdStrike has no agent for AIX or IBM i. Neither does SentinelOne. Neither does Microsoft Defender. It's a blind spot in the commercial EDR market that hits the sectors with the largest regulated attack surface — banking, insurance, healthcare, logistics — which happen to be the ones with the heaviest IBM Power footprint.
The angle few people look at
You're already paying for CrowdStrike, SentinelOne or Microsoft Defender. The problem isn't only a security one — it's that part of your most critical infrastructure sits outside that investment. You're paying for coverage that, by design, never reaches the systems running your transactions.
03 · The market
Consolidation, concentration and a quiet alternative
The EDR landscape has been reshaping itself for a couple of years now. And the most significant move didn't come from the products — it came from the mergers.
The enterprise leaderCrowdStrike remains the reference at the high end. The July 2024 incident brought a level of scrutiny that wasn't there before, but technically it's still among the best.
The native integrationMicrosoft Defender for Endpoint is gaining share on the back of its Microsoft 365 integration. For anyone already in that stack, the marginal cost is hard to beat.
The acquisitionsCisco bought Splunk (USD 28 billion). Palo Alto absorbed the SaaS side of QRadar. The message: detection and response are merging with the SIEM. They're no longer separate products — they're layers of the same platform.
The open-source alternativeMeanwhile, Wazuh has passed 10 million annual downloads and added local-LLM threat hunting — with no licensing cost.
04 · Wazuh as EDR/XDR
What works and what doesn't
Let's be specific, because this is a product we work with daily and we know both its strengths and its limits well. Wazuh is open source, lightweight and cross-platform — and, most relevant for this article, its agent runs in IBM i PASE environments and on AIX.
What it does well
File integrity monitoring (FIM) and rootkit detection
System log analysis and software/hardware inventory
CVE-based vulnerability detection and automated active response
Agents for Linux, Windows and macOS; deployable on PASE (IBM i) and with an agent for AIX
Local-LLM threat hunting since 2025, with no licensing cost
Where its limits are
No kernel-level protection like CrowdStrike or SentinelOne
No threat sandboxing
Functional console, with room to improve on usability
The 3,000+ default rules are a starting point, not a turnkey solution
Needs a team that knows how to configure and tune it
That last line is the important one. The difference between a Wazuh that generates noise and one that generates actionable intelligence lies in configuration, tuning and knowledge of the environment. For the full comparison with commercial alternatives, it's on our Wazuh page.
05 · Reducing the blind spot
Is there an EDR for IBM i and AIX?
It's the direct question, and the honest answer is: not in the catalogue of the big vendors, but yes — through open source. Back to the two red tiles on the map. If the commercial solutions don't reach AIX and IBM i, three pieces remain that complement each other.
Wazuh on PASE (IBM i) and AIX
Wazuh can be deployed in PASE environments on IBM i, letting you collect system telemetry and events that are then correlated in the central platform. For AIX there's a native agent. They don't match the coverage Wazuh offers on Windows, but they collect system logs, monitor file integrity and detect configuration changes. On IBM i, pairing Wazuh with collection of the QAUDJRN — the native audit journal — adds a layer of visibility most of these systems don't have today.
PowerSC for hardening and compliance
PowerSC is IBM's native tool for AIX and IBM i. It monitors file changes, checks configurations against CIS/STIG standards and generates compliance reports. It isn't an EDR in the strict sense, but it covers the change detection and configuration management that complement Wazuh. IBM itself positions PowerSC as an EDR solution for Power environments.
Open source for IBM Power
Beyond IBM's own tooling, there are open-source repositories maintained specifically for IBM Power that make it easier to deploy monitoring agents and automation tools on AIX and IBM i.
LibrePower: the open-source catalogue for IBM PowerIt maintains package repositories for AIX and IBM i with the dependencies needed to deploy monitoring agents, audit scripts and automation tools. With AWX and Ansible, you deploy and configure those agents across fleets of Power servers just as you would on Linux.› AIX catalogue› IBM i catalogue› AWX / Ansible
The piece the auditor wants to see
Wazuh + PowerSC + Ansible across IBM Power isn't an off-the-shelf EDR. But it provides visibility over systems the commercial EDR platforms don't cover, and it produces evidence aligned with the monitoring, traceability and detection requirements set out in NIS2.
06 · Where to start
Three steps if you only protect Windows
1
Audit your real coverage
Inventory every endpoint — not just the ones IT actively manages, but the ones that have been running "on their own" for years. Every AIX server, every IBM i, every production LPAR that sends no telemetry to a central system is a blind spot. If you don't know how many unprotected systems you have, you can't size the solution.
2
Deploy Wazuh as a baseline
A Wazuh server with agents on everything — Windows, Linux, AIX, IBM i — gives you centralised visibility. It isn't the final step, but it's the one that generates the most insight per euro spent. Our guide to Wazuh and NIS2 walks through the process for environments under regulatory pressure.
3
Define your response strategy
Detection without the ability to respond is an alarm nobody turns off. Wazuh's active responses (endpoint isolation, IP blocking, process kill) need careful configuration to avoid false positives that hit production. This is where experience matters more than technology.
Where SIXE comes in
Sizing a Wazuh deployment, bringing your Power systems into the EDR strategy, or preparing detection for a NIS2 audit — at SIXE we've spent more than 15 years at that intersection of IBM Power infrastructure and security.
In short
The essentials in five points
What to take away
→ Traditional antivirus isn't enough: it detects signatures, not behaviour. EDR does see fileless malware.
→ The leading EDR solutions have no agent for AIX or IBM i — a blind spot in banking, insurance and logistics.
→ Wazuh is a genuine open-source alternative, with an agent for PASE (IBM i) and AIX, and over 10M annual downloads.
→ Wazuh + PowerSC + Ansible significantly reduces that blind spot and produces evidence aligned with NIS2.
→ The LibrePower open-source ecosystem makes deploying agents and automation on IBM Power simpler.
FAQ
Frequently asked questions
What's the difference between EDR, XDR and antivirus?
Antivirus looks for known malware signatures in files. EDR analyses system behaviour (processes, connections, changes) to detect threats that leave no file behind, such as fileless malware. XDR extends that visibility beyond the endpoint, correlating data from network, email, cloud and identity into a single platform.
Do CrowdStrike or SentinelOne have an agent for AIX or IBM i?
No. The leading commercial EDR solutions have no agent for AIX or IBM i. It's a blind spot that affects sectors with heavy IBM Power footprints: banking, insurance, healthcare and logistics.
Is there an EDR alternative to CrowdStrike or SentinelOne on AIX?
Since CrowdStrike and SentinelOne offer no agent for AIX, the practical alternative combines Wazuh (detection and event collection), PowerSC (IBM's native hardening and compliance) and Ansible for automated deployment. It's not a one-to-one replacement, but it provides the detection layer those platforms don't offer on AIX.
Does this help with NIS2 compliance?
Combining Wazuh, PowerSC and Ansible automation across IBM Power provides a detection and traceability layer over systems that commercial EDR platforms don't cover. Collecting IBM i's QAUDJRN and AIX syslog into a central SIEM produces evidence aligned with the monitoring, traceability and detection requirements set out in NIS2.
Endpoint security · IBM Power
Got blind spots in your EDR coverage?
Tell us which systems are unprotected, how many endpoints you run and which regulations apply to you. We'll get back to you within 24 hours with an outline architecture and a realistic sense of effort. If Wazuh fits, we'll say so. If it doesn't, we'll say that too.
Your team is doing manually what Db2 12 already handles. And they don't know it.
Backups that take longer than they should, failovers built on a product IBM no longer develops for Linux, downtime for operations the engine now handles online. If your team hasn't updated to Db2 12, they're doing more work than they need to — and possibly taking on risks they no longer have to.
9 min read●Technical analysis●
IBM released Db2 12.1.5 on 9 June 2026 — the sixth mod pack since version 12 shipped in November 2024. With each one, the gap between how a DBA operates and what the engine already does on its own has kept growing. And nobody told the team.
It's not a competence problem. The product has changed underneath and nobody has brought the team up to speed. Version 11.5 has had no new features for years, and between it and 12.1 the engine handles high availability, backups, maintenance and even the types of data it can store in fundamentally different ways. But nobody told the team.
Five concrete situations where it shows. These aren't edge cases — they're the daily reality of a DBA who doesn't know their Db2 already handles what they've been doing by hand for years.
01
The failover your team builds on a product IBM no longer extends
This is the clearest case. Your team configures HADR for high availability. On Linux, they set up TSAMP (Tivoli System Automation) because that's what they learned. It works. But IBM is focusing its new HADR automation on Pacemaker and positions it as the strategic option for new Linux deployments. The reference cluster manager is now Pacemaker, open source, standard, simpler to operate.
What your team doesConfigures TSAMP as the cluster manager for HADR. Follows the documentation they know. Manages failover with Tivoli tooling.
What Db2 12 expectsPacemaker integrated. Native failover automation, decoupled VIP and Overlay IP. In 12.1.5 (June 2026): quorum disk tiebreaker and quorum node fencing.
⚠The cost: an HA layer built on the option IBM no longer extends. It works today, but every mod pack adds Pacemaker automation your team isn't using — and the gap with the official documentation widens.
On AIX, the story points in the same direction with a different actor: the right option for demanding, mission-critical workloads is PowerHA SystemMirror, not TSAMP. PowerHA is the product IBM maintains and evolves for Db2 high availability on Power — more robust, more integrated and better suited to production environments. TSAMP is the layer to avoid, regardless of platform. The conclusion isn't that Linux is the modern option and AIX the legacy one — it's that on both platforms there is a correct option, and TSAMP isn't either of them.
02
The backup window that no longer needs to be this wide
Before version 12, backups processed each tablespace with a single thread. On large databases, backup windows stretched and the DBA accepted them as inevitable. In Db2 12, the behaviour has changed on two specific fronts:
What your team doesAccepts that each tablespace is processed with a single thread. Schedules wide windows. Assumes that history file maintenance happens during the backup and blocks.
What Db2 12 does on its ownMulti-threaded backups — multiple threads processing a single tablespace, with no extra configuration. In 12.1.4 (March 2026): history file maintenance runs asynchronously, without blocking. In 12.1.5 (June 2026): automatic archive log pruning.
⚠The cost: maintenance windows wider than necessary. Every extra hour is operational risk and business coordination that could be avoided.
03
The maintenance that takes the service down to change a column
Changing the scale of a DECIMAL or widening a SMALLINT to INT on a columnar (BLU) table meant recreating the table, migrating data and verifying. In practice, scheduled downtime. In Db2 12.1.4 (March 2026) and 12.1.5 (June 2026), several of these operations no longer require an outage.
What your team doesCreates a new table, migrates data, renames, verifies. Schedules downtime. Same for index reorganisation.
What Db2 12 does on its ownOnline ALTER on columnar tables: alter DECIMAL, widen SMALLINT to INT, DROP and RENAME with no downtime. Online index reorg in 12.1.5 (June 2026). Table movement without service interruption.
⚠The cost: service outages for operations Db2 12 handles online. Every avoidable outage is availability recovered.
04
The architecture your team ruled out with 2022 criteria
This case breaks the pattern of the previous ones, but it's just as relevant: it isn't something Db2 12 does on its own, it's an architecture that is now viable and wasn't before. If anyone on your team evaluated Db2 pureScale — IBM's active-active high availability for Db2, conceptually comparable to Oracle RAC — they probably ruled it out over the hardware requirements. That was a valid criterion in 2022. It no longer is.
What your team assumespureScale requires specific on-premises hardware, InfiniBand interconnect and a complex infrastructure project.
What Db2 12 offerspureScale self-managed on Azure and AWS. On AWS, EFA cuts latency by 40% and multiplies throughput by 2.5×. Mixed HADR topology for DR with different node counts.
⚠The cost: ruling out an architecture over requirements that stopped applying years ago. A design decision made on 2022 information that limits the team's options today.
05
What your team assumes needs another database
A semantic search or RAG requirement comes up. The instinct is to assume you need another database: another vector engine, another backup, another monitoring system, another lifecycle to maintain. It may well be the right call. But it's worth knowing that Db2 12 already stores and queries vectors inside the same engine:
What your team assumesThat doing RAG needs another database, another backup, another monitoring system and another lifecycle to manage.
What Db2 12 hasNativeVECTOR datatype (12.1.2). DiskANN indexing(12.1.5). SQL Functions TO_EMBEDDING y TEXT_GENERATION that invoke watsonx.ai or OpenAI models directly from a SQL query.
⚠The native option won't always be the best. But one less system to maintain, back up and monitor is an architecture decision worth evaluating — especially if the team didn't even know it was on the table.
The pattern
It's not a competence problem. It's an information problem.
All five cases share the same root cause: the team isn't doing things wrong. They're doing them as they were taught. The problem is that the product has changed and nobody told them. IBM has shipped six mod packs since November 2024. The procedures the team learned — whether on version 10 or 11.5 — no longer reflect how the engine works today.
And here's what matters: most of these problems aren't solved by buying hardware or adding headcount. They're solved by updating procedures. The risk isn't running Db2 badly — it's running Db2 12 as if it were Db2 11.5.
We've built two in-house courses that cover exactly this gap. They're not generic: they're updated to Db2 12.1.5, delivered on AIX and Linux, and tailored to the team's level. On-site or remote, in English, Spanish and French.
Yes, on Linux. Pacemaker replaces Tivoli System Automation as the cluster manager for HADR. Configuration, validation and failover procedures change entirely. On AIX, the right option for critical workloads is PowerHA SystemMirror — the product IBM actively develops for Db2 HA on Power. TSAMP is the layer to avoid on both platforms.
What does Db2 12 automate that used to be manual?
Multi-threaded backups with no extra configuration, history file maintenance decoupled from backup execution, online schema evolution on columnar tables, automatic archive log pruning and online index reorg without blocking.
Is there up-to-date Db2 12 training for AIX and Linux?
Yes, since Db2 12. Self-managed on Azure (RoCE and TCP/IP, BYOL) and on AWS (with Elastic Fabric Adapter). Dedicated on-premises hardware is no longer required.
Db2 12 Training · AIX and Linux
Is your team running Db2 without having caught up with v12?
Tell us which version you're on, how many DBAs need training and on which platform. We'll put together a tailored proposal — syllabus, format, dates and language.
The 10 critical API security risks per OWASP, one by one, mapped to real IBM API Connect and DataPower capabilities. Where the gateway solves it, where it helps, and where the work remains your backend's.
10 min read●Technical analysis●
APIs are the main attack vector against enterprise applications, and as AI agents and protocols like MCP gain adoption, the inventory of autonomous consumers keeps growing. The risks in the OWASP API Security Top 10 (2023 edition, current) don't change — they just become more critical.
This post gets straight to the point: a risk-by-risk mapping of what IBM API Connect + DataPower cover and what they don't. Out of 10 risks, the gateway has native coverage on 4, partial help on another 4, indirect impact on 1, and leaves 1 to the backend. Knowing which is which is what separates a trained team from one figuring it out in production.
10
Critical risks in the OWASP list
2023
Latest current OWASP edition
4 / 10
Native coverage by IBM gateway
3
New categories vs 2019
01 · Context
OWASP what, and why does it matter more in 2026?
The OWASP API Security Top 10 is the industry reference list of the 10 most critical API security risks. The latest edition is from 2023 — and in 2026 it remains the standard, with no new edition pending. What's changed is not the list, it's the context where it applies:
APIs remain one of the main attack vectors against enterprise applications.
Growing adoption of AI agents and protocols like MCP adds autonomous consumers to the picture — distinct from the apps and partners we've always had.
API sprawl — undocumented, ungoverned APIs — is still a recurring challenge in organisations with years of accumulated integrations.
In this scenario the gateway stops being just a proxy and becomes the piece where OWASP API Top 10 controls are enforced — or not.
How to read this post
Each risk carries a coverage badge with four levels: Native (the gateway covers it on its own), Partial (it helps but needs proper design), Indirect (limited contribution), or Not direct (the problem lives in the backend). The point isn't to sell — it's to know where to put the effort.
02 · The 10 risks
OWASP API Top 10 (2023) · mapped to IBM API Connect + DataPower
The client changes an ID in the URL (/orders/42 → /orders/43) and accesses an object that doesn't belong to them. Still the #1 risk — because object ownership logic lives in the backend.
What the gateway DOESValidates JWT, extracts user claims and passes them to the backend in signed headers. Can enforce policies by OAuth scope.
What your backend must doCheck that the user_id in the token matches the owner of the requested object on every endpoint. The gateway doesn't know your data model.
API2:2023Broken AuthenticationNative
Poorly validated tokens, insecure authentication mechanisms, JWTs signed with none, default credentials. Authentication is the plane where the gateway contributes most, no debate.
What the gateway DOESFull OAuth 2.0 (authorization server, scopes, refresh), JWT validation (signature, exp, aud, iss), OIDC, mTLS, rotating API keys, integration with external LDAP/AD/IAM. This is WD509G and WE752G territory.
What your backend must doTrust the gateway's validation result. If you re-validate at the backend, make sure not to introduce inconsistencies.
The backend returns more fields than the user should see (excessive data exposure) or accepts more fields than expected on write (mass assignment). Combines the former API3:2019 and API6:2019.
What the gateway DOESResponse transformations (masking sensitive fields, scope-based filtering). DataPower can apply XSLT or GatewayScript policies to sanitise payloads.
What your backend must doDon't return fields the role shouldn't see. Don't accept unexpected fields on writes. The gateway can help after the fact, but the responsibility stays with API design.
API4:2023Unrestricted Resource ConsumptionNative
Missing rate limiting, no quotas, payloads with no size cap. Used to be called "Lack of Resources & Rate Limiting". Where the gateway shines.
What the gateway DOESRate limit per consumer, per plan, per endpoint. Daily/monthly quotas. Configurable throttling. Payload size limits. Burst control. All configured in the manager and enforced at DataPower or Nano Gateway.
What your backend must doDefine the SLAs for each plan/consumer. The gateway enforces what you decide — it doesn't decide what's reasonable for you.
API5:2023Broken Function Level AuthorizationPartial coverage
A normal user reaches admin endpoints because the API doesn't check the role beyond authentication.
What the gateway DOESApplies different policies per endpoint based on OAuth scopes. Blocks access to admin routes from tokens without the required scope. Conditional routing.
What your backend must doDesign OAuth scopes properly from the start. An admin scope is useless if every flow grants it. The gateway enforces rules — it doesn't invent them.
API6:2023Unrestricted Access to Sensitive Business FlowsPartial coverage
An API exposes a sensitive business flow (purchases, transfers, voting) and an attacker automates thousands of legal but abusive calls. The damage isn't from a technical exploit — it's volume.
What the gateway DOESPer-consumer throttling, pattern detection, geo-blocking, CAPTCHA gateway integration, WAF integration (DataPower) for advanced rules.
What your backend must doIdentify which flows are sensitive (not all are) and design business counters that the gateway can consume via analytics.
API7:2023Server Side Request Forgery (SSRF)Not direct
An API accepts a URL from the user and uses it to make internal requests — the attacker uses it to hit your internal network. Vector on the rise in cloud due to metadata services (AWS IMDS, Azure IMDS).
What the gateway DOESLittle directly. If the backend forwards outbound traffic through the gateway, you can restrict destinations. Not the usual pattern.
What your backend must doValidate incoming URLs against an allowlist. Block internal ranges (RFC 1918, link-local). Don't use user inputs directly in server-side HTTP requests. This is 95% backend.
API8:2023Security MisconfigurationNative
Insecure defaults, misconfigured TLS, overly permissive CORS, missing security headers, stack-trace errors exposed. The classic that still causes incidents.
What the gateway DOESDataPower ships with secure defaults and allows centralised policies for TLS, CORS, security headers (HSTS, CSP, X-Frame-Options), stack-trace suppression. Unified configuration audit from API Connect V12.
What your backend must doDon't override at the backend what the gateway already does correctly (double-configuration errors). Keep secure defaults also inside the internal network.
API9:2023Improper Inventory ManagementNative
Zombie APIs in production, old versions never retired, staging environments reachable from the internet, no documentation. The root of API sprawl.
What the gateway DOESAPI Connect's core is exactly this: API catalog, versioning, lifecycle (creation, publication, deprecation, retirement), federated governance in V12 (heterogeneous gateways visible from one control plane), Developer Portal with auto-generated documentation.
What your backend must doFollow the governance process: every published API goes through the manager. APIs not in the catalog are shadow — and those are the ones that lead to breaches.
API10:2023Unsafe Consumption of APIsIndirect coverage
Your app consumes third-party APIs without validating what they return — and a compromised provider takes you down with them. New in 2023, especially relevant in architectures with many SaaS integrations.
What the gateway DOESIf outbound consumption of external APIs goes through the gateway, you can apply schema validation, response sanitisation and rate-limit the provider. Not always the pattern.
What your backend must doValidate consumed API contracts. Don't trust received payloads. Isolate dependencies. This is development discipline, more than platform configuration.
03 · Visual summary
The 10 risks, at a glance
Coverage table of the IBM gateway (API Connect + DataPower) per OWASP risk:
The gateway enforces rules — someone has to design them
The honest takeaway after reading the mapping is the one rarely surfaced in marketing material: the gateway is a powerful tool, but with no judgement of its own. It applies to the letter what your team configures. If OAuth scopes are poorly thought out, the gateway doesn't fix them. If you set a 10,000 req/s rate limit on a transfers endpoint, the gateway just helps you fail faster.
The capabilities of API Connect and DataPower are the ones you saw above. The difference between "we have API Connect" and "we have API Connect properly mitigating 8 of the 10 OWASP risks" comes down to the team operating it.
The 5 official courses that cover all of thisWD509G and WD514G for the API Connect core; WE761G, WE752G and WE754G for DataPower. In English, in-company from 2 attendees.
Not just "what each DataPower node does". It's when to apply which policy, how to design OAuth scopes that scale, when per-consumer rate limit falls short and business-flow throttling kicks in — the kind of operational decision you only see in projects, not in the manual.
Summary
The essentials in 5 points
Take-aways
→ OWASP API Top 10 2023 remains the current standard in 2026 — no pending re-edition, but more relevant with AI-agent adoption.
→ The IBM gateway (API Connect + DataPower) has native coverage on 4 risks — authentication, rate limiting, secure configuration and API inventory.
→ Partial help on another 4 (BOLA, property authz, function authz, business flows) — business logic stays in the backend.
→ SSRF and unsafe consumption are mostly developer territory — don't expect the gateway to solve them for you.
→ The difference between owning the tool and mitigating the risks is the team configuring it.
FAQ
Frequently asked questions
Is the 2023 OWASP API Top 10 still current in 2026?
Yes. The OWASP Foundation released the latest API Security Top 10 update in 2023 and no new edition has been published in 2026. The list remains the de facto industry benchmark — more relevant than ever with growing AI-agent API consumption.
Does API Connect / DataPower cover all 10 OWASP risks?
No, and that's not a gateway shortcoming. Out of 10 risks, the gateway has native coverage for 4 (API2, API4, API8, API9), partial coverage for 4 (API1, API3, API5, API6), indirect impact on 1 (API10) and leaves 1 to backend (API7 SSRF). The rest needs proper backend design and human review.
Which OWASP risk is easiest to mitigate with the gateway?
API4 (Unrestricted Resource Consumption) and API9 (Improper Inventory Management). Rate limiting, quota plans and throttling are API Connect's native territory. Catalogs, versioning and federated governance in V12 directly cover inventory management.
Where do I learn to configure all this in API Connect?
The official WD509G (admins) and WD514G (devs) courses, plus the DataPower ones (WE761G, WE752G, WE754G). SIXE delivers them in-company from 2 attendees with engineers who deploy these products in real customer environments. Full catalog at the API Connect training hub.
Tell us which OWASP risks worry you most, how many people are on your team and where you're based. We respond within 24 hours with an itinerary, format and closed quote. No endless forms.
At SIXE, we prioritize your comfort and security. These technologies help us optimize our services, personalize content and offer you solutions tailored to what you really need. Your privacy is important: you will always be in control of what you share with us.
Functional
Always active
El almacenamiento o acceso técnico es estrictamente necesario para el propósito legítimo de permitir el uso de un servicio específico explícitamente solicitado por el abonado o usuario, o con el único propósito de llevar a cabo la transmisión de una comunicación a través de una red de comunicaciones electrónicas.
Preferences
El almacenamiento o acceso técnico es necesario para la finalidad legítima de almacenar preferencias no solicitadas por el abonado o usuario.
Statistics
El almacenamiento o acceso técnico que es utilizado exclusivamente con fines estadísticos.El almacenamiento o acceso técnico que se utiliza exclusivamente con fines estadísticos anónimos. Sin un requerimiento, el cumplimiento voluntario por parte de tu Proveedor de servicios de Internet, o los registros adicionales de un tercero, la información almacenada o recuperada sólo para este propósito no se puede utilizar para identificarte.
Marketing
El almacenamiento o acceso técnico es necesario para crear perfiles de usuario para enviar publicidad, o para rastrear al usuario en una web o en varias web con fines de marketing similares.
