joshkel

As explained by https://www.nytimes.com/2026/05/12/magazine/testosterone-mas..., "Supplementing with testosterone sends the message to the brain that testosterone is in oversupply, shutting down the testicles’ production of testosterone and sperm... The hormone is so incredibly effective at decreasing sperm counts that it is being tested as a possible male contraceptive."

FWIW, it sounds like the judge may be open to ruling against such an action. From his decision at https://aboutblaw.com/blQg:

Even if Plaintiff had made a “vote dilution” or “one person/one vote” claim under the Equal Protection Clause, it fails. Plaintiff does not assert facts that would adequately support such a claim. Plaintiff does not allege... that natural person voters are a minority or are politically cohesive [or] that entity property owners vote sufficiently as a bloc to usually defeat the preferred candidates of natural persons.

Although he also notes that the recent Callais case, severely weakening section 2 of the Voting Rights Act, may change this - and, of course, waiting until the Legalize Asbestos Consortium is doing its thing and trying to file a lawsuit is much more complex than preemptively saying "only natural persons can vote."

But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages.

Yes, and these are positive changes. But they aren't security boundaries, and they don't mean that pip won't execute arbitrary code: a malicious update could ship an update with sdist instead of wheels, a malicious pyproject.toml could provide an arbitrary-code `build-backend`, etc., and pip would still function as designed.

I appreciate the clarifications/corrections on PHP.

Which most people don't install directly, but have already had built for them by their distro.

Yes, but the original claim was that npm is "particularly susceptible to these attacks" because "npm can execute code after install and most package managers don't do that." I don't think that's accurate: we've seen hundreds of NPM packages compromised in multiple high-profile attacks over the last several months, while .tar.gz was used for decades with nowhere near the same number of compromises.

Rather, I suspect it's a combination of factors: Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects. And the extreme popularity of JS, the centralization of NPM + GitHub, and increased usage of automation makes attacks more practical and more lucrative.

Taking a step back from that particular debate, I'm very much in favor of changes like what you describe.

Taking still another step back, I'm not sure that even those will be enough. If I download a package, it's because I intend to run its code at some point: if it's malicious, I may be less automatically hosed than if its postinstall script runs, but I'm still hosed at execution time. I trust my distro packages, not because they don't execute arbitrary code on installation (RPMs and .debs both do), but because I _trust my distro_. NPM et al. simply cannot vouch for every package they host.

Thanks for the reply!

I'm far from an expert, but this feels like an oversimplification.

Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control.

Native Ruby Gems execute arbitrary code via extconf.rb.

Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorporated into your build (and so can run code at build time).

PHP Composer packages can ship install scripts or configure themselves as Composer plugins.

The venerable .tar.gz approach to packaging, covering decades of C and C++ code, is all about executing code during installation.

There are measures that can help (e.g., PHP Composer doesn't run install scripts of _transitive_ dependencies) but the JS space is adopting measures that can help too (like pnpm's approve-builds).

https://localnewsmatters.org/2026/05/16/musk-v-altman-week-3... has a good explanation of the legalities:

"If the jury determines that at any time before those dates, Musk either knew — or had or should have known — that he had a claim that he could bring, then his suit was brought too late. The consequence of being too late is swift and absolute. If the lawsuit was filed late for a particular claim, that claim is out of the case; if it was too late for all of Musk’s claims, the lawsuit is over."

That's where the question of fact (i.e., the requirement for a jury decision) came in: "What was the statute of limitations?" is a question of law, but "When should Musk have known that OpenAI was moving too much toward for-profit?" is a question of fact (and, here, determines whether the statute of limitations applies).

Reading this article has given me a profound realization: As a software user, I don't want the products I use to ship new features at "three, five, or ten times what they shipped a year ago," at the expense of "probabilistic" stability and reliability.

I want software that works.

Yet the economics of the software industry, and perhaps the economy as a whole, seem to inexorably push toward the former.

