As regular readers would know, since I never stop banging on about it, I run Pwnedkeys, a service which finds and collates private keys which have been disclosed or are otherwise compromised. Until now, the only way to check if a key is compromised has been to use the Pwnedkeys API, which is not necessarily trivial for everyone. Starting today, that s changing. The next phase of Pwnedkeys is to start offering more user-friendly tools for checking whether keys being used are compromised. These will typically be web-based or command-line tools intended to answer the question is the key in this (certificate, CSR, authorized_keys file, TLS connection, email, etc) known to Pwnedkeys to have been compromised? .

Opening the Toolbox Available right now are the first web-based key checking tools in this arsenal. These tools allow you to:

1. Check the key in a PEM-format X509 data structure (such as a CSR or certificate);
2. Check the keys in an authorized_keys file you upload; and
3. Check the SSH keys used by a user at any one of a number of widely-used code-hosting sites.

Further planned tools include live checking of the certificates presented in TLS connections (for HTTPS, etc), SSH host keys, command-line utilities for checking local authorized_keys files, and many other goodies.

If You Are Intrigued By My Ideas and wish to subscribe to my newsletter, now you can! I m not going to be blogging every little update to Pwnedkeys, because that would probably get a bit tedious for readers who aren t as intrigued by compromised keys as I am. Instead, I ll be posting every little update in the Pwnedkeys newsletter. So, if you want to keep up-to-date with the latest and greatest news and information, subscribe to the newsletter.

Supporting Pwnedkeys All this work I m doing on my own time, and I m paying for the infrastructure from my own pocket. If you ve got a few dollars to spare, I d really appreciate it if you bought me a refreshing beverage. It helps keep the lights on here at Pwnedkeys Global HQ.

The final piece of my 5G (well, 4G) based based backup internet connection I needed to sort out was IPv6. While Three do support IPv6 in their network they only seem to enable it for certain devices, and the MC7010 is not one of those devices, even though it also supports IPv6. I use v6 a lot - over 50% of my external traffic, last time I looked. One suggested option was that I could drop the IPv6 Router Advertisements when the main external link went down, but I have a number of internal services that are only presented on v6 addresses so I needed to ensure clients in the house continued to have access to those. As it happens I ve used the Hurricane Electric IPv6 Tunnel Broker in the past, so my pass was re-instating that. The 5G link has a real external IPv4 address, and it s possible to update the endpoint using a simple HTTP GET. I added the following to my /etc/dhcp/dhclient-exit-hooks.d/modem-interface-route where we are dealing with an interface IP change: I needed some additional configuration to bring things up, so /etc/network/interfaces got the following, configuring the 6in4 tunnel as well as the low preference default route, and source routing via the 5g table, similar to IPv4: We need to deal with IPv4 changes in for the tunnel endpoint, so modem-interface-route also got: /etc/nftables.conf had to be taught to accept the 6in4 packets from the tunnel in the input chain: Finally, I had to engage in something I never thought I d deal with; IPv6 NAT. HE provide a /48, and my FTTP ISP provides me with a /56, so this meant I could do a nice stateless 1:1 mapping: This works. Mostly. The problem is that HE, not unreasonably, expect your IPv4 address to be pingable. And it turns out Three have some ranges that this works on, and some that it doesn t. Which means it s a bit hit and miss whether you can setup the tunnel. I spent a while trying to find an alternative free IPv6 tunnel provider with a UK endpoint. There s less call for them these days, so I didn t manage to find any that actually worked (or didn t have a similar pingable requirement). I did consider whether I wanted to end up with routes via a VM, as I described in the failover post, but looking at costings for VMs with providers who could actually give me an IPv6 range I decided the cost didn t make it worthwhile; the VM cost ended up being more than the backup SIM is costing monthly. Finally, it turns out happy eyeballs mostly means that when the 5G ends up on an IP that we can t setup the IPv6 tunnel on, things still mostly work. Browser usage fails over quickly and it s mostly my own SSH use that needs me to force IPv4. Purists will groan, but this turns out to be an acceptable trade-off for me, at present. Perhaps if I was seeing frequent failures the diverse routes approach to a VM would start to make sense, but for now I m pretty happy with the configuration in terms of having a mostly automatic backup link take over when the main link goes down.

