It never Rains but it Pours
This proverbial expression originated in 1726 in an article by Jonathan Swift and Alexander Pope where they wrote in “Prose Miscellanies”, "It Cannot Rain But It Pours"; the progenitor of our title here.
They were referring to the observation that when one bad thing happens, it often seems that other bad things accompany it.
It is sometimes tempting to believe that the cluster of bad events is somehow functionally related. Whilst this can sometimes be true, it is also true that clusters of events (bad or otherwise) can just be the result of randomness. This is illustrated in the diagram below:
One hundred random Y coordinates were plotted against random X coordinates.
Being randomly placed, there is absolutely no relationship between the position of any point and any other point. In fact, a good definition of random positioning of points or events (in space, time or both) is that the position of one point (or event) is not influenced by, nor does it influence, the position of any other point (or event).
Examining the scatter diagram, we can see that if we consider, for example, the two equal areas marked in yellow that are quite close to each other, one contains no points (events) and the other contains six points (events). The cluster of six points (events) has absolutely no significance just as the area containing no points (events) has no significance; they are simply random. There are other clusters and gaps in the diagram that are also not significant and are also just the natural result of randomness.
I mention all of this because I have recently written an article entitled “Why do they do these things” in which I describe actions taken by Apple and the Raspberry Pi Foundation that have repercussions for UVC cameras (Apple) and Pi Cameras (Pi Foundation), that impact astronomical imagers; that can be read HERE.
It never rains but it pours, because I now also have to report that in Distributions of Linux with a kernel of 5.15 (and above at the moment), for example Fedora Linux, changes in the userland interface in the kernel means that the way that applications detect the names of UVC cameras has changed, and not for the better.
Linux has always assigned UVC cameras on the USB bus as Video4Linux video capture device numbers. However, it has always been possible to discover the names of these cameras, to facilitate the choosing of the correct camera to connect to the imaging program. With the release of the latest kernel as mentioned above, it is no longer straightforward for imaging programs to identify cameras by their names. They now have to be identified by their Video4Linux video capture device numbers.
This is the way that a DMK 21AU04.AS camera (which is an enhanced UVC camera) is presented to the user in the Windows (which does not have the problem) version of AstroDMx Capture:
This is also the way that the same camera appears in Linux with lower kernel numbers than 1.15.
However with kernel number 5.15 this is how it appears in Linux:
This is not a deal breaker, but it is an inconvenience that at the moment affects all Linux imaging software including AstroDMx Capture for Linux.
It is entirely possible that this situation will be rectified in the future, but at the moment there is no sign of this. It may be that Nicola will produce a solution for this problem whether or not it is rectified by the Linux kernel developers.
These three events that affect UVC cameras and also Pi Cameras are an unrelated cluster, but they add simultaneously to the problems of capture software developers. They are random events, but for developers, it seems that It Never Rains but it Pours!
