So I decided to write something from scratch after all. And instead of writing something for myself like everyone else does, I started writing it as a tool that could be used by anyone or used as a base for custom migration scripts. I gave it a name (Linux Desktop Migration Tool) and created a proper project.

It’s a shell script because it’s quick to prototype and easy to extend. I wish it was a desktop app, or even something integrated into GNOME as for example part of GNOME Initial Setup, but something with a nice UI written in a modern toolkit is beyond my skills and time I can spend on it. The shell script may not have the best user experience, but it gets the job done.

I’m primarily targeting Fedora Silverblue because that’s what I use and install for people around me. But at the moment it should work on any modern desktop distribution. And I want to keep it that way if possible, it’s just that I’m not interested in use cases that aren’t relevant on Silverblue. At least until I complete features that are on my todo list.

What can it do? At the moment it can copy over the contents of XDG directories (Documents, Pictures, Downloads…) or any arbitrary home directories. It can reinstall flatpak applications on the new machine, copy over their data, migrate existing Toolbx containers. In the future I’d like to dig into migrating desktop settings, certificates, keyring etc.

I’m trying to avoid the “copy files over and hope for the best” approach. Otherwise I would just have a one line script to copy over the entire home partition. Wherever possible, I use export-import functions. And reinstalling flatpaks is also a cleaner way than just copying directories with binaries as I recently learned when I needed to migrate data from an x86 laptop to an aarch64 Macbook.

If you need to migrate data from one desktop machine to another, check out the tool. Perhaps you will find it useful. Suggestions for improvements or even merge requests are welcome.

Some time ago I also started building Evolution for the beta channel on Flathub. When there are already development releases of the upcoming version (it will be 3.49.x this cycle), I build those for the beta channel. If they’re not available yet, I push stable releases there right after the upstream release is done, roughly one week before they go to the stable channel.

So the beta channel always provides the latest and greatest. Be it the latest development version, or freshly released stable version, depending on the phase of the development cycle. It really helps us find problems before they hit average users. For example, the latest release – 3.48.2 – introduced an ugly regression that made basically impossible to view some HTML messages. It was identified and patched while the version was still in the beta channel, so it never reached users on stable.

That’s why I’d like to raise awareness of the beta channel with Evolution. If you’re a bit more advanced user who would like to help with testing and you use Evolution from Flathub, consider switching to the beta channel. You wouldn’t switch to something broken. Milan doesn’t let low quality releases out. It’s for rather rare bugs that would be great to identify and fix before they hit everyone, or for early feedback when UX changes are being done.

All you need to do is to add the beta channel:

flatpak remote-add --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo

And install Evolution from it:

flatpak install flathub-beta org.gnome.Evolution

Of course, there are other ways to get the latest release of Evolution. You can build it from source yourself, or build a flatpak directly from the upstream git repo, but the beta channel on Flathub is the most convenient.

EDIT: I forgot the most important thing: where to report problems. All general issues including problems specific to Flatpak as a distribution format belong to the Evolution issue tracker on GNOME Gitlab. Only problems that are specific to Evolution on Flathub should belong to our Flathub issue tracker on Github. I understand it may be difficult for the user to distinguish between a Flatpak problem in general and a problem specific to Flathub. So if you report the former in our issue tracker on Github, it’s fine, too.

The following chart shows the distribution of responders by year of school. The survey was primarily targeting students in the first year which is why they make up over 50% of the responses.

The following chart shows how many students had experience with a Linux distribution prior their studies at the university. 46% did which shows a pretty good exposure to Linux at high schools.

And now what desktop OS students use primarily. Windows are dominating, but Linux is used as a primary OS by roughly one third of students. macOS is only at 10%. Although we gave responders an option to specify other OSes, no one submitted, for example, BSD.

The following chart shows in what form students use Linux primarily (as either a primary or secondary OS). 44% of students have it installed on their desktop/laptop. 31% use Windows Subsystem for Linux. School programming assignments have to run on Linux, so if they want to stick with Windows, WSL is the easiest way for them. Virtualization is at 9% and remote server at 13% (I suspect it’s mostly uni servers where students can test their assignments before submission).

