Agreguesi i feed

Almost exactly three years ago the Oceangate submarine implosion happened. The disaster came about when a billionaire called Stockton Rush created his own unclassified submarine to go sightseeing on the Titanic. Ignoring all advice from experts he created a "macgyveresque death trap" that eventually killed him and sadly also 4 innocent people. The whole thing was a massive display of stupidity and arrogance with unfortunate outcomes. We are not going to go into the actual event any deeper, but those interested can find lots of material online.

Instead we are going to look more deeply into one often overlooked points of Stockton Rush's character. Apparently he felt like he was something of a "new James T. Kirk" (link1 paywalled, link2). Liking Star Trek is not that unusual. I'm guessing that more than 99% of the readers of this blog are fellow Star Trek fans. The problem lies elsewhere, but to understand it we first have travel back in time.

A brief overview of the British navy during the Napoleonic wars (by a non-historian, so probably inaccurate)

The original concept for Star Trek was, approximately, The Adventures of Horatio Hornblower in Space! The Enterprise is basically a British warship sailing through the vast ocean of outer space. The command structure mirrors this, where you have a captain, navigator, ship's doctor and so on. The Next Generation leaned into this even further by having a first officer and so on. The original Star Trek never went into detail on how the main cast got to their current positions, just that there was an Starfleet Academy they went to.

In the Napoleonic era of Hornblower things were quite different. Anyone who wanted to become a captain pretty much had to be from the upper classes. They had to obtain a letter of recommendation so that they could join a vessel as a midshipman at the age of 13 or so. They were expected to be able seamen by this time and then spent the next six to seven years working on the ship rigging sails and doing all manner of random jobs. This went on for six to nine years depending on circumstances, after which the person could take a formal examination to become a lieutenant. The test was not trivial, many people could not pass even after trying multiple times.

A lieutenant then had to work successfully for several years before obtaining the rank of captain. Even that did not guarantee a commission. Some captains never commanded a ship simply because there were not enough of them to go around. All in all becoming a ship's captain was a long and difficult journey. In a surprisingly non-British turn of events it was not possible for aristocrats to sneak past the gates. Getting a midshipman position was obviously easier with connections, but the lieutenant's test was something they had to pass on their own.

All of this is to say that every captain of the time was an expert with decades of working experience on many different positions aboard the ship.

What does a captain actually do?

[Note: I have not fact checked this portion at all. Feel free to consider it fanfiction.]

The year is 1808 and we are aboard a British warship about to leave for a mission of great importance. The captain gives the order to set sail. Whistles are blown, bells are rung and sailors springs into action. Every single man, with one exception, is either doing manual labour or directly supervising their underlings. That exception is the captain, who seemingly stands around doing nothing (at least if you ask the crew). This is not so.

What he is doing is crucial. He is observing the state of the ship and her crew. This includes things like overall crew morale, any aberrations from normal operations that could cause problems, thinking of workflow improvements and so on. In a sense he has to sense the ship itself. This only works because of two things. First of all he has personal experience doing the exact work he is observing. If you have not personally "been there", you can't really know if a crew is working well or not. You need a "gut feeling" to be able to sense this. Secondly the captain does not have any manual labour so he can focus all of his mental energy on observing the ship's state. He is preparing for all the unexpected things that may occur in the future. This can only happen if your brain is free from menial tasks.

This is exactly what most books on business and project management advocate. It is a time tested way of improving your chances of success. A highly skilled commander can take an average team of people and lead them to victory. It is the basic plot of most military and sports movies.

Getting back to the present

Now take a typical modern day billionaire-via-inheritance and show them Star Trek at an impressionable age. Do they see the advantages of education, hard work and ethics? The foundation upon which Gene Roddenberry carefully built the show? Hell no! What they see is this (TNG screenshot used because TOS did not have a suitable maritime episode).

And then they think: "Wow! I want to be exactly like that! Parading around in a funny hat while everyone obeys my orders without question is my life's mission from now on. And I get to have sexy space sex with hot sexy space ladies of sex whenever I want. This appeals to me even more profoundly than Atlas Shrugged." Some of them might go on to watch Master and Commander and shed tears upon realizing that they cant publicly flog employees for failing to salute their superiors. Yet. Expect this to be made legal in Silicon Valley any day now.

Liking Kirk is not in any way a bad thing. Wanting to "be just like Kirk" is, because in the real world running a business like Kirk runs the Enterprise is a terrible way to do things. An example will illustrate this nicely. Let's imagine a random episode where the Enterprise has gotten into trouble. Eventually Kirk will call for Scotty and tell him: "You need to <babble> <babble> <babble>." Scotty will then reply with a varying level of scottish accent something like: "I cannae change the laws of physics, captain". Kirk will then say the same thing again, just more aggressively and in a close up shot. Scotty replies with "Well in that case I can get it done in sixty minutes." Kirk counters with: "You have five." And thus the problem is solved. Kirk gets a commendation for incredible valour under stress while Scotty, who did all of the actual work, is never mentioned.

In "Kirk style" management the Big Boss tells his underlings what to do. If they try to give any sort of feedback, the Boss ignores everything and just repeats his original orders again and again until the other party yields. The only reason underlings ever resist The Vision is that they are lazy and it is the job of the manager to put them in their place. This seems like a bit from a comedy show, but I have unfortunately worked under bosses like this. Either you try to talk at least some sense into them, fail, get labeled as a "not team player", watch the project crash and get blamed for the failure, or you try to do the impossible task given to you, fail watch the project crash and get blamed for the failure.

Another major problem with Kirk is that due to the way tv shows and movies need to be structured, he is actually an obsessive gambler. The stakes must always get higher and the ways to get out of trouble must become ever crazier. Kirk will break any and all laws and regulations he sees fit and then, once he has succeeded, no disciplinary action is taken. The ends justify the means. Idolising this sort of behaviour leads to thinking that wild one-in-a-million gambits will succeed at least 99 times out of a hundred. And even if it fails, you can get out of it by betting everything on an even bigger gamble. The real world does not work like that. Reality is not a story and you are not its hero. It does not owe you eternal, or even eventual, success. Had Stockton Rush survived his death trap, he would most likely have faced criminal charges and, if convicted, gone to jail.

