Debian GNU/Linux 9.2 Released 2017-10-07 (and Other Unix-Linux-Debian Remarks)

My Debian GNU/Linux 9.2 workstation, with its Full Tower case (a 2008-vintage Cosmos) on the right. To the left of the monitor and keyboard is my trusty Brockhaus English-Deutsch/Deutsch-English dictionary, now less necessary than before the advent of Google Translate. To the right of the screen and keyboard is a trusty old book on the Bourne Again Shell. The screen itself is set up to show three things: (1) a /usr/bin/xterm, or "glass teletype", window under the use of root (I like to set up such an xterm to display red type, on a parchment-coloured background, as I warning to myself that I possess the dangerous root privileges in that terminal session); (2) a /usr/bin/xterm window under the use of ordinary user karmo (I like to set up such an xterm to display black, inky-blue, or on rather rare occasions green type, again on a parchment-coloured background, as a reassurance to myself that in the given terminal session, I do not possess root's dangerously wide privileges); a window generated by /usr/bin/eog, and displaying the first image from https://en.wikipedia.org/wiki/VT100. Each invocation of /usr/bin/xterm - at any one moment, I might have two or so for root, and five or ten for karmo - is like the creation of a fresh virtual VT100 (or similar no-images) terminal, by way of a window on the screen. In the Bad old Days, around 1980, the Departmental Mini would sit in some specially guarded room, and every end user lucky enough to be accorded on-demand computing, under timesharing, by the high authorities, would have just one single, clunky, VT100, or similar terminal, in so to speak one corner of her or his office. Not evident here, but pretty mission-central, is the ability to jump from one "virtual GNOME desktop", with its numerous onscreen windows, to another. I generally have five or so such GNOME desktops, each tending to serve some particular circumscribed area of my overall mission. A proliferation of desktops helps keep each individual screen display comparatively free of clutter.- As is usual with Web publications through  blogger and blogspot.com, the image can be enlarged in one's browser by mouse-clicking.

Quality assessment:

On the 5-point scale current in Estonia, and surely in nearby nations, and familiar to observers of the academic arrangements of the late, unlamented, Union of Soviet Socialist Republics (applying the easy and lax standards Kmo deploys in his grubby imaginary "Aleksandr Stepanovitsh Popovi nimeline sangarliku raadio instituut" (the "Alexandr Stepanovitch Popov Institute of Heroic Radio") and his  grubby imaginary "Nikolai Ivanovitsh Lobatshevski nimeline sotsalitsliku matemaatika instituut" (the "Nicolai Ivanovich Lobachevsky Institute of Socialist Mathematics") - where, on the lax and easy grading philosophy of the twin Institutes, 1/5 is "epic fail", 2/5 is "failure not so disastrous as to be epic", 3/5 is "mediocre pass", 4/5 is "good", and 5/5 is "excellent"): 5/5. Justification: There was enough time (upon delaying)  to write out essentially all the appropriate points to essentially their full appropriate length.


Revision history:

All times in these blog "revision histories" are stated in UTC (Universal Coordinated Time/ Temps Universel Coordoné,  a precisification of the old GMT, or "Greenwich Mean Time"), in the ISO-prescribed YYYYMMDDThhmmZ timestamping format. UTC currently leads Toronto civil time by 4 hours and currently lags Tallinn civil time by 3 hours.
 

• 20171016T2200Z/version 2.3.0: Kmo made some tiny substantive improvements, including the addition of a referernce to the LibreOffice suite. He reserved the right to make further tiny, nonsubstantive, purely cosmetic, tweaks over the coming 48 hours, as here-undocumented version 2.3.1, 2.3.2, 2.3.3, ... .  
• 20171015T0110Z/version 2.2.0: Kmo added a photo to illustrate some key concepts, familiar in much of the GNU/Linux world, but less familiar in a Microsoft or Apple environment. - Kmo reserved the right to make further tiny, nonsubstantive, purely cosmetic, tweaks over the coming 48 hours, as here-undocumented versions 2.2.1, 2.2.2, 2.2.3, ... . 
• 20171014T1550Z/version 2.1.0: Kmo made a few substantive changes, the most important of which were the following: specification of his year-of-hardware-assembly; correction of misspellings in both the names of his highlighted German-language authors; correction of a broken hyperlink, to list of Debian Project "teams"; addition of more information on the Hurd kernel; and addition of remarks on W3C Web-standards compliance, and on quality-assurance comparison of Firefox against Chromium. He reserved the right to make further tiny, nonsubstantive, purely cosmetic, tweaks over the coming 72 hours, as here-undocumented versions 2.1.1, 2.1.2, 2.1.3, ... .  
• 20171014T0351Z/version 2.0.0: Kmo, running still more behind the time (depression has been a problem), finished converting his polished point-form outline into coherent full-sentences prose. He reserved the right to make further tiny, nonsubsantive, purely cosmetic, tweaks over the coming 72 hours, as here-undocumented versions 2.0.1, 2.0.2, 2.0.3, ... . 
• 20171013T0129Z/version 1.0.0: Kmo, running almost 50 hours late, uploaded just a polished point-form outline. He hoped to finish converting this into full-sentences prose through a series of incremental uploads, finishing at some such point as UTC=20171013T1800Z.]  

[CAUTION: A bug in the blogger server-side software has in some past months shown a propensity to insert inappropriate whitespace at some points in some of my posted essays. If a screen seems to end in empty space, keep scrolling down. The end of the posting is not reached until the usual blogger "Posted by Toomas (Tom) Karmo at" appears. - The blogger software has also shown a propensity, at any rate when coupled with my erstwhile, out-of-date, Web-authoring uploading browser, to generate HTML that gets formatted in different ways on different downloading browsers. Some downloading browsers have sometimes perhaps not correctly read in the entirety of the "Cascading Style Sheets" (CSS) which on all ordinary Web servers control the browser placement of margins, sidebars, and the like. If you suspect CSS problems in your particular browser, be patient: it is probable that while some content has been shoved into some odd place (for instance, down to the bottom of your browser, where it ought to appear in the right-hand margin), all the server content has been pushed down into your browser in some place or other. - Finally, there may be blogger vagaries, outside my control, in font sizing or interlinear spacing or right-margin justification. - Anyone inclined to help with trouble-shooting, or to offer other kinds of technical advice, is welcome to write me via Toomas.Karmo@gmail.com.]

1. Two Purposes of this Posting

This week's posting has two purposes. Firstly, and primarily, it is intended as information for people outside the Debian GNU/Linux community (whether working with other GNU/Linux distributions, such as Red Hat, or with non-Linux operating systems, such as the various offerings, for devices of various capabilities, by Microsoft and Apple). Although the information which I present here is Debian-specific, it will encourage such readers to delve into the finer points of their own operating systems, asking themselves, "Well, if Debian GNU/Linux does such-and-such a job in such-and-such a way, then what is the equivalent in my own environment?" It is a bit like being a tourist, and soaking up a lot of initially rebarbative information about the courts and legislatures of some foreign country. The information is more practical than it at first looks, since it eventually invites the question, "Well, how do they handle ombudsman complaints (or petitions to a legislature, or municipal planning hearings, or whatever) back home?" 

Secondly, and secondarily, this week's posting seeks to be helpful in a couple of small ways to the Debian GNU/Linux community itself. Although much of what I have to say is from a Debian standpoint obvious, a few readers in that community are liable to benefit mildly from at least the following:

• my brief remarks, in Section Five, regarding two perhaps not-too-well-known pieces of Web outreach, https://tracker.debian.org and https://tracker.debian.org/teams/
• my reference, likewise in Section Five, to the Hofmann-Beckert German-language book-in-progress (this book project may not be known to many Debian users within the Anglosphere - familiar though such readers are likely to be with the English translation of a recent high-quality Debian book by French authors Raphaël Hertzog and Roland Mas, to which I also refer)
• my explanation in Section Three (I wrote it on the strength of the just-mentioned Hertzog-with-Mas) regarding an initially puzzling point, the use of a special "updates" section in a typical /etc/apt/sources.list file, over and above the (obviously update-regulating) "base-repository" and "security" sections of that same file

