Agreguesi i feed

GIMP is Free and Libre Open Source Software, but none of it is possible without the people who create with and contribute to it. Our project maintainer Jehan wanted to interview the volunteers who make GIMP what it is, and share their stories so you can learn more about the awesome people behind GIMP!

After the first Wilber Week in 2017, we published interviews with Michael Natterer and Michael Schumacher. Many years later, the remaining interviews with Simon Budig and Øyvind Kolås were unearthed and shared.

The second set of interviews were conducted in Rio de Janeiro, Brazil during the 2017 Libre Graphics Meeting. The first one shared was with Brazilian artist and free software advocate Nara Oliveira.

The next subject of the LGM interviews was Liam Quin. Liam is a multi-talented individual whose impact is difficult to sum up in a single sentence - but which includes their involvement with creating XML, their award-winning typography work, and their efforts to improve accessibility and the text tool in GIMP!

This interview took place during April 21 - 23, 2017. In addition to Jehan and Liam, Simon Budig, Aryeom Han, and Americo Gobbo were also involved and asked questions.

Liam Quin, CC-BY-SA

Jehan: Hello Liam!

Liam: Good evening.

Jehan: First of all, could you introduce yourself?

Liam: My name is Liam Quin. What do you want to know about me? I’ve been using GIMP for over 300 years, since 1997 or 1998. I’m not sure – ‘98 I think.

Jehan [laughing]: Not very good with mathematics.

Liam: Not very good with mathematics, numbers, no - I’ve heard of them. Computer science, got that – don’t need to be very good at maths to get a degree in computer science. Although I should have specialized in maths – and digital typography is my background, and I think my first love.

I work today for the World Wide Web Consortium, the W3C, where I’ve been in charge of our XML work. Now I do CSS and accessibility and some payment stuff and some SVG stuff, all sorts of things.

[Editor’s note: Since this interview, Liam has left W3C and founded Delightful Computing]

Jehan: Okay, so what has been your involvement with GIMP?

Liam: I’m just a hanger-on, a time-waster. I throw bricks from the side, I make suggestions. For a while I was the official spiritual advisor to the GNOME project, but I believe I had to give that up when Bush was elected. I was, actually, if you look at the foundation page you’ll see me there. I just met the people at a GNOME GUADEC conference years ago, and decided they were really good people.

I’ve been using GIMP professionally. I run a small stock image company and the images, both photographs and scanned images from old books, I clean them up with GIMP and do creative work with them and sell them. The GIMP team has been responsive when I needed changes or when I wanted changes, and very occasionally I’ve even made some patches, although not very many.

Jehan: Maybe you can tell us what you like about GIMP, what you don’t like about GIMP?

Liam: What I like least about GIMP is the name, because I work in accessibility. So for example, I can’t wear the GIMP shirt at work because there will be people who are upset.

[Editor’s note: More information about the name and where things currently stand]

But what I like most about it is that is Free Software. That I have a right to change the code, or to pay someone else to change the code if I can’t. That it runs on free platforms, such as GNU/Linux systems. I like that it’s in a language I can read. I particularly like that it’s got a lot of functions, it does a lot. It does pretty much everything I need. I can imagine it doing more, I can imagine a program that I would just say, “Scan this image and clean it up for me”, but we’re not there yet. I actually have to do work, including creative work, to repair image. GIMP is actually the best program I have used for that, and I’ve used both commercial and other free software – free in both senses. I’ve found that GIMP has features that are really good for cleaning up scanned images.

The Haunted Chest of Drawers from La Vie Parisienne (1863), scanned and restored by Liam Quin, CC-BY-SA

Americo: What do you think about artists using GIMP?

Liam: I think artists, people approach art from all sorts of different angles and direction. And some people want something very immediate, which you might find in MyPaint for example, where you open MyPaint and you don’t even have to do File → New, it’s just there, and you can start drawing.

And at the other extreme, there are people who plan a drawing for a long time, maybe draw careful pencil sketches and build something up over a period of hours, days, months, even years. And within those, there’s people who are very precise, work with numerical angles, will write a little programming script to create a particular effect – and there’s other people who will want to do lots of experiments and choose the one that works best.

I think what we’ve been seeing is that the user interface of GIMP has been changing. There’s been a move towards supporting the spontaneity a lot more. The early GIMP was really aimed at the people who thought about their art more than – as I see it – more than just sitting down and painting. That’s actually why I think my husband would prefer MyPaint to GIMP. He said he hated GIMP, and part of that was because he was taught Photoshop at university. Universities shouldn’t be teaching specific programs, they should be teaching the underlying skills, they should teach image editing, not a particular version of a particular program. But you spend so long learning one program that you get really tied to it.

But we also have the fact that GIMP has been more – um, people have this left-brain, right-brain categorization which turns out to not have much basis in reality, our brains don’t actually work that way – but GIMP is more “left-brain” than “right-brain”. Not as extreme as Inkscape or Illustrator for example, where you can’t even do a brush stroke, you do an outline really, unless you fight the tool.

[Editor’s note: While not quite the same as a raster tool, Inkscape has brush-like features such as the Calligraphy Tool, no fighting required!]

So there’s people doing fabulous, professional artwork - really good quality artwork with GIMP. It doesn’t suit everyone, but if it does suit you, it’s absolutely awesome. It’s got lots of features. I don’t know of any other art program where you can control the brush size with a MIDI keyboard, right. That might sound really weird, and yet, I can imagine holding a MIDI device in one hand, or using one foot to control a MIDI device, because it exists, a pedal for example, and wiring that to brush size and that could be really interesting.

So yeah, GIMP is fine for doing professional art, but as an artist you’ve got to figure out which tools you’re going to use. When you walk into a gallery and you see paintings by the old masters, you look at them and they stand out. They’re called masters because they’ve mastered the technique, and they think about what they want to do, and the technique becomes – as far as the observer is concerned, watching them work – they’re not thinking about how to achieve the effect they want, it just happens. In actual fact, some of them probably spent a long time thinking about the effect they want, but it doesn’t seem that way.

Some people say it takes about 10,000 hours of work to become a master in something if you practice it. I think you can become a master in digital painting, in multiple tools, and GIMP is one of them. It’s a strong one, but it doesn’t have to be the end of it.

Jehan: Does your work in W3C have maybe any relationship or link with GIMP?

Liam: We have stronger links to Inkscape actually. The strongest link to GIMP a long time ago was the PNG support, because the PNG image format was jointly developed with W3C and IETF. The Inkscape work, SVG, is on-going, and even though it hasn’t been implemented the same way in all programs, it’s already pretty useful. But there have been other overlaps such as color management and compositing, for example.

Liam Quin (right) in costume at W3C conference, CC-BY-SA

At one point I reached out to someone from Adobe who was working on CSS compositing, and who knew about the internals of Photoshop, and he came and joined the GIMP IRC channel and talked with people there about color models and compositing. So in some ways I’ve tried to encourage communication. And I think the culture of the web, the web has really done a lot for free and open source software. More people are using free software now than ever before, because of free web browser and free web tools. So the work that we’re doing at W3C certainly relates to the GNU project, the GNOME project, the GIMP project – both technically, legally, socially. So there’s links in that kind of way. But I don’t think we have a whole lot of direct contact.

Jehan: What do you see in the future of GIMP?

Liam: I suspect that the long term future of GIMP is that these native toolkits are going to get replaced with webpages and Javascript.

Jehan: So you mean GTK+?

Liam: I expect eventually there will be a Javascript to replace GTK. In ten years time, I think GIMP will be running in a web browser as a web app in some way.

Jehan [laughing]: Seriously, or is that a joke?

Liam: No, I was completely serious. And the reason I think that is, what the web has done is it’s assimilated – like the famous Borg – it’s taken over all sorts of things. Native clients for particular applications have gone away whenever it was feasible to replace them with a web app. 25 years ago – can that be right? In 1995, how long ago was that? 22 years ago… I was in a conference in Ottawa, for document management systems. And these all had proprietary desktop clients that were basically GitHub. That you loaded a proprietary client, and it had a button to check out a file, another one to check it back in, open it in editor, show differences.

