My Librem 5 has arrived

Well, it arrived two weeks ago, but I had a pretty terrible cold so I didn’t really take a look… Here are my initial findings:

  • It’s a brick. It thick, fat, heavy and feel awkward to hold. But it’s got three manual kill switches.
  • On startup, it asks for a disk encryption password, which the manual didn’t say anything about. I guessed it would be 123456, based on some quick googling, and it was. You need to press OK yourself, it doesn’t figure out that the password has been entered.
  • Then you get a bit of text scrolling past when the thing is booting
  • Then there is no wizard to set up accounts or anything — I got asked for a password and again it was 123456
  • Then I noticed that when it’s charging it gets REALLY hot.
  • And then I could start exploring the software a bit…

I know how hard developing for mobile Linux is. I worked with Nokia on the Maemo/MeeGo Documents application based on KOffice/Calligra. I’ve worked on Plasma Mobile for Blue Systems. I know that after the N900, with its mostly GTK stack, everyone until Purism has tried to build their mobile Linux UI on Qt and later QML. (Well, FirefoxOS was different, but Blackberry, Nokia, Ubuntu, Palm… That was all Qt.) And they all failed, for various reasons.

This thing runs GTK-based software again. And it’s really bad. It’s slow; even scrolling in the Settings application is not smooth. The browser doesn’t scroll smoothly. And its’s buggy. Starting the Usage applet randomly pops up a dialog asking whether this or that applet should be force-quit. There are two back buttons in the system update applet next to each other, but only one works.

  • And finally, battery life is abysmal.

I haven’t seen a Fairphone yet, but literally nothing in the Librem 5 is an improvement over the Nokia N9. Well, maybe the killswitches. It’s as if there have been no developments whatsoever for the past ten years. And in the meantime, since I first backed the 2017 crowdfunding campaign I have sort of lost interest in mobile devices…

Should we stop flying to our free software conferences?

Whelp, the latest IPCC report doesn’t beat about the bush. It whacks right into it. And, yes, while governments and companies need to take responsibility and finally start to DO something, we all still have a personal responsibility.

As KDE we’re working on the energy consumption of our applications (which already has shown something we, the Krita developers, can do right away), I changed to buying the electricity I use for building Krita (and everything else) from the local windmill coop… I don’t drive, never have, and that pile of wood next to the stove dates back to 2018, and we’re not going to burn it any more. (Why would we — it’s too warm in winter, when we came to live here in 2007, we needed that stove because it was too cold otherwise!)

All of that is peanuts.

But there is one place where we, as a free software community, have to take responsibility (that word again) and stop doing something we absolutely love to do, and for which we’ve been pining.

In-person conferences with a world-wide attendance.

I’m hating having to say this, and I’m hating that I have to say that it is inevitable, and I hate that many of my Krita collaborators won’t actually be meeting me, the improved second release, but… We, as a free software community need to have this discussion, and until now, all I’ve seen has been silence.

Flying always scared me irrationally, but that’s not the reason I think we should stop it. Cheap air travel is only possible because it’s subsidized, untaxed and airlines are being kept alive only as a matter of national pride. And that’s the only reason we can actually afford to fly people from all around the world to conferences, sprints, Akademies and the like.

Our conference model is built upon something we wouldn’t be able to afford if air travel was priced in accordance with its real cost.

And, we’re probably not going to miss the presentations, much? Most presentations at free software conferences are, honestly, a bit meh. A conference with presentations is something we’ve copied from Academia. What we’re really missing is the meetings, the chats, the sitting together at a table and making notes, the occasional pair programming, the making new acquaintances, the gossip.

And the remote conference format pretty much only provides the presentations, with a bit of chat, which we already have next to it. And I really cannot handle remote conferences myself. For meetings and BoF sessions, I get a headache in a minute or ten. For presentations, especially when pre-recorded, I get bored in under a minute. That sucks.

Maybe we can find a better on-line get-together activity. Max Miller from Tasting History has a virtual cocktail party with his patreons. Maybe the next virtual conference could start with planning and facilitating the socializing, and only add in a program as an afterthought?

