mechanicalpulse

You're not OP, but I think it's obvious that the question wouldn't have been asked had the nomenclature been more precise (i.e., had the article been titled "wax linear actuator" rather than "wax motor"). Yes, it's "like" a solenoid in the sense that it uses electricity to move a piston, but a solenoid is a very specific type that relies on electromagnetism. Linear actuators are also available in other forms -- geared and pneumatic ones immediately come to mind -- and I felt it was important to point out the distinction.

A solenoid is a coil of wire that functions as an electromagnet. Solenoid actuators are named after the coil. This device does not contain an electromagnet, so it would be inaccurate to call it a solenoid.

It depends on the vertical. If you're outsourcing a sixth-generation fighter jet or an aircraft carrier, your options are fewer than if you're outsourcing building construction or office supplies. You don't want to trust your nuclear-powered supercarrier to Joe's Boat Emporium.

Maybe a honeypot?

Anthropic is gearing up for an IPO. The fact that other protocols already do what MHS describes is not relevant to the intended audience: investors with FOMO.

Also: https://xkcd.com/927/

> I also think calling these a "sensor" is a bit of a stretch.

Indeed. At best, they're an "emitter", a "proxy", a "relay", a "transformer", or some combination thereof with "sense" or "marshall" that indicates the transformation of input to output a la "sense proxy emitter" or "marshalling sensor".

> Don’t we pass someone walking with a gas can on the highway every year though?

No. I see something like that every year on television, but not in the real world. If you've seen something like that every year, let me ask you a question: was the gas can empty or full? Gait while lugging five gallons of gas looks very different than gait while slinging around an empty can. Then, ask yourself whether or not you (or anyone you know) carries around a spare gas can in their vehicle.

The solution is A/B testing and then looking at the resulting crash statistics. Weekly reports produced by the connected BI system should use excrutiatingly precise language like "number of {people,children,dogs,expectant mothers} {killed,saved} under <PO>'s <new idea>". A real Trolley Web Problem 2.0. /s

> a little clumsily

s/a little/very/;

> What do you think the best implementation would look like?

We already had one! Dashboard indicator lamps have been an international standard (ISO 2575) since 1982.

> But it's also dangerous for a driver to run out of fuel on the highway if we didn't catch their attention.

Yes, it is. But the key word is "if". The product folks involved in making these UI/UX decisions were more concerned with whether or not they could (read: "chimp attract" for "feature parity" to "drive sales") than with whether or not they should (read: "should we be manufacturing two ton death machines that act like nannies?"). Where is the research that provides the answers to the questions "how likely is it that the driver isn't aware of how much fuel is in the vehicle?", "are our customers really as stupid as we think they are?", or even "what's the downside of training our customers to accept a more mindless state of existence while piloting giant metallic flesh-tearing bone crushers packed full of explosive hydrocarbons and squishy humans?"

> The general public though… uh oh!

You can come down from your ivory tower at any time. We have tacos down here and we all enjoy them.

To quote the late, great Lou Holtz, "they put their pants on the same way we do". I don't think there's ever been a time in all of my years on this planet that I've gotten into a car to go on a highway journey of any length and not looked at the fuel gauge. Oftentimes, my passenger will even ask me how much gas is in the tank. Glancing at the fuel gauge should be the first thing that any motor vehicle operator looks at when climbing into the captain's chair. Maybe I'm at that stage of life where I'm no longer capable of comprehending the manner in which the younger generations experience the world, but getting into an automobile and driving off without knowing how much fuel you have is like walking out the front door without confirming that your shoe laces are tied.

This constant othering of "the general public" without any research to back it up really grinds my gears, to use a contextually appropriate idiom. Please stop.

None of it matters if the controls aren’t responding. You’ll know, too, because they make that sad static beepy noise like some sort of Tactile Control Panel ACKnowledgement failure.

I can’t argue with you there. The Pentagon’s silence is deafening; I only want to caution myself as much as anyone against jumping to conclusions. It may be AI, it may be bad intelligence, it may be Russian counterintelligence, it may be an IRGC false flag, it may be a little bit of all of the above.

> I think Blizzard could have also made the player base just as happy by [...] understanding the underlying problem.

I'm reminded of the 1995 interview in which Steve Jobs elucidated the fundamental reasons that Xerox missed its golden opportunity to own the computer industry and why former PepsiCo CEO John Sculley later ultimately failed at the helm of Apple.

It's fundamentally the same issue with a number of gaming conglomerates nowadays. These companies are more interested in increasing the sales of sugar water than making great games. Perhaps, then, it's not surprising in the least to learn that former Activision Blizzard boss Bobby Kotick was on the board of Coca-Cola for a decade.

Modern 802.11 implementations are wildly complex. The output from `iw list` on a Linux system with a modern WiFi radio, a trip through the example configuration that ships with `hostapd`, or perusing the lengthy list of standards, amendments, and extensions on Wikipedia will reveal it, too.