Considering the many hundreds of technical comments over at the PR (https://github.com/nodejs/node/pull/61478), the 8 reviewers thanked by name in the article, and the stellar reputations of those involved, seems likely.

Appreciate the reminder (the lack of SemVer has thrown me in the past). In this case, 6.0 is a bigger change than normal:

TypeScript 6.0 arrives as a significant transition release, designed to prepare developers for TypeScript 7.0, the upcoming native port of the TypeScript compiler. While TypeScript 6.0 maintains full compatibility with your existing TypeScript knowledge and continues to be API compatible with TypeScript 5.9, this release introduces a number of breaking changes and deprecations that reflect the evolving JavaScript ecosystem and set the stage for TypeScript 7.0.

The main selling point for me is that it has proper data times for dates, times, etc.

Most date/time libraries that I've seen have a only single "date/time" or "timestamp" type, then they have to do things like representing "January 13 2026" as "January 13 2026 at midnight local time" or "January 13 2026 at midnight UTC."

Temporal has full-fledged data types representing the different concepts: an Instant is a point in time. A PlainDate is just a date. A PlainTime is just a time. ("We eat lunch at 11am each day.") A ZonedDateTime is an Instant in a known time zone. Etc.

Temporal draws a lot of inspiration from Java's Joda-Time (which also went on to inspire .NET's Noda Time, Java's official java.time API, and JavaScript's js-joda). This is helpful; it means that some concepts can transfer if you're working in other languages. And, more importantly, it means that it benefits from a lot of careful thought on how to ergonomically and effectively represent date/time complexities.

In a follow-up tweet, Mark Atwood eloborates: "Amazon was very carefully complying with the licenses on FFmpeg. One of my jobs there was to make sure the company was doing so. Continuing to make sure the company was was often the reason I was having a meeting like that inside the company."

I interpret this as meaning there was an implied "if you screw this up" at the end of "they could kill three major product lines with an email."

pnpm doesn't execute lifecycle scripts by default, so it avoids the particular attack vector of "simply downloading and installing an NPM package allows it to execute malicious code."

As phiresky points out, you're still "download[ing] arbitrary code you are going to execute immediately afterwards" (in many/most cases), so it's far from foolproof, but it's sufficient to stop many of the attacks seen in the wild. For example, it's my understanding that last month's Shai-Hulud worm depended on postinstall scripts, so pnpm's restriction of postinstall scripts would have stopped it (unless you whitelist the scripts). But last month's attack on chalk, debug, et al. only involved runtime code, so measures like pnpm's would not have helped.

The way you know is by running the full SQLite test suite, with 100% MC/DC coverage (slightly stricter than 100% branch coverage), on each new compiler, version, and set of flags you intend to support. It's my understanding that this is the approach taken by the SQLite team.

Dr. Hipp's position is paraphrased as, “I cannot trust the compilers, so I test the binaries; the source code may have UBs or run into compiler bugs, but I know the binaries I distribute are correct because they were thoroughly tested" at https://blog.regehr.org/archives/1292. There, Dr. John Regehr, a researcher in undefined behavior, found some undefined behavior in the SQLite source code, which kicked off a discussion of the implications of UB given 100% MC/DC coverage of the binaries of every supported platform.

(I suppose the argument at this point is, "Users may use a new compiler, flag, or version that creates untested code, but that's not nearly as bad as _all_ releases and platforms containing untested code.")

Yes. Sardar Biglari, who's an activist investor and the CEO and owner of Steak'n'Shake, has been pushing for more control over Cracker Barrel for several years. He amplified some of the backlash against Cracker Barrel.

https://fortune.com/2025/09/18/sardar-biglari-war-against-cr...

Would you still say it's a small API surface? State, memos, callbacks (which are just memo functions), effects, effect events, reducers, context, external stores, special handling for any tags that go in the `<head>`, form actions, form status, action state, activities, refs, imperative handles, transitions, optimistic updates, deferred updates, suspense, server components, compiler, SSR?

Or maybe it's a small enough API but a lot of concepts. Or maybe I'm just grumpy that the days of "it's just a view layer" feel long ago.

I assume you're referring to Web SQL? As I understand it, the argument against isn't just "there's only 1 implementation," it's "there's no standard and there's only 1 implementation," so the standard would have to devolve to "whatever that 1 implementation does."

https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

For Git? Maybe not. For GitHub? IPv6 support would sure be nice: https://github.com/orgs/community/discussions/10539

at least occasionally one should choose to do something one will regret.

Not necessarily. My take was that the practice of choosing may well be more valuable than the harm of the occasional regretted choice.

The View Transitions API (https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...) is intended to let you control transitions between clicks.

I'm not sure how much difference that bill's clause makes in practice. As I understand it (courtesy of the "Advisory Opinions" legal podcast, but any misunderstandings are my own), the problem is that, if the executive branch is going to ignore the courts, then they're going to ignore the courts. A court can recommend prosecution for contempt, but prosecutors are part of the executive branch. A court could try and appoint their own prosecutor, but then the court is both judge and prosecutor - which goes against the US system's goal of an impartial and independent judiciary. The court could issue a fine for contempt, but then the government is paying a fine to the government? It could issue a sentence of jail time, but the executive branch administers the prisons and has the pardon power.