The myth of the existence of the professional manager

Let's make one last detour in the 1800s and assume that the 7th Earl of Sidcup or some such really wants to get his idiot son instated as a captain. He and contacts the appropriate naval officers.

"My offspring needs to become a captain of a ship post haste!"

"Well first he has to become a midshipman and ..."

"Phah! None of that nonsense. It's way too slow and not becoming of my statute. Also my son is 35 years old so the post of a midshipman would be beneath him."

"I see. Well what sort of prior naval experience does he have?"

"None."

"Has he even ever been out to sea?"

"Not to my knowledge. But that does not matter. He is highly skilled in using the abacus excelius to compute annual budgets."

"By himself?"

"Of course not. That is what secretaries are for. He just gives them orders. That he can do. And that is all that matters. Same as in sailing."

This person is unlikely to get his wish with this line of reasoning. On the other hand in modern business life this is common. For example when startups get VC money, a common requirement is that they need to get a "proper manager" as a CEO. Typically this means the investor's friend, and more often than not an MBA.

Contrary to common belief, having an MBA does not make you incompetent at managing a technical company (though there is a strong positive correlation). It is entirely possible to be a good manager on a field you have no personal experience in. You just have to have a lot of humility, listen (actually, properly listen) to your employees and let the people with hands-on experience make the most technical, product and development decisions. In other words you have to be the enabler, not the maverick decision maker. People with these sorts of personality traits are rare and typically their career choices steer as far away from getting an MBA as possible.

The absolute worst thing happens if the CEO in question combines the (lack of) skills of an MBA with the attitude of Kirk. That leads to incompetent decisions based on willful ignorance, executed with the fury of an egomaniac who refuses to even entertain the notion that they might be wrong. Further, any person inside the organisation who dares to point out potential flaws in the plan will soon find themselves outside said organisation. Disagreement is treason. Treason shall not go unpunished.

In the 1800s the British navy could be said to be the best in the world. It seems plausible that one component of this success was the requirement that the officers running their ships had to have actual experience operating the ship. Not looking at other people operating it. Not pretending to read about operating it for a test. Actually doing it. If we look around how MBA wielding sociopath CEOs are enshittifying absolutely everything about the tech industry, bringing this requirement back into active use starts to feel awfully tempting.

Epilogue: Why doesn't everything immediately explode?

A reasonable counterpoint to everything written above would be that if managers truly are that bad, shouldn't all those companies be bankrupt by now? In an ideal world they would be, but there are opposing forces that keep them going.

The first one is that all corporations have inertia. If you took an established major company and actively started to mismanage it to death, it would still take years for things to eventually collapse. 

The second one is a dirty little secret. Many employees care more about the product they work on than "corporate visions" that seem to stem from overuse of peyote. They don't blindly obey idiotic commands but instead try to make things silently work within the system. Basically this means that corporations thrive despite their mad kings, not because of them. I know several people who have worked in these kinds of organizations and this is not as rare of an occurrence as one might imagine.

I have also experienced it personally. Years ago I was at a company, whose CEO (who, to the best of my knowledge, did not have an MBA) wanted to change the company's product so that it would do a specific thing X. Everybody thought this was a horrible idea and tried to reason with him using solid business and technical reasons (which turned out to be 100% correct). That failed. Spectacularly. This lead to an eternal series of secret meetings. The participants were main developers and all managers except the CEO. The only item on the agenda was "How can we make the CEO think that we did what he ordered while doing the exact opposite".

Eventually we did succeed, but boy was that a surreal couple of weeks.

(these notes are being posted in two parts to make the length more manageable, part 1 is here)

Continuing from where we left off, about topics discussed at the PipeWire hackfest in Nice…

DSP features

We discussed a number of features related to digital signal processing blocks which are typically realised on specialised hardware (often a DSP core that can directly interface with physical audio inputs and outputs on your laptop/phone/…).

There is currently no standard way for the firmware running on these DSPs to signal what features can be realised directly on DSP. We also would want to allow such features, if exposed from PipeWire, to be realisable on CPU.

Now we do have a way to hide away signal processing in a specific node, which is the filter-graph parameter on the audioconvert node that wraps all audio nodes.

We could extend this mechanism to allow the internal node (say the ALSA node implementation), to expose what filtering it can perform “in hardware” (i.e. the software running on DSP). This would allow the audioconvert to delegate some or all processing to the internal node, with fallbacks available on the CPU.

We would need a number of pieces to do this, including:

• Some standard definition of filters and associated parameters, so different implementations could have a standard “API” to express any given filter.

• The DSP block would need to expose what features it has and how they might be used. We could imagine extending the ALSA UCM configuration to do that.

• The audioconvert node would need to have a way to push down filter-graph params to the internal node, and negotiate what work it is doing vs. what is being delegated

This is a non-trivial effort, but gives us some sketch of what might be possible.

More DSP features

In addition to standard filters, we spoke about two topics that have come up commonly in the past.

The first is some way to expose the processing graph in the DSP, so PipeWire and other userspace daemons have a better view of what is happening on the DSP. With the ability to push dynamic topologies to DSP, there was some renewed interest in exposing and using the ASoC DAPM widget graph. As always, the devil is in the details.

The second thing that came up is speaker calibration. There is a lot of processing and tuning that goes into driving speakers on modern devices as much as possible without destroying them. Some of these are one-time parameters decided at product design time, and some of these translate to runtime parameters based on voltage and current feedback from the speaker amplifier.

For some systems (like Qualcomm platforms), speaker calibration might be run on each system start to perform dynamic tuning. We had some discussion of how this might tie in with the rest of the system for both determining the parameters (separate startup daemon vs. in-process initialisation), as well as uploading parameters to the speaker (some ALSA UCM extensions to load parameters on PCM open but before start, or preloading parameters into ALSA kernel controls and having the driver feed them in at the right point).

Volume limits

A way to set a limit on the maximum volume for a given device has been a common user request ([1] [2]). We discussed the possibility of creating a per-route property (with a fallback to the node, if there are no routes), which WirePlumber could manage to provide users a simple interface to control.

Since the hackfest, Wim has already done some work on this, and we need to bubble this up as a more user-accessible setting.

Performance

A number of performance-related topics were discussed.

