From the Mine Wars to Bloody Harlan, the coal miners of Appalachia have a long and storied history of fighting for the rights and protections often denied to them while mining the region’s rich bituminous coal. So when men who had worked their whole lives underground began dying in increasing numbers from a chronic respiratory illness, their lungs literally blackened from years of inhaling coal dust, Appalachians did as they have often done. As labor studies scholar Alan Derickson writes, they organized a grassroots movement to challenge the deadly working conditions in the coal mines.

Coal mining has always been a dangerous job, but by the 1950s, technological advances that automated some of the miner’s tasks, like the continuous miner, had succeeded in reducing the number of deaths and injuries from mechanical accidents. But the new equipment also significantly increased miner’s exposure to coal dust, leading to a spike in the number of workers afflicted by black lung disease.

Black lung, also known as coal workers’ pneumoconiosis, is a terminal respiratory condition caused by long-term exposure to coal dust. Particles of dust settle into the lungs, progressively weakening the organs and causing shortness of breath and coughing fits. Later stages of the disease cause chronic bronchitis and emphysema. Because black lung can lie dormant for years, appearing long after a miner had left the job, coal operators denied the connection between coal mining and black lung for decades. According to the Department of Labor, more than 76,000 miners have died from the disease.

From past experience, miners knew that neither the companies nor the state and federal legislatures they controlled through hefty donations would ever voluntarily agree to regulations to protect the health of workers. Even the UMW, the union that spearheaded many of the turn-of-the-century battles against the coal operators, couldn’t be counted on for support. Years earlier, union leadership made an agreement that tied industry funding for their pension plan to the union’s ability to limit and control strikes and work-stoppages. The pressure would have to come from from the miners and their families themselves.

The first rumblings of the movement came in the aftermath of a 1968 mine explosion in Farmington, WV, that killed seventy-eight men. Physicians like Dr. Donald Rasmussen, who had spent his career practicing medicine in the coal fields, took the lead. They were joined by the newly-formed West Virginia Black Lung Association, a coalition of disabled coal miners, local union leaders, and other mine workers.

By January of 1969, they had enough momentum to muster over 3,000 miners to Charleston, WV, to hear the initial draft of a bill that would compensate miners who were sick with the disease. Then came the strikes. The West Virginia legislature began hearings on the bill, setting off walkouts at mines across the state. “No law, no work,” they said, as supporters gathered at the state capital to witness the proceedings and protest the opposition. Eventually, over 40,000 workers participated in the strike, effectively bringing the state’s mining sector to a halt until the bill was passed in March of that year.

Over the next year, the black lung movement would succeed in getting similar legislation passed at the federal level, including the 1970 law that created the Occupational Safety and Health Administration (OSHA). President Nixon wavered on signing the first round of laws in December 1969. In a show of the organizing power and influence held by the miners, a wave of walkouts reverberated across the West Virginia coal fields. Within “a matter of hours,” Nixon announced the signing of the bill.

Functional CSS (or Atomic CSS, or Utility-first CSS) is the latest thing to have blown my mind. This post is my attempt to explain why I think it's amazing and why all of the common arguments against it are misguided or rooted in outdated ideas.

What the heck is it?

Functional CSS basically means that you have a ton of tiny, single purpose classes that are named based on their visual function.

For example, instead of something like this:

<divclass="profile-card">
  ...</div><style>.profile-card{padding: 20px;margin: 20px;color: #eee;background: #333;border: 1px solid #555;}</style>

You'd instead just do this:

<divclass="m-5 p-5 text-gray-light bg-gray-darker border border-gray-light">
  ...</div>

So instead of actually writing any CSS, you just apply the utility classes for each of the CSS rules that you would normally have written.

But I don't want to sit there and write a bajillion utility classes

And you don't have to. Lots of frameworks exist, such as:

There are also lots more if none of those are doing it for you.

Isn't that basically the same thing as inline styles?

Not quite, for a few reasons:

• Inline styles don't respect media queries, which basically rules out responsive design
• Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue)
• Inline styles cause specificity issues, since they trump separate stylesheets.
• Inline styles don't support print-specific styles.
• Inline styles can't address pseudo-elements (such as ::before and ::after)
• Inline styles can't apply to multiple elements. Utility classes can define .bg-blue once and have it apply to many things, which leads to shorter markup and quicker rendering speed.
• Inline styles are a pain to type. Compare class="f-sm bg-blue" to style="font-size: 10px; background-color: #0000ff;".

Utility classes fix all of these things.

If, however, your objection to inline styles is that dirty up your markup or they go against your principles, then keep reading.

What about separation of concerns and semantic class names?

This can be tough to get past, but let's think about it. First of all, let me be clear that I'm NOT suggesting we do away with semantic markup, meaning using the correct HTML elements. I'm talking about semantic class names, which are classes that describe what that element is or contains rather than what it looks like. With that in mind, first ask yourself if your class names are even semantic. If you're using presentational classes like card or form__submit--disabled, then they probably aren't.

If your classes ARE semantic, then why is this useful? Have you ever really looked at a thing with class="profile-card" and said "oh this is a profile card", when it wouldn't have been just as easy to tell that based on the context or what it contains?

If your answer is an emphatic "YES I HAVE!" then there's nothing stopping you from continuing to add those semantic classes, even if they're irrelevant for styling. You can still make the first class profile-card for your own sake, and follow it with the utility classes that do the styling. You can completely ignore the styling implications of the class names that you choose, because there are none.

As a side note, this approach can also help with debugging, for those situations where you see something broken in the browser and need to find out where in the codebase that thing is being defined. It's a lot easier to track down profile-card in your code than bg-blue mt-5 w-50, even though profile-card won't have any CSS attached to it.

I think that separation of concerns (i.e., the whole idea that the markup should be completely independent from the styling) is something that has been burned into our brains because of the history of CSS (trying to get people away from using tables, sites like CSS Zen Garden, etc.) and it's not necessarily very useful anymore. If you're skeptical, take some time and read this post which really was a light bulb for me.

OK, but the DOM still looks like a dumpster fire

Again, this is tough to get past, but once you get used to it, there's a chance you might just learn to love it. That dumpster fire tells you exactly what something will look like, and doesn't give you any information you don't need.

Anyways, it looks better than it would if you were using many of the common CSS in JS solutions, which give you a ton of crazy randomly-generated class names.

I don't want to have to repeat the same 20 classes on every single button

That's understandable. I will say that there's a chance that repeating those 20 classes can actually be somewhat valuable, because when you get into a situation where one of the buttons needs to have slightly more margin-top than the others, then it's easy to fix.

Also, if you find yourself in a situation where you're using the exact same classes in a bunch of different places, that's probably a DRY problem with repeated markup, and you should likely consider abstracting that into a reusable fragment or template so that you can define it in one place and just include it wherever you need it.

That said, for situations where you're sure that you need to reuse the exact same set of styles, and for whatever reason it doesn't make sense to abstract that into a reusable template, then some of the frameworks have solutions for this. Tailwind, for example, allows creating components which are composed of utility classes. This allows you to do things like this:

<buttonclass="btn-blue">Button</button><style>.btn-blue{@apply .bg-blue .text-white .font-bold .py-2 .px-4 .rounded;}.btn-blue:hover{@apply .bg-blue-dark;}</style>

Note that you can always combine component classes with utility classes for the pieces that do vary. So you can do things like:

<buttonclass="btn-blue mt-3">Button</button>

That'll give you all of the default classes for btn-blue in addition to adding a custom margin-top for this specific instance.

All that said, I don't necessarily love this approach because it can muddy the waters. You might end up in a place where lots of things use component classes and lots of things don't and you aren't really sure what the dividing line is. My suggestion is to only use this technique when you absolutely have to because the alternative would drive you crazy.

Won't I end up with thousands of classes that I don't even need?

Since the framework generates so many classes, plus versions of those classes for hover state or responsive breakpoints, you really end up with a lot of classes unless you do something about it.

This may not be a huge deal, since (as an example), all of Tachyons is only 15kb when compressed and minified, and most non-trivial sites have at least that size in custom CSS.

Either way, the frameworks have solutions for this too. Tachyons for example has a generator which allows you to specify which classes you need or don't need, and Tailwind has configuration support for it as well. For example, this allows you to say "I don't need responsive versions of box-shadow classes", or "I only need classes for these 4 colors."

What if I need things (colors, fonts, padding options) that don't exist in the pre-made classes?

Frameworks to the rescue again. The same configuration options I mentioned above give you the ability to specify what you want your padding options to be, or which font families to use for which font stacks, or what your color options are, etc.

You can basically build your own list of utility classes, to the point that it's theoretically possible that you shouldn't need to write a single line of custom CSS.

Ok fine, but what are the benefits?

There's really a lot to love here, I think.

