Fedora 26 is not out yet, but it’s already time to think about how to improve the Workstation edition of Fedora 27. One of the areas my team is focusing on is printing (the desktop side of it). For GNOME 3.24 and Fedora 26 Workstation we landed a new interface for the printing module in GNOME Control Center. It gives a much cleaner overview of printers that are set up on your system.
One thing that I think deserves an improvement is printer sharing. GNOME Control Center doesn’t allow you to easily share a printer with other devices over the network. I’ve heard users complain about it and the competition provides it (even though Windows do it very unintuitively). Sharing via IPP is a pretty low hanging fruit because that’s what CUPS already perfectly supports, you just need to expose it in the UI.
A common use case is sharing a printer with your mobile devices. iOS uses AirPrint which is an extension of the IPP, you just need to convince the device that it’s talking to an AirPrint server. To support Android devices, I think the best way is to use Google Cloud Print. We already support Google Cloud Print, but from the client side. I wonder if it’d be useful to support the server side as well. Google provides an open source server implementation, but it’s written in Go and unnecessarily advanced for our use cases, so writing our own implementation would probably be a better way to go. But I wonder if it’d be worth it. Do people use Google Cloud Print? If not, how do you print from your Android device?
Or are there any other things you think we should improve in printing (desktop-wise)?
Two weeks ago, I blogged about the fact that Netflix was blocking Chrome and Firefox with Fedora user agents although those browsers are now officially supported on Linux. The blogpost got a lot of publicity, almost 5000 hits, and I was even accused of creating clickbaits on reddit 🙂 But it led to the wanted result – solving the issue.
Someone pointed me to Paul Adolph from Netflix. He no longer works in the department which is responsible for user agent filtering, but was very helpful and forwarded the issue to responsible engineers. They never told me why they were blocking Fedora (and it turned out other distributions such as CentOS, Debian, openSUSE too), but promised to fix it within the next couple of weeks. I assume it was just some outdated user agent filter.
I tested it today and it seems to be fixed, both for Chrome and Firefox. And also not only for Fedora, but also for other distributions (I tested CentOS, Debian, and openSUSE). So now you can watch Netflix on Fedora without any user agent tweaking. Just keep in mind that for Firefox you need to install ffmpeg Firefox is using for media playback, Chrome should work out of the box.
I’d like to thank Netflix for resolving the situation pretty quickly.
Netflix should finally support their HTML5 player in Firefox 52 on Linux. This version has already landed in Fedora and been there for a couple of weeks and we’ve already received complaints from users who are confused. Both Netflix and Mozilla claim it should work, but it doesn’t for them.
Netflix still forwards them to their Silverlight player. That’s pretty much a showstopper because Silverlight has been dead for quite a few years and it has never been easy to make it work on Linux.
In fact, Firefox 52 in Fedora does work with Netflix. As we found out the problem is in the user agent. The default user agent is:
Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
If you remove “Fedora” from the user agent, Netflix suddenly stops offering Silverlight and just works. One would say that they only want to support official builds from Mozilla and allow only the upstream user agent. It would be an unfortunate way to do it, but at least partly understandable. But things get really weird when you try replacing “Fedora” with random strings. Because then it also works which means that Netflix blocks Fedora specifically!
Netflix has supported Chrome for much longer and it also has behaved the same there. We set the Fedora user agent via an extension and the only reason why it works in Chrome on Fedora is that we blacklisted the netflix.com domain for the Fedora user agent.
We could do the same in Firefox, but I think it’s something that should be fixed on the side of Netflix. Users should not be denied a service based on their user agent. It takes us 15 years back when Opera had to fake its user agent to work with websites. Moreover Fedora isn’t anyhow different in this than other Linux distributions, so why is it blocked while others are not?
As a Netflix customer, I tried to call their support. I got to a first line support person who didn’t have much of a clue, trying to convince me that Silverlight works just fine on Fedora (which is not really true). So I tried to explain the problem and asked if they could pass it on to responsible engineers. We’ve also been trying to reach them through various contacts. Linux is not probably an important platform for Netflix, but they at least care enough to block specifically Fedora, so they should care enough to fix it. Moreover there are many Linux engineers in the company who could care, too. If you know anyone working in Netflix, please tell them about this and ask them to pass it on to responsible people. If you’re both a Netflix and Fedora user, you may also try to contact their support and let them know that it doesn’t work for you. Maybe if they collect more such cases it will make them look at it.
Edit: I’ve been told that Netflix also blocks user agents of other popular distros. So to make it work you can replace “Fedora” with random strings so long as it’s not “openSUSE”, “Debian”, “CentOS”. The only exception is Ubuntu which is not blocked.
Edit2: I’ve managed to contact the right people in Netflix and they promised to fix it within the next couple of weeks!
I’ve used different services for my personal agenda and I always valued if they could well integrate into my Fedora Workstation. Some did it well, some at least provided a desktop app, some only had a web client. That’s fine for many people, but not for me. Call me old-school, but I still prefer using desktop applications and especially those who look and behave natively.
Last summer, I decided to install Nextcloudon my VPS. Originally I was planning to replace Dropbox with it, but then I found out I could actually use it for many other things, for all my personal agenda. Shortly after that I realized that I’d found what I was always looking for in terms of integration into my desktop. Nextcloud apps use standard protocols and formats and integrate very well with the desktop apps I use.
Nextcloud/ownCloud is supported by GNOME Online Accounts, so I log in to my server and automagically get this:
Files – my Nextcloud appears in Nautilus as a remote disk. I like that it doesn’t work like the official desktop client of Nextcloud or Dropbox and doesn’t sync files to the local drive. If you work with small files and documents remotely, you can hardly notice lags and they don’t consume space on your hard drive. If I want to work with large files (e.g. video) or offline, I just download them.
Documents – documents that are stored on your Nextcloud server appear among documents in GNOME Documents. The app makes an abstraction layer over different file sources and the user can work with documents no matter where they come from. A nice thing, but I’m a bit conservative in this and prefer working with files and Nautilus.
Contacts – the Nextcloud app for contacts uses CardDAV, so after a login in GOA your contact list appears in all applications that are using the evolution-data-server backend. In my case it’s Evolution and GNOME Contacts. Evolution is still my daily driver at work while I use the specialized apps at home.
Calendars – the calendar app for Nextcloud uses CalDAV, so after a login in GOA you get the same automagic like with contacts, your calendars appear in all apps that are using evolution-data-server. Again in my case it’s Evolution and GNOME Calendar.
Tasks – CalDAV is also used for tasks in Nextcloud, so if you enable calendars in GOA, your task lists will also appear in Evolution or GNOME Todo.
Notes – the same applies to notes, you will also be able to automagically access them in Evolution or GNOME Bijiben.
News – the only thing I had to set up separately is a news reader. I use FeedReader which (among other services) supports Nextcloud/ownCloud, too. So I could replace Feedly with it and get a native client as a bonus.
What’s really great is that except for the RSS reader everything is set up with one login. I’m done with Feedly, Evernote, Wunderlist and all those services that each require another login and generally have poor desktop integration. Now I can use Nextcloud, have all my data under control and get great and super-easy-to-setup integration into my desktop.
I can imagine even more areas where Nextcloud can improve my desktop experience. For instance, it’d be great if my desktop user settings could be synced via Nextcloud or I could back them up there and then restore them on my new machine. Or it’d be great if the desktop keyring could work with Passman and sync your passwords.
BTW integration into my Android phone is equally important to me and Nextcloud doesn’t fail me there either although setting it up was not as easy as in my Fedora Workstation. I needed to install CalDAV-Sync and CardDAV-Sync apps (DAVdroid which is officially recommended by Nextcloud never worked for me, a while back it didn’t want to sync my contact list at all, now it does, but doesn’t import photos). Then my contacts and calendars were synced to the default apps. For tasks I use OpenTasks. For RSS ownCloud/Nextcloud Reader and for notes MyOwnNotes. To access files Nextcloud provides their own app.
And if I’m not around my PC or phone, I can always access all the services via the web interface which is pretty nice, too. So all in all I’ve been really satisfied with Nextcloud and am really happy how dynamically it’s developing.
When I announced Firefox Developer Edition for Flatpak over a month ago, I also promised that we would not stop there and bring more options in the future. Now I can proudly announce that we provide two more variants of Firefox – Firefox Nightly and Firefox Nightly for Wayland.
With Nightly, you can closely follow the development of Firefox. Due to Flatpak you can easily install it and keep getting daily updates via our flatpak repo.
As a bonus, we’re also bringing a Firefox build that runs natively on Wayland. We used to provide a Copr repository, but with Flatpak it’s open to users of other distros, too. When running this version, keep in mind it’s still WIP and very experimental. Firefox seems to run just fine on Wayland at first glance, but there is still some basic functionality missing (copy-paste for example) and it’s not so stable either (it crashed the whole Wayland session for me once). But once it’s done, it will be a big improvement in security for Firefox on Linux because Wayland isolates the application on the display server level. Together with other pieces of Flatpak sandboxing, it will provide a full sandbox for the browser in the future.
When adding more Firefox variants to the repo, we first considered using branches, but you have to switch between them manually to start different variants of Firefox which we didn’t find very user friendly. In the end, we’re using one branch and multiple applications with different names in it. This way, you can install and run multiple variants in parallel.
You can find the instructions to install Firefox for Flatpak on the repository webpage. We’re also constantly improving how Firefox runs in Flatpak. If you have any Flatpak-specific problems with Firefox, please report it to our bug tracker on Github. If you hit problems that are not Flatpak-specific, please report them directly to Mozilla.
And again kudos to Jan Hořák from our team who made all this happen!
One of our goals for Fedora Workstation is to run Qt applications in GNOME as seamlessly as possible. Their look should be as close to their GTK+ counterparts as possible, you shouldn’t have to set things on two different places just to make the change in both GTK+ and Qt applications.
A while back, we introduced the Adwaita theme for Qt and QGnomePlatform which makes sure all settings get translated from the GTK+ world to the Qt one. The original Adwaita theme was written from scratch. To write a theme for Qt is pretty complex and the look of Adwaita for Qt was close to Adwaita for GTK+, but not close enough. Then Martin Bříza, who is working on this, decided to change the approach and based the new version on the default KDE theme and kept changing it until he got a theme that is very similar to Adwaita for GTK+. And indeed it’s now much closer than the first version.
Martin also worked on the dark variant of Adwaita for Qt, so that if you switch to this variant, Qt apps still don’t look out of place. Or if there is a Qt app that uses a dark theme it can have a look that fits into GNOME.
Martin didn’t stop there. GNOME also offers a high contrast theme for those with visual impairment which prevents them from using standard themes. They’re also not left behind. If you switch to the HighContrast theme in GNOME Qt apps will switch to it, too.
On the video below, you can see a mix of Qt and GTK+ apps and how they change when you switch between different themes:
These changes should land in Fedora 26 Workstation, but you can already try them out. Martin created a Copr repository. Keep in mind it’s work in progress. If you’d like to report bugs or help with tuning the themes, all the code is on Github.
Another edition of DevConf.cz took place last week. It was already the second edition I didn’t organize. This year, I was involved in the organization even less, just helping with the program and serving as a session chair for one day. So I could enjoy the conference more than ever before.
DevConf.cz is still growing. This year, we had over 1700 registrations and ~1600 ppl actually showed up. This time, we also know for sure because it was the first edition when we did a registration and check-in. DevConf.cz is growing into a smaller FOSDEM with more focus on open source enterprise technologies and I think it even covers this area better than FOSDEM. The number of talks and workshops was also a bit higher, I think (200-250).
The opening keynote was pretty interesting. Tim Burke, the VP of Red Hat, announced a focus on integration of different Red Hat products and this year he showed it had actual results. People could see a demo of using different Red Hat products from hardware provisioning to deploying an app to OpenShift from JBoss Developer Studio. I hope that we as the desktop team will be able to contribute to this. Fedora Workstation is a great OS for developers and it should be the best OS for developers that want to develop on Red Hat platforms. I’d love us to get to the point where starting to develop with Red Hat technologies is just a matter of a couple of clicks/commands.
Another highlight of the conference was Hans de Goede’s talk “Making Fedora run better on laptops”. Hans announced a new team which is part of the desktop team and which will work on better hardware support in Fedora and RHEL (with the focus on laptops). We will finally have laptop models which will be officially supported!
The desktop track took place on Sunday. I session-chaired it, so I was more or less obliged to watch it all 🙂 Matthias Clasen prepared a very good presentation on Flatpak. His talk and, in fact, the whole track was interrupted when the projector system broke down. Unfortunately it was a failure in one of the main hardware components which couldn’t be fixed immediately. Matthias had to carry on without the projector and I must say that despite all the difficulties he did very well and there was a lot of questions. Meanwhile we managed to get a backup room where we moved the track once Matthias’ talk was over. Unfortunately the room was much smaller and a bit hidden which might have had an impact on attendance. So not so many people had an opportunity to watch another interesting talk – “Fedora Workstation – removing obstacles to success” by Christian Schaller who outlined some of our plans for the official Fedora desktop edition.
The weather during the conference was extraordinarily cold and a new term – devconflu – was invented. But I really enjoyed it, just had to give up FOSDEM for it. I was not up for another DevConf.cz+Red Hat internal meetings+FOSDEM this year.