- cross-posted to:
- fediverse@lemmy.world
- cross-posted to:
- fediverse@lemmy.world
TLDR: The main reason was Lemmy hogging server resources.
Last year, during the Reddit 2023 API controversy I finally deleted my account and moved on to Lemmy. Here’s a look at my experiences and why I eventually decided to switch to PieFed.
You must log in or register to comment.
There is /kbin which seems down all the time and its fork MBin which seems to have a good community but is written in PHP which I try to avoid.
Can you expand on the reasoning for avoiding PHP? I get avoiding Java; JRE it’s s disaster, and a resource hog.
The only software through my servers have ever been owned by scriptkiddies were poorly written PHP software, specifically WordPress in my case.
It’s just a personal preference because I’ve been burned too many times.
I’ll grant that PHP is set up to allow some super shitty code, but on fairness to the language; WordPress is a dumpster fire (compounded by endless awful plugins). That’s compounded by it’s ubiquity, so it’s a massive target.
I just set up mbin as a single-user instance, and other than a bug I found (that they fixed live with me, in chat, including PRs), it’s been awesome.
I hope your instance continues to work well for you 👍
Interesting! Any insights or comments on what’s increased the resources of lemmy over the recent updates?
Sadly I couldn’t figure it out. It seems it’s something with the database for sure but what exactly I don’t know.
Yea I did a quick search through the GitHub issues, and it seems like there are some growing pains with updates they’re making to the way things work and the load it puts onto the database. Sad to hear for smaller instances as my impression was that lemmy had pretty good performance for smaller instances. Architecturally, it makes sense that there are different tradeoffs for bigger and smaller instances. It’d be good to see things mature to the point that you can tune things for your instance size. In the end though, picking the appropriate platform but with the assurance that migration can occur when you need to change platform may be a good way to go.
Anecdotal evidence: I run two instances, a private and a public one. Neither uses a lot of resources.
But I get the database thing. Its spiking every couple minutes and a lot every hour. It’s not a big deal if you have 2 threads at least but I can see how it doesnt work for everyone in every scenario.
I‘m glad alternatives exist and I‘m much more positive on AP alternatives than protocol exiles.
But I get the database thing. Its spiking every couple minutes and a lot every hour. It’s not a big deal if you have 2 threads at least but I can see how it doesnt work for everyone in every scenario.
Yea database management seems to where the growing pains are right now (with the core devs welcoming help from anyone with DB/PostreSQL expertise) … and indeed it seems to be a perennial issue across the fediverse platforms.
If I may ask (sorry, probably annoying) … what sort of resources would you recommend for a small personal lemmy instance? (let’s say 1-5 users, ~200 community subs and a few local communities?)
Not annoying at all.
I‘m running a public instance on two threads and I think 2 gb of ram. A private instance shared with other services on 6 threads and 8 gb of ram. Make of that what you want. :)
I would probably rent a vps which you could extend if needed but start small. With 2 threads and 4 gb of ram at least.
Cheers! 2 threads and 2gb RAM I’d what I would have hoped for anyway. Thanks!
Interesting and PieFed looks promising
I think there’s a pretty fair argument that more common and easier languages and tech stacks are preferable platforms for smaller more personal instances … just the comfort of being able to modify and debug is probably worth whatever other tradeoffs may be encountered. Python, naturally, is basically a prime candidate. So yea, PieFed seems very cool, especially for personal servers and they’ve got a good performance profile.
On that topic, are you guys still doing the Rust book club?
Ha, yea! If you know rust, then you don’t need to reach for Python (right?!). Plus the main motivation was to contribute to lemmy itself while also learning rust. That another platform is good for personal instances doesn’t change that, though piefed does seem cool and I can see myself wanting to get involved with it at some point.
There is Sublink but it’s written in Java, I don’t think I want to deal with Java’s runtime environment.
Don’t hate Java just for the sake of it. According to the repository they ship a Dockerfile and use gradle to build it. Everything should be abstracted for you.
When comparing environments for a program between Java and Python you should probably prefer Java’s. Years of experience and build from the ground up for enterprise deployment. Python module system is hacked together. It ain’t even be fair for python to compare itself in this regard.
Also this project is spot-on within Java’s main territory. It makes absolutely sense to me to use Java for such a program.
Plus monitoring/maintaining a Java application is way better then any python program.
Java and gradle build is way easier (IMO) than trying to wrangle the dep and build steps of everything react/node/rust based.
along those lines, how well would the link-aggregator concept match up with one of the BEAM languages (Erlang, Elixir, Gleam)?
That’s beyond my experience but I would say functional languages can perform similiarly.
I suppose - and honestly do not know if - aggregation is done via synchronization into some persistance unit.
Therefore I would eypect that a functional language like Elixir, Lisp etc. would outperform a language with manual memory management in terms of maintainability.
Depending on the capabilties of packing structs into close memory or traceability and elaboration of compiler it may outperform single or multi-threaded.
Though outperforming recent JREs may be hard, since they may trace hot paths. Default configuration Java vs. a proficient developer of a functional language I assume that latter at least go even.
But I can’t judge. Even on the repository of said program I did not even bother to look at the contents of the gradle.build or Dockerfile to be honest.
I do think that maintainability of functional languages, when only the common denominator between any functional language is used, is better to spaghetti Java source code. But that’s another issue, right?
// edit: Spaghetti Source Code is a good thing in my opinion. And sincr I did not adsress your question directly: A proficent developer is more likely to write faster Java then functional code, since Java is just a layer above C with one of the best compilers there is. Functional languages require carrying some non-neglectable knowledge of the compiler to make use of the fastest paths through the code. On the other hand Java is just ALGOL-Syntax and therefore imperative; Which translates more easier into *.asm.
// edit2: Synchronization into some db isn’t depending on the nature of the language but there may be overhead where some concepts of languages simply perform better. So I would expect that transitions from some interpreted language is slower then compiled languages. Note that even though Java belongs to the former it is conceptually compatible with the latter. I’m out. You called me out. I’m a still a newbie. Had to append so much.
What are the main differences from a user perspective rather than hosting? Is it worth checking out?
I think it is.
-You can arrange communities it topics
- you can show community posts as å wall of thumbnails, nice for memes
- shows user reputation
- you can hide posts from searches
- moderation tools (there are more)
- you can post videos and polls
- better integration with PeerTube
- keyword filtersBut it doesn’t have an API for 3rd parties
‘subscribe to anything’ is handy, too. I’m subscribed to this post, for instance, so get notifications of new top-level comments.
The api is being worked on for the 1.0 release and there’s also some work being done for lemmy api compatibility to use lemmy apps https://codeberg.org/rimu/pyfedi/issues/13#issuecomment-1814982
