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.
I spent the last weekend in Prague attending InstallFest 2017. The event is called InstallFest because many, many years ago it started as an event where students could come and get help with installations of various Linux distributions. Times of installfests are gone and this event has transitioned into an open source conference with more practical focus.
The event has moved to a new venue – Faculty of Electrical Engineering of Czech University of Technology. It’s where Red Hat recently started a new open source lab. The venue was larger than the one in previous years and hosted 3 tracks + a small booth area.
I came to talk on two things – Flatpak and Endless OS. My Flatpak talk was on Saturday and got a 55-minute slot which seemed like a lot of time, but if you want to cover all the specifics of the technology, even 55 minutes is not much. The room was pretty full and the topic apparently stirred some attention. There was even one person interested in porting Flatpak to another distribution.
My talk on Endless OS was the first one of the second day. I only asked for a 25-minute slot which was just enough to make a brief introduction of the system. I also brought with me both Endless devices I have in possession – Endless One and Endless Mini. There were not as many people as at my Flatpak talk, but those who came seemed pretty interested. Almost none of them had ever heard of the OS and PCs before. They asked if they’d ever be available in Europe (which I couldn’t answer because I have no idea) or if you can connect extending hardware to the PCs just like to Raspberry.
As a side note, I was positively surprised how many people wore Fedora t-shirts at the conference.
Last week, we had a presentation on Google Summer of Code and Outreachy at Brno University of Technology. Around 80 students attended which was a pretty good success considering it was not part of any course. It was a surprise for the uni people as well because the room they booked was only for 60 ppl.
The main reason why we did the presentation is that there have been very few students in Brno who participated in such programs. And the open source community is pretty big at local universities due to the presence of Red Hat. When we asked students who had heard of Google Summer of Code or Outreachy before only two raised their hands. That was even fever then we expected.
Shortly before the presentation, we discovered that the money reward for successfully finishing Google Summer of Code was not the same globally any more. And for the Czech Republic, it’s now $3600 instead of $5500. So considerably less, but still fairly attractive to local students.
As a follow-up to this presentation, we organized a GNOME hackaton in the Red Hat lab at BUT. Carlos Soriano was in charge of it with me, Felipe Borges, and Debarshi Ray helping him. Carlos prepared images for VirtualBox and KVM with a prepared development environment every student was supposed to download. People had to work in a virtual machine, but they didn’t have to spend time configuring and compiling everything and it assured that everyone had the same environment.
Around 12 students showed up which I think was a good turnout. 3 of them were women which is definitely higher % than the average at the uni. First Carlos told them to read the GNOME Newcomers guide and pick an app they’d like to contribute to. Then he created a dummy bug and showed students the whole process of fixing it from searching the code to the patch review. Then they were supposed to find some easy bug in the app of their choice and fix it.
Almost all students picked apps written in C, which is not so surprising because that’s the language they learn primarily at the university. Only one picked GNOME Music written in Python. The hackaton lasted for 5 hours and all students were busy for the whole time and almost everyone submitted some fix in the end.
Carlos is planning to do a follow-up with those who want to continue, probably before our (ir)regular Linux Desktop Meetup next week. Let’s see if some of them will make it to Google Summer of Code or Outreachy and even become long-term contributors to GNOME later on. It was the first time we actually made students to dip their fingers into the code. At all events before we had presentations on how they can contribute and pointed them to the docs to study at home, but the response was minimal. Maybe such a hackaton where you help students in person to make the first steps is the right approach to break through the barrier.
I’m pretty sure Carlos will also blog about his findings and it will be much more insightful since he spent a lot of time preparing the hackaton and was the one who talked to the students the most.
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!