So Fedora Workstation 21 is done and out and I am extremely pleased to see the positive reception and great reviews. But we are not resting on our laurels here and are already busy planning for the Fedora Workstation 22 release. As many of you might know Fedora Workstation 22 is going to come up relatively fast, so we only have about 6 more weeks of development on it feature the freezes starts to kick inn. Luckily we have a relatively long list of items that we started working on during the Fedora Workstation 21 cycle that is nearing completing and thus should make the next release. We are of course also working on bigger long term developments that you should maybe see the first outline of in Fedora 22, but not the final version. I thought it would be nice to summarize some of the bigger items we expect to land and link to the relevant blogs and announcements for each one.
So first out is to give an update on our work on Wayland as I know that is something a lot of people are curios about. We are continuing to make great strides forward and recently hired Jonas Ådahl to the team who many might recognize as an active Wayland and libinput developer. He will be spearheading our overall Wayland effort as we are approaching the finish line. All in all things are looking good, we got a lot of the basic plumbing in place for Fedora Workstation 21, so most works these days is mostly focused on polish and cleanups. One of the bigger items is the migration to use libinput. libinput is a library we decided to create to be able to share input device handling between X and Wayland and thus make the transition smoother and lower our workload during the transition period. Libinput itself is getting very close to feature complete and they are even working on some new features for it now taking it beyond what was in X. Peter Hutterer recently released version 0.8 and we expect to have 1.0 out and in use for both X.org and Wayland in time for Fedora Workstation 22.
In parallel we are also working on porting the needed bits in GNOME over to use libinput and remove any lingering X dependencies, like the GNOME Control Center which should also be ready for Fedora Workstation 22.
Another major change related to Wayland in Fedora Workstation 22 is that we will switch the default backends in GTK+ and SDL over to using Wayland. Currently in Fedora Workstation 21 applications are actually running on top of XWayland, but in Fedora Workstation 22 at least GTK+ and SDL applications will be default to Wayland when run under the Wayland session.
The Wayland SDL backend has been around for quite a bit, but Jonas Ådahl plans on spending some time smoothing out the last rough edges, in fact for SDL applications we hope we can actually provide noticeable performance improvement over X in some cases (not because OpenGL will be faster of course, but because we might be able to be smarter about handling different resolutions between desktop and game), but we have to wait and see if that pans out or if we have to settle for performance parity with X. We are also looking at getting the login session to use Wayland by default. All in all this should take us a huge step forward towards making using Wayland feel real.
As it looks now Wayland should be quite close to what you would define as feature complete for Fedora Workstation 22, but one thing that is going to take longer to reach maturity is the support for binary drivers, especially the NVidia ones. This of course is a task that mostly falls on NVidia for natural reasons, but we are trying to help out by Adam Jackson working to making sure Mesa works with their proposed EGLStreams and OpenGL Dispatcher proposals. So during the course of the coming year we will likely have a situation that you will be able to have a production ready Wayland session if you are running any of the open source drivers, but if you want to run Wayland on top of the NVidia binary driver that is most likely to only really be possible towards the end of the year. That said this is a guesstimate from our side as how quick the heavy lifting will happen, and how quickly it will be released by NVidia for public consumption is of course all relying on internal plans and resources at NVidia and not something we control.
One thing we know being developers ourselves and from speaking with developers about their operating system of choice, battery life is among the top 5 reasons for what choice people make about their hardware and software. Due to this Owen Taylor has been investigating for some time now both what solutions exist today, what other operating systems are doing and what approaches we can take to improve battery life. Because a common complaint we hear from a lot of people is that they don’t feel they get great battery life when running linux on their laptops currently. Some people are able to solve this using powertop, but we feel there are a lot of room for automatically give our users better battery life beyond manual tweaking user powertop.
Improving battery life is a complex issue in many ways, including figuring out how to measure battery life. I guess everyone has seen laptops advertised with X number of hours of battery life, but it is our impression that those numbers tend to be quite bogus even when running the bundled operating system. In some testing we done we concluded that the worst offenders numbers could only true if you left your laptop idle in the corner with the screen blacked out. So gnome-battery-bench will help us achieve a couple of things, it should generate comparable battery lifetime numbers which both should help our users choose the hardware that gives the best battery life under linux and it also lets us as developers keep tracking how changes affect battery life so that we can catch regressions for instance. It also lets us verify the effect various kernel tuneables or ambient light detection schemes have on battery life in a better way than we can with existing tools. We also hope to use this to work with vendors to improve the battery life of their hardware when running Fedora or RHEL. Anyway, I suggest reading Owens Taylors blog for some more details of his work on improving battery life..
One important effort we want to undertake here, which might not all make it for Fedora Workstation 22, is taking advantage of the ambient light detectors in many modern laptops. One of the biggest battery drains in your system is the screen brightness setting and by using the ambient light detection hardware we hope to be able to put in place some intelligent behavior for different situations. This is a hard problem though and it was attempted solved in GNOME before, but the end result back then was that people felt they where “fighting” GNOME over their laptop brightness settings, so in the end it was dropped completely, so we need to careful to not repeat that outcome.
Another major effort that is not going to ready for Fedora Workstation 22, but which we might have some preview of is Application bundles. Matthias Clasen recently sent out an email to the Fedora Desktop mailing list outlining the state of the application bundles work. This is a continuation of the Sandboxed Applications in GNOME proposal from Lennart Poettering. The effort is being spearheaded by Alexander Larsson and the goal is to build the infrastructure needed to do sandboxed desktop applications efficiently. There is a wiki page up already detailing Sandboxed Apps and there are some test applications already available. For instance you can grab an application bundle of Builder, the cool new IDE project from Christian Hergert. (Hint, make sure to support his Builder crowdfunding effort if you have not already.). Once this effort matures it will revolutionize how desktop applications are built and distributed. It should make life easier for application developers as these bundled applications are designed to be distribution agnostic and the sandboxing aspect should help improve security. Also the transition should put the application developers directly in charge of the update cycle of their applications enabling them to better support their users.
3rd Party Application handling
So the ever resourceful Richard Hughes has been working on adding support for handling 3rd party applications in GNOME Software. He outlined this effort in a recent blog post about GNOME Software.
While the end goal here it to offer 3rd party application bundles as described in the section above, the feature has also a lot of near term advantages. We have seen that over the course of the last years we moved from a model where you use your browser to search for software online to users expecting to find all software available for a system through its app store. With this 3rd party application support available in GNOME Software we can start working to make that expectation a reality also in Fedora. We took great strides forward in Fedora Workstation 21 with having metadata available for most of the standard applications packaged in Fedora, but there is also a lot of popular applications and other things out there that people tend to install and use which we for various reasons are not interested or able to ship in Fedora. The reason for this can range from licensing issues, to packaging issues to simply resource issues. With Richards work we will be able to make such software discoverable in Fedora, yet make a clear distinction between the software we have vetted and checked and the software you get from 3rd parties.
How to deal with 3rd party software has been a long and ongoing discussion in the Fedora community, and there are a lot of practical and principal details to deal with, but hopefully with this infrastructure in place it will be a lot easier to navigate those issues as people have something concrete to relate to instead of just abstract ideas and concepts.
One challenge for instance we have to figure out is that on one side we don’t want 3rd party software offered in Fedora to be some for of endorsement or sign of being somehow vetted by the Fedora Project on an ongoing basis, yet on the other side the list will most likely need to be based on some form of editorial process to for instance protect both Red Hat and Fedora from potential legal threats. I plan on sending an initial proposal to the Workstation Working Group soon for how this can work and once we hashed out the details there we will need to bring the Working groups proposal into the wider Fedora community as this also affects our Cloud and Server offering.
A lot of people these days use Google Drive, be that personally or because their company has a corporate Google apps account. So to make life easier for our users we are making sure that Nautilus are able to treat your Google drive as just another drive on the system, letting you drag and drop files off or on it. We also dedicated some effort to clean up and modernize the file manager in general, with Carlos Soriano blogging about his efforts there just before Christmas. All in all I think these are improvements that should improve the life of our developer and sysadmin target audience, but of course they are also very useful improvements to the general linux using public.
One of the things we had to postpone for Fedora Workstation 21 was the Adwaita theme for Qt applications. We are expecting it to hit Fedora Workstation 22 though and you can get the theme to install and test from Martin Briza copr repository. The end goal here is wether you run a pure Qt application like Skype or Scribus, or a KDE application like Krita or Amarok, you should get an Adwaita look and feel to the application. Of course desktop integration isn’t just about a theme, there is a reason the GNOME HIG exists, but this should be an improvement over the current situation. The theme currently targets Qt4, but of course Qt5 is also on the roadmap for a later release.
Further terminal improvements
As I mentioned in an earlier blog entry about Fedora Workstation we realize that the terminal is the most important application for many developers and sysadmins. So we are also hoping to land some more of the terminal improvements we been working on in Fedora Workstation 21. The notifications for long running jobs being maybe the thing I know a lot of developers are excited about getting their hands on. It will let you for instance start a long compile in a terminal and know that you will be notified once it is completed instead of having to manually check in from time to time.
More development tools
In my opinion the best IDE for Python development currently is PyCharm. And not only is it the best from a functionality standpoint they also decided to release an open source version last year. That said we have been struggling a bit with the packaging of PyCharm, and interestingly enough it is one of those applications I think will benefit greatly from the application bundle work we are doing, but in the meantime we at least do have a Copr of PyCharm available. It is still an open question, but we might make this CoPR one of our testcases for the 3rd party application support in GNOME Software as mentioned earlier. Anyway if you are a Python developer I strongly recommend taking a lot at it. Personally I looked at various Python IDEs over the years, but always ended up just going back to Gedit, but when trying PyCharm it was the first time I felt that the application actually offered me useful functionality beyond what a text editor like Gedit does. Also in recent versions they also deal well with the introspection based Python bindings for GTK3 which was a great boon for me.
We are also looking at improving the development story around Vagrant and doing Fedora and RHEL development, more details on that at a later point.
The ABRT tool has become a crucial development tool for us over the last couple of years. The Fedora Retrace server is one of our main tools
for prioritizing which bugs to look at first and a crucial part of our goal of making Fedora a solid
distribution. That said, especially its early days, ABRT has had its share of detractors and people
being a bit frustrated with it, so Bastien Nocera and Allan Day has been working with the ABRT team to both integrate
it further with the desktop, for instance ensuring that it follows your desktop wide privacy settings
and to make sure that the user experience of submitting a retrace report is as smooth and intuitive as possible
and not to mention as unobtrusive as possible, for instance you don’t want ABRT to choke your system while trying to generate
a stack trace for us. The Fedora Workstation Tasklist contains links to bugzilla and github so you can track their progress.
Still a lot to do!
So making our vision for the Fedora Workstation come through takes of course a lot of effort from a lot of people. And we are really lucky to be part of such a great community where so much cool stuff is happening all the time. I mean the Builder effort from Christian Hergert as I talked about earlier is one of them, but there are so many other things happening too. So if you want to get involved take a look at our tasklist and see if there is anything that interests you or for that matter if there is something that you think should be worked on, but isn’t on the list yet. Then come join us either on #fedora-workstation on the freenode IRC network or join the fedora-desktop mailing list.
Great to hear Fedora is progressing. In particular, the Application Bundles sound like a great step forward. It’s about time we got away from the many restraints imposed by rpm/deb/etc.
hi! the bundles you are referring to are similar to osx bundles?which are the differences?thank you!
They are similar in some ways for sure, but I think our plans around sandboxing are quite different from anything Apple does.
Similar, but taken further. Apple app bundles contain all the files needed to distribute the application, but runtime files are stored in the main filesystem, e.g., in /Library and ~/Library. In Gnome application bundles, everything about the application will live in the app bundle, including the app’s own /var for runtime information. Applications should be completely sandboxed and self-contained.
I would really love beter hidpi support. I know this is partly an app thing but I think Fedora should make it transparant for apps to run either on low or hi DPI.
It should *just work*..
We have done a lot of work around HiDPI already, but the switch to Wayland will hopefully sort out the last major issues (for instance running with two monitors one hi-dpi and one normal)
Very nice, especially the Wayland progress (can’t wait to drop X) and the Google Drive integration!
I agree with you that this is a loss of robustness, but it’s something we may have to deal with (I suppose each app could started outside wayland and remoted in, but that seems…hacky).
As for js, I don’t think that js, in itself, is going to make the de any less stable (extensions, yeah, but that’s due to architecture not js).
JS is a symptom that gnome-shell was never designed to be the central piece that can’t crash.. A program using a GC just can’t be a long running piece. I still think the solution is to have a “simple” compositor that does 95% of the work, for example, by drawing windows as rectangles, and then offloads drawing the UI and “complex composition” (such as the activities views) to a “client compositor”. Basically, something that in the normal case does the compositing, but in the more complex case, works like gnome-shell does in X11. But that requires a pretty big re-write of gnome-shell and I’m afraid that it won’t happen before F22 or even F23…
I really love the captive portal support in network manager shipping in F21. Nevertheless, there is room for improvement: form and password retainment. Most (hotel) portals rquire you to log in again and again after you have disconnected from the network or after some predefined time. Remembering these login credentials would make my life a lot easier!
If half of this finds way into F22, I’ll be crying while installing it. But, it won’t be sad cry.
After seeing the “future of systemd” video, I’m eagerly looking forward to seeing systemd.networkd incorporated into Fedora. Having programmatic access to create wifi stations, faster dhcp client behavior and bridging support would really make a lot of sense for my team’s product.
Are there any plans to make the KDE spin achieve the same attention as the “Workstation” one?
Honestly, there is a world of difference in usability. GNOME has some good ideas, but it a death by a thousand cuts with their ideas that are all over the place.
I guess the answer to your question is no and maybe yes. I mean we as the Workstation working group is not planning to put the same level of attention into creating a desktop operating system around KDE, but that doesn’t mean that someone else can’t step forward and do it.
How about Qt5? Many applications are based on Qt5, ported from Qt4 to Qt5, KDE and its apps are on Qt5 now, an increasing number of high profile applications are ported fom other toolkits, like Gtk2, to Qt.
Yet another Qt4 gtk-style is nice but what about Qt5 which has gtk3 Adwaita theme support but nobody who seems to have focus on polishing the last percent to make all this Qt5 applications proper themed on Fedora. One example:
It is on the TODO list, we simply hasn’t had time to get around to it yet :)
In a nutshell, Fedora is backing Gnome3. Screw everyone else.
In reality, KDE / XFCE fulfill the needs of many – however these are going to get left behind as Gnome3 gets more convoluted and abstracted from a real DE.
Fedora will stick with Gnome3 and systemd – and EL8+ will be infected with this as well. We’ll witness the exodus of users to other solutions (FreeBSD activity has skyrocketed).
Sadly, RedHat has enough swing that its dragging the rest of the linux ecosystem along with it. And its not a good thing.
I never understood this idea that doing something is ‘anti’ everything else. For instance currently I drive a Toyota because that was the car that fit my needs the best, but that doesn’t mean I am against BMW, Ford, Honda or any of the other brands out there. And when I meet people driving those other brands of cars I do assume or think of them as Toyota haters.
And that is all what we are doing here too, we are making a choice that makes sense for us in the context of what we are trying to achieve.
Something that would help idle battery a great deal is timer consolidation (via the timer_slack property handled by systemd), and possibly handled dynamically via g-s-d. That’s something that needs a bit of thought (that is, some timers can afford more slack than others, and pretty much all timers can be more tolerant when system is idle) but is used by all the major desktops and mobile os’s.
>Fedora Workstation 21 was the Adwaita theme for Qt applications.
does this means that qt apps will have adwaita theme but not gtk3-qt engine kind.other themes will have to be ported to qt4?
It would be great if ABRT could come out of GNOME’s pond and support a wider desktop community. For example by supporting KStatusNotifierItems via libappindicator.
Nice summary Christian! I have played around Wayland a lot in Fedora 21, and it looks like we are getting there.
Will be interesting how your work on GNOME Software support for third party software and app containers change landscape of Linux desktop software. I personally have no problems to use rpm/deb these days, but I guess it’s not very convenient.
A few years ago I heard a good idea for managing screen dimming timeouts better (It was in a talk about OLPC).
Start with a timeout of 1 min. If the user moves the mouse within a few seconds of the screen dimming, then the timeout is probably too short, so increase it, if the user does not move the mouse within a few seconds, then maybe the timeout is too long, so reduce it.
So I am reading something wordy on screen, that only requires a scroll every couple of minutes, then after a couple of screen dims and mouse pokes the timeout will be perfect. Then I might start reading a book, an poke the mouse occasionally to check the time or if I have a new email, when the screen dims, I ignore it and the timeout gets reduced.
I am not sure it got implemented for OLPC, but I’d like to see it implemented on a normal desktop.
I too think that there should be a KDE workstation. KDE is arguably the most widely used graphic environment on Linux. It is particularly appreciated in the scientific community. It is really a pity that the Fedora team regards KDE as just one more of the exotic, or niche, environments.
Our resources are limited so we want to focus our efforts to have maximum effects, and despite popularity of the topic among linux insiders the choice of desktop environment is a secondary concern for most users. So for instance if we want to double the number of Fedora Workstation users then spending time on improving battery life is immensely more important than spending time on enabling and trying to keep parity between two desktop alternatives. Also I don’t think anyone can arguably or non arguably claim that KDE is the most used graphics environment on Linux unless they venture far into wishful thinking territory, personally I would bet Unity is the desktop environment with the most users currently. Or ChromeOS if we count them as a linux desktop. Of course both those examples underscore the reasons for why we keep a singular focus for the Workstation, most people choose operating system to run, not desktop environment, in fact I am sure ChromeOS users don’t even think of their desktop environment as separate from the operating system at all and I would not be surprised if a significant percentage of Ubuntu users see things the same way.
I’m sorry, but your assertion that “the choice of desktop environment is a secondary concern for most users” is at best misleading. While a percentage such as 60% is “most”, it is not exactly an overwhelming majority. In fact, it indicates that 40% of users are not happy, which is an alarming number.
Let us look at Fedora statistics (notwithstanding all the caveats). The total repository connections are listed at
and show that after Fedora 15 was released (with Gnome 3.0), the average number of users dropped by about 2.5 million, or around 40% of the user base.
Since the major change in F15 was Gnome 3, it means that 40% of people do find the choice of the desktop environment important.
Details about the stats are as follows. The average amount of repository connections across Fedora 7 to 14 is about 6 million. For Fedora 15 to 20, the average is about 3.5 million. That’s a drop of around 2.5 million, or around 40% of the user base.
Sandboxing software to fix security problems seems like the wrong way to do it. You are effectively trying to solve one of the key functions of a kernel; keeping track of which rights a program does and does not have and make sure it doesn’t violate any restrictions.
Regardless, sandboxing will only help damage done by software that has already been sandboxed — it does nothing to software outside the boxes, which makes me question the impact of sandboxing at all. Any piece of software out of the box, is going to be just as problematic as before; it will be able to manipulate the same files as it would without sandboxing and will be able to connect to the save servers as it would without sandboxing.
Fixing this kind of problem in the kernel (i.e. make the kernel own up to it’s responsibilities) seems like the only solution.
Glad to see that innovation is back in the house Fedoras
Unfortunately I have been unable to test Wayland properly on Fedora 21, because on all three Intel systems I have, I hit this bug. It is particularly annoying since all three systems are supposedly using free drivers for video. Hopefully this will be fixed in Fedora 22.
what is with the support of high dpi displays. Linux Desktop will sickly on that more and more
Not sure I 100% understand your question, but we have been doing a lot of work on HiDPI support and it is mostly there now. There are some 3rd party apps that are a bit painful still, Google Chrome being maybe the most important and then there is the case of using a HiDPI display with a second non-HiDPI monitor which is something we will be able to fix in Wayland. In fact we hope to have that fix in Wayland before Fedora Workstation 22 for people to try out, but I can make no promises on that yet.
Nice post. I would be pretty cool if we could improve the gnome-terminal to something like http://finalterm.org/ (there are many cool features, but it have tons of bugs)