mpyne

Yes

I don't know, did the prior vibe-coded Zig code not ever have pointers aliased to data? Might be preserving semantics too well, if anything.

People absolutely will sell you Linux, and they make a lot of money in the process.

I'm not even sure I'd describe it as a monoculture either, if it was that would probably have accelerated its growth even more. Imagine where Linux would be if it were like FreeBSD in having only one distro, one libc, one set of system libs.

You're starting to see it as a server backend lingua franca but even there, there are multitudes. And there remain a great number of organizations that run on one of the BSDs, Windows, old mainframe OS, and so on.

Couldn't they already do this today, without an additional regulation?

Why is a charity supposed to be able to magically conjure sales the original seller was unable to find?

I just think if it was as easy to doing this, there's already be nothing for regulators to be complaining about.

Sure. Until it wasn't.

Even if Linux was a monopoly that would not necessarily be the case for ever, as the example of the Windows monopoly demonstrates. But Linux isn't even a monopoly today.

At the time that may even have been true, there was essentially nothing else for personal computer usage, and there were no alternate form factors like mobile.

But even there the issue wasn't the existence of monopoly per se, but with the (ab)use of the monopoly to also capture the emerging Internet browser market.

The invisible hand of the market has been handcuffed a bit here though. Though I imagine this will simply show up as higher cost rather than blanket inavailability.

Typescript isn't nearly as popular as C++

Huh?

You should reassess how your current understanding of language popularity compares to what's actually going on outside your environment.

Typescript has already surpassed C++ in popularity. [1] [2] [3] [4]

As a primarily C++ dev myself I wish that wasn't the case, but it is.

aside from a couple of legacy features that don't seem to be commonly used, it can be erased without needing transpilation

"If you ignore the parts that don't need transpilation, it doesn't need transpilation". Well yeah, sure.

But even there, erasing types is still a transpilation, just an error-prone version of it. It's still being run as Javascript at the end, whether you actually compile to Javascript or use a frankentranspilation instead.

[1] https://www.libhunt.com/index [2] https://www.itransition.com/developers/in-demand-programming... [3] https://eu.36kr.com/en/p/3549523189739394 [4] https://survey.stackoverflow.co/2025/technology

The Linux kernel isn't even a monopoly though.... FreeBSD, OpenBSD, heck even ReactOS are all things you can use and make better instead.

No one is forcing you to use Linux any more than anyone is forcing you to use Windows or macOS.

Typescript is an even better example. And there are some domain-specific languages that aren't meant to become popular general-purpose languages, but succeed in their niche through the help of transpilation to a general-purpose language.

No they weren't, in fact they were very surprised by the adoption from Python folks

I'm kind of surprised that the Go creators were surprised by this.

Like I know they didn't like C++, but Go is by no means a replacement for C++ despite whatever was said about "building a better C++/Java".

It took so long to pick up generics that Rust was already around and the logical next step for C++ developers by the time that happened. And that's only scratching the surface of why people choose C++.

On the other hand, having a more performant "simple" language that directly supports concurrency and lets you compile to native code without a ton of ceremony could be very helpful indeed if you're a Python dev who need to take an app to the next level without having to learn intricacies of C FFI or the GIL.

But it also stands to ask, why isn't the bridge being constantly targeted? What factors are weighing ukrainian decisionmaking to not simply strike the hell out of this bridge until it falls?

It's not as easy as it sounds to put the weight of ordnance required in the very tight windows that would be needed to actually cause more than cosmetic or minor damage to that bridge.