And here come shares of Linux distributions. Responders could pick multiple options, so the total is over 100%. Basically the only relevant distributions among FIT BUT students are Ubuntu, Fedora, Arch Linux and Debian.

Ubuntu has a clear lead. It’s the default option for WSL where it is on vast majority of installations, so I wondered what the share would be without WSL.

Without WSL the gap between Ubuntu and the rest of the pack is smaller. And since I’m from the Red Hat desktop team I also wondered what are the shares among students who indicated they use Linux primarily on desktop/laptop.

When it comes to desktop computers and laptops the shares of Fedora and Ubuntu are almost the same. That shows two things: 1. Fedora is strong on the desktop among local students, 2. being the default option in WSL gives Ubuntu an advantage in mindshare. Fedora is not even officially available for WSL, but even if it was, it wouldn’t probably change much because other distros are available in the Microsoft Store and only one student of out 50+ who primarily use WSL responded that they use something else than Ubuntu. WSL is probably used by users who want some Linux in their Windows and don’t care much which one it is, so they stay with the default.

We also asked students what prevents them from using Linux primarily. By far the most frequent answer (80%) was “Software I use is not available for Linux”, followed by “I don’t like the UX and logic of the OS” (28%) and “Compatibility with my hardware” (11%). Some students also responded that they simply hadn’t had enough time to get familiar with Linux and are staying with what they know. Other reasons were marginal.

Previously, Twitter had a verification process for high-profile accounts (politicians, journalists, etc.). I honestly don’t know what that verification entailed, but after the Twitter takeover, Musk came up with the idea that anyone who pays $8 is eligible for verification. The ironic thing was that the new process didn’t actually include any identity verification at all. You paid $8, got a blue badge, and could impersonate anyone. This unsurprisingly didn’t work, so after a series of bummers over a short period of time, they discontinued this method of verification. They restarted it just recently and it seems to be as flawed as before.

Not that I have any major need to have my social media accounts verified, but I was wondering if there was any way to verify an account on Mastodon, because there isn’t some central entity that can verify your accounts. I found out that Mastodon goes about it in a pretty elegant way. It outsources the authentication to internet domain administrators.

The Internet domain is, in my opinion, the best “holder” of online identity. Internet domain administrators generally operate in the public interest, have long term continuity, and are globally recognized authorities. Domains are affordable and the rules for owning them are relatively loose. The chances of losing your domain, and therefore your online identity, are relatively small. Email is the most common identifier today and if you run it on your own domain, you are using the domain as an identity across online services. If you don’t have your own domain, I recommend getting one. It’s a much better idea in the long run than relying on an identity derived from accounts with service providers (Google, Facebook, Apple, Microsoft…) because with you’re just building one big vendor lock-in for yourself.

Mastodon simply uses the XHTML Friends Network format, which has been around since 2003. It allows a link to declare a relationship. So on a domain you own, you can place a link to your Mastodon profile in the format:

<a href="proxy.php?url=https://floss.social/@sesivany" rel="me">Me on Mastodon</a>

In your Mastodon profile, you link back to the page that contains the link, and when Mastodon detects the backlink, it marks the connection as verified. This will link the account to your domain. If you run, say, a popular blog on your domain and you’re generally known as the owner, that may be enough, but proving that you have control over the content of a site on a domain does not mean that you have verified your identity.

But if you own a Czech domain, you can go further. CZ.NIC allows you to link your entry in the domain registry to your account with MojeID which is also operated by CZ.NIC. This identity service is also certified to log into online government services in the EU and in order to do that requires in-person identity verification. This means that you have to go to a CzechPoint with your ID card, where someone will verify that you are really who you claim to be in MojeID (you can also use an eID card or a data box to verify your MojeID account online, but these also required in-person verification when you created them).

I have my MojeID account verified this way. So the chain of trust goes from my Mastodon account to verification with my ID at a CzechPoint. Which online service has such strong authentication? Yet from Mastodon’s side, this is a simple thing to implement and costs me about $8 in domain fees per year, not per month. And it has a much broader application. It’s a pity that XFN is not used by more services.