Review: Lyorn, by Steven Brust

Series:	Vlad Taltos #17
Publisher:	Tor
Copyright:	2024
ISBN:	1-4668-8971-3
Format:	Kindle
Pages:	274

Lyorn is the 17th Vlad Taltos book and a direct sequel to 2014's Hawk. (Yes, actual main story progress!) You do not want to start reading here; you would be hopelessly confused. When this series is complete, I want to re-read the entire thing from the beginning and pick up more of the bits I missed the first time. Vlad is not, in fact, free to see his friends and get entangled in imperial politics again as I thought after Hawk. Despite the successes of that story, there is one remaining small problem: incredibly powerful magic users still want to kill him. His immediate solution is to shelter in a theater, since Draegaran theaters are well-known for their excellent magical shielding. This works well enough at first, but the theater is rehearsing a play about Draegaran politics that is highly offensive to the Lyorn and the theater may be shut down because of it. Vlad's enemies are also willing to lean on his friends to find him and kill him. This series continues to be thoroughly enjoyable. Lyorn is "just" more of Vlad being Vlad, meddling in everyone's business and coming up with elaborate plans with too many moving parts that he somehow manages to pull off, but I'll happily read lots of books like that. Vlad is both anxious and grumpy, both of which give the plot some needed tension without being overwhelming. There are no truly major world-building revelations here (or, if there are, I missed them), but there's a lot of processing of what the reader learned in Tsalmoth. It's increasingly looking like the payoff from those revelations is going to be the series finale. This is the first Vlad book that contains solid confirmation of where the series as a whole is headed. Brust mentioned some time ago that the last book is titled The Last Contract, and Lyorn comes close to stating explicitly what that contract will be. I am sure that it will be more complicated than it appears now and there are misdirections yet to come, but I am excited to see where Brust takes this idea. Vlad has been insistently apolitical for much of the series, meddling in politics only when he has to or to help his friends and otherwise treating it as a system that he has to navigate and survive. That was the root of the conflict in Teckla, all the way back at the start of the series. This may be starting to change, and when Brust ties it together with the Jenoine, the Great Weapon Godslayer, and the rest of the world-building he's cued up, the results are going to be explosive. Two books left: Chreotha and The Last Contract. I can hardly wait. In every Vlad book, Brust plays some sort of structural game. This time, befitting the setting, it's a musical. The action is interspersed with quotes from a fictional history about the play the theater is putting on, a work called Song of the Presses about political censorship during the reign of a Lyorn emperor in the 14th cycle, thousands of years before the time of this book. This was, at times, nearly as interesting as the main plot. The chapters are also numbered like the acts and scenes of a play, although this I didn't notice as much since books often have that structure anyway. Since this is a musical, there are also songs. Specifically, each chapter is introduced by a parody of songs from various musicals in our world, rewritten so that they fit within Brust's fictional musical. Brust is also a musician and a filker, so these songs are actually good, or at least they amused me a great deal. I'm not much of a musical fan and I still could hear the tune playing when I read most of them. Lyorn is not so good that I would rave about it. It's one of those functional connective books of a series that advances the plot, tells a good story, and has some fun along the way. The guns on the mantelpiece of this world have not gone off yet, and Vlad is still maneuvering into position. But it's looking like we're going to get the conclusion, and it's going to be spectacular. If you have read this far, you will want to keep reading. Followed by Chreotha, which may be a bit of a wait because apparently Brust is going to write The Last Contract first to make sure he ties up loose ends properly. Rating: 7 out of 10