2. Why Debian GNU/Linux? 

The overall  philosophy of computing is interesting. A full treatment would require a discussion of, among other things, the question "How much is enough?" It is not enough for the typical knowledge worker, such as a historian or classicist or modern linguist or astronomer-physicist, to have only sporadic, or even to have continuous, access to a 1970s text-only "Departmental Mini" - as in the days when the leading-edge professor would keep a VT100 terminal, in other words glass teletype, glowing blue-on-black in a corner of her or his office, I suppose astonishing everyone on the Departmental corridor with such marvels as "e-mail". No: these days we really do have to be able to set type for high-quality publications, with exquisitely worked mathematical symbols right on our screen, or to view colour photographs. And on the other side, it seems inappropriate to let a computer invade one's nonprofessional life, through Facebookery, "online gaming", inordinate YouTubery, and the like. 

I will not embark on such questions here. Here it is enough to remark that I said much of what needs to be said around 2004 in essays within my server space http://www.metascientia.com - especially in the 2004 essay entitled "No-Frills GNU/Linux: Philosophical Foundations", at http://www.metascientia.com/PNNN____lit/SNEN____values.html.

A full treatment would also require a discussion of the questions "What happens to computing as climate change and fossil-fuel depletion drive the world into a Dark Age over the coming century, and how might we now prepare?" Perhaps that further, unavoidably speculative, pair of questions calls for a fresh essay some day on this blog, either by me or by someone else. I even have a possible guest author in mind, who I suspect now offers professional Microsoft consulting and professional GNU/Linux consulting in his home country of Mexico.

For the moment, it is enough to fire off just a couple of points:

