Monday, 16 October 2017

Toomas Karmo: Remarks, Including Duly Diligent Advisories to Organs, on the R.F.Garrison 2017-10-14 Memorial

Some mementos of Prof. R.G.Garrison, by way of a snapshot from one of my approximately five GNU/Linux GNOME desktops. Anticlockwise, from top right: a /usr/bin/xterm window, configured to display some of my casenotes on the Garrison database conservation problem (in fact - perhaps helpfully? - a formal report which I wrote around 2009, for several individuals in Prof. Garrison's circle); performers of Chilean music at the Prof. Garrison's 2017-10-14 memorial; a /usr/bin/xterm window, configured to display my sole casenote for a never-completed biographical essay on Prof. Garrison (although it was I who wrote this note, its pronoun "I" refers to Prof. Garrison); a framed photograph, as displayed at the 2017-10-14 memorial, of a meeting between the very Catholic Pope John Paul II and the very nice-but-not-Catholic Prof. Garrison, in the context of a Vatican Observatory "Summer School" at which Prof. Garrison was lecturing. - Popes tend to be friendly toward astronomy without being knowledgeable. A wonderful photo exists of John XXIII examining 1960-era gear which I think was used by the Vatican Observatory to construct a line atlas of the iron spectrum. (Iron absorption lines are prominent in the spectroscopy of the cooler stars, such as our own Sun.) The Pope who got farthest in astronomy was amateur observer Paul VI. Paul VI was said to have liked visiting the Castel Gandolfo telescope, near Rome, which back in the 1960s and 1970s was pretty much all the Vatican had. Nowadays, Castel Gandolfo is light-polluted, and the serious work gets done in Arizona, at the "Vatican Advanced Technology Telescope" (VATT).  Francis I for his part is too busy in Vatican City to spend much time at  Castel Gandolfo, and the Arizona VATT mountaintop will surely be too remote for him to visit.  - As is usual with Web publications through blogger and blogspot, the image can be enlarged through 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"): 4/5. Justification: There was enough time, given an unvaoidably brisk overall work tempo, to write out most or all of the appropriate points to reasonable 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.

  • 20171020T0131Z/version 2.1.0: Kmo added a graphic. He  reserved the right to make tiny, nonsubstantive, purely cosmetic, tweaks over the coming 48 hours, as here-undocumented versions 2.1.1, 2.1.2, 2.1.3, ... .
  • 20171017T1825Z/version 2.0.0: Kmo, running about two and a half hours late, finished converting  his finegrained outline into coherent full-sentences prose. He reserved the right to make tiny, nonsubstantive, purely cosmetic, tweaks over the coming 48 hours, as here-undocumented versions 2.0.1, 2.0.2, 2.0.3, ... .
  • 20171017T0414Z/version 1.0.0: Kmo had time only to upload a moderately polished finegrained outline. He hoped to convert this into a short full-sentences essay by UTC=20171017T1600Z.


[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.]




On the Saturday which was 2017-10-14 came the event I had long been anticipating with unease and worry. On that afternoon, many tens of people gathered in the Common Room of Massey College, in the physical and intellectual centre of the University of Toronto, for their communal memorial to Prof. R.F. Garrison. 

I discussed Prof. Garrison's scientific and community contributions in my blogspot posting of 2017-08-14 or 2017-08-15, headed "Prof. Robert F. Garrison Remembered (1936-05-09/2017-08-13)". Now I have to discuss his memorial. I will try to do so in the spirit of my companion blogspot posting this week, on the Innermost House Foundation. I will in a particular way try to follow the spirit of Innermost House as I discuss shadowy, troubling, things - my presumed surveillance officer Z____ from the University of Toronto, and his connection (or rather, in my respectfully submitted estimation, in his present lack of connection) with the organs of Russian state security. 

****

Seldom, if ever, have I seen a memorial so well planned and executed. Toward the end, music was delivered in the Chilean tradition dear to Prof. Garrison, who through much of his career had been a guiding mind at the David Dunlap Observatory's erstwhile Andean outstation. My afternoon's unhappiness was relieved, at this Chilean moment, by seeing a few couples even dancing.

Additionally, there was music of the highest professional calibre from one of Ontario's leading vocal ensembles, the Nathaniel Dett Chorale. (From https://en.wikipedia.org/wiki/Nathaniel_Dett_Chorale, one gathers that President Obama had the good fortune to hear this ensemble performing at his 2009 Inauguration.)

And there were speeches.

Here I treasured not only Garrison family reminiscences, and words from variable-stars authority Prof. John Percy, and of course remarks from Prof. Garrison's Shelton-family collaborators regarding Supernova 1987A, but also a set of remarks from Prof. Garrison's sometime Ph.D. student Prof. Richard Gray (Department of Physics and Astronomy, Appalachian State University). As I remarked in my blogspot death notice for Prof. Garrison back in August, Prof. Gray is the lead author, with Fr Chris Corbally, S.J. (Vatican Observatory Research Group, Arizona) his collaborator, of the currently authoritative work on stellar spectroscopic classification.

I was touched that upon timidly entering that big Massey College space, I was so promptly greeted by Prof. Garrison's widow. She was under no obligation to be specially warm toward me in her crowded assembly - standing as I do at the mere periphery of Toronto scientific life, and having not even been properly diligent in visiting Prof. Garrison, in his capacity of mentor, during the final phases of his illness.

I am pained that I did not correct dots correctly, and so did not take the correct initiative in greeting my astrophysics-coursework classmate, through fully three years, Adam Muzzin (now Prof. Adam Muzzin,  Department of Physics and Astronomy, in Ontario's York University). He for his part had directed to me a glance of friendly query.

I was touched that I was greeted warmly by various former DDO colleagues, several of whom would now have adequate, or arguably adequate, reasons for personal coolness. It seems to me that in the just-mentioned portion of Saturday's socializing there was an element of generous understanding - a sort of tacit, generous, acknowledgement that in the destruction of 32 out of the total 77 David Dunlap Observatory and Park hectares, and in my failure to save so much as a single tree from the commercial ambitions of the De Gasperis and Muzzo families (they are acting through the "D.G. Group" subsidiary "Corsica"), and in my concomitant loss through legal bills of the bulk of my life savings, I did not now have to be made a target of reprisals. (I do, after all, plead - here today on this blog as on earlier occasions - that I did pretty much everything I could think of, from 2007 right up to 2014 or 2015, in the teeth of opposition, and that my various actions have in their seeming recklessness harboured also an element of prudence. Who could ever have predicted not merely that the greater part, but that, astonishingly, the entirety, of the Ontario Municipal Board (OMB) and Divisional Court work would in the end prove futile? Was it not a reasonable supposition when the OMB hearings kicked off, back in the northern-hemisphere summer of 2012, that the conservationists, under the aegis of my friends the Richmond Hill Naturalists, would succeed in blocking at least a few of the most offensive of the developers' projected Hillsview Drive McMansions, so close to the main dome? The expectation would surely have been reasonable - I do not say, reasonable back home in Estonia; but I do say, reasonable in so well governed and law-abiding a jurisdiction as Finland, or again Switzerland. And are we not in general right in according to the Canadian legal system the same level of confidence as we habitually accord to, at any rate, Finland and Switzerland?)

****

In the course of conversations in that big Massey College room, I obtained a point of scientific importance, which I now set down to supplement what I was able to write here to blogspot on 2017-08-14 or 2017-08-15, in discussing Prof. Garrison's database: Contrary to what I had feared, the physical media on which the database was stored are safe - and this despite my own lack of diligence, as discussed in my posting of 2017-08-14/2017-08-15. It will suffice for a couple of us now to work on the problem together. We will have to get the database once more running as an application under Prof. Garrison's antique OS/2 operating system, whether running the legacy hard drive, or better an exact byte-by-byte mirroring of it, either on his (as I learned on Saturday, conserved) workstation, or (better?) on some other. (I myself have some documentation for OS/2, and conceivably even an installation CD.) - The run will of course be the first step toward doing a flat-ASCII database dump, for which I think I can work out the appropriate SQL commands, I think drawing in part on some private casenotes regarding the organization of Prof. Garrison's SQL tables. With flat ASCII safely in hand, we can hope to port the SQL tables to some modern database-managing application, running under some convenient modern flavour of GNU/Linux. 

****

From that thing of joy which is the database, I turn now to a darker aspect of the Saturday afternoon. (That afternoon does as a whole remind me of a passage in Homer, about the minds of men being cast over with varying sunshine and cloud, as Olympus may from moment to moment decree.) Was I under surveillance; and if "yes", then on the part of what organ, or even alliance of organs?

We are told to pray for our enemies. However, I do not have enemies, at any rate in the sense of having people I am out to punch, kick, sue, or even in vigorous ways humiliate or mock. It is true that I imagine, perhaps especially in the morning shower, fancy courtroom scenes, involving this person and that. In these scenes, I reduce this person or that to a pulp, quivering in the dock, as I quietly pose question upon incisive question, in my imagined capacity of amateur advocate. In my flattering scenario, I end by suavely murmuring to my now-weeping victim and the judge, "Thank you. That was helpful." And afterward, outside the courtroom, I am urged by my learned opponent, perhaps property-developer advocate Mr David Bronskill, to enter the legal profession, so as to ornament the Ontario Bar. At this point one switches the flow of hot water briefly over to the Icy Cold, and then one reaches for the towels.

Enemies in the sense just sketched are the proper province of the schoolyard. In a schoolyard, I imagine noses could on occasion be bloodied and clothes on occasion torn.

I did not myself suffer such things to any notable degree. When one looks at the lives of others, who did suffer them, one applauds above all the stance of eventual mathematical physicist James Clerk Maxwell (1831-1879), on his first day at the Edinburgh Academy.

When I started school early in the September of 1958, not knowing English, and to my alarm seeing children in boisterous play, I wailed in the only language I then knew - I see in my mind's eye that noisy Nova Scotian classroom, with its firewood piled high in a small side-room, as though it were yesterday - Aga  Ämi, millal siis õpitakse?" - "But Mummy, when, then, are they going to be learning?"

Young James, on the other hand, got well and truly worked over. We are told in biographical notes (cf http://www-history.mcs.st-andrews.ac.uk/HistTopics/Maxwell_House.html) that he came home "with his tunic in rags", "his neat frill rumpled and torn". But, we are also told, he came "/.../ excessively amused by his experiences, and showing not the smallest sign of irritation".

So either you can have enemies, or you can not have them (instead diverting energies into, perhaps, mathematics), and I choose the latter.

Now, O Gentle Reader, comes the topic of people for whom I myself wish no ill, and toward whom indeed I try to be correctly sympathetic, sorry and helpful, but who all the same may have it in for me in my past, present, and future capacities as a DDO troublemaker. In particular, there is the high academic administrator Z____, remaining through much or most of Prof. Garrison's memorial immobile, at practically the sole spot in Massey College's big public space which gave him a commanding view of everything important. I, mounting countersurveillance in response to anticipated surveillance, was of course also pretty much immobile, and of course likewise in a good vantage point. We stayed at all times ten, or so, metres apart, without exchanging the slightest tokens of recognition.

It was Z____ who was the chief 2003-era or 2007-era architect, within the University of Toronto at the ordinary Departmental level, as opposed to the more exalted decanal and Vice Presidential  levels,  of the University's eventual, widely condemned, 2008 DDO sale. I am not at all sure that Z____was on a surveillance mission. If he was, I have no proof that Z____'s interest lay in me. But it is true that of all the persons in that room, I was the sole DDO troublemaker, the Visible Tree-Hugger. If Z____ had anyone else in his sights in that room, then he was poorly briefed, and was wasting both his own time and the time of his masters. This would seem to me uncharacteristic of his sharp intellect. It is also true that (I repeat) we squared off, as people must in all spookshops be trained to do - in MI5, in MI6, in Mossad, in FSB, in Estonia's Kaistepolitsei - with the two of us far apart, each thoughtfully selecting the spot  physically appropriate for (so to speak) his particular set of Embassy duties. All I can do here is to put everything on public record, herewith assuring Z____ that I mean him no harm.

****

It will in addition be asked: Was Z____'s putative Saturday operation linked to FSB-cum-SVR?

Russia has been very active indeed in the last 48 or 72 or so hours, reading my blog with an assiduity only seldom precedented in my personal blogspot operations. Whether the so-recent downloading was linked to Z____, I cannot say.

Trying to be helpful to everyone, I make the following points:

  • I am most desperately sorry for the current situation in Russia. I wish Russia no ill. Quite the reverse - I wish Russia to turn aside from its current trajectory, which can only end badly. (On the current trajectory, things hold together, more or less. for twenty years, or even for thirty. Then, however, Vovan Vovanitch is dead - he may, I grant, as a person from my own generation, now reasonably aspire to high old age, in imitation of Mr Robert Mugabe - with the oilwells running dry (in their own eventual, sad, imitation of Britain's now-departed "North Sea Oil"). What comes next? On the current trajectory, the Russia of the mid-century has no world-class universities, no manufacturing capable of competing with China and Germany, and perhaps not even any correctly managed forests. So I think people to the east of the Urals will have to throw their mid-century political lot in with China, and that the people to the west of the Urals will have to do all in their now-limited power to avoid becoming a failed state. I know we in Estonia, surveying this impending meltdown from our own side of the Narva River, may not always be too keen on east-bank wild dancing, on east-bank vodka binges, on east-bank balalaikas,  on those teary east-bank folk songs - I do, on the other hand, in a certain russophilia, applaud two such songs in my blog posting of 2017-03-20 or 2017-03-21, headed "A Russia Situation Appraisal, for Kmo Case Officer and Others" - or on the noisy, wearisome, kinda-sorta American-patriot exaggeration of legitimate love-of-родина-or-отечество. But Russia deserves something better than failed-state status. A country with Tolstoy, Rachmaninoff, geometer Lobachevsky, and theoretical physicist L.D. Landau in its history deserves better.)
  • I appreciate that my presumed FSB or SVR case officers are unlikely to themselves be recruited from the criminal and near-criminal classes. The old rule from the pertinent recruitment folklore - The organs check you out, they find out if you fight dirty in a street brawl, or again are capable of killing some small animal; if those initial observations are promising, the organs set up a situation, harvest the resulting компромат, and make you a recruitment offer you cannot refuse - is in their case unlikely to apply. They do, to be sure, know who pays their nice salaries. But they are themselves no criminals, merely analysts - not even all that different from me in their training, their literary and musical interests, and their temperament. There is not the slightest point in shaking a fist at them.
  • It is interesting that FSB and/or SVR should be working hard on my case (with all that blogspot downloading, now and in past months, and perhaps also with that pleasant pair of sex workers waiting for me in vain, that night I emerged from the Toronto Hacklab - unless, indeed, it was the DDO developers, in place of FSB or SVR, who engaged the pleasant, talkative,  молодой человек and the pleasant, silent, дебушка; but I really do not think Italians are so detail-oriented). All the same, I cannot in the legitimate Russian public interest encourage Russian officials in fostering illusions. The organs need NATO dirt. Mere dirt on a Canadian municipal matter, such as DDO, is of scant Foreign Ministry utility. This is a point I have already covered in all the correct detail - right down to the matter of professional services putatively rendered to a few York Region officials, perhaps outside Richmond Hill, by our erstwhile local Natasha (now said to be an "investor" in one of the warmer parts of the Union, and I think unconnected in her professional life with the just-mentioned pleasant молодой человек and pleasant дебушка)  - in my blog posting of 2017-03-06 or 2017-03-07, headed "Open Letter to My FSB/SVR Case Officer, with a Query on Practical Russian". 
  • Racking my brains for some way the FSB or SVR could play the DDO card, I still come up with nothing beter than what I was able to offer in the posting of 2017-03-06 or 2017-03-07: if (if, if) you want to run a big public-relations risk - and I advise against it - then first buy up some of the DDO developers' lots, as currently promoted at http://myobservatoryhill.ca/, and then with diplomatic fanfare turn them back into greenspace. Explain, as the rootballs of birch saplings enter newly humus-remediated soil by way of a graceful botanical tribute to the родина or отечество, that Vovan Vovanitch is "as a worried friend of Canada doing for Canadian natural and scientific heritage what Canada, in its hour of need, lacked the courage and skill to do".
  • In the a priori improbable event that FSB or SVR in future approach Z____, exploring the prospects for collaboration, Z____ should proceed circumspectly, on no account doing anything which could later be construed by some troublesome blogger (by me, for example) as the accepting of a personal benefit. The sole question which can in that a-priori-improbable contingency of an approach be allowed to form in Z____'s cranium is, "What might I now do, working with these now approaching three-letter agencies, to protect the telescope I helped harm in 2008?"
  • All parties should feel free to consult me if necessary. I am not haughty; I am not proud; I am not stiff; I do not carry on like some doctrinaire Estonian-diaspora Cold Warrior, much though it might sometimes sound that way: if people come to me, I will give what help I can. Admittedly, I might, even while giving help, seek guidance from such Church or NATO authorities as might seem to me from hour to hour, in the rapidly evolving situation, appropriate. 
[This is the end of the current blog posting.] 

Toomas Karmo: Open Letter to the Innermost House Foundation

To accompany this small writeup on the Innermost House Foundation, I choose not to reproduce photos of Innermost House itself - for photos, the reader should visit http://www.innermosthousefoundation.org/ - but a graphic on themes which will be found on due reflection to touch on the Innermost House mission. From top right, clockwise: a /usr/xterm  window configured to display some private flat-ASCII (plain text) casenotes on Russian affairs; the Munich memorial to a wartime White Rose dissident trial (from https://en.wikipedia.org/wiki/White_Rose); a /usr/bin/xterm window configured to display some flat-ASCII (plain text) private casenotes on the concept of healing; the memorial to victims of repression which currently stands in Lubyanka Square, opposite secret-police headquarters (from https://en.wikipedia.org/wiki/Solovetsky_Stone). As is usual with Web publications through blogger and blogspot, the graphic can be enlarged through 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"): 3/5. Justification: There was enough time to write out essential points, but not enough time for being very careful or thoughtful. (It was necessary this week to upload two, in a subtle way mutually supporting, pieces - this one, and also a piece on the Garrison memorial, in that memorial's  dark potential University-of-Toronto surveillance, and also FSB-SVR-surveillance, setting). With two pieces to write, time runs short.

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.

  • 20171017T1953Z/version 3.1.0: Kmo added a top-of-posting graphic, intended to reinforce what he judges to be pertinent Innermost House themes. He reserved the right to make further tiny, nonsubstantive, purely cosmetic, tweaks over the coming 48 hours, as here-undocumented versions 3.1.1, 3.1.2, 3.1.3, ... .  
  • 20171017T1557Z/version 3.0.0: Kmo finished converting his fine-grained outline into a short full-sentences essay. He reserved the right to make further tiny, nonsubstantive, purely cosmetic, tweaks over the coming 48 hours, as here-undocumented versions 3.0.1, 3.0.2, 3.0.3, ... .  
  • 20171017T0408Z/version 2.0.0: Kmo uploaded a fairly polished fine-grained outline. He hoped to covert this into a short full-sentences essay by UTC=20171017T1600Z.
  • 20171017T0002Z/version 1.0.0: Kmo only had time to upload a coarse-grained outline. He hoped over the coming four hours first to upload a fine-grained outline, and then to convert the outline into a short full-sentences essay.


[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.]



I was initially suspecting I would be able to make this the week for uploading "Part P" of my long essay on the "Philosophy of Perception, Action, and 'Subjectivity'". However, events have conspired to delay that anticipated upload by at least a week. This week I have to deal with unexpected, welcome, incoming American correspondence, from the Innermost House Foundation. 

The Foundation continues philosophical initiatives of Emerson and Thoreau. Before reading the not-very-adequate writing that I have to offer on my own part, as a sort of respectful open letter to the Foundation, I would urge my readers to spend at least a few preliminary minutes examining the Foundation's Web outreach at http://www.innermosthousefoundation.org/. Special attention should be devoted to three things: 
  • to the images, both still and ciné, of the physical Innermost House (as viewed from the outside, a classic Thoreauvian cabin; but as viewed from the inside, a cosmos of minimalist elegance in the quiet perfection of its hearth, of its book case, of its writing alcove, of its washing and food-preparation spaces, and of its sleeping loft: my hero Thoreau was, by contrast, a scruiffy, none-too-elegant bachelor, who is said to have lugged his washing from cabin (I have hiked this modest hike) down to Concord, where his Mum took care of it);
  • to the page on "Craft", namely http://www.innermosthousefoundation.org/craft/
  • to the page on "Connections", namely http://www.innermosthousefoundation.org/connections/.
Having written this autumn on the Foundation, I unexpectedly received a reply this past week, from Foundation officer "N.N." My replies to much of what N.N. asks  (he wonders, for instance, how I learned of the site) will be not quite right for insertion into the public glare of a blog, being in fact in some respects merely dull. I do, on the other hand, feel I should blog for the general public benefit, by way of an open letter, my attempt - however clumsy, however abbreviated - to answer the most important of N.N.'s sequence of questions. Here I quote verbatim: 

You speak of our "witness." That interests me. I wonder if you would be willing to say a little more of what you mean? You clearly foresee dark times ahead, and Innermost House is significantly a response to such times. What is the nature of our witness? What purpose do you believe it is meant to serve? 

In responding, I write as a Catholic in the theological traditions of G.K. Chesterton (1874-1936), Peter Maurin (1877-1949), and Dorothy Day (1897-1980). This tradition is nowadays articulated in the Catholic world by the "Distributist" and "Catholic Worker" movements, as at http://distributistreview.com/ and http://www.catholicworker.org/

I write also as a Cold War survivor, mindful in a pained way during many of my waking hours, day upon sombre day, of Estonia's one Reich occupation (1941-1944) and two Soviet occupations (1940-1941, 1944-1991). 

****

The Innermost House witness seeks in my judgement  to serve a purpose of love, more specifically the purpose of breaking chains (of setting prisoners free). It calls to mind the ancient Hebrew prophets, and their close modern equivalents - in the 20th-century Reich, the White Rose (https://en.wikipedia.org/wiki/White_Rose), and in the 20th-century Union, the repressed dissidents (among them the Isaiah-or-Jeremiah figure who was Aleksandr Isayevich Solzhenitsyn (Александр Исаевич Солженицын; 1918-2008)). The Innermost House witness is in my judgement an affirmation that spiritual freedom is possible even under adverse cultural conditions.

(A) Just as we were not free back in the 20th century if we allowed into our brains and hearts the Soviet "General Party Line", or generalnaya liniya (formally the генеральная линия), or its Reich equivalent, so we are in the present day not free if we allow into our brains and hearts the General Party Line of consumerism.

The latter-day Line - an exhortation to hedonistic, somnanbulistic, egoism - is urged on us in various ways.

It forms a backdrop to our politicians' various, ostensibly and superficially competing, forms of vote-scrounging, in a perversion of authentic parliamentary government - "Vote," in all cases, from the exalted Donald Trump right down to the most pitiable municipal councillor, "for the Great Me, in whom you see a reflection of the Great You, in all its self-seeking."

It is arguted intellectually (somewhat as the генеральная линия was argued intellectually by the "theoreticians" in the Union's various Departments of Philosophy) by the extensive "Business" sections of our contemporary bookstores.

It is urged in crudely hypnotic sound-and-image techniques (already explored with verve and skill, back in the Reich, on monochrome celluloid, by cinéaste Leni Riefenstahl) over our contemporary airwaves and Web.

(B) We are again in the present day not free if we allow into our brains and hearts the General Party Line of consumerism's principal contemporary competitor, religious fundamentalism (be it Christian or non-Christian - and if Christian, then be it Protestant, Eastern Orthodox, or Catholic).

Freedom consists in living in truth.

Freedom in this sense can be lost in the midst of contemporary material culture, and can equally be lost in the church pew. Visible, institutional, Catholicism can function, despite its authentic charisms, as one of the "principalities and powers" from which the authentic Bride of Christ, the Church not-here-fully-visible, is to set us free.

Conversely, freedom in this sense can be gained even behind the barbed wire of the Stalag or gulag, or even in the teeth of ecclesial repression.

Living in truth involves mindfully - reflectively, deliberately, wakefully - living our dual nature, both (a) as sentient animals immersed in what now proves to be a radically fragile biosphere and (b) as analyzing and valuing subjects, engaging with that same fragile biosphere in transcendence.

People live under the first heading when they (e.g.) diligently, mindfully, mend some article of clothing, or diligently, mindfully, plant seeds.

People live under the second heading when they engage, in a duly diligent, mindful, self-effacing, way, in science and scholarship. Still more important, however, than such scientific and scholarly missions - vital though these are - is a trio of activities by no means confined to élites: (1) the diligent thinking-through of practical problems (as when we plan a garden or devise a tool: many people can do this); (2) loving service to others (as when we help nurse the sick, comfort the homeless, or administer a municipality: again, many can do this, including those lacking advantages of intellect and education); and (3) prayer (this is even more open to everyone than are the abundant concrete, materially effective, opportunities for loving service - as can be seen from, for example, the contemplative lives of homeless Saint Francis of Assisi and homeless, mentally ill, Saint Benedict Joseph Labré).

The two kinds of living are not sharply distinct. It is in many cases in and through living under the first heading that people come to "have Life, and have it abundantly" (John 10:10) under the second heading. Many people can therefore truthfully say, even in the spirit of John 10:10: I do not find myself saying many prayers. And yet my life - its labours, its sufferings, its joys (including its moments of apprehended beauty) is itself a prayer. 

Innermost House - in its shelves of classics in their fine bindings; in its austerely meatless meals, cooked over coals in what looks like a Rumford hearth; in its communion with the forest or savanna fauna of California; and to my mind above all in its celebration of crafts, as documented at http://www.innermosthousefoundation.org/craft/ - affirms the possibility, under the current adverse cultural conditions, of making our lives a prayer.

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


Thursday, 12 October 2017

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 rootuuu. 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.]