My students at LIDSOL (Laboratorio de Investigaci n y Desarrollo de Software Libre, Free Software Research and Development Lab) at Facultad de Ingenier a, UNAM asked me to help them get the needed hardware to set up a mirror for various free software projects. We have some decent servers (not new servers, but mirrors don t require to be top-performance), so A couple of weeks ago, I approached the Debian Project Leader (DPL) and suggested we should buy two 16TBhard drives for this project, as it is the most reasonable cost per byte point I found. He agreed, and I bought the drives. Today we had a lab meeting, and I handed them over the hardware. Of course, they are very happy and thankful with the Debian project In the last couple of weeks, they have already set up an Archlinux mirror (https://archlinux.org/mirrors/fi-b.unam.mx), and now that they have heaps of storage space, plans are underway to set up various other mirrors (of course, a Debian mirror will be among the first).

I received a mail today from Google (noreply-findmydevice@google.com) notifying me that they would unconditionally enable the Find my device functionality I have been repeatedly marking as unwanted in my Android phone. The mail goes on to explain this functionality works even when the device is disconnected, by Bluetooth signals (aha, so turn off Bluetooth will no longer turn off Bluetooth? Hmmm ) Of course, the mail hand-waves that only I can know the location of my device. Google cannot see or use it for other ends . First, should we trust this blanket statement? Second, the fact they don t do it now means they won t ever? Not even if law enforcement requires them to? The devices will be generating this information whether we want it or not, so it s just a matter of opening the required window. Of course, it is a feature many people will appreciate and find useful. And it s not only for finding lost (or stolen) phones, but the mail also mentions tags can be made available to store in your wallet, bike, keys or whatever. But it should be opt-in. As it is, it seems it s not even to opt out of it.

A new FAI version was released and the FAIme service is using this new release. You can now also create installation images for Debian 13 (testing aka Trixie). https://fai-project.org/FAIme/ Another new feature of the FAIme service will be announced at DebConf24 in August.

This is a bug fix and minor feature release over INN 2.7.1, and the upgrade should be painless. You can download the new release from ISC or my personal INN pages. The latter also has links to the full changelog and the other INN documentation. For the full list of changes, see the INN 2.7.2 NEWS file. As always, thanks to Julien LIE for preparing this release and doing most of the maintenance work on INN!

The x13binary team is thrilled to share the availability of Release 1.1.61 of the x13binary package providing the X-13ARIMA-SEATS program by the US Census Bureau which arrived on CRAN earlier today. This release brings two updates suggested by the tireless CRAN maintainers. Kurt Hornik suggested to now also ignore stderr when calling the x13 binary via system: it appears that builds under the new-ish and clang-based flang-new now emit on stderr even if Fortran-based binaries did not before. So we adjust. And Brian Ripley pointed out that our Makefile for creating the x13 binary was not quite as is should be, which we adjusted. And I just realized I should have named this 1.1.60-2 to follow the upstream convention but didn t. Next time. Courtesy of my CRANberries, there is also a diffstat report for this release showing changes to the previous release. If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Release 0.6.36 of the digest package arrived at CRAN today and has also been uploaded to Debian. 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,crc32c, xxh3_64 and xxh3_128), and enables 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 69.1 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. This release updates one contributed C++ function to be compliant with R s revent preference for explicit declaration of REMAP, and improves the behavior under the (increasingly rare) big endian system via a patch to blake3 as well as a hint that spookyhash under big endian may not meed its reference output from little endian . My CRANberries provides a summary of changes to the previous version. For questions or comments use the issue tracker off the GitHub repo. For documentation (including the changelog) see the documentation site. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

IPv4 is an expensive resource. However, many content providers are still IPv4-only. The most common reason is that IPv4 is here to stay and IPv6 is an additional complexity.¹ This mindset may seem selfish, but there are compelling reasons for a content provider to enable IPv6, even when they have enough IPv4 addresses available for their needs.

Why ISPs need IPv6? Providing a public IPv4 address to each customer is quite costly when each IP address costs US$40 on the market. For fixed access, some consumer ISPs are still providing one IPv4 address per customer.² Other ISPs provide, by default, an IPv4 address shared among several customers. For mobile access, most ISPs distribute a shared IPv4 address. There are several methods to share an IPv4 address:³

NAT44

The customer device is given a private IPv4 address, which is translated to a public one by a service provider device. This device needs to maintain a state for each translation.

464XLAT and DS-Lite

The customer device translates the private IPv4 address to an IPv6 address or encapsulates IPv4 traffic in IPv6 packets. The provider device then translates the IPv6 address to a public IPv4 address. It still needs to maintain a state for the NAT64 translation.

Lightweight IPv4 over IPv6, MAP-E, and MAP-T

The customer device encapsulates IPv4 in IPv6 packets or performs a stateless NAT46 translation. The provider device uses a binding table or an algorithmic rule to map IPv6 tunnels to IPv4 addresses and ports. It does not need to maintain a state.

