I was looking around for a pastebin a while back, and I realized that a self-hosted pastebin is way too much overhead for a simple problem: easily serving possibly-highlighted rich text to people. I already have an editor I like for _writing_, so the problem becomes a matter of hooking into the editor’s syntax highlighting to generate equivalent JavaScript. A quick htmlize + tramp hack later, I could serve my current emacs buffer with the world:
> Deno apps don't seem to need/want to be dockerized. Which means less overhead.
Why do you say that? I can’t think of any reason a Deno project wouldn’t benefit from Docker more or less any other application. There’s an official Deno Docker image, so I wouldn’t say that not using Docker is a part of Deno culture.
But I could see the single executable being easier to use than Docker if you’re just trying to run a script on a home server!
The original commenter could be referring to Deno's permission system being similar to Docker's sandboxing, which could be true; I am not familiar enough with Docker to confirm that.
Personally, I tend to run my Deno/Node services using simple SystemD services rather than using docker or running the executable as-is.
I feel like the biggest issues with pastebins are:
- Data is known by the provider
- Not enough economic incentive to keep the pastebin running for a long time (you still need pocket money and some maintenance to keep it running)
0bin, another popular Pastebin alternative, solved this problem by encrypting the paste on the client and embedding the key in the paste URL - so the server had no idea about the data being posted.
Presumably they’re placing it in the # part of the url, which isn’t passed to servers by browsers. Now, of course, the client could still exfiltrate the key with client side JS, but that would be noticeable to anyone that wanted to check.
https://fwoar.co/pastebin/3daaf7ce49ca221702c70b0d10ac5caec8...