Omarchy Sunday Social: Demystifying Plugins Omarchy! Omarchy! Omarchy! X Spaces, Episode 2 Listen here: https://x.com/i/spaces/1wxWjloyOYnJQ Recorded Sunday, September 20, 2026. 62 RSVPs, a room that kept filling, and the marketplace maintainer himself dropped in near the end. See you next Sunday, 3pm EST. Last week was a free-for-all and it was fun. This week we picked a subject and stayed on it: what a plugin actually is, how you get started, how you iterate, and how you share it. Then we opened the floor and the room turned out to be full of people building things nobody had heard about yet. That second half is the good part. WHO WAS IN THE ROOM: @ncfrontiersman Wes Grimes, co-host, built OmaStorm. 25 years a software developer, "got a little bored in the career, but man, Omarchy has just injected my veins with adrenaline." Me, co-host: Blip, Infomarchy, Burnbar. @hancore_linux, who runs the plugin marketplace and joined us for the first time. @m_tolhuijs, who built OmarKit because he watched @hancore_linux's issue list and thought we should help. @cfaulkingham, who has been fine tuning a local model for Omarchy and will tell you honestly how hard it is. @thetundeo in London, hosting the London meetup this Thursday. @MuchmoreIT, who designs high performance computers for the federal government and has been on a 5,000 GPU system and a 250,000 core supercomputer. @ZryMiller Zach, building a voice transcription and agent management app called Soto. @NoPowerPoints David, who published HyperTile Equalizer and GitHub Repo Tracker. Mihai, who got an Unreal Tournament engine running on Omarchy. Plus a room of people who listened, which counts. PART ONE: WHAT WE TALKED ABOUT Follow everybody Before anything else. X used to have this nonsense about follower ratios. Throw that crap out. If somebody follows you and they have Omarchy in their title, follow them back. There is no ego here and the follower count does not matter. Send DMs, make connections. It costs you nothing. Same house rules as last week. No politics. No egos. We did talk about the controversy going on, and I think that stayed inside the lines. As @ncfrontiersman put it: there is plenty of negative noise out there and plenty of other avenues for it. This is not going to be one of them. What a plugin actually is, and the mental shift that has to happen first Omarchy shifted away from "download the application somebody else made" to "customize your own bar." That is a technical change, but the real change is in your head. My grandmother used to say, "You get what you get, you don't pitch a fit." For decades that was computing. The binaries were locked down and if you wished the software did one more thing, tough. A lot of newcomers are still standing in that mindset. They download plugins and comment underneath asking if you can make it do one small extra thing. I am not judging anybody for that, but I want to encourage them: do it yourself. You can. That is the whole point now. I am not a programmer. Last week we talked about why agents give infrastructure people a bigger boost than they give programmers. 2X an infrastructure guy and it does not help much, I am already okay at that. What helps is being able to think of an idea and make it real. And do not let the agent limit you to a language you happen to know. I tell mine: code it in whatever you think is best, Python, Rust, whatever. Drive the idea. Let it pick the tools. @ncfrontiersman's version of the same point: when computers first showed up, plenty of people were scared to touch them in case they broke something. He never had that fear but watched people who did. With Omarchy and an agent there is even less reason for it. Please break it. Please touch it. Please mess with it. Two first plugins, and neither of them was impressive @ncfrontiersman liked the built in Omarchy Weather plugin but wanted sunrise, sunset and moon phase on it. So he opened his agent, cloned the plugin, and asked for it. Cloning is built in: the agent reads the Omarchy skill, copies the built in plugin into your own config, and it is yours to edit. Nothing is compiled, so it reloads in front of you while the agent works. "It's almost like building a web page." The data was already there. Weather.in and Open Meteo were already being called and already returned sunrise and sunset. So the whole ask was: grab that from the same call, put it in a row under the forecast, give me an icon for each. All natural language. Then you iterate. He compared it to SimCity, building it up until it is yours. Mine was worse. My first change was not even a plugin. I took the calendar in the center of the bar and added a small bar showing what percentage of the year we are through. That was it. Then I tweaked it to show two decimal places, and I thought, wow, it did it. We are 71.94% through the year, by the way. Here is why I tell that story. Even I was not thinking big enough, and I am reasonably good at the AI part. If you are learning Omarchy and AI at the same time, that is a wall. But the second one was bigger than the first, and the third bigger than that. Infomarchy started as something just for me and it was crap. Then about 15 people started contributing and finding things I had no idea about. @gh_TechLuddite has sent me stuff I read and thought, I do not know what he is talking about, but he is smart. There are still things out of my grasp. I lean on people for those. Fork it. It is legal, and it is good manners to send something back. There are no completely unique ideas. If a plugin is close to what you want, the license usually says you can fork it and make it your own, and that is the fastest path to something you actually like. When your agent finds a bug in the fork, send a PR back upstream. That is how this grows. Full disclosure: I found @ncfrontiersman's plugin before I knew @ncfrontiersman, before any of this, and the first thing I did was fork it. I did DM him to ask if he minded, out of politeness, and he said go ahead. One correction from the show. I credited the Trackpad plugin to "a guy named Fanta, I think it's David" and apologized in advance for getting it wrong. It is @davidfano. Sorry David, and thank you for the plugin. The @dhh clip, which did not play I tried to play a clip from @dhh's interview with @0xSero and the audio never made it into the room. My fault, I will do better next time. Here is what it said. @dhh, on @ncfrontiersman: "He's been working on this thing called OmaStorm. So it tracks storms going over your area. And he put it into the weather widget that we have in Omarchy. It looks incredible. We're going to ship it in the next version. But here's a guy who just went like, well, I like storms. I want to see this lightning. I want to see where it's moving. He would not have done that before." And the number in that same clip, already out of date when he said it: 3,000 plugins created for Omarchy in three weeks. @ncfrontiersman's response to all of it was the most @ncfrontiersman thing possible: "It ain't about me. I would love to see everybody on this call have that opportunity." The barrier to entry is lower than it has ever been. Build the thing you personally love, share it, and see who else needed it. The elephant in the room A lot of the Arch Linux crowd is angry right now, and I want to talk about why without turning this into a fight. Linux has been hard to use for a long time. For some people that difficulty became their identity. Running Arch was a badge of honor, ironically or not, because it meant you were willing to learn the hard stuff and break things and fix them. Omarchy changed that equation. The barrier is not your technical ability anymore. It is curiosity, persistence, and the desire to just do it. That opens the door to a completely different group. Some of the pushback is the feeling that something small and yours is becoming available to everybody. From the inside, that reads as a loss. People handle loss two ways. They adapt and move forward, or they rebuild the wall around a smaller group. You can see both. Some look at Omarchy and think, good, more people are coming to Linux. Others are building a new badge of honor around not needing Omarchy. Now the cool kids run something harder, configure everything themselves, and can list all the reasons Omarchy is doing it wrong. Same wall, different garden. There is a much more interesting move available to them. If Omarchy made the hard layer of Linux dramatically easier, then the people who liked hard problems should go find the next hard layer. Push into the kernel. Solve power management. Improve Wayland. Make gaming better. If difficulty is part of your identity, good news: there is an endless supply of difficult things left. Omarchy did not take away the frontier. It moved it forward. @ncfrontiersman went further: he bets that if we actually got to talk to them, a lot would change their minds. People scan headlines, pick a side, and miss the nuance. He wants a big tent, because there are hard problems left and we need the people with the scar tissue, who have the muscle of sticking with something until it is solved. Those skills matter more now, not less. AI generating the code does not mean the thinking is done. You should never outsource your thinking to it. And if they do not come over, that is fine too. You can lead a horse to water. Build what you need. That is the whole strategy. All of my stuff is for me. If I need it, I build it, and I hope when I put it out someone else needed it too. Occasionally it resonates. Burnbar 2.0 went out right before the Space for exactly that reason: I was not budgeting my subscription tokens well, so now it tells me when to stop for the day. @ncfrontiersman said the same from the other direction: it goes better when you take something you built for yourself and cared about than when you try to work out which plugin would go viral. Focus on what you know. Somebody else likes the same stuff you do. That is also where @dhh's point about capitalism lands. The old guard was openly anti-capitalist and then surprised nobody funded them. Build something good, and what matters to you will matter to somebody else. Five ways to put a plugin out there 1. Keep it to yourself. Completely fine. I have about 30 forks that will never be published because they are only for me. 2. Post it on X and code in the open. 3. Host your own plugin site. I did that at omarchy.nixfred.com, mostly as disaster recovery and a single place to install everything on a new box. 4. Submit it to the official marketplace. You do not have to: anyone can point the omarchy plugin command at a GitHub URL and install directly. But it is where people discover things, and it is not much effort. 5. Facebook, I suppose. You will not find me there. I sold storage to them years ago, they pulled me aside and showed me everything they knew about me, and I deleted my account that afternoon. What submitting actually looks like Point your agent at the publishing docs and have it walk you through. You open an issue on the plugin repo, answer a few questions, and automated checks run against your code. @ncfrontiersman's real example: OmaStorm has a quickshell popover plus a background engine. The scan came back and said the engine might download more files than needed and fill people's disks. Good feedback. He fixed it, edited the issue, they rescanned, and it passed. One of the checks is the commit SHA, so the code they verified is the code on your main branch. To re-trigger a check you edit the issue and update it. @NoPowerPoints raised a real gotcha: sometimes the fix is editing the anchor point in the submission rather than pushing a fix and expecting it to get picked up. There is a sequence, and it is learned the hard way. @ncfrontiersman's advice, and it is the big one: tell your agent at the very beginning that you intend to publish, and have it keep the requirements in mind while you build. Much cheaper than building a pile of things that will never be accepted. And once people use your thing, you have customers whether you wanted them or not. Do not rip a feature out from under them. Do not change the config shape and break everybody. @ncfrontiersman built OmaStorm on an x86 VM, shipped an x86 only Rust binary, and heard from people it would not install on ARM64. Now he ships both. You find that out by shipping and listening. Prior art, and not wasting tokens I have been burned on this more than once. Partway into building something I stop and tell my agent: go see if somebody already did this better. It comes back with "15 people have tried this and 17 of them are better than you." Damn it. Tokens gone, time gone. Do that first. Then fork the best one and make it yours. @ncfrontiersman called it by its real name: prior art. Before agents, the first step on any problem was finding out if somebody already solved it. That has not changed. @ZryMiller added the part nobody says out loud: agents will gaslight you into thinking your idea is the most unique in the world. Push back. Ask it directly. "Oh, yep, there are 30 applications that already do this and they do it better." @ZryMiller also asked the question none of us fully answered: when do you actually launch? He is building Soto on Windows, voice transcription plus agent management, close to T3 Code, and plans to port it to Omarchy in something more native than Electron because Omarchy people want things they can customize. His plan was to ship when he uses it daily without hitting constant bugs, and he is not sure that day comes. My answer: keep the first feature set as small as you can stand. If you build all 15 features up front, you are playing whack a mole forever. He admitted he is already way too deep in features. That is most of us. And treat the agent like a person you are training. Three minutes of instruction gets you three minutes of results. Spend a day teaching it what you want and it gets much better. I treat Larry like a coworker and told him to push back on me and be snarky about it. Three tips before you submit Do not submit on the day you build it. Even if you are happy with it, sleep on it for a week and you will find something to make better. I get my best ideas away from the machine, walking the dog. Open it up to PRs. Let other people in. That is where the stuff you did not know about comes from. Bring patience. @hancore_linux has a lot on his plate. OmarKit: run the marketplace pipeline on your own machine first @m_tolhuijs built OmarKit for exactly the problem everyone had been circling. He watched @hancore_linux's issue list and thought, we need to help this guy. So OmarKit runs the whole marketplace pipeline locally: the same tests, plus the things @m_tolhuijs reviews himself, because he knows what AI tends to get wrong. He comes from a Laravel background and wanted test driven development for agent written code, something that can tell the AI flatly, no, this is not good. It has verify and inspect commands, and he is building a run command that wraps your plugin so the failure modes @hancore_linux checks for, memory leaks and similar, cannot happen in the first place. His honest take on skills: they are genuinely nice and a lot of work has gone into them, but they only go so far. "I had so many countless moments where I said, did you completely ignore what I just said here." That is why OmarKit exists. It is released, somebody from the community has already tested it successfully, and he wants people to try it. @ncfrontiersman has been working the same seam from another angle: a dev loop that symlinks your plugin into the plugins directory, installs it, runs it, and removes it when you kill the command, so you get web style hot reload while building. He offered to contribute it. Two tools that already exist and deserve more attention @cfaulkingham came in with the practical answer to everything we had just spent ten minutes wondering about. There is an Omarchy security skill on GitHub. Search "Omarchy security skill" and it comes up. It is by @jankeesvw. @cfaulkingham used it on two of his plugins with great success, and it saved him the repeated cycle of CI throwing issues back at him. Same author, another tool: OmaVM, which spins up Omarchy VMs on Omarchy so you can test your plugin in a clean machine. @cfaulkingham said those two helped him more than anything else. He also did not plug his own plugins, which is very him, so I will: a couple are in the directory and the rest are on his GitHub. The local model report from somebody who actually tried it Last week the room talked about a small local model trained on Omarchy. @cfaulkingham went and did it, and came back with an honest result. He started with a LoRA adapter aiming to replace the default Omarchy skill, and used OmaVM to test it. He found a LiquidAI model that runs acceptably on modest hardware, because as he put it, it has to run on a potato, and not many models do. Basic testing was not bad. But it is harder than he expected. It overfits very easily. He automated the training runs with Grok deciding what to change each round, and you can automate nearly all of it, but without a lot of human input on the fine tuning data it will not be good enough to be worth it. He is looking for people to work on it with him. @ncfrontiersman's read: there are so many man hours going into the frontier models that it is hard to compete on general capability. The interesting question is what a small model only has to be good at. @thetundeo on how to start a meetup: just do it I asked @thetundeo for the secret to the London meetup, since it has more people signed up than most of us could manage. He corrected me: it has not happened yet, it is Thursday. So @ncfrontiersman asked him prophetically what the secret is. "Honestly, I just did it. I didn't overthink it." He saw @dhh's post about the WhatsApp exchange with Toby around funding, pulled the car over, and called a friend. The friend had not even heard of it and said "Oma what?" @thetundeo told him, just trust me, give me a venue and I will sort out the rest. They gave him the venue. He added that this is very unlike him. That is the part worth hearing. He also asked @ncfrontiersman why he had been hunting for a good Rust repo, and the answer generalizes past Rust. @ncfrontiersman has 25 years of software behind him but never touched Rust, so his method is to find exemplary codebases that are not just pretty but performant and healthy, point the agent at them, and pull out the patterns and the places people hit pain. Then distill that into a style guide made of code examples. His finding: writing a pile of rules into agent docs saying do this, do not do that, works worse than simply showing good examples. Show me a well structured controller, model and view. Do not describe them. Agents follow examples better than instructions. @MuchmoreIT: ROCm 10.0, a Grace Blackwell box, and Omarchy Fort Knox @MuchmoreIT has been a friend of mine for 20 years. I cannot say where he works, and that is legitimate rather than me being coy. He designs high performance computing and AI systems for the federal government, talks to Department of Energy people for a living, and has worked on a 5,000 GPU system and a supercomputer of roughly 250,000 CPU cores. He is relentlessly humble about all of it. Three things he is working on: He got ROCm 10.0 running on his AMD Omarchy machine, which took spoofing the device ID. Next he wants an Arch derivative underneath so it runs cleanly from an Omarchy perspective. His note for the AMD people: ROCm 10.0 brings massive performance improvements. He picked up a Dell GB10, the Dell equivalent of an NVIDIA Spark: Grace Blackwell, ARM CPU paired with NVIDIA GPUs. It is on DGX OS right now, which is Ubuntu derived, and somebody has already done part of the work to get Omarchy on Grace Blackwell. He is going to benchmark one against the other. And the long one: shortcuts for federal customers who would want Omarchy. That means a crypto validation suite tested at NIST, which he puts at the better part of a year, plus the hardening checklist that makes a system acceptable in a federal environment. @ncfrontiersman named it on the spot: Omarchy Fort Knox. It is also the end of the federal fiscal season, so he is buried for the next few weeks. @hancore_linux, who runs the marketplace, showed up He joined because I asked him to, and I am glad he did. He had spent the day on maintenance and necessary updates, and was upfront that he had not had much time for improvements this past week. Anyone watching the queue noticed. The news: a new marketplace is coming, with a new submission system. @ryanrhughes is building the backend and @hancore_linux has been supporting on the frontend. He did not want to spoil it, since @ryanrhughes or @dhh will announce it properly, but he said it is taking shape. On pre-validation his answer was honest. Use what exists: OmarKit, and the security skill. He cannot yet predict how the new system will check submissions. It will be agent checked, but how deep and what it requires is not settled. Mihai got Unreal Tournament running He reverse engineered an Unreal Tournament engine into working on Omarchy, and got it running on Omarchy Mac too, which was meaningfully different from the x86 side. It runs well on the current kernel. We lost his connection before we could ask anything else, which is a shame, because that is a hell of a thing to do on a Sunday. PART TWO: THE QUESTIONS STILL UNANSWERED Last week we ended with twelve open questions. Several got answered this week, which is the point. These are the ones still standing. Q1. How do you know what the marketplace will check before you submit? This came up three separate times from three people who had never spoken to each other. @NoPowerPoints asked it directly. @m_tolhuijs built OmarKit to solve it. @cfaulkingham found jankeesvw's security skill and OmaVM. @ncfrontiersman points his agent at the marketplace source to work out the checks ahead of time. @hancore_linux says a new submission system is coming but cannot say what it will require yet. Three partial answers, no official one. Does a preflight skill ship with the new marketplace, or does the community keep owning this? Q2. Is it safe to let an agent do the submission for you? @NoPowerPoints said the quiet part: having the agent run the initial submission is great, and also a little scary, because it is using your credentials. Nobody in the room had a policy for that. What should an agent be allowed to do with your GitHub credentials, and what should always be a human pressing the button? Q3. When is a thing ready to ship? @ZryMiller asked and we gave him tactics, keep the feature set small, but not an answer. He is waiting for the day he uses it without hitting constant bugs and suspects it never comes. What is the actual signal that a thing is ready to put in front of people? Q4. What does a small local Omarchy model actually need to be good at? @cfaulkingham did the work and reported back: overfits easily, has to run on a potato, automatable but weak without serious human curated training data. Competing on general capability is a losing fight. So what is the narrow job where a tiny local model beats sending the prompt to the cloud, and who builds the training set? Q5. With 3,000 plugins in three weeks, how do you find prior art before you burn the tokens? Everybody now has the habit of asking the agent if somebody already built it. That is a workaround, not a system. Discovery across the marketplace, GitHub and X is still manual. Q6. Does the big tent actually work? @ncfrontiersman thinks a lot of the Arch crowd would change their minds if we got to talk to them. Nobody tested that this week. Is there a real move here, or do the walls just relocate? Q7. Fleet management and rebuilding a box from scratch. I raised it and we moved on. I run my own plugin site partly as disaster recovery, and we put import and export into Atmos as a piece of it. The Omarchy crew will probably beat me to the full answer, but right now there is not one. Q8. What happens to a community plugin when it goes into core? OmaStorm is going into the next version of Omarchy, the first time that has happened to somebody in this room. What changes for the maintainer, for the people sending PRs, and for the people who forked it? We did not ask @ncfrontiersman directly and we should have. Q9. Who does the federal hardening work with @MuchmoreIT? A NIST tested crypto validation suite is the better part of a year for one busy person. Omarchy Fort Knox is a real opportunity and right now it is one guy with a day job at the end of fiscal season. ASKS ON THE TABLE @m_tolhuijs wants people to try OmarKit and reach out. He is building it as we speak, aimed squarely at the submission pain. @cfaulkingham wants collaborators on the local fine tune. He has a LoRA adapter, a model that runs on modest hardware, and a clear view of why it is hard. @ncfrontiersman wants to see a proper plugin dev loop with hot reload, and offered to contribute his version to OmarKit. @hancore_linux wants patience while the new marketplace gets built, and recommends OmarKit and the security skill in the meantime. @MuchmoreIT is building toward federal ready Omarchy and would welcome anyone who knows that world. @thetundeo's London meetup is Thursday. If you are anywhere near, go. Everybody: follow everybody in this room. Ratios are nonsense. Send DMs. Make the connections. NEXT EPISODE Same time next Sunday, 3pm EST. Same format: come tell us what you are building and where you are stuck. If you have never built a plugin, here is your homework, and it is smaller than you think. Clone a built in plugin with your agent and change one thing about it. One. Mine was a percentage bar on a calendar and it changed how I think about computers. Do not just accept things as they are. If you can think of it, build it. And when you see somebody struggling in the comments, help them. Get their dictation working and they are off to the races. Thanks to @ncfrontiersman for co-hosting, to @hancore_linux for the marketplace and for dropping in, and to everybody who spoke. As @ncfrontiersman closed it: everybody's a special guest. See you next Sunday.