(Long) I'd like to see a Linux package manager co-operate with development

What provoked me to think about this

I recently went from using the Debian lenny version of Rosegarden to being a developer and using my development version. As transitions go, this was probably one of the easier ones. And overall, Debian is pretty clean about package management.

Yet it seemed to me that there were gratuitous obstacles. Most packages managers simply proceed as if versions that you build yourself do not exist:

• They cannot satisfy requirements. For instance, a year or so ago when I built a newer gEda than Debian lenny had, I had to remove a perfectly good installed copy of easyspice and build it manually, because aptitude (and dpkg) couldn't understand that I still had gEda.
• They cannot have requirements. For instance, Rosegarden wants jackd to be installed, but when I told aptitude to remove its copy of Rosegarden, it wanted to remove jackd too because it thought it was unused.
• They tend to be stepped on when installing, and by the same token "make install" often steps on installed packages. Package managers do usually take care not to erase things they don't own. But this is of the nature of first endangering the other software, then sparing it.
• Any config data that installed and built versions can share is purely accidental. The package manager thinks it controls all the config.

It's something I've noticed before, I'm just blogging about it for the first time.

An understandable choice

Now, this is all understandable. They don't call development versions "the bleeding edge" for nothing. If a package manager has to choose between blindly trusting locally built software and blindly ignoring it, it should ignore it.

And trying to make it all work together would raise problems of communication and coordination. How is a package manager supposed to know what it needs to know? And even if it knows, how is it supposed to coordinate with "make install"?

Does CheckInstall fix it?

Not for me. CheckInstall wants to watch "make install" and create a package (deb, RPM, others). The idea is that then you use that package to install and uninstall.

• Creating a package every time I "make install" is a very heavy mechanism. It's not really for developers, it's for small distributors.
• I'd forget to use it when I "make install", then what have I got?
• The way I work would confuse it. I typically configure to install into usr/local/stow. Which leads me to the next section.
• It's a roundabout way of doing things.

Stow could help

What Stow does

If you know about Stow, you probably should skip to Could a package manager work thru stow?

Stow is a Perl package by Bob Glickstein that helps install packages cleanly. More cleanly than you might think possible, if you're familiar with traditional installation. It works like this:

• You install the package entirely inside one directory, usually a subdirectory of usr/stow or usr/local/stow We'll say it's in usr/local/stow/foo-1.0 No part of it is in bin or usr/bin or usr/doc etc. Every file lives under usr/local/stow/foo-1.0

  With most builds you can arrange for "make install" to do this by passing ./configure an argument like

  --prefix=/usr/local/stow/foo-1.0/
  

• To complete the install, just:

  cd /usr/local/stow/ 
  stow foo-1.0
  

• That makes symlinks from usr/doc, usr/bin, etc into the stow/foo-1.0 directory tree. No file is physically moved or copied out of stow/foo-1.0
• Now the package is available just as if it had been installed.
• Want it gone? Just

  cd /usr/local/stow/ 
  stow -D foo-1.0
  

• Want it completely gone from your disk? After the above, you can just:

  rm -r foo-1.0
  

This is neat in every sense of the word. It also can manage multiple versions of a package neatly.

Could a package manager work thru stow?

Imagine a package manager that simply put each installation into an appropriate subdirectory of usr/stow and then stowed it. As far as I can know, this hasn't been done.

That would make it easier for installed and built versions to live side by side.

• Tracking a package's files is no longer an issue. They all live under a subdirectory and nothing else lives there (Oversimplification, but I'll get to that below). So stepping on built versions is no longer an issue. Neither is being stepped on by them. This also takes a lot of weight off the package manager.
• Whether a package is considered installed is no longer tied to the package manager. A package would be considered installed just if it is stowed and considered uninstalled otherwise.

  What about incomplete stowage, especially what if there's a race condition? A canonical flag could indicate when an (un)stow is in progress. I'm not aware whether stow does this; I've never seen it leave a stow half-done.

• The directory provides a place that developer, stow, and package manager can all see for installation-related information about the software.

Must it be stow?

Maybe you don't like Perl. I don't either, though I've coded in it and I do like CPAN and a fair bit of stuff that's written in Perl.

stow is not the only tool for this, it's just the first. There are a number of variants or offshoots: Graft, ln_local, Reflect, Sencap, Toast. They mostly seem to be in Perl as well. One exception is Reflect, which requires only bash and coreutils. Unfortunately, Reflect appears to be abandoned.

So the idea here is not so much an application as a file-location protocol. Another tool could do the same job on the same directory. You could even change tools later on.

General approach

It's easy for me to say "it uses stow", but that leaves a lot of little issues. I'll tackle them one by one below, but first I'll outline a general approach.

Desiderata:

• It needs to work safely even if interrupted. So all the relevant information needs to be stored in the filesystem.
• It shouldn't require any component to understand details that are not its own concern, following the general rule that components should do one thing well.
• If possible, it shouldn't require any component to do much more than it does now.
• It should place little or no extra constraint on development
  • Especially it should place no constraint on how to develop packages that one's package manager is not interested in.
• It should not make security holes.

File-naming scheme

So I will base this mostly on a file-naming scheme:

• A package named "FOO" relates uniquely to /usr/stow/FOO/
• The files of version N.N of a package FOO live under /usr/stow/FOO/N.N/
  • It's a slightly stronger version of the usual stow subdirectory naming practice. The difference from usual practice is just a level of subdirectory; it's FOO/N.N/ instead of FOO-N.N/
  • Almost no format is assumed for N.N, except that it can't start with a single colon.
  • I'm reserving double or more initial colons for situations where the version name wants to start with a colon.
