Ragnarork

They do really shine during the tumble especially.

Love how that adds a nice element of fun to an otherwise impressive project and writeup.

It is the ultimate cop-out to avoid having any involvement in anything. "AI said so..." then shrugs or more AI answers, ultimately removing oneself from any form of commitment to an opinion or knowledge (even partial).

In addition to the damages award, Rakoff entered a permanent worldwide injunction

Because apparently U.S. courts and judges can do that. The more this is ignored by third-parties outside of the U.S., the better.

I'm not against international cooperation regarding common rules (I'm rather for), but the current context certainly doesn't designate the U.S. as a responsible custodian/enforcer of such rules.

What's odd and strange about this? Author clearly specifies this at the start:

To summarise for yous there are three main issues for me and the last one happened today and is what pushed me through the threshold.

The compounding led to this, not that individual issues existed (and have been a problem) for a while.

nearly everyone has some niche thing they like, some 5% that isn't covered by the FOSS

I'm interested in where that estimate + number are coming from. And I'd like to point out that I don't nearly see as many people pushing back against say MacOS for "not being Windows", despite the fact that the same issue would be there. I wonder why Linux gets special treatment in that regards, when modern distros make usage very accessible.

And that doesn't even get into gaming.

Gaming on Linux works very well. And if something doesn't, it's usually by choice (e.g. BattleEye customers not enabling it on Linux) or by sheer incompetence / malevolence (e.g. EA Games and their shitty EA App that breaks often even on Windows, and even worse on Linux in a Wine environment).

Also, "perceived" or "real"?

This reasoning is flawed in my opinion, because at the end of the day, the software still has to be paid for (for the people that want/need to make a living out of it), and customers wallet are finite.

Our attention is also a finite resource (24h a day max). We already see how this has been the cause for the enshittificaton of large swathes of software like social media where grabbing the attention for a few seconds more drives the main innovation...

Then the statement "Stuff can't interoperate with c++" is true

Where is that statement? The statement I reacted to (and with some caveats) was the following: "Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++."

Which in my opinion is not true for the reason I mentioned.

Nothing from c++ ever gets exposed

