Can you elaborate on this? I’m facing a similar decision in my org and think sharing a common database store sounds smart. With rules of course, like clear ownership of data, only one writer, etc.

> but knowing which products might satisfy it is not automatic.

Would not search + first party description solve that? It’s easy to create a page “you have problem A? Try our product B”.

Of course it does, but this proposal entails banning search engines, right? I can imagine definitions of "advertising" that don't encompass search, but this author doesn't intend them; he explicitly states that he is not just classifying "paid" advertising of products as advertising but all "third-party" advertising, "full stop", and acknowledges this would make Google "cease to exist" in its "current form". He clearly intends his proposal to include banning search engines, entirely.

It doesn’t ban search engines, it prevents a company from making money with their search engine through advertising.

> It’s easy to create a page “you have problem A? Try our product B”.

How is that not advertising?

Because you’d have to search for and choose to see that page, not being fed a banner/pop up

> have the whole server crashing

You do not need to solve that at the language level. A common pattern is using multiple replicas, service discovery and automatic restart upon a dead replica. For example kubernetes does this out of the box.

For dark corners of the code, that is often a good middle ground between interrupting the service and never die.

Sure, it's a good idea to have something like that just in case. But crashing is really not desirable and could cause all kinds of problems, even if you do have recovery mechanisms in place.

A crash in a web server could result in data loss, timeouts and performance issues on clients due to the response never coming back, crashes on poorly written clients, cascading failures in poorly written services, etc.

And for a client application, imagine if your web browser would just randomly crash sometimes. Do you think it would make it much better if the browser would detect the crash and relaunch itself? And what if it relaunches itself and then crashes again for the same reason?

Can you find other examples for when force pushing a shared branch is acceptable? I have trouble finding plausible examples for communicating a force push with 50 colleagues.

API keys and certs must be removed from git even if compromised. Many firms use in-house GitLab, Bitbucket, etc. GitHub has enterprise support for removal of sensitive data.

Force pushes occur for various reasons. Sensitive data includes customer and employee personal info.

Other cases involve logs, DB backups, cache, PDFs, configs, and binary files.

Maintenance and performance needs form another category.

Team dynamics and varying git expertise can lead to accidental or uninformed force pushes, especially challenging in a monorepo with 50+ contributors.

In summary, reasons range from personal data (GDPR compliance), security requirements for logs/configs, to resolving merge conflicts and performance issues.

Your question regarding the need to communicate between 50 or more devs, there was no need but monorepo idea forces unnecessary communication and team effort when none was needed if there would be more repositories.

If you use helm charts or similar, the version of the image would be a variable that is updated outside the repo. ArgoCD can do this with the Application resource.

For example: build code and image, update git reference and version number in Application when build done.

You then get atomic updates of both code and configuration.