jt2190

I would have called this “strictly typed” I think, not “strongly”. Maybe my terminology is off.

> Strongly typed and weakly typed do not seem to have good definitions.

Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?

I don’t think this is anything new, really: Businesses have been running software that we’d call a “big ball of mud” [1] forever.

A common way to market to these firms is to be very easy to find when their software starts to have serious issues.

[1] https://www.laputan.org/mud/

> In America, at least, the school curriculum spends a lot of time talking about dictators.

I don’t think this is actually true. What’s your source for this? States set K-12 curriculum.

> … deterministic processes…

Just to be clear, software development itself is not deterministic, though? The software developer pushes a given business process from less-deterministic toward more deterministic? When we say we’ve “abstracted LLMs out of a process” we’d also say that we’ve abstracted software developers out that process as well?

Why can’t my firm react if we find out we’re being undercut by a competitor? Or are you saying that we “know” only in a theoretical, “we can’t prove we’re not being undercut” sort of way, but without “proof” we can’t take action?

> link aggregators

This is definitely manageable: canonical meta tags and other metadata; update the URL to a canonical permalink that encodes the language preference; a banner that informs people that there is an alternate version, etc.

Isn’t the client-side case something like “the banking app you’re entering your account password into is the binary the bank created and not a compromised binary that will drain your bank account”?

Why is attestation always bad, all the time? When two people interact there’s a trust/risk calculation on both sides. Isn’t attestation just a means of reducing risk for both parties? (We can debate who should control the attestation process and how it should work but your point 1 suggests that there is never a good form of attestation.) What would we do instead?

> Shell is not a programming language, it's an interface to the OS, and thinking about it like a programming language is just asking for frustration.

I guess this just isn’t obvious to me. Where do you see the boundary between “interface to the os” and “programming language”?

> Overall the evaluation of success was one of the most challenging parts of the project. As a developer, I’m used to building features that either work or don’t and there is often an objective way to measure how well a feature performs. For messy real world data it was hard to evaluate how good or bad the pipeline was. Furthermore, it was easy to start optimising for a specific parameter or route and find later that this work led to severe degradations in other areas.

> Verification becomes hard to reason about because there is no ground truth for points of interest, there are no red/green unit tests for taste. I’m sure these are familiar challenges to data scientists and that there are frameworks and evals for working on them. This will require more iteration and manual overrides. Hopefully with feedback and collaboration from the community. But for now I’ve shipped V1…

I suspect LLMs may be able to help us quantify our taste because they can keep track of so many data points all at once, where we have to lossily abstract these details away.

But the larger point still stands: Limited liability was granted “on the front end” without the entity needing to demonstrate a minimum amount of capital. You’re only pointing out that in the U.S. that it’s possible that “on the back end” the owners of the entity might become personally liable.

> [L]eadership thinks (likely correctly) that implementing them would just hurt company’s bottom line.

Exactly. There's little "win" here for the business, especially when the simpler "just cap at n requests" solution exists. Pursuing this solution:

- introduces more technical complexity (increased cost of developing, testing and maintentance)

- forces overage costs onto the vendor, who will then... increase prices to cover these costs, which upsets customers and makes the company less competitive.

- doesn't improve cost prediction (since n requests can be costed out a $/request quite easily and reliably)