And there still are proprietary clients for git and CVS on Windows, for example, there’s TortoiseCVS and friends, but I wouldn’t want to bet my business on something like that today. Because someone else would come along and make a web-based one, and it would work almost as well as mine, as best as I could do. And it would cost them a tenth a cost to develop it. They could sell it for much less than I could sell mine, it would be easier to support – I’d be out of business. And in fact, almost all of those document management companies have gone out of business. I think there’s two left of the ones that was at that show, and one of them has been bought by AutoCAD. So, I think we’re going to be replaced – the question is when, not whether.

Jehan: So we will be replaced, or GIMP will go to that format?

Liam: One way or another. That will depend on the people, whether the people are willing to do that change, and they’re around when it happens.

Jehan: And so GIMP would run remotely on some server?

Liam: It’ll run in your web browser.

Jehan: So still locally, but on your web browser?

Liam: Yeah, I think so.

Serpentin-Tanzerin, from Moderne Kunst in Meister-Holzschnitten Band XV (1901), scanned and restored by Liam Quin, CC-BY-SA

Simon: So this is my question. When you say Web page or Web browser, you’re not talking about Software as a Service.

Liam: No, I’m actually talking about a program written in Javascript or something that compiles into Javascript, more likely. What they call a transpiler these days.

Simon: But users doesn’t necessarily have to realize it’s doing this, right?

Liam: No, correct. They’d look identical for all we know, because every GIMP window would just be a browser window.

Jehan: It’s funny because Mitch had basically a question about this. Did you read Mitch’s message?

Liam: Yes I did.

Jehan: He had a question about Javascript, and we kind of laughed about it.

Simon: Yeah, but this was a different Javascript approach.

Jehan: Javascript for the UI.

Simon: Yes, but not necessarily via a browser.

Liam: I’m expecting gegl.js to happen, let’s put it that way.

Simon: In some ways I think it’s even already happened.

Liam: It has already, because people have done the automatic translation. But what you really want is something written to take advantage of the browser’s own image processing capabilities whereever it can, so it actually goes fast.

Simon: And, for example, having a WebGL backend or something.

Liam: Yeah. I mean, things written in the browser, in Javascript, can actually be reasonably performant now, they can go reasonably fast. I just think it will happen. If it doesn’t happen, what will happen is someone will write – people are already writing – one of the many photo-editing applications and art applications that are happening as web apps now, will take over. Because there will be 20 million users of the one, and 5,000 users of the other, probably. But that would be sad because there’s so much work that’s gone into GIMP. I would like to see it carry on, but I just think that the future may be running in web browsers.

I don’t know for sure. I mean I’m not sure I like it. I’m not saying drop everything and do this now, but I am saying “keep your sword at your side, for you know not when the hour will come”. That’s a Biblical quote – they’re actually referring to the end of the world [laughing].

Jehan: Is there something regarding your work with GIMP, for your stock image company - is there anything in GIMP that you’re really looking forward to? A feature or planned change, to really help your daily work?

Liam: Yeah, actually. I think that non-destructive editing when that happens will really help me. Because the ability to go back and conceptually edit the graph, for example, to have a check box – not saying you’d do it this way – but imagine having a checkbox by each entry in the undo history, and being able to deselect one of them and see what the image would be like if I didn’t do this. You can’t actually implement it like that inside GIMP, but that’s a way of thinking about how it might look.

Because quite often I would do something like a 10, 15, 20 pixel radius blur to get rid of screening artifacts, and then I have to do several other operations and scale the image down and sharpen before I get an image I can sell. I can’t sell a blurry image, but I can’t sell one that’s made up of lots of dots either. So I have to get rid of the dots and I do that either by blurring or wavelet decompose or something like that. And then I do other operations, and I discover some time later that I didn’t use the right radius for my blur, because the challenge is to use the smallest radius that gets rid of all the dots. If I use too big a radius, I get an image that’s too blurry to sell. If I use too small a radius, when I scale the image down, the dots come back when I sharpen it. So I can imagine being able to go back and just change that radius, and have GIMP show me the result of the scaled down image, and I can see “Yes, great, that was the right number!”.

So the non-destructive editing will be a big plus for me.

[Editor’s note: Non-destructive editing was added in GIMP 2.99.18, and officially released in GIMP 3.0 in 2025!]

Image of Grose: Antique Books, photographed by Liam Quin, CC-BY-SA

Jehan: You also have a very interesting use case, which is that you work on very, very big images.

Liam: I hear that a lot from GIMP people. I hear it a lot from photography people. I never hear it from print people. People doing graphic design with print, are not surprised if an image says it takes a gigabyte of memory for one layer.

[Audible gasp of shock from the audience]

We have people who come to the GIMP IRC channel, say they do work for print, and they’re editing a 20,000 by 15,000 pixel image in RGB mode and it’s going a bit slowly, and what should they do about this?

Jehan: Yes, of course you always have people who have bigger images, but what is a typical size for you?

Liam: Well, that is a typical size. I was editing one yesterday that was 3.6 gigabytes when I first opened it, just one layer. And I scan in high resolution because people typically want a detail of an image at large size, and also because I can produce higher quality images than most other people. And if you’re a small company, you’ve got to have an advantage over the big companies. The big companies have millions of mediocre images and I’ve got thousands of really good ones, so people come to me. And it works.

There are some issues with GIMP. I mean, 16 gigabytes of memory is a minimum. My laptop’s not really good enough for the larger images, it has 8 gigabytes. My desktop has 32 gigabytes and that’s okay, as long as you don’t use multiple layers. You start using too many layers then you have to be careful.

Jehan: Do you think that GIMP handles the images well?

Liam: Pretty well. I understand that compared to two or three other image editors that I’ve use, it seems very slow with these images. An example is if I do Curves, after pressing Okay I might have to wait 5 minutes, whereas in the other editors I don’t have to wait at all.

The reason for that though is that they’re doing the work in the background, and they’re just showing me the preview image, what I can see on the screen, and then they’re applying curves in the background to the full image. And every now and again you catch up and the program tells you to wait for no obvious reason, so it’s a trade-off.

Jehan: So do you think it’s better what we’re doing, or do you think…?

Liam: I actually think in most cases it’s better to do the work in the background, because after I’ve done Curves, I probably want to look at the image and think for a minute about what to do next, and the program could make use of that time. But I’m also aware that there’s a lot of optimizations that has not been done to GEGL yet, and it could well be that the bottlenecks could be improved a lot. So I’m not too worried about it right now. It’s usable, there are places where it’s slow, and I’m not too worried.

Aryeom: I want to hear about your typography.

Liam: Yeah, I have a background in typography.

Requiem by Liam Quin, CC-BY-SA

Aryeom: And you have another art style.

Liam: I do, I’ve done other art, yes. I do calligraphy as well. But the calligraphy I do is done with pen and ink and gouache and paper. That’s partly because I don’t have a tablet. So this week I actually got to try graphics tablets, thank you, although I discovered it didn’t work with GIMP 2.9 properly, the preview version. It did work with 2.8, and I think I could get use to drawing with a tablet. So that was quite interesting – I wasn’t sure before. And it would be quite interesting to do some calligraphy with a tablet. But with calligraphy I’m use to looking at the pen, positioning it between pencil lines and thinking about each stroke. I think working with a tablet would be more like brush calligraphy than paint calligraphy, but I don’t know.

The hardest thing I’ve found is that the tablet’s surface is too smooth. So the bite of the paper, as they call it, which slows you down when you’re drawing, is an important part of calligraphy.

Jehan: Someone was telling me about Wacom tablets, and other tablets I think, where you can put paper on the tablet and you actually draw on it. Have you seen that kind of stuff?

Liam: I see! I hadn’t thought of that, that would be really interesting. And the computer would record the drawing while I made it.

Jehan: You can even do it while the tablet is unplugged, because it will record it and then later you can plug it in.

Aryeom: Yes, but it’s vector.

Jehan: Maybe vector, yeah.

Aryeom: Can you send us your work?

Liam: Yes I can. I can send you some pictures, yeah. Some of it has been published so that’s quite nice. I had a calligraphy piece that was used on the front cover of Time magazine, so that was quite nice. I don’t often get phone calls from the art director of Time magazine, so that was a surprise.

