The replies talking about portability are wild, my irssi instance started on a Pentium 90, and is running on an AMD EPYC the two commands it actually took were:
Look at it the other way. Why muck up my OS with a bunch of tiny apps? Who knows what version I’ll pull in my repo today. Chances are good it’s outdated with weird patches.
The docker image is built by the devs. All the proper dependencies are baked into the image. It’s going to run exactly as intended every time, no surprises.
And I can pick up the docker file and my configs and run it exactly the same on any OS.
For my homelab: portable state. I don't use this image specifically but I use many others.
I put docker-compose files in ~/configdata/_docker/
The docker-compose files always mount volumes inside the ~/configdata/ directory. So let's say irssi has a config directory to mount I'd mount it to ~/configdata/irssi/config/
Then I can just run a daily backup on ~/configdata/ using duplicati or whatever differential backup tool of your choice and be able to restore application state, easily move it to another server, etc.
I can guess a reason: persistence of your IRC server connection(s), across device sessions, and maybe switchable between devices. Without using an IRC bouncer.
So this this would a turnkey way to run this somewhere centralized and persistent, and then you connect to it however you connect to that Docker container (e.g., SSH, remote desktop of some kind).
Of course, a non-Docker way to achieve simple persistence would be to just run a character-terminal IRC client in an SSH-able shell account (or VPS or AWS EC2), inside a `screen` or `tmux` session that can be detached and reattached when SSH-ing in from whatever devices.
(Persistence of your IRC server connections means things like you can see what you missed in scrollback, you aren't being noisy in your channels with join and part messages, you preserve your channel operator status and other channel modes without relying on bots, and you aren't leaking so much info about your movements in real time to random crazy people who hang out in Internet chat rooms.)
(Also, early on, if your leet channels attracted trolls, remaining connected meant that whatever automated countermeasures your client had could help defend the channel. Also, the more people who had channel operator status, the harder it would be for an attacker who, say, "netsplit" to hack ops, to de-op them all, before a remaining op's scripts detected the mass-deop attack, and took out the attacker. Also, your persistence bouncer or shell account obscured your real IP address, so if an attacker targeted your client's IP addr but not your home addr, such as with a protocol or flood attack, you could more likely get back on quickly. Trolls were often annoying, but it was also cyberpunk satisfying when your channel made short work of them.)
Back in the day I would keep an old PC running Linux in the closet just for my IRC and shell needs. Having a vanity domain name was a must if you were lucky enough to have a static IP. I remember undernet adding support to hide your IP once you created an account.
Maintainers had a project where they ran everything in containers. The project had helped docker itself and the ecosystem by allowing some interesting software to be containerized.
Poor mans abstraction. Docker swarm makes a cheap node pool from random hardware. Compose makes all your apps and config live in git.
You don't _need_ docker, but if you are already set up for it then it's a boon. Adding an app for me to be very available across a fleet of hardware with ceph backed storage is a one-liner.
I use thelounge, it's pretty amazing except it hogs up a lot of disk space with the logs. I ve also been really sad that you can't update it without restarting the process which means I lose everything I am connected to (which on IRc sometimes isnt ideal)
Is it possible to run multiple instances of this, so I could join an irc server that I also spin up in another docker instance and then have a rousing conversation with myself???
Better would be a docker container for an IRC server. Something using a modern approach where you could have link attachments, replies for message threads etc. An IRC slack alternative.
1) scp
2) dpkg --set-selections
They don't want to apt install, they want to use docker :-)
[1] https://knowyourmeme.com/memes/but-i-dont-want-to-cure-cance...
Look at it the other way. Why muck up my OS with a bunch of tiny apps? Who knows what version I’ll pull in my repo today. Chances are good it’s outdated with weird patches.
The docker image is built by the devs. All the proper dependencies are baked into the image. It’s going to run exactly as intended every time, no surprises.
And I can pick up the docker file and my configs and run it exactly the same on any OS.
All of the things you describe are just "package manager, but outside distro control," which is fine I guess but not really a meaningful answer.
I put docker-compose files in ~/configdata/_docker/
The docker-compose files always mount volumes inside the ~/configdata/ directory. So let's say irssi has a config directory to mount I'd mount it to ~/configdata/irssi/config/
Then I can just run a daily backup on ~/configdata/ using duplicati or whatever differential backup tool of your choice and be able to restore application state, easily move it to another server, etc.
So this this would a turnkey way to run this somewhere centralized and persistent, and then you connect to it however you connect to that Docker container (e.g., SSH, remote desktop of some kind).
Of course, a non-Docker way to achieve simple persistence would be to just run a character-terminal IRC client in an SSH-able shell account (or VPS or AWS EC2), inside a `screen` or `tmux` session that can be detached and reattached when SSH-ing in from whatever devices.
(Persistence of your IRC server connections means things like you can see what you missed in scrollback, you aren't being noisy in your channels with join and part messages, you preserve your channel operator status and other channel modes without relying on bots, and you aren't leaking so much info about your movements in real time to random crazy people who hang out in Internet chat rooms.)
(Also, early on, if your leet channels attracted trolls, remaining connected meant that whatever automated countermeasures your client had could help defend the channel. Also, the more people who had channel operator status, the harder it would be for an attacker who, say, "netsplit" to hack ops, to de-op them all, before a remaining op's scripts detected the mass-deop attack, and took out the attacker. Also, your persistence bouncer or shell account obscured your real IP address, so if an attacker targeted your client's IP addr but not your home addr, such as with a protocol or flood attack, you could more likely get back on quickly. Trolls were often annoying, but it was also cyberpunk satisfying when your channel made short work of them.)
You don't _need_ docker, but if you are already set up for it then it's a boon. Adding an app for me to be very available across a fleet of hardware with ceph backed storage is a one-liner.
But irssi is a chat client:
0 - https://irssi.org/