Treating Omarchy as a starting point: a supported path to taking full ownership? #9359
Replies: 1 comment 1 reply
|
I think what you're describing is perfectly reasonable, but it may also mean you have outgrown Omarchy Omarchy's value isn't the initial Arch+Hyprland setup, it's also the opinionated and continuously evolving layer of defaults, integrations, migrations and experiments. I would expect that layer to change frequently, given Omarchy's frontier nature and Arch's rolling-release model. Freezing Omarchy while continuing to receive supported system updates would effectively create another product with different compatibility and maintenance requirements. Plain Arch with your own Hyprland config, or a personal Omarchy fork that you maintain yourself might be a better fit. A documented "graduation" or migration guide could still be useful, but I don't think a detached installation should remain a supported Omarchy mode. Reaching the point to where you want to own everything yourself can also be seen as Omarchy having done its job successfully. |
Uh oh!
There was an error while loading. Please reload this page.
First: I love Omarchy. I love the idea, what it represents and what it did for me.
I've been a Linux user for a very long time, with some years of macOS in between, and Omarchy (coupled with the ecosystem gradual growth/convergence) gave me the excuse to come back. I like most of its defaults and many of its updates, but the most valuable thing it gave me was a coherent starting point.
Now I think I may be reaching the point where I want to treat Omarchy as a foundation rather than an ongoing upstream.
Concretely, I would like to:
I asked about this on Discord, and the suggested approach was roughly:
~/.config/omarchy/plugins/~/.config/hypr/configurationomarchy-updatein~/.local/bin/with behavior I controlThat sounds close to what I want, but I wonder if this could become a documented and perhaps supported path rather than an entirely personal workaround.
Maybe this doesn't require a new feature at all. A guide explaining the ownership boundaries - what Omarchy manages, what should be copied or overridden, how package channels interact with updates and how to keep following upstream changes safely - might be enough.
Alternatively, perhaps there is room for an explicit “detach” or “freeze the Omarchy layer” operation that:
I'm also interested in the philosophical side of this. An opinionated system can succeed precisely because it gives people somewhere excellent to begin. Some users may eventually want to outgrow its update stream while keeping most of its ideas. That doesn't necessarily mean abandoning Omarchy; it can mean that Omarchy successfully helped them create their own Linux system.
Is there already a clean, recommended way to do this? If not, would documentation or a supported ownership-transfer path be useful to other people?
All reactions