Agreguesi i feed

Longtime Slashdot reader schwit1 shares a report from NBC News: British Prime Minister Keir Starmer has announced a sweeping ban on social media use for those under 16, joining other countries around the world seeking to protect children online. "It's a big step for our country," Starmer said in a recorded video message released Monday. "Social media is making our children unhappy and unsafe, and as a parent, as much as a Prime Minister, I just can't let that go on anymore," he added. The ban will include social platforms like Snapchat, TikTok, YouTube, Instagram, Facebook and X, while there is no intention for messaging services like WhatsApp and Signal to be included, the government said in a release. [...] Starmer's government called Monday's announcement a "landmark" move, saying the new measures would be brought to Parliament before Christmas, with protections expected to come into force next spring. Beyond the blanket social media ban, the restrictions will also include blocks on functions such as livestreaming and stranger communication with children for under-16s, it added. "It's not an easy thing to do. I'll be honest about that," Starmer said. "We haven't rushed into it. We've looked carefully at the evidence, and we'll have to adapt our approach as technology changes, learn from other countries which are taking similar steps." He went on to say that it will face resistance from some of the most powerful companies in the world. "But we will take them on, and we will win, because the need for action could not be any clearer."

Read more of this story at Slashdot.

(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!

Version:7.1 (mainline) Released:2026-06-14 Source:linux-7.1.tar.xz PGP Signature:linux-7.1.tar.sign Patch:full

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.

A Fedora contributor account recently came under scrutiny for apparently AI-generated activity that disrupted the project's bug tracker. 

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.