Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)S
Posts
1
Comments
49
Joined
3 yr. ago

  • Having the default box being "on" is only for the purpose of hoping people click through without realizing.

    There is literally no other argument here. "Consent" is: "Hey do you want this, yes or no?". Not "We are assuming yes unless you explicitly tell us otherwise".

  • Reading through the post it looks like the project leads (Fedora council members) are arguing in favour of "opt-out" and the larger community is arguing in favour or either opt-in or a middle ground where the user has to select an option with no default.

    Honestly it seems like the Fedora team is arguing that there are only two options: opt-out, or nothing at all. This isn't true and people are commenting with more reasonable alternatives.

    I know its not in development yet, but if the Fedora council members are saying "opt-out or nothing", not a good look TBH given this initial community response.

  • I daily drive Fedora Silverblue on my laptop and distrobox has been great.

    I have layered only two packages: USB Guard and Distrobox. I run syncthing in a rootless podman container, and the rest goes through Distrobox.

    I was even able to setup ProtonVPN in distrobox and it functions as if it was directly installed on the host (just need to map your home folder and some permissions).

    I hope that immutable becomes either the standard or at least all major distros start offering it as an alternative. Makes everything foolproof and makes me much more willing to try new packages and tools because I can always just roll back.

    The only thing that would really make it perfect is if files in /etc/ where also handled in a similar manner. IE: Can make changes to configuration files, and easily roll back to defaults at any time.

  • I don’t think it will have any impact tbh

    Historically the flow of code has pretty much been:

    1. Fedora
    2. CentOS stream (as of a couple years ago)
    3. RHEL
    4. CentOS Rocky Linux / Alma Linux

    I think there’s been discussion on what will happen with Rocky/Alma, but nothing should change with Fedora.

  • I also recommend Fedora if OP wants a similar “just works” experience as Ubuntu.

    Been using it for a while now on my desktops/laptops with no issues.

  • Yeah that’s true.

    I guess I was coming at it more from a “why doesn’t Ubuntu/fedora/debian promote or endorse something like the AUR in their official docs”

    But yeah no distro really has an AUR, and it’s kind of a chicken and egg problem now because the barrier to entry for the AUR is much lower than anything else

  • I think looking at the two major enterprise players (Red Hat and Canonical) can give hints.

    Fedora: run by Red Hat, upstream of RHEL. No way they are going to allow an unreviewed repository to be shipped with fedora by default. But they do have guides to add RPM fusion, and copr repos (the closest equivalent)

    Ubuntu: run by Canonical. No way they are going to allow an unreviewed repository to be shipped with Ubuntu by default. But they do host and have guides for PPAs (closest AUR equivalent)

    Debian: kind of the base layer for a lot of other distros. Debian itself is kept very minimal, and has a whole philosophy on what packages are allowed.

    Edit: I realized this implies PPAs, copr and the AUR are the same when I know they aren’t functionally. I am just trying to highlight the motivations behind the distros and how it may play a part

  • I run everything in rootless containers using systemd service files generated with podman generate systemd.

    Podman Compose is a "community effort", and Red Hat seems to be less focused on its development (here is their post about it).

    There are ways to get it working but I find it easier to go with podman containers and pods through systemd because the majority of documentation (both official and unofficial) leans in that direction.

    I don't know how much you already know, so here is just a summary of things that worked for me for anyone reading.

    Podman uses the concept of "Pods" to link together associated containers and manage name spaces, networking, etc. The high level summary for running podman pods through systemd:

    • Create an empty pod podman pod create --name=<mypod>.
    • Start containers using podman run --pod=<mypod> ... and reconfigure until containers are working within the same pod as desired.
    • Use podman generate systemd to create a set of systemd unit files. Be sure to read through the options in that man page. -- this is more reliable than creating systemd unit files by hand because it creates unit files optimized for the podman workflow.
    • place the generated systemd unit files in the right place (user vs. system) and then it can be started, enabled, and disabled as with other systemd unit files.

    Note: for standalone containers that are not linked or reliant on other containers, you can should skip creating the empty pod and can skip the --pod=<mypod> when starting containers. This should result in a single service file generated and that container will operate independently.

    This post goes over pods as systemd services.

    This doc goes over containers as systemd services.

    The Red Hat Enterprise Linux docs have a good amount of info, as well as their "sysadmin" series of posts.

    Here are some harder to find things I've had to hunt down that might help with troubleshooting:

    • Important: be sure to enable loginctl enable-linger <username> or else rootless pods/containers will stop when you log out of that session.
    • If you want it to run a container or pod at system startup you will need to specify the right parameters in the [Install] section of the systemd file, see this doc page. Podman generate systemd should take care of this.
    • If you are using SELinux there is a package called container-selinux that has some useful booleans that can help with specific policies (container-use-devices is a good one if your container needs access to a GPU or similar). Link to repo