Another year alive, another year of watching the distributed storage industry outdo itself in commercial creativity. If 2024 was the year everyone discovered they needed “storage for AI” (spoiler: it’s the same old storage, but with better marketing), 2025 has been the year MinIO decided to publicly immolate itself while the rest of the ecosystem continues to evolve apace.

Hold on, the curves are coming.

The Drama of the Year: MinIO Goes Into “Maintenance Mode” (Read: Abandonment Mode)

If you haven’t been following the MinIO soap opera, let me give you some context. MinIO was the open source object storage that everyone was deploying. Simple, fast, S3 compatible. You had it up and running in 15 minutes. It was the WordPress of object storage.

Well, in December 2025, a silent commit in the README changed everything: “This project is currently under maintenance and is not accepting new changes.” No announcement. No migration guide. No farewell. Just a commit and goodbye.

The community, predictably, went up in flames. One developer summed it up perfectly: “A silent README update just ended the era of MinIO as the default open-source S3 engine.”

But this didn’t come out of the blue. MinIO had been pursuing an “open source but don’t overdo it” strategy for years:

• 2021: Silent switch from Apache 2.0 to AGPL v3 (no announcement, no PR, no nothing)
• 2022-2023: Aggressive campaigns against Nutanix and Weka for “license violations”
• February 2025: Web console, bucket management and replication removed from the Community version
• October 2025: Stop distributing Docker images
• December 2025: Maintenance mode

The message is clear: if you want MinIO for real, pay up. Their enterprise AIStor product starts at €96,000/year for 400 TiB. For 1 PB, we are talking about more than €244,000/year.

The lesson? In 2025, “Open Source” without Open Governance is worthless. MinIO was a company with an open source product, not a community project. The difference matters.

In the Meantime, Ceph Continues to Swim Peacefully

While MinIO was self-destructing, Ceph was celebrating its 20th stable release: Tentacle (v20.2.0), released in November 2025. The project accumulates more than 1 exabyte of storage deployed globally on more than 3,000 clusters.

The most interesting thing about Tentacle is FastEC (Fast Erasure Coding), which improves the performance of small reads and writes by 2x to 3x. This makes erasure coding finally viable for workloads that are not pure cold file. With a 6+2 EC profile, you can now achieve approximately 50% of the performance of replication 3 while using only 33% of the space.

For those of us who have been hearing “erasure coding is slow for production” for years, this is a real game changer.

Other Tentacle news:

• Integrated SMB support via Samba Manager
• NVMe/TCP gateway groups with multi-namespace support
• OAuth 2.0 authentication on the dashboard
• CephFS case-insensitive directories (finally)
• ISA-L replaces Jerasure (which was abandoned)

The Crimson OSD (based on Seastar for NVMe optimization) is still in technical preview. It is not production ready, but the roadmap is promising.

The Numbers That Matter

Bloomberg operates more than 100 PBs in Ceph clusters. They are a Diamond member of the Ceph Foundation and their Head of Storage Engineering is on the Governing Board. DigitalOcean has 54+ PBs in 37 production clusters. CERN maintains 50+ PBs in more than 10 clusters.

And here’s the interesting part: ZTE Corporation is among the top 3 global contributors to Ceph and number 1 in China. Its TECS CloveStorage product (based on Ceph) is deployed in more than 320 NFV projects worldwide, including China Mobile, izzi Telecom (Mexico) and Deutsche Telekom.

The telco sector is Ceph’s secret superpower. While many are still thinking of traditional appliances, telcos are running Ceph in production on a massive scale.

The Enterprise Ecosystem: Understanding What You’re Buying

This is where it gets interesting. And it’s worth understanding what’s behind each option.

IBM Fusion: Two Flavors for Different Needs

IBM has two products under the Fusion brand, and it is important to understand the difference:

• IBM Fusion HCI: Uses IBM Storage Scale ECE (the old GPFS/Spectrum Scale). Parallel file system with distributed erasure coding. Hyperconverged appliance that scales from 6 to 20 nodes.
• IBM Fusion SDS: Uses OpenShift Data Foundation (ODF), which is based on Ceph packaged by Red Hat.

Storage Scale is a genuinely differentiated technology, especially for HPC. Its parallel file system architecture offers capabilities that Ceph simply doesn’t have: advanced metadata management, integrated tiering, AFM for federation…. If you have high-performance computing, supercomputing or AI workloads at serious scale, Storage Scale has solid technical arguments to justify it.

IBM Fusion HCI performance claims are impressive: 90x acceleration on S3 queries with local caching, performance equivalent to Databricks Photon at 60% of the cost, etc.

Now, it’s always worth asking the question: how much of that performance is proprietary technology and how much is simply well-dimensioned hardware with an appropriate configuration? It’s not a criticism, it’s a legitimate question that any architect should ask before making a decision.

In the case of Fusion SDS, you’re buying Ceph with the added value of packaging, OpenShift integration, and IBM enterprise support. For many organizations, that has real value.

Red Hat Ceph Storage: The Enterprise Standard

Red Hat Ceph Storage continues to be the enterprise distribution of choice. They offer 36 months of production support plus optional 24 months of extended support. The product is robust and well integrated.

What you are really buying is: tested and certified packages, 24/7 enterprise support, predictable life cycles, and OpenShift integration.

Is it worth it? It depends on your context. If your organization needs a support contract to comply with compliance or simply to sleep easy, probably yes. And we’d be happy to help you with that. But if you have the technical team to operate Ceph upstream, it’s a decision that deserves analysis.