I'm disgusted with the executive branch's actions and congressional GOP's enablement. And, since the administration at times seems to want a fig leaf of legality, maybe the bill would make a difference after all by giving them more coverage. But, overall, I'm not sure that it's the "game over" step change that some commentary makes it sound like it is.

I could be misunderstanding - comments / counterarguments welcome.

Belief within limits, yes. At least, I can only think of a couple of possible explanations for the event:

1. Cook only cares about pursuing profits, but at a shareholder meeting where shareholders were pressuring him to pursue profits, he lied to them (and had the presence of mind and acting chops to pretend to be uncharacteristically angry about it), because he believed that the story would get reported on and Apple fans would want to hear it, and he made the calculation that that would be more beneficial to his bottom line than being honest (or at least more politically neutral) with his shareholders.

2. Cook really does believe about accessibility, environmental issues, and worker safety, and he tries (or at least likes to think that he tries) to take steps toward those causes at the expense of profits, but he's also a complex and flawed mixture of motivations and is capable of compromising his values (and/or of letting those under him compromise their values) to varying degrees in the face of financial rewards or the pressures of the capitalist system.

#2 seems more likely and is more consistent with my view of humanity in general.

That's not universally true, at least. From https://www.macobserver.com/news/tim-cook-rejects-ncppr-poli...:

“When we work on making our devices accessible by the blind,” he said, “I don't consider the bloody ROI.” He said that the same thing about environmental issues, worker safety, and other areas where Apple is a leader.

As evidenced by the use of “bloody” in his response—the closest thing to public profanity I've ever seen from Mr. Cook–it was clear that he was quite angry. His body language changed, his face contracted, and he spoke in rapid fire sentences compared to the usual metered and controlled way he speaks.

More broadly, I know that for-profit businesses are concerned with their bottom line, and I know businesses regularly throw other values under the bus in pursuit of profit. But I'm not sure it's possible to build a successful business (in terms of maintaining consumer trust, attracting and motivating decent employees, etc.) without some values beyond what's immediately quantifiable on the bottom line.

The biggest difference I'm aware of is that ECharts has an add-on for 3D charts (echarts-gl). Chart.js doesn't have any 3D functionality.

(Our project mostly uses Chart.js, so I'm more familiar with it.)

I mean, yeah, I said it was easy enough to work around. But it's an issue I've seen raised in a discussions of C code maintenance. (The typical conclusion is that using `-Wall -Werror` is a mistake for long-lived, not-actively-developed code.) Apologies if I overstated the case.

In practice, C has a couple of significant pitfalls that I've read about.

First is if you compile with `-Werror -Wall` or similar; new compiler diagnostics can result in a build failing. That's easy enough to work around.

Second, nearly any decent-sized C program has undefined behavior, and new compilers may change their handling of undefined behavior. (E.g., they may add new optimizations that detect and exploit undefined behavior that was previously benign.) See, e.g., this post by cryptologist Daniel J. Bernstein: https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...

Yes. I don't remember Murderbot using the Rin disguise / persona later on.

Why do you say that?

I don't have access to the books right now, but from what I remember, Rin is referred to as she/her, and random Reddit comments (https://www.reddit.com/r/murderbot/comments/118s7on/comment/...) back that up.

For what it's worth, Murderbot's "Security Consultant Rin" human disguise is apparently female.

Interesting.

The way I was taught Python, you really, really don't want to use bare `except:`, because it catches _everything_: Ctrl-C interruptions, system exit, etc. Instead, you really ought to use `except Exception:` (where `Exception` is the base class for any "normal" runtime error).

So I definitely understand the rationale, but it's hard to say it's worth the pain of backward incompatibility - we have linters, style guides, etc. that can catch this.

The FTC rule banning noncompetes was blocked by the courts: https://www.npr.org/2024/08/21/g-s1-18376/federal-judge-toss...

As explained by the FTC, "A district court issued an order stopping the FTC from enforcing the rule on September 4. The FTC is considering an appeal. The decision does not prevent the FTC from addressing noncompetes through case-by-case enforcement actions." (https://www.ftc.gov/news-events/features/noncompetes)

As I understand it:

Meltdown lets a process read from kernel memory.

There are several variations of Spectre. The first variant ("Spectre V1") lets a process read its own memory; the second variant ("Spectre V2") lets a process read another process's memory.

Web browser manufacturers seem to be focused on preventing Spectre V1, although I'm unclear on whether that's because V2 is too hard to exploit from JavaScript, is mitigated in other ways (e.g., CPU updates), etc.

Further reading: https://stackoverflow.com/q/53042230/25507, https://stackoverflow.com/q/48200753/25507, https://security.googleblog.com/2018/07/mitigating-spectre-w..., https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-..., https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...