Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)WH
Posts
3
Comments
1,355
Joined
2 yr. ago

  • I really hope Rakuten buys it.

    why do you think they won't enshittify it? they own viber, see what they did there. ads all over the app, some in channels you can't disable. once it asked me about the data collection I allow, I had to manually disable it with dozens of toggles for all their "business partners", and it took at least half an hour.

  • a bit heavy but cool to have. and it seems to be better than radicale, but I couldn't explain why.

    but it would be even cooler if we could do contact and calendar sync across personal devices without a server, because common people not just won't be able to set up a server, but they won't have a dedicated machine either that is online 24/7. and you shouldn't run a service like this on your android phone that you carry around with you because it'll not let the system save power by throttling the CPUs and switching off cores

  • Which age were you when you didn't agree and what age are you now?

    yeah, that's the reason I probably changed my mind, because it was not too long ago that I would fall under such a restriction, and I remember thinking about schools that do this that it is unfair, and wouldn't have wanted to be in such a school.

  • honestly a few years ago I didn't agree with it, but now things are enshittifying so much that it really seems to be the better option now. it'll unfortunately bar even those from using their phones who would use it for other things than mindless scrolling, using ai chatbots and playing microtransaction and ad filled games, but for the whole class and the whole generation it would be better in the end.

  • Opening a port doesn't mean you are opening your whole home network just the specific services you want.

    until a new high severity vulnerability gets discovered and some bot exploits it on your server, taking it over. and you won't even know. if they were a bit smart, you won't notice it ever either.

    but there's more! its not only the reverse proxy that can be exploited! over the past few years, jellyfin has patched a dozen vulnerabilities, some of which allowed execution of arbitrary system commands. one of the maintainers have expressed that nobody should be running those old versions anymore, because they are not safe even only on the LAN. and this was just jellyfin.

  • if that's true, I assume it is because they don't know about the security consequences, nor about more secure ways. and for 99% that is the worst solution, because they won't tighten security with a read only filesystem, DMZ and whatnot, worse, they won't be patching their systems on schedule, but maybe in a year.

    99% users should not expose any public services other than wireguard or something based on it. on a VPS the risk my be lower, but on a home network, hell no!

  • all of these run the database in a separate container, not inside the app container. the latter would be hard to fix, but the first is just that way to make documentation easier, to be able to give you a single compose file that is also functional in itself. none of them use their own builds of the database server (though lemmy with its postgres variant may be a bit of an outlier), so they are relatively easy to configure for an existing db server.

    all I do in cases like this is look up the database initialization command (in the docker compose file), run that in my primary postgres container, create a new docker network and attach it to the postgres stack and the new app's stack (stack: the container composition defindd by the docker compose file). and then I tell the app container, usually through envvars or command line parameters embedded in the compose file, that the database server is at xy hostname, and docker's internal DNS server will know that for xy hostname it should return the IP address of the container that is named xy, through the appropriate docker network. and also the user and pass for connection. from then, from the app's point of view, my database server in that other container is just like a dedicated physical postgres machine you put on the network with its own cable going to a switch.

    unless very special circumstances, where the app needs a custom build of postgres, they can share a single instance just fine. but in that case you would have to run 2 postgres instances even without docker, or migrate to the modified postgres, which is an option with docker too.