#1 thing helping me with GUI Rust is sccache for crate compilation caching. and #2 is building independent-compilable subcrates. This improves build times by 10x.

Also shoutout to ratatui because even though it's technically a TUI not GUI, it's superb.

I'm the author and the patient. Ask me anything here or email me joel@joelparkerhenderson.com.

how did you get past the biology "safeguards"?

By describing it as a senior doctor teaching a junior doctor.

Because of so many GitHub problems, I'm adding GitLab.com and Codeberg.org.

Setup is simply 3 steps:

1. Sign up on each service, ideally with the same username.

2. For each repo you want to share, create the same repo name as a blank repo; do not automatically create a README.

3. Edit your local file .git/config to add push URLs, then push as usual.

Example:

    [remote "origin"]
        url = git@github.com:foo/bar.git
        pushurl = git@codeberg.org:foo/bar.git
        pushurl = git@github.com:foo/bar.git
        pushurl = git@gitlab.com:foo/bar.git
        fetch = +refs/heads/*:refs/remotes/origin/*

Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.)

These days, the problem with cloud-hosted Git platforms is not where to push your code. Replicating repositories across multiple providers is relatively easy, and Git has always been good at that. The harder problem is that successful teams end up accumulating a lot more than source code around their repositories, and much of that information becomes just as important as the code itself.

Bug reports, feature requests, documentation, design discussions, code reviews, project planning, CI/CD configuration, and years of historical context all tend to live inside platforms such as GitHub. While the Git repository itself is portable, all of that surrounding data is often much harder to migrate cleanly, especially if a team has built workflows and integrations around a particular provider.

That, in my view, is one of the main reasons so many companies are heavily dependent on GitHub. Moving the code elsewhere is usually straightforward; moving the entire development process, with all of its history, metadata, and institutional knowledge, is not. When GitHub goes down, the question is often less about where you can push your next commit and more about how easily you can recreate the rest of the environment that your team relies on every day.

(I upvoted you, for asking the real questions, but to answer)

> Where do you keep Issues,

Youtrack

> Pull Requests,

Gerrit, it's way better for code review

> Wikis,

Also Youtrack, but other software exists that's specific for this, I have seen Confluence used a lot and while I don't recommend: that's usually the case.

> Discussions,

As far away from code as possible, right now it's Zulip

> project boards,

Youtrack, though usually in companies they use Jira for this.

> and everything else? (rhetorical question.)

In proper tools that are designed to solve a specific need, not try to do everything: badly.

--

Now, a sane person will respond to me with the fact that I haven't removed any single points of failure, I've actually just added more of them. They'd be right! The differences is that it makes the stack a bit more flexible and composable. Migration of, say, the Wiki, doesn't make major issues because it's already somewhat decoupled.

For a large project with dedicated resources that is pretty reasonable. And GitHub issues probably isn't sophisticated enough for you anyway. But for a small to medium open source project, that's a lot to set up and manage, and in the case of gerrit, you have to host it yourself.

And then for Youtrack, Jira, Confluence, etc. You still have the same problem where it is difficult to migrate to a different system, because the data is all stored in a proprietary format that can't easily be ported to something else. For the wiki, there are somewhat standard formats used by multiple systems, like markdown and mediawiki. But for issues, I don't know of any standardized format, and migrating from one product to another is going to be pretty difficult.

> Now, a sane person will respond to me with the fact that I haven't removed any single points of failure, I've actually just added more of them. They'd be right! The differences is that it makes the stack a bit more flexible and composable.

Not really, it sounds you made a mess of things by having to rely on a dozen small disjointed services and separate account and auth needs instead of just using a single integrated environment.

There are many reasons why a service like GitHub is really not about git.

its funny how many people came to me as if I invented this and that I’m wrong by default, but I have never worked in a company that only used an all-in-one solution.

would a self-hosted all-in-one solution be a viable alternative that doesn't split these all up into separate cloud hosted apps? it's been years since i've explored anything other than github/gitlab/etc.

Fossil does all of this, and has a better VCS for my use case than git does. https://fossil-scm.org

Like a hawk? If GitHub was down while you slept, would you notice?

Those third parties will be more invested in you as a customer than GitHub is.

> In proper tools that are designed to solve a specific need, not try to do everything: badly.

And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?

That's one of the reasons I like the code, issues, docs (code or wiki depending), and discussions all in the same repo.

Not to be confused with Chat, which is more ephemeral, and is, for us, in Slack. But we have to be mindful of chat discussions that turn substantive and make sure we copy that info to a Discussion in the repo (which can be annoying to do and annoying when it's not done).

> And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?

Not GP, but is that actually a real problem? Take a project like OpenBSD where the code, the bug tracking , and the design discussion happens in different place?

Even in reality, you don’t put the workshop in the conference room.

We are a software dev/consulting company. We have a lot of client repos and a lot of different internal teams. It's a real and significant problem for us and we are a pretty small org.

I've done consulting with bigger orgs (Fortune 500) and the more systems they have the harder it is to find things. It's a problem for them too.

So..in short, yes it's a real problem.

I don’t get it. That’s a lot of failure points to incur in the name of flexibility.

> Where do you keep Issues, Pull Requests, Wikis, Discussions, project boards, and everything else? (rhetorical question.)

I think it's worthy of a non-rhetorical answer anyways: https://docs.gitlab.com/user/project/import/github/#imported...

None of those might be perfect, but at least people are trying. Even something like Gitea and other forges that you can host yourself have support for most of the basic functionality you'd expect.

However, If we ever wanted a setup where it's easy to mirror rather than import stuff, we'd probably want to look in the direction of storing everything in folders within the repo, e.g. a file/folder for every issue, for every Wiki page etc. Most of the mirroring seems to only concern the repo itself, not the stuff around it, for example: https://docs.gitlab.com/user/project/repository/mirror/

This isn't a direct answer, because I agree it is difficult to move away from Github's familiarities amongst developers - so it doesn't necessarily solve the problem for a collaborative codebase involving a handful or more developers (complete with Issues, PRs, etc) but if you are working with a less technical/developer oriented team ie- regardless of org size it's just you or maybe one other teammate who are the only ones involved directly in code/PRs then you can fairly trivially roll your own issue tracker or wiki.

Particularly if your work and the employer/client/org is primarily based on a web project (extra points, you already are managing their auth) then you could simply add a new subdomain or route to your existing web project that serves said self-hosted issue tracker or wiki.

Of course these things can get into the weeds but I do think that given the dramatically reduced turnaround times for a competent dev to spin up and customize in-house/self-hosted solutions for basic things like issues and wikis the strategy is more relevant and prudent than ever.

This is the real issue. We’re currently migrating from GitLab+Jira to GitHub. I did most of the migration, including our CI/CD with a self-hosted runner, and it was… fine.

The straw that broke the camel’s back was that Claude managed cloud agents are awkward to use with anything other than GitHub. In general, we realized that the whole world was on GitHub and we were swimming upstream.

But the original mistake was separating issue tracking and source control when we didn’t need all that power. Everything is so much simpler if you don’t have to maintain those integrations.

Maybe they’ll really enshittify GitHub in the future. We’ll cross that bridge when we come to it.

Somehow I never knew that you can have multiple push URLs for a single remote. Thank you for sharing this, I've been manually pushing to two remotes with a script for years!

I switched my personal projects to Codeberg recently and couldn't be happier. After spending lord knows how many hours wading through cluttered buggy interfaces in Github it's a pleasure to use a clean intuitive platform.

Years ago I was a big fan of Gitlab and always talked them up as a better Github. At this point though they've spent years trying to become just as convoluted and "enterprisey" as Github, but with much less success.

Hey, that's my workflow!

I also built a convenient CLI tool to switch identities on a per-repository basis. [1] [2] ...which makes working in enterprise environments much easier, as I can just have separate identities/keypairs for each customer.

[1] https://github.com/cookiengineer/git-identity

[2] https://cookie.engineer/projects/development/git-identity.ht...

I'd also add tangled.org and radicle.dev. I've been looking into these new decentralized forges recently.

And for fun, just spin up a VPS and initialize some bare repos there.

What's the purpose of using EC2 over something much cheaper, like OVH, digitalocean, or Hetnzer?

Usually the argument is for scalability, but a single VM for personal use doesn't need that, and even if you do want that, you'll need more than a bare repo.

Oh, EC2 is mostly a catchall for VPS for me. Sorry, that's unclear.

At this point why not just host your own gitea or something.

yes let's fix the lack of capacity by 3x'ing the demand to take down all of these other volunteer services , too

Asserts in my Rust code use a custom runtime macro "assert_eq_as_result" which does what the article is describing, by returning Rust Ok or Rust Error.

The Rust crate: https://crates.io/crates/assertables

All the macros have forms for different outcomes:

    assert_gt!(1, 2) // panic
    assert_gt_as_result!(1, 2) return Result (Ok or Error)
    debug_assert_gt!(a, b) // panic when running in debug mode

If anyone here wants to help me port it to Zig, I'm happy to do it.

Excellent info thank you. Your explanation makes perfect sense, and leads to the security compliance info that I'm reading.

I'm seeking to stop supply chain attacks as described at https://wiki.debian.org/Rust

Could there potentially be a way for a program to include all the source code of all its dependencies, at least for any that aren't on Debian?

You're welcome, thanks for the shout out. Glad it's helping you. <3

I see in your posts that you do a lot with Rust and biology. Broadly, the same way you can use the tool "cargo install" to fetch a bunch of dependency crates from one source and be sure their versions can all run well together and update together, I can use the tool "apt install" to do the same for applications.

The concept is called a "package manager" and it greatly helps me achieve a concept called "reproducible builds", as I gradually migrate the work toward a package manager for reproducible builds called "Nix".

https://en.wikipedia.org/wiki/Package_manager

https://en.wikipedia.org/wiki/Reproducible_builds

https://en.wikipedia.org/wiki/Nix_(package_manager)

That is some attention to detail in your research! I appreciate the explanation and examples. I think perhaps I am deliberately dodging the OP's question, treating it as an X/Y problem. He or she mentioned compliance as a valid reason, but it still feels like a smell: I think the original software could be installed using the provided deb, or building from source by cloning the repo and running `cargo run` on a Debian or Ubuntu system older than or the same version as the one he intends to use. (A Rule of Thumb I've found works well for Debian!)

I recognize that a lot of Linux users like the package system. I think it's a great tool for software that's intended to be integrated with the OS, but is a bit of a mismatch for third-party software. The creators here have even build a .deb, which is above and beyond. (Compared to, for exmple, compiling a +x linux executable that has been tested on Debian)

So, from a writer and user of software, I think I would rather publish the executables or a script to install them on my website (as they have done) for all the major OS branches, and as a user, I think c+ping and launching the CLI command they provided front and center is fantastic. It's an above-avg experience; a trivial install process, which isn't a given for OSS.

Good info, thank you. I'll aim for the next version with $100 to get it into Debian 14. <3

Good idea, thank you. I'll add examples in the documentation. Currently there are example repos that show all the components for each flavor: React, Vue, Svelte, Blazor, Nunjucks, HTML. Angular coming soon.

AI use is mixed: I write everything by hand in the specifications, and the components.tsv file, and in the Svelte version because it's my stack of choice. If you dig in, you'll see lots of hierarchies that are all hand-written to help Svelte caching, for example. I also research other major design systems, especially government-oriented public-sector systems such as GOV.UK and Reuters, and fold them in.

Then Claude Opus tranforms the Svelte version into the other stacks. Claude does a lot of the documentation text because I'm aiming for clear and consistent explanations, suitable for novice developers.

I'm developing Lily Design System because I work with multiple teams that each use a different tech stacks, each with their own ad hoc HTML tag names and semantic names. As a salient example, for a hospital form one team used terminology "health banner area" and another used terminology "medical red box". Lily is my attempt to converge these into something that works better internationally and across multiple stacks.

That said, I'm seeking help doing human proofing and improvements for the stacks, because we all know AI isn't perfect, and needs tuning, guardrails, expert feedback, and the like.

Great idea, yes you're right. I'll add that now.