Solutions to share an IPv4 address across several customers. Some of them require the ISP to keep state, some don't.

All these solutions require a translation device in the ISP s network. This device represents a non-negligible cost in terms of money and reliability. As half of the top 1000 websites support IPv6 and the biggest players can deliver most of their traffic using IPv6,⁴ ISPs have a clear path to reduce the cost of translation devices: provide IPv6 by default to their customers.

Why content providers need IPv6? Content providers should expose their services over IPv6 primarily to avoid going through the ISP s translation devices. This doesn t help users who don t have IPv6 or users with a non-shared IPv4 address, but it provides a better service for all the others. Why would the service be better delivered over IPv6 than over IPv4 when a translation device is in the path? There are two main reasons for that:⁵

1. Translation devices introduce additional latency due to their geographical placement inside the network: it is easier and cheaper to only install these devices at a few points in the network instead of putting them close to the users.
2. Translation devices are an additional point of failure in the path between the user and the content. They can become overloaded or malfunction. Moreover, as they are not used for the five most visited websites, which serve their traffic over IPv6, the ISPs may not be incentivized to ensure they perform as well as the native IPv6 path.

Looking at Google statistics, half of the users reach Google over IPv6. Moreover, their latency is lower.⁶ In the US, all the nationwide mobile providers have IPv6 enabled. For France, we can refer to the annual ARCEP report: in 2022, 72% of fixed users and 60% of mobile users had IPv6 enabled, with projections of 94% and 88% for 2025. Starting from this projection, since all mobile users go through a network translation device, content providers can deliver a better service for 88% of them by exposing their services over IPv6. If we exclude Orange, which has 40% of the market share on consumer fixed access, enabling IPv6 should positively impact more than 55% of fixed access users.

---

In conclusion, content providers aiming for the best user experience should expose their services over IPv6. By avoiding translation devices, they can ensure fast and reliable content delivery. This is crucial for latency-sensitive applications, like live streaming, but also for websites in competitive markets, where even slight delays can lead to user disengagement.

---

1. A way to limit this complexity is to build IPv6 services and only provide IPv4 through reverse proxies at the edge.
2. In France, this includes non-profit ISPs, like FDN and Milkywan. Additionally, Orange, the previously state-owned telecom provider, supplies non-shared IPv4 addresses. Free also provides a dedicated IPv4 address for customers connected to the point-to-point FTTH access.
3. I use the term NAT instead of the more correct term NAPT. Feel free to do a mental substitution. If you are curious, check RFC 2663. For a survey of the IPv6 transition technologies enumerated here, have a look at RFC 9313.
4. For AS 12322, Google, Netflix, and Meta are delivering 85% of their traffic over IPv6. Also, more than half of our traffic is delivered over IPv6.
5. An additional reason is for fighting abuse: blacklisting an IPv4 address may impact unrelated users who share the same IPv4 as the culprits.
6. IPv6 may not be the sole reason the latency is lower: users with IPv6 generally have a better connection.

I wrote about my blog writing methodology back April 2021. My writing method has undergone a significant shift now, so thought about writing this update. New blog topics are added to my note-taking app quite frequently now. Occasionally going through the list, I merge topics, change order to prioritize certain topics or purely drop ideas which seems not worth a write-up. Due to this, I have the liberty to work on blogs according to mood. Writing the last one was tiring, so I chose to work on an easy one, i.e. this blog now. Topic decided, everything starts on etherpad now. Etherpad has this nice font and sync feature, which helps me write from any device of choice. Actual writing usually happens in the morning, right after I wake up. For most topics, I quickly jot down pointers and keep on expanding them over the course of multiple days at a leisurely pace. Though, sometime it adds too many pieces in the puzzle and takes additional time to put everything in flow. New pointer addition keeps on happening along with writing. Nowadays, pictures too dot my blog, which I rarely use to do earlier. I have come to believe on less usage of external links. These breaks the flow of readers. If someone is sufficiently motivated to learn more about something, finding useful sources isn t. As the first draft comes into being, I run it through LanguageTool for spelling corrections (which typically are many) and fixing grammatical issues. Post that, for the first time I read the complete write-up in one go for formation of coherent storyline, moving paragraphs around for form a structure , adding explainers wherever something new or unexplained is introduced, removing elaborate sentences, making amends wherever required and moving paragraphs around for forming structure. Another round of LanguageTool follows. All set now, I try to space out my final read before publishing, which helps find additional mistakes or loopholes. When everything is set, I do hugo to generate the site and rsync everything to the web server. A final git sync closes the publication part. After a day or two, I come back to read the blog on the website. This entails another round finding and fixing trivial mistakes. After this, it s set for good. Nowadays, in addition to being on my blog, everything is syndicated on Planet FSCI and Planet Debian, which has given it more visibility. As someone who s into infrastructure and Internet as a lot, I do pay attention to logs on my server, but as a disconnected exercise to if the blog is being read or not. More hits on the blog doesn t translate to any gratification for me, at least for writers point of view. Occasionally, people do mention my blog, which does flatter me. Four years and nearly a hundred posts later, I still wonder how I kept on writing for this long.

