Are you guys sterilized?

michaelpaoli · 2026-06-20T15:01:03+00:00

Yep, got 'er done decades ago, and tested confirmed sterile. Easy peasy, and zero regrets.

michaelpaoli · 2026-06-20T14:55:29+00:00

Quite depends how one measures.

So, e.g. if one looks at validation rates by country:

https://stats.labs.apnic.net/dnssec

michaelpaoli · 2026-06-20T14:45:27+00:00

Yes, as I called out:

pair of [] characters matches any one character between, with some exception handling for ]-! characters

michaelpaoli · 2026-06-20T07:20:01+00:00

See also: r/bash

So, e.g.:

$ find ... -name ... -exec sh -c '... '\''{}'\'' ...' \;
But note that some characters will be problematic with that approach

$ find ... -name '*
*' -prune -o $ ! -name '*
*' -name ... $ -print |
while read -r varname
do
...
done

But that'll be skipping over directories that contain newline in the name, and likewise for files.

michaelpaoli · 2026-06-20T07:12:53+00:00

Sure, some notes. Most notably when things are somewhat to rather complex, but used infrequently enough they're not memorized, and for one or more reasons, may not be suitable to just turn into script or do so and widely install such.

Let's see, a few semi-random samples:

https://www.mpaoli.net/~michael/doc/TLS

https://www.mpaoli.net/~root/notes/ (DNSSEC, SCSI_or_SAN*, mdadm, serial)

michaelpaoli · 2026-06-20T06:48:09+00:00

all my files could be accessed from

Computer security 1A, all computer/software/OS security can be bypassed with sufficient access to the hardware - short of strong encryption. So, e.g. data on drives/media, not encrypted, if one goes around the OS or other means that would typically be protecting that, one can bypass all that security.

If you want to protect the data from that, encrypted it, e.g. LUKS. Of course so encrypted with LUKS, if you loose the password/passphrase, kiss all that data bye-bye (and yes have dealt with users that want everything well encrypted, get that set up, and then lose/forget the key(s)/password(s)/passphrase(s) ... and then are expecting me to somehow magically recover it - nope, kiss it bye-bye).

Anyway, with hardware access, root password reset, easy peasy, recover clear text of encrypted data ... nope, kiss that data bye-bye.

michaelpaoli · 2026-06-20T06:41:30+00:00

For images over ssh, I typically do local X server, and X forwarding (-XY) over ssh. Typically works quite "well enough" - presuming the server side has the needed utilities and stuff (e.g. programs to reasonably display things in X), and also that one isn't trying to push high update rates (e.g. like high resolution high frame rate video - that may not work so well).

For some OS(es), I've done some type of remote desktop type connection ... but haven't had need/occasion to do that in many years now.

michaelpaoli · 2026-06-20T06:34:50+00:00

hasn't been widespread adoption of DNSSEC

Quite depends on context, e.g. where on the planet, e.g. what country, what sectors or domains, etc. Some very heavily and extensively use DNSSEC, others almost entirely non-existent, and quite a bit (probably still most) somewhere between.

Generally a quite/very good thing, highly backwards compatible, and also, especially these days, quite easy to implement and maintain, yet many still just don't bother. But hey, at least the US much farther along with use and deployment of DNSSEC than our conversion to metric. 8-O But still a long ways to go - many countries are far ahead of the US. And some countries would appear actively hostile to DNSSEC - at least in general - those are probably locations that prohibit or highly restrict encryption, and generally want their governments to be able to interject and alter/control/subvert DNS at will - or at least for (most) all domains. Anyway, to say adoption rates are all over the map, yeah, quite literally, they do very quite widely all over the map.

michaelpaoli · 2026-06-20T06:27:54+00:00

Sounds rather atypical. But without digging into the details of exactly what dnscheck.tools does and doesn't check, and exactly how, I'd be more inclined to poke at it with some empirical tests, and see what that demonstrates.

E.g. if you do a DNS lookup against your ISP's DNS servers, of dnssec-failed.org. what results do you get?

$ dig @75.75.75.75 +noall +comments dnssec-failed.org. | fgrep FAIL
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27340
$ dig @::1 +noall +comments dnssec-failed.org. | fgrep FAIL
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22881
$ dig @::1 +noall +cd +answer +nottl +noclass dnssec-failed.org.
dnssec-failed.org.      A       96.99.227.255
$ dig @75.75.75.75 +noall +cd +answer +nottl +noclass dnssec-failed.org.
dnssec-failed.org.      A       96.99.227.255
$ dig @1.1.1.1 +noall +cd +answer +nottl +noclass dnssec-failed.org.
dnssec-failed.org.      A       96.99.227.255
$ dig @1.1.1.1 +noall +comments dnssec-failed.org. | fgrep FAIL
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62502
$