Depends what's your definition for "getting exposed". If you mean "no C++ feature from the language gets exposed" then it's mostly true (you can still wrap certain things like allocators, though painful, but there's certain C++ features that have no real equivalent in some target languages indeed). But you can definitely expose the functionality of C++ code through a C interface.

Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics?

If the interface itself has or leaks those features, no that's not easy indeed. But if those do not leak, then they can be used internally yes.

My point was not that it's easy to wrap a currently existing C++ library that has modern features in its interface in a C interface, especially post-C++11.

But that if you design something from the ground up, then it's rather easy (with a certain set of constraints). My bad for not conveying that better.

You do lose the ability to use some features, that's true. Mostly RAII around the interface. You can still leverage it internally in the implementation, and if using context objects it would be even easier. The main pain point is if you want to let client of the library use their own allocators. It's still doable, but quite a pain.

Classes can be wrapped with a bit of effort. You do need to write the constructors and the destructors manually and invoke a pair of new/delete on the C side, but it's just as you would handle a type allocated by a C library itself. You'd use it the same way. You just have the liberty to have the implementation use (mostly) C++.

Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language.

Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface. I've done it multiple time throughout my career (that ended up being called from Python, Swift, Objective-C/C++, Swift, Java, and Kotlin).

And as a side note, you don't have to do object-oriented programming in C++ if you don't want to.

What happens when your values are strongly at odds with lying and being dishonest?

a high risk of being disrupted by those clients just using AI agents instead of paying $2-5000/day for a team of 20 barely-qualified new-grads in some far-off country

Is there any concrete evidence of that risk being high? That doesn't come from people whose job is to sell AI?

In a way, they really condensed perfectly a lot of what's silly currently around AI.

Codex, Opus, Gemini try to build Counter Strike

Even though the prompt mentions Counter Strike, it actually asks to build the basics of a generic FPS, and with a few iterations ends up with some sort of minecraft-looking generic FPS with code that would never make it to prod anywhere sane.

It's technically impressive. But functionally very dubious (and not at all anything remotely close to Counter-Strike besides "being an FPS").

Fitting.

This reminded me instantly of Every Frame a Painting's video "Vancouver never plays itself"[0].

[0] https://www.youtube.com/watch?v=ojm74VGsZBU

Gee, how hard is to find SE experts in that particular combination of available ops tools?

You find expert in Ops, not in tools. People that know the fundamentals, not just the buttons to push in "certain situations" without knowing what's really going on under the hood.

Well a big reason this is missed is people discussing it are not part of these groups and mainly saw this as an annoyance.

I can agree that heavy & strict CoCs can be daunting and probably overkill for small open source projects. And they're far from flawless, as shown by the Rust mods resignation incidents. But to say they're useless and anti-meritocratic is to forget (and/or silence) these people that wanted to contribute in an environment where they wouldn't feel threatened (incidentally, sometimes despite being skillful contributors, so much so for the supposed meritocracy of the CoC-less projects).

I'm not sure strict CoCs are the answers to these real problems, but this feels like dismissing these problems altogether.

If you don't like the scope of the license especially with regards to the legal jurisdiction it sits under, then don't use it, don't use software under EUPL license, and call it a day?

Junior devs eventually will have been brought up with agentic coding

But if they're not hired...?

The license used for this is quite a read.

  Available to the world except the European Union, the UK, and South Korea

  3. DISTRIBUTION.
  [...]
  c. You are encouraged to: (i) publish at least one technology introduction blogpost or one public statement expressing Your experience of using the Tencent HunyuanWorld-Voyager Works; and (ii) mark the products or services developed by using the Tencent HunyuanWorld-Voyager Works to indicate that the product/service is “Powered by Tencent Hunyuan”; [...]

Henriksen wrote in an op-ed earlier this year, might have been: The Country That Should Have Been Even Richer

What's wrong with not rabidly chasing bigger wealth? Why has this become totally unacceptable in this world?

This reeks of late stage capitalist views.

We are choosing a model that is uninspiring for capital investment

Sounds fantastic in my book.

I also like that sort of example:

His examples include $2.6 billion to develop a carbon-capture project whose commercial viability remains unclear

What if the goal was carbon capture and not commercial viability? What worth will be your commerce if we choke ourselves out on carbon dioxyde? That's also the concept of subsidiary and state funded stuff, it's not because it's not commercially viable that it's not useful.

I'm also unconvinced by quotes like "the country is suffering from the dutch disease" while Norway seems to have done what's indicated in such a case, through its sovereign fund. Another mitigation for that is to avoid letting in too many foreign investments in, to combat the currency appreciation that comes as a symptom of dutch disease... which this article presents as a bad situation.

Sure, the country might face a challenge as the oil wells dry up, and I'm not saying everything is fine (although I think a lot of countries would prefer to have that sort of issue).

I also think cost-efficiency should be a goal, and a responsibility of the state for state-funded projects and endeavours. I'm absolutely not absolving things like overblown costs and delays in big government led projects, this shouldn't be an excuse either (although the definition of "overblown" for delays may vary from person to person).

But his article looks more like people upset that Norway's money isn't going to them, rather than worrying about the fate of Norway itself.

Joke aside, is there a field (or sub-fields) of mathematics that just... studies what breaking some axioms would do and where would it lead? This seems both completely stupid but also potentially fascinating at the same time.

It's a 2.5D tower defense with inspiration from Into The Breach, but grounded in the real world around the topic of anti-air.

I've finally come around to set on a journey to develop my first game. It followed a read on Gamedev in 2025 that actually popped on HN a few months ago[0].

I've mostly scribbled notes on paper for now, trying to be exhaustive about all that before scoping MVP (maybe SLC[1] would be better but I'm first doing that for myself so I'm not really pressuring myself for now).

I'm using modern C++, and will probably start from SDL3, plus a couple other libraries, but nothing too big or framework-y beyond that.

[0] https://news.ycombinator.com/item?id=44038209 [1] https://longform.asmartbear.com/slc/

It's interesting also how these takes consistently ignore spectacularly the environmental cost of these as well.

I'm a bit on the fence myself, as I think it's very harmful, but I can also see ways it can be useful. But it's absolutely mindblowing how this is nearly always completely out of the discussion even though our current way of living and powering things is on a timer and we still haven't addressed it as a whole.

- There's a lot of allegations that they don't need VCs because they have backing from the USA army.

Citation needed. Strange allegations (and from whom?) when the pentagon itself has discouraged using Signal in an official capacity...[0]

[0]https://abcnews.go.com/Business/what-is-signal-messaging-enc...:

The Pentagon's internal watchdog criticized a former official's use of the Signal app in 2021, calling it a breach of the department's "records retention policies" and an unauthorized means of communicating sensitive information.

"Signal is not approved by the DoD as an authorized electronic messaging and voice-calling application," the report asserted, adding that "the use of Signal to discuss official DoD information does not comply with Freedom of Information Act requirements and DoD's records retention policies."

I can agree on the strawman but parent I responded to was mentioning "silly reasons" for not choosing a Rust implementation over a C one. A 5% performance difference in that space is anything but a silly reason.

Also glancing over the implementation of rav1d, it seems to have some C dependencies, but also unsafe code in some places. This to me makes banging the drum of memory safety - as it is often done whenever a Rust option is discussed, for obvious reasons since it's one of the main selling point of the language - a bit moot here.

$20K sounds very low for the effort and expertise that are demanded here in my opinion. It would be quite a steal to bring this to the same level as the state of the art (which, correct me if I'm wrong, but I believe is dav1d?) for only that sum.

I'm really surprised that a 5% performance degradation would lead people to choose C over Rust

I'm really surprised that because something is in Rust and not in C, it would lead people to ignore a 5% performance degradation.

Seriously... when you get something that's 5% faster especially in the video codec space, why would you dismiss it just because it's not in your favorite language... That does sound like a silly reason to dismiss a faster implementation.

The first part of your statement feels true, although that's... unverified and lacks actual backing up.

The second part of your statement is very debatable based on what safe means in this case, and whether it's an enormous benefit for a given situation.

There's plenty of stories [0][1] about Rust getting in the way and being very innappropriate for certain tasks and goals, and those "enormous benefits" can become "enormous roadblocks" in different perspectives and use cases.

In my personal and very subjective opinion I think Rust can be very good when applied to security applications, realtime with critical safety requirements (in some embedded scenarios for example), that sort of stuff. I think it really gets in the way too much in other scenarios with demanding rules and pattern that prevent from experimenting easily and exploring solutions quickly.

[0]https://barretts.club/posts/rust-for-the-engine/ [1]https://loglog.games/blog/leaving-rust-gamedev/