We’ve been working hard for the last months to improve GNOME Software both in Fedora Workstation and Silverblue, especially its reliability. One thing we identified as a problem is a long feedback loop. I took months before bug reporters and designers could easily test changes made based on their feedback.
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!
We’ve been organizing Fedora release parties for the Czech community since Fedora 15 (normally in Prague and Brno, once in Košice, Slovakia), but in those coronavirus times it seemed like we were out of luck. Not quite. We’ve decided to organize a virtual release party everyone can join from the comfort (and safety) of their homes.
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.
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.
As it’s our tradition since Fedora 15 we’ve organized Fedora 30 release parties in the Czech Republic. Normally the Brno one is earlier, but this time the Prague took place one week before the Brno one – on June 4.
The Prague party was again held in offices of Etnetera, a Fedora-friendly software company. I was worried about the attendance because at the same time the biggest demonstration since 1989 (100+k people) was taking place in Prague. A lot of our friends went there. A lot of old faces didn’t show up, but they were replaced by quite a few new faces (which I think it’s partly due to posting an invitation to the biggest Czech Linux group on Facebook), and in the end the attendance was the same or a bit higher than last time – around 30 ppl.
We’ve prepared 5 talks for visitors. I started with news in Fedora Workstation and also added a pack of news in Fedora Silverblue. We try to make the release parties as informal as possible, so the talks should not be lectures where one is talking and the rest is listening in silence. My talk was again mixed with a lot of discussion and instead of 30-40 min, it took 1h20m.
Then Petr Hráček introduced the project he’s working on Packit. As someone who maintains packages in Fedora I find the idea interesting because in package maintenance there is a lot of work that can be automated and if there is a tool that can help you with that, great! The only thing that limits my enthusiasm about Packit is that it relies on having YAML files in the upstream repo. And you know how some upstream projects are dismissive to hosting any downstream-specific files…
The next two talks were delivered by Fedora QA guys – František Zatloukal and Lukáš Růžička. František talked on how they test Fedora, what tools they use and how you can help them. Lukáš talked on how to report bugs the useful way.
The 5th talk that was supposed to be on GNOME Builder was cancelled because we were considerably over time, but its author – Ondřej Kolín – promised that he’d change it into an article on mojefedora.cz.
To continue with the bad luck, the release party in Brno a week later had a time conflict with another demonstration against our prime minister. And this time it had an impact on the attendance, around 40 people showed up and we normally get twice more. I hope he will go away, so that there are no longer any demonstrations against him that lower attendance of our release parties 🙂
The party took place in the offices of Red Hat and the program of talks was exactly the same as in Prague.
At both parties we also had cool swag for participants. Especially brand-new Fedora hadbook that arrived from a printing-shop just before the Prague party.
If you maintain a distribution package, or app bundle, or container image, it’s handy to know when components you use in it have new releases.
There is a really useful service Anitya that resides on release-monitoring.org. It watches almost 20 thousand projects for new releases and notify about them.
I maintain several packages in Fedora and the Fedora Project already makes it really convenient for me. It uses Anitya and opens a new bug against your package every time there is a new upstream release which I close once I update the package. But not every project gives you this service.
I also maintain several apps on Flathub which doesn’t provide such a service (yet). And it’s even more important to know about new upstream releases because besides the apps themselves I also have to maintain their dependencies which are not available in runtimes. Especially Evolution has quite a few of them.
Anitya gives you an API, so you can write your own service that will be checking with Anitya. But I’m a lazy person and why to write something that already exists, right? The Fedora Project has a web app called Fedora Notificationswhich can send notifications of all sorts of events to your email or IRC. You don’t have to be a Fedora package maintainer or anyhow involved in the Project. All you need is a Fedora account (FAS) to log in.
You pick Email Notifications (or IRC, whichever you prefer), click Create New Filter, then you pick Anything regarding a particular “upstream project” rule, and add projects you want to monitor separated by commas. Then click Add this rule and you’re good to go. This is what my rule for components I maitain in Flathub looks like:
You’ll be getting notifications of new upstream releases to your email and it’s up to you how you’ll act on them. I typically check what kind of release it is, if there are any security or important bug fixes. I try to release those ASAP. Otherwise I plan them for future app releases and test with them beforehand.
I can imagine that there can be a nice automation built on the top of the Anitya API. If it detects a new release, it updates the manifest, triggers a build, and sends you info how it went. Maybe one day 🙂
I really like how Fediverse is shaping up and its federation is starting to make sense to me. It’s not federation for the sake of federation and running different instances of the same service, but about variety of different services that focus on different things, cater different users and yet being to able to talk to each other.
There is Mastodon for microblogging, Friendica for a Facebook-style social network, PeerTube for videos, PixelFed for pictures, Nextcloud Social for making a social network out of your private cloud etc.
The number of users is also growing, it’s already in millions, so it’s becoming an interesting platform for promotion. There are quite a few open source projects already present: GNOME, KDE, openSUSE, Ubuntu, Nextcloud, Debian, F-Droid… And I’ve seen quite a few Fedora contributors scattered across different instances.
So I was like why not to have a Fedora instance there. That’s where Fedora contributors and enthusiasts can have their fediverse homes and create a community within a community, and where the Project can have official accounts for posting just like on Twitter or Facebook. The Fedora Code of Conduct would be enforced there, so that people can feel safe there.
I think the most suitable service for that would be Mastodon, microblogging is generally the most popular in Fediverse, Mastodon has a very active development and seems to be the most mature. There is also “Mastodon as a Service” hosting called masto.host. The domain could be e.g. fedora.social.
After proposing it on Fedora Discourse and talking to several people I think the best approach would be starting it as a personal initiative and if it gets traction handing it over to the Project. It would mean that I’d have to cover the hosting costs and rely on donations for the time being because that’s what having a social network where you’re not the product that is being sold takes.
But it would all go in vain if there was no demand for it. So I wonder:
Would it make you start using Fediverse/Mastodon?
Would it make you switch from another instance? (Mastodon allows you to transfer your data)
Would you be willing to take a more active role (admin, moderator…)?
Would you make a small contribution to help cover costs of running the service?
If you answer yes to any of the questions, let me know. I’d love to know if there is some demand for this or even people willing to help with it.
Over a year ago I got my first serious Bluetooth headphones. They worked with Fedora well, they paired, connected, sound was directed to them. Just the sound quality was not overwhelming. I learnt that because of limited bandwidth of Bluetooth a codec with audio compression has to be used. There are quite a few of them to pick from: AAC (very widely supported because it’s the only one iPhone supports, partly freely available), AptX (also very widely supported, but proprietary), AptX-HD (enhanced AptX with a higher bitrate, also proprietary), LDAC (probably the best codec available, highest bitrate, available in Android, supported mostly by Sony devices), MP3 (also possible, but supported by virtually no devices). And also SBC which is a native Bluetooth, first generation compression codec with rather bad sound quality.
My headphones supported SBC, AAC, AptX, AptX-HD, LDAC, so all the advanced codecs. Sadly on Linux it fallbacked to the basic SBC because no other was available for Bluetooth, and headphones for €200 produced rather underwhelming sound. I mostly listen to music on Spotify. Listening to it on my headphones meant transcoding OGG 320 kbps to SBC and losing a lot of sound quality.
Today I learnt that such a plugin had been finally created. And besides LDAC it also supports AAC, AptX, and AptX-HD. Those are patent-protected codecs and the plugin relies on ffmpeg to support them, so it’s not likely they will be available in Fedora any time soon. But libldac is already in Fedora package review and is waiting for the final legal approval. The plugin currently depends on ffmpeg, but if it were made optional, we could at least ship LDAC support by default in Fedora Workstation.
I don’t have bat ears, but I could recognize a difference in sound quality immediately.
If I’m not mistaken it makes Linux the first desktop system to support LDAC. And with support for other codecs it will make it the OS with the best Bluetooth sound quality support because all other systems support only a subset of the list, hence fewer headphones/speakers at their best sound quality.
I’ve been organizing Fedora release parties in Brno since Fedora 15 (2011) and with the great release of Fedora 29 I couldn’t make an exception. With help of Květa Mrštíková, Lenka Čvančarová, and all speakers I organized F29 release parties in Brno (Nov 26) and in Prague (Dec 4).
The Brno one was hosted in Red Hat offices in Brno and all speakers were redhatters. I kicked off the event with a talk on news in F29 Workstation. Then Michal Konečný continued with his experience using Silverblue (OSTree-based Workstation). František Zatloukal talked on his passion – gaming on Fedora. After the recent release of Proton by Valve, there was a lot to talk about. The last talk was delivered by Lukáš Růžička and it was about maybe the biggest feature in Fedora 29 – modularity.
The party was attended by 50+ visitors both from Red Hat and local community (mainly students). Besides food for their minds (talks) there was also refreshment and all kinds of Fedora swag.
Fedora parties in Prague are usually smaller simply because Red Hat doesn’t have a large office there and visitors come from local community. A smaller number of people and a very cozy venue provided by Etnetera creates very informal atmosphere that generates interesting discussions. I must say I enjoyed this release party perhaps the most from all I’ve ever organized.
I started with a talk on Workstation and since there was no talk on Silverblue I also talked on my experience with it. My talk blended with interesting discussions about related topics and it took over an hour. But I really enjoyed it because it didn’t feel like talking to a silent crowd and some attendees contributed by interesting points and pushed me to clarify some things I talked about. We also had a talk on modularity, this time by Adam Šamalik and František Zatloukal came with me from Brno to talk on gaming on Fedora. I was really looking forward to the talk by Ondřej Koch from the National Library of Technology where they deployed Fedora Workstation on ~200 PCs. Unfortunately he didn’t show up. Then one of the attendees stepped up and gave a talk on how he created a backup solution based on ZFS for a really small municipality in his birth village.
The number of attendees was around 25 and again besides talks we also prepared some food refreshment (courtesy of Red Hat) and a small keg of beer (courtesy of Etnetera). Lenka also surprised everyone by a cake for the 15-year anniversary of Fedora Project.
I’d like to thank everyone who helped with the events and Red Hat and Etnetera for providing venues and refreshment.
I finally finished the 2018 edition of Fedora Handbook (aka Fedora Workstation Beginner’s Guide). Just a recap what the handbook is about: it’s a printed handbook that should give enough information to get a user from “knowing nothing about Fedora” to first steps in the system. It’s used as a giveaway at conferences and other events.
The original handbook was written in Czech in 2015 and the English version released last year introduced only cosmetic changes, so even though the handbook has pretty generic info and is not specific to any Fedora release there were quite a lot of changes needed.
I’d especially like to thank Petr Bokoč who suggested a lot of improvements, implemented some of them, and did the proofreading.
The 2017 edition was only translated into Czech and Spanish. I’d like to see more translations this time. If you’d like to translate it into your language, just go ahead, fork the repo, create a directory named after your language code in the “2018” branch, copy the English origin content into it, and start translating. Once you’re done, do a PR. Please stay in the stable 2018 branch and don’t translate the master. Master is a subject of change and shouldn’t be translated.
We provide a script to automatically generate Docbook, HTML, and PDF files. But ideally the outcome should be a quality PDF that is then printed. But that’s not an automatic process. I’m taking care of the English and Czech versions, but other languages would need volunteers to do the typesetting.
We also have a new cover created by Tereza Hlaváčková under supervision of Mairin Duffy.