• You don't have to write any CSS of your own (which, to me, is fantastic)
• You can likely build things faster (obviously non-scientific, but anecdotally I've seen many people confirm this)
• You don't ever have to think about naming things
• You can tell what something looks like by just reading the markup for it
• You don't ever have to worry that changing the styles for one thing will break something else (which may make visual regression testing irrelevant)
• You never have to deal with one instance of a thing needing a slightly different style than the other instances, which screws up your reusable classes.
• Your CSS always stays the same size rather than expanding over time
• It's easy to un-apply a style by just removing the class (as opposed to the traditional cascade where you typically have to override, adding even more CSS)
• Rendering speed performance is supposedly improved (though I have seen no proof of this)

Still not convinced?

Here's a giant list of links defending Functional CSS that you may find interesting.

Also, feel free to tweet at me and debate!

After more than a century of slicing tiny, inflamed organs from people’s guts, doctors have found that surgery may not be necessary after all—a simple course of antibiotics can be just as effective at treating appendicitis as going under the knife.

The revelation comes from a large, randomized trial out of Finland, published Tuesday, September 25, in JAMA.

Despite upending a long-held standard of care, the study’s finding is not entirely surprising; it follows several other randomized trials over the years that had carved out evidence that antibiotics alone can treat an acute appendicitis. Those studies, however, left some dangling questions, including if the antibiotics just improved the situation temporarily and if initial drug treatments left patients worse off later if they did need surgery.

The new JAMA study, with its full, five-year follow-up, effectively cauterised those remaining issues. Nearly two-thirds of the patients randomly assigned in the study to get antibiotics for an uncomplicated appendicitis didn’t end up needing surgery in the follow-up time, the Finnish authors, based at the University of Turku, report. And those drug-treated patients that did end up getting an appendectomy later were not worse off for the delay in surgery.

“This long-term follow-up supports the feasibility of antibiotic treatment alone as an alternative to surgery for uncomplicated acute appendicitis,” the authors conclude.

The finding suggests that many appendicitis patients could be spared the risks of surgical procedures, such as infections. They may also be able to save money by not needing such an invasive procedure (although the study didn’t compare costs), and they could reap the benefits of shorter treatment and recovery times. Researchers will have to collect more data to back up those benefits, though.

For their initial look at the simpler appendicitis treatment, researchers led by Paulina Salminen randomly assigned 530 patients that showed up in the hospital with an acute, uncomplicated appendicitis to get either a standard, open surgery to remove their inflamed organ or a course of antibiotics. (By “uncomplicated,” the authors mean there weren’t other issues like perforation, abscess, or suspicion of a tumor.)

The patients ranged in age from 18 to 60 and enrolled in the trial between November 2009 and June 2012. Those who went under the knife stayed in the hospital for a median of three days, while the antibiotic-treated patients stayed in the hospital for three days to get intravenous drugs, which were then followed by seven days of oral antibiotics out of the hospital.

A couple of patients were lost in follow-up, including one from an unrelated death, leaving 272 patients in the surgery group and 256 in the antibiotic group.

In the antibiotic group, 70 patients ended up having surgery within the first year of the treatment. Within the subsequent five years, 30 others also underwent surgery. That left 156 antibiotic-treated patients, or about 61 percent, who were able to escape the scalpel.

The authors think that percentage could be even higher in follow-up studies. They note that the decision to undergo surgery after the initial randomization was entirely up to the patients’ treating surgeons—most of whom weren’t involved in the trial and some of whom were skeptical of the idea that antibiotics alone could treat appendicitis. This fact, the authors note, could have artificially inflated the number of people who ended up getting an appendectomy. They point out that seven of the 100 antibiotic-treated patients who underwent surgery didn’t actually have evidence of appendicitis at the time of their surgery, based on their medical records.

Still, going with antibiotics first meant fewer complications and faster recoveries overall. The antibiotic group had a complication rate of 6.5 percent, whereas those assigned to surgery had a rate of 24 percent, mostly due to infections. Of the 100 antibiotic-treated patients who later had surgery, they had typical complication rates for the procedure. This suggests that delaying the surgery for this group didn’t lead to more problems.

Complications or not, the antibiotic group overall took a median of 11 days of sick leave to recover, while the surgery group took 22 days.

There were a couple of catches to the study that warrant follow-up. One big issue is that the study compared antibiotic treatment to standard, open surgery—not a more modern, minimally invasive laparoscopic surgery, which is now common in the US. If this had been the standard of care in the surgery group for this study, it might have shifted the cost-benefit scales, potentially reducing complication rates and recovery times.

That said, the authors note that the antibiotic treatment was also heavy-handed in the study. The researchers went with a "conservative" three-day IV treatment followed by more oral antibiotics, which may have been overkill. They did this because “[w]hen this protocol was designed, there was little information available to guide the application of antibiotic treatment for appendicitis,” they note. Future studies could find that shorter, less intense courses of antibiotics could also do the trick, further reducing complication rates and treatment time.

Last, the study didn’t compare costs of the interventions or the bills that would have been incurred by those in the two treatment groups. This will be another question to address in follow-up studies as doctors fine-tune the best way to handle appendicitis after all these years.

JAMA, 2018. DOI: 10.1001/jama.2018.13201 (About DOIs).

Released in July 2016, Pokémon Go is a location-based, augmented-reality game for mobile devices, typically played on mobile phones; players use the device’s GPS and camera to capture, battle, and train virtual creatures (“Pokémon”) who appear on the screen as if they were in the same real-world location as the player: As players travel the real world, their avatar moves along the game’s map. Different Pokémon species reside in different areas—for example, water-type Pokémon are generally found near water. When a player encounters a Pokémon, AR (Augmented Reality) mode uses the camera and gyroscope on the player’s mobile device to display an image of a Pokémon as though it were in the real world.^* This AR mode is what makes Pokémon Go different from other PC games: Instead of taking us out of the real world and drawing us into the artificial virtual space, it combines the two; we look at reality and interact with it through the fantasy frame of the digital screen, and this intermediary frame supplements reality with virtual elements which sustain our desire to participate in the game, push us to look for them in a reality which, without this frame, would leave us indifferent. Sound familiar? Of course it does. What the technology of Pokémon Go externalizes is simply the basic mechanism of ideology—at its most basic, ideology is the primordial version of “augmented reality.”

The first step in this direction of technology imitating ideology was taken a couple of years ago by Pranav Mistry, a member of the Fluid Interfaces Group at the Massachusetts Institute of Technology Media Lab, who developed a wearable “gestural interface” called “SixthSense.”^** The hardware—a small webcam that dangles from one’s neck, a pocket projector, and a mirror, all connected wirelessly to a smartphone in one’s pocket—forms a wearable mobile device. The user begins by handling objects and making gestures; the camera recognizes and tracks the user’s hand gestures and the physical objects using computer vision-based techniques. The software processes the video stream data, reading it as a series of instructions, and retrieves the appropriate information (texts, images, etc.) from the Internet; the device then projects this information onto any physical surface available—all surfaces, walls, and physical objects around the wearer can serve as interfaces. Here are some examples of how it works: In a bookstore, I pick up a book and hold it in front of me; immediately, I see projected onto the book’s cover its reviews and ratings. I can navigate a map displayed on a nearby surface, zoom in, zoom out, or pan across, using intuitive hand movements. I make a sign of @ with my fingers and a virtual PC screen with my email account is projected onto any surface in front of me; I can then write messages by typing on a virtual keyboard. And one could go much further here—just think how such a device could transform sexual interaction. (It suffices to concoct, along these lines, a sexist male dream: Just look at a woman, make the appropriate gesture, and the device will project a description of her relevant characteristics—divorced, easy to seduce, likes jazz and Dostoyevsky, good at fellatio, etc., etc.) In this way, the entire world becomes a “multi-touch surface,” while the whole Internet is constantly mobilized to supply additional data allowing me to orient myself.

Mistry emphasized the physical aspect of this interaction: Until now, the Internet and computers have isolated the user from the surrounding environment; the archetypal Internet user is a geek sitting alone in front of a screen, oblivious to the reality around him. With SixthSense, I remain engaged in physical interaction with objects: The alternative “either physical reality or the virtual screen world” is replaced by a direct interpenetration of the two. The projection of information directly onto the real objects with which I interact creates an almost magical and mystifying effect: Things appear to continuously reveal—or, rather, emanate—their own interpretation. This quasi-animist effect is a crucial component of the IoT: “Internet of things? These are nonliving things that talk to us, although they really shouldn’t talk. A rose, for example, which tells us that it needs water.”¹ (Note the irony of this statement. It misses the obvious fact: a rose is alive.) But, of course, this unfortunate rose does not do what it “shouldn’t” do: It is merely connected with measuring apparatuses that let us know that it needs water (or they just pass this message directly to a watering machine). The rose itself knows nothing about it; everything happens in the digital big Other, so the appearance of animism (we communicate with a rose) is a mechanically generated illusion.

Our “direct” experience of “real” reality is already structured like a mixture of RR, AR, and MR.

However, this magic effect of SixthSense does not simply represent a radical break with our everyday experience; rather, it openly stages what was always the case. That is to say: In our everyday experience of reality, the “big Other”—the dense symbolic texture of knowledge, expectations, prejudices, and so on—continuously fills in the gaps in our perception. For example, when a Western racist stumbles upon a poor Arab on the street, does he not “project” a complex of such prejudices and expectations onto the Arab, and thus “perceive” him in a certain way? This is why SixthSense presents us with another case of ideology at work in technology: The device imitates and materializes the ideological mechanism of (mis)recognition which overdetermines our everyday perceptions and interactions.

And does not something similar happen in Pokémon Go? To simplify things to the utmost, did Hitler not offer the Germans the fantasy frame of Nazi ideology that made them see a specific Pokémon—“the Jew”—popping up all around, and providing the clue to what one has to fight against? And does the same not hold for all other ideological pseudo-entities that have to be added to reality in order to make it complete and meaningful? One can easily imagine a contemporary anti-immigrant version of Pokémon Go where the player wanders about a German city and is threatened by Muslim immigrant rapists or thieves lurking everywhere. Here we encounter the crucial question: Is the form the same in all these cases, or is the anti-Semitic conspiracy theory which makes us see the Jewish plot as the source of our troubles formally different from the Marxist approach which observes social life as a battleground of economic and power struggles? There is a clear difference between these two cases: In the second case, the “secret” beneath all the confusion of social life is social antagonisms, not individual agents which can be personalized (in the guise of Pokémon figures), while Pokémon Go does inherently tend toward the ideologically personalized perception of social antagonisms. In the case of bankers threatening us from all around, it is not hard to see how such a figure can easily be appropriated by a Fascist populist ideology of plutocracy (as opposed to “honest” productive capitalists). … The point of the parallel between Nazi anti-Semitism and Pokémon Go is thus a very simple and elementary one: Although Pokémon Go presents itself as something new, grounded in the latest technology, it relies on old ideological mechanisms. Ideology is the practice of augmenting reality.

The general lesson from Pokémon Go is that, when we deal with the new developments in Virtual Reality (VR) technology, we usually focus on the prospect of full immersion, thereby neglecting the much more interesting possibilities of Augmented Reality (AR) and Mixed Reality (MR):

• In VR, you wear something on your head (currently, a head-mounted display that can look like a boxy set of goggles or a space helmet) that holds a screen in front of your eyes, which in turn is powered by a computer. Thanks to specialized software and sensors, the experience becomes your reality, filling your vision; at the high end, this is often accompanied by 3-D audio that feels like a personal surround-sound system on your head, or controllers that let you reach out and interact with this artificial world in an intuitive way. The forthcoming development of VR will heighten the level of immersion so that it will feel as if we are fully present in it: When VR users look (and walk) around, their view of that world will adjust in the same way as it would if they were looking or moving in real reality.

• AR takes our view of the real world and adds digital information, from simple numbers or text notifications to a complex simulated screen, making it possible to augment our view of reality with digital information about it without checking another device, leaving both our hands free for other tasks. We thus immediately see reality plus selected data about it that provide the interpretive frame of how to deal with it—for example, when we look at a car, we see the basic data about it on screen.

• But the true miracle is MR: It lets us see the real world and, as part of the same reality, “believable” virtual objects which are “anchored” to points in real space, and thus enable us to treat them as “real.” Say, for example, that I am looking at an ordinary table, but see interactive virtual objects (a person, a machine, a model of a building) sitting on top of it; as I walk around, the virtual landscape holds its position, and when I lean in close, it gets closer in the way a real object would. To some degree, I can then interact with these virtual objects in such a “realistic” way that what I do to them has effects in non-virtual reality (for example, I press a button on the virtual machine and the air-conditioning starts to work in reality).²

We thus have four levels of reality: RR (“real” reality which we perceive and interact with), VR, AR, MR; but is RR really simply reality, or is even our most immediate experience of reality always mediated and sustained by some kind of virtual mechanism? Today’s cognitive science definitely supports the second view—for example, the basic premise of Daniel Dennett’s “heterophenomenology”³ is that subjective experience is the theorist’s (interpreter’s) symbolic fiction, his supposition, not the domain of phenomena directly accessible to the subject. The universe of subjective experience is reconstructed in exactly the same way as we reconstruct the universe of a novel from reading its text. In a first approach, this seems innocent enough, self-evident even: Of course we do not have direct access to another person’s mind, of course we have to reconstruct an individual’s self-experience from his external gestures, expressions and, above all, words. However, Dennett’s point is much more radical; he pushes the parallel to the extreme. In a novel, the universe we reconstruct is full of “holes,” not fully constituted; for example, when Conan Doyle describes Sherlock Holmes’s apartment, it is in a way meaningless to ask exactly how many books there were on the shelves—the writer simply did not have an exact idea of it in his mind. And, for Dennett, it is the same with another person’s experience in “reality”: what one should not do is to suppose that, deep in another’s psyche, there is a full self-experience of which we get only fragments. Even the appearances cannot be saved.

This central point of Dennett can be nicely explained if one contrasts it with two standard positions which are usually opposed as incompatible, but are in effect solidary: first-person phenomenalism and third-person behavioral operationalism. On the one hand, the idea that, even if our mind is merely software in our brains, nobody can take from us the full first-person experience of reality; on the other hand, the idea that, in order to understand the mind, we should limit ourselves to third-person observations which can be objectively verified, and not accept any first-person accounts. Dennett undermines this opposition with what he calls “first-person operationalism”: the gap is to be introduced into my very first-person experience—the gap between content and its registration, between represented time and the time of representation. A nice proto-Lacanian point of Dennett (and the key to his heterophenomenology) is this insistence on the distinction, in homology with space, between the time of representation and the representation of time: They are not the same, i.e., the loop of flashback is discernible even in our most immediate temporal experience—the succession of events ABCDEF … is represented in our consciousness so that it begins with E, then goes back to ABCD, and, finally, returns to F, which in reality directly follows E. So even in our most direct temporal self-experience, a gap akin to that between signifier and signified is already at work: Even here, one cannot “save the phenomena,” since what we (mis)perceive as a directly experienced representation of time (the phenomenal succession ABCDEF …) is already a “mediated” construct from a different time of representation (E/ABCD/F …).

“First-person operationalism” thus emphasizes how, even in our “direct (self-)experience,” there is a gap between content (the narrative inscribed into our memory) and the “operational” level of how the subject constructed this content, where we always have a series of rewritings and tinkerings: “introspection provides us—the subject as well as the ‘outside’ experimenter—only with the content of representation, not with the features of the representational medium itself.”³ In this precise sense, the subject is his own fiction: The content of his own self-experience is a narrativization in which memory traces already intervene. So when Dennett makes “ ‘writing it down’ in memory criterial for consciousness; that is what it is for the ‘given’ to be ‘taken’—to be taken one way rather than another,” and claims that “there is no reality of conscious experience independent of the effects of various vehicles of content on subsequent action (and, hence, on memory),”³ we should be careful not to miss the point: What counts for the concerned subject himself is the way an event is “written down,” memorized—memory is constitutive of my “direct experience” itself, i.e., “direct experience” is what I memorize as my direct experience. Or, to put it in Hegelian terms (which would undoubtedly appall Dennett): Immediacy itself is mediated, it is a product of the mediation of traces. One can also put this in terms of the relationship between direct experience and judgment on it: Dennett’s point is that there is no “direct experience” prior to judgment, i.e., what I (re)construct (write down) as my experience is already supported by judgmental decisions.

For this reason, the whole problem of “filling in the gaps” is a false problem, since there are no gaps to be filled in. Let us take the classic example of our reading a text which contains a lot of printing errors: Most of these errors pass unnoticed, i.e., since, in our reading, we are guided by an active attitude of recognizing patterns, we, for the most part, simply read the text as if there were no mistakes. The usual phenomenological account of this would be that, owing to my active attitude of recognizing ideal patterns, I “fill in the gaps” and automatically, even prior to my conscious perception, reconstitute the correct spelling, so that it appears to me that I am reading the correct text, without mistakes. But what if the actual procedure is different? Driven by the attitude of actively searching for known patterns, I quickly scan a text (our actual perception is much more discontinuous and fragmentary than it may appear), and this combination of an active attitude of searching and fragmented perception leads my mind directly to the conlcusion that, for example, the word I just read is “conclusion,” not “conlcusion,” as it was actually written? There are no gaps to be filled in here, since there is no moment of perceptual experience prior to the conclusion (i.e., judgment) that the word I have just read is “conclusion”: Again, my active attitude drives me directly to the conclusion.

What I (re)construct as my experience is already supported by judgmental decisions.

Back to VR, AR, and MR: Is not the conclusion that imposes itself that our “direct” experience of “real” reality is already structured like a mixture of RR, AR, and MR? It is thus crucial to bear in mind that AR and MR “work” because they do not introduce a radical break into our engagement in reality, but mobilize a structure that is already at work in it. There are arguments (drawn from the brain sciences) that something like ideological confabulation is proper to the most elementary functioning of our brain; recall the famous split-brain experiment:

The patient was shown two pictures: of a house in the winter time and of a chicken’s claw. The pictures were positioned so they would exclusively be seen in only one visual field of the brain (the winter house was positioned so it would only be seen in the patient’s left visual field [LVF], which corresponds to the brain’s right hemisphere, and the chicken’s claw was placed so it would only be seen in the patient’s right visual field [RVF], which corresponds to the brain’s left hemisphere).

A series of pictures was placed in front of the patient who was then asked to choose a picture with his right hand and a picture with his left hand. The paradigm was set up so the choices would be obvious for the patients. A snow shovel is used for shoveling the snowy driveway of the winter house and a chicken’s head correlates to the chicken’s claw. The other pictures do not in any way correlate with the two original pictures. The patient chose the snow shovel with his left hand (corresponding to his brain’s right hemisphere) and his right hand chose the chicken’s head (corresponding to the brain’s left hemisphere). When the patient was asked why he had chosen the pictures he had chosen, the answer he gave was astonishing: “The chicken claw goes with the chicken head, and you need a snow shovel to clean out the chicken shed.” Why would he say this? Wouldn’t it be obvious that the shovel goes with the winter house? For people with an intact corpus callosum, yes it is obvious, but not for a split-brain patient. Both the winter house and the shovel are being projected to the patient from his LVF, so his right hemisphere is receiving and processing the information and this input is completely independent from what is going on in the RVF, which involves the chicken’s claw and head (the information being processed in the left hemisphere). The human brain’s left hemisphere is primarily responsible for interpreting the meaning of the sensory input it receives from both fields, however the left hemisphere has no knowledge of the winter house. Because it has no knowledge of the winter house, it must invent a logical reason for why the shovel was chosen. Since the only objects it has to work with are the chicken’s claw and head, the left hemisphere interprets the meaning of choosing the shovel as “it is an object necessary to help the chicken, which lives in a shed, therefore, the shovel is used to clean the chicken’s shed.” Gazzaniga famously coined the term “left brain interpreter” to explain this phenomenon.⁴

It is crucial to note that the patient “wasn’t ‘consciously’ confabulating”: “The connection between the chicken claw and the shovel was an honest expression of what ‘he’ thought.”⁵ And is not ideology, at its most elementary, such an interpreter confabulating rationalizations in the conditions of repression? A somewhat simplified example: Let’s imagine the same experiment with two pictures shown to a subject fully immersed in ideology, a beautiful villa and a group of starving miserable workers; from the accompanying cards, he selects a fat rich man (inhabiting the villa) and a group of aggressive policemen (whose task is to squash the workers’ eventual desperate protest). His “left brain interpreter” doesn’t see the striking workers, so how does it account for the aggressive policemen? By confabulating a link such as: “Policemen are needed to protect the villa with the rich man from robbers who break the law.” Were not the (in)famous nonexistent weapons of mass destruction that justified the United States’ attack on Iraq precisely the result of such a confabulation, which had to fill in the void of the true reasons for the attack?

• Slavoj Žižek is a Slovenian philosopher and cultural critic. He is a professor at the European Graduate School, International Director of the Birkbeck Institute for the Humanities, Birkbeck College, University of London, and a senior researcher at the Institute of Sociology, University of Ljubljana, Slovenia. His books include First as Tragedy, Then as Farce; Iraq: The Borrowed Kettle; In Defense of Lost Causes; Living in the End Times; and many more.

Excerpted from Incontinence of the Void by Slavoj Žižek published by The MIT Press. © 2017 Massachusetts Institute of Technology. All rights reserved.

References

1. Quoted from Dnevnik newspaper, Ljubljana, Slovenia, Aug. 24, 2016.

2. Johnson, E. What are the differences between virtual, augmented and mixed reality? www.recode.net (2016).

3. Dennett, D.C. Consciousness Explained Little, Brown, Boston, MA (1991).

4. M.S. The split brain revisited. Scientific American279, 50-55 (1998).

5. Foster, C. Wired to God? Hodder, London (2011).

Footnotes

* This short description shamelessly relies on the Wikipedia entry on Pokémon.

** Apart from numerous reports in the media, see the concise description under “SixthSense” on Wikipedia.

Photocollage credits: Everett Collection; tangxn /Shutterstock

The study, by Dr. John Leach, a senior research fellow at the University of Portsmouth, is the first to describe the clinical markers for 'give-up-itis', a term used to describe what is known medically as psychogenic death.

It usually follows a trauma from which a person thinks there is no escape, making death seem like the only rational outcome.

If not arrested, death usually occurs three weeks after the first stage of withdrawal.

Dr. Leach said: "Psychogenic death is real. It isn't suicide, it isn't linked to depression, but the act of giving up on life and dying usually within days, is a very real condition often linked to severe trauma."

He describes in clinical detail the five stages leading to progressive psychological decline and suggests give-up-itis could stem from a change in a frontal-subcortical circuit of the brain governing how a person maintains goal-directed behaviour.

The likely candidate in the brain is the anterior cingulate circuit, responsible for motivation and initiating goal-directed behaviours.

He said: "Severe trauma might trigger some people's anterior cingulate circuit to malfunction. Motivation is essential for coping with life and if that fails, apathy is almost inevitable."

Death isn't inevitable in someone suffering from give-up-itis and can be reversed by different things at each stage. The most common interventions are physical activity and/or a person being able to see a situation is at least partially within their control, both of which trigger the release of the feel-good chemical dopamine.

"Reversing the give-up-itis slide towards death tends to come when a survivor finds or recovers a sense of choice, of having some control, and tends to be accompanied by that person licking their wounds and taking a renewed interest in life," he said.

The five stages of give-up-itis are:

1. Social withdrawal - usually after a psychological trauma. People in this stage can show a marked withdrawal, lack of emotion, listlessness and indifference and become self-absorbed.

Prisoners of war have often been described in this initial state, having withdrawn from life, of vegetating or becoming passive.

Dr. Leach said withdrawal can be a way of coping, to pull back from any outward emotional engagement to allow an internal re-alignment of emotional stability, for example, but if left unchecked it can progress to apathy and extreme withdrawal.

2. Apathy - an emotional or symbolic 'death', profound apathy has been seen in prisoners of war and in survivors of shipwreck and aircraft crashes. It's a demoralising melancholy different to anger, sadness or frustration. It has also been described as someone no longer striving for self-preservation. People in this stage are often dishevelled, their instinct for cleanliness gone.

Dr. Leach said one prisoner of war who was also a medical officer described being in this stage as waking each morning but being unable to summon the energy to do anything. Others describe it as a severe melancholy, where even the smallest task feels like the mightiest effort.

3. Aboulia - a severe lack of motivation coupled with a dampened emotional response, a lack of initiative and an inability to make decisions.

People at this stage are unlikely to speak, frequently give up washing or eating and withdraw further and deeper into themselves.

At this stage, a person has lost intrinsic motivation—the ability or desire to start acting to help themselves—but they can still be motivated by others, through persuasive nurturing, reasoning, antagonism and even physical assault. Once external motivators are removed, the person reverts to inertia.

Dr. Leach said: "An interesting thing about aboulia is there appears to be an empty mind or a consciousness devoid of content. People at this stage who have recovered describe it as having a mind like mush, or of having no thought whatsoever. In aboulia, the mind is on stand-by and a person has lost the drive for goal directed behaviour."

4. Psychic akinesia - a further drop in motivation. The person is conscious but in a state of profound apathy and unaware of or insensitive to even extreme pain, not even flinching if they are hit, and they are often incontinent and continue to lie in their own waste.

A lack of pain response is described in a case study in which a young woman, later diagnosed with psychic akinesia, suffered second-degree burns while visiting the beach, because she hadn't removed herself from the sun's heat.

5. Psychogenic death - Dr. Leach describes this final stage as the disintegration of a person.

He said: "It's when someone then gives up. They might be lying in their own excreta and nothing—no warning, no beating, no pleading can make them want to live."

In concentration camps, people who reached this stage were often known to be near death by fellow prisoners when they took out a hidden cigarette and began smoking it. Cigarettes were highly valuable in the camps and could be traded for important things such as food.

Dr. Leach said: "When a prisoner took out a cigarette and lit it, their campmates knew the person had truly given up, had lost faith in their ability to carry on and would soon be dead."

The progress from stage four, psychic akinesia, to stage five, psychogenic death, generally takes three to four days and shortly before death, there's often a false dawn—a flicker of life, for example, when someone suddenly enjoys a cigarette.

Dr. Leach said: "It appears briefly as if the 'empty mind' stage has passed and has been replaced by what could be described as goal-directed behaviour. But the paradox is that while a flicker of goal-directed behaviour often takes place, the goal itself appears to have become relinquishing life."

Explore further:Contrary to popular belief, ALS does affect the mind

More information: John Leach. 'Give-up-itis' revisited: Neuropathology of extremis, Medical Hypotheses (2018). DOI: 10.1016/j.mehy.2018.08.009

Welcome! To bring you the best content on our sites and applications, Meredith partners with third party advertisers to serve digital ads, including personalized digital ads. Those advertisers use tracking technologies to collect information about your activity on our sites and applications and across the Internet and your other apps and devices.

You always have the choice to experience our sites without personalized advertising based on your web browsing activity by visiting the DAA’s Consumer Choice page, the NAI's website, and/or the EU online choices page, from each of your browsers or devices. To avoid personalized advertising based on your mobile app activity, you can install the DAA’s AppChoices app here. You can find much more information about your privacy choices in our privacy policy. 

Even if you choose not to have your activity tracked by third parties for advertising services, you will still see non-personalized ads on our site.

By clicking continue below and using our sites or applications, you agree that we and our third party advertisers can:

• transfer your personal data to the United States or other countries, and
• process your personal data to serve you with personalized ads, subject to your choices as described above and in our privacy policy.

EU Data Subject Requests

Image copyrightAFP

Chile has launched a huge hiking route through its Patagonian wilderness to boost tourism and highlight the need for conservation.

The Route of Parks covers 2,800km (1,740 miles) from the city of Puerto Montt down to Cape Horn.

The trail was the idea of Tompkins Conservation, the foundation set up by US billionaire Douglas Tompkins and his wife Kristine.

Last year the foundation donated vast amounts of land to Chile's government.

The land has helped create a network of 17 national parks and the new route - called the Patagonian Route of Parks - connects all of them.

"We want Chile to be internationally recognised for having the most spectacular scenic route in the world, and thus become a benchmark for economic development based on conservation," said Carolina Morgado, executive director at Tompkins.

A website for the new trail says it encompasses three existing hiking routes - the Southern Way, the Patagonian channels and the End of the World Route.

The sparsely inhabited terrain is known for its lakes, waterways and rich habitat of flora and fauna.

The website includes advice on transport, accommodation and more than 50 GPS-traced paths.

Mr Tompkins, a keen conservationist and the founder of North Face clothing, died in a kayaking accident in Chile in 2015. The businessman had bought up huge swathes of land in southern Chile and Argentina to preserve it.

His widow, Kristine McDivitt Tompkins, signed an agreement with the national government in March 2017, donating the land with the intention of creating a network of national parks roughly the size of Switzerland.

Then Chilean President Michelle Bachelet called the signing an "unprecedented preservation effort".

The foundation described it as "the largest land donation in history from a private entity to a country".

• The Great Trail is a winding network of paths, waterways and roadways running 23,000km (14,900 miles) across Canada
• The Appalachian National Scenic Trail in the US is about 3,500km (2,190 miles) long and travels through 14 states from Georgia to Maine
• The 3,000km (1,800 mile) Te Araroa trail in New Zealand stretches from Cape Reinga in the north to Bluff in the south
• The Great Himalaya Trail runs for 1,700km (1,000 miles) and traverses the whole length of the Himalayas in Nepal

This post is about building Linux systems for Raspberry Pi boards using software from the Yocto Project.

Yocto is a set of tools for building a custom embedded Linux distribution. The systems are usually targeted for a particular application like a commercial product.

If you are looking to build a general purpose development system with access to pre-built packages, I suggest you stick with a more user-friendly distribution like Raspbian.

And while the Yocto system is very powerful, it does have a substantial learning curve. You may want to look at another popular, but simpler tool for building embedded systems Buildroot.

Yocto uses what it calls meta-layers to define the configuration. Within each meta-layer are recipes, classes and configuration files that support the primary build tool, a python app called bitbake.

I have created a custom meta-layer for the RPi boards called meta-rpi.

The systems built from this layer use the same GPU firmware, linux kernel and include the same dtb overlays as the official Raspbian systems. This means that no hardware functionality is lost with these Yocto built systems as compared to the “official” Raspbian distro. It is only the userland software that differs and that is completely configurable by you.

There are a some example images in meta-rpi that support the programming languages and tools that I commonly use in my own projects.

When using this repository for customer projects, I first fork and move it to another repository, usually with a different name. I recommend you do the same if you require stability. I use the meta-rpi layer for my experiments.

My systems use sysvinit, but Yocto supports systemd.

If you are Qt5 developer then you will appreciate that the RPi comes with working OpenGL drivers for the RPi GPU. This means Qt OpenGL and QML applications will work when using the eglfs platform plugin.

I am using the official Yocto meta-raspberrypi layer, but have updated recipes for the Linux kernel and gpu firmware to keep them more current. I also have occasional ‘fixes’ to other components, sometimes for bugs, but often just because I don’t like the meta-raspberrypi defaults.

I have access to all of the RPi boards and have at one time or another tested these builds with all of them including the RPi CM and CM3 modules.

Most of the time I test only with RPi3 and RPi0-W boards.

Downloads

If you want a quick look at the resulting systems, you can download some pre-built images here.

Instructions for installing onto an SD card are in the README.

The login user is root with password jumpnowtek.

You should change that password.

All systems are setup to use a serial console. For the RPi’s that have it, a dhcp client will run on the ethernet interface and there is an ssh server running.

Note: There is a custom firewall rule that will lock your IP out for 1 minute if you fail to login with ssh after 3 attempts.

System Info

The Yocto version is 2.5.1, the [sumo] branch.

The 4.14 Linux kernel comes from the github.com/raspberrypi/linux repository.

These are sysvinit systems using eudev.

The Qt version is 5.10.1 There is no X11 and no desktop installed. Qt GUI applications can be run fullscreen using one of the Qt embedded linux plugins like eglfs or linuxfb, both are provided. The default is eglfs.

Python 3.5.5 with a number of modules is included.

gcc/g++ 7.3.0 and associated build tools are installed.

git 2.16.1 is installed.

omxplayer is installed for playing video and audio from the command line, hardware accelerated.

Raspicam the command line tool for using the Raspberry Pi camera module is installed.

There is an example image that I use for a couple of Raspberry Pi music systems. They use either an IQaudIO Pi-DigiAMP+ or HiFiBerry Amp+ add-on board and pianobar, a console-based client for Pandora internet radio.

The Adafruit PiTFT 3.5” and PiTFT 2.8” resistive touchscreens work. Support for some other TFT displays is included, but I haven’t tested them.

Raspi2fb is included for mirroring the GPU framebuffer to the small TFT displays. This allows for running Qt GUI applications on the TFTs.

Ubuntu Setup

I primarily use 16.04 64-bit servers for builds. Other versions should work.

You will need at least the following packages installed

build-essential
chrpath
diffstat
gawk
libncurses5-dev
texinfo

For 16.04 you also need to install the python 2.7 package

And then create some links for it in /usr/bin

sudo ln -sf /usr/bin/python2.7 /usr/bin/python
sudo ln -sf /usr/bin/python2.7 /usr/bin/python2

For all versions of Ubuntu, you should change the default Ubuntu shell from dash to bash by running this command from a shell

sudo dpkg-reconfigure dash

Choose No to dash when prompted.

Fedora Setup

I have used a Fedora 27 64-bit workstation.

The extra packages I needed to install for Yocto were

chrpath
perl-bignum
perl-Thread-Queue
texinfo

and the package group

Fedora already uses bash as the shell.

Clone the dependency repositories

For all upstream repositories, use the [sumo] branch.

The directory layout I am describing here is my preference. All of the paths to the meta-layers are configurable. If you choose something different, adjust the following instructions accordingly.

First the main Yocto project poky layer

~# git clone -b sumo git://git.yoctoproject.org/poky.git poky-sumo

Then the dependency layers under that

~$ cd poky-sumo
~/poky-sumo$ git clone -b sumo git://git.openembedded.org/meta-openembedded
~/poky-sumo$ git clone -b sumo https://github.com/meta-qt5/meta-qt5
~/poky-sumo$ git clone -b sumo git://git.yoctoproject.org/meta-security
~/poky-sumo$ git clone -b sumo git://git.yoctoproject.org/meta-raspberrypi

These repositories shouldn’t need modifications other then periodic updates and can be reused for different projects or different boards.

Clone the meta-rpi repository

Create a separate sub-directory for the meta-rpi repository before cloning. This is where you will be doing your customization.

~$ mkdir ~/rpi
~$ cd ~/rpi
~/rpi$ git clone -b sumo git://github.com/jumpnow/meta-rpi

The meta-rpi/README.md file has the last commits from the dependency repositories that I tested. You can always checkout those commits explicitly if you run into problems.

Initialize the build directory

Again much of the following are only my conventions.

Choose a build directory. I tend to do this on a per board and/or per project basis so I can quickly switch between projects. For this example I’ll put the build directory under ~/rpi/ with the meta-rpi layer.

You could manually create the directory structure like this

$ mkdir -p ~/rpi/build/conf

Or you could use the Yocto environment script oe-init-build-env like this passing in the path to the build directory

~$ source poky-sumo/oe-init-build-env ~/rpi/build

The Yocto environment script will create the build directory if it does not already exist.

Customize the configuration files

There are some sample configuration files in the meta-rpi/conf directory.

Copy them to the build/conf directory (removing the ‘-sample’)

~/rpi$ cp meta-rpi/conf/local.conf.sample build/conf/local.conf
~/rpi$ cp meta-rpi/conf/bblayers.conf.sample build/conf/bblayers.conf

If you used the oe-init-build-env script to create the build directory, it generated some generic configuration files in the build/conf directory. If you want to look at them, save them with a different name before overwriting.

It is not necessary, but you may want to customize the configuration files before your first build.

Warning: Do not use the ‘~’ character when defining directory paths in the Yocto configuration files.

Edit bblayers.conf

In bblayers.conf file replace ${HOME} with the appropriate path to the meta-layer repositories on your system if you modified any of the paths in the previous instructions.

WARNING: Do not include meta-yocto-bsp in your bblayers.conf. The Yocto BSP requirements for the Raspberry Pi are in meta-raspberrypi.

For example, if your directory structure does not look exactly like this, you will need to modify bblayers.conf

~/poky-sumo/
     meta-openembedded/
     meta-qt5/
     meta-raspberrypi
     meta-security
     ...

~/rpi/
    meta-rpi/
    build/
        conf/

Edit local.conf

The variables you may want to customize are the following:

• MACHINE
• TMPDIR
• DL_DIR
• SSTATE_DIR

The defaults for all of these work fine with the exception of MACHINE.

MACHINE

The MACHINE variable is used to determine the target architecture and various compiler tuning flags.

See the conf files under meta-raspberrypi/conf/machine for details.

The choices for MACHINE are

• raspberrypi (BCM2835)
• raspberrypi0 (BCM2835)
• raspberrypi0-wifi (BCM2835)
• raspberrypi2 (BCM2836 or BCM2837 v1.2+)
• raspberrypi3 (BCM2837)
• raspberrypi-cm (BCM2835)
• raspberrypi-cm3 (BCM2837)

You can only build for one type of MACHINE at a time.

There are really just two tuning families using the default Yocto configuration files

• arm1176jzfshf - for the the BCM2835 boards
• cortexa7thf-neon-vfpv4 - for the BCM2836 and BCM2837 boards

Boards in the same family can generally run the same software.

One exception is u-boot, which is NOT the default for the systems being built here.

One of the reasons you would want to use u-boot with the RPis is to work with the Mender upgrade system.

TMPDIR

This is where temporary build files and the final build binaries will end up. Expect to use at least 50GB.

The default location is under the build directory, in this example ~/rpi/build/tmp.

If you specify an alternate location as I do in the example conf file make sure the directory is writable by the user running the build.

DL_DIR

This is where the downloaded source files will be stored. You can share this among configurations and builds so I always create a general location for this outside the project directory. Make sure the build user has write permission to the directory you decide on.

The default location is in the build directory, ~/rpi/build/sources.

SSTATE_DIR

This is another Yocto build directory that can get pretty big, greater then 8GB. I often put this somewhere else other then my home directory as well.

The default location is in the build directory, ~/rpi/build/sstate-cache.

ROOT PASSWORD

There is only one login user by default, root.

The default password is set to jumpnowtek by these two lines in the local.conf file

INHERIT += "extrausers"
EXTRA_USERS_PARAMS = "usermod -P jumpnowtek root; "

Obviously you should change this.

If you want no password, convenient for development, comment those two lines and uncomment this line

EXTRA_IMAGE_FEATURES = "debug-tweaks"
#INHERIT += "extrausers"
#EXTRA_USERS_PARAMS = "usermod -P jumpnowtek root; "

You can also change or add a password once logged in.

Run the build

You need to source the Yocto environment into your shell before you can use bitbake. The oe-init-build-env will not overwrite your customized conf files.

~$ source poky-sumo/oe-init-build-env ~/rpi/build

### Shell environment set up for builds. ###

You can now run 'bitbake '

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-toolchain-sdk
    adt-installer
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'
~/rpi/build$

I don’t use any of those Common targets, but instead always write my own custom image recipes.

The meta-rpi layer has some examples under meta-rpi/images/.

Build

To build the console-image run the following command

~/rpi/build$ bitbake console-image

You may occasionally run into build errors related to packages that either failed to download or sometimes out of order builds. The easy solution is to clean the failed package and rerun the build again.

For instance if the build for zip failed for some reason, I would run this

~/rpi/build$ bitbake -c cleansstate zip
~/rpi/build$ bitbake zip

And then continue with the full build.

~/rpi/build$ bitbake console-image

To build the qt5-image it would be

~/rpi/build$ bitbake qt5-image

The cleansstate command (with two s’s) works for image recipes as well.

The image files won’t get deleted from the TMPDIR until the next time you build.

Copying the binaries to an SD card (or eMMC)

After the build completes, the bootloader, kernel and rootfs image files can be found in **/deploy/images/$MACHINE** with **MACHINE** coming from your **local.conf**.

The meta-rpi/scripts directory has some helper scripts to format and copy the files to a microSD card.

See this post for an additional first step required for the RPi Compute eMMC.

mk2parts.sh

This script will partition an SD card with the minimal 2 partitions required for the RPI.

Insert the microSD into your workstation and note where it shows up.

lsblk is convenient for finding the microSD card.

For example

~/rpi/meta-rpi$ lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda       8:0    0 931.5G  0 disk
|-sda1    8:1    0  93.1G  0 part /
|-sda2    8:2    0  93.1G  0 part /home
|-sda3    8:3    0  29.8G  0 part [SWAP]
|-sda4    8:4    0     1K  0 part
|-sda5    8:5    0   100G  0 part /oe5
|-sda6    8:6    0   100G  0 part /oe6
|-sda7    8:7    0   100G  0 part /oe7
|-sda8    8:8    0   100G  0 part /oe8
|-sda9    8:9    0   100G  0 part /oe9
`-sda10   8:10   0 215.5G  0 part /oe10
sdb       8:16   1   7.4G  0 disk
|-sdb1    8:17   1    64M  0 part
`-sdb2    8:18   1   7.3G  0 part

So I will use sdb for the card on this machine.

It doesn’t matter if some partitions from the SD card are mounted. The mk2parts.sh script will unmount them.

WARNING: This script will format any disk on your workstation so make sure you choose the SD card.

~$ cd ~/rpi/meta-rpi/scripts
~/rpi/meta-rpi/scripts$ sudo ./mk2parts.sh sdb

You only have to format the SD card once.

Temporary mount point

You will need to create a mount point on your workstation for the copy scripts to use.

This is the default

~$ sudo mkdir /media/card

You only have to create this directory once.

If you don’t want that location, you will have to edit the following scripts to use the mount point you choose.

copy_boot.sh

This script copies the GPU firmware, the Linux kernel, dtbs and overlays, config.txt and cmdline.txt to the boot partition of the SD card.

This copy_boot.sh script needs to know the TMPDIR to find the binaries. It looks for an environment variable called OETMP.

For instance, if I had this in build/conf/local.conf

TMPDIR = "/oe4/rpi/tmp-sumo"

Then I would export this environment variable before running copy_boot.sh

~/rpi/meta-rpi/scripts$ export OETMP=/oe4/rpi/tmp-sumo

If you didn’t override the default TMPDIR in local.conf, then set it to the default TMPDIR

~/rpi/meta-rpi/scripts$ export OETMP=~/rpi/build/tmp

The copy_boot.sh script also needs a MACHINE environment variable specifying the type of RPi board.

~/rpi/meta-rpi/scripts$ export MACHINE=raspberrypi3

or

~/rpi/meta-rpi/scripts$ export MACHINE=raspberrypi0-wifi

Then run the copy_boot.sh script passing the location of SD card

~/rpi/meta-rpi/scripts$ ./copy_boot.sh sdb

This script should run very fast.

If you want to customize the config.txt or cmdline.txt files for the system, you can place either of those files in the meta-rpi/scripts directory and the copy_boot.sh script will copy them as well.

Take a look at the script if this is unclear.

copy_rootfs.sh

This script copies the root file system to the second partition of the SD card.

The copy_rootfs.sh script needs the same OETMP and MACHINE environment variables.

The script accepts an optional command line argument for the image type, for example console or qt5. The default is console if no argument is provided.

The script also accepts a hostname argument if you want the host name to be something other then the default MACHINE.

Here’s an example of how you would run copy_rootfs.sh

~/rpi/meta-rpi/scripts$ ./copy_rootfs.sh sdb console

or

~/rpi/meta-rpi/scripts$ ./copy_rootfs.sh sdb qt5 rpi3

The copy_rootfs.sh script will take longer to run and depends a lot on the quality of your SD card. With a good Class 10 card it should take less then 30 seconds.

The copy scripts will NOT unmount partitions automatically. If an SD card partition is already mounted, the script will complain and abort. This is for safety, mine mostly, since I run these scripts many times a day on different machines and the SD cards show up in different places.

Here’s a realistic example session where I want to copy already built images to a second SD card that I just inserted.

~$ sudo umount /dev/sdb1
~$ sudo umount /dev/sdb2
~$ export OETMP=/oe4/rpi/tmp-sumo
~$ export MACHINE=raspberrypi2
~$ cd rpi/meta-rpi/scripts
~/rpi/meta-rpi/scripts$ ./copy_boot.sh sdb
~/rpi/meta-rpi/scripts$ ./copy_rootfs.sh sdb console rpi3

Once past the development stage I usually wrap all of the above in another script for convenience.

Both copy_boot.sh and copy_rootfs.sh are simple scripts, easily customized.

Some custom package examples

spiloop is a spidev test application.

The bitbake recipe that builds and packages spiloop is here

meta-rpi/recipes-misc/spiloop/spiloop_git.bb

Use it to test the spidev driver before and after placing a jumper between pins 19 and 21.

tspress is a Qt5 GUI application installed with the qt5-image. I use it for testing touchscreens.

The recipe is here and can be used a guide for your own applications.

meta-rpi/recipes-qt/tspress/tspress_git.bb

Check the README in the tspress repository for usage.

Adding additional packages

To display the list of available recipes from the meta-layers included in bblayers.conf

~$ source poky-sumo/oe-init-build-env ~/rpi/build

~/rpi/build$ bitbake -s

Once you have the recipe name, you need to find what packages the recipe produces. Use the oe-pkgdata-util utility for this.

For instance, to see the packages produced by the openssh recipe

~/rpi/build$ oe-pkgdata-util list-pkgs -p openssh
openssh-keygen
openssh-scp
openssh-ssh
openssh-sshd
openssh-sftp
openssh-misc
openssh-sftp-server
openssh-dbg
openssh-dev
openssh-doc
openssh

These are the individual packages you could add to your image recipe.

You can also use oe-pkgdata-util to check the individual files a package will install.

For instance, to see the files for the openssh-sshd package

~/rpi/build$ oe-pkgdata-util list-pkg-files openssh-sshd
openssh-sshd:
        /etc/default/volatiles/99_sshd
        /etc/init.d/sshd
        /etc/ssh/moduli
        /etc/ssh/sshd_config
        /etc/ssh/sshd_config_readonly
        /usr/libexec/openssh/sshd_check_keys
        /usr/sbin/sshd

For a package to be installed in your image it has to get into the IMAGE_INSTALL variable some way or another. See the example image recipes for some common conventions.

Playing videos

The RPi project has a hardware-accelerated, command-line video player called omxplayer.

Here’s a reasonably sized example from the Blender project to test

root@rpi3:~# wget https://download.blender.org/demo/movies/Cycles_Demoreel_2015.mov

You can play it like this (-o hdmi for hdmi audio)

root@rpi3:~# omxplayer -o hdmi Cycles_Demoreel_2015.mov
Video codec omx-h264 width 1920 height 1080 profile 77 fps 25.000000
Audio codec aac channels 2 samplerate 48000 bitspersample 16
Subtitle count: 0, state: off, index: 1, delay: 0
V:PortSettingsChanged: 1920x1080@25.00 interlace:0 deinterlace:0 anaglyph:0 par:1.25 display:0 layer:0 alpha:255 aspectMode:0

If you get errors like this

COMXAudio::Decode timeout

Increase memory allocated to the GPU in config.txt

The RPi GPU can support more then one display, (the DSI display is the default), though apps have to be built specifically to support the second display. Omxplayer is an app with this ability.

So for example, with the RPi DSI touchscreen and an HDMI display attached at the same time, you could run a video on the HDMI display from the touchscreen this way

root@rpi3:~# omxplayer --display=5 -o hdmi Cycles_Demoreel_2015.mov
Video codec omx-h264 width 1920 height 1080 profile 77 fps 25.000000
Audio codec aac channels 2 samplerate 48000 bitspersample 16
Subtitle count: 0, state: off, index: 1, delay: 0
V:PortSettingsChanged: 1920x1080@25.00 interlace:0 deinterlace:0 anaglyph:0 par:1.25 display:5 layer:0 alpha:255 aspectMode:0

I was not able to run a eglfs Qt app on the RPi DSI display while simultaneously playing a movie with omxplayer on the HDMI display. Perhaps a linuxfb Qt app that doesn’t use the GPU could run simultaneously. Some more testing is needed.

Using the Raspberry Pi Camera

The raspicam command line tools are installed with the console-image or any image that includes the console-image

• raspistill
• raspivid
• raspiyuv

To enable the RPi camera, add or edit the following in the RPi configuration file config.txt

start_x=1
gpu_mem=128
disable_camera_led=1   # optional for disabling the red LED on the camera

To get access to config.txt, mount the boot partition first

root@rpi# mkdir /mnt/fat
root@rpi# mount /dev/mmcblk0p1 /mnt/fat

Then edit, save and reboot.

root@rpi# vi /mnt/fat/config.txt

or

root@rpi# nano /mnt/fat/config.txt

A quick test of the camera, flipping the image because of the way I have my camera mounted and a timeout of zero so it runs until stopped.

root@rpi2# raspistill -t 0 -hf -vf

s-tui is a terminal UI for monitoring your computer. s-tui allows to monitor CPU temperature, frequency, power and utilization in a graphical way from the terminal.

Screenshot

What it does

• Monitoring your CPU temperature/utilization/frequency/power
• Shows performance dips caused by thermal throttling
• Requires minimal resources
• Requires no X-server
• Built in options for stressing the CPU (stress/stress-ng)

Usage

or

Simple installation

pip (x86 + ARM)

The most up to date version of s-tui is available with pip

Or if you cannot use sudo:

If you are installing s-tui on a Raspberry-Pi you might need to install python-dev first

Options

********s-tui manual********
usage: s-tui [-h] [-d] [-c] [-t] [-j] [-nm] [-v] [-ct CUSTOM_TEMP]

TUI interface:

The side bar houses the controls for the displayed grahps.
At the bottom of the side bar, more information is presented in text form.

* Use the arrow keys or 'hjkl' to navigate the side bar
* Toggle between stressed and regular operation using the radio buttons in 'Modes'.
* If you wish to alternate stress defaults, you can do it in 'Stress options'
* Select a different temperature sensors from the 'Temp Sensors' menu
* Change time between updates using the 'Refresh' field
* Use the 'Reset' button to reset graphs and statistics
* Toggle displayed graphs by selecting the [X] check box
* If a sensor is not available on your system, N/A is presented
* If your system supports it, you can use the utf8 button to get a smoother graph
* Press 'q' or the 'Quit' button to quit

* Run `s-tui --help` to get this message and additional cli options

optional arguments:
  -h, --help            show this help message and exit
  -d, --debug           Output debug log to _s-tui.log
  -c, --csv             Save stats to csv file
  -t, --terminal        Display a single line of stats without tui
  -j, --json            Display a single line of stats in JSON format
  -nm, --no-mouse       Disable Mouse for TTY systems
  -v, --version         Display version
  -ct CUSTOM_TEMP, --custom_temp CUSTOM_TEMP
                        
                        Custom temperature sensors.
                        The format is: <sensors>,<number>
                        As it appears in 'sensors'
                        e.g> sensors
                        it8792-isa-0a60,
                        temp1: +47.0C
                        temp2: +35.0C
                        temp3: +37.0C
                        use: -ct it8792,0 for temp 1
  -cf CUSTOM_FAN, --custom_fan CUSTOM_FAN
                        Similar to custom temp
                        e.g>sensors
                        thinkpad-isa-0000
                        Adapter: ISA adapter
                        fan1:        1975 RPM
                        use: -cf thinkpad,0 for fan1

Dependencies

s-tui is a great tool for monitoring. If you would like to stress your computer, install stress. Stress options will then show up in s-tui (optional)

sudo apt-get install stress

Configuration

s-tui is a self-contained application which can run out-of-the-box and doesn’t need config files to drive its core features. However, additional features like running scripts when a certain threshold has been exceeded (e.g. CPU temperature) does necessitate creating a config directory. This directory will be made in ~/.config/s-tui by default.

Selecting <Save Settings> will save the current configuration to ~/.config/s-tui/s-tui.conf. If you would like to restore defaults, simply remove the file.

Adding threshold scripts

s-tui gives you the ability to run arbitrary shell scripts when a certain threshold is surpassed, like your CPU temperature. You can define this custom behaviour by adding a shell file to the directory ~/.config/s-tui/hooks.d with one of the following names, depending on what threshold you’re interesting in reacting to:

• temperaturesource.sh: triggered when the CPU temperature threshold is exceeded

If s-tui finds a script in the hooks directory with the name of a source it supports, it will run that script every 30 seconds as long as the current value of the source remains above the threshold.

Note that at the moment only CPU temperature threshold hooks are supported.

More installation methods

Ubuntu

The latest stable version of s-tui is available via pip. To install pip on Ubuntu run:
sudo apt-get install gcc python-dev python-pip
Once pip is installed, install s-tui from pip:
(sudo) pip install s-tui

A ppa is available (xenial,bionic)

sudo add-apt-repository ppa:amanusk/python-s-tui
sudo apt-get update
sudo apt-get install python3-s-tui

Arch-Linux

AUR packages of s-tui are available

s-tui is the latest stable release version. Maintined by @DonOregano
s-tui-git follows the master branch. maintained by @MauroMombelli
install with
yay -S s-tui

Run source code

Running s-tui from source
Clone

git clone https://github.com/amanusk/s-tui.git

Install dependencies, these need to be installed to run python -m s_tui.s_tui

(sudo) pip install urwid
(sudo) pip install psutil

Install stress (optional)

sudo apt-get install stress

Run the .py file

(sudo) python -m s_tui.s_tui

OPTIONAL integration of FIRESTARTER (via submodule, does not work on all systems)

FIRESTARTER is a great tool to stress your system to the extreme. If you would like, you can integrate FIRESTARTER submodule into s-tui. To build FIRESTARTER

git submodule init
git submodule update
cd ./FIRESTARTER
./code-generator.py
make

Once you have completed these steps, you can either:

• Install FIRESTARTER to make it accessible to s-tui, e.g make a soft-link to FIRESTARTER in /usr/local/bin.
• Run s-tui from the main project directory with python -m s_tui.s_tui
  An option to run FIRESTARTER will then be available in s-tui

Compatibility

s-tui uses psutil to probe some of your hardware information. If your hardware is not supported, you might not see all the information.

Q&A

Q: How is this different from htop?
A: s-tui is not a processes monitor like htop. The purpose is to monitor your CPU statistics and have an option to test the system under heavy load. (Think AIDA64 stress test, not task manager).

Q: What features require sudo permissions?
A: Top Turbo frequency varies depending on how many cores are utilized. Sudo permissions are required in order to accurately read the top frequency when all the cores are utilized.

Q: I don’t have a temperature graph
A: Systems have different sensors to read CPU temperature. If you do not see a temperature read, your system might not be supported (yet). You can try manually setting the sensor with the cli interface (see –help), or selecting a sensor from the ‘Temp Sensors’ menu

Q: I have a temperature graph, but it is wrong.
A: A default sensor is selected for temperature reads. On some systems this sensor might indicate the wrong temperature. You can manually select a sensor from the ‘Temp Sensors’ menu or using the cli interface (see –help)

Q: I am using the TTY with no X server and s-tui crashes on start
A: By default, s-tui is handles mouse inputs. This causes some systems to crash. Try running s-tui --no-mouse

Q: I am not seeing all the stats in the sidebar.A: The sidebar is scrollable, you can scroll down with DOWN or j or scroll to the bottom with PG-DN or G. You can also decrees the font of you terminal, to view more at once.

Contributing

New issues and Pull Requests are welcome :)

