10:55 <nullroute>

10:55 <nullroute> cy8aer how many resources does an instances of lemmy take? I couldn't find that info anywhere on their site

10:56 <cy8aer> Don't know either. I am just a user on an instance in germany.

10:57 <nullroute> According to ChatGPT: Server or VPS: You will need a server or a virtual private server (VPS) to host the Lemmy instance. The server should have sufficient resources to handle the expected traffic and user load. The specific requirements will depend on factors such as the number of users, the amount of content, and the desired performance. As a general guideline, a server with at least 2 CPU cores, 4 GB RAM, and 20 GB of storage should

10:57 <nullroute> be a good starting point.

10:59 <ChaosPrincess> please dont use bullshit generators to make those kinds of decisions

10:59 <nullroute> :shrug: its a good guideline better than the nothing that can be found on their website.

11:00 <ChaosPrincess> its not

11:01 <nullroute> What do you recommend? or have a link to a recommendation then instead?

11:05 <ChaosPrincess> the problem is that the bullshit generator provided completely random data that has no relation to actual hardware requirements. esp since they dont have those listed on their site, the bs-gen cant possibly "know" it

11:09 <cy8aer> So for nullroute 's question: The engine itself is written in rust and can run on a raspberry pi. That means it is possible to run a private instance with minor ressources. But it will grow with the number of users on the instance and probably with the popularity of a community

11:10 <cy8aer> (this is according to https://github.com/LemmyNet/lemmy)

13:01 <mini_> from their actual docs: Lemmy uses roughly 150 MB of RAM in the default Docker installation. CPU usage is negligible.

13:01 <mini_> https://join-lemmy.org/docs/en/administration/administration.html

13:14 <marcan> we're going to be on some Discourse instance most likely

13:14 <marcan> I'm not particularly interested in lemmy

13:16 <ellyq> same for us, seems like the only reasonable option

17:40 <skmp__> hmm

17:40 <skmp__> so I was thinking on 4k pages / emulation

17:41 <skmp__> well, one would need one bit per page

17:41 <skmp__> or two for 16k

17:42 <skmp__> or a 16-bit xor

17:44 <skmp__> 32 GB address space

17:47 <skmp__> one could also use a 512mb rainbow table

17:48 <skmp__> marcan: so, lack of 4k pages could be fully mitigated with ~ 5-15% perf hit and 1-75% higher memory usage

17:48 <skmp__> is there any chnage in native 4k page support?

17:48 <skmp__> otherwise I think i'll move forward with the rainbow table

17:49 <skmp__> should average +2 (0-30) latency to memops

17:49 <skmp__> (cyclces)

17:50 <skmp__> usually they make up to 50% of the opcode mix, often closer to 25%

17:52 <skmp__> i still think that providing a maps scoped /dev/tlb and implementing AWE like NT has, would bealso an acceptable solution

17:52 <skmp__> I think you were against any kmods last time

17:52 <skmp__> though