Update: thanks to the very kind involvment of the widow of our wemaster, we could provide enough private information to Dreamhost, who finally accepted to reset the password and the MFA. We have recovered evrything! Many thanks to everybody who helped us! Due to tragic circumstances, one association that I am part of, Sciencescope got locked out of its account at Dreamhost. Locked out, we can not pay the annual bill. Dreamhost contacted us about the payment, but will not let us recover the access to our account in order to pay. So they will soon close the account. Our website, mailing lists and archives, will be erased. We provided plenty of evidence that we are not scammers and that we are the legitimate owners of the account, but reviewing it is above the pay grade of the custommer support (I don't blame them) and I could not convince them to let somebody higher have a look at our case. If you work at Dreamhost and want to keep us as custommers instead of kicking us like that, please ask the support service in charge of ticket 225948648 to send the recovery URL to the secondary email adddresses (the ones you used to contact us about the bill!) in addition to the primary one (which nobody will read anymore). You can encrypt it for my Debian Developer key 73471499CC60ED9EEE805946C5BD6C8F2295D502 if you worry it gets in wrong hands. If you still have doubts I am available for calls any time. If you know somebody working at Dreamhost can you pass them the message? This would be a big, big, relief for our non-profit association.

Today I stumbled upon this youtube video which takes a retrocomputing look at a product I was involved in creating in 1999. It was fascinating looking back at it, and I realized I've never written down how this boxed set of Debian "slink and a half", an unofficial Debian release, came to be. As best I can remember, the CD in that box was Debian 2.1 ("slink") with the linux kernel updated from 2.0 to 2.2. Specifically, it used VA Linux Systems's patched version of the kernel, which supported their hardware better, but also 2.2 generally supported a lot of hardware much better than 2.0. There were some other small modifications that got rolled back into Debian 2.2. I mostly remember updating the installer to support that kernel, and building CD images. Probably over the course of a few weeks. This was the first time I worked on the (old) Debian installer, and the first time I built a Debian CD. I also edited the O'Rielly book that was included in the boxed set. It was wild when pallet loads of these boxed sets showed up. I think they sold for $19.95 at Fry's, although VA Linux Systems also gave lots of them away at conferences.

---

Watching the video of the installation, I was struck again and again by pain points, which the video does a good job of highlighting. It was a guided tour of everything about Debian that I wanted to fix in 1999. At each pain point I remembered how we fixed it, often years later, after considerable effort. I remembered how the old installer (the boot-floppies) was mostly moribund with only a couple people able and willing to work on it at all. (The video is right to compare its partitioning with old Linux installers from the early 90's because it was a relic from that era!) I remembered designing a new Debian installer that was more modular so more people could get invested in maintaining smaller pieces of it. It was yes, a second system, and developed too slowly, but was intended to withstand the test of time. It mostly has, since it's used to this day. I remembered how partitioning got automated in new Debian installer, by a new "partman" program being contributed by someone I'd never heard of before, obsoleting some previous attempts we'd made (yay modularity). I remembered how I started the os-prober project, which lets the Debian installer add other OS's that are co-installed on the machine to the boot menu. And how that got picked up even outside of Debian, by eg Red Hat. I remembered working on tasksel soon after that project was started, and all the difficult decisions about what tasks to offer and what software it should install. I remembered how the horrible stream of questions from package after package was to deal with, and how I implemented debconf, which tidied that up, integrated it into the installer's UI, made it automatable, and let novices avoid seeing configuration that was intended for experts. And I remembered writing dpkg-reconfigure, so that those configuration choices could be revisited later. It's quite possible I would not have done most of that if VA Linux Systems had not tasked me with making this CD. The thing about releasing something imperfect into the world is you start to feel a responsibility to improve it...

---

The main critique in the video specific to this boxed set and not to any other Debian release of this era is that this was a single CD, while 2 CDs were needed for all of Debian at the time. And many people had only dialup internet, so would be stuck very slowly downloading any other software they needed. And likewise those free forever upgrades the box promised. Oh the irony: After starting many of those projects, I left VA Linux Systems and the lands of fast internet, and spent 4 years on dialup. Most of that stuff was developed on dialup, though I did have about a year with better internet at the end to put the finishing touches in the new installer that shipped in Debian 3.1. Yes, the dialup apt-gets were excruciatingly slow. But the upgrades were in fact, free forever.

---

PS: The video's description includes "it would take many years of effort (primarily from Ubuntu) that would help smooth out many of the rough end of this product". All these years later, I do continue to enjoy people involved in Ubuntu downplaying the extent that it was a reskin of my Debian installer shipped on a CD a few months before Debian could get around to shipping it. Like they say, history doesn't repeat, but it does rhyme. PPS: While researching this blog post, I found an even more obscure, and broken, Debian CD was produced by VA Linux in November 1999. Distributed for free at Comdex by the thousands, this CD lacked the Packages file that is necessary for apt-get to use it. I don't know if any versions of that CD still exist. If you find one, email me and I'll send some instructions I wrote up in 1999 to work around the problem.

It s been quite a few months since the most recent updates about Flathub last year. We ve been busy behind the scenes, so I d like to share what we ve been up to at Flathub and why and what s coming up from us this year. I want to focus on:

• Where Flathub is today as a strong ecosystem with 2,000 apps
• Our progress on evolving Flathub from a build service to an app store
• The economic barrier to growing the ecosystem, and its consequences
• What s next to overcome our challenges with focused initiatives

Today Flathub is going strong: we offer 2,000 apps from over 1,500 collaborators on GitHub. We re averaging 700,000 app downloads a day, with 898 million HTTP requests totalling 88.3 TB served by our CDN each day (thank you Fastly!). Flatpak has, in my opinion, solved the largest technical issue which has held back the mainstream growth and acceptance of Linux on the desktop (or other personal computing devices) for the past 25 years: namely, the difficulty for app developers to publish their work in a way that makes it easy for people to discover, download (or sideload, for people in challenging connectivity environments), install and use. Flathub builds on that to help users discover the work of app developers and helps that work reach users in a timely manner. Initial results of this disintermediation are promising: even with its modest size so far, Flathub has hundreds of apps that I have never, ever heard of before and that s even considering I ve been working in the Linux desktop space for nearly 20 years and spent many of those staring at the contents of dselect (showing my age a little) or GNOME Software, attending conferences, and reading blog posts, news articles, and forums. I am also heartened to see that many of our OS distributor partners have recognised that this model is hugely complementary and additive to the indispensable work they are doing to bring the Linux desktop to end users, and that having more apps available to your users is a value-add allowing you to focus on your core offering and not a zero-sum game that should motivate infighting. Ongoing Progress Getting Flathub into its current state has been a long ongoing process. Here s what we ve been up to behind the scenes: Development Last year, we concluded our first engagement with Codethink to build features into the Flathub web app to move from a build service to an app store. That includes accounts for users and developers, payment processing via Stripe, and the ability for developers to manage upload tokens for the apps they control. In parallel, James Westman has been working on app verification and the corresponding features in flat-manager to ensure app metadata accurately reflects verification and pricing, and to provide authentication for paying users for app downloads when the developer enables it. Only verified developers will be able to make direct uploads or access payment settings for their apps. Legal So far, the GNOME Foundation has acted as an incubator and legal host for Flathub even though it s not purely a GNOME product or initiative. Distributing software to end users along with processing and forwarding payments and donations also has a different legal profile in terms of risk exposure and nonprofit compliance than the current activities of the GNOME Foundation. Consequently, we plan to establish an independent legal entity to own and operate Flathub which reduces risk for the GNOME Foundation, better reflects the independent and cross-desktop interests of Flathub, and provides flexibility in the future should we need to change the structure. We re currently in the process of reviewing legal advice to ensure we have the right structure in place before moving forward. Governance As Flathub is something we want to set outside of the existing Linux desktop and distribution space and ensure we represent and serve the widest community of Linux users and developers we ve been working on a governance model that ensures that there is transparency and trust in who is making decisions, and why. We have set up a working group with myself and Mart n Abente Lahaye from GNOME, Aleix Pol Gonzalez, Neofytos Kolokotronis, and Timoth e Ravier from KDE, and Jorge Castro flying the flag for the Flathub community. Thanks also to Neil McGovern and Nick Richards who were also more involved in the process earlier on. We don t want to get held up here creating something complex with memberships and elections, so at first we re going to come up with a simple/balanced way to appoint people into a board that makes key decisions about Flathub and iterate from there. Funding We have received one grant for 2023 of $100K from Endless Network which will go towards the infrastructure, legal, and operations costs of running Flathub and setting up the structure described above. (Full disclosure: Endless Network is the umbrella organisation which also funds my employer, Endless OS Foundation.) I am hoping to grow the available funding to $250K for this year in order to cover the next round of development on the software, prepare for higher operations costs (e.g., accounting gets more complex), and bring in a second full-time staff member in addition to Bart omiej Piotrowski to handle enquiries, reviews, documentation, and partner outreach. We re currently in discussions with NLnet about funding further software development, but have been unfortunately turned down for a grant from the Plaintext Group for this year; this Schmidt Futures project around OSS sustainability is not currently issuing grants in 2023. However, we continue to work on other funding opportunities. Remaining Barriers My personal hypothesis is that our largest remaining barrier to Linux desktop scale and impact is economic. On competing platforms mobile or desktop a developer can offer their work for sale via an app store or direct download with payment or subscription within hours of making a release. While we have taken the time to first download time down from months to days with Flathub, as a community we continue to have a challenging relationship with money. Some creators are lucky enough to have a full-time job within the FLOSS space, while a few superstar developers are able to nurture some level of financial support by investing time in building a following through streaming, Patreon, Kickstarter, or similar. However, a large proportion of us have to make do with the main payback from our labours being a stream of bug reports on GitHub interspersed with occasional conciliatory beers at FOSDEM (other beverages and events are available). The first and most obvious consequence is that if there is no financial payback for participating in developing apps for the free and open source desktop, we will lose many people in the process despite the amazing achievements of those who have brought us to where we are today. As a result, we ll have far fewer developers and apps. If we can t offer access to a growing base of users or the opportunity to offer something of monetary value to them, the reward in terms of adoption and possible payment will be very small. Developers would be forgiven for taking their time and attention elsewhere. With fewer apps, our platform has less to entice and retain prospective users. The second consequence is that this also represents a significant hurdle for diverse and inclusive participation. We essentially require that somebody is in a position of privilege and comfort that they have internet, power, time, and income not to mention childcare, etc. to spare so that they can take part. If that s not the case for somebody, we are leaving them shut out from our community before they even have a chance to start. My belief is that free and open source software represents a better way for people to access computing, and there are billions of people in the world we should hope to reach with our work. But if the mechanism for participation ensures their voices and needs are never represented in our community of creators, we are significantly less likely to understand and meet those needs. While these are my thoughts, you ll notice a strong theme to this year will be leading a consultation process to ensure that we are including, understanding and reflecting the needs of our different communities app creators, OS distributors and Linux users as I don t believe that our initiative will be successful without ensuring mutual benefit and shared success. Ultimately, no matter how beautiful, performant, or featureful the latest versions of the Plasma or GNOME desktops are, or how slick the newly rewritten installer is from your favourite distribution, all of the projects making up the Linux desktop ecosystem are subdividing between ourselves an absolutely tiny market share of the global market of personal computers. To make a bigger mark on the world, as a community, we need to get out more. What s Next? After identifying our major barriers to overcome, we ve planned a number of focused initiatives and restructuring this year: Phased Deployment We re working on deploying the work we have been doing over the past year, starting first with launching the new Flathub web experience as well as the rebrand that Jakub has been talking about on his blog. This also will finally launch the verification features so we can distinguish those apps which are uploaded by their developers. In parallel, we ll also be able to turn on the Flatpak repo subsets that enable users to select only verified and/or FLOSS apps in the Flatpak CLI or their desktop s app center UI. Consultation We would like to make sure that the voices of app creators, OS distributors, and Linux users are reflected in our plans for 2023 and beyond. We will be launching this in the form of Flathub Focus Groups at the Linux App Summit in Brno in May 2023, followed up with surveys and other opportunities for online participation. We see our role as interconnecting communities and want to be sure that we remain transparent and accountable to those we are seeking to empower with our work. Whilst we are being bold and ambitious with what we are trying to create for the Linux desktop community, we also want to make sure we provide the right forums to listen to the FLOSS community and prioritise our work accordingly. Advisory Board As we build the Flathub organisation up in 2023, we re also planning to expand its governance by creating an Advisory Board. We will establish an ongoing forum with different stakeholders around Flathub: OS vendors, hardware integrators, app developers and user representatives to help us create the Flathub that supports and promotes our mutually shared interests in a strong and healthy Linux desktop community. Direct Uploads Direct app uploads are close to ready, and they enable exciting stuff like allowing Electron apps to be built outside of flatpak-builder, or driving automatic Flathub uploads from GitHub actions or GitLab CI flows; however, we need to think a little about how we encourage these to be used. Even with its frustrations, our current Buildbot ensures that the build logs and source versions of each app on Flathub are captured, and that the apps are built on all supported architectures. (Is 2023 when we add RISC-V? Reach out if you d like to help!). If we hand upload tokens out to any developer, even if the majority of apps are open source, we will go from this relatively structured situation to something a lot more unstructured and we fear many apps will be available on only 64-bit Intel/AMD machines. My sketch here is that we need to establish some best practices around how to integrate Flathub uploads into popular CI systems, encouraging best practices so that we promote the properties of transparency and reproducibility that we don t want to lose. If anyone is a CI wizard and would like to work with us as a thought partner about how we can achieve this make it more flexible where and how build tasks can be hosted, but not lose these cross-platform and inspectability properties we d love to hear from you. Donations and Payments Once the work around legal and governance reaches a decent point, we will be in the position to move ahead with our Stripe setup and switch on the third big new feature in the Flathub web app. At present, we have already implemented support for one-off payments either as donations or a required purchase. We would like to go further than that, in line with what we were describing earlier about helping developers sustainably work on apps for our ecosystem: we would also like to enable developers to offer subscriptions. This will allow us to create a relationship between users and creators that funds ongoing work rather than what we already have. Security For Flathub to succeed, we need to make sure that as we grow, we continue to be a platform that can give users confidence in the quality and security of the apps we offer. To that end, we are planning to set up infrastructure to help ensure developers are shipping the best products they possibly can to users. For example, we d like to set up automated linting and security scanning on the Flathub back-end to help developers avoid bad practices, unnecessary sandbox permissions, outdated dependencies, etc. and to keep users informed and as secure as possible. Sponsorship Fundraising is a forever task as is running such a big and growing service. We hope that one day, we can cover our costs through some modest fees built into our payments but until we reach that point, we re going to be seeking a combination of grant funding and sponsorship to keep our roadmap moving. Our hope is very much that we can encourage different organisations that buy into our vision and will benefit from Flathub to help us support it and ensure we can deliver on our goals. If you have any suggestions of who might like to support Flathub, we would be very appreciative if you could reach out and get us in touch. Finally, Thank You! Thanks to you all for reading this far and supporting the work of Flathub, and also to our major sponsors and donors without whom Flathub could not exist: GNOME Foundation, KDE e.V., Mythic Beasts, Endless Network, Fastly, and Equinix Metal via the CNCF Community Cluster. Thanks also to the tireless work of the Freedesktop SDK community to give us the runtime platform most Flatpaks depend on, particularly Seppo Yli-Olli, Codethink and others. I wanted to also give my personal thanks to a handful of dedicated people who keep Flathub working as a service and as a community: Bart omiej Piotrowski is keeping the infrastructure working essentially single-handedly (in his spare time from keeping everything running at GNOME); Kolja Lampe and Bart built the new web app and backend API for Flathub which all of the new functionality has been built on, and Filippe LeMarchand maintains the checker bot which helps keeps all of the Flatpaks up to date. And finally, all of the submissions to Flathub are reviewed to ensure quality, consistency and security by a small dedicated team of reviewers, with a huge amount of work from Hubert Figui re and Bart to keep the submissions flowing. Thanks to everyone named or unnamed for building this vision of the future of the Linux desktop together with us. (originally posted to Flathub Discourse, head there if you have any questions or comments)

Posted on March 7, 2023

Yesterday around 13:00 I started my usual I m being lazy bread recipe:

• 400 g flour
• 250 g water
• 6 g salt

worked for 8 minutes (by machine), left to rise until about 18:00. For the record, it was a strong flour (310 W), type 1, so white, but somewhat coarsely ground. And then, when it was time to cook bread for dinner I realized that something was missing. Something critical. See if you can spot it in the list above. The yeast. Some bread was taken out of the freezer and defrosted in the oven, but I didn t want to throw away the flour, so I mixed 2-3 g dried yeast, 10 g flour and 10 g water, and left it to rise until after dinner. Then I added it to the dought, added some more water (I know. I should have measured it. I didn t expect having to repeat the thing. It was probably about 20 g), mixed for 5 minutes, covered it to rise. This afternoon, around 15:30, I took the dought, folded it 5-6 times, formed a round loaf on the lined baking tray and left it in the cold oven until 17:45. Then I removed it from the oven, turned it on at 240 C, scored the top of the loaf and sprinkled it with water. When the oven was hot I baked the loaf for 10 minutes at 240 C, then turned it down to 160 C for 20 additional minutes. And then I realized I need to repeat this. No, there are no pictures (there is some left, but it s too dark to take pictures).

Posted on March 6, 2023

When I paint postcards I tend to start with a draft (usually on lightweight (250 g/m ) watercolour paper, then trace¹ the drawing on blank postcards and paint it again. I keep the drafts for a number of reasons; for the views / architectural ones I m using a landscape photo album that I bought many years ago, but lately I ve also sent a few cards with my historical outfits to people who like to be kept updated on that, and I wanted a different book for those, both for better organization and to be able to keep them in the portrait direction. If you know me, you can easily guess that buying one wasn t considered as an option. Since I m not going to be writing on the pages, I decided to use a relatively cheap 200 g / m linoprint paper with a nice feel, and I ve settled on a B6 size (before trimming) to hold A6 postcard drafts. For the binding I ve decided to use a technique I ve learned from a craft book ages ago that doesn t use tapes, and added a full hard cover in dark grey linen-feel² paper. For the end-papers I ve used some random sheets of light blue paper (probably around 100-something g / m ), and that s the thing where I could have done better, but they work. Up to now there isn t anything I hadn t done before, what was new was the fact that this book was meant to hold things between the pages, and I needed to provide space for them. After looking on the internet for solutions, I settled on adding spacers by making a signature composed of paper - spacer - paper - spacer, with the spacers being 2 cm wide, folded in half. And then, between finishing binding the book and making the cover I utterly forgot to add the head bands. Argh. It s not the first time I make this error. I m happy enough with the result. There are things that are easy to improve on in the next iteration (endpapers and head bands), and something in me is not 100% happy with the fact that the spacers aren t placed between every sheet, but there are places with no spacer and places with two of them, but I can t think of (and couldn t find) a way to make them otherwise with a sewn book, unless I sew each individual sheet, which sounds way too bulky (the album I m using for the landscapes was glued, but I didn t really want to go that way). The size is smaller than the other one I was using and doesn t leave a lot of room around the paintings, but that isn t necessarily a bad thing, because it also means less wasted space. I believe that one of my next project will be another similar book in a landscape format, for those postcard drafts that aren t landscapes nor clothing related. And then maybe another? or two? or

Traceback (most recent call last):
TooManyProjectsError: project queue is full

---

1. yes, trace. I can t draw. I have too many hobbies to spend the required amount of time every day to practice it. I m going to fake it. 85% of the time I m tracing from a photo I took myself, so I m not even going to consider it cheating.
2. the description of which, on the online shop, made it look like fabric, even if the price was suspiciously low, so I bought a sheet to see what it was. It wasn t fabric. It feels and looks nice, but I m not sure how sturdy it s going to be.

February ended up being a very short work month as I made a last minute decision to travel to Adelaide for the first 2 weeks of the month to help my brother with some house renovations he was undertaking. I thought I might be able to keep up with some work and my writing goals in the evenings while I was there, but days of hard manual labour are such an unfamiliar routine for me that I didn t have any energy left to make good on that intention. The majority of my time and focus for the remaining one and half weeks of the month was catching up on the consulting work that I had pushed back while in Adelaide. So while it doesn t make for a thrilling first month to look back and report on, overall I m not unhappy with what I achieved given the time available. Next month, I hope to be able to report some more exciting progress on the product development front as well.

Monthly Scoring Rubric I m evaluating each goal using a 10 point scale based on execution velocity and risk level, rather than absolute success (which is what I will look at in the annual/mid-year review). If velocity is good and risk is low or well managed the score is high, if either the velocity is low, or risk is high then the score is low. E.g:

• 10 - perfect execution with low-risk, on track for significantly overachieving the goal.
• 7 - good execution with low or well managed risk, highly likely to achieve the goal.
• 5 - execution and risk are OK, should achieve the goal if all goes well.
• 3 - execution or risk have problems, goal is at risk.
• 0 - stalled, with no obvious path to recovery or success.

Goals

Consulting - 6/10 Goal: Execute a series of successful consulting engagements, building a reputation for myself and leaving happy customers willing to provide testimonials that support a pipeline of future opportunities.

• I have one active local engagement assisting a software team with migrating their application from a single to multi-region architecture.
• Two promising international engagements which were close to starting both cancelled based on newly issued company policies freezing their staffing/outsourcing budgets due to the current economic climate.

I m happy with where this is at - I hit 90% of my target hours in February (taking into account 2 weeks off) and the feedback I m receiving is positive. The main risk is the future pipeline of engagements, particularly if the cancellations indicate a new pattern. I m not overly concerned yet, as all the opportunities to date have been from direct or referred contacts in my personal network, so there s plenty of potential to more actively solicit work to create a healthier pipeline.

Product Development - 3/10 Goal: Grow my product development skill set by taking several ideas to MVP stage with customer feedback received, and launch at least one product which generates revenue and has growth potential.

• Accelerating electrification - I continued to keep up with industry news and added some interesting reports to my reading queue, but made no significant progress towards identifying a specific product opportunity.
• Farm management SaaS - no activity or progress at all.
• co2mon.nz - I put significant thought and planning into how to approach a second iteration of this product. I started writing and completed 80% of a post to communicate the revised business plan, but it s not ready for publication yet, and even if it was, the real work towards it would need to actually happen to score more points here.

I had high hopes to make at least some progress in all three areas in February, but it just didn t happen due to lack of time. The good news is that since the low score here is purely execution driven, there s no new risks or blockers that will hinder much better progress here in March.

Professional Network Development - 8/10 Goal: To build a professional relationship with at least 30 new people this year. This is off to a strong start, I made 4 brand new connections and re-established contact with 9 other existing people I d not talked to for a while. I ve found the conversations energising and challenging and I m looking forward to continuing to keep this up.

Writing - 2/10 Goal: To publish a high-quality piece of writing on this site at least once a week. Well off track as already noted. I am enjoying the writing process and I continue to find it useful in developing my thoughts and forcing me to challenge my assumptions, but coupling the writing process with the thinking/planning that is a prerequisite to get those benefits definitely makes my output a lot slower than I was expecting. The slower speed, combined with the obvious time constraints of this month are not a great doubly whammy to be starting with, but I think with some planning and preparation it should have been avoidable by having a backlog of pre-written content for use in weeks where I m on holiday or otherwise busy. It s worth noting that among all the useful feedback I received, this writing target was often called out as overly ambitious, or likely to be counterproductive to producing quality writing. The feedback makes sense - for now I m not planning to change the goal (I might at my 6-month review point), but I am going to be diligent about adhering to my quality standard, which in turn means I m choosing to accept missing a weekly post here and there and taking a lower score on the goal overall. I apologise if you ve been eagerly waiting for writing that never arrived over February!

Community - 5/10 Goal: To support the growth of my local technical community by volunteering my experience and knowledge with others through activities such as mentoring, conference talks and similar.

• I was an invited participant of the monthly KiwiSRE meet-up which was discussing SRE team models, and in particular I was able to speak to my experiences as described in an old CRE blog post on this topic.
• I joined the program committee for SREcon23 APAC which is scheduled for mid-June in Singapore. I also submitted two talk proposals of my own (not sharing the details for now, since the review process is intended to be blind) which I m hopeful might make the grade with my fellow PC members!

Feedback As always, I d love to hear from you if you have thoughts or feedback triggered by anything I ve written above. In particular, it would be useful to know whether you find this type of report interesting to read and/or what you d like to see added/removed or changed.

Hello World! I haven't really had time to blog here since the start of the semester, as I've been pretty busy at work¹. All this to say, this report for the Bug Squashing Party we held in Montreal last weekend is a little late, sorry :) First of all, I'm pleased to announce our local community seems to be doing great and has recovered from the pandemic-induced lull. May COVID stay away from our bodies forever. This time around, a total of 9 people made it to what has become somewhat of a biennial tradition². We worked on a grand total of 14 bugs and even managed to close some! It looks like I was too concentrated on bugs to take a picture of the event... To redeem myself, I hereby offer you a picture of a cute-but-hairless cat I met on Sunday morning: You should try to join an upcoming BSP or to organise one if you can. It's loads of fun and you'll be helping the project make the next release happen sooner! As always, thanks to Debian for granting us a budget for the food and to rent the venue. Goodbye Bullseye!

tl;dr git submodules are always the wrong solution. Yes, even the to the problem they were specifically invented to solve.

• What is wrong with git submodules
• Better alternatives to git submodules
  • Use git subtree
  • Just have a monorepo
  • Use a package management system, and explicit dependencies
  • Use the multiple repository tool mr
  • Have your build expect to find the dependency in .., its parent dir
  • Provide an ad-hoc in-tree script to download the dependency

( Read more... )

comments

Vox has an insightful interview with the author of Slouching Towards Utopia: An Economic History of the Twentieth Century [1]. The main claim of that book is that The 140 years from 1870 to 2010 of the long twentieth century were, I strongly believe, the most consequential years of all humanity s centuries . A claim that seems well supported. PostMarketOS is an interesting OS for hardware designed for Android [2]. It is based on Alpine Linux, is small, and modular. If you want to change something just change that package not the entire image. Also an aim is to have as much commonality between devices as possible, all phones with the same CPU family can run the same packages apart from the kernel and maybe some utilities related to hardware. Abhijithpa blogged about getting started with pmOS, it seems easy to do [3]. Interesting article about gay samurai [4]. Regarding sex with men or women an elderly arbiter, after hearing the impassioned arguments of the two sides, counsels that the wisest course is to follow both paths in moderation, thereby helping to prevent overindulgence in either . Wow. The SCP project is an interesting collaborative SciFi/horror fiction project [5] based on an organisation that aims to Secure and Contain dangerous objects and beings and Protect the world from them. The series of stories about the Anti-Memetics Division [6] is a good place to start reading.

• [1] https://tinyurl.com/2y6ynv4k
• [2] https://postmarketos.org/
• [3] https://abhijithpa.me/2022/Running-postmarketos-on-my-phone/
• [4] https://www.tofugu.com/japan/gay-samurai/
• [5] https://scp-wiki.wikidot.com/
• [6] https://qntm.org/scp

Ever since 2019, I ve been learning about how radios work, and trying to learn about using them the hard way by writing as much of the stack as is practical (for some value of practical) myself. I wrote my first Hello World in 2018, which was a simple FM radio player, which used librtlsdr to read in an IQ stream, did some filtering, and played the real valued audio stream via pulseaudio. Over 4 years this has slowly grown through persistence, lots of questions to too many friends to thank (although I will try), and the eternal patience of my wife hearing about radios nonstop for years into a number of Go repos that can do quite a bit, and support a handful of radios. I ve resisted making the repos public not out of embarrassment or a desire to keep secrets, but rather, an attempt to keep myself free of any maintenance obligations to users so that I could freely break my own API, add and remove API surface as I saw fit. The worst case was to have this project feel like work, and I can t imagine that will happen if I feel frustrated by PRs that are getting ahead of me solving problems I didn t yet know about, or bugs I didn t understand the fix for. As my rate of changes to the most central dependencies has slowed, i ve begun to entertain the idea of publishing them. After a bit of back and forth, I ve decided it s time to make a number of them public, and to start working on them in the open, as I ve built up a bit of knowledge in the space, and I and feel confident that the repo doesn t contain overt lies. That s not to say it doesn t contain lies, but those lies are likely hidden and lurking in the dark. Beware. That being said, it shouldn t be a surprise to say I ve not published everything yet for the same reasons as above. I plan to open repos as the rate of changes slows and I understand the problems the library solves well enough or if the project dead ends and I ve stopped learning.

Intention behind hz.tools It s my sincere hope that my repos help to make Software Defined Radio (SDR) code a bit easier to understand, and serves as an understandable framework to learn with. It s a large codebase, but one that is possible to sit down and understand because, well, it was written by a single person. Frankly, I m also not productive enough in my free time in the middle of the night and on weekends and holidays to create a codebase that s too large to understand, I hope! I remain wary of this project turning into work, so my goal is to be very upfront about my boundaries, and the limits of what classes of contributions i m interested in seeing. Here s some goals of open sourcing these repos:

• I do want this library to be used to learn with. Please go through it all and use it to learn about radios and how software can control them!
• I am interested in bugs if there s a problem you discover. Such bugs are likely a great chance for me to fix something I ve misunderstood or typoed.
• I am interested in PRs fixing bugs you find. I may need a bit of a back and forth to fully understand the problem if I do not understand the bug and fix yet. I hope you may have some grace if it s taking a long time.

Here s a list of some anti-goals of open sourcing these repos.

• I do not want this library to become a critical dependency of an important project, since I do not have the time to deal with the maintenance burden. Putting me in that position is going to make me very uncomfortable.
• I am not interested in feature requests, the features have grown as I ve hit problems, I m not interested in building or maintaining features for features sake. The API surface should be exposed enough to allow others to experiment with such things out-of-tree.
• I m not interested in clever code replacing clear code without a very compelling reason.
• I use GNU/Linux (specifically Debian ), and from time-to-time I ve made sure that my code runs on OpenBSD too. Platforms beyond that will likely not be supported at the expense of either of those two. I ll take fixes for bugs that fix a problem on another platform, but not damage the code to work around issues / lack of features on other platforms (like Windows).

I m not saying all this to be a jerk, I do it to make sure I can continue on my journey to learn about how radios work without my full time job becoming maintaining a radio framework single-handedly for other people to use even if it means I need to close PRs or bugs without merging it or fixing the issue. With all that out of the way, I m very happy to announce that the repos are now public under github.com/hztools.

Should you use this? Probably not. The intent here is not to provide a general purpose Go SDR framework for everyone to build on, although I am keenly aware it looks and feels like it, since that what it is to me. This is a learning project, so for any use beyond joining me in learning should use something like GNU Radio or a similar framework that has a community behind it. In fact, I suspect most contributors ought to be contributing to GNU Radio, and not this project. If I can encourage people to do so, contribute to GNU Radio! Nothing makes me happier than seeing GNU Radio continue to be the go-to, and well supported. Consider donating to GNU Radio!

hz.tools/rf - Frequency types The hz.tools/rf library contains the abstract concept of frequency, and some very basic helpers to interact with frequency ranges (such as helpers to deal with frequency ranges, or frequency range math) as well as frequencies and some very basic conversions (to meters, etc) and parsers (to parse values like 10MHz). This ensures that all the hz.tools libraries have a shared understanding of Frequencies, a standard way of representing ranges of Frequencies, and the ability to handle the IO boundary with things like CLI arguments, JSON or YAML. The git repo can be found at github.com/hztools/go-rf, and is importable as hz.tools/rf.

 // Parse a frequency using hz.tools/rf.ParseHz, and print it to stdout.
 freq := rf.MustParseHz("-10kHz")
fmt.Printf("Frequency: %s\n", freq+rf.MHz)
// Prints: 'Frequency: 990kHz'

// Return the Intersection between two RF ranges, and print
 // it to stdout.
 r1 := rf.Range rf.KHz, rf.MHz 
r2 := rf.Range rf.Hz(10), rf.KHz * 100 
fmt.Printf("Range: %s\n", r1.Intersection(r2))
// Prints: Range: 1000Hz->100kHz

These can be used to represent tons of things - ranges can be used for things like the tunable range of an SDR, the bandpass of a filter or the frequencies that correspond to a bin of an FFT, while frequencies can be used for things such as frequency offsets or the tuned center frequency.

hz.tools/sdr - SDR I/O and IQ Types This is the big one. This library represents the majority of the shared types and bindings, and is likely the most useful place to look at when learning about the IO boundary between a program and an SDR. The git repo can be found at github.com/hztools/go-sdr, and is importable as hz.tools/sdr. This library is designed to look (and in some cases, mirror) the Go io idioms so that this library feels as idiomatic as it can, so that Go builtins interact with IQ in a way that s possible to reason about, and to avoid reinventing the wheel by designing new API surface. While some of the API looks (and is even called) the same thing as a similar function in io, the implementation is usually a lot more naive, and may have unexpected sharp edges such as concurrency issues or performance problems. The following IQ types are implemented using the sdr.Samples interface. The hz.tools/sdr package contains helpers for conversion between types, and some basic manipulation of IQ streams.

IQ Format	hz.tools Name	Underlying Go Type
Interleaved uint8 (rtl-sdr)	sdr.SamplesU8	[][2]uint8
Interleaved int8 (hackrf, uhd)	sdr.SamplesI8	[][2]int8
Interleaved int16 (pluto, uhd)	sdr.SamplesI16	[][2]int16
Interleaved float32 (airspy, uhd)	sdr.SamplesC64	[]complex64

The following SDRs have implemented drivers in-tree.

SDR	Format	RX/TX	State
rtl	u8	RX	Good
HackRF	i8	RX/TX	Good
PlutoSDR	i16	RX/TX	Good
rtl kerberos	u8	RX	Old
uhd	i16/c64/i8	RX/TX	Good
airspyhf	c64	RX	Exp

The following major packages and subpackages exist at the time of writing:

Import	What is it?
hz.tools/sdr	Core IQ types, supporting types and implementations that interact with the byte boundary
hz.tools/sdr/rtl	sdr.Receiver implementation using librtlsdr.
hz.tools/sdr/rtl/kerberos	Helpers to enable coherent RX using the Kerberos SDR.
hz.tools/sdr/rtl/e4k	Helpers to interact with the E4000 RTL-SDR dongle.
hz.tools/sdr/fft	Interfaces for performing an FFT, which are implemented by other packages.
hz.tools/sdr/rtltcp	sdr.Receiver implementation for rtl_tcp servers.
hz.tools/sdr/pluto	sdr.Transceiver implementation for the PlutoSDR using libiio.
hz.tools/sdr/uhd	sdr.Transceiver implementation for UHD radios, specifically the B210 and B200mini
hz.tools/sdr/hackrf	sdr.Transceiver implementation for the HackRF using libhackrf.
hz.tools/sdr/mock	Mock SDR for testing purposes.
hz.tools/sdr/airspyhf	sdr.Receiver implementation for the AirspyHF+ Discovery with libairspyhf.
hz.tools/sdr/internal/simd	SIMD helpers for IQ operations, written in Go ASM. This isn t the best to learn from, and it contains pure go implemtnations alongside.
hz.tools/sdr/stream	Common Reader/Writer helpers that operate on IQ streams.

hz.tools/fftw - hz.tools/sdr/fft implementation The hz.tools/fftw package contains bindings to libfftw3 to implement the hz.tools/sdr/fft.Planner type to transform between the time and frequency domain. The git repo can be found at github.com/hztools/go-fftw, and is importable as hz.tools/fftw. This is the default throughout most of my codebase, although that default is only expressed at the leaf package libraries should not be hardcoding the use of this library in favor of taking an fft.Planner, unless it s used as part of testing. There are a bunch of ways to do an FFT out there, things like clFFT or a pure-go FFT implementation could be plugged in depending on what s being solved for.

hz.tools/ fm,am - analog audio demodulation and modulation The hz.tools/fm and hz.tools/am packages contain demodulators for AM analog radio, and FM analog radio. This code is a bit old, so it has a lot of room for cleanup, but it ll do a very basic demodulation of IQ to audio. The git repos can be found at github.com/hztools/go-fm and github.com/hztools/go-am, and are importable as hz.tools/fm and hz.tools/am. As a bonus, the hz.tools/fm package also contains a modulator, which has been tested on the air and with some of my handheld radios. This code is a bit old, since the hz.tools/fm code is effectively the first IQ processing code I d ever written, but it still runs and I run it from time to time.

 // Basic sketch for playing FM radio using a reader stream from
 // an SDR or other IQ stream.

bandwidth := 150*rf.KHz
reader, err = stream.ConvertReader(reader, sdr.SampleFormatC64)
if err != nil  
...
 
demod, err := fm.Demodulate(reader, fm.DemodulatorConfig 
Deviation: bandwidth / 2,
Downsample: 8, // some value here depending on sample rate
 Planner: fftw.Plan,
 )
if err != nil  
...
 
speaker, err := pulseaudio.NewWriter(pulseaudio.Config 
Format: pulseaudio.SampleFormatFloat32NE,
Rate: demod.SampleRate(),
AppName: "rf",
StreamName: "fm",
Channels: 1,
SinkName: "",
 )
if err != nil  
...
 
buf := make([]float32, 1024*64)
for  
i, err := demod.Read(buf)
if err != nil  
...
 
if i == 0  
panic("...")
 
if err := speaker.Write(buf[:i]); err != nil  
...
 
 

hz.tools/rfcap - byte serialization for IQ data The hz.tools/rfcap package is the reference implementation of the rfcap spec , and is how I store IQ captures locally, and how I send them across a byte boundary. The git repo can be found at github.com/hztools/go-rfcap, and is importable as hz.tools/rfcap. If you re interested in storing IQ in a way others can use, the better approach is to use SigMF rfcap exists for cases like using UNIX pipes to move IQ around, through APIs, or when I send IQ data through an OS socket, to ensure the sample format (and other metadata) is communicated with it. rfcap has a number of limitations, for instance, it can not express a change in frequency or sample rate during the capture, since the header is fixed at the beginning of the file.

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 1042 other packages on CRAN, downloaded 28.1 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 513 times according to Google Scholar. This release brings a new upstream release 12.0.1. We found a small regression with the 12.0.0 release when we tested prior to a CRAN upload. Conrad very promptly fixed this with a literal one liner and made it 12.0.1 which we wrapped up as 0.12.0.1.0. Subsequent testing revealed no issues for us, and CRAN autoprocessed it as I tweeted earlier. This is actually quite impressive given the over 1000 CRAN packages using it all of which got tested again by CRAN. All this is testament to the rigour, as well as the well-oiled process at the repository. Our thanks go to the tireless maintainers! The releases actually has a rather nice set of changes (detailed below) to which we added one robustification thanks to Kevin. The full set of changes follows. We include the previous changeset as we may have skipped the usual blog post here.

Changes in RcppArmadillo version 0.12.0.1.0 (2023-02-20)

• Upgraded to Armadillo release 12.0.1 (Cortisol Profusion)
  • faster fft() and ifft() via optional use of FFTW3
  • faster min() and max()
  • faster index_min() and index_max()
  • added .col_as_mat() and .row_as_mat() which return matrix representation of cube column and cube row
  • added csv_opts::strict option to loading CSV files to interpret missing values as NaN
  • added check_for_zeros option to form 4 of sparse matrix batch constructors
  • inv() and inv_sympd() with options inv_opts::no_ugly or inv_opts::allow_approx now use a scaled threshold similar to pinv()
  • set_cout_stream() and set_cerr_stream() are now no-ops; instead use the options ARMA_WARN_LEVEL, or ARMA_COUT_STREAM, or ARMA_CERR_STREAM
  • fix regression (mis-compilation) in shift() function (reported by us in #409)
• The include directory order is now more robust (Kevin Ushey in #407 addressing #406)

Changes in RcppArmadillo version 0.11.4.4.0 (2023-02-09)

• Upgraded to Armadillo release 11.4.4 (Ship of Theseus)
  • extended pow() with various forms of element-wise power operations
  • added find_nan() to find indices of NaN elements
  • faster handling of compound expressions by sum()
• The package no longer sets a compilation standard, or progagates on in the generated packages as R ensures C++11 on all non-ancient versions
• The CITATION file was updated to the current format

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. 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.

Like each month, have a look at the work funded by Freexian s Debian LTS offering. This is the first monthly report in 2023.

Debian LTS contributors In January, 17 contributors have been paid to work on Debian LTS. which is possibly the highest number of active contributors per month! Their reports are available:

• Abhijith PA did 0.0h (out of 3.0h assigned and 11.0h from previous period), thus carrying over 14.0h to the next month.
• Adrian Bunk did 26.25h (out of 26.25h assigned).
• Anton Gladky did 11.5h (out of 8.0h assigned and 7.0h from previous period), thus carrying over 3.5h to the next month.
• Ben Hutchings did 8.0h (out of 24.0h assigned), thus carrying over 16.0h to the next month.
• Chris Lamb did 18.0h (out of 18.0h assigned).
• Emilio Pozuelo Monfort did 8.0h (out of 0h assigned and 43.0h from previous period), thus carrying over 35.0h to the next month.
• Guilhem Moulin did 20.0h (out of 17.5h assigned and 2.5h from previous period).
• Helmut Grohne did 10.0h (out of 15.0h assigned), thus carrying over 5.0h to the next month.
• Lee Garrett did 7.5h (out of 20.0h assigned), thus carrying over 12.5h to the next month.
• Markus Koschany did 26.25h (out of 26.25h assigned).
• Ola Lundqvist did 4.5h (out of 10.0h assigned and 6.0h from previous period), thus carrying over 11.5h to the next month.
• Roberto C. S nchez did 3.75h (out of 18.75h assigned and 7.5h from previous period), thus carrying over 22.5h to the next month.
• Stefano Rivera did 4.5h (out of 0h assigned and 32.5h from previous period), thus carrying over 28.0h to the next month.
• Sylvain Beucler did 23.5h (out of 0h assigned and 38.5h from previous period), thus carrying over 15.0h to the next month.
• Thorsten Alteholz did 14.0h (out of 10.0h assigned and 4.0h from previous period).
• Tobias Frost did 19.0h (out of 19.0h assigned).
• Utkarsh Gupta did 43.25h (out of 26.25h assigned and 17.0h from previous period).

Evolution of the situation Furthermore, we released 46 DLAs in January, which resolved 146 CVEs. We are working diligently to reduce the number of packages listed in dla-needed.txt, and currently, we have 55 packages listed. We are constantly growing and seeking new contributors. If you are a Debian Developer and want to join the LTS team, please contact us.

Thanks to our sponsors Sponsors that joined recently are in bold.

• Platinum sponsors:
  • TOSHIBA (for 89 months)
  • GitHub (for 80 months)
  • Civil Infrastructure Platform (CIP) (for 57 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 100 months)
  • Linode (for 94 months)
  • Babiel GmbH (for 83 months)
  • Plat Home (for 83 months)
  • University of Oxford (for 39 months)
  • Deveryware (for 26 months)
  • VyOS Inc (for 21 months)
  • EDF SA (for 10 months)
• Silver sponsors:
  • Domeneshop AS (for 105 months)
  • Nantes M tropole (for 99 months)
  • Univention GmbH (for 90 months)
  • Universit Jean Monnet de St Etienne (for 90 months)
  • Ribbon Communications, Inc. (for 84 months)
  • Exonet B.V. (for 74 months)
  • Leibniz Rechenzentrum (for 68 months)
  • CINECA (for 57 months)
  • Minist re de l Europe et des Affaires trang res (for 52 months)
  • Cloudways Ltd (for 41 months)
  • Dinahosting SL (for 39 months)
  • Bauer Xcel Media Deutschland KG (for 33 months)
  • Platform.sh (for 33 months)
  • MOXA INC. (for 27 months)
  • sipgate GmbH (for 24 months)
  • Tilburg University (for 23 months)
  • OVH US LLC (for 22 months)
  • GSI Helmholtzzentrum f r Schwerionenforschung GmbH (for 14 months)
  • Soliton Systems K.K. (for 11 months)
• Bronze sponsors:
  • Evolix (for 105 months)
  • Seznam.cz, a.s. (for 105 months)
  • Intevation GmbH (for 102 months)
  • Linuxhotel GmbH (for 102 months)
  • Daevel SARL (for 101 months)
  • Bitfolk LTD (for 99 months)
  • Megaspace Internet Services GmbH (for 99 months)
  • NUMLOG (for 99 months)
  • Greenbone Networks GmbH (for 98 months)
  • WinGo AG (for 98 months)
  • Ecole Centrale de Nantes - LHEEA (for 94 months)
  • Entr ouvert (for 89 months)
  • Adfinis AG (for 87 months)
  • GNI MEDIA (for 81 months)
  • Laboratoire LEGI - UMR 5519 / CNRS (for 81 months)
  • Tesorion (for 81 months)
  • Bearstech (for 73 months)
  • LiHAS (for 72 months)
  • Catalyst IT Ltd (for 67 months)
  • Supagro (for 62 months)
  • Demarcq SAS (for 61 months)
  • Universit Grenoble Alpes (for 47 months)
  • TouchWeb SAS (for 39 months)
  • SPiN AG (for 36 months)
  • CoreFiling (for 31 months)
  • Institut des sciences cognitives Marc Jeannerod (for 26 months)
  • Observatoire des Sciences de l Univers de Grenoble (for 23 months)
  • Tem Innovations GmbH (for 18 months)
  • WordFinder.pro (for 17 months)
  • CNRS DT INSU R sif (for 16 months)
  • Alter Way (for 9 months)

Back in September last year I chose to back the StarFive VisionFive 2 on Kickstarter. I don t have a particular use in mind for it, but I felt it was one of the first RISC-V systems that were relatively capable (mentally I have it as somewhere between a Raspberry Pi 3 + a Pi 4). In particular it s a quad 1.5GHz 64-bit RISC-V core with 8G RAM, USB3, GigE ethernet and a single M.2 PCIe slot. More than ample as a personal machine for playing around with RISC-V and doing local builds. I ended up paying 67 for the Early Bird variant (dual GigE ethernet rather than 1 x 100Mb and 1 x GigE). A couple of weeks ago I got an email with a tracking number and last week it finally turned up. Being impatient the first thing I did was plug it into a monitor, connect up a keyboard, and power it on. Nothing except some flashing lights. Looking at the boot selector DIP switches suggested it was configured to boot from UART, so I flipped them to (what I thought was) the flash setting. It wasn t - turns out the ON marking on the switches represents logic 0 and it was correctly setup when I got it. I went to read the documentation which talked about writing an image to a MicroSD card, but also had details of the UART connection. Wanting to make sure the device was at least doing something before I actually tried an OS on it I hooked up a USB/serial dongle and powered the board up again. Success! U-Boot appeared and I could interact with it. I went to the VisionFive2 Debian page and proceeded to torrent the Image-69 image, writing it to a MicroSD card and inserting it in the slot on the bottom of the board. It booted fine. I can t even tell you what graphical environment it booted up because I don t remember; it worked fine though (at 1080p, I ve seen reports that 4K screens will make it croak). Poking around the image revealed that it s built off a snapshot.debian.org snapshot from 20220616T194833Z, which is a little dated at this point but I understand the rationale behind picking something that works and sticking with it. The kernel is of course a vendor special, based on 5.15.0. Further investigation revealed that the entire X/graphics stack is living in /usr/local, which isn t overly surprising; it s Imagination based. I was pleasantly surprised to discover there is work to upstream the Imagination support, but I m not planning to run the board with a monitor attached so it s not a high priority for me. Having discovered all that I decided to see how well a clean Debian unstable install from Debian Ports would go. I had a spare Intel Optane lying around (it s a stupid 22110 M.2 which is too long for any machine I own), so I put it in the slot on the bottom of the board. To my surprise it Just Worked and was detected ok: I created a single partition with an ext4 filesystem (initially tried btrfs, but the StarFive kernel doesn t support it), and kicked off a debootstrap with: The u-boot setup has a convoluted set of vendor scripts that eventually ends up reading a /boot/extlinux/extlinux.conf config from /dev/mmcblk1p2, so I added an additional entry there using the StarFive kernel but pointing to the NVMe device for /. Made sure to set a root password (not that I ve been bitten by that before, too many times), and rebooted. Success! Well. Sort of. I hit a bunch of problems with having a getty running on ttyS0 as well as one running on hvc0. The second turns out to be a console device from the RISC-V SBI. I did a systemctl mask serial-getty@hvc0.service which made things a bit happier, but I was still seeing odd behaviour and output. Turned out I needed to reboot the initramfs as well; the StarFive one was using Plymouth and doing some other stuff that seemed to be confusing matters. An update-initramfs -k 5.15.0-starfive -c built me a new one and everything was happy. Next problem; the StarFive kernel doesn t have IPv6 support. StarFive are good citizens and make their 5.15 kernel tree available, so I grabbed it, fed it the existing config, and tweaked some options (including adding IPV6 and SECCOMP, which chrony wanted). Slight hiccup when it turned out trying to do things like make sound modular caused it to fail to compile, and having to backport the fix that allowed the use of GCC 12 (as present in sid), but it got there. So I got cocky and tried to update it to the latest 5.15.94. A few manual merge fixups (which I may or may not have got right, but it compiles and boots for me), and success. Timings: On the subject of kernels I am pleased to note that there are efforts to upstream the VisionFive 2 support, with what appears to be multiple members of StarFive engaging in multiple patch submission rounds. It s really great to see this and I look forward to being able to run an unmodified mainline kernel on my board. Niggles? I have a few. The provided u-boot doesn t have NVMe support enabled, so at present I need to keep a MicroSD card to boot off, even though root is on an SSD. I m also seeing some errors in dmesg from the SSD: It doesn t seem to cause any actual issues, and it could be the SSD, the 5.15 kernel or an actual hardware thing - I ll keep an eye on it (I will probably end up with a different SSD that actually fits, so that ll provide another data point). More annoying is the temperature the CPU seems to run at. There s no heatsink or fan, just the metal heatspreader on top of the CPU, and in normal idle operation it sits at around 60 C. Compiling a kernel it hit 90 C before I stopped the job and sorted out some additional cooling in the form of a desk fan, which kept it as just over 30 C. I haven t seen any actual stability problems, but I wouldn t want to run for any length of time like that. I ve ordered a heatsink and also realised that the board supports a Raspberry Pi style PoE Hat , so I ve got one of those that includes a fan ordered (I am a complete convert to PoE especially for small systems like this). With the desk fan setup I ve been able to run the board for extended periods under load (I did a full recompile of the Debian 6.1.12-1 kernel package and it took about 10 hours). The M.2 slot is unfortunately only a single PCIe v2 lane, and my testing topped out at about 180MB/s. IIRC that is about half what the slot should be capable of, and less than a 10th of what the SSD can do. Ethernet testing with iPerf3 sustained about 941Mb/s, so basically maxing out the port. The board as a whole isn t going to set any speed records, but it s perfectly usable, and pretty impressive for the price point. On the Debian side I ve not hit any surprises. There s work going on to move RISC-V to a proper release architecture, and I m hoping to be able to help out with that, but the version of unstable I installed from the ports infrastructure has looked just like any other Debian install. Which is what you want. And that pretty much sums up my overall experience of the VisionFive 2; it s not noticeably different than any other single board computer. That s a good thing, FWIW, and once the kernel support lands properly upstream (it ll be post 6.3 at least it seems) it ll be a boring mainline supported platform that just happens to be RISC-V.

To be able to investigate and work on the the measured boot features I have switched from grub to systemd-boot (sd-boot). This initial step is optional, but it is useful because this way /etc/kernel/cmdline will become the new place where the kernel command line can be configured:

. /etc/default/grub
echo "root=/dev/mapper/root $GRUB_CMDLINE_LINUX $GRUB_CMDLINE_LINUX_DEFAULT" > /etc/kernel/cmdline

Do not forget to set the correct root file system there, because initramfs-tools does not support discovering it at boot time using the Discoverable Partitions Specification. The installation has been automated since systemd version 252.6-1, so installing the package has the effect of installing sd-boot in the ESP, enabling it in the UEFI boot sequence and then creating boot loader entries for the kernels already installed on the system:

apt install systemd-boot

If needed, it could be manually installed again just by running bootctl install. I like to show the boot menu by default, at least until I will be more familiar with sd-boot:

bootctl set-timeout 4

Since other UEFI binaries can be easily chainloaded, I am also going to keep around grub for a while, just to be sure:

cat <<END > /boot/efi/loader/entries/grub.conf
title Grub
linux /EFI/debian/grubx64.efi
END

At this point sd-boot works, but I still had to enable secure boot. So far sd-boot has not been signed with a Debian key known to the shim bootloader, so I needed to create a Machine Owner Key (MOK), enroll it in UEFI and then use it to sign everything. I dislike the complexity of mokutil and the other related programs, so after removing it and the boot shim I have decided to use sbctl instead. With it I easily created new keys, enrolled them in the EFI key store and then signed everything:

sbctl create-keys
sbctl enroll-keys
for file in /boot/efi/*/*/linux /boot/efi/EFI/*/*.efi; do
  sbctl sign -s $file
done

Since there is no sbctl package yet I need to make sure that also the kernels installed in the future will be automatically signed, so I have created a trivial script in /etc/kernel/install.d/ which automatically runs sbctl sign -s or sbctl remove-file. The Debian wiki SecureBoot page documents how do do this with mokutil and sbsigntool, but I think that sbctl is much friendlier. Since I am not using the boot shim, I also had to set DisableShimForSecureBoot=true in /etc/fwupd/uefi_capsule.conf to make firmware updates work automatically. As a bonus, I have also added to the boot menu the excellent Debian-based GRML live distribution. Since sd-boot is not capable of loopback-mounting CD-ROM images like grub, I first had to extract the kernel and initramfs and copy them to the ESP:

mount -o loop /boot/grml/grml64-full_2022.11.iso /mnt/
mkdir /boot/efi/grml/
cp /mnt/boot/grml64full/* /boot/efi/grml/
umount /mnt/
cat <<END > /boot/efi/loader/entries/grml.conf
title GRML
linux /grml/vmlinuz
initrd /grml/initrd.img
options boot=live bootid=grml64full202211 findiso=/grml/grml64-full_2022.11.iso live-media-path=/live/grml64-full net.ifnames=0 
END

As expected, after a reboot bootctl reports the new security features:

System:
      Firmware: UEFI 2.70 (Lenovo 0.4496)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: yes
  Boot into FW: supported
Current Boot Loader:
      Product: systemd-boot 252.5-2
     Features:   Boot counting
                 Menu timeout control
                 One-shot menu timeout control
                 Default entry control
                 One-shot entry control
                 Support for XBOOTLDR partition
                 Support for passing random seed to OS
                 Load drop-in drivers
                 Support Type #1 sort-key field
                 Support @saved pseudo-entry
                 Support Type #1 devicetree field
                 Boot loader sets ESP information
          ESP: /dev/disk/by-partuuid/1b767f8e-70fa-5a48-b444-cfe5c272d66e
         File:  /EFI/systemd/systemd-bootx64.efi
...

Relevant documentation:

• systemd-boot(7)
• systemd-cryptenroll(1)
• sbctl
• Boot Loader Specification
• Unified Kernel Image (UKI)