Have you ever wondered what a security probe of a computer sounded
like? I d guess probably not, because on the face of it that doesn t
make a whole lot of sense. But there was a time when I could very
clearly discern the sound of a computer being scanned. It sounded
like a small mechanical heart beat: Click-click
click-click click-click
Prior to 2010, I had a computer under my desk with what at the time
were not unheard-of properties: Its storage was based on a stack of
spinning metal platters (a now-antiquated device known as a hard
drive ), and it had a publicly routable IPv4 address with an
unfiltered connection to the Internet. Naturally it ran Linux and an
ssh server. As was common in those days, service logging was handled
by a syslog daemon. The syslog daemon would sort log messages based
on various criteria and record them somewhere. In most simple
environments, somewhere was simply a
file on local storage.
When writing to a local file, syslog daemons can be optionally
configured to use the
fsync()
system call to ensure that writes are flushed to disk. Practically
speaking, what this meant is that a page of disk-backed memory would
be written to the disk as soon as an event occurred that triggered a
log message. Because of potential performance implications, fsync()
was not typically enabled for most log files. However, due to the
more sensitive nature of authentication logs, it was often enabled for
/var/log/auth.log.
In the first decade of the 2000 s, there was a fairly unsophisticated
worm loose on the Internet that would
probe sshd
with some
common username/password combinations.
The worm would pause for a second or so between login attempts, most
likely in an effort to avoid automated security responses. The effect
was that a system being probed by this worm would generate disk write
every second, with a very distinct audible signature from the hard
drive.
I think this situation is a fun demonstration of a side-channel data
leak. It s primitive and doesn t leak very much information, but it
was certainly enough to make some inference about the state of the
system in question. Of course, side-channel leakage issues have been
a concern for ages, but I like this one for its simplicity. It was
something that could be explained and demonstrated easily, even to
somebody with relatively limited understanding of how computers
work , unlike, for instance
measuring electromagnetic emanations from CPU power management units.
For a different take on the sounds of a computing infrastructure,
Peep (The Network Auralizer)
won an award at a USENIX conference long, long ago. I d love to see a
modern deployment of such a system. I m sure you could build
something for your cloud deployment using something like
AWS EventBridge or
Amazon SQS fairly easily.
For more on research into actual real-world side-channel attacks, you
can read
A Survey of Microarchitectural Side-channel Vulnerabilities, Attacks and Defenses in Cryptography
or
A Survey of Electromagnetic Side-Channel Attacks and Discussion on their Case-Progressing Potential for Digital Forensics.
Just as I did for 2020, I won't publically disclose exactly how many books I read in 2021, but they evidently provoked enough thoughts that felt it worth splitting my yearly writeup into separate posts. I will reveal, however, that I got through more books than the previous year, and, like before, I enjoyed the books I read this year even more in comparison as well.
How much of this is due to refining my own preferences over time, and how much can be ascribed to feeling less pressure to read particular books? It s impossible to say, and the question is complicated further by the fact I found many of the classics I read well worth of their entry into the dreaded canon.
But enough of the throat-clearing. In today's post I'll be looking at my favourite books filed under memoir and biography, in no particular order.
Books that just missed the cut here include: Bernard Crick's celebrated 1980 biography of George Orwell, if nothing else because it was a pleasure to read; Hilary Mantel's exhilaratingly bitter early memoir, Giving up the Ghost (2003); and Patricia Lockwood's hilarious Priestdaddy (2017). I also had a soft spot for Tim Kreider's We Learn Nothing (2012) as well, despite not knowing anything about the author in advance, likely a sign of good writing. The strangest book in this category I read was definitely Michelle Zauner's Crying in H Mart. Based on a highly-recommended 2018 essay in the New Yorker, its rich broth of genuine yearning for a departed mother made my eyebrows raise numerous times when I encountered inadvertent extra details about Zauner's relationships.
Beethoven: A Life in Nine Pieces (2020)
Laura Tunbridge
Whilst it might immediately present itself as a clickbait conceit, organising an overarching narrative around just nine compositions by Beethoven turns out to be an elegant way of saying something fresh about this grizzled old bear. Some of Beethoven's most famous compositions are naturally included in the nine (eg. the Eroica and the Hammerklavier piano sonata), but the book raises itself above conventional Beethoven fare when it highlights, for instance, his Septet, Op. 20, an early work that is virtually nobody's favourite Beethoven piece today. The insight here is that it was widely popular in its time, played again and again around Vienna for the rest of his life. No doubt many contemporary authors can relate to this inability to escape being artistically haunted by an earlier runaway
success.
The easiest way to say something interesting about Beethoven in the twenty-first century is to talk about the myth of Beethoven instead. Or, as Tunbridge implies, perhaps that should really be 'Beethoven' in leaden quotation marks, given so much about what we think we know about the man is a quasi-fictional construction. Take Anton Schindler, Beethoven's first biographer and occasional amanuensis, who destroyed and fabricated details about Beethoven's life, casting himself in a favourable light and exaggerating his influence with the composer. Only a few decades later, the idea of a 'heroic' German was to be politically useful as well; the Anglosphere often need reminding that Germany did not exist as a nation-state prior to 1871, so it should be unsurprising to us that the late nineteenth-century saw a determined attempt to create a uniquely 'German' culture ex nihilo. (And the less we say about Immortal Beloved the better, even though I treasure that film.) Nevertheless, Tunbridge cuts through Beethoven's substantial legacy using surgical precision that not only avoids feeling like it is settling a score, but it also does so in a way that is unlikely to completely alienate anyone emotionally dedicated to some already-established idea of the man to bring forth the tediously predictable sentiment that Beethoven has 'gone woke'.
With Alex Ross on the cult of Wagner, it seems that books about the 'myth of X' are somewhat in vogue right now. And this pattern within classical music might fit into some broader trend of deconstruction in popular non-fiction too, especially when we consider the numerous contemporary books on the long hangover of the Civil Rights era (Robin DiAngelo's White Fragility, etc.), the multifarious ghosts of Empire (Akala's Natives, Sathnam Sanghera's Empireland, etc.) or even the 'transmogrification' of George Orwell into myth.
But regardless of its place in some wider canon, A Life in Nine Pieces is beautifully printed in hardback form (worth acquiring for that very reason alone), and it is one of the rare good books about classical music that can be recommended to both the connoisseur and the layperson alike.
Sea State (2021)
Tabitha Lasley
In her mid-30s and jerking herself out of a terrible relationship, Tabitha Lasley left London and put all her savings into a six-month lease on a flat within a questionable neighbourhood in Aberdeen, Scotland. She left to make good on a lukewarm idea for a book about oil rigs and the kinds of men who work on them: I wanted to see what men were like with no women around, she claims. The result is Sea State, a forthright examination of the life of North Sea oil riggers, and an unsparing portrayal of loneliness, masculinity, female desire and the decline of industry in Britain. (It might almost be said that Sea State is an update of a sort to George Orwell's visit to the mines in the North of England.)
As bracing as the North Sea air, Sea State spoke to me on multiple levels but I found it additionally interesting to compare and contrast with Julian Barnes' The Man with Red Coat (see below). Women writers are rarely thought to be using fiction for higher purposes: it is assumed that, unlike men, whatever women commit to paper is confessional without any hint of artfulness. Indeed, it seems to me that the reaction against the decades-old genre of autofiction only really took hold when it became the domain of millennial women. (By contrast, as a 75-year-old male writer with a firmly established reputation in the literary establishment, Julian Barnes is allowed wide latitude in what he does with his sources and his writing can be imbued with supremely confident airs as a result.) Furthermore, women are rarely allowed metaphor or exaggeration for dramatic effect, and they certainly aren t permitted to emphasise darker parts in order to explore them... hence some of the transgressive gratification of reading Sea State.
Sea State is admittedly not a work of autofiction, but the sense that you are reading about an author writing a book is pleasantly unavoidable throughout. It frequently returns to the topic of oil workers who live multiple lives, and Lasley admits to living two lives herself: she may be in love but she's also on assignment, and a lot of the pleasure in this candid and remarkably accessible book lies in the way these states become slowly inseparable.
Twilight of Democracy (2020)
Anne Applebaum
For the uninitiated, Anne Applebaum is a staff writer for The Atlantic magazine who won a Pulitzer-prize for her 2004 book on the Soviet Gulag system. Her latest book, however, Twilight of Democracy is part memoir and part political analysis and discusses the democratic decline and the rise of right-wing populism. This, according to Applebaum, displays distinctly authoritarian tendencies, and who am I to disagree? Applebaum does this through three main case studies (Poland, the United Kingdom and the United States), but the book also touches on Hungary as well.
The strongest feature of this engaging book is that Appelbaum's analysis focuses on the intellectual classes and how they provide significant justification for a descent into authoritarianism. This is always an important point to be remembered, especially as much of the folk understanding of the rise of authoritarian regimes tends to place exaggerated responsibility on the ordinary and everyday citizen: the blame placed on the working-class in the Weimar Republic or the scorn heaped upon 'white trash' of the contemporary Rust Belt, for example.
Applebaum is uniquely poised to discuss these intellectuals because, well, she actually knows a lot of them personally. Or at least, she used to know them. Indeed, the narrative of the book revolves around two parties she hosted, both in the same house in northwest Poland. The first party, on 31 December 1999, was attended by friends from around the Western world, but most of the guests were Poles from the broad anti-communist alliance. They all agreed about democracy, the rule of law and the route to prosperity whilst toasting in the new millennium. (I found it amusing to realise that War and Peace also starts with a party.) But nearly two decades later, many of the attendees have ended up as supporters of the problematic 'Law and Justice' party which currently governs the country. Applebaum would now cross the road to avoid them, and they would do the same to her, let alone behave themselves at a cordial reception. The result of this autobiographical detail is that by personalising the argument, Applebaum avoids the trap of making too much of high-minded abstract argument for 'democracy', and additionally makes her book compellingly spicy too.
Yet the strongest part of this book is also its weakest. By individualising the argument, it often feels that Applebaum is settling a number of personal scores. She might be very well justified in doing this, but at times it feels like the reader has walked in halfway through some personal argument and is being asked to judge who is in the right. Furthermore, Applebaum's account of contemporary British politics sometimes deviates into the cartoonish: nothing was egregiously incorrect in any of her summations, but her explanation of the Brexit referendum result didn't read as completely sound.
Nevertheless, this lively and entertaining book that can be read with profit, even if you disagree with significant portions of it, and its highly-personal approach makes it a refreshing change from similar contemporary political analysis (eg. David Runciman's How Democracy Ends) which reaches for that more 'objective' line.
The Man in the Red Coat (2019)
Julian Barnes
As rich as the eponymous red coat that adorns his cover, Julian Barnes quasi-biography of French gynaecologist Samuel-Jean Pozzi (1846 1918) is at once illuminating, perplexing and downright hilarious. Yet even that short description is rather misleading, for this book evades classification all manner number of ways.
For instance, it is unclear that, with the biographer's narrative voice so obviously manifest, it is even a biography in the useful sense of the word. After all, doesn't the implied pact between author and reader require the biographer to at least pretend that they are hiding from the reader? Perhaps this is just what happens when an author of very fine fiction turns his hand to non-fiction history, and, if so, it represents a deeper incursion into enemy territory after his 1984 metafictional Flaubert's Parrot. Indeed, upon encountering an intriguing mystery in Pozzi's life crying out for a solution, Barnes baldly turns to the reader, winks and states: These matters could, of course, be solved in a novel. Well, quite.
Perhaps Barnes' broader point is that, given that's impossible for the author to completely melt into air, why not simply put down your cards and have a bit of fun whilst you're at it? If there's any biography that makes the case for a rambling and lightly polemical treatment, then it is this one.
Speaking of having fun, however, two qualities you do not expect in a typical biography is simply how witty they can be, as well as it having something of the whiff of the thriller about it. A bullet might be mentioned in an early chapter, but given the name and history of Monsieur Pozzi is not widely known, one is unlikely to learn how he lived his final years until the closing chapters. (Or what happened to that turtle.) Humour is primarily incorporated into the book in two main ways: first, by explicitly citing the various wits of the day ( What is a vice? Merely a taste you don t share. etc.), but perhaps more powerful is the gentle ironies, bon mots and observations in Barnes' entirely unflappable prose style, along with the satire implicit in him writing this moreish pseudo-biography to begin with.
The opening page, with its steadfast refusal to even choose where to begin, is somewhat characteristic of Barnes' method, so if you don't enjoy the first few pages then you are unlikely to like the rest. (Indeed, the whole enterprise may be something of an acquired taste. Like Campari.) For me, though, I was left wryly grinning and often couldn't wait to turn the page. Indeed, at times it reminded me of a being at a dinner party with an extremely charming guest at the very peak of his form as a wit and raconteur, delighting the party with his rambling yet well-informed discursive on his topic de jour. A significant book, and a book of significance.
Review: Out of Office, by Charlie Warzel & Anne Helen Petersen
Publisher:
Alfred A. Knopf
Copyright:
2021
ISBN:
0-593-32010-7
Format:
Kindle
Pages:
260
Out of Office opens with the provocative assertion that you were
not working from home during the pandemic, even if you were among the 42%
of Americans who were able to work remotely.
You were, quite literally, doing your job from home.
But you weren't working from home. You were laboring in confinement
and under duress. Others have described it as living at work. You
were frantically tapping out an email while trying to make lunch and
supervise distance learning. You were stuck alone in a cramped
apartment for weeks, unable to see friends or family, exhausted, and
managing a level of stress you didn't know was possible. Work became
life, and life became work. You weren't thriving. You were
surviving.
The stated goal of this book is to reclaim the concept of working from
home, not only from the pandemic, but also from the boundary-destroying
metastasis of work into non-work life. It does work towards that goal,
but the description of what would be required for working from home to
live up to its promise becomes a sweeping critique of the organization and
conception of work, leaving it nearly as applicable to those who continue
working from an office. Turns out that the main problem with working from
home is the work part, not the "from home" part.
This was a fascinating book to read in conjunction with
A World Without Email. Warzel and
Petersen do the the structural and political analysis that I sometimes
wish Newport would do more of, but as a result offer less concrete advice.
Both, however, have similar diagnoses of the core problems of the sort of
modern office work that could be done from home: it's poorly organized,
poorly managed, and desperately inefficient. Rather than attempting to
fix those problems, which is difficult, structural, and requires thought
and institutional cooperation, we're compensating by working more. This
both doesn't work and isn't sustainable.
Newport has a background in productivity books and a love of systems and
protocols, so his focus in A World Without Email is on building
better systems of communication and organization of work. Warzel and
Petersen come from a background of reporting and cultural critique, so
they put more focus on power imbalances and power-serving myths about the
American dream. Where Newport sees an easy-to-deploy ad hoc work style
that isn't fit for purpose, Warzel and Petersen are more willing to point
out intentional exploitation of workers in the guise of flexibility. But
they arrive at some similar conclusions. The way office work is organized
is not leading to more productivity. Tools like Slack encourage the
public performance of apparent productivity at the cost of the attention
and focus required to do meaningful work. And the process is making us
miserable.
Out of Office is, in part, a discussion of what would be required
to do better work with less stress, but it also shares a goal with Newport
and some (but not most) corners of productivity writing: spend less time
and energy on work. The goal of Out of Office is not to get more
work done. It's to work more efficiently and sustainably and thus work
less. To reclaim the promise of flexibility so that it benefits the
employee and not the employer. To recognize, in the authors' words, that
the office can be a bully, locking people in to commute schedules and
unnatural work patterns, although it also provides valuable moments of
spontaneous human connection. Out of Office tries to envision a
style of work that includes the office sometimes, home sometimes, time
during the day to attend to personal chores or simply to take a mental
break from an unnatural eight hours (or more) of continuous focus,
universal design, real worker-centric flexibility, and an end to the
constant productivity ratchet where faster work simply means more work for
the same pay.
That's a lot of topics for a short book, and structurally this is a grab
bag. Some sections will land and some won't. Loom's video messages sound
like a nightmare to me, and I rolled my eyes heavily at the VR boosterism,
reluctant as it may be. The section on DEI (diversity, equity, and
inclusion) was a valiant effort that at least gestures towards the dismal
track record of most such efforts, but still left me unconvinced that
anyone knows how to improve diversity in an existing organization without
far more brute-force approaches than anyone with power is usually willing
to consider. But there's enough here, and the authors move through topics
quickly enough, that a section that isn't working for you will soon be
over.
And some of the sections that do work are great. For example, the whole
discussion of management.
Many of these companies view middle management as bloat, waste, what
David Graeber would call a "bullshit job." But that's because bad
management is a waste; you're paying someone more money to essentially
annoy everyone around them. And the more people experience that sort
of bad management, and think of it as "just the way it is," the less
they're going to value management in general.
I admit to a lot of confirmation bias here, since I've been ranting about
this for years, but management must be the most wide-spread professional
job for which we ignore both training and capability and assume that
anyone who can do any type of useful work can also manage people doing
that work. It's simply not true, it creates workplaces full of horrible
management, and that in turn creates a deep and unhelpful cynicism about
all management.
There is still a tendency on the left to frame this problem in terms of
class struggle, on the reasonable grounds that for decades under
"scientific management" of manufacturing that's what it was. Managers
were there to overwork workers and extract more profits for the owners,
and labor unions were there to fight back against managers. But while
some of this does happen in the sort of office work this book is focused
on, I think Warzel and Petersen correctly point to a different cause.
"The reason she was underpaid on the team was not because her boss was
cackling in the corner. It was because nobody told the boss it was
their responsibility to look at the fucking spreadsheet."
We don't train managers, we have no clear expectations for what managers
should do, we don't meaningfully measure their performance, we accept a
high-overhead and high-chaos workstyle based on ad hoc one-to-one
communication that de-emphasizes management, and many managers have never
seen good management and therefore have no idea what they're supposed to
be doing. The management problem for many office workers is less
malicious management than incompetent management, or simply no effective
management at all apart from an occasional reorg and a complicated and
mind-numbing annual review form.
The last section of this book (apart from concluding letters to bosses and
workers) is on community, and more specifically on extracting time and
energy from work (via the roadmap in previous chapters) and instead
investing it in the people around you. Much ink has been spilled about
the collapse of American civic life, about how we went from a nation of
joiners to a nation of isolated individual workers with weak and failing
community institutions. Warzel and Petersen correctly lay some blame for
this at the foot of work, and see the reorganization of work and an
increase in work from home (and thus a decrease in commutes) as an
opportunity to reverse that trend.
David Brooks recently filled in for Ezra Klein on his podcast and
talked with University of Chicago professor Leon Kass, which I listened
to shortly after reading this book. In one segment, they talked about
marriage and complained about the decline in marriage rates. They were
looking for causes in people's moral upbringing, in their life priorities,
in the lack of aspiration for permanence in kids these days, and in any
other personal or moral failing that would allow them to be smugly
judgmental. It was a truly remarkable thing to witness. Neither man at
any point in the conversation mentioned either money or time.
Back in the world most Americans live in, real wages have been stagnant
for decades, student loan debt is skyrocketing as people desperately try
to keep up with the ever-shifting requirements for a halfway-decent job,
and work has expanded to fill all hours of the day, even for people who
don't have to work multiple jobs to make ends meet. Employers have fully
embraced a "flexible" workforce via layoffs, micro-optimizing work
scheduling, eliminating benefits, relying on contract and gig labor, and
embracing exceptional levels of employee turnover. The American worker
has far less of money, time, and stability, three important foundations
for marriage and family as well as participation in most other civic
institutions. People like Brooks and Kass stubbornly cling to their
feelings of moral superiority instead of seeing a resource crisis. Work
has stolen the resources that people previously put into those other areas
of their life. And it's not even using those resources effectively.
That's, in a way, a restatement of the topic of this book. Our current
way of organizing work is not sustainable, healthy, or wise. Working from
home may be part of a strategy for changing it. The pandemic has already
heavily disrupted work, and some of those changes, including increased
working from home, seem likely to stick. That provides a narrow
opportunity to renegotiate our arrangement with work and try to make those
changes stick.
I largely agree with the analysis, but I'm pessimistic. I think the
authors are as well. We're very bad at social change, and there will be
immense pressure for everything to go "back to normal." Those in the best
bargaining position to renegotiate work for themselves are not in the
habit of sharing that renegotiation with anyone else. But I'm somewhat
heartened by how much public discussion there currently is about a more
fundamental renegotiation of the rules of office work. I'm also reminded
of a deceptively profound aphorism from economist Herbert Stein: "If
something cannot go on forever, it will stop."
This book is a bit uneven and is more of a collection of related thoughts
than a cohesive argument, but if you are hungry for more worker-centric
analyses of the dynamics of office work (inside or outside the office), I
think it's worth reading.
Rating: 7 out of 10
DocKnot is my static site generator and software release management
toolkit. It's what generates all of what you're reading.
DocKnot has always supported pointing to external files from inside its
input tree and converting those files to HTML. This is how I include HTML
conversions of POD documentation, CVS logs, text files, and other things
in my web pages. This release starts the migration from an ad hoc text
format for these pointers to YAML, which will permit a much richer
configuration and a consistent format and extension for those external
pointers.
As the first supported format, DocKnot now supports Markdown conversion
(using pandoc). POD conversion is also now supported via both the new
pointer file syntax and the old one, but the latter is deprecated and will
be removed in a later release.
This release also includes some internal reorganization, a fix for RSS
output on systems where the locale isn't set to English, and support for
cutting releases from a main branch instead of a master
branch.
You can get the latest version from CPAN or the
DocKnot distribution page.
If your workstation is using full-disk encryption, you may want to
jump directly to your desktop environment after entering the
passphrase to decrypt the disk. Many display managers like GDM and
LightDM have an autologin feature. However, only GDM can run
Xorg with standard user privileges.
Here is an alternative using startx and a systemd service:
The unit starts after systemd-user-sessions.service, which enables
user logins after boot by removing the /run/nologin file.
With User=bernat, the unit is started with the identity of the
specified user. This implies that Xorg does not run with elevated
privileges.
With PAMName=login, the executed process is registered as a PAM
session for the login service, which includes pam_systemd.
This module registers the session to the systemd login manager.
To be effective, we also need to allocate a TTY with
TTYPath=/dev/tty8. When the TTY is active, the user is granted
additional access to local devices notably display, sound, keyboard,
mouse. These additional rights are needed to get Xorg working
rootless.1 The TERM environment variable is unset because
it would be set to linux by systemd as a result of attaching the
standard input to the TTY. Moreover, we inform pam_systemd we want
an X11 session with Environment=XDG_SESSION_TYPE=x11. Otherwise,
logind considers the session idle unless it receives input on
the TTY. Software relying on the idle hint from logind would be
ineffective.2
The UtmpIdentifier=tty8 and UtmpMode=user directives are just
a nice addition to register the session in /var/run/utmp.
The last step is to execute Xorg through startx. For logind to
allow Xorg to take control of the local devices, chvt 8 switches
to the allocated TTY.3StandardOutput=journal, combined
with the -verbose 3 -logfile /dev/null flags for Xorg, puts the
logs from the X server into the journal instead of using a file.
While equal to the default value, the Restart=no directive
highlights we do not want this unit to be restarted. This ensures
the loginless session is only available on boot. By default,
startx runs xinitrc. If you want to run Kodi instead, add
/usr/bin/kodi-standalone between startx and --.
Drop this unit in /etc/systemd/system/x11-autologin.service and
enable it with systemctl enable x11-autologin.service. Xorg is now
running rootless and logging into the journal. After using it for a
few months, I didn t notice any regression compared to LightDM with
autologin.
For more information on how logind provides access to
devices, see this blog post. The method names do not match the
current implementation, but the concepts are still correct. Xorg
takes control of the session when the TTY is active.
Xorg could change the type of the session itself after
taking control of it, but it does not.
There is some code in Xorg to do that, but it is
executed too late and fails with: xf86OpenConsole: VT_ACTIVATE
failed: Operation not permitted.
Review: The Empress of Salt and Fortune, by Nghi Vo
Series:
Singing Hills Cycle #1
Publisher:
Tordotcom
Copyright:
March 2020
ISBN:
1-250-75029-6
Format:
Kindle
Pages:
119
Cleric Chih is a record-keeper and historian from the Singing Hills abbey.
They have come to Lake Scarlet with their neixin, the hoopoe Almost
Brilliant, because the magical imperial lock placed on the site by the
Empress In-yo has just been lifted. They hope to be one of the first to
catalog what may be found there, but are surprised to encounter an old
woman named Rabbit. Along with a catalog of objects will come a catalog
of stories.
Empress In-yo came from the north, a political bride for Emperor Sung.
She was exiled to Lake Scarlet, to a compound her attendants called
Thriving Fortune as a bitter joke. This is the site that Cleric Chih is
cataloging. The old woman named Rabbit was one of the empress's
attendants. Cleric Chih slowly draws out her stories, often sparked by an
object found in the compound and described in the chapter epigraphs.
The Empress of Salt and Fortune is a short fantasy novella set in a
slightly modified version of China. In-yo comes from a recognizably
Mongolian north, but it's colder and has mammoths. Anh, the analogue of
China, uses magic to ensure that winter never comes. The court politics,
though, seem largely unchanged from our world. The empress from the north
had one important duty: delivery of an heir. Once that was done, the
empire had no more need for her.
That was, as foreshadowed at the start of the novella, not the end of
In-yo or Rabbit's story.
This is a lovely, layered, and subtle story that was a bit too subtle for
my mood when I was reading it. It is the type of story that understates
the emotions of the characters and rewards close reading and paying
attention. I was not paying enough attention and missed a few significant
character developments, which in this concise and careful of a story is
not advisable. If you read this, learn from my experience, take it slow,
and don't expect major plot events to be signaled in neon.
The center of this story is careful and ruthless use of power in a world
that is attempting to deny you any, and the sacrifices that one makes to
reach that power anyway. Both the empress and Rabbit play bad hands with
great effectiveness, taking advantage of the ways in which they're
underestimated. It's a sharp and difficult and quietly angry story with a
good emotional payoff that doesn't deliver a typical ending. I like
stories in which characters make difficult decisions with their eyes wide
open, and then refuse to second-guess them or feel bad about the expected
consequences.
If you like stories about decisive women using and bypassing systems that
were stacked against them, you will probably enjoy this novella.
The Empress of Salt and Fortune won the 2021 Hugo for best novella,
but there is not a lot of fantasy here. It's mostly in the background and
setting of a political and character story, and I'm not sure any of it was
essential to the plot. What it does have is memorable characters and
concise and effective storytelling. We may be living through the golden
age of the novella, at least in the science fiction and fantasy world.
Chih is a quiet and careful questioner who knows the value of patience and
creating space. They don't get much opportunity for characterization in
this novella, but what hints we get of their order's approach are
intriguing. It appears that this series of novellas will be following
Chih rather than the other branches of the story. That will likely keep
me reading.
Followed by When the Tiger Came Down the Mountain.
Rating: 7 out of 10
Happy solstice, and happy
Volunteer Responsibility Amnesty Day!
After my inventory of my code today, I have decided it's time to pass
on moreutils to someone new.
This project remains interesting to people, including me. People still send
patches, which are easy to deal with. Taking up basic maintenance of this
package will be easy for you, if you feel like stepping forward.
People still contribute ideas and code for new tools to add to moreutils.
But I have not added any new tools to it since 2016. There is a big
collections of ideas that I have done nothing with. The problem, I
realized, is that "general-purpose new unix tool" is rather open-ended,
and kind of problimatic. Picking new tools to add is an editorial process,
or it becomes a mishmash of too many tools that are perhaps not general
purpose. I am not a great editor, and so I tightened my requirements
for "general-purpose" and "new" so far that I stopped adding anything.
If you have ideas to solve that, or fearless good taste in curating a
collection, this project is for you.
The other reason it's less appealing to me is that unix tools as a whole
are less appealing to me now. Now, as a functional programmer, I can
get excited about actual general-purpose functional tools. And these are
well curated and collected and can be shown to fit because the math says
they do. Even a tiny Haskell function like this is really very
interesting in how something so maximally trivial is actually usable in so
many contexts.
id :: a -> a
id x = x
Anyway, I am not dropping maintenance of moreutils unless and until someone
steps up to take it on. As I said, it's easy. But I am laying down the
burden of editorial responsibility and won't be thinking about adding new
tools to it.
Thanks very much to Sumana Harihareswara for developing and promoting
the amnesty day idea!
I've been using Vim as my main text editor for 18 years, but for most of that
time I've been using something very close to the default configuration: my
vimrc contained not much more than preferences for indentation and how to
visually indicate white space characters like tabs.
Last but not least, I've used a single colour scheme for most of that time:
Zenburn.
In 20151 I started exploring a few Vim plugins2. To manage
them, I started by choosing a plugin manager,
Pathogen3. Recently I
noticed that the plugin's author, Tim Pope, now recommends new users just use
Vim's built in package management instead. I got curious about Tim Pope's
other plugins: He has written a great deal of them.
Given I've spent most of two decades with a barely-configured Vim, you can
imagine that I don't want to radically alter the way it works, and so I did
not expect to want to use a lot of plugins. The utility of a plugin would have
to outweight the disadvantages of coming to rely on one. But when browsing
Tim's plugins, time and time again, I found myself reacting to description
with How did I manage without this?. And so, I've ended up installing all
of the following, all by Tim Pope:
vim-rsi - readline key mappings in a few sensible places
vim-sleuth Figure out whitespace preferences (tabs, indentation level) from the current buffer
vim-speeddating handle dates (YYYY-MM-DD) properly with the increment/decrement functions (<C-A>, <C-X>)
vim-surround mappings to manage "pairs" of characters nicely (e.g. brackets, quotes)
vim-unimpaired pairs of complementary mappings, e.g. short mappings for :cnext and :cprevious
vim-vinegar quality-of-live improvements to netrw, Vim's built-in file browser
I had to look this up, probably because I started at redhat
I have opinions about Plugins, what supporting them means
architecturally for your application, the interaction with Open
Source, and stuff like that, perhaps for another post.
To try out Vim plugins the first thing you need to figure out is how to manage
them (install, activate, configure). Vim grew a Plugin manager in version 8
(2016). Prior to that, people wrote third-party ones. For this reason there is
a frankly absurd number of Plugin managers, including: Vim's own; Vim Plug;
Vundle; Dein; Volt and Pathogen.
Many developers manage their user-specific application configuration also
known as dotfiles in a version control system such as git. This allows
for keeping track of changes and synchronizing the dotfiles across different
machines. Searching on github, you ll find thousands of dotfile
repositories.
As your dotfiles are sprinkled all over your home directory, managing them in
a single repository is not trivial, i.e. how do you make sure that your
.bashrc, .tmux.conf, etc. that life in your dotfile repository appear in
the proper places in your home directory? The most common solution is to use
symlinks so that the .tmux.conf in your home directory is just a symlink
pointing to the appropriate file in your dotfile repository:
This leads immediately to another problem: how do you manage the symlinks? For
the longest time I just manually maintained the symlinks on the various
machines, but this approach does not scale well with the number of dotfiles
and machines you re using this repository on. Often, people write their own
shell scripts that help them with the maintenance of the symlinks, but at
least the solutions I ve seen so far did not convince me.
Last year I stumbled upon GNU Stow, an unpretentious little tool that
does not reveal at first sight how useful it would be for the job. The
description on the website says:
GNU Stow is a symlink farm manager which takes distinct packages of software
and/or data located in separate directories on the filesystem, and makes
them appear to be installed in the same place.
Right.
How does it work?
In stow s terminology, a package is a set of files and directories that
need to be installed in a particular directory structure. The target
directory is the root of the tree in which the package appear to be
installed.
When you stow a package, stow creates symlinks in the target directory
that point into the package.
Let s say I have my dotfiles repository in ~/git/dotfiles/. Within this
repository, I have a tmux package, containing the .tmux.conf dotfile:
$ pwd
/home/venthur/git/dotfiles
$ find tmux
tmux # the package
tmux/.tmux.conf # the dotfile
The target directory is my home directory, as this is where the symlinks
need to be created. I can now stow the tmux package into the target
directory like so:
$ stow --target=/home/venthur tmux
and stow will create the appropriate symlinks to the contents of the package
into the target directory:
$ ls -l ~/.tmux.conf
lrwxrwxrwx 1 venthur venthur 342. Jun 2021 /home/venthur/.tmux.conf -> git/dotfiles/tmux/.tmux.conf
Note that the name of the package (i.e. the name of the directory) does not
matter as stow points the symlinks into the package, so you can choose
it freely. I usually use the name of the program that the configuration
belongs to as the package name.
Your package can also contain several files or even a complex directory
structure. Let s look at the configuration for neovim, which lives below
~/.config/nvim/:
At this point we should mention that the target directory for my dotfiles will
always be my home directory, so the contents of the packages are either the
configuration files or the directory structure as they live in my home
directory.
Deleting a package from the parent directory
You can also remove (unstow) a package from the target directory again, using
the --delete parameter:
$ ls -l ~/.tmux.conf
lrwxrwxrwx 1 venthur venthur 3418. Dez 22:53 /home/venthur/.tmux.conf -> git/dotfiles/tmux/.tmux.conf
$ stow --target=/home/venthur --delete tmux/
$ ls -l ~/.tmux.conf
ls: cannot access '/home/venthur/.tmux.conf': No such file or directory
Stowing several packages at once
Since your dotfile repository will likely contain more than one package, it
makes sense to combine the individual stow commands into one, so instead of
stowing everything individually,
Note that I use */ instead of * to match all directories (i.e. packages),
since my dotfiles repository also contains a README.md and a makefile.
Putting it all together
My dotfiles repository contains a makefile that allows me to
create/update or delete all symlinks at once:
The --restow parameter tells stow to unstow the packages first before
stowing them again, which is useful for pruning obsolete symlinks from the
target directory.
Et voil ! Whenever I make a change in my dotfiles repository that involves
creating or deleting a dotfile (or a package), I simply call:
$ make
and everything is updated. To delete all dotfile-related symlinks from this
machine, I simply run:
This year I finally bought an e-reader: a "Kobo Libra H2O": a 7" 300ppi
screen with an adjustable colour temperature front light, waterproof,
physical buttons on a "margin"/spine which pushes the case dimensions up
to 8", which is sadly a little too big for most jeans pockets.
In fact this is the second time I've bought one. Sarah and I bought a pair
of Amazon Kindle Paperwhite (2nd generation) readers as Honeymoon
gifts for each other in 2013. Sarah took to hers, but after giving mine a try
and reading a couple of books on it I ended up giving it to my Father-in-law.
The main problem I had with it was the colour temperature of the backlight: it
was too blue and "clinical".
It's interesting to me to realise how the environment that I read in can become
indelibly linked to the memory of that book. One book in particular that I read
on the Kindle was James Smythe's "The Machine", a modern twist on a classic
horror story. This was perfectly complemented by the somewhat pallid, sick
colour of the backlight, especially on its lowest brightness settings. It didn't
go so well with other stories.
Broken Libra H2O e-reader
I got on much better with the Libra H2O. For me, e-books and e-reading has not
replaced traditional paper books, but complemented them, giving me an opportunity
to read in contexts and situations where I couldn't manage with a real book (such
as in the pitch black, lying on my back with a toddler on my chest). I feel that
being able to read more often thanks to the e-reader has spurred me on to read
even paper books more frequently as well.
Unfortunately the screen broke, about 10 months after I bought it! After a bit
of soul-searching on what to do about replacing it, and briefly considering the
latest Amazon Paperwhite (which now has a 300ppi display and adjustable-colour
temperature front-light). This looks like a very nice e-reader: no physical
buttons which is a bit of a shame but narrower without the margin/spine of the
Kobo, so possibly more pocket-friendly. On the other hand, I really felt that I
wanted to avoid giving Amazon the money, for a whole variety of reasons.
Libra 2 e-reader. Spot the difference?
So I instead settled on the "Kobo Libra 2", which is a slight refresh of the
Libra H2O, but almost identical. I'm going to pair it with a nice cover for when
its not in use and hopefully it will last longer than its predecessor.
My current favourite feature on the Libra 2, that I don't remember on the H2O
and I'm fairly sure doesn't exist on Kindles is it supports a "night mode",
which is effectively a reverse video, white-on-black mode. This is fantastic
for keeping the light levels down at night. I was already using the backlight
at about 2% brightness and occasionally found even that too bright.
Boost is a very large and comprehensive set of (peer-reviewed) libraries for the C++ programming language, containing well over 100 individual libraries. The BH package provides a sizeable subset of header-only libraries for (easier, no linking required) use by R. It is fairly widely used: the (partial) CRAN mirror logs (aggregated from the cloud mirrors) show over 28 million package downloads.
Version 1.78.0 of Boost was released in a few days ago on their schedule with April, August and December releases. We follow these releases at a lower (annual) cadence, and BH 1.78.0-0 catches up to Boost 1.78 from the 1.75 version packaged last winter. Three reverse-depends checks revealed only minors needs for changes (after I corrected a fat-finger typo, whoops) in a handful of packages whose maintainers I contacted via PRs or emails. With that, CRAN permitted the upload yesterday. My thanks once again to the maintainers of these packages for helping it along promptly, and of course to the CRAN team.
This release adds the new header-only library Boost Lambda2 offering simple but functional lambda functions (for C++14 and later), as well as Boost Process to manage system processes.
Via my CRANberries, there is a diffstat report relative to the previous release.
Comments and suggestions about BH are welcome via the issue tracker at the GitHub repo.
If you like this or other open-source work I do, you can now sponsor me at GitHub.
Boost is a very large and comprehensive set of (peer-reviewed) libraries for the C++ programming language, containing well over 100 individual libraries. The BH package provides a sizeable subset of header-only libraries for (easier, no linking required) use by R. It is fairly widely used: the (partial) CRAN mirror logs (aggregated from the cloud mirrors) show over 28 million package downloads.
Version 1.78.0 of Boost was released in a few days ago on their schedule with April, August and December releases. We follow these releases at a lower (annual) cadence, and BH 1.78.0-0 catches up to Boost 1.78 from the 1.75 version packaged last winter. Three reverse-depends checks revealed only minors needs for changes (after I corrected a fat-finger typo, whoops) in a handful of packages whose maintainers I contacted via PRs or emails. With that, CRAN permitted the upload yesterday. My thanks once again to the maintainers of these packages for helping it along promptly, and of course to the CRAN team.
This release adds the new header-only library Boost Lambda2 offering simple but functional lambda functions (for C++14 and later), as well as Boost Process to manage system processes.
Via my CRANberries, there is a diffstat report relative to the previous release.
Comments and suggestions about BH are welcome via the issue tracker at the GitHub repo.
If you like this or other open-source work I do, you can now sponsor me at GitHub.
Our project funding work continues with an active bid on the work of packaging a recent gradle in Debian. This month the bidder has been estimating the scope of the entire project.
The Grow Your Ideas project page also has some ambitious initiatives that may evolve into a funded project. The project ideas on that page range from a new wiki for Debian, a more efficient reimbursement process, and the implementation of PPAs for Debian.
We continue to looking forward to hearing about Debian project proposals from various Debian stakeholders. This month has seen work on a survey that will go out to Debian Developers to gather feedback on what they think should be the priorities for funding in the project.
Learn more about the rationale behind this initiative in this article.
Debian LTS contributors
In November 13 contributors were paid to work on Debian LTS, their reports are available below. If you re interested in participating in the LTS or ELTS teams, we welcome participation from the Debian community. Simply get in touch with Jeremiah if you are interested in participating.
Adrian Bunk did 62h out of 56h assigned for November and 6h from October.
Jeremiah Foster is coordinating/managing the LTS team did 29h (out of 10h assigned and 10h from October for LTS administration), and spent 9 hours on Projects funded directly through the project funding program.
Lee Garrett did 9 hours out 60 assigned and carried over 51h into December
Utkarsh Gupta did 30 (out of 40h assigned), thus carrying over 10h to December.
Evolution of the situation
In November we released 31 DLAs.
The security tracker currently lists 23 packages with a known CVE and the dla-needed.txt file has 16 packages needing an update.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Debian security is pretty good, but there s always scope for improvement. Here are some ideas that I think could be used to improve things.
A security wizard , basically a set of scripts with support for plugins that will investigate your system and look for things that can be improved. It could give suggestions on LSMs that could be used, sysctl settings, lists of daemons running as root that possibly don t need root privs, etc. Plugins could be for different daemons, so there could be a plugin for Apache that looks for potential issues with Apache configuration. It wouldn t be possible to cover everything, but it would be possible to cover many common cases. It appears that we used to have a harden package to do some of these things which disappeared. It appears that the only remnant of that is the hardening-runtime package.
Kali Linux [1] is a distribution designed for penetration testing, I recently tried out many of it s features and I was very impressed. While I don t think that the aim should be to copy all Kali features into Debian there are probably some that are worthy of inclusion. Most Kali features run well in a VM, but the Wifi penetration testing tools need access to the hardware, so they could be a good candidate for inclusion in Debian (license permitting).
We have a Securing Debian Manual [2] that is really good. It s a little out of date and needs some contributions, it also needs to be better known.
The Security Management page of the Debian wiki [3] has links to a number of pages about improving system security. It needs some updates, it doesn t have a link to a page about SE Linux so there s some work for me to do there.
Can training help people? I would be happy to run some Debian SE Linux training sessions over Matrix or Jitsi. We can probably find people to offer training on other aspects of Linux security that are implemented in Debian if there is an audience. I don t think that I and other DDs (Debian Developers) can train everyone, but we could train people who then go on to run other training sessions and make the session notes etc available under the GPL.
There would also be some benefits to training other DDs as probably no-one has a good overview of all the security features that are supported.
Any other ideas? Feel free to comment here or start a thread on a public mailing list. If you start a mailing list discussion please email me or comment here with the URL if it s a list that I m not on so I can track it via the archives. This post was inspired by a discussion on a private list of a related topic. I think it s better to have a public discussion instead.
The first time I applied for grad school it was a bit of a lark. I was serious about it, I wanted to go, I had goals, and I am happy to be here now. However, it was a little fun. I took a white paper and crisped it up with the help of some friends who read it and provided comments. I wrote a personal statement, got some letters of recommendation, and generally felt pretty good about the process. It wasn t stressful.
The second time I applied to grad school it was a slog. For several weeks I gave up most of my free time to application writing and when I wasn t working on applications I thought about how I ought to be doing something about it. Applications are due while you re coming up on the end of your semester or end of the year push at work or both! There just isn t enough time for everything. I think even applying for grad school qualifies you to attend.
Here are some things I learned in the application process. Note, I haven t gotten in anywhere (yet), so we ll see how it pans out.
You have to do a lot of research.
This changes by field, school, and even individual faculty preference. Some possible mentors / advisors like to talk with prospective students ahead of time. On two of my applications I was explicitly asked who I spoke with in the department. On others I was asked to list faculty (in order of preference even!) that I would be interested in working with. Some schools requested in essays to list faculty. In general, it s considered important to explain why a particular school: what about that school attracts you? What resources do they have that you want to take advantage of? What research that they are doing interests you?
Faculty profiles and department websites are useful for this, but far from complete. A co-worker suggested I contact someone who, based on their profile, I shared no research interests with. However, we talked and it turns out we had things in common! In general, colleagues, peers, other academics, and friends were the best resource I had for investigating schools and potential faculty.
I also went to some Q&A sessions / office hours run by schools / departments / labs. Some really cool people wrote blog posts and / or Tweets soliciting grad students. These are great.
Sometimes the people you want to work with aren t taking grad students.
Most schools I looked at did not maintain lists of who is taking on grad students starting in the fall, but I think two did. Sometimes I contacted people and got back Sorry, not taking on anyone this year. Try $OtherProfessor. This was actually really helpful! But, it s a downer to learn you re not going to get to work with one of your academic heroes because the timing is wrong.
It s expensive and waivers might not help.
Most applications in the US cost about $100 (USD). In some fields it s recommended you apply to 8-10 schools. That s a lot of money. I think everywhere I applied had a waiver you could apply for, but I generally didn t qualify. Some waivers require you to submit days to weeks ahead of the deadline. Others require that you participate in certain professional organizations, student organizations, or live locally to the school. These might be less useful than you were hoping.
Everyone says your writing sample matters, but only five people will read it.
This is what I was told anyway. I was told that my writing sample (which was 20 pages!) will probably only be read by faculty who are thinking of taking me on as an advisee. Someone else might pick it up and read it out of curiosity. I was told stories about how the right writing sample turned eh, maybe candidates into enthusiastic yeses.
Everyone says letters of recommendation matter and it s extremely frustrating.
My recommenders are all amazing people I have so much respect and admiration for it s wild. They re people I want to be like in my academic career. They also all got their letters in the day they were due. I had a moment where I genuinely thought I was just not going to go to grad school because of how close the deadline was.
I ve been told that a great letter matters a lot, but meh letters don t hold you back as much as it sounds like they will. I ve been told that where a recommender is affiliated matters a lot.
My personal statement radically changed based on school / program.
Two of the schools I applied to had very specific requirements for their personal statements. Other schools wanted me to mostly talk about my research interests. One school had a 350 word personal statement, but a 1,000 word research statement. I wrote a research statement and a personal statement and then used them as the basis for what I submitted to different schools. Each application ended up with something pretty different, and not just because I talked about why each program was exciting to me in different ways.
I also applied to different kinds of programs, and presented myself a differently depending on the program s focus and the faculty. For the more social science heavy programs I emphasized the empirical research I did, while for others I leaned more heavily on my philosophical background and theoretical interests.
Oh, also, I was told to not use contractions. Getting rid of them in all my materials was super tedious.
Diversity Statements are becoming more common.
A few of my schools had diversity statements either required or optional. The purpose of these, I was told, is not to play some sort of marginalization Olympics, but to show that you can talk about diversity (and equity and inclusion, etc) without being offensive. It s just as valid to write about your own disability as the disability of a parent (though, ask their permission first).
Triple check what s required.
I made spreadsheets about what each school required. For example, some people wanted official transcripts, some unofficial. Some places required essays rather than generic personal statements, and I needed to build in enough time to manage that.
Ask your friends to help.
I hate asking for help, but applying for grad school made me shameless. I asked anyone I could to read over materials, proofread, or just talk with me about what I was writing. People picked up on things like you used the word technology five times in this one sentence and it looks real weird.
Some schools have projects where current grad students will even look over materials!
As a follow on to a previous blog entry of mine, Free and Open, I feel it
worthwhile to do my bit to dismantle the pseudo-science and over
simplification in the idea that gender is binary at a biological level.
TL;DR: Science simply does not support binary sexes or binary genders.
Truth is a bit more complicated.
There is certainty and there are binary answers in mathematics. Things
get less definitive in physics, certainly as soon as quantum is
broached. Processes become more of an equilibrium between states in
chemistry, never wholly one or the other. Yes, there is the oddity of
absolute zero but no experiment has yet achieved that fully. It is
accurate to describe physics as a development of applied mathematics
and to view chemistry as applied physics. Biology, at the biochemical
level, is applied chemistry. The sciences build on each other, "on the
shoulders of giants", but at each level, some certainty is lost, some
amount of uncertainty is expanded and measurements become
probabilities, proportions and percentages.
Biology is dependent on biochemistry - chemistry is how a biological
change results in a different organism. Physics is how that chemical
change occurs - temperature, pressure and physical states are inherent
to all chemical changes.
Outside laboratory constraints, few chemical reactions, especially in
organic chemistry, produce one and only one result from two or more
known reagents.
In biology, everyone is familiar with genetic mutations but a genetic
mutation only happens because a biochemical reaction (hydrogen bonding
of nucleobases) does not always produce the expected result. Every cell
division, every viral infection, there is a finite probability that a
change will occur. It might be a small number but it is never zero and
can never be dismissed. This is obvious in the current Covid pandemic -
genetic mutations result in new variants. Some variants are inviable,
some variants produce no net change in the way that the viral particles
infect adjacent cells. Sometimes, a mutation happens that changes
everything. These mutations are not mistakes - these are simply changes
with undetermined outcomes. Genetic changes are the foundation of
biodiversity and variety is what allows lifeforms of all kinds to
survive changes in environmental factors and/or changes in prevalent
diseases.
It is precisely the same in humans, particularly in one of the
principle spheres of human life that involves replicating genetic
material - the creation of gametes for sexual reproduction. Every
single time any DNA is copied, there is a finite chance that a
different base will be put in place compared to the original. Copying
genetic material is therefore non-binary. Given precisely the same
initial conditions, the result is not always predictable and the range
of how the results vary from one to another increases with every
iteration.
Let me stress that - at the molecular level, no genetic operation in
any biological lifeform has a truly binary result. Repeat that
operation sufficiently often and an unexpected result WILL inevitably
occur. It is a mathematical certainty that genetic changes will arise
by attempting precisely the same genetic operation enough times.
Genetic changes are fundamental to how lifeforms survive changing
conditions. Life would likely have died out a long time ago on this
planet if every genetic operation was perfect. Diversity is life.
Similarity leads to extinction.
Viral load is interesting at this point. Someone can be infected with a
virus, including coronavirus, by encountering a small number of viral
particles. Some viruses, it may be a few hundred, some viruses may need
a few thousand particles to infect a vulnerable host. But here's the
thing, for that host to be at risk of infecting another host, the virus
needs the host to produce billions upon billions of copies of the virus
by taking over the genetic machinery within a huge number of cells in
the host. This, as is accepted with Covid, is before the virus has been
copied enough times to produce symptoms in the host. Before those
symptoms become serious, billions more copies will be made. The numbers
become unimaginable - and that is within a single host, let alone the
265 million (and counting) hosts in the current Covid19 pandemic. It's
also no wonder that viral infections cause tiredness, the infection is
diverting huge resources to propagating itself - before even
considering the activity of the immune system.
It is idiocy of the highest order to expect all those copies to be
identical. The rise of variants is inevitable - indeed essential - in
all spheres of biology. A single viral particle is absolutely no threat
of any kind - it must first get inside and then copy the genetic
information in a host cell. This is where the complexity lies in the
definition of life itself. A virus can be considered a lifeform but it
is only able to reproduce using another, more complex, lifeform. In
truth, a viral particle does not and cannot mutate. The infected host
mutates the virus. The longer it takes that host to clear the
infection, the more mutations that host will create and then
potentially spread to others.
Now apply this to the creation of gametes in humans. With seven billion
humans, the amount of copying of genetic material is not as large as
the pandemic but it is still easy for everyone to understand that
children do not merely combine the DNA of both parents. Changes happen.
Human sexual reproduction is not as simple as 1 + 1 = 2. Sometimes, the
copying of the genetic material produces an unexpected result. Sexual
reproduction itself is non-binary. Sexual reproduction is not easy or
simple for lifeforms to adopt - the diversity which results from the
non-binary operations are exactly why so many lifeforms invest so much
energy in reproducing in this way.
Whilst many genetic changes in humans will be benign or beneficial, I d
like to take an example of a genetic disorder that results from the
non-binary nature of sex. Humans can be born with the XY phenotype -
i.e. at a genetic level, the individual has the same combination of
chromosomes as another XY individual but there are changes within the
genes in those chromosomes. We accept this, some children of blonde
parents do not have blonde hair, etc. There are also genetic changes
where an XY phenotype is not binary. Some people, who at a genetic
level would be almost identical to another person who is genetically
male, have a genetic mutation which makes it impossible for the cells
of that individual to respond to androgens (testosterone). (See
Androgen insensitivity syndrome). Genetically, that individual has an X
and a Y chromosome, just like many other individuals. However, due to a
change in how the genes on those chromosomes were copied, that
individual is biologically incapable of constructing the secondary
sexual characteristics of a male. At a genetic level, the individual
has the XY phenotype of a male. At the physical level, the individual
has all the sexual characteristics of a female and none of the sexual
characteristics of a male. The gender of that individual is not binary.
Treatment is centred on supporting the individual and minimising some
risks from the inactive genes on the Y chromosome.
Human sexual reproduction is non-binary. The results of any sexual
reproduction in humans will not always produce the binary option of
male or female. It is a lie to claim that human gender is binary. The
science is in plain view and cannot be ignored.
Identifying as non-binary is not a "cop out" - it can be a biological,
genetic, scientific fact.
Human sexuality and gender are malleable. Where genetic changes result
in symptoms, these can be ameliorated by treatment with human sex
hormones, like oestrogen and testosterone. There are valid medical uses
for anabolic steroids and hormone replacement therapies to help
individuals who, at a genetic level, have non-binary gender. These
treatments can help align the physical outer signs with the personality
and identity of the individual, whether with or without surgery. It is
unacceptable to abandon such people to suffer life long discrimination
and harassment by imposing a binary definition that has no basis in
science.
When a human being has an XY phenotype, that human being is not
necessarily male. That individual will be on a spectrum from female
(left unaffected by sex hormones in the womb, the foetus will be
female, even with an X and a Y chromosome), to various degrees of male.
So, at a genetic, biological level, it is a scientific fact that human
beings do not have binary gender. There is no evidence that this is new
to the modern era, there is no scientific basis for thinking that
copying of genetic material was somehow perfectly reliable in earlier
history, or that such mutations are specific to homo sapiens. Changes
in genetic material provide the diversity to fight infections and adapt
to changing environmental factors. Species have and will continue to go
extinct if this diversity is absent.
With that out of the way, it is no longer a stretch to encompass other
aspects of human non-binary genders beyond the known genetic syndromes
based on changes in the XY phenotype. Science has not uncovered all of
the ways that genes affect personality, behaviour, or identity.
How other, less studied, genetic changes affect the much more subtle
human facets, especially anything to do with consciousness, identity,
personality, sexuality and behaviour, is guesswork. All of these facets
can and likely are being affected by genetic factors as well as
environmental factors in an endless range of permutations. Personality
traits are a beautiful and largely unknowable blend of genes and
environment. Genetic information has a finite probability of changes at
each and every iteration. Environmental factors are more akin to chaos
theory. The idea that the results will fit into binary constructs is
laughable.
Human society puts huge emphasis on societal norms. Individuals who do
not fit into those norms suffer discrimination. The norms themselves
have evolved over time as a response to various influences on human
civilisation but most are not based on science. It is up to all humans
in that society to call out discrimination, to call for changes in the
accepted norms and support those who are marginalised. It is a
precarious balance, one that humans rarely get right, but it must be
based on an acceptance that variation is the natural state. Artificial
constraints, like binary genders, must be dismantled because human
beings and human sexual reproduction are not binary.
To those who think, "well it is for 99%", think again about Covid. 99%
(or closer to 98%) of infected humans recover without notable after
effects. That has still crippled the nations of the globe and humbled
all those who tried to deny it. Five million human beings are dead
because "most infected people recover".
Just because something only affects a proportion of human beings does
not invalidate the suffering of those humans and the discrimination
that those humans will face.
Societal norms are not necessarily correct. Religious and other
influences typically obscure and ignore scientific fact and undermine
human kindness.
The scientific truth of life on this planet is that gender is not
binary.
The more complex the lifeform, the more factors will affect where on
the spectrum any one individual will appear.
Just because we do not yet fully understand how genes affect human
personality and sexuality, does not invalidate the science that
variation is the natural order.
My previous blog about diversity is not just about male vs female, one
nationality vs another, one ethnicity compared to another. Diversity is
diverse. Diversity requires accepting that every facet of humanity is
subject to variation. That leads to tension at times, it is inevitable.
Tension against societal norms, tension against discrimination, tension
around those individuals who would abuse the tolerance of others for
their own gratification or from their own ignorance.
None of us are perfect, none of us have any of this fully sorted and
all of us will make mistakes. Personally, I try to respect those around
me. I will use whatever pronouns and other conventions that the person
requests, from their perspective and not mine. To do otherwise is to
deny the natural order and to deny the science.
Celebrate all diversity, it is the very stuff of life.
Final comments:
The discussions around (typically female) bathroom facilities often
miss the point. The concern is not about individuals who describe
themselves as non-binary. The concern is about individuals who are
fully certain of their own sexuality and who act as sexual predators
for their own gratification. These people are acting out a lie for
their own ends. The problem people are the predators, so stop blaming
the victims who are just as at risk as anyone else who identifies as
female. Maybe the best people to spot such predators are those who are
non-binary, who have had to pretend to fit into societal norms. Just as
travel can be a good antidote to racism, openness and discussion can be
a tool to undermine the lies of sexual predators and reassure those who
are justifiably fearful. There can never be a biological binary test of
gender, there can never be any scientific justification for binary
division of facilities.
Humanity itself is not binary, even life itself has blurry borders
around comas, suspended animation and locked-in syndrome. Legal
definitions of human death vary around the world.
The only common thread I have ever found is: Be kind to each other.
If you find anything above objectionable, then I can only suggest that
you reconsider the science and learn to be kind to your fellow humans.
None of us are getting out of this alive.
My degree is in pharmaceutical sciences and I practised community and
hospital pharmacy for 20 years before moving into programming. I have
direct experience of supporting people who were prescribed hormones to
transition their physical characteristics to match their personal
identity. I had a Christian upbringing but my work showed me that those
religious norms were incompatible with being kind to others, so I
rejected religion and I now consider myself a secular humanist.
Advent of Code 2021Advent of Code, for those not in the know,
is a yearly Advent calendar (since 2015) of coding puzzles many people
participate in for a plenary of reasons ranging from speed coding to code
golf with stops at learning a new language or practicing already known
ones.
I usually write boring C++, but any language and then some can be used.
There are reports of people implementing it in hardware, solving them by
hand on paper or using Microsoft Excel
so, after solving a puzzle the easy way yesterday, this time
I thought: CHALLENGE ACCEPTED! as I somehow remembered an old 2008
article about solving Sudoku with aptitude
(Daniel Burrows via archive.org as the blog is long gone)
and the good same old a package management system that can solve [puzzles] based on package dependency rules is not something that I think would be useful or worth having (Russell Coker).
Day 8 has a rather lengthy
problem description and can reasonably be approached in a bunch of
different way. One unreasonable approach might be to massage the
problem description into Debian packages and let apt help me solve the
problem (specifically Part 2, which you unlock by solving Part 1. You
can do that now, I will wait here.)
Be warned: I am spoiling Part 2 in the following, so solve it yourself
first if you are interested.
I will try to be reasonable consistent in naming things in the following
and so have chosen: The input we get are lines like acedgfb cdfbe gcdfa fbcad dab cefabd cdfgeb eafb cagedb ab cdfeb fcadb cdfeb cdbaf.
The letters are wires mixed up and connected to the segments of the
displays: A group of these letters is hence a digit (the first 10)
which represent one of the digits 0 to 9 and (after the pipe) the four
displays which match (after sorting) one of the digits which means
this display shows this digit. We are interested in which digits are
displayed to solve the puzzle. To help us we also know which segments
form which digit, we just don't know the wiring in the back.
So we should identify which wire maps to which segment!
We are introducing the packages wire-X-connects-to-Y for this which
each provide & conflict1 with the virtual packages segment-Y and
wire-X-connects.
The later ensures that for a given wire we can only pick one segment and
the former ensures that not multiple wires map onto the same segment.
As an example: wire a's possible association with segment b is
described as:
Note that we do not know if this is true! We generate packages for
all possible (and then some) combinations and hope dependency resolution
will solve the problem for us. So don't worry, the hard part will be
done by apt, we just have to provide all (im)possibilities!
What we need now is to translate the 10 digits (and 4 outputs) from
something like acedgfb into digit-0-is-eight and not, say
digit-0-is-one. A clever solution might realize that a one consists
only of two segments so a digit wiring up seven segments can not be
a 1 (and must be 8 instead), but again we aren't here to be clever:
We want apt to figure that out for us! So what we do is simply making
every digit-0-is-N (im)possible choice available as a package and
apply constraints: A given digit-N can only display one number and
each N is unique as digit so for both we deploy Provides
& Conflicts again.
We also need to reason about the segments in the digits: Each of the
digit packages gets Depends on wire-X-connects-to-Y where X is each
possible wire (e.g. acedgfb) and Y each segment forming the digit
(e.g. cf for one). The different choices for X are or'ed together,
so that either of them satisfies the Y.
We know something else too through: The segments which are not used by
the digit can not be wired to any of the Xs. We model this with
Conflicts on wire-X-connects-to-Y.
As an example: If digit-0s acedgfb would be displaying a one
(remember, it can't) the following package would be installable:
Repeat such stanzas for all 10 possible digits for digit-0 and then
repeat this for all the other nine digit-N. We produce pretty much the
same stanzas for display-0(-is-one), just that we omit the second
Provides & Conflicts from above (digit-is-one) as in the display
digits can be repeated. The rest is the same (modulo using display
instead of digit as name of course).
Lastly we create a package dubbed solution which depends on all 10
digit-N and 4 display-N all of them virtual packages apt will have
to choose an installable provider from and we are nearly done!
The resulting Packages file2 we can give to apt while requesting to
install the package solution and it will spit out not only the display
values we are interested in but also which number each digit represents
and which wire is connected to which segment. Nifty!
$ ./skip-aoc 'acedgfb cdfbe gcdfa fbcad dab cefabd cdfgeb eafb cagedb ab cdfeb fcadb cdfeb cdbaf'
[ ]
The following additional packages will be installed:
digit-0-is-eight digit-1-is-five digit-2-is-two digit-3-is-three
digit-4-is-seven digit-5-is-nine digit-6-is-six digit-7-is-four
digit-8-is-zero digit-9-is-one display-1-is-five display-2-is-three
display-3-is-five display-4-is-three wire-a-connects-to-c
wire-b-connects-to-f wire-c-connects-to-g wire-d-connects-to-a
wire-e-connects-to-b wire-f-connects-to-d wire-g-connects-to-e
[ ]
0 upgraded, 22 newly installed, 0 to remove and 0 not upgraded.
We are only interested in the numbers on the display through, so grepping
the apt output (-V is our friend here) a bit should let us end up with
what we need as calculating3 is (unsurprisingly) not a strong suit of
our package relationship language so we need a few shell commands to
help us with the rest.
$ ./skip-aoc 'acedgfb cdfbe gcdfa fbcad dab cefabd cdfgeb eafb cagedb ab cdfeb fcadb cdfeb cdbaf' -qq
5353
I have written the skip-aoc script as a testcase for apt,
so to run it you need to place it in
/path/to/source/of/apt/test/integration and built apt first, but that
is only due to my laziness. We could write a standalone script
interfacing with the system installed apt directly and in any apt
version since
~2011.
To hand in the solution for the puzzle we just need to run this on each
line of the input (~200 lines) and add all numbers together. In other
words: Behold this beautiful shell one-liner:
parallel -I ' ' ./skip-aoc ' ' -qq < input.txt paste -s -d'+' - bc
(You may want to run parallel with -P to properly grill your CPU as
that process can take a while otherwise and it still does anyhow as
I haven't optimized it at all the testing framework does a lot of
pointless things wasting time here, but we aren't aiming for the
leaderboard so )
That might or even likely will fail through as I have so far omitted a
not unimportant detail: The default APT resolver is not able to solve
this puzzle with the given problem description we need another solver!
Thankfully that is as easy as installing apt-cudf (and with it aspcud)
which the script is using via --solver aspcud to make apt hand over the
puzzle to a "proper" solver (or better: A solver who is supposed to be
good at "answering set" questions). The buildds are using this for
experimental and/or backports builds and also for installability checks
via dose3 btw, so you might have encountered it before.
Be careful however: Just because aspcud can solve this puzzle doesn't
mean it is a good default resolver for your day to day apt. One of the
reasons the default resolver has such a hard time solving this here is
that or-groups have usually an order in which the first is preferred over
every later option and so fort. This is of no concern here as all these
alternatives will collapse to a single solution anyhow, but if there are
multiple viable solutions (which is often the case) picking the "wrong"
alternative can have bad consequences. A classic example would be
exim4 postfix nullmailer. They are all MTAs
but behave very different. The non-default solvers also tend to lack
certain features like keeping track of auto-installed packages or
installing Recommends/Suggests. That said, Julian is working on
another solver
as I write this which might deal with more of these issues.
And lastly: I am also relatively sure that with a bit of massaging the
default resolver could be made to understand the problem, but I can't
play all day with this maybe some other day.
Disclaimer: Originally posted in the daily megathread
on reddit, the version here is just slightly better understandable as
I have hopefully renamed all the packages to have more conventional
names and tried to explain what I am actually doing.
No cows were harmed in this improved version, either.
If you would upload those packages somewhere, it would be good
style to add Replaces as well, but it is of minor concern for apt
so I am leaving them out here for readability.
We have generated 49 wires, 100 digits, 40 display and 1 solution
package for a grant total of 190 packages. We are also making use of
a few purely virtual ones, but that doesn't add up to many packages
in total. So few packages are practically childs play for apt given it
usually deals with thousand times more. The instability for those
packages tends to be a lot better through as only 22 of 190 packages
we generated can (and will) be installed. Britney will hate you if
your uploads to Debian unstable are even remotely as bad as this.
What we could do is introduce 10.000 packages which denote every
possible display value from 0000 to 9999. We would then need to
duplicate our 10.190 packages for each line (namespace them) and then
add a bit more than a million packages with the correct dependencies
for summing up the individual packages for apt to be able to display
the final result all by itself. That would take a while through as at
that point we are looking at working with ~22 million packages with
a gazillion amount of dependencies probably overworking every solver
we would throw at it a bit of shell glue seems the better option for
now.
This article was written by David Kalnischkies on apt-get a life and republished here by pulling it from a syndication feed. You should check there for updates and more articles about apt and EDSP.
Last week I attended the UK Systems Research
2021 conference in County Durham, my first
conference in nearly two years (since FOSDEM 2020,
right on the cusp of the Pandemic). The Systems conference community
is very pleasant and welcoming and so when I heard it was going to
take place "physically" again this year I was so keen to attend I
decided to hedge my bets and submit two talk proposals. I wasn't
expecting them both to be accepted
As well as the regular talks (more on those in another post) there is
a tradition for people to give short, impromptu lightning talks after
dinner on the second night. I've given two of these before, and I'd
been considering whether to offer to one this time or not, but with
two talks to deliver (and finish writing) I wasn't sure. Usually
people talk about something interesting that they have been doing
besides their research or day-jobs, but the last two years have been
somewhat difficult and I didn't really think I had a topic to talk
about. Then I wondered if that was a topic in itself
During the first day of the conference (and especially one I'd got
past one of my talks) I started to outline a lightning talk idea and
it seemed to come out well enough that I thought I'd give it a go.
Unusually I therefore had something written down and I was surprised
how well it was received, so I thought I'd share it. Here it is:
I was anticipating the lightning talks and being cajoled into talking
about something. I've done it twice before. So I've been racking my
brains to figure out if I've done anything interesting enough to talk
about.
in 2018 I talked about some hack I'd made to the classic computer game
Doom from 1993. I've done several hacks to Doom that I could probably
talk about except I've become a bit uncomfortable about increasingly
being thought of as "that doom guy". I'd been reflecting on why it was
that I continued to mess about with that game in the first place and I
realised it was a form of expression: I was treating Doom like a canvas.
I've spent most of my career thinking about what I do in the frame of
either science or engineering. I suffer from the creative urge and I've
often expressed (and sated) that through my work. And that's possible
because there's a craft in what we do.
In 2019 I talked about a project I'd embarked on to resurrect my
childhood computer, a Commodore Amiga 500, in order to rescue my
childhood drawings and digital paintings. (There's the artistic thing
again). I'd achieved that and I have ambitions to do some more Amiga
stuff but again that's a work in progress and there's nothing much to
talk about.
In recent years I've been thinking more and more about art and became
interested in the works and writings of people like Grayson Perry,
Laurie Anderson and Brian Eno. I first learned about Eno through his
music but he's also a visual artist. and a music producer. As a producer
in the 70s he co-invented a system to try and break out of writer's
block called "oblique strategies": A deck of cards with oblique
suggestions written on them. When you're stuck, you pull a card and it
might help you to reframe what you are working on and think about it in
a completely different way.
I love this idea and I think we should use more things like that in
software engineering at least.
So back to casting about for something to talk about. What have I been
doing in the last couple of years? Frankly, surviving - I've just about
managed to keep doing my day job, and keep working on the PhD, at home
with two young kids and home schooling and the rest of it. Which is an
achievement but makes for a boring lightning talk. But I'd like to say
that for anyone here who might have been worrying similarly: I think
surviving is more than enough.
I'll close on the subject of thinking like an artist and not an
engineer. I brought some of the Oblique Strategies deck with me and I
thought I'd draw a card to perhaps help you out of a creative dilemma if
you're in one. And I kid you not, the first card I drew was this one:
This post is part of a series called "PACKRAT". If this is the first post
you've found, it'd be worth reading the
intro post first and then looking over
all posts in the series.
In the last post, we left off at being able to send and recieve PACKRAT frames
to and from devices. Since we can transport IPv4 packets over the network,
let s go ahead and see if we can read/write
Ethernet frames from a Linux network
interface, and on the backend, read and write PACKRAT frames over the air.
This has the benifit of continuing to allow Linux userspace tools to work (like
cURL, as we ll try!), which means we don t have to do a lot of work to
implement higher level protocols or tactics to get a connection established
over the link.
Given that this post is less RF and more Linuxy, I m going to include more code
snippits than in prior posts, and those snippits are closer to runable Go, but
still not complete examples. There s also a lot of different ways to do this,
I ve just picked the easiest one for me to implement and debug given my
existing tooling for you, you may find another approach easier to implement!
Again, deviation here is very welcome, and since this segment is the least
RF centric post in the series, the pace and tone is going to feel different.
If you feel lost here, that s OK. This isn t the most important part of
the series, and is mostly here to give a concrete ending to the story arc.
Any way you want to finish your own journy is the best way for you to finish
it!
Implement Ethernet conversion code
This assumes an importable package with a Frame struct, which we can use to
convert a Frame to/from Ethernet. Given that the PACKRAT frame has a field that
Ethernet doesn t (namely, Callsign), that will need to be explicitly passed
in when turning an Ethernet frame into a PACKRAT Frame.
...// ToPackrat will create a packrat frame from an Ethernet frame.
funcToPackrat(callsign [8]byte, frame*ethernet.Frame) (*packrat.Frame, error)
varframeTypepackrat.FrameTypeswitchframe.EtherTypecaseethernet.EtherTypeIPv4:
frameType = packrat.FrameTypeIPv4default:
returnnil, fmt.Errorf("ethernet: unsupported ethernet type %x", frame.EtherType)
return&packrat.FrameDestination: frame.Destination,
Source: frame.Source,
Type: frameType,
Callsign: callsign,
Payload: frame.Payload,
, nil// FromPackrat will create an Ethernet frame from a Packrat frame.
funcFromPackrat(frame*packrat.Frame) (*ethernet.Frame, error)
varetherTypeethernet.EtherTypeswitchframe.Typecasepackrat.FrameTypeRaw:
returnnil, fmt.Errorf("ethernet: unsupported packrat type 'raw'")
casepackrat.FrameTypeIPv4:
etherType = ethernet.EtherTypeIPv4default:
returnnil, fmt.Errorf("ethernet: unknown packrat type %x", frame.Type)
// We lose the Callsign here, which is sad.
returnðernet.FrameDestination: frame.Destination,
Source: frame.Source,
EtherType: etherType,
Payload: frame.Payload,
, nil
Our helpers, ToPackrat and FromPackrat can now be used to transmorgify
PACKRAT into Ethernet, or Ethernet into PACKRAT. Let s put them into use!
Implement a TAP interface
On Linux, the networking stack can be exposed to userland using TUN or
TAP interfaces. TUN devices allow a
userspace program to read and write data at the Layer 3 / IP layer. TAP devices
allow a userspace program to read and write data at the Layer 2 Data Link /
Ethernet layer. Writing data at Layer 2 is what we want to do, since we re
looking to transform our Layer 2 into Ethernet s Layer 2 Frames. Our first job
here is to create the actual TAP interface, set the MAC address, and set the IP
range to our pre-coordinated IP range.
...import (
"net""github.com/mdlayher/ethernet""github.com/songgao/water""github.com/vishvananda/netlink"
)
...config:=water.ConfigDeviceType: water.TAPconfig.Name = "rat0"iface, err:=water.New(config)
...netIface, err:=netlink.LinkByName("rat0")
...// Pick a range here that works for you!
//
// For my local network, I'm using some IPs
// that AMPR (ampr.org) was nice enough to
// allocate to me for ham radio use. Thanks,
// AMPR!
//
// Let's just use 10.* here, though.
//
ip, cidr, err:=net.ParseCIDR("10.0.0.1/24")
...cidr.IP = iperr = netlink.AddrAdd(netIface, &netlink.AddrIPNet: cidr,
Peer: cidr,
)
...// Add all our neighbors to the ARP table
for_, neighbor:=rangeneighborsnetlink.NeighAdd(&netlink.NeighLinkIndex: netIface.Attrs().Index,
Type: netlink.FAMILY_V4,
State: netlink.NUD_PERMANENT,
IP: neighbor.IP,
HardwareAddr: neighbor.MAC,
)
// Pick a MAC that is globally unique here, this is
// just used as an example!
addr, err:=net.ParseMAC("FA:DE:DC:AB:LE:01")
...netlink.LinkSetHardwareAddr(netIface, addr)
...err = netlink.LinkSetUp(netIface)
varframe = ðernet.Framevarbuf = make([]byte, 1500)
forn, err:=iface.Read(buf)
...err = frame.UnmarshalBinary(buf[:n])
...// process frame here (to come)
...
Now that our network stack can resolve an IP to a MAC Address (via ip neigh
according to our pre-defined neighbors), and send that IP packet to our daemon,
it s now on us to send IPv4 data over the airwaves. Here, we re going to take
packets coming in from our TAP interface, and marshal the Ethernet frame into a
PACKRAT Frame and transmit it. As with the rest of the RF code, we ll leave
that up to the implementer, of course, using what was built during Part 2:
Transmitting BPSK symbols and Part 4: Framing
data.
...for// continued from above
n, err:=iface.Read(buf)
...err = frame.UnmarshalBinary(buf[:n])
...switchframe.EtherTypecase0x0800:
// ipv4 packet
pack, err:=ToPackrat(
// Add my callsign to all Frames, for now
[8]byte'K', '3', 'X', 'E', 'C' ,
frame,
)
...err = transmitPacket(pack)
......
Now that we have transmitting covered, let s go ahead and handle the recieve
path here. We re going to listen on frequency using the code built in
Part 3: Receiving BPSK symbols and
Part 4: Framing data. The Frames we decode from
the airwaves are expected to come back from the call
packratReader.Next in the code below, and the exact way that works
is up to the implementer.
...for// pull the next packrat frame from
// the symbol stream as we did in the
// last post
packet, err:=packratReader.Next()
...// check for CRC errors and drop invalid
// packets
err = packet.Check()
...ifbytes.Equal(packet.Source, addr)
// if we've heard ourself transmitting
// let's avoid looping back
continue// create an ethernet frame
frame, err:=FromPackrat(packet)
...buf, err:=frame.MarshalBinary()
...// and inject it into the tap
err = iface.Write(buf)
......
Phew. Right. Now we should be able to listen for PACKRAT frames on the
air and inject them into our TAP interface.
Putting it all Together
After all this work weeks of work! we can finally get around to putting
some real packets over the air. For me, this was an incredibly satisfying
milestone, and tied together months of learning!
I was able to start up a UDP server on a remote machine with an RTL-SDR dongle
attached to it, listening on the TAP interface s host IP with my defined MAC
address, and send UDP packets to that server via PACKRAT using my laptop,
/dev/udp and an Ettus B210, sending packets into the TAP interface.
Now that UDP was working, I was able to get TCP to work using two PlutoSDRs,
which allowed me to run the cURL command I pasted in the first post (both
simultaneously listen and transmit on behalf of my TAP interface).
It s my hope that someone out there will be inspired to implement their own
Layer 1 and Layer 2 as a learning exercise, and gets the same sense of
gratification that I did! If you re reading this, and at a point
where you ve been able to send IP traffic over your own Layer 1 / Layer 2,
please get in touch! I d be thrilled to hear all about it. I d love to link
to any posts or examples you publish here!
Welcome to the November 2021 report from the Reproducible Builds project.
As a quick recap, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is therefore to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. If you are interested in contributing to our project, please visit our Contribute page on our website.
On November 6th, Vagrant Cascadian presented at this year s edition of the SeaGL conference, giving a talk titled Debugging Reproducible Builds One Day at a Time:
I ll explore how I go about identifying issues to work on, learn more about the specific issues, recreate the problem locally, isolate the potential causes, dissect the problem into identifiable parts, and adapt the packaging and/or source code to fix the issues.
In the role of a packager, updating packages is a recurring task. For some projects, a packager is involved in upstream maintenance, or well written release notes make it easy to figure out what changed between the releases. This isn t always the case, for instance with some small project maintained by one or two people somewhere on GitHub, and it can be useful to verify what exactly changed. Diffoscope can help determine the changes between package releases. []
diffoscopediffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb made the following changes, including preparing and uploading versions 190, 191, 192, 193 and 194 to Debian:
New features:
Continue loading a .changes file even if the referenced files do not exist, but include a comment in the returned diff. []
Log the reason if we cannot load a Debian .changes file. []
Bug fixes:
Detect XML files as XML files if file(1) claims if they are XML files or if they are named .xml. (#999438)
Don t duplicate file lists at each directory level. (#989192)
Don t raise a traceback when comparing nested directories with non-directories. []
Re-enable test_android_manifest. []
Don t reject Debian .changes files if they contain non-printable characters. []
Codebase improvements:
Avoid aliasing variables if we aren t going to use them. []
Use isinstance over type. []
Drop a number of unused imports. []
Update a bunch of %-style string interpolations into f-strings or str.format. []
When pretty-printing JSON, mark the difference as being reformatted, additionally avoiding including the full path. []
Import itertools top-level module directly. []
Chris Lamb also made an update to the command-line client to trydiffoscope, a web-based version of the diffoscope in-depth and content-aware diff utility, specifically only waiting for 2 minutes for try.diffoscope.org to respond in tests. (#998360)
In addition Brandon Maier corrected an issue where parts of large diffs were missing from the output [], Zbigniew J drzejewski-Szmek fixed some logic in the assert_diff_startswith method [] and Mattia Rizzolo updated the packaging metadata to denote that we support both Python 3.9 and 3.10 [] as well as a number of warning-related changes[][]. Vagrant Cascadian also updated the diffoscope package in GNU Guix [][].
Software development
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:
Elsewhere, in software development, Jonas Witschel updated strip-nondeterminism, our tool to remove specific non-deterministic results from a completed build so that it did not fail on JAR archives containing invalid members with a .jar extension []. This change was later uploaded to Debian by Chris Lamb.
reprotest is the Reproducible Build s project end-user tool to build the same source code twice in widely different environments and checking whether the binaries produced by the builds have any differences. This month, Mattia Rizzolo overhauled the Debian packaging [][][] and fixed a bug surrounding suffixes in the Debian package version [], whilst Stefano Rivera fixed an issue where the package tests were broken after the removal of diffoscope from the package s strict dependencies [].
Testing framework
The Reproducible Builds project runs a testing framework at tests.reproducible-builds.org, to check packages and other artifacts for reproducibility. This month, the following changes were made:
Holger Levsen:
Document the progress in setting up snapshot.reproducible-builds.org. []
Extend testing to include Debian bookworm too.. []
Automatically create the Jenkins view to display jobs related to building the Live images. []
Vagrant Cascadian:
Add a Debian package set group for the packages and tools maintained by the Reproducible Builds maintainers themselves. []
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
Just as 
Happy solstice, and happy
I've been using Vim as my main text editor for 18 years, but for most of that
time I've been using something very close to the default configuration: my
Many developers manage their user-specific application configuration also
known as dotfiles in a version control system such as 
As a follow on to a previous blog entry of mine, 
](https://jmtd.net/log/lightning/tweet.jpg)
Now that UDP was working, I was able to get TCP to work using two PlutoSDRs,
which allowed me to run the cURL command I pasted in the first post (both
simultaneously listen and transmit on behalf of my TAP interface).
It s my hope that someone out there will be inspired to implement their own
Layer 1 and Layer 2 as a learning exercise, and gets the same sense of
gratification that I did! If you re reading this, and at a point
where you ve been able to send IP traffic over your own Layer 1 / Layer 2,
please get in touch! I d be thrilled to hear all about it. I d love to link
to any posts or examples you publish here!