I let go my domain abhijithpa.me. It was getting expensive and I don t fancy that anymore. I never actually purchased this domain but came with a package offer. I then kept it for couple of years. I have now bought a new domain abhijithpa.in and pointed everything to it. So if you are seeing abhijithpa.me with lot of contents, that is no me. Its either domain squatters or someone impersonating me.

I let go my domain abhijithpa.me. It was getting expensive and I don t fancy that anymore. I never actually purchased this domain but came with a package offer. I then kept it for couple of years. I have now bought a new domain abhijithpa.in and pointed everything to it. So if you are seeing abhijithpa.me with lot of contents, that is no me. Its either domain squatters or someone impersonating me.

Review: And the Stars Will Sing, by Michelle Browne

Series:	The Meaning Wars #1
Publisher:	Michelle Browne
Copyright:	2012, 2021
Printing:	2021
ASIN:	B0075G7GEA
Format:	Kindle
Pages:	85

And the Stars Will Sing is a self-published science fiction novella, the first of a (currently) five book series. I believe it may be Browne's first publication, although I don't have a good data source to confirm. Crystal Weiss is a new graduate from Mars, about to leave the solar system to her first job assignment: installation of a permanent wormhole in the vicinity of Messier 14. Her expertise is the placement calculations. The heavy mathematical lifting is of course done by computers, but humans have to do the mapping and some of the guidance. And the Stars Will Sing is an epistolary novel, told in the form of her letters to her friend Sarah. I feel bad when I stumble across a book like this. I want to stick with my habit of writing a review of each book I read, but it's one thing to pan a bad book by a famous author and another thing to pick on a self-published novella that I read due to some recommendation or mention whose details I've forgotten. Worse, I think this wasn't even the recommended book; I looked up the author, saw that the first of a series was on sale, and thought "oh, hey, I like epistolary novels and I'm in the mood for some queer space opera." This book didn't seem that queer (there is a secondary lesbian relationship but the main relationship seemed rather conventional), but I'll get to the romance in a moment. I was not the reader for this book. There's a reason why most of the books I read are from traditional publishers; I'm too critical of a reader for a lot of early self-published work. It's not that I dislike self-publishing as a concept many self-published books are excellent and the large publishers have numerous problems but publishers enforce a quality bar. Inconsistently, unfairly, and by rejecting a lot of good work, but still, they do. I'm fairly sure traditional publishers would have passed on this book; the quality of the writing isn't there yet. (It's certainly a better book than I could have written! But that's why I'm writing my reviews over in my quiet corner of the Internet and not selling fiction to other people.) The early chapters aren't too bad, although they have a choppy, cliched style that more writing experience usually smoothes out. The later chapters have more dialogue, enough that I started wondering how Crystal could remember that much dialogue verbatim to put into a letter, and it's not good. All of the characters talk roughly the same (even the aliens), the dialogue felt even more cliched than the rest of the writing, and I started getting distracted by the speech tags. Crystal comes across as very young, impulsive, and a drama magnet who likes being all up in her coworkers' business. None of these are objective flaws in the book, but I could tell early on that I was going to find her annoying. She has a heavily-foreshadowed enemies-to-lovers thing with one of her male coworkers. Her constant complaining about him at the start of the story was bad enough, but the real problem is that in the very few places where he has more personality than plastic lawn furniture, he's being obnoxious to Crystal. I'm used to being puzzled by a protagonist's choice in love interests, but this one felt less like an odd personality choice and more a lack of writing skill. Even if the relationship is being set up for failure (not true by the end of this book), you've got to help me understand what the protagonist saw in him or was getting out of the relationship. The plot was so predictable that it ironically surprised me. I was sure that some sort of twist or complication was coming, but no. I will give Browne some credit for writing a slightly more realistic character reaction to violence than most SF authors, but there was nothing in the plot to hold my interest. The world-building was generic science fiction with aliens. It had a few glimmers of promise, but there was some sort of psychic hand-waving involved in siting wormholes that didn't work for me and the plot climax made no sense to me whatsoever. This is the kind of bad book that I don't want to hold against the writer. Twelve years later and with numerous other novels and novellas under her belt, her writing is probably much better. I do think this book would have benefited from an editor telling her it wasn't good enough for publication yet, but that's not how the Kindle self-publishing world works. Mostly, this is my fault: I half-followed a recommendation into an area of publishing that I know from past experience I should avoid without a solid review from an equally critical reader. Followed by The Stolen, a two-story collection. Rating: 3 out of 10

