Tips and Tricks

# For Fedora 39 and earlier: $ sudo cp /usr/share/applications/firefox.desktop /usr/local/share/applications/ $ sudo sed -i "2a\\NotShowIn=GNOME;KDE" /usr/local/share/applications/firefox.desktop

# Fedora 40 and later: $ sudo cp /usr/share/applications/org.mozilla.firefox.desktop /usr/local/share/applications/ $ sudo sed -i "2a\\NotShowIn=GNOME;KDE" /usr/local/share/applications/org.mozilla.firefox.desktop

$ sudo update-desktop-database /usr/local/share/applications/ ```

== Reenabling the default browser (Firefox)

If you want to make the default browser (Firefox) visible again after hiding it, you can follow these steps:

``` $ sudo rm -f /usr/local/share/applications/*firefox*.desktop $ sudo update-desktop-database /usr/local/share/applications ```

== Enabling RPM Fusion repos

[CAUTION]
====
This section discusses third-party software sources not officially affiliated with or endorsed by the Fedora Project. Use them at your own discretion. Fedora recommends the use of free and open source software and avoidance of software encumbered by patents.
====

Users may want to take advantage of the non-free software that is made available via the https://rpmfusion.org/[RPM Fusion] repos in order to use the proprietary NVIDIA drivers, multimedia codecs, or other software not distributed as part of Fedora.

The first time you install the RPM Fusion repos, you need to install the versioned RPMs:

    $ sudo rpm-ostree install \
        https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
        https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
    $ reboot


Once you have rebooted into the new deployment, you can run the following command to remove the “lock” on the versioned packages that were installed previously. This will enable the RPM Fusion repos to be automatically updated and versioned correctly across major Fedora version rebases:

    $ sudo rpm-ostree update \
        --uninstall rpmfusion-free-release \
        --uninstall rpmfusion-nonfree-release \
        --install rpmfusion-free-release \
        --install rpmfusion-nonfree-release
    $ reboot

For more information, see https://discussion.fedoraproject.org/t/simplifying-updates-for-rpm-fusion-packages-and-other-packages-shipping-their-own-rpm-repos/30364[this thread] on the Fedora Discourse site.

== Working with Toolbx

=== Finding out if you are currently in a Toolbx container

If you frequently make use of Toolbx to perform various tasks and use multiple Toolbx containers it can be hard to keep track of whether you are currently executing commands on the host or in a Toolbx container. Furthermore, there is currently no command to tell you in which Toolbx container you are working.

To alleviate this, you can add the following shell alias at the end of your `~/.bashrc`:

  alias istoolbx='[ -f "/run/.toolboxenv" ] && grep -oP "(?<=name=\")[^\";]+" /run/.containerenv'

When you open a new shell, you now have access to the new command `istoolbx`. This will behave as follows:

* When run from the host, returns an exit code of 1
* When run from a Toolbx container, returns an exit code of 0 and prints the current Toolbx containers name to the console

If a more automated solution is your preference the following added to your `~/.bashrc` will change your bash prompt to include "[toolbox <name>]":

Now you can include `is_toolbox` in your `PS1` variable and not need to execute any extra commands in order to know whether or not your are in a toolbox or host shell.

Example: ``` export PS1="\[\e[31m\]\`is_toolbox\`\]\e[m\]\[\e[32m\]\\$ \[\e[m\]\[\e[37m\]❱\[\e[m\] " ```

This results in a prompt which appears as such when not in a toolbox: `$ ❱`

However, when running in a toolbox named "default" looks like: `[toolbox default]$ ❱`

=== Running applications from inside Toolbx on the host

This can be necessary if you want to interact with tools available from the host, for example `podman`, `nmcli` or `rpm-ostree` without leaving the Toolbx container in between. You can use `flatpak-spawn`, included in the base installation for this:

  $ flatpak-spawn --host podman --help

If the application you want to call requires `sudo` access, the `-S` option must be supplied to `sudo` like below:

  $ flatpak-spawn --host sudo -S rpm-ostree status

If you find yourself using commands like these frequently to access e.g. the flatpak command from inside the Toolbx container, you can create yourself a short custom wrapper script (*inside the Toolbx container*). To do this, perform the following steps:

1. Define the `istoolbx` alias (for convenience) by executing the command mentioned above in your terminal

2. Make sure you are in a Toolbx container. If the following command doesn't produce any output, you are likely still working on the host!

     [toolbx]$ istoolbx
     <Toolbx container name here>

3. Once you have made sure you're in a Toolbx container, execute the following command:

    [toolbx]$ echo -e '#!/bin/sh\nexec /usr/bin/flatpak-spawn --host flatpak "$@"' | sudo tee /usr/local/bin/flatpak 1>/dev/null && sudo chmod +x /usr/local/bin/flatpak

You now have a `flatpak` command available that allows you to interact with `flatpak` as if you were running the command on the host.

== Working with `ostree`/`rpm-ostree`

=== Tracking changes to the base OS

Some directories in `ostree`-based operating systems are writable by the user, like `/etc`. You can get a quick overview of the files changed under `/etc` using the following command:

  $ sudo ostree admin config-diff

To get a more elaborate diff, you can use something like this:

  $ sudo diff -yrW200 --suppress-common-lines --color=always /usr/etc /etc 2>/dev/null

NOTE: This works because ostree keeps an unmodified copy of the `/etc` directory under `/usr/etc`.
      All of your changes go to `/etc` directly.

== Working with Flatpak applications

=== Directly accessing Flatpak applications from the CLI

The most noticable change when using Flatpak applications instead of conventional installations is that the applications cannot be directly called from the CLI any more, like so:

  $ evince
  bash: command not found: evince

Instead, one can call them like this:

  $ flatpak run org.gnome.Evince

In addition, most Flatpak applications export their internal binaries under an installation-dependent location:

* For Flatpak applications installed from `system` remotes, these can be found under `/var/lib/flatpak/exports/bin/`
* For Flatpak applications installed from `user` remotes, these can be found under `$HOME/.local/share/flatpak/exports/bin/`

[NOTE]
====
If you're unsure to which installation a Flatpak application belongs, you can use this command to print it out:

  $ flatpak list --app --columns=name,installation
====

You can then either add these directories to your `$PATH`:

  $ org.gnome.Evince

or setup shell `alias`es as needed to make them available to the CLI like so:

  $ alias evince="flatpak run org.gnome.Evince"
    # or alias evince="org.gnome.Evince"
  $ evince