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