SUSE: A Lesson in Vendor Lock-in

Here’s a story that bears reflection: SUSE completely exited the Ceph enterprise market. Their SUSE Enterprise Storage (SES) product reached end of support in January 2023. After acquiring Rancher Labs in 2020, they pivoted to Longhorn for Kubernetes-native storage.

If you were an SES customer, you found yourself orphaned. Your options were to migrate to Red Hat Ceph Storage, Canonical Charmed Ceph, community Ceph, or find a specialized partner to help you with the transition.

This is not a criticism of SUSE; companies pivot according to their strategy. But it is a reminder that control over your infrastructure has value that doesn’t always show up in TCO.

Pure Storage and NetApp: The Appliance Approach

Pure Storage has created a category called “Unified Fast File and Object” (UFFO) with its FlashBlade family. Impressive hardware, consistent performance, polished user experience. Its FlashBlade//S R2 scales up to 60 PB per cluster with 150 TB DirectFlash Modules.

NetApp StorageGRID 12.0 focuses on AI with 20x throughput improvements via advanced caching and support for more than 600 billion objects in a single cluster.

Both are solid solutions that compete with Ceph RGW in S3-compatible object storage. The performance is excellent. The question each organization must ask itself is whether the premium justifies the vendor lock-in for their specific use case.

The Question No One Asks: What Are You Really Buying?

This is where I put on my thoughtful engineer’s hat.

Ceph upstream is extremely stable. It has 20 releases under its belt. The Ceph Foundation includes IBM, Red Hat, Bloomberg, DigitalOcean, OVHcloud and dozens more. Development is active, the community is strong, and documentation is extensive.

So when does it make sense to pay for enterprise distribution and when does it not?

It makes sense when: your organization requires a compliance support contract or internal policy; you don’t have the technical staff to operate Ceph and you don’t want to develop it; you need predictable and tested upgrade cycles; the cost of downtime is higher than the cost of the license; or you need specific integration with other vendor products.

It deserves further analysis when: the decision is based on “it’s what everyone does”; no one has really evaluated the alternatives; the main reason is that “the vendor told us that open source is not supported”; or you have capable technical equipment but have not invested in their training.

The real challenge is knowledge. Ceph has a steep learning curve. Designing a cluster correctly, understanding CRUSH maps, tuning BlueStore, optimizing placement groups… this requires serious training and hands-on experience.

But once you have that knowledge, you have options. You can choose an enterprise vendor judiciously, knowing exactly what value-add you are buying. Or you can operate upstream with specialized support. The key is to make an informed decision.

Demystifying Marketing Claims

One thing I always recommend is to read benchmarks and marketing claims with a constructive critical spirit.

“Our product is 90x faster” – Compared to what baseline? On what specific workload? With what competitor configuration?

“Performance equivalent to [competitor] at 60% of cost” – Does this include full TCO? Licensing, support, training, personnel?

“Enterprise-grade certified solution” – what exactly does that mean? Because Ceph upstream is also enterprise-grade at CERN, Bloomberg, and hundreds of telecoms.

I’m not saying the claims are false. I am saying that context matters. The reality is that distributed storage performance is highly dependent on correct cluster design (failure domains, placement groups), appropriate hardware (25/100GbE network, NVMe with power-loss protection), operating system configuration (IOMMU, CPU governors), and workload specific tuning (osd_memory_target, bluestore settings).

A well-designed Ceph cluster operated by experienced people can achieve impressive performance. The Clyso benchmark achieved 1 TiB/s with 68 Dell PowerEdge servers. IBM demonstrated over 450,000 IOPS on a 4-node Ceph cluster with 24 NVMe per node.

Sometimes, that “certified solution” seal you see on a datasheet is, at heart, free software with an expert configuration, well-dimensioned hardware, and a lot of testing. Which has value, but it’s good to know.

The Smart Move: Deciding With Information

After 15 years in this industry, my conclusion is that there is no single answer. What there is are informed decisions.

For some organizations, a packaged enterprise solution is exactly what they need: guaranteed support, predictable cycle times, validated integration, and the peace of mind of having an accountable vendor. IBM Fusion with Storage Scale is an excellent choice for HPC. Red Hat Ceph Storage is solid for anyone who wants Ceph with enterprise backup.

For other organizations, Ceph upstream with specialized support and training offers significant advantages:

1. Foundation governance: Ceph is a project of the Linux Foundation with open governance. MinIO can’t happen.
2. Active community: Thousands of contributors, regular releases, bugs fixed quickly.
3. Flexibility: It’s your cluster, your configuration. If tomorrow you decide to change your support partner, you lose nothing.
4. Transparent TCO: The software is free. You invest in appropriate hardware and knowledge.
5. Version control: You update when it makes sense for you, not when the vendor puts out the next packaged release.

The common denominator in both cases is knowledge. Whether you buy an enterprise solution or deploy upstream, understanding Ceph in depth allows you to make better decisions, negotiate better with vendors, and solve problems faster.

Where to Get This Knowledge

Ceph is complex. But there are clear paths:

The official documentation is extensive and much improved. The Ceph blog has excellent technical deep-dives.

Cephalocon is the annual conference where you can learn from those who operate Ceph at full scale (Bloomberg, CERN, DigitalOcean).

Structured training with hands-on labs is the most efficient way to build real competence. You don’t learn Ceph by reading slides; you learn by breaking and fixing clusters.

