Hello folks.
Like a lot of great software, we built OctoPunk out of frustration.
We are a set of developers who, for one reason or another, have been using GitHub as our primary code forge for professional work for a very long time.
We've seen GitHub grow, stagnate, ignore feature requests, and simply never produce a full-featured desktop client.
Finally, we had enough, decided to build our own, and OctoPunk was born.
OctoPunk is not a git GUI wrapper like GitKraken, not a half-implemented desktop client like GitHub's official client, which doesn't support code review, and not something that ignores complete workflows like per-commit reviews, looking at you, VS Code extension (https://github.com/microsoft/vscode-pull-request-github/issu...).
OctoPunk is a full-featured GitHub client that surfaces 95% of GitHub's functionality as a desktop client, presented through a UI and UX that feels instantly familiar to modern editors and developer tools. We provide a customizable dashboard, quick search widgets, desktop notifications, and even an AI assistant that optionally understands what you're looking at and can help explain comments, draft responses, and more.
OctoPunk got its name not just from the software we are building, but from the mentality of the company. We are a tiny team that doesn't subscribe to big tech practices. We plan on staying small, independent, and nimble.
Anyway, if you're looking for a desktop-native and productivity-focused GitHub client, give us a try.
We are currently in beta and looking for feedback, feature requests, and bug reports, all of which can be conveniently sent from within OctoPunk itself.
All of OctoPunk is free for public repositories and requires a subscription for private ones. That's our only monetization model: no dark patterns, no data harvesting, and we promise to always keep it simple.
That's probably not going to happen as part of the core editor (there's a long discussion about this somewhere on the bug tracker) but should be easy to add using the now work-in-progress plugin system. Scroll down to the Examples section.
Funny how the maintainers preferred to build a plugin system instead of just the tree explorer, I suspect Helix will lose its biggest feature: no plugins and easy configuration :(
I used to use tree explorers all the time, but once I discovered fuzzy-search file explorers, I never used a tree explorer again. It’s been too long for me to remember why I liked tree explorers before or why I stopped using them, so I’m curious, what are the benefits of a tree explorer over a fuzzy-search file explorer?
I’m not questioning the usefulness or validity of tree explorers. I’m just trying to see things from a different perspective.
Tree-based finders allow you to explore a project.
Fuzzy finders only work when you already know what files exist.
Without a tree-based finder, you have no way to know which files exist in an unfamiliar project. Imagine being asked to change something in a project (e.g. add some extra space between two things on screen) without knowing what files existed. If you only rely on searching for names/terms that come to mind, you're probably going to miss the best way to accomplish the task at hand.
For discovering files in an unknown codebase I use the grep feature in Helix (or just ripgrep CLI). Way faster than going through a tree in most cases.
Tbh, I like having both, I find a fuzzy search is faster at finding what I want but a file tree is really helpful for building a mental model of directory relationships in a complex project.
I agree, these things seem to do okish on trivial web projects. I've never seen them do anything more than that.
I still use ChatGPT for some coding tasks, e.g. I asked it to write C code to do some annoying fork/execve stuff (can't remember the details) and it did a decentish job, but it's like 90% right. Great for figuring out a rough shape and what functions to search for, but you definitely can't just take the code and expect it to work.
Same when I asked it to write a device driver for some simple peripheral. It had the shape of an answer but with random hallucinated numbers.
I've also noticed that because there is a ton of noob-level code on the internet it will tend to do noob-level things too, like for the device driver it inserted fixed delays to wait for the device to perform an operation rather than monitoring for when it had actually finished.
I wonder if coding AIs would benefit from fine tuning on programming best practices so they don't copy beginner mistakes.
I used a web project in the demo because I figured it would be familiar to a wide range of developers, but actually many nontrivial pieces of Plandex have been built with the help of Plandex itself.
That's not to say it's perfect or will never make "noob-level" mistakes. That can definitely happen and is ultimately a function of the underlying model's intelligence. But I can at least assure you that it's quite capable of going far beyond a trivial web project.
It's also on me to show more indepth examples, so thanks for calling it out. I'd love it if you would try some of the projects you mention and let me know how it goes.
It seems like more examples demonstrating relatively complex tasks would be helpful, so I'll work on those.
I'm certainly not trying to claim that it can handle any task. The underlying model's intelligence and context size do place limits on what it can do. And it can definitely struggle with code that uses a lot of abstraction or indirection. But I've also been amazed by what it can accomplish on many occasions.
I do plan on having a "flow of a packet on a simple node". Working on an ingress and egress packet flow posts. These are rather large undertakings tho that require a post of their own IMO. Stay tuned for those :)
Yes, you are right here. It's always difficult to know how far down the tree of topics you should go to provide a end-to-end explanation. I tried to call this out in the start of the article. These are the "hard parts" of technical writing IMO.
I sometimes put a list at the top, like "This article assumes that you have a working familiarity with Linux namespaces (link to 3rd party intro to that), veth interfaces (link to 3rd party intro to that), [...]."