Given the complexity of modern 802.11 protocols and the prevalence of WiFi radios in devices of all kinds, I find it well within the realm of possibilities for anyone to observe 802.11 traffic that is sufficiently ambiguous to create the confidence necessary to be a mentally workable substitute for evidence of a targeted attack. There may be a lot of evidence that could be found to refute that very same premise, though, if one knows what to look for.

“Life imitates art far more than art imitates life.” — Oscar Wilde, The Decay of Lying (1889)

I do and it does.

    $ ls -al /dev/std*
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stderr -> fd/2
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdin -> fd/0
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdout -> fd/1
    $ ls -n /dev/fd/[012]
    crw--w----  1 501  4  0x10000000 Feb 27 13:38 /dev/fd/0
    crw--w----  1 501  4  0x10000000 Feb 27 13:38 /dev/fd/1
    crw--w----  1 501  4  0x10000000 Feb 27 13:38 /dev/fd/2
    $ uname -v
    Darwin Kernel Version 24.6.0: Mon Jan 19 22:00:55 PST 2026; root:xnu-11417.140.69.708.3~1/RELEASE_ARM64_T6000
    $ sw_vers
    ProductName:  macOS
    ProductVersion:  15.7.4
    BuildVersion:  24G517

Lest you think it's some bashism that's wrapping ls, they exist regardless of shell:

    $ zsh -c 'ls -al /dev/std*'
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stderr -> fd/2
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdin -> fd/0
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdout -> fd/1
    $ csh -c 'ls -al /dev/std*'
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stderr -> fd/2
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdin -> fd/0
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdout -> fd/1
    $ tcsh -c 'ls -al /dev/std*'
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stderr -> fd/2
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdin -> fd/0
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdout -> fd/1
    $ ksh -c 'ls -al /dev/std*'
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stderr -> fd/2
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdin -> fd/0
    lr-xr-xr-x  1 root  wheel  0 Feb 24 15:08 /dev/stdout -> fd/1

I tried the install example that you provided and it worked on macOS as well as Linux.

It's possible that he's taking "hope for the best, prepare for the worst" to its logical if unhealthy extreme by interpreting every ambiguous 802.11 frame as one with ill intent. However, just because he's paranoid doesn't mean there aren't misaligned people, devices, and applications out there probing networks.

It's probably a good idea for anyone to check themselves every now and then by playing Angel's Advocate just as much as they might play Devil's Advocate, but I don't think rejecting his premises out of hand with a drive-by diagnosis is all that helpful.

Oh my... This is how the code could look indeed. Which LLM did you use to generate this?

Yes! I also used glyphosate to kill things growing in and around my sidewalk, driveway, steps, and curb. I've also used a propane torch for the same purposes, but it requires more effort and cannot be applied quite so selectively. It works, though, and is a good choice for anyone who would rather use a petroleum product than an herbicide.

I looked up the product you mentioned and you're right -- it does look like deodorant! It's a gel that contains glyphosate and isopropylamine salt. Neat!

> As I'm sure you're aware, glyphosate is usually only appropriate as a weed killer on your property if you're looking to kill all vegetation in/around where you spray it.

> It's a non-selective herbicide in this context, it kills everything.

It is a non-selective herbicide, but it's not a systemic herbicide. It functions by interfering with photosynthesis, but since it is minimally absorbed via root systems, it must be applied directly to the foilage. You can spray it on the ground around a plant and that plant will happily ignore it. This is why the instructions are explicit about applying directly to the foilage during sunny days when the wind is light.

As a homeowner, I loved glyphosate. It was cheap, simple, effective, and could be applied in a selective manner. It's not the best choice for getting rid of broadleaf weeds in a lawn, but I used it all the time in my gardens to kill weeds and keep the bermudagrasses out.

Nest is hardly the only thermostat out there using solid-state relays. Have you considered the possibility that they did take it into account and they deliberately chose to use SSRs instead of electromechanical relays? Have you considered the possibility that they were concerned about the impact that mechanical relays may have on the RF, especially if "there is higher current than you think running through those terminals"? Have you considered the possibility that they were worried about making the first one fatter than it already was?

In my heat pump, none of the thermostat wires directly control the contactors. They all run into a logic board that applies logic like time delays, temperature-controlled defrost cycling, and active protection lockouts for the compressor. I mean, there's a seven-segment LCD on the logic board for system troubleshooting. The air handler has a variable speed blower as well.

I understand that HVAC equipment varies wildly, but if you try to solve every possible problem or scenario and target every possible customer, you'll never make it to market.

I also understand that I am the target demographic.

Well that's certainly a take. Solid state relays using optoisolated MOSFETs have been around for fifty years. Mechanical relays are overkill for signal switching as in HVAC thermostats, IMHO, but you do you.

Anecdotally, I have a first generation Nest and haven't had a problem. Maybe some of the earlier hardware had fewer protection against misuse (e.g., with non-24VAC systems or otherwise incorrect installation), but that's generally the case with most new things.