L3 technical support from people who live Ceph every day gets you out of trouble when things get complicated in production. Because they will. At SIXE, we’ve spent years training technical teams in Ceph and providing L3 support to organizations of all types: those operating upstream, those using enterprise distributions, and those evaluating options. Our Ceph training program covers everything from basic architecture to advanced operations with real hands-on labs. And if you already have Ceph in production and need real technical support, our specialized technical support is designed for exactly that.

In addition, we have just launched a certification program with badges in Credly so that your team can demonstrate their competencies in a tangible way. Because in this industry, “be Ceph” doesn’t mean the same thing to everyone.

 

Conclusions for 2026

1. MinIO is dead for serious use. Look for alternatives. Ceph RGW, SeaweedFS, or even the OpenMaxIO fork if you are brave.
2. Understand what you are buying. There are cases where a packaged enterprise solution brings real value. There are others where you are mainly paying for a logo and a configuration that you could replicate.
3. Ceph upstream is mature and production-ready. Bloomberg, DigitalOcean, CERN and 320+ telecoms projects can’t all be wrong.
4. The true cost of distributed storage is knowledge. Invest in quality training and support, regardless of which option you choose.
5. Control over your infrastructure has value. Ask SUSE SES customers how it went when the vendor decided to pivot.
6. The governance of the project matters as much as the technology. Open Foundation > company with open source product.

2026 looks interesting. FastEC is going to change the erasure coding equation. Integration with AI and ML will continue to push for more performance. And the vendor ecosystem will continue to evolve with proposals that deserve serious evaluation.

You decide. This is the only important thing.

Bringing MariaDB to AIX, the Platform That Powers the World’s Most Critical Systems

There are decisions in life you make knowing full well they’ll cause you some pain. Getting married. Having children. Running a marathon. Porting MariaDB 11.8 to IBM AIX.

This (Part 1) is the story of the last one — and why I’d do it again in a heartbeat.

Chapter 1: “How Hard Can It Be?”

It all started with an innocent question during a team meeting: “Why don’t we have MariaDB on our AIX systems?”

Here’s the thing about AIX that people who’ve never worked with it don’t understand: AIX doesn’t mess around. When banks need five-nines uptime for their core banking systems, they run AIX. When airlines need reservation systems that cannot fail, they run AIX. When Oracle, Informix, or DB2 need to deliver absolutely brutal performance for mission-critical OLTP workloads, they run on AIX.

AIX isn’t trendy. AIX doesn’t have a cool mascot. AIX won’t be the subject of breathless tech blog posts about “disruption.” But when things absolutely, positively cannot fail — AIX is there, quietly doing its job while everyone else is busy rebooting their containers.

So why doesn’t MariaDB officially support AIX? Simple economics: the open source community has centered on Linux, and porting requires platform-specific expertise. MariaDB officially supports Linux, Windows, FreeBSD, macOS, and Solaris. AIX isn’t on the list — not because it’s a bad platform, but because no one had done the work yet.

At LibrePower, that’s exactly what we do.

My first mistake was saying out loud: “It’s probably just a matter of compiling it and adjusting a few things.”

Lesson #1: When someone says “just compile it” about software on AIX, they’re about to learn a lot about systems programming.

Chapter 2: CMake and the Three Unexpected Guests

Day one of compilation was… educational. CMake on AIX is like playing cards with someone who has a very different understanding of the rules — and expects you to figure them out yourself.

The Ghost Function Bug

AIX has an interesting characteristic: it declares functions in headers for compatibility even when those functions don’t actually exist at runtime. It’s like your GPS saying “turn right in 200 meters” but the street is a brick wall.

CMake does a CHECK_C_SOURCE_COMPILES to test if pthread_threadid_np() exists. The code compiles. CMake says “great, we have it!” The binary starts and… BOOM. Symbol not found.

Turns out pthread_threadid_np() is macOS-only. AIX declares it in headers because… well, I’m still not entirely sure. Maybe for some POSIX compatibility reason that made sense decades ago? Whatever the reason, GCC compiles it happily, and the linker doesn’t complain until runtime.

Same story with getthrid(), which is OpenBSD-specific.

The fix:

IF(NOT CMAKE_SYSTEM_NAME MATCHES "AIX")
  CHECK_C_SOURCE_COMPILES("..." HAVE_PTHREAD_THREADID_NP)
ELSE()
  SET(HAVE_PTHREAD_THREADID_NP 0)  # Trust but verify... okay, just verify
ENDIF()

poll.h: Hide and Seek

AIX has <sys/poll.h>. It’s right there. You can cat it. But CMake doesn’t detect it.

After three hours debugging a “POLLIN undeclared” error in viosocket.c, I discovered the solution was simply forcing the define:

cmake ... -DHAVE_SYS_POLL_H=1

Three hours. For one flag.

(To be fair, this is a CMake platform detection issue, not an AIX issue. CMake’s checks assume Linux-style header layouts.)

The Cursed Plugins

At 98% compilation — 98%! — the wsrep_info plugin exploded with undefined symbols. Because it depends on Galera. Which we’re not using. But CMake compiles it anyway.

Also S3 (requires Aria symbols), Mroonga (requires Groonga), and RocksDB (deeply tied to Linux-specific optimizations).

Final CMake configuration:

-DPLUGIN_MROONGA=NO -DPLUGIN_ROCKSDB=NO -DPLUGIN_SPIDER=NO 
-DPLUGIN_TOKUDB=NO -DPLUGIN_OQGRAPH=NO -DPLUGIN_S3=NO -DPLUGIN_WSREP_INFO=NO