Front cover of Time Magazine, featuring calligraphy by Liam Quin

Americo: I have a question. Do you have any advice for users, artists, photographers who think about or consider using GIMP? Do you have any advice on how we should approach it?

Liam: I suppose it depends on what you’re trying to achieve and your personality. So if your personality is that you just like to go and do things quickly, as I said earlier. If you want the MyPaint style where you just go and do, but you want more richness, which GIMP gives you. For example, you might make a set of images which are blank or mostly blank, and basically use them like templates. You just double-click on an image and GIMP comes up with that blank image, and then you start. Which is much easier than doing File → New and using a GIMP template. Then you can just start painting.

I mean you could ask people who paint. We have people like Americo here, who is doing fabulous stuff with making his own brushes from patterns in the clipboard and with paint dynamics, and really spending a lot of thought into exploring the tool and what it can do.

And you have other people who say, “All I want is something like a charcoal stick with undo”. Or you have people who want things more like an engineering drawing. I occasionally do text-based art with GIMP. I’m more likely to use Inkscape because it has slightly better typography. And these days I’m more likely to use a web browser and CSS, because I can get the OpenType features which I can’t in GIMP or Inkscape. If you’re a typographer, being able to use the font properly is important to you. GIMP is very, very limited at this time, it really is. But it has it, and it’s the only thing you can go back and edit afterwards. So from that point of view… [laughing]

I think the biggest two problems I hear with people using GIMP, one of them is they haven’t found Single Window Mode. If you’re not someone who grew up with the X Window System and applications having 25 windows, you might find it really cluttered and difficult to manage. So then you get switched to Single Window Mode, which I use. Even though I used the X Window System as early as 1988 I think.

Simon: It’s the default now, at least for 2.9.

Liam: I’m glad it’s the default. It’s not perfect, it was never finished, but it’s more approachable.

The other default that people often have to change is the tile cache size. If you’re working with print images especially, then you need to change the tile cache size to be three-quarters of your physical memory or maybe more, depending on what else you’ve got running. You want as much in memory as possible without crashing your system, and it can be a hard trade-off.

Americo: Something I often discover is that people try to “get” GIMP by trial and error, and I’m not sure if this is the right approach to software as complex as GIMP. I’ve tried this with Paint Shop Pro and also Photoshop, and I didn’t get far either. I always have to turn to the manual.

Liam: I believe it’s deliberate that you can’t in Photoshop. Paint Shop Pro I don’t know about, it’s been years since I used it. But I suspected – don’t know this for sure – I suspect that in Photoshop, what they’re trying to do – you use to get this from the Debian community as well – the idea is to make something hard enough, it’s a trial by fire. You make something hard enough, that people have to put real emotional effort into learning it. And then they’ll stick with it through thick and thin. Because they’ve put so much emotional effort into learning something so hard.

Photoshop and Illustrator have an interface where there’s hidden buttons in the toolbox. You hold down the mouse pointer over one of the little squares in the toolbox and eventually a hidden secret drawer opens and more tools appear. There’s no way you would discover something like that, right, it’s not discoverable. The way that you find it is the manual or a tutorial.

[Editor’s note: In GIMP 2.10, we ended up adding an option for these “hidden buttons”, known as tool groups]

So for GIMP, probably the best of the books I’ve seen for learning GIMP is called “The Artist’s Guide to GIMP”, and I love that guy’s tutorials. He says things like, “To start with, press D on the keyboard to get the black and white default colors. Now press X to exchange them. Now you’re drawing with white.”. And telling you things like that, mean that the tutorial will work regardless of your previous settings. He’s teaching you a way of using GIMP where you don’t mess yourself up, and if you don’t mess yourself up, you have much more confidence to explore.

Cover of ‘The Artist’s Guide to GIMP’, by Michael Hammel

So I really love his tutorials. He explains, he says how you can do things by clicking, or by using the keystroke or by using the menu. It’s really, really well done. So that’s what I have suggested to people who want to learn GIMP, is that particular book. But other people prefer video tutorials. I don’t have patience for video tutorials – just tell me! But a lot of other people like them.

Aryeom: If I want to make a tutorial, is there any advice on the best way?

Liam: I’ve done some tutorials that people didn’t like, and some that they really did like. And the tutorials that people really did like are the ones where you’re teaching, and at the same time you’re not assuming. So you don’t assume that people know jargon, you don’t assume that people know special names. If you start off in a tutorial saying “The first thing you’ve got to do is add an alpha channel to your image, and then divide the hypotenuse by the cosine of the vertex”, you’ve lost three-quarters of your audience.

If instead you say, “We need our layer to be transparent so that we can see things in the lower layers through it, and to do this, we have to use a menu item called Add Alpha Channel”, then what you’ve done is you’ve taught someone what alpha channel means and why they want to use it. So instead of just saying “Do this, do this, do this”, if you teach people a little while, you’re also writing a tutorial that’s more robust. Because it might be that in a future version of GIMP, the menu moves. So you can build in notes. You can do things like say, “If you can’t find this, you can use the slash key to search for things in the new release. This is how you do that”. And then you might make a tutorial that’s robust and that people follow. Because people get really upset if they find a tutorial for GIMP version 1.2 and they try to follow it and it doesn’t work. So then they find a tutorial for some other image editor and they try to follow that and it doesn’t work, obviously. And they get angry and swear at us, and maybe they come to IRC and say your program is full of worms and your mother was a raspberry tart! And we say, “Why are you saying this?” and they say this tutorial doesn’t work!

You can’t write something that’s going to be proof against future completely, but you can write something that’s going to be a little bit robust, and that teaches people and keeps the sense of delight and fun. And if you do that, people will enjoy using your tutorial and learn from it, and you’ll have fun.

Aryeom: Thank you for the advice!

Liam: I’m hoping to do some tutorials this year for scanning images, working on scanning images from books, old books, published, printed books.

Jehan: That’s good – for gimp.org?

Liam: Yeah, I hope so. One of the things I’m really hoping for is the XSane project makes a version of their GIMP plug-in that works with the new release, with 2.9, to do high bit depth images. Right now it’s restricted to 8 bits per channel. My scanner can do 16 bits per channel, RGB, it’s A4 or Tabloid size. But in fact XSane crashes if I try to do that.

Jehan: So you scan with another software?

Liam: I scan with XSane, but I have to save it to a file and then I have to open the file in GIMP. And that’s actually a pain for me, because the point at which I choose the file name, the book is still on the scanner, and my file names are usually the page number in the book and the caption as the file name. But if the book is on the scanner then I can’t see what page number it’s on, so I have to remember beforehand to write down the page name, so it’s a pain. So if I’m scanning six images or something at once with the plug-in, it arrives one after the other in GIMP. And a fabulous GIMP feature, not in any of the other software I’ve used, is that I can be scanning one image with a progress bar going along, cleaning up another one, and saving a third one, all at the same time. And that’s three times the throughput that I get with other software.

Happy New Year from Moderne Kunst in Meister-Holzschnitten Band XIII (1897), scanned and restored by Liam Quin

I’ve been to places where they’re scanning books professionally, and they have three, four, five computers in a row, with multiple scanners. So you start scanning on one, then you move to the next one, start scanning on that, go back to the first one, start cleaning it up, go to the next one, start that one scanning, go this one, start saving the image – because that other proprietary software could only do one of those things at a time. That’s still true today.

So by using the plug-in I get much more throughput, so I can have the scanner going – and it can take up to 20 minutes to scan an image, and it can take up to 5 or 10 minutes to save an image. For GIMP to export an image to PNG for example, can take 5 or 10 minutes if it’s a several gigabyte image going to a hard drive. So, it’s really nice to be able to work effectively with multiple threads. I like that.

So I should write some tutorials because GIMP really is better than anything else I’ve used.

Aryeom: I will translate it to Korean because I’ve seen someone on a Korean website asking how to scan in GIMP like this.

Liam: Okay! Maybe they’ve already written a better tutorial than I will, we’ll see. I’ve been doing it for more than ten years. 1999, I think, I started my website, fromoldbooks.org. So it’s going to be coming up to 20 years old before too long. Some of the books are 500 years old.