I also went about looking at the difference rather than the order. In the hexadecimal case, the difference is 15 (0xEF vs 0x12). I thought, then, that for any base B with ascending digits A and descending digits D, (D-(B-1))/A=B-2.

For binary, it looks like (1-(b-1))/1=b-10 or (1-(2-1))/1=2-2=0 in decimal.

For trinary, it looks like (21-(b-1))/12=b-2 or (7-(3-1))/5=5/5=1 in decimal.

For quaternary, it looks like (321-(b-1))/123=b-2 or (57-(4-1))/27=54/27=2 in decimal.

Essentially and perhaps unsurprisingly, the size of the slices in the number pie get smaller the bigger the pie gets. In binary, the slice is the pie, which is why the division comes out to zero there.

> Did you live at a time where Internet was not a thing?

You must be relatively young. Software existed before the widespread adoption of the Internet.

> I remember very clearly buying software on physical media and never, ever "receiving" a single patch.

You had to take action to receive them. They weren’t automatic updates like they are today.

> I don't even know how that would have looked... "buy this floppy disk, it's a patch for a bug in the other floppy disk you bought recently"?

That’s exactly what it looked like. That’s still the process today for some systems —- avionics updates for Boeing 747s are provided on 3.5” floppies.

At infinity, the shape becomes a sphere and all orientations of it are identical. It is no longer a convex polyhedron and, thus, not subject to consideration.

Podman is daemonless while docker is a client/server pair. Podman also shipped with support for rootless containers, though Docker now has that capability as well.

The podman CLI is nearly a drop-in replacement for docker such that `alias docker=podman` works for many of the most common use cases.

If you don't care about the security implications of running containers as root via a client/server protocol, then by all means keep using Docker. I've switched to podman and I'm happy with my decision, but to each their own.

I've experienced the mind-numbing frustration of API specs that don't match the implementation, which is why I have embraced the concept of requiring the spec to be part of the implementation. For example, the express-openapi package for Node.js expects the specification to be supplied as a property of the very function implementing the operation. This permits middleware to access the OpenAPI specification directly and utilize it for coercion and validation of requests and responses, so you get several birds with one stone.

I've also experienced enterprise OpenAPI deployments where the API specifications were owned by a separate enterprise API architecture team and were fed into some central consumer-facing documentation portal along with whatever unbeknownst infrastructure sat between the application and the Internet. Developers had access to the spec repository, but API architects reviewed PRs and made any recommendations for normalizing interfaces or using existing or canonical types.

Either way works, IMNSHO.

Edit: I should also say that I have likely misrepresented the deficiencies I experienced with API Blueprint. Take it with a grain of salt; I literally do not remember because it's been ... checks code ... nearly five years since I touched that project. The issue I ran into may have been as simple a problem as providing two example POST requests with slightly different payloads or two example HTTP 200 responses with slightly different response bodies. This is something that API documentation might often include to show multiple common use cases. It may have not have even been part of the actual spec or it may have been only a limitation of the specific UI renderer I was using.

Mostly the fact that it's based on Markdown, which makes the raw specification far easier to read with a text editor than OpenAPI/Swagger. Markdown also permits styling in the various descriptive portions, which makes for superior documentation.

I ran into some deficiencies, though, at least with the parser I was using with Node/TS -- IIRC (and it's been a few years), I wasn't able to specify a wide variety of disparate responses (e.g., an HTTP 200 with an application/json Content-Type header, an HTTP 200 with a text/plain Content-Type header, and an HTTP 400 response with an X-Error-Code header). Since API Blueprint was introduced, the tooling around OpenAPI has improved dramatically and it's become a de facto standard, so I'd probably avoid API Blueprint for anything serious.

It's unfortunate, though, because I really liked the idea.

Others have already mentioned that this is possible with iOS. iOS 14 introduced a bunch of privacy improvements including the PHPickerViewController, but some apps may not yet be using it. [0]

I will say that in the event that an app is not using PHPickerViewController, sometimes it's still possible to emulate it by exiting the app, going into the photos app, selecting the photo, selecting the little "send" arrow in the bottom left, and then picking the app to send it to. I do this all the time with the Slack app. Copy-and-paste may be another route. Sure, it's a silly workaround for a feature that should have been there from day one, but c'est la vie.

[0] https://developer.apple.com/documentation/photokit/deliverin...

Yup. I've even found myself in situations where the owner of the third-party service is another team or department within the organization I'm working for or partnering with. Oftentimes, the product/project people on our team tries to make it a business issue with the partner only to find that they don't have the leverage to effect a fix, they get told that the service doesn't offer the SLA you require, or you hear back from the team some hilarious quote like six weeks of development that can't begin until the next quarter. Meanwhile, your feature or product has to launch by the end of the current sprint or quarter.

What happens when the unstoppable force meets the immovable object? The unstoppable force works over the weekend to implement a store-and-forward solution.

Gruber is famously protective of the original Markdown specification and his specific use case. He’s reacting to others’ expectations and clarifying his position that a “Markdown editor” is a bit of an oxymoron. He supports that position by reiterating his inspiration for creating the format.