If you notice a bug, please report it as a new issue, using the provided template.

To open a Pull Request, please see CONTRIBUTING for more information.

Tip

If you like this work, please star in on GitHub.

If you realy like it, share it with your friends and co-workers.

If you really really like this work, leave a tip :)

ETH: 0xc169699A825066f2F07E0b29C4082094b32A3F3e

“I love my domain registrar.” Has anyone ever said this? From before Cloudflare even launched in September 2010, our early beta customers were literally begging us: "Will you please launch a registrar too?!" Today we're doing just that, launching the first registrar we hope you’ll be able to say you love. It's built around three principles: trust, security, and always-fair pricing. And it’s available to all Cloudflare customers.

Needing Secure Domain Registration Ourselves

Cloudflare has actually run a registrar for some time. Like many of our best products, it started by solving an internal issue we had. Cloudflare has several mission-critical domains. If the registration of these domains were ever compromised, it would be, in a word, bad.

For years, we worked with our original domain registrar to ensure these domains were as locked down as possible. Unfortunately, in 2013, a hacker was able to compromise several of the systems of the registrar we used and come perilously close to taking over some of our domains.

That began a process of us looking for a better registrar. Unfortunately, even the registrars that charge hefty premiums and promise to be very secure turn out to have pretty lousy security. We ultimately decided the only way to get the level of security we needed was to build a registrar ourselves.