The conference grew to occupy pretty much the whole venue (Faculty of Informatics of Brno Technical University) and offer 6+ tracks. This year it shrank back to its pre-2012 times.

For us from the Fedora community it was great to be back among people, talking directly to our users. We demoed the freshly released Fedora 37 Beta and we also showcased Fedora on a Pinephone (with the Posh environment). The theme of this year’s OpenAlt turned out to be Linux on mobile phones. There were several talks on this topic, people showed up with different phones (Pinephone, Librem 5…) and different OSes on them (Fedora, Manjaro, Debian, SailfishOS…).

During the last 3 years we have also accumulated a lot of Fedora swag in the storage, so we had a lot to give away and people appreciated it because apparently getting a sticker of your favorite distribution is something people were missing too.

I’d also like to thank Vojtech Trefny, Jan Beran, Ondrej Michal, and Lukas Kotek for helping me staff the booth.

That’s why Milan Crha, the new GNOME Software maintainer, created a Copr repository that includes the latest development version of GNOME Software. If you want to help us with testing, install GNOME Software from the Copr repository and report issues. They won’t be overlooked. Milan is a very responsive maintainer.

I’m the go-to IT guy in the family, so my relatives rely on me when it comes to computers and software on them. In the past I also helped them with computers with Windows and macOS, but at some point I just gave up. I don’t know those systems well enough to effectively administer them and I don’t even have much interest in them. So I asked them to decide: you either use Linux which I know and can effectively help you with or ask someone else for help.

Long story short: I (mostly remotely) support quite a few Fedora (Linux of my choice) users in my family now. It’s a fairly easy task. Usually after I set up the machine I don’t hear from the user very often. Just once 6 months and a year typically when I visit them I upgrade the machine to the new release and check whether everything works. But Fedora upgrades became so easy and reliable that recently I usually just found out that they had already done it by themselves.

But there was still one recurring problem: even though they performed upgrades because it was probably a big enough thing to catch their attention they didn’t act on normal updates and I often found them with outdated applications such as Firefox.

I could set up automated DNF updates running in the background, but it’s really not the safest option. And that’s where Fedora Silverblue comes to rescue. Applications run as flatpaks which can be and in fact are by default updated automatically in the background. And it’s pretty safe because the updates are atomic and the app is not affected until you restart it.

The same goes for system updates. rpm-ostree can prepare the update in the background and the user switches to it once the computer is restarted.

So I thought: the user base of Silverblue typically consists of developers and power users used to the container-based workflow, but hey, it could actually be a pretty good system for the users I support in my family.

I got an opportunity to try it out some time ago. I visited my mom and decided to upgrade her laptop to Fedora 32. Everything would have gone well if my son hadn’t pulled the power cord out during the process. The laptop is old and has a dead battery, so it resulted in an immediate shutdown. And that’s never good during a system upgrade. Instead of manually fixing broken packages which is a lengthy process I decided to install Silverblue.

The fruits of it came a week later. My mom called me that she was experiencing some graphical glitches and hangs with Fedora 32. Probably some regression in drivers/mesa. It’s a T400s from 2009 and neither Intel nor anyone else does any thorough regression testing on such old models I suppose. On the standard Fedora Workstation my mom would have been screwed because there is no easy way back.

But it’s a different story on Silverblue. I just sent her one command over Telegram:

rpm-ostree rebase fedora/31/x86_64/silverblue

She copy-pasted it to Terminal, pressed Enter and 5 minutes later she was booting into Fedora 31.

And the best thing about it is not that it’s so easy to upgrade and rollback in Silverblue, but that the apps are not affected by that. I know that if I let my mom rollback to Fedora 31 she will find her applications there just like she left them in Fedora 32. The same versions, same settings…

P.S. my mom’s laptop is from 2009, but Fedora Workstation/Silverblue flies on it. Who would have thought that GNOME Shell animations could be smooth on an 11-year-old laptop. Kudos to everyone who helped to land all the performance optimizations in the last several releases!

