Computing notes 2025 part one

This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.

[file this blog page at: dig del.icio.us Technorati]

2025 February

20250222Domain, zone, realm ...

There are some computer engineering terms that are almost synonyms and are used somewhat interchangeably but can indicate quite different concept and here a list of some of them involving the words domain, zone, realm, ...

Term	Area	Description
Domain	generic	Usually indicates a collection of computers that share some configuration.
Domain	DNS	The name of a DNS RR (usually an IP address) that may have longer subdomains. By extension that domain and all subdomains. Such names are case independent and can only be made by a very narrow range of characters, unless they encode UNICODE.
Zone	DNS	A collection of domains configured in the same file sharing an SOA RR.
Domain	UNIX identifier mapping	A collection of UNIX systems with the same user name mapping in /etc/idmap.conf with the same map name. Such domains do not have a name usually except sometimes in NIS or idmap.conf.
Realm	Kerberos	A collection of Kerberos servers that share the same user names and user keys. Such names usually are upper case and often are the upper case version of the related DNS domain name.
Domain	MS-AD	A collection of computers registered with and using authentication and authorization servers that share the same configuration. The name of such a domain is usually lower case, but is case independent. Since MS-AD uses Kerberos the MS-AD domain is associated with a Kerberos real with a name that is the all-uppercase name of the MS-AD domain if that name is all lowercase. If there are any upper-case letters in the MS-AD domain name they are prefixed with an equal sign.

2025 March

20250323Directories for builds

There are many discussions about building software and many omit some of the possible locations:

• Source directory: where the inputs to the build process are.
• Build directory: where the intermediate files of the build process are produced.
• Install directory: where the outputs of the build process are copied to.
• Use directory: where the users expect the outputs of the the build process to be.

There are two distinctions that are not immediately obvious, and one of them is not commonly made:

• It is useful to have distinct source and build directories in part because this keeps the source directory unmodified giving more confidence in the build process, but often because the same sources need to be build in several different ways (for example with and without debugging options, for different targer architectures or compilers, ...).
• It is useful to have distinct install and use directories because storage of build outputs needs to be to a different place from where they will be used. For example some variants of the outputs are installed to an archive, or viceversa different sets of outputs are installed installed on different archives, but used at the same place; then one of the install locations is made available to the users using a different path (it could be filesystem mounting, soft-linking, package deployment, ...).

20250323MPICH layering

devices:

pamid

CH3

channels:

• ch3:sock
• ch3:nemesis
  • sysv
  • mmap
  • tcp
  • mx
  • ib
  • portals4
  • mxm
  • ofi

CH4

• shmmods:
  • posix
  • xpmem
  • cma
• netmods:
  • ch4:ucx
  • ch4:ofi:
    • sockets:
    • UDP:
    • tcp:
    • verbs:
    • :
    • :
    • :