It looks like surgical amputation, but it’s actually just trimming the fat. These plugins are edge cases that few deployments need.

Chapter 3: Thread Pool, or How I Learned to Stop Worrying and Love the Mutex

This is where things got interesting. And by “interesting” I mean “I nearly gave myself a permanent twitch.”

MariaDB has two connection handling modes:

• one-thread-per-connection: One thread per client. Simple. Scales like a car going uphill.
• pool-of-threads: A fixed pool of threads handles all connections. Elegant. Efficient. And not available on AIX.

Why? Because the thread pool requires platform-specific I/O multiplexing APIs:

So… how hard can implementing pollset support be?

(Editor’s note: At this point the author required a 20-minute break and a beverage)

The ONESHOT Problem

Linux epoll has a wonderful flag called EPOLLONESHOT. It guarantees that a file descriptor fires events only once until you explicitly re-arm it. This prevents two threads from processing the same connection simultaneously.

AIX pollset is level-triggered. Only level-triggered. No options. If data is available, it reports it. Again and again and again. Like a helpful colleague who keeps reminding you about that email you haven’t answered yet.

Eleven Versions of Increasing Wisdom

What followed were eleven iterations of code, each more elaborate than the last, trying to simulate ONESHOT behavior:

v1-v5 (The Age of Innocence)

I tried modifying event flags with PS_MOD. “If I change the event to 0, it’ll stop firing,” I thought. Spoiler: it didn’t stop firing.

v6-v7 (The State Machine Era)

“I know! I’ll maintain internal state and filter duplicate events.” The problem: there’s a time window between the kernel giving you the event and you updating your state. In that window, another thread can receive the same event.

v8-v9 (The Denial Phase)

“I’ll set the state to PENDING before processing.” It worked… sort of… until it didn’t.

v10 (Hope)

Finally found the solution: PS_DELETE + PS_ADD. When you receive an event, immediately delete the fd from the pollset. When you’re ready for more data, add it back.

// On receiving events: REMOVE
for (i = 0; i < ret; i++) {
    pctl.cmd = PS_DELETE;
    pctl.fd = native_events[i].fd;
    pollset_ctl(pollfd, &pctl, 1);
}

// When ready: ADD
pce.command = PS_ADD;
pollset_ctl_ext(pollfd, &pce, 1);

It worked! With -O2.

With -O3… segfault.

The Dark Night of the Soul (The -O3 Bug)

Picture my face. I have code working perfectly with -O2. I enable -O3 for production benchmarks and the server crashes with “Got packets out of order” or a segfault in CONNECT::create_thd().

I spent two days thinking it was a compiler bug. GCC 13.3.0 on AIX. I blamed the compiler. I blamed the linker. I blamed everything except my own code.

The problem was subtler: MariaDB has two concurrent code paths calling io_poll_wait on the same pollset:

• The listener blocks with timeout=-1
• The worker calls with timeout=0 for non-blocking checks

With -O2, the timing was such that these rarely collided. With -O3, the code was faster, collisions happened more often, and boom — race condition.

v11 (Enlightenment)

The fix was a dedicated mutex protecting both pollset_poll and all pollset_ctl operations:

static pthread_mutex_t pollset_mutex = PTHREAD_MUTEX_INITIALIZER;

int io_poll_wait(...) {
    pthread_mutex_lock(&pollset_mutex);
    ret = pollset_poll(pollfd, native_events, max_events, timeout);
    // ... process and delete events ...
    pthread_mutex_unlock(&pollset_mutex);
}

Yes, it serializes pollset access. Yes, that’s theoretically slower. But you know what’s even slower? A server that crashes.

The final v11 code passed 72 hours of stress testing with 1,000 concurrent connections. Zero crashes. Zero memory leaks. Zero “packets out of order.”

Chapter 4: The -blibpath Thing (Actually a Feature)

One genuine AIX characteristic: you need to explicitly specify the library path at link time with -Wl,-blibpath:/your/path. If you don’t, the binary won’t find libstdc++ even if it’s in the same directory.

At first this seems annoying. Then you realize: AIX prefers explicit, deterministic paths over implicit searches. In production environments where “it worked on my machine” isn’t acceptable, that’s a feature, not a bug.

Chapter 5: Stability — The Numbers That Matter

After all this work, where do we actually stand?

The RPM is published at aix.librepower.org and deployed on an IBM POWER9 system (12 cores, SMT-8). MariaDB 11.8.5 runs on AIX 7.3 with thread pool enabled. The server passed a brutal QA suite:

1,648,482,400 bytes of memory — constant across 30 minutes. Not a single byte of drift. The server ran for 39 minutes under continuous load and performed a clean shutdown.

It works. It’s stable. It’s production-ready for functionality.

Thread Pool Impact

The thread pool work delivered massive gains for concurrent workloads:

For high-concurrency OLTP workloads, this is the difference between “struggling” and “flying.”

What I Learned (So Far)

1. CMake assumes Linux. On non-Linux systems, manually verify that feature detection is correct. False positives will bite you at runtime.
2. Level-triggered I/O requires discipline. EPOLLONESHOT exists for a reason. If your system doesn’t have it, prepare to implement your own serialization.
3. -O3 exposes latent bugs. If your code “works with -O2 but not -O3,” you have a race condition. The compiler is doing its job; the bug is yours.
4. Mutexes are your friend. Yes, they have overhead. But you know what has more overhead? Debugging race conditions at 3 AM.
5. AIX rewards deep understanding. It’s a system that doesn’t forgive shortcuts, but once you understand its conventions, it’s predictable and robust. There’s a reason banks still run it — and will continue to for the foreseeable future.
6. The ecosystem matters. Projects like linux-compat from LibrePower make modern development viable on AIX. Contributing to that ecosystem benefits everyone.