Ukraine did pull off a spectacularly successful operation to destroy a laden fuel truck while it was crossing the bridge (https://en.wikipedia.org/wiki/2022_Crimean_Bridge_explosion)... Russia repaired the damage within months and simply redirected fuel transport to other means.

Russia also has dedicated a large amount of air defense and EM jamming resources to protect the bridge, which increases the difficulty of pulling something off for Ukraine.

For a long time Ukraine didn't have the types of weapons that would be needed to even attempt it outside of saboteur types of actions. Now they have some precise ordnance like Storm Shadow but even these weapons are not destructive enough to take the bridge down except in large quantities, and those are quantities they seem to have decided are best put towards other targets.

Ukraine has recently seen substantial success in finding better weapons, with drones that can engage in "medium-range" scenarios to close off the so-called land bridge from Russia to Crimea. These weapons have also helped in degrading Russia's own defenses, but with this in mind Ukraine may feel it best to leave the Kerch bridge standing for now to allow Russian occupiers to flee across the bridge back to Russia, since Ukraine has the northern land route through occupied territories under much more effective fire control than at any point since 2022.

Where are the armored vehicles now in Ukraine?

A more appropriate question might be, where are the armored vehicles now in Russia?

And as it turns out, they have indeed started adding armor to transport craft, including trains: https://en.wikipedia.org/wiki/Russian_armoured_train_Yenisei

And despite Ukrainian strikes earlier, the Russian bridge over the Kerch strait remains standing and in use for some (not all) logistical supply from Russia to Crimea, and this is due in no small amount due to the amount of 'armoring' that is inherent to the design of a bridge that must cross a strait of that size.

It's a question of cost more than anything, the more expensive a transport means becomes to build, the more it makes sense to start including armor to force an attack on that transport to itself have to invest a lot more for success.

I still have my CD for Office 97 and (somewhere) SuSE Linux 7.2, but I can't honestly say I can continue to use those.

The way to get around that is either continually releasing feature upgrades with one-time payments, or paying for access to the software only while you need that access.

Both models have strengths, one is not inherently evil and the other inherently good.

It's easy to say app updates should be bundled into the one-time cost but even that needs to have a time bound on it. When software lasted 3 years that potentially made sense, but now the release velocity is so much higher that there would be an explosion in complexity to try to keep up with all "one-time" releases going back for years.

Even completely Free software packages struggle with the balance with how far back to claim prior releases are under maintenance (e.g. LTS is popular, but so are 'rolling releases'). That's because of the underlying economic complexity with the costs to maintain what has gone before vs. the cost to develop what will come next.

However, if my continued use of a specific version of your software has no continued cost to you

That's just it, it does carry a cost, at the least for security updates and allowing the application to continue to be installed on later OSe or key libraries.

That's why even open-source libraries that in actively being used will get forked if unmaintained too long, because there's always something to do to keep bitrot at bay.

Nintendo does it the right way. I'm not at all afraid to say I want more Mario, Samus, Fox McCloud, Fire Emblem avatars and the like.

But they don't simply do roster updates, they bring those characters and worlds into new experiences, and they're willing to sit on good games rather than push out yearly new releases with almost nothing different compared to the previous iteration.

And the stability these franchises gives them, allows them to continue to make new IPs that may themselves grow into future tentpoles. So it's not just that they squander those successes, they are often trying to innovate into new things.

C++ has std::reduce for that, which is std::accumulate except it's defined to operate without any specific ordering.

The original example isn't really using ranges except to emulate C++98 iterator work though.

The actual equivalent might be something closer to:

    inline double algorithm_call(std::span<double const> xs) noexcept {
        return std::accumulate(
            xs, 0.0,
            [](double acc, double volts) {
                auto mv  = calibrated_mv(volts);
                auto err = residual(mv);
                return weighted_square(err) + acc;
        });
    }

Even that is enough to make ranges useful in my mind, but in a codebase which has started to integrate some functional programming techniques, there are also applications for things like views and transforms.

This can make it easier to reason about iteration pipelines in ways you might already be familiar with from POSIX.

That all said, it's C++ so sometimes the error messages get a lot more 'interesting' than they would have with STL-style iterators, especially when mixed with constexpr expressions as you might do with std::format or fmt libs.

That's correct, with curbside pickup you drive to the store, pop open your trunk, and in principle someone from the store's staff is ready and waiting to verify your identity and then load your pre-staged shopping right into your trunk, and you drive off.

So you still have to go to the store but it can be an in-and-out if everything works.

"isn't fast" is basically how you'd sum up the U.S. military in a nutshell.

So much of what it is in the past 3 decades is coasting off its Cold War legacy.

Target lists for an Iran scenario should absolutely have been updated before use for combat, but if it turned out they had not been substantively reviewed ab initio in a decade, I'd absolutely believe it.

The worker-owned businesses that are more effective will do a better job of concentrating wealth though, as they don't have to pay investors back dividends or participate in stock buybacks.

Software in general is a field quite compatible with initial self-funding, in ways you can't say for other industries.

But even still, investors threw away gobs of money on clearly unsustainable businesses like NFTs, and capitalism in general is happy to sell people the rope they will use to hang capitalists, so it's not even impossible to find investors if you absolutely need them.

Pair the lack of ongoing payments to investors or lenders with the superior execution of worker-led organizations, and companies such as these should pretty clearly mop up their competitors saddled with non-value-added executive management and non-value-added investors.

That is, assuming these roles don't provide any value to companies.

If you're being told explicitly to consume tokens then leaving it running while you try to get real work done sounds value-added to me. "Don't worry boss, no one's beating our team on the token leaderboard this week..."

Nothing is stopping employees from banding together to create these obviously-superior businesses right now and eating the VCs' lunch. Right?

This is true of every market that has ever existed, and that's not stopped small players from finding niches.

No doubt, but the issue I think they keep running into is they don't understand how useful those "human tools" are, so they keep trying to replace the functions humans provide with AI, without realizing all the other functions that the humans also provided.

The NSA managed to deliberately insert a backdoor into elliptic-curve cryptography right under the noses of everyone capable of making elliptic-curve cryptography.

That sort of proves the opposite point, assuming you're referring to Dual EC DRBG, because the flaw was noticed very early on, by people who weren't even involved in its development.

I grew up poor and that was never an inducement to commit crime. I took plenty of "food I didn't want" off my friends' hands at lunch in middle and high school, but never even thought of crime.

Although my parents weren't rich they still tried to teach right from wrong, respect for others and all the rest.

And not to put too fine a point on it, but there's plenty of examples of rich assholes who act as if money makes them immune from justice.

Tons of the Navy's public websites still run on it.

Yes that's a thing too, but it's a question of cost and potential revenue. So if replacement hardware is really expensive then maybe you make the inefficient stuff hang out longer, as long as it's not broken and you have paying customers.

But at some point hardware does break and if you're going to keep the datacenter open for business you'll need to address turnover of inventory on an ongoing basis, and if you haven't locked in long-term deals for hardware then you'll have to bear current market prices when you do that.

thus replace their hardware constantly?

Yes? How else do you think it works? At scale, hardware breaks all the time and must therefore be replaced all the time.

This is true even at Hetzner's scale.