I had thought screen was pretty commonly known, but its a tool you can use to background and reconnect to a process, with the child process being completely separated from your shell. So you can ssh into a box, start a process with screen, and then logout, return later and reconnect. (It also does other stuff like read from serial consoles)

Codewise, there isnt a lot there, 3 main files (main.rs, server.rs and client.rs) all weighing in at ~200 lines.

It felt premature to add a readme at this stagr, as I dont see this as a complete thing yet, but I can add a readme later today.

I'll look into that, I'm currently just using cross term, which was enough to pass my rudimentary tests of nyancat. I'll have to create some form of test suite to chuck various inputs at it and confirm it all works correctly.

Its definitely not intended to replace screen or be better, that would require a lot more features and work that I just dont want to do. Its for fun/scratching an itch.

I started it originally when I had issues with screen and permissions issues. The main branch is what I actually use, and I use it for running Minecraft servers. Its just an easy way to send commands to stdin of the process. (Stdout connected to regular stdout, stdin connected directly to a Unix socket).

As for tmux, most I'm not that familiar with it, and used screen more.

Nothing, it can't be used for anything else. You can't reverse the encryption keys from it. Its like adding all the digits in your phone number and giving that out. People with your phone number can verify it, but to everyone else, its basically useless.

Call them and read the number out? I dont think it matters if someone else can see your safety number, you can print it in a newspaper if you really wanted to.

What is openwebzine? Can't find any info on it.

L

P

256gb of ram seems well beyond standard self-hosting, what are you planning on running?!

I did create a fork and MR, and neither used your runner (sorry if that is what spooked you).

Develop local and push remote also let's you sanitize what is public and what isnt. Keep your half-backed personal projects local, push the good stuff to github for job opportunities.

I think it was when you create a merge request back, that the original repo would then run the forked branch on the original runners.

From what I can tell, its now been much more locked down, so its better, but still worth being careful about.

More discussion: https://www.reddit.com/r/github/comments/1eslk2d/forks_and_selfhosted_action_runners/

The other potential risk is that the github action author maliciously modifies their code in a later version, but that is solved with version pinning the actions.

I can't find it right now, but there used to be a warning about not self-hosting runners for public repos. Anyone could fork your repo, and the fork would inherit your runners, and then they could change the pipeline to RCE on your runner.

Has that been fixed?

I went to a completely private gitlab instead, with mirroring up to github for anything that needed to be public.

Edit: seems to maybe not be an issue anymore, at the very least it doesn't seem to affect that repo. Still, for anyone else, make sure forks and MRs can't cause action to run automatically on your runner, because that would be very bad.

This is my personal opinion, but you should add :

0. Dont.

Unless there is a really good reason, don't rename your project. It only adds confusion, and users will get lost during the transition. It also makes them hesitant to try the new one - "What if they do it again and i get left behind".

Pihole isnt pi specific either, it still kept the name.