The first was an option of a combined DSP mode, where instead of one port per channel, a node would expose one port for all the channels of the stream (but continue to run in the configured “DSP” format/rate). This would improve stream performance for non-JACK-like use-cases, especially in resource-constrained environments.

On the WirePlumber side, there was a discussion about using LuaJIT instead of standard Lua. There are some compatibility issues to be determined there (such as language version supported, etc.), but there might be some quick performance wins to be made if this is feasible.

There is a plan to move some of the WirePlumber core to Rust, and that might be a good time to also port over some of the more standard functionality that tends not to change from Lua to Rust (though that could happen in a Lua->C transition and does not really need to wait on a Rust port).

Declarative Session Management

Another interesting, and broader, thread is the imperative nature of WirePlumber scripts – that is, policy decisions and associated action are often interwoven. It might be helpful to be able to make a clearer split where all policy decisions are first run, and then decisions are translated into actions at one go.

There are some historical choices that make this hard – for example, changing the profile of a device might create and destroy nodes, which makes it hard to be able to make decisions that are independent of the action. There were some ideas around redoing the profile concept such that all nodes are always exposed, but nodes could get a new state to signal availability (and profiles that would allow availability to change). That might make a declarative system possible to implement.

We also discussed the possibility of a “transaction” system. Something that would allow a client to submit a set of objects (think links between nodes), and then “commit” that transaction. This would also help reduce the number of roundtrips between PipeWire and WirePlumber, and generally help performance.

Bluetooth

Being colocated with the BlueZ face-to-face meeting, we had representation from the BlueZ community, so we were able to dive into a number of topics related to Bluetooth, primarily LE Audio.

The first topic was Auracast, the LE Audio system for broadcast audio, allowing listeners to tune into public broadcasts in a space, or to have a device stream audio to multiple headsets concurrently for shared listening. George had a demo system showing an implementation of Auracast with PipeWire, WirePlumber and BlueZ.

We had some discussion of where this feature should live, and the consensus was that we would probably want a separate daemon to manage Auracast settings and loading up the appropriate nodes (either for receiving or sending) based on users’ preferences.

This led to a more general discussion about the current split of the Bluetooth implementation in PipeWire being SPA modules, which include streaming and some policy, and a lot more policy living inside WirePlumber. We could, and likely should, move all of this into higher level PipeWire modules instead, which could make these easier to work with overall.

There was also a discussion about the complexities of LE Audio, and the state of the current user experience with actual devices:

• Device interop is not always great, as the spec is new, the BlueZ implementation is still being completed, and device implementations seem of variable quality
• Reliable pairing/feature detection is hard, partly due to how BlueZ exposes the ability to talk to devices in Bluetooth Classic or Bluetooth LE modes
• Pairing left/right pairs currently needs individual pairing, which does not seem to be needed by other implementations (Android for example)
• Inter-device synchronisation might need some work as well

While there is much work to be done here, the pieces are coming together for first-class LE Audio support on Linux-based systems.

Audio analytics

We also spoke about “analytics” – using local neural networks to implement things like text-to-speech, speech-to-text, language translation, or other forms of processing.

These pose an interesting problem, because they look like a standard-ish audio stream on one side, but are effectively a sparse stream on the other side if we are talking about text. Even conversion between languages does not look like a standard filter, because the underlying model might consume a varying amount of data before generating an output, and the input and output lengths are not tightly correlated.

While it should be possible to implement such a system with PipeWire, it is not quite clear whether we should. As the application space in this area becomes more mature, it may become clearer what the right place in the stack is for these features.

Click detection and elimination

We spoke about detecting and eliminating clicks at the stop or start of a stream.

If an application is playing back audio, and suddenly stops (i.e. feeds silence, or just nothing), then the sudden drop in the signal might cause a click to be output. If you think of the corresponding waveform as representing the physical displacement of the speaker, then the drop to zero is like a sudden brake to a halt, which isn’t possible, and manifests as a jolt that you hear as a clicky noise. The same analogy holds for resuming from a pause, but in the opposite direction.

The solution is usually to smooth out the end of the sound by fading out, but most applications do not do this, so this problem manifests quite clearly for most browser or application streams if you listen closely.

Wim described a number of experiments he has done for detecting such abrupt changes in audioconvert, but he was not happy with the results. We discussed some of these approaches, and what might work as acceptable tradeoffs to capture the most common cases while still trying to respect the integrity of the signal being sent by the application.

(sorry about the vagueness here, I missed taking more detailed notes)

Miscellanea

The rest of the discussion covered disparate topics that I don’t have long form notes on:

• Hardware profiles: Shipping hardware-specific configuration for PipeWire and WirePlumber is hard. We discussed some approaches using context properties and conditions, but this is an area that needs more work.

• Data loop management: PipeWire allows splitting work across data loops so different nodes in a graph can be assigned to different threads. This is currently an all-or-nothing system, where either all nodes go to a single data loop, or every node must be manually assigned a specific data loop. There was some desire to have the ability for there to be a default data loop to make the manual management less cumbersome.

• ACP -> UCM: PipeWire inherits the ALSA card profile configuration from PulseAudio, which has been helpful in making the migration path smoother on most hardware. There was always some desire to have a single configuration system (probably ALSA UCM) for all hardware, but this likely needs some work on what we can express in UCM configuration, but we also need to clean up how we translate our UCM handling code (George has an RFC for this).

Thanks

That’s it, thank you for reading if you made it this far, and a shout out to George, Mark, and others organising the event!

It was great to see continued interest and so much exciting work that is yet to come. I hope to see more of the community in the next edition of the hackfest.

(these notes are being posted in two parts to make the length more manageable, part 2 is here)

The PipeWire community organised a hackfest in Nice, France, colocated with Embedded Recipes, the GStreamer hackfest, and a number of other events.

In attendance were members of the upstream community, as well as folks interested in PipeWire from Collabora, Red Hat, Qualcomm, Stream Unlimited, Texas Instruments, and Valve. In some cases these were the same person wearing upstream and professional hats, as some of us often do! :)

It was two days of fruitful and deep technical discussions, and lovely evenings hanging out in the Côte d’Azur. Shout out to George Kiagiadakis and Mark Filion for putting this together!

Beautiful view of the Côte d’Azur

The topics were disparate and can be somewhat esoteric for folks who are not familiar with the Linux audio space. I will try to strike a balance between providing context and summarising the finer details we discussed. Please feel free to write in if I missed or can expand on anything.

Multistream nodes

A recurring topic for the last couple of years has been supporting multistream nodes. The PipeWire API currently offers a pw_stream interface that can offer a node with single input or output (closer to the PulseAudio API), and the pw_filter interface that provides a lower-level freeform API to individually manage ports on a node (closer to the JACK API).

The stream API while convenient, can be a bit unwieldy for realising concepts such as loopbacks and filters, because each set of inputs and outputs needs to be implemented as an individual node. If you’ve ever loaded the loopback module, for example, you would have noticed that there are two nodes created for each instance.

Wim has created a version of the API that allows a node to provide multiple streams, which allows us to keep the conveniences of the stream API, but more easily express ideas like the loopbacks, filters, etc. Each stream is effectively a group of ports on the node, and nodes can have an arbitrary number of input and output streams.

The code on the PipeWire side is ready. The primary idea is there will be a PortConfig param per stream, and this is where the format of the stream, and other metadata expressed on port groups (which is essentially what a stream is) will live.

We discussed what is needed in WirePlumber to make sure the linking logic adapts to this concept, and Julian will be implementing that in the coming weeks.

Settings

PipeWire has a generic metadata system based on the JACK API that is used for storing metadata (allowing you to attach a key/type/value, optionally attached to an object). This is also used by WirePlumber to provide its settings system (see wpctl settings), along with some key features such as a schema and persistence.

We discussed that it might be nicer to have the concept of settings as a first-class citizen, and possibly even standardise some settings for desktop wide usage (such as common processing elements). There was consensus that:

• A new settings interface (instead of extending metadata) would make sense
• The API should be asynchronous, and can fail
• A schema for valid settings and their types could be exposed as a well-known metadata key
• Implementors of the interface would perform validation

Security

We spoke about the current state of security for applications using PipeWire. For context, PipeWire has a fine-grained permissions model where each client can have selective access to what objects are visible to it, and what actions it may perform. There is also a less granular system, where a “manager” application can connect to the manager socket for full access. We broadly think about restricted security for sandboxed applications (primarily Flatpak).

One scenario is sandboxed PulseAudio applications getting full access via the pipewire-pulse server on the host. The discussion on this concluded that there is a way for pipewire-pulse to forward enough security-related information from sandboxed applications for us to apply sandbox restrictions to them, and we need to make that system work.

There was a discussion that it might be reasonable for our default policies to apply for all applications connecting to the regular PipeWire socket to be restricted (this does not prevent malicious applications from accessing the manager socket, but helps applications not do bad things erroneously).

This might be disruptive to introduce as a default change, so we might implement it via an opt-in setting so that there can be some broader testing and refinement of default permissions before flipping the switch for all users.

There are a number of mechanisms related to how security context properties are relayed, and how those properties are used by WirePlumber to determine permissions. We need to document and verify the expected behaviour here.

Flatpak and Portals

Relatedly there was a discussion about how things should fit in with Flatpak, and Sebastian Wick from the Flatpak team joined us briefly on the second day.

There was some discussion of making sure the PulseAudio socket is provided to the sandbox in a similar way to the PipeWire socket, such that some additional security properties can be assigned from the host in a way that the sandboxed client cannot override.

We agreed that we needed the ability for applications to specify with some granularity what permissions they require (via portals), and for us to grant only that (with user intervention, if needed). Broadly this is:

• Playback (optionally enumeration of sinks)
• Capture (optionally enumeration of sources)
• Default visibility of only the application’s own nodes

We also spoke about how we might want to associate PipeWire objects with applications. With Flatpak moving to using a cgroup for each application, this should become easier. We may also want to be able to have a way to associate a stream with a specific window (to, for example, share a window and its audio), which should be possible.

It was also noted that for some classes of applications, we may want a way for users to allow some of these permissions at install time (for example, a remote desktop application asking permission on every start can be annoying). This is already possible with Flatpak manifests (which are static, but we might need to add some more options here), and there is a potential entitlement system being discussed (for server-driven overrides to be distributed for malicious applications, for example).

Encapsulation and Collections

One topic that came up last year is the ability to encapsulate a group of nodes such that they appear as a single node to other applications in the system. This could be useful for:

• Collapsing all the output from an application so it appears to be providing a single stream
• Grouping all the filters for a sink or source node, and making it appear as a single node with all the processing hidden away

One piece to making such a system possible is to have a first-class notion of this group. Julian has an implementation of such an entity, called a “collection”. This is currently implemented on top of PipeWire metadata, but we agree that this is likely worth having an explicit PipeWire interface for.

Once that is in place, we discussed the possibility of having a smarter “proxy” node that can act as the interface that translates from the “outside” of the encapsulated region to the “inside”, so that format selection, volume changes, etc. can properly be proxied to the underlying device, for example.

Tooling improvements

It was noted that the tools we have (such as pw-top and pw-dot) can make it hard to get at some information, such as negotiated formats, rates, etc. They can also be “noisy” when we have a large number of filters and loopbacks.

While we did not have a concrete plan to tackle this, some of us have been playing with LLM-based tooling to generate some helper code for this sort of thing. At least my attempts have been too sloppy to share as yet, but it should be possible to get something useful with a structured approach.

That’s it for now. Watch this space for part 2!

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-penguins 1.5~rc2-7.amd64 [debian-testing-main] ▣ acorn-fdisk 3.0.6-14.amd64 [debian-testing-main] ▣ ardour 1:9.2.0+ds-1.amd64 [debian-testing-main] ✔ audacity 3.7.7+dfsg-1.amd64 [manual:debian-testing-main] ✔ audacity-data 3.7.7+dfsg-1.all [auto:debian-testing-main] ▣ augeas-tools 1.14.1-1.1.amd64 [debian-testing-main] ▣ emacs 1:30.2+1-3.all [debian-testing-main] ▣ gedit 48.1-9+b1.amd64 [debian-testing-main] ▣ gedit-common 48.1-9.all [debian-testing-main] ▣ gedit-dev 48.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:

