Flemish is more of a political construct than linguistic, it's a grouping of belgian-dutch the coastal, brabant and limburg language groups with each having their own regional dialects.
It's more than political. In speaking Flemish is to Dutch as UK English is to US English. In writing however there is no difference in spelling, but there is a difference in word choice.
Now, being from Belgium, even within that small part of the country where everybody is supposed to speak Dutch, I genuinely don't understand people from near the coast, which was about 150 miles from where I used to live.
Well yes, the dialects are very distinct linguistically, but what is often referred to as Flemish is the Dutch "tussentaal" aka "verkavelingsvlaams"[1]. That's not really a language per se, it's a regiolect of the official Dutch language, itself a Dutch variant of the Brabant dialects. The Flemish Dutch is usually used a lingua franca because the official Dutch otherwise sounds too formal (and native dialect speakers are foreign language speakers of Dutch). If I was to nominate a regional language for recognition it would more be the regional dialects like Brugs, Gents, Antwerps, Brussels Vloms, Hasselts, etc.
What I find interesting is that the differences in Flemish dialects make them much more distinct than what would normally call dialects. There are significant grammatical difference beyond the usual vocabulary differences. For instance, coastal Flemish conjugates yes and no[1], Limburgisch is a tonal language.
If ARM's memory tagging is a guide, not much for the general developer. You will be able to run with address sanitizers enabled at a much lower overhead. Perhaps, use some hardened allocators or library variants that rely on the extension.
My interpretation, going off on the linked integrated GC research: extensions to the ISA and thus compiler backend, no modifications to 'well formed' applications, some changes to the language runtime dealing with memory management.
Unless the CPU hardware becomes some kind of hybrid monster with both OMA and traditional paged MMU, you will need to make changes to the kernel. You may be able to emulate some of the kernel's page table shenanigans with the object-based system, but I don't think that the kernel's C code is typically 'well-formed'. It's probably a lot of engineering effort to make the necessary kernel changes, but so are all those complex kernel hardening efforts that hardware-level memory security like OMA would render moot.
Yep air-gapped security is a thing. But servicing, patching and communicating with air-gapped devices still needs to happen, which involves connecting to them somehow. Likely a manufacturing plant has started to connect everything together to streamline the process and created an attack surface that way.
You can see the appeal for not needing to go through all the issues, complexity and costs that entails.
reply