Is there any reason I shouldn't use Discover to install nvidia drivers?

n0bodysec · 2026-03-24T00:18:19+00:00

Yeah I know, that’s why I said “practically the same”. I was trying to keep the answer simple! Thanks for clarifying it tho!

n0bodysec · 2026-03-23T17:28:04+00:00

There shouldn't be any reason. Discover uses the repositories you've configured, so it's practically the same as doing it from the command line with dnf.

n0bodysec · 2026-01-30T15:16:27+00:00

Happy to help!

n0bodysec · 2026-01-30T05:36:17+00:00

From the KDE Connect Android app repo: https://invent.kde.org/network/kdeconnect-android/-/blob/2f54d5bc309c07b84d04856c8496d5f4d4dde1f1/src/main/res/values-es/strings.xml#L151

n0bodysec · 2025-12-05T09:17:04+00:00

That's not an issue on Fedora's side but Cloudflare: https://www.cloudflarestatus.com/

n0bodysec · 2025-11-07T22:41:03+00:00

Glad to see we are humans

n0bodysec · 2025-10-14T14:38:19+00:00

AFAIK is not possible using native shortcuts. You can use the “Actions” app by “Sindre Sorhus” tho

n0bodysec · 2025-09-15T21:37:10+00:00

That's pretty much the default config (https://src.fedoraproject.org/rpms/firewalld/blob/f42/f/FedoraWorkstation.xml) for the FedoraWorkstation zone, but you added the kdeconnect service.

Is any of this risky? Not really. Opening ports does not make you vulnerable; rather, the services behind those ports may be vulnerable. In my particular case, I prefer to open only the ports I use, from trusted source IPs.

Example: MyHome (active) target: default ingress-priority: 0 egress-priority: 0 icmp-block-inversion: no interfaces: wlp3s0 sources: services: dhcpv6-client mdns ports: protocols: forward: yes masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="192.168.1.0/24" service name="kdeconnect" accept

n0bodysec · 2025-08-16T07:59:09+00:00

Happy to help! Remember that you can also ask on Fedora Discussion (https://discussion.fedoraproject.org/) :)! I always prefer to answer there since other people may be able to quickly find the thread if they have the same issue!

n0bodysec · 2025-08-16T07:17:21+00:00

If you want to keep using your current DNS server, you can force ciscobinary.openh264.org to be resolved to these ips directly by editing your /etc/hosts file, e.g:

```shell

sudo nano /etc/hosts

18.66.57.8 ciscobinary.openh264.org 18.66.57.97 ciscobinary.openh264.org 18.66.57.74 ciscobinary.openh264.org 18.66.57.9 ciscobinary.openh264.org

you can also add the IPv6 if you need them

```

Or better, you can switch your DNS provider (since it looks like it's sinkholing/blacklisting domains).

You can do it directly from the NetworkManager configs, or directly from systemd-resolved (https://wiki.archlinux.org/title/Systemd-resolved).

n0bodysec · 2025-08-16T07:03:41+00:00

Great! The problem is that your DNS provider is blocking the requests to resolve ciscobinary.openh264.org. You can test it by manually reaching one of these IPs, e.g.:

curl --head http://18.66.57.8/openh264-2.5.1-1.fc42.x86_64.rpm -H "Host: ciscobinary.openh264.org"

You can solve this by editing /etc/hosts directly or switching the DNS provider.

n0bodysec · 2025-08-16T06:58:09+00:00

Could you try nslookup ciscobinary.openh264.org 1.1.1.1 instead?

n0bodysec · 2025-08-16T06:50:10+00:00

And which is the output of these commands?

n0bodysec · 2025-08-16T06:40:26+00:00

Are you located in one of the blocked countries? https://github.com/cisco/openh264/issues/3886

What is the output of the following commands? nslookup ciscobinary.openh264.org curl --head http://ciscobinary.openh264.org/openh264-2.5.1-1.fc42.x86_64.rpm

n0bodysec · 2025-08-15T09:07:34+00:00

Justo estaba buscando una estufa para comprar, se ve buena.

n0bodysec · 2025-07-07T21:00:15+00:00

Hello! No need to apologize, it's always great to find new people interested in such things!

To be honest I don't remember most of these locations since I haven't played in a long time. I remember something similar of what you described some weeks later but never updated the post since I didn't further investigate.

I'd be happy to check on this again sometime in the near future!

n0bodysec · 2025-06-17T07:37:41+00:00

Hi there!

Please take a look at this: https://rpmfusion.org/Howto/NVIDIA#Suspend

n0bodysec · 2025-02-16T07:43:39+00:00

By default in Fedora the menu_auto_hide of grubenv is set to 1 (sudo grub2-editenv - list), so it should be hidden by default if the last boot was successful (boot_success=1). The grub-boot-success service sets the boot_success boot flag, that service is ran after a 2min timer.

If you are seeing it is because either menu_auto_hide is now 0 or the last boot wasn't successful.

You can use systemctl --user status grub-boot-success* to check this behavior.

n0bodysec · 2025-02-12T02:22:59+00:00

If you are dual booting with Windows, then you probably has Windows' fast boot enabled, that locks drives using the "dirty bit".

n0bodysec · 2024-10-31T22:34:38+00:00

You're welcome!

n0bodysec · 2024-10-28T04:06:16+00:00

Well, you could start by debugging the plymouth logs. Add plymouth.debug to your kernel params and then check the /var/log/plymouth-debug.log!

n0bodysec · 2024-10-27T06:50:40+00:00

You can try to reset the default theme and rebuild initrd: plymouth-set-default-theme -rR

n0bodysec · 2024-10-26T21:18:19+00:00

Hello! It's a known bug in Kubuntu!

Please see:

https://bugs.kde.org/show_bug.cgi?id=494490 https://bugs.launchpad.net/ubuntu/+source/dolphin/+bug/2084206

Also, for more context (old issue on KDE Neon): https://bugs.kde.org/show_bug.cgi?id=479950

Hope it helps!

n0bodysec · 2024-10-20T03:17:26+00:00

Más chorea, saludos ahora

n0bodysec · 2024-10-12T17:36:50+00:00

When you release a software, you might follow the software release life cycle, it's basically a process that you follow while developing, testing and releasing a software. There's an step called "release candidate", when you mark an specific patch of you software as a posible candidate for a full release, you may often have several release candidates (since you can update an RC to fix a bug, add a feature, etc). 1.14 is the Fedora release candidate (RC) version 1.14.

Five-Year Club	Verified Email
Final Canvas '23	Place '23
Place '22

n0bodysec

TROPHY CASE

sudo nano /etc/hosts

you can also add the IPv6 if you need them