You realise you can run VMs for any other os right? It's a limit on running macOS not a limit on running VMs.

I run up to a dozen Linux VMs at once on my Macs.

I've never hit the referenced limit because it isn't a limit on running VMs it's a limit on running macOS, and I hardly ever run macOS VMs.

I'm not sure why people don't use Mac's are so obsessed with telling people who do use Macs that they're wrong, and yet here we are.

It's wild that these companies have convinced you to pay to be a beta (at best; arguably much of this is pre alpha quality shit) tester and you're perfectly happy with that scenario.

The lengths people go to not to solve the actual issue never cease to amaze me.

Currently "I don't know how to configure xdebug so I wrote a convoluted alternative" is tied for top place with "I don't know how MySQL sockets work so I rewrote the entire thing to use Mongodb".

I've seen https://codefloe.com mentioned, can't say I've used it myself yet though.

If by need you mean, can choose to use, and if by push you mean, login to the GitHub web ui, then sure.

> adds risk (what if you lose it)

Lose what exactly? Decent 2FA setups make you confirm you've recorded a set of backup codes somewhere (they often recommend print and store in a safe, I find a secure note in a password manager works well) before activating it.

Furthermore plenty of TOTP applications offer secure backup and syncing features.

So again, what specifically do you think you're going to "lose"?

In the era of enshittification I can't really see the logic in tying a bunch of your infrastructure/services to the likes of stripe.

Then again I also don't see the logic in asking spicy autocomplete to write code or provision services for you either.

Maybe I'm just not the target market. I guess if you're spinning up 5 new toy todo list apps a week to show off how well you can talk to a predictive text engine maybe this is actually useful.

It probably also doesn't make much sense to me because I see external services as something to use when we have to, not as default choice.

When your application runs on VMs you control and just uses a payment gateway and an email gateway it's hardly a challenge to get the services setup.

“Spicy autocomplete” absolutely made my day. Thank you.

You're very welcome.

Are you using an existing forge package (like eg Forgejo which codeberg is built on) or something custom?

Custom-built on top of libgit2.

Not trying to be dismissive/snarky... But why?

I started developing it as a slim wrapper around Git to support my own needs. At the same time, it is essential to have rich features like pull requests/code review, so I started focusing on designing a tool that strikes an appropriate balance between being minimalistic and functional. One thing that I focus on is allowing users to disable any feature they don't need.

If it's your ssh server and it's single user you don't need to use the "git@" part at all.

Just store the repo and access it with your account.

The whole git@ thing is because most "forge" software is built around a single dedicated user doing everything, rather than taking advantage of the OS users, permissions and acl system.

For a single user it's pointless. For anyone who knows how to setup filesystem permissions it's not necessary.

I prefer to be explicit about which user is connecting to ssh.

There isn't much advantage that can be taken from O/S users and perms anyway, at least as far as git is concerned. When using a shared-filesystem repository over SSH (or NFS etc.), the actually usable access levels are: full, including the abilities to rewrite history, forge commits from other users, and corrupt/erase the repo; read-only; and none.

Git was build to be decentralized with everyone having its own copy. If it's an organization someone trusted will hold the key to the canonical version. If you need to discuss and review patches, you use a communication medium (email, forums, IRC, shared folder,...)

Git was built to be decentralized but it ended up basically displacing all other version control systems, including centralized ones. There are still some holdouts on SVN and even CVS, and there are niche professional fields where other systems are preferred due to tighter integration with the rest of their tools and/or better binary file support, but, for most people, Git is now synonymous with version control.