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.

I was curious, and since the author of this answer provided links to what they called leaks [1], it's not difficult to download both the leak and ReactOS source [2] and look for similarities. So, out of curiosity, that's what I did.

I started poking at some source files at random in ntoskernel, and it only took a minute to get some "hits" from the ReactOS source:

    $ rg InitializeContextThread
    ./ntoskrnl/ke/thrdobj.c:872:        KiInitializeContextThread(Thread,
    ./ntoskrnl/ke/powerpc/thrdini.c:53:KiInitializeContextThread(IN PKTHREAD Thread,
    ./ntoskrnl/ke/i386/thrdini.c:92:KiInitializeContextThread(IN PKTHREAD Thread,
    ./ntoskrnl/ke/amd64/thrdini.c:36:KiInitializeContextThread(IN PKTHREAD Thread,
    ./ntoskrnl/ke/arm/thrdini.c:53:KiInitializeContextThread(IN PKTHREAD Thread,
    ./ntoskrnl/include/internal/ke.h:464:KiInitializeContextThread(

    $ rg NpxFrame
    ./ntoskrnl/ke/i386/v86vdm.c:473:    PFX_SAVE_AREA NpxFrame;
    ./ntoskrnl/ke/i386/v86vdm.c:480:    NpxFrame = &StackFrame->NpxArea;
    ./ntoskrnl/ke/i386/v86vdm.c:481:    ASSERT((ULONG_PTR)NpxFrame % 16 == 0);
    ./ntoskrnl/ke/i386/v86vdm.c:485:    RtlCopyMemory(KiGetThreadNpxArea(Thread), NpxFrame, sizeof(FX_SAVE_AREA));
    ./ntoskrnl/ke/i386/v86vdm.c:510:    PFX_SAVE_AREA NpxFrame = &StackFrame->NpxArea;
    ./ntoskrnl/ke/i386/v86vdm.c:512:    ASSERT((ULONG_PTR)NpxFrame % 16 == 0);
    ./ntoskrnl/ke/i386/v86vdm.c:551:    RtlCopyMemory(NpxFrame, V86Frame->ThreadStack, sizeof(FX_SAVE_AREA));

[1] https://github.com/Zer0Mem0ry/ntoskrnl

[2] https://sourceforge.net/projects/reactos/files/ReactOS/

I clicked the article link just because I was expecting to see this guy: https://en.wikipedia.org/wiki/Steve_Urkel#/media/File:Steve_...

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?

I have not used Java in many years now, but I'm curious if anyone has anecdotal experience using OpenJDK in production? Performance vs Oracle Java, bugs/ idiosyncrasies due to internal API differences, etc?

I tried this as well, can't reproduce.

I've got a 15" "late 2013" rMBP, set display options to "more space." I've got a total of 45 tabs open between a couple different windows (I use the userChrome hack to re-enable multiple tab rows.) Cycled between tabs, refreshed, navigated around FB, GMail, etc. Can't get the CPU to do anything out of the ordinary.

If anyone is interested in other lightweight tools to complement a minimal embedded linux distro, check out Troglobit's GitHub repo: https://github.com/troglobit. He has a collection of tiny apps perfect for embedded systems, such as...

  - mdnsd (not in Busybox), 
  - merecat httpd (much more full-featured than busybox  httpd) 
  - inadyn dynamic DNS updater
  - finit (IMO much nicer than busybox's runsv)
  - watchdogd
  - uftpd
  - ntpd (with ipv6 support!)

I hate to say it, but demonizing ICE seems like the wrong thing. It's the executive administration that direct ICE and Congress that tells ICE the laws to enforce.

That's not to say they are blameless but we could point fingers at pretty much every federal agency. ICE is just in the crosshairs at the moment.

How about a web interface on an embedded device?

I really don't want to learn dart

Literally half of programmers: "Ugh why can't everything be Javascript" Other half of programmers: "Ugh Javascript is the worst language in existence" /s

Given that javascript (esp on mobile) has a hard time reaching native performance, they presumably chose Dart because its design makes it immensely easier to target native iOS and Android without drastically augmenting JS to the point where it's no longer JS.

If there's a non-JS language that's easy to learn for a JS programmer, Dart (and I guess, TS) are it.

This is true. Thankfully node-pre-gyp helps here because you can build the native modules once for each target arch/platform. I actually have a node app that uses several native modules, and `npm install` it for an ARM target from an x86 host. It also works cross-OS (e.g. build on MacOS for linux.) The key flags are `npm install --production --target_arch=arm --target_platform=linux`.

Have you looked into a DIY battery replacement?[1] I've replaced "non removable" batteries and cracked screens in several phones over the years (the latest being a Nexus 5X) and it's definitely doable if you have a steady hand, patience, and the right tools.

[1] https://www.ifixit.com/Guide/Motorola+Moto+X+Battery+Replace...

There is no real demand for alternatives to the RPi.

Only if you quality that with "among consumers." There is tons of demand for ARM-based modules that are designed to be embedded in a commercial product. Comparing this product to any SBC such as RPi3 or Orange Pi completely misses the point. Just look at the headers on pretty much every SBC. If you see 0.1" pitch headers, it's meant for hobbyists, not commercial application.

As mentioned elsewhere, you can compare this to CM3, but there are tons of other players in this space (and there have been for longer than the CM has been around.) To name a few: Anything from Variscite, Myir, Toradex: note many of these cost well north of $50 because they're meant for commercial/ industrial. Samsung Artik 053, Chip Pro, Olimex SOMs and SOPINE are some newer players that have been pushing the price down a bit in this space. So this product is price competitive, esp since there aren't many aarch64 modules out there.

Specifically: if you were designing a product that needs Ethernet (esp GbE) you almost certainly would not choose the RPi CM because it's not on the BCM chip. i.MX and AM335x support 10/100 MAC/Phy, H5 supports GbE. If you were doing an automotive product, RPi and H5 do not have CAN, so you might choose an AM335x SOM. There is definitely a real demand for alternatives to the RPi in the space that this product is targeting.

I don't know firsthand, but "Debian" is primarily responsible for userspace binaries, which just need to be built for aarch64. Just about everything specific to the chip & peripherals is handled in the kernel. (Yes Debian has a linux-image deb but I don't think anyone uses that on ARM. You build your own kernel.)

I am oversimplifying a bit, but you should be able to take these instructions [1], combine with a kernel and bootloader built for this board, and write the resulting image to eMMC/flash. You need to configure a few things correctly, boot cmdline & bootloader options but that's it.

Source: have used debootstrap to build custom distros for a couple ARM modules as well as x86.

[1] https://www.olimex.com/wiki/AM335x#File_system

I think "ecosystem" doesn't actually matter much (if "ecosystem" means maker/ tinkerer mindshare) for commercial applications. All you need is (1) kernel support for the chip including drivers e.g. for video/ peripherals, and (2) good userland support for aarch64. You can debootstrap a Debian rootfs that will work on any aarch64 chip. As mentioned elsewhere, it sounds like the H5 chip has good kernel support which covers (1.) Actually there's a (3), which is bootloader support. I don't know if the H3 typically uses u-boot or some other bootloader.

What differs is what each chip actually supports. E.g the Pi/BCM2835 doesn't have onboard ethernet MAC/Phy. Neither Pi nor H3 have onboard CAN but maybe neither of those things matter. Point is these days most of the details of the chip are abstracted away; if you have good kernel support there's not a lot to worry about.

PocketBeagle unfortunately isn't sufficient for integration into a commercial product. It doesn't breakout most of the AM3357's pins. If all you need is USB/I2C/SPI/GPIOs you're OK but PocketBeagle omits things like ethernet, LCD, CAN. If I'm not mistaken PB also has no onboard wireless.

The ironic part here is, part of npm's core design - installing all deps to `./node_modules` - makes it extremely easy to "build" on one machine and then zip up the whole project directory which only needs `node` to run.

This is in fact way easier than options for python, ruby (and probably many others) which tend to install versioned dependencies to some shared directory and then add them to the path at runtime. So you're very right, it's trivial to not need npm at all, ever, in production.

The real interesting part of this is the formal verification tools they described which were used to uncover these vulns.

It seems that, while not a silver bullet, FV tools of this sort would be the most reliable way of discovering (and preventing) these sort of issues in microarchitecture.

I'm currently taking Andrew Ng's Machine Learning course on Coursera; I immediately thought of using logistic regression to find this shape algorithmically. I know the premise of the paper is "with four parameters." But: with enough polynomial terms it should be easy to get much closer to the example in figure a than the one shown in figure b, no?

MQTT and CoAP both support TLS. With TLS 1.2 you've got elliptic ciphers which puts it in reach of small embedded devices. So TLS with server certificates are enough to ensure confidentiality and server authenticity.

Client certificates can cover the client auth side although there are gotchas:

(1) dealing with revocation is more difficult as devices can more easily become compromised (physical access = extracting keys from flash/RAM.)

(2) assume a vendor issues a unique client cert on every device, and the chain reaches a CA. For multi-tenant cloud vendors, you still need to figure out which e.g. Philips Hue bulb is Bob's when Bob logs into his cloud portal. So there's a pairing issue that usually requires a one-time-pad or similar. Right now everyone does that differently.