$ pkgcli refresh && pkgcli list-updates Loading cache [████████████████████████████████████████] 100% ▲ cme 1.048-1.all [debian-testing-main] ▲ gir1.2-gdm-1.0 50.1-2.amd64 [debian-testing-main] ▲ imagemagick 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main] ▲ imagemagick-7-common 8:7.1.2.24+dfsg1-1.all [debian-testing-main] ▲ imagemagick-7.q16 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main] ▲ libdlrestrictions1 0.22.0.amd64 [debian-testing-main] ▲ libfftw3-bin 3.3.11-1.amd64 [debian-testing-main] ▲ libfftw3-dev 3.3.11-1.amd64 [debian-testing-main]

Explore relationships between packages:

$ pkgcli list-depends inkscape # list what inkscape depends on $ pkgcli list-requiring libappstream5 # list what requires libappstream5

Find the package that provides a capability, here the AV1 GStreamer decoder:

$ pkgcli what-provides "gstreamer1(decoder-video/x-av1)" ✔ gstreamer1.0-plugins-bad 1.28.3-1.amd64 [auto:debian-testing-main]

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 --json list-updates | jq -r '.name' cme gir1.2-gdm-1.0 imagemagick imagemagick-7-common imagemagick-7.q16 libdlrestrictions1 libfftw3-bin libfftw3-dev libfftw3-double3 Try it

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.

I occasionally see people go through great effort to do end-to-end testing of keyboard input latency. That is fantastic but it requires hardware and patience I don’t, nor will ever, have.

Here is a much simpler way to get about 90% of the value. For example, everything but driver/interrupt handler latency and display link scanout/monitor visibility latency and of course your app side (but you could theoretically rig this up to do that too, inside your app). Not that those aren’t important, but they definitely fall into the category of things I personally cannot control for you.

Keyspeed is a very simple GTK application which uses /dev/uinput to synthesize keypresses. Since it knows the time of provenance, it can compare that to when it gets the event back from compositor delivery.

Wrap all that data up in Sysprof capture marks, pull in some from the compositor (GNOME Shell/Mutter support this), tie in some callgraphs/flamegraphs, and you have a very good overview of what is going on during your keypress.

Run it like this (but remember to chmod back when you’re done less you have attack surface available).

$ sudo chmod 660 /dev/uinput $ git clone https://gitlab.gnome.org/chergert/keypress $ sudo dnf install sysprof-devel libinput-devel gtk4-devel $ make $ sysprof-cli --gtk --gnome-shell capture.syscap -- ./keyspeed $ sysprof capture.syscap

Currently, this only shows you keypress send to receive in GTK, but if someone cared enough, you could make it take the next GtkFrameTimings and use that to get the presentation time. I don’t need that for what I’m doing, so it doesn’t.

If you go to the marks section, you can dive in to a specific keypress/release cycle. Zoom in on just that section, switch back to callgraph/flamegraph profiler and see what was going on.

Pretty simple, no special hardware needed.

You can see how long it took, where time was spent, and more importantly, how much time was empty between things that matter.

An anonymous reader quotes a report from NBC News: The first quarter of 2026 produced the most blocked and delayed data center projects on record, according to a new study shared with NBC News. The study -- conducted by Data Center Watch, a project of the AI intelligence firm 10a Labs that tracks local data center activity -- found that data center opponents blocked or delayed at least 75 projects nationwide worth about $130 billion from January through March, the most in a three-month period since the group began tracking in 2023. "The quarter reflected a structural shift rather than a cyclical spike: communities have internalized an opposition playbook, legislative sessions introduced formal regulatory uncertainty, and the number of active opposition groups more than doubled to 833 across 49 states," the authors wrote, noting that the total number and value of data centers blocked or delayed during the first three months of 2026 roughly matched the total for all of 2025. [...] The report found that legislative pushes for moratoriums on constructing data centers ballooned during the first quarter of 2026, sponsored by lawmakers on both sides of the aisle. The report found such proposals introduced in 14 states from January through March, with Sen. Bernie Sanders, I-Vt., and Rep. Alexandria Ocasio-Cortez, D-N.Y., introducing a federal version. Though none of the proposals has been signed into law, one did reach the desk of Democratic Gov. Janet Mills in Maine. She vetoed it in April. More than 300 bills were introduced in statehouses across the country just in the first six weeks of 2026, the authors found, saying it marked "a clear shift from incentive-focused policies toward regulatory oversight as the scale of energy demands became clearer." What's more, the study found that the number of active grassroots opposition groups across the country more than doubled from 396 at the end of 2025 to 833 by March. The authors found that the states with the most opposition groups through that month were Maryland, Ohio and Texas. "In some cases," they wrote, "opposition mobilized before any project was officially filed, the mere rumor of a data center was enough to trigger organized resistance."

Read more of this story at Slashdot.

Greetings from Planet Peanut!

Since there’s a whole new generation of GNOME contributors active right now, I’ll do a short reintroduction: Hello, I’m Hylke!

I was a design contributor in the late 2.X, early 3.X days. Mainly icons and theming. I’ve attended many GUADECs.

I’m also the developer of SparkleShare, a Git-based file sync app. Once a much used tool by the Design Team to collaborate on mockups, now in need for some love and care.

After many years just lurking I’m happy to be officially back as a GNOME Foundation member now that Bobby has joined Circle.

App icons created in recent months New plan

I lost my job this year due to the big tech layoffs. Also dealing with burnout, it made me realise I need to go back to working on things that matter to me.

I would love to contribute design full-time.

If you like my work and want to support me, I’m trying to gather enough small monthly sponsors to support me with a basic income. Every little helps.

My focus for 2026:

• Supply a stream of icons to the Linux ecosystem by designing at least one app icon a week. Developers can request free icons.
• Reboot SparkleShare. Finish the rewrite in Rust and redesign the interface with GTK4 and libadwaita.
• Launch a FOSS design service. Make a plan for sustainably assist FOSS communities with product design work.

I will post frequent updates here and on the Fediverse.

Good to be back!

