1. 6
  1.  

  2. 3

    I’m surprised there aren’t more of these self-hosted Bitcoin payment processor web apps. The last one I remember hearing about was Baron, which looks not-so-active now. Admittedly I haven’t been following this area closely. What other popular ones are out there?

    1. 2

      This is yet another project that has piqued my curiosity, only to find it participates in open source vendor lock-in by requiring Docker. Due to that, I’m unable to use it.

      1. 2

        it participates in open source vendor lock-in by requiring Docker

        Can you explain what is “vendor lock-in” about Docker?

        Isn’t Docker now part of an “open container initiative” or something?

        AFAIK, it’s usually not too difficult to de-Dockerify something.

        1. 1

          Because Docker isn’t supported everywhere and won’t be. It’s not supported on the BSDs. Unless there’s a business requirement to run Linux, I only run BSD.

          1. 3

            I’ve never heard of “vendor lock-in” meaning “it doesn’t run everywhere”. By that definition almost all software is “vendor lock-in”. Mostly I’ve heard the phrase used to refer to data formats and data in general. But whatever the case may be, the Dockerfile doesn’t mean Docker is required. You’re free to try building it and running it on BSD without Docker.

            1. 1

              The old definition of cross-platform code meant it runs on the widely-used platforms regardless of what a vendor chooses. The project itself controls it. This code, if tied to Docker, will only use the hosts and targets Docker supports. Its locked into what that project chooses. I haven’t heard of open-source, vendor lock-in before but it makes sense: many OSS foundations are easier to use than modify heavily.

              These people probably have no intention to put Docker on BSD or take over Docker development. They’ll depend on upstream to do that or not do that. So, they’re locked in if the Docker dependency isn’t easily replaceable by them or their users. If it is easily replaceable, I’d not call it lock-in: just a project preference for development and distribution with cross-platform being limited to Docker’s definition of platforms. Which maybe be enough for this project. I can’t say any more than that since I’m just glancing at it.

              1. 1

                This code, if tied to Docker, will only use the hosts and targets Docker supports

                For probably the third time now: this project is not “tied to Docker”, and the concept of “tied to Docker” for a single piece of code is borderline nonsensical.

                There are projects that are “tied to Docker”, but that most likely means they assemble multiple software pieces together via a docker-compose.yml file, not a Dockerfile file.

                1. 1

                  It does appear that I misread the project. I looked at their deployment guide and Docker is front-and-center. However, it appears that the project does not have a hard dependency on Docker.

                  For those projects that do have a hard dependency on Docker, my statement still stands. Docker, in those cases, is a form of open source vendor lock-in due to deliberate non-portability.

                  1. 0

                    Docker, in those cases, is a form of open source vendor lock-in due to deliberate non-portability.

                    Let’s Internet rage at non-portable BSD-specific features as well then.

            2. 2

              Docker, in fact, literally only runs on Linux. It uses a wide variety of Linux-specific functionality, and all extant Docker images contain Linux x86 binaries. On Windows and OS X, Docker runs on Linux in a VM (a setup which is impressively fragile and introduces an incredibly variety of weird edge cases and complications).