Custom Domain Protection for the Ultra High End

A handful of our customers noticed we had our own registrar and asked us about it. Those conversations turned into our Enterprise Registrar product with Custom Domain Protection for our most security-conscious clients. Every client using Custom Domain Protection defines their own process for updating records. For instance, if a Custom Domain Protection client wants us to not change their DNS records unless 6 different individuals call us, in order, from a set of predefined phone numbers, each reading multiple unique pass codes, and telling us their favorite ice cream flavor, on a Tuesday that is also a full moon, we will enforce that. Literally.

That, obviously, doesn't scale. As a result, we charge a significant premium for our Custom Domain Protection product. (If you're interested you can learn more about it here.) Running that, however, has helped us define a set of best practices that we think every registrar should follow. And that got us thinking: can we build a better registrar for everyone?

What Consumers Hate About Their Current Registrar

With a good idea on how to build a more secure registrar we asked our customers what they hated about their current registrar. Two phrases kept coming up: "bait and switch" and “endless upsell.” If you've ever registered a domain, you know the drill. You get a discounted price when you first register, but with each renewal the price soars. In the best cases we've found, it's around two times the original offer. In the worst, it's more than twenty times. It's gross. That’s in addition to the constant upsells for other products that either should be included for free (for example, DNSSEC) or that you just don’t want (for example, worthless trusted site seals).