Jehan: And you’ve been using GIMP since the beginning?

Liam: I used GIMP early on. I had a period when I was writing a book and the publisher required me to use Microsoft Office, so I was on Windows. For a lot of that time I was using other software. I actually end up using Paint Shop Pro because it had something like, what GIMP calls a corrective or reverse transformation.

Jehan: And GIMP did not have it?

Liam: GIMP had it, but GIMP wasn’t doing well on Windows at the time. And the other software I had, Photoshop, did not have anything like a corrective mode that was as useful. GIMP’s corrective mode is actually better because it’s a grid and not just a line. The Photoshop one, as I recall, you draw a line on something that should be horizontal or vertical. But in most scanned images I’ve got, they’re hand-made engravings, there isn’t going to be a definite horizontal or vertical, because it’s an artist’s sketch. So I have to choose what looks best. I start out by getting the grid roughly right, clicking rotate and seeing what happens. Flatten the image to get rid of the corner artifacts and seeing what it looks like. And if it looks okay – with experience you can most of the time do it first time.

One of my few patches to GIMP in fact, was to change the undo history to say what the angle was. This way, I can do an undo, even half an hour later, I can see what the angle was and I can say, “Well, that was just a bit too much, I’ll try reducing it just a bit and try again”, and usually second go I get it right. And that’s an example of it being an open source free/libre software. I was able to contribute a patch, which Mitch kindly rejected, and I was able to redo it, and get it in the right format. And he incorporated it – and then I think he wrote it even more. Looking at the code yesterday I discovered – it’s a year or two since I did the patch – I looked at the patch and discovered it’d been rewritten even more, which is good. But that simple patch has saved me, cumulatively, hours and hours of work, just knowing that information. Because I might do two or three rotations in a sequence, then go back and undo them and do a single rotation, because you degrade the image slightly when you rotate it. And if it takes 10, 15 minutes to do a rotate of a large image, then saving two or three attempts at rotation everyday has saved me a lot of time, you know.

Screenshot of Undo History with Rotation Angles shown, from Liam’s patch

So that’s all part of why GIMP is so fabulous. That, and being able to come onto the IRC channel and say a particular thing is really slow. The first time I did that, it was Sven at the time years ago, he couldn’t believe it was taking me 20, 25 minutes to rotate an image. He looked at the code, and he had me do some profiling, and then he said “Oh”, and made a one line fix. And it went down from 20 minutes to 2 minutes the next time I recompiled GIMP, ten minutes later. Same day! A fix on the same day. In the libre graphics world, in the free software world, that’s not unusual. In the “I’ll make a support ticket with my vendor” world, it’s not unheard of but it’s pretty rare. So that’s been a real plus.

Sometimes the developers will say “No, we can’t make that faster because…”, or “We won’t, because we’re going to replace it”. But there’s been a few occasions when GIMP has been faster because I’ve gone into the IRC channel and said I profiled this, or here’s a patch, or can someone fix that. So it’s been fabulous.

Jehan: I think we’ve asked most questions. Is there anything you’d like to say that we didn’t ask you?

Liam: Yeah. The biggest thing I think we have to do, is get a message out to the world that GIMP is perfectly suitable for professional use. It’s aimed at professional use, and people are using it professionally, successfully. It’s not a second choice, it’s a first choice. It’s not because I can’t afford this other program, or because my principles say I don’t eat meat, or I don’t use programs beginning with P. It’s a first choice – it’s actually better for what I’m doing then any other program I’ve used, and I’ve used a lot.

So we need to get that message out a lot more, and we need to have more confidence in talking about GIMP. We’re close to it, we see all the problems, we have visions that we know are not happening, and yet, we forget sometimes that we’ve got something really really good there. And we need not be ashamed to say that.

Aryeom: Why do you think people are sometimes ashamed or don’t have confidence to use GIMP?

Liam: I knew a chemist once who worked in a jam factory, where they made marmalade and jam. And he saw what the jam did to the steel containers where they mixed it. And they had huge steel vats like the size of a small building, like a big mixing bowl. And the jam is highly acidic, and it would eat the steel. And he said he would never eat jam again, after seeing how jam was made. But you know, if you make jam at home it’s no better. It’s no better than any other food, or worse – alright, it may have too much sugar in it. Or it’s like the sausage maker who knows what goes in the sausage.

We’re aware of all the problems, and we’re aware that we have visions of how GIMP could be in some other universe, and it isn’t. But that’s okay, it’s what it is. The fact we can say, the text tool could be improved so that after you scale the image, text is still text for example. We can look at that and say “Yeah, that’d be fairly easy to fix but we’re busy”. But we still have a better text tool than a lot of other programs, you know, even without making any other changes. We’re too busy to go look at other programs – and perhaps worried too about intellectual property, about using someone else’s design. But the truth is, GIMP is better than, in many ways – not perfect, not saying that – but it’s better in many ways than we realize.

Links

• Liam’s company, Delightful Computing
• Liam’s other company, From Old Books

Week 31

This week's icon is for Mark Wyner's project:
Ratio: "Validate color contrasts"

Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Join as a community sponsor to maintain a steady supply of app icons to the Linux ecosystem (every little helps!).

After connecting some dots, it came to our notice that some conduct reports written through the conduct.gnome.org form might have been silently lost. If you have sent a report between Jan 5th 2026 and Sep 28th 2026 and got no response for it, we invite you to send it again, either through the form or conduct@gnome.org.

How

In Jan 5th, GNOME sysadmins introduced a filter to the CoC report form to prevent attempts of SQL injection. The filter was however overeager, filtering out messages containing certain natural English words that matched a subset of the SQL syntax. We do not know the full impact of this filter yet. After the issue came to our notice the GNOME sysadmins quickly fixed it on Sept 28th.

We appreciate GNOME sysadmins’ diligence and the speedy fix.

Contact us

If you’ve sent a message in this time period through the conduct.gnome.org form and are missing a response from the CoCC, we invite you to send the report again. It sounds likely that it was filtered down and missed by the CoCC.

The CoC Committee

I'm happy to announce the availability of a COPR repository which rebuilds Fedora 45 kernels with the patches from the qcom-laptops git branch added. This is a branch where various upstream pending patches with Snapdragon laptop improvements are gathered. For the exact contents of the latest kernel from this COPR see this Fedora kernel git-repo fork.

Installing the kernel from this COPR adds camera support for various X1 laptop models, adds bluetooth support for the ThinkPad T14s as well various other improvements. Most of these are expected to land in the 7.4 kernel.



comments

After the initial work to make Fedora live iso media boot OOTB on Snapdragon X1 laptops in Fedora 44, I've continued working on improving the Fedora experience on these laptops for Fedora 45. For Fedora 44 a long list of workarounds was necessary, see the Snapdragon laptop install instructions on the wiki.

For Fedora 45 various improvements have been made in the mainline kernel and I've been working on improvements at the initramfs generator / distro level. Together these result in a much smoother experience, see the install instructions for Fedora 45 on the wiki. A few workarounds are unfortunately still necessary for Fedora 45. For Fedora 46 I hope that the Fedora aarch64 live iso media will just work on X1 laptops.

Note that this blog post is about Snapdragon X1 (Elite,Plus) laptops. Support for Snapdragon X2 laptops at the same level as the current X1 laptop support is quickly coming together in the mainline kernel. But the 7.2 kernel used for the Fedora 45 beta and release isos is still missing some bits and Devicetrees, so Fedora 45 will not work OOTB on Snapdragon X2 laptops.



comments

