5
Is there any plan to try to push improvements upstream? Or you're not even going to try?
mergeability is desirable (and itself is a two-way street), but there are various foreseeable problems that could unfortunately limit our ability to merge in the future. there are also items on our roadmap that we understand are uninteresting or undesirable to upstream and so shouldn’t be merged; see the build environment discussion elsewhere in this thread for an example of a planned improvement on our end that is very unlikely to be merged upstream.
I still think it's worth a try. If they reject it, nothing lost, no?
sure! anyone who feels that work is important and wants to do it can take it on — we aren’t in the business of obstructing contributors, and again mergeability is desirable. this isn’t on the top of my personal list, but this fork is in its early stages (we haven’t even renamed anything yet), so it’s definitely possible that one or more parties will come along whose ideal contribution is ensuring patches make their way upstream.
Fair shout :)
one for the FAQs:
Q. Why a fork? Why not just contribute to Lemmy upstream?
A. The Lemmy devs aggressively don't want to hear from Lemmy site admins about problems, and frequently don't seem to understand the problems. Many site admins have tried to work with the project and given up in frustration.
e.g.
https://wedistribute.org/2024/03/lemmy-image-problem/
https://lemmy.ml/post/12829700
https://my.jewy.blog/my-love-hate-relationship-with-lemmy
https://lemmy.ml/comment/8968867
https://literature.cafe/post/7623718
We appreciate and are grateful for the Lemmy developers' considerable efforts to build discussion forum software that works well enough to sustain a social network. However, the practical issues with direct contribution remain.
As Lemmy developer nutomic said (archive):
if you leave Lemmy it means less work and less complaints for us.
We are taking him up on this offer.
Our code remains under the same license (AGPL 3) and is fully available for reuse by the upstream project, or anyone else.
but you see, you can't get modtools, because nutomic has a critically important task of creating tankie wikipedia
some tasks I plan to tackle this week:
- rebrand this fork to Philthy and replace the README with more of a stub (to be expanded upon later)
- rename our repos to
philthy,philthy-ui, andphilthy-js-clientif doing so won't break other developers. I'll need to see what Codeberg does when repos are renamed. - we currently have a single-user testing instance at making.awful.systems. this effort likely won't finish this week, but I'd like to come up with a plan that'd use Codeberg's Woodpecker CI to kick off deployments to that test instance whenever we've got new code in
main. there are still some open questions around how to coordinate the versions oflemmy,lemmy-ui, and the deployment flake; I might need to refactor the current test instance to work better in a CD workflow. longer term, I'd like to be able to spin up a testing container for a pull request on demand, but that kind of thing's definitely harder to do when you're hosting it. - run
nix flake lock --update-input lemmy-translationsinlemmy-uito pull new translation strings from upstream (should hopefully fix some missing UI labels I've noticed)
as always, guidance on all of the above is welcome. if anyone has a strong preference for a CI or a suggestion for a container management framework they've used for something similar and enjoyed, or there's a low-hanging fruit feature or fix I might be able to fit in this week, definitely post it here. my only ask for infrastructural stuff is that it's a good fit for a flake-based NixOS deployment like awful.systems, and ideally that it works well with Codeberg.
I've renamed the repos to reflect the fork name. please let me know if this broke anything for you, if you've got a fork or clone of the repos under their old names!
currently I'm working on updating our inter-project Nix, npm, and git submodule dependencies to point at the new repo URLs
suggested site decoration
I know rust and react/typescript, so I might be able to help out with this (time permitting).
Is the intention to stay fairly close to the upstream, or make the code less horrible? Also, I haven't looked at it yet, what makes the lemmy code so bad? Not the first time I've heard this complaint.
thank you! definitely let me know if you’d like a pointer to where something is in the code, or a summary of how anything is architected.
so the problem with Lemmy on the frontend is that it violates a bunch of web dev best practices. a lot of them are pretty easy to spot for someone who’s worked in react before (an example off the top of my head is, the frontend will just throw an exception and show a misleading error page if it can’t parse your JWT. this has broken us in production before). I figure we can clean these up relatively casually, unless we catch something that looks like a security risk (and Lemmy has a long history of those too).
the problems on the backend are a lot more structural — it’s a weird assemblage of sub-crates arranged and typed in a way that makes a lot of types of changes way harder than they really should be. it feels like the kind of rust code someone would write if their main experience was in “enterprise” typescript and they were very new to rust.
as a whole, the Lemmy codebase feels like an excuse to play with technology the authors liked but weren’t particularly knowledgeable in. this is proven out by the fact that they’ve actually deprecated the react/typescript UI and are intent on replacing it with a Rust version using the Leptos framework — a stupendously unpopular choice that seems to be driven purely by the desire to write more rust and use more experimental technology, regardless of the consequences to the project.
there’s also just a ton of systemic weirdness to look out for. for example, Lemmy really doesn’t like running outside of the preconfigured docker container it pulls some of its metadata from (including its version, even though cargo.toml and package.json are right there — this data being missing will silently break cache-control in a very destructive way). I’ve fixed some of that weirdness already just to get a Nix flake version of the software working, but I’d like to fix these breakages in a more cross-platform way too.
as a whole, the Lemmy codebase feels like an excuse to play with technology the authors liked but weren’t particularly knowledgeable in.
Yes, it feels a lot like some of my personal projects where I play with new tech in some of its structure. But it also has stupid decisions.
lemmy was the first example i can remember using of a React based site that is actually zippy and not slow as shit cos it isn't serving 100 ad trackers
Hmm the first sign may be that it doesn't build. I think it's expecting translations that don't exist.
Edit: Cargo build fails, nix build succeeds. Edit2: Oops, submodules.
oh god, they put all the structs in the same file and all the impl's in different ones. Why?
you know, @self has been mentioning things about the awfulness of the codebase and I hadn't yet gotten to look, but .... wow. that's certainly a Choice.
it’s entirely possible they assumed C++’s compilation model applies to Rust
I'd love to help when I have the time. I know a bit of Rust but am fairly confident in TS/React.
I just spent an hour trying to get the backend run locally on my macOS machine without success so far. First, cargo build failed because of a linker error, but that was pretty straightforward. So for anyone running into the same error, just do this:
brew install libpq
brew link --force libpq
cargo clean
cargo build
Then there was an error connecting to the database. Which is strange, because I was pretty sure I had postgres installed. After some digging, it seems that this is a problem with postgresql@14 specifically and does not occur with earlier versions, so I downgraded to 13. With that, cargo run finally executed, but I ran into an actual error here.
>> Error: LemmyError { message: Unknown("Couldn't run DB Migrations: Failed to run 2023-07-08-101154_fix_soft_delete_aggregates with: syntax error at or near \"TRIGGER\""), inner: Couldn't run DB Migrations: Failed to run 2023-07-08-101154_fix_soft_delete_aggregates with: syntax error at or near "TRIGGER", context: SpanTrace [] }
I gave up for now. Debugging database migrations is probably the closest thing to the Basilisk torturing me for all eternity that I can imagine. If anyone knows what this is and how to fix it, I'd appreciate it.
it isn’t just you; this very frustrating lemmy github thread has a bunch of other developers that ran into it too. there are a few workarounds in there — it looks like the official method is to use lemmy’s dockerized setup for everything, of course, but it seems there’s a few other ways forward if you’d understandably prefer not to use docker.
lemmy depending so hard on its weird docker environment is something I really would like to fix very soon
lemmy depending so hard on its weird docker environment is something I really would like to fix very soon
is it just me or is this fundamentally proprietisation?
has anyone bothered checking the docker image for presents?
if they were more technical I'd mutter "Jia Tan mf's"
Oh for fuck's sake. They depend on postgresql@16 but in their official documentation they say to use brew install postgresql, which installs 14 as that's the current stable/LTS/whatever in the brew repos.
brew remove postgresql
brew install postgresql@16
brew services start postgresql@16
$(brew --prefix postgresql@16)/bin/createuser -s postgres
And then run the Lemmy db-init.sh script. Now it works.
At least I didn't have to use Docker.
lemmy depending so hard on its weird docker environment is something I really would like to fix very soon
(to let this rant out just a tiny bit:) it is infuriating how much more rope container-based workflow has given the "works on my machine" dipshits of the world
it has also minorly improved the problem in that if they have to ship container construction workflows (which by and large are Dockerfiles, but..) then you get to see what kind of insane bullshit they pull to do this. but then at the exact same time you get to see that bullshit, which instantly makes things worse again. 1 tiny step forward, 300 paces of frenetic running away in horror
this post was submitted on 05 Apr 2024
5 points (100.0% liked)
FreeAssembly
75 readers
1 users here now
this is FreeAssembly, a non-toxic design, programming, and art collective. post your share-alike (CC SA, GPL, BSD, or similar) projects here! collaboration is welcome, and mutual education is too.
in brief, this community is the awful.systems answer to Hacker News. read this article for a solid summary of why having a less toxic collaborative community is important from a technical standpoint in addition to a social one.
some posting guidelines apply in addition to the typical awful.systems stuff:
- all types of passion projects and contributions are welcome, including and especially those that aren't programming or engineering in nature
- this is an explicitly noncommercial, share-alike space
- don't force yourself to do work you don't enjoy, or demand it of others
(logo credit, with modifications by @dgerard@awful.systems)
founded 7 months ago
MODERATORS