???

The changelog for nosystemd.org is at //github.com/muellermartin/nosystemd.org/commits

There do not appear to be any links added today...

Yeah, for people who need to do video calling that'll matter.

Based on this 2020 Arch Linux thread, that is what apulse solves:

It's good to know that, for people who don't need their browser accessing the microphone, the rest should work without needing the apulse hack.

For clarity, when you say "works just fine", you mean you have successfully streamed audio and video though the browser, yes?

Desktop files can also be overridden.

(Using /usr/local/share/applications/firefox-esr.desktop should work, but I can't verify right now; using ~/.local/share/applications/firefox-esr.desktop will work, but is of course per-user.)

-

Although I guess you might also need to update /etc/alternatives/x-www-browser too, so maybe working directly with /usr/lib/firefox-esr/firefox-esr is actually less work.

The domain ublock.org IS NOT uBlock Origin, and never has been.

uBlock Origin is from Raymond Hill who is at //github.com/gorhill - that's "go" followed by "rhill" - the initial and surname of the author.

YouTube videos aside, Manifest V3 is absolutely a bad thing, and part of Google's efforts to take over the Internet.

The easiest way to combat Google's increasing dominance is to stop using Google-controlled browsers, like Chrome, Chromium, Brave, Edge, Vivaldi, etc.

YouTube is not monitoring the forums of random Debian derivatives, but - even if they were - uBlock Origin is currently installed on over FIFTY MILLION browsers. It is far from a secret.

It is almost certainly the case that YouTube have known about uBlock Origin for most of its nine year life; there are very likely YouTube developers who started using it back in 2015 when it first became popular.

Manifest V3 is already Google's attempt to block such extensions, but - so long as we have non Google-controlled browsers - their success will be limited to those who use Google-controlled browsers.

And, even if Mozilla cave in and the efforts of Raymond Hill and others fail, there's still Invidious and yt-dlp and other options for viewing YouTube videos without being subjected to Google's adverts.

No, because I don't know what would populate them.

(Well, I could probably come up a list of things that I think should be documented, but that'd be adding more to already full plates, so would be counter-productive until enough existing tasks are resolved.)

Fixing bugs is important, and having a list of low-hanging fruit enables a greater number of people to potentially do so.

Particularly if there's a lot of easy-but-time-consuming tasks; give those to someone with plenty of time but less experience, whilst the more experienced people focus on the harder tasks, and more gets done overall.

There is no "frequent updates" or "by the time published"; the lists get dynamically generated by the bug tracker, all it (should) take is appropriate tagging, direct links to the relevant filters, and a suitable explanation of desired processes.

Here's Debian's page - it's not a good example to copy, because it's badly done - but hopefully it makes clearer what I'm saying.

If the first post had been an attempt at a bug report, I'm sure more would have been done to encourage diagnosis and sending of the relevant information to bugs.devuan.org

But since it was essentially just a rant just about dropped balls and low bars, I'd say the responses were just right.

-

Anyhow, if I cared about network-manager, I might be asking if it's relevant that Excalibur appears to be on 1.44.2-5 when Trixie is still on 1.44.2-3

Also, if I saw unexpected changes to my system, I'd make sure to copy text-based output of relevant commands, which - for anything package-related - would include a confirmation of active repositories...

*shrug*

Heh, localepurge sounds interesting...

*sigh* It should not need to be a post-install hack!

The package manager should know which locale(s) are relevant and not even waste bandwidth on those files to begin with.

Unless you were in the bin directory when running the command, it's not going to be a problem. Assuming you're in your home directory, just make sure you use ~/grep to view/remove the file and it'll be fine.

If you're super paranoid, rename the file, download grep.deb just in case, restart, confirm grep still works (which it will), then remove the renamed version.

(Also, since my edit was a bit slow you may have missed that you don't need grep to filter the output.)

It's already here, and called dconf.

Running ss -ltnp sport 53 - as root/sudo - should confirm which process is listening on port 53.

Strictly, only -l (--listening) and -p (--processes) are needed here, but depending on what one is filtering, limiting to -t (--tcp) and -n (--numeric) makes the output clearer.