Here s my monthly but brief update about the activities I ve done in the FOSS world.
Debian
Whilst I didn t get a chance to do much, here are still a few things that I worked on:
Leading the DebConf Bursary team along with PEB.
This took most of my Debian time this month but we ve been able to wrap that work now.
Got back to all the tickets on Zammad, too.
Assisted a few folks in getting their patches submitted via Salsa.
Mentoring for newcomers.
Moderation of -project mailing list.
Ubuntu
I joined Canonical to work on Ubuntu full-time back in February 2021.
Whilst I can t give a full, detailed list of things I did, here s a quick TL;DR of what I did:
Continued to push for infrastructure improvements:
[LTS] Emilio pointed out that the gst-plugins-ugly1.0 binaries were still not fully released, so I ran dcut migrate to fully release them. The DLA had gone out earlier.
[ELTS] Did some more work on ruby-rack - a lot of new CVEs have opened up and, whilst I made some progress, Santiago let me know that ruby-rack is no longer supported and so it ll be removed from the ela-needed list.
[E/LTS] Set up the security-tracker and a few other things on the new machine, and debugged the git repository size madness. Sent a summary here.
[E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates.
While watching a YouTube video I saw an advert for the Plaud AI Note Taker [1]. The Plaud device looks pretty good for what it does, taking notes and managing them, using some sort of LLM function to manage the notes. The devices all cost about $300 which is an amount that doesn t seem unreasonable for someone who s in a lot of meetings. One of the models is the NotePin that seems comparable to the Humane AI Pin I previously blogged about [2].
The business model for Plaud is based on only allowing 5 hours per month of free transcriptions, then charging $16.25/month for 20 hours per month and $33.33/month for unlimited use. That s quite expensive for any serious use.
The number of people in the market for an audio recording system that automatically transcribes things may be greater than the number of people in the market for all the stuff that the Humane AI Pin did, but it still may not be enough to run a profitable business when competing with apps on mobile phones.
While the product does look decent it seems that they are making the same mistakes as the original Humane developers did, of wanting to lock it down as a subscription based service which reduces the usability of the device. If they had sold an Android hand-held computer with their own app pre-loaded and allowed the user to install a different app then it would have been much more usable. If they had sold Android devices designed for the note taking market and allowed people to choose their own apps to install then their products would have a much longer life expectancy.
The majority of Android devices in use are probably out of support but still working while the Humane AI pin can t be used any more and at some time in the not too distant future the Plaud devices will also become unusable. People who buy devices like the Plaud seem to be unaware of the history of such things and the expected future for them. But possibly some people just consider $300 for a year of use to be an acceptable price. If someone wanted to purchase a new high end phone every year and sell their previous one they would probably have a net cost of about $500/year.
Maybe I should look for work with a company with an implausible AI based business plan. It would be fun developing such a device if you weren t emotionally invested in the project. Just develop new technology, earn a heap of money, play with fun computers, and move on to the next thing when it collapses. Just like all the Internet companies about 25 years ago.
After getting a HP Z4 G4 tower server/workstation to house my Intel Battlemage GPU [1] I ve been playing around with some GPU stuff. For years I ve been just buying GPUs based on the resolution and price and not bothering about anything else due to lack of ability to measure what cards are doing. The nvidia-smi program is really good for NVidia/CUDA setups but I hadn t been aware of anything similar for AMD cards. As I prefer AMD cards for my workstations due to driver issues with NVidia that was a problem for me.
I ve recently discovered that the program nvtop (Debian package nvtop) shows the GPU use of multiple GPU types, for me it s worked on AMD and Intel discrete GPUs and shows some information on Intel integrated GPUs, I don t have others convenient for testing at the moment. Currently BOINC has the Einstein@Home [2] project running on the HP Z4 G4 and it s using between 66% and 100% of GPU compute power and 1.6G of GPU RAM. Using 100% GPU compute power allegedly takes 62W of power out of the 190W quoted TDP. I presume that the power use reported by nvtop is very inaccurate.
A friend installed a LLM on that system and the libraries used for the LLM were sufficient that BOINC just started using the GPU.
On my workstation running an AMD [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (actually R560) with 4G of GPU RAM I have mpv taking 1G of GPU RAM to play a FullHD video expanded to a full screen window on my 5120*2160 display. I also have about 2G used by the kwin_wayland process (the Wayland server for KDE). That doesn t leave enough GPU RAM to allow Einstein@Home to use the GPU. When playing the FullHD video in question (which is 1.2G for 42 minutes about 500KB/s) at 1.5* speed (a common playback speed I use) that takes about 30% of the compute power on my GPU.
I had installed the rocm-opencl-icd package on my workstation (with a 5120*2160 monitor) and restarted boinc-client.service which is all that s needed to allow BOINC to use an AMD GPU. Then the screen started flickering as the Einstein process repeatedly core dumped which I initially assumed to be it s reaction to not having enough GPU RAM available. On every core dump the screen flickered so it went through a process of dozens of screen flickers until it had caused a sufficient number of core dumps and BOINC gave up running that job.
Another annoyance is that the boincmgr program (the graphical program for managing BOINC systems) launches two webkit processes that each use about 400M of GPU RAM, so even if other things weren t using all my GPU RAM the boincmgr process would stop the BOINC jobs from using the GPU. I shut down some of the programs that were using GPU RAM until there was 2G free and the BOINC process kept crashing so it seems that there is some other issue.
On another system with a 4K monitor there were Chrome and Chromium GPU process taking 1.1G and 500M of GPU RAM respectively and the KWin Wayland process was taking 1G of GPU RAM. So that s well over half the GPU RAM for just browsers and Wayland. With programs like Kitty (terminal emulator) and Nheko (Matrix client) taking over 100M of GPU RAM it seems that 4G is the bare minimum for GPU RAM with modern software and a 4K or similar display.
I also noticed the kscreenlocker_greet process taking 440M of GPU RAM. I wonder if a hostile web server could make a web browser take more GPU RAM and starve the screenlocker of GPU RAM, could that allow forcing a screen lock operation to fail?
It seems that 4G is the minimum for modern systems, which isn t necessarily a problem as GPUs that are capable of driving 4K displays tend to have no less than 4G. My local computer store has new GPUs with 4G starting at $120 but 12G seems to be the next option up which starts at about $400.
Ebay currently has a selection of AMD GPUs with 8G of RAM under $200. I ve had some problems with the GPU in my workstation crashing as described in my previous post where I thought it was driver issues [3]. I now believe that there are hardware issues and will look into buying one of the cards with 8G.
Further Investigation
I need to determine which of the AMD GPUs that are currently going cheap on ebay are best. While my current PC has support for 150W PCIe power I d rather something less power hungry than that. I have occasional issues of mpv reporting that my system is too slow for a video so slightly more compute power on the GPU would be good, but I think that every available option has significantly more compute power.
I need to find out what the relationship is between screen resolution and GPU memory. If I get an 8K display or an array of 4*4K displays (which is quite plausible as 27 4K displays go for $230 each) will I find 16G of GPU RAM as limiting as I find 4G now?
The nvtop program tracks PCIe data transfers for AMD GPUs, I haven t yet seen more than 25MB/s and I need to do more tests to see what the maximum is. Running on an Intel Battlemage card nvtop doesn t report PCIe data transfer speed which is a missing feature in either the driver or the program. I need to find out where the problem is and report a bug if someone hasn t already done so.
The GPU RAM use of some applications seems excessive. 440M for a lockscreen? 100M+ for a terminal emulator? 320M for Thunderbird?
The Folded Sky is a far-future space opera and a fairly direct
sequel to Ancestral Night, but with a
different protagonist. You do not need to have a vivid memory of the
previous book to read this one. It is somewhere around Elizabeth Bear's
31st (!) novel, depending on how one counts and what one includes.
Sunyata Song is an archinformist, which is sort of an archaeologist, sort
of a librarian, and sort of a historian. She recovers, decodes, and
organizes information so that it can be preserved and made usefully
available. As the book opens, she is, after an exceedingly long white
space journey in an actively hostile ship with a (to Sunya at least) an
atavistically off-putting crew, reaching her goal: a vast artifact that I
won't describe further to avoid any spoilers for Ancestral Night.
She is eager to get to work, an eagerness that is both heightened and made
more anxious by the discovery that her academic rival and abusive ex has
arrived before her. The pirate attack doesn't help, nor (at least at
first) does the surprise appearance of her wife and kids.
The opening of this book is a lot of infodumping mixed with nearly
stream-of-consciousness emotional dumping. The style shift in this series
continues to surprise me; previously, Elizabeth Bear books avoided reader
hand-holding to the point of bafflement if you weren't paying close
attention. Not here. The Folded Sky takes the shift perhaps too
far, and I almost stalled out at the start of this book when Sunya's
near-constant self-conscious litany and analysis of fears and concerns
started feeling like whining.
The book picks up considerably after the attempted murder.
About a third of the way through, The Folded Sky feels like it's
settling into a recognizable subgenre of murder mystery except set in the
far future with fascinating technology and aliens. There has been an
attempted murder on a closed station besieged by pirates. There is a law
enforcement officer present, but they don't have a lot of investigative
experience. For various reasons, Sunya decides to start poking around
while being conscious she has no idea what she's doing. The bumbling
detective is a common trope, so I thought that was where the story was
headed.
It is, sort of. There is a mystery and Sunya is involved in solving it.
But that's only a small fraction of what's going on, and by the end of the
book the plot has shifted firmly back to the genre of space opera, with a
side note of family... drama is the wrong word. Whatever one would call a
story about raising a rebellious teenager while trying very hard to not
turn conflicts into actual drama.
I am fascinated by the characterization of this book. Sunya is something
of an emotional mess, but Bear doesn't use that fact in the ways that I
would normally expect. Similar to Ancestral Night, I finished this
book thinking that The Folded Sky is primarily an examination of
rightminding, but a more subtle one than the previous novel.
Rightminding is a central technology of the White Space series, and I
suspect its intended thematic core. Humans in this civilization are
equipped with near-universal implants that allow conscious manipulation of
one's neurotransmitters and thus emotional state, either by the wearer or
by a helpful nearby AI. The fox, the implant used to accomplish this,
comes with some other features such as sensory recordings and the ability
to load ayatanas (James White style
personality recordings to provide some bit of necessary expertise), but
rightminding is its primary and most frequently-used function. It is the
critical technology that allowed humans to break out of cycles of endless
war and join the other peaceful inhabitants of the galaxy in a shared
civilization.
The name is (intentionally, I assume) Orwellian because Bear knows that
many readers, particularly those from the US who have been steeped in
simplistic libertarian ideas, will find the idea profoundly creepy. (This
was a major plot point in Grail.) This
book is not the argument for the technology, though; Bear dealt with that
in Ancestral Night. This book is a look at its practical messiness
for a person who needs a lot of psychological support.
Sunya is anxious, prone to catastrophizing, hates surprises, has some
PTSD-style symptoms around space habitats due to earlier trauma, and is
also dealing with the unwelcome reappearance of her ex-girlfriend who
stole her work. Her first-person narration tends towards insecurity and
anxiety spirals, and in another book this might signal an unreliable
narrator. In this book, though, there are no dramatic emotional
revelations or backstory twists the way there were in Ancestral
Night, and the resolution of her troubled relationship with her daughter
only partly hinges on plot developments. Instead, Sunya muddles through,
with a lot of self-analysis, help from her fox, and a great deal of
support from her wife.
This makes it sounds like the emotional mess at the start of the book is
left unresolved at the end, but that's not true at all. The muddling
through works! Sunya keeps doing things that I thought were foreshadowing
some catastrophe, but she knows herself better than the reader does. Bear
largely avoids the sudden ruptures that are normally used to resolve
emotional problems in fiction. Instead, Sunya spends a lot of time and
energy working on her thinking and her relationships while trying to be
ethical and useful, and those efforts slowly bear fruit.
I'm worried this makes the book sound boring; rest assured that it isn't.
This emotional subplot is only an undercurrent in the novel, and the main
plot has enough weird science, alien aliens, and space opera drama to
satisfy my page-turning desires.
I'm focusing on the emotional arc in this review because I find it so
unusual and so oddly compelling, particularly in retrospect. This is not
how one normally does emotional development in a novel. Sunya's fox and
rightminding aren't even the focus except when the pirates express their
typical libertarian disgust for the idea. Rightminding is an entirely
normal part of Sunya's life that she relies on. It doesn't solve all of
her problems, but it gives her a foundation from which to tackle them in
the slow and frustrating and inconsistent way that is required outside of
novels, via a long series of small decisions to be the person she wants to
be.
I think The Folded Sky will be more hit and miss for readers than the
other books of this series. Sunya was, for me at least, a much harder
character to like early in the book, and it takes quite a while for the
plot to get going. But this is one of those books that I've not stopped
thinking about since I finished it. I think it makes a fascinating pair
with Ancestral Night. The first book makes the philosophical
argument for rightminding, and this book shows the practical reality with
all of its messiness. The Synarche has some significant flaws (including
the status of AIs, which is another interesting subplot), but it's a
workable system.
It feels rare to read a science fiction novel that shows this level of
messiness without pairing it with an argument for radical change, and as
frustrating as it was to read in places, I am intrigued by the overall
effect. Sometimes acknowledging problems and working on them within an
existing framework works.
Followed by a book tentatively titled Shipwreck Star that does not
yet have a release date.
Rating: 7 out of 10
Please consider supporting my work in Debian and elsewhere through Liberapay.
Some months ago I started working on a small experiment: a specialised LLM assistant for Debian maintainers preparing proposed updates for stable and oldstable.
The aim is not to replace review by the Stable Release Managers, nor to automate away maintainer judgement. It is meant to be a pre-advice tool: something maintainers can use while they are still preparing a proposed update, before sending it to other people to review.
If you ve uploaded to stable before you may have some experience with our acceptance criteria. Does the version sort correctly? Is the changelog clear enough? Is the delta focused? Are the patches documented? Are the right bugs or CVEs mentioned? Are they of sufficient severity? What is the risk to users of stable? Is there an ABI change hiding in the diff?
These are the sort of checks where a structured first pass can be useful, provided it is treated as advice rather than authority.
To explain what the tool does, what could be more appropriate in an AI age than to ask it?
Describe yourself and your abilities and limitations for a blog post.
It answers:
I m Debian Stable Update Adviser, a specialised ChatGPT assistant for Debian maintainers preparing proposed updates for Debian stable and oldstable.
My main job is to review a single .debdiff and give practical, policy-aware feedback before a maintainer submits or uploads a proposed update. I focus on whether the update appears suitable for Debian stable or oldstable, especially under the Stable Release Managers expectations for minimal, targeted, low-risk changes.
I can inspect a debdiff for Debian changelog quality, including suite, version, bug references, CVE mentions, and rationale. I can check version correctness using Debian dpkg version semantics. I can review packaging changes under debian/, such as patches, maintscripts, symbols files, conffiles, Build-Depends, autopkgtests, and control metadata. I can also group upstream source changes into behavioural and non-behavioural categories, and flag areas that may carry regression risk.
My reports are intended to be concise and useful to maintainers. A typical review includes a quick summary, behavioural and non-behavioural change breakdown, mechanical policy checks, risk assessment, stable-policy checklist, acceptance likelihood, rationale, maintainer advice, and a clear conclusion.
My limitations are important. I cannot prove that a package builds, that tests pass, that the bug is fully fixed, or that the Stable Release Managers will accept the upload. I also do not replace maintainer judgment, archive review, autopkgtest results, reproducibility checks, or real-world upgrade testing. I can only review the provided debdiff and point out likely issues, risks, and improvements.
I also do not proceed without a valid debdiff. The whole point of my review is to assess the actual proposed delta, not to speculate from package names or bug descriptions alone.
In short, I act as a focused pre-review assistant for Debian stable and oldstable proposed updates: useful for catching policy, versioning, changelog, packaging, and regression-risk issues early, but not a substitute for the Debian review process itself.
That last point is an important one. This is not an oracle, and it is not part of the Debian archive machinery. It is a checklist with some language-model assistance, aimed at reading a debdiff and pointing out things that might be worth another look.
I know that commercial AI and LLM tools are not universally welcome in Debian. That is understandable. Debian depends on transparency, human responsibility, licensing clarity, and technical correctness. LLMs have obvious problems in all of those areas. They can be wrong, and worse, they can be wrong in a fluent and plausible way. They are impossible to reproduce and their training is opaque.
But I see this as a useful first pass for a maintainer who is unused to working in stable, and would benefit from a virtual mentor giving their proposal a quick check and reassurance. Perhaps they don t have a more experienced co-maintainer to ask. Perhaps they are conscious that stable reviews are presently a two-man effort and want to avoid adding round trips to that load. Perhaps they just need some reassurance.
So despite my reservations I am today opening the adviser up for general use, and I m interested in feedback about how it responds to real world proposals in various states. Most of the examples I have tested with already had a green light, so the value added by the adviser is limited. I would especially be interested in seeing a transcript alongside the submitted debdiff.
Try it out
I would dearly love to build this in a more Debian-ish environment, but for now I m limited in resources and skill to do that (help is welcome). Until that s a reality, you can try out the ChatGPT implementation: Debian Stable Update Adviser
Platform Decay is the eighth book in the Murderbot science fiction
series. You absolutely should not start here, but you also don't need to
remember the specifics of the previous books.
As the story opens, Murderbot and a friend (the identity of whom is a
spoiler for previous books) are infiltrating a Corporation Rim torus, a
massive space station that encircles a mined-out planet. (Like most
science fiction megastructures, this is more space than the plot really
requires.) Murderbot's mission is to exfiltrate some of Dr. Mensah's
family members who have become entangled in corporate shenanigans. The
corporates are eager to get revenge for the events of
System Collapse, not to mention the
other times Preservation Station has upended corporate plans. Murderbot's
job is to stop them.
The group, in addition to one of Dr. Mensah's partners, includes an older
woman and a young child. Murderbot is analytical and of course not at all
emotional about children, which is reliably a good time. Also, the older
woman is gruff, stubborn, and thoroughly enjoyable.
There are, of course, complications that lead to picking up more children
and going through rather more of the torus than Murderbot wanted to
explore. Each section of the torus is run by a different corporation and
has a different constructed environment and visual aesthetic, so there are
a lot of opportunities for fights, daring escapes, and incidental trouble.
Also, well:
So I had installed a mental health module. I know, I was surprised I
did it too.
After the events of System Collapse, University Medical decided
that Murderbot needed a bit more metal health support.
The only reason I agreed to it was that the mental health module
didn't actually try to adjust my processing or core programming or
anything; it just monitored my organic neural tissue. When my neural
tissue started to generate weird chemicals and whatever, it would ping
me to "check in with my emotional state." Seriously, I could have
coded that myself.
(I told Dr. Bharadwaj that, and she said, "Would you have ever coded
that yourself?" which was totally unfair and also correct. I would
never have done that.)
Speaking as someone whose neural tissue sometimes generates weird
chemicals and whatever, I sympathize.
The specific form this module takes is periodic "emotion check"
parentheticals throughout the narration, which I found utterly delightful.
I ran that through risk assessment and it produced the equivalent of a
shrug.
(Emotion check: Shrug sigil right back at you, you piece of shit.)
This is otherwise an extended action movie sort of a book, much like
several of the early novellas. There are no major political or
interpersonal developments here and the usual cast (apart from Murderbot)
is mostly absent. Instead, we get an extended, dangerous journey through a
corporation-controlled habitat, mixed with Murderbot trying to interact
with humans in a way that minimizes its annoyance while being hopefully
reassuring. It's competence porn with awkward but surprisingly heartfelt
emotional bonding, not that Murderbot in any way wants to bond or would
appreciate that description.
I doubt this will be anyone's favorite entry into the series since there
are none of the big reveals or major leaps of character development there
have been in the past few books. But, like all Murderbot books, the
narrative tone is wonderful and all of the small asides and little moments
of character interaction are an utter delight. If you've gotten this far
in the series, you know what I mean and you'll be as happy to read more of
it as I was. There is a part of me that is hoping for some major plot
development, and I always want to see more of ART (who has no significant
role in this book), but Wells has the narrative style down so perfectly
that I would read and enjoy a book about Murderbot doing just about
anything.
If you're this far in the series, you probably don't need a review, and
since this is an action-heavy adventure rather than a character growth
novel, I don't have a lot more to add. There's a new short Murderbot novel
out and you want to read it. Recommended to everyone who enjoys the
series.
Rating: 8 out of 10
A new small package of mine just hit CRAN. The tl package wraps the (also
very new) rspdlite package
(announced last
week) to offer a lightweight and consistent logging interface from
both R and C++ that is also tiny, fast, capable thanks to rspdlite.
The rspdlite
announcement is a good place to get a first glimpse at that package;
the upstream spdlite
repo has all the details (for the C++ side of things). With tl we follow the same idea
that our spdl package
introduced: a simple consistent interface via just the tl::
prefix and the appropropriate logging level. In other words
tl::debug("Alert -- foo is at ' '", foo) will work from
both R and C++ (given a variable foo, and in the case of
C++ an extra semicolon). Just give it a try, and see how it goes. The
package is still young and small.
The NEWS entry for this release is also very simple and just
announces that we have a release. More details are in the ChangeLog
and the GitHub
repo.
In what is hopefully the conclusion of my hunt for a cheap tower server supporting REBAR [1] I have just bought a HP Z4 G4 with W-2125 CPU for $320.
Hardware
One interesting thing is that it has an adaptor from SATA power to 8 pin PCIe power. According to Wikipedia the 8 pin connector provides 150W at 12V [2]. According to Wikipedia SATA power cables include 3 12V pins each of which can deliver 1.5A [3] which is 54W. The system as I received it had a single SATA power plug connected so potentially 150W could be drawn from a connector designed for 54W. The first thing I did was to connect a second SATA power connector on the same cable so I could have connectors designed for a total of 108W supplying potentially 150W (and definitely more than 75W).
I found two versions of the specs for this system, this version seems to match what I bought as it references W-21xx CPUs [4] while this version matches what I would rather have with a W-22xx CPU [5]. The URL naming scheme implies that there are potentially at least a few other variants out there. So much for the buy name brand and you can buy two systems with the same model and have them work the same benefit you hope to get. Why don t they just name them G4.1 , G4.2 , etc?
It seems that W-21xx and W-22xx CPUs are incompatible, so the W-2295 scoring 30,804 multithread and 2,634 single thread on passmark that I hoped to get isn t an option [6].
The system is well designed for space efficiency, both it and the Z640 are 17cm wide but the Z4G4 allows my to close the lid with the Intel Battlemage card installed which doesn t come close to fitting in a Z640. It has 8 DIMM sockets and with the ready availability of 32G DIMMS that allows 256G of RAM which is the maximum the motherboard supports. That compares well to the Z640 that only has 4 DIMM slots and the Z6G4 which only has 6.
The system supports a maximum RAM speed of DDR4-2666 which is better than the DDR4-2400 of the Z640 but less than the DDR4-2933 of the Z6G4.
The NVMe sockets on the motherboard are a convenient feature. Most systems I run need at most two NVMe devices so this saves a PCIe slot which is important when dealing with GPUs that take 2+ slots. Also for systems that don t really need NVMe I can use some of the small NVMe devices that I have no other use for. 128G NVMe devices aren t even worth selling and 256G will be of little use in the near future. So when I move to gen4 Z servers I can use up some of them without wasting slots.
Using the lesser socket LGA2066 in the Z4G4 is a minor annoyance, but for a single socket system 18 cores is probably enough.
The BIOS has an option for single-socket NUMA, which is basically locking cores in a single CPU to specific RAM channels. I enabled it but it did nothing presumably because I only have 2 DIMMs. When I get more DIMMs I ll do some tests of that and compare it with NUMA on my Z840.
Variants
There are many different variants of the Z4G4 and the only way to recognise them is by the CPU not by any part number or serial number AFAIK. The first difference is between server grade CPUs (the W-2xxx CPUs) and desktop grade CPUs (the i7 and i9 CPUs). The systems with i7 and i9 CPUs don t support ECC RAM which makes them less reliable, gives smaller limits for RAM
The below table compares the Z640 which is my current desktop PC with the Z4G4, Z6G4, and Z8G4 systems. For the latter 3 I have included multiple options for the parts that differ in different models in the same name series. The Z4G4 I have is an early one which only supports W-21xx CPUs which means a maximum RAM speed of 2666 and the best possible CPU would only be 15% faster than my Z640. I can only use this for ML stuff as it s the only system I have with REBAR support (which works well).
Z640 (1 socket)
Z4G4
Z6G4 (1 socket)
Z8G4
DIMM slots
4
8
6
24
Max DDR4 speed
2400
2666/2933
2666/2933
2666/2933
Max DIMM size
32G
64G
64G
64G/128G
System Max Ram
128G
512G
192G/384G
1.5T/3T
CPU Socket
LGA2011-3
LGA2066
LGA3647
LGA3647
Best CPU
E5-2699A v4
W-2195/W-2295
Platinum 8180/W-3275
Platinum 8180/8280
Motherboard NVMe
0
2
2
?
Conclusion
In my previous blog post I concluded that the next step up for me would be DDR5 systems [10]. But now some of the LGA3647 systems are appealing. The Z8G4 would be a decent upgrade from my current Z840 build server and should be affordable long before any two socket DDR5 system becomes affordable.
The Z4G4 doesn t have any potential for useful upgrades. But for me it was a good cheap way to house a GPU that had already damaged the motherboard of one good system. If the Z4G4 has a PCIe slot break the way my Z840 did then it wouldn t bother me a lot. It was annoying to discover how limited this variant of the Z4G4 is after buying it, but at that price I can t complain.
A Z6G4 could be a nice workstation if I found one at a really low price. The only reason I d seek one out is if I had a need for a desktop workstation with REBAR support, which seems unlikely.
The Problem
In 2019 I blogged about getting a 4K monitor because of my vision being inadequate for a 2560*1440 monitor [1]. Now I m using a 40 5120*2160 monitor [2] and still trying to find the correct balance between how much I want to see on the screen and what I am physically capable of seeing on screen.
Currently Kitty is my terminal emulator of choice [3]. What I most like about it is the feature of having multiple terminal windows in a single OS window, so instead of having 9 or 16 different xterm instances running all with possible alignment issues I have a single window for all terminals which can be brought to the foreground. The impending 6.7 release of KDE (my favourite Linux desktop environment) [4] includes the feature of per-screen virtual desktops which might be the feature I need to make multiple monitors usable for me. One of the factors stopping me from using multiple monitors in the past was the issue of not getting the alignment of dozens of xterms right if a monitor goes to sleep mode and is regarded as disconnected, moving a few Kitty windows is much easier than moving dozens of xterms (also a tiling window manager isn t my style).
I ve just decided that the Terminus font (my favourite out of the monospaced fonts in Debian) is too small for me at 9.0 point. But then I tried 10.0 which looked really ugly and an experiment showed that 10.5 looked good.
What I ve Learned
This is the best explanation I ve seen of how ridiculous the whole font point thing is [5]. It doesn t and won t ever correlate to pixels. So what we ideally want to do is set the size on screen to match the actual pixel size of the font. I can t find any software to interrogate a font file and find out what sizes it supports. The web page for the Terminus font says that it supports 6 12, 8 14, 8 16, 10 18, 10 20, 11 22, 12 24, 14 28 and 16 32 [6]. So the question is how to get a terminal program that uses one of those.
Kitty doesn t and won t support specifying font size by pixel. I tried some other terminal programs, I started with the Debian Wiki page TerminalEmulator [7] which wasn t very helpful, I added some new entries to that page. There doesn t seem to be another option for a terminal emulator with multiple terminals in one OS window that can arrange them automatically. I didn t even get to the stage of checking whether other terminal emulators supported font size in pixels.
The lcdf-typetools package contains the program otfinfo which gives some interesting information on fonts but nothing about the font sizes in pixels.
Sites like Coding Font to compare fonts [8] can never work properly as the fonts will always be slightly different sizes as the same point size doesn t mean the same display size.
The Current Situation
On my 5120*2160 monitor with 9 Kitty terminal sessions with 9.0 point font they each have 277*50 characters. With 10 point it s 237*46 but fuzzy and unpleasant to read. With 10.5 point it s 208*43 which isn t as good as I m used to but is still almost 4.5* as many characters as the original 80*25 standard for terminals.
Some time before 2019 I had a 4*4 array of terminal windows that were 100*25 or 120*25. That left some space at the right and bottom so I could open another 8 or 9 terminals that were partially obscured if I needed to. By 2019 before getting a 4K monitor I had a 3*3 array of terminal windows as my standard desktop and a larger monitor that did 4K resolution allowed me to have 16+ terminals again. Now with Kitty I routinely have 9 terminals in a 3*3 array and I can easily open more if I need them and have them resize appropriately.
This situation works reasonably well, but the element of just trying different sizes in 0.5 point increments until I find something that looks good is unpleasant. I should be able to specify the next largest increment of the bitmaps in the font and just have it look good.
Conclusion
It would be good if more people tested the terminal emulators in Debian and added information to the wiki page about them. The current page is useful but needs more information to support the variety of features that people find important.
We need some tools to provide information on fonts in Debian, such as the sizes of bitmapped fonts.
The whole point size thing is just wrong and would ideally go away. The vast majority of font use nowadays is for things that will probably never end up on a printed page so trying to map it to a physical size in fractions of an inch makes no sense. But that s just one of many horrible things used for backwards compatibility that aren t going to go away any time soon. Really everything involving inches should go away.
Through work, I have paid license to windsurf
(recently renamed to "devin"), an application for LLM-based (aka,
"Agentic") development.
I hadn't been using it that much, but in an effort to more clearly
understand how this whole AI development thing works, I decided to give
it a closer look recently.
My conclusions:
In its current form, this whole LLM wave is problematic for multiple
reasons. But ignoring that, and looking at the technology only, I can
say that:
it is a paradigm shift;
it is, at the technological level, a positive evolution;
and it is a threat to free software.
Problems
Lest someone (incorrectly) assume that I am arguing in favour of the
current state of affairs with regards to LLMs, let me state this first.
The way LLMs are built today is highly parasitic. Websites are
downloaded in whole, at unsustainable rates, regardless of the consent
of the people who made the original content. The result is predictable:
servers get overloaded, server administrators attempt to implement
various mitigations. Some of these mitigations work; some do, for a
while; some are entirely useless. In actual fact, the mitigations are an
arms race -- if too many people implement the same mitigation, then the
people who try to build yet another LLM so they can extract rent will
just try to work around the mitigation, eventually they will succeed,
and you'll just have to come up with another mitigation. It's a bit like
spam; you introduce regex-based spam filters, they introduce spelling
mistakes, you introduce bayesian filters, they add a large batch of
markov chain-generated semi-nonsense words made invisible by markup, you
add filters to block emails with such markup, they move the text into an
image. We have working mitigations today, but eventually we'll run out
of ideas.
LLMs glob up everything they can while ignoring the license of the
source material. The people who push those LLMs claim that pushing the
source material through the machine learning algorithms makes the output
of the algorithm distinct enough from the source material that the
license no longer applies; I'm not so sure that this is true. I guess
the New York Times v OpenAI
lawsuit
will teach us some of the answer to that question here, but even so
the ethical questions about "is it OK to bring down another server just
so we can download the internet for another for-pay LLM" are still
open. And regardless of what the law states, my opinion on "you're using
my copyleft code to generate code under a different license" is not
something you might like if you agree with the rent seekers' opinion on
the subject.
That all being said and true, the technology works. You can have a
"conversation" with an LLM that resembles a human one. If you pass it
some data, you can use plain english to ask it questions about that
data, which is a lot easier than to ask it about that in a formal way.
You can request it to generate some code, and it will generate something
that looks like what you need and that will be mostly correct for like
95% of the time.
Now, yes, 95% of the time is not 100% of the time, and no, you can't ask
it to "write me a piece of software that implements this 300-page
requirements document and get back to me when you're done", because it
will fail, and you won't know where it has failed, and you'll take it
into production and expect everything to be fine because it won't and
this one minor logic bug will cause half your servers to spin and
consume credits with your infrastructure provider with nothing to show
for it.
But that doesn't mean you can't use an LLM to build a large piece of
software. It just means you have to understand the LLMs limitations and
strenghts, and use them correctly.
Here's what an LLM is good at:
Generating plausible text
Interpreting text to figure out what a plausible meaning or summary of
that text is
Giving vague indications as to what the probable context of a given
body of text is.
It turns out that that's enough to use the LLM to build a reliable piece
of software, provided you do it right.
Paradigm shift
An LLM can generate text by the truckful. The generated text could be
code. Given a good enough LLM, the generated text might even run and do
something useful.
You can try to blindly run the code, and if it doesn't run correctly,
you can paste the error message to the LLM, and it can tell you what
went wrong and how you could possibly fix it. This creates a feedback
loop: you ask it for an amount of code, you run the code, you receive an
error, you tell it that the code is problematic and give it the error
message, it makes changes to the code, now you have something that at
least no longer fails at startup.
If you ask it to add tests to make sure that your code acts as per your
specification, now you get an error if and when the code doesn't act
as per your specification. Or, well, at least not as per the part of the
specification that was correctly turned into a unit test by the LLM.
LLMs have a context window, so if the error message is pasted in the
same conversation as where the code was generated, it is able to reuse
the earlier prompts to refine how it should interpret the error message
that you received.
You can't really paste the source code of an entire application into the
prompt of your LLM, that would quickly overrun its context window. But
LLMs also allow you to provide some form of background information --
a document, say -- on which you ask it to reason. It will interpret that
document, but doing so uses less of the LLMs context window. So
providing the LLM with your application's source code as background
information can help it understand better how your code interacts. This
is especially helpful if you only provide the LLM the background
information relevant to the actual question.
So now if you are able to:
Create background context with your application's source code
Have the LLM generate a first draft of your requested change, plus the
tests to make sure it works
Compile (if applicable) the generated code (and tests) and run said
tests
Return any error messages to the LLM with a request to correct the
error
Then the combination of "getting it 95% right off the bat" and the above
feedback loop means you can generate syntactically correct code, that
probably does what you need, in minutes.
I say "probably" for a reason. There are going to be cases where you
specify a request without a number of details (because they are
implied), and the LLM will get most of those details right but just not
implement the one bit because it's an automaton and it doesn't think. Or
you will ask it to make sure that two bits of the application look
exactly the same, without specifying that they must act the same, now
and in the future, and it will just generate the same block of code
twice and then in a future change it will change one but not the other.
But if you review the changes, and you have experience as a
programmer, you will be able to spot most cases where the LLM got it
wrong. And so it's possible, if not necessarily easy at first, to
use an LLM to generate mostly correct code.
There are certain places where "mostly correct" code is not desireable.
But equally, there are also cases where, "mostly correct" is good
enough.
After all, most of the software you run today -- the bits of it that
weren't, yet, generated by an LLM -- is only "mostly correct", too,
because to err is human and we all make mistakes. If not, there wouldn't
be any CVEs and your software would never do anything wrong.
Now, doing the feedback loop described above is certainly something you
could do manually. You could open an account on one of the LLM websites,
upload the source code of your application, ask it to generate some new
feature, download the newly generated feature, run it, and then
copy/paste any error messages back into the LLM.
But that's a lot of manual work of the type that computers are pretty
good at. So that's what the "windsurf" tool helps you with: you run it
inside your IDE -- either a VSCode-based tool that you download from
their website which comes with their product preinstalled, or a separate
JetBrains plugin that you can install. You can then open your entire
relevant codebase in a workspace in your IDE. You then ask the LLM,
through the IDE, to generate a new feature in your codebase, and to also
generate the test while it's at it. It will use a mixture of LLM
interpretation and non-LLM functionality to scoop out the relevant bits
of your codebase to send to the LLM as background information, will send
it your prompt, will download the generated code and patch or create
files, will compile (if required) and run the newly generated code and
tests, and will refine the generated code if the tests produce any
errors. All mostly automatic; by default, running anything requires
explicit confirmation. You can turn that off completely (probably not a
good idea), or you can give it a whitelist of things that you don't want
to confirm (perhaps OK), and the tool also passes standing instructions
to the LLM to never generate any command that deletes a file (which,
like with any LLM, can be overridden, but it requires you to be very
stubborn and to use more credits than you'd probably like).
All this put together means you can build something without writing any
piece of code, provided you do it right.
A technically positive evolution
Don't go and say, "here's a 300-page document, read it and write
whatever the document says". It will get it wrong, it will write a
massive test suite that it will only run at the end, it will choke
itself up trying to interpret the massive amount of failures it
encounters, it will fill up its context window and it will start to
forget some of the requirements. That won't work.
But what you can do -- what I did, in fact -- is this.
First, create an empty workspace. Don't put any code in it.
Then, tell the LLM to generate a backend framework using technology X
and a frontend framework using technology Y that initially only says
"hello, world". Also add tests to it, and run the tests.
It will do that. You'll not get much, but it will work.
Then, ask it to add some UI elements. A login page, perhaps. A
navigation bar. Small things. Most of it doesn't have to be functional
-- but tests must be there for the bits that are, and have it run the
tests and evaluate the results.
Rinse, repeat, until you have a working application.
Importantly, in between the steps, you should also run the application
yourself and see if the change was implemented correctly. Sometimes it
won't be. Sometimes there will be a subtle bug -- I at one point had a
the application hang after a few minutes. Sometimes you tell it that
there's a subtle bug, and it will discover it more quickly than you
could, and it will fix it, and in implementing the fix it will uncover
another bug, and then you have to fix that one -- the fix it came up
with for the hang was to move something to an async process on the
server, which caused the application to start spinning while trying to
create hundreds of async jobs (this is when I realized that the hang was
a deadlock due to some part of the codebase doing something that
indirectly triggered itself). Sometimes it will try to fix the bug you
tell it about, and you'll see that it's going off on a tangent that has
nothing to do with what you're seeing. It's important to keep an eye on
what it's doing, so you can guide it back on track when that happens --
when I told it about the hang, it started investigating the part of the
code which sends out emails, thinking that it could hang while waiting
for sendmail to finish, but the hang was happening when the
application was idle, not when it was sending out emails, and only
when I told it about it happening when it was idle did it find the
deadlock.
So it's not a fully automatic process, and it needs to be guided by
someone who knows what they're doing. But if that is the case, you can
come up with something that works. I spent evenings and breaks for about
a week, and I managed to create a working application which, had I
written it by hand, would have taken me a few months of full-time work
to come up with. And I now have a side project, fully complete and
working, that I had been thinking about doing for more than a decade,
but never got around to actually doing, because of all the work that
would be involved and I just didn't see myself having the time for.
It's not perfect code. But it's mostly good enough, and it will perform
the job it needs to. And it looks far slicker than most of the side
projects I've done in the past, because in the past I would prioritize
between implementing new features or making something look slick, and I
would decide that the new feature was more important because it's only
for me and there's only me and nobody cares if it looks good or not and
I don't have three weeks to come up with something that looks better.
But here, I found myself sometimes spending 10 minutes writing a prompt
with instructions on making things look better. Because what's 10
minutes when you just spent an hour writing down and refining
specifications for functionality and tests?
There are a number of other things in which an LLM can help a
programmer.
For instance.
I received a bug report recently in a project I'm paid to
maintain that I couldn't make heads
or tails of. I opened the source code in my windsurf IDE, pasted the bug
report in the prompt, and then requested the tool to analyze the source
code and the associated logs and tell me how the described behavior
could be happening. It turned out that I had overlooked something, but
with the help of the tool, I found the bug in minutes.
I was trying to understand a particular part of a large
codebase that I didn't really grasp very well.
I loaded the codebase in the tool, and asked it to explain to me how a
particular action is performed by the code. I requested specific
functions and line numbers. I now have a far better understanding of how
the code works, and will be able to write that patch that I've been
wanting to write for years -- without using the LLM.
I have been struggling for, literally, years with understanding why
another tool that I
maintain was
misbehaving in a particular way but only in Firefox. I opened the
codebase in Firefox, explained the buggy behavior in plain English, and
asked it to explain how this could be happening. It picked up some
obscure corner case behavior of ffmpeg and mp4 containers that I was not
aware of and that perfectly explained why things were misbehaving in the
way that they were.
At the same time, there are limitations. Giving an LLM a codebase that
was originally generated by an LLM (either the same one or another one)
seems to work well. Giving it a codebase that was written by a human and
expecting it to correctly update it seems to be more error-prone. I did
one or two of those as a trial, and it is more problematic than
anything.
An LLM is also not intelligent, notwithstanding the popular term of
"Artificial Intelligence". On multiple occasions, I've asked it to write
a test case for some code that was not set up to do so; and rather than
suggesting a refactor is required, it would instead copy the code that
needed to be tested and then test the copy, rather than the original.
The tool has made multiple similar errors. I have sometimes people
describe agentic coding as "similar to interacting with junior
programmers", but that is not the case. A junior programmer will either
fill in the gaps in your specifications, or ask for clarification when
something seems off. The LLM will not do that; it will do what you ask,
exactly that and nothing more. If you missed a corner case in your
specification, then all bets are off.
I remember learning about programming language generations in college.
A first-generation language is "machine code", a second-generation
language is "assembler", a third-generation language is any high-level
language such as C, Perl, or Pascal. I've forgotten what set a
3rd-generation language apart from a 4th-generation language. But I
remember the definition they gave me for a 5th-generation language: "you
tell the computer what to do, and it will do it". At the time, I thought
it was ridiculous. Nobody could ever write something like that.
But it's here.
And it's a threat to free software.
A threat to free software?
Yes.
There is the obvious part where most of the well-known LLMs are non-free
software. I mean, there
are
some "open source" LLM models. The windsurf tool that I used doesn't allow
you to use them (directly), but they're there. There are also open
source applications that implement what the
windsurf editor does. So it's definitely possible to work like this
without resorting to non-free software and non-free services, even
though the non-free LLMs might be a bit ahead of the curve of the free
ones. But that's not what I mean.
And there is also the obvious thing which I mentioned earlier in this
post, which is that the people who try to build LLMs are doing it in
unethical, disgusting ways, causing downtimes and disregarding licenses
for whatever they can get their grubby hands on. Ideally we wouldn't be
in that situation, and ideally this wouldn't be a problem, but we are
where we are.
And there's the obvious thing where the OSI sold itself out and declared
that a machine learning program can be open source even when the very
things it was built from -- the training data -- is not available.
That's a major issue that the free software community needs to fight
against, but there's not really anything that that is a threat to free
software. You just build your own, free software, LLM, and you're done.
The actual threat is in funding and developer support.
Most large businesses do not care about free-as-in-freedom software.
They like the free-as-in-beer part, and they appreciate that the
free-as-in-freedom bits can make the software more customizable. They
are (mostly) happy to do sponsorships of the free-as-in-freedom projects
that they use if that means their free-as-in-beer usage of the software
gets improved.
But why would you care about all that when you can just generate the
code you need, rather than interacting with an open source community
that may or may not care about your business's interests?
Where to go from here
Although I think the moral and environmental issues with LLMs are real
and problematic, given the experiments I did I am not convinced that the
concept of interacting with a computer system in natural language and
to use it to generate code is necessarily deficient. There are pitfalls,
but they can be managed. It is possible to use such a system to create
throwaway, proof-of-concept type "good enough" code bases. It can be
used to interpret code bases and to understand bug reports.
I believe that the major issue with LLMs has to do with that saying
about hammers and nails:
If all you have is a hammer, then everything looks like a nail.
LLMs are an outgrowth of machine learning, pushed by large corporations.
These large corporations have a lot of money. If all you have is money,
then every problem can be fixed by throwing more money at it. The
initial language models were promising but not (yet) good enough, and it
seemed that one way in which they could be improved was to increase the
scale of the statistics: throw more hardware (and thus money) at it, and
rather than improving the efficiency of the models, just scale up.
Scaling up is something that megacorporations are very good at. It's
only a money problem, after all. Does that mean that "scaling up"
is the only way to improve the models, though? I'm not convinced.
Some hardware, such as most modern Apple and Samsung devices, ship with
accelerator hardware for machine learning algorithms. There are some
models that are small enough to be able to run on these devices. I don't
see why it should not be possible to create a small(er) language model
that can do some useful part of the above-described use cases; if not
locally, then at least on a server that one can run on-prem rather than
requiring that you pay rent to one of the LLM companies.
The Software Freedom Conservancy has
published an aspirational statement on machine learning-assisted
programming
that, I think, gets a lot right. It's not quite a definition, but it's
something to keep in mind.
Perhaps that's the way forward?
More questions than answers at this point, anyway.
Activity summary
During the month of May, 21 contributors have been
paid to work on Debian LTS (links to individual
contributor reports are located below).
The team released 56 DLAs fixing 877 CVEs.
May was a much busier month than usual, especially due to the disclosed
vulnerabilities on linux regarding Local Privilege Escalation (LPE), that
included public proof-of-concept (PoC) exploits. These reports of course
impacted Debian as a whole, and the situation warrants a special mention to the
Kernel Team, especially Ben Hutching and Salvatore Bonaccorso, who faced the
pace and released linux packages on a weekly basis. On the LTS side, the Front
Desk team also
triaged a significant flow of high severity CVEs.
It is also important to note that
Debian 12 ( bookworm ) will be
handed over to
the LTS Team on June 11th. If you benefit from Debian, especially during the
full 5-year lifecycle, please consider subscribing as a sponsor of Debian LTS:
https://www.freexian.com/lts/debian/.
Moreover, Debian 11 ( bullseye ) will reach the end of the Debian LTS period on
August 31st. After that, Freexian will continue the security support under the
Extended LTS offer.
The team published several notable updates:
As mentioned above, several exploitable LPE vulnerabilities in linux were published during May. Ben released the following DLAs for the Debian LTS versions:
exim update
(DLA-4580-1),
prepared by Thorsten, to address a vulnerability that may result in remote code
execution.
gnutls28 update
(DLA-4595-1) by
Guilhem Moulin, fixes several vulnerabilities that may result in execution of
arbitrary code, information leak, authentication bypass, among other impacts.
krb5 updates released as
DLA-4603-1, fixing
two vulnerabilities that may yield to a denial of service. Updated prepared by
Emmanuel Arias
lemonldap-ng
(DLA-4602-1),
released by Abhijith PA, fixing multiple vulnerabilities
Two imagemagick updates
(DLA-4559-1 and
DLA-4609-1), prepared
by Bastien Roucari s, fixing several vulnerabilities
openjdk-11 and openjdk-17 updates
(DLA-4566-1 and
DLA-4565-1), both
prepared by Emilio, to fix seven vulnerabilities.
php7.4 update
(DLA-4586-1) to fix
six vulnerabilities that could result in remote code execution, information
disclosure or denial of service. Update prepared by Guilhem Moulin.
python3.9 update (DLA-4583-1), prepared
by Arnaud Rebillout, addressing multiple vulnerabilities.
Contributions from outside the LTS Team:
We are greatly thankful for the contributions from people outside the LTS Team:
Colin Watson prepared an OpenSSH update, that was released by Santiago as
DLA-4584-1.
Thomas Goirand handled a keystone update, whose advisory was done by Santiago
and released as
DLA-4611-1.
Christopher Obbard kindly prepared a sentry-python update, released as
DLA-4612-1.
Christoph Goehre made two thunderbird updates
(DLA-4562-1 and
DLA-4582-1). As is
customary, Emilio released the advisories.
The LTS Team has also contributed with updates to the latest Debian releases:
Andreas proposed a firewalld update
for bookworm to fix a local issue that may result in bypass control rules.
Andreas proposed atril updates
for trixie and bookworm.
Thorsten completed the uploads of zvbi, taglib and libuev to bookworm and did
an upload of libcoap3 for
wtrixie.
Tobi prepared libpng1.6 updates for trixie and bookworm, released as
DSA-6263-1.
Moreover, thanks to our partnership with Catalyst, it has been possible to extend the support for Samba 4.17, the version shipped with Debian 12. In May, several vulnerabilities were disclosed, and their patches were prepared by Catalyst. For Debian 12, the update was prepared by the Samba maintainer and released as DSA-6297-1.
There has been a video blog post recently published with a review of Ubuntu Touch as an option to opt out of the Android world: https://www.youtube.com/watch?v=wTK6TS3pXgc
Thanks to @SwitchandClick for spending time on this and publishing that video. Much appreciated.
Many Issues amended in upcoming 24.04-2.0 Release
When I watched that video referenced above, I continuously thought: ah... this is fixed in the next major release of Ubuntu Touch, or: ah... this is a known issue that we have on the roadmap..., or: ah... this is done in this ways by design (so it's a feature or basic functionality)...
Let me just state, that most of the criticized aspects will be resolved in upcoming Ubuntu Touch release 24.04-2.0 (the tests in that video blog post have been run on Ubuntu Touch 24.04-1.x):
Camera notch and rounding corners get honoured now by the UI
Ubuntu Touch's default webbrowser (Morph Browser) has been bumped from Chromium engine v87 (Qt5 based) to v134 (Qt6 based), installing another browser should not be necessary anymore (note that the privacy level in Morph Browser is pretty high, so using other browsers could mean a loss of privacy).
Bluetooth pairing agent got added to the bluetooth indicator
Ubuntu Touch now supports Snaps on CLI level and in the OpenStore app
Libertine has received fixes, but no substantial improvements. It mainly targets users who want to use their Ubuntu Touch device as desktop daily driver. Libertine-provided desktop apps UI-wise are often not usable on a phone-like device.
The full feature preview of the 24.04-2.0 release can be found here: https://ubports.com/blog/ubports-news-1/ubuntu-touch-24-04-2-0-beta-is-n...
Ubuntu Touch App Ecosystem
The app ecosystem of Ubuntu Touch is quite specific, because many apps in Ubuntu Touch have been explicitly developed for Ubuntu Touch using a widget toolkit called Lomiri.Components. However, in Ubuntu Touch we also encourage developers to provide apps written with other convergent-capable toolkits, such as QQC2-based apps or Kirigami-based apps.
One reason for the very different app ecosystem in Ubuntu Touch is that many service providers don't have Ubuntu Touch on their radar when investing in app development for their services. Some Ubuntu Touch App Developers work around this by either implementing unofficial client apps for web services (e.g. the Flow app for Deezer by Sander Klootwijk), others provide the web service via implementing a web app (will not work when offline, but at least will show up as an app in the launcher).
The overall solution for making Open-Store.io more familiar to users who migrate from Android is that commercial service providers start honouring digital sovereignty and start providing apps for Linux. Not just for the Linux desktop, but also for mobile Linux platforms. This dual use case can easily achieved with an app development that bears convergence in mind.
App Ecosystems are also a Matter of Perspective
And one more minor note: whenever I open an Android appstore or can peak over someone's shoulder using an iOS device: I always wonder: what are all these apps about??? Never heard about them.
So, familiarity really depends on perspective. And perspective depends on what you are used to. Change what you do and your perspective will follow.
Ubuntu Touch's root filesystem (rootfs) is Immutable
Only thing from that video blog post that we haven't fixed and won't do so in the midterm future is apt-get not working on the command line.
The reason for this is: the Ubuntu Touch root file system is an immutable file system and thus shall not be changed via apt-get & friends by ordinary users.
There are various discussions ongoing such as dpkg-divert'ing apt-get to a wrapper shell script that spits out an error message if rootfs is mounted read-only and someone tries to install packages the Debian/Ubuntu way. Other approaches are to mount some RAM disk over the rootfs, so apt-get can be used at runtime but changes to the system get reset at reboot.
However, it is possible to mount the root filesystem read-write and test newer package versions (as UT core developers do regularly, in fact). If you tinker with this, it is recommended to reflash your device (don't wipe user data, when you reflash!) from time to time, because adding packages or package upgrades to your rootfs may over time corrupt the integrity of the rootfs.
One reason for apt-get breaking the rootfs and thus your Ubuntu Touch development device is that the upgrade process of the rootfs image is incremental, so update tarballs sometimes contain only those parts that got changed between this and your previous upgrade (sometimes, upgrades contain a complete rootf image, depending on the interval between upgrades). If files from an incremental update tarball mix into a rootfs that got tinkered with via apt-get, you really end up on your own. Re-flashing will grab the complete rootfs tarball and wipe the whole rootfs and reinstall a fresh version of the newest rootfs image. Developers also do this in regular intervals to ensure their test device is clean again before running more/other tests.
Very happy to share that a new package rspdlite arrived on
CRAN today in its inaugural
version 0.1.0-1. It wraps and provides the (header-only) C++20 library
spdlite which its author
describes (aptly) as tiny, fast, capable. Just like its bigger
sibbling spdlog (which we
wrapped as rcppspdlog), it is
written by Gabi Melman. However,
with a focus on C++20 and compile-time configuration, it is lighter,
nimbler and faster. It is also still a fairly young project so changes
may occur.
I have been working on this for about a month, and it is ready for
use by R and C++. It contains the initial upstream release 0.1.0, and I
plan to follow the upstream versioning making this first release as
0.1.0-1.
The package itself provides the headers for use from other C++
projects (i.e. mostly other packages), as well as a simple R wrapper so
that logging can occur from either C++ or R. It will generally access
the single logger instance in a compilation unit. So for a package built
against these header it would be shared library of that package. At
present we provide the basic logging level setters and getters,
formatting accessors, and two (compile-time) options of a null logger
and a file-based logger. More options are availble from the C++ level,
multiple logging sinks are but one example. Some examples are provided
in the package as an R
example and a C++
example; these are probably best examined from the sources.
The NEWS entry for this release is simply and just announces that we
have a release. More details are in the ChangeLog
and the GitHub
repo.
The next Ubuntu Touch major release is approaching rapidly, yesterday we reached a major step in the preparation of the upcoming Ubuntu Touch 24.04-2.0 release: The branching-off (see below on what that is).
Ubuntu Touch 24.04-2.0 Beta is Now Available
Part of this development release step is the publication of the 24.04-2.0 Beta release images, for more details and information see: https://ubports.com/blog/ubports-news-1/ubuntu-touch-24-04-2-0-beta-is-n...
And additionally, find below some background information on how we maintain various Ubuntu Touch releases in parallel via Git(Lab). In fact, the release model of Ubuntu Touch has partially been adopted from how we in Debian maintains our various Debian versions in parallel, only that in Ubuntu Touch we use Git(Lab) for maintaining the different package versions and not, like in Debian, the APT archive itself.
What does 'Branching-Off' Mean?
Last Saturday, in the UBports Q&A, I explained Ubuntu Touch's "branching-off", an aspect of the Ubuntu Touch release workflow based on Git(Lab). To make this accessible to even more people, here it comes as a write-up:
We host many Git repositories on GitLab, and our primary work is done on the main branches, which contain the bleeding-edge code. When a merge request is deemed critical for stable versions of Ubuntu Touch, we cherry-pick it into a release series branch.
Currently, we land our changes in the main branches and then cherry-pick them to the ubports/24.04.1.x branches. The 'branching off' process for the upcoming 24.04-2.x release means that our current main branches will be copied over to create new branches for this release cycle, namely ubports/24.04-2.x.
This has two major implications. First, any item that hasn't been translated by the time of the branch-off will not receive any more translation updates during the 24.04-2.x cycle. This is why it is crucial that translation work is completed before the branching-off.
Warning of Breaking Changes arriving soon in 26.04-1.x Daily Development UT Images
Second, looking ahead to the release after 24.04-2.x, we will be approaching 26.04-1.x. The OS base will change to Ubuntu 26.04 LTS, hopefully being ready for release to Ubuntu Touch users before the end of the year. We already have a list of features we want to land there. Because we plan to include various major changes, such as the switch from Mir 1 to Mir 2, new calendar and contacts backends, Qt6-based core apps and service components, etc., the likelihood of breaking changes at the beginning of the 26.04-1.x release cycle (which will become the next main branches' target) is very high.
The Ubuntu Touch 24.04-2.0 Release Schedule
The current release schedule is estimated to be:
25 May 2026 [done]
Platform stability freeze 24.04-2.x
25 May 2026 [done]
String freeze 24.04-2.x
15 June 2026 [done]
Branching-off (and unfreeze 26.04-1.x development), UT image release: 24.04-2.0 Beta
22 or 29 June 2026 [coming]
Final freeze for 24.04-2.x, UT image release: 24.04-2.0 RC
6 or 13 July 2026 [coming]
Release version 24.04-2.0
Go default compatibility, by Helmut Grohne
At the MiniDebConf Hamburg, Andrew Lee
had prepared a talk on how Debian accidentally chooses Go compatibility.
Helmut joined Tobias Quathammer and Andrew Lee in looking into the problem.
Go has a compatibility system where modules declare a desired Go version to be
compatible with. This influences various features such as whether RSA keys
smaller than 1024 bits are accepted. Unfortunately, Debian s way of building Go
packages is unique in setting GO111MODULE=off, which practically implies a
very old compatibility version that enables a number of insecure settings. Most
Linux distributions use the default GO111MODULE=on and therefore consult a
go.mod file that often declares a sensible version. While doing so is the way
for Debian longer term, getting there involves major changes so we also sought
a more short term workaround. We developed a
patch to the Go compiler
that would enable it to pick up a compatibility version from the environment.
Tobias uploaded it to unstable. The next step is
communicating the declared compatibility version
from go.mod to the compiler via the new variable. Then, rebuilding the archive
resolves the immediate symptoms. This does not save us from having to perform
the larger transition to GO111MODULE=on, but this shortcut can be backported
to trixie.
Trimming build-essential, by Helmut Grohne
One of the harder problems of the architecture cross bootstrap is correctly
expressing the Build-Depends of glib during the toolchain bootstrap. It
implicitly depends on build-essential, which happens to depend on libc6-dev.
This poses a cycle. It applies even for cross building, because it is
interpreted for the host architecture and that there is no way of satisfying
this dependency during the toolchain bootstrap.
Given discussions at MiniDebConf Hamburg
with Jochen Sprickerhof and others, a seemingly stupid idea evolved: Let s
delete build-essential. What looks insane on the surface might deserve a
second look. Given how we moved away from C, C++ and autotools, what is in
build-essential no longer is required by much of the archive. With the rise of
debputy, debian/rules no longer has to be a makefile. While the task would
be huge, those packages relevant to architecture bootstrap could explicitly
support building without the implied dependency making their dependencies
explicit. In a number of cases, this amounts to issuing a dependency on
g++-for-host. This dependency requires the use of architecture-prefixed tools.
Therefore, Helmut wrote a debhelper change
that makes it always pass build tools to various build systems. This also
enables more packages to honour environment variables such as CC and CXX.
Python upstream engagement, by Stefano Rivera
Stefano attended PyCon US (at personal expense)
to improve upstream relations and ensure Debian s voice is heard where it needs
to be. On Friday there was a packaging summit
(notes) with good
discussion on the future of the wheel format, and some discussion of the new
abi3t shared library format for free-threaded python.
In preparation for the event, Stefano did a complete review of the current patch
stack.
Stefano s primary goal was to get some of Debian s patches merged during the
sprints, and results were mixed. Some trivial patches
(e.g. GH-150098, made progress
and merged, but the most consequential patch Debian is carrying
is still blocked. Stefano will
continue to try to drive progress on this.
Miscellaneous contributions
Carles worked on po-debconf-manager:
Reviewed Catalan translations for 6 packages, submitted 10 packages to
maintainers, and removed 3 packages from po-debconf-manager.
Carles worked on check-relations:
Continued improving the backend, including importing source package build
dependencies to better support analysis of Debian blends. Added support for
ignoring packages using regular expressions and source package names in response
to user feedback. Used the tool to report 5 new bugs and followed up on
previously reported issues.
Helmut sent a cross build patch on behalf of a customer.
Helmut uploaded debvm and guess_concurrency both featuring improved
reproducibility and documentation.
Helmut continued maintaining rebootstrap and made it correctly handle binNMUs
of gcc-defaults. Additionally, he poked at existing gcc patches giving answers,
rebasing or closing them.
Helmut supported the video team in Hamburg mixing audio.
Helmut continued to report undeclared file conflicts of various kinds and
corresponded with maintainers about them.
Antonio attended a debate during the Brazil Internet Forum
about the impacts of the child protection regulation (ECA Digital) on free
software operating systems.
Antonio worked on Debian CI to improve the system transparency for users. This
included listing any pending jobs explicitly in the job lists for each
package/architecture/suite page, as well as adding a
queue status page that users can check
for an estimate of test latency.
Antonio worked on several Debian CI maintenance tasks, including but not
limited to some monitoring improvements, replacing usage of fonts-font-awesome
with fonts-fork-awesome, and adding the ability in debci to configure a global
notice (which is being used in Debian CI to point to the system status pages).
Antonio started doing some tests related to the change of default Debian CI
backend from lxc to incus-lxc. This helped identify an omission in the creation
of incus-lxc images. It was missing dpkg-dev, which caused a few packages that
assumed its presence to fail. In the end, the incus-lxc backend will be fixed to
include dpkg-dev by default in the image, but that uncovered an undeclared
dependency in gem2deb (Ruby packaging helper) and in ruby-byebug, both
already fixed in unstable.
May included the discovery of several high-severity Linux kernel root
exploits. Stefano updated kernels and rebooted debian.social infrastructure
several times.
Stefano supported the Hamburg miniDebConf s
wafer website during the event, and set up an instance
for the 2027 edition too.
Stefano supported the bursary team issuing bursaries for
DebConf 26.
Stefano uploaded routine updates of python-pip, pystemmer, snowball-data,
snowball (making up a mini, uncoordinated snowball transition),
python-authlib, python-discovery, python-installer, python-mitogen,
python-pipx, python-cachecontrol, platformdirs, and python-virtualenv.
Stefano fixed a small number of bugs in dh-python, culminating in the
7.20260524 upload.
Thorsten finally managed to upload a new upstream version of hplip. He also
uploaded a new upstream version of epson-inkjet-printer-escpr. Last but not
least with the help of other contributors he could fix bugs in lprng.
Lucas and Santiago contributed significantly to the DebConf 26 Content team;
helping to organize the team, review and rate talk proposals.
Lucas also supported a packaging sprint held in India by rebuilding and
publishing the latest results of the Ruby 3.4 transition effort.
Santiago continued contributing to the efforts to organize DebConf 26,
especially supporting the local team with different tasks.
In collaboration with Emmanuel Arias, Santiago is mentoring Aryan Karamtoth,
a GSoC participant that is working to introduce linux live-patching support in
Debian. The GSoC project started in May, with community bonding and coding.
Santiago reviewed a merge request
to prepare the clang-extract package for debian. clang-extract is one of the
building blocks that will help to extract specific functions from large C code,
so only relevant code can be patched, without recompiling the whole original
basecode.
Anupa assisted Jean-Pierre Giraud with the point release announcements for
Debian 13.5 and Debian 12.14.
Colin backported various security fixes from OpenSSH 10.3 to all supported
releases (including LTS and ELTS).
Colin backported IP quality-of-service fixes to OpenSSH in trixie. The
situation there had been unsatisfactory for some time, and upstream reworked
their QoS support in OpenSSH 10.1 in a way that typically produces much better
results.
Colin imported new upstream versions of 26 Python packages, and fixed around
25 RC bugs for the Python team.
For almost two decades, the PackageKit package management abstraction layer has shipped with pkcon as its command-line client. pkcon does its job, but it was always kind of a testing front-end for the PackageKit daemon rather than a tool designed for everyday use. The focus has instead been on the GUI tools, automatic system updates, GUI application managers and other front-ends. Its command names mirror the D-Bus API almost one-to-one (get-details, get-updates, get-depends), output is very plain, and there is no machine-readable mode for scripting. Most importantly though, there has been no development on it at all for almost a decade, so pkcon was stuck in its rudimentary state from that era.
Since a lot of changes will be coming to PackageKit, and testing the daemon and working with it from the command-line was not very pleasant anymore in 2025/2026, I decided to modernize the tool as part of my work as fellow for the Sovereign Tech Agency last year. pkgcli is the new command-line client for PackageKit. It is built from the ground up to be pleasant to use interactively and easy to drive from scripts.
Why a new tool?
Of course, instead of introducing a new tool, I could have just expanded pkcon instead. The problem with that approach is that the pkcon utility has been around for so long and its command-line API had ossified so much, that rather than changing it and potentially breaking a lot of scripts relying on its quirks, I decided to introduce a new tool instead. pkcon can still be optionally compiled for people who need it in their scripts and workflows.
The goals for pkgcli, and the features it now has are:
Human-friendly command names. Verbs that read the way you d describe the task, instead of mirroring the D-Bus API 1:1: show, search, list-updates, what-provides, instead of get-details and friends.
Readable, colored output by default (still respecting NO_COLOR and degrading gracefully).
A real scripting mode. A global --json flag emits JSONL instead of fully human-readable output when possible, to make it easier to use the tool for scripting purposes.
Sensible defaults. A few defaults have been changed, such as the metadata cache-age, or automatic cleanup of unused dependencies being enabled by default. This is more in line with current defaults by other tools and frontends. We also print package information in a slightly different, more readable way.
Better handling of internationalized text. Text should now align properly in the terminal window, and we should no longer have completely chaotic text output on non-English locales (especially Chinese/Japanese).
Why not pkgctl?
Originally, this tool was called pkgctl, to match other common cross-distro tool names. However, that name was already taken by an Arch-specific distro development tool. When this issue was raised, we decided to just rename our tool to pkgcli with the next release, to avoid the name clash on Arch Linux.
Examples!
Here are some examples on how to use the new tool (some of which include the abridged output pkgcli prints).
Search for anything containing the string editor in name or description, then look at the details of one result:
$ pkgcli search editor
Querying [ ] 100%
ace-of-penguins1.5~rc2-7.amd64 [debian-testing-main]
acorn-fdisk3.0.6-14.amd64 [debian-testing-main]
ardour1:9.2.0+ds-1.amd64 [debian-testing-main]
audacity3.7.7+dfsg-1.amd64 [manual:debian-testing-main]
audacity-data3.7.7+dfsg-1.all [auto:debian-testing-main]
augeas-tools1.14.1-1.1.amd64 [debian-testing-main]
emacs1:30.2+1-3.all [debian-testing-main]
gedit48.1-9+b1.amd64 [debian-testing-main]
gedit-common48.1-9.all [debian-testing-main]
gedit-dev48.1-9+b1.amd64 [debian-testing-main]
[...]
$ pkgcli show nano
Package: nano
Version: 9.0-1
Summary: small, friendly text editor inspired by Pico
Description: GNU nano is an easy-to-use text editor originally designed as
a replacement for Pico, the ncurses-based editor from the non-free mailer
package Pine.
[...]
URL: https://www.nano-editor.org/
Group: publishing
Installed Size: 2.9 MB
Download Size: 646.0 KB
Search only within package names rather than descriptions:
$ pkgcli search name python3
Check for updates. refresh updates the metadata, then list-updates reports what s available:
You can also have JSON output for most commands! Attach --json to any query and pipe the result straight into jq. Each line is a self-contained JSON object:
pkgcli is built by default alongside the rest of PackageKit since PackageKit 1.3.4. If your distribution ships a recent enough PackageKit, it should already be on your PATH. You can read its man page man pkgcli for more information. Feedback, bug reports, and patches are very welcome.
Today we went to see a theater play in UNAM s Cultural Center, very near
our home. No, not inside any of the theaters in the square just between
Sala Nezahualc yotl, Foro Sor Juana and Sala Carlos
Ch vez.. So, yes, not only we had fun,
but we had fun for free!
UNAM s El Carro de
Comedias is an
itinerant theater company that often presents in this same spot (but you
can see the stage is foldable, and they do have presentations elsewhere, of
this same play even). I went with my family, and we enjoyed a very fun
adaptation of this great play (written by teenager Alfred Jarry in
1894). One of those plays that could be inspired any day by current
geopolitical events
I know most of the people that happen to stumble upon my blog are not in
Mexico City. But if you happen to be here, do consider going to their
function. Check their
schedule;
being it an itinerating show, they can also be found at other places, but
they are scheduled at the same place we saw them, every Saturday and Sunday
until June 28, 11:00AM. They mentioned they will likely continue during
August, but AFAICT it is not confirmed (or, at least, announced) yet.
Some pics, shot randomly by me throughout the play:
In the process of preparing a major Ubuntu Touch release (v24.04-2.0, coming soon...) we will also update Ayatana Indicators in Ubuntu Touch.
Last week various new features have been added to some of the indicators (toggle switch to keep the display switched on permanently, blue tooth pairing agent, redesign of the keyboard indicator, etc.) and those changes require translation updates.
If you can, please visit [1] this weekend and help translating Ayatana Indicators into your native language. Thanks so much!!!
light+love
Mike
[1] https://hosted.weblate.org/projects/ayatana-indicators/
Some of you might have noticed that the recent (or rather: previous) version of libayatana-appindicator (v0.5.94) notified users and developers of the library being deprecated.
This short post is to notify you, that with today's libayatana-appindicator v0.6.0 release [1] this deprecation warning has now been removed again. Another new feature (added to AppIndicator without ABI breakage) is tooltip support. The new package version has just been uploaded to Debian experimental. Please test if your application (if it gets linked against libayatana-appindicator) continues to work flawlessly. Thanks!
libayatana-appindicator will receive continued support until GTK-3 becomes end-of-life (because libayatana-appindicator has a baked-in GTK-3 dependency which should not be ported to GTK-4 imho). That said, in the future, GTK-3 applications can continue using libayatana-appindicator for sending AppIndicator-like icons and menus over DBus to KStatusNotifierItem-based system tray renderers.
If you are looking for an AppIndicator implementation for GTK-4 applications (or other), I'd like to encourage you to help making libayatana-appindicator-glib [2] a new standard (can be used in GTK and Qt applications alike, implementation is using pure Glib-2.0). Currently, there is only one renderer (ayatana-indicator-application), so more work needs to be done on the renderers' side. (One of the next work items here is to get AppIndicator-Glib support working in Lomiri's desktop/windowed mode).
[1] https://github.com/AyatanaIndicators/libayatana-appindicator/releases/ta...
[2] https://github.com/AyatanaIndicators/libayatana-appindicator-glib/
The RISC-V CPU architecture has been gaining a lot of popularity since it launched in 2014, and now that the industry is standardizing on the RVA23 level that includes vector support as a mandatory extension, we are likely to see a lot more edge- and IoT devices with the ability to run local LLMs at reasonable speed, and most importantly at very compelling prices.
SpacemiT is a Chinese RISC-V CPU manufacturer that launched on May 11th, 2026, their long-anticipated next-gen RISC-V AI chip K3. It is among the earliest RISC-V CPUs that adhere to the RVA23 standard and performance-wise it is quite capable, providing 130 KDMIPS general computing power, 60 TOPS on INT4 which translates to about 15 tokens per second when running a 30 billion parameter large language model.
The aspect that really makes it stand out is:
Comparing the resellers
SpacemiT does not sell anything directly to consumers. Instead you need to buy a board that includes the K3 chip from an integrator. Currently the main resellers are:
All of the above are Chinese companies that ship to customers both inside and outside China. DeepComputing stands out as the only one that actually has done real integration and ships the K3 on a custom board, while the others simply resell the SpacemiT-produced K3 pico-ITX and K3 CoM260 Kit.
Milk-V
Milk-V is a RISC-V specialized integrator, as the name already implies. They sell the K3 under the name Jupiter2. Of all the K3 pico-ITX reseller product pages, the Jupiter2 presentation is the nicest and most detailed. Unfortunately their order page at arace.tech only states that it is a pre-order with no information about shipping schedule, taxes, or other details like what SSD is included (if any). Based on the pictures it does ship with a Milk-V branded case. The 32 GB RAM lists at 504 EUR, which is a very reasonable price. The @MilkV_Official account on X recently promoted the K3.
Documentation and support
As of this writing, the Milk-V Jupiter2 documentation site is just a stub and has no actual content, and only two links to the SpacemiT K3 documentation site. For support there is a web forum with a dedicated Jupiter2 section. There is also a Matrix space, but unlike their other products, there is no dedicated Jupiter (neither v1 nor v2) channel.
Community size and open source involvement
At least one prior Milk-V product was certified by Canonical, which indicates there is some collaboration in progress. Canonical also lists the Milk-V Titan on its official Ubuntu for RISC-V partner-built hardware page.
Sipeed
The Sipeed K3 announcement is well written (in English) with all the relevant details and links to additional PDF manuals. However, their main page at sipeed.com says nothing about the K3, so one must know the subpage URL to access it. They offer both the K3 CoM260 kit compatible with Jetson Orin Nano carrier boards, and the stand-alone K3 pico-ITX-sized motherboard. The CoM260 kit is only 10 USD cheaper than the full pico-ITX motherboard, so choosing the latter is a no-brainer if starting from scratch. The pico-ITX model with 32 GB DDR5 RAM sells for 639 USD. The product page does not mention anything about hard disk size, so you don t really know exactly what you will be getting if placing an order. There is no indication about case, Wi-Fi antennas or power supply either, so most likely they are not included.
Their store.sipeed.com website does not work at all, and their Taobao and AliExpress stores are not public and only accessible to registered users. The order page also says nothing about shipping time, delivery time, or taxes. The X account @SipeedIO is active and recently posted pictures of shipments in progress.
Documentation and support
The main documentation wiki does not yet have any K3 content at the time of writing. There is a Discord channel for general RISC-V discussion, and their MaixHub also has a discussion board, but I didn t find anything K3-specific.
Community size and open source involvement
Sipeed has had at least one of their previous devices certified by Canonical, which indicates they are active in the community.
Note that the other RISC-V company SiFive that also has had hardware certified and officially supported by Canonical is a different company, despite the very similar name.
Banana Pi
Banana Pi announced that they offer both the K3 CoM260 kit and the K3 pico-ITX motherboard version. Their product page for the K3 confusingly shows a MediaTek product in the page banner rather than the SpacemiT K3. Based on the product description and the fact they renamed the product as BPI-SM10, it seems to ship with some carrier board. The product pictures look identical to the SpacemiT documentation and there is no picture of the carrier board, and details are very sparse. The pico-ITX version with 8 GB RAM and 128 GB SSD sells for 293 USD and the CoM260 developer kit with the same specs sells for 287 USD and the 32 GB RAM with 128 GB SSD model sells for 595 USD. The shop page shows only five orders so far and items are currently out of stock. As there was no 32 GB RAM version of the pico-ITX available at all, this isn t an option for me as I want to run 30B parameter models that need the larger memory version.
Of all of these resellers, the Banana Pi website seems the most outdated. It does not have a search feature, it is not mobile-friendly, pictures can t be pinched to zoom in and so forth. Product names are also almost all identical, and as the product listings only show the beginning of the product name, figuring out what product is what requires extra effort that just makes the online purchase experience plain bad.
Documentation and support
I was only able to find the documentation page for the CoM260 kit, but none for the pico-ITX version. For support there is a forum, but the category list does not show any section for K3, and the forum search prohibits using the search term k3 as too short.
Community size and open source involvement
Banana Pi has a long history in the ARM single-board computer market, but their presence in the RISC-V ecosystem is still growing. Their X account @sinovoip has posted only once about the K3 and otherwise promotes their ARM boards. However, their community culture page does express a commitment to open hardware in general, but there is no visible K3-specific community activity.
Firefly
Firefly s K3 product page is comprehensive. Based on the details, they do not offer the K3 pico-ITX variant at all, but only the K3 CoM260 board inside the AIBOX-K3 Firefly RISC-V Edge Mini PC product. This is a feature-complete offering with a Jetson Orin Nano carrier board and case. The AIBOX-K3 with 32 GB RAM and 128 GB SSD in a case sells for 689 USD in their own Firefly.store. Unfortunately it only has HDMI and there is no USB-C with DisplayPort support, which is a deal-breaker for me personally.
Interestingly, Firefly also offers rack-mounted servers with K3 as the CPU.
Documentation and support
The wiki link on the product page is broken. The Firefly wiki does have a section for the AIBOX-K3, but it too has a broken link. It seems that as of the time of writing, there is no wiki section for this product yet.
For support there is a web forum, which does have at least one K3 thread covering guides such as Hermes Agent installation, though broader K3-specific sections are still sparse.
Community size and open source involvement
Firefly s X account @TeeFirefly has had no posts since 2024, and their GitLab/T-Firefly shows mostly 2024 activity, with only one repository updated in 2025 and nothing in 2026. Historically they have built a moderate community around their ARM-based Rockchip boards, with active forums and wiki contributions for those product lines. Their RISC-V K3 offerings are newer, and likely need a lot more polish to be attractive products overall.
DeepComputing
Last, but certainly not least, is the laptop manufacturer DeepComputing that offers a Framework laptop compatible motherboard with the SpacemiT K3 chip. They also sell the plain motherboard, or with the Cooler Master case, which allows one to easily connect it to an external monitor and keyboard and use it as a desktop computer. The plain board with 32 GB RAM and no SSD sells for about 882 EUR. Shipping of the first batch is expected to start by end of June 2026. Their X account @DeepComputingio promotes this DC-ROMA RISC-V Mainboard III as their flagship product, so they seem to put a lot of effort into it.
The overall product design and packaging seems good. Of all the K3 resellers and integrators that I was able to find, DeepComputing is the only one that actually designs their own boards with the K3 processor, while all the other vendors above are simply reselling the vanilla K3 boards with or without a case.
After reviewing all these options I decided to buy the DC-ROMA RISC-V Mainboard III for Framework Laptop 13 with 32 GB RAM, 1 TB SSD and the Cooler Master case, totalling about 1100 EUR.
Documentation and support
DeepComputing maintains product information for their RISC-V hardware at github.com/DC-DeepComputing/Framework, with documentation of the newest Mainboard III (FML13V05) still being finalized ahead of the first batch shipment. They provide community support through Discord and web forum, although the latter has very little activity.
Community size and open source involvement
DeepComputing has established itself as a pioneer in RISC-V laptops, beginning with the DC-ROMA. I have seen their stand at FOSDEM, which shows they are genuinely active in the open source community. Canonical lists DeepComputing s first mainboard / FML13V01 on its official Ubuntu for RISC-V partner-built hardware page, and it seems likely that they will continue to collaborate with Canonical with the new model once it ships. While the underlying Linux enablement depends on SpacemiT s upstream efforts, DeepComputing s involvement helps bridge the gap between reference hardware and consumer-ready products.
Conclusion
After weighing all the options, I ended up placing an order with DeepComputing for their custom K3 board with the Cooler Master case. Despite the premium price, the active community support and the properly documented promise of a complete, working system made it easy to place an order with confidence.
The SpacemiT K3 is poised to be one of the most significant RISC-V chips for local AI workloads, thanks to its RVA23 compliance and high tokens per second potential. Yet the buying experience in mid-2026 remains fragmented and incomplete. Hopefully this is just because the product is new, and they will get the purchase experience polished soon.
What struck me most during this process was how poor the customer experience is across nearly all of these vendor websites: broken links, missing search functions, outdated product banners, pages that show the wrong product entirely, and no information about shipping times, stock levels, taxes, and so on. One wonders why these companies don t fully invest in their web presence.
Personally I would assume they likely have enough customers already, primarily through domestic channels like Taobao and JD.com, that they do not feel any pressure to improve their international-facing sites. However, I did also review what was offered on Taobao, and the product details were very incomplete there too. Taobao, however, has a built-in live chat with almost all sellers, which can be used to ask questions and thus compensate for missing product details.
I don t fully understand why the sales process seems unpolished. The websites feel almost like an afterthought a checkbox to claim global reach while the real business apparently happens elsewhere via closed platforms or via inaccessible reseller channels. It is a frustrating reminder that in the RISC-V hardware world, the technology may be open and global, but the purchase experience is less so.
A new small package of mine just hit 
Through work, I have paid license to 
The Debian LTS Team, funded by 
There has been a video blog post recently published with a review of Ubuntu Touch as an option to opt out of the Android world: 
Today we went to see a theater play in UNAM s Cultural Center, very near
our home. No, not inside any of the theaters 
The RISC-V CPU architecture has been gaining a lot of popularity since it launched in 2014, and now that the industry is standardizing on the RVA23 level that includes vector support as a mandatory extension, we are likely to see a lot more edge- and IoT devices with the ability to run local LLMs at reasonable speed, and most importantly at very compelling prices.
