OEM launchers often include annoying anti-features, like a screen you can't remove and that has the brand's voice assistant. They also tend to be slow, bad at search, and have all kinds of unnecessary phone-home functionality like sharing your location with their owners (austensibly to show the weather forecast).
Besides, I have a work phone and a private phone - different brands, same launcher.
DigiD is "the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller", and thus falls under paragraph 3(b), which excempts this data from the Right to erasure. In much the same way that the IRS won't delete your data if you tell them you're a sovereign citizen.
Weird. Seems to work for Airbus, Allianz, BASF, E.ON, Fresenius, LVMH Moët Hennessy Louis Vuitton (and its subsidiary Dior), SAP, Schneider Electric, TotalEnergies, Unibail-Rodamco-Westfield and Vonovia.
Of course, that's the existing pan-European SE which is a public company. Needs like a few sentences changed in the existing regulation to extend that to private companies. https://en.wikipedia.org/wiki/Societas_Europaea
This is very different. In a SE these are incorporated and sponsored by the member state. It is like each country making an equivalent copy of the same thing.
The EU-INC is EU designated without a sponsor, which is not permissible under EU law other than for the EU institutions themselves. This is one of the red lines for the design of the EU legally speaking
An SE is incorporated under EU law, and it has a headoffice registered in a member state - and that registration can be moved to another member state. Like GDPR, the relevant law is an EU "regulation" and not a directive. Directives need to be implemented in local laws, regulations apply directly (local laws may fill in details as long as they don't contradict or restrict the regulation, except of course where the regulation explicitely allows derogation).
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
What do you mean by "sponsored by the member state"? Can you point to the exact regulation, treaty or directive that imposes this requirement?
This is the basic Maastricht treaty. You cannot make EU law in France without France creating it not as EU law, but as French law. A SE or EU-INC would have to exist within this construct.
The only exception to a legal entity are the EU entities themselves which are supranational.
This is what most people don't understand with the EU, that there is a very specific process to create law and limitations on what it can do. It isn't like the US and the EU isn't a country. I may appreciate you might be European but even within Europe the detail with it is where it matters.
BTW this is extremely common in life insurance systems, where premiums (provisions, surrender values, etc.) depend on formulas applied to mortality tables; these data themselves are simply tables for people from 0 to 100 years of age, so many formulas end up with only 100 possible outputs and are precomputed. (or 200 for combined probabilities, or gender-specific ones)
In practice when I discuss retention requirements in my country (EU), the issue is the _maximum_ retention limit - after which data must be deleted. A minimum retention limit (e.g. business records for tax purposes) is almost never an issue. Systems that need soft-delete, bi-temporal state, etc. typically already have it, whereas actually deleting stuff is an afterthought.
I guess I'm saying the former is usually a functional requirement in the first place, and the latter is a non-functional (compliance) requirement.
This is one of those occasions where people are arguing semantics, and you're like "but -- I was there!"
My first cable modem did not have a NAT, nor did my first ADSL modem. You'd use "Internet Connection Sharing" on Windows 98 SE to share the internet connection on your LAN. And you'd get badly hacked, and then also install a firewall. Sygate had a firewall and NAT combined. (Or, you'd use linux - and also get badly hacked, but for different reasons.)
As a response, ISPs started to ship modems with built-in NATs. They did not start to ship what we now call routers (modem+NAT) because they wanted to encourage people to share their internet connections out of the goodness of their hearts. They'd prefer to sell more cablemodems, or dial-up. They started shipping (NATted!) routers because it saved them a lot of support calls from hacked (and disconnected) customers. Instead they got support calls about port-forwarding, so uPnP was the next hot feature.
Was NAT originally intended to be a firewall? No. Did it effectively protect many innocents? It did. Is it still needed as an additional layer of security-through-side-effects? Let's hope not.
The main thing about prolog isn't the algorithms. In fact, the actual depth-first search isn't even part of the standard.
The nice thing about prolog is that you write logical rules, and they can get used in whatever order and direction that is needed. By direction, I mean that if you define "a grandparent is the parent of a parent", you can now use that rule not just to evaluate whether one person is a parent (or to find all grandparents) but also to conclude that if you know someone is a grandparent, and they are the parent of some one, then that person is someone's parent. Ok, it can also do recursion, so if you define an ancestor as a parent or the parent of an ancestor it will recurse all the way up the family tree. Neat.
You could write some kind of runtime that takes c code and brute-forces its way from outputs to inputs, except that regular imperative code allows for all kinds of things that make this impossible (e.g. side-effects). So then, you'd be limited to some subset, essentially ending up with a domain specific language again, albeit with the same syntax as your regular code, rather than those silly :- symbols (although LISP looks much sillier than prolog IMHO).
What the article is getting at is that if you use some features specific to a language, it's hard to embed your code as a library in another language. But is it? I mean, DLLs don't need to be written in the same language, there's stuff like JNI, and famously there's stuff like pytorch and tensorflow that runs CUDA code from python.
>The nice thing about prolog is that you write logical rules, and they can get used in whatever order and direction that is needed.
This generalizes!
Prolog: declare relations. Engine figures out how to satisfy them. Bidirectional -- same rules answer "is X a grandparent?" and "find all grandparents."
LLMs do something similar but fuzzier. Declare intent. Model figures out how to satisfy it. No parse -> AST -> evaluate. Just: understand, act.
@tannhaeuser is right that Prolog's power comes from what the engine does -- variables that "range over potential values," WAM optimization, automatic pruning. You can't get that from a library bolted onto an imperative language. The execution model is different.
Same argument applies to LLMs. You can't library your way into semantic understanding. The model IS the execution model. Skills aren't code the LLM runs -- they're context that shapes how it thinks.
Prolog showed that declarative beats imperative for problems where you can formalize the rules. LLMs extend that to problems where you can't.
I've been playing with and testing this: Directories of YAML files as a world model -- The Sims meets TinyMUD -- with the LLM as the inference engine. Seven architectural extensions to Anthropic Skills. 50+ skills. 33 turns of a card game, 10 characters, one LLM call. No round trips. It just works.
> By direction, I mean that if you define "a grandparent is the parent of a parent", you can now use that rule not just to evaluate whether one person is a parent (or to find all grandparents) but also to conclude that if you know someone is a grandparent, and they are the parent of some one, then that person is someone's parent.
Debugging rarely works correctly between languages, and features like "find all references" usually break too. Maybe that's not an issue with Prolog because a C logic solver would also be hard to debug, but it's a problem with many template languages.
Thanks again for unsubscribing! This is your weekly reminder that you are still unsubscribed. As usual, we've included a little bonus for you to enjoy at the end of this unsubscribe-reminder e-mail: a complementary full edition of this week's newsletter!
reply