Originally I was planning to use Jitsi.org with streaming to Youtube. Speakers would join the call on Jitsi.org and attendees would watch it on Youtube and comment under the Youtube stream or in our Telegram chat. But the stream was one minute delayed behind the call which didn’t promise an interactive event.

In the end we were offered a solution from Czech Technical University (BigBlueButton running on powerful physical hardware and with a really good connectivity) and went for it which turned out to be a great decision. I have never had a better video call experience. It was the first time I could fully utilize my FullHD webcam, there were virtually no delays and BBB could hold 8 webcam streams in parallel and 40 participants in total without a hiccup. Afterwards people told me that when I was demoing GNOME 3.36 the GNOME Shell effects looked almost as smooth as performed on the local machine.

We put together a program of 4 talks on Fedora topics and had an open discussion afterwards. Most people used the integrated chat to comment and ask questions, a few besides the speakers used their voice which is something I expected because most people feel too intimidated to speak in front of strangers who they can’t even see.

The event lasted for 3 hours and would have probably continued if I hadn’t had to stop it because I had to put kids to bed. The kids were the biggest challenge for me. Our offices were closed, so were public universities, so I couldn’t find any quiet private space to join the call from. So I was moderating the event and delivering my talk with my kids constantly crying in the background or demanding my attention. But I somehow managed and it was not a complete disaster.

What was originally an improvised solution turned out to be a pretty good experience. Participants said they would like to do it again or perhaps combine it with the physical release parties. Although the virtual event can’t deliver the same experience as in-person one, it brings some sense of equal opportunity. No matter if you’re stuck home with small kids, or with disability, or if you’re a young student living in countryside far away from a big city, you can join. In-person events are pretty selective in this.

We also have a recording from the event in case you’re interested (it’s in Czech).

If you can’t organize the traditional Fedora release party for your local community, don’t hesitate and organize a virtual one!

Three years ago we started a testing flatpak repo with Firefox Developer Edition and soon after that we added Firefox Nightly. For a long time it was the only source of Firefox for Flatpak out there. The user base grew into thousands, a level our hosting could barely deal with. Lately we haven’t had much time for its maintenance and at least the nightly builds were often broken.

That’s why from the very beginning we worked with Mozilla to make official Firefox builds available as flatpaks. The effort was later on picked up by Endless.

Now it brings first fruits, Mozilla is already shipping Firefox Beta in the beta channel on Flathub. You just need to enable it by installing this file: https://flathub.org/beta-repo/appstream/org.mozilla.firefox.flatpakref

I think it may already be useful for Silverblue users who have relied on our testing repo if they didn’t want to use package overlay.

There are still a few things to polish before making the stable Firefox available in the stable channel. One of them is localization files which has always been a difficult thing with Firefox. Mozilla has traditionally provided official localized builds for each language. This is not how localizations are typically handled in Flatpak or even in Linux distro packages.

For Fedora Firefox RPM we had to write a script that on startup automatically loads a particular localization file in the form of an addon. I suppose the official Firefox flatpak will work in a similar way.

Last year we also started providing Firefox flatpak built from Fedora packages. That has been the only stable Firefox for Flatpak around. And even after Mozilla releases their official Firefox for Flatpak, we will stay committed to it because there is demand among Fedora users for Firefox that is verified and built by the Fedora Project and it’s also a requirement for software included in Fedora anyway. So if we want to have Firefox as a default, pre-installed browser e.g. in Silverblue we’ll have to build the flatpak ourselves. It also gives us flexibility to ship crucial fixes and features important to our users faster than upstream (e.g. Firefox in Fedora already runs natively on Wayland by default, not on XWayland like upstream Firefox).

In the future, users will have a choice. They can either stick with the default Firefox provided by us, or switch to the one provided directly by Mozilla in a more convenient and secure way than the current tarballs with binaries are. We will also keep maintaining our testing repo for those who are interested in Nightly and Developer Edition. And we’ll see if there is sufficient interest in it to continue.