• FOO-related files and directories that are not themselves installed ("Magic" files) live in /usr/stow/FOO/
  • Their names all start with a single colon.

Specifically unaffected so far:

• Most stow functionality.
• Most package manager functionality. It mostly needs to build paths accordingly.
• Naive local packages that live as usr/stow/FOO-N.N (no slash). They just are not understood as versions of FOO and thus receive no benefit.

stow2

I will talk about stow2, a hypothetical variant of stow. It's old stow with a few minor extra behaviors. It doesn't aim to be a package manager. It doesn't watch out for system coherence as a package manager does. In this vision, it's merely the part of the package manager that handles physically adding or removing a package. It just aims to do software-stowing for either a package manager, a developer or both without inviting problems.

Specific issues

What about shared config?

I mentioned sharing config above. Config shouldn't disappear or get overwritten when changing versions, or when changing how versions are managed.

So configuration data that should persist across versions will live under /usr/stow/FOO/:config/. It's stowed or unstowed just like a normal stow directory. There difference is in how it's used:

• It is meant to contain data that ought to remain unchanged across versions, such as user preferences.
• It initially contains very little. I am tempted to say nothing at all, but the case of config triggers makes me unsure.

Unaffected:

• Unaware packages will just operate on config data where they think it lives, which is where it's stowed from /usr/stow/FOO/:config/.
• Developers can treat config data for their builds by their own lights.
• stow2 can stow this like any other directory tree.
• Maybe package format, which would not need a separate space for config data if there isn't any.

Altered responsibility: A package manager should:

• When installing or updating
  • Create the FOO/:config/ directory if it doesn't already exist.
  • If it already exists, don't alter it.
  • In any case, arrange for the package to update the config data, eg to add settings for new flags.
• When told to remove a package's config data, unstow that directory before deleting it.

How the updating can be done is another issue, and this post is already long. I'll just say that I have a vision of farming off the (re)config control role entirely to make, at some stage higher than stow2, in such a way that developers and package managers can both use it.

What about config that consists of triggers?

For instance, what about scripts that live in /etc/init.d/? They are created when installing, but if the user removes them, they need to stay removed even when versions change. So they are shared config. Yet as scripts, they may freely change between versions. So they are not straightforwardly handled by stowing.

I'm not sure that what I'm about to propose will work with out-of-the-box tools, but I'll air it anyways:

• Let scripts be stowed from FOO/N.N into a dedicated directory that isn't otherwise used, maybe /etc/triggers/FOO/. The contents of the scripts can vary freely across versions.
• Let the triggers be symlinked into /etc/triggers/FOO/ from FOO:config

When scripts disappear between versions, it seems like it would leave dangling symlinks unless specifically removed. "make config" should handle removing obsolete ones, but it might not be perfect.

So one (possibly) new behavior is wanted: stow2 mustn't normally stow dangling symlinks, or at least ones into /etc/triggers/. (I'm not sure stow stows dangling symlinks even now)

What if a user unstows an installed package?

OK, everything works neat while the package manager is the only thing moving. But what happens when the user/developer starts using stow as it was meant to be used? He doesn't hurt anything by stowing new packages, but what happens when he unstows an installed package. . .:

• . . .and he doesn't replace it, because he thinks that doing so constitutes uninstalling it. Operating behind a package manager's back could greatly confuse it.

  Note that generally one needs to su in order to stow or unstow, so anything he can break this way he can break anyways. So we are only concerned about breakage by misunderstanding.

• . . .and he replaces it with another version, presumably one he built? If his new version is buggy, he may have broken not only this software but packages that depend on it. But that's the same problem we developers already face, and it's not amplified by this. How his new version works with the package manager's various controls is a separate topic, below.

I propose solving the unstow case by adding:

• New flag: Whether a given stow directory is under control of a package manager or not.
• New behavior:
  • Let stow2 refuse to unstow if that flag is set, unless forced.
  • If forced, inform the package manager.

So reserve the filename /usr/stow/FOO/:managed-by

• If it doesn't exist, that means no package manager considers FOO installed.
• If it exists, it is a symlink to a package manager that considers FOO installed.
  • I don't specify what part of the package manager. It might be useful to be a link to an executable.
  • A package-manager, as package itself, has to manage versions of where that symlink points
    • Maybe by pointing it towards an unchanging location.
    • Maybe by understanding previous installed versions of itself.
• When stow2 stows, it should create ../:managed-by pointing to itself.
• stow2 should refuse to unstow if ../:managed-by exists and doesn't point to itself, unless forced.
• (Stows that require unstowing another version are really the unstow case)
• If stow2 forces an unstow, it should erase ":managed-by".
• stow2 should support an filename argument that means "Act for this package manager".

What if a user stows a package?

I said "He doesn't hurt anything by stowing new packages". But we wanted more than harmlessness. We wanted locally built packages to be basically on the same footing as installed packages; at least, we want the user to be able to make that happen without real extra work.

But that invites us into a potentially complex system of dependencies and signing. Again, stow2 shouldn't have to concern itself with that but it also shouldn't make a mess.

For dependencies etc

For some concerns, we're just going to have to bite the bullet and say that the developer must talk to the package manager in its own format. Dependencies are one example.

Let's reserve the directories /FOO/:control for all package control data about FOO. Now, various package managers might have their own formats, and different dependencies etc might apply to different versions. So let's further reserve any file or directory /FOO/:control/PMNAME/N.N for a package manager named PMNAME with regard to package FOO version N.N. Here we can't do much about name clashes, but it's just between a few package managers.

