Happy 2024!
DAIS have continued their programme of posthumous Coil remasters and re-issues.
Constant Shallowness Leads To
Evil
was remastered by Josh Bonati in 2021 and re-released in 2022 in a dizzying
array of different packaging variants. The original releases in 2000 had barely
any artwork, and given that void I think Nathaniel Young has done a great job
of creating something compelling.
A limited number of the original re-issue have special lenticular covers, although
these were not sold by any distributors outside the US. I tried to find a copy on
my trip to Portland in 2022, to no avail.
Last year DAIS followed Constant with Queens Of The Circulating
Library,
same deal: limited lenticular covers, US only.
Both are also available digital-only, e.g. on Bandcamp:
Constant ,
Queens .
The original, pre-remastered releases have been freely available on archive.org for a long time:
Constant ,
Queens
Both of these releases feel to me that they were made available by the group
somewhat as an afterthought, having been produced primarily as part of their
live efforts. (I'm speculating freely here, it might not be true). Live takes
of some of this material exist in the form of Coil Presents Time
Machines, which
has not (yet) been reissued. In my opinion this is a really compelling
recording. I vividly remember listening to this whilst trying to get an hour's
rest in a hotel somewhere on a work trip. It took me to some strange places!
I'll leave you from one of my favourite moments from "Colour Sound Oblivion",
Coil's video collection of live backdrops. When this was performed live it
was also called "Constant Shallowness Leads To Evil", although it's distinct
from the material on the LP:
also available on
archive.org. A version of
this Constant made it onto a Russian live bootleg, which is available on
Spotifyand Bandcamp
complete with some John Balance banter: we only do this on religious holidays Constant Shallowness Leads to Evil by Coil
Back at $COMPANY we had an internal meme-site. I had some reputation in my team for creating good memes. When I watched Episode 3 of Season 2 from Yes Premier Minister yesterday, I really missed a place to post memes.
This is the full scene. Please watch it or even the full episode before scrolling down to the GIFs. I had a good laugh for some time.
With Debian, I could just download the episode from somewhere on the net with youtube-dl and easily create two GIFs using ffmpeg, with and without subtitle:
I believe, one needs to install the libavfilter-extra variant to burn the subtitle in the GIF.
Some
space
to
hide
the
GIFs.
The Premier Minister just learned, that his predecessor, who was about to publish embarassing memories, died of a sudden heart attack:
I can t actually think of a meme with this GIF, that the internal thought police community moderation would not immediately take down.
For a moment I thought that it would be fun to have a Meme-Site for Debian members. But it is probably not the right time for this.
Maybe somebody likes the above GIFs though and wants to use them somewhere.
Making Money is the 36th Discworld novel, the second Moist von
Lipwig book, and a direct sequel to Going
Postal. You could start the series with Going Postal, but I
would not start here.
The post office is running like a well-oiled machine, Adora Belle is out
of town, and Moist von Lipwig is getting bored. It's the sort of boredom
that has him picking his own locks, taking up Extreme Sneezing, and
climbing buildings at night. He may not realize it, but he needs
something more dangerous to do. Vetinari has just the thing.
The Royal Bank of Ankh-Morpork, unlike the post office before Moist got to
it, is still working. It is a stolid, boring institution doing stolid,
boring things for rich people. It is also the battleground for the Lavish
family past-time: suing each other and fighting over money. The Lavishes
are old money, the kind of money carefully entangled in trusts and
investments designed to ensure the family will always have money
regardless of how stupid their children are. Control of the bank is
temporarily in the grasp of Joshua Lavish's widow Topsy, who is not a true
Lavish, but the vultures are circling.
Meanwhile, Vetinari has grand city infrastructure plans, and to carry them
out he needs financing. That means he needs a functional bank, and
preferably one that is much less conservative.
Moist is dubious about running a bank, and even more reluctant when Topsy
Lavish sees him for exactly the con artist he is. His hand is forced when
she dies, and Moist discovers he has inherited her dog, Mr. Fusspot. A
dog that now owns 51% of the Royal Bank and therefore is the chairman of
the bank's board of directors. A dog whose safety is tied to Moist's own
by way of an expensive assassination contract.
Pratchett knew he had a good story with Going Postal, so here he
runs the same formula again. And yes, I was happy to read it again.
Moist knows very little about banking but quite a lot about pretending
something will work until it does, which has more to do with banking than
it does with running a post office. The bank employs an expert, Mr. Bent,
who is fanatically devoted to the gold standard and the correctness of the
books and has very little patience for Moist. There are golem-related
hijinks. The best part of this book is Vetinari, who is masterfully
manipulating everyone in the story and who gets in some great lines about
politics.
"We are not going to have another wretched empire while I am
Patrician. We've only just got over the last one."
Also, Vetinari processing dead letters in the post office was an absolute
delight.
Making Money does have the recurring Pratchett problem of having a
fairly thin plot surrounded by random... stuff. Moist's attempts to
reform the city currency while staying ahead of the Lavishes is only
vaguely related to Mr. Bent's plot arc. The golems are unrelated to the
rest of the plot other than providing a convenient deus ex
machina. There is an economist making water models in the bank basement
with an Igor, which is a great gag but has essentially nothing to do with
the rest of the book. One of the golems has been subjected to
well-meaning older ladies and 1950s etiquette manuals, which I thought was
considerably less funny (and somewhat creepier) than Pratchett did. There
are (sigh) clowns, which continue to be my least favorite Ankh-Morpork
world-building element. At least the dog was considerably less annoying
than I was afraid it was going to be.
This grab-bag randomness is a shame, since I think there was room here for
a more substantial plot that engaged fully with the high weirdness of
finance. Unfortunately, this was a bit like the post office in
Going Postal: Pratchett dives into the subject just enough to make
a few wry observations and a few funny quips, and then resolves the deeper
issues off-camera. Moist tries to invent fiat currency, because of course
he does, and Pratchett almost takes on the gold standard, only to veer
away at the last minute into vigorous hand-waving. I suspect part of the
problem is that I know a little bit too much about finance, so I kept
expecting Pratchett to take the humorous social commentary a couple of
levels deeper.
On a similar note, the villains have great potential that Pratchett
undermines by adding too much over-the-top weirdness. I wish Cosmo Lavish
had been closer to what he appears to be at the start of the book: a very
wealthy and vindictive man (and a reference to Cosimo de Medici) who
doesn't have Moist's ability to come up with wildly risky gambits but who
knows considerably more than he does about how banking works. Instead,
Pratchett gives him a weird obsession that slowly makes him less sinister
and more pathetic, which robs the book of a competent antagonist for
Moist.
The net result is still a fun book, and a solid Discworld entry, but it
lacks the core of the best series entries. It felt more like a skit
comedy show than a novel, but it's an excellent skit comedy show with the
normal assortment of memorable Pratchettisms. Certainly if you've read
this far, or even if you've only read Going Postal, you'll want to
read Making Money as well.
Followed by Unseen Academicals. The next Moist von Lipwig book is
Raising Steam.
Rating: 8 out of 10
As well as the collection and distribution of compromised keys, the pwnedkeys project also matches those pwned keys against issued SSL certificates.
I m excited to announce that, as of the beginning of 2024, all matched certificates are now being published on the Fediverse, thanks to the botsin.space Mastodon server.
Want to know which sites are susceptible to interception and interference, in (near-)real time?
Do you have a burning desire to know who is issuing certificates to people that post their private keys in public?
Now you can.
How It Works
The process for publishing pwned certs is, roughly, as follows:
All the certificates in Certificate Transparency (CT) logs are hoovered up (using my scrape-ct-log tool, the fastest log scraper in the west!), and the fingerprint of the public key of each certificate is stored in an LMDB datafile.
As new private keys are identified as having been compromised, the fingerprint of that key is checked against all the LMDB files, which map key fingerprints to certificates (actually to CT log entry IDs, from which the certificates themselves are retrieved).
This makes it sound all very straightforward, and it is in theory.
The trick comes in optimising the pipeline so that the five million or so new certificates every day can get indexed on the one slightly middle-aged server I ve got, without getting backlogged.
Why Don t You Just Have the Certificates Revoked?
Funny story about that
I used to notify CAs of certificates they d issued using compromised keys, which had the effect of requiring them to revoke the associated certificates.
However, several CAs disliked having to revoke all those certificates, because it cost them staff time (and hence money) to do so.
They went so far as to change their procedures from the standard way of accepting problem reports (emailing a generic attestation of compromise), and instead required CA-specific hoop-jumping to notify them of compromised keys.
Since the effectiveness of revocation in the WebPKI is, shall we say, homeopathic at best, I decided I couldn t be bothered to play whack-a-mole with CAs that just wanted to be difficult, and I stopped sending compromised key notifications to CAs.
Instead, now I m publishing the details of compromised certificates to everyone, so that users can protect themselves directly should they choose to.
Further Work
The astute amongst you may have noticed, in the above How It Works description, a bit of a gap in my scanning coverage.
CAs can (and do!) issue certificates for keys that are already compromised, including weak keys that have been known about for a decade or more (1, 2, 3).
However, as currently implemented, the pwnedkeys certificate checker does not automatically find such certificates.
My plan is to augment the CT scraping / cert processing pipeline to check all incoming certificates against the existing (2M+) set of pwned keys.
Though, with over five million new certificates to check every day, it s not necessarily as simple as just hit the pwnedkeys API for every new cert .
The poor old API server might not like that very much.
Support My Work
If you d like to see this extra matching happen a bit quicker, I ve setup a ko-fi supporters page, where you can support my work on pwnedkeys and the other open source software and projects I work on by buying me a refreshing beverage.
I would be very appreciative, and your support lets me know I should do more interesting things with the giant database of compromised keys I ve accumulated.
Apparently I got an honour from OpenUK.
There are a bunch of people I know on that list. Chris Lamb and Mark Brown
are familiar names from Debian. Colin King and
Jonathan Riddell are people I know from past work in
Ubuntu. I ve admired David MacIver s work on
Hypothesis and Richard Hughes work on
firmware updates from afar. And there are a bunch of
other excellent projects represented there:
OpenStreetMap,
Textualize, and my alma mater of
Cambridge to name but a few.
My friend Stuart Langridge
wrote about
being on a similar list a few years ago, and I can t do much better than to
echo it: in particular he wrote about the way the open source development
community is often at best unwelcoming to people who don t look like Stuart
and I do. I can t tell a whole lot about demographic distribution just by
looking at a list of names, but while these honours still seem to be skewed
somewhat male, I m fairly sure they re doing a lot better in terms of gender
balance than my home project of Debian is, for one. I hope this is a sign
of improvement for the future, and I ll do what I can to pay it forward.
Review: The Library of Broken Worlds, by Alaya Dawn Johnson
Publisher:
Scholastic Press
Copyright:
June 2023
ISBN:
1-338-29064-9
Format:
Kindle
Pages:
446
The Library of Broken Worlds is a young-adult far-future science
fantasy. So far as I can tell, it's stand-alone, although more on that
later in the review.
Freida is the adopted daughter of Nadi, the Head Librarian, and her
greatest wish is to become a librarian herself. When the book opens,
she's a teenager in highly competitive training. Freida is low-wetware,
without the advanced and expensive enhancements of many of the other
students competing for rare and prized librarian positions, which she
makes up for by being the most audacious. She doesn't need wetware to
commune with the library material gods. If one ventures deep into their
tunnels and consumes their crystals, direct physical communion is
possible.
The library tunnels are Freida's second home, in part because that's where
she was born. She was created by the Library, and specifically by Iemaja,
the youngest of the material gods. Precisely why is a mystery. To Nadi,
Freida is her daughter. To Quinn, Nadi's main political rival within the
library, Freida is a thing, a piece of the library, a secondary and
possibly rogue AI. A disruptive annoyance.
The Library of Broken Worlds is the sort of science fiction where
figuring out what is going on is an integral part of the reading
experience. It opens with a frame story of an unnamed girl (clearly
Freida) waking the god Nameren and identifying herself as designed for
deicide. She provokes Nameren's curiosity and offers an Arabian Nights
bargain: if he wants to hear her story, he has to refrain from killing her
for long enough for her to tell it. As one might expect, the main
narrative doesn't catch up to the frame story until the very end of the
book.
The Library is indeed some type of library that librarians can search for
knowledge that isn't available from more mundane sources, but Freida's
personal experience of it is almost wholly religious and oracular. The
library's material gods are identified as AIs, but good luck making sense
of the story through a science fiction frame, even with a healthy
allowance for sufficiently advanced technology being indistinguishable
from magic. The symbolism and tone is entirely fantasy, and late in the
book it becomes clear that whatever the material gods are, they're not
simple technological AIs in the vein of, say, Banks's Ship Minds.
Also, the Library is not solely a repository of knowledge. It is the
keeper of an interstellar peace. The Library was founded after the Great
War, to prevent a recurrence. It functions as a sort of legal system and
grand tribunal in ways that are never fully explained.
As you might expect, that peace is based more on stability than fairness.
Five of the players in this far future of humanity are the Awilu, the most
advanced society and the first to leave Earth (or Tierra as it's called
here); the Mah m, who possess the material war god Nameren of the frame
story; the Lunars and Martians, who dominate the Sol system; and the
surviving Tierrans, residents of a polluted and struggling planet that is
ruthlessly exploited by the Lunars. The problem facing Freida and her
friends at the start of the book is a petition brought by a young Tierran
against Lunar exploitation of his homeland. His name is Joshua, and
Freida is more than half in love with him. Joshua's legal argument
involves interpretation of the freedom node of the treaty that ended the
Great War, a node that precedent says gives the Lunars the freedom to
exploit Tierra, but which Joshua claims has a still-valid originalist
meaning granting Tierrans freedom from exploitation.
There is, in short, a lot going on in this book, and "never fully
explained" is something of a theme. Freida is telling a story to Nameren
and only explains things Nameren may not already know. The reader has to
puzzle out the rest from the occasional hint. This is made more difficult
by the tendency of the material gods to communicate only in visions or
guided hallucinations, full of symbolism that the characters only partly
explain to the reader.
Nonetheless, this did mostly work, at least for me. I started this book
very confused, but by about the midpoint it felt like the background was
coming together. I'm still not sure I understand the aurochs, baobab, and
cicada symbolism that's so central to the framing story, but it's the
pleasant sort of stretchy confusion that gives my brain a good workout. I
wish Johnson had explained a few more things plainly, particularly near
the end of the book, but my remaining level of confusion was within my
tolerances.
Unfortunately, the ending did not work for me. The first time I read it,
I had no idea what it meant. Lots of baffling, symbolic things happened
and then the book just stopped. After re-reading the last 10%, I think
all the pieces of an ending and a bit of an explanation are there, but
it's absurdly abbreviated. This is another book where the author appears
to have been finished with the story before I was.
This keeps happening to me, so this probably says something more about me
than it says about books, but I want books to have an ending. If the
characters have fought and suffered through the plot, I want them to have
some space to be happy and to see how their sacrifices play out, with more
detail than just a few vague promises. If much of the book has been
puzzling out the nature of the world, I would like some concrete
confirmation of at least some of my guesswork. And if you're going to end
the book on radical transformation, I want to see the results of that
transformation. Johnson does an excellent job showing how brutal the
peace of the powerful can be, and is willing to light more things on fire
over the course of this book than most authors would, but then doesn't
offer the reader much in the way of payoff.
For once, I wish this stand-alone turned out to be a series. I think an
additional book could be written in the aftermath of this ending, and I
would definitely read that novel. Johnson has me caring deeply about
these characters and fascinated by the world background, and I'd happily
spend another 450 pages finding out what happens next. But,
frustratingly, I think this ending was indeed intended to wrap up the
story.
I think this book may fall between a few stools. Science fiction readers
who want mysterious future worlds to be explained by the end of the book
are going to be frustrated by the amount of symbolism, allusion, and
poetic description. Literary fantasy readers, who have a higher tolerance
for that style, are going to wish for more focused and polished writing.
A lot of the story is firmly YA: trying and failing to fit in, developing
one's identity, coming into power, relationship drama, great betrayals and
regrets, overcoming trauma and abuse, and unraveling lies that adults tell
you. But this is definitely not a straight-forward YA plot or world
background. It demands a lot from the reader, and while I am confident
many teenage readers would rise to that challenge, it seems like an
awkward fit for the YA marketing category.
About 75% of the way in, I would have told you this book was great and you
should read it. The ending was a let-down and I'm still grumpy about it.
I still think it's worth your attention if you're in the mood for a
sink-or-swim type of reading experience. Just be warned that when the
ride ends, I felt unceremoniously dumped on the pavement.
Content warnings: Rape, torture, genocide.
Rating: 7 out of 10
Est aberta a inscri o de participantes e a
chamada de atividades
para a
MiniDebConf Belo Horizonte 2024 e para o
FLISOL - Festival Latino-americano de Instala o de Software Livre.
Veja abaixo algumas informa es importantes:
Data e local da MiniDebConf e do FLISOL
A MiniDebConf acontecer de 27 a 30 de abril no
Campus Pampulha da UFMG - Universidade Federal de Minas Gerais.
No dia 27 (s bado) tamb m realizaremos uma edi o do
FLISOL - Festival Latino-americano de Instala o de Software Livre,
evento que acontece no mesmo dia em v rias cidades da Am rica Latina.
Enquanto a MiniDebConf ter atividades focados no Debian, o FLISOL ter
atividades gerais sobre Software Livre e temas relacionados como linguagem de
programa o, CMS, administra o de redes e sistemas, filosofia, liberdade,
licen as, etc.
Inscri o gratuita e oferta de bolsas
Voc j pode realizar a sua inscri o gratuita para a MiniDebConf Belo Horizonte
2024.
A MiniDebConf um evento aberto a todas as pessoas, independente do seu n vel
de conhecimento sobre Debian. O mais importante ser reunir a comunidade para
celebrar um dos maiores projeto de Software Livre no mundo, por isso queremos
receber desde usu rios(as) inexperientes que est o iniciando o seu contato com o
Debian at Desenvolvedores(as) oficiais do projeto. Ou seja, est o todos(as)
convidados(as)!
Este ano estamos ofertando
bolsas de hospedagem e passagens
para viabilizar a vinda de pessoas de outras cidades que
contribuem para o Projeto Debian.
Contribuidores(as) n o oficiais, DMs e DDs podem solicitar as bolsas usando o
formul rio de inscri o.
Tamb m estamos ofertando bolsas de alimenta o para todos(as) os(as)
participantes, mesmo n o contribuidores(as), e pessoas que moram na regi o de
BH.
Os recursos financeiros s o bastante limitados, mas tentaremos atender o m ximo
de pedidos.
Se voc pretende pedir alguma dessas bolsas, acesse
este link e veja mais informa es
antes de realizar a sua inscri o:
A inscri o (sem bolsas) poder ser feita at a data do evento, mas temos uma
data limite para o
pedido de bolsas de hospedagem e passagens, por isso fique atento(a) ao
prazo final: at 18 de fevereiro.
Como estamos usando mesmo formul rio para os dois eventos, a inscri o ser
v lida tanto para a MiniDebConf quanto para o FLISOL.
Para se inscrever, acesse o site, v em
Criar conta. Criei a sua conta
(preferencialmente usando o Salsa) e acesse o
seu perfil. L voc ver o bot o de
Se inscrever.
https://bh.mini.debconf.org
Chamada de atividades
Tamb m est aberta a
chamada de atividades
tanto para MiniDebConf quanto para o FLISOL.
Para mais informa es, acesse
este link.
Fique atento ao prazo final para enviar sua proposta de atividade: at 18 de
fevereiro.
Contato
Qualquer d vida, mande um email para contato@debianbrasil.org.br
Organiza o
Posted on January 13, 2024
Tags: madeof:atoms, craft:bookbinding
In 2022 I read a post on the fediverse by somebody who mentioned that
they had bought on a whim a cute tiny book years ago, and that it
had been a companion through hard times. Right now I can t find the
post, but it was pretty aaaaawwww.
At the same time, I had discovered Coptic binding, and I wanted to do
some exercise to let my hands learn it, but apparently there is a limit
to the number of notebooks and sketchbooks a person needs (I m not 100%
sure I actually believe this, but I ve heard it is a thing).
So I decided to start making minibooks with the intent to give them
away: I settled (mostly) on the A8 size, and used a combination of found
materials, leftovers from bigger projects and things I had in the Stash.
As for paper, I ve used a variety of the ones I have that are at the
very least good enough for non-problematic fountain pen inks.
Thanks to the small size, and the way coptic binding works, I ve been
able to play around with the covers, experimenting with different styles
beyond the classic bookbinding cloth / paper covered cardboard,
including adding lace, covering food box cardboard with gesso and
decorating it with acrylic paints, embossing designs by gluing together
two layers of cardboard, one of which has holes, making covers
completely out of cernit, etc. Some of these I will probably also use in
future full-scale projects, but it s nice to find out what works and
what doesn t on a small scale.
Now, after a year of sporadically making these I have to say that the
making went quite well: I enjoyed the making and the creativity in
making different covers. The giving away was a bit more problematic, as
I didn t really have a lot of chances to do so, so I believe I still
have most of them. In 2024 I ll try to look for more opportunities (and
if you live nearby and want one or a few feel free to ask!)
LXD/Incus backend bug in autopkgtest by Stefano Rivera
While working on the Python 3.12 transition, Stefano repeatedly ran into
a bug in autopkgtest when using LXD (or in
the future Incus), that caused it to hang when running cython s multi-hour
autopkgtests. After some head-banging, the bug turned out to be fairly
straightforward: LXD didn t shut down on receiving a SIGTERM, so when a
testsuite timed out, it would hang forever. A simple
fix has
been applied.
/usr-merge, by Helmut Grohne
Thanks to Christian Hofstaedtler and others, the effort is moving into a
community effort and the work funded by Freexian becomes more difficult to
separate from non-funded work. In particular, since the community fully handled
all issues around lost udev rules, dh_installudev now installs rules to
/usr.
The story around diversions took another detour. We learned that
conflicts do not reliably prevent concurrent unpack
and the reiterated mitigation for molly-guard triggered this. After a bit of
back and forth and consultation with the developer mailing list, we concluded
that avoiding the problematic behavior when using apt or an apt-based
upgrader combined with a loss mitigation would be good enough. The involved
packages bfh-container, molly-guard, progress-linux-container and
systemd have since been uploaded to unstable and the matter seems finally
solved except that it
doesn t quite work with sysvinit yet. The
same approach is now being proposed for the diversions of
zutils for
gzip. We thank involved maintainers for
their timely cooperation.
gcc-for-host, by Helmut Grohne
Since forever, it has been difficult to correctly express a toolchain build
dependency. This can be seen in the Build-Depends of the linux source
package for instance. While this has been solved for binutils a while back,
the patches for gcc have been unfinished. With lots of constructive feedback
from gcc package maintainer Matthias Klose, Helmut worked on finalizing and
testing these patches. Patch stacks are now available for
gcc-13 and
gcc-14 and
Matthias already included parts of them in test builds for Ubuntu noble.
Finishing this work would enable us to resolve around 1000 cross build
dependency satisfiability issues in unstable.
Miscellaneous contributions
Stefano continued work on the Python 3.12 transition, including uploads of
cython, pycxx, numpy, python-greenlet, twisted, foolscap and dh-python.
Stefano reviewed and selected from a new round of DebConf 24 bids, as part
of the DebConf Committee. Busan, South Korea
was selected.
For debian-printing Thorsten uploaded hplip to unstable to fix a /usr-merge
bug and cups to Bookworm to fix bugs related to printing in color.
Utkarsh helped newcomers in mentoring and reviewing their packaging;
eg: golang-github-prometheus-community-pgbouncer-exporter.
Helmut sent patches for 42 cross build failures unrelated to the
gcc-for-host work.
Helmut continues to maintain rebootstrap. In December, blt started
depending on libjpeg and this poses a
dependency loop. Ideally, Python would
stop depending on blt. Also linux-libc-dev having become
Multi-Arch: foreign poses non-trivial issues that are not fully resolved
yet.
Enrico participated in /usr-merge discussions with Helmut.
Version 0.0.16 of RcppSpdlog is now
on CRAN and will be uploaded to
Debian. RcppSpdlog
bundles spdlog, a
wonderful header-only C++ logging library with all the bells and
whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn
more at the nice package
documention site.
This releases updates the code to the version 1.13 of spdlog which was release
this morning.
The NEWS entry for this release follows.
An new version 0.2.6 of the random-number generator tester RDieHarder
(based on the DieHarder
suite developed / maintained by Robert Brown with contributions by David
Bauer and myself along with other contributors) is now on CRAN (and to the day year after
the previous release).
This release contains changes to printf format strings
to avoid new warnings on Windows. No functional changes have been
made.
Thanks to CRANberries, you
can also look at the most recent diff
to the previous release.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
Release 0.6.34 of the digest package
arrived at CRAN today and has
also been uploaded to Debian
already.
digest
creates hash digests of arbitrary R objects. It can use a number
different hashing algorithms (md5, sha-1,
sha-256, sha-512, crc32,
xxhash32, xxhash64, murmur32,
spookyhash, blake3, and crc32c),
and ebales easy comparison of (potentially large and nested) R language
objects as it relies on the native serialization in R. It is a mature
and widely-used package (with 63.8 million downloads just on the partial
cloud mirrors of CRAN which keep logs) as many tasks may involve
caching of objects for which it provides convenient
general-purpose hash key generation to quickly identify the various
objects.
(Oh and we also just passed the 20th anniversary of the initial CRAN
upload. Time flies, as they say.)
This release contains small (build-focussed) enhancements contributed
by Michael Chirico, and another set of fixed for printf
format warnings this time on Windows.
My CRANberries
provides a summary of changes to the previous
version. For questions or comments use the issue tracker
off the GitHub
repo.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
Tobias Frost
did 10.25h (out of 12.0h assigned), thus carrying over 1.75h to the next month.
Utkarsh Gupta
did 18.75h (out of 11.25h assigned and 13.5h from previous period), thus carrying over 6.0h to the next month.
Evolution of the situation
In December, we have released 29 DLAs.
A particularly notable update in December was prepared by LTS contributor
Santiago Ruano Rinc n for the openssh package. The updated produced
DLA-3694-1 and included a
fix for the Terrapin Attack (CVE-2023-48795), which was a rather serious flaw in
the SSH protocol itself. The package bluez was the subject of another notable
update by LTS contributor Chris Lamb, which resulted in
DLA-3689-1 to address an
insecure default configuration which allowed attackers to inject keyboard
commands over Bluetooth without first authenticating.
The LTS team continues its efforts to have a positive impact beyond the
boundaries of LTS. Several contributors worked on packages, preparing LTS
updates, but also preparing patches or full updates which were uploaded to the
unstable, stable, and oldstable distributions, including: Guilhem Moulin s
update of tinyxml (uploads to LTS and unstable and patches submitted to the
security team for stable and oldstable); Guilhem Moulin s update of xerces-c
(uploads to LTS and unstable and patches submitted to the security team for
oldstable); Thorsten Alteholz s update of libde265 (uploads to LTS and stable
and additional patches submitted to the maintainer for stable and oldstable);
Thorsten Alteholz s update of cjson (upload to LTS and patches submitted to the
maintainer for stable and oldstable); and Tobias Frost s update of opendkim
(sponsor maintainer-prepared upload to LTS and additionally prepared updates for
stable and oldstable).
Going beyond Debian and looking to the broader community, LTS contributor
Bastien Roucari s was contacted by SUSE concerning an update he had prepared for
zbar. He was able to assist by coordinating with the former organization of the
original zbar author to secure for SUSE access to information concerning the
exploits. This has enabled another distribution to benefit from the work done in
support of LTS and from the assistance of Bastien in coordinating the access to
information.
Finally, LTS contributor Santiago Ruano Rinc n continued work relating to how
updates for packages in statically-linked language ecosystems (e.g., Go, Rust,
and others) are handled. The work is presently focused on more accurately and
reliably identifying which packages are impacted in a given update scenario to
enable notifications to be published so that users will be made aware of these
situations as they occur. As the work continues, it will eventually result in
improvements to Debian infrustructure so that the LTS team and Security team are
able to manage updates of this nature in a more consistent way.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Welcome to the December 2023 report from the Reproducible Builds project! In these reports we outline the most important things that we have been up to over the past month. As a rather rapid recap, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries (more).
Reproducibility to affect package migration policy in Debian
In a post summarising the activities of the Debian Release Team at a recent in-person Debian event in Cambridge, UK, Paul Gevers announced a change to the way packages are migrated into the staging area for the next stable Debian release based on its reproducibility status:
The folks from the Reproducibility Project have come a long way since they started working on it 10 years ago, and we believe it s time for the next step in Debian. Several weeks ago, we enabled a migration policy in our migration software that checks for regression in reproducibility. At this moment, that is presented as just for info, but we intend to change that to delays in the not so distant future. We eventually want all packages to be reproducible. To stimulate maintainers to make their packages reproducible now, we ll soon start to apply a bounty [speedup] for reproducible builds, like we ve done with passing autopkgtests for years. We ll reduce the bounty for successful autopkgtests at that moment in time.
Speranza: Usable, privacy-friendly software signing
Kelsey Merrill, Karen Sollins, Santiago Torres-Arias and Zachary Newman have developed a new system called Speranza, which is aimed at reassuring software consumers that the product they are getting has not been tampered with and is coming directly from a source they trust. A write-up on TechXplore.com goes into some more details:
What we have done, explains Sollins, is to develop, prove correct, and demonstrate the viability of an approach that allows the [software] maintainers to remain anonymous. Preserving anonymity is obviously important, given that almost everyone software developers included value their confidentiality. This new approach, Sollins adds, simultaneously allows [software] users to have confidence that the maintainers are, in fact, legitimate maintainers and, furthermore, that the code being downloaded is, in fact, the correct code of that maintainer. []
Nondeterministic Git bundles
Paul Baecher published an interesting blog post on Reproducible git bundles. For those who are not familiar with them, Git bundles are used for the offline transfer of Git objects without an active server sitting on the other side of a network connection. Anyway, Paul wrote about writing a backup system for his entire system, but:
I noticed that a small but fixed subset of [Git] repositories are getting backed up despite having no changes made. That is odd because I would think that repeated bundling of the same repository state should create the exact same bundle. However [it] turns out that for some, repositories bundling is nondeterministic.
Paul goes on to to describe his solution, which involves forcing git to be single threaded makes the output deterministic . The article was also discussed on Hacker News.
Rework the generate-id() function to return deterministic values. We use
a simple incrementing counter and store ids in the 'psvi' member of
nodes which was freed up by previous commits. The presence of an id is
indicated by a new "source node" flag.
This fixes long-standing problems with reproducible builds, see
https://bugzilla.gnome.org/show_bug.cgi?id=751621
This also hardens security, as the old implementation leaked the
difference between a heap and a global pointer, see
https://bugs.chromium.org/p/chromium/issues/detail?id=1356211
The old implementation could also generate the same id for dynamically
created nodes which happened to reuse the same memory. Ids for namespace
nodes were completely broken. They now use the id of the parent element
together with the hex-encoded namespace prefix.
Community updates
There were made a number of improvements to our website, including Chris Lamb fixing the generate-draft script to not blow up if the input files have been corrupted today or even in the past [], Holger Levsen updated the Hamburg 2023 summit to add a link to farewell post [] & to add a picture of a Post-It note. [], and Pol Dellaiera updated the paragraph about tar and the --clamp-mtime flag [].
On our mailing list this month, Bernhard M. Wiedemann posted an interesting summary on some of the reasons why packages are still not reproducible in 2023.
diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including processing objdump symbol comment filter inputs as Python byte (and not str) instances [] and Vagrant Cascadian extended diffoscope support for GNU Guix [] and updated the version in that distribution to version 253 [].
Challenges of Producing Software Bill Of Materials for Java
Musard Balliu, Benoit Baudry, Sofia Bobadilla, Mathias Ekstedt, Martin Monperrus, Javier Ron, Aman Sharma, Gabriel Skoglund, C sar Soto-Valero and Martin Wittlinger (!) of the KTH Royal Institute of Technology in Sweden, have published an article in which they:
deep-dive into 6 tools and the accuracy of the SBOMs they produce for complex open-source Java projects. Our novel insights reveal some hard challenges regarding the accurate production and usage of software bills of materials.
Debian Non-Maintainer campaign
As mentioned in previousreports, the Reproducible Builds team within Debian has been organising a series of online and offline sprints in order to clear the huge backlog of reproducible builds patches submitted by performing so-called NMUs (Non-Maintainer Uploads).
During December, Vagrant Cascadian performed a number of such uploads, including:
In addition, Holger Levsen performed three no-source-change NMUs in order to address the last packages without .buildinfo files in Debian trixie, specifically lorene (0.0.0~cvs20161116+dfsg-1.1), maria (1.3.5-4.2) and ruby-rinku (1.7.3-2.1).
Reproducibility testing framework
The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org) in order to check packages and other artifacts for reproducibility. In December, a number of changes were made by Holger Levsen:
Detect failures due to rename of the vmlinuz file. []
Improve the grammar of an error message. []
Document that freebsd-jenkins.debian.net has been updated to FreeBSD 14.0. []
In addition, node maintenance was performed by Holger Levsen [] and Vagrant Cascadian [].
Upstream patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
This post is in part a response to an aspect of Nate s post Does Wayland really break everything? , but also my reflection on discussing Wayland protocol additions, a unique pleasure that I have been involved with for the past months1.
Some facts
Before I start I want to make a few things clear: The Linux desktop will be moving to Wayland2 this is a fact at this point (and has been for a while), sticking to X11 makes no sense for future projects. From reading Wayland protocols and working with it at a much lower level than I ever wanted to, it is also very clear to me that Wayland is an exceptionally well-designed core protocol, and so are the additional extension protocols (xdg-shell & Co.). The modularity of Wayland is great, it gives it incredible flexibility and will for sure turn out to be good for the long-term viability of this project (and also provides a path to correct protocol issues in future, if one is found). In other words: Wayland is an amazing foundation to build on, and a lot of its design decisions make a lot of sense!
The shift towards people seeing Linux more as an application developer platform, and taking PipeWire and XDG Portals into account when designing for Wayland is also an amazing development and I love to see this this holistic approach is something I always wanted!
Furthermore, I think Wayland removes a lot of functionality that shouldn t exist in a modern compositor and that s a good thing too! Some of X11 s features and design decisions had clear drawbacks that we shouldn t replicate. I highly recommend to read Nate s blog post, it s very good and goes into more detail. And due to all of this, I firmly believe that any advancement in the Wayland space must come from within the project.
But!
But! Of course there was a but coming I think while developing Wayland-as-an-ecosystem we are now entrenched into narrow concepts of how a desktop should work. While discussing Wayland protocol additions, a lot of concepts clash, people from different desktops with different design philosophies debate the merits of those over and over again never reaching any conclusion (just as you will never get an answer out of humans whether sushi or pizza is the clearly superior food, or whether CSD or SSD is better). Some people want to use Wayland as a vehicle to force applications to submit to their desktop s design philosophies, others prefer the smallest and leanest protocol possible, other developers want the most elegant behavior possible. To be clear, I think those are all very valid approaches.
But this also creates problems: By switching to Wayland compositors, we are already forcing a lot of porting work onto toolkit developers and application developers. This is annoying, but just work that has to be done. It becomes frustrating though if Wayland provides toolkits with absolutely no way to reach their goal in any reasonable way. For Nate s Photoshop analogy: Of course Linux does not break Photoshop, it is Adobe s responsibility to port it. But what if Linux was missing a crucial syscall that Photoshop needed for proper functionality and Adobe couldn t port it without that? In that case it becomes much less clear on who is to blame for Photoshop not being available.
A lot of Wayland protocol work is focused on the environment and design, while applications and work to port them often is considered less. I think this happens because the overlap between application developers and developers of the desktop environments is not necessarily large, and the overlap with people willing to engage with Wayland upstream is even smaller. The combination of Windows developers porting apps to Linux and having involvement with toolkits or Wayland is pretty much nonexistent. So they have less of a voice.
A quick detour through the neuroscience research lab
I have been involved with Freedesktop, GNOME and KDE for an incredibly long time now (more than a decade), but my actual job (besides consulting for Purism) is that of a PhD candidate in a neuroscience research lab (working on the morphology of biological neurons and its relation to behavior). I am mostly involved with three research groups in our institute, which is about 35 people. Most of us do all our data analysis on powerful servers which we connect to using RDP (with KDE Plasma as desktop). Since I joined, I have been pushing the envelope a bit to extend Linux usage to data acquisition and regular clients, and to have our data acquisition hardware interface well with it. Linux brings some unique advantages for use in research, besides the obvious one of having every step of your data management platform introspectable with no black boxes left, a goal I value very highly in research (but this would be its own blogpost).
In terms of operating system usage though, most systems are still Windows-based. Windows is what companies develop for, and what people use by default and are familiar with. The choice of operating system is very strongly driven by application availability, and WSL being really good makes this somewhat worse, as it removes the need for people to switch to a real Linux system entirely if there is the occasional software requiring it. Yet, we have a lot more Linux users than before, and use it in many places where it makes sense. I also developed a novel data acquisition software that even runs on Linux-only and uses the abilities of the platform to its fullest extent. All of this resulted in me asking existing software and hardware vendors for Linux support a lot more often. Vendor-customer relationship in science is usually pretty good, and vendors do usually want to help out. Same for open source projects, especially if you offer to do Linux porting work for them But overall, the ease of use and availability of required applications and their usability rules supreme. Most people are not technically knowledgeable and just want to get their research done in the best way possible, getting the best results with the least amount of friction.
KDE/Linux usage at a control station for a particle accelerator at Adlershof Technology Park, Germany, for reference (by 25years of KDE)3
Back to the point
The point of that story is this: GNOME, KDE, RHEL, Debian or Ubuntu: They all do not matter if the necessary applications are not available for them. And as soon as they are, the easiest-to-use solution wins. There are many facets of easiest : In many cases this is RHEL due to Red Hat support contracts being available, in many other cases it is Ubuntu due to its mindshare and ease of use. KDE Plasma is also frequently seen, as it is perceived a bit easier to onboard Windows users with it (among other benefits). Ultimately, it comes down to applications and 3rd-party support though.
Here s a dirty secret: In many cases, porting an application to Linux is not that difficult. The thing that companies (and FLOSS projects too!) struggle with and will calculate the merits of carefully in advance is whether it is worth the support cost as well as continuous QA/testing. Their staff will have to do all of that work, and they could spend that time on other tasks after all.
So if they learn that porting to Linux not only means added testing and support, but also means to choose between the legacy X11 display server that allows for 1:1 porting from Windows or the new Wayland compositors that do not support the same features they need, they will quickly consider it not worth the effort at all. I have seen this happen.
Of course many apps use a cross-platform toolkit like Qt, which greatly simplifies porting. But this just moves the issue one layer down, as now the toolkit needs to abstract Windows, macOS and Wayland. And Wayland does not contain features to do certain things or does them very differently from e.g. Windows, so toolkits have no way to actually implement the existing functionality in a way that works on all platforms. So in Qt s documentation you will often find texts like works everywhere except for on Wayland compositors or mobile 4.
Many missing bits or altered behavior are just papercuts, but those add up. And if users will have a worse experience, this will translate to more support work, or people not wanting to use the software on the respective platform.
What s missing?
Window positioning
SDI applications with multiple windows are very popular in the scientific world. For data acquisition (for example with microscopes) we often have one monitor with control elements and one larger one with the recorded image. There is also other configurations where multiple signal modalities are acquired, and the experimenter aligns windows exactly in the way they want and expects the layout to be stored and to be loaded upon reopening the application. Even in the image from Adlershof Technology Park above you can see this style of UI design, at mega-scale. Being able to pop-out elements as windows from a single-window application to move them around freely is another frequently used paradigm, and immensely useful with these complex apps.
It is important to note that this is not a legacy design, but in many cases an intentional choice these kinds of apps work incredibly well on larger screens or many screens and are very flexible (you can have any window configuration you want, and switch between them using the (usually) great window management abilities of your desktop).
Of course, these apps will work terribly on tablets and small form factors, but that is not the purpose they were designed for and nobody would use them that way.
I assumed for sure these features would be implemented at some point, but when it became clear that that would not happen, I created the ext-placement protocol which had some good discussion but was ultimately rejected from the xdg namespace. I then tried another solution based on feedback, which turned out not to work for most apps, and now proposed xdg-placement (v2) in an attempt to maybe still get some protocol done that we can agree on, exploring more options before pushing the existing protocol for inclusion into the ext Wayland protocol namespace. Meanwhile though, we can not port any application that needs this feature, while at the same time we are switching desktops and distributions to Wayland by default.
Window position restoration
Similarly, a protocol to save & restore window positions was already proposed in 2018, 6 years ago now, but it has still not been agreed upon, and may not even help multiwindow apps in its current form. The absence of this protocol means that applications can not restore their former window positions, and the user has to move them to their previous place again and again.
Meanwhile, toolkits can not adopt these protocols and applications can not use them and can not be ported to Wayland without introducing papercuts.
Window icons
Similarly, individual windows can not set their own icons, and not-installed applications can not have an icon at all because there is no desktop-entry file to load the icon from and no icon in the theme for them. You would think this is a niche issue, but for applications that create many windows, providing icons for them so the user can find them is fairly important. Of course it s not the end of the world if every window has the same icon, but it s one of those papercuts that make the software slightly less user-friendly. Even applications with fewer windows like LibrePCB are affected, so much so that they rather run their app through Xwayland for now.
I decided to address this after I was working on data analysis of image data in a Python virtualenv, where my code and the Python libraries used created lots of windows all with the default yellow W icon, making it impossible to distinguish them at a glance. This is xdg-toplevel-icon now, but of course it is an uphill battle where the very premise of needing this is questioned. So applications can not use it yet.
Limited window abilities requiring specialized protocols
Firefox has a picture-in-picture feature, allowing it to pop out media from a mediaplayer as separate floating window so the user can watch the media while doing other things. On X11 this is easily realized, but on Wayland the restrictions posed on windows necessitate a different solution. The xdg-pip protocol was proposed for this specialized usecase, but it is also not merged yet. So this feature does not work as well on Wayland.
Automated GUI testing / accessibility / automation
Automation of GUI tasks is a powerful feature, so is the ability to auto-test GUIs. This is being worked on, with libei and wlheadless-run (and stuff like ydotool exists too), but we re not fully there yet.
Wayland is frustrating for (some) application authors
As you see, there is valid applications and valid usecases that can not be ported yet to Wayland with the same feature range they enjoyed on X11, Windows or macOS. So, from an application author s perspective, Wayland does break things quite significantly, because things that worked before can no longer work and Wayland (the whole stack) does not provide any avenue to achieve the same result.
Wayland does break screen sharing, global hotkeys, gaming latency (via no tearing ) etc, however for all of these there are solutions available that application authors can port to. And most developers will gladly do that work, especially since the newer APIs are usually a lot better and more robust. But if you give application authors no path forward except use Xwayland and be on emulation as second-class citizen forever , it just results in very frustrated application developers.
For some application developers, switching to a Wayland compositor is like buying a canvas from the Linux shop that forces your brush to only draw triangles. But maybe for your avant-garde art, you need to draw a circle. You can approximate one with triangles, but it will never be as good as the artwork of your friends who got their canvases from the Windows or macOS art supply shop and have more freedom to create their art.
Triangles are proven to be the best shape! If you are drawing circles you are creating bad art!
Wayland, via its protocol limitations, forces a certain way to build application UX often for the better, but also sometimes to the detriment of users and applications. The protocols are often fairly opinionated, a result of the lessons learned from X11. In any case though, it is the odd one out Windows and macOS do not pose the same limitations (for better or worse!), and the effort to port to Wayland is orders of magnitude bigger, or sometimes in case of the multiwindow UI paradigm impossible to achieve to the same level of polish. Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps.
The porting dilemma
I spent probably way too much time looking into how to get applications cross-platform and running on Linux, often talking to vendors (FLOSS and proprietary) as well. Wayland limitations aren t the biggest issue by far, but they do start to come come up now, especially in the scientific space with Ubuntu having switched to Wayland by default. For application authors there is often no way to address these issues. Many scientists do not even understand why their Python script that creates some GUIs suddenly behaves weirdly because Qt is now using the Wayland backend on Ubuntu instead of X11. They do not know the difference and also do not want to deal with these details even though they may be programmers as well, the real goal is not to fiddle with the display server, but to get to a scientific result somehow.
Another issue is portability layers like Wine which need to run Windows applications as-is on Wayland. Apparently Wine s Wayland driver has some heuristics to make window positioning work (and I am amazed by the work done on this!), but that can only go so far.
A way out?
So, how would we actually solve this? Fundamentally, this excessively long blog post boils down to just one essential question:
Do we want to force applications to submit to a UX paradigm unconditionally, potentially loosing out on application ports or keeping apps on X11 eternally, or do we want to throw them some rope to get as many applications ported over to Wayland, even through we might sacrifice some protocol purity?
I think we really have to answer that to make the discussions on wayland-protocols a lot less grueling. This question can be answered at the wayland-protocols level, but even more so it must be answered by the individual desktops and compositors.
If the answer for your environment turns out to be Yes, we want the Wayland protocol to be more opinionated and will not make any compromises for application portability , then your desktop/compositor should just immediately NACK protocols that add something like this and you simply shouldn t engage in the discussion, as you reject the very premise of the new protocol: That it has any merit to exist and is needed in the first place. In this case contributors to Wayland and application authors also know where you stand, and a lot of debate is skipped. Of course, if application authors want to support your environment, you are basically asking them now to rewrite their UI, which they may or may not do. But at least they know what to expect and how to target your environment.
If the answer turns out to be We do want some portability , the next question obviously becomes where the line should be drawn and which changes are acceptable and which aren t. We can t blindly copy all X11 behavior, some porting work to Wayland is simply inevitable. Some written rules for that might be nice, but probably more importantly, if you agree fundamentally that there is an issue to be fixed, please engage in the discussions for the respective MRs! We for sure do not want to repeat X11 mistakes, and I am certain that we can implement protocols which provide the required functionality in a way that is a nice compromise in allowing applications a path forward into the Wayland future, while also being as good as possible and improving upon X11. For example, the toplevel-icon proposal is already a lot better than anything X11 ever had. Relaxing ACK requirements for the ext namespace is also a good proposed administrative change, as it allows some compositors to add features they want to support to the shared repository easier, while also not mandating them for others. In my opinion, it would allow for a lot less friction between the two different ideas of how Wayland protocol development should work. Some compositors could move forward and support more protocol extensions, while more restrictive compositors could support less things. Applications can detect supported protocols at launch and change their behavior accordingly (ideally even abstracted by toolkits).
You may now say that a lot of apps are ported, so surely this issue can not be that bad. And yes, what Wayland provides today may be enough for 80-90% of all apps. But what I hope the detour into the research lab has done is convince you that this smaller percentage of apps matters. A lot. And that it may be worthwhile to support them.
To end on a positive note: When it came to porting concrete apps over to Wayland, the only real showstoppers so far5 were the missing window-positioning and window-position-restore features. I encountered them when porting my own software, and I got the issue as feedback from colleagues and fellow engineers. In second place was UI testing and automation support, the window-icon issue was mentioned twice, but being a cosmetic issue it likely simply hurts people less and they can ignore it easier.
What this means is that the majority of apps are already fine, and many others are very, very close! A Wayland future for everyone is within our grasp!
I will also bring my two protocol MRs to their conclusion for sure, because as application developers we need clarity on what the platform (either all desktops or even just a few) supports and will or will not support in future. And the only way to get something good done is by contribution and friendly discussion.
Footnotes
Apologies for the clickbait-y title it comes with the subject
When I talk about Wayland I mean the combined set of display server protocols and accepted protocol extensions, unless otherwise clarified.
I would have picked a picture from our lab, but that would have needed permission first
Qt has awesome platform issues pages, like for macOS and Linux/X11 which help with porting efforts, but Qt doesn t even list Linux/Wayland as supported platform. There is some information though, like window geometry peculiarities, which aren t particularly helpful when porting (but still essential to know).
Besides issues with Nvidia hardware CUDA for simulations and machine-learning is pretty much everywhere, so Nvidia cards are common, which causes trouble on Wayland still. It is improving though.
Boost is a very large and
comprehensive set of (peer-reviewed) libraries for the C++ programming
language, containing well over one hundred individual libraries. The BH package provides a
sizeable subset of header-only libraries for (easier, no linking
required) use by R. It is fairly
widely used: the (partial) CRAN mirror logs (aggregated from the cloud
mirrors) show over 35.7 million package downloads.
Version 1.84.0 of Boost was released in December following the
regular Boost release schedule of April, August and December releases.
As the commits and changelog show, we packaged it almost immediately and
started testing following our annual update cycle which strives to
balance being close enough to upstream and not stressing CRAN and the
user base too much. The reverse depends check revealed five packages
requiring changes or adjustments which is a pretty good outcome given
the over three hundred direct reverse dependencies. So we opened issue #100 to
coordinate the issue over the winter break during which CRAN also closes
(just as we did in previous years). Our sincere thanks to the two
packages that already updated before, and to the one that updated today
within hours (!!) of the BH uploaded it needed.
There are very few actual changes. We honoured one request (in issue #97) to
add Boost
QVM bringing quarternion support to R. No other new changes needed to
be made. A number of changes I have to make each time in BH, and it is worth
mentioning them. Because CRAN cares about backwards compatibility and
the ability to be used on minimal or older systems, we still
adjust the filenames of a few files to fit a jurassic constraints of
just over a 100 characters per filepath present in some long-outdated
versions of tar. Not a big deal. We also, and that is more
controversial, silence a number of #pragma diagnostic
messages for g++ and clang++ because CRAN
insists on it. I have no choice in that matter. One warning we
suppressed last year, but no longer do, concerns the C++14 standard that
some Boost libraries now default to.
Packages setting C++11 explicitly will likely get a note from CRAN
changing this; in most cases that should be trivial to remove as we only
had to opt into (then) newer standards under old compilers. These days
newer defaults help; R itself now defaults to C++17.
Via my CRANberries, there
is a diffstat report relative to the previous
release. Comments and suggestions about BH are welcome via the issue
tracker at the GitHub
repo.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
I ve mentioned this in a
couple of
other
places, but I realized I never got round to posting about it on my own blog
rather than on other people s services. How remiss of me.
Anyway: after much soul-searching, I decided a few months ago that it was
time for me to move on from Canonical and the
Launchpad team there. Nearly 20 years is a long
time to spend at any company, and although there are a bunch of people I ll
miss, Launchpad is in a reasonable state where I can let other people have a turn.
I m now in business for myself as a freelance developer! My new company is
Columbiform, and I m focusing on Debian
packaging and custom Python development. My
services page has some
self-promotion on the sorts of things I can do.
My first gig, and the one that made it viable to make this jump, is at
Freexian where I m helping with an exciting
infrastructure project that we hope will start making Debian developers
lives easier in the near future. This is likely to take up most of my time
at least through to the end of 2024, but I may have some spare cycles.
Drop me a line if you have
something where you think I could be a good fit, and we can have a talk
about it.
Having had success running Trisquel on the ppc64 Talos II, I felt ready to get an arm64 machine running Trisquel. I have a Ampere Altra Developer Platform from ADLINK, which is a fairly powerful desktop machine. While there were some issues during installation, I m happy to say the machine is stable and everything appears to work fine.
ISO images for non-amd64 platforms are unfortunately still hidden from the main Trisquel download area, so you will have to use the following procedure to download and extract a netinst ISO image (using debian-installer) and write it to a USB memory device. Another unfortunate problem is that there are no OpenPGP signatures or hash checksums, but below I publish one checksum.
Insert the USB stick in a USB slot in the machine, and power up. Press ESCAPE at the BIOS prompt and select the USB device as the boot device. The first problem that hit me was that translations didn t work, I selected Swedish but the strings were garbled. Rebooting and selecting the default English worked fine. For installation, you need Internet connectivity and I use the RJ45 port closest to VGA/serial which is available as enP5p1s0 in the installer. I wouldn t connect the BMC RJ45 port to anything unless you understand the security implications.
During installation you have to create a EFI partition for booting, and I ended up with one 1GB EFI partition, one 512GB ext4 partition for / with discard/noatime options, and a 32GB swap partition. The installer did not know about any Trisquel mirrors, but only had the default archive.trisquel.org, so if you need to use a mirror, take a note of the necessary details. The installation asks me about which kernel to install, and I went with the default linux-generic which results in a 5.15 linux-libre kernel. At the end of installation, unfortunately grub failed with a mysterious error message: Unable to install GRUB in dummy. Executing 'grub-install dummy' failed. On another console there is a better error message: failed to register the EFI boot entry. There are some references to file descriptor issues. Perhaps I partitioned the disk in a bad way, or this is a real bug in the installer for this platform. I continued installation, and it appears the installer was able to write GRUB to the device, but not add the right boot menu. So I was able to finish the installation properly, and then reboot and manually type the following GRUB commands: linux (hd0,gpt2)/boot/vmlinuz initrd (hd0,gpt2)/boot/initrd.img boot. Use the GRUB ls command to find the right device. See images below for more information.
Booting and installing GRUB again manually works fine:
root@ampel:~# update-grub
Sourcing file /etc/default/grub'
Sourcing file /etc/default/grub.d/background.cfg'
Sourcing file /etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-91-generic
Found initrd image: /boot/initrd.img-5.15.0-91-generic
Found linux image: /boot/vmlinuz-5.15.0-58-generic
Found initrd image: /boot/initrd.img-5.15.0-58-generic
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
root@ampel:~#
During installation I tend to avoid selecting any tasksel components, in part because it didn t use a local mirror to gain network speed, and in part because I don t want to generate OpenSSH keys in a possibly outdated environment that is harder to audit and reproducible rebuild than the finally installed system. When I selected the OpenSSH and GNOME tasksel, I get an error, but fortunately using apt get directly is simple.
Graphics in GNOME was slow using the built-in ASPEED AST2500 VGA controller with linux-libre 5.15. There are kernels labeled 64k but I haven t tested them, and I m not sure they would bring any significant advantage. I simply upgraded to a more recent linux-libre 6.2 kernel via the linux-image-generic-hwe-11.0 virtual package. After a reboot, graphics in GNOME is usable.
There seems to be some issue with power-saving inside GNOME, since the machine becomes unresponsive after 20 minutes, and I m unable to make it resume via keyboard or power button. Disabling the inactivity power setting in GNOME works fine to resolve this.
I will now put this machine to some more heavy use and see how it handles it. I hope to find more suitable arm64-based servers to complement my ppc64el-based servers in the future, as this ADLINK Ampere Altra Developer Platform with liquid-cooling is more of a toy than a serious server for use in a datacentre.
Happy Trisquel-on-arm64 Hacking!
SAS and SATA are electrically compatible to a degree that allows connecting a SATA storage device to a SAS controller. The SAS controller understands the SATA protocol so this works. A SAS device can t be physically connected to a SATA controller and if you did manage to connect it then it wouldn t work.
Some SAS RAID controllers don t permit mixing SAS and SATA devices in the same array, this is a software issue and could be changed. I know that the PERC controllers used by Dell (at least the older versions) do this and it might affect many/most MegaRAID controllers (which is what PERC is).
If you have a hardware RAID array of SAS disks and one fails then you need a spare SAS disk and as the local computer store won t have any you need some on hand.
The Linux kernel has support for the MegaRAID/PERC superblocks so for at least some of the RAID types supported by MegaRAID/PERC you can just connect the disks to a Linux system and have it work (I ve only tested on JBOD AKA a single-disk RAID-0). So if you have a server from Dell or IBM or any other company that uses MegaRAID which fails you can probably just put the disks into a non-RAID SAS controller and have them work. As Linux doesn t care about the difference between SAS and SATA at the RAID level you could then add a SATA disk to an array of SAS disks. If you want to move an array from a dead Dell to a working IBM server or the other way around then you need it to be all SATA or all SAS. You can use a Linux system to mount an array used by Windows or any other OS and then migrate the data to a different array.
If you have an old array of SAS disks and one fails then it might be a reasonable option to just migrate the data to a new array of SATA SSDs. EG if you had 6*600G SAS disks you could move to 2*4TB SATA SSDs and get more storage, much higher performance, less power use, and less noise for a cost of $800 or so (you can spend more to get better performance) and some migration time.
Having a spare SAS controller for data recovery is convenient. Having a spare SAS disk for any RAID-5/RAID-6 is a good thing. Having lots of spare SAS disks probably isn t useful as migrating to SATA is a better choice. SATA SSDs are bigger and faster than most SAS disks that are in production. I m sure that someone uses SAS SSDs but I haven t yet seen them in production, if you have a SAS system and need the performance that SSDs can give then a new server with U.2 (the SAS equivalent of NVMe) is the way to go). SATA hard drives are also the solution for seriously large storage, 16TB SATA hard drives are cheap and work in all the 3.5 SAS systems.
It s hard to sell old SAS disks as there isn t much use for them.
The Rcpp Core Team is once again thrilled to announce a new release
1.0.12 of the Rcpp package. It
arrived on CRAN early today,
and has since been uploaded to Debian as well. Windows and macOS
builds should appear at CRAN in the next few days, as will builds in
different Linux distribution and of course at r2u should catch up
tomorrow. The release was uploaded yesterday, and run its reverse
dependencies overnight. Rcpp always
gets flagged nomatter what because the grandfathered
.Call(symbol) but we had not single change to worse
among over 2700 reverse dependencies!
This release continues with the six-months January-July cycle started
with release
1.0.5 in July 2020. As a reminder, we do of course make interim
snapshot dev or rc releases available via the Rcpp drat repo and strongly
encourage their use and testing I run my systems with these versions
which tend to work just as well, and are also fully tested against all
reverse-dependencies.
Rcpp has long established itself
as the most popular way of enhancing R with C or C++ code. Right now,
2791 packages on CRAN depend on
Rcpp for making analytical code go
faster and further, along with 254 in BioConductor. On CRAN, 13.8% of
all packages depend (directly) on Rcpp, and 59.9% of all compiled packages
do. From the cloud mirror of CRAN (which is but a subset of all CRAN
downloads), Rcpp has been downloaded
78.1 million times. The two published papers (also included in the
package as preprint vignettes) have, respectively, 1766 (JSS, 2011) and 292 (TAS, 2018)
citations, while the the book (Springer useR!,
2013) has another 617.
This release is incremental as usual, generally preserving existing
capabilities faithfully while smoothing our corners and / or extending
slightly, sometimes in response to changing and tightened demands from
CRAN or R standards.
The full list below details all changes, their respective PRs and, if
applicable, issue tickets. Big thanks from all of us to all
contributors!
Changes in
Rcpp release version 1.0.12 (2024-01-08)
Changes in Rcpp API:
Missing header includes as spotted by some recent tools were
added in two places (Michael Chirico in #1272 closing #1271).
Casts to avoid integer overflow in matrix row/col selections have
neem added (Aaron Lun #1281).
Three print format correction uncovered by R-devel were applied
with thanks to Tomas Kalibera (Dirk in #1285).
Correct a print format correction in the RcppExports glue code
(Dirk in #1288
fixing #1287).
The upcoming OBJSXP addition to R 4.4.0 is supported
in the type2name mapper (Dirk and I aki in #1293).
Changes in Rcpp Attributes:
Generated interface code from base R that fails under LTO is now
corrected (I aki in #1274 fixing a
StackOverflow issue).
Changes in Rcpp Documentation:
The caption for third figure in the introductory vignette has
been corrected (Dirk in #1277 fixing #1276).
A small formatting issue was correct in an Rd file as noticed by
R-devel (Dirk in #1282).
The Rcpp FAQ vignette has been updated (Dirk in #1284).
The Rcpp.bib file has been refreshed to current
package versions.
Changes in Rcpp Deployment:
The RcppExports file for an included test package has been updated
(Dirk in #1289).
Happy 2024!
DAIS have continued their programme of posthumous Coil remasters and re-issues.
Constant Shallowness Leads To
Evil
was remastered by Josh Bonati in 2021 and re-released in 2022 in a dizzying
array of different packaging variants. The original releases in 2000 had barely
any artwork, and given that void I think Nathaniel Young has done a great job
of creating something compelling.
I can t actually think of a meme with this GIF, that the internal 
As well as the collection and distribution of 
Apparently I got an 
Est aberta a inscri o de participantes e a
In 2022 I read a post on the fediverse by somebody who mentioned that
they had bought on a whim a cute tiny book years ago, and that it
had been a companion through hard times. Right now I can t find the
post, but it was pretty aaaaawwww.
At the same time, I had discovered Coptic binding, and I wanted to do
some exercise to let my hands learn it, but apparently there is a limit
to the number of notebooks and sketchbooks a person needs (I m not 100%
sure I actually believe this, but I ve heard it is a thing).
So I decided to start making minibooks with the intent to give them
away: I settled (mostly) on the A8 size, and used a combination of found
materials, leftovers from bigger projects and things I had in the Stash.
As for paper, I ve used a variety of the ones I have that are at the
very least good enough for non-problematic fountain pen inks.
Thanks to the small size, and the way coptic binding works, I ve been
able to play around with the covers, experimenting with different styles
beyond the classic bookbinding cloth / paper covered cardboard,
including adding lace, covering food box cardboard with gesso and
decorating it with acrylic paints, embossing designs by gluing together
two layers of cardboard, one of which has holes, making covers
completely out of cernit, etc. Some of these I will probably also use in
future full-scale projects, but it s nice to find out what works and
what doesn t on a small scale.
Now, after a year of sporadically making these I have to say that the
making went quite well: I enjoyed the making and the creativity in
making different covers. The giving away was a bit more problematic, as
I didn t really have a lot of chances to do so, so I believe I still
have most of them. In 2024 I ll try to look for more opportunities (and
if you live nearby and want one or a few feel free to ask!)
Version 0.0.16 of 
Like each month, have a look at the work funded by 
I think while developing Wayland-as-an-ecosystem we are now entrenched into narrow concepts of how a desktop should work. While discussing Wayland protocol additions, a lot of concepts clash, people from different desktops with different design philosophies debate the merits of those over and over again never reaching any conclusion (just as you will never get an answer out of humans whether sushi or pizza is the clearly superior food, or whether CSD or SSD is better). Some people want to use Wayland as a vehicle to force applications to submit to their desktop s design philosophies, others prefer the smallest and leanest protocol possible, other developers want the most elegant behavior possible. To be clear, I think those are all very valid approaches.
But this also creates problems: By switching to Wayland compositors, we are already forcing a lot of porting work onto toolkit developers and application developers. This is annoying, but just work that has to be done. It becomes frustrating though if Wayland provides toolkits with absolutely no way to reach their goal in any reasonable way. For Nate s Photoshop analogy: Of course Linux does not break Photoshop, it is Adobe s responsibility to port it. But what if Linux was missing a crucial syscall that Photoshop needed for proper functionality and Adobe couldn t port it without that? In that case it becomes much less clear on who is to blame for Photoshop not being available.
A lot of Wayland protocol work is focused on the environment and design, while applications and work to port them often is considered less. I think this happens because the overlap between application developers and developers of the desktop environments is not necessarily large, and the overlap with people willing to engage with Wayland upstream is even smaller. The combination of Windows developers porting apps to Linux and having involvement with toolkits or Wayland is pretty much nonexistent. So they have less of a voice.
I will also bring my two protocol MRs to their conclusion for sure, because as application developers we need clarity on what the platform (either all desktops or even just a few) supports and will or will not support in future. And the only way to get something good done is by contribution and friendly discussion.
The Rcpp Core Team is once again thrilled to announce a new release
1.0.12 of the