A quick bug fix release 0.3.9 for our nanotime package is now on CRAN, following up on the 0.3.8 release made this week. nanotime relies on the RcppCCTZ package (as well as the RcppDate package for additional C++ operations) and offers efficient high(er) resolution time parsing and formatting up to nanosecond resolution, using the bit64 package for the actual integer64 arithmetic. Initially implemented using the S3 system, it has benefitted greatly from a rigorous refactoring by Leonardo who not only rejigged nanotime internals in S4 but also added new S4 types for periods, intervals and durations. The 0.3.8 release added a accurate parameter for POSIXct conversions, and it turns out that this did not test as expected on arm64 so we disabled the test on that platform. The NEWS snippet below has the full details.

Changes in version 0.3.9 (2024-06-21)

• Condition two tests to not run on arm64 (Dirk in #129 fixing #128)

Thanks to my CRANberries, there is a diffstat report for this release. More details and examples are at the nanotime page; code, issue tickets etc at the GitHub repository and all documentation is provided at the nanotime documentation site. If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Chaque dition de Debian b n ficie d'un nouveau th me brillant visible sur l' cran d'amor age, l' cran de connexion et, de la fa on la plus vidente, sur le fond d' cran. Debian pr voit de publier Trixie, sa prochaine version, durant l'ann e venir. Et, comme toujours, nous avons besoin de vous pour cr er son th me ! Vous avez l'occasion de concevoir un th me qui inspirera des milliers de personnes quand ils travaillent sur leur machine Debian. Pour disposer des d tails les plus r cents, veuillez vous r f rer la page du wiki. Nous voudrions profiter de cette occasion pour remercier Juliette Taka Belin pour avoir cr le th me Emerald pour Bookworm. La date limite pour les propositions est le 19 septembre 2024. Le th me est habituellement choisi en se basant sur ce qui para t le plus :

• Debian : il est vrai que ce n'est pas le concept le mieux d fini, dans la mesure o chacun a son sentiment sur ce que repr sente Debian pour eux ;
• possible int grer sans corriger le logiciel de base : autant nous aimons les th mes follement excitants, certains n cessiteraient un gros travail d'adaptation des th mes GTK+ et la correction de GDM/GNOME ;
• clair et bien con u : sans tre quelque chose qui devient ennuyeux regarder au bout d'un an. Parmi les bons th mes, on peut citer Joy, Lines, Softwaves et futurePrototype.

Si vous souhaitez disposer plus d'informations, veuillez utiliser la liste de diffusion Debian Desktop.

Shortly before coming back from Argentina, I got news of a very interesting set of little machines, the MilkV Duo. The specs looked really interesting and fun to play with, particularly those of the bigger model, Milk-V DUO S Some of the highlights:

• The SG2000 SoC is a Dual-architecture beast. A hardware switch controls whether the CPU is an ARM or a RISC-V.
  • Not only that: It has a second (albeit lesser) RISC-V core that can run independently. They mention this computer can run simultaneously Linux and FreeRTOS!
• 512MB RAM
• Sweet form factor (4.2 4.2cm)
• Peeking around their Web site, it is one of the most open and well documented computers in their hardware range.
  • Schematics at different levels of detail
  • Datasheet. It s preliminary, and it s written in Mandarin, but the information it contains is quite descriptive and clear.
  • Full specifications (all 710 pages of it!) Again, it has a lot of Mandarin in it, but it conveys a lot of useful information.

Naturally, for close to only US$12 (plus shipping) for the configuration I wanted I bought one, and got it delivered in early May. The little box sat on my desk for close to six weeks until I had time to start tinkering with it I must say I am surprised. Not only the little bugger delivers what it promises, but it is way more mature than what I expected: It can be used right away without much tinkering with! I mean, I have played with it for less than an hour by now, and I ve even managed to get (almost) regular Debian working. Milk-V distributes a simple, 58.9MB compressed Linux image, based on Buildroot, a simple Linux image generator mostly used for embedded applications, as well as its source tree. I thought that would be a good starting point to work on setting up a minimal Debian filesystem, as I did with the CuBox-i4Pro ten years ago, and maybe even to grow towards a more official solution, akin to what we currently have for the Raspberry Pi family Until I discovered what looks like a friendly and very active online community of Milk-V users! I haven t yet engaged in it, but I stumbled across a thread announcing the availability of Debian images for the Milk-V family. And yes, it feels like a very normal Debian system. /etc/apt/sources.list does point to a third-party repository, but it s for only four packages, all related to pinmux controlfor CVITEK chips. It does feel like a completely normal Debian system! It is not as snappy and fast to load as Buildroot, but given Debian s generality, that s completely as expected. Even the wireless network, one of the usual pain points, works just out of the box! The Debian images can be built or downloaded from this Git repository. In case you wonder how is this system booting or what hardware it detects, I captured two boot logs:

• Milk- Duo S booting with Buildroot (24K)
• Milk- Duo S booting with Debian (49K)

Hello folks, I ve been working this year on better integrating NVIDIA hardware with the Google Cloud Dataproc product (Hadoop on Google Cloud) running the default cluster node image. We have an open bug[1] in the initialization-actions repo regarding creation failures upon enabling secure boot. This is because with secure boot, kernel driver code has its signature verified before insmod places the symbols into kernel memory. The verification process involves reading trust root certificates from EFI variables, and validating that the signatures on the kernel driver either a) were made directly by one of the certificates in the boot sector or b) were made by certificates which chain up to one of them. This means that Dataproc disk images must have a certificate installed into them. My work on the internals will likely start producing images which have certificates from Google in them. In the meantime, however, our users are left without a mechanism to have both secure boot enabled and install out-of-tree kernel modules such as the NVIDIA GPU drivers. To that end, I ve got PR #83[2] open with the GoogleCloudDataproc/custom-images github repository. This PR introduces a new argument to the custom image creation script, trusted-cert , the argument of which is the path to a DER-encoded certificate to be included in the certificate database in the EFI variables of the disk s boot sector. I ve written up the instructions on creating a custom image with a trusted certificate here: https://github.com/cjac/custom-images/blob/secure-boot-custom-image/examples/secure-boot/README.md Here is a set of commands that can be used to create a Dataproc custom image with certificate installed to the EFI s db variable. You can run these commands from the root directory of a checkout such as this:

git clone https://github.com/cjac/custom-images.git --branch secure-boot-custom-image --single-branch
pushd custom-images
PROJECT_ID=your-project-here
PROJECT_NUMBER=your-project-nnnn-here
my_bucket=your-bucket-here
custom_image_zone=your-zone-here
gcloud projects add-iam-policy-binding $ PROJECT_ID  \
        --member=serviceAccount:$ PROJECT_NUMBER -compute@developer.gserviceaccount.com \
        --role=roles/secretmanager.secretAccessor
gcloud config set project $ PROJECT_ID 
gcloud auth login
eval $(bash examples/secure-boot/create-key-pair.sh)
metadata="public_secret_name=$ public_secret_name "
metadata="$ metadata ,private_secret_name=$ private_secret_name "
metadata="$ metadata ,secret_project=$ secret_project "
metadata="$ metadata ,secret_version=$ secret_version "
#dataproc_version=2.1-debian11
dataproc_version=2.2-debian12
#customization_script=examples/secure-boot/install-nvidia-driver-debian11.sh
customization_script=examples/secure-boot/install-nvidia-driver-debian12.sh
#image_name="nvidia-open-kernel-bullseye-$(date +%F)"
image_name="nvidia-open-kernel-bookworm-$(date +%F)"
disk_size_gb="50"
python generate_custom_image.py \
    --image-name $ image_name  \
    --dataproc-version $ dataproc_version  \
    --trusted-cert "tls/db.der" \
    --customization-script $ customization_script  \
    --metadata "$ metadata " \
    --zone "$ custom_image_zone " \
    --disk-size "$ disk_size_gb " \
    --no-smoke-test \
    --gcs-bucket "$ my_bucket "
