>>813c61f4 tfw no chanting

images.jpg, 30.09 kB

https://m.soundcloud.com/princesschelsea/04-i-love-my-boyfriend

>>cb1194e3 This version has a guy singing at the end who is kind of grating. Reccomend the youtube version instead.

so I tried to upload yet another pack of files and node ate 2.8G+ of RAM, hanging a VM oh well gotta retry {"level":40,"time":1713381836133,"pid":590099,"hostname":"host","module":"lazystream","msg":"Failed processing messages to id: 12D3KooWL8xa855uAcLpstvXSyzVqUgErW5kkwJ2TSexm4EnT3Qg. unexpected end of input"} {"level":50,"time":1713381836580,"pid":590099,"hostname":"host","module":"lazystream","msg":"Cannot push value onto an ended pushable"} {"level":40,"time":1713381840808,"pid":590099,"hostname":"host","module":"lazystream","msg":"Failed processing messages to id: 12D3KooWJQ9L3ChAcN7vnJ3VkYciZYxfL2hVVUyjKiQz9Ffw6wBs. unexpected end of input"} Terminated those are last logs no errors though, I killed it (RIP) Sometimes I wonder is it ethical to use GBs of other people space they provided for actual messages mostly, and with replication=1 every node would have to download all the stuff if they want to open /mu. But then I remind myself that such issue better emerge sooner than later. Bugfixing accelerationism

The bulk of the data on any imageboard is gonna be the files either way. Maybe setting the default to 64 was overkill in some sense, but then again it's basically the same as dividing it up into individual posts Keep also in mind the default acceptable file size for a file to actually show up is 5 MB, so unless other people also configure that to be bigger, they won't see the files that are bigger than that. Eventually we can experiment again with the sharding aspect of peerbit for the file chunks so they can be split up across the network and not need a full copy on every node.

>>03f5b102 Actually the only thing that really has to be done for that is splitting up the config settings for post, file references, and file chunks replication factors.