Irssi: IRC client in a Docker image
hub.docker.com
hub.docker.com
For example, my exim image https://hub.docker.com/r/grepular/exim4 is built like this: https://gitlab.com/grepular/docker-exim4/-/blob/main/Dockerf... - The final image only contains the necessary executables, shared lib files, CA certs, timezone files, a few other bits and nothing else.
xxx/znc 25.4MB xxx/oidentd 10.6MB
this is based on alpine and at most I could save 30MB total. Not worth the effort for me.
I've noticed a lot of people seem to think Docker is some dark art technology when it's really just an amalgamation of various things that you can do anyway.
Incidentally, when I was on dial up and before I had a home network (just one family PC) I started to learn networking by running things like IRC servers (unrealircd to be specific) and multiple clients locally (including eggies). I was really talking to myself in every sense. Was quite fun to give myself ops etc.
I personally use weechat inside nsjail on a raspberry pi (isolated rpi is enough here, but just for fun): https://github.com/google/nsjail/tree/master/configs
What's the difference?
A good book on this was "Hacking: The Art of Exploitation".
My argument though is that irssi is that old, I think automatic file receiving (DCC) is off by default and it has sensible defaults and a long history of being reliable(?)
They don't want to apt install, they want to use docker :-)
[1] https://knowyourmeme.com/memes/but-i-dont-want-to-cure-cance...
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:
About
Irssi is a modular text mode chat client. It comes with IRC
support built in.[0]
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.)
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.
The docker image is built by the devs.
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 do agree that Docker is ubiquitous in the development world, but I think the fraction of people even aware enough of packaging to have an opinion is vanishingly small.
Soon everyone adopts this, and then someone complains “why is there 500 libc libraries on my machine” or “there was critical bug and I had to update 388 containers - and some maintainers didn’t update and it’s a giant mess!”
Then someone will invent dynamic underlying container sharing (tm) and the pendulum will swing the other way for a bit, and in 2032, one dev will paste your comment in a slightly different form - why muck up my mindvisor with a bunch of tiny apps? Isolated runtimes are built by the devs,
And so on, back and forward forever
My god, we've discovered a genuine perpetual motion machine.
> this is static linking in another dress
Although static linking usually seems to result in small binaries that just run on the target machine while this needs all the Docket machinary (and the image sizes can get horrendous)
1) scp
2) dpkg --set-selections
But secondly, containerization, despite its vulnerabilities through the years, does add a layer of security to applications. And we must not forget that irc clients have been exploited in the past. Remember the old adage, never irc as root.
What I'm confused about is why it's notable enough to be on the front page of HN. If you needed this and you use K8s you could trivially write this Dockerfile yourself.