> All the cache plugins break the system and thus aren't usable
We intend to rewrite the whole caching system during this summer.
> find out why web requests are an order of magnitude slower than other services
We intend to improve both network and load balance and, as a consequence, that should improve.
> fix database thrashing
Can you elaborate on that?
> replace qvitter with something that doesn't destroy performance, and supports GS' extensive featureset
We want to work on some UI/UX improvements and @dansup has some plans in mind, but I guess it will depend a bit on how fast we are tackling the other issues tho.
> probably other stuff I'm forgetting.
Keep them coming as you remember! :)
> I don't even know why they are bothering.
We just like GS and believe in its potential.
> It's hard to know what culture GS has now, given that a lot of people have moved on elsewhere or moved to different software. I guess we'll see what the current devs for it have in mind for the direction they want to take it.
We will remain true to the values that have always been intrinsic to *GNU* social.
I think it is hard to claim GS has a single culture. There is a collective conscience in a subscribers circle, another in an instance, another in a circle of highly connected instances and so on. We can escalate this to the point in which we analyze the fediverse's collective conscience with principles like a preference for decentralized services and eventually some technological comfort?.
People have different interests and ideologies... I guess there is space in the fediverse for everyone's interests and ideologies. GS just is, I don't think it or its devs take a role on setting a culture more than gcc devs do in who will use their compiler.
> My prime suspect for the database thrashing was the queue. Sounds like a fair bet...
> My take on that was to port it to postgresql. Can you tell me the big differences between a DBMS and the other? I thought they weren't that much different these days...
TBH, I'm not sure why GS doesn't support PostgreSQL already, it uses PDO so supporting both shouldn't be that hard...? (Despite that, we should move from PEAR/DB modules to something more modern and with active maintenance (there are various non-solved open issues on DB module upstream) anyway)