This is kind of a shortcoming of all package management in general; should deleting the package delete your user data? There's an argument to be made that data should be removed with the application, but deleting data irrecoverably as the default isn't necessarily the easiest approach.
There's also another problem, which is that the behaviour of deleting data may make sense for per-user applications, but for system-wide apps, should uninstalling an application start nuking data in people's homedirs?
As far as I can tell this seems to be for deleting application data (~/.var/app/*), whereas flatpak uninstall --unused is for uninstalling runtimes that are no longer needed.
For fun, a shell script for the same functionality:
#!/bin/sh
br="$(printf "\n")" # Obtain a line-break
# If RM_CMD is unset, use trash-cli
if [ -z ${RM_CMD+y} ]; then RM_CMD="trash"; fi
# List of apps. The leading br is necessary for later pattern matching
apps="$br$(flatpak list --columns=application)" || exit 1
cd ~/.var/app || exit 1
for app in *; do
case "$apps" in
*"$br$app$br"*) ;; # Matches if $app is in the list (installed)
*)
printf 'Removing app data %s\n' "${app}"
"$RM_CMD" "./${app}"
;;
esac
done
Although I do like the idea of having some other information outside of the spoiler, I'm of the opinion that bots should distinguish themselves with the bot flag, and no more. The message should introduce the content, rather than the bot itself, and information about the bot should go in the bot's bio.
Here's a summary of the article! This summary is 100% shorter than the article:
::: spoiler Summary
:::
To be fair, the TL;DR would be a lot shorter if the breaks between sentences were removed. I personally draw the line at around 200 words for a summary, so the 183 words in the summary is a bit long but still a reasonable TL;DR for an article.
Since Lemmy implements spoiler tags, I think wrapping the summary in a spoiler tag would be a way to solve the length problem.
In my opinion, such bots indicate more of a need for some kind of easy "pipe" feature to integrate tools to transform a post before publishing, so that all of the tweaks can be done within the post instead of as a bot reply. For example, there could be a "MTG-ify" button that takes the text in the input box, turns the double bracketed names into CommonMark links, and then puts the modified text back into the input box.
My opinion is that bots should be classed by how they operate.
Summoned bots should be mostly free of restriction. If it needs someone to explicitly summon it, then the onus is on them to not needlessly summon bots. Requiring explicit
Keyword/auto-summon bots should at a minimum be required to implement easy user/community/instance opt-out. I think the most viable would be allowing auto-summon only when explicitly allowed by the user, community, or instance, but allow them to reply to manual summons without restrictions.
So how it would work is if someone had a bot that would, for example, post Nitter links in response to Twitter links, it would be allowed to:
As long as you stay off of any .onion sites, there won't be any difference w.r.t. dark/deep web access. If a domain doesn't end in .onion, then it can be accessed with a regular web browser anyway.
The strategy I use for JS is to try to find things on MDN first, since a lot of the time there's the JS method, and then there's the jQuery/whatever-framework method, and MDN only has the prior.
I think I used to use a brand account just to separate my music subscriptions and regular subscriptions. I'm not sure if it affected suggestions though.
For me, I prefer typing for just plain text, however things involving diagrams and equations can be easier to write out, rather than futzing around scrolling and adjusting the layout.
Also, as a side note, I think 0.3 mechanical pencils are underrated for writing.
What if they technically allow redistribution, but terminate access to recieving updates for doing so? So you can distribute a copy of version N, but if you do so you will not recieve version N+1, and therefore will not be able to get source code for version N+1. Not sure if this is how it is in their contract though.
This is kind of a shortcoming of all package management in general; should deleting the package delete your user data? There's an argument to be made that data should be removed with the application, but deleting data irrecoverably as the default isn't necessarily the easiest approach.
There's also another problem, which is that the behaviour of deleting data may make sense for per-user applications, but for system-wide apps, should uninstalling an application start nuking data in people's homedirs?