A good backup strategy needs to consider various threats to the integrity of data. For instance:
Building catches fire
Accidental deletion
Equipment failure
Security incident / malware / compromise
It s that last one that is of particular interest today. A lot of backup strategies are such that if a user (or administrator) has their local account or network compromised, their backups could very well be destroyed as well. For instance, do you ssh from the account being backed up to the system holding the backups? Or rsync using a keypair stored on it? Or access S3 buckets, etc? It is trivially easy in many of these schemes to totally ruin cloud-based backups, or even some other schemes. rsync can be run with delete (and often is, to prune remotes), S3 buckets can be deleted, etc. And even if you try to lock down an over-network backup to be append-only, still there are vectors for attack (ssh credentials, OpenSSL bugs, etc). In this post, I try to explore how we can protect against them and still retain some modern conveniences.
A backup scheme also needs to make a balance between:
Cost
Security
Accessibility
Efficiency (of time, bandwidth, storage, etc)
My story so far
About 20 years ago, I had an Exabyte tape drive, with the amazing capacity of 7GB per tape! Eventually as disk prices fell, I had external disks plugged in to a server, and would periodically rotate them offsite. I ve also had various combinations of partial or complete offsite copies over the Internet as well. I have around 6TB of data to back up (after compression), a figure that is growing somewhat rapidly as I digitize some old family recordings and videos.
Since I last wrote about backups 5 years ago, my scheme has been largely unchanged; at present I use ZFS for local and to-disk backups and borg for the copies over the Internet.
Let s take a look at some options that could make this better.
Tape
The original airgapped backup. You back up to a tape, then you take the (fairly cheap) tape out of the drive and put in another one. In cost per GB, tape is probably the cheapest medium out there. But of course it has its drawbacks.
Let s start with cost. To get a drive that can handle capacities of what I d be needing, at least LTO-6 (2.5TB per tape) would be needed, if not LTO-7 (6TB). New, these drives cost several thousand dollars, plus they need LVD SCSI or Fibre Channel cards. You re not going to be hanging one off a Raspberry Pi; these things need a real server with enterprise-style connectivity. If you re particularly lucky, you might find an LTO-6 drive for as low as $500 on eBay. Then there are tapes. A 10-pack of LTO-6 tapes runs more than $200, and provides a total capacity of 25TB sufficient for these needs (note that, of course, you need to have at least double the actual space of the data, to account for multiple full backups in a set). A 5-pack of LTO-7 tapes is a little more expensive, while providing more storage.
So all-in, this is going to be in the best possible scenario nearly $1000, and possibly a lot more. For a large company with many TB of storage, the initial costs can be defrayed due to the cheaper media, but for a home user, not so much.
Consider that 8TB hard drives can be found for $150 $200. A pair of them (for redundancy) would run $300-400, and then you have all the other benefits of disk (quicker access, etc.) Plus they can be driven by something as cheap as a Raspberry Pi.
Fancier tape setups involve auto-changers, but then you re not really airgapped, are you? (If you leave all your tapes in the changer, they can generally be selected and overwritten, barring things like hardware WORM).
As useful as tape is, for this project, it would simply be way more expensive than disk-based options.
Fundamentals of disk-based airgapping
The fundamental thing we need to address with disk-based airgapping is that the machines being backed up have no real-time contact with the backup storage system. This rules out most solutions out there, that want to sync by comparing local state with remote state. If one is willing to throw storage efficiency out the window maybe practical for very small data sets one could just send a full backup daily. But in reality, what is more likely needed is a way to store a local proxy for the remote state. Then a runner device (a USB stick, disk, etc) could be plugged into the network, filled with queued data, then plugged into the backup system to have the data dequeued and processed.
Some may be tempted to short-circuit this and just plug external disks into a backup system. I ve done that for a long time. This is, however, a risk, because it makes those disks vulnerable to whatever may be attacking the local system (anything from lightning to ransomware).
ZFS
ZFS is, it should be no surprise, particularly well suited for this. zfs send/receive can send an incremental stream that represents a delta between two checkpoints (snapshots or bookmarks) on a filesystem. It can do this very efficiently, much more so than walking an entire filesystem tree.
Additionally, with the recent addition of ZFS crypto to ZFS on Linux, the replication stream can optionally reflect the encrypted data. Yes, as long as you don t need to mount them, you can mostly work with ZFS datasets on an encrypted basis, and can directly tell zfs send to just send the encrypted data instead of the decrypted data.
The downside of ZFS is the resource requirements at the destination, which in terms of RAM are higher than most of the older Raspberry Pi-style devices. Still, one could perhaps just save off zfs send streams and restore them later if need be, but that implies a periodic resend of a full stream, an inefficient operation. dedpulicating software such as borg could be used on those streams (though with less effectiveness if they re encrypted).
Tar
Perhaps surprisingly, tar in listed incremental mode can solve this problem for non-ZFS users. It will keep a local cache of the state of the filesystem as of the time of the last run of tar, and can generate new tarballs that reflect the changes since the previous run (even deletions). This can achieve a similar result to the ZFS send/receive, though in a much less elegant way.
Bacula / Bareos
Bacula (and its fork Bareos) both have support for a FIFO destination. Theoretically this could be used to queue of data for transfer to the airgapped machine. This support is very poorly documented in both and is rumored to have bitrotted, however.
rdiff and xdelta
rdiff and xdelta can be used as sort of a non-real-time rsync, at least on a per-file basis. Theoretically, one could generate a full backup (with tar, ZFS send, or whatever), take an rdiff signature, and send over the file while keeping the signature. On the next run, another full backup is piped into rdiff, and on the basis of the signature file of the old and the new data, it produces a binary patch that can be queued for the backup target to update its stored copy of the file.
This leaves history preservation as an exercise to be undertaken on the backup target. It may not necessarily be easy and may not be efficient.
rsync batches
rsync can be used to compute a delta between two directory trees and express this as a single-file batch that can be processed by a remote rsync. Unfortunately this implies the sender must always keep an old tree around (barring a solution such as ZFS snapshots) in order to compute the delta, and of course it still implies the need for history processing on the remote.
Getting the Data There
OK, so you ve got an airgapped system, some sort of runner device for your sneakernet (USB stick, hard drive, etc). Now what?
Obviously you could just copy data on the runner and move it back off at the backup target. But a tool like NNCP (sort of a modernized UUCP) offer a lot of help in automating the process, returning error reports, etc. NNCP can be used online over TCP, over reliable serial links, over ssh, with offline onion routing via intermediaries or directly, etc.
Imagine having an airgapped machine at a different location you go to frequently (workplace, friend, etc). Before leaving, you put a USB stick in your pocket. When you get there, you pop it in. It s despooled and processed while you want, and return emails or whatever are queued up to be sent when you get back home. Not bad, eh?
Future installment
I m going to try some of these approaches and report back on my experiences in the next few weeks.
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!
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.
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.
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.
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.
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).
Despite having worked on a numberofARMplatforms I ve never actually had an ARM based development box at home. I have a Raspberry Pi B Classic (the original 256MB rev 0002 variant) a coworker gave me some years ago, but it s not what you d choose for a build machine and generally gets used as a self contained TFTP/console server for hooking up to devices under test. Mostly I ve been able to do kernel development with the cross compilers already built as part of Debian, and either use pre-built images or Debian directly when I need userland pieces. At a previous job I had a Marvell MACCHIATObin available to me, which works out as a nice platform - quad core A72 @ 2GHz with 16GB RAM, proper SATA and a PCIe slot. However they re still a bit pricey for a casual home machine. I really like the look of the HoneyComb LX2 - 16 A72 cores, up to 64GB RAM - but it s even more expensive.
So when I saw the existence of the 8GB Raspberry Pi 4 I was interested. Firstly, the Pi 4 is a proper 64 bit device (my existing Pi B is ARMv6 which means it needs to run Raspbian instead of native Debian armhf), capable of running an upstream kernel and unmodified Debian userspace. Secondly the Pi 4 has a USB 3 controller sitting on a PCIe bus rather than just the limited SoC USB 2 controller. It s not SATA, but it s still a fairly decent method of attaching some storage that s faster/more reliable than an SD card. Finally 8GB RAM is starting to get to a decent amount - for a headless build box 4GB is probably generally enough, but I wanted some headroom.
The Pi comes as a bare board, so I needed a case. Ideally I wanted something self contained that could take the Pi, provide a USB/SATA adaptor and take the drive too. I came across the pre-order for the DeskPi Pro, decided it was the sort of thing I was after, and ordered one towards the end of September. It finally arrived at the start of December, at which point I got round to ordering a Pi 4 from CPC.
Total cost ~ 120 for the case + Pi.
The Bad
First, let s get the bad parts out of the way.
I managed to break a USB port on the Desk Pi. It has a pair of forward facing ports, I plugged my wireless keyboard dongle into it and when trying to remove it the solid spacer bit in the socket broke off. I ve never had this happen to me before and I ve been using USB devices for 20 years, so I m putting the blame on a shoddy socket.
The first drive I tried was an old Crucial M500 mSATA device. I have an adaptor that makes it look like a normal 2.5 drive so I used that. Unfortunately it resulted in a boot loop; the Pi would boot its initial firmware, try to talk to the drive and then reboot before even loading Linux. The DeskPi Pro comes with an m2 adaptor and I had a spare m2 drive, so I tried that and it all worked fine. This might just be power issues, but it was an unfortunate experience especially after the USB port had broken off.
(Given I ended up using an M.2 drive another case option would have been the Argon ONE M.2, which is a bit more compact.)
The Annoying
The case is a little snug; I was worried I was going to damage things as I slid it in. Additionally the construction process is a little involved. There s a good set of instructions, but there are a lot of pieces and screws involved. This includes a couple of FFC cables to join things up. I think this is because they ve attempted to make a compact case rather than allowing a little extra room, and it does have the advantage that once assembled it feels robust without anything loose in it.
I hate the need for an external USB3 dongle to bridge from the Pi to the USB/SATA adaptor. All the cases I ve seen with an internal drive bay have to do this, because the USB3 isn t brought out internally by the Pi, but it just looks ugly to me. It s hidden at the back, but meh.
Fan control is via a USB/serial device, which is fine, but it attaches to the USB C power port which defaults to being a USB peripheral. Raspbian based kernels support device tree overlays which allows easy reconfiguration to host mode, but for a Debian based system I ended up rolling my own dtb file. I changed
#include "bcm283x-rpi-usb-peripheral.dtsi"
to
#include "bcm283x-rpi-usb-host.dtsi"
in arch/arm/boot/dts/bcm2711-rpi-4-b.dts and then I did:
and the resulting bcm2711-rpi-4-b.dtb file replaced the one in /boot/firmware. This isn t a necessary step if you don t want to use the cooling fan in the case, or the front USB ports, and it s not really anyone s fault, but it was an annoying extra step to have to figure out.
The DeskPi came with a microSD card that was supposed to have RaspiOS already on it. It didn t, it was blank. In my case that was fine, because I wanted to use Debian, but it was a minor niggle.
The Good
I used Gunnar s pre-built Pi Debian image and it Just Worked; I dd d it to the microSD as instructed and the Pi 4 came up with working wifi, video and USB enabling me to get it configured for my network. I did an apt upgrade and got updated to the Buster 10.7 release, as well as the latest 5.9 backport kernel, and everything came back without effort after a reboot. It s lovely to be able to run Debian on this device without having to futz around with self-compiled kernels.
The DeskPi makes a lot of effort to route things externally. The SD slot is brought out to the front, making it easy to fiddle with the card contents without having to open the case to replace it. All the important ports are brought out to the back either through orientation of the Pi, or extenders in the case. That means the built in Pi USB ports, the HDMI sockets (conveniently converted to full size internally), an audio jack and a USB-C power port. The aforementioned USB3 dongle for the bridge to the drive is the only external thing that s annoying.
Thermally things seem good too. I haven t done a full torture test yet, but with the fan off the system is sitting at about 40 C while fairly idle. Some loops in bash that push load up to above 2 get the temperature up to 46 C or so, and turning the fan on brings it down to 40 C again. It s audible, but quieter than my laptop and not annoying.
I liked the way the case came with everything I needed other than the Pi 4 and a suitable disk drive. There was an included PSU (a proper USB-C PD device, UK plug), the heatsink/fan is there, the USB/SATA converter is there and even an SD card is provided (though that s just because I had a pre-order).
Speaking of the SD, I only needed it for initial setup. Recent Pi 4 bootloaders are capable of booting directly from USB mass storage devices. So I upgraded using the RPi EEPROM Recovery image (which just needs extracted to the SD FAT partition, no need for anything complicated - boot with it and the screen goes all green and you know it s ok), then created a FAT partition at the start of the drive for the kernel / bootloader config and a regular EXT4 partition for root. Copies everything over, updated paths, took out the SD and it all just works happily.
Summary
My main complaint is the broken USB port, which feels like the result of a cheap connector. For a front facing port expected to see more use than the rear ports I think there s a reasonable expectation of robustness. However I m an early adopter and maybe future runs will be better.
Other than that I m pretty happy. The case is exactly the sort of thing I wanted; I was looking for something that would turn the Pi into a box that can sit on my desk on the network and that I don t have to worry about knocking wires out of or lots of cables hooking bits up. Everything being included made it very convenient to get up and running. I still haven t poked the Pi that hard, but first impressions are looking good for it being a trouble free ARM64 dev box in the corner, until I can justify a HoneyComb.
After an unexpectedly short discussion on debian-project, we re moving forward with this new initiative. The Debian security team submitted a project proposal requesting some improvements to tracker.debian.org, and since nobody of the security team wants to be paid to implement the project, we have opened a request for bids to find someone to implement this on a contractor basis.
If you can code in Python following test-driven development and know the Django framework, feel free to submit a bid! Ideally you have some experience with the security tracker too but that s not a strong requirement.
About the project
If you haven t read the discussion on debian-project, Freexian is putting aside part of the money collected for Debian LTS to use it to fund generic Debian development projects. The goal is two-fold:
First, the LTS work necessarily had an impact on other Debian teams that made the project possible (security team, DSA, buildd, ftpmasters, debian-www mainly) and we wanted to be able to give back to those teams by funding improvements to their infrastructure.
We have always allowed paid contributors to go beyond just preparing security updates for the LTS release. They can pick tasks that improve the LTS project at large (we try to collect such tasks here: https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues) but they should not go over 25% of their allocated monthly hours so this limits their ability to tackle bigger projects and we would like to be able to tackle bigger projects that can have a meaningful impact on the LTS project and/or Debian in general.
We have tried to formalize a process to follow from project submission up to its implementation in this salsa project: https://salsa.debian.org/freexian-team/project-funding https://salsa.debian.org/freexian-team/project-funding/-/blob/master/Rules-LTS.md
We highly encourage the above-mentioned Debian teams to make proposals. A member of those teams can implement the project and be paid for it. Or they can decide to let someone else implement it (we expect some of the paid LTS contributors to be willing to implement such projects), and just play the reviewer role driving the person doing the work in the right direction. Contrary to Google s Summer of code and other similar projects, we put the focus on the results (and not in recruiting new volunteers), so we expect to work with experienced persons to implement the project. But if the reviewer is happy to be a mentor and spend more time, then it s OK for us too. The reviewer is (usually) not a paid position.
If you re not among those teams, but if you have a project that can have a positive impact on Debian LTS (even if only indirectly in the distant future), feel free to try your chance and to submit a proposal.
Last week I officially joined the Site Reliability Engineering team at the Wikimedia Foundation. I'll be working with the Service Operations team, which "...takes care of public and user-visible services."
I'm glad to be back at the WMF; I had originally started working there in 2013 but recently took a break to finish school. SRE will be my ninth distinct team at the WMF, and I'm looking forward to even more adventures.
As part of transitioning into my new role, I have unsubscribed myself from most MediaWiki bug mail and Gerrit notifications. Once I get more situated I'll put out a more detailed request for new maintainers for the components that need them. I'll continue taking care of maintenance as needed until then.
P.S.: I created a new userbox about Rust on mediawiki.org.
remctl is a simple GSS-API-based RPC system designed to be as trivial to
deploy as possible for sites already using Kerberos.
I owe various people deeper reviews of remctl feature changes, but alas
this release is not that. This is a bit of a stopgap maintenance release
primarily to fix a testing problem on Debian that booted remctl out of
testing. The basic problem is that a lot of test machinery assumes that
every system will have an IPv4 address available, but this is not
necessarily true on modern systems. This release only fixes the tests
that don't use Kerberos. The tests that require Kerberos have much deeper
assumptions that the IPv4 loopback will be available, and will require
later work (hampered by the fact that I personally don't have such an
environment readily available that also has access to a KDC and need to
construct something in Docker or some similar container system).
This release also adds support for PHP 8 in anticipation of a possible
Debian migration (some minor C source cleanup was required, nothing
major), fixes some Python build system problems, and incorporates the
changes from rra-c-util 8.4.
For future releases, I am considering removing the language bindings from
the remctl distribution and distributing them separately as stand-alone
tarballs. The primary reason for this is to more easily upload those
packages to the respective repositories for those languages (particularly
Perl and Python; I don't know how the Ruby and PHP ones work and would
need to find out), thus making them available to tools like cpanm
and pip as long as the C libraries were already installed. The
cost is that someone who wants the C libraries and the extensions will
have to download multiple tarballs, and someone (not me) will have to
create separate Red hat spec files for the various language bindings.
If this would cause problems for you, let me know. It's not likely to
happen soon since it would require some major reworking of my web page
publication software, but once I finish the prerequisites, I'm likely to
adopt this approach unless there are objections.
You can get the latest release from the remctl distribution page.
I've released a new version of my collection of utility libraries,
Autoconf macros, and similar support infrastructure, primarily to include
changes in the upcoming remctl and INN releases. Highlights:
Add a new RRA_PROG_LD_FLAG Autoconf macro to check whether
flags are supported by the linker, and add support for commas in flags
passed to RRA_PROG_C_FLAG.
NetBSD provides reallocarray but doesn't prototype it unless
_OPENBSD_SOURCE is set. Autoconf 2.70 will set that flag when
AC_USE_SYSTEM_EXTENSIONS is given, but it's not yet packaged
for Debian. Work around this in the meantime by prototyping
reallocarray if it's available but not prototyped. (NetBSD
prefers reallocarr, which does indeed have a better API, but
since no other operating system supports it, I'm sticking with
reallocarray for now.)
Fix the probe for AI_ADDRCONFIG on macOS.
Fix the test suite for the portable getnameinfo replacement on
musl libc, whose getaddrinfo returns the stringified version of
an IP address if there is no reverse DNS. This seems like odd
behavior and no other platform does this, but it's easy enough to work
around.
The general support policy for rra-c-util is now that I will drop support
for systems older than fifteen years if it becomes annoying to support
them. That's still extremely conservative, but may let me drop some more
support code that is essentially never used. The replacements for missing
IPv6 functions are probably next on the chopping block.
Thanks to Julien LIE and Bo Lindbergh for their contributions to this
release.
You can get the latest release from the rra-c-util distribution page.
While our last release has matured for quite a little time, there raised demands within our community for a new release. The development has settled this fall and @sni was already using master for a while in production, so we thought about to release. Anyway Debian Freeze is coming, let's cut a new upstream release! The last question was: Who should cut the release?
The last releases was done by @JeremyHolger, but these days everybody is short on time. Fortunately Holger has documented the whole release process very well, so I jumped on the band wagon and slipped into the release wizard role.
Surprisingly it seems I was able to fix all faults I've done in the release process (beside using the 2.2 link in the release announcement mail) and kicked the release of monitoring-plugins 2.3 successfully.
Grab the new Monitoring Plugins release while it's hot (and give the new check_curl a try)!
Hopefully monitoring-plugins 2.3 will hit Debian experimental soon.
If you're familiar with linguistics as a field of scientific study (as
opposed to the tool-based fields of grammar or writing advice), you'll be
familiar with the dichotomy between written and spoken language. We may
spend more time thinking about written language since it is central to
most types of education and carries much of the intellectual and social
weight of society. Linguists, however, see spoken language as more
fundamental, since speech is wired into our brains and universal in human
societies. Written language is a recent and somewhat artificial
invention.
One also learns from linguistics that spoken language does not follow many
of the rules of written language that we painstakingly memorized in
school. In casual speech, people split infinitives, speak in partial and
run-on sentences, ignore nit-picking pronoun case rules, and rarely notice
or care about the difference between less and fewer. Spoken language does
have rules, but they're more subtle and nuanced than the grammar rules we
learn in school. (I think the real fun of linguistics is separating the
rules that native speakers follow effortlessly from the artificial rules
used as education markers.) This is, in part, because nearly all spoken
language is informal, whereas nearly all written language is formal.
Enter the Internet, and enter this book. For the first time in human
history we have both an explosion of informal writing and easy
availability of that writing to linguists for study.
Informal writing is not entirely new, of course. We've had personal
letters for nearly as long as we've had writing, not to mention private
notes, diaries, and other writing intended for tiny audiences. But
consider who wrote private letters and, on top of that historical filter,
whose private letters were preserved for linguistic research. Until
relatively recently, only the upper classes were literate and had access
to the infrastructure to write and send letters. Someone's letters or
private notes were unlikely to be preserved unless they were someone
famous and important, and thus often well-educated and more likely to take
a more formal tone in writing.
If you compare this to the Internet-driven blizzard of work and personal
email, SMS conversations, chatrooms, and social media posts, the
difference is obvious in both volume and level of informality. We're all
on the Internet, we all read and write with a frequency that would be
staggering to the average person from even fifty years ago, and while one
may take a bit of additional care with a tricky email to one's manager,
the SMS message to one's friend is as informal of a use of language as a
conversation over coffee.
Gretchen McCulloch is a professional linguist and Because Internet
is about exactly this phenomenon: the new conventions of informal writing,
how it has changed and evolved, and the new subtleties and shortcuts we've
invented to make written communication easier. That goes beyond words and
grammar to encompass punctuation, emoji and emoticons, memes and reaction
gifs, and even the subtleties of timing, whitespace, and the construction
of virtual places via our choices in how and where we write.
This topic is my catnip, so it's not surprising I love this book. I've
been heavily involved with online communities that communicate in writing
since 1993 (making me, in McCulloch's classification, an Old Internet
Person; each wave of introduction to the Internet has its own conventions
that can be in conflict with later waves). I've now spent more than half
my life carrying out most of my social activity and most of my closest
friendships primarily in writing, so I found a lot of satisfaction in a
linguistic study that takes that seriously rather than treating it as a
curiosity. But, even better, I was amazed at how much I didn't know, in
part because I am from a specific wave. I have a deep intuition for the
Usenet conventions, but not as good of an understanding of the ones from
AIM and LiveJournal one wave later (the Full Internet People). And I had
a lot to learn about the conventions of the Instagram and Snapchat cluster
(the Post Internet People, who have never known life without the
Internet).
One of the things that struck me while reading this book is how most of
the language innovations that McCulloch describes are addressing the old
complaint that written communication is inferior to face-to-face
conversation because it lacks emotional nuance. My knee-jerk reply is
that, no, written communication is full of emotional nuance and the
complainer is just bad at reading it, but that's somewhat unfair. A
better statement of the problem is that there is not a standardized
language for emotional nuance in written communication, in part because
it's so new in human history. Most humans are extremely good at reading
facial expressions and body language for emotional cues, and those
physical expressions are largely subconscious, reliable, and similar among
different people (particularly within a culture; one can get in trouble
with body language variations across cultures). This is not true of
writing. With friends I've talked to over chat for twenty-five years, I
can read volumes about their emotional state in a couple of short lines of
text. But with strangers, despite decades of Internet communications, I
will still misread cues and misinterpret simple intentions.
The other standard response to this complaint is that it is possible to
put extensive emotional nuance into formal writing. Just get better at
writing! This is true, but unhelpful. There's a reason why we give book
contracts to people who are very good at investing formal writing with
emotional nuance. It's difficult, time-consuming, and requires a great
deal of practice. That may be appropriate for formal, paid writing, but
it won't do for informal writing, which by definition needs to be as
effortless as possible.
It's therefore unsurprising that once millions of people were using the
Internet regularly for informal writing, they started adding new
mechanisms, shortcuts, and conventions for emotional nuance. The
standardization is growing, but conventions still vary widely between
waves of Internet users. One of the most fascinating parts of this book
for me was McCulloch's explanation of why periods (and, to a lesser
extent, capital letters) in short chat messages are perceived by younger
users as harsh or passive-aggressive. I still have the formal writing
mindset of treating proper capitalization and punctuation as a point of
pride, but McCulloch makes an excellent argument for letting go of my
biases and understanding how and why language is changing.
The realization I had while reading this is that many of the changes that
look like sloppiness or laziness to someone trained in formal writing have
the effect of giving language greater dynamic range. If one always uses
periods uniformly, the period becomes meaningless except as a sentence
boundary (which is redundant with newlines in most short informal chat
messages). If one normally doesn't use it, and then suddenly starts using
it, the period can carry semantic weight. It can convey a snippy tone of
voice, a note of annoyance, or other subtle shades of meaning.
I still use periods in most of my Slack messages because habits are hard
to break, but I'm remembering to leave them off some of the time and
paying more attention to what emotional weight they're carrying when
present. Because Internet is therefore the rare book that meets
the bar of changing my day-to-day behavior.
"lol" is another excellent example that McCulloch spends some time on. It
started life as LOL, an abbreviation for "laughing out loud," and that's
still how it's stuck in my head. But, as McCulloch explains, it no longer
means that to newer waves of Internet users. It now carries a far more
complicated and nuanced meaning that has very little to do with physical
laughter and that doesn't easily translate to a single word or sentence.
I went from being mildly irritated by and mildly superior towards the
ubiquitous "lol" to realizing that it's a fascinating new word that
carries primarily emotional nuance and that I don't understand well enough
to read or use properly (yet).
One more example of the type of analysis McCulloch brings to this book:
emoji. The tendency when talking about emoji is to treat them as rebuses
(pictures that stand in for a word, or at least a specific concept). They
are sometimes used that way, but McCulloch argues that they more often
function in the same role that gestures play in informal speech, including
the gestures that have no simple name and no independent meaning outside
of the context of the words being said at the same time. This seems
obvious in retrospect, but before reading Because Internet I had
never thought about what a gesture is, what function it plays in speech,
and how that could be translated into informal written communication.
If you're as interested in this area as I am, this is great stuff. I'd
seen several mentions of this book go past on Twitter and kept holding off
because I had lots of things to read and was worried it would only cover
the superficial things I already knew as a long-time Internet user who has
listened to a few lectures on linguistics. That was not the case at all.
I learned so much from this book and had a delightful time reading it. If
you're also interested in these topics, recommended.
Rating: 9 out of 10
Okay, getting a title that will ensure clicks for this post was easy. Now comes the hard part: content!
When you deploy The Foreman, you want a secure setup by default. That's why we ship (and enable) a SELinux policy which allows you to run the involved daemons in confined mode.
We have recently switched our default Ruby application server from Passenger (running via mod_passengerinside Apache httpd) to Puma (running standalone and Apache just being a reverse proxy). While doing so, we initially deployed Puma listening on localhost:3000 and while localhost is pretty safe, a local user could still turn out evil and talk directly to Puma, pretending to be authenticated by Apache (think Kerberos or X.509 cert auth).
Obviously, this is not optimal, so the next task was to switch Puma to listen on an UNIX socket and only allow Apache to talk to said socket.
This doesn't sound overly complicated, and indeed it wasn't. The most time/thought was spent on doing that in a way that doesn't break existing setups and still allows binding to a TCP socket for setups where users explicitly want that.
We also made a change to the SELinux policy to properly label the newly created socket and allow httpd to access it.
The whole change was carefully tested on CentOS 7 and worked like a charm. So we merged it, and it broke. Only on CentOS 8, but broken is broken, right?
This is the start of my Thanksgiving story "learn how to debug SELinux issues" ;)
From the logs of our integration test I knew the issue was Apache not being able to talk to that new socket (we archive sos reports as part of the tests, and those clearly had it in the auditd logs). But I also knew we did prepare our policy for that change, so either our preparation was not sufficient or the policy wasn't properly loaded.
The same sos report also contained the output of semanage fcontext --list which stated that all regular files called /run/foreman.sock would get the foreman_var_run_t type assigned. Wait a moment, all regular files?! A socket is not a regular file! Let's quickly make that truly all files. That clearly changed the semanage fcontext --list output, but the socket was still created as var_run_t?!
It was time to actually boot a CentOS 8 VM and try more things out. Interestingly, you actually can't add a rule for /run/something, as /run is an alias (equivalency in SELinux speak) for /var/run:
I have no idea how the list output in the report got that /run rule, but okay, let's match /var/run/foreman.sock.
Did that solve the issue? Of course not! And you knew it, as I didn't get to the juciest part of the headline yet: systemd!
We use systemd to create the socket, as it is both convenient and useful (no more clients connecting before Rails has finished booting). But why is it wrongly labeling our freshly created socket?! A quick check with touch shows that the policy is correct now, the touched file gets the right type assigned. So it must be something with systemd
A bit of poking (and good guesswork based on prior experience with a similar issue in Puppet: PUP-2169 and PUP-10548) led to the realization that a systemctl daemon-reexec after adding the file context rule "fixes" the issue. Moving the poking to Google, you quickly end up at systemd issue #9997 which is fixed in v245, but that's in no EL release yet. And indeed, the issue seems fixed on my Fedora 33 with systemd 246, but I still need it to work on CentOS 7 and 8
Well, maybe that reexec isn't that bad after all? At least the socket is now properly labeled and httpd can connect to it on CentOS 8.
Btw, no idea why the connection worked on CentOS 7, as there the socket was also wrongly labeled, but SELinux didn't deny httpd to open it.
Big shout out to lzap and ewoud for helping me with this beast!
Welcome to gambaru.de. Here is my monthly report (+ the first week in December) that covers what I have been doing for Debian. If you re interested in Java, Games and LTS topics, this might be interesting for you.
Debian Games
I updated ufoai, UFO: Alien Invasion, and had to remove its map editor uforadiant because it depends on obsolete GTK 2 libraries. This prevented the removal of the whole game from testing. Upstream is looking for help to port the editor to GTK 3.
ArmagetronAD, a light cycle game, was updated to version 0.2.9.0.1 and then to 0.2.9.1.0. Apparently the developers had some Corona related spare time and fixed various bugs.
I could fix a display error in bastet s highscore list, a ncurses falling block game. (#931550)
At the end of the release cycle I usually update all of my remaining packages which haven t been updated already. Most of the time I check if a package is still Policy compliant with the latest released version of the Debian Policy and I switch to the latest debhelper compatibility level and do some other polishing. This affected the following games: abe, amoebax, late, zangband, brainparty, dangen, and etw.
I also packaged new versions of berusky, a sokoban game, and freeciv, the famous strategy game and
sponsored a bug fix update of whichwayisup for Reiner Herrmann and
did a NMU for fonts-play, patch by Martin Erik Werner, to prevent the removal of Red Eclipse, a first person shooter, from testing.
Debian Java
Similar to games I also update the remaining Java packages at the end of the release cycle with focus on my own packages but also other team maintained packages which haven t seen updates for quite a long time. Hence I touched libjcommon-java, libjemmy2-java, libjfreechart-java, libcsv-java, electric and dbus-java. I dropped dbus-java-bin because it was of little value for users, the tools were not working as intended and buggy. The project itself is no longer actively developed but it appears there is a fork with new updates. As long as the reverse-dependencies of libdbus-java continue to function I don t plan to switch though.
Debian LTS
This was my 57. month as a paid contributor and I have been paid to work 12 hours on Debian LTS, a project started by Rapha l Hertzog. In that time I did the following:
DLA-2447-1. Issued a security update for libxstream-java fixing 1 CVE.
Triaged the open CVE in webcit as ignored in line with the latest version in Buster. The package was recently removed from Debian.
Completed the package upgrade of pacemaker. My local tests finished successfully but I will only upload it if I get positive feedback from the users who reported the previous regression. The update would fix all remaining security issues but as with any new version there is a risk of introducing regressions.
Continued the work on ansible.
ELTS
Extended Long Term Support (ELTS) is a project led by Freexian to further extend the lifetime of Debian releases. It is not an official Debian project but all Debian users benefit from it without cost. The current ELTS release is Debian 8 Jessie . This was my 30. month and I have been paid to work 15 hours on ELTS.
ELA-326-1. Issued a security update for libxstream-java fixing 1 CVE.
ELA-329-1. Investigated the eight remaining CVE in jasper. I could fix four CVE. It looks the rest is either not security relevant or can only be observed when jasper is compiled with ASAN.
Investigated the remaining CVE in phpmyadmin and synced the fixes from Stretch with the released version in Jessie.
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 
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 
Today, the 
Despite having worked on a 
I managed to break a USB port on the Desk Pi. It has a pair of forward facing ports, I plugged my wireless keyboard dongle into it and when trying to remove it the solid spacer bit in the socket broke off. I ve never had this happen to me before and I ve been using USB devices for 20 years, so I m putting the blame on a shoddy socket.
The first drive I tried was an old Crucial M500 mSATA device. I have an adaptor that makes it look like a normal 2.5 drive so I used that. Unfortunately it resulted in a boot loop; the Pi would boot its initial firmware, try to talk to the drive and then reboot before even loading Linux. The DeskPi Pro comes with an m2 adaptor and I had a spare m2 drive, so I tried that and it all worked fine. This might just be power issues, but it was an unfortunate experience especially after the USB port had broken off.
(Given I ended up using an M.2 drive another case option would have been the 
The case is a little snug; I was worried I was going to damage things as I slid it in. Additionally the construction process is a little involved. There s a good set of instructions, but there are a lot of pieces and screws involved. This includes a couple of 
I hate the need for an external USB3 dongle to bridge from the Pi to the USB/SATA adaptor. All the cases I ve seen with an internal drive bay have to do this, because the USB3 isn t brought out internally by the Pi, but it just looks ugly to me. It s hidden at the back, but meh.
Fan control is via a USB/serial device, which is fine, but it attaches to the USB C power port which defaults to being a USB peripheral. Raspbian based kernels support device tree overlays which allows easy reconfiguration to host mode, but for a Debian based system I ended up rolling my own dtb file. I changed
After an unexpectedly short 
While our last release has matured for quite a little time, there 
Welcome to gambaru.de. Here is my monthly report (+ the first week in December) that covers what I have been doing for Debian. If you re interested in Java, Games and LTS topics, this might be interesting for you.
Debian Games
