This is a very exciting day for me as two major projects I am deeply involved with are having a major launch. First of all Fedora Workstation 24 is out which crosses a few critical milestones for us. Maybe most visible is that this is the first time you can use the new graphical update mechanism in GNOME Software to take you from Fedora Workstation 23 to Fedora Workstation 24. This means that when you open GNOME Software it will show you an option to do a system upgrade to Fedora Workstation 24. We been testing and doing a lot of QA work around this feature so my expectation is that it will provide a smooth upgrade experience for you.
The second major milestone is that we do feel Wayland is now in a state where the vast majority of users should be able to use it on a day to day basis. We been working through the kinks and resolving many corner cases during the previous 6 Months, with a lot of effort put into making sure that the interaction between applications running natively on Wayland and those running using XWayland is smooth. For instance one item we crossed off the list early in this development cycle was adding middle-mouse button cut and paste as we know that was a crucial feature for many long time linux users looking to make the switch. So once you updated I ask all of you to try switching to the Wayland session by clicking on the little cogwheel in the login screen, so that we get as much testing as possible of Wayland during the Fedora Workstation 24 lifespan. Feedback provided by our users during the Fedora Workstation 24 lifecycle will be a crucial information to allow us to make the final decision about Wayland as the default for Fedora Workstation 25. Of course the team will be working ardently during Fedora Workstation 24 to make sure we find and address any niggling issues left.
In addition to that there is also of course a long list of usability improvements, new features and bugfixes across the desktop, both coming in from our desktop team at Red Hat and from the GNOME community in general.
There was also the formal announcement of Flatpak today (be sure to read that press release), which is the great new technology for shipping desktop applications. For those of you who have read my previous blog entries you probably seen me talking about this technology using its old name xdg-app. Flatpak is an incredible piece of engineering designed by Alexander Larsson we developed alongside a lot of other components.
Because as Matthew Garret pointed out not long ago, unless we move away from X11 we can not really produce a secure desktop container technology, which is why we kept such a high focus on pushing Wayland forward for the last year. It is also why we invested so much time into Pinos which is as I mentioned in my original annoucement of the project our video equivalent of PulseAudio (and yes a proper Pinos website is getting close :). Wim Taymans who created Pinos have also been working on patches to PulseAudio to make it more suitable for using with sandboxed applications and those patches have recently been taken over by community member Ahmed S. Darwish who is trying to get them ready for merging into the main codebase.
We are feeling very confident about Flatpak as it has a lot of critical features designed in from the start. First of all it was built to be a cross distribution solution from day one, meaning that making Flatpak run on any major linux distribution out there should be simple. We already got Simon McVittie working on Debian support, we got Arch support and there is also an Ubuntu PPA that the team put together that allows you to run Flatpaks fully featured on Ubuntu. And Endless Mobile has chosen flatpak as their application delivery format going forward for their operating system.
We use the same base technologies as Docker like namespaces, bind mounts and cgroups for Flatpak, which means that any system out there wanting to support Docker images would also have the necessary components to support Flatpaks. Which means that we will also be able to take advantage of the investment and development happening around server side containers.
Flatpak is also heavy using another exciting technology, OSTree, which was originally developed by Colin Walters for GNOME. This technology is actually seeing a lot of investment and development these days as it became the foundation for Project Atomic, which is Red Hats effort to create an enterprise ready platform for running server side containers. OStree provides us with a lot of important features like efficient storage of application images and a very efficient transport mechanism. For example one core feature OSTree brings us is de-duplication of files which means you don’t need to keep multiple copies on your disk of the same file, so if ten Flatpak images share the same file, then you only keep one copy of it on your local disk.
Another critical feature of Flatpak is its runtime separation, which basically means that you can have different runtimes for some families of usecases. So for instance you can have a GNOME runtime that allows all your GNOME applications to share a lot of libraries yet giving you a single point for security updates to those libraries. So while we don’t want a forest of runtimes it does allow us to create a few important ones to cover certain families of applications and thus reduce disk usage further and improve system security.
Going forward we are looking at a lot of exciting features for Flatpak. The most important of these is the thing I mentioned earlier, Portals.
In the current release of flatpak you can choose between two options. Either make it completely sandboxed or not make it sandboxed at all. Portals are basically the way you can sandbox your application yet still allow it to interact with your general desktop and storage. For instance Pinos and PulseAudios role for containers is to provide such portals for handling audio and video. Of course more portals are needed and during the the GTK+ hackfest in Toronto last week a lot of time was spent on mapping out the roadmap for Portals. Expect more news about Portals as they are getting developed going forward.
I want to mention that we of course realize that a new technology like Flatpak should come with a high quality developer story, which is why Christian Hergert has been spending time working on support for Flatpak in the Builder IDE. There is some support in already, but expect to see us flesh this out significantly over the next Months. We are also working on adding more documentation to the Flatpak website, to cover how to integrate more build systems and similar with Flatpak.
And last, but not least Richard Hughes has been making sure we have great Flatpak support in Software in Fedora Workstation 24 ensuring that as an end user you shouldn’t have to care about if your application is a Flatpak or a RPM.
FWIW, https://bugzilla.gnome.org/show_bug.cgi?id=758958 is still a complete showstopper for Wayland for me. I cannot use it for practical work until that’s fixed. Most anyone who uses a password manager will tell you the same. I can hack manually re-typing long, random passwords full of special characters for about a day, then I run screaming back to X…
Thanks for pointing me to that Adam, I will check with the guys what the plan is and let you know.
FWIW, https://bugzilla.redhat.com/show_bug.cgi?id=1326304 for me is close to the point where “I cannot use wayland for practical work until that’s fixed.”
Agreed. While I doubt I’ll ever use GNOME 3 (too much difference of opinion on how a desktop should work and how much it should weigh), this will definitely be a major factor in slowing my move to Wayland.
I type 20+-character hard-random passwords using Win+P and I value configurable window tiling enough that I wrote and maintain QuickTile, which exploits X11’s insecure design philosophy to monkey-patch it into any WM.
15 years ago, when I was a teenager, I’d have been excited about Wayland. Now, I’ve got actual work to get done, I can just as easily enjoy the thrill of being on the cutting edge by learning Rust, and I don’t need another source of drudgework to burn me out.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
Drudgework? I don’t think you really thought this through did you? There’s practically zero work involved in switching to Wayland for users.
Yet another change averse moaner….
Fair point, that’s not implemented yet because that’s kind of a layering break. clutter/libst need to learn about mutter’s clipboard implementation, and a x11-only one should be available too.
In 3.21/master we’ve folded an internal copy of clutter into mutter, so it will be certainly easier to implement now.
Could you please compare Flatpak and AppImage?
I’m disapointed about à new format war instead of an unified solution in the Linux world.
Well I think it would be better if more or less neutral third parties did that comparison as any comparison I would do would likely be met with claims of bias. In general though I think the important differences you would find are things like the runtime separation, ostree functionality like de-duplication and the sandboxing model with portals.
Mouse pointer movements are not smooth enough under Wayland, I see some annoiyng lags.
I think that is a fixed libinput issue, at least I know there was some issues like that caused by missing but now implemented libinput support.
Seamless upgrade. Good job.
I was so excited when middle-click paste landed in Wayland and then I discovered it’s not fully backwards-compatible. :(
I use vim with X11 clipboard support and :set clipboard=unnamed, inside a gnome-terminal tab, and means I’m used to copying text in vim using ‘yy’ and pasting it into Chromium using the middle mouse. And also selecting text in Chromium and then pasting it into vim by hitting ‘p’. Neither of these work in Wayland. :(
I suspect it’s because Xwayland doesn’t export the PRIMARY selection.
Who cares how you accomplish copying and pasting…? Just use the Wayland equivalent and move on.
Marius, what mechanism does vim use to detect the availability of a X11 clipboard? mutter 3.20 indeed implemented the PRIMARY selection to X11 clients, that’s mapped to the wp_primary_selection protocol for gtk+ wayland applications, so c&p using middle click works across clients.
So whatever happens in your case, I think it’s around proper detection of this feature.
– Does the feature work if you run on GDK_BACKEND=x11 gnome-terminal?
– Does the feature work if you run on xterm?
– Does middle click pasting work otherwise between those clients?
Anyhow, if you file a bug, I’ll have a look at this.
I know little about vim internals, but I believe it uses Xlib directly to talk to the X server when DISPLAY is set.
Middle-click paste works fine for Xwayland clients *when I use middle-click to paste*. It doesn’t work when I use key mappings to ask vim to copy/paste.
I seem to remember something about a Wayland security feature that the contents of the selection aren’t made available to a Wayland client unless the user actually used the middle mouse button on a window that belongs to that client, to prevent passive password sniffing attacks. I thought that was the reason.
Thank you for the encouragement of filing a bug! I probably will, once I get over my current burnout phase.
Christian, is there a target date in mind for the ‘Software’ update that will allow the upgrade from F23 to F24?
The suspense is killing me!