Are AI chatbots quietly shaping the perceptions of U.S. voters? Voters trying to educate themselves about candidates "are unknowingly being served partisan talking points in the guise of neutral news summaries," write two news researchers in Politico magazine: Leading AI chatbots cite partisan websites masquerading as independent local news outlets nearly half of the time when people ask about candidates and issues that the partisan sites have covered in the midterm campaign, according to a new audit by NewsGuard, an organization focused on news reliability where we work as analysts... NewsGuard prompted seven leading AI tools with queries based on recent coverage of candidates and issues by 12 pink slime sites — six left-leaning and six right-leaning. The results were stark. Collectively, the chatbots cited pink slime sites along with other sources in 48.2 percent of their responses. In 7.7 percent of responses, pink slime sites were the only sources at all that were cited in chatbot responses, although other sources appeared in the source list provided at the end of the response. None of the AI tools received results they'd probably be eager to boast about, though the percentage of chatbots' responses that cited a pink slime site had a relatively large range: 70.8 percent for OpenAI's ChatGPT, 54.2 percent for Microsoft's Copilot, 54.2 percent for Perplexity, 50 percent for Anthropic's Claude, 41.7 percent for Google's Gemini; 37.5 percent for Meta AI and 29.2 percent for xAI's Grok... The seven chatbots were also collectively three times more likely to cite left-leaning pink slime sites (cited in 36.3 percent of responses) than their right-leaning counterparts (cited in 11.9 percent of responses) — though that may have more to do with the progressive sites' far more frequent posting than any political bias from the chatbots. "While citing the pink slime sites, only one chatbot response out of 168 total queries noted the partisan nature of the source," the article points out. But they also note that the real problem seems to be that consumer-oriented AI chatbots just "use much of the internet's content — regardless of the reliability or standards of the source — to frame their answers."

Read more of this story at Slashdot.

"A federal jury in San Diego awarded Taction Technology more than $5.7 billion in damages Friday after finding that Apple infringed claims from two haptics patents," reports CNBC: Taction sued Apple in 2021 in the U.S. District Court for the Southern District of California. The company alleged that Apple was improperly "capitalizing on Taction's innovation and success" by selling devices that infringed on its vibration technology, according to the complaint. Apple initially won dismissal in 2023, and the Federal Circuit later revived the case.... Taction argued that Apple's "Taptic Engine," which is embedded in its Apple Watches and iPhones, uses its inventions without proper license or authority. Taction's lead counsel told CNBC "Taction waited five and a half years for this case to get to trial, so it was a long time coming." CNBC also reported that the jury "did not find Apple's infringement willful" — and that Apple said they'd appeal.

Read more of this story at Slashdot.

A new Brookings Institution study notes the "strikingly physical" economic footprint of AI's buildout, from specialized chips and electricity to purpose-built data centers. (Two-thirds of a data center's costs are IT equipment, with one-third going to real estate and its associated power infrastructure.) "At an average of 3.63 percent of GDP per year, the projected buildout would be larger relative to the economy than the major U.S. canal, railroad, electrification, highway, and telecommunications investment booms." This is pushing up prices for workers, electricity, and even commercial real estate (as well as consumer products that use chips), notes the Wall Street Journal, and reducing the construction on new houses and apartment buildings. And in addition, the paper points out, projections for this buildout "would double the electricity consumption of the entire U.S. residential sector." The calculations come from Columbia Business School finance/real estate professor Stijn van Nieuwerburgh — and Reuters explains their significance: Just as the rail and telecoms expansions led to notable bubbles and busts, Van Nieuwerburgh wrote that the extent of the buildout, the still-untested revenue streams, and the intricate financing structure emerging around AI mean it could be primed for a fall. "This is freaking complicated," he said in a briefing with reporters of the arrangements emerging between AI firms, major tech hyperscalers, banks, private credit lenders, real estate firms, and a host of other players involved in building what he conservatively estimated at 183 gigawatts worth of new data-center capacity over the next seven years, compared with about 57 gigawatts currently installed.... The investment underway already has outstripped what the major players can fund from their own cash flows. The shift to outside financing has increased leverage, redistributed risks across the economy, and made the venture dependent on revenue streams that have yet to be proven, Van Nieuwerburgh noted in the paper, which will be presented on Friday... "These developments do not imply that financial distress is imminent. Strong growth in AI applications, high utilization, and continued improvements in model capability could support the projected infrastructure and generate stable cash flows," he wrote. "But the combination of uncertain demand, rapid technological change, execution bottlenecks, and high leverage creates meaningful downside risk if expectations are revised." As an example, he wrote that the AI industry will need to be earning about $3.7 trillion in annual revenue by 2032 to achieve the expected return on the investment, and "given current estimates of annual combined revenues of OpenAI and Anthropic of around $100 billion, revenues would need to grow at roughly 80% per year." The paper suggests policies that "improve measurement and transparency" for financing.

Read more of this story at Slashdot.

Like many, I’ve been thinking a lot about the impact of LLMs on the free software community. In the GNOME community, there have been a couple of posts on Planet GNOME and Discourse, and assorted heated discussions on Matrix and Mastodon. We are not unique in this — there are similar conversations in the KDE and Debian communities as well.

I think we should be actively working on figuring out how best we can adapt to the new world we find ourselves in, and use LLMs for the good of GNOME.

The argument being made

Some folks in the community would like to have the GNOME project refuse to accept LLM-generated content (be it code, bug reports, or other forms of contributions).

The concerns are not unfounded. LLM-generated content can often be verbose, annoying to read, and downright incorrect. This is very dependent on specific models and how they’re used, and the state of the art is constantly changing.

There are other nuanced arguments around the subject, but I’m skipping them in the interest of brevity.

The thrust of the argument is the immediate increase in maintainer load, which is already a matter of concern in the project. I think this is valid, but I think we have to search for solutions to address this problem (for example, the Linux kernel project has Sashiko).

Inevitability

In my own experience, I have used LLMs to write new tools that I would not have had the time for. I have used them to learn about topics and codebases that would otherwise have taken me much longer to navigate. Using these tools, I have been able to solve some pretty non-trivial problems.

In the process, I am also learning the limits of the LLMs, what kind of usage makes sense in what kind of context, and how not to lose the process of critical reasoning while working with them.

In every conversation I have had with people across various parts of the software industry, the experiences are similar, and the process of software development is changing.

That means that we also have to change the ways in which we interact with each other in building the software that we care so deeply about. We do not need to eject our values to do that.

Access

Like me, other people are able to use LLMs to build prototypes, write patches, and as a learning tool. This is especially useful for areas where we don’t have good documentation. Sometimes the patches or the learning are wrong, but that is not terribly different from reading the code and learning as one often has to do. And as with any nascent tooling, we are still building the right mental models to use for the process.

This makes contributing to GNOME more accessible. The arcana of software development are suddenly not in the way of getting something done. Perhaps we could embrace the loss of those barriers and figure out how to include more contributors without adding additional burden to our maintainers.

Accessibility

There is so much we are yet to realise with LLMs. We could have LLMs (on-device, or otherwise) do:

• Live captions as hearing assistance
• Translations for non-native speakers
• Image descriptions as visual assistance

Some of this is table stakes now on other platforms. We have a history of continuous improvement to the desktop accessibility stack, and LLMs unlock a lot of new possibilities to raise the bar on what we are able to provide our users.

Keeping GNOME GNOME

There are a lot of details missing here — what would the processes look like, how do we keep the infrastructure free (open models? with open datasets?), and so on. But for that, we need to agree on a direction.

As a community, we have always been deeply invested in the human aspects of the software that we build. Even if the state of LLMs is frozen at the current level, we are seeing a sea-change in the process of building software, and we cannot hide from it.

As with other changes before this (the inception of the project, the adoption of the HIG, GNOME 3), it behooves us to play a positive role in defining how we build software for humans in the future.

Version:7.3-rc5 (mainline) Released:2026-09-27 Source:linux-7.3-rc5.tar.gz Patch:full (incremental)

Jordan Petridis evidently has strong opinions on the use of LLMs. He’s welcome to those.

What’s not welcome is when it escalates into vigilantism and defacement of bug reports. Specifically for me, this bug where a tag “Probabilistically Automated” was added. That tag has a meaning of

Usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code.

I am reading that as screaming “It’s the work of the Devil!” in a shrill voice. The naming of the tag likewise suggests religious fanaticism.

The LLM work in the bug report was (1) specifically requested, (2) excellent quality, and (3) very helpful given that the underlying problem does not happen on my machine.

If you can’t be bothered to actually assess the quality instead of hiding behind “usually” then you are not adding anything positive and should stay away.

