Intro
For the longest time, SchedMD treated the Devil with suspicion. FreeBSD, with its horned mascot and outsider reputation, wasn’t exactly invited onto the Slurm dance floor. At best, the Beastie might be allowed to linger at the edge of the club — patches tolerated, but never really welcomed.
Previous port Maintainers used to sneak their fixes in like someone hoping the bouncer wouldn’t notice the horns under their hood, quietly patching things up while the main party carried on inside. But this month felt different: one of my patches actually made it upstream. And suddenly, the Devil wasn’t just standing in the corner anymore — SchedMD had turned, offered a hand, and maybe, just maybe, the dance had begun.
Background and insight
So why do I even dare accuse SchedMD of being difficult dance partners for Beastie folks like me? Well, the commit history speaks volumes: only a handful of tiny FreeBSD patches ever made it upstream, and only if they didn’t brush up against the Linux-only code. Anything more serious? Straight to the corner of the club.
Digging through old FreeBSD Slurm issues, I even crossed paths with Jason W. Bacon, the original porter of Slurm. He confirmed what I suspected — he walked away from Slurm largely because upstream simply wasn’t responsive to FreeBSD-related submissions. (For the curious, that conversation is still archived here: Bug 276001)
I’ll be honest: hearing that history made me briefly regret picking Slurm as my first port to maintain. It felt like setting up my dance shoes just to find out the band refused to play. Frustration was very real. But instead of bowing out, I chose to let motivation overrule it. After all, it wasn’t a fatal error — just a compiler warning.
And choosing Slurm was no random shot in the dark. It was a deliberate strategic move. Slurm is the workload manager at most Tier-1 and Tier-0 HPC centers — the giants of the supercomputing world. If there’s any chance of getting those big players to experiment with or even migrate towards FreeBSD, the prerequisite is clear: Slurm has to run seamlessly.
The Turning Point
So, instead of letting frustration take over, I doubled down. I kept opening upstream submissions and tracked them carefully. After about a month of radio silence, I sent a friendly ping — not pushy, just enough to get my patches back on the radar.
And to my surprise, there was movement! My submissions had been assigned to team members. That already meant my pings weren’t vanishing into the void — someone was actually listening.
Then came the big moment: a reply on my oldest ticket, from SchedMD developer Tim McMullan. Not only did he acknowledge the patch, he said it looked good — and even better, that they were considering how to apply it across all the BSDs. That was huge. For the first time, this wasn’t just FreeBSD sneaking past the bouncer; it was recognition that the Devil might actually be a worthy dance partner. And not only the Devil — the Pufferfish and the Flag were being invited, too. A win for the whole BSD family in terms of HPC readiness.
What’s more, Tim shared a cleaned-up, generalized patch for *BSD compatibility. I tested it successfully across FreeBSD, OpenBSD, and NetBSD, reported back, and upstream confirmed. Shortly after, the patch was merged as commit d9f8f18f03. You can read the full exchange in SchedMD ticket #23388.
This wasn’t just a patch; it was a signal. SchedMD isn’t just tolerating horns in the club anymore — they’re willing to step onto the floor and dance. And maybe, just maybe, they’re even considering starting their own *BSD compatibility efforts internally.
The Dance
Tim has since taken on my other submissions as well, which feels like clear proof that the dance has truly begun. My role now is to keep assisting with testing, authoring new patches, and reporting issues as I uncover them. The aim is simple: get as much functionality working as possible — and where it doesn’t, find replacements — so that one day Slurm runs on BSD as smoothly as it does on Linux.
What makes this moment exciting is that the work is no longer a solo effort. Upstream support means my FreeBSD patches can be generalized across all the BSDs, letting the whole family share in the progress. Instead of slipping unnoticed into the club with horns hidden under my hood, Beastie now has a real partner to dance with.
So here we are, stepping onto the floor together. The music has just started, the rhythm is still new, but the potential is real. With cooperation, BSD can become a fully recognized platform in the HPC world — one that helps save power, optimize capacity, and broaden the ecosystem.
So, SchedMD — shall we keep dancing into that promising future?
Disclaimer
I am not associated with the FreeBSD Project, the OpenBSD Project, or the NetBSD Project. I work independently and have no association with them.
I have a history of developing software and working with FreeBSD in private projects of mine. I mainly program in C, or C++ but am also familiar with developing in C#, python, java, php x mysql webapps and of course shell scripts. I maintain multiple virtual servers on a few physical servers, some of them run FreeBSD, some Linux. I started getting into the development of FreeBSD ports in summer 2025, by submitting multiple commits to the sysutils/slurm-wlm port, to ultimately gain Maintainership over it. I am now actively maintaining that port and am trying to get more involved into the FreeBSD project, since i have always been fascinated about the system.