The thing is, registering a domain is a commodity. There's no meaningful difference between any of the existing mass market registrars. Each top level domain registry (TLDs like .com .org .info .io, etc) sets a wholesale price for registering a domain under them. These prices are known and remain relatively consistent over time. All the registrar does is record you as the owner of a particular domain. That just involves sending some commands to an API. In other words, domain registrars are charging you for being a middle-man and delivering essentially no value to justify their markup. The more we looked at it, the more crazy the whole market looked to us.

Learning from Making SSL Free

The last time we saw a market as messed up as this was when we looked into the market for SSL certificates. Back in 2014, we decided it was crazy that people should have to pay to be encrypted online. During our Birthday Week celebrations that year, we became one of the first services to say that you should get encryption at no extra cost, even on our free plan. Since then there's been an encryption revolution and we're proud that nearly all forward-thinking services offer SSL for free. If some service you're using still charges you extra to support encryption they’re ripping you off.

Granted, the economics of registering a domain are a bit different, but only a bit. TLDs need to do some work to make sure no two people register the same domain. And it makes sense for there to be some cost to keep someone from just registering every possible combination of characters. But why should registrars charge any markup over what the TLDs charge? That seemed as nutty to us as certificate authorities charging to run a bit of math. When we see a broken market on the Internet we like to do something about it.

