Oh wow thanks! :) One program syncs my home Mastodon timeline, with all replies, to a Maildir. Dovecot serves that over IMAP. Sending involves a custom SMTP server which reads the mail message and creates a post from it.
For Mastodon it was all about converting statuses (toots? Posts?) into RFC 5322 messages. Using the status’ ID as Message-Id in the message header is handy. Mail clients do the heavy lifting of rendering threads thankfully!
But synchronising to disk is super inefficient: too many API calls. Should subscribe using ActivityPub proper and store updates received as RFC 5322 messages.
From there we could serve the messages via NNTP. Then, finally, we could use nntpfs(4)
I suppose there’s positive, then there’s “totally changed how I work”. It’s a big call. Maybe a real-world example would make it sound more believable: “before ChatGPT, I would have to sift through stacks of outdated VB6 documentation on $task. This took up most of the day. Yesterday I used a LLM to get a basic implementation of $task then I tidied it up and installed it within an hour.”
If I remember rightly, the backend update takes a long time as the database needs to do a particularly slow schema update.
https://old.lemmy.sdf.org seems to still be ok.
FYI, on lemm.ee I have been testing 0.19.1 patched with the #4330 changes by @phiresky for the past week and have noticed no further issues with outgoing federation, so I think this issue will be resolved with the next release
For me it’s the bloody “video essay” format. Hyper narrated, spoken straight to the camera. Waste of traffic, waste of storage, waste of attention. People think the argument carries more weight, or is just more persuasive, when someone is speaking at you with some vaguely related visual in the background. But really a written piece could be pulled apart so much more quickly.
Unfortunately OpenAI’s Whisper doesn’t do written transcriptions fast enough on my workstation yet for me to use it full time.
BYD employ about 570,000 people and by some measures are the largest carmaker in the world. I’d never heard of them either until a couple years ago. They’ve definitely got the cash to put into PR like this. Past couple years Australia started importing their electric cars. https://en.wikipedia.org/wiki/BYD_Company
Even with (more) UX engineers, it was incredibly difficult to get any development done. When I was in this space, management and contractors were incredibly entrenched playing political games to grow teams even bigger to get more funding. There was nobody with any authority using the thing end-to-end saying “this sucks”.
Unfortunately for those who have those values,
not all paid positions involve acting on those values.
Random brain dump incoming...
Most businesses pay money to solve problems so they can make more money.
You can solve their problems - but not in the way that you may be thinking.
This is a generalisation that is not strictly true, but I say it to illustrate a different way of thinking:
Businesses do not undertake penetration testing because they want more secure software.
They do pentesting so they can stay in business in the face of compliance and bad actors.
To find a job,
you want to start learning what people pay for.
People pay contractors to come in and fix things, then leave again (politically easier, sometimes cheaper).
People pay sotfware developers to develop features (to sell more stuff).
Start looking up job titles and see which ones interest you (DevOps, frontend dev, backend dev, embedded...).
Don't get too stuck on the titles themselves.
It's just to narrow down what kinds of business problems you find interesting.
Other random questions:
What specific projects are you interested in?
What types of problems do you like solving?
Do you like digging in and finding those tricky bugs that have been bothering people for years?
Do you like trying out new frameworks which let you think about the system differently?
Would you rather implement a database or GUI toolbox?
Once you're deep in the belly of the beast, you'll find ways to exercise those values.
It's hard to know in advance what this will look like.
Ah yes! That is a great trick that kept me going doing software dev professionally.
Instead of trying to get the system I was working with to interact correctly with some shit enterprise system, I would find common protocols (or related protocols) and implement that well.
Then I would discover more specifically where the shit enterprise system was behaving badly, and point to something politically neutral (like an IETF RFC) to help get us out of a rut.
It made debugging so much easier.
Those specifications and open-source implementations have had much more engineering talent put in them than what I was usually dealing with.
I'm not so surprised anymore.
I'm self-taught using open-source software projects for guidance.
But not everyone learns like that. For example in the commercial software dev world, having patches easy to apply with minimum tooling isn't usually a priority (for better or worse).
I also think about pop-ups back in the 90s/00s.
Imagine if browsers sent a "No-Popups" header (or something) back then. I doubt we would have seen any change in company behaviour. Instead, it took something like Firefox to implement pop-up blocking by default (https://lwn.net/Articles/130792/).
Yes that's true. I guess what I wanted to point out is that GitLab has dependencies like Postgres, Redis, Ruby (with Rails), Vue.js... whereas Forgejo can use just SQLite and jQuery.
I wonder whether they are aware of the ForgeFed project?