raising warning flag on firewalld-default feature
Przemek Klosowski
przemek.klosowski at nist.gov
Tue Nov 20 17:52:30 UTC 2012
On 11/17/2012 12:26 PM, Kevin Kofler wrote:
> Przemek Klosowski wrote:
>> Remember also that data is code: any config files could be seen as tiny
>> specialized interpreted languages, so it's not like you can avoid
>> interpretation anyway.
>
> That's a bad view of things, it leads to WTFs like PolicyKit using rules
> written in JavaScript. A simple key-value store is not and should not be
> Turing-complete, or even anywhere near Turing-complete. The logic needs to
> be in the native code, not in the configuration.
You say it yourself---if you need Turing, you have to put him in
somewhere. You argue that the complex logic HAS to go in the native
code, but that is inflexible. PolicyKit needed flexibility so they used
weird data; they combined inflexibility of native code with
inscrutability of complex logic in interpreted input. Plus they still
have a run-time and maintenance overhead of the interpreter, which they
were trying to avoid by designing a native code implementation.
Interpreters do not preclude simple data: they just scale better, from
simple linear declarative data to complex, Turing-cranking swamp. The
only argument against it is runtime overhead, which isn't a problem in
many, if not most, cases.
More information about the devel
mailing list