• 2 Posts
  • 13 Comments
Joined 1 year ago
cake
Cake day: July 3rd, 2025

help-circle

  • 2nd DB would be on the NAS but its not being used by the app, so as long as it’s asynchronous writes, you should be okay

    But then I have to maintain it too. And it will be using RAM that was supposed to only be for servicing RAID. On a platform where RAM can’t grow

    For sure my setup will be growing and changing with time. But ATM this “prod” db lives only on laptop’s SSD


  • replication in the database it self

    AFAIK db replication would require running another db on NAS. Which I tried to avoid

    I have another cronjob that takes a backup into the first database docker init folder. Older backups end with -date so they won’t get picked up by the init script. You can do similar with just docker.

    Yeah, that’s why I’m thinking to do. Have a container that watches changes to db data and rsyncs those into the NAS for safekeeping. My main goal in all of this is so db data won’t die with laptop’s SSD







  • it’s generally not a good plan to put anything that needs realtime access remote to the device processing it

    So in your opinion putting whole nextcloud_data as NFS mount is also a bad idea? Keep NFS as external storage and/or only user data?

    AIO docker

    It was too blackbox to me. I had some issue and found it hard to debug. fpm+nginx is more my speed
    This BorgBackup app is available only in AIO?


  • You can easily just try it out though

    Yeah, but if that setup leads to problem in a few months, I won’t catch that. That’s why I decided to ask and judging by the other answer, I dodged a bullet here

    Now I’m thinking of setting up something like this. Maybe even in another container? One volume with data bound, one with NFS and a bunch of scripts in entrypoint to rsync(?) between the two on inotifywait. There is lsyncd but it’s been unmaintained for two years now





  • The question I responded to was rather a general one. And I think that seeing all dev-related dramas as “that guy was just fascist all along” is similar to saying “all X are thieves” - a simplification that is easy to choose because it addresses our emotions regarding what has happened but not necessarily always the best explanation

    That is when they have a meltdown and quit the project because demand for bug fixes or new features it too much pressure.

    That requires self-awareness to ask oneself “maybe I need a break?” and I think such decision can be hard to make due to sunken cost fallacy. I think that with the pressure of the pings about bugs and requests etc, it’s easy to get into mindset of “it’s either on or off” with nothing in between. Because 5 bugs solved means only 3 other to go.
    And the second option is to dig in harder and in this case “curate the feed. All of it. Whatever that means”

    I’m not saying that that person did not act out of an agenda. But I can imagine a set of choices that lead to a catastrophic breaking point


  • I think it’s the pressure and the solo developer model

    You put something out. It seems to be running. There are bugs. You fix them. There are more bugs (pareto is a PITA). You fix them too. Someone accuses you of sacrificing kittens in the basement. There are ideas for features and more bugs. Some worded in an entitled or just tone-deaf way. Very often you’re the only one working on the project and saying “I accept PRs” somehow became received as a FU. It becomes hard to put the project away for just a week
    You are perpetually in “I-fix-it” mode
    Not to mention that in order to even start a project like that one needs to have at least a bit of “fuck it, I’ll do it myself” mentality

    It’s a pity that !unfinishedprojects@forum.unfinishedprojects.net wound down. I hoped it might have been a space for projects to find communities. As we see around, it doesn’t require a 10 person team with a kanban board to write something that works. But on the other side of the spectrum I think a project needs some sort of community around it. So even if there’s only one dev, someone else could write the tutorials, less technical parts of docs, help new deployments etc