popd

I d love to hear your feedback! [1] https://github.com/GoogleCloudDataproc/initialization-actions/issues/1058
[2] https://github.com/GoogleCloudDataproc/custom-images/pull/83

esptool, the Espressif SoC serial bootloader utility, tends to dislike cheap Flash chips attached to the various incarnations of the ESP32 chip family. And it seems to dislike them even more when running esptool on Linux than on other OSs. The common error mode is seeing it break at the 2MB barrier when trying to dump (esptool read_flash) a 4MB flash configuration. will fail with

esptool.py v4.7.0
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
[..]
Detected flash size: 4MB
[..]
2097152 (50 %)
A fatal error occurred: Failed to read flash block (result was 01090000: CRC or checksum was invalid)

typically at the 2MB barrier. I found the solution in a rather unrelated esptool Github issue: Create an esptool.cfg file in the project directory (from where you will run esptool): The timeout = 30 is the setting that fixed reading flash memory via esptool read_flash for me. When your esptool.cfg is read, esptool will tell you so in its second line of output:

esptool.py v4.7.0
Loaded custom configuration from /home/dl/[..]/Embedded_dev/ESP-32_Wemos/esptool.cfg
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting......
[..]

Thank you Radim Karnis and wibbit from the Github issue linked above.

Leonardo and I are happy to annunce that a new version 0.3.8 of our nanotime package arrived on CRAN today. It is the first release in over 1 1/2 years. nanotime relies on the RcppCCTZ package (as well as the RcppDate package for additional C++ operations) and offers efficient high(er) resolution time parsing and formatting up to nanosecond resolution, using the bit64 package for the actual integer64 arithmetic. Initially implemented using the S3 system, it has benefitted greatly from a rigorous refactoring by Leonardo who not only rejigged nanotime internals in S4 but also added new S4 types for periods, intervals and durations. This release responds to a number of enhancements including a new paramter accurate for POSIXct to nanotime conversions, a vector date converter, a switch to double return value when durations objects are dividded as well as a small battery of CRAN requests for changes and updates. This started with a move away from the now non-API function SET_S4_OBJECT which has been replaced by use of Rf_asS4. We also no longer need a custom compiler flag on Windows (where for some reasons nobody understands or remembers, bitfields are not packed) to small enhancements of manual page formatting and last-but-not-least avoidance of some new UBSAN warnings. The NEWS snippet has the full details.

Changes in version 0.3.8 (2024-06-19)

• Time format documentation now has a reference to RcppCCTZ
• The package no longer sets a default C++ compilation standard of C++11 (Dirk initially in #114, and later switched to C++17)
• New accurate parameter for conversion from POSIXct to nanotime (Davor Josipovic and Leonardo in #116 closing #115)
• The as.Date() function is now vectorized and can take a TZ argument (Leonardo and Dirk in #119 closing #118)
• Use of internal function SET_S4_OBJECT has been replaced by API function Rf_asS4 (Leonardo in #121 closing #120)
• An nanoduration / nanoduration expression now returns a double (Leonardo in #122 closing #117)
• Bitfield calculations no longer require an Windows-only compiler switch (Leonardo in #124)
• A simple manual page format nag involving has been addressed (Dirk in #126 fixing #125)
• An set of tests tickling an UBSAN issue via Rcpp code no longer run unless CI is set (Dirk in #127 fixing #123)

Thanks to my CRANberries, there is a diffstat report for this release. More details and examples are at the nanotime page; code, issue tickets etc at the GitHub repository and all documentation is provided at the nanotime documentation site. If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.