But whatever, we still should not go back to burning enormous amounts of kerosene for our get-togethers. Would it be too much to say that that would be criminal?

Krita, Qt and OpenGL — again.

I have previously written about this subject, and back then couldn’t reach any conclusion. The options open to us were all confusing: we could try to write Krita’s canvas directly in Metal, OpenGL and Direct3D and show those in native windows in our QtWidgets based application.

We could try to rewrite our canvas in QRhi, the semi-private GPU API  abstraction Qt 5.15 and up provides — though it might not have enough functionality for us, since it us just written for what Qt needs for QtQuick.

We could try to rewrite all of Krita in QtQuick and integrate our canvas into QtQuick’s render loop: but yes, that means a complete rewrite, because you cannot put a QWidget in a QtQuickWindow, and putting QtQuick into a QWidget window means you’re rendering using OpenGL, which breaks on Windows, now that Qt6 doesn’t come with an Angle option.

So we had a big blue button meeting on Friday, where we discussed this issue and some other issues.

Here’s what we concluded:

We will patch Qt6 to render OpenGL using Angle on Windows and macOS.

In the meantime, using Qt 5.12, we’ll move forward adding QtQuick based elements to Krita.

And we’ll try  to make a QtQuickWindow based version of Krita for Android. Sharaf Zaman has succeeded in prototyping that, so we know it can be done now; something we lost in the migration from Qt4 to Qt5.

We also want to strip out the CPU-based canvas in Krita and port our usage of QPainter on OpenGL surfaces to straight OpenGL.

And finally, something we should have done during the port to Qt5, we’ll move uploading the canvas textures into a thread, which should solve the performance problems on macOS.

All in all, it was a very focused and very productive meeting, though I guess the conclusion might be a bit startling. And we’re a bit daunted, but only a bit: we already patch the heck out of Qt anyway.


A new macbook pro — first impressions

Two days ago, my macbook pro M1 arrived. I mainly got this device to test Krita on and make ARM builds of Krita, but it’s also the first macbook anyone in the Krita community that allows playing with sidecar and has a touch strip.

So, SideCar works, as expected. There is one problem, though, and that’s that the pressure curve of the Apple Pencil seems to be seriously weird, so I first thought I was painting with a sketch engine brush. But apart from that, it’s nice and smooth.

KDAB has published a library to integrate support for the touchbar: kdmactouchbar — so on that front we might see some support coming.

Krita itself, the x86 build, runs fine: the performance is much better than on my 2015 15″ macbook pro, and rosetta seems to even translate the AVX2 vectorization instructions we use a lot. Weirdly enough, X86 Firefox doesn’t seem to be able to load any website, and Safari is very annoying. Looks like the macOS build of Kate isn’t notarized yet, or maybe I need to use the binary factory build for that. XCode took about two hours to install and managed to crash the system settings applet in the process.

We haven’t succeeded in actually making an ARM build yet. We first need to build the libraries that Krita uses, and some of those seem to build as X86, and some as ARM, and we haven’t figured out how to fix that yet.

The laptop itself is, well, a laptop. It’s not bad, but it would never be my favorite. Yes, it’s very fast, that’s what everyone says, and it’s true: Qt builds in a mere 20 minutes.

The keyboard is nice, much better than the one on the 2015 macbook pro, so Apple was able to make some progress. But the edges of the palm rest — well, all of the edges are really sharp, which is quite painful when typing.

Really cute was the way the language choice on installation tells you to press Enter in all the language, including four dialects of English.

MacOS 11 is also really annoying, with an endless stream of notifications and please-use-your-finger-to-unlock for the most innocuous things. The visuals are appallingly ugly, too, with really ugly titlebars, a cramped system settings applet and weird little pauses now and then. And if the performance monitor can still be put in the menubar, I haven’t found the way to do that.

Anyway, that’s it. We’ll be making ARM builds of Krita one of these days. If you value your freedom, if you like the idea of actually owning the hardware and being able to do whatever you want with it, don’t buy one.