ldelossa

Learn how Linux's transparent proxying works by building a toy proxy server in C.

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.

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

Don't these lockless bags break down when it comes to threads not spinning? For instance, if you want to sleep a thread until something was produced?

Hello all.

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.

Since you say 'quite exactly', definitely no.

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.

All we want is a tree explorer :'(

Show me one of these things do something more complex then a front end intern project.

Super cool project, which really means nothing when its MacOS only :laugh:

Good tip

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 :).

Thanks for the constructive feedback.

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 :).

Here's the first in a series of posts which show off eBPF networking techniques.

Still in fedora repos. Not deprecated for me, haha.

Wow this is cool.

I've been looking for 'runnable C examples' on my blog.

Do you know if I can integrate this with Hugo easily?

Lol, I read this comment and immediately went "No way".

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.

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.

I really want to like this laptop but...

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.

Hmm, if I had to guess, its probably the task of centering two <div>'s side-by-side

This is a plugin for those looking for a VSCode-like experience in Neovim.

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

I think I will add a configuration flag to allow for viewing all files in the pull as well.

Calltree implements the missing "call-hierarchy" tree UI seen in other popular IDE's such as Pycharm and VSCode.

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.

Created a set of very simple scripts which incorporate FZF into your Sway desktop.

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.

Clair is an open source solution for finding vulnerabilities lurking in containers. We just reached GA with our newest version, V4! Check us out and feel free to contribute to our development.

Very cool! Excited to give this a try and see what else you guys come out with. - Louis.

Terminal emulators, as their name describes, emulate old school terminals.

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.

Completely agree here. Not a big fan of ppl shitting on tech they don't completely understand, but i guess thats half of tech content in general.

Writing a terminal emulator is a pain in the ass. Thats all I'm going to say.

I agree with this. I do believe, that if youre writing a prototypical, client facing, transactional application, a web framework is very useful.

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.