Jeff Bezos says his new AI startup, Prometheus, is working toward an "artificial general engineer" capable of helping design complex physical products such as robots, drugs, manufacturing systems, and rocket engines. The Verge reports: The NYT first reported on Prometheus last November, but now Bezos is sharing more information about the startup after a $12 billion funding round, putting the company at a $41 billion valuation. Bezos serves as co-CEO of Prometheus alongside Vik Bajaj, who co-founded Alphabet's health-focused research group, Verily. The startup currently has around 150 employees. The tools Prometheus intends to build could help develop physical products across several industries, including robotics, drug design, and manufacturing, the NYT reports. "Blue Origin is a perfect example of a company that could benefit from the tools that Prometheus is building," Bezos tells the NYT. "Any company that is building sophisticated devices -- like rocket engines -- would benefit greatly from this kind of technology."

Read more of this story at Slashdot.

The Justice Department has approved Paramount Skydance's $111 billion acquisition of Warner Bros. Discovery without requiring divestitures or other concessions. The deal still faces scrutiny from state attorneys general. Politico reports: The decision, expected to be announced Friday, paves the way for Paramount to combine with the entertainment and media company behind a vast film and television studio, CNN, and the HBO Max streaming service, which would be combined with Paramount+ to create a new offering boasting about 200 million subscribers. The deal, which would upend the Hollywood ecosystem by combining two historic rival studios, is opposed by many in the entertainment industry who fear it could lead to mass layoffs, among other concerns. After an extensive review, DOJ officials determined the transaction did not pose a threat to competition and declined to challenge it, said the people, who were granted anonymity to discuss sensitive matters. The department approved the merger without requiring any divestitures, behavioral remedies or concessions, according to one of the people. [...] The DOJ's approval does not end the merger's legal scrutiny. California Attorney General Rob Bonta has been reviewing the transaction and could still sue to block the deal despite federal regulators signing off. A spokesperson for Bonta's office told POLITICO earlier this week "the Paramount acquisition of Warner Brothers remains an active investigation." [...] Throughout those discussions, Paramount maintained that the merger would strengthen competition rather than diminish it, creating a media company better positioned to compete with streaming leaders and deep-pocketed technology rivals, according to people familiar with the matter. Hollywood workers fear the merger could trigger another wave of layoffs in an industry already reeling from years of consolidation. Critics argue that billions in promised cost savings will come at the expense of jobs, fewer opportunities for creators and greater concentration of power across film, television and streaming.

Read more of this story at Slashdot.

ShinyHunters claims it exploited a critical Oracle PeopleSoft zero-day to compromise more than 100 organizations, including the University of Nottingham, where it says it stole 40GB of student and billing data. "ShinyHunters posted the UK university on its data leak site on Tuesday before publishing the stolen files later that same day, presumably because the school refused to pay the extortion demand," reports The Register. From the report: "University of Nottingham on our leak site is one of the first publicly confirmed incidents," a ShinyHunters spokesperson told us. "We have only just started outreach to affected orgs and are actively looking to reach an agreement with affected orgs." They didn't say when they planned to post the other 100 or so claimed victims. A Google threat intelligence report published Thursday afternoon corroborated ShinyHunters' claims to have compromised more than 100 organizations. Google said it spotted malicious activity, "consistent with the exploitation of CVE-2026-35273," between May 27 and June 9, and notified more than 100 global orgs "whose IP addresses correlated with potentially vulnerable endpoints." Most of these, we're told, are based in the US and 68 percent are in the higher-education sector. Oracle has released a "patch availability document," but it's unclear whether a patch is currently available.

Read more of this story at Slashdot.

An anonymous reader quotes a report from TechCrunch: Google is suing to dismantle the infrastructure behind an alleged massive AI-powered cybercrime operation. On Friday, the tech giant announced a lawsuit against an alleged Chinese cybercrime network called Outsider Enterprise, which Google says uses AI in its campaigns to send scam text messages impersonating Google and other brands to steal passwords and credit card numbers. Outsider Enterprise has financially scammed "hundreds of thousands of victims" with losses "estimated in the millions." The group deployed 9,000 fake websites, 1 million fraudulent web domains, and 2.5 million texts sent to Android users in a two-week period, according to Google. "55,000 spam texts were flagged by Android users in just two weeks this past May -- that's more than two text spam complaints a minute," Google said. Google said it uses "AI-powered tools to fight AI-powered scams", which enable the company to detect scams and alert users of suspicious calls and text messages, leading to the interception of more than 10 billion scam messages a month. The company said it has been collaborating with AT&T, T-Mobile, and Verizon to block the scam text messages and said it is coordinating with the FBI, which is taking unspecified law enforcement actions.

Read more of this story at Slashdot.

A leaker with a strong Apple rumor track record says a touchscreen MacBook is "100% confirmed. If true, it would mark a major reversal for Apple, which has long argued that the Mac is built for indirect input rather than reaching up to touch a vertical screen. MacRumors reports: Instant Digital has a good track record for Apple rumors and has provided some strikingly accurate information in the past, so it's always worth noting what they have to say about Apple's plans. The claim is also backed by several recent reports. [...] Touchscreen support is expected to be one of several major upgrades coming to Apple's next-generation high-end MacBook Pro models. Other rumored features include M6 Pro and M6 Max chips, an OLED display, a Dynamic Island (i.e., no notch), and a thinner design. The new laptops could also adopt MacBook Ultra branding. Notably, macOS 27 Golden Gate also introduces a more touch-friendly interface, since Apple's Sidecar feature now allows users to tap and interact with macOS interface elements using a finger on their iPad. Apple apparently is not going to advertise the new MacBook Pro/Ultra as a touch-first device like the iPad -- it will be "touch-friendly, not touch-first," according to [Bloomberg's Mark Gurman]. In that sense, Apple will let customers use touch and mouse gestures interchangeably for all functions. Further reading: Steve Jobs Was Wrong About Touchscreen Laptops (2012)

Read more of this story at Slashdot.

Version:next-20260612 (linux-next) Released:2026-06-12

