thom_nic

> A leak was detected in one of the fittings and an attempt was made to correct it by striking the fitting with a large wrench.

> is this pressure from the gun manufacturing lobby

Definitely not, it's pressure from the anti-gun lobby that keeps pushing "one more bill that this time will actually change violent crime statistics, we promise!"

These bills are being introduced in the states that already have the most restrictive gun control already, yet to nobody's surprise, hasn't done much to curb violent crime. But the lobby groups and candidates campaign and fundraise on the issue so they have to keep the boogeyman alive rather than admit that the policies have been a failure.

This is fair, but I would venture to guess 99% of people including software developers and even most IT professionals completely rely on the vendor pre-installed root CAs.

DOD Cyber Exchange, home of DISA STIGs among other resources, appears to be signed by a root CA "US DoD CCEB Interoperability Root CA 2" which does not appear to be in any browser list of trusted root CAs. This seems to have changed at some point, because public.cyber.mil used to be accessible without any browser warnings. Certificate chain:

    $ gnutls-cli --print-cert public.cyber.mil 443 </dev/null
    Processed 150 CA certificate(s).
    Resolving 'public.cyber.mil:443'...
    Connecting to '23.9.224.83:443'...
    - Certificate type: X.509
    - Got a certificate list of 2 certificates.
    - Certificate[0] info:
     - subject `CN=comm-cyber.mil,OU=DISA,OU=PKI,OU=DoD,O=U.S. Government,C=US', issuer `CN=DOD SW CA-74,OU=PKI,OU=DoD,O=U.S. Government,C=US', serial 0x087ef6, RSA key 2048 bits, signed using RSA-SHA256, activated `2025-08-11 17:51:06 UTC', expires `2026-09-12 17:51:06 UTC', pin-sha256="zqDELcwzXa0DHRYN6o+J5FGm2fSFXYb3O0knmjH3MrE="
            Public Key ID:
                    sha1:2925dac566b06932f1995cc904f1e723e26d6f5d
                    sha256:cea0c42dcc335dad031d160dea8f89e451a6d9f4855d86f73b49279a31f732b1
            Public Key PIN:
                    pin-sha256:zqDELcwzXa0DHRYN6o+J5FGm2fSFXYb3O0knmjH3MrE=


    -----BEGIN CERTIFICATE-----
    ...snip
    -----END CERTIFICATE-----

    - Certificate[1] info:
     - subject `CN=DOD SW CA-74,OU=PKI,OU=DoD,O=U.S. Government,C=US', issuer `CN=DoD Root CA 6,OU=PKI,OU=DoD,O=U.S. Government,C=US', serial 0x4a, RSA key 2048 bits, signed using RSA-SHA384, activated `2023-05-16 16:05:29 UTC', expires `2029-05-15 16:05:29 UTC', pin-sha256="NJVFdvvbhMFMXyUHKDk1RLnMkkY5Qt9eP3Q0Q8QHPUk="

    -----BEGIN CERTIFICATE-----
    ...snip
    -----END CERTIFICATE-----

    - Status: The certificate is NOT trusted. The certificate issuer is unknown. 
    *** PKI verification of server certificate failed...
    *** Fatal error: Error in the certificate.

From my anecdotal observation this is true. Gun sales are also growing among demographics not typically associated with gun ownership (non-white, non-conservative.)

> the salesman wasn't supposed to TELL YOU that we are monitoring what you install

Exactly. The old "I'm sorry I got caught" and not "I'm sorry I did it."

> There's always the risk that the West might internally reject the scientific revolution.

In the US I am pretty sure we are already on the decline.

I think it has to do with, during the industrial revolution and post-war, huge scientific advancements and tech grew the economy, fed capitalism by means of providing new desirable goods to consumers (e.g. dishwashers, nicer cars, etc.)

I wonder if we've reached a "peak" of consumer comfort where advances in science/ tech/ medicine are no longer frequent/ impactful enough to meaningfully satisfy consumers, (why do we care about exploring Mars?) so it's easy for people to reject it and say "we don't need science."

I agree, for a couple reasons. One, while you usually have to deal with a cross toolchain (usually intel-> ARM) it's easier to build and debug on a target board versus booting and rebooting your PC to see if you did everything right. Also the

I've used debootstrap to build a Debian distro for ARM with a custom kernel (for an Olimex board target or Beaglebone.) That's very hands-off and not nearly the same "depth" as LFS. The next step was taking the same kernel and building a busybox-based rootfs. Then I had to make my own PID 1 and do init work to bring up services such as networking on boot which was very educational, yet busybox provides most of the "lego bricks" that you're not left writing too much from scratch.

Building to an embedded target also allows one to punt on the most annoying and complex parts of a desktop linux distro, such as the desktop environment, audio/video drivers, UEFI bootloader, etc. Building a semi-custom (e.g. Arch or Debian/debootstrap, Buildroot or OpenEmbedded) headless distro was what I'd call a "shallow dive" or gentle introduction to more of Linux's inner workings without having to understand every bit in order to get a running system.

This sounds a bit like the custom bicycle frame builder phenomenon as well. Well-known builders/shops can have years-long wait lists and their builds will go for 2x, 5x or 10x the cost of a top of the line mainstream model - 10s of thousands of $$.

Granted each one is built by hand so the artisanal craft is easy to appreciate.

But exclusivity is there, because these shops are building less than a dozen bikes per year. If you got your hands on one, wow it will turn heads when you roll up to the bier garden at the CX race.

Beyond the Abstract, can anyone give a TL;DR on novel or interesting things covered in this paper?

I actually implemented something on an embedded linux product once: a busybox initramfs that you could boot into "recovery mode," then along with dropbear, SSH into a completely in-memory system and re-flash the entire system image without having to pop out an SD card or connect a cable for DFU.

The recovery mode could even be initiated remotely, so you could re-flash a device without ever touching it. Of course you have to be careful, if the re-flash failed you could be SOL :) Apparently I need to go back and improve it so we can re-flash without rebooting!

These days you can use things like containers (Balena also looks very cool) to achieve a similar goal in possibly a "safer" way. But the idea of being able to re-flash the entire system while running it felt sort of like changing the engine of a car while driving it down the freeway!

The issue becomes when you're calling some generic library that's unaware that it is running in a request handler. If you want to log from deeper in some logic, maybe you've passed some data or domain objects but not a request/context/session object. Do you pollute that logic with additional data passed in or does your library just create its own logger and call `log.info('intermediate result of some thing: XXX')` and let the CLS magic associate that with the request that generated the call?