As fhn points out, there are now truly open video codecs available (open specification, royalty free, unencumbered by patent terms) that are able to compete with the patent-encumbered ones on technical merit. Seems curious that the patent-holders would want to hike prices in this way and validate the motivation behind the truly open codecs.

Also, the article mentions the licensing fees for H265 were also increased recently. It doesn't seem to give a figure, a quick web search turns up 25% [0] or perhaps 20% [1]. Perhaps I'm missing something obvious but I'm not clear on how the change in price relates to the patent dispute between Nokia and certain laptop manufacturers.

(It seems the H264 fee increase affects streaming providers only, whereas the H265 fee increase did not, as it affected laptop manufacturers.)

[0] https://news.ycombinator.com/item?id=46004129

[1] https://news.ycombinator.com/item?id=46003285

Kotlin has explicit nullable types. Rust has no null, but has option types. Both languages work fine.

I think your point was that neither approach could reasonably be retrofitted to C++, do I have that right?

From a quick search, it seems HackerNews's own jcelerier has put together a C++ library for doing this. https://github.com/celtera/ahsohtoa

I wouldn't say so, most object-oriented languages don't work like Objective-C/Smalltalk. Today, I think most programmers would agree that inheritance is the defining feature of object-orientation.

The guidelines ask that you don't do this. From https://news.ycombinator.com/newsguidelines.html :

> Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.

In terms of solutions, the practice of 'preregistration' seems like a move in the right direction.

The replication crisis is largely particular to psychology, but I wonder about the scope of the don't rock the boat issue.

> The proposition that technological progress that increases the efficiency with which a resource is used tends to increase (rather than decrease) the rate of consumption of that resource.

See also Wikipedia: https://en.wikipedia.org/wiki/Jevons_paradox

Plenty of real programming languages are ambiguous in ways that surely disqualify them as formal specification languages. A trivial example in C: decrementing an unsigned int variable that holds 0. The subtraction is guaranteed to wrap around, but the value you get depends on the platform, per the C standard.

> There are plenty of formal specifications that cannot be compiled, even not by an AI. If you use AI, how do you make sure that the AI compiler compiles correctly?

By proving that the code satisfies the formal spec. Getting from a formal spec to a program (in an imperative programming language, say) can be broken down into several stages of 'refinement'. A snippet from [0] :

> properties that are proved at the abstract level are maintained through refinement, hence are guaranteed to be satisfied also by later refinements.

[0] https://www.southampton.ac.uk/~tsh2n14/publications/chapters...

Not really, on both counts.

Firstly they're not really programming languages in the usual sense, in that they don't describe the sequence of instructions that the computer must follow. Functional programming languages are considered 'declarative', but they're still explicit about the computational work to be done. A formal spec doesn't do this, it just expresses the intended constraints on the correspondence between input and output (very roughly speaking).

Secondly, regarding the we don't know how to compile it aspect: 'constraint programming' and SMT solvers essentially do this, although they're not a practical way to build most software.

Not really. There's a long history of seemingly credible closed-source codebases turning out to have concealed malicious functionality, such as smart TVs spying on user activity, or the 'dieselgate' scandal, or the Sony rootkit. This kind of thing is extremely rare in Free and Open Source software. The creators don't want to run the risk of someone stumbling across the plain-as-day source code of malicious functionality. Open source software also generally makes it easy to remove malicious functionality, or even to create an ongoing fork project for this purpose. (The VSCodium project does this, roughly speaking. [0])

Firefox's telemetry is one of the more high-profile examples of unwanted behaviour in Free and Open Source software, and that probably doesn't even really count as malware.

> If you're malicious, you can still release malicious software with an open-source cover (ideally without the source including the malicious part - but even then, you can coast just fine until someone comes along and actually checks said source).

I already acknowledged this is possible, you don't need to spell it out. Again I don't have hard numbers, but it seems to me that in practice this is quite rare compared to malicious closed-source software of the 'ordinary' kind.

A good example of this was SourceForge injecting adware into binaries. [1]

> Remember that the xz-utils backdoor was only discovered because they fucked up and caused a slowdown and not due to an unprompted audit.

Right, that was a supply chain attack. They seem to be increasingly common, unfortunately.

[0] https://vscodium.com/

[1] https://en.wikipedia.org/wiki/SourceForge#Installer_with_adw...

What you mean here? Businesses often implement their own core code, but they don't deliberately favour closed-source software.

I don't have hard numbers on this, but in my experience it's pretty rare for an open source codebase to contain malware. Few malicious actors are bold enough to publish the source of their malware. The exception that springs to mind is source-based supply chain attacks, such as publishing malicious Python code to Python's pip package-manager.

You have a valid point that a binary might not correspond to the supposed source code, but I think this is quite uncommon.

• Increased upfront software complexity

• Increased maintenance burden (to not break officially supported plugins/customizations)

• Increased support burden

• Possible security/regulatory/liability issues

• The company may want to deliberately block functionality that users want (e.g. data migration, integration with competing services, or removing ads and content recommendations)

> That was a genuine blocker for me because it prevented me from answering my question.

It's always been this way. From the user's point of view there has always been value in having access to the source, especially under the terms of a proper Free and Open Source licence.

This seems unlikely. It's not the norm today for closed-source software. Why would it be different tomorrow?