I write English / Escribo en Español.

Vidya / videojuegos. Internet. Cats / Gatos. Pizza. Nap / Siesta.

This user’s posts under CC-BY-NC-SA license. Ask me if you need a different permission.

  • 13 Posts
  • 729 Comments
Joined 2 years ago
cake
Cake day: July 26th, 2023

help-circle
  • Technically the only way you can vet, is by having root access to their servers and law officer level access to their documents.

    Failing that, I can think of four baseline conditions to venture that a given product “shouldn’t” enshittify, or that at least the utility of the project is recoverable (or forkable) if it does:

    Req 0: Copiability. The software actually provides a full offline (or local) service. There’s no way (that I know of!) to enshittify something that can live fully independently from its “mothership”.

    Req 1: “Letter and Spirit”. License has to be Free Software (not just “Open Source”) with all the liberties that come with it. (I assume in the future, an exception might be made to allow for New Ethical licenses that would be not FOSS as per the current definition)

    Req 2: Reproducibility. Someone else has to have verified that using the source release builds the whole product (at most excepting “assets” like logos). This is usually verified empirically by someone getting to run and maintain a competing instance.

    Req 3: No bite hand. The provider must have not used legal measures to exercise violence or restrictions against users of the product (be those consumers or devs). This includes eg.: using the DMCA to punish reviews, or punish implementation of req 2.

    If a combination of provider and product completes those four requirements, I feel relatively well assured that the product can’t reasonably enshittify, or at least that if it were to happen, there will be enough advance notice and devel momentum that the value of the product can be recovered from it.










  • Persistence of “mental state” mostly. By setting up a compose, you have a written down notion of things like volumes, environment variables and other elements stored somewhere for the behaviour of the container, that can not be ignored or defaulted if you don’t wish it, for when you need to undo and redo a container and default behaviours are important.

    While sure, those elements can be set in a loooong ${engine} run... command, it’s easy to forget to set up something important or copy and paste an accidental endline. A compose file (plus a sample envfile, if you so wish) helps keep the way to set up variables and state under control. Made much easier now that we have both docker-compose run and podman-compose run.