> OSS licensing. Free Software was designed to avoid this
This is pretty much a distinction without a difference. There are licences that qualify as one but not the other (per the FSF and OSI's determinations), but none are in widespread use.
> When you fork Free Software, your fork is also Free Software.
That would be copyleft. [0] Not all Free Software licences are copyleft licences.
The improved register count must make it much less claustrophobic for students. It's not just the same ISA but with wider words.
Looks like I'm mistaken on terminology though. x86 includes the 16-bit, 32-bit, and 64-bit ISAs of that family, and doesn't refer specifically to the 32-bit generation.
Seems unlikely, migrating away from an entrenched codec like H264 isn't like a routine software update. It has widespread hardware support, and there's an enormous body of H264 video out there.
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.)
Rust works fine because types are not required to have a default, if you want your type to have a default you implement Rust's Default trait. Stuff which only makes sense if there's a default just depends on that trait and so won't be available, for example you can't core::mem::take your custom Goose type which has no default because core::mem::take<T: Default>. In Rust if we say there's a variable of type Goose and don't initialize it, it's not initialized, and if the compiler can't see why it's initialized before it's used the program is rejected as nonsense because Rust is a safe language and that's an unsafe outcome.
I don't write Kotlin, so I can't speak to the details there.
C++ like Rust does not require that types have a default. In C++ the way you provide a "default" is usually via a zero argument constructor, since the compiler can just call that wherever you asked for an instance of that type and there's no requirement to write such a constructor, or indeed to provide any public constructor at all. So "just use the default" could not work in C++ as it exists today yes.
The other reason C++ can't do anything like this is that it makes a newer C++ with this behaviour behave differently despite no syntactical change. Rust is OK with that, because it has the Edition system to differentiate Rust 2015 code which means one thing from Rust 2024 code which means something else despite having the same text, but in C++ they do not have anything like that, it's not rare for somebody's C++ 17 code to get compiled in C++ 23 and people expect that to work (it doesn't always work but that's what they expect).
Isn't readability what matters here? Conciseness isn't the same thing.
reply