the software we use to run awful.systems, which @dgerard@awful.systems suggested I call Philthy (and I agreed!), is seeking contributors.
like upstream Lemmy, this consists of a Rust backend and a Typescript+React frontend. contributions to both are welcome; use this thread to discuss ideas and collaborate.
here’s some contribution ideas off the top of my head (but all reasonable contributions are welcome):
- (frontend & backend) actually rebrand to Philthy, to prevent confusion between us and upstream Lemmy
- (frontend & backend) rewrite
README.md
to emphasize that this is a fork - (frontend) make the page header and footer more configurable; remove various links that aren’t relevant to awful.systems
- (backend) delete posts from Mastodon when they’re deleted on our end
- (frontend & backend) implement The Firehose, a big admin-only list of the posts and content leaving our instance
- (frontend & backend, ongoing) merge in changes from upstream Lemmy if there are features you wish our instance had
or make suggestions in this thread!
one major blocker preventing folks from contributing to Lemmy-related development I’ve seen is that a lot of people don’t know Rust. if that’s the case, I can offer the following:
- the Lemmy codebase is the worst possible place to learn Rust, but I’d love to start a thread for Rust tutorials and shared learning. it’s honestly an excellent language in its own right, so I’d love to teach folks about it even if they don’t end up contributing to Philthy.
- if you’re good with React and/or Typescript and the feature you want to implement has a backend component, I don’t mind handling the backend portion if I’m able.
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
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.
(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
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”