pcgaldo

The motherboard can be cleaned with a generous amount of isopropyl alcohol. It cleans slightly corroded areas, displaces water, is not a good conductor of electricity and evaporates easily.

I think the real problem is that Automattic did not plan for another company to get this volume of customers using WordPress, creating a burden on WordPress servers that is not compensated for.

What they should have done is set limits or payment plans above a certain volume of connections or transfers from a person's or company's servers.

The problem is to act in this way, suddenly, apparently without foresight and that the possible problems will have to be borne mainly by WP Engine users.

Yes, but I guess what is limited is access to those resources from a site running on WP Engine servers. I also assume that users can download the themes from outside WP Engine and install them anyway.

The Subversion repositories with the code are also public. Anyone can use them. There is no restriction of freedom by restricting access to such a repository, if the code is still publicly available.

This way WP Engine still has the opportunity to mount its plugin and theme repositories, without taking abusive advantage of the WordPress repository infrastructure.

There is work, energy consumption and so on behind it. Expenses that WP Engine is not taking on and does not even want to compensate for.

Automattic's reaction may seem like overkill, but it's a clear and forceful wake-up call to companies that are out to parasite their work and infrastructure. They do it because they have a privileged position. I think they are right to do so.

This does not mean that somebody could criticize a possible lack of consistency when Automattic is the company that adopts abusive attitudes towards third parties.

I'm not clear, has access to the code been denied or only access to other types of resources hosted on WordPress servers?

The FSF has clear guidelines and follows them rigorously, nothing else. It's good that they don't make exceptions. Any problem with microcode or other proprietary drivers starts with the fact that they are not free. Making exceptions would partially solve the problem, but the situation would not change significantly, and the FSF would then be violating its own principles.

The FSF's job in this regard is to try to open debate about the problems of not having free security patches and, in any case, to try to uncover hidden vulnerabilities in proprietary tools and facilitate the creation of free tools that solve the problems.

I was going to recommend Tox, but I don't think there have been any iPhone clients with up-to-date development for years.

You can also try Jami.

https://jami.net/

The most reasonable thing to do is to cite the original publication and its author.

Thank you.

Without it, it would be of little use. But, unfortunately, even with it, we also have little guarantee that someone will reuse the code without re-sharing it.

Not a bad idea. It would not be difficult to include it in this project.

Literally.