While yay doesn’t have a direct --needed option like pacman, you can still achieve a similar result using a loop. Here’s how you can install packages from a list, skipping those that are already installed:

1. First, export the list of installed packages from the source system:

yay -Qqe > installed_packages.txt

2. Transfer the “installed_packages.txt” file to the new Manjaro system.

3. On the new system, use the following bash script to install packages:

#!/bin/bash

# Function to print a separator line
print_separator() {
    echo "========================================"
}

# Function to handle Ctrl+C
ctrl_c() {
    echo
    echo "Skipping current package..."
    return 1
}

# Set up trap for Ctrl+C
trap ctrl_c INT

# Read the file line by line
while IFS= read -r package; do
    print_separator
    echo "Processing package: $package"
    print_separator

    if ! yay -Qi "$package" &> /dev/null; then
        echo "Installing $package..."
        echo "Press Ctrl+C to skip this package."
        print_separator
        if yay -S --noconfirm "$package"; then
            echo "Installation of $package completed."
        else
            if [ $? -eq 130 ]; then
                echo "Installation of $package skipped."
            else
                echo "Installation of $package failed."
            fi
        fi
    else
        echo "$package is already installed. Skipping."
    fi

    echo  # Print an empty line for better readability
done < installed_packages.txt

# Remove the trap
trap - INT

print_separator
echo "All packages processed."
print_separator

This script does the following:

• It reads each package name from the “installed_packages.txt” file.
• For each package, it checks if it’s already installed using yay -Qi.
• If the package is not installed, it installs it using yay -S --noconfirm.
• If the package is already installed, it skips it and prints a message.

Save this script as “install_packages.sh” and make it executable:

chmod +x install_packages.sh

Then run the script:

./install_packages.sh

Important considerations:

• This method will install packages one by one, which may be slower than installing them all at once.
• The --noconfirm option is used to avoid prompts, but be cautious as it will automatically accept all default options.
• Some AUR packages might still require manual intervention during the build process.
• Be aware that not all packages may be compatible with the new system, especially if there are significant differences in hardware or software versions.
• This method only installs packages, not their configurations. You’ll need to transfer configuration files separately.

By using this approach, you can replicate the functionality of the --needed option while using yay to install packages from both official repositories and the AUR[2].

Citations: [1] https://www.hostzealot.com/blog/how-to/installing-yay-aur-helper-on-arch-linux-a-step-by-step-guide [2] https://www.reddit.com/r/archlinux/comments/jtaraj/is_there_a_way_to_automate_pkg_install_with_yay/ [3] https://linuxcommandlibrary.com/man/yay [4] https://stackoverflow.com/questions/53921707/loop-in-order-to-load-or-install-packages-does-not-work-what-am-i-doing-wrong [5] https://forum.manjaro.org/t/force-yay-to-rebuild-aur-package-s/141726 [6] https://es.hostzealot.com/blog/how-to/instalacion-de-yay-aur-helper-en-arch-linux-guia-paso-a-paso [7] https://xerolinux.xyz/posts/install-yay-paru/ [8] https://bbs.archlinux.org/viewtopic.php?id=281104

deleted by creator

This is golden.

Raspberry Pi 5 with 8 GB of RAM

He already has a couple spare computers. I don’t really know why he asked to try it on the Pi.

I don’t know I would have to ask him.

I remember there was a lot of drama around this, I can’t believe it’s still an issue.

Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)

Comprehensive Tagging System

I once read that there are some states in the U.S. where firefighters don’t put out fires in houses that don’t pay a monthly subscription.

I’m particularly concerned about the potential for automods to become a problem on Lemmy, especially if it gains popularity like Reddit. I believe a Discourse-style trust level system could be a better approach for Lemmy’s moderation, but instead of rewarding “positive contributions,” which often leads to karma farming, the system should primarily recognize user engagement based on time spent on the platform and reading content. Users would gradually earn privileges based on their consistent presence and understanding of the community’s culture, rather than their ability to game the system or create popular content. This approach would naturally distribute moderation responsibilities among seasoned users who are genuinely invested in the community, helping to maintain a healthier balance between user freedom and community standards, and reducing the reliance on bot-driven moderation and arbitrary rule enforcement that often plagues many Reddit communities.

Grant users privileges based on activity level

A more robust approach could involve combining multiple user engagement metrics like votes, reading time and number of comments, along with a system that sorts posts depending on how they compare to their community averages. This system would be less susceptible to manipulation by new accounts or brigading, as it would require genuine engagement across multiple factors to influence a post’s ranking.

Incorporating User Engagement Metrics in Lemmy’s Sorting Algorithms

Reminds me of Custom Feeds

• Inspired by Firefish’s Antennas feature
• Similar to Reddit’s multireddit functionality
• Follow specific users, communities, and instances
• Include/exclude tags or keywords
• Choose post types (posts, comments, or both)
• Set custom feeds as default

The decentralized nature of Lemmy, while appealing in theory, creates significant frustration in practice due to widespread instance blocking. Finding an ideal instance becomes a daunting task, as users must navigate a complex web of inter-instance politics and restrictions. This challenge is further compounded for those who prioritize factors like low latency or specific content policies. Lemmy’s architecture heavily favors instance-level configurations, leaving individual users with limited control over their experience. The only reliable solutions seem to be either hosting a personal instance—a technical hurdle for many—or simply hoping that your chosen instance’s admins align with your preferences and don’t block communities you enjoy. This politicking ultimately undermines the platform’s potential.

There were several issues on GitHub regarding proposals on how to solve the low visibility of small instances. However, after the Scaled Sort was implemented, all those issues were closed, yet the problem persists. I continue to use Reddit the same as before because I primarily used it for niche communities, which are lacking here. The few times I’ve posted to a niche community here, I’ve either received no answers or been subject to drive-by downvotes, likely from users not even subscribed to the community. As a result, I now only post on Lemmy when the post is directed to a large community, and I use Reddit for the rest.

Even large social media platforms have trouble dealing with bots, and with AI advancements, these bots will become more intelligent. It feels like a hopeless task to address. While you could implement rules, you would likely only eliminate the obvious bots that are meant to be helpful. There may be more sophisticated bots attempting to manipulate votes, which are more difficult to detect, especially on a federated platform.

User-Driven Linking:

• Allow users to suggest links between related posts, with a voting system to confirm relevance.
• Create a “Related Discussions” section for each post, populated by user suggestions.

Dynamic Linking System:

• A system that automatically links related posts across different communities and instances.
• Allow users to see all related discussions in one place, regardless of where they were originally posted.

Consolidated View:

• Create a “Consolidated Thread” view that aggregates comments from all related posts into a single, cohesive conversation.
• Provide an option to switch between individual instance views and the consolidated view.

Merge comments from similar posts into a single view

Something like multireddits or Kbin collections would solve this, but it would still take a lot of effort to turn all similar communities into a single group. I really hope there is an automatic way to solve this.

My biggest issue is that when I post, I’m torn between sharing in the community of the largest instance or in the instance I prefer the most. Posting in the largest instance offers more visibility for my post, but it feels like I’m not supporting the instance I truly like. The communities are too fragmented.