Longtime Slashdot reader Dotnaught shares a report from The Register: For the past 90 days, Microsoft has been quietly patching a firmware flaw in Surface devices that allowed the hardware to be bricked with a single packet, though only for those who have disabled Secure Core and Secure Boot. And the company's Copilot AI software inadvertently helped identify the faulty firmware. According to Jack Darcy, a security researcher based in Australia, his instance of Microsoft Copilot stumbled across the bug after being asked to adjust the screen backlighting on a Surface device. The Copilot-conjured Python script ended up rendering the researcher's laptop inoperable by overwriting the embedded controller firmware. "Copilot autonomously created and executed four progressively aggressive Python scripts during a probe for backlight control values that sent raw SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) directly to the SAM microcontroller through the SAM software path," Darcy explained to The Register. [...] "We appreciate the work of Jack Darcy and The Register for reporting this issue under a coordinated vulnerability disclosure," a Microsoft spokesperson said in a statement. "Our investigation found that a deprecated UEFI interface could trigger a boot loop on some devices. To trigger this loop, the user must have administrator privileges and have already disabled the Secure Boot security feature. We have released updates to address the issue for most impacted devices." That means managed devices are not at risk. But those using Linux, or Windows users who have disabled Secure Core and Secure Boot for gaming, or who use custom Windows drivers, or who have USB boot enabled, may still be vulnerable if their systems haven't received the update. We're uncertain about the range of Surface devices affected. Our source said it appears to be all of them (Surface Laptops 3-6, Surface Book 1-3) except for Surface Go models. ARM variants, however, have not been tested. The report notes that Microsoft is planning to move the Surface stack to a more secure architecture based on Rust code. "Our most recent Surface for Business hardware features a major architectural shift in terms of improved reliability and security that spans our embedded controller, UEFI, but also some of our drivers," said David Abzarian, chief architect for Microsoft Surface. "We're investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust (as part of leveraging and contributing to the Open Device Partnership (ODP)) in addition to a rewrite of the UEFI DXE Core in Rust; these projects are known as Secure EC and Project Patina respectively." "We're also not only shipping some of our drivers written in Rust, but also helping co-develop the framework Windows Drivers in Rust (WDR) to help enable a broad set of partners in the Windows ecosystem to capitalize on these benefits. I will also note that all of these efforts are open-source promoting one of our key security principles around transparency."

Read more of this story at Slashdot.

Sam Bankman-Fried lost his appeal to overturn his FTX fraud conviction and 25-year sentence. Reuters reports: In a unanimous decision, a three-judge panel of the Manhattan-based 2nd U.S. Circuit Court of Appeals said prosecutors' evidence against Bankman-Fried "was, conservatively stated, robust." "While he was publicly reassuring customers, investors and regulators that FTX customer funds were safe, he was simultaneously using FTX as his own personal piggy bank, spending customer funds on real estate, political contributions, and investments," Circuit Judge Barrington Parker wrote on behalf of the panel. Bankman-Fried's lawyers did not immediately respond to a request for comment. They may next ask all the active judges on the 2nd Circuit to hear the case, or ask the U.S. Supreme Court to take up the case. Bankman-Fried is also seeking a pardon from President Donald Trump, according to the Justice Department's Office of the Pardon Attorney. Bankman-Fried was sentenced to 25 years in prison in 2024 for "masterminding one of the largest financial frauds in American history," wrote US District Judge Lewis Kaplan. He was convicted on all charges, including wire fraud, conspiracy to commit securities fraud, commodities fraud, and money laundering.

Read more of this story at Slashdot.

Infineon is set to open a $5.8 billion power-chip fab in Dresden on July 2, backed by about $1.1 billion in EU Chips Act subsidies. The plant will make power semiconductors for AI data centers and could eventually add up to $5.8 billion in annual revenue as demand for AI infrastructure strains global electricity systems. Bloomberg reports: Infineon, traditionally a chipmaker for the automotive industry, has increasingly benefited from soaring demand for power chips used in AI data centers, which will be produced at the new facility. "The AI data centers currently being built and planned around the world will consume twice as much electricity in 2030 as they do today," [said Chief Operating Officer Alexander Gorski]. "That's as much as the entire Federal Republic of Germany." Chip production at the Dresden fab will be scaled over time depending on demand, potentially adding as much as 5 billion euros in revenue per year, Gorski said, declining to comment on when full capacity will be reached. The company has invested around 2 billion euros on construction and the remaining amount will be spent over time to add more machines to the fab, he added. The new facility is "a key catalyst," Bank of America analysts including Didier Scemama wrote in a note last week. Demand from Al customers is materially above Infineon's current capacity, they said, adding the imbalance could improve in the 2027 and 2028 financial years. The analysts raised their Al power revenue forecast for the company by 500 million euros to 4.5 billion euros for 2028. Infineon expects data center-related revenue to rise from around 1.5 billion euros in fiscal 2026 -- roughly 10% of sales -- to 2.5 billion euros in 2027, it said last month. The hundreds of billions of dollars being invested in AI are driving the rapid expansion of data center capabilities around the world. Infineon doesn't produce advanced AI chips, like those designed by Nvidia. But the power semiconductors it plans to produce in Dresden are still needed for AI infrastructure.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Reuters: Few business leaders have been as deeply embedded in popular culture as Elon Musk, the ambitious entrepreneur who has become a central figure in internet culture and amassed a fortune that has made him the world's first trillionaire. At a time when concerns about inequality are high and public attitudes toward the ultra-wealthy have soured, Musk has managed to retain a loyal following despite his stratospheric net worth and without the folksy persona that endeared other tycoons such as Warren Buffett to the masses. While admirers view Musk's no-filter style as part of his appeal, critics have accused him of wielding oligarch-like power, raised concerns about governance at his companies and objected to his increasingly partisan political interventions. Still, SpaceX, the sprawling rocket, satellite and AI company that together with electric-car maker Tesla form the center of Musk's empire, raised a record $75 billion in its initial public offering on Thursday, highlighting investor enthusiasm for his business ventures. Prior to the share sale, Forbes pegged his net worth at roughly $780 billion, far ahead of the man next in line, Alphabet co-founder Larry Page. "The second richest person has been hovering around $300 billion, so about less than one-third of what Musk can potentially be worth tomorrow," said Matt Durot, deputy editor at Forbes Wealth. "And only one other person, (Oracle founder) Larry Ellison, has ever been worth $400 billion." Most of Musk's wealth now rests with SpaceX, where he holds a stake worth roughly $866 billion. Along with Tesla and the rest of his properties, his net worth will exceed $1.1 trillion when the stock begins trading Friday, according to Forbes and Reuters calculations based on company filings.