The Cloudflare Registrar Promise

Today, on Cloudflare’s 8th birthday, we’re giving all our customers a present: a registrar they can love.

Here's the promise of the Cloudflare Registrar: we'll follow the best possible security practices and offer you the best possible price. What do we mean by that? From the security side, we promise we'll allow you to enable two-factor authentication, we’ll lock your domain registration by default, and automatically enable best-practice security services like DNSSEC.

From the price side it’s even simpler: we promise to never charge you anything more than the wholesale price each TLD charges. That’s true the first year and it’s true every subsequent year. If you register your domain with Cloudflare Registrar you’ll always pay the wholesale price with no markup.

For instance, Verisign, which administers the .com TLD, currently charges $7.85 per year to register a .com domain. ICANN imposes a $0.18 per year fee on top of that for every domain registered. Today, if you transfer your .com domain to Cloudflare, that's what we'll charge you per year: $8.03/year. No markup. All we're doing is pinging an API, there's no incremental cost to us, so why should you have to pay more than wholesale?

You may be able to find a cheaper price somewhere else under some promotion. But, ultimately, there's a wholesale price that the other registrar must cover so inevitably you know there's going to be a bait and switch — with the price getting jacked up in the future — along with endless upsells.

Cloudflare Registrar will also be offering personal data redaction on WHOIS, that meets current ICANN guidelines, for free. Broadcasting the registrant contact information, via the WHOIS service, can invite mountains of spam to your personal addresses. Like your domain, your privacy should not come at a markup.

