woodruffw

The author of that page appears to be a Holocaust denier[1]. Not exactly the example I would put forwards, especially if I want to make an unannealed appeal against Israeli war crimes.

[1]: A search for that name mostly brings up links to pages for SS apologia.

I left out the code on medical devices for a reason! And similarly for avionics software.

(The distinction I’m making is between the code that operates the medical device and the code that operates the app I make doctors’ appointments in. The latter is subjected to a different - and lighter - regime than the former.)

What does this mean? NIST and NSA are not even in the same federal department.

It might be an unpopular option, but I think the regulatory regimes that control medical and financial privacy as they interact with software are significantly lighter touch than e.g. the regimes that control material quality for bridges and tunnels, much less airplanes.

It seems to me like two things can be (and are) true: programming can be hard in absolute terms, and is also the easy part of the thing that we call “software engineering.”

How many programmers operate under that kind of regulatory and operational constraint regime? I think most don’t.

(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)

“Ultraviolet baths” for vitamin D.

https://www.nationalgeographic.com/photo-of-the-day/photo/ul...

I meant shedding of legitimate base load, not retries. I think we can safely assume they do the latter.

I think they kind of have to operate that way if you want a control plane/access to GitHub’s own layered services like caching and artifact storage. There are plenty of things to blame GitHub for, but this one doesn’t seem sinister at all.

Edit: to be clear, I mean the part where they maintain state on their end. I have no idea if they do that with another runner instance, that seems unlikely.

Why not both? Higher base load combined with insufficient internal controls for ratelimiting/load-shedding (as in, they don’t know who to shed) would be explanatory.

I don’t think the impact of these recent malware campaigns is below the threshold for federal interest.

I don’t think npm itself is measurably bad in ways that are useful to index on. Like others, I think that JS as an ecosystem has a culture that encourages both dependency sprawl and living at the edge, both of which contribute to the end problem of OSS malware.

(Rust has a similar culture, to be clear. I don’t think it’s a death knell.)

I would consider 2FA and signing to be strong layers, when applied well. I think everybody agrees we shouldn’t add layers just for the sake of it.

Yep. That remains the norm with Python source distributions as well. It’s a hard thing to overcome when it’s baked deeply into packaging assumptions.

RubyGems actually adopted Trusted Publishing before both npm and crates.io. To my recollection, they were second after PyPI.

(I have no opinion about the overall security posture of these indices.)

That would be extremely surprising, given the number and severity of federal crimes involved.

(I also dare say: many of these attackers demonstrate a better in-depth understanding of packaging ecosystems than supply chain security vendors do.)

Defense in depth is the “meat and potatoes” of security.

In other words: people should be auditing their software, but we should also design systems and schemes that provide varying degrees of defense and protection when people invariably fail to review the code they run.

Yep. This post is really old, I probably broke the CSS for these older posts a long time ago and never noticed it. I can try and fix it later today.

It’s funny to see this on HN. I wrote this 11 years ago as an undergraduate.

The afternotes at the end of the post are worth reading; people have sent me various qualifications and corrections over the years.

Sure, I don't disagree. It's just not clear to me that developers actually index that heavily on hot reloading to begin with.

Rust has an incremental compiler. And TMU SwiftUI’s live preview is essentially a very rough approximation of what the actual build would produce; it’s not a suitable replacement for a real build when developing a non-trivial UI.

Yeah, I mean more for the iteration half -- YMMV, but I find that I make the LLMs most productive when I have them design the typestates first, ensure they compile, and then work on tests after that (rather than stacking tests through the process).

Is it? An immense amount of the world’s graphical software is written for native graphical targets like SwiftUI, where the iteration cycle is similarly bound to build times. It’s certainly painful, but I don’t think it’s a non-starter.

You probably already know this, but I figure it bears repeating: most people should be running `cargo check` during development, not `cargo build`. The latter is only necessary when you actually need the built binary; the former is sufficient for type- and borrow-checking.

(On my local machine, `cargo check` is roughly 2x faster than `cargo build`. It's still slower than hot-reloaded Python, but it's rarely my development bottleneck.)

Anecdotally: I disabled Zed’s AI features, but I use LLMs more extensively than ever outside of my IDE. So the numbers may not paint a clear story here.

Is there a categorical division between “library builders” and “ordinary code”? That’s not one I’ve heard before.

(I’m aware of the difference between application and library code, but every large codebase I’ve ever worked in is a mixture of both.)

I don’t think that’s a parsimonious explanation in a post-COVID world. It seems equally if not more likely that talent is more distributed, and people find fewer reasons to relocate into the Bay Area (in terms of career progression, etc.)

(This is not, in my mind, either a good or a bad thing.)

For me, honestly not much.

WDYM by madness? I know what the flag is (and what it does), but people have strong opinions in opposite directions about what Python packaging should do around system environments.

It’s widely used, and there are still a lot of workflows that we hear about from users where they want/need to manually twiddle environments rather than having the “declarative” layer do it for them.