• 42 Posts
  • 767 Comments
Joined 2 years ago
cake
Cake day: July 5th, 2023

help-circle






  • Avid Amoeba@lemmy.catoMicroblog Memes@lemmy.worldWelp
    link
    fedilink
    English
    arrow-up
    28
    arrow-down
    1
    ·
    edit-2
    2 days ago

    Keep telling people about Mastodon. Don’t push them. Just explain that this is a result of BlueSky being VC funded and more will follow just like it did with Twitter, Facebook and so on. Add that Mastodon is open source run by multiple non-profits around the world so if one fails, the rest would pickup the slack. Conclude with - if they want to stop having to uproot their network every so often, Mastodon is their best bet for microblogging.




  • Much more important than the enjoyable culture is the material aspect - how much work each developer has to do. Nice vibes help delay burnout but rarely eliminate it. Or they let it happen with a smile on the face.

    Pay the developers instead, so they can reduce hours worked elsewhere, if you can. Or contribute code, if you can. This isn’t aimed at you personally, but anyone reading. I can’t contribute code but I can pay so I do that.






  • Well, you gotta start it somehow. You could rely on compose’es built-in service management which will restart containers upon system reboot if they were started with -d, and have the right restart policy. But you still have to start those at least once. How’d you do that? Unless you plan to start it manually, you have to use some service startup mechanism. That leads us to systemd unit. I have to write a systemd unit to do docker compose up -d. But then I’m splitting the service lifecycle management to two systems. If I want to stop it, I no longer can do that via systemd. I have to go find where the compose file is and issue docker compose down. Not great. Instead I’d write a stop line in my systemd unit so I can start/stop from a single place. But wait 🫷 that’s kinda what I’m doing isn’t it? Except if I start it with docker compose up without -d, I don’t need a separate stop line and systemd can directly monitor the process. As a result I get logs in journald too, and I can use systemd’s restart policies. Having the service managed by systemd also means I can use aystemd dependencies such as fs mounts, network availability, you name it. It’s way more powerful than compose’s restart policy. Finally, I like to clean up any data I haven’t explicitly intended to persist across service restarts so that I don’t end up in a situation where I’m debugging an issue that manifests itself because of some persisted piece of data I’m completely unaware of.