Rolling Out Cloudflare Registrar

You can't actually register a new domain with the Cloudflare Registrar. Not yet. Today, the service is restricted to existing Cloudflare customers transferring their existing domains to us. If you’ve had trouble transferring domains before, just wait: we’ve made the process extremely smooth and easy.

We anticipate there's going to be quite a bit of demand, so we’ll be rolling invitations out slowly to make sure we provide a terrific transition experience. To claim your place in line, you need to be a Cloudflare customer and sign up for Early Access. Invitations will then go out over the next few weeks based on loyalty: the longer you've used Cloudflare, the sooner you'll get your invitation. Just our way of thanking our most loyal customers and helping them save money on their domain registration fees.

One twist: we’re providing another way to jump to the front of the queue. Just as we want to thank and reward our most tenured customers, we also want to help support those organizations that are attempting to make a meaningful difference in our industry.  One such organization is Girls Who Code, which aims to help close the gender gap in the technology industry.  To support this organization’s efforts, we’re inviting customers to make a contribution to Girls Who Code during the Early Access registration process, and those who do will move to the front of our Early Access invitation queue.

Welcoming Everyone to a Registrar You Can Love

We estimate that if every one of our customers moved their domains to the Cloudflare Registrar, they’d save over $50 million per year. Combined with our Bandwidth Alliance announcement yesterday, we hope the announcements this Birthday Week will save our customers well over $100 million per year they’d been paying for their infrastructure before.