When asked for an explanation, none was provided. A comment on his blog post was, as far as I can tell, moderated away.

(I do agree that poor-quality LLM-generated bug reports exist. Do they ever. A tag like the above is not part of the solution to that, whatever it may be.)

Waymo's self-driving car technology "continues to outperform human benchmarks," the company claimed this week. "It was involved in 841 fewer injury-causing crashes — an 82% reduction compared to human drivers." Electrek reports: We've seen various Waymo crash data before, with Waymo claiming crash reductions. That's all well and good when the company says it, but we've also seen independent data confirming similar (though lower) crash reduction numbers... Waymo has enough miles that it's ready to start quoting how many injuries it has prevented, and the number is pretty high. Its newest crash data states that it had operated a total of 271 million driverless miles through June of this year, which is 50 million more miles added in the 3 months since its end-of-March update. Over those miles, Waymo says there was an 82% reduction in crashes that caused injury, and a 95% reduction in crashes that cause "serious injury or worse" [compared to human drivers]. Waymo also says that compared to human drivers it's reduced injury-causing crashes involving pedestrians by 93%, cyclists by 86%, and motorcyclists by 82%. Waymo's analysis comes from San Francisco, Los Angeles, Austin, Atlanta, and Phoenix, and its blog post includes video showing some near-misses where it says its automated system prevented an injury-causing collision.

Read more of this story at Slashdot.

"OpenAI said it has paused training of its latest AI models," reports the Associated Press, "as reports of AI agents going rogue mount." The decision to halt development came just hours after the company disclosed Friday that it was reviewing several incidents from the summer in which OpenAI agents searching federal government websites acted in unexpected ways beyond what was asked of them while gathering and distributing information... OpenAI said in a statement that it will resume training "only when we are confident that we have additional safeguards" in place, adding that it expects it will have to "hit pause" again as AI develops and other issues emerge... It is the second time in three months that OpenAI has halted development of its models. The first came in July after disclosure of a cyberattack targeting AI startup Hugging Face, a now notorious incident that raised fears the industry was losing control. OpenAI "also said it had notified dozens of third parties about improper activity," reports Reuters: As of mid-September, one person briefed on the matter estimated that OpenAI had found roughly two dozen incidents of its agents acting in undesirable ways. But the number has continued rising as OpenAI teams sift through internal logs of the agents' activities and find previously unknown cases, the two people close to the company said... OpenAI has acknowledged a general need for more transparency around rogue AI behavior... Even so, two people familiar with OpenAI's investigation into its agents' activity described it as locked down and shaped by company lawyers. The process has been unusually compartmentalized for a company that some former employees say was more open about these issues in the past, the people said. Roughly 100 people were in some way involved in the process to understand the Hugging Face hack, three people briefed on the matter said. During that process, evidence of other incidents surfaced. Reuters has previously reported that OpenAI investigators looking into the Hugging Face breach were discouraged by the company's lawyers from expanding the scope of the investigation to include other incidents. OpenAI said its lawyers did not discourage deeper investigation. Many incidents have been uncovered by outside researchers rather than OpenAI directly. In several episodes, the agents took problematic actions that went unnoticed by the company for months. Meanwhile, Axios reports that Anthropic's Claude Opus 5.5 model "sought to escape a sandbox — a secure testing environment — in 1.5% of test runs, though the company emphasized that these were adversarial experiments where a task couldn't be solved without escaping the sandbox." Anthropic points out that those tests were run "without the additional safeguards we apply in production". But they acknowledged that then Claude Opus 5.5 "when given apparent credentials to a public package registry in a simulated security exercise, took potentially harmful actions in roughly half of cases. Very rarely, pre-release snapshots produced and acted on spontaneous malicious tool calls, and during training some snapshots concealed actions from an automated grader." Claude Opus 5.5 "showed less misaligned behavior and less cooperation with misuse than any other recent Claude model on nearly all measures," Anthropic adds, and "took overeager or destructive actions less than any other model we tested." But Axios makes an interesting estimate about that 1.5% of test runs (without safeguards). "Anthropic and other companies conduct hundreds of thousands of test runs on their models, or more, sources said. That means even a small percentage of misaligned behavior can still amount to tens of thousands of incidents in which the models behaved in unexpected, sometimes troubling ways." The sheer number of incidents, which occurred in recent months in internal testing and the real world, indicates that the problem is orders of magnitude more complex than what is publicly known. The findings, which are surfacing as part of internal work to assess models and in investigations at both companies into model behavior, raise questions about whether either company — or any top model-maker — is currently capable of establishing complete control over their technology. The episodes include bypassing guardrails, creating message boards, escaping sandboxes, website hijacking, self-prompting or seeking to bypass monitors, sources said. They occurred in internal testing and in the real world, and many have yet to become public as security researchers continue to investigate, sources said... Some at OpenAI see Hugging Face as a one-off, with disclosures about future incidents likely to be less severe due to improved controls and the unusual nature of the testing they conducted, which involved an unreleased model, sources told Axios. AI security researchers agree that there are simple fixes that will help AI companies avoid aspects of what made the Hugging Face episode appear so dangerous to outsiders. Other AI executives and safety researchers, however, cautioned that they have limited confidence that AI companies will be able to prevent all problematic model behavior... It's not about how damaging each individual instance was, Connor Leahy, AI researcher and executive director at ControlAI told Axios. The "crazy thing," he said, is that these instances involve "autonomous systems doing things they were told not to do," potentially including crimes.

Read more of this story at Slashdot.

Could this push solar cell efficiency beyond the theoretical 33% limit? Interesting Engineering reports: Researchers at the University of Groningen in the Netherlands found that tin-based perovskite solar cells can slow heat loss from high-energy "hot electrons..." When sunlight strikes a panel, photons jump-start electrons into action. The most energetic photons create super-charged hot electrons... [but] in fractions of a trillionth of a second, these high-energy particles rapidly cool, dumping their bonus energy as waste heat before ever leaving the solar cell... In collaboration with Maria Antonietta Loi, professor of Photophysics and Optoelectronics, the team created an experimental setup. Using a specialized solar cell material called tin-based perovskite, Loi's lab performed a feat many thought impossible: she slowed the heat loss down by a factor of 1,000. Suddenly, the extra energy lingered for nanoseconds instead of vanishing in picoseconds... To solve the puzzle, Koster and PhD student Tim Faber built digital simulations to peel back the quantum layers. And discovered a surprising double-action mechanism at work... The simulations matched the exact nanosecond delay observed in the lab... These specialized materials could be used to build a new generation of super-efficient solar cells. Tin-based metal halide perovskites are non-toxic, eco-friendly crystalline materials for high-performance solar energy conversion... The material possesses an unusually low electron mass. As a result, electric charges move quickly and retain extra thermal energy for extended periods. This combination of broad light absorption, efficient charge movement, and prolonged energy retention makes these materials prime candidates for next-generation solar panels. "There are many other questions that still need answers," the team said in their announcement, "but in theory, this discovery could allow the creation of more efficient solar cells, beyond the theoretical limit of 33 percent." Thanks to long-time Slashdot reader fahrbot-bot for sharing the article.

Read more of this story at Slashdot.

