I know what you mean. There are tools I see everyday and I ask, but why? I have started to just ask, why not? There doesn’t always have to be a use case and sometimes people just want to create shit. They don’t even care if others use it, but want to share it anyway in case there is that one other person that does.

Does there need to be a need? Some people just like to create things to see if they can. Some people like TUIs. There may not be a huge need for this, but it’s pretty freaking awesome to have.

Oh God. Those are the 2 worst ones. They are mainly used for IT tickets, not for developing software. Jira isn’t the worst, but it does lack basic features. It’s just when companies use Jira you just know you are going to have to deal with a bunch of PMs who all they care about is velocity.

There are so many other simplified alternatives these days. Basecamp is one.

The status code that gets returned should be the status code of the messenger and not the data. If you want to add a status code about the data, then please do.

If something can return null and empty and it’s valid, that is not a 404. That is a 200.

As far as a 403, the messenger is telling you that you shall not pass. There is no data. 403 is appropriate here. The return response can be anything since 403 is pretty self explanatory, but I would probably return json to be consistent. I would also use the field message. Something like the first one for this use case only.

In other cases where i do get data, I would use data, message, status (optional). But status in the json response would be status about the message.

Not sure where you got the idea that it’s not advisable to mount the box via NFS. You can totally do this. I would make some adjustments though.

I would use mergerfs to union multiple mounts into one. You would then download to the local mount which is the drive connected directly to your seed box. Then I would have a remote mount to the nfs mount. You merge these into one so that when you link up jellyfin, it won’t know the difference and you can just stream like normal.

You need to copy files from the local drive to the remote, so you can try and roll your own solution by using rclone or use something like cloudplow which solves this issue as well. Cloudplow uses rclone as well, but monitors for changes automatically.

As far as copying files, why are you using sync anyway? It’s pretty dangerous. Just use move or copy instead. This way you don’t need to keep copies on your computer and the server.

As far as streaming from the nfs mount. You may need to make some changes to the cache settings and ensure they are set correctly.

With a setup like that, you should have no problems though.

Somewhat, but just a few pieces of it. Podman build is mainly a way to be backwards compatible with the docker cli. Buildah has some more flexibility and the way it builds the images are slightly different. You can use podman to build, but it’s probably better to move to buildah for the build step as time permits.

You typically don’t use podman to build images and you would instead use something like buildah.

Then you would probably enjoy concourse