brie

joined 2 years ago
[–] brie 17 points 1 year ago (11 children)

Anyone have recommendations for non-male youtubers? My YouTube subscriptions are pretty much all men, from gaming, to education, to music.... The few non-male YouTube channels have very infrequent uploads, which makes my subscription feed even further skewed.

[–] brie 1 points 1 year ago

Silverblue is very "traditional" as far as immutable distros go. The main difference from regular Fedora I've noticed are the side effects of using rpm-ostree instead of dnf, which is that by using a base image, it is easier to track how an install deviates from the base image, and easy to swap out for another base set of packages by changing the image.

[–] brie 2 points 1 year ago

Now I kind of want an linter that checks that compound words in a given dictionary are joined, and those that are not are separate....

[–] brie 2 points 1 year ago

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?

[–] brie 1 points 1 year ago

The check for if a package is installed can be simplified using flatpak info.

$ flatpak info com.example.Nonexistent &>/dev/null; echo $?
1
$ flatpak info org.mozilla.firefox &>/dev/null; echo $?    
0
[–] brie 5 points 1 year ago

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.

[–] brie 4 points 1 year ago (2 children)

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

(May eat your files)

[–] brie 8 points 1 year ago (1 children)

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:

Summary

[–] brie 9 points 1 year ago (1 children)

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.

[–] brie 5 points 1 year ago (1 children)

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.

[–] brie 11 points 1 year ago

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:

  • Respond to @nitterbot@example.com
  • Respond on posts by someone who's indicated they want the bot to auto-reply to their posts
  • Respond to posts on a community that allows the bot to do so
[–] brie 2 points 1 year ago

There's also DeaDBeeF, which has more UI customization available as far as I can tell.

view more: ‹ prev next ›