NO MORE UPDATES TO THIS PAGE PLEASE. SUBMIT ALL FUTURE COMMENTS TO

6.1.1 pg 103

A location can also mix policies, if necessary. eg servers could be functional, whereas workstations could be themeatic or formulaic or whatever.

p. 104

In two examples on this page, hostnames consist of a word and a zero-padded number (pc0011, server05). I see the point you're making re: "sexy" low-digit numbers, but I'd actively discourage left-zero-padding in namespaces. It's nice to be able to iterate over a few hundred machines with a couple lines of shell.

-- BenjyFeen - 16 Sep 2006

p. 105 Note retro-stylee "telnet" under "Difficult-to-type Names". Also note that it'd be better to just disallow logins by anyone who shouldn't log in.

[ Tom's reply. Yes, but the true story was in the days of telnet, and the days when you couldn't disable some logins without disabling all. ]

-- BenjyFeen - 16 Sep 2006

Scope policy pg 109

In the context of DNS and subzones you have "They could even name their desktop PC's 'pc' followed by a number, and sites would have to coordinate between each other to ensure that no overlapping numbers are used."

Is that backwards? If each site had it's own subzone (isn't sub-domain a better term, anyway?) then they wouldn't need to coordinate at all; pc0011.siteA and pc0011.siteB are totally different.

[ Tom's reply: Wow, that is a typo. Fixed. Status: DONE ]

How Longevity affects Reuse

At my first job everyone was assigned an ID based on their name; the initial letters of lastname, firstname, middlename (or 'x' if not present) then a number which incremented as that letter combination was used. In a company fo 1000 employees we only had a few xxx2 type accounts; collision was less than I expected! So I was hsw1. That ID will never be assigned to anyone ever again; infiinite longevity and so no risk of ID reuse and so none of the problems mentioned on pg 111. We did have a problem with a Greek lady who would have been 'sex1'. She didn't quite understand why I was reluctant to assign that ID to her. That's the problem with any automated procedure!

-- StephenHarris - 11 Aug 2006

6.2.1 One Huge Database

An important aspect of the "one huge database" is to provide many varied read-only views on that data. It's nice having a huge corporate directory where each person has their manager listed, but providing that data as a structured feed means that other people can use your data to automate their stuff; eg the inventory managemant system could have an ownership field, and if the owner leaves the company (as indicated by the corporate directory) or changes job (cost center) then automated reports can be kicked off to initiate a transfer of ownership process. Security issues on a box can be reported to the owner, and his manager. And so on. Just providing a pretty web page with search engine is not sufficient; provide access to raw structured data.

-- StephenHarris - 13 Aug 2006