When we set of to do the Fedora Workstation we had some clear idea about where we wanted to take it, but we also realized there was a lot of cleaning up needed in our stack to make our vision viable. The biggest change we felt was needed to enable us was the move towards using application bundles as the primary shipping method for applications as opposed to the fine grained package universe that RPMS represent. That said we also saw the many advantages the packages brought in terms of easing security updates and allowing people to fine tune their system, so we didn’t want to throw the proverbial baby out with the bathwater. So we started investigating the various technologies out there, as we where of course not alone in thinking about these things. Unfortunately nothing clearly fit the bill of what we wanted and trying to modify for instance Docker to be a good technology for running desktop applications turned out to be nonviable. So we tasked Alex Larsson with designing and creating what today is known as xdg-app. Our requirements list looked something like this (in random order):
a) Easy bundling of needed libraries
b) A runtime system to reduce the application sizes to something more manageable and ease providing security updates.
c) A system designed to be managed by a desktop session as opposed to managed by sysadmin style tools
d) A security model that would let us gradually move towards sandboxing applications and alleviate the downsides of library bundling
e) An ability to reliably offer online updates of applications
f) Reuse as much of the technology created by others as possible to lower maintenance overhead
g) Design it in a way that makes supporting the applications cross multiple distributions possible and easy
h) Provide a top notch developer story so that this becomes a big positive for application developers and not another pain point.
As we investigated what we needed other requirements become obvious, like the need to migrate from X to Wayland in order to build a modern composited windowing system that renders using GL, instead of an aging one that has a rendering interface that is no longer used for the most part, and to be able to provide the level of system security we wanted. There was also the need to design new systems like Pinos for handling video and add new functionality to PulseAudio for dealing with sandboxed applications, creating libinput to have great input handling in Wayland and also let us share the input subsystem between X and Wayland. And of course we wanted our new packaging system tightly integrated into GNOME Software so that install, updating and running these applications became smooth and transparent to the user.
This would be a big undertaking and it turned out to be an even bigger effort than we initially thought, as there was a lot of swamp draining needed here and I am really happy that we have a team capable of pulling these things off. For instance there is not really many other people in the Linux community other than Peter Hutterer who could have created libinput, and without libinput there is no way Wayland would be a viable alternative to X (and without libinput neither would Mir which is a bit ironic for a system that was created because they couldn’t wait for Wayland :).
So going back to the title of this blog entry I feel that we are now finally exiting what I think of as Phase 1, even if we never formally designated it as such, of our development roadmap. For instance we initially hoped to have Wayland feature complete in a Fedora 22 timeframe, but it has taken us extra time to get all the smaller details right, so instead we are now having what we consider the first feature complete Wayland ready with Fedora Workstation 24. And if things go as we expect and hope that should become our default system starting from Fedora Workstation 25. The X Window session will be shipping and available for a long time yet I am sure, but not defaulting to it will mark a clear line in the sand for where the development focus is going forward.
At the same time Xdg-app has started to come together nicely over the last few Months with a lot of projects experimenting with it and bugs and issues being quickly resolved. We also taking major steps towards bringing xdg-app into the mainstream by Alex now working on making Xdg-apps OCI compliant, basically meaning that xdg-apps conform to the Open Container Initative requirements defined by Opencontainers.org. Our expectation is that the next Xdg-app development release will include the needed bits to be OCI compliant. Another nice milestone for Xdg-app was that it recently got added to Debian, meaning that Xdg-apps should be more easily runable in both Fedora its downstreams and in Debian and its downstreams.
Another major piece of engineering that is coming to a close is moving major applications such as Firefox, LibreOffice and Eclipse to GTK3. This was needed both to get these applications able to run natively on Wayland, but it also enabled us to make them work nicely for HiDPI. This has also played out into how GTK3 have positioned itself which to be a toolkit dedicated to pushing the Linux desktop forward and helping that quickly adapt and adopt to changes in the technology landscape. This is why GTK3 is that toolkit that has been leading the charge on things like HiDPI support and Wayland support. At the same time we know some of the changes in GTK3 have been painful for application developers, especially the changes in how theming works, but with the bulk of the migration to using CSS for theming now being complete we expect that even for applications that use GTK3 in ‘weird ways’ like Firefox, LibreOffice and Eclipse, things should be stable.
Another piece of the puzzle we have wanted to improve is the general Linux hardware story. So since Red Hat joined Khronos last year the Red Hat Graphics team, with Dave Airlie and Adam Jackson leading the charge, has been able to participate in preparing the launch of Vulkan through doing review and we even managed to sneak in a bit of code contribution by Adam Jackson ensuring that there was a vendor neutral Vulkan loader available so that we didn’t end up in a situation where every vendor had to provide their own.
We have also been contributing to the vendor neutral OpenGL dispatcher. The dispatcher is basically a layer that routes an applications OpenGL rendering to the correct implementation, so if you have a system with a discrete GPU system you can for instance control which of your two GPUs handle a certain application or game. Adam Jackson has also been collaborating closely with NVidia on getting such a dispatch system complete for OpenGL, so that the age old problem of the Mesa OpenGL library and the proprietary NVidia OpenGL library conflicting can finally be resolved. So NVidia has of course handled the part in their driver and they where also the ones designing this, but Adam has been working on getting the Mesa parts completed. We think that this will make the GPU story on Linux a lot nicer going forward. There are still a few missing pieces before we have the discrete graphics card scenario handled in a smooth way, but we are getting there quickly.
The other thing we have been working on in terms of hardware support, which is still ongoing is improving the Red Hat certification process to cover more desktop hardware. You might ask what that has to do with Fedora Workstation, but it actually is a quite efficient way of improving the quality of Linux support for desktop hardware in general as most of the major vendors submit some of their laptops and desktops to Red Hat for certification. So the more issues the Red Hat certification process can detect the better Linux support on such hardware can become.
Another major effort where we have managed to cover a lot of our goals and targets is GNOME Software. Since the inception of Fedora Workstation we taken that tool and added functionality like UEFI firmware updates, codecs and font handling, GNOME Extensions handling, System upgrades, Xdg-app handling, users reviews, improved application metadata, improved handling of 3rd party repositories and improved general performance with the move from yum to hawkeye. And I think that the Software store has become a crucial part of what you expect of a desktop these days, with things like the Google Play store, the Apple Store and the Microsoft store to some degree defining their respective products more than the heuristics of the shell of Android, iPhone, MacOS or Windows. And I take it as an clear recognition of the great work Richard Hughes had done with GNOME Software that this week there is a special GNOME Software hackfest in London with participants from Fedora/Red Hat, Ubuntu/Canonical, Codethink and Endless.
So I am very happy with where we are at, and I want to say thank you to all long term Fedora users who been with us through the years and also say thank you and welcome to all the new Fedora Workstation users who has seen all the cool stuff we been doing and decided to join us over the last two years; seeing the strong growth in our userbase during this time has been a great source of joy for us and been a verification that we are on the right track.
I am also very happy about how the culmination of these efforts will be on display with the upcoming Fedora Workstation 24 release! Of course it also means it is time for the Fedora Workstation Working group to start planning what Phase 2 of reaching the Fedora Workstation vision should be :)
Thank you, your doing great job!
I’m looking forward to phase 3 for the world domination!
Hey!
Fedora user since Fedora Core 1 here. I love the move that Fedora is going towards with xdg-apps as I feel that it can help us move towards a more atomic desktop where I can feel safe to always update because I can roll back changes easily and one app isn’t going to break because the libraries were updated for another app.
One question – I know that Fedora is officially a Gnome distro, but is there work planned by the KDE/XFCE SIGs to implement the UEFI, app metadata, etc that you mention near the end of your blog post? I don’t want to get into Holy Wars, I think each person should use the GUI that works best for them. But I really love KDE’s paradigm more than Gnome’s paradigm, but don’t want to be missing out on all the awesome Fedora features.
Well I can’t speak for those other SIGs, but my expectation is that most of the features we do will eventually make it everywhere. For instance a lot of the push behind metadata for GNOME Software should also benefit Apper as it can parse the same metadata as far as I understand. And the underlaying libraries we made for the UEFI stuff for instance should be equally usable by any frontend.
KDE’s alternative to GNOME Software is Muon, it also uses the AppStream format and thus benefits from appdata initiative.
I dream of a perfect integration Desktop-Home Server-Mobile-HTPC suite. I am achieving it by using Fedora, Raspbian, Synchthing, Owncloud, Ampache, mpd, Kodi, Samba, passwordstore, OpenWRT, etc. But it takes a lot of time to set it up and maintain.
I think that is the way I would go if I had the money to create a company. I think would try to sell my own very specific hardware too (buy, reflash, rebrand, resell, give support).
By the way, I am available for hiring by you or by any other Open Source company.
Thank you for all your hard work (and the entire GNOME team).
Christian, I love your blog posts. They are positive and optimistic and fill me with hope that Linux desktop will not only be OK, but even thrive. Thanks, and keep it up! :-)
Coming from Ubuntu, a great thank you!
Thanks, Christian. I enjoy your posts, but the summaries like this really pick up my spirits. I’ve really liked all the improvements over the many years (tho I’ve only recently accepted Gnome3 ;).
s/discreet/discrete/
(sorry, it bugs me more than it really should)
Fixed, in fact I think until this point I didn’t even realize they where two different words, so thanks :)
The (rh) hardware certification effort might become a rather big deal, especially if it leads to laptops becoming more reliable at suspending/hibernating.
With regards to the dispatch library, should that read:
“The dispatcher is basically a layer that routes an applications X rendering to the correct”, where X is OpenGL rather than Vulkan?
Thanks for catching that, it was a leftover from a much earlier draft :) Fixed.
where can I find out what Fedora workstation is intended to look like and do when it’s available?
Here you go:
https://fedoraproject.org/wiki/Workstation/Tasklist
Thanks for your awesome job. I’m quite a young user of Fedora (since Fedora 21). I was an Arch and Ubuntu user before and I was impressed by the quality of the user expérience. I have less hardware and software problem with Fedora and I never had to reinstall since the beginning.
I like how You try to be neutral and provide solutions for entire Linux ecosystem. Thanks for the work. Looking forward to Fedora 24 release, as I just installed it on my laptop.