Too Busy For Words - the PaulWay Blog

I realised, in bed last night, that there's a spectrum of control that runs from the immediate to the delayed and detached. The more detached we are from what we're trying to control, the more we have to specify exactly how we want the result to come out; the more interactive our control, the more we can fine-tune it on the spot to be how we want.

(This came out after having shown Kate the "How to shoot yourself in the foot in various programming languages" page, in particular noting the 370 JCL one: "You send your foot down to MIS and include a 400-page document explaining exactly how you want it to be shot. Three years later, your foot comes back deep-fried.", which relies less on the physical details of 370 JCL and more on the environment it was written in: old-style MIS bureaus where computers were attended by chanting acolytes and high priests in formal robes, and if you'd been really good you could even see a photo of a computer almost like the one you had in the sealed room doing work for someone else. Of course, now with everyone having a computer on their desks that leaves an IBM 370/135 for dead (240,000 bytes of memory! Count them!), you can interactively scale that graph to the size you want, rather than having to specify exactly how big every single element would be in a 4,000 page document. And that's where the realisation came from.)

One key thing, to my mind, is that Open Source has given us part of that interactivity. If you're a user with no programming ability, you have to specify how things should look and how things should work. If you have access to the source code and the programming ability to change it, all of a sudden you can interactively change the code to do what you want. The process of getting that algorithm to do the right thing, or the output to come out the way you like it, is suddenly much much faster.

And then because a lot of developers are on email lists, IRC channels and web forums, things can often be fixed much faster. Not only can the developers come to an agreement about how a thing should look quickly, but suddenly that forum post, email archive or channel log has become a 'standards document' that people can refer to at a later time. And, furthermore, they can communicate with the users much more quickly - the users have a slightly more 'interactive' experience in getting their particular bug fixed or feature implemented. With the closed business model that closed source is often associated with, the user has much less influence and a much longer delay before they see something being done; so they have to specify much more.

And, personally, I think specifications can lead developers down the wrong path. If there's something that doesn't quite make sense in the spec, then the smart developers have to go back to the client and get it cleared up; the dumb developers implement it in whatever way they think it should be done (or whatever way is easiest) and then the client inevitably says "No, that's not how we want it," and you have another round of specification-writing. Standards are good, and specifications are essential when you're wanting many people to work on a project (perhaps over a long period of time). But the more disconnected the end user is from whatever's being written, the more time is wasted writing specifications that only serve to insulate the programmer from any form of interactive decision-making, the longer it takes and the more it costs and the more lawsuits you end up with when things don't work quite as the user wishes.

(Users are a fickle bunch, too, and by the time a spec is implemented the user may have changed their mind. Which leaves the user with something that they don't want but agreed to pay for. Which is no solution at all, really.)

Look at Cricket or Tennis: umpires and linesmen and cameras and watchers all trying to make sure that the specifications don't get broken, and causing lots of upset and angst when the decision they make doesn't seem to be fair according to a different interpretation of the rules. Look at Ultimate Frisbee: no referees, and the players interactively agree about what's fair and not (inside the global specifications that govern all Ultimate Frisbee games everywhere.) Look at Calvinball: only one rule and lots of fun for its participants who interactively agree on how to play, but you can't write it down because codifying it is useless by definition. Is competition Cricket fun for its players or umpires? (Could someone even argue that they're not out there to have fun, they're being paid to do a job with their skills?)

Imagine a society like the Edenists in Peter Hamilton's "Night's Dawn" trilogy: people that have an inbuilt biological 'affinity' connection. They can 'telepathically' communicate with eachother, but they can also join a superconsciousness called Consensus that combines the thoughts and feelings of the entire population. If some new decision needs to be made, the society communicates interactively and comes to a consensus (hence the name) - some people might have a differing opinion about what the decision should be, but they are in the minority and can still see that the group knows their point of view and has chosen using all their intellects and feelings, rather than a small minority.

Now that's interactive!

I wrote my own SELinux policy file today!

Today I realised my CGI pages weren't coming up because the scripts weren't allowed to connect to, read and write the Postgres socket. (They also seem to require the ability to getattr and read the krb5.conf file, and I have absolutely no freaking clue why, because my code doesn't use Kerberos in any way). I'd done a bit of research and found the command:

grep <error messages> /var/log/messages | audit2allow

A bit of questioning on #selinux on irc.freenode.org revealed that if I did audit2allow -M <name>, I'd get a module with the name I gave, so that later I can identify what particular policy modules I've loaded into SELinux and what they do (rather than just 'local'). (They even have version numbers too!) The module .te file is a text file, so you can edit it. Including all the various permissions you want to set in one file means that when you compile and load it with:

checkmodule -m -M -o <name>.mod <name>.te
semodule_package -o <name>.pp -m <name>.mod
semodule -i <name>.pp

(which the audit2allow script will do all but the last automatically) then you can have all your policy revisions in one neat place, rather than grabbing each separate error, making a separate policy for, and then probably overwriting the last policy module you called 'local' or whatever.

Neat.

Now all I have to learn is how to create new SELinux types, so I can say "only these HTTP scripts are allowed to read and write to this directory". Then I will truly know what the hell I'm doing. Possibly.