It’s a general Unix thing. It’s a general Linux thing. It specifically applies to the Linux kernel, and has been used recently (2.6.whatever) to defend choices about the wretched scheduler implementation.
Now, it’s nice that you can swap things in and out, which is what “mechanism” implies. (Obviously I’d rather not have to do this via the virtual fs of /proc, but still.)
But it’s evil and nasty and downright disastrous, from an architectural point of view, that you completely disregard policy.
This is how X came to acquire a dozen different widget sets, all disjoint from the others. (There are other X consequences: see Unix Hater’s Handbook for details.)
This is how Unix, in general, came up with not one, not two, but something like six or seven shells. Every one of them with completely unparseable languages. Which is just the start, really: try using a single common command on any of them (go on, I bet you can’t remember the ksh switches to ls).
This is how the Linux desktop ends up with not one but two major IDEs (OK there are more). This is how, when I come to look up a FOSS alternative for Visio — just basic, mind, I don’t care about the bloat — there is no such thing. Whatever I choose is closely bound to a mechanism, not a policy. And guess what? It’s a totally arbitrary mechanism that changes at random and is unsupported anywhere else.
MechanismNotPolicy™ sounds hifalutin’ and the cynosure of all CS Majors’ eyes, but I’m telling you, it’s not.
It’s a suppurating sore and it’s criminal neglect of responsibility and it just will never work.
Comments
And this is why PolicyKit and similar are all broken, conflict with each other and is a PITA to even look at they configuration, which is a sucky XML file full of nonsense.
What’s really funny is that Autodesk Maya, the 3D software, even has an ls command in their MEL language.
MEL (Maya Expression Language) is a shell language unto itself. Using switches as arguments and generally being unreadable since every switch has a short form.
So count that as the obscure 7th Unix shell.
...it should be noted that ls in Maya isn’t used for listing files, it’s used for listing objects in the scene/DAG. Much like ls for file systems, it does its job with marginal results.
<< This is how X came to acquire a dozen different widget sets, all disjoint from the others. (There are other X consequences: see Unix Hater’s Handbook for details.)>>
even more prominently, this is why X separates the GUI’s “look and feel” part (how to arrange /snap/layout windows in the gui in response to input events) from the “low level” part (primitive rendering + actual moving and resizing windows + mouse pointer drawing + more) and implements them in two concurrent processes (with the inherent overhead and protocol complesity this entails)
even worse, the fact this absurd and anachronistic separation has survived up to this day…
That separation sometimes makes sense, but only when used with a proper API. Instead of an API, they simply use a network protocol since they assumed everyone would be running these things on mainframes.
It’s actually more general than that. It’s an attitude fail.
“Here! We haven’t actually built anything you can use, but we’ve given you the unstable and ever-changing tool-set to build something that actually works.
“Making choices (policy) is far too difficult. That would take actual design.
“No, what we do is we translate one form of assembler into another form of assembler. That’s Mechanism! As long as you understand the documentation to the mechanism. Which is of course the code.
“But the code/mechanism is free!”
Basically what Slix (shame you can’t up-vote comments) and the Unix Hater’s Handbook pointed out about X.
I actually think Policy mandates the mechanism – not only are they inseparable, but the design decisions define the “engine” requirements.
You can’t simply provide a design-less engine and expect everyone to use it for whatever product.
You have to pre-design the engine so it will fit the needs of developers.
That pre-design is, of course, policy.
You must be signed in to leave comments.