mpyne

> sorry, but this just sounds like a rationalisation for "we built the wrong thing".

If it were so easy to decide what the right thing is to build before you build it then business would be easy.

That's the whole reason options have value. Having 3 shippable products ready to go when you can only effectively ship 1 puts the whole team in a much better position than choosing 1, focusing everyone on it, and hoping you hit the lottery with product-market fit.

So yes, an engineer may work on something that doesn't ship. That doesn't retroactively make their effort worthless, and that's not even counting the experience gained by the endeavor which may well pay off on the next round of products to ship.

Salinity, temperature and pressure aren't normally large factors for cetaceans, no.

If you're referring to active sonar, that's an issue for anything with ears under the water. But animals themselves also can make loud noises (e.g. the sperm whale can reach 230+ dB), as can surface ships with their own active sonar kits.

Is it? Seems from the outside that it was the thing that finally drove Anthropic into profitability.

About right, but more importantly it's highly dependent on factors like pressure, temperature and salinity, all of which change in relevant ways in the ocean depths.

People imagine sonar like it's radar, where you get clean bearings and distance readings, but it's so much noisier and hard to decipher.

And yet it really does travel long distances which is both good and bad if you're a submariner.

I've used many a government website in the Navy, and they were almost invariably bad, but it had nothing to do with React per se.

A very slow website I can think of had something like 200 GET requests required to load the landing page, and it used Liferay with Material Design Bootstrap. That was closer to the "style at the time". React is the style of this time, but you can write very slow websites in anything, I'm convinced.

This issue was one of AWS's listed reasons for tending to prefer NoSQL style databases over "more performant" RDBMS, because of the more consistent worst-case performance, even if the result is worse average-case performance, which was important in their assumptions for scalability planning.

