232 karma · joined November 18, 2019
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.
Learn more about us and how to download the beta here: https://www.octopunk.io/blog/introducing-octopunk Interact with our community here: https://github.com/octopunkio/community
I write a lot of shell scripts.
I'm usually frustrated with the effort it takes to get argument parsing and shell completion working quickly.
So, I wrote a tiny ZSH framework for writing terse scripts. If you adhere to the constraints in the framework you get:
1. Command completion with support for nested commands (think, kubectl like cli). 2. Argument parsing and validation 3. Argument completion
If it looks cool try it out. Contributions welcome.
Is it another desktop shell? yes lol.
It mirrors the look and feel of Gnome and will stay Gnome adjacent as they introduce new UI changes and feel.
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've been looking for 'runnable C examples' on my blog.
Do you know if I can integrate this with Hugo easily?
Then thought about it for another second then agreed.
Then thought about it for longer and said "No way again".
Honestly, I'm stumped on this one haha, which is an interesting place to be, contemplating who's more evil.
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.
If you go to their twitter, its a constant barrage of angry customers who havent received their orders in over a year.
I dont think im okay with shelling out $3000, waiting possibly over a year, and being told "we are working on it" the entire time.
I personally just went with Tuxedo for a linux first laptop.
Some of the unique features:
A rich set of default plugins which make up an IDE experience A Panel which stacks plugins similar to VSCode The ability to swap groups of plugins into panels, similar to VSCode A well defined API for creating out-of-tree plugins and extending `nvim-ide` If you are particularly looking for an "all-in-one" IDE plugin then this maybe interesting to you.
Quick workflow video: https://youtu.be/GcoHnB5DoFA
Calltree allows you to start at a root symbol and discover the callers or callees of it.
Subsequently, you can drill down the tree futher to discover the "callers-of-caller" or the "callees-of-callee".
This relationship forms a tree and this is exactly how Calltree works, keeping an in memory representation of the call tree and writing the tree out to an outline form when requested.
Right now it depends on alacritty, which I think is a fan favorite lately. If the need comes up to use other terminals I'd be into the idea.
Terminal support in linux is built directly into the kernel. So bar minimum you need to be familiar with these syscalls, which are a little obscures, but luckily only a hand full are necessary.
Next, youll need to understand process management in the kernel, standard pipes, and job control.
The actual emulator code has to keep a mapping of terminal control characters to terminal features, and keep this working across OS's if portability is a goal. Here in lies the devil in the details. This emulation layer is tribal knowledge.
Finally you have to also be a good UI dev, who knows how to inter-op ASCII and UTF8 shell escaping.
This isnt touching on colors, GPU acceleration, and other pluses.
I also advice any individuals coming from Django or friends to use a web framework.
But after some time spent with the stdlib, and understanding how some of those implementations work, it gets to the point where Id rather not read another set of documentation, learn a new mental model, and deal with bugs. This all comes with a framework.
After awhile you realize that the stdlib provides most of what you need, and that writing more vanilla Go can be simpler then learning a full framework.
I will admit, most my work in Go revolves around internal services, and dont deal with web technologies such as CSRF and CORS. So I do acknowledge my opinion here is leaned toward those use cases.