• Although we must fear the Internet's suddenly going dark, as when cybersaboteurs crash the Domain Name System (DNS) (is, perhaps, the Network Time Protocol a DNS vulnerability?), we must also fear a more incremental scenario, in which the Internet first fragments, and then fades away slowly and unevenly. The fade-to-black might perhaps prove especially slow in some well-networked, cybersecurity-conscious, jurisdictions - in the upcoming cyber-Byzantiums, as opposed to the less happy upcoming cyber-Romes. 
• Warlords will always need their computers, just as they will always need their Semtex, their weaponized anthrax, their Kevlar, and their aeroplanes. So Internet or no Internet, we may expect a couple of centuries from now that the Man in the High Castle, while perhaps bereft of external networking, is nevertheless running the dreaded old Departmental Mini - replete with, say, one VT100, or its New-Dark-Age equivalent, in his Map Room, another VT100-or-equivalent in his Records Office, and a few more scattered here and there, in the outlying bunkers on his sprawling estate. It is perhaps a minor consolation that with slave labour once again abundant, backplanes will be readily wired up with lots and lots of discrete, low-capability chips, or even with discrete transistors, somewhat in the manner of the feeble old 1980s VAXen, or of their still feebler 1960s-1970s PDP forerunners. (Sorry, folks: if you con't like your New Dark Age running on recreated DEC hardware, such as the VAX series and the PDP series, do feel free to substitute whatever other things you consider appropriate. People used to say, in the grim era of the Departmental Mini, "Nobody gets fired for procuring IBM.") 

My own guiding philosophy at present, with the New Dark Age still conceivably decades away, is to run a kinda-sorta epoch-2008 private facility, sporting a Full Tower with lots of fans. Inside is a notably conservative, 2008-vintage, Intel motherboard, running a mere Intel Core Duo CPU, with a mere 2 GB of RAM.

Everyone will say, "Well, how quaint; do you also wear spats, and winged collars?" Well, ask I in response, what other device is appropriate if you are trying to study elementary maths, physics, and astronomy, and are trying to keep an eye on world and Church events, and accordingly find yourself maintaining thousands upon thousands of lines of flat-ASCII (plain-text) private casenotes, at your well-equipped reading and writing desk - while also trying to make a decent automated contribution, over the nights and the Sundays, to seti@HOME (https://en.wikipedia.org/wiki/SETI@home)? Laptops and tablets seem somehow, in this kind of work, flimsy and ephemeral, rather as the private motorcar seems flimsy and ephemeral when compared with rail.

The people who in sympathetic worry say "How quaint!" will also worriedly ask, "Aren't you missing a lot of important software by not exploring the world of shirt-pocket cell-phone apps?" Here, however, the answer is that should it ever be necessary to start exploring the world of shirt pockets, one can within GNU/Linux emulate at least Android (I have not yet investigated the situation for Apple iOS). The emulation would presumably make it possible to download Android software, as desired, from some "Apps Store".  

Within my overall mission parameters, as just outlined, I try to keep the total cost of ownership low, by buying good hardware at the outset, and then keeping it going for years and years. (I selected and assembled my full-tower components myself - buying, to be sure, in 2008 or 2009, and yet assembling early in 2013, as I dealt with depression and tried in vain to save some of the now-ruined David Dunlap Observatory greenspace (77 hectares total, 32 hectares ruined). I found the most time-consuming of my various tasks to be the preliminary reading of consumer reviews, with a concentration on the various complainers. It was when I saw a reviewer in a gamer mag announce, in lofty disdain for the play-it-safe grey and plodding, "This would make a fine motherboard for your Dad," that I knew I was picking out an appropriate motherboard.)

Since reliability is paramount, so is security - both against component failures and against hacking.  I therefore have, among other things, a manual nightly backup procedure, involving a second hard drive within that Full Tower, and have in additional rather special disciplines for offsite backup - both (1) onto physical media, stored outside my place of residence, and in part (2) over the Internet, on a sort of poor-man's "Cloud" appropriately far from both Ontario and Estonia.

My mission-required emphasis on reliability and security in turn entails a minimization of automation (seti@HOME being one of the rare exceptions), with a parallel effort to understand the details of my workstation. I therefore decided, from 1996 onward, to make my normal, day-to-day, workstation operating system a Unix, rather than some flavour of Apple or Microsoft. It is Unix, and not the Microsoft offerings, that constitutes current best software practice. By 1996, it was fortunately possible to run Unices on even simple poor-man's-workstation hardware, such as I then possessed. (Back then, I owned not even a 486 DX, but a mere 486 SX - that is like a DX, but minus the maths co-processor - addressing a mere 4 MB of RAM.)

An in-essence-Unix kernel, of one specific Unix-tribe lineage or another, is what nowadays lies at the heart even of Apple's macOS in the workstation and laptop world, and of both Android and Apple's iOS in shirtpockets.

To be sure, everyone would find an element of chutzpah in the old industry quip, "Unix, The One True Operating System". But what is better than a Unix kernel? Some dim knowledge of one serious competitor, the Hurd kernel, has percolated down even to my rather humble level (and so, a fortiori, must be much alive in the august halls of Google, and in those august government spookshops which are GCHQ and NSA). But Hurd. although started back in 1990, is not mature. It is perhaps a sign of slow project advance that https://en.wikipedia.org/wiki/GNU_Hurd gives the date of the latest release (version 0.9) as 2016-12-18 - in other words, as almost a year ago. There is, to be sure, not only such a thing as Debian GNU/Linux (the main topic of this present posting) but the unofficial port Debian GNU/Hurd (https://en.wikipedia.org/wiki/Debian_GNU/Hurd). The latter is said by Wikipedia to be as of its 2013 initial release running 78% of the 2013 universe of Debian GNU/Linux packages, for those brave enough to entrust their workstations to an experimental kernel. I, for one, am not brave in computing, especially when it comes to the central coordinating nerve centre which is the kernel.

Within the general world of Unices, it is advisable, for reasons both philosophical and economic, to concentrate on open-source software. What corporation or NGO, then, in the universe of Unix offerings, (a) surveys the global community of open-source developers most thoroughly, and (b) packages up its duly selected offerings under the most thorough process of testing, and (c) imposes the most thorough package-management algorithms, to ensure that installed packages coexist correctly on each of the potentially millions (cf https://www.linuxcounter.net/statistics) of individual end-user machines?

Having in early days, from 1996 or indeed in a sense from 1995 onward, worked with Slackware's  GNU/Linux (this I installed in 1995, from a stack of about twenty floppies), Red Hat's GNU/Linux, and the GNU/Linux branded "Mandrake" (later rebranded "Mandriva"), I have since 2003 selected the non-corporate, and therefore I suppose essentially NGO, Debian GNU/Linux. In making that selection, I have been guided by a high-grade I.T. consultant, Mr Rob Brockway, who fortunately happened to be in Toronto at the very time I was seeking a consultant. Mr Brockway's profile can be found at  https://www.linkedin.com/in/rbrockway/. He is now physically, however, not in Toronto at all, but back in his native Australia, and we have been out of touch for years.

This week I confirmed for myself, once again, the general appropriateness of my opting, as already in Mr Brockway's time, for Debian GNU/Linux, by once again glancing at a table in https://en.wikipedia.org/wiki/Comparison_of_Linux_distributions. Once again I asked, "Which particular GNU/Linux distributions offer how many pre-compiled software packages?" Debian GNU/Linux presently comes out second in the table, with 57,290 packages. (On my own workstation, I have at the moment installed of course only a small subset from this vertigo-inducing universe - in fact, on a recent inspection, exactly 2100. The fewer the packages chosen for installs, the lower the risks.) First, with 73,229 packages comes Ubuntu, with its derivatives (each likewise having 73.229) Kubuntu and Xubuntu. But I do prefer Debian GNU/Linux over the Ubuntu family. As a justification, I reason here that Ubuntu has potentially tedious ties to the corporate world, and is newer than Debian GNU/Linux, and has a history of fast-and-frequent version releases (a potential source of quality problems), and is indeed derived from Debian GNU/Linux. (As I have indeed remarked somewhere else in my blogging over the past 18 months, Debian GNU/Linux has been paid the compliment of spawning many derivatives - including not the Ubuntu family alone, and "Linux Mint", but even such things as, back home in Estonia, "Estobuntu".)

3. Overall Debian GNU/Linux Strategy and Tactics

Having (as just explained) settled first on the Unix world, and then within that wide world on Debian GNU/Linux, I implement the following specific strategy points within Debian GNU/Linux:

• Prize conformity with open-source software ideals above feature-richness, important though feature-richness itself is. Consequently (a) make all, or virtually all, installations from one of the Debian GNU/Linux mirrors, as opposed to some Debian-compatible server or servers outside the Debian Project; and (b) within the Debian Project make all, or virtually all, installations from the so-called main repository of a duly selected Debian GNU/Linux mirror, ignoring that mirror's so-called contrib and non-free repositories. (Currently, I am running no software at all from Debian-compatible GNU/Linux distribution points outside the Debian Project, and I have nothing at all - not even so much as a Radeon video-card driver - from contrib or non-free within the Debian Project. But it might some day be necessary to relax this rule slightly. In particular, a relaxation might in future prove necessary if my private astronomy efforts come to require my running the usual tools for the processing of CCD-camera spectrograms (IRAF in North America, and MIDAS in at least some centres in Europe). Additionally, it might in the near future be advisable for me to heighten the security of my machine by running one or more cyber-forensics tools from outside the Debian Project servers. In particular, I might over the coming weeks, days, or hours find it advisable to install a fully up-to-the-minute version of the security scanner lynis from the (Netherlands-based, non-Debian, and yet Debian-compatible) server cisofy.com, after uninstalling my existing, not-quite-current, Debian-Project-procured /usr/sbin/lynis.)
• Prize  stability over feature-richness, important though (to repeat) feature-richness itself is. Consequently update all, or virtually all, Debian-mirror downloads merely against the current stable. (That is, as of 2017, Debian GNU/Linux 9.x stretch - where at this instant, in 2017 October, x no longer equals 0, or even 1, but equals 2. The (small) transition from k.n to k.(n+1), as distinct from the (large) transition from k.n to (k+1).0 - in this latter case, I suspect n must be the final release in the series k.1, k.2, ... - is known as a "point release".) In this necessary updating, ignore the Debian-mirror testing and unstable, which within the Debian Project constitute work-in-progress. It is only stable that is the result of duly completed testing. Since testing takes time, it is only every two or so years that one Debian GNU/Linux stable release is followed by another. Over the last couple of years, in 2015 and 2016, the stable mantle was worn in succession by the successive members of the Debian 8.x, or jessie, series (in other words, by the various successive jessie point releases). For much of this year (2017), and one presumes also for all of 2018 and for at least some part of 2019, the stable mantle is instead to be worn by Debian GNU/Linux 9.x - at first, this past northern-hemisphere summer, by Debian GNU/Linux 9.0, and then by Debian GNU/Linux 9.1, and as of the Saturday which was 2017-10-07 by Debian GNU/Linux 9.2. In the more remote future - in the middle of 2019, perhaps, or late in 2019, or early in 2020? - the mantle will pass, from perhaps something like Debian GNU/Linux 9.9 or Debian GNU/Linux 9.10 or Debian GNU/Linux 9.11, to Debian GNU/Linux 10.0 and its 10.1, 10.2, ... . point-release successors (all of them being formally named buster; a little additional background is available at https://en.wikipedia.org/wiki/Debian_version_history.) That upcoming 10.0 is a Debian GNU/Linux incarnation (a) with which some brave people are playing now, in a work-in-progress version under the testing section of the Debian Project, but (b) which it would be inappropriate for me to allow as yet onto my own (deliberately conservative) workstation. 
• Avoid undue automation of the update process. Invoke instead a manual updating routine, say two or four or six times a week. - For updating, I have been using the /usr/bin/apt tool. But I now think it best to acquire just a little more personal control, by using the perhaps marginally less user-friendly /usr/bin/apt-get tool. I gather that both /usr/bin/apt and my now-preferred /usr/bin/apt-get (and indeed a third alternative, the scary /usr/bin/aptitude on which I shall have to comment in a moment) perform what the professional computer scientists call a "topological sort". The universe of packages on a machine running Debian GNU/Linux is a collection of n pairwise disconnected "graphs", with each (internally connected) graph comprising k-sub-i "nodes", for i = 1, 2, ... , n. In this formalism, each software package is a node (typical packages then being in some cases recondite parts of the workstation internals (bind9-host, openssl), but in other cases being such more or less familiar things as chromium and its seemingly less error-prone peer firefox-esr, for browsing.  (The Gentle Reader can contrast and compare by launching both browsers from a /usr/bin/xterm window, with the STDERR plain-text error-messages stream either appearing, teletype-like, in that window or directed to some convenient plain-text file. Under this setup, one can then compare the two browsers by surfing some demanding, not quite W3C-standards-compliant, site such as http://news.bbc.co.uk. (That is right, Gentle Reader, the Beeb is Web-standards-noncompliant. The reader can check this, as I just did, by pointing the validating parser at https://validator.w3.org/ to http://news.bbc.co.uk.  Similarly noncompliant - the blame rests not with me, but with blogger and blogspot - is http://toomaskarmo.blogspot.com.)  A further example is vim, for editing text files. (I discuss vim in more detail below, at a more appropriate point in my exposition.) Yet another example of a more-or-less-familiar thing is eog ("Eye of Gnome"), for displaying in its own on-screen window some humble digital photo - as it might be auntie_foobar_feeding_our_cat_tibbles_in_her_back_garden.jpg. If Package X needs Package Y to function, then say that X "depends on" Y, and in formal descrete-mathematics, or "graph", terms, that there is a "directed edge" running from node Y to node X. Since, as already noted, there are presently a little over 50,000 available Debian GNU/Linux software packages, and since it is (surely) normal to install on even a modest workstation like mine one or two or three thousand packages from this universe, either the number n or some of the individual numbers k-sub-1, k-sub-2, k-sub-3, ... , k-sub-n are liable to get large, into the domain of three or four figures. (As at UTC=20171012T012727Z, I find my workstation to have exactly 2100 installed packages. If n happens to be 10, then the numbers k-sub-1, ..., k-sub-10 must therefore add up to the large sum of 2100. it could be, for all I know at the moment, that n is even as small as 1 - but in that limiting case, k-sub-1 must be very large indeed, namely 2100.) I believe that /usr/bin/apt-get, /usr/bin/apt, and the scarier /usr/bin/aptitude all attempt to find a path through each of the n graphs, traversing all the given graph's nodes in the order defined by its various directed edges, while taking into account the various updates that might be available on one's selected Debian Project security server and one's selected other Debian Project mirror or mirrors. The goal is to ensure that (A) every package is updated to its latest available version within the selected global constraint (in my particular case - to reiterate - the constraint that every package shall be from the now-so-exhaustively-tested, so-conservative, stable (also known, in this epoch of Debian GNU/Linux 9.x, as stretch), and shall within stable (i.e, for the present epoch, stretch) be from the so-open-source main), and that (B) the updates shall be done in the right order.  At the moment, I consequently have for my root account a bash-shell alias uuu, with the following two-command line in my root-account /root/.bashrc shell-initializing file: alias uuu='apt-get update; apt-get dist-upgrade'. The apt-get upgrade, which runs first, ensures that my workstation has a correctly updated list of the packages either now available on my selected Debian mirror(s) or now available on a special Debian Project security server. The apt-get dist-upgrade, which runs second, then ensures that my workstation checks all its installed packages for upgradability against the latest globally distributed state of (here comes my self-imposed constraint) Debian GNU/Linux stretch, as confined to main - consulting the just-mentioned list, and upgrading my workstation wherever the list shows an upgraded package to be available for download at the Debian Project. - It would, to be sure, be more conservative to run against stretch-cum-main the command apt-get upgrade, as opposed to running against stretch-cum-main the command apt-get dist-upgrade. But the use of dist-upgrade secures an advantage worth the risk of automation. If the vicissitudes of software development within the world of X, perhaps at the desks of programmers far upstream of the Debian Project itself, now mean that upgrading Package X within Debian GNU/Linux stretch-cum-main either requires package Y to be installed within Debian GNU/Linux stretch-cum-main (if not yet installed) or requires Package Y to be uninstalled (if presently installed), apt-get dist-upgrade will boldly perform the required surgery on Y. In this awkward contingency, the less bold apt-get upgrade, on the other hand, will bashfully refuse to do surgery involving Y, and will therefore issue a message explaining, with a reference to Y, its refusal to upgrade X. On balance, it does seem better here to let the workstation take charge. - In allowing this much automation, I do still steer clear of the rather scarily automated /usr/bin/aptitude, except that I make a momentary launch of /usr/bin/aptitude, with an invocation of the sole /usr/bin/aptitude command go, one of my tests for overall workstation integrity, (go, say I to the scary tool: and then if /usr/bin/aptitude displays the reassuring message (as so far it always has) No packages are scheduled to be installed, removed, or upgraded, I exit.) - It goes almost, but not quite, without saying that when I issue, in a root-terminal window, my double-barreled uuu, I have to look very closely at what messages are being generated, staying ready to abort the upgrade process if something in the messages looks odd. (To spell this out a little: /usr/bin/apt-get, and indeed its more "user-friendly", in other words more dangerous, cousins /usr/bin/apt and /usr/bin/aptitude, explain what actions are proposed - what it is proposed to download either from my chosen mirror or from the special security server, by way of upgrades for which particular packages, and how many further bytes of storage it is proposed to consume in creating the upgrade-necessitated new files. The human sysadmin, reading the messages as they are written, is therefore given the chance to say, in effect, "No, please do not do it.") 
• Keep a full log, in the spirit of a ship's or an observatory's maintenance log, of actions performed by /usr/bin/apt-get. In simple cases, it suffices to mouse-swipe copy and mouse-click paste, straight from a root-account /usr/bin/xterm window, straight into a vim editing session of one's maintenance log, the various message lines - the so-to-speak "advisories from root's /usr/bin/xterm smart-or-dumb terminal, in other words glass teletype" - output by /usr/bin/apt-get. In more difficult cases, where /usr/bin/apt-get outputs some hundreds of lines of text, it is advisable not only to read the messages on the glass teletype as they come in, but also to run the /usr/bin/script tool. That tool generates an automatic transcript of what the /usr/bin/apt-get tool has been generating at root's glass teletype, when screenful succeeds wearisomely eloquent screenful. It is easy enough, within a vim session, to then copy the entire transcript, at one fell swoop, into the log. 

It additionally goes almost, and yet not quite, without saying that one documents in this log not only system-upgrade actions, but also the rather frequent occasions on which one finds oneself installing some altogether new software - perhaps on the strength of reading within the geekier stretches of Wikipedia or the geekier stretches of the blogosphere. By way of illustration, I reproduce here a specially simple, short, maintenance-log entry from an occasion this past August on which I installed a new package (using, back then, /usr/bin/apt rather than the /usr/bin/apt-get which I now favour). I wanted to try out a package, newsbeuter, of which I have admittedly made little or no subsequent use, for reading RSS feeds. (The newsbeuter idea is appealing, since it generates news feeds right in one of the typical GNU/Linux workstation's numerous old-fashioned glass-teletype /usr/bin/xterm windows. All the same, it proves best to forsake the 1980s for the present day, setting up RSS feeds directly in Firefox or Chromium, and thereby forego one's possible occasional nostalgia for the Thatcher-Regan Era. I do not, after all, have all that many RSS feeds. At the moment, I use RSS only for reading the mainstream press. I have from from RSS at the moment just a handful of broadcaster or newspaper outlets in English, plus the Vatican press office in English, plus one RSS newspaper feed each in German, French, and Estonian (and those non-Anglo newspaper feeds I visit all too seldom). I suppose newsbeuter would come into its own if some global catastrophe were to make it suddenly advisable to raise the number of monitored press feeds to twenty or thirty, and perhaps to start archiving such newspaper-and-broadcaster content in clever ways, as the so easily /bin/grep-searched, and so easily /usr/bin/fmt-reformatted, and so easily /usr/bin/perl-massaged, flat ASCII ("plain text").)

I do add here, as a small aside, that my treatment of dependencies and graphs, with directed edges, is a little simplified. In reality, Debian GNU/Linux operates not only with the notion that Package X outright depends on Package Y, but with at least two further notions: (1) perhaps Package X "recommends" Package Y, in the sense that most users would not want to run X without also having Y (maybe X is in its ordinarily intended uses limited in its features if Y is absent, even though X-without-Y runs without crashing); (2) perhaps Package X "suggests" Package , in the sense that to get full value out of X, exploiting the full power of its features rationally, it is a Pretty Good Idea to have also Y. I am not here claiming that I have a very sharp understanding of the difference between "recommends" and "suggests", or even that the difference can be explained in formally sharp terms by the full-bore professionals. Readers needing to take their researches farther than I have taken mine might Google on the string  debian recommends and suggests.

As can be seen from the display I am about to give, although I wanted /usr/bin/apt to install just newsbeuter, /usr/bin/apt said, "Oh, wait a moment: you can't do that unless you also install the package libstf10." (This was a matter of outright "depends", not of mere "recommends" or "suggests".) /usr/bin/apt then asked me for my assent to the pair of recommendations.

It can also be seen from the display I am about to give that the downloading was done not from one server but two - on the one hand from my normally selected mirror (for personal security, I conceal details, including selected country, regarding that selected mirror), and on the other hand from a special Debian Project security server, which my minor forensics this week indicate might possibly have resided in the American midwest. The visit to "security" had nothing much (surely) to do with the normally-surely-so-harmless newsbeuter on my selected mirror, but was made by my system in a prudential spirit, as it checked that there was no fresh security-relevant news from the central Debian Project desks, of a character to call into question, I suppose even in some subtly indirect way, the prudence of the envisaged newsbeuter download-from-normal-mirror.

Here, then, is my promised display, showing newsbeuter getting installed along with a package on which newsbeuter has turned out to outright depend:

((ITEM WHEN="20170818T145356Z"))

root@veritas:/etc# apt install newsbeuter
Reading package lists... Done
Building dependency tree    
Reading state information... Done
The following additional packages will be installed:
  libstfl0
The following NEW packages will be installed:
  libstfl0 newsbeuter
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 610 kB of archives.
After this operation, 2,398 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://mirror.[[[[redacted]]]].[[[[redacted]]]].[[[[some-national-domain]]]] /debian stretch/main amd64 libstfl0 amd64 0.22-1.3+b4 [37.2 kB]
Get:2 http://security.debian.org stretch/updates/main amd64 newsbeuter amd64 2.9-5+deb9u1 [572 kB]
Fetched 610 kB in 0s (900 kB/s)    
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package libstfl0.
(Reading database ... 194484 files and directories currently installed.)
Preparing to unpack .../libstfl0_0.22-1.3+b4_amd64.deb ...
Unpacking libstfl0 (0.22-1.3+b4) ...
Selecting previously unselected package newsbeuter.
Preparing to unpack .../newsbeuter_2.9-5+deb9u1_amd64.deb ...
Unpacking newsbeuter (2.9-5+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libstfl0 (0.22-1.3+b4) ...
Setting up newsbeuter (2.9-5+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...
root@veritas:/etc#
((/ITEM)) 

From what I have said already, it will be appreciated that central to everything in Debian GNU/Linux package management is the selection of one's mirror. It is at this point that cybersabotage becomes chiefly possible. Corrupt even one of the 427 or so mirrors in the worldwide Debian Project - a full, annotated, list is published at  https://www.debian.org/mirror/list-full, it seems to me with daily, or not-far-from-daily, updating - and you corrupt potentially some thousands or tens of thousands of end-of-stream machines. Many of these would not even be humble private-analyst workstations, like mine, but, worryingly, production servers, in universities, governments, and corporations (including Web servers, and other kinds of purveyors of Internet content or Internet connectivity; those vulnerable Debian GNU/Linux boxes help, among other things, in a backroom way to keep the Internet running, from building to building, from neighbourhood to neighbourhood, and from city to city, even for people who are unaware of Debian GNU/Linux).

Admittedly, mirrors have security controls, with verification of digital signatures. All the same, for safety I refrain from displaying my own workstation's version of that centrally important file which is /etc/apt/sources.list.

I do remark, on the other hand, that, as is usual with Debian GNU/Linux on normally administered workstations, my particular /etc/apt/sources.list specifies fully three things:

1. a special server, to be thought of as centrally located in the worldwide Debian Project, for my workstation to use in checking that no "security upgrades" are available
2. a mirror for my workstation to use in checking that no intermediate-urgency upgrades are available
3. a mirror for my workstation to use in checking that no lowest-urgency upgrades, reflecting mere changes in the Debian GNU/Linux 9.x "base repository", are available

It may or may not be that the mirror I have selected for the second of these three tasks is physically identical with the mirror I have selected for the third of these three tasks. Regarding this detail, I divulge nothing.

All three checks are performed when I issue that system-update command uuu (which is, as already noted, a bit of command-line shorthand for the double-barrelled command apt-get update; apt-get dist-upgrade - update updates my locally stored information on what packages the Debian Project is making available, and dist-upgrade actually pulls the appropriate package upgrades down to my local machine, thereafter running their various install-or-tweak shell scripts, as in each case bundled up inside the package). There accordingly are three broad update scenarios, within the overarching framework of Debian GNU/Linux 9.x:

1. Something bad has happened, with software analysts, in a typical case somewhere outside the Debian Project, finding some security vulnerability in some tool or other - say, for concreteness, in the image-viewing tool eog ("Eye of Gnome"). Governments and corporations, and also non-profits such as the Debian Project, are alerted, through various channels (perhaps involving, for instance, the authority of Uncle Sam, as at https://www.us-cert.gov/ncas). Within the Debian Project management, it is felt - as it might be, by duly worried Debian Project software engineers, duly plugged into the alert-distribution channels of such official sources as Uncle Sam, as are also other software engineers, for instance within the walls of Red Hat and Microsoft - that the situation is severe. So severe is it, in the official Debian Project software-engineering assessment, as to require an improved eog package to be uploaded in haste to the special Debian Project security server. (That improved eog will of necessity sport some newly incremented Debian Project version-tracking number. We would typically imagine the revised Debian GNU/Linux eog package to incorporate, apart from the inevitable install shell scripts and uninstall shell scripts, other automated-administration supports, and documentation, a binary - created from the upstream C++, or whatever, source code by some compiler within the Debian Project. The binary would be destined ultimately to reside on the humble end-of-stream workstations, like mine, as something like an "ELF 64-bit LSB shared object", in something like 10,680-byte 64-bit-amd-architecture glory, say as the executable file /usr/bin/eog. One would typically imagine the upstream Eye-of-Gnome developers - they promote their work at https://wiki.gnome.org/Apps/EyeOfGnome, quite outside the Debian Project - to have revised their C++ source code themselves, in haste, releasing it for the benefit of the general compiler-running engineer community, including segments of the community outside the Debian Project.) When I issue the command uuu at my workstation, my workstation notices that, no matter what is the current state of the other mirror or pair-of-physical mirrors specified in my /etc/apt/sources.list, at any rate my specified security server has now a version of the eog package more recent than the version I have so far been running. My workstation accordingly asks me for permission to upgrade my eog. 
2. Something notably pressing, but not downright bad, has happened. Some significant bug not radically compromising cybersecurity, has been repaired in eog - either at the upstream development desks, outside the Debian Project, or conceivably just at the level of Debian Project packaging. (a) In the former case, there might be some change in the source code. Nobody at the Debian Project is in a typical case so bold (I believe) as to edit that particular code. But the Debian Project eog package manager does study the code in a quality-assurance spirit. Upon satisfying herself or himself, in the formal capacity of a Debian Project officer, that the change is an acceptable one, the manager uses it in compiling the binary, in as it were its ELF 64-bit-architecture, 10,680-byte glory, which eventually ends up on the machines of Debian Project end users, say as /usr/bin/eog. (b) In the latter case, the upstream source code, as the special province of the folks at https://wiki.gnome.org/Apps/EyeOfGnome, stays the same. What changes is perhaps (b.a) a mildly downstream thing, namely the binary. Maybe the Debian Project managers decide in their wisdom to throw some new and different switches on their compiler, as they once again create the publicly distributed binary from the (unmodified) source code. (b.b) It is, however, more likely that some decidedly downstream thing changes. (b.b.a) That "decidedly downstream thing" could be documentation accompanying the application. Or (b.b.b.) it could be very far down stream indeed, being one of the scripts written by the Debian Project software engineers themselves, for installing, tweaking, or uninstalling eog under Debian-specific package-management arrangements. (An example: always when a package for some application is created, one of the questions to be asked is, "What happens if the end user later chooses to uninstall the application? In what order do the various necessary file deletions get performed on her or his machine, and with what particular advisory messages printed for her or his screen-vigilant eyes?") - Whatever this thing is (however far upstream or downstream, in particular, it may happen to lie), it is on this second scenario notably awkward. If the current Debian GNU/Linux 9.x happens to be 9.0, then duly update-aware users should implement the notably pressing modification even before the release of Debian GNU/Linux 9.1 (just as in the first of our present triple of scenarios); if the current Debian GNU/Linux happens to be 9.1, then those duly update-aware users should implement the notably pressing modification even before the release of Debian GNU/Linux 9.2 (just as in the first of out current triple of scenarios); and so on. (So awkward, in other words, is the situation that it cannot wait for the next point release. If we wait for, say, the transition from 9.1 to 9.2, we are liable to wait too long. At the Debian Project, the interval between point releases is typically on the order of two months.) And so whatever action the Debian Project managers do or do not take in respect of their other two classes of server, they at any rate put a version of the eog package, with duly incremented version number, onto their servers-for-updates-of-intermediate-urgency. When end users execute their update routines, their machines accordingly note that on at least one of the three classes of server, an upgrade of eog is available, and so they again ask the end user for permission to upgrade her or his system.
3. Something important, but not at all bad, and not even notably pressing, has happened. Some substantial improvement has been made in, as it might be, eog. The improvement is big enough to matter, and fortunately is not so drastic as to require months or years of testing by the Debian Project quality-assurance managers. (It is safe to roll it out, for the benefit of end users, within the overall framework of Debian 9. It need not wait until the 2019-or-thereabouts release of Debian 10.) If we are currently in, say, Debian GNU/Linux 9.1, then the improvement is not worth bringing to the immediate attention of Debian GNU/Linux 9.1 users, and yet is worth putting into the ensemble or bundle of improvements that shall define, perhaps two months after the point-release transition from Debian GNU/Linux 9.0 to Debian GNU/Linux 9.1, the point-release transition from Debian GNU/Linux 9.1 to Debian GNU/Linux 9.2. Consequently, whatever action the Debian Project managers do or do not take in respect of their other two classes of server, they at any rate put a version of the eog package, with duly incremented version number, onto their mirrors-of-Debian-GNU/Linux-9-base-repository, bundled on the day of that action with many other changes, of this same general character, to many other packages. At the same time, they put out a press release, or a similar formal document, announcing to the public that Debian GNU/Linux 9.1 is superseded, in a fresh point release, by Debian GNU/Linux 9.2. When end users execute their once-per-day or three-times-per-week (or whatever) update routines, their machines note not only that an upgrade of eog has become available, but also that upgrades for many other packages have become available. Rather careless users will be startled to find their /usr/bin/apt-get asking for permission to upgrade quite a few packages. More careful users (last Saturday, I was fortunately in that more respectable camp) will have already noticed a Debian Project point-release advisory in their e-mail, warning that the "base repository" mirrors have gone from offering Debian GNU/Linux 9.n to offering Debian GNU/Linux 9.(n+1). Such users will therefore be braced for quite a bit of terminal-window messaging when they next invoke apt-get update and apt-get dist-upgrade: now, suddenly, they might find their machines asking for permission to upgrade not one or two or five packages, as on a rather normal day, but more like fifty or a hundred packages. If all goes well (as one expects - the point-release transition from Debian GNU/Linux 9.n to Debian GNU/Linux 9.(n+1) is after all not as epochal as the transition from Debian GNU/Linux 9.x to Debian GNU/Linux 10.0, to be discussed shortly), the machine-requested actions will not look very dicey, and sysadmins will find themselves assenting readily.

4. Specific Debian System Upgrades
(9.1 to 9.2 Now; 9.x to 10.0 Later)

When, last Saturday, 2017-10-07, Debian GNU/Linux made its point-release move from 9.1 to 9.2, I was advised that a new kernel was available, and that about a hundred packages already installed by me, even as a diligent week-by-week upgrader within 9.1, were now available in upgraded versions:

The following NEW packages will be installed:
  linux-image-4.9.0-4-amd64
The following packages will be upgraded:
  apt apt-transport-https apt-utils at-spi2-core dbus dbus-user-session
  dbus-x11 desktop-base dirmngr evolution evolution-common evolution-plugins
  freerdp-x11 gir1.2-atspi-2.0 gir1.2-javascriptcoregtk-4.0 gir1.2-webkit2-4.0
  gnupg gnupg-agent gnupg-l10n gnupg2 gpgv krb5-locales libapt-inst2.0
  libapt-pkg5.0 libatspi2.0-0 libdb5.3 libdbus-1-3 libevolution
  libfreerdp-cache1.1 libfreerdp-client1.1 libfreerdp-codec1.1
  libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1
  libfreerdp-gdi1.1 libfreerdp-locale1.1 libfreerdp-plugins-standard
  libfreerdp-primitives1.1 libfreerdp-rail1.1 libfreerdp-utils1.1
  libgnutls-openssl27 libgnutls30 libgssapi-krb5-2 libhogweed4
  libjavascriptcoregtk-4.0-18 libk5crypto3 libkrb5-3 libkrb5support0
  libldap-2.4-2 libldap-common libncurses5 libncursesw5 libnettle6 libselinux1
  libsmbclient libspeechd2 libtinfo5 libwbclient0 libwebkit2gtk-4.0-37
  libwinpr-crt0.1 libwinpr-crypto0.1 libwinpr-dsparse0.1
  libwinpr-environment0.1 libwinpr-file0.1 libwinpr-handle0.1 libwinpr-heap0.1
  libwinpr-input0.1 libwinpr-interlocked0.1 libwinpr-library0.1
  libwinpr-path0.1 libwinpr-pool0.1 libwinpr-registry0.1 libwinpr-rpc0.1
  libwinpr-sspi0.1 libwinpr-synch0.1 libwinpr-sysinfo0.1 libwinpr-thread0.1
  libwinpr-utils0.1 libwpd-0.10-10 libxfreerdp-client1.1 linux-image-amd64
  linux-libc-dev ncurses-base ncurses-bin ncurses-term ntpdate osinfo-db
  python-samba python3-speechd samba-common samba-common-bin samba-libs
  smbclient speech-dispatcher speech-dispatcher-audio-plugins
  speech-dispatcher-espeak-ng vim vim-common vim-runtime vim-tiny whois
  xkb-data xxd
103 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 104 MB of archives.
After this operation, 190 MB of additional disk space will be used.
Do you want to continue?

The new kernel was the scary "NEW" package linux-image (or, in its full-length name, incorporating a freshly incremented version number, linux-image-4.9.0-4-amd64).

Other things were less scary. It is notable that there were upgrades at least potentially related to my tool of choice for package management, /usr/bin/apt-get.

Further, it is notable that there was an upgrade to something I use tens or hundreds of times every day, the vim text editor, on which it is now advisable to comment in detail. In serious computing, one has little or no use for "word processors", with their time-consuming, search-impeding refinements in formatting. (It is a sign of the weak character of "word processors" that they cannot, in general, hope to tell one into what column one is typing, willing though they might on occasion be - for all I know - to display row numbers. It does not make sense to say "This page is 80 (or whatever) columns wide", or "Your cursor is now sitting in column 43," unless the font is  monospaced, in the special manner of that "word processor" typewriter-imitation which is Courier. I do have to keep a "word processor" handy, to be launched by selecting from the on-screen stuff-for-the-office menu that appears upon executing /usr/bin/libreoffice. Within this LibreOffice environment, one can also create "presentations" and "spreadsheets". But in practical mission terms, it proves necessary to launch /usr/bin/libreoffice perhaps just once a month.) One constantly, on the other hand, has to create or modify flat-ASCII, plain-text files (perhaps on some rare, and yet significant, occasion even extracting, say, as with the tool /usr/bin/cut, "the column which starts at cursor position 5 and ends at cursor position 9"). Typically such files are not only workstation-configuration files, but also files for one's own concrete mission, such as one's research-and-reading notes, and one's list-of-addresses-and-phone-numbers. - There is some developer promo for this mission-critical tool, in other words for this Swiss Army Knife, upstream of the Debian Project itself, at http://www.vim.org/ (with, for instance, the interesting news that Berlin staged a "Vimfest" in 2017 September). Additionally, Wikipedia has a writeup, https://en.wikipedia.org/wiki/Vim_(text_editor).

So far as the kernel goes, I took the precaution of first examining the Debian GNU/Linux 9.2 e-mail advisory, and then writing into my maintenance log (of necessity using the pre-update vim) particulars of my own kernel arrangement, before typing, as root,  uuu. I also had, and still have, handy an "operating-system-on-a-stick", a bootable Debian GNU/Linux USB, in case something some day goes hideously wrong, with my workstation failing upon some reboot-from-hard-drive - say, because something has gone hideously wrong with some new kernel. Accompanying this "operating-system-on-a-stick" I keep a handwritten record of my disk partitioning scheme, documenting both my main hard drive and the internal-backup hard drive which is the first stage in my multiple layers of data backup. In a disaster situation, I would hope to be able first to boot from the USB, and then manually to mount at least some of the desired partitions. It is part of this tactic that my disk partitions are rather numerous. If just one or two fail in a hard-drive event such as a head crash, all is therefore not lost. 

Here is a pertinent extract from my log, showing how things originally stood with the kernel:

 ((ITEM WHEN="20171007T174631Z"))
__prepare to do uuu in the knowledge that Debian 9.2
  was released today:
  * ((SESSION))
      $cat /proc/version
      Linux version 4.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u5 (
2017-09-19)
      $  
((SNIP))
     $pwd
     /boot
     $ls -l vmlin*
     -rw-r--r-- 1 root root 3128384 Jun 18 09:56 vmlinuz-3.16.0-4-amd64
     -rw-r--r-- 1 root root 4204320 Sep 18 21:34 vmlinuz-4.9.0-3-amd64
     $  
    ((/SESSION))  
__now do the upgrade, and reboot: ((SNIP))

Half an hour or so later, once usr/bin/apt-get had done its work and I had rebooted the workstation, I satisfied myself that the expected kernel replacement had been made, and wrote (of necessity now using the updated vim) a corresponding log update: 

__now check status of kernel:
  * ((SESSION))
      $cat /proc/version
Linux version 4.9.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28)
      $   
      $pwd
      /boot
      $ls -l vmlinu*
      -rw-r--r-- 1 root root 3128384 Jun 18 09:56 vmlinuz-3.16.0-4-amd64
      -rw-r--r-- 1 root root 4204320 Sep 18 21:34 vmlinuz-4.9.0-3-amd64
      -rw-r--r-- 1 root root 4208416 Sep 28 13:27 vmlinuz-4.9.0-4-amd64
      $   
      $pwd
      /boot
      $ls -l vmlinu*
      -rw-r--r-- 1 root root 3128384 Jun 18 09:56 vmlinuz-3.16.0-4-amd64
      -rw-r--r-- 1 root root 4204320 Sep 18 21:34 vmlinuz-4.9.0-3-amd64
      -rw-r--r-- 1 root root 4208416 Sep 28 13:27 vmlinuz-4.9.0-4-amd64
      $
    ((/SESSION))

Here is part of the e-mail I got last Saturday, announcing that Debian GNU/Linux had gone from 9.1 to 9.2 (the e-mail, to repeat, which I fortunately had read before running my habitual uuu update routine): 

The Debian project is pleased to announce the second update of its
stable distribution Debian 9 (codename "stretch"). ((SNIP))
Upgrading an existing installation to this revision can be achieved by
pointing the package management system at one of Debian's many HTTP
mirrors. A comprehensive list of mirrors is available at:

https://www.debian.org/mirror/list


As a special case for this point release, those using the "apt-get" tool
to perform the upgrade will need to ensure that the "dist-upgrade"
command is used, in order to update to the latest kernel packages.

The mail goes on to give explanations for all or many of the changes. To convey the general flavour of the explanations (they are to me rather cryptic, and yet every Debian GNU/Linux end user ought to be skimming them as her or his time and background knowledge may allow), I take one particular case - the explanation given for the changes in my mission-critical tool, the text editor vim:

  Fix several crashes / illegal memory    
  accesses [CVE-2017-11109] 

The cryptic "CVE 2017-11109" is explained by the folks at NIST, at https://nvd.nist.gov/vuln/detail/CVE-2017-11109, in part as follows:

Vim 8.0 allows attackers to cause a denial of service (invalid free) or possibly have unspecified other impact via a crafted source (aka -S) file. NOTE: there might be a limited number of scenarios in which this has security relevance.

Although I do not really know what this means, it don't sound good, and so I am glad vim has been repaired. "CVE" is here short for "Common Vulnerabilities and Exposures". "NIST", in turn, is here one of Uncle Sam's agencies, the National Institute of Standards and Technology - the very same agency, in fact, as ensures through a standards laboratory and a downward chain of formal certifications that American laboratories and factories mean the physically same thing, down to some exquisite nano-precision level, as their foreign peers do, when measuring metres, kilograms, seconds, amperes, kelvins, moles, and candelas.

I was pleased to find that my e-mail came, as is appropriate in a framework of transparent management, from a readily identifiable human source, a particular "Cédric Boutillier <boutil@debian.org>". M. or dr or prof. Boutillier's further Debian-Project involvements are themselves open to public inspection, at https://contributors.debian.org/contributor/boutil@debian/, as transparent management would require.

I was also pleased to find that this e-mail openly and clearly confessed to a small error within the Debian Project:

Due to an oversight while preparing the point release, the usual
update to the "base-files" package to reflect the new version was
unfortunately not included. An updated package will be made available
via "stretch-updates" in the near future.

In terms of my three-way classification of incidents, what is herewith confessed is a quality failure in "Class 2" - not so severe as to require a security-servers remedy, but somewhat pressing, and therefore calling for the servers-for-updates-of-intermediate-urgency.

Later on Saturday, I did a fresh update, and indeed found my system taking care of the "base-files" package, as foreseen  by M. or dr or prof. Boutillier. Here is the pertinent entry in my general maintenance log, from late on Saturday (or early on the Sunday which was 2017-10-08: I was evidently writing at or near the Coordinate Universal Time instant 05:19:27):

((ITEM WHEN="20171008T051927Z"))
__the deficiency reported in Debian Project documentation
  of release 9.2 has evidently now been recitified HUZZAA:
  ((SESSION))
root@veritas:~# uuu
Ign:1 http://[[[[redacted]]]].[[[[redacted]]]].[[[[redacted]]]].[[[[some-national-domain]]]]/debian stretch InRelease
Get:2 http://[[[[redacted]]]].[[[[redacted]]]].[[[[redacted]]]].some-national-domain]]]]/debian stretch-updates InRelease [91.0 kB]
Hit:3 http://[[[[redacted]]]].[[[[redacted]]]].[[[[redacted]]]].[[[[some-national-domain]]]]/debian stretch Release
Hit:4 http://security.debian.org stretch/updates InRelease
Fetched 91.0 kB in 1s (49.3 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  base-files
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 67.2 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://[[[[redacted]]]].[[[[redacted]]]].[[[[redacted]]]].[[[[some-national-domain]]]]/debian stretch-updates/main amd64 base-files amd64 9.9+deb9u2 [67.2 kB]
Fetched 67.2 kB in 0s (185 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 212566 files and directories currently installed.)
Preparing to unpack .../base-files_9.9+deb9u2_amd64.deb ...
Unpacking base-files (9.9+deb9u2) over (9.9+deb9u1) ...
Setting up base-files (9.9+deb9u2) ...
Installing new version of config file /etc/debian_version ...
Processing triggers for install-info (6.3.0.dfsg.1-1+b2) ...
Processing triggers for cracklib-runtime (2.9.2-5) ...
Processing triggers for man-db (2.7.6.1-2) ...
Scanning processes...
Scanning candidates...
Scanning linux images...
Running kernel seems to be up-to-date.
Restarting services...
 systemctl restart boinc-client.service
No containers need to be restarted.
No user sessions are running outdated binaries.
root@veritas:~#
  ((/SESSION))
((/ITEM))

That major event which is not a mere point release, but a transition from Debian 9.z (I presume for a final value of z, perhaps 8 or 9 or 10 or 11 or so) to Debian 10.0 will be handled a little differently, at least under the present configuration of my workstation. In my /etc/apt/sources.list file, I specify that I am working in stretch, which is the codename for Debian 9.x. When Debian 10.0 is released, there will for the be moment be no upgrade. I shall instead for the moment stay safely anchored in Debian 9.z.  Once I am aware that 10.0 is available, I shall have to edit my workstation's /etc/apt/sources.list file by hand (vim will be an appropriate tool), replacing all occurrences of the text string stretch with occurrences of the corresponding Debian 10.0 text-string name (that will be buster; and Debian 11.0, to come perhaps in 2021 or 2022 or so, will, we are already told, for its part be textually designated bullseye). Once the edit of /etc/apt/sources.list is made, I can once again run my double-barrelled uuu updating routine - but now taking still greater care to read onscreen messages and think things through, in the grim knowledge that I shall be facing not a hundred or so package upgrades, as in Saturday's point-release transition from 9.1 to 9.2, but many hundreds.

Those sysadmins who are more adventurous than I will write into their /etc/apt/sources.list not the text string stretch, and not the text string buster, but simply the text string stable - meaning "Please update for whatever Debian release, - be it some 9.x, or some 10.x, or some 11.x, or some 12.x, or whatever - happens to be the latest stable release." Under such a tactic for /etc/apt/sources.list, the full upgrade will be started without further ado. That will no doubt require a reboot, as did Saturday's upgrade from 9.1 to 9.2. But it may be dramatic in other ways also -  perhaps changing some anchor of one's day-to-day comprehension, like the look-and-feel of each of one's five-or-so GNOME desktops, or perhaps changing something fundamental in internals, like the arrangement, or even the basic nature, of system-initializing routines.

5. Further Reading

Debian sysadmins curious about the history of a given package can (although I have not myself done much of this) investigate https://tracker.debian.org/, searching under package name. The tracker.debian.org server has also a further helpful feature. Under https://tracker.debian.org/teams/ is a listing of hyperlinks to "teams". From this I note to my grief that the "Astronomy" team has no current offerings for IRAF or MIDAS (although a heavy-duty package suite, anchored in Uncle Sam's National Radio Astronomy Observatory, is, gratifyingly, available for professional radio astronomy as casacore, casacore-data, casacore-data-igref, casacore-data-lines, casacore-data-observatories, casacore-data-sources, and casacore-data-tai-utc). And many readers of this current blog will want to note, as a potential resource for self-education in cybersecurity, the many packages (about one hundred of them) listed for the "Forensics" team:

aesfix aeskeyfind afflib aimage bruteforce-salted-openssl cewl chaosreader crack dc3dd dfdatetime dfvfs dfwinreg dislocker ed2k-hash exifprobe ext3grep ext4magic extundelete fcrackzip forensics-all forensics-colorize forensics-extra galleta gpart grokevt grr grr-client-templates guymager hashdeep hashrat libbde libbfio libesedb libevt libevtx libewf libfsntfs libfvde libfwnt libfwsi libguytools1 libguytools2 liblnk libmsiecf libolecf libpff libphash libqcow libregf libscca libsigscan libsmdev libsmraw libvhdi libvmdk libvshadow libvslvm lime-forensics mac-robber magicrescue md5deep memdump metacam missidentify myrescue nasty outguess pasco pipebench plaso pompem pytsk rdd recoverdm recoverjpeg reglookup rekall rephrase rifiuti rifiuti2 rkhunter rsakeyfind safecopy scalpel scrounge-ntfs shed sleuthkit ssdeep steghide tableau-parm tct undbx unhide unhide.rb vinetto volatility volatility-profiles winregfs wipe yara

* 

A robust GNU/Linux computer installation requires some kind of hardware Bible, plus some small shelfful of GNU/Linux-general, or still more broadly Unix-general, books on TCP/IP basics, sysadmin concepts (e.g., the mounting and unmounting of filesystems, or again the killing of processes), and the "Bourne Again Shell" (bash).

But in addition to this small shelfful, one needs something on what I have been in this blog posting proclaiming as the principal special feature of Debian GNU/Linux, its package management system. I am 70% sure, after digging off and on over recent months, that the two best current book-length treatments of Debian GNU/Linux package management are the following:

• Raphaël Hertzog and Roland Mas, The Debian Administrator's Handbook. The coverage of package management is thorough, although many other Debian GNU/Linux-pertinent, or in a more general spirit Unix-pertinent, topics are discussed as well. The book is available for surfing and download, under both a Creative Commons licence and a GNU General Public License, at  https://debian-handbook.info/. It is additionally procurable as a Debian GNU/Linux package, debian-handbook (and therefore is procurable even as software is - by issuing, as root, the command apt-get install debian-handbook). Copyrights are asserted for 2003 through 2015. The English-language publication is one of a large suite of translations into various languages, from the original French Debian 8 Jessie. M. (or prof., or dr) Hertzog has also a personal Web site, with blog-style personal English-language professional news, at https://raphaelhertzog.com/. Moreover, his site offers a free newsletter, for the "Debian Supporters Guild" (I think likewise issued in English), to which I subscribed just this week. 
• Frank Hofmann and Axel Beckert, Debian-Paketmanagement. The book, although long, concentrates entirely on packet management, as its title already implies. The content presently constitutes work-in-progress, but seems to me already highly polished. The content is available in German for surfing and download, under a Creative Commons licence, from  https://www.debian-paketmanagement.de/. Although the authors profess themselves optimistic that as their project evolves, an English translation will eventually appear, my own experiments with Google Translate suggest that machine translation works well enough on their particular material. Google Translate, as applied to this particular content, indeed seems good enough to meet not only the needs of readers who resemble me in having shaky German, but also of those who lack German altogether.

6. Concluding Philosophical Remarks

GNU/Linux in general, and most certainly Debian GNU/Linux, gives one a pleasant sense of participating in Real Technology.

The pleasures are in some ways the quasi-monastic pleasures of the scriptoriuim - the pleasures (even the mystique) of record-keeping, of archiving, of editing, and of publishing, as reflected also in amateur bookbinding. Persons who share my weakness for wasting some time on YouTube might in this context enjoy the 2013-03-17  amateur-bookbinding upload by YouTube user "John the Verbose", to a length of 20:50, under the misspelled title "Creating a Grimoire 101: Binding of 'A Refomed Druid Anthology". ("Refomed" is surely a typo for "Reformed".) In my corner of the Web, his video can be reached through the URL https://www.youtube.com/watch?v=aT5toj4EG8o. Shown is a classic High-Middle-Ages and Renaissance technique, with the binding done not onto cloth tapes but onto cords. "John the Verbose" does a delightful job of covering his boards in leather, with the cords producing those classic, harrypotteresque, ridges on his completed book spine. 

The pleasures are in some way also the Victorian pleasures of the mighty steam locomotive (since one has a sense, in GNU/Linux, of not only working with powerful machinery, but of staying rather close to the hot metal).  If I might be allowed to cite YouTube material to parallel "John the Verbose", I would take the tiny 2011-04-24 revival-of-steam upload by YouTube user "Linesider Video", to a length of just 00:45, under the title "60163 Tornado Blitzes Beattock at 65mph". In my corner of the WEb, this video can be reached through the URL https://www.youtube.com/watch?v=9QY_ukezLtM. Shown is a quite long train, its loco working pistons in a most imposingly frenzied cadence. An accompanying comment by YouTube user "Struck2soon", from 2014 or thereabouts, sums it up well: "This still has to be probably the best clip on Youtube of a steam-powered train at full tilt. Lost count of the number of times I have watched it /.../"

Additionally, Debian GNU/Linux induces reflection on Catholic social teaching. Here we have a social movement not driven by commercial motives. The Debian Project charges nothing to the many - putatively the hundreds of thousands - of institutions and individuals downloading from it. The Debian Project is instead driven in essence by the desire, on the part of some 1700 or 1800 qualified software specialists (https://contributors.debian.org/), with perhaps some not-too-close, not-too-controlling, corporate sponsorship,  to serve what I gather Saint Thomas Aquinas called the "common good".

[This is the end of the current blog posting.]