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.
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.
Not a bad suggestion, may even make the "pwru" analysis a bit simpler. Definitely worth playing with. You can even give it a try in the lab and lmk how it fares :).
The reason laid out in the article was for "jumping over the default linux network stack" to move a packet closer to its destination. I provide that just to hopefully help, ill have to read thru the article again to see how I can improve on making that clearer or defining more practical wording :).
And yeah, I understand your comments on all the naming spaghetti. I throw together these things so often that the convention used here are ones from my own head sprinkled with a bit of "iproute2" output format. Ill see if I can improve on this a bit moving forward. The explanation by another reply is correct :).
I'm surprised that the reason I'm mostly interested in Zig is not mentioned.
This is C interop.
I work with C quite a bit and I enjoy it, however writing a large project in C can be tiresome.
Having an option like Zig which can import C headers and call C functions without bindings is pretty attractive, especially when you want to write something a big larger but still stay in C world.