PrincipleOfCharity

This isn’t an application on a Mac, but it is a demo website for a series of qr-code libraries so it will work on any platform. It isn’t as convenient for people unfamiliar with QR codes, but if you need full control over the encoded data then this works really well.

The website does the generation in JavaScript so you don’t need worry about hammering some guy’s API if you needed to generate a lot of QR codes.

QR-Code Generator

Whenever my friends or I point to the sky after sitting in a chair in a McDonald’s on the second Saturday of the month while wearing a purple shirt. We just start cracking up until the manager comes out and tells us to leave.

I have also thought this is a good idea. I think that the ActivityPub standard should have a required field that lists a copyright license. Then a copyleft style copyright should be created that allows storing and indexing for distribution via open-source standards, and disallows using for AI training and data scraping. If every single post has a copyleft license then it would be risky for bigtech to repurpose it because if a whistleblower called them out that could be a huge class action suit.

A good question is if a single post can be copyrighted. I think it could. Perhaps you would consider each post like a collaborative work of art. People keep adding to it, and at the end of the day the whole chain could function as a “work”. Especially since there is a lot of useful value and knowledge in some post threads.

You can do that, but there are a couple of things to keep in mind.

Different apps may only be compatible with certain database products and versions. I could be a real pain if you have to spin up a new version of a database and migrate just for one service that updated their dependencies or have to keep an old database version around for legacy software.

If you stop using a service then it’s data is still in the database. This will get bloated after a while. If the database is only for one service then wiping it out when you are done isn’t a big deal. However, if you use a shared database then you likely have to go in and remove schemas, tables, and users manually; praying you don’t mess something up for another service.

When each service has its own database moving it to another instance is as easy as copying all the files. If the database is shared then you need to make sure the database connection is exposed to all the systems that are trying to connect to it. If it’s all local then that’s pretty safe, but if you have services on different cloud providers then you have to be more careful to not expose your database to the world.

Single use databases don’t typically consume a lot of resources unless the service using it is massive. It typically is easier to allow each service to have its own database.

I’m confused. Isn’t the commission that is paid just a cut of the profits from sales? The 85% not paying commission would be because their app is free. Apple’s argument is that they are providing a huge platform and infrastructure for app developers; many of which are utilizing it for zero cost (except the annual $99 developer fee).

If someone then uses that infrastructure to make money then Apple takes a cut of either 15% or 30% to help sustain the whole thing. Those numbers are argued to be too high although they are basically in-line with the mark-up of most goods and services.

The real complaint is that Apple doesn’t allow alternate app stores that would compete, and theoretically push down the commission to whatever the free market determines is reasonable (and presumably below 15%). Apple, of course, argues that they do it for safety purposes. One way to offer lower commissions is to have less strict screening processes to save money. This could end up being a race to the bottom of quality which may not really benefit users.

I was like, “Portainer costs money? When did that happen. I thought it was open source.” Granted it has been awhile since I used it.

You want to check out the Community Edition. Here’s their Github.

I believe the point of OP’s “thought” Is that death-by-implosion is basically instant (30 milliseconds) so it could be considered more humane than other methods.

Not sure if this is the same problem, but it has been noticed that passing messages between federated instances has been hampered by the way the “worker threads” are currently been done. The big instances are essentially getting overloaded with outbound federation work. Solutions for that are in the works. issue/3230