There are Qt analogs for just this thing (QStandardPaths, https://doc.qt.io/qt-6/qstandardpaths.html) to drastically simplify what can be a quite annoying task if you're trying to write GUI software that respects the OS standard file locations across multiple desktops.

This is a different problem than migrating file locations in the same OS, as what the linked blog post is about, but it is a related issue for apps intending to be multi-platform.

> If cloud keeps making offers good enough such that people pick it instead of building their own PC, the number of personal devices will decrease.

Perhaps, but I never claimed otherwise. Simply that the personal devices that do exist will also have games for them. Computer games were here from the beginning, and they will be here in the end. And even personal devices that were chosen for non-gaming needs can play games, nothing requires games to run only on RGB-infested PCs.

> But I'm a bit skeptical of how much market value can be sustained by

Yes, the market dynamics may certainly shift, but that's been the story for decades already. And if cloud gaming were going to be this immediately-better story, things like Stadia and Luna would have performed much better in the market.

I think people worry about the cost-efficiency of how to do gaming in a world where hardware is expensive, but the reason hardware is expensive is because it's being sucked up for AI usage, not for gaming usage. So cloud gaming will also necessarily be expensive by these terms, even if the average cost seems less for a cloud gaming subscription than owning your own PC or console.

> The future of gaming will unfortunately be renting from the cloud

That might be your future. But as long as there are computing platforms that users can run in their own home there will be games for them.

Nor do I think Nintendo will simply drop their hardware efforts to focus on cloud, and their customers have proven willing to pay higher prices for the types of gaming experience Nintendo will deliver.

Yes, and this is much of my lament. The DoD mindset pervaded a lot of places building significant software systems in early computing, as compared to NASA and others.

I don't think iteration should have been considered unfortunate even back then, but it was. And by the time the DoD started to realize iteration was not only required, but helpful (no later than the mid-1980s with a Defense Science Board report on software acquisition methods initiated by Dr. Fred Brooks), the waterfall methods had more or less infested all of DoD software acquisition.

Even worse (for DoD), this was occurring even as DoD's organic ability to develop software-based systems was atrophying, so they needed their contracting/acquisition process to lead to successful software delivery more than ever before. Had DoD had a solid internal iterative software development process they could fall back on they'd have been in much less of a pickle.

> Oh I see. I guess your zygotes have developed more than mine. I think Google may have coined or at least popularized the term zygote for this in Chrome and Android, Chrome documentation [1] says:

Google may have popularized the term, but this approach was already in use by KDE developers in the KDE 2.x timeframe, where it was used as part of a system called kdeinit.

In this scheme, launching KDE apps from a KDE desktop could bypass much of the startup cost of dynamic linking by forking from a long-running kdeinit process (with kdeinit itself deliberately linked to all large dependency libs like Qt and kdelibs), dynamically loading the application logic (stored as a .so) and then launching the app.

This was more to save startup time due to how long it took to dynamically resolve a multitude of C++-based symbols back then, all the common logic came before the app's own main() would ever be called. But it did also save a bit of memory as well.

I don't think fork() mandates overcommit. OpenBSD doesn't seem to even allow overcommit or have an OOM killer, memory allocations that exceed available capacity fail immediately even if the memory is not touched.

Then it wasn't "actual waterfall development". The paper that defined waterfall literally tells you that you will build the system twice. Ideally only twice. You can refer to Dr. Royce's paper as the primary source on that.

It is heartening to know that iterative development has been commonplace since long before the agile manifesto was written though, to make it clear that it has long been used and long been successful.

> Just because I feel like something is better or different doesn't mean it actually is.

Of course, but it is a data point, and multiple such data points can be aggregated. This is true even if all you can do is compare two things.

The shape of that data will reveal something more about the thing you want to measure than the null hypothesis you'd otherwise have.

> I just don't believe non-deterministic tools can actually be benchmarked. It's all hoopla to me.

We benchmark non-deterministic things all the time and it's frankly not even that unusual or hard. You yourself indicate that one model outperforms another one in your experience on various facets, and that is itself a benchmark.

The more relevant question is probably how well does a given benchmark translate to improvement on a specific desired outcome or task. The military uses the ASVAB testing battery to benchmark potential new recruits for suitability in various career specialties, but the actual outcome the benchmark is meant to correlate with is later success in the training pipeline.

So every so often the various military branches have to do and compare ASVAB results against training results and make sure that they still have a predictive relationship.

And this is benchmarking real flesh-and-blood human beings where you get on the order of magnitude of a million data points or so per year. You can benchmark AIs much more efficiently than that, as non-deterministic as they are, and as long as the benchmark itself is reasonably predictive of outcome it's going to be useful information.

In fairness, with the waterfall methodology that pervaded back then, the "first" system you shipped was actually the second. "Build one to throwaway; you will, anyhow".

> In fact I thought the government had long since gotten pretty serious about using smartcards and HSMs for everything?

They do use it for a lot, but there are a lot of things that need to authenticate to each other in a modern ecosystem, especially if you're trying to replace security based on network boundaries as trust boundaries with zero trust (as the government is).

I worked with more than a few IL4 systems where the PKI/smartcard stuff was simply shoved into an F5 that did TLS termination and then everything on the internal VPC just used HTTP headers without even a crypto signature to convey which user had actually logged in.

As with anything else, the more you make it easy to the do the right thing, the more often you tend to see the right thing being done. So agencies that make it easy to request server PKI certs see increased uptake, other agencies just have server-to-server auth done by PSKs / API keys instead.

So the concern isn't usually cost but compliance, if it's nearly impossible to get those little developer experience affordances ATO'd themselves, agencies will instead just focus on getting the mission system itself ATO'd come hell or high water and the devs just get told to piece it together however...

Yes, the harness they used actually existed and was in use beforehand, it wasn't developed for testing with Mythos.

> The stdin-vs-stdout split is where I see the most actual "is this a TTY" mistakes though. Tools that emit JSON-on-stdout-when-piped and TUI-when-not work fine until something stuffs them into a PTY with piped stdin — then they're in TUI mode but can't actually read the user input format they expect.

Stuff like this is why a build script I used to maintain would redirect stdin from /dev/null when running commands that were intended to be non-interactive. You only need one script to hang forever waiting for a user to type in a password to decide that you'll force the issue going forward.

> Why would the price go down in the future?

Because price is driven mainly by competition, not by a desire to recoup prior spending.

Investors aren't doing things out of the sheer goodness of their hearts, so if they could just bump the price up they'd have already forced it up. The very existence of workable local models puts a cap on how high the price can realistically go, but the high level of competition still extant makes the price floor ever closer to the actual cost to generate tokens.

> I just wouldn’t bet that LLMs are going to make any of these realities any better, they might exacerbate those issues.

Yes, that's certainly a fair assessment, especially the more it convinces software developers they can talk to the LLM rather than talking to users.

Recruiting for those considering careers, and marketing more broadly for those who pay taxes.

They'd actually make economic sense where I live, the only thing that's held me from pulling the trigger is that I want to time it with when I need to have the roof inspected/replaced.

I'm aware of the arguments about how it can be that much cheaper when deployed at mass centralized scale rather than decentralized across a bunch of rooftops, however the way the electric markets are prices is based primarily on the cost to produce the marginal supply, which is usually gas.

So while the power company might flood a bunch of solar panels trying to capture the profit between cost to generate solar vs. cost to generate using gas, those profits haven't been lowering electric costs at residential rates. If anything those costs are still climbing.

It's actually not hard to get rooftop solar to pencil out in that situation, especially if you assume even moderate growth in future electricity rates or inflation. In my own tracker it would even be superior to paying down additional principle on my home mortgage!

Admittedly it would be less of a slam dunk if the net metering was less generous around here as you'd basically be required to add battery to the mix if you weren't already. But even that just prolongs the time to payoff, it still ends up having good ROI economically speaking.

My time in submarines at sea just coincided with the last few years where smoking on submarines was still authorized.

It was awful, just awful. Especially in a space as cramped as a submarine and with a common ventilation system, you can't just put the smokers in a convenient spot all to themselves, they're always going to be near something the rest of the crew needs to access.

> The process didn’t work before because the person writing the requirements either put out vague requirements or bad requirements because they didn’t understand the business intent (or were careless).

You make it sound like writing good requirements is easy.

If it were easy we wouldn't need all these concepts around PMF, product pivots and the like. And even before that was Peter Naur's paper "Programming as Theory Building" [1].

If you truly understand the problem you're solving with software then requirements can be easy. But usually we don't, not right away, and so we have to build up our understanding of the problem first in order to solve it.

Even then, the problem we solve may not have been the problem paying users will have, so you can have "good requirements" and still have a bad business, or even the opposite where you somehow build a working business despite bad requirements, because you hit upon a customer's need quite by mistake.

Nothing about any of this precludes LLMs being helpful, though nothing guarantees LLMs will be helpful either.

[1]: https://cekrem.github.io/posts/programming-as-theory-buildin...

If there are datacenters sitting idle right now then you could probably make a lot of money selling that capacity to Anthropic at this point...

They're responding to the people doing things like buying the most expensive Mac they can find specifically to do local inference for their AI agents.

Some do it to have control over their ability to use AI. Some do it because they think it will be cheaper to not have to pay a SaaS to generate tokens for them.

But for those interested in the latter case, it seems like it's not actually cheaper after all, at least at current prices. But then I don't expect prices to drastically jump because of how much competition there is in model development.

I hadn't but it would make sense for doing my own personal programming challenges.

Given the ongoing disasters around the software supply chains I've been fighting the creeping NPM-ism that people are trying to introduce to C++, where you just FetchContent 20 different libraries to build your own app upon.

I do use gtest, fmt and a few others though, so something as broadly used as Highway would probably be fine by that standard as well. But I'd still like it better if there was a Good Enough solution that was part of C++ stdlib to reduce the number of external integrations that are deemed required for a modern C++ program.

That's why it's an issue for investors. Their investment may not payout. But the things that were built will still have been built and available to sell for related purposes, the models that were trained will still be trained, and so on.

If things don't end up working out a lot of people have already been (and in the future will be) paid. It's the investors that will lose out, not the subscriber.

> I think a legitimate criticism is that it is unclear who std::simd is for.

I think it's for people like me, who recognize that depending on the dataset that a lot of performance is left on the table for some datasets when you don't take advantage of SIMD, but are not interested in becoming experts on intrinsics for a multitude of processor combinations.

Having a way to be able to say "flag bytes in this buffer matching one of these five characters, choose the appropriate stride for the actual CPU" and then "OR those flags together and do a popcount" (as I needed to do writing my own wc(1) as an exercise), and have that at least come close to optimal performance with intrinsics would be great.

Just like I'd rather use a ranged-for than to hand count an index vs. a size.

> People that don’t use SIMD today are unlikely to use std::simd tomorrow.

I mean, why not? That's exactly my use case. I don't use SIMD today as it's a PITA to do properly despite advancements in glibc and binutils to make it easier to load in CPU-specific codes. And it's a PITA to differentiate the utility of hundreds of different vpaddcfoolol instructions. But it is legitimately important for improving performance for many workloads, so I don't want to miss it where it will help.

And even gaining 60, 70% of the "optimal" SIMD still puts you much closer to highest performance that the alternative.

In the end I did end up having to write some direct SIMD intrinsics, I forget what issue I'd run into starting off with std::simd, but std::simd was what had made that problem seem approachable for the first time.