Whether it is the Incompatible Timesharing System from the early days at the MIT lab, Unix, or the Internet, it is clear that hackers encode and realize values through the making of various technologies. But this encoding is not always straightforward and it tends to embody a multiplicity of potentialities that get realized in sometimes conflicting modes.

As interesting is that geeks theorize this, and do so in a dialogically, enganged manner. The following 2 blog entries are by Debian developers and they are about Debian, Unix permissions, and the ways in which openness/opaquness foster different forms of access and possiblities. I don’t have time now to give any analysis but here they are:

From From Joey Hess’ Blog:

I could give many more examples of subsystems in Debian that exist at different point in the spectrum between locked down unix permissions and a wiki. There seems to be a definite pull toward moving away from unix permissions, once ways can be found to do so that are secure or that allow bad changes to be reverted (and blame properly assigned). Cases of moving in the other direction are rare (one case of this is the further locking down of the Debian archive server and BTS server after the server compromise last year).

Anyway, the point of this is that, if you survey the parts of dealing with the project where Debian developers feel most helpless and unempowered, the parts that are over and over again the subject of heated discussions and complaints, you will find that those are the parts of the project where unix permissions still hold sway. This can range from simple cases such as a cron job that only one person can look at and modify[1], to various data files that could perhaps be kept in svn, but aren’t, all the way through to stuff like the Debian keyring. I would love to see a full list developed, although many of the things that remain are obscure little corners like certian blacklists in the BTS, bits of the buildd infrastructure that only a half dozen people know about, etc.

And then a reply from former Debian release manager, Anthony Towns:

One interesting approach, to my mind, is worrying less about permissions and more about space – so that different people with different ideas on how to do things can do them independently. That’s part of the idea behind usertags and usercategories: rather than having people try to find an imperfect compromise, let them work on the same stuff in the way they actually prefer. That reduces the risk of carelessness, in that you stop having any reason to bother other people, and also reduces the problem of restrictions, in that if you don’t have permission to work in someone else’s area, you can just setup your own area and work there.

Perhaps the worst problem is if the drawbacks feed on each other: a restrictive system turns away contributions, which causes prospective contributors to get frustrated and hence careless, which then reinforces the reasons that the restrictions were put their in the first place and diminishes the chance they’ll be reconsidered. That’s a hard cycle to break, but it’s not one where anyone really wins.