(The cynical will say something about "the business has an incentive to _not_ fix this issue because they get paid for overages", but this assumes that Cloudflare has the, "monopolistic" market power to make customers unhappy and still charge whatever they want. In this case implementing billing caps wouldn't do anything because Cloudflare could just... charge whatever they want.)

The playlist is hilarious and really helps nail the feeling of driving around in circles! Love it!

Counterpoint: I’ve had recent support calls with two large corporations, both with humans. In both cases the humans lied about what could be done to address my issue.

In one case I was literally repeating back to the human what I’d just been told, and getting them to confirm that what I said was correct. First bill arrives and I find out the truth.

Second case I was told I’d have to cancel and create a new account to add a service. I decided to keep my existing account and learned that there is a web page where I can easily self-serve and add the additional service in one or two clicks. (I assume like the human actually made more money for “new account signups”.

My point is that the feeling of being a valued customer is really independent of whether you’re interacting with a human.

How did you make the illogical leap to “could not”?

Repeatedly requesting time/budget to fix an ongoing issue is a requirement of any half-decent manager. If they’re reporting issues then just smiling blankly when asked “what can we do about it?” they’ve failed their basic job duty.

> But for high quality work [a code review is] indispensable.

The argument here is that all code reviews are done with attention and care, but quality of a code review is highly dependent on the reviewer and the team’s review process, and in the real world the quality of reviews pretty much follow the same distribution curve as, say, agile project management: For the time invested in reviewing, a handful of teams get excellent utility from them, most teams get little benefit, and a sad few actually cause harm.

If most code reviews provide only a little benefit at base for most teams, recommending that most teams should also delay shipping quality work is going to sound a lot like bad advice.

(2021)

> container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. This approach has the following properties:

> - Security: Each container has the isolation properties of a full VM, using a minimal set of core utilities and dynamic libraries to reduce resource utilization and attack surface.

> - Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.

> -Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.

More details, including technical limitations (they’re looking for bug reports and contributions): “Container: Technical Overview” https://github.com/apple/container/blob/main/docs/technical-...

Because while consumers value “inefficiency” (high design, wonderful prose, beautiful images, great usability) they don’t want to actually pay for it. Producers have to become extremely efficient without revenue, and are stuck with a choice: Produce at a loss, stop producing, or seek payment from another source (sponsorships, ads).

> This is a measurement discipline: when someone offers you a test pass rate as evidence of a safety property, check whether the test suite measures that property. Behavioral equivalence and memory soundness are different axes. A green test suite tells you the new thing acts like the old thing. If the old thing was a body of manual memory management and the new thing is a faithful translation of it, then green tells you the translation is good - and tells you nothing whatsoever about whether the thing is safe. The number that would actually answer the question is the one nobody can produce yet, because producing it is, for now, an unsolved problem.

Bottom line is we didn’t have a measurement of safety before the port, and we don’t have one now.

What we do have is a known list of unsafe blocks, and we can use that as our safety measure. (I’m neither a Zig not Rust programmer, but I’m guessing that the unsafe parts of the Zig codebase were also mostly measurable so we could have had this measure.)

I do wonder if the next step is to move bun into WASM for an additional layer of security. Those unsafe blocks might be neutered by not granting WASM the ability to run them. That would give anthropic a “sandboxed by default” opportunity.

It’s a fun project to watch!

Lovely!

I mean, yes? Anthropic’s investors are seeing more upside now and valuing the company higher. Your thesis is that this additional value is driven by better marketing rather than a superior model. Could be! The truth is we’ll never really know with certainty what factors are doing the heavy lifting here, we can only guess and argue over who’s a better guesser.

Literally the next sentences:

> It’s one that we’ve been facing for quite some time. The reason we wrote this report, however, is to highlight the fact that we’re sort of in this moment in time right now, with our relationship with the U.S. deteriorating and us trying to diversify our trading partners, to highlight the fact that we are still not really all that competitive. Our productivity growth is quite low and has been for a few years now. So, banging this drum about wanting to raise this issue around competitiveness, that was the goal of this.

With the U.S. moving from a cooperative trade partner to a trade competitor, Canada needs to up its game.

No, it’s actual insurance:

> Iran has started a Bitcoin-backed insurance service for Iranian shipping companies that want to transit the Strait of Hormuz, the semi-official Fars news agency reported, citing documents obtained from the country’s Ministry of Economy and Financial Affairs.

> According to a screen shot of the insurance company’s website, dubbed Hormuz Safe and shared by Fars news, it “provides Iranian shipping companies and cargo owners with fast, verifiable digital insurance.” Fars didn’t give a detailed break down of how the insurance works and whether it’s available to foreign shipping companies and vessels.

Why would a brand new car not be road worthy? Is it common for new cars to be unsafe to drive?

You’re not an example of what we’re taking about here. Congratulations!

A better example would be if you’d changed the behavior of the library as you did this work, and the library changes introduced hard-to-detect bugs across the application.

Same article syndicated on msn.com, without paywall: https://www.msn.com/en-us/money/companies/new-york-californi...

The issues:

> The New York and California pension systems would become holders of SpaceX shares through their passive allocations if the company is admitted to major U.S. stock indexes.

> The officials… objected to the amount of power the board has given Musk over the company, including:

- voting control over the stock,

- veto power over his own removal as CEO, and

- protections from litigation, including mandatory arbitration for SpaceX shareholder claims.

> …

> In their letter, the pension leaders urged SpaceX to:

- adopt one-share, one-vote or sunset super-voting shares within seven years;

- install a majority-independent board and separate the CEO and chair roles;

- eliminate provisions protecting Musk from termination without his approval;

- scrap mandatory arbitration; and require independent approval of related-party transactions with Musk's other companies.

(Formatting mine; moved paragraph about becoming holders above the lists of concerns and recommendations.)

Isn’t a change to the code that incorporates your suggestions enough acknowledgment? Presumably the code change would be required to get your approval?

Docker recommends using multi-stage builds e.g. Stage one image has the package manager, stage two image omits it completely, leaving only the installed software.