I'm still waiting for better Windows Git Auth integration in GitButler. I don't want to enter my key password for each remote action (fetch or push).

Double Commander is free and open source. I've been using it for a long time. I'm not sure which one I used before, but could very well have been FreeCommander.

I've liked the idea of it, but IIRC it launched with noticeable delay. Even if it's only one or two seconds, I want to access my files fast.

Linux isn't even a file explorer. Different distros serve different file explorers by default.

I've been using Double Commander for a long time. I can recommend.

I've looked for alternatives occasionally, because I'd prefer some things differently, preferably something I'd be able to source inspect or work on as well, but haven't found anything better.

They make valid points, and maybe it makes sense to always prefer them in their context.

I don't think exceptions always lead to better error handling and messages though. It depends on what you're handling.

A huge bin of exception is detailed and has a lot of info, but often lacks context and concise, obvious error messages. When you catch in outer code, and then have a "inaccessible resource" exception, it tells you nothing. You have to go through the stack trace and analyze which cases could be covered.

If explicit errors don't lead to good handling I don't think you can expect good exception throwing either. Both solutions need adequate design and implementation to be good.

Having a top-level (in their server context for one request or connection) that handles and discards one context while the program continues to run for others is certainly simple. Not having to propagate errors simplifies the code. But it also hides error states and possibilities across the entire stack between outer catch and deep possible throw.

In my (C#) projects I typically make conscious decisions between error states and results and exceptional exceptions where basic assumptions or programming errors exist.

Does the performance cost of error checking/result types they discovered in C++ apply to languages that have native result and option types like Rust?

I would hope they were able to find efficient, performant implementations, and that branch prediction picks the expected non-error branch in most cases.

Yes, I think so.

I'm surprised my not one of the biggest German cities is in there too. Very cool.

I opened/open-sourced my ed2k link generator that I use to generate them for files so I can manage my AniDB mylist more easily.

I had done most work in 2022 and have been using it since then. For opening it up I still had to check whether I had sensitive code committed. I had to remove a local filepath from my initial commit. But now it's versioned and open on GitHub.

Yesterday I started migrating and extending some Mumo project (Mumble Moderator, python app/framework) CI and docs. I plan to further improve it, and to try to reproduce a bug that may be an issue because of changes in a deb/ubuntu library dependency.

That depends on the licenses. Saying they're libre is a classification, not specific.

Note also that source code may be licensed differently from binaries, assets/resources, etc.

Check the license of what you're obtaining and bundling specifically. To get an overview of licenses and their permissions and requirements, see https://choosealicense.com/

It requires compile flag and runtime enabling. So it at least requires some thought and development more than just a lib version upgrade.

I saw the link on the Mumble dev chat, so at least they're aware of it.

Given that it's only really (very) useful in very flaky/bad connection scenarios I'm not sure it's even worth it in most cases.