What’s Next: The Performance Question

The server is stable. The thread pool works. But there’s a question hanging in the air that I haven’t answered yet:

How fast is it compared to Linux?

I ran a vector search benchmark — the kind of operation that powers AI-enhanced search features. MariaDB’s MHNSW (Hierarchical Navigable Small World) index, 100,000 vectors, 768 dimensions.

Linux on identical POWER9 hardware: 971 queries per second.

AIX with our new build: 42 queries per second.

Twenty-three times slower.

My heart sank. Three weeks of work, and we’re 23x slower than Linux? On identical hardware?

But here’s the thing about engineering: when numbers don’t make sense, there’s always a reason. And sometimes that reason turns out to be surprisingly good news.

In Part 2, I’ll cover:

• How we discovered the 23x gap was mostly a configuration mistake
• The compiler that changed everything
• Why “AIX is slow” turned out to be a myth
• The complete “Failure Museum” of optimizations that didn’t work

The RPMs are published at aix.librepower.org. The GCC build is stable and production-ready for functionality.

But the performance story? That’s where things get really interesting.

Part 2 coming soon.

TL;DR

• MariaDB 11.8.5 now runs on AIX 7.3 with thread pool enabled
• First-ever thread pool implementation for AIX using pollset (11 iterations to get ONESHOT simulation right)
• Server is stable: 1,000 connections, 11M+ queries, zero memory leaks
• Thread pool delivers 83% improvement for concurrent workloads
• Initial vector search benchmark shows 23x gap vs Linux — but is that the whole story?
• RPMs published at aix.librepower.org
• Part 2 coming soon: The performance investigation

Questions? Ideas? Want to contribute to the AIX open source ecosystem?

This work is part of LibrePower – Unlocking IBM Power Systems through open source. Unmatched RAS. Superior TCO. Minimal footprint 🌍

LibrePower AIX project repository: gitlab.com/librepower/aix

We want to unleash the full potential of IBM Power

We build community to grow the Power ecosystem – more solutions, more users, more value.

The most capable hardware you’re not yet taking full advantage of

IBM Power underpins mission-critical computing around the world. Banking transactions, flight reservations, hospital systems, SAP installations – workloads that can’t afford to fail run on Power.

This is no coincidence.

Power systems offer legendary reliability thanks to their RAS (Reliability, Availability, Serviceability) architecture that x86 simply cannot match. They run trouble-free for 10, 15 years or more. Their design – large caches, SMT8, extraordinary memory bandwidth – is designed to keep performance at scale in a sustained manner.

But there is an opportunity that most organizations are missing:

Power can do much more than what is usually asked of it.

The capacity is there. The potential is enormous. What has been missing is independent validation, momentum from the community and accessible tools that open the door to new use cases.

Exactly what LibrePower is building.

What is LibrePower?

LibrePower is a community initiative to extend what is possible in IBM Power – across the entire ecosystem:

• AIX – The veteran Unix that runs the most demanding enterprise loads
• IBM i – The integrated system that thousands of companies around the world run on
• Linux on Power (ppc64le) – Ubuntu, Rocky, RHEL, SUSE, Fedora on POWER Architecture

We are not here to replace anything. We come to add:

• More certified solutions running on Power
• More developers and administrators relying on the platform
• More reasons to invest in Power – both in new and existing equipment

What we do

1. LibrePower Certified – independent validation

ISVs and open source projects need to know that their software works on Power. Buyers need confidence before deploying. IBM certification has its value, but there is room for independent community-driven validation.

LibrePower Certified offers three levels:

Free for open source projects. Premium levels for ISVs looking for deeper collaboration.

Open source repositories

We compile, package and distribute software that the Power community needs:

• AIX(aix.librepower.org): modern CLI tools, security utilities, compatibility layers
• ppc64le: container tools (AWX, Podman), development utilities, monitoring
• IBM i: open source integration (under development)

Everything is free. Everything is documented. Everything is in GitLab.

3. Performance testing and optimization

Power hardware has unique features that most software does not take advantage of. We benchmark, identify opportunities and work with upstream projects to improve performance on Power.

When we find optimizations, we contribute them back. The entire ecosystem benefits.

4. Building community

The Power world is fragmented. AIX administrators, Linux on Power teams, IBM i environments – all solving similar problems in isolation.

LibrePower connects these communities:

• Cross-platform knowledge sharing
• Amplify the collective voice to manufacturers and projects
• Create a network of expertise in Power

5. Expanding the market

Every new solution validated in Power is one more reason for organizations to choose the platform. Every developer who learns Power is talent for the ecosystem. Every success story demonstrates value.

More solutions → more adoption → stronger ecosystem → more investment in Power.

This virtuous circle benefits everyone: IBM, partners, ISVs and users.

Why should you care?

If you manage Power systems:

• Access tools and solutions you were missing
• Join a community that understands your environment
• Maximize the return on your hardware investment

If you are a developer:

• Learn a platform with unique technical features
• Contribute to projects with real impact in the enterprise world.
• Develops expertise in a high value niche

If you are an ISV:

• Get your software validated in Power
• Connect with enterprise customers
• Discover market opportunities in the Power ecosystem

If you are evaluating infrastructure:

• Find out what’s really possible in Power beyond traditional charging
• Find independent validation of solutions
• Connect with the community to learn about real experiences

What we are working on

AIX(aix.librepower.org)

• ✅ Modern package manager (dnf/yum for AIX)
• ✅ fzf – fuzzy search engine (Go binary compiled for AIX)
• ✅ nano – modern editor
• 2FA tools – Google Authenticator with QR codes
• 🔄 Coming soon: ripgrep, yq, modern coreutils

Linux ppc64le

• 🔄 AWX – Ansible automation (full port in progress)
• 🔄 Container Tools – Podman, Buildah, Skopeo
• 🔄 Development tools – lazygit, k9s, modern CLIs

IBM i

• 📋 Planning phase – assessing priorities with community input.

The vision

Imagine:

• Every major open source project considers Power at the time of release
• ISVs see Power as a strategic platform, not an afterthought
• Organizations deploy new loads on Power with confidence
• A connected and growing community that powers the ecosystem

That’s The Power Renaissance.

It is not nostalgia for the past. It is not just extending the life of existing deployments.

Active expansion of what Power can do and who uses it.

Join

LibrePower grows with the community. This is how you can participate:

• 📬 Subscribe to the latest news – new releases, guides, community news
• 💻 Explore our repos – use, contribute, request
• ✅ Certify your software – validate your software in Power
• 🤝 Become a sponsor – support the initiative

Who is behind it?

LibrePower is an initiative of SIXE, an IBM and Canonical Business Partner with more than 20 years of experience in the Power ecosystem.

We have seen what Power can do. We’ve seen what’s missing. Now we build what should exist.

LibrePower – Unlocking the potential of Power Systems through open source software 🌍. Unmatched RAS. Superior TCO. Minimal footprint. 🌍

At SIXE we have been dealing with infrastructure, networks and security for more than 15 years. We have seen everything from PLCs connected “a la brava” to the internet, to hospital networks where a smart coffee maker could take down a critical server. So, when we talk about Industrial Cybersecurity (OT) and IoMT (Internet of Medical Things), we don’t marry just anyone. But, if you’ve gotten this far by Googling, you probably have a major name mess. What is xDome? what is CTD? which one do I need? Don’t worry, today we’re putting on our engineering overalls to explain it to you clearly.

The big question: What is the difference between Claroty CTD and xDome?

This is the million-dollar question. Both solutions aim for the same thing: total visibility and protection of your industrial environment, but their architecture is radically different.

1. Claroty xDome (The future Cloud-Native)

It is the SaaS evolution. xDome is designed for companies that want to take advantage of the agility of the cloud without sacrificing security.

• How does it work? It is a cloud-based solution that performs asset discovery, vulnerability management and threat detection.

• The best: Deploys lightning fast and scales beautifully. Ideal if your organization already has a “Cloud First” mentality and you want to manage multiple sites from a single pane of glass without deploying tons of hardware.

2. Claroty CTD (Continuous Threat Detection – On-Premise)

It is the classic heavyweight for environments that, by regulation or philosophy, can’t (or won’t) touch the cloud.

• How does it work? Everything stays in-house. It’s deployed on your own local infrastructure.

• The best: Total data sovereignty. It is the preferred option for highly sensitive critical infrastructures (energy, defense) where data does not leave the physical perimeter under any circumstances.

SIXE’s advice: There is no one “better” than another, there is one that best suits your architecture. At SIXE we perform a thorough analysis before recommending anything.

And what does Claroty Edge have to do with all this?

Sometimes you don’t need to deploy a complete continuous monitoring infrastructure from day one, or you just need a quick audit to find out “what the heck I have connected in my plant”.

Claroty Edge requires no network changes (no SPAN ports, no complex inbound TAPs). It is an executable that you launch, it scans, gives you a complete “snapshot” of your assets and vulnerabilities in minutes, and closes without a trace.

Who does Claroty compete with and which are the best cybersecurity companies?

If you are evaluating software, names like Nozomi Networks, Dragos or Armis will surely ring a bell. They are the big “rivals” in the magic quadrant.

Which are the best? It depends on who you ask, but the technical reality is this:

1. Claroty: Undisputed leader in protocol comprehensiveness (speaks the language of your machines, whether Siemens, Rockwell, Schneider, etc.) and its integration with medical environments (Medigate).

2. Nozomi: Very strong in passive visibility.

3. Dragos: Very focused on pure threat intelligence.

Why did SIXE choose Claroty? Because we understand what’s underneath the software. IT/OT convergence is complex and Claroty offers the most complete suite (Secure Remote Access + CTD/xDome). It doesn’t just tell you “there’s a virus”, it allows you to manage third-party remote access (goodbye to insecure vendor VPNs) and segment the network correctly.

If you want to learn more about how industrial safety standards compare globally, you can take a look at the following standards IEC 62443which is the bible we follow for these implementations.

Implementing Claroty is not just about installing, it’s about understanding

This is where we come in. A powerful tool configured by inexperienced hands is just a generator of noise and false positives.

At SIXE we do not limit ourselves to implementation, we think about:

• Design the architecture: We plan where to put the sensors (SPAN Ports, TAPs) so as not to generate latency. The plant can NOT be stopped.

• Fine-tune policies: A false positive in a plant can mean an engineer running at 3 am. We adjust the tool to the reality of your protocols (Modbus, Profinet, CIP).

