DefederateLemmyMl

Yeah and Flatpaks also exist.

Flatpaks are probably the best generic solution for using an LTS release like Debian Stable on a desktop system. You get the best of both worlds: up to date desktop packages and a stable base.

Good news … it’s a suppository!

videos above 1080p can sometimes cause problems if they have heavy encoding like vp9 or av1

Yeah they’re probably decoded in software because I doubt that the integrated graphics supports hardware decoding of those recentish codecs.

At that point, just put a gt1030 in it.

Actually, are these 2 forks of another, when?

Yes forgejo was forked from gitea in 2022. It was a soft fork at first, but became a hard fork earlier this year.

Full story here: https://forgejo.org/2024-02-forking-forward/

In the case of Arch the backdoor also wasn’t inserted into liblzma at all, because at build time there was a check to see if it’s being built on a deb or rpm based system, and only inserts it in those two cases.

See https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 for an analysis of the situation.

So even if Arch built their xz binaries off the backdoored tarball, it was never actually vulnerable.

That’s committing the cardinal sin of cherrypicking your backup contents. You may end up forgetting to include things that you didn’t know you needed until restore time and you’re creating a backup that is cumbersome to restore. Always remember: you should really be creating a restore strategy rather than a backup strategy.

As a general rule I always backup the filesystem wholesale, optionally exclude things of which I’m 100% sure that I don’t need it, and keep multiple copies (daylies and monthlies going some time back) so I always have a complete reference of what my system looked like at a particular point in time, and if push comes to shove I can always revert to a previous state by wiping the filesystem and copying one of the backups to it.

Bloat multiplies when you have to back it up.

I’ve found that the silliest desktop problems are usually the hardest to solve, and the “serious” linux system errors are the easiest.

System doesn’t boot? Look at error message, boot from a rescue disk, mount root filesystem and fix what you did wrong.

Wrong mouse cursor theme in some Plasma applications, ignoring your settings? Some weird font rendering issue? Bang your head against a wall exploring various dotfiles and rc files in your home directory for two weeks, and eventually give up and nuke your profile and reconfigure your whole desktop from scratch.

Full kernel corruption

What does that even mean?

Was the file system on which your kernel resided corrupt, or did something go wrong with a kernel upgrade/installation?

No. They closed their sources to subscribers, which in itself would be fine, but the terms of service contain a clause forbidding redistribution of the sources by subscribers, at the penalty of termination of the agreement.

Otherwise a second PiHole set as the secondary DNS in DHCP would keep things online.

No, that just creates time outs and delays when either of them is offline.

The proper way is to have a standby pihole that takes over the IP address of the main pihole when it goes down. It’s quite easy to achieve this with keepalived.

Mental note: have to migrate my gitea instance over to forgejo.

The encryption i was talking about is the encryption of your dns server

You mean encryption between the client and your DNS server, on your local network?

Just wanted to chime in and say that with a pihole you can also have encryption if you point to a local resolver like cloudflared or unbound.

My pihole forwards everything to a cloudflared service running on 127.0.0.1:5353 to encrypt all my outgoing DNS queries, it was really easy to setup: https://docs.pi-hole.net/guides/dns/cloudflared/

DNS-over-HTTPS

You can also do that with running cloudflared or unbound on your pihole.

For me gravity sync was too heavy and cumbersome. It always failed at copying over the gravity sqlite3 db file consistently because of my slow rpi2 and sd card, a known issue apparently.

I wrote my own script to keep the most important things for me in sync: the DHCP leases, DHCP reservations and local DNS records and CNAMES. It’s basically just rsync-ing a couple of files. As for the blocklists: I just manually keep them the same on both piholes, but that’s not a big deal because it’s mostly static information. My major concern was the pihole bringing DHCP and DNS resolution down on my network if it should fail.

Now with keepalived and my sync script that I run hourly, I can just reboot or temporarily shutdown pihole1 and then pihole2 automatically takes over DNS duties until pihole1 is back. DHCP failover still has to be done manually, but it’s just a matter of ticking the box to enable the server on pihole2, and all the leases and reservations will be carried over.

That’s what I do. I do have a small VM that is linked to it in a keepalived cluster with a synchronized configuration that can takeover in case the rpi croaks or in case of a reboot, so that my network doesn’t completely die when the rpi is temporarily offline. A lot of services depend on proper DNS resolution being available.

You can use log2ram to mitigate that.

Alternatively, you can even boot a root filesystem residing on an NFS share, but in the case of a rpi hosting the network’s DNS and DHCP services, you could end up with a chicken and egg problem.

uBlock can do much more refined and targeted blocking than a pihole because it has access to the entire page that is being served and can selectively filter elements. The pihole only has access to the DNS name, and DNS blocking is a rather crude tool to block ads that can be defeated by serving the ads from the same domain.

For example: a pihole doesn’t work for blocking YouTube ads, because they come from the same domain.

I think it’s a good tool to have on your toolbelt, so it can’t hurt to look into it.

Whether you will like it or not, and whether you should move your existing stuff to it is another matter. I know us old Unix folk can be a fussy bunch about new fads (I started as a Unix admin in the late 90s myself).

Personally, I find docker a useful tool for a lot of things, but I also know when to leave the tool in the box.