What features are missing from piefed, or, why aren't we reccommending piefed instead of lemmy?
-
not to piefed specifically.
Why not? I'm not saying to move everything, but a few communities to Piefed could be nice. A few to Mbin too to keep everyone happy.
Thats literally what I said.
-
We won't 100% know the answer to that until we get there. But in 2025 fear of a lack of CPU cores is NOT what keeps me awake at night.
Early performance results are positive. Check these links out:
https://join.piefed.social/2024/02/13/technical-performance-of-each-fediverse-platform/
https://join.piefed.social/2024/02/09/comparing-network-utilization-of-lemmy-kbin-and-piefed/
There are many many ways to ruin web app performance and choice of backend language is not really a big one. It's what you do with it that counts.
https://piefed.social is running on a low end VPS which costs $7.50 per month. Load average is about 1.45 during the busiest part of the day. Most of the load is caused by federating with lemmy.world and that won't increase as more users come on board.
PieFed is already really efficient with storage. After 16 months of operation, subscribed to every popular community, the piefed.social DB is 30 GB and the media storage is 28 GB. A Lemmy instance would be 10x that.
using Python
Full disclosure: I like Python a lot and have written a lot of it.
That said, if not for my recent work experiences, I would be absolutely horrified at the idea of using Python for such a project. Between the type system and being interpreted, the performance and runtime issues are pretty painful. That and the historical greater dependence on external application servers really makes Python-based services something that really sucks to administer.
However, as I noted, I have also recently seen Python performing far faster than it has any right to with highly-optimized use of multi-processing and offloading the server stuff to Go.
I think I'm going to have to take a look at Piefed source this weekend.
-
While theoretically true, the main bottleneck with Lemmy seems to be the database performance, so with both projects depending on PostgreSQL for that, I somewhat doubt that Piefed being written in Python will have much noticeable effect in reality.
the main bottleneck with Lemmy seems to be the database performance, so with both projects depending on PostgreSQL
Postgres being a bottleneck is a first for me. Not saying it's not possible, just... It's postgres. Wondering if it's more an issue with ORM, etc.
-
Postgres is so quick if you know how to use it...
You don't even need to know how to use it very well, in my experience.
-
If you want it to be "free to most users", the cost of data storage and IO will completely dominate over the cost of CPU.
There are plenty of good arguments to prefer Rust over python for a distributed application, but "language efficiency" is not one of them.
Anyway, if you are biased in favor of Rust and want a decent argument to justify it, I will let you use 'It's easier to compile Rust to WASM and have the application run on the browser, while compiling python in a cross-platform way is a nightmare', free of charge.
Ease of cross-compiling is really one of my favorite things about Rust. It can run anywhere with little coaxing needed.
-
using Python
Full disclosure: I like Python a lot and have written a lot of it.
That said, if not for my recent work experiences, I would be absolutely horrified at the idea of using Python for such a project. Between the type system and being interpreted, the performance and runtime issues are pretty painful. That and the historical greater dependence on external application servers really makes Python-based services something that really sucks to administer.
However, as I noted, I have also recently seen Python performing far faster than it has any right to with highly-optimized use of multi-processing and offloading the server stuff to Go.
I think I'm going to have to take a look at Piefed source this weekend.
Cool! Before you dive in, check this out https://join.piefed.social/docs/developers/
-
You don't even need to know how to use it very well, in my experience.
Really depends on many factors. If you have everything in RAM, almost nothing matters.
If your dataset outgrows the capacity, various things start to matter, based on your workload. Random reads need to have good indices (also writes with unique columns), OLAPs benefit from work_mem, >100M rows will need good partitioning, OLTP may even need some custom solutions if you need to keep a long history, but not for every transaction.
But even with >B of rows, Postgres can handle it with relative ease, if you know what you're doing. Usually even on a hardware you would consider absolutely inadequate (last year I migrated our company DB from MySQL to Postgres, and with even more data and more complex workflows we downsized our RAM by more than half).
-
Personally, because I think all server-centric AP software is broken and I want to see a client-first application to browse the social web.
Piefed goes in the opposite direction, giving more power to the server admins and taking a good page of social engineering / "nudge theory" principles to apply in its design. Much like Mastodon, it seems to be strongly opinionated about how people should behave and it kinda gives me an icky feeling about its culture.
[PieFed] seems to be strongly opinionated about how people should behave and it kinda gives me an icky feeling about its culture
Yea, I get this same feeling. It's not that I mind that culture or being mindful of how people behave and such - I just don't think that is the domain of the software to decide. Individual instances can decide that for themselves, but the software shouldn't influence that kind of thing, I feel.
-
We won't 100% know the answer to that until we get there. But in 2025 fear of a lack of CPU cores is NOT what keeps me awake at night.
Early performance results are positive. Check these links out:
https://join.piefed.social/2024/02/13/technical-performance-of-each-fediverse-platform/
https://join.piefed.social/2024/02/09/comparing-network-utilization-of-lemmy-kbin-and-piefed/
There are many many ways to ruin web app performance and choice of backend language is not really a big one. It's what you do with it that counts.
https://piefed.social is running on a low end VPS which costs $7.50 per month. Load average is about 1.45 during the busiest part of the day. Most of the load is caused by federating with lemmy.world and that won't increase as more users come on board.
PieFed is already really efficient with storage. After 16 months of operation, subscribed to every popular community, the piefed.social DB is 30 GB and the media storage is 28 GB. A Lemmy instance would be 10x that.
-
It may be a bit opiniated, but it's nice to see a different approach from Lemmy devs who don't see the need for any additional moderation tool.
I brought up mod mail during the AMA, it has been considered too complex to implement. A moderation panel with an overview of the mod queue would be nice too, but not a priority.
I'm not saying Piefed is perfect, but at least they prioritize that aspect.
We are working on new moderation features all the time, for example 1.0 will correctly federate instance bans which is quite complicated to get right. There will also be a plugin system which allows for much more flexible mod tools. Its just that our time is very limited for all the work that needs to be done on a project with over 50k active users.
-
For those that may only vote and otherwise lurk, there's a decent amount.
The inability to create multi-communities/reddits (or feeds as Piefed calls them), the absence of post-folding/deduplication for when someone posts the same article to multiple communities (sometimes similar, sometimes distinct), the absence of keyword filtering to automatically filter out stuff from local/all feeds one's uninterested in, and these are just a few from the top of my head for those that mostly lurk.
Keyword filtering is about to be merged into Lemmy. Other features will also be added over time.
-
Can confirm. When we took over the running of feddit.uk migrating the images took forever as it was around 300GB.
Migrating the images as in media? The discussion is about database sizes.
The biggest DB I have is the one from alien.top, which got close to deal with 600k mirrored bots and 10M posts + comments. The database was clocking around 25GB.
-
Didn't I with the Mbin post yesterday?
Yes sorry, it's perfect.
-
Phanpy is phenomenal and fixes a lot of the problems Mastodon and all microblogging platforms have.
Mona is also a good app.
-
Probably app support. If Lemmy didn’t have wefwef/voyager during the API debacle of 2023, I probably would not have stuck around. The default UI is terrible for mobile.
The default UI is terrible for mobile.
I'm definitely in the minority, but I prefer the Web UI on mobile to apps
-
The lemmy.ml server costs 70 Euros per month and doesnt have much loa, with almost 10 times as many active users.
I know the 0.03€ per user per month has been known for a while, but it still impresses me.
-
I run a Pixelfed instance. The code is faaaaaaaarrrrr from polished. Its buggy and the admin interface either doesn't work or is poorly implemented. I'd rather run and moderate Lemmy than Pixelfed. I have considered just shutting it down several times. I run the instance https://social.photo/.
-
We are working on new moderation features all the time, for example 1.0 will correctly federate instance bans which is quite complicated to get right. There will also be a plugin system which allows for much more flexible mod tools. Its just that our time is very limited for all the work that needs to be done on a project with over 50k active users.
This comment was not supposed to be a huge critique of Lemmy, more like a comparison.
Everybody is aware that you do what you can with the resources you have.
-
Keyword filtering is about to be merged into Lemmy. Other features will also be added over time.
Will there be a release with that feature before Lemmy 1.0, or will it be delivered with Lemmy 1.0?
-
Even so, .world will eventually enable parallel sending, and even in the meantime aussie.zone only boasts 375 MAUs. I don't know that such a miniscule minority is worth bending over backwards for and creating further fragmentation.
Don't get me wrong, I'm all for choosing instances other than .world when setting up new comms. They're too big. But while we're still at a point where content amount is the primary concern and we're trying to achieve critical mass I also don't know if endless fragmentation is well advised.
.world will eventually enable parallel sending
But when? I don't want to openly ask LW admins because the 0.19.9 migration took them a while, but it doesn't seem like it's going to happen any time soon. I've seen someone mentioning that they might be delaying it due to resources issues, but their resource usage is not going to go down any time soon.
aussie.zone
It is not only aussie.zone. Reddthat is also hosted in Australia, and then had to add a proxy in Europe to prevent a similar delay: https://reddthat.com/post/37387576/17377718. Lemmy.nz is in a similar case.
Lemmy.blahaj.zone is also Australian IIRC, but not sure where the server is hosted. Reddthat is only 429 MAU, but Blahaj is 1171
