Fedora Media Writer is the tool to create live USB flash drives with Fedora. You can also use dd or GNOME Disks, but Fedora Media Writer is the only graphical tool that is tested with Fedora ISOs (please don’t use UNetbootin and such because they really cause faulty Fedora installations).
Fedora Media Writer is available as an RPM package in Fedora repositories and we provide installation files for Windows and macOS. Those are actually offered to users with Windows and macOS as the default download options at getfedora.org. We’ve provided users of other Linux distributions with a flatpak, but it was hosted in its own repo. Recently we managed to get the flatpak to Flathub which many users have already enabled, so now it’s even easier and faster to install.
Several years ago, we organized two workshops focused on packaging software for Fedora. It was a success. Both workshops were full and several participants became package maintainers in Fedora. Packaging for Flatpak is becoming popular lately, so we decided to offer a workshop which is focused on flatpaking apps.
Two weeks ago, I had the pleasure to attend Flock 2017, the annual Fedora contributor conference. It moves between North America and Europe and after Krakow, Poland last year it took place in Hyannis, Massachussetts.
The conference started with the traditional keynote by Matthew Miller on the state of the Fedora Project. Matthew does a lot of data mining to create interesting statistics about how the project is doing. The keynote is an opportunity to share it with the public.
The Fedora user base is still growing as you can see on the chart of IP connections to Fedora update servers. Fedora 26 exceeded F25 just before Flock:
Here are also geologic eras of Fedora as Matthew calls them. As you can see there is still a decent number of very old, unsupported Fedora installations which are still alive:
It’s a pity that Matthew didn’t include the slide with ISO download shares of Fedora editions and spins. But last time he did Fedora Workstation amounted to ~80 % of all ISO downloads.
But by far the most popular part of the project is EPEL. Just look at its number of IP connections compared to all Fedora editions:
Which brings me to another interesting talk I attended and that was EPEL State of the Union by a Fedora Project veteran Stephen Smoogen. As a Fedora packager I also maintain a couple of packages for EPEL, so it was interesting to hear how this successful sub-project is doing.
There were not many desktop-related talks this year. No “Status of Fedora Workstation” any more. It was very modularization and infrastructure focused. One of a few desktop talks was “Set up your own Atomic Workstation” by Owen Taylor, who is experimenting with distributing and running Fedora Workstation as an atomic OS, and Patrick Uiterwijk, who has been running it on his machine for a year or so (had a similar talk last year). Wanna try it yourself? Check out https://pagure.io/workstation-ostree-config
Although I didn’t attend the talk about secondary architectures by Dan Horák, we ended up talking and I was very happy to learn that the secondary arch team is doing automated builds of Firefox Nightly to catch problems early. That’s great news for us because with every major release of Firefox secondary architectures consumes a lot of our time. I asked Dan if they could do the same with WebKitGTK+ because it’s a very similar case and it looks like they will!
Several months ago David Labský created a device called Fedorator as his bachelor thesis supervised by a Fedora contributor and Fedora badge champion Miro Hrončok. The device lets you create a bootable USB stick with a Fedora edition of your choice. It’s Raspberry Pi-based, it has a touchscreen. The design is open source and you can assemble it yourself. Two months ago I got an idea to get David to Flock, buy components and assemble a dozen of fedorators which Fedora ambassadors can take home to use at local events. The result of it was a session at Flock where participants indeed assembled a dozen of fedorators. I only provided the idea and connected David with the right people. It wouldn’t have been possible without help of Brian Exelbierd, Paul Frields and others who arranged a budget, bought components etc.
I also did have a session, but unfortunately it was a complete failure 😦 I coordinate the Fedora Workstation User’s Guide project whose goal is to produce a printed guidebook for new users. We’ve had a Czech version for the last two years and we just finished the English one. I wanted to work on content changes for the next release and help people start versions translated into their languages. Unfortunately my session was scheduled at 6pm on the last day when everyone was ready for dinner or was even leaving the conference. It also overlapped with the docs session which people who I knew had been interested attended.
In the end, not a single person showed up at my session which is my new personal record. I’ve done dozens of talks and sessions at conferences, but zero audience was a new experience.
Anyway, if you’d like to produce a handbook in your language to use at booths and to spread the word about Fedora, check the project on Pagure. As I said the 2017 release is out and will only receive bug fixes, the content is final and thus it’s safe to translate.
Although my session was not really a success I’m still glad I could attend the conference. I had several hallway conversations about the project and countless other interesting conversations, learned new things, caught up with Fedora friends.
Recently I got Dell XPS 13 as my new work laptop and I use it with the TB16 dock. This dock doesn’t seem to fully work with Linux, only monitors work. But if you go to BIOS settings and set the Thunderbolt Security level to “No security”. Then suddenly almost everything is working.
However, it’s not an ideal solution, especially if you’re at least a bit paranoid. External Thunderbolt devices may connect to the machine via PCI-Express which means they can potencially read your system memory. That’s why Thunderbolt comes with a security system.
There are 4 security levels:
none (legacy mode): no security, everything gets enabled.
dponly: no PCIe tunneling, only USB and DisplayPort.
user: ask the user if it is ok to connect the device.
secure: as “user” but also create and use a random key that later can be used on subsequent connects of the same device to ensure its identity.
Intel is already working on a Linux implementation of TB security. But the user and secure levels need user’s action, so there will have to be some support for it in the desktop. I discussed that with designers and they don’t really like the idea of poping up dialogs asking users if they trust the device. “Do I trust this projector? I’m not really sure, but since I’m plugging it in, I guess I do”.
I also checked how it works in Windows 10. And it works exactly that way. I plugged in the dock and I got a bunch of dialogs asking about every single plugged-in device. The experience is pretty terrible. And I have to agree with the designers, I’m not sure how this improves security.
On the other hand, I don’t think it’s a good idea to leave the Thunderbolt port completely unprotected. There is one relevant use case: you leave your computer unattanded and even though you locked your screen, someone can access your system through an unsecured TB3 port.
I wonder if it could be solved by automatically switching to a “reject everything” mode once you lock your screen. You lock your screen, leave your computer, and any device plugged into the TB3 port would be rejected. Once you come back and unlock your screen, it’s your responsibility what you plug in and any plugged device would be accepted.
I wonder if there is any relevant use case which would not be covered well by this policy. Any ideas?
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.
Our team maintains Firefox RPMs for Fedora and RHEL and a lot of people have been asking us to provide Firefox for Flatpak as well. I’m finally happy to announce Firefox Developer Edition for Flatpak.
We started with the Developer Edition because that’s something that is not easily available to Fedora users. Providing the standard Firefox wouldn’t bring a lot of benefit right now because it’s available very quickly after upstream releases via Fedora repositories. In the future, we’d like to add releases of the standard Firefox (nightly, stable, perhaps ESR).
Firefox DE for Flatpak is built on our internal build cluster and hosted on mojefedora.cz (mojefedora == myfedora in Czech) on OpenShift. It’s an unofficial build for testing purposes, not provided by Mozilla. We’d like to work with Mozilla, so that it can eventually be adopted by the Mozilla project and you can get Firefox flatpaks directly from the source.
Right now, Firefox DE is not sandboxed, it has full access to user’s home. In the near future, we’d like to start a devel branch in the flatpak repository where we will ship a sandboxed Firefox and experiment how well Firefox can handle sandboxing and what needs to be done to assure the expected user experience. A web browser is definitely the #1 candidate among desktop applications for sandboxing. If you’re interested in sandboxing Firefox on Linux via Flatpak, contact us (you’ll find Jan’s email on the website with installation instructions).
We’ve tested the FDE flatpak on Fedora 25, openSUSE Tumbleweed, and Ubuntu 16.10. You need flatpak 0.6.13 or newer for the installation commands to work. The repo should work with older versions as well, but there was a change in command syntax and the commands we use don’t work in older releases than 0.6.13. Fedora 25 has the newest release (0.8.0), openSUSE Tumbleweed has a new enough release (0.6.14), just for Ubuntu you’ll need to install the newest flatpak from a PPA.
GNOME Software in Fedora 25 also supports adding repos via .flatpakrepo files and installing apps via .flatpakref files, but it’s not reliable enough yet, so we only recommend you use the command line instructions. It’s just two commands (you only need the latter one on Fedora 25 with the newest flatpak).
There are also a couple of problems we haven’t quite figured out yet. In openSUSE and Ubuntu, the desktop file database is not refreshed after the installation, so the launcher doesn’t appear right away. You need to log out and log in to refresh it and make the launcher appear. In openSUSE Tumbleweed in KDE Plasma in a VM, I couldn’t start the app getting “no protocol specified, Error: cannot open display: :99.0”. We’re looking for hearing from you how it works on other distributions.
Although the repo is for testing purposes, we’re committed to updating it regularly until we announce otherwise on the website with the installation instructions. So you don’t have to worry that you’ll end up with a scratch build that will never get updated.
At last, I’d like to thank Vadim Rutkovsky who made the initial proof-of-concept Firefox build for Flatpak we built upon, and Jan Hořák who did most of the work on the current build and repo setup.
A lot of users complained that installing flatpaks was too difficult. And they were right, just look at the installation instructions on the Flatpak download page at LibreOffice.org. But that was never meant to be the final user experience.
Richard Hughes integrated Flatpak support into GNOME Software and the Red Hat desktop apps team worked with him to make sure it works well with apps we’ve already packaged for Flatpak. And this is the result. As you can see installing LibreOffice for Flatpak is now a matter of a couple of clicks with GNOME Software 3.22.2 in Fedora 25:
Flatpak allows you to generate a .flatpak bundle which includes the app and all the necessary info for installation of the app and setting up its repo for future updates. You can also create a .flatpakref file which doesn’t contain the app, but all the installation info and the app is downloaded during the installation. This format is also supported by GNOME Software now. LibreOffice offers a .flatpak bundle because it’s more similar to what users are used to from Windows and macOS.
As you can see on the video, installing .flatpak bundles is a matter of downloading the file and opening it directly with GNOME Software or double-clicking it. There is one prerequisite though. You need to have a repo of the runtime the app requires enabled which I had because I had been using the GNOME runtime for other apps already. Installation of runtimes is being streamlined as well. As a runtime provider, you can ship .flatpakrepo file which includes necessary info for setting up the repo and is as easy to install as .flatpak and .flatpakref. For Fedora Workstation we’re currently considering to enable repos of most common runtimes by default, so users would not have to deal with them at all, the required runtimes would get installed automatically with the app.
Last Thursday, we organized a regular Linux Desktop Meetup in Brno and because two major desktop environments had had their releases recently we also added a release party to celebrate them.
The meetup itself took place in the Red Hat Lab at FIT BUT (venue of GUADEC 2013) and it consisted of 4 talks. I spoke on new things in GNOME 3.22, our KDE developer Jan Grulich spoke on new things in Plasma 5.8, then Oliver Gutierrez spoke on Fleet Commander and the last talk was given by Lucie Karmova who is using Fedora as a desktop in a public organization and shared her experiences with the Linux desktop.
After the talks, we moved to the nearby Velorex restaurant to celebrate the releases. The whole event attracted around 25 visitors which is definitely above the average attendance of our meetups. Let’s see if we can get the same number of people to the meetup next month.
Last, but not least I’d like to thank the Desktop QA team of Red hat for sponsoring the food and drinks at the release party.
Yet another app is packaged for Flatpak. Jan Grulich from our team has packaged the official desktop client for Telegram (EDIT: see his blogpost).
And it was quite some task because the app is… well… wildly put together. Just see the build instructions provided by upstream. Flatpak manifests are usually fairly simple files, less complex than spec files, but this one ended up being 394 lines long.
I think such an app is an ideal target for Flatpak. There is no way that an app like this would make it to the official Fedora repositories and its authors don’t even seem to be interested in making it more possible.
Telegram client for Flatpak is also built from source. That’s not the case of most packages of this app out there. The Copr package or snap just wrap the upstream binary. With Jan’s manifest, you can build the app yourself. It also works better than the Copr package which creates its own desktop file and then the app itself creates another and you need to log in every time you start the app. It simply behaves weirdly.
If you want to try it out, Jan has created a repo:
If you still don’t have it, you also need to install the GNOME runtime (the app is using Qt, but it’s own patched version and it also uses components that are in the GNOME runtime, so it was a more sensible option):
It should create (Nightly) Telegram launcher (why nightly? because it’s built from master). And you’re good to go! Feedback is welcome. We’d like to propose it to the upstream project one day, so that they can build it themselves and ship it directly to their users with better experience than just a binary in an archive.