HN user

mechanicalpulse

129 karma
Posts0
Comments66
View on HN
No posts found.

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.

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.

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.

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.

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.

API Blueprint 11 months ago

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.

API Blueprint 11 months ago

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.

I'm reminded of a Final Jeopardy! clue from a few years back --

As of 2013, this 3-letter verb common in sports, theater & politics has the largest entry in the online OED.

The correct response? What is "run"?

The site was assembled using webpack and at least one element has a `data-react-helmet` attribute, so my guess is it's a React or React derivative such as Next.js. You're right -- it's not progressive enhancement and it's not necessary to present a simple tutorial.

Maybe there are other reasons, though? Maybe Ben wanted to learn the framework? Maybe Ben wanted to integrate a storefront and a comment section -- which he has done via Shopify and Disqus -- and his choice of framework made that easy due to the existence of official React libraries from both vendors? Maybe Ben's using cloud-native serverless deployment tools alongside his React application because some of the derivative frameworks like Next.js do really well at minifying, compressing, caching, and serving only the content that's needed?

I can understand the purist argument -- I really can, especially from a security standpoint given what we've learned in the past few years about cache-timing side-channel attacks -- but is it possible that Ben is simply a fan of learning and he's as excited about building a web application in React as he is about building an 8-bit computer from scratch?

Why intentionally introduce potential bugs for the sake of making a point?

It seems spiteful, but it strikes me as an interesting illustration of how the robustness principle could be hacked to force change. It’s a descriptivist versus prescriptivist view of standards, which is not how we typically view standards.

Great read, though I am compelled to comment on this ad-hoc date/time conversion:

    $ date=$(python3 -c 'import datetime; print(datetime.datetime.fromtimestamp(1707074879).isoformat())')
Consider reaching for `date` from GNU coreutils instead:
    $ date -Is -d @1707074879
Fewer keystrokes, faster execution, and the output includes the TZ offset.

So it looks like those have drifted further from "standard" Spanish, while Chile hasn't as much?

I think the chart is saying less about differences relative to Spanish Spanish and more about each regional dialect relative to the others.

In the table, the countries appear to be ordered (horizontally as well as vertically) by distance relative to Spain. Assuming there's nothing (like an ocean) to prevent the diffusion and evolution of language, given any cross-location in the grid, the cells nearest should theoretically have little to no gradient.

That's clearly not the case with Chile and isolation due to the Andes seems like a reasonable cause.

Colombia and Costa Rica also exhibit this effect, though, and I'm not sure why. FARC? They are separated by Panama and the PCZ; has the canal had an effect of preserving Panama's cultural ties relative to other countries at the expense of those of CO/CR?

Edit: s/Columbia/Colombia/; s/expensive/expense/