r2b2

[delayed]

Patients and providers should have the ability to shop and negotiate price directly with each other. No 3rd party will ever be in a better position to negotiate individualized care and prices for 350,000,000 people better than we (or our family) can for ourselves.

Currently, patients cannot price compare anything, not even for the exact same drug from two different pharmacies on the same street! To make it worse, most providers can't even make sense enough of the provider-insurer prices to shop on behalf of the patients.

To improve prices in healthcare, all care must have a price visible to all, paid by patients. Insurance should be required by law to publicly publish their reimbursement rates and immediately (48 hours) reimburse their insured patients for care at approved (in-network) providers.

This would end the current: impossible to self advocate, impossible for providers to advocate on behalf of patients, intractable insurer-provider price web.

Insurers and providers should never negotiate price. Providers should only be concerned with providing good care, how to classify/code it, and the amount they need to charge for that care to be financially viable. Insurers should only be concerned with how much they will pay out for each classification/code, and which providers they authorize as in-network.

Last, since there is a long tail of medical care that doesn't fit nicely into a code box, each plan should have a mandatory minimum coverage of something like 50% all unknown-care costs at in-network providers and pharmacies above $5,000 annually, with some annual cap.

As a society, if we want to further subsidize healthcare for those with lower economic means, and/or those who end up with catastrophic expenses, then that should be done on it's own, as two distinct standalone welfare programs.

I've found that as LLMs improve, some of their bugs become increasingly slippery - I think of it as the uncanny valley of code.

Put another way, when I cause bugs, they are often glaring (more typos, fewer logic mistakes). Plus, as the author it's often straightforward to debug since you already have a deep sense for how the code works - you lived through it.

So far, using LLMs has downgraded my productivity. The bugs LLMs introduce are often subtle logical errors, yet "working" code. These errors are especially hard to debug when you didn't write the code yourself — now you have to learn the code as if you wrote it anyway.

I also find it more stressful deploying LLM code. I know in my bones how carefully I write code, due to a decade of roughly "one non critical bug per 10k lines" that keeps me asleep at night. The quality of LLM code can be quite chaotic.

That said, I'm not holding my breath. I expect this to all flip someday, with an LLM becoming a better and more stable coder than I am, so I guess I will keep working with them to make sure I'm proficient when that day comes.

Firefox should make it clear that Firefox (browser) will not collect, transmit, nor sell user data beyond what is technically required for interaction between the browser and other computers over networks.

Anything less and people stop using Firefox.

If other Mozilla services need broader terms, those should be separate.

Building a service on top of the OSS, where some people prefer to self-host, but many don't want to self host.

Ex. Bitwarden, Infisical, Docker, etc.

[delayed]

Yes, adding max-use counts and expiration dates to links can mitigate against some browser-history snooping. However, if your browser history is compromised you probably have an even bigger problem...

Correct, DNS only queries the hostname portion of the URL.

Maybe my attempt to be thorough – by making note of DNS along side HTTP since it's part of the browser ↔ network ↔ server request diagram – was too thorough.

Good to point out. This distinction is especially important to keep in mind when thinking about when and/or who terminates TLS/SSL for your service, and any relevant threat models the service might have for the portion of the HTTP request after terminattion.

To somewhat mitigate the link-loading bot issue, the link can land on a "confirm sign in" page with a button the user must click to trigger the POST request that completes authentication.

Another way to mitigate this issue is to store a secret in the browser that initiated the link-request (Ex. local storage). However, this can easily break in situations like private mode, where a new tab/window is opened without access to the same session storage.

An alternative to the in-browser-secret, is doing a browser fingerprint match. If the browser that opens the link doesn't match the fingerprint of the browser that requested the link, then fail authentication. This also has pitfalls.

Unfortunately, if your threat model requires blocking bots that click too, your likely stuck adding some semblance of a second factor (pin/password, bio metric, hardware key, etc.).

In any case, when using link-only authentication, best to at least put sensitive user operations (payments, PII, etc.) behind a second factor at the time of operation.

To create private shareable links, store the private part in the hash of the URL. The hash is not transmitted in DNS queries or HTTP requests.

Ex. When links.com?token=<secret> is visited, that link will be transmitted and potentially saved (search parameters included) by intermediaries like Cloud Flare.

Ex. When links.com#<secret> is visited, the hash portion will not leave the browser.

Note: It's often nice to work with data in the hash portion by encoding it as a URL Safe Base64 string. (aka. JS Object ↔ JSON String ↔ URL Safe Base 64 String).

The syntax of your language is quite nice. I’d maybe change (for …) to (each …), (fun …) to (fn …), and (let …) to (def …) or (set …) depending on implementation details of variable assignment, but those are just aesthetic preferences :)

I love '{thing}' for string interpolation.

If you haven’t already, check out clojure, janet-lang, io-lang, and a library like lodash/fp for more syntax and naming inspiration.

Keep building!

  The list-style properties should be called marker-style, and list-item renamed > to marked-block or something.

I think list and list-item are clear.

How about just `mark` instead of `marker-style` to be consistent with other properties that decorate part of an element like `border` or `background`?

Autonomous electric cars make tunnels easier, which have smaller negative impact on the environment.

HN needs a @dang apprentice program so it can thrive for centuries.

Jitsi App Privacy:

→ https://apps.apple.com/us/app/jitsi-meet/id1165103905

And Zoom:

→ https://apps.apple.com/us/app/id546505307

Looks like one company likes to gobble data more than the other even if both privacy policies are gobble-open.

Yes, using a watch + compile + restart development environment where everything can be worked on locally reduces cycle time to 5ms, which is ~100,000x quicker than the 10m compile time in the parent post.

I've deployed 35,000+ lines of code to prod in 2023 with this flow. I've only had 2 small bugs.

This is by far the most efficient setup I've ever used.

• Ngrok only provides tunnels.

• Ngrok pulled a pricing bait-and-switch a year ago increasing prices to $240/year/user if you wanted a stable subdomain, even for bandwidth-trivial users.

-

Edit: Looks like they now have an $8/month/user tier for a single stable subdomain and now offer some edge hosting as well.

Money now is more valuable than money later.

As someone who has both built and sold software, it's simply to be able to sell software before it's complete. Without estimates, you can't sell something that doesn't exist yet.

This doesn't change the fact that requiring estimates is a bad idea if you want great software. The best software is built well, then sold.[0]

Great software later is more valuable long-term than bad software now.

--

[0] The best case is actually to sell software without a timeline. But most organizations are not able to operate this way.

Why mix regulation of two effects (sound and emissions)?

It's smarter to write regulation for each uniquely and directly.

Eg.

- Sound from air traffic shall meet <sound regulations> and when violated will incur automatic fees of <formula> amount.

- Air traffic emissions are required to meet <emission regulations> and will be taxed at <formula> amount (which should be used to offset pollution).