Read more of this story at Slashdot.

Pokemon Go players' optional location scans reportedly helped train Niantic Spatial's visual positioning system, which uses camera imagery and 3D maps to navigate when GPS is unavailable or jammed. According to DroneXL, that technology is now being paired with Vantor's drone navigation software for military and intelligence use, raising questions about whether gamers understood that footage collected for in-game rewards could eventually support defense systems. From the report: The pipeline runs from a mobile game to the battlefield in three steps. Players scanned the physical world. Niantic Spatial turned those scans into a 3D map that lets a machine locate itself by sight when satellite signals fail. And in December 2025, Niantic Spatial announced a partnership with Vantor, the defense and intelligence firm formerly known as Maxar Intelligence, to fuse that ground-level system with Vantor's aerial navigation software for use in GPS-denied operations. I have spent years covering how drones lose their way the moment an electronic warfare unit switches on a jammer, a problem that has spread from the battlefield into civilian airspace, from Ukrainian workshops cycling through navigation generations to American programs scrambling for alternatives. The unsettling part of this story is not the technology. It is where the training data came from, and whether the people who supplied it would have agreed had anyone explained the destination. "Now as part of Scopely (the Saudi-owned company that acquired Niantic last year for $3.5 billion), Pokemon GO data is not shared with Niantic Spatial," a company spokesperson said in a statement to Kotaku. "AR Scans collected through Pokemon GO were submitted voluntarily by players who opted into the feature and were subject to the applicable Terms of Service and Privacy Policy at the time. The discontinuation of AR scanning and the end of data sharing with Niantic Spatial were part of the transition planning associated with Pokemon GO's move to Scopely."

Read more of this story at Slashdot.

Riverside County has launched an 8-mile "smart freeway" pilot on northbound I-15 near Temecula, using roadway sensors and an algorithm to coordinate ramp meters and suggest speeds rather than widening the freeway. Officials say the $33 million project could reduce stop-and-go traffic and travel times. According to SFGATE, similar systems in Australia and Denver reportedly cutting delays by 20% to 65%. From the report: Unlike typical on-ramp stoplights that run on a timer lasting a few seconds, Interstate 15 drivers could find themselves waiting up to four minutes or even longer while the system determines the necessary speed for traffic entering the freeway. By spacing out the cars, transportation officials hope to improve traffic flow, reduce stop-and-go traffic and decrease the amount of time that travelers have to spend on the freeway. The transportation commission spent $33 million to build the project, which will run for two years. Riverside County Transportation Commission spokesperson David Knudsen told SFGATE that if the program is successful, the agency will work with Caltrans to deploy it elsewhere in the county and then potentially to other traffic choke points in California. "This system is a lot less expensive than trying to build new lanes, and so the idea here is let's make the system that we have work better," he said. Knudsen said the program is not managed by artificial intelligence but instead uses advanced sensors in the roadway to monitor real-time traffic conditions and make adjustments. The stretch of freeway that connects Temecula at the Riverside/San Diego County line to the Interstate 215 interchange in Murrieta can be notoriously clogged. What can be less than a 10-minute drive with no traffic can take between 25 and 45 minutes during the afternoon peak period, according to the transportation commission. "The intent is to create a consistent flow of traffic on the freeway system, and the coordinated ramp metering among the three on-ramps ... will help do that," Knudsen said. "If we can manage that, then we can help prevent that stop-and-go traffic frustration that so many people feel ... on the freeway."

Read more of this story at Slashdot.

An anonymous reader quotes a report from Bloomberg: While traditional hotspots in the region such as Thailand, South Korea and Malaysia focus on services such as cosmetic surgery, IVF or physicals, China is trying to differentiate itself by providing some of the world's most advanced procedures. "There are two reasons why a patient travels for medical treatments: availability of advanced treatments and price," said Victor Cao, operations director of Joyful Medical, an agency in Shanghai that connects international patients to advanced cancer therapies in China. "Chinese people used to travel overseas for treatments that were not available at home, but now tables have turned." As expanding visa-free policies eased travel in the past year or so, videos are proliferating on social media of foreigners recounting their positive experiences of treatment in China, usually for consumer procedures like acupuncture and tooth scaling. But one treatment that's more quietly gaining traction is CAR-T, among the most promising breakthroughs in oncology but unavailable in most countries, or extremely costly. The process sees doctors collect T cells from the patient's blood then modify them in a lab to produce a special receptor, CAR, that can bind to a specific protein on cancer cells. These engineered cells are then multiplied into large numbers and infused back into the patient. The CAR-T cells seek out cancer cells carrying the target antigen and kill them. In the US, one single infusion can cost between $300,000 to $475,000, according to the American Cancer Society. In China, the equivalent costs about $150,000 to $180,000, and it could get even cheaper -- its drug regulator recently accepted a marketing application for a therapy aimed to be priced below 300,000 yuan ($44,000). China's medical tourism market remains in its infancy. Lecheng International Medical Tourism Pilot Zone in Hainan, which was designated as the country's only special medical zone in 2013, treated just a few thousand foreign medical tourists last year, compared to hundreds of thousands of domestic patients who visited. There, patients can access advanced drugs, devices, and therapies approved in other countries but not elsewhere in mainland China. But China is pushing to upgrade its economy and reshape its global image from just a manufacturing hub into a provider of high-value services, and demand for medical tourism is surging. Globally, the market is estimated at around $34 billion and expected to reach $126 billion by 2035, according to San Francisco-based Grand View Research. Meanwhile, China's sector is projected to grow from $1.3 billion in 2025 to $3.4 billion by 2035, according to New York-based firm Market Research Future. "The patients chose China for something they can't get at home," said Shi Haoying, the group's founder and chief executive officer. "I think the growing attention to medical tourism to China is the inevitable result of long-term accumulation and development in many areas, such as growing medical technologies, quality of service and cost-effectiveness." Jeroen Groenewegen-Lau, an analyst at the Mercator Institute for China Studies, added: "Many new treatments, including in very advanced areas, are made in China but too advanced for the state of its healthcare system and the ability of its patients to pay for these things. It's in China's interest to integrate into the international system."

Read more of this story at Slashdot.