Sometimes the same control data applies to many versions of the same package, up to version identity data. Particularly in development, the version might change frequently but the developer shouldn't have to create new control data each time. So let's reserve /FOO/:control-default and /FOO/:control-default/PMNAME.

So a conforming package manager PMNAME:

• Must recognize files of the form /FOO/:control/PMNAME/N.N and /FOO/:control-default/PMNAME even if FOO is not a package it knows about.
• Similarly, must recognize files of /FOO/:control-default/PMNAME
  • For them, find all FOO/N.N and consider each a version of FOO.
• Must treat all such package versions as available or installed, as appropriate.
  • Even where this requirement conflicts with security measures it uses for external packages, such as digital signing.
• May use its own internal control format, except insofar as it conflicts with other requirements. For instance:
  • The requirement to associate :control-default/PMNAME data with multiple versions, which might conflict with a "version" field in control data.
  • The requirement to treat such packages as available, which might conflict with digital signing.
• Is allowed but not required to distinguish such packages, for instance by:
  • presenting them differently
  • presenting their dependency chains differently
• Is recommended to provide a means in control data for indicating particular packages as unstable. Generally package managers already provide this.

But this still requires that the developer create control data in the package manager's format. Let's make it a little easier for him and require any package manager that has FOO-N.N to create /FOO/:control/PMNAME/N.N on request. Generally that's simple. Then the developer can adapt that instead of starting from scratch.

Digital signatures

A package manager generally guarantees package integrity by checking signatures. They are considered part of the control data.

We could require the developer to cause each "make install" to be signed. But this would not make /usr/stow/ even slightly more secure. Someone already put the code in question into it (usually by "sudo make install") Any misbehavior they wanted to do was already possible.

So I just say, trust the local versions. They belong there - or if somehow they don't, it's beyond what a package manager can provide security against.

The exception is if some user:

• Has write permission into /usr/stow/
• Does not have permission to stow
• Does have permission to run the package manager
• Can stow via the package manager. Perhaps it has the sticky bit, or he can sudo it but can't sudo stow.

So a package manager ought not to consider local versions installable by a user who can't directly run stow. It seems difficult for that situation can arise.

What about name collision?

What if two packages have the same name? That wasn't an issue when we assumed a package manager, which assumes a naming authority that can manage the namespace. And what about the flip side, if one package has two names at various times?

There's often no problem, but when there is, the developer has all the power to solve it. He can name his local stow subdirectories anything he pleases (directly or thru ./configure --prefix=). So it's up to the developer to manage the stow namespace in harmony with his favorite package manager.

Now, if more than one package manager is operating on the same system, there could namespace problems. But that wasn't even possible before, so nothing is lost.

What about bootstrapping?

How do you use stow2 if it's sitting in /usr/stow/stow2/1.1 unstowed? This is a solved problem: To bootstrap, call stow2 by its absolute path. Its support apps (Perl interpreter or w/e) also would be used by absolute path if they haven't been installed. That's all.

What about system bootstrapping?

Some Linux boot systems require some boot software such as the kernel to live in a small1 (<100 Mb) partition at the front of the hard disk. You can't symlink from /boot/ into /usr/stow/, but there's already a well-known solution. You make a stow directory there, eg /boot/stow/, and you put such software in it.

One would have to define a mapping that the package manager understands, and affected systems would have to be configured, and affected packages tagged, but for most packages and systems it's no work.

What about an unbuilt package having requirements?

So I solved most of the obstacles, including "they cannot satisfy requirements", but not "they cannot have requirements". There's a place for them in control data, but:

• It pertains to the wrong stage. Generally you need packages for the build stage, not after installation. If you as a developer only find you need some other package after installation, you just fetch it.
• At the time /FOO/:control/PMNAME/N.N is read, FOO/N.N doesn't exist and the package presumably isn't available thru the package manager. So it would be fruitless for a package manager to try to install FOO-N.N.
• It misses an opportunity to learn requirements from the configure stage.
• It misses a wider opportunity for other apps to communicate their needs to a package manager. For instance, as a simple way for an app to pull in optional support that's not bundled with it (hopefully only with user approval)

"BUILD" packages don't suit development requirements either.

This one is unrelated to anything stow2 should do. It is properly the domain of package managers as requirement managers. Here I suggest:

• A common file format for representing requirements, not particular to any package manager.
• A canonical flag to invoke a package manager with regard to such a file, like:

  aptitude2 --wanted autoconf2-201109212117-1.requirements
  

The format seems to require at least these fields:

• Name of requesting app
• Date requested
• List of desired packages, each giving:
  • Name
  • Version required
  • What exactly is wanted, eg app, static lib, dynamic lib, dev headers.

Because there is no one package manager in control, name collision and name splits are now an issue. In particular, virtual package names have little to go on.

One approach is to allow the package name to be represented in multiple ways, each with respect to some managed namespace. Like:

(("debian" "sawfish") ("redhat" "sawmill"))

Total requirements

So totalling up the requirements,

• A file-naming scheme, consisting of:
  • One or more STOW directories
    • Zero or more package names
      • Zero or more version names (each a directory tree)
      • :managed-by (a symlink)
      • :installed (a symlink)
      • :config (a directory tree)
      • :control
        • Zero or more package-manager names
          • Zero or more version names
      • :control-default
        • Zero or more package-manager names
      • :stowing (a symlink)
• A format for listing required packages, not specific to one project manager.
• stow2 must
  • Respect ../:managed-by wrt any directory it (un)stows from.
  • Impersonate a given package-manager, by filename argument, to ../:managed-by.
  • Otherwise behave like stow