If you're not yet a Cloudflare customer, but you want to use Cloudflare Registrar, we encourage you to sign up for our core service now. We don't prioritize based on how much you pay us — or if you pay us at all — so even new free customers will get a place in the queue.

After we've given existing Cloudflare customers a chance to take advantage of the Cloudflare Registrar, we'll open it up more broadly. At that time, we'll allow new domain registration as well. But, regardless of when you sign up, our promise will always be the same: best security practices at the wholesale registration price. A registrar you can trust, and, we hope, one you can love.

Subscribe to the blog for daily updates on all our Birthday Week announcements.

25 September 2018

I don’t like marzipan. And I don’t like Marzipan.

I haven’t been running Mojave on my machine in the beta period. I always wait for public releases before updating the software on my (only) Mac. I knew what to expect of course. I don’t have my head in the sand. I watched the WWDC keynote, I saw all my friends’ complaints on Twitter, I was braced for it. But, man, these suck.

Marzipan apps are ugly ducklings. As soon as you use them, you can just know these are not at one with the system. You detect that there’s a translation layer of some kind at work here, just like when you use Slack on the Mac you instinctively feel that it’s a web app in a thin wrapper. The underlying implementation is exposed to the user with a bevy of performance sluggishness, UI quirks and non-standard behaviours. That’s bad.

I launch News. I see a window with a reasonable lineup of platform-standard toolbar controls, although I notice that the title of the window is ‘News’. This is a little odd as modern Mac design generally means that the application name is not repeated in the window itself. The title represents the active visible content inside the window, or they simply might not have a visible title at all. Not a universal rule, but certainly not the norm.

Then, only a few pixels down the screen, is the words Apple News repeated again, this time in all-caps. ‘News’ in the menubar, ‘News’ in the titlebar, ‘Apple News’ in the sidebar. Is the word News redundantly displayed in these three different places because that’s what makes sense for the Mac UI? I’d wager it is not a design choice. I think it’s pretty clear that Apple News is in the sidebar because the sidebar is a wholesale port of the iPad interface. iOS on the iPad doesn’t have a menubar or a titlebar, so it isn’t uncommon for apps to put their branding in the app itself. Why is News in the titlebar? In this case, I suspect the Marzipan system houses apps in a window with a titlebar, and it automatically populates the window with the display name of the bundle. Home is the only app of the new set that bucks this pattern, instead using a segmented control as the centred toolbar item.

This first point is arguably a nitpicky detail, but it’s emblematic of the problem I have with these apps. Their fabric is so clearly of another world. A more blatant visual transgression is the News search field. It doesn’t look like a Mac search field. It is bubblier than an Aqua field, the corner radius is off. Moreover, when you press the little ‘X’ button to empty the text, the field loses keyboard focus and hides itself offscreen. That was surprising to me, and anything surprising is unlikely to be following platform idioms that are ingrained into my head. If you type something and then hit ‘escape’, the text box clears, keyboard focus is resigned, but the sidebar search results aren’t reset. I’d pass that last one off as a bug. (Voice Memos and Stocks exhibit the same behaviours, by the way.)

A big landmark sigh of frustration is that all of these Marzipan apps are single window affairs. There’s no attempt to support opening a company stock detail or a news article in its own window. Voice Memos is a particularly bad offender here. When you start a new recording, it takes over the entire window with a modal view. The user loses context of where they were. This is a common pattern on iPhone and iPad but it really feels alien on the Mac.

Home is the worst case of the single window constraints. It is an app that naturally has hierarchy. Single-window iOS uses modal form sheets. Marzipan Mac uses … single-window form sheets. You don’t need to be a designer or a developer to work out where these interfaces came from. It’s transparent. Interestingly, they did change the animation slightly on the Mac — form sheets appear with a quick fade rather than a slide up effect as seen on iPhone and iPad. If this was a real Mac app, it would spawn multiple floating windows, use source lists instead of touch-friendly bubbly tiles, popup menus rather than sliding reels, checkboxes not green switches, etcetera etcetera. I especially like how single clicking on an accessory tile does nothing but make it bounce a little.

Keyboard shortcuts are very patchy. My instinct when making a voice recording was to slam the space bar to pause. It doesn’t work. I went to the menubar and saw that it was greyed out in the current view, but noted that space bar does work during playback. The trip to the menubar showed me an item for ‘Play/Pause Recording’. If you look in iTunes, you will find a ‘Play’ command when a song isn’t playing and a ‘Pause’ command when it is. This dynamic nicety didn’t make it to Voice Memos, ostensibly because iOS doesn’t have a menubar so nobody considered those kind of situations before. For the same reason, the Touch Bar app region is completely blank on all of these ‘new’ apps.

Coming down to some more fundamental issues, I found button interactions to be wonky in places. Consider the ‘Details’ button in Home app for viewing active accessory status. How do buttons work on a computer? You press down with the mouse, and let go. If you press down and decide you don’t want to depress, you move your mouse away. Not so with the ‘Details’ button in the Home app. As soon as you have pressed down, you are committed. It doesn’t matter where your mouse goes. It can leave the bounds of the button, even the frame of the window, and its action will still fire. This issue does not plague most of the buttons in the Marzipan suite, but it was not an isolated occurrence either.

The Home app lets you use a jump bar to navigate to a room quickly through the toolbar item; this is a nice Mac feature. In fact, the equivalent navigation in the iPhone and iPad Home apps is much uglier as it involves an abuse of action sheets. However, you can also navigate between rooms by swiping left or right with the trackpad. This is a downright mess on the Mac. The swipes don’t register consistently, the momentum feels wrong, and sometimes you can make the view bounce as if it has reached the end of the pages, only to swipe again and have it suddenly spawn the next page. There’s also a really ugly rendering glitch with the background. This should not have passed QA.

I already mentioned how everything is single window. Let’s consider the basic window operations. You get the standard rainbow close/minimise/full-screen widgets and they work fine. Window resizing using mouse drags — not so much. The performance is just poor. I use News in this example video, and compare it with resizing equivalent content in Safari, and the difference is night and day. I observe laggy resizing on Home, Voice Memos, Stocks and News, and this is using a 2016 15-inch MacBook Pro. Again, I think this is an inherent part of how these apps are conceived — iOS apps don’t need to worry about live window resizing — bubbling up as user-facing deficiencies.

Here’s one another one I’ll toss out there. Try dragging a News article from the Today screen into a Messages conversation. You can’t do it, you get a funky file permissions error instead. Great. Now try dragging from the Today screen to the desktop. This will work, it will make a webloc shortcut file. However, it takes an extraordinarily long time. You can count many seconds go by before it completes. Whilst this happens, the rest of the app is locked up and cannot be interacted with. I even saw my mouse cursor turn into a beachball when doing this. Copying a link to the desktop.

I debated calling this post ‘Home, News, Stocks and Voice Memos for Mac’ because it’s not really a comment on the Marzipan project initiative. After all, I don’t expect the solution Apple ships next year to have the same laundry list of drawbacks that these Mojave apps do. It’s a critique of the apps that are shipping now to customers of macOS. These apps are preinstalled with the OS. News was even unceremoniously placed into the middle of my Dock upon upgrading. And they are not good, simple as that. I would have been mildly happier if Apple had offered these apps as optional App Store downloads affixed with a beta label.

Functionally, they are a win. These apps make the Mac do things it couldn’t before. That shouldn’t excuse them from blame, though. These are mediocre, bordering on bad, experiences. It’s not a good poster child for the future of the Mac. The Mac — heck Apple as a whole — is about delighting users with good-to-great experiences. What drew me to Apple was never how many bullet points they checked off the feature list.

Carrie Lam, the chief executive of Hong Kong, a semiautonomous Chinese territory, said in a statement on Sunday that Dr. Kao’s work on fiber optics had made a “tremendous contribution to Hong Kong, the world and mankind.” She added that he had also played a prominent role in shaping local higher education and scientific research.

“An eminent figure, Professor Kao is the pride of Hong Kong people,” Ms. Lam said.

Charles Kuen Kao was born in Shanghai on Nov. 4, 1933, to a wealthy family, according to an autobiographical sketch published by the Nobel Foundation. His father, Kao Chun Hsin, was a judge, and his grandfather, Kao Hsieh, had been a Confucian scholar active in a movement to bring down the Qing dynasty during the Chinese Revolution of 1911.

Dr. Kao described his early life in Shanghai as “very pampered and protected.” His family moved to Hong Kong when he was 14, on the brink of China’s Communist Revolution of 1949, and at 19 he sailed to England to study electrical engineering at Woolwich Polytechnic, now known as the University of Greenwich.

Dr. Kao would later admit that he had not been the most diligent university student. “In those days the degrees were awarded as a First, Second, Pass or Fail,” he said. “As I spent more time on the tennis court than with my books, my degree was a Second.”

After graduation, he joined a British subsidiary of International Telephone & Telegraph, and spent the next three decades working for the company in Britain, Europe and the United States. It was during his stint in England that he met his future wife, Gwen Wong, a fellow engineer who worked on an upper floor.