Question about Lemmy front-end and feddit.de

lemmyreader@lemmy.ml to Asklemmy@lemmy.ml – 24 points –

feddit.de has been giving "Server error" for some time but I read that the server is still working when using a Lemmy app. Tried the Photon front-end today and choosing feddit.de as instance.

My question (I'm just curious, I have no account on feddit.de) is : Can an alternative front-end on their server co-exist with the other server software ? I guess it would be a matter of installing Photon and then point nginx configuration to that. Or am I missing something crucial ?

20

You are viewing a single comment

It is not that the regular frontend doesn't work and alternative frontends do, it is that half of the stuff on their server (including image uploads and the frontend) don't work because the admin has no time to deal with it. The problem isn't the software used but the lack of maintenance.

Isn't there a software issue if it breaks with time unless you maintain it? What has happened more specifically? Memory leaks?

Memory leaks?

Possible, but much more likely is disk full. Not a bug, just something that happens...

Good point, didn't think of that. That's not an issue with the software. Although, one could argue that it should not break down and become unresponsive.

A lot of software writes to log files or temporary files or lock files or database transaction logs as part of its normal function and when those writes fail due to a full disk the software doesn't work anymore.

That's bad software then, right? The inability to write to disk shouldn't cause the software to lose all functionality. Unless that's its only function, or somehow depends on it for proper functioning. 🤷‍♂️

No. Every good software program should write at least logs to disk. Every good database writes to disk. Add a new post, db will commit to the db and the db will grow in size.

Name any decent sized program where new content is added and I guarantee it writes to disk and will fail eventually if not maintained.

Nice down vote. Let's discuss instead.

I'm saying that the server shouldn't go down just because new content can't be added. You should get maybe a 500-series REST response or something. Not... nothing. Ideally it should write to disk. Ideally it should allow new content to be added. But uptime and content access is still more important than being able to write to disk. It should warn the admin of the serious errors, and explain to the user in some diplomatic/apologetic manner. But never go down completely. That's not resilient at all.

That's my opinion. 👍

For the record I did not downvote.

But I capitulate on your point. It would be great if every piece of software was written with resilience and uptime in mind.

As a former sysadmin that sounds like a dream. But I don’t think I have ever seen that with any mainstream program that I’ve had responsibility for. Does that mean all those programs were bad? I don’t think so. We wouldn’t need sysadmins if all programs were written the way you describe.

Programs can be written to auto rotate their logs, compact and reindex their db’s. Using browser updates as an example, they can even safely auto update and revert back on failure.

How many programs actually do these things? My experience is next to 0. But I wouldn’t call them all bad or poorly written programs.

For the record I did not downvote.

Thank you. It's alright, just aimed at whoever did. Sorry if it came off salty!

How many programs actually do these things? My experience is next to 0. But I wouldn’t call them all bad or poorly written programs.

I meeeaaan... I hear what you're saying. I think your definition of "bad" is a bit stricter than what I was going for. So, you're right. They're not bad in some sense that they're useless or something along those lines. But if I were to write server software, my main goals I guess would be security, performance, and resiliency to failure. Stay alive at all costs (within reason).

But I think we're both on the same side there on all counts. 😁👍

6 more...
6 more...
6 more...
6 more...
6 more...
6 more...
9 more...
9 more...