Nick Pettigrew was an anti-social behavior officer for council housing for
over a decade. This book is a diary of one year in the life of that job.
According to the author, the dates, names, and some of the identifying
details have been changed but not exaggerated. While it's hard to verify
that, and I'm sure a few of the stories have been tweaked to make better
narratives, it has a messiness and chaos of half-resolved drama mixed with
mundane office tedium that makes it ring true.
The subject matter requires some explanation for US readers.
Council housing is the UK's version of what the US would call public
housing or "the projects," although it's a far larger percentage of the
housing stock in the UK than it is in the US. These are buildings built
by the government and run by local governments or non-profits to provide
housing to working class and poor people at reduced cost compared to the
private market. As in the US, new council housing construction has
dropped off dramatically; as in the US, a bunch of it has been privatized,
although in the UK the Right to Buy law at least sells the housing to the
people living in it, as opposed to slumlords.
The 1998 UK Crime and Disorder Act collects under anti-social behavior a
bunch of low-grade irritations that in the US would fall under public
nuisance laws, noise ordinances, and other vague misdemeanors like
"creating a public disturbance": essentially, all the irritating and
obnoxious things that people subject their neighbors to, but which fall
short of obvious criminal behavior like theft or assault. As Pettigrew
puts it:
"I just don't want to hear the word 'cunt' shouted repeatedly at 3am
every night any more. I don't think that's unreasonable."
That law required the organizations managing council estates to have a
procedure to deal with anti-social behavior, and thus the job of an
anti-social behavior officer was created.
In the US, these sorts of problems are dealt with by the local police,
which is a little like trying to get rid of a raccoon by running it over
with a balky, thirty-year-old car. The best outcome is that the raccoon
gets freaked out by your efforts to get the car to start and leaves. The
worst outcome is that you accidentally run over your neighbor's kid while
aiming for the raccoon. Either way, neither you nor the car nor your
neighbors are going to be happy about the process.
An anti-social behavior officer is someone with some authority to do
things like install cameras, tell people who don't live somewhere that
they need to stop coming there, and start eviction proceedings, but who
doesn't carry guns, can't arrest people, and enforces those rules when
necessary via court proceedings or calling the police. In other words,
it's one of the types of alternative responders whose job is to solve
problems rather than stop crimes that we've been talking about in the
United States. And although Pettigrew is quite grumpy and cynical about
his job (for very understandable reasons explained in this book), my
takeaway from another country with even worse problems is that the system
sort of works. It's underfunded and poorly managed and nebulous and
sometimes very sad, but it also achieves some of what it sets out to do,
and you can see the outlines of a better system beneath it.
My favorite thing about this book is that it forces the reader to grapple
with the actual job in all its messiness, rather than our ideals of what
we want the job to be. For example, if you're going to hire a bunch of
people to do this job, you need some way to figure out whether they're any
good at it, but it's not obvious how to measure success.
One infuriating KPI we're measured on is the final question a resident
is asked once their case is closed: "Are you happy with the outcome of
your case?" Because unless you evict the problem neighbor within a
fortnight, erect a security wall around the complainant's house
manned by armed guards, and bake them a cake, the answer will almost
certainly be no.
Pettigrew has a background in comedy so he's sarcastically funny rather
than strident or didactic, which for me was just the tone I needed to
enjoy reading this enough to think deeply about it.
The thing that most surprised me, even though it probably shouldn't, was
just how many of the problems Pettigrew had to deal with stemmed from
drugs. My guess is that a good 75% of the issues he described were a
direct result of someone dealing drugs, growing drugs, stealing things to
buy drugs, throwing parties with druggie friends, doing bizarre and
dangerous things because they were on drugs, not taking care of their
property because they were too busy doing drugs, or letting their property
be taken over by other people doing or selling drugs. It's just
never-ending. The case load is clearly made worse by chronic
understaffing and underfunding, and spending more money on giving people
more assistance is part of any reasonable solution, but so is reducing the
demand. If the pattern of complaints in the US is at all similar (and I
bet it is), it's no wonder that the police perceive drugs as central to
their job.
Pettigrew talks about this at some length in the epilogue, and I think one
of his conclusions is worth quoting here:
Years of interacting with class A drug users has shown me that they
really don't want to be out hustling to make enough money for their
next score of diluted heroin. They want to sit at home, take drugs
and when those drugs wear off, take some more. You may view this as a
wasted life, and you may well be right, but here's the thing: they are
going to do this anyway, whether we decide to criminalize them or not.
If, after a lengthy period of honest, mature drug education across the
country via schools, further education, government advertising and so
on, class A drugs were made legally available on prescription to
adults via pharmacies, the vast majority of users would pick up their
prescriptions, go home, take their drugs and leave everyone else
alone. They couldn't be arsed to break into your car if they didn't
have to.
The decriminalization argument is a lot larger than the space of this book
review, so I won't get into it further, except to say that if you think
that conclusion sounds unreasonable or dangerous or destructive to
society, consider reading this book. One of the things that becomes
obvious from Pettigrew's diary of incidents is that most people just want
to feel safe, and a truly stunning amount of crime and anti-social
behavior that makes them feel not safe is a direct or indirect result of
people trying to get drugs or to get money to get drugs.
The other pattern that's obvious from this book (and obvious from most
writing by anyone involved in the justice system) is that the system
doesn't really work.
The best way to describe going to court is that it's like paying a
visit to a run-down hospital where nobody gets better.
Some of that is because it's not set up to solve problems, and a lot of
that is because solving problems is a lot more expensive than we want to
admit and we don't want to pony up the resources.
I'm probably making this book sound hopelessly depressing, but it's not.
It's angry and cynical, but it's also very funny (particularly if you like
sarcasm), extremely quotable, insightful, and deeply empathetic. There
are people trying their best to help other people despite a system that
doesn't reward them for doing so, and surprisingly often they manage to do
so. The path to helping more people isn't even that difficult to find.
The epilogue of this book is full of solid and straightforward ideas that
don't require some novel insight into humanity, just a bunch of hard work.
And, while reading about the work of helping people and being exasperated
by people, you'll also get to laugh at the bits of office nonsense that
are universal.
The old form for monthly one-to-ones used to have two questions
"What did you do over the last month?" and "What do you plan to do in
the next month?" and my line manager at the time seemed unimpressed
when I answered "my job" to both.
I loved this book. It was one of my favorite random finds of the year,
and, at least judging from how difficult it is to find in Amazon search
results, it's not gotten enough attention in the United States. Highly
recommended.
Rating: 9 out of 10
There are a lot of rain clouds in life these days. May we all remember that days like this one are behind us and also ahead of us.
Every storm runs out of rain.
That was the start of a series of photos from my collection & quotes I shared with friends during the initial lockdown in spring. I ll be sharing some here.
And here we all are, still dealing with this and it s more severe in a lot of ways. One of my colleagues won t be able to see his parents this Christmas for the first time in over 40 years.
But this storm will run out rain.
And look how the scene changed, in just a few minutes. This is coming!
Recently, I needed to package a Rust crate libslirp for a Apertis, a Debian derivative. libslirp is used by the newly release UML backend of debos, our Debian image build tool. Unfortunately, this crate hasn t yet been properly packaged for Debian proper, so I could not simply pull the packaging from Debian. Even worse, its build dependencies haven t all been packaged yet. Most importantly, I have only uploaded zbus to Debian today, and at that time none of its dependencies were in Debian either.
Another issue with this were that each crate is packaged for Debian as a separate package, making the process a bit more tricky since I d need to import all of the crates into Apertis separately. Doing that takes time and is further complicated by the CI loop we re using which requires the full build process to complete for a package before a pipeline a dependent package can run.
Having all that considered, I took a shortcut: I vendored all the build dependencies with the package itself, and here s how.
I started with debcargo-conf, where the not-yet-complete packaging lives. With debcargo, I generated the source package as if I were to upload to Debian. Since I ll be vendoring the dependencies, I have removed most of the Rust dependencies and replaced them with those extra dependencies needed by those crates.
So, I replaced this:
I wanted to keep the delta to the future Debian package at a bare minimum, so I kept the original dh-cargo build process, only making sure the vendored dependencies are found in the right place. The cleanest approach in my view was to use the fact that the 3.0 (quilt) source format allows multiple original tarballs: the main tarball would be the same orig tarball as in Debian, and an extra tarball would contain the vendored code. When we sync with Debian, the extra tarball would be dropped, just as the adjustments to the debian/rules.
To generate the vendor tarball, I added this to the rules file:
include /usr/share/dpkg/pkg-info.mkvendor:
-[ -d vendor ]&& rm -rf vendor
rm -rf Cargo.lock
cargo vendor
tar Jcf ../$(DEB_SOURCE)_$(DEB_VERSION_UPSTREAM).orig-vendor.tar.xz vendor/
.PHONY:vendor
This target, being run manually and not as part of the build process, download the latest dependencies satisfying the requirements in Cargo.toml and rolls them into a vendor tarball.
Now, to make dh-cargo use the vendored code, we need to link it into the right place. dh-cargo creates a Cargo registry tree in a subdirectly under debian/ where it symlinks crates from the Rust development packages. This extra code makes sure the vendored dependencies are available there too:
override_dh_auto_configure:
dh_auto_configure $@for d in vendor/* ;\do\[ -L debian/cargo_registry/$$(basename $$d)]&& rm debian/cargo_registry/$$(basename $$d);\
ln -rs $$d debian/cargo_registry ;\done
An important thing here is that if the build happens on a non-clean system, dh-cargo may have symlinked a system crate already installed so we need to remove that symlink and replace it by ours. We build packages in clean chroots, so this is not that important, otherwise for reproducibility reasons it would be better to create the registry directory from scratch.
The final package can be found at the Apertis GitLab.
As announced recently I prepared a monitoring-plugins 2.3 package for experimental. If there is enough positive feedback until 12th January 2021, I intend to upload this into unstable targeted for Debian Bullseye.
Fifteen years have passed since I started my career in IT which is quite some time. I've been playing with computers for 25 years now, which makes me quite knowledgeable about the field, for sure.However, while I was fully prepared to bargain with computers, I was not prepared to do so with humans. The whole career management thing was unknown to me. I had no useful skills to navigate within the enterprise organization. I had to learn the ropes the hard way, failing along the way. It hurt.Almost ten years ago, I had the chance to meet a new colleague Alexis Monville. Alexis was a team facilitator, and I started to work with him on many non-technical levels. He taught me a lot about agility and team organization. Working on this set of new skills changed how I envisioned my work and how I fit into the company.Alexis MonvilleI worked on those aspects of my job because I decided to be in charge of my career rather than keeping things boring. That was one of the best decisions I ever made. Growing the social aspect of my profession allowed me to develop and find aspiring jobs and missions.Getting to that point takes a lot of time and effort, and it's pretty hard to do it alone. My friend Alexis wrote an excellent book titled I am a Software Engineer and I am in Charge. I'm proud to have been the first reviewer the book before it was released a few weeks ago.Many developers out there are stuck in a place where they are not excited by their colleagues' work and whose managers do not appropriately recognize their achievement. It would be best for them if they did something about that.The book!This book is an excellent piece for engineers who wants to break the cycle of frustration. It covers many situations I encountered across my professional life those last years, giving good insights into how to solve them.To paraphrase Alexis, the answers to your career management problems are not on StackOverflow they're not technical issues. However, you can still solve them with the right tools. That's where I am a Software Engineer and I am in Charge shines. It gives you leads, solutions, and exercise to get out of this kind of situation. It helps increase your impact and satisfaction at work.I love this book, and I wish I had access to it years ago. Developing technical leadership is not easy and requires a mindset shift. Having a way to bootstrap yourself with this is a luxury.If you're a software engineer at the beginning of your career or struggling with your current professional situation, I profoundly recommend reading this book! You'll get a fast track on your career, for sure.
TL;DR: CPS-conversion and defunctionalization can help you to come up with a constant-stack algorithm.
Update: Turns out I inadvertedly plagiarized the talk The Best Refactoring You ve Never Heard Of by James Koppel. Please consider this a form of sincere flattery.
The starting point
Today, I ll take you on a another little walk through the land of program transformations. Let s begin with a simple binary tree, with value of unknown type in the leaves, as well as the canonical map function:
dataT a =L a B (T a) (T a)
map1 :: (a -> b) ->T a ->T b
map1 f (L x) =L (f x)
map1 f (B t1 t2) =B (map1 f t1) (map1 f t2)
As you can see, this map function is using the program stack as it traverses the tree. Our goal is now to come up with a map function that does not use the stack!
Why? Good question! In Haskell, there wouldn t be a strong need for this, as the Haskell stack is allocated on the heap, just like your normal data, so there is plenty of stack space. But in other languages or environments, the stack space may have a hard limit, and it may be advised to not use unbounded stack space.
That aside, it s a fun exercise, and that s sufficient reason for me.
(In the following, I assume that tail-calls, i.e. those where a function end with another function call, but without modifying its result, do not actually use stack space. Once all recursive function calls are tail calls, the code is equivalent to an imperative loop, as we will see.)
Think?
We could now just stare at the problem (rather the code), and try to come up with a solution directly. We d probably think ok, as I go through the tree, I have to remember all the nodes above me so I need a list of those nodes and for each of these nodes, I also need to remember whether I am currently processing the left child, and yet have to look at the right one, or whether I am done with the left child so what do I have to remember about the current node ?
ah, my brain spins already. Maybe eventually I figure it out, but why think when we can derive the solution? So let s start with above map1, and rewrite it, in several, mechanical, steps into a stack-less, tail-recursive solution.
Go!
Before we set out, let me rewrite the map function using a local go helper, as follows:
map2 :: forall a b. (a -> b) ->T a ->T b
map2 f t = go t
where go ::T a ->T b
go (L x) =L (f x)
go (B t1 t2) =B (go t1) (go t2)
This transformation (effectively the static argument transformation ) has the nice advantage that we do not have to pass f around all the time, and that when we copy the function, I only have to change the top-level name, but not the names of the inner functions.
Also, I find it more aesthetically pleasing.
CPS
A blunt, effective tool to turn code that is not yet using tail-calls into code that only uses tail-calls is use continuation-passing style. If we have a function of type -> t, we turn it into a function of type -> (t -> r) -> r, where r is the type of the result we want at the very end. This means the function now receives an extra argument, often named k for continuation, and instead of returning some x, the function calls k x.
We can apply this to our go function. Here, both t and r happen to be T b; the type of finished trees:
map3 :: forall a b. (a -> b) -> T a -> T b
map3 f t = go t (\r -> r)
where
go :: T a -> (T b -> T b) -> T b
go (L x) k = k (L (f x))
go (B t1 t2) k = go t1 (\r1 -> go t2 (\r2 -> k (B r1 r2)))
Note that when initially call go, we pass the identity function (\r -> r) as the initial continuation.
Alas, suddenly all function calls are in tail position, and this codes does not use stack space! Technically, we are done, although it is not quite satisfying; all these lambdas floating around obscure the meaning of the code, are maybe a bit slow to execute, and also, we didn t really learn much yet. This is certainly not the code we would have writing after thinking hard .
Defunctionalization
So let s continue rewriting the code to something prettier, simpler. Something that does not use lambdas like this.
Again, there is a mechanical technique that can help it. It likely won't make the code prettier, but it will get rid of the lambdas, so let s do that an clean up later.
The technique is called defunctionalization (because it replaces functional values by plain data values), and can be seen as a form of refinement.
Note that we pass around vales of type (T b -> T b), but we certainly don t mean the full type (T b -> T b). Instead, only very specific values of that type occur in our program, So let us replace (T b -> T b) with a data type that contains representatives of just the values we actually use.
We find at all values of type (T b -> T b). These are:
(\r -> r)
(\r1 -> go t2 (\r2 -> k (B r1 r2)))
(\r2 -> k (B r1 r2))
We create a datatype with one constructor for each of these:
dataK=IK1K2
(This is not complete yet.)
We introduce an interpretation function that turns a K back into a (T b -> T b):
eval ::K-> (T b ->T b)
eval = (*TBD*)
In the function go, instead of taking a parameter of type (T b -> T b), we take a K. And when we actually use the continuation, we have to turn the K back to the function using eval:
go ::T a ->K a b ->T b
go (L x) k = eval k (L (f x))
go (B t1 t2) k = go t1 K1
We also do this to the code fragments identified in the first step; these become:
(\r -> r)
(\r1 -> go t2 K2)
(\r2 -> eval k (B r1 r2))
Now we complete the eval function: For each constructor, we simply map it to the corresponding lambda from step 1:
eval ::K-> (T b ->T b)
eval I= (\r -> r)
eval K1= (\r1 -> go t2 K2)
eval K2= (\r2 -> eval k (B r1 r2))
This doesn t quite work yet: We have variables on the right hand side that are not bound (t2, r1, k). So let s add them to the constructors K1 and K2 as needed. This also changes the type K itself; it now needs to take type parameters.
This leads us to the following code:
dataK a b
=IK1 (T a) (K a b)
K2 (T b) (K a b)
map4 :: forall a b. (a -> b) ->T a ->T b
map4 f t = go t Iwhere go ::T a ->K a b ->T b
go (L x) k = eval k (L (f x))
go (B t1 t2) k = go t1 (K1 t2 k)
eval ::K a b -> (T b ->T b)
eval I= (\r -> r)
eval (K1 t2 k) = (\r1 -> go t2 (K2 r1 k))
eval (K2 r1 k) = (\r2 -> eval k (B r1 r2))
Not really cleaner or prettier, but everything is still tail-recursive, and we are now working with plain data.
We like lists
To clean it up a little bit, we can notice that the K data type really is just a list of values, where the values are either T a or T b. We do not need a custom data type for this! Instead of our K, we can just use the following, built from standard data types:
type K' a b = [Either (T a) (T b)]
Now I replace I with [], K1 t2 k with Left t2 : k and K2 r1 k with Right r1 : k. I also, very suggestively, rename go to down and eval to up:
map5 :: forall a b. (a -> b) ->T a ->T b
map5 f t = down t []
where down ::T a ->K' a b ->T b
down (L x) k = up k (L (f x))
down (B t1 t2) k = down t1 (Left t2 : k)
up ::K' a b ->T b ->T b
up [] r = r
up (Left t2 : k) r1 = down t2 (Right r1 : k)
up (Right r1 : k) r2 = up k (B r1 r2)
At this point, the code suddenly makes more sense again. In fact, I can try to verbalize it:
As we traverse the tree, we have to remember for all parent nodes, whether there is still something Left to do when we come back to it (so we remember a T a), or if we are done with that (so we have a T b). This is the list K' a b.
We begin to go down the left of the tree (noting that the right siblings are still left to do), until we hit a leaf. We transform the leaf, and then go up.
If we go up and hit the root, we are done. Else, if we go up and there is something Left to do, we remember the subtree that we just processed (as that is already in the Right form), and go down the other subtree. But if we go up and there is nothing Left to do, we put the two subtrees together and continue going up.
Quite neat!
The imperative loop
At this point we could stop: the code is pretty, makes sense, and has the properties we want. But let s turn the dial a bit further and try to make it an imperative loop.
We know that if we have a single tail-recursive function, then that s equivalent to a loop, with the function s parameter turning into mutable variables. But we have two functions!
It turns out that if you have two functions a -> r and b -> r that have the same return type (which they necessarily have here, since we CPS-converted them further up), then those two functions are equivalent to a single function taking a or b , i.e. Either a b -> r. This really nothing else than the high-school level algebra rule of rarb = ra + b.
So (after reordering the arguments of down to put T b first) we can rewrite the code as
map6 :: forall a b. (a -> b) ->T a ->T b
map6 f t = go (Left t) []
where go ::Either (T a) (T b) ->K' a b ->T b
go (Left (L x)) k = go (Right (L (f x))) k
go (Left (B t1 t2)) k = go (Left t1) (Left t2 : k)
go (Right r) [] = r
go (Right r1) (Left t2 : k) = go (Left t2) (Right r1 : k)
go (Right r2) (Right r1 : k) = go (Right (B r1 r2)) k
Do you see the loop yet? If not, maybe it helps to compare it with the following equivalent imperative looking pseudo-code:
mapLoop :: forall a b. (a -> b) -> T a -> T b
mapLoop f t
var node = Left t;
var parents = [];
while (true)
switch (node)
Left (L x) -> node := Right (L (f x))
Left (B t1 t2) -> node := Left t1; parents.push(Left t2)
Right r1 ->
if (parents.len() == 0)
return r1;
else
switch (parents.pop())
Left t2 -> node := Left t2; parents.push(Right r1);
Right r2 -> node := Right (B r1 r2)
Conclusion
I find it enlightening to see how apparently very different approaches to a problem (recursive, lazy functions and imperative loops) are connected by a series of rather mechanical transformations. When refactoring code, it is helpful to see if one can conceptualize the refactoring as one of those mechanical steps (refinement, type equivalences, defunctionalization, cps conversion etc.)
If you liked this post, you might enjoy my talk The many faces of isOrderedTree, which I have presented at MuniHac 2019 and Haskell Love 2020.
A long journey has come to nice finish. 9 month ago I switched to KDE/Plasma, and started to package newer versions of it than available in Debian. Since then I have packaged every single version of Plasma, the KDE frameworks, and KDE Apps and made them available for Debian/unstable and Debian/testing via the OBS build server.
Today, finally, I have uploaded Frameworks 5.77 and Plasma 5.20.4 to unstable, the end of a long story. Despite some initial disagreements with the Debian Qt/KDE Team, we found a modus vivendi, and since some months now I am member of the team and working together with the rest to get an uptodate KDE/Plasma system into Debian/bullseye. Thanks to everyone involved!
The last weeks we have also worked on updating many of the KDE/Apps packages to the latest release 20.12.0, which means that as of now, Debian/unstable contains the most recent versions of KDE Frameworks, KDE Plasma, and of most KDE Apps.
Thanks goes to all the team members, in particular to (in alphabetic order) Aur lien, Patrick, Pino, Sandro, and Scarlett for their work, and to all the testers and bug reporters.
The current status is also more or less what we plan to get into Debian/Bullseye. An update to Frameworks 5.78 and Plasma 5.20.5 is still possible, but not decided by now.
Concerning my OBS packages: they are mostly superseeded by now, and all but the KDE Apps package can be removed from the apt sources. The only remaining archive of interest is
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2012/Debian_Unstable/ ./
and the same with Testing instead of Unstable for Debian/testing.
For those adventurous, there is also the digikam-beta repository
That s it. Have a nice Christmas, if you celebrate it, and a good start into a hopefully better 2021!
Enjoy.
I recently took part in an interview with Vladimir Bejdo, an intern at the Software Freedom Conservancy, in order to talk about the Reproducible Builds project, my own participation in software freedom, the importance of reproducibility in software development and to have a brief discussion on the issues facing free software as a whole:
VB: To start off with, it might be useful to first ask you this how would you relate the importance of reproducibility to a user who is non-technical?
CL: I sometimes use the analogy of the food supply chain to quickly relate our work to non-technical audiences. The multiple stages of how our food reaches our plates today (such as seeding, harvesting, picking, transportation, packaging, etc.) can loosely translate to how software actually ends up on our computers, particularly in the way that if any of the steps in the multi-stage food supply chain has an issue then it quickly becomes a serious problem.
For example, even if we could guarantee that only the most wholesome apples were picked in our orchards, if they became tainted on the way to the supermarket it will be a real problem for us at the end of the day. We may not even be able to even tell by simply inspecting our Pink Ladies or Honeycrisps, and washing them thoroughly under the tap may not be enough either.
In an ideal world, we would be able to personally inspect the provenance of our food at all of the stages of manufacturing and transportation. But at some point, we must place our trust in the process and in brands, as well as various regulatory bodies to ensure that potential problems in our food are minimized, possibly even paying a time/effort premium by growing our own or buying direct from local markets in order to minimize the number of steps, etc.
However, when we use free software we can do better: Reproducible builds are a set of software development practices, ideas and tools that create an independently-verifiable path all the way from the original source code to what actually runs on our machines. Reproducible builds can reveal the injection of back-doors introduced by the hacking of developers own computers, build servers and package repositories, and also expose where volunteers or companies have been coerced into making changes via blackmail, court order, and so on.
With reproducible builds, there is no longer any need to trust any particular source of authority. In the same way that, say, a Mr Smith might check that his calculator is giving him the right answer to 2+2=4 by asking enough of his friends to check theirs too, users and developers of a reproducible build can verify the software they are using by creating a collective consensus instead.
The latest docker 20.10.x release unlocks the buildx subcommands
which allow for some sugar, like building something in a container
and dumping the result to your local directory in one command.
Dockerfile
FROM docker-registry.mycorp.com/debian-node:lts as builder
USER service
COPY . /opt/service
RUN cd /opt/service; npm install; npm run build
FROM scratch as dist
COPY --from=builder /opt/service/dist /
Here we build a page, copy the result with all assets from the /opt/service/dist
directory to an empty image and dump it into the local pages directory.
Hail is a gunrunner, an outlaw and criminal, someone who knows how to
survive violence and navigate by personal loyalty. That world knows her
as Cressen Stone. What her colleagues don't know is that she's also an
Imperial Princess. Hailimi Mercedes Jaya Bristol left that world twenty
years earlier in secret pursuit of her father's killer and had no
intention of returning. But her sisters are dead, her mother's health is
failing, and two Imperial Trackers have been sent to bring her back to her
rightful position as heir.
I'm going to warn up-front that the first half of this novel was rough to
the point of being unreadable. Wagers tries much too hard to establish
Hail as a reluctant heroine torn between her dislike of royal protocols
and her grief and anger at the death of her sisters. The result is
excessively melodramatic and, to be frank, badly written. There are a lot
of passages like this:
His words slammed into me, burning like the ten thousand volts of a
Solarian Conglomerate police Taser.
(no, there's no significance to the Solarian Conglomerate here), or, just
three paragraphs later:
The air rushed out of my lungs. Added grief for a niece I'd never
known. One more log on the pyre set to burn my freedom to ashes. The
hope I'd had of getting out of this mess was lost in that instant, and
I couldn't do anything but stare at Emmory in abject shock.
Given how much air rushes out of Hail's lungs and how often she's struck
down with guilt or grief, it's hard to believe she doesn't have brain
damage.
Worse, Hail spends a great deal of the first third of the book whining,
which given that the book is written in first person gets old very
quickly. Every emotion is overwritten and overstressed as Hail rails
against obvious narrative inescapability. It's blatantly telegraphed from
the first few pages that Hail is going to drop into the imperial palace
like a profane invasion force and shake everything up, but the reader has
to endure far too long of Hail being dramatically self-pitying about the
plot. I almost gave up on this book in irritation (and probably should
have).
And then it sort of grew on me, because the other thing Wagers is doing
(also not subtly) is a story trope for which I have a particular
weakness: The fish out of water who nonetheless turns out to be the person
everyone needs because she's systematically and deliberately kind and
thoughtful while not taking any shit. Hail left Pashati young and
inexperienced, with a strained relationship with her mother and a habit of
letting her temper interfere with her ability to negotiate palace
politics. She still has the temper, but age, experience, and confidence
mean that she's decisive and confident in a way she never was before. The
second half of this book is about Hail building her power base and winning
loyalty by being loyal and decent. It's still not great writing, but
there's something there I enjoyed reading.
Wagers's setting is intriguing, although it makes me a bit nervous. The
Indranan Empire was settled by colonists of primarily Indian background.
The court trappings, mythology, and gods referenced in Behind the
Throne are Hindu-derived, and I suspect (although didn't confirm) that
the funeral arrangements are as well. Formal wear (and casual wear) for
women is a sari. There's a direct reference to the goddess Lakshimi (not
Lakshmi, which Wikipedia seems to indicate is the correct spelling,
although transliteration is always an adventure).
I was happy to see this, since there are more than enough SF novels out
there that seem to assume only western countries go into space. But I'm
never sure whether the author did enough research or has enough personal
knowledge to pull off the references correctly, and I personally wouldn't
know the difference.
The Indranan Empire is also matriarchal, and here Wagers goes for an
inversion of sexism that puts men in roughly the position women were in
the 1970s. They can, in theory, do most jobs, but there are many things
they're expected not to do, there are some explicit gender lines in power
structures, and the role of men in society is a point of political
conflict. It's skillfully injected as social background, with a
believable pattern of societal prejudice that doesn't necessarily apply to
specific men in specific situations. I liked that Wagers did this without
giving the Empire itself any feminine-coded characteristics. All admirals
are women because the characters believe women are obviously better
military leaders, not because of some claptrap about nurturing or caring
or some other female-coded reason from our society.
That said, this gender role inversion didn't feel that significant to the
story. The obvious "sexism is bad, see what it would be like if men were
subject to it" message ran parallel to the main plot and never felt that
insightful to me. I'm therefore not sure it was successful or worth the
injection of sexism into the reading experience, although it certainly is
different from the normal fare of space empires.
I can't recommend Behind the Throne because a lot of it just isn't
very good. But I still kind of want to because I sincerely enjoyed the
last third of the book, despite some lingering melodrama. Watching Hail
succeed by being a decent, trustworthy, loyal, and intelligent person is
satisfying, once she finally stops whining. The destination is probably
not worth the journey, but now that I've finished the first book, I'm
tempted to grab the second.
Followed by After the Crown.
Rating: 6 out of 10
After writing my post about VDPAU in Debian [1] I received two great comments from anonymous people. One pointed out that I should be using VA-API (also known as VAAPI) on my Intel based Thinkpad and gave a reference to an Arch Linux Wiki page, as usual Arch Linux Wiki is awesome and I learnt a lot of great stuff there. I also found the Debian Wiki page on Hardware Video Acceleration [2] which has some good information (unfortunately I had already found all that out through more difficult methods first, I should read the Debian Wiki more often.
It seems that mplayer doesn t suppoer VAAPI. The other comment suggested that I try the mpv fork of Mplayer which does support VAAPI but that feature is disabled by default in Debian.
I did a number of tests on playing different videos on my laptop running Debian/Buster with Intel video and my workstation running Debian/Unstable with ATI video. The first thing I noticed is that mpv was unable to use VAAPI on my laptop and that VDPAU won t decode VP9 videos on my workstation and most 4K videos from YouTube seem to be VP9. So in most cases hardware decoding isn t going to help me.
The Wikipedia page about Unified Video Decoder [3] shows that only VCN (Video Core Next) supports VP9 decoding while my R7-260x video card [4] has version 4.2 of the Unified Video Decoder which doesn t support VP9, H.265, or JPEG. Basically I need a new high-end video card to get VP9 decoding and that s not something I m interested in buying now (I only recently bought this video card to do 4K at 60Hz).
The next thing I noticed is that for my combination of hardware and software at least mpv tends to take about 2/3 the CPU time to play videos that mplayer does on every video I tested. So it seems that using mpv will save me 1/3 of the power and heat from playing videos on my laptop and save me 1/3 of the CPU power on my workstation in the worst case while sometimes saving me significantly more than that.
Conclusion>
To summarise quite a bit of time experimenting with video playing and testing things: I shouldn t think too much about hardware decoding until VP9 hardware is available (years for me). But mpv provides some real benefits right now on the same hardware, I m not sure why.
Another note to myself before I forget about this nifty usage
of socat again.
I was looking for something to mock a serial device, similar to
a microcontroller which usually ends up as /dev/ttyACM0 and might
output some text. What I found is a very helpful post on
stackoverflow
showing an example utilizing socat.
$ socat -d -d pty,rawer pty,rawer
2020/12/20 21:37:53 socat[29130] N PTY is /dev/pts/8
2020/12/20 21:37:53 socat[29130] N PTY is /dev/pts/11
2020/12/20 21:37:53 socat[29130] N starting data transfer loop with FDs [5,5] and [7,7]
Write whatever you need to the second pty, here /dev/pts/11, e.g.
$ i=0; while :; do echo "foo: $ i " > /dev/pts/11; let i++; sleep 5; done
Now you can listen with whatever you like, e.g. some tool you work on, on the fist pty,
here /dev/pts/8. For demonstration purpose just use cat:
$ cat /dev/pts/8
foo: 0
foo: 1
socat is an awesome tool, looking through the manpage you need some knowledge about
sockets, but it's incredibly vesatile.
The people who are pro-Government and in this case pro-Corporate do not have any success stories that they can share. Hence, most of the time the arguments are that the other are bad. For e.g. quite a few people argue that we don t need farmers, we can just order from restaurant. They have completely disassociated the idea that even then you need farmers as unless the farmers put the seed in, till the soil and wait for the rains or have irrigation you won t get ripe vegetables which then has to be taken out, and somehow sold to the wholesaler from where it comes to the restaurant and then to your plate. Sadly, even the farm-to-fork infographics are so depressingly sad, you want to look away. If you see the infographic you see it is just not non-veg but also vegetarian food grains which go under lot of questionable practices. Even, with such scenarios that is done by corporations our people want to go ahead. I will share stories from other countries which tell how they are doing more.
The Soldier-Farmer
Another sad part of these protests have been soldiers who have been returning their medals. The ones who oppose have the gall to say they should return the cash rewards they got. So just like farmers, seems soldiers also do not need money to survive. They are supposed to live only on air and water. This is after the present Govt. has reduced their pensions after retirement and that too without any discussion
GOI pensions to ex-servicemen
Now I nor anybody else would have minded if these conditions were shared going forward rather than doing it retrospectively. People who usually go to the army are not in it for money but for the adventure and glory they bring. But they do also have a family and have a family responsibility. In most other countries, the soldier and his families are well-looked after. If you know that even after you die, the Government would look after your family, you will do your best. Unfortunately, many veterans in India themselves are asked to help by many war widows as the widows don t get family pensions. The proposal naturally has left many miffed. In fact many of the veterans who used to advise people to join the armed forces now advise young people to pursue civilian life and careers. This is when Indian Army has been ironically having shortage of officers from well over a decade and stresses felt by Army personnel also known for a long time.
Even under this nationalistic Government, if it cannot take care of its soldiers, then forget about others.
India Defence Spending vis-a-vis other countries.
Now it is nobody s argument that India needs to improve its tooth-to-tail ratio but this is the wrong way to go about it. I would probably talk about that some other time as that totally needs its whole place.
Even OROP, which was the mandate of this Government hasn t had been done in full as there are quite a few cases in the Supreme Court. Almost all the cases have been heard and only decisions have to be given which the SC for whatever reason doesn t want to give. They just keep changing the date of the hearing. Nowadays, in many suits/cases, the SC asks for fresh hearings even though all the old records are there. This is a newish phenomena which is being observed in SC. Why is it being done? Your guess is as good as mine. One thing for sure has changed, the SC which used to be citizen-focussed or enabler of human rights and used to be held as a beacon for judicial activism has changed but these are other topics which need their own space.
Update 16/12/2020 The SC recommends setting up a committee to discuss farmer issues. And this is nothing new. This is called death by committee. When there is already so much literature on the subject, including the works done by Swaminathan Commission. There has been 6 reports which do look at farmer issues in a holistic manner. This is the Supreme Court giving an escape route to GOI. They also have abstained from having a whole session citing Covid. This is when the ruling Govt. is putting a massive 1000 crore on a new building on which the SC has put on hold. And even then the GOI went ahead and did a Bhoomi-Pujan (traditional ceremony when making a new construction from scratch.)
Naturally due to the double whammy of both the pension reforms and now the laws to make corporate farming more aggressive has left a deep impact on the soldier-farmer that the state does not think or feel for him.
Even the United States farm-aid eloquently describes how corporate farming has made independent farmers suffer. You read that, and it seems it is as the state of our farmers here in India. Even their average land-holding has dropped a bit. I have shared about the state of farmers in India, in twoblog posts previously. And it is not just farm owners who have had it bad, even farm workers in U.S. The issue may look to be about the pandemic but goes far deeper.
The Israeli Model
The Israelis have always used collective farming and do have a large share in farming there. The old model called Kibbutz is what made Israelis self-sufficient in food and water and actually are world-leaders where they export their services to other nations on the same thing.
France
Just like many other countries, France also seems to have favored farmer co-operatives. Almost 75% of all farmers are in co-operatives.
Italy
The country world-famous for its wines and cheese are made by its co-operatives. In fact co-ops are the buzzword it seems in Italy, more so in Northern Italy.
Asian economies
Even Asian economies, especially East Asian economies by and large have been turning to co-operatives.
Brazil
Now Brazil is almost 40% more than India. In fact, in most of the indices, Brazil beats India handsomely. So one would be forgiven to think that Brazil must have corporate farming. But nothing could be further from the truth. The only downer is that they have high crime in some areas. Otherwise, they are in many ways better than India. In fact, I was surprised a few years ago to learn about Mercsour. I would have to admit though I learned much about Brazil when Debian was holding a debconf about a year back. Otherwise, I had known about the country for number of years but apart from its carnival and samba, hadn t known much about it. I did come to know that most of Latin America also loves spices as much as Indians do. They show that love by using hot sauces. I do one day wanna try one of their sauces to see what makes it tick. I do know they like to barbecuevegetables as much as barbecuing non-veg food. This is going a bit OT but then that s the foodie in me Conclusion
I could have shared more countries which have chosen the co-operative way rather than corporate farming and that is simply because they know what is best for their people and what is best even politically. The new farm laws are neither grounded in farmer s welfare nor anything else. The Govt. has been trying to undermine the farmers for years together. In fact, Madhya Pradesh has openly said that they will not allow farmers from other states to sell in their state. Although, even before these laws there was nothing to restrict the farmer from selling his produce anywhere in the country. Angering the farmers is not good politics as was found sometime back but guessing some lessons need to be re-learned.
One comment though, on social media I have seen many people especially youngsters having no real understanding of what inflation is all about. For e.g. if you ask them how come we are having a sort of record inflation in a technical recession (there has been a contraction, actually) and you see them putting themselves into bigger and bigger ditches. This does explain in part why the BJP wins in elections. If you do more rhetoric, which BJP is good as, rather than educating people than you are bound to win. You don t need plans, you don t need a vision, just rhetoric will do. What more evidence is needed when the economy is and was in a worse shape even before the pandemic and BJP won. I would probably write about that as that again needs lot of background and understanding as well as related terms.
The Hetzner server that hosts my blog among other things has 2*256G SSDs for the root filesystem. The smartctl and smartd programs report both SSDs as in FAILING_NOW state for the Wear_Leveling_Count attribute. I don t have a lot of faith in SMART. I run it because it would be stupid not to consider data about possible drive problems, but don t feel obliged to immediately replace disks with SMART errors when not convenient (if I ordered a new server and got those results I would demand replacement before going live).
Doing any sort of SMART scan will cause service outage. Replacing devices means 2 outages, 1 for each device.
I noticed the SMART errors 2 weeks ago, so I guess that the SMART claims that both of the drives are likely to fail within 24 hours have been disproved. The system is running BTRFS so I know there aren t any unseen data corruption issues and it uses BTRFS RAID-1 so if one disk has an unreadable sector that won t cause data loss.
Currently Hetzner Server Bidding has ridiculous offerings for systems with SSD storage. Search for a server with 16G of RAM and SSD storage and the minimum prices are only 2E cheaper than a new server with 64G of RAM and 2*512G NVMe. In the past Server Bidding has had servers with specs not much smaller than the newest systems going for rates well below the costs of the newer systems. The current Hetzner server is under a contract from Server Bidding which is significantly cheaper than the current Server Bidding offerings, so financially it wouldn t be a good plan to replace the server now.
Monitoring
I have just released a new version of etbe-mon [1] which has a new monitor for SMART data (smartctl). It also has a change to the sslcert check to search all IPv6 and IPv4 addresses for each hostname, makes freespace check look for filesystem mountpoint, and makes the smtpswaks check use latest swaks command-line.
For the new smartctl check there is an option to treat Marginal alert status from smartctl as errors and there is an option to name attributes that will be treated as marginal even if smartctl thinks they are significant. So now I have my monitoring system checking the SMART data on the servers of mine which have real hard drives (not VMs) and aren t using RAID hardware that obscures such things. Also it s not alerting me about the Wear_Leveling_Count on that particular Hetzner server.
Like many other people, I first became aware of Anne Helen Petersen's
journalism when her Buzzfeed article
"How Millennials Became the Burnout Generation" went viral. Can't
Even is the much-awaited (at least by me) book-length expansion of that
thesis: The United States is, as a society, burning out, and that burnout
is falling on millennials the hardest. We're not recognizing the symptoms
because we think burnout looks like something dramatic and flashy. But
for most people burnout looks less like a nervous breakdown and more like
constant background anxiety and lack of energy.
Laura, who lives in Chicago and works as a special ed teacher, never
wants to see her friends, or date, or cook she's so tired, she just
wants to melt into the couch. "But then I can't focus on what I'm
watching, and end up unfocused again, and not completely relaxing,"
she explained. "Here I am telling you I don't even relax right! I
feel bad about feeling bad! But by the time I have leisure time, I
just want to be alone!"
Petersen explores this idea across childhood, education, work, family, and
parenting, but the core of her thesis is the precise opposite of the
pervasive myth that millennials are entitled and lazy (a persistent
generational critique that Petersen points out was also leveled at their
Baby Boomer parents in the 1960s and 1970s). Millennials aren't slackers;
they're workaholics from childhood, for whom everything has become a
hustle and a second (or third or fourth) job. The struggle with
"adulting" is a symptom of the burnout on the other side of exhaustion,
the mental failures that happen when you've forced yourself to keep going
on empty so many times that it's left lingering damage.
Petersen is a synthesizing writer who draws together the threads of other
books rather than going deep on a novel concept, so if you've been reading
about work, psychology, stress, and productivity, many of the ideas here
will be familiar. But she's been reading the same authors that I've been
reading (Tressie McMillan Cottom,
Emily Guendelsberger, Brigid Schulte, and even Cal Newport), and
this was the book that helped me pull those analyses together into a
coherent picture.
That picture starts with the shift of risk in the 1970s and 1980s from
previously stable corporations with long-lasting jobs and retirement
pensions onto individual employees. The corresponding rise in precarity
and therefore fear led to a concerted effort to re-establish a feeling of
control. Baby Boomers doubled down on personal responsibility and
personal capability, replacing unstructured childhood for their kids with
planned activities and academic achievement. That generation, in turn,
internalized the need for constant improvement, constant grading, and
constant achievement, accepting an implied bargain that if they worked
very hard, got good grades, got into good schools, and got a good degree,
it would pay off in a good life and financial security.
They were betrayed. The payoff never happened; many millennials graduated
into the Great Recession and the worst economy since World War II. In
response, millennials doubled down on the only path to success they were
taught. They took on more debt, got more education, moved back in with
their parents to cut expenses, and tried even harder.
Even after watching our parents get shut out, fall from, or simply
struggle anxiously to maintain the American Dream, we didn't reject
it. We tried to work harder, and better, more efficiently, with more
credentials, to achieve it.
Once one has this framework in mind, it's startling how pervasive the
"just try harder" message is and how deeply we've internalized it. It is
at the center of the time management literature: Getting Things Done focuses almost entirely on individual
efficiency. Later time management work has become more aware of the
importance of pruning the to-do list and doing fewer things, but addresses
that through techniques for individual prioritization.
Cal Newport is more aware than most that
constant busyness and multitasking interacts poorly with the human brain,
and has taken a few tentative steps towards treating the problem as
systemic rather than individual, but his focus is still primarily on
individual choices. Even when tackling a problem that is clearly
societal, such as the monetization of fear and outrage on social media,
the solutions are all individual: recognize that those platforms are bad
for you, make an individual determination that your attention is being
exploited, and quit social media through your personal force of will.
And this isn't just productivity systems. Most of public discussion of
environmentalism in the United States is about personal energy
consumption, your individual carbon footprint, household recycling, and
whether you personally should eat meat. Discussions of monopoly and
monopsony become debates over whether you personally should buy from
Amazon. Concerns about personal privacy turn into advocacy for using an
ad blocker or shaming people for using Google products. Articles about
the growth of right-wing extremism become exhortations to take
responsibility for the right-wing extremist in your life and argue them
out of their beliefs over the dinner table. Every major systemic issue
facing society becomes yet another personal obligation, another place we
are failing as individuals, something else that requires trying harder,
learning more, caring more, doing more.
This advice is well-meaning (mostly; sometimes it is an intentional and
cynical diversion), and can even be effective with specific problems. But
it's also a trap. If you're feeling miserable, you just haven't found the
right combination of time-block scheduling, kanban, and bullet journaling
yet. If you're upset at corporate greed and the destruction of the
environment, the change starts with you and your household. The solution
is in your personal hands; you just have try a little harder, work a
little harder, make better decisions, and spend money more ethically
(generally by buying more expensive products). And therefore, when we're
already burned out, every topic becomes another failure, increasing our
already excessive guilt and anxiety.
Believing that we're in control, even when we're not, does have
psychological value. That's part of what makes it such a beguiling trap.
While drafting this review, I listened to Ezra Klein's interview with
Robert Sapolsky on poverty and stress, and one of the points he made is
that, when mildly or moderately bad things happen, believing you have
control is empowering. It lets you recast the setback as a larger
disaster that you were able to prevent and avoid a sense of futility. But
when something major goes wrong, believing you have control is actively
harmful to your mental health. The tragedy is now also a personal
failure, leading to guilt and internal recrimination on top of the effects
of the tragedy itself. This is why often the most comforting thing we can
say to someone else after a personal disaster is "there's nothing you
could have done."
Believing we can improve our lives if we just try a little harder does
work, until it doesn't. And because it does work for smaller things, it's
hard to abandon; in the short term, believing we're at the mercy of forces
outside our control feels even worse. So we double down on
self-improvement, giving ourselves even more things to attempt to do and
thus burning out even more.
Petersen is having none of this, and her anger is both satisfying and
clarifying.
In writing that article, and this book, I haven't cured anyone's
burnout, including my own. But one thing did become incredibly clear.
This isn't a personal problem. It's a societal one and it will not
be cured by productivity apps, or a bullet journal, or face mask skin
treatments, or overnight fucking oats. We gravitate toward those
personal cures because they seem tenable, and promise that our lives
can be recentered, and regrounded, with just a bit more discipline, a
new app, a better email organization strategy, or a new approach to
meal planning. But these are all merely Band-Aids on an open wound.
They might temporarily stop the bleeding, but when they fall off, and
we fail at our new-found discipline, we just feel worse.
Structurally, Can't Even is half summaries of other books and
essays put into this overall structure and half short profiles and quotes
from millennials that illustrate her point. This is Petersen's typical
journalistic style if you're familiar with her other work. It gains a lot
from the voices of individuals, but it can also feel like argument from
anecdote. If there's a epistemic flaw in this book, it's that Petersen
defends her arguments more with examples than with scientific study. I've
read enough of the other books she cites, many of which do go into the
underlying studies and statistics, to know that her argument is
well-grounded, but I think Can't Even works better as a roadmap and
synthesis than as a primary source of convincing data.
The other flaw that I'll mention is that although Petersen tries very hard
to incorporate poorer and non-white millennials, I don't think the effort
was successful, and I'm not sure it was possible within the structure
of this book. She frequently makes a statement that's accurate and
insightful for millennials from white, middle-class families, acknowledges
that it doesn't entirely apply to, for example, racial minorities, and
then moves on without truly reconciling those two perspectives. I think
this is a deep structural problem: One's experience of American life
is very different depending on race and class, and the phenomenon that
Petersen is speaking to is to an extent specific to those social classes
who had a more comfortable and relaxing life and are losing it.
One way to see the story of the modern economy is that white people are
becoming as precarious as everyone else already was, and are reacting by
making the lives of non-white people yet more miserable. Petersen is
accurately pointing to significant changes in relationships with
employers, productivity, family, and the ideology of individualism, but
experiencing that as a change is more applicable to white people than
non-white people. That means there are, in a way, two books here: one
about the slow collapse of the white middle class into constant burnout,
and a different book about the much longer-standing burnout of being
non-white in the United States and our systemic failure to address the
causes of it. Petersen tries to gesture at the second book, but she's not
the person to write it and those two books cannot comfortably live between
the same covers. The gestures therefore feel awkward and forced, and
while the discomfort itself serves some purpose, it lacks the insight that
Petersen brings to the rest of the book.
Those critiques aside, I found Can't Even immensely clarifying.
It's the first book that explained to me in a way I understood what's so
demoralizing and harmful about Instagram and its allure of cosplaying as a
successful person. It helped me understand how productivity and
individual political choices fit into a system that emphasizes individual
action as an excuse to not address collective problems. And it also gave
me a strange form of hope, because if something can't go on forever, it
will, at some point, stop.
Millennials have been denigrated and mischaracterized, blamed for
struggling in situations that set us up to fail. But if we have the
endurance and aptitude and wherewithal to work ourselves this deeply
into the ground, we also have the strength to fight. We have little
savings and less stability. Our anger is barely contained. We're a
pile of ashes smoldering, a bad memory of our best selves.
Underestimate us at your peril: We have so little left to lose.
Nothing will change without individual people making different decisions
and taking different actions than they are today. But we have gone much
too far down the path of individual, atomized actions that may produce
feelings of personal virtue but that are a path to ineffectiveness and
burnout when faced with systemic problems. We need to make different
choices, yes, but choices towards solidarity and movement politics rather
than personal optimization.
There is a backlash coming. If we let it ground itself in personal
grievance, it could turn ugly and take a racist and nationalist direction.
But that's not, by in large, what millennials have done, and that makes me
optimistic. If we embrace the energy of that backlash and help shape it
to be more inclusive, just, and fair, we can rediscover the effectiveness
of collective solutions for collective problems.
Rating: 8 out of 10
VDPAU is the Video Decode and Presentation API for Unix [1]. I noticed an error with mplayer Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object file: No such file or directory , Googling that turned up Debian Bug #869815 [2] which suggested installing the packages vdpau-va-driver and libvdpau-va-gl1 and setting the environment variable VDPAU_DRIVER=va_gl to enable VPDAU.
The command vdpauinfo from the vdpauinfo shows the VPDAU capabilities, which showed that VPDAU was working with va_gl.
When mplayer was getting the error about a missing i915 driver it took 35.822s of user time and 1.929s of system time to play Self Control by Laura Branigan [3] (a good music video to watch several times while testing IMHO) on my Thinkpad Carbon X1 Gen1 with Intel video and a i7-3667U CPU. When I set VDPAU_DRIVER=va_gl mplayer took 50.875s of user time and 4.207s of system time but didn t have the error.
It s possible that other applications on my Thinkpad might benefit from VPDAU with the va_gl driver, but it seems unlikely that any will benefit to such a degree that it makes up for mplayer taking more time. It s also possible that the Self Control video I tested with was a worst case scenario, but even so taking almost 50% more CPU time made it unlikely that other videos would get a benefit.
For this sort of video (640 480 resolution) it s not a problem, 38 seconds of CPU time to play a 5 minute video isn t a real problem (although it would be nice to use less battery). For a 1600*900 resolution video (the resolution of the laptop screen) it took 131 seconds of user time to play a 433 second video. That s still not going to be a problem when playing on mains power but will suck a bit when on battery. Most Thinkpads have Intel video and some have NVidia as well (which has issues from having 2 video cards and from having poor Linux driver support). So it seems that the only option for battery efficient video playing on the go right now is to use a tablet.
On the upside, screen resolution is not increasing at a comparable rate to Moore s law so eventually CPUs will get powerful enough to do all this without using much electricity.
Like each month, here comes a report about the work of paid contributors to Debian LTS.
Individual reports
In November, 239.25 work hours have been dispatched among 13 paid contributors. Their reports are available:
Evolution of the situation
In November we held the last
LTS team meeting for 2020 on IRC, with the next one coming up at the end of January.
We announced a new formalized initiative for
Funding Debian projects with money from Freexian s LTS service.
Finally, we would like to remark once again that we are constantly looking
for new contributors. Please contact Holger
if you are interested!
We re also glad to welcome two new sponsors, Moxa, a device manufacturer, and a French research lab (Institut des Sciences Cognitives Marc Jeannerod).
The security tracker currently lists 37 packages with a known CVE and the dla-needed.txt file has 40 packages needing an update.
Thanks to our sponsors
Sponsors that joined recently are in bold.
For a while I ve had a problem with my Thinkpad X1 Carbon Gen 1 [1] where storage pauses for 30 seconds, it s become more common recently and unfortunately everything seems to depend on storage (ideally a web browser playing a video from the Internet could keep doing so with no disk access, but that s not what happens).
echo 3 > /sys/block/sda/device/timeout
I ve put the above in /etc/rc.local which should make it only take 3 seconds to recover from storage problems instead of 30 seconds, the problem hasn t recurred since that change so I don t know if it works as desired. The Thinkpad is running BTRFS and no data is reported as being lost, so it s not a problem to use it at this time.
The bottom of this post has an example of the errors I m getting. A friend said that his searches for such errors shows people claiming that it s a SATA controller or cable problem, which for a SATA device bolted directly to the motherboard means it s likely to be a motherboard problem (IE more expensive to fix than the $289 I paid for the laptop almost 3 years ago).
A Lenovo forum discussion says that the X1 Carbon Gen1 uses an unusual connector that s not M.2 SATA and not mSATA [2]. This means that a replacement is going to be expensive, $100US for a replacement from eBay when a M.2 SATA or NVMe device would cost about $50AU from my local store. It also means that I can t use a replacement for anything else. If my laptop took a regular NVMe I d buy one and test it out, if it didn t solve the problem a spare NVMe device is always handy to have. But I m not interested in spending $100US for a part that may turn out to be useless.
I bought the laptop expecting that there was nothing I could fix inside it. While it is theoretically possible to upgrade the CPU etc in a laptop most people find that the effort and expense makes it better to just replace the entire laptop. With the ultra light category of laptops the RAM is soldered on the motherboard and there are even less options for replacing things. So while it s annoying that Lenovo didn t use a standard interface for this device (they did so for other models in the range) it s not a situation that I hadn t expected.
Now the question is what to do next. The Thinkpad has a SD socket and micro SD cards are getting large capacities nowadays. If it won t boot from a SD card I could boot from USB and then run from SD. So even if the internal SATA device fails entirely it should still be useful. I wonder if I could find a Thinkpad with a similar problem going cheap as I m pretty sure that a Windows user couldn t make any storage device usable the way I can with Linux.
I ve looked at prices on auction sites but haven t seen a Thinkpad X1 Carbon going for anywhere near the price I got this one. The nearest I ve seen is around $350 for a laptop with significant damage.
While I am a little unhappy at Lenovo s choice of interface, I ve definitely got a lot more than $289 of value out of this laptop. So I m not really complaining.
A new release 0.3.3.9.1 of RcppEigen arrived on CRAN today (and just went to Debian too) bringing support for Eigen 3.3.9 to R. Eigen is a C++ template library for linear algebra: matrices, vectors, numerical solvers, and related algorithms.
The release started with a gentle nudge from the Stan team to package Eigen 3.3.8. And once I got around to it and sat down, Eigen 3.3.9 had just been released the previous day. The freshly prepared release 0.3.3.9.0 was then announced on Twitter (and the rcpp-devel mailing list) along with a request for testing alongside the usual extended reverse dependency checking we do (just like CRAN asks us to). And it turns out that Eigen 3.3.9 required an update to StanHeaders, a CRAN package that is itself quite widely used. This took a couple of days and its round of testing, but Ben Goodrich shipped it to CRAN last night, so we were able to ship RcppEigen in turn today.
So this release once again bring few required changes to Eigen (see this directory for details). As we said for the previous three releases:
One additional and recent change was the accomodation of a recent CRAN Policy change to not allow gcc or clang to mess with diagnostic messages. A word of caution: this may make your compilation of packages using RcppEigen very noisy so consider adding -Wno-ignored-attributes to the compiler flags added in your ~/.R/Makevars.
I actually find this requirement rather annoying. Eigen is then only usable if you set, say,
as g++ options in ~/.R/Makevars. But CRAN makes the rules. Maybe if a few of us gently and politely nudge them they may relent one day. One can only hope.
The complete NEWS file entry follows.
Changes in RcppEigen version 0.3.3.9.1 (2020-12-17)
Today, the Debian website displays a new homepage.
Since the most recent web team sprint
in March 2019, we have been working on renewing the structure, content, layout
and scripts that build the site.
There has been work mainly in two areas: removing or updating obsolete content,
and creating a new homepage which is more attractive to newcomers,
and which also highlights the social aspect of the Debian project
in addition to the operating system we develop.
Although this took longer than we would have liked,
and we don't consider this new homepage final,
we think it's a good first step towards a much better web site.
The web team will continue to work on restructuring the Debian website.
We would like to appeal to the community for help, and are also considering
external assistance, since we're a small group, whose members are also involved
in other Debian teams. Some of the next steps we expect to walk are
improve the CSS, icons, and layout in general, and review of the content,
to have a better structure.
If you would like to help, contact us. You can reply to the version of this
article (with some more details)
published in our public mailing list
or chat with us in the #debian-www IRC channel (at irc.debian.org).
As 
Fifteen years have passed since I started my career in IT which is quite some time. I've been playing with computers for 25 years now, which makes me quite knowledgeable about the field, for sure.However, while I was fully prepared to bargain with computers, I was not prepared to do so with humans. The whole career management thing was unknown to me. I had no useful skills to navigate within the enterprise organization. I had to learn the ropes the hard way, failing along the way. It hurt.Almost ten years ago, I had the chance to meet a new colleague Alexis Monville. Alexis was a team facilitator, and I started to work with him on many non-technical levels. He taught me a lot about agility and team organization. Working on this set of new skills changed how I envisioned my work and how I fit into the company.
Alexis Monville
The book!
TL;DR: CPS-conversion and defunctionalization can help you to come up with a constant-stack algorithm.
Update: Turns out I inadvertedly plagiarized the talk 
A long journey has come to nice finish. 
The last weeks we have also worked on updating many of the KDE/Apps packages to the latest release 20.12.0, which means that as of now, Debian/unstable contains the most recent versions of KDE Frameworks, KDE Plasma, and of most KDE Apps.
Thanks goes to all the team members, in particular to (in alphabetic order) Aur lien, Patrick, Pino, Sandro, and Scarlett for their work, and to all the testers and bug reporters.
The current status is also more or less what we plan to get into Debian/Bullseye. An update to Frameworks 5.78 and Plasma 5.20.5 is still possible, but not decided by now.
Concerning my OBS packages: they are mostly superseeded by now, and all but the KDE Apps package can be removed from the apt sources. The only remaining archive of interest is
I recently took part in an interview with Vladimir Bejdo, an intern at the 
The people who are pro-Government and in this case pro-Corporate do not have any success stories that they can share. Hence, most of the time the arguments are that the other are bad. For e.g. quite a few people argue that we don t need farmers, we can just order from restaurant. They have completely disassociated the idea that even then you need farmers as unless the farmers put the seed in, till the soil and wait for the rains or have irrigation you won t get ripe vegetables which then has to be taken out, and somehow sold to the wholesaler from where it comes to the restaurant and then to your plate. Sadly, even the farm-to-fork infographics are so depressingly 
Like 
A new release 0.3.3.9.1 of 
Today, the 