• Train your team: We train your SOC to understand that an OT alert is not the same as an IT alert.

👉 Discover how we implemented Claroty at SIXE

When CERN needs to store and process data from the Large Hadron Collider ( LHC, the world’s largest and most powerful particle accelerator), scale is everything. At this level, technology and economics converge in a clear conclusion: open source technologies such as Ceph, EOS and Lustre are not an “alternative” to traditional enterprise solutions; in many scenarios, they are the only viable way forward.

With more than 1 exabyte of disk storage, 7 billion files y 45 petabytes per week processed during data collection campaigns, the world’s largest particle physics laboratory is moving into a field where the classical models of capacity licensing models no longer no longer make economic sense.

This reality, documented in the paper presented at CHEP 2025, “Ceph at CERN in the multi-datacentre era”, reflects what more and more universities and research centers are finding: there are use cases where open source does not compete with enterprise solutions.reflects what more and more universities and research centers are realizing: there are use cases where open source does not compete with enterprise solutions, it defines its own categoryIt defines its own category, for which traditional architectures were simply not designed.

CERN: numbers that change the rules

The CERN figures are not only impressive; they explain why certain technologies are chosen:

• >1 exabyte of disk storage, distributed over ~2,000 servers with 60,000 disks.

• >4 exabytes of annual transfers.

• Up to 45 PB/week and sustained throughput >10 GB/s sustained throughput in data collection periods.

Architecture is heterogeneous by necessity:

• EOS for physics files (more than 1 EB).

• CTA (CERN Tape Archive) for long-term archiving.

• Ceph (more than 60 PB) for blocks, S3 objects and CephFS, backing up OpenStack.

It is not only the volume that is relevant, but also the trajectory. In a decade, they have gone from a few petabytes to exabytes. without disruptive architectural leapsadding nodes commodity horizontally. This elasticity does not exist in the proprietary cabins with capacity licenses.

The economics of the exabyte: where capacity models fail

Current licensing models in the enterprise market are reasonable for typical environments. for typical environments (tens or hundreds of terabytes, predictable growth, balanced CapEx and OpEx). They provide integration, 24×7 support, certifications and a partner ecosystem. But at petabyte or exabyte scale with rapid growth, the equation changes.

• At SIXE we are IBM Premier Partnerand we have evolved towards capacity-based licensing.
  • IBM Spectrum Virtualize uses Storage Capacity Units (SCU)~1 TB per SCU. The annual cost per SCU can range from 445 y 2.000 €depending on volume, customer profile and environmental conditions.

  • IBM Storage Defender uses Resource Units (RUs). For example, IBM Storage Protect consumes 17 RUs/TB for the first 100 TB and 15 RUs/TB for the next 250 TB, allowing resiliency capabilities to be combined under a unified license.

• Similar models exist at NetApp (term-capacity licensing), Pure Storage, Dell Technologies and others: pay for managed or provisioned capacity..

All of this works in conventional enterprise environments. However, manage 60 PB under per-capacity licensing, even with high volume discounts, can translate into millions of euros per year in software alonewithout counting hardware, support or services. At that point, the question is no longer whether open source is “viable”, but rather whether it is is there any realistic alternative to it for these scales.

Technical capabilities: an already mature open source

The economic advantage would not apply if the technology were inferior. This is not the case. For certain AI and HPC loads, the capabilities are equivalent or higher:

• Ceph offers unified storage virtualization with thin provisioning, compression at BlueStore, snapshots y COW clones without significant penalty, multisite replication (RGW and RBD), and tiering between media, and if you want your team to understand how to take advantage of Ceph, we have…
  • Ceph initiation course
  • Advanced Ceph course
• CERN documents multi-datacenter strategies for business continuity and disaster recovery using stretch clusters y multisite replicationwith RPO/RTO comparable to enterprise solutions.

IBM recognizes this maturity with IBM Storage Ceph (a derivative of Red Hat Ceph Storage), which combines open source technology technology with support, certifications and SLAs enterprise level. At SIXEas an IBM Premier Partnerwe implemented IBM Storage Ceph when business support is required and also Ceph upstream when flexibility and independence are prioritized.

Key architectural difference:

• IBM Spectrum Virtualize is an enterprise layer that manages heterogeneous storage from blockwith dedicated nodes or instances, and advanced mobility, replication and automation features.

• Ceph is a native native distributed system that serves blocks, objects and files from the same horizontal infrastructureeliminating silos. At pipelines for datasets, blocks for metadata, file shares for collaboration – this unification brings clear operational advantages clear operational advantages.

Large-scale AI and HPC: where the distributed shines

The training training of foundational models read petabytes in parallel in parallelwith aggregate bandwidths of 100 GB/s or more. The inference requires sub-10 ms latencies with thousands of concurrent requests.

Traditional architectures with SAN controllers controllers suffer bottlenecks when hundreds of GPUS (A100, H100…) access data at the same time. It is estimated that about 33 % of GPUs in corporate AI environments operate at less than 15 15 % utilization due to storage saturationwith the consequent cost in underutilized underutilized assets.

Distributed architectures architectures –Ceph, Lustre, BeeGFS– were born for these patterns:

• Luster drives 7 of the 10 supercomputers in the Top500supercomputers, with >1 TB/s aggregate throughput in large installations. Frontier (ORNL) uses ~700 PB in Lustre and writes >35 TB/s sustained.

• BeeGFS scales storage and metadata independently independentlyexceeding 50 GB/s sustained with tens of thousands of customers in production.