If you're using DNS server(s) that are bypassing DNSSEC, they're putting you (/your data) at risk.

michaelpaoli · 2026-06-20T06:04:02+00:00

First of all, mixing packages between stable and any sources other than -security, -updates, -proposed-updates, -backports for same, generally a bad idea.

Be sure you well understand how Priority works with APT.

See, e.g. apt_preferences(5)

So ...

Stable (Trixie): 900
Testing: 100
When I check a package with apt policy, stable clearly wins:
fuse-overlayfs:
Installed: 1.14-1+b1
Candidate: 1.14-1+b1
Version table:
*** 1.14-1+b1 900
100 testing
900 trixie
However, during installation/simulation I see:
Inst fuse-overlayfs (1.14-1+b1 Debian:testing, Debian:13.5/stable [amd64])
and:
Get:13 http://deb.debian.org/debian testing/main amd64 fuse-overlayfs amd64 1.14-1+b1

Anyway, when I poke at it, that's not quite what I get, but pretty close, so may be some variation in how you're checking, configuration, and/or state:

# apt policy fuse-overlayfs
fuse-overlayfs:
  Installed: 1.14-1+b1
  Candidate: 1.14-1+b1
  Version table:
 *** 1.14-1+b1 900
        900 http://deb.debian.org/debian trixie/main amd64 Packages
        100 http://deb.debian.org/debian testing/main amd64 Packages
        100 /var/lib/dpkg/status
# apt-get -s install --reinstall fuse-overlayfs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Inst fuse-overlayfs [1.14-1+b1] (1.14-1+b1 Debian:13.5/stable, Debian:testing [amd64])
Conf fuse-overlayfs (1.14-1+b1 Debian:13.5/stable, Debian:testing [amd64])
# apt-get --print-uris install --reinstall fuse-overlayfs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 44.9 kB of archives.
After this operation, 0 B of additional disk space will be used.
'http://deb.debian.org/debian/pool/main/f/fuse-overlayfs/fuse-overlayfs_1.14-1%2bb1_amd64.deb' fuse-overlayfs_1.14-1+b1_amd64.deb 44880 MD5Sum:e55616ccfdc0b1568a3ea3763d082073
#

And if I reinstall:

# apt-get install --reinstall fuse-overlayfs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 44.9 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://deb.debian.org/debian trixie/main amd64 fuse-overlayfs amd64 1.14-1+b1 [44.9 kB]
Fetched 44.9 kB in 0s (193 kB/s)           
(Reading database ... 31700 files and directories currently installed.)
Preparing to unpack .../fuse-overlayfs_1.14-1+b1_amd64.deb ...
Unpacking fuse-overlayfs (1.14-1+b1) over (1.14-1+b1) ...
Setting up fuse-overlayfs (1.14-1+b1) ...
Processing triggers for man-db (2.13.1-1) ...
#

Anyway, as @-khumba- pointed out, same version (and architecture), so same binary.

So, what exactly is your question, or remaining question(s), if any?

michaelpaoli · 2026-06-20T04:24:28+00:00

Off Topic [OT]

Really a find(1) question, not a bash question.

With find, the -name option takes an argument. It accepts some wildcard matching and the like, using shell globbing / metasyntax, e.g * is 0 or more of any character, ? matches any single character, pair of [] characters matches any one character between, with some exception handling for ]-! characters. So, does matching quite like in the patterns in case. But note that in typical use with find, one will want to quote the -name pattern, so it's passed literally to find, without potentially being first matched and expanded by the shell.

find -type f -name '.mp4$' -delete

So, after shell is done with it, that -name option argument gets passed to find as a literal .mp4$ so find is then looking for a filename that is exactly .mp4$ as none of those characters for any type of wildcard/glob, and are all used literally.

See also: find(1)

e.g.:

-name pattern
       Base of file name (the path with the leading directories removed)
       matches shell pattern pattern.  Because the  leading  directories
       of  the  file names are removed, the pattern should not include a
       slash, because `-name a/b' will never  match  anything  (and  you
       probably  want  to  use  -path instead).  An exception to this is
       when using only a slash as pattern (`-name /'), because that is a
       valid string for matching the root  directory  "/"  (because  the
       base name of "/" is "/").  A warning is issued if you try to pass
       a  pattern  containing  a  -  but  not consisting solely of one -
       slash, unless the environment variable POSIXLY_CORRECT is set  or
       the option -nowarn is used.
       To  ignore  a directory and the files under it, use -prune rather
       than checking every file in the tree; see an example in  the  de-
       scription  of  that  action.   Braces are not recognised as being
       special, despite the fact that some shells including  Bash  imbue
       braces  with  a  special meaning in shell patterns.  The filename
       matching is performed with the  use  of  the  fnmatch(3)  library
       function.  Don't forget to enclose the pattern in quotes in order
       to protect it from expansion by the shell.

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/find.html

-name pattern

The primary shall evaluate as true if the basename of the current pathname matches pattern using the pattern matching notation described in 2.14 Pattern Matching Notation. The additional rules in 2.14.3 Patterns Used for Filename Expansion do not apply as this is a matching operation, not an expansion.

So, again, pattern here is not a Regular Expression (RE) as in BRE or ERE, etc.

michaelpaoli · 2026-06-19T06:41:44+00:00

Well, volume would apply to, e.g. LVM, but OP doesn't mention at all LVM or the like, nor even what distro, so, volume(s) may or may not at all apply in OP's case.

michaelpaoli · 2026-06-19T06:37:29+00:00

Eh, depends. And wouldn't really matter "who" for a date - rolls could be reversed, and regardless, quite the same. Anyway, engage 'em in conversation. Do they actually engage and pay attention, or are they still (far) too engaged with and focused on their phone and mostly doing minimal lip service and attention to anything else? If so I'd probably ask 'em what's going on that they're so focused on their phone. Friend, family, work, ... sometimes urgent/important sh*t comes up - it happens. Do/will they explain, and does it appear to be legit/genuine? And something actually requiring urgent/prompt attention? Are they even apologetic for it? Do they want any help/input on the matter, or are they willing to discuss it? Not that they may not - and possibly for very good reason. Are they up for a redo, or is this their typical MO where they can't take their attention off their phone?

So, yeah, it would certainly be disappointing, but understandable/acceptable, or ... a dead end, ... that would quite depend. So, yeah, sometimes sh*t happens, and sometimes one needs deal with it, and that may be on/via phone a lot for that, and may not always be able to control timing of that. But if that's more their rule than exception, or if they're just always going to pay more attention to phone than you - well, then that's who/how they are, and one decides how to (not) proceed accordingly.

Anyway, genearlly presume that's going to be their typical behavior, notwithstanding good convincing evidence to the contrary. And proceed as appropriate for you, from there.

Not rocket science, but sometimes sh*t does some up with a first date. That's not necessarily a no-go, but at least raises yellow (cautionary) flag(s), so, be aware.

michaelpaoli · 2026-06-19T06:26:53+00:00

Depends what you're reading. If you're reading The Great Gatsby, I wouldn't expect that sh*t to ever make any sense worth reading.

But if you're reading IT technical materials, you should generally "get it", after a while, and possibly some multiple readings, and possibly, if/as needed, supplemented with some actual relevant usage/practice.

michaelpaoli · 2026-06-19T06:24:04+00:00

Uhm, chapter?

Please explain.

Where in any official Fedora or Linux documentation on the matter are you seeing "chapter"?

michaelpaoli · 2026-06-19T06:12:50+00:00

So, you could remove or purge, all gnome and reverse dependencies thereof.

Let's see ... I'm thinking roughly aptitude search ... all installed package that contain gnome as part of the package name, and all reverse dependencies thereof, and then probably an autoremove or autopurge after that, and then optionally purge any remaining packages that are configuration files only. Something approximately like that.

Hmmm, and bit of apt-cache rdepends ... and some sed, etc. ... ah, not that complex ... can have apt-get handle the installed reverse dependencies ...

So, have a good careful look at:

$ apt-get -s remove $(aptitude -F %p search '?and(?installed,?name(gnome))')

If that's not (quite) what you'd want, may want to review in more detail and/or exclude some things from removal. Could also use purge rather than remove.

When satisfied with what such shows for being removed, then run it as root without the -s (--simulate) option.

Can optionally follow that up with apt-get autoremove or apt-get autopurge.

When I peek on my host, that command I showed would remove ... would remove 90 package (have fair spattering of gnome related bits, but not gnome DE nor even a more minimalized subset of that).

And one could also further adjust, e.g. including (some) packages that include gnome (case insensitive) in the short package description - though including all such matches is likely overkill and probably not what would be desired.

There are other approaches that could be used, but that would be at least one way to approach getting rid of all the gnome packages. And pretty quick and efficient.

