AI as a problem is illusion. Just don't use it. It's that easy.

“Full of security holes" - and two examples in the article have been swiftly addressed, ignoring that there is a whole dedicated security team https://omarchy.org/teams/

What kind of blogging is this?

> What kind of blogging is this?

Happy to explain: it's personal blogging, for writing down what's on my mind.

The fact that it was addressed swiftly doesn't affect the claims in the post at all: I'm worried about development practices which produce code like that.

Also, the "full of security holes" is not my framing, someone else choose this submission title.

The problem with those two picked examples is that their nature displays a lack of basic care and due diligence.

Of course, this is a culture war, but the point the blog post is making is that the Omarchy side is not exactly at the forefront of merit.

The same kind as a similar recent post [1] where a person pointed out a bunch of problems with Omarchy's shell scripts as examples of it being terrible.

Open a pull request.

That's how this is supposed to work. Wisdom of the crowd and what not.

1. https://xn--gckvb8fzb.com/a-word-on-omarchy/

Why would I do that? It's a crazy non-sequitur.

My opinion is that the way Omarchy is developed leads to gigantic security holes. I wanted people to be aware of it.

In my opinion, there are much better choices both for me and I'd imagine for other people as well. I don't want to help Omarchy succeed, I don't care about them.

Because you could make the world a better place instead of just complaining about it? I don't understand the "all I wanna do is complain" process at all.

Fix it. If you see a problem in the world, fix it.

If they reject the fix, that's when you complain.

I dont just complain. I making the world a better place in ways which I believe are worth it.

Improving Omarchy seems like a waste of time to me. Letting people know how insecure it likely is, given how little time it took, is much better bang for buck.

Or, in colourful analogy: if people on the streets are hitting themselves on the head with frying pans repeatedly, I want them to stop, not to help them recover from the pain quicker so that they can hit themselves more.

> My opinion is that the way Omarchy is developed leads to gigantic security holes

>> Fix it. If you see a problem in the world, fix it.

You can't "open a pull request" to fix a projects development process. The point of the article isn't about any specific security issue, it's that these vulnerabilities will keep getting introduced due to the lax attitude the project takes towards security.

Thanks for sharing the link. I think it provides a lot of reasons why installing Omarchy or opening a pull request would be a waste of time. I can’t fix fundamental design flaws in a PR. I don’t want to try to fix apps written in Bash and QML & vanilla JavaScript. There are other ecosystems out there that are built on stronger foundations I can (and do) contribute my time to.

Well, as far as I know, the internal config systems of most popular distros like Debian, Arch, even NixOS are all Bash. There is nothing that makes Omarchy fundamentally bad design; it's pretty average.

You're not suggesting that you can't criticize something unless you're willing to fix it yourself, are you?

The bar is a lot higher when you're empowered and capable.

Like a lot a lot a lot.

And that's before we had LLMs writing code. So really it's basically orbital now.

The fractional pennies in tokens it could have taken to fix this would cost less than their web traffic bill. But alas, if you fix it and put in a PR, that doesn't get you the eyeballs and social good-boy points that a blog post appealing to correct politics does.

Why fix when you can farm?

It's simple: They're coping and seething[0] due to Omarchy recently getting all that money. "It should have been me!"[1].

0. https://www.youtube.com/watch?v=a8MZBUoQt68

1. https://www.youtube.com/watch?v=dpKc8N3FJsQ

The kind where the author hates the omarchy creator, so every issue is a world-ending issue.

I got tired of scrolling through poorly organized Go methods, so I built gomsort - a tool that automatically sorts methods within types using call graph analysis.

The Problem: Methods in Go structs are often randomly ordered, making code hard to follow. You end up with public entry points scattered between private helpers.

The Solution: gomsort analyzes your call graphs and sorts methods by: 1. Public methods first 2. Entry points (low call depth) before helpers 3. Shared utilities (high in-degree) at the bottom

Example transformation:

  // Before - random order
  func (s *Server) helper() string { return "help" }
  func (s *Server) Start() error { return s.connect() }
  func (s *Server) connect() error { s.helper(); return nil }
  func (s *Server) Stop() error { return nil }

  // After - logical flow
  func (s *Server) Start() error { return s.connect() }
  func (s *Server) Stop() error { return nil }
  func (s *Server) connect() error { s.helper(); return nil }
  func (s *Server) helper() string { return "help" }

Features: - Works like go fmt - recursive by default - Integrates with golangci-lint - Preserves comments and semantics - Configurable via .msort.json

Install: go install github.com/borovikovd/gomsort@latest

Repo: https://github.com/borovikovd/gomsort

What do you think? Would this help your codebases?

I like this idea, thanks for making this.