frankus

Isn't this just seeing a slippery slope and deciding to build a terrace[1], in that the existence of a digital ID doesn't automatically lead to mandate to carry one—any more than the existence of a physical ID card does?

[1] to paraphrase one many excellent John McCarthy-isms: http://jmc.stanford.edu/general/sayings.html

Rounding to a nickel has the advantage that's it's both simple (1, 2, 6, and 7 round down; 3, 4, 8, and 9 round up) and fair (there's no systematic bias in favor of the buyer or seller).

Dimes need to deal with how to round numbers ending in 5, making them unfair, or (with a more elaborate system of looking at both digits) complicated.

Quarters (being an odd value) are fair, but kind of a nightmare to memorize all of the values that round up or down (1–12, 26–37, 51–62, and 76–87 round down; 13–24, 38–49, 63–74, and 88–99 round up; and I'm not even sure I don't have an error in those numbers).

Also it's awkward if a higher-valued coin (e.g. quarters) isn't divisible by the least valuable coin (e.g. a dime)

I think business-logic-in-JavaScript is something cross-platform folks shouldn't snooze on either, with the usual caveats of not doing anything performance-critical or where an asynchronous API would be awkward (to be clear, using JavaScriptCore or QuickJS or the like, not just running in a WebView)

But it'll run on iOS (v7.0+), Android (I think more recently) and of course web and server-side. And most importantly, it's hot-reloadable, as long as you don't run afoul of platform gatekeepers (i.e. use it for bug fixes and minor behavior changes, not like whole new features).

One of the frustrating things about mobile development is that once you ship a version, that version will almost certainly be running on at least someone's device indefinitely without being upgraded. My day job is even on step further back in that we have to get our customers to update the version of our SDK that they're integrating (which for many of them means contracting out because they don't have an in-house mobile dev team), before they ship an app update, which then needs to be installed by end-users, whose device might not even support the new deployment target…

(I've been trying to sell this to the bosses for the last 9 years or so, and never gotten the go-ahead, so there could be aspects I'm missing, but it always seemed like a huge missed opportunity).

This would have been super helpful like 20 years ago when I was on the data center floor trying to debug rack-mount (headless) Linux servers. The center had like one KVM "crash cart" that needed to be plugged into a spare outlet in the rack that wasn't always easy to come by.

I'm sure we could have improved on that setup but we were an inexperienced skeleton crew on a shoestring budget and not the best management.

I always thought it would be great to have a "laptop without a motherboard" to manage these, and this is close enough given the price of the redundant hardware now.

For just straight up assembly of one-sided SMT boards (i.e. not reclaiming components from a donor board), a $30 plug-in electric skillet and a solder paste stencil from the PCB manufacturer (or patience and a solder paste syringe) works far better than it has any right to. https://www.instructables.com/Simple-Skillet-Surface-mount-S...

If a private jet is just too "new money" for you, you can travel in style like a 19th-century robber baron.

I had the same thought, with what looks like a ZIRP bump pre-2021 finally normalizing to where it tracks the stock market much more closely.

"and very good reasons for not implementing Apple Wallet"

Judging by the screenshots, it looks like a thin wrapper around a mobile-optimized web site, or at best something like Flutter, so the likelihood that they have in-house developers that are sufficiently versed in the dustier corners of Apple's APIs is slim.

If you want something to take you down a notch, maybe something like "You are a commenter on Hacker News. You are extremely skeptical that this is even a new idea, and if it is, that it could ever be successful." /s

I'm subjectively terrible at recognizing faces but scored significantly better than the average test taker on the recognition test (https://www.testmybrain.org/face-blindness/face-blindness.ht...). There must be some selection effects among the test takers.

I scored worse than average on the celebrity faces test, but I chalk that up to be largely oblivious about pop culture.

A similar thing happened with SkyTrain's Canada Line, where it reached capacity very soon after it was built. They did plan a contingency to be able to extend the platforms for somewhat longer trains, however.

The US government also has a program of subsidizing/mandating biofuels that raise prices of both food and fuel for supposed environmental and energy security reasons that mostly don't pass a sniff test.

I need some of these mathematical tiles to be available as physical ceramic tiles for nerdy backsplashes and bathrooms.

Every now and then I dream about how much more money I'd be making if I lived in the Bay Area, but then I read something like this and realize that earning ~half as much working remotely from a cheaper (at least when I bought) city maybe isn't so bad.

Pretty much only less boilerplate. Definitely questionable if it's worth the added complexity. And also it could probably be a macro.

Swift has a typealias keyword but it's not really useful for this since two distinct aliased types with the same underlying type can be freely interchanged. Wrong code may look wrong but it will still compile.

Wrapper structs are the idiomatic way to achieve this, and with ExpressibleByStringLiteral are pretty ergonomic, but I wonder if there's a case for something like a "strong" typealias ("typecopy"?) that indicates e.g. "this is just a String but it's a particular kind of String and shouldn't be mixed with other Strings".

Teletypes were long gone by the time I started playing with computers, but computing definitely existed before CRTs were the dominant output format.

My favo(u)rite Type 1 has got to be “whippersnipper” (string trimmer).

Thanks for the link. One of the projects I'll probably never get around to is a thermoelectric-augmented fan coil unit for air-to-water heat pump retrofits. The existing emitters (and crucially the in-wall distribution piping that's expensive to insulate and vapor seal after the fact) would stay just above the dew point, and then the augmented fan coil would work to remove latent heat (humidity) by dropping a bit below the dew point via thermoelectric coolers that reject heat into the return piping.

It's a relatively small delta-T and in most climates a relatively small fraction of the overall cooling load, so it might just barely pencil out.

I'm not sure of the exact reasons but you don't really see vapor-compression heat pumps in the tens- to low-hundreds-of-watts range. So I suspect there are some scaling factors where the reduced size/noise/complexity of a solid-state device starts to be more important than the extra energy that it uses.

I think most of the commercial bed cooling systems are thermoelectric (ChiliPad, Eight Sleep) and they seem to work fine, but by the time you get to the scale of a small fridge or dehumidifiers the products are generally awful.

I think the gotcha is that you need a beefy heatsink and fan (and power for the fan) to keep the hot side anywhere close to room temperature.

I imagine the requirement to be the default phone app is in part to prevent rogue apps from colluding with rogue expensive-toll-services to place calls to them without the user's authorization.

I work all day in Swift (which makes you go out of your way to omit argument labels) and I'm surprised they aren't more common.

Loosely related talk from Hank Green a number of years ago whose thesis is basically that you don't owe your past self's dreams anything. It's kind of hard to summarize further, but I really like it:

https://www.youtube.com/watch?v=lPtopvsxmZY (the main part starts about 5 minutes in, some salty text)

I attended a talk given by a local author who wrote a book about his father being the first black software engineer at IBM, who joined with several women around 1950, and the gist was that it was mostly to take some heat off of them for this collaboration.

Any idea why they used a dog (or werewolf?) mouth model in the video?

Appropriately enough, that "everywhere on earth gets the same number of hours of daylight" fact came from a solar system salesperson, who didn't go out of his way to emphasize the atmospheric effects here at ~49°N.

The silver lining is that our longest days are often our sunniest.

The whole "6am sunrise and 6pm sunset every day of the year" thing at the equator is kind of mind blowing.

Another maybe counterintuitive fact is that (to a reasonable approximation) everywhere on earth gets the same number of hours of daylight over the course of a year.

Stepping back, would granting a time-limited exclusive license to the output of generative AI "promote the Progress of Science and useful Arts"?

In other words is there important AI art that society would be missing out on because the originator deemed it not worth the effort without some protection against unauthorized copies being made?

In that case there's going to be a pre-existing work-for-hire agreement where the camera operator assigns copyright to the studio.