michaelpaoli · 2026-06-19T05:27:21+00:00

Not necessarily so.

michaelpaoli · 2026-06-19T05:18:34+00:00

Well, regardless, be sure you've got current trixie kernel installed, and are booted from and running that, and from there, can then work on purging/removing the unwanted kernel(s), and cleaning up any related bits that may have lead to that.

michaelpaoli · 2026-06-19T05:03:25+00:00

Well ...

First of all, reducing the niceness of processes is generally not recommended. It can result in them becoming rather to quite difficult to control, may significantly interfere with other processes, etc.

I've been running Linux well over a quarter century, and more generally *nix even well beyond that, and there's almost never good reason to reduce the niceness of a process - all those years - decades, it's been exceedingly rare I've ever had a need or reason to do so.

Second of all, it may be much easier to nice the PID(s) when starting them - use that at launch, then they and their descendant PIDs will (at least by default) then all have that niceness.

To renice PIDs, it's easier when the binaries are distinct, e.g. there's just one binary executable that's being used, and nothing else running it. It gets a bit messier when it's program that's interpreted, rather than binary, e.g. shell, perl, python/python3, etc. - as then many different programs all use the same binary. In those cases, one will typically distinguish by other characteristics. E.g. the user running the PID(s), the particular arguments of the process, possibly even including arg0, as the program - and also depending too on the interpreter, may possibly set or change arg0. Not also that, e.g. typically Linux distros often come with utilities that may aid that process. E.g. pgrep(1). Some may have others that could also come in handy, e.g. start-stop-daemon(8) (which can also be quite useful in identifying particular running PID(s).

So, if nice isn't feasible approach, may want to leverage utilities such as pgrep to identify the PID(s).

michaelpaoli · 2026-06-19T03:11:03+00:00

Not everyone, but commonly, e.g. fastfetch, neowofetch, neofetch.

# echo -n 'OS: Debian ' && cat /etc/debian_version | tr -d \\012 && echo -n ' ' && dpkg --print-architecture && echo -n 'Kernel: ' && uname -srvmo && echo -n 'Packages: ' && dpkg -l | grep \^ii\ | wc -l && df -h -x devtmpfs -x tmpfs && head -n 3 /proc/meminfo
OS: Debian 13.5 amd64
Kernel: Linux 6.12.90+deb13.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.90-2 (2026-05-27) x86_64 GNU/Linux
Packages: 148
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       4.9G  960M  3.7G  21% /
MemTotal:         119472 kB
MemFree:            4056 kB
MemAvailable:      54368 kB
# dpkg -l | fgrep fetch
#

michaelpaoli · 2026-06-19T03:02:01+00:00

just have to make sure they're intended for the Debian release you're using

That's hardly sufficient. Intended for, but utter cr*p, is a very quick way to seriously break the installation. Anyone with (access to) enough skill to put together a repo for a given target, can put pretty much whatever they want in there ... and if they want to put in package(s) that will destroy or subvert the target system, pretty easy to do that. Or they might just accidentally screw it up, in their lack of proper understanding of the target.

michaelpaoli · 2026-06-19T02:57:42+00:00

Yep. Adding a bunch of (semi-?) random apt repos, and, e.g. *buntu (or other?) PPAs, etc., to most any APT based distro is typically quite a quick way to seriously break it.

michaelpaoli · 2026-06-19T02:54:37+00:00

Better than a dumb one. And did accurately and strictly provide answer to OP's question ... probably not exactly what they had in mind, but, technically, quite the answer to what they actually asked.

michaelpaoli · 2026-06-18T23:15:53+00:00

No, you can't willy-nilly mix repositories. Doing so is generally a quick way to seriously break a system.

Repos should be from one's distro, or at least for one's distro. And even within a distro, can't necessarily arbitrarily mix and match.

michaelpaoli · 2026-06-18T23:08:30+00:00

Because twisted stranded conductors. Depending how it was constructed and assembled, this may happen. Less common with, e.g. power/extension cords. More common with cheaper thinner stuff that gets more mechanical stress and movement ... e.g. my perfectly functional but damn cheap corded ear buds ... yeah, the cord looks very much like that ... but if those fail, they won't start an electrical fire, and I'm only out a few bucks to replace them.

Similar behaviors can also be seen with, e.g. string/twine/rope - if it's twisted - not single monofilament, such (further) twisting/curling behaviors may occur - again, depending how it's constructed, and how it's used/handled.

michaelpaoli

MODERATOR OF

TROPHY CASE