• Package managers must
  • Respect /FOO/:managed-by
  • Recognize /FOO/:control-default/PMNAME
  • Recognize /FOO/:control/PMNAME/N.N
  • Create /FOO/:control/PMNAME/N.N on request
  • Obey a tag-to-stow-directory mapping, part of its own config.
  • Understand the above required packages format
  • Obey command-line flag --wanted
• A common means for developers and package managers alike to cause config updates. I suggest leaning on make.
• That's all.

Footnotes:

¹ I just called 100 Mb small. There was a time when we all called that "huge".

A prediction from PDM

A prediction from Parallel Dark Matter

Previously

Parallel Dark Matter is my (possibly entirely wrong) theory that dark matter is explained by 5 "parallel universes" that exchange only gravitational force with the visible universe. I presumptively call these parallel universes "branes" because they fit with braneworld cosmology.

Recent news and PDM

Recently astronomers found supermassive black holes growing in surprisingly small galaxies ¹.
If PDM is true, a black hole in one brane is a black hole in all 6 branes and is fed by all 6 branes. This suggests that in the other branes the associated galaxy is bigger, by two arguments:

• A "Where did the mass for the hole come from?" argument
• A regression-to-means argument across branes

A prediction and possible test of PDM

So if PDM is true, we should find that these galaxies have disproportionate dark matter. If this is not true, then PDM will simply be wrong.
Quantitatively, I'd expect the amount of dark matter to be nearly in line with the size of the black holes. Ie, we should find that:

1. The ratio of dark matter mass to black hole mass is nearly the same between these galaxies and massive early galaxies.
2. The ratio of dark matter mass to whole galaxy mass is not at all the same between these galaxies and massive early galaxies.

But I don't understand galaxy formation well enough, so I'll play it safe and merely predict that factor (1) is more predictive of amount of dark matter than factor (2) is.
I'd also predict that, if it be established in the future that some otherwise similar galaxies have no central massive black hole, those galaxies will not have as much dark matter as these will (in ratio to galactic mass). No quantitative prediction here, just "less".

Possible confounding factors