• MinIOoptimized for objects in AI, has demonstrated >2.2 TiB/s read performance in training, difficult to match by centralized architectures.

Integration with GPU has also matured: GPUDirect Storage allows GPUs to read from NVMe-oF without passing through the CPU, reducing latency and freeing up cycles. Modern open source systems support these protocols. nativelyin proprietary solutions, they often rely on firmware y certifications that take quarters to arrive.

SIXE: sustainable open source, with or without commercial support

Migrating to large-scale open source storage is not trivial. Distributed systems require specific experience.

At SIXE we have been more than 20 years with Linux y open source. Like IBM Premier Partnerwe offer the best of both worlds:

• IBM Storage Ceph e IBM Storage Scale (formerly Spectrum Scale/GPFS) for those who need Guaranteed SLAs, certifications y 24×7 global support.

• Ceph upstream (and related technologies) for organizations that prefer maximum flexibility and control maximum flexibility and control.

It is not a contradictory position, but a strategic strategicdifferent profiles, different needs. A multinational bank values certifications and enterprise support. A research center with strong technical equipment can operate upstream directly.

Our intensive training at Ceph are hands-on workshops from three-dayThe workshops are three days: real clusters are deployed and design decisions. Knowledge transfer reduces the dependence on consultants and empower to the internal team. If your team still has little experience with Ceph, click here to see our initiation course, if on the other hand you want to get the most out of Ceph, we leave you here the advanced Ceph course, where your team will be able to integrate two crucial technological factors right now: Storage + AI.

Our philosophyWe do not sell technology, we transfer capacity. We deploy IBM Storage Ceph with full support, Ceph upstream with our specialized support or hybrid approacheson a case-by-case basis.

The opportunity for massive data and science

Several factors align:

• The data is growing exponentially: a NovaSeq X Plus can generate 16 TB per run; the SKA telescope telescope will produce exabytes per yearAI models demand datasets datasets.

• The budgets do not grow at the same pace. The capacity licensing models make unfeasible to scale proprietary systems at the required pace.

Open source solutions, whether upstream o commercially supported (e.g., IBM Storage Ceph), eliminates this dichotomy: growth is planned by hardware cost y operational capacitywith software whose costs do not do not scale linearly per terabyte.

Centers such as Fermilab, DESY, CERN itself CERN or the Barcelona Supercomputing Center have demonstrated that this approach is technically feasible y operationally superior for their cases. In its recent paper, CERN details multi-datacenter for DR with Ceph (stretch and multisite), achieving availability comparable to enterprise solutions, with flexibility and total control.

A maturing ecosystem: planning now

The open source storage ecosystem for HPC e AI is evolving fast:

• Ceph Foundation (Linux Foundation) coordinates contributions from CERN, Bloomberg, DigitalOcean, OVH, IBMamong others, aligned with real production needs.

• IBM maintains IBM Storage Ceph as a supported product and actively contributes upstream.

It is the ideal confluence between open source innovation y enterprise support. For organizations with a horizon of decadesthe question is no longer whether adopt open source, but when and when and how do so in a structured structured way.

The technology is matureThe technology is mature, the success stories are documented and support exists in both community community and commercial. What is often missing is the expertise to draw up the roadmap: model (upstream, commercial or hybrid), sizing, training y sustainable operation.

SIXE: your partner towards a storage that grows with you

At SIXE we work at that intersection. Like IBM Premier Partnerwe gain access to world-class support, roadmaps y certifications. At the same time, we maintain deep expertise in upstream and other ecosystem technologies, because there is no one-size-fits-all solution one-size-fits-all solution.

When a center contacts us, we don’t start with the catalog catalogbut with the key key questions:

• What are your access patterns?

• What growth project?

• What capabilities does your equipment have?

• What are the risks can you assume?

• What is the budget budget (CapEx/OpEx)?

The answers guide the recommendation: IBM Storage Ceph with enterprise support, upstream with our support, a hybrid, or even evaluate if a traditional solution still makes sense in your case. We design solutions that work for 5 and 10 years, the important thing for us is to create durable and sustainable solutions over time ;)

Our commitment is to sustainable technologiestechnologies, not subject to commercial fluctuations, that provide control over infrastructure and scale technically and technically and economically.

The case of CERN is not an academic curiosity: it shows where storage for data-intensive loads is going. data-intensive loads. The question is not whether your organization will get there, but whether it will how will arrive: ready o on the run. The window of opportunity to plan calmly is open. open. The successes exist. The technology is ready. The ecosystem also. It remains to take the strategic decision to invest in infrastructures that will accompany your organization for decades to come. decades of data growth.

Contact us!

Does your organization generate massive volumes of data for AI o research? At SIXE we help research centers, universities, and innovative organizations to design, implement and operate storage scalable with Ceph, Storage Scale and other leading technologies, both upstream as with IBM business supportaccording to your needs. Contact us at for a no-obligation strategic consultation.

References

• Goggin, Z., Lekshmanan, A., Valverde, R., & Bocchi, E. (2025). Ceph at CERN in the multi-datacentre era.. EPJ Web of Conferences, 337, 01331.

• CERN Storage Group. (2024). CERN’s Open Source Storage Systems. FOSDEM 2024.

• Linux Foundation. (2024). Ceph, the Default Choice of Enterprise Storage for Mission Critical Workloads.

• IBM. (2024). IBM Storage Defender: Unified data resilience with Resource Units licensing.