The United States and China have agreed to "launch a dialogue" on AI, reports Reuters. On artificial intelligence, the two sides agreed to hold a dialogue on the technology's risks and benefits, with the next round of discussions set for November, and to set up a communication channel for AI-related incidents, the Chinese Foreign Ministry and the White House said. The White House said that the leaders had agreed to use the term "super intelligence" in place of "artificial intelligence." In a separate statement, the Chinese ministry said that Beijing valued Washington's use of the new term. As AI technology continues to advance, the two sides should step up exchanges and work toward consensus in line with new developments, it said. But CNN argues that "Despite growing calls to prevent AI development from spiraling out of control, the Trump-Xi summit has produced little substance, as many experts expected." The right thing to do on AI, [China's leader] Xi said during talks with Trump, is to "draw on each other's strengths, not guard against each other" — a reference to Beijing's concern about US containment, from existing tech export controls to potential AI restrictions. "The two sides can continue their dialogue on AI, exchange views on its risks and benefits, and jointly prevent the misuse and abuse of AI," he added. But the summit has yielded little progress on AI beyond a formal dialogue and a bilateral communication channel, proposals discussed before the two leaders' summit — underscoring the entrenched mutual mistrust amid contrasting visions on AI... Because of low levels of trust, cooperation between the two superpowers remains limited, said George Chen, chair of digital practice at The Asia Group consultancy. "Beijing continues to believe Washington seeks to contain China's rise in AI and other emerging technologies, a perception that will shape the pace and scope of future engagement for the two countries on AI," he said. CNN also points out that while China trails the US in frontier AI models, "it's rapidly narrowing the technology gap while championing a more open ecosystem centered on accessibility and lower cost." In July, Chinese leader Xi Jinping launched the World Artificial Intelligence Cooperation Organization — a rival grouping to the Pax Silica alliance that Trump formed last year to reduce reliance on China for AI supply chains. While over two dozen countries and the European Union signed up to Trump's Pax Silica, Xi has recruited 29 countries, including Russia, Indonesia and Pakistan, to his alternative vision of open models, which allow users to freely download, customize and run without paying hefty fees to American firms like Anthropic and OpenAI. For developers in the Global South, an inexpensive Chinese model from DeepSeek or Moonshot may be more useful than a slightly more capable system requiring an expensive subscription and access to a foreign cloud provider, said Eric Olander, editor in chief of The China-Global South Project, a research agency.... China's embrace of open systems has not always been a top-down strategy by Beijing. Restrictions on access to the most advanced chips because of US export controls, coupled with smaller capital markets, have pushed Chinese developers toward open models as a way to compete with leading US proprietary systems. That shift has proved effective. In a year, Chinese models' global usage skyrocketed from less than 15% to over 54% last week, led by DeepSeek, according to AI leaderboard data by OpenRouter, a marketplace for models. Even American firms, from Airbnb and DoorDash to Shopify, have embraced Chinese models, tapping into the advantages of open systems, including lower costs and greater flexibility for customization. CNN adds this insight from Alex Colville, an analyst focusing on tech and security at the government-backed Australian Strategic Policy Institute. "The more capable Chinese models become, the less likely it is Beijing may leave them unrestricted."

Read more of this story at Slashdot.

Last weekend KDE's annual Akademy conference included a presentation proposing an AI-native KDE," writes The Register. This led KDE developer Nate Graham to open a discussion about proposed restrictions on LLM-assisted contributions which "rapidly became heated. Moderators issued warnings, restricted further comments, and eventually removed the thread." But as Graham writes on his blog, "A bunch of people mostly outside of KDE who disapprove of LLM usage derailed KDE's attempt to add restrictions to LLM usage." Two people unknown to any KDE contributors appeared and began fighting with one another about the broader topic of the morality of AI, not the proposed guidelines... Someone else outside of KDE set up kdeforpeople.com in an attempt to... pressure KDE into banning LLMs. A bunch of people signed onto it, almost none of whom are known KDE contributors. The topic was picked up on social media and the press with... varying levels of accuracy. The draft proposal was removed and the whole topic hidden... Yep, that's where we're at in the state of online discourse around AI... The "lovable, sovereign, AI-native KDE" idea was presented by two people important to KDE in decades past, but who had not made any contributions recently besides this Akademy talk. Their idea does not reflect the overall direction of KDE or Plasma, and I don't think it ever will. If "a lovable, sovereign, AI-native KDE" freaks you out, I believe it is completely reasonable and safe to ignore... I completely understand why a lot of people have problems with LLMs. I have these concerns as well. He concluded by asking people not to derail any future process to set usage guidelines, fighting over "the broader topic of AI in general." "The discussion is gone, but the argument continues," adds The Register: GNOME developer Jordan Petridis has also published The GNOME LLM Policy That I Want, proposing that LLMs be barred from creating or modifying anything submitted to GNOME or hosted on its infrastructure. "You might be asked to prove your code meets this requirement," Petridis writes, arguing for proposals that target the norms around developer behavior. His rationale? "The GNOME Project prioritizes the social and human aspects of collective software creation,"

Read more of this story at Slashdot.

Microsoft's senior product manager for Excel acknowledges that "Throughout Excel's 40-year history, you've only been able to put one value per cell." But that's now changing with arrays in cells (as well as nested arrays) and lists. "You can create a list by selecting Insert > List or pressing Ctrl+J, then typing or pasting items separated by commas or semicolons, depending on your regional settings. Selecting the icon in the cell shows the individual values..." "With lists, you can filter by one or more individual items instead of whole text entries. Referencing a list returns all its values for calculations. For example, =B2 spills those values into separate cells..." "For the first time in Excel, arrays can exist natively in cells as values or as formula results. They can be any size or shape and can even contain other arrays. You can now keep the result of any spilling formula in a single cell by "wrapping" the formula body with braces { }." "Since the introduction of dynamic arrays, array results have spilled across cells — for example ={1;2;3}. Wrapping the original array with braces creates a 1x1 array around it, so instead of spilling to multiple cells, the array stays in a single cell. Braces have long been used to describe arrays in Excel and this extends that behavior by allowing multiple layers of braces. This gives you more flexibility when building spreadsheets. Instead of leaving room for a formula to spill, you can keep the result in one cell." "Arrays can now also 'nest' inside other arrays... Previously, a formula that produced an array of arrays would return a truncated result or #CALC! error. Now, supported formulas return the complete nested result... FLATTEN(array, [pad_value], [levels]) simplifies nested arrays by removing one or more levels of nesting..." Three HAS functions check whether values are in an array: — HAS(array, value) returns TRUE if value appears anywhere in array, and FALSE otherwise. — HASANY(array, values) returns TRUE if any of the values appear anywhere in array, and FALSE otherwise. — HASALL(array, values) returns TRUE if all of the values appear anywhere in array, and FALSE otherwise.

Read more of this story at Slashdot.

"Finding vulnerabilities faster also puts pressure on Linux distributions to fix and deliver patches faster," writes Slashdot reader BrianFagioli AI has transformed bug discovery from "a manual, time-intensive process into a highly automated engine," notes Canonical's blog, leading to a "recent explosion in the volume of CVEs". Additionally, the upstream kernel community became its own CVE Numbering Authority (CNA) and assigned CVE (Common Vulnerabilities and Exposures) identifiers to thousands of bugs, arguing that at the kernel level, almost any type of bug that can affect a running system, could potentially be classified as a vulnerability. As a result, the volume of CVEs has skyrocketed exponentially, creating a massive backlog of alerts and forcing defenders to drastically increase the speed of their fixes to close the window of risk. To address the growing volume of CVEs and the demand for faster security fixes, we are transitioning to a unified, 2-week release cycle... While a patch is being prepared, Canonical aims to provide safe workarounds where applicable, so users aren't left exposed in the meantime. Where no safe workaround exists, Canonical will say so clearly and point users toward general hardening steps instead. The goal is to get environments into a defensible, safer state within 24 to 48 hours of public disclosure — well before a patch ships. This doesn't replace the patch; it buys the time needed to fix the vulnerability properly, without sacrificing security. "Linux did not suddenly become wildly insecure overnight," notes the blog Nerds.xyz. "We are getting much better at finding and cataloging problems that may have previously gone unnoticed." There is something almost ironic about all of this. AI is routinely pitched as a tool that will make software development faster, but it is also making vulnerability discovery faster. That means maintainers now have to accelerate the other side of the equation too. For Ubuntu users, that should ultimately be good news. More bugs being discovered is preferable to vulnerabilities sitting unnoticed in the Linux kernel.

Read more of this story at Slashdot.

Most modern operating systems (including iOS, Android, macOS, and ChromeOS) have been using image-based architectures for a while, and in recent years we’ve been making progress towards this on the desktop side as well. It’s a necessity if we want to provide the security, usability and reliability that people expect from their devices nowadays.

However, broadly speaking the adoption of image-based designs has been limited in the free desktop world so far because there are still a few major gaps. While Flatpak and Flathub have more or less solved the app distribution on these systems, the developer-facing story still looks much more incomplete.

Traditionally, people have been developing against the host OS they are running. Assuming you’re working on something like NetworkManager and need a new dependency, you’d just “apt install” it globally on your system, and then configure/compile against that. Similarly, if you need a command-line utility, compiler toolchain, or other build dependency, you’d also install them from the distribution repository.

In an image-based world this approach doesn’t work, and people have come up with various ways to address this.

RPM-Ostree and Package Overlays

Fedora Silverblue can be extended similar to package-based distros with rpm-ostree overlays, but the issue with this approach is that overlayed packages can completely break the system in unexpected ways or stop it from further updating. This is why the next iteration of Silverblue is based on “bootc”, and will be explicitly avoiding this paradigm. Same issue are present with other package overlay approaches as well.

Monolithic “Development” Overlay

The approach used by Android, iOS, Windows, et al is to have a single monolithic overlay with “system development tools”. Developers can install this overlay, and it provides all the utilities people developing the system itself need.

GNOME OS does something similar: There is a “developer” system extension that overlays the toolchain used for building the OS on top of the user-facing OS image. However, this is a finite list of utilities needed specifically to build the OS. As such, it can not cover the long tail of development and debugging tools developers in different areas need (e.g. kernel development).

Toolbox

Another approach is trying to replicate the same traditional package-based experience inside a container. Toolbox and distrobox are examples of this.

Unfortunately, with this approach you are still relying on the same old package infrastructure, while also being inside a more restrictive container environment that none of the tools expect to be run in. As such, you often run into limitations when developing system components and need to bypass the container layers in order to debug the system itself.

Homebrew

Homebrew provides an independent tool chain to develop against, but in order for homebrew binaries to be usable directly in the terminal, they have to be prioritized over system binaries. This means that the system can break if there is a mismatch between what the system expects and what homebrew provides. For example, you install QEMU, but it overrides the GLib your system uses for everything else.

There are other architectural issues with homebrew, but in my opinion this alone disqualifies it for system development.

Flatpak

Lastly, we have Flatpak. Like Toolbox it uses “containers”, so the same issues and limitations are also present here, but it’s even more restrictive because the assumption is that apps will use portals to access system resources such as directories and devices. Flatpak was designed specifically with desktop apps in mind, and its architecture and integration points are not well suited for command line apps.

Somewhat tangentially, there are apps that can’t be made to fully work with Flatpak as it is today, particularly debugging utilities and IDEs. While it’s technically possible (GNOME Builder and the Ptyxis terminal are proof), older applications were not designed with sandboxed resources in mind, or have not adapted to this model yet.

What Could We Do Instead?

While we would love for everything to be sandboxed and confined, that is sadly not yet possible. All the existing approaches that attempted to containerize tooling, run into the same conflicts between the desired functionality and the restrictions inherited by this approach. This is a topic we will discuss in more depth later on.

Additionally I believe there are two different use cases here. The build tooling/toolchain used by projects, and the developer utilities.

Project Build Setups

One aspect of this is the build setup used by individual project, which would ideally be something more deterministic, and containerized like Buildstream, flatpak-builder, bazel or even nix, instead of the old status quo “apt install -yqq gcc meson libone-devel libtwo-devel”. This is also a topic for another day though.

Developer Utilities

The other aspect, and what I want to focus on today, is that a lot of developer utilities that people rely on can’t realistically be run in a confined environment (such as a container) without a near complete rewrite.

We need a way to make things like strace, ripgrep, and qemu available. Shipping them in the host system is one option, but there is a real long tail issue here. You can’t (and don’t want to) provide every single utility any developer might need. Thus we need them to be shipped independently, and as such, not attached to the host OS.

Toolpak

If we were to take a fresh look at this issue and design something from scratch, what would we want it to look like? Over the past months we’ve had a number of discussions on these topics, and it feels like we’re finally converging on a solution would address most people’s concerns and needs.

These are the important properties we would want:

• Tools should be independent from the host OS, and they should not break the host OS if something goes wrong. They need to be able to access every resource in the system, much like today.
• A large catalog of existing tooling, like we find today in distribution repositories today.
• Tools work out of the box, and will be fully functional, as it’s not feasible to modify all of them. Things like shelling out to other tools should work like it does now.

Here is what I imagine an implementation, which we will call Toolpak, would look like:

• Discoverable Disk Images (UAPI.3) as the image format. This will provide us state of the art security practices, like Verity. It will also give us a good base for allowing Reproducible builds, given that the build tooling permits.
• A mount namespace for the binaries. The /usr and /app split from Flatpak is a great idea and we should also steal it much like portable services now can use Base/Runtime images! /usr should be provided by the “Runtime Image” and shared among tools. And /app will be the main contents of the Tool image.
• Tools have unrestricted access to everything else. This should also satisfy the “no need to port” requirement (Some edge cases where the mount namespace will conflict, but they are minor).
• We should prepend the tools, to the PATH of the user (ie. our binaries will override the system ones), but it should avoid breaking the system as you can only override the system binaries. Said binary will then setup the mount namespace and execute the real binary from inside the image. This avoids messing with the linker and shared libraries. Unless you overriding the system GNU Tar with the BSD Tar (or other incompatible cases of the same binary), things should work fine. More research is needed to explore what other safeguards will be required.
• Tools can not depend on other tools. One of the issues with traditional distributions is dependency resolution and package management (this is subcategory of a heavily discussed topic, I also talked about it in my LAS talk from 2025. We should avoid making individual packages or having dependencies between tools, to avoid all the unnecessary complexity that comes with it.
• Tools will bundle all their dependencies. This will ensure that they will always execute against the environment they were tested against. It additionally allows tools to bring their own versions of libraries that might be present in the system, without conflicts. We mentioned the /usr and /app split above.
• Great user experience to discover and install tools. There should be a flagship “app store” and ideally the tools should be packaged and distributed by the developers themselves, similar to Flathub. No more “download this static binary and chmod +x it”.
• Tools have complete and arbitrary access to the system, so it’s crucial that it not be simple to install random images. They will be have to be signed with a trusted key, and verity checked at runtime, and be thoroughly reviewed before appearing on the flagship “app store”, and all the other practices we should expect from distributing software securely.
• Apps that can be packaged using Flatpak should be rejected. Unless they are less functional, like IDEs on Flathub.

In order to be adopted, it will also have to come with tooling that will make it easy to build said Toolpaks. Here are some specific properties the build tooling should have:

• It should be easy to orchestrate builds of your tool and its dependencies.
• Great caching for all build artifacts in a Content Addressable Storage.
• Reproducible by default, with tooling to easily verify the output.
• Can be used for both local development and composing the final image.
• Handles all the licensing/SBOM/etc requirements.
• A Buildstream plugin or wrapper around it should satisfy all these needs.

Next Steps

While this topic has been discussed for years, there’s now concrete work towards a prototype as part of a Prototypefund project. We plan to share more on this in the coming weeks and are interested in feedback from the wider community. In the mean time, if you have any other feedback, find us in #gnome-os:gnome.org on Matrix, or leave a comment.

"Copilot+ PCs" were Microsoft's official branding for Windows 11 "AI PCs" that met their system requirements. But the 2024 launch "didn't go smoothly," writes Windows Central, after security researchers discovered its proposed "Recall" feature was woefully insecure: This pretty much tarnished the Copilot+ PC brand, and over the last two years more and more OEMs have dropped the moniker from marketing materials and product names. In fact, even Microsoft has seemingly stopped mentioning it. I've noticed that none of the Surface PCs launched in 2026 include the Copilot+ PC moniker in their product names, unlike the Surface PCs that launched in 2025 and before. Now, you have to go digging to find any mention of Copilot+ compatibility in specification sheets... It's also worth mentioning that NVIDIA hasn't gone anywhere near the Copilot+ PC brand for its upcoming RTX Spark platform, even though all RTX Spark PCs meet the Copilot+ PC specification bar. I suspect that's a deliberate decision. It seems pretty obvious that the Copilot+ PC brand hasn't resonated with the market, and OEMs and Microsoft itself are now quietly pulling back on that branding. The specification baseline for Copilot+ PC experiences still exists, it just no longer has a pretty marketing name tied to it.

Read more of this story at Slashdot.