Galaxies tend to be smaller the further back you go. As I read the article, these particular galaxies are even much smaller than the norm back then. If I misread that, then ignore this post.
These galaxies are about 10 billion years old, so the universe was about 1/4 its current age. If it were much younger, the parallel galaxies probably wouldn't have had time to form or to grow very big, and the above logic wouldn't hold (But then we'd barely be seeing visible galaxies either). AIUI 10 billion years ago is old enough.

Footnotes:

¹ University of California - Santa Cruz (2011, September 16). Small distant galaxies host supermassive black holes, astronomers find. ScienceDaily. Retrieved September 17, 2011, from http://www.sciencedaily.com/releases/2011/09/110915131601.htm

Could backquote be adapted sensibly for Kernel?

Backquote vs Kernel

If you look at Kernel source, you'll quickly see constructions that a Lisper or Schemer would immediately use backquote for, like:

(eval ($if (null?/1 bindings)
           (list* $let () body)
           (list $let
                 (list (car bindings))
                 (list* $let* (cdr bindings) body)))
      env)

Quote and backquote are discouraged in Kernel. They tend to detach symbols from the environments they pertain to. They're not needed much, because in Kernel it's usually not neccessary to pass bare symbols around unevaluated.

But backquote is a lot more convenient than managing tree structure manually. It's more WYSIWYG. It lets you read and write something like:

(eval ($if (null?/1 bindings)
         ($` $let () . body)
         ($` $let
            (#unquote(car bindings))
            ($let* (cdr bindings) . body)))
   env)

Can we have it both ways? Yes.

Is it possible to have a variation of backquote that only exposes the sort of things manual list construction exposes, forms that don't naturally include symbols?

Yes. For instance, one could construct a form as traditional backquote does and evaluate that form in the current environment, without exposing the quoted form. The result would usually be evaluated a second time.

That gives the right result, but some pieces of the sexp get evaluated early (the low-quoted pieces), some get evaluated late (but still internally). It works but it seems dodgy.

With an equivalent result, one could say that backquote internally builds a form that, when evalled, recovers the original structure of the tree, except that low-quoted pieces are copied literally. Then it evals that form. In this formulation, there are no new quoted parts even internally, and all evaluation wrt the current environment happens in the final stage of backquote.

Any new machinery needed? Not much.

The backquote itself can be just an operative. The existing primitives supply enough functionality. The one piece of new language machinery needed is a means to introduce the low quote without causing special cases.

This rules out using a combiner, because backquote doesn't ordinarily evaluate combiners until it has settled the form structure, and low quote must be seen before that.

So low quote needs to be something that backquote understands particularly, which implies a unique object defined with backquote. But we can't convey this object by the usual means of binding it and writing its symbol. The logic is similar to the above: We'd need to use it before we evalled it and found it was special.

So we need a special way to read this object, thus the "#unquote" above. And that's about it.

Are the stances really in that order?

Previously

I'm basically continuing this from comments that John Shutt and I exchanged on The Obligational Stance. He questions whether the stances are really in that order or even in that topology.

My answer (Repeating myself from a comment)

I'm not sure I have a compelling argument that the hierarchy is in that order, or in that topology. But my thinking, albeit somewhat loose, is "How could stance N+1 mean anything if the machinery for stance N wasn't already in place?", for each of the 3 cases.

In the case of N = intentional, how could an entity see obligations if it didn't have beliefs about the world?

Trying for a counterexample

Would (say) an ATM be a counterexample? As a machine, it naturally fits the design stance and does not naturally fit the intentional stance. Yet it's "obligated" to give you your money on demand, and generally does so.

But is it really seeing an obligation? ISTM no, not any more than it has beliefs when it prints out in English "Your bank balance is X". Its designers have the beliefs and see the obligations. The ATM is competent to realize the designers' beliefs and obligations schematically, but is not competent to treat them qua beliefs and obligations. For instance, it's not capable of improvising with them or of extending them to new situations.

One can try to stretch the stances to cover it. It, like a thermostat, has tiny, rickety, mini-beliefs and mini-sees obligations in a tiny, rickety way. Can it mini-see obligations without having mini-beliefs? My intuition says no.

Addenda to Where the Obligational Stance might lead

Previously

I wrote about The Obligational Stance, which I earlier called The Ethical Stance, and I suggested that it might give us tools to reason about ethics without deriving an "ought" from an "is".

Argument From Conflict

Now ISTM that the Argument From Ramifications Of Who/Whom is more particular than it needs to be, and A need not be a set. The first three lines could be replaced by something like:

Given ethos E where:

• there exists obligational entity A
• E requires negative obligations (or fails to require positive obligations) wrt A.

and the rest of the argument scheme is basically unchanged, except that A is an individual, not a set. That scheme would be the Argument From Conflict. The Argument From Ramifications Of Who/Whom would be a subtype of it.

Clarification

From the last post, one might get the impression that the Obligational Stance is about the ethoi that all the moral shouting is about. But I intend it to apply more broadly. It's about entities that see obligations, be the obligations petty or grand.

Where the Obligational Stance might lead

Where the Obligational Stance might lead

I've been writing about The Obligational Stance, which I earlier called The Ethical Stance. I'm writing this post to explain why I'm doing that.

It's a truism in philosophy that you can't derive an "ought" from an "is". In other words, any valid argument whose conclusion is a moral statement also has a moral statement somewhere among its premises. No valid argument starts from just observations and math and arrives at a moral conclusion.

I don't expect to derive "ought" from "is" either, but I hope to sketch some lines along which arguments could proceed from "is" to lesser normative conclusions. Such normative conclusions could not rise to the level of an objective "ought", but they might still be persuasive.

Comparing ethoi

I have (I hope) already described ethoi in a way that persuades you that they are as real as beliefs, yet a way that does not rest on any moral axioms. Borrowing one of Dennett's favorite idioms, I'd say that Martians who shared nothing of our ethics could be honestly shown that obligational entities are real and are really obligational.

The way I defined ethoi implies there can be many of them. Infinitely many, in fact. However, that doesn't entirely prevent us from making comparative arguments.

Argument from simplicity

One of the basic arguments, I expect, will be that of two given ethoi, one is favored above the other because the structure that defines it is simpler than the other's. It an ethical analog of Occam's Razor: less required information = higher probability.

That's all well and good, and leaves some sort of Nihilism looking like the simplest, best ethos. But just as with Occam's Razor, theories are constrained by facts. They must be "as simple as possible but no simpler".

Argument from brokenness

Another basic argument, I think, will draw on the concept of "broken" entities in the stances. Just as we wouldn't want to credit a belief that could only be held by could only be held by the ignorant or the foolish, we may not want to credit an ethic that could only be held by "broken" obligational entities.

And of course "brokenness" is contingent on any number of facts in the real world. In a hypothetical world where Thomas Jefferson had discovered Newtonian Mechanics, those who believed so would not be ignorant and those who thought otherwise would be. Similarly, an obligational entity who (say) demands a service that he really paid for and was promised is probably healther as an obligational entity than one who sincerely demands a service that really did not.1

That's an intentional-level contingency. Could there be obligational level contingencies too? I think so; we might also suspect the health of an obligational entity who very strongly demands a service that was paid for at an extremely cheap rate. I don't want to go too far with this sort of example, to avoid introducing my own "oughts".

Argument from brokenness is a whole can of worms, of course. Many are the partisan arguments where one side calls the other side ethically broken - or ignorant and foolish for that matter. An ugly sight, but also one that makes me think I am on the right track. This line of argument wouldn't have the psychological power that it does, be it ever so often abused, if it was entirely invalid.

Two arguments from lower stances

At this point, I'd expect certain concepts from the lower stances to play a role in arguments about ethoi. Truth, from the intentional stance; a healthy intentional entity seeks true beliefs and too many false beliefs makes for a broken intentional entity. Harm and benefit, which I suppose come from the design stance, on similar grounds.

ISTM obligational propositions are often about truth, harm, and benefit. I think this situation provides many facts that our ethical Occam's Razor could operate on.

Seperately but relatedly, there could be an argument like this:

• Assumed as fact: Ethos E's propositions also stipulate certain propositions P that relate to a lower stance.
• Assumed as fact: P is badly wrong.
  • More rigorously, any embodiment of the respective type of platonic entity for the lower stance, where that embodiment includes all of P, is flawed in this world. It's misaligned with the real world well beyond an "everybody makes mistakes" level.
• So any would-be embodiment of E in the world is neccessarily broken at the lower level.
• By our earlier thinking, this breakage at the lower level implies indeterminacy at higher levels.
• So there can be no real embodiment of E in this world.
• Conclusion: E is unacceptable.

Argument from ramifications of who/whom

I said that ethoi are platonic, probably not countable, and vary across a dimensional space which is difficult to even characterize. But while ethoi are platonic, their embodiments are real and countable, and skewed in interesting ways.

In the real world, ISTM one very revealing characteristic of an ethos is the interaction of identity and obligations. Particularly when it takes the form of different rules for different entities.

In a mild form, it's unavoidable. No viable ethos could give truly equal weight to insects and people. It's more usual to completely ignore insects obligationally.

Now, that by itself doesn't demonstrate anything normative about any ethos. We need further argument for that. Our actual argument might go something like:

• Assumed as fact: By ethos E's precepts, a set of entities A and set B are owed differently as a function of their relative identities.
  • Real careful with the qualifier here. It's not a function of their identities if the same outcome can be found without reference to their identities - unless the substitute input is really a proxy for identity. Common sense needs to be used.
• By lower level stances, this differential is unfavorable to A. Perhaps ethos E considers it OK to lie to or harm members of A but not B.
• Assumed as fact: Members of A are obligational entities, and not markedly inferior as obligational entities to B or to embodiments of E.
  • If we didn't have the "not markedly inferior" qualifier, we'd risk reading marginal obligational entities such as insects as appropriate A's for this argument. Apart from the intuitive objection wrt insects, ISTM admitting marginal cases of obligational entity undercuts the argument; they're not "really" the sort of thing the argument needs them to be.
• Consider the set of all ethoi that a member of A, an obligational entity, might embody. Ie, we're quantifying over all members of A and then over all suitable ethoi. Understand this quantification as generic ("mostly universal") rather than strictly universal.
• (For conciseness, in what remains I will speak of a single member of A and a possible ethos F that he could embody. So understand the rest as being inside the scope of the two quantifiers)
• By excluded middle, either E and F can be satisfied simultaneously wrt A or they can't be.
  • As an example of unsatisfiability, A might hold that certain agents are obligated to treat him as well as they treat Bs, or that they have certain absolute obligations wrt him.
  • I'm not treating fuzzy intermediate values rigorously. ISTM in fuzzy cases we can just visit both following branches of this argument.
• If E and F cannot both be satisfied simultaneously, the neccessary gives us grounds in this branch for disfavoring E. So E's acceptability stands or falls on the strength of the other branch.
  • I haven't made this part of the argument rigorous but I'm pretty sure it works.
  • It stands or falls on the strength of the other branch even if in fact all members of A subscribe to ethoi that conflict with E.
• If E and F can both be satisfied simultaneously, then we can try to raise one of the earlier arguments:
  • Maybe F needs to have a lot of special rules.
  • Maybe whatever embodies F must be broken at another level.
  • Maybe assertions that E makes supporting the distinction between As and Bs have problems wrt lower stances. For example, maybe the assertions are lies.

Conclusion

So ISTM the Obligational Stance gives us a tool to reason about ethics without deriving an "ought" from an "is".

Footnotes:

¹ I realize this runs the risk of appearing to introduce my own ethics. It's just an example, not a premise.

The . . . Obligational Stance?

The Obligational Stance?

I blogged about what I called "The Ethical Stance". I'm having second thoughts about the name. Already it's been a tad misleading. It's supposed to be in the same general topic area as ethics, and I hope it will lead to some interesting meta-ethics, but it's not supposed to itself be ethics. Rather, it's about perceiving obligations qua obligations.

I did try other names before "The Ethical Stance":

• "The moral stance" - even worse
• "The obligatory stance" - Suggests something very different.
• "The obliging stance" - Again, suggests something very different.
• "The obliged stance" - And again.

So I went back and tried harder and came up with "The Obligational Stance" which applies to "Obligational Entities"¹

"Obligational" has two existing definitions, neither of which exactly fit. But they are not grossly misleading and they are not so common as to create a significant false impression.

• "relating or constituting or qualified to create a legal or financial obligation" - the
• Synonym for "obligatory" - but there's a perfectly good word for "obligatory".

I'm keeping "ethos" and "ethic", though.

New chart

Name	Associated	Part of	What to apply	Something that a
	platonic type	P. type	the stance to	nonbroken one does
Physical stance	N/A	N/A	any physical thing	exists
Design stance	design	requirement?	artifacts and life	performs function X
Intentional Stance	mindset	belief	intentional entities	knows X / wants X
Obligational stance	ethos	ethic	obligational entities	sees obligation X

An example

Consider a father, a normal, decent guy, during the height of the Cabbage Patch Doll craze in the 80's, who has promised his child a Cabbage Patch Doll for Christmas thinking it would cost maybe $20. Christmas draws near and he finds that a doll is going to cost - I don't remember exactly what the prices were, but something utterly out of line. Let's say $300.

Being not crazy, he doesn't dip into the emergency fund to buy the doll. Instead he buys his child a more sensible gift and resigns himself to explaining that, promise or no, there will be no cabbage patch doll.

Is that father unethical? I don't think so. Speaking just for myself, I'd think worse of him if he did the opposite.

But did he break an obligation? Of course. The father is (being a normal decent guy as we said) a healthy obligational entity. His promise creates, in his own eyes, an obligation. And he sees it as an obligation, as something that ordinarily should be done. That all follows from "he's normal".

A subtle point: The obligational stance doesn't say "an obligation should be done". It says that it appears to an obligational entity that the apparent obligations that it sees should be done. The "should" is in the entity, not the stance. If it were otherwise, I'd be in the position of deriving an "ought" from an "is".

That's why I'm keeping the terminology "ethos" and "ethic". Viewed from the POV of an obligational entity, they do say "ought", but we can view them from outside.

Back to the parent without the doll. Let's use him to exorcise another potential red herring, the idea that "by definition, obligational entity keep obligations".

Being a healthy obligational entity didn't make him keep the obligation. He weighed it against other desiderata and chose not to keep it. Nor would that act, in the normal course of events, "break" him as an obligational entity. Being (as we said) normal and decent, he wouldn't start ignoring all his other obligations, or all his promises to his child. It won't even make him fail to see the broken obligation; he may try to make it up to the child in some way.

Easy to accidentally call obligations objective

It's easy for me to slip up and talk about obligations as if they were objective things in the world. I find myself writing things like "the obligations that it sees" and "the promise created an obligation". When I slip like that, I mislead. Obligations are only visible when viewed thru the POV of an obligational entity, just like beliefs are only visible when viewed thru the POV of an intentional entity.

Another red herring exorcised

All my talk about the father and his promise may have created another misleading impression: That these obligations are obligations-by-self.

The obligational stance contemplates no restrictions on the agent or patient of obligations. An obligational entity can see itself as owed something, and it can see obligations between others.

Footnotes:

¹ Or "Obligational Systems" when I feel the need to emphasize that we're systems if you look closely enough. Dennett always talks of systems, but I think that mixing "ethicXX" and "system" in the same sentence risks creating the impression that the systems I'm talking about are ethoi ("ethical systems") to tell people what they should do, which is very false.

The Ethical Stance

The Ethical Stance

I recently read and reviewed Daniel Dennett's The Intentional Stance.

He defines three levels of analysis:

1. The physical stance. All things are made up of physical material (atoms and molecules, usually) and obey physical laws. This applies to anything.
2. The design stance. Some things behave as though selected for a particular purpose. This stance applies to artifacts and creatures - things that are selected, whether by "real" designers or blindly by evolution.
3. The Intentional Stance. Some things behave as if they held beliefs and goals. This stance applies to intentional systems (basically, intelligent living things).

This got me thinking. What if there are further continuations of this pattern? What might the next layer be?

I've already given away the answer in my title. So I'll just jump in and start explaining it.

1. The ethical stance. This stance applies to moral systems. A moral system M behaves as if someone (not neccessarily M) is obliged to (not) engage in certain behaviors.

Some parallels

Some parallels between the stances other than the physical stance:

• The stances are about predicting the behavior of specific physical entities as "black boxes", ie without reference to the specific physical (or lower-stance) mechanisms that make them behave thus.
• In cases where they apply, higher stances are expected to predict behavior more efficiently, from less input and less computation, than lower ones.
• However, they are expected to predict behavior less reliably, though still fairly well.
• They are not expected to apply to "broken" systems, which must be understood by lower stances, by the physical stance as a last resort.
• One can relate each stance to a specific type of platonic entity:
  • A design
  • A set of beliefs
  • An ethos
• Those platonic types have very many instances (platonic entities), across very many dimensions of difference, and it's difficult to even characterize that dimensional space. Nor can one always point to discrete platonic individuals - sometimes there's a continuum. But for simplicity I will talk about platonic entities.
• One can kind of associate a given physical entity with a given platonic entity, but always with reservations. With similar reservations, one can associate it in part:
  • That a design satisfies a particular requirement (among others)
  • That a believer holds a particular belief (among other beliefs)
  • That a moral actor holds to a particular ethic (among other ethics)
• It is equivalent to say (always with the reservations) that:
  • A given physical thing and a given platonic entity have such an association.
  • A given thing is an {artifact or creature, intentional system, moral system}.
  • A {design, ethos, mindset} is embodied in a given thing.
• That association is not absolute. If you look hard enough, you can find:
  • Ambiguity about which platonic entity a given thing embodies. At high magnification, as it were, the association is to a fuzzy dot rather than a crisp point.
  • Similarly, ambiguity about the boundaries of the physical thing. "Extended phenotype", for instance.
  • "Mistakes", where natural implications of the association accidentally fail.
  • "Insufficiencies" where far-removed implications of the association systematically fail. For example, you're rational and you know the basic axioms of arithmetic (the Peano Axioms), and they neccessarily imply the answer to the Goldbach conjecture, so is the Goldbach conjecture true?
  • Misrepresentations, where explicit claims more-or-less by the entity itself are unreliable or wrong. Moreso for the higher stances.
• That association uses structure from the immediately previous stance. When lower layer associations break, the higher layer associations tend to become indeterminate (much more indeterminate than usual, anyways)
• That association doesn't need to be explicit or conscious. It can be tacit.
• An embodiment operates with regard to entities (and structures, operations, and properties) interpreted at its own level. With only two previous data points, I'm not sure how this goes, but I think it's something like:
  • Functions (of artifacts or creatures) are about expected entities (which may be historical phantoms)
  • Beliefs are about wrt notional entities
  • Ethics (viewed by moral agents) are about (notional) entities that (again notionally) have or are owed obligations. (This I'm least sure about)
• The notional entities (etc) are nevertheless generally bound to things in the real world, especially in healthy systems.

A chart of parallel parts between the stances:

Name	Associated	Part of	What to apply	Something that a
	platonic type	P. type	the stance to	nonbroken one does
Physical stance	N/A	N/A	any physical thing	exists
Design stance	design	requirement?	artifacts and life	performs X
Intentional Stance	mindset	belief	intentional systems	knows X
Ethical stance	ethos	ethic	moral systems	sees obligation X

Shouldn't "value" and "harm" and "benefit" play a part?

That was my first impulse. Of course value and benefit and harm interact with the ethical stance.

But "values" is already captured by lower stances. To define the ethical stance in terms of valuing, "behaves as if _ values X", would have been a mistake. It would risk capturing quirky personal preferences that have no ethical relevance. It also strains on situations where a moral agent has views about a distant occurence that can't ever affect him.

Much more to be said

There's much more to be said, but I've already spent a lot of time writing this up, so I'm going to stop now.

Daniel Dennett's The Intentional Stance

The Intentional Stance

I recently finished reading Daniel Dennett's The Intentional Stance. It is more or less a collection of his early articles about the intentional stance, with some editing for cohesion.

It's a pretty slow read; just 350 pages but his prose requires careful attention. I found it worth the time. He actually explains the main idea in the first few pages. Dennett has never been one of those philosophers who talks for a dozen chapters before he gets to his real ideas.

Roughly speaking, he defines three levels of analysis:

• The physical stance. All things are made up of physical material (atoms and molecules, usually) and obey physical laws. This applies to anything.
• The design stance. Some things behave as though selected for a particular purpose. This applies to artifacts and products of evolution - things that are designed, whether by "real" designers or blindly by evolution.
• The Intentional Stance. Some things behave as if they held beliefs and goals. This stance applies to intelligent living things.

He then defends why stances other than the physical should even be needed or useful. Roughly, because they predict so well from sparse data.

Dennett gives the example that, given the phone call "Honey, could you pick up a gallon of milk on the way home?", we can predict a very high likelihood that some ten or twenty minutes later, the man on the phone will drive a car into the driveway and enter the house carrying a gallon of milk (with some assumptions by context, eg assuming they have a driveway). A "martian" who uses exclusively the physical stance might make the same prediction by number-crunching through an overwhelming deluge of physical data, laboriously calculating the non-collision of the man's vehicle with other vehicles at intersections and so forth. But obviously the martian is doing it the hard way.

On mistakes

In "Making Sense Of Ourselves" and "When Frogs (and others) Make Mistakes", he considers the intentional stance when agents make mistakes. By which he means acknowledged mental failures, like a boy who sells lemonade for $0.12 giving a customer $0.11 change for a quarter. He didn't think that 11 + 12 = 25 and he wasn't trying to steal $0.02, he just made a mistake.

Dennett finds, roughly, that mistakes are gaps in the applicability of the intentional stance, much like the design stance will fail to predict when a broken alarm clock will ring. And he find that the intentional stance remains viable nonetheless, just as the design stance remains useful even if some alarm clocks do break.

Interesting quote on a side-topic:

[Quine] has been unable to give a detailed and realistic example, not because his thesis is false but because it postulates the possibility of a case poised on a knife-edge - two [possibilities] such that all the available relevant information fails to favor one over the other. The actual world abhors knife-edges even more than vaccuums. Almost inevitably grubby details begin to mount faster on one side than the other [. . .]

Beyond Belief

In "Beyond Belief", the longest chapter, Dennett takes issue with the "propositional attitudes" model and finds that what we have beliefs about are not objects in the real world, but notional objects. The notional objects are nevertheless generally tightly bound to real objects.

He also takes issue with the de dicto / de re dichotomy. He gives the example of a prank that he contemplated as a youth but never actually committed. There were two very nearly identical restaurants, and the prank would have been to have dinner with his friends at one restaurant, slip one of his friends a mickey, and drive him to the identical other restaurant, arranging everything identically. Thus the status of all of his friend's beliefs about "the restaurant" would be sensitive to whether they were about "the restaurant I'm in" or "the restaurant I went to tonight".

Dennett also uses the example of a belief about "the shortest spy in the KGB". This of course refers to an actual person (given that there are no exact ties and at least one KGB spy), yet the actual person is practically undiscoverable. Consider the belief that this person is female. The truth value of this belief can change from moment to moment as the KGB roster secretly changes, and without any "ordinary" change in the believer. Dennett borrows Geach's term "Cambridge change" to describe this sort of change, "like that change that befalls you when you suddenly cease to have the property of being closer to the north pole than the oldest plumber born in Utah"

Building on these examples, Dennett makes a persuasive argument that the de dicto / de re dichotomy misses something crucial. ISTM de dicto and de re still remain useful shorthands, as long as one that they abbreviate a potentially more complex situation.

Intentional systems in cognitive ethology / Interpreting Monkeys, Theorists, and Genes

He reviews some experiments on vervet monkeys - civilized experiments, I want you to know, like playing fake monkey alarm calls and seeing how the other monkeys react. He proposes that we should design experiments with an eye on the intentional stance.

He also takes issue with Lewontin and Gould's stance against "adaptionism" and "The Panglossian Paradigm", finding that they have more in common with B F Skinner than they think.

Another great quote on a side-topic, this time in a footnote and borrowed from Kahnemann:

I shall always treasure the visual memory of a very angry philosopher, trying to convince an audience that `if you believe that A and you believe that if A then B, then you must believe that B'. I don't know whether he had the moral power to coerce anyone to believe that B, but a failure to comply does make it quite difficult to use the word `belief', and that is worth shouting about.

Retreading

In "Error, Evolution, and Intentionality" he largely revisits themes from the earlier chapters. Apparently other philosophers had misunderstood him, and he is clarifying himself and rebutting them.

Sometimes it takes years of debate for philosophers to discover what it is they really disagree about. Sometimes they talk past each other in a long series of books and articles, never guessing at the root disagreement that divides them. But occasionally a day comes when something happens to coax the cat out of the bag. "Aha!" one philosopher exlaims to another, "so that's why you've been disagreeing with me, misunderstanding me, resisting my conclusions, puzzling me all these years!"

There's enough new material here that I don't think I wasted my time, but it doesn't lend itself to much of a summary other than "largely revisits".

Fast Thinking

This chapter is somewhat anomalous for this book. Here Dennett opines that maybe slow AI isn't AI at all, because thinking fast enough to keep up with events as they happen is a crucial part of intelligence.

Mid-term examination

Largely his thoughts on philosophy "as she is done". This is the first time I've seen Dennett address this subject. Sometimes I have thought that he must be awfully frustrated with some of his fellow philosophers, who seem to misunderstand points that this layman easily grasps. But he tackles the subject without a cross word.

Priority squabbles [. . .] in philosophy [. . .] tend to take on the air of disputes among sailors about who gets credit for first noticing that the breeze has come up