@kev Would it be better instead if the "card" was generated and fetched by the client instead ? There are much more clients than instance out there, but people won't read your post at the same time, and their mastodon client could decide or not to show these cards
@postmarketOS Well, think of the engineers working in Gitlab. They were probably forced to implement this as their product owners / managers want to go in the AI hype train too. The only hope here is that they don't use everything they host to fine tune without any form of consent ...
Apparently, in python web ecosystem, /foo/bar and /foo%2Fbar are interpreted the same (but not /foo?bar and /foo%3Fbar at least) ๐คฆ #Python#FastAPI#flask#django
today I'm thinking about the tradeoffs of using git rebase a bit. I think the goal of rebase is to have a nice linear commit history, which is something I like.
but what are the costs of using rebase? what problems has it caused for you in practice? I'm really only interested in specific bad experiences you've had here -- not opinions or general statements like โrewriting history is badโ
@b0rk Previous week in my team : we do rebase before merging to main so while we still have merge commit, we always merge 1 commit. Dev A create a branch, do many commits. Dev B do a branch from Dev A branch (here was a mistake). Dev A rebase and merge, Dev B branch is a bit "lost" from main because it is based on a gone history. We ended up checkout individual files into a brand new branch
On the surface, the current #Linux distribution model (where distros package everything, from the kernel to the apps) seems fine.
But it's pretty broken, and it's holding the Linux desktop back, which is why distributions like #Ubuntu or #Fedora (and a lot more), are moving away from it, and replacing packages with Snaps and Flatpaks for graphical applications.
Here's my opinion on this, trying to explain why exactly this change needs to happen:
