Thank you for joining the Omarchy Space today @letsbuildanyway and @NotJustShaking ! You guys are awesome!

Omarchy Sunday Social: Demystifying Plugins X @XSpaces Episode 2 Listen here: nitter.cf/i/spaces/1wxWjloyOYnJQ WHO WAS IN THE ROOM: 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 room of 108 people who matter. PART ONE: WHAT WE TALKED ABOUT Follow everybody!!!! 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. Same house rules as last week. No politics, no egos. We did talk about the controversy and I think that stayed inside the lines. As Wes put it: there is plenty of negative noise out there and plenty of other avenues for it. This is not one of them. What a plugin actually is, and the mental shift that has to happen first Omarchy shifted 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 in that mindset. They download plugins and comment asking if you can make it do one small extra thing. I am not judging anybody for that, but do it yourself. You can. Wes and I are not a programmer. Last week we talked about why agents give infrastructure people a bigger boost than programmers. 2X an infrastructure guy and it does not help much, I am already okay at that. What helps is thinking of an idea and making it real. And do not let the agent limit you to a language you know. I tell mine: code it in whatever you think is best. Drive the idea, let it pick the tools. Wes' version: when computers first showed up, plenty of people were scared to touch them in case they broke something. With Omarchy and an agent there is even less reason for that fear. Please break it. Please touch it. Please mess with it. Two first plugins, and neither of them was impressive Wes 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 and Open Meteo were already being called and already returned sunrise and sunset. So the whole ask was: grab it from the same call and put it in a row under the forecast with an icon for each. All natural language. Then you iterate. He compared it to SimCity. 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 two decimal places and 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. I lean on people for the things out of my grasp. 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 yours. When your agent finds a bug in the fork, send a PR back upstream. That is how this grows. Full disclosure: I found OmaWeather plugin before I knew him, 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. 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 Wes: "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. 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. The barrier is not 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. Wes 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, 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. 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. Wes 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. 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 as disaster recovery and one 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. 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. Wes' example: OmaStorm has a quickshell popover plus a background engine. The scan came back saying the engine might download more files than needed and fill people's disks. Good feedback. He fixed it, edited the issue, they rescanned, 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. Wes' 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 or break everybody's config. Wes' 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. @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. 7Wes' 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. Sleep on it 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. 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 what he 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 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. Wes 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. 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, saving 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 worth it. He is looking for people to work on it with him. Wes' read: too many man hours go into the frontier models 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 Wes 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 Wes why he had been hunting for a good Rust repo, and the answer generalizes past Rust. 25 years of software behind him but he 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 Heath 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 and has worked on a 5,000 GPU system and a 250,000 core supercomputer. He is relentlessly humble about 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. Wes 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 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 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, and Wes; 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. 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 submission is great and also a little scary, because it is using your credentials. Nobody had a policy for that. What should an agent 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? Q4. What does a small local Omarchy model need to be good at? @cfaulkingham reported back: overfits easily, has to run on a potato, automatable but weak without human curated training data. Competing on general capability is a losing fight. So what is the narrow job where a tiny local model beats 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 asks their 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? Wes 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. 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 Wes directly and we should have. Q8. 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. It is 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. Wes wants 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 meanwhile. @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. 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 Wes for co-hosting, to @hancore_linux for the marketplace and for dropping in, and to everybody who spoke. Every episode, summary and transcript: spaces.nixfred.com See you next week.. everybody's a special guest. See you next Sunday!