Posted: 03 Dec 2017 04:30 AM PST
My second coloured beard story will be more familiar to those of you who still cherish nursery tales: it is that of Bluebeard.
Most probably originating in Breton legends, possibly with a nobleman who had fought alongside Joan of Arc but was later convicted of serial murders, the story of Bluebeard has been retold in many different forms and media since it was first recorded and published by Charles Perrault in 1697.
Bluebeard is a wealthy and powerful man, with a certain frisson about him, including worrying rumours about his many marriages and disappearing wives. One beautiful young woman – in some accounts, the youngest daughter of his neighbour, against her will – is chosen to be his next wife, and goes to live with him in his extensive palace in the country.
After their marriage, Bluebeard tells his new wife that he must go away for a while, and leaves her the keys to the palace. He explains that she is given complete freedom to explore and use the rooms, but there is one which she must not, under any circumstances, enter. His wife invites her sister and friends over to enjoy the palace with her, and explores its many rooms and riches.
The wife eventually cannot resist entering the forbidden room, which she discovers is covered with blood and contains the bodies of Bluebeard’s previous wives, each hung on a hook. In her panic, she drops the key in the blood, rushes out, locks the room again, and tries to clean the key. She discovers that she cannot remove the blood from the key, so decides to flee the palace the next day.
Bluebeard then returns unexpectedly, discovers the key still covered in blood, and flies into a rage. He tells his wife that she will join those corpses, but allows her one last prayer before he kills her too. The wife then goes out and awaits the arrival of relatives whom she is expecting. Bluebeard calls her down, and prepares to murder her. Just in the nick of time, his wife’s relatives arrive and kill Bluebeard.
His wife inherits his palace and wealth, and has Bluebeard’s dead wives buried, and lives happily ever after (as she always had to).
This story has been retold in several books containing nursery stories such as that of Cinderella and the Sleeping Beauty. Its account of a horrific serial murderer is clearly not for telling in explicit detail. Although words can remain subtle and leave much to the imagination, it is a tough challenge for the artist to tell visually. Even showing the contents of the forbidden room seems unwise for such young and impressionable audiences, but it is central to the story.
The most complete series of illustrated pages, containing the story in rhymed verse and illustrations, appears to be that made by Walter Crane, one of the best illustrators (and painters) of nineteenth century Britain. I also have a set of four engravings made by Gustave Doré, one of the best illustrators and painters of nineteenth century France. After those, I show three illustrations by two other artists, for their individual interest.
Walter Crane (before 1911)
These pages (above and below) form a spread. The words at the top of the page below have been cropped off, and read:
Gustave Doré (c 1862)
Doré provided a set of four engravings to illustrate the original French, taken from Charles Perrault’s text of 1697.
The first shows a pop-eyed Bluebeard handing the keys to his young wife just before he departs. Doré’s characterisations are wonderful here, particularly of Bluebeard, who appears to be a cross between a benevolent uncle and an evil gnome.
Doré follows the original text, in which the wife explores the riches of the palace with her sister, as shown here.
He skips the tricky section of story altogether, it appears, and rejoins it as the wife’s two relatives come racing up to the château on horseback.
The final engraving shows those relatives about to kill Bluebeard, leaving his wife still shocked in the background. Doré works in some wonderful detail here, in the amusing griffon watching proceedings from its place on the wall, and the caduceus/sword carved below it.
Harry Clarke (before 1922) & Walter C Kiedaisch (1903)
I have two illustrations made by Harry Clarke, who seems to have been an admirer of Aubrey Beardley’s style, with even sharper elements of caricature.
That is the only image in which I have seen Bluebeard’s beard depicted as being blue.
My final illustration is by Walter C Kiedaisch, and was made as a New Year’s Day print with which to celebrate the New Year in 1904.
I presume that this must have been aimed at an adult audience, for its explicit display of the heads of Bluebeard’s previous wives. The artist also plays on racial stereotypes, which is quite uncalled for.
This illustration is odd for its indication that ‘Miss Bluebeard 1904’ calmly walks arm-in-arm with her murdering husband after she has seen those heads. Kiedaisch may have been referring to one of the other, changed re-tellings of the story.
As an exercise in visual storytelling, Crane and Doré’s solutions appear acceptable for the nursery, and are lessons in making parts of a story implicit even when working in such a visually explicit medium. I still can’t think why any parent would ever want their young children to know this story. Can you?
Filed under: General, Language, Life, Painting
Posted: 03 Dec 2017 12:00 AM PST
When we were told that High Sierra was going to fix bugs and introduce the new APFS file system, none of us could have expected what has happened since its release on 25 September. Yes, there have been some significant improvements in its bundled apps like Photos, and some bugs – probably including the scheduling of Time Machine backups – appear to have been fixed.
What has been most prominent about High Sierra, even reaching the general news media, have been some glaringly obvious bugs in its security. Last week’s crisis over the root user vulnerability was the most serious, as it affected every single Mac running any version of High Sierra. In the end, when Apple was shamed in a tweet, its engineers responded magnificently, and all was patched in less than twenty-four hours.
Commentators are right to question Apple’s quality management, as I have done previously, but the buck shouldn’t stop there. There’s more to High Sierra’s problems than just inadequate checking of code and flimsy pre-release testing. We need to drill down beyond these proximal causes if we are to understand what is going wrong.
For me, the most striking observation about last week’s vulnerability, and the previous password hint bug which made some encryption near-useless, is that these bugs occurred in code which had previously been working well in Sierra and earlier. The same is true of the bugs in High Sierra’s new version of Disk Utility, which I and many others have been complaining about.
These are indicators that Apple is in the process of rewriting a lot of macOS. In the case of the root user vulnerability, this was in Open Directory, whose source code may well date back ten years or more. It has been my contention that macOS-only code, such as Time Machine, gets considerably less resources than that which is shared with iOS, but that doesn’t explain why, if such macOS development is being poorly resourced, Apple’s precious engineers are busy rewriting systems such as Open Directory, when there are so many other demands.
It also makes sense that, when there is a lot of code development taking place, code checking and testing tends to be rushed, and serious bugs like these can slip through into release. Apple must surely have proven procedures in place, so here the pace of development seems to have exceeded the capacity for checking and testing.
One simple reflection of what is happening in Apple’s software engineering is the change in version number for Open Directory, which leaped from 417.50.4 in 10.12.6 (released 19 July) to the current 483.20.7 in 10.13.1 updated (on 29 November). If Apple has numbered versions consecutively, that is 66 major version increments in four months; even if High Sierra started at 450.0.0 it still appears a prodigious pace.
Other clues come from what is happening in Apple’s use of Swift. Alexandre Colucci, in his Timac blog, tracks the use of Swift in iOS and macOS, and has found its use has grown from a mere 10 binaries in macOS 10.12.1 (released 24 October 2016) to 23 in macOS 10.13.1 (31 October 2017). Many of these are components which don’t appear to have undergone major external change.
We have been complaining about Apple’s apparent under-investment in macOS (and Mac hardware), when perhaps it has been investing more heavily than ever before. When we were promised that High Sierra would ‘fix bugs’, that may have been code for ‘our engineers are progressively re-writing much of macOS’, although not necessarily entirely in Swift, just yet.
Thus far, I think that we have evidence of what is happening, but from here we can only speculate as to why Apple is doing this now. Rewriting much of such a huge and protean operating system is not something that companies undertake lightly: there must be a compelling reason why this is occurring now.
Two good reasons for this sort of effort are maintainability, and hardware change.
Many years ago, when I was assessing its suitability for use by my team, I persuaded the author of a large and very sophisticated mathematical model to provide me with its source code. It took but a few minutes to discover that it was written in spaghetti Fortran, completely unstructured, and that it would actually have been quicker and cheaper to have re-written it from scratch than trying to use its source.
It is quite feasible that many of the older nooks and crannies in macOS have become similarly unmaintainable, although they would normally be revamped as part of a long-term rolling programme, and not all at once in a rush.
There may be one clue here in Apple’s sudden interest in its own EFI firmware, another new engineering task in High Sierra. Maybe the deadline which is driving all this activity has already been set in the introduction of new hardware next year.
I’d hazard a guess that those new systems include custom systems-on-a-chip (SoC), as are already used in the latest MacBook Pro models, and are rumoured for other imminent products. Once you need to move your code onto auxiliary processor systems, it’s a great help when it is modern, structured, and written in a language like Swift.
Apple would clearly never have wanted the embarrassment of last week’s root user vulnerability. Maybe in the long run it will prove a small price to pay for its ultimate goal in 2018.
Filed under: Macs, Technology, Uncategorized
|You are subscribed to email updates from The Eclectic Light Company. |
To stop receiving these emails, you may unsubscribe now.
|Email delivery powered by Google|
|Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States|