October 08, 2019


Andy Wingo
(wingo)

thoughts on rms and gnu

Yesterday, a collective of GNU maintainers publicly posted a statement advocating collective decision-making in the GNU project. I would like to expand on what that statement means to me and why I signed on.

For many years now, I have not considered Richard Stallman (RMS) to be the head of the GNU project. Yes, he created GNU, speaking it into existence via prophetic narrative and via code; yes, he inspired many people, myself included, to make the vision of a GNU system into a reality; and yes, he should be recognized for these things. But accomplishing difficult and important tasks for GNU in the past does not grant RMS perpetual sovereignty over GNU in the future.

ontological considerations

More on the motivations for the non serviam in a minute. But first, a meta-point: the GNU project does not exist, at least not in the sense that many people think it does. It is not a legal entity. It is not a charity. You cannot give money to the GNU project. Besides the manifesto, GNU has no by-laws or constitution or founding document.

One could describe GNU as a set of software packages that have been designated by RMS as forming part, in some way, of GNU. But this artifact-centered description does not capture movement: software does not, by itself, change the world; it lacks agency. It is the people that maintain, grow, adapt, and build the software that are the heart of the GNU project -- the maintainers of and contributors to the GNU packages. They are the GNU of whom I speak and of whom I form a part.

wasted youth

Richard Stallman describes himself as the leader of the GNU project -- the "chief GNUisance", he calls it -- but this position only exists in any real sense by consent of the people that make GNU. So what is he doing with this role? Does he deserve it? Should we consent?

To me it has been clear for many years that to a first approximation, the answer is that RMS does nothing for GNU. RMS does not write software. He does not design software, or systems. He does hold a role of accepting new projects into GNU; there, his primary criteria is not "does this make a better GNU system"; it is, rather, "does the new project meet the minimum requirements".

By itself, this seems to me to be a failure of leadership for a software project like GNU. But unfortunately when RMS's role in GNU isn't neglect, more often as not it's negative. RMS's interventions are generally conservative -- to assert authority over the workings of the GNU project, to preserve ways of operating that he sees as important. See for example the whole glibc abortion joke debacle as an example of how RMS acts, when he chooses to do so.

Which, fair enough, right? I can hear you saying it. RMS started GNU so RMS decides what it is and what it can be. But I don't accept that. GNU is about practical software freedom, not about RMS. GNU has long outgrown any individual contributor. I don't think RMS has the legitimacy to tell this group of largely volunteers what we should build or how we should organize ourselves. Or rather, he can say what he thinks, but he has no dominion over GNU; he does not have majority sweat equity in the project. If RMS actually wants the project to outlive him -- something that by his actions is not clear -- the best thing that he could do for GNU is to stop pretending to run things, to instead declare victory and retire to an emeritus role.

Note, however, that my personal perspective here is not a consensus position of the GNU project. There are many (most?) GNU developers that still consider RMS to be GNU's rightful leader. I think they are mistaken, but I do not repudiate them for this reason; we can work together while differing on this and other matters. I simply state that I, personally, do not serve RMS.

selective attrition

Though the "voluntary servitude" questions are at the heart of the recent joint statement, I think we all recognize that attempts at self-organization in GNU face a grave difficulty, even if RMS decided to retire tomorrow, in the way that GNU maintainers have selected themselves.

The great tragedy of RMS's tenure in the supposedly universalist FSF and GNU projects is that he behaves in a way that is particularly alienating to women. It doesn't take a genius to conclude that if you're personally driving away potential collaborators, that's a bad thing for the organization, and actively harmful to the organization's goals: software freedom is a cause that is explicitly for everyone.

We already know that software development in people's free time skews towards privilege: not everyone has the ability to devote many hours per week to what is for many people a hobby, and it follows of course that those that have more privilege in society will be more able to establish a position in the movement. And then on top of these limitations on contributors coming in, we additionally have this negative effect of a toxic culture pushing people out.

The result, sadly, is that a significant proportion of those that have stuck with GNU don't see any problems with RMS. The cause of software freedom has always run against the grain of capitalism so GNU people are used to being a bit contrarian, but it has also had the unfortunate effect of creating a cult of personality and a with-us-or-against-us mentality. For some, only a traitor would criticise the GNU project. It's laughable but it's a thing; I prefer to ignore these perspectives.

Finally, it must be said that there are a few GNU people for whom it's important to check if the microphone is on before making a joke about rape culture. (Incidentally, RMS had nothing to say on that issue; how useless.)

So I honestly am not sure if GNU as a whole effectively has the demos to make good decisions. Neglect and selective attrition have gravely weakened the project. But I stand by the principles and practice of software freedom, and by my fellow GNU maintainers who are unwilling to accept the status quo, and I consider attempts to reduce GNU to founder-loyalty to be mistaken and without legitimacy.

where we're at

Given this divided state regarding RMS, the only conclusion I can make is that for the foreseeable future, GNU is not likely to have a formal leadership. There will be affinity groups working in different ways. It's not ideal, but the differences are real and cannot be papered over. Perhaps in the medium term, GNU maintainers can reach enough consensus to establish a formal collective decision-making process; here's hoping.

In the meantime, as always, happy hacking, and: no gods! No masters! No chief!!!

October 08, 2019 03:34 PM

October 07, 2019


Christian Schaller
(cschalle)

GStreamer Conference 2019 (including GStreamer and PipeWire hackfests)

GStreamer Conference 2019 banner

GStreamer Conference 2019 in Lyon France


So the GStreamer Conference 2019 is approaching being held in Lyon, France between 31st October and 1st November 2019. This year is special as it marks the GStreamer projects 20th year of existence. I still remember seeing the announcement of GStreamer 0.0.9 which Erik Walthinsen sent to the GNOME announe mailing list. Back then I felt that multimedia support where one of the big gaps around the Linux operating system that needed filling (no, XAnim was nice for its time, but it was not a long term solution :) and GStreamer seemed like the perfect project to fill it. So I joined the GStreamer IRC channel determined to try to help the project succeed however I could. A little over a year later we all met for the first time at GUADEC in Copenhagen, even posing for this exciting team photo.

GStreamer Team at GUADEC Copenhagen in 2001 (we all looked slightly younger and fresher back then.)


Anyway, 20 years later there will be a talk and presentation by GStreamer co-founder Wim Taymans (wearing blue shirt and black pants in picture above) at the GStreamer Conference commemorating 20 years of GStreamer. Detailing taking the project from idealistic spare time effort to the multimedia industry juggernaut it is today.

Of course the conference is not going to be focused on the past, as there is a long line up of great talks talking about modern streaming with DASH, HDR support in GStreamer, latest developments around GStreamer and Rust, Virtual reality, Vulkan and more. Actually on the ‘and more’ topic, Wim Taymans will also do a presentation on PipeWire, the next generation audio and video server, at the GStreamer Conference this year, hopefully demoing some of the great improvements in things like our pro-audio Jack emulation support.
So if you haven’t already, make your way to the GStreamer Conference 2019 website and register for the 10th annual GStreamer Conference!

For those going be aware that there will also be a joint GStreamer fall hackfest and PipeWire hackfest in the two days following the GStreamer Conference. So be sure to sign up for those if interested. They will be co-located with participants flowing freely between the two events.

October 07, 2019 03:57 PM


Philip Withnall
(pwithnall)

A diary program for GNOME: Almanah Diary

tl;dr: I’m giving up maintaining Almanah as it no longer scratches my itch — it’s yours if you want it, but maybe it should die in favour of more modern apps like Lifeograph or Red Notebook.

Almanah Diary is a project I started many years ago for maintaining a personal diary, with encryption and tracking of the events you did that day (from your calendar). It’s been neglected for a long time — given that I no longer use it, I have no incentive to maintain it and improve it, and have only held on to maintainership for so long out of a feeling of duty.

However, having me listed as a maintainer might have been giving people the false impression that it was actually maintained. So I’m removing myself as maintainer, having just made the 0.12.0 release. Álvaro Peña is also listed as a maintainer, but hasn’t been active for over a year. The project is technically now his, but if someone else turns up wanting to work on it, I am happy to add them as a co-maintainer, especially if they are going to revitalise things.

Other diary programs exist, and while I haven’t tried them, Lifeograph and Red Notebook look like they could be much more featureful and maintained than Almanah. Perhaps it’s time for them to be blessed as GNOME apps?

That said, if you want to take over maintenance of Almanah, please be my guest. It’s been ported to Meson, but needs some UI updates and needs flatpacking and putting on flathub.

If you’re interested, please get in touch, or send a merge request through.

October 07, 2019 02:00 PM


Felipe Borges
(felipeborges)

GNOME 3.34 Release Party in Brno, Czech Republic

In September 25th we had once more a local meetup in Brno to celebrate another fantastic GNOME Release!

GNOME “Thessaloniki” 3.34 is out now and will be reaching distros in the following months. This version is the result of the work of approximately 777 contributors in the last six months. For more details, check out the release notes.

Our Brno celebrations this cycle were held in Schrott, a place with a wide variety of beers and a neat industrial decor. Dominika Vagnerova arranged delicious GNOME themed cupcakes with eatable app icons that went along pretty well with the drinks.

This was an excelent opportunity for us to sit down, relax, and chat about GNOME, Free Software, and all things that bring us together.

More photos of the event are available in our shared album, including ~exclusive~ pictures of application maintainers eating their apps’ cupcakes. :-)

Thanks everyone that showed up, special thanks to Dominika for organizing the event and Rishi for the photos. Stay tuned for 3.36!

October 07, 2019 09:40 AM

October 06, 2019


Tobias Mueller
(muelli)

Talking at ARES 2019 in Canterbury, UK

It’s conference season and I attended the International Conference on Availability, Reliability, and Security (ARES) in Canterbury, UK. (note that in the future, the link might change to something more sustainable)

A representative of the Kent University opened the event. It is the UK’s European University, he said, with 20000 students, many of them being from other countries. He attributed that to the proximity to mainland Europe. Indeed it’s only an hour away (if you don’t have to go back to London to catch a direct Eurostar rather than one that stops in, say, Ashford). The conference was fairly international, too, with 230 participants from 33 countries. As an academic conference, they care about the “acceptance rate” which, in this case, was at 20.75%. Of course, he could have mentioned any number, because it’s impossible to verify.

The opening keynote was given by Alistair MacWilson from Bletchley Park. Yeah, the same Bletchley Park which Alan Turing worked at. He talked about the importance of academia in closing the cybersecurity talent gap. He said that the deficit of people knowing anything about cybersecurity skills is 3.3M with 380k alone in Europe, but APAC being desperately short of 2.1M professionals. All that is good news for us youngsters in the business, but not so good, he said, if you rely on the security of your IT infrastructure… It’s not getting any better, he said, considering that the number of connected devices and the complexity of our infrastructure is rising. You might think, he said, that highly technical skills are required to perform cybersecurity tasks. But he mentioned that 88% of the security problems that the global 5000 companies have stem from human factors. Inadequate and unfocussed training paired with insufficient resources contribute to that problem, he said. So if you don’t get continuous training then you will fall behind with your skill-set.

There were many remarkable talks and the papers can be found online; albeit behind a paywall. But I expect SciHub to have copies and authors to be willing to share their work if you ask. Anyway, one talk I remember was about delivering Value Added Services to electric vehicle charging. They said that it is currently not very attractive for commercial operators to provide charging stations, because the margin is low. Hence, additional monetisation in form of Value Added Services (VAS) could be added. They were thinking of updating the software of the vehicle while it is charging. I am not convinced that updating the car’s firmware makes a good VAS but I’m not an economist and what do I know about the world of electric vehicles. Anyway, their proposal to add VAS to the communication protocol might be justified, but their scenario of delivering software updates over that channel seems like a lost opportunity to me. Software updates are currently the most successful approach to protecting users, so it seems warranted to have an update protocol rather than a VAS protocol for electric vehicles.

My own talk was about using the context and provenance of USB-borne events (illegal public copy) to mitigate attacks via that channel. So general idea, known to readers of my blog, is to take the state of the session into account when dealing with events stemming from USB devices. More precisely, when your session is locked, don’t automatically load drivers for a new USB device. Your session is locked, after all. You’re not using your machine and cannot insert a new device. Hence, the likelihood of someone else maliciously inserting a device is higher than when your session is unlocked. Of course, that’s only a heuristic and some will argue that they frequently plug devices into their machine when it’s locked. Fair enough. I argue that we need to be sensitive and change as little as possible to the user’s way of working with the machine to get high acceptance rates. Hence, we need to be careful when devices like keyboards are inserted. Another scenario is the new network card that has been attached via USB. It should be more suspicious to accept that nameserver that came from the new network card’s DHCP server when the system has a perfectly working network configuration (and the DHCP response did not contain a default gateway). Turns out, that those attacks are mounted right now in real-life and we have yet to find defences that we can deploy on a large scale.

It’s been a nice event, even though the sandwiches for lunch got boring after a few days ;-) I am happy to have met researchers from other areas and I hope to stay in touch.

October 06, 2019 07:55 AM


Patrick Griffis
(TingPing)

Hardening Flatpak Permissions Over Time

One of the main goals of Flatpak is to sandbox applications but a common complaint is that many packages add a lot of insecure permissions which is entirely valid. I’ll be showing an example of how over time many permissions now have secure alternatives.

For this example I’ll be using Pithos which is an application I maintain.
It is an online radio player for Pandora.com.

These are the Flatpak permissions used for the application 2 years ago:

  "finish-args": [
    "--share=ipc",
    "--share=network",
    "--socket=x11",
    "--socket=wayland",
    "--socket=pulseaudio",

    "--env=DCONF_USER_CONFIG_DIR=.config/dconf",
    "--filesystem=xdg-run/dconf",
    "--filesystem=~/.config/dconf:ro",
    "--talk-name=ca.desrt.dconf",

    "--talk-name=org.freedesktop.secrets",

    "--talk-name=org.freedesktop.Notifications",

    "--talk-name=org.gnome.SettingsDaemon",
    "--talk-name=org.mate.SettingsDaemon",

    "--talk-name=org.gnome.ScreenSaver",
    "--talk-name=org.cinnamon.ScreenSaver",
    "--talk-name=org.freedesktop.ScreenSaver",
    "--talk-name=com.canonical.Unity.Session",

    "--talk-name=org.kde.StatusNotifierWatcher",

    "--own-name=org.mpris.MediaPlayer2.pithos"
  ]

These are the possible* permissions today:

  "finish-args": [
    "--share=ipc",
    "--share=network",
    "--socket=fallback-x11",
    "--socket=wayland",
    "--socket=pulseaudio",

    "--talk-name=org.gnome.SettingsDaemon.MediaKeys",
    "--talk-name=org.mate.SettingsDaemon",

    "--talk-name=org.kde.StatusNotifierWatcher"

So lets go over each permission from the old manifest.

    "--share=ipc", "--share=network", "--socket=x11", "--socket=wayland", "--socket=pulseaudio"

These are simply required for the application to function. The application will always require network access and wayland access. We did replace x11 with fallback-x11 which means on Wayland X11 is blocked. Eventually (hopefully within a year?) pulseaudio will have a similar solution for pipewire which will be able to block things like being able to record audio.

    "--filesystem=xdg-run/dconf", "--filesystem=~/.config/dconf:ro", "--talk-name=ca.desrt.dconf"

As of GLib 2.60.6+ this permission is simply removed and settings are stored locally. This prevents applications from reading and writing settings for all software on the system.

    "--talk-name=org.freedesktop.secrets"

In an upcoming libsecret release this will also store secrets locally preventing the application from being able to read and write all stored secrets in the system keyring.

* This is not in a stable release yet.

    "--talk-name=org.freedesktop.Notifications"

A portal for notifications have been supported for a long time and the application simply uses the GNotification API and just works.

    "--talk-name=org.gnome.SettingsDaemon", "--talk-name=org.mate.SettingsDaemon"

These permissions are required for GNOME (and forks of GNOME like MATE) to bind media keys. Granting talk access to everything the settings daemon can do is not ideal and lets the application mess with system wide settings. Years ago gnome-settings-daemon improved this by splitting the features into their own namespaces so you only need to expose org.gnome.SettingsDaemon.MediaKeys which should be relatively safe to talk to. Hopefully this goes away entirely eventually with a host side solution using MPRIS.

    "--talk-name=org.gnome.ScreenSaver", "--talk-name=org.cinnamon.ScreenSaver", "--talk-name=org.freedesktop.ScreenSaver", "--talk-name=com.canonical.Unity.Session"

These were used to track the state of the screensaver to pause playback. This isn’t the most dangerous thing in the world but it does allow applications to activate the screensaver. GTK now supports the GtkApplication::screensaver-active property which lets an application monitor the state without having extra permissions.

    "--own-name=org.mpris.MediaPlayer2.pithos"

This was never a dangerous permission but as of Flatpak 1.0.4 you implicitly have permission to own org.mpris.MediaPlayer2.$app_id and subnames so that is now used for our name.

    "--talk-name=org.kde.StatusNotifierWatcher"

Lastly we do not have an alternative to this permission which still isn’t ideal and could be used to spoof other applications or exploit the host service which was likely never designed to handle untrusted data.

In conclusion there is certainly progress being made and this isn’t the only application slowly tightening permissions. There are of course still big holes where no alternative exists (most usage of --filesystem) but already today relatively secure but still well integrated flatpak’d applications can and do exist.

October 06, 2019 04:00 AM

October 05, 2019


Georges Basile Stavracas Neto
(feaneron)

Incremental present in GTK4

When working with graphical applications, there are multiple constraints and techniques applied in order to reduce the number of pixels that are being uploaded to the GPU, swapped on screen, or being manipulated. Even with highly optimized GPUs, the massive number of pixels we have to deal with (a 1080p monitor, for example, has 2 million pixels!) forces everyone to have some level of scrutiny.

When it comes to Linux compositors and clients, a widely adopted technique is regional rendering. GTK tracks which parts of the window actually changed and only redraws that part; then sends this information to the compositor so that the compositor itself can redraw only the new contents of the window.

Fortunately, the entire graphics stack is well optimized for doing that! When using EGL, we can use eglSwapBuffersWithDamageEXT(), which receives a list of rectangles representing the parts of the window that changed. Mutter also uses a similar API after compositing the desktop.

With GTK4, we have not only GL-based renderers, but Vulkan renderers as well! A few years back, GTK4 received support for Vulkan on Wayland. While developing GNOME To Do (which already uses GTK4), I recently tried the Vulkan renderer, but the result was disappointing:

It looks terribly broken!

After a lot of research, asking around various places, and trying to understand Vulkan again, finally it was fixed! I must say, it was extremely hard to figure it out. Vulkan is very interesting, but the number of details is absolutely overwhelming. However, having it rendering correctly wasn’t enough.

The Vulkan renderer in GTK4 always submits the entire window to the compositor. Sure, we’re still rendering everything in the GPU, so pixels are not being uploaded, but it’s still suboptimal. Fortunately for us, we have VK_KHR_incremental_present, which allows us to tell Vulkan which parts of the window actually changed — like eglSwapBuffersWithDamageEXT() — and optimize the rendering.

Much better, isn’t it?

This was already merged and will be part of GTK 4.

October 05, 2019 07:52 PM

October 04, 2019


Matthew Garrett
(mjg59)

Investigating the security of Lime scooters

(Note: to be clear, this vulnerability does not exist in the current version of the software on these scooters. Also, this is not the topic of my Kawaiicon talk.)

I've been looking at the security of the Lime escooters. These caught my attention because:
(1) There's a whole bunch of them outside my building, and
(2) I can see them via Bluetooth from my sofa
which, given that I'm extremely lazy, made them more attractive targets than something that would actually require me to leave my home. I did some digging. Limes run Linux and have a single running app that's responsible for scooter management. They have an internal debug port that exposes USB and which, until this happened, ran adb (as root!) over this USB. As a result, there's a fair amount of information available in various places, which made it easier to start figuring out how they work.

The obvious attack surface is Bluetooth (Limes have wifi, but only appear to use it to upload lists of nearby wifi networks, presumably for geolocation if they can't get a GPS fix). Each Lime broadcasts its name as Lime-12345678 where 12345678 is 8 digits of hex. They implement Bluetooth Low Energy and expose a custom service with various attributes. One of these attributes (0x35 on at least some of them) sends Bluetooth traffic to the application processor, which then parses it. This is where things get a little more interesting. The app has a core event loop that can take commands from multiple sources and then makes a decision about which component to dispatch them to. Each command is of the following form:

AT+type,password,time,sequence,data$

where type is one of either ATH, QRY, CMD or DBG. The password is a TOTP derived from the IMEI of the scooter, the time is simply the current date and time of day, the sequence is a monotonically increasing counter and the data is a blob of JSON. The command is terminated with a $ sign. The code is fairly agnostic about where the command came from, which means that you can send the same commands over Bluetooth as you can over the cellular network that the Limes are connected to. Since locking and unlocking is triggered by one of these commands being sent over the network, it ought to be possible to do the same by pushing a command over Bluetooth.

Unfortunately for nefarious individuals, all commands sent over Bluetooth are ignored until an authentication step is performed. The code I looked at had two ways of performing authentication - you could send an authentication token that was derived from the scooter's IMEI and the current time and some other stuff, or you could send a token that was just an HMAC of the IMEI and a static secret. Doing the latter was more appealing, both because it's simpler and because doing so flipped the scooter into manufacturing mode at which point all other command validation was also disabled (bye bye having to generate a TOTP). But how do we get the IMEI? There's actually two approaches:

1) Read it off the sticker that's on the side of the scooter (obvious, uninteresting)
2) Take advantage of how the scooter's Bluetooth name is generated

Remember the 8 digits of hex I mentioned earlier? They're generated by taking the IMEI, encrypting it using DES and a static key (0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88), discarding the first 4 bytes of the output and turning the last 4 bytes into 8 digits of hex. Since we're discarding information, there's no way to immediately reverse the process - but IMEIs for a given manufacturer are all allocated from the same range, so we can just take the entire possible IMEI space for the modem chipset Lime use, encrypt all of them and end up with a mapping of name to IMEI (it turns out this doesn't guarantee that the mapping is unique - for around 0.01%, the same name maps to two different IMEIs). So we now have enough information to generate an authentication token that we can send over Bluetooth, which disables all further authentication and enables us to send further commands to disconnect the scooter from the network (so we can't be tracked) and then unlock and enable the scooter.

(Note: these are actual crimes)

This all seemed very exciting, but then a shock twist occurred - earlier this year, Lime updated their authentication method and now there's actual asymmetric cryptography involved and you'd need to engage in rather more actual crimes to obtain the key material necessary to authenticate over Bluetooth, and all of this research becomes much less interesting other than as an example of how other companies probably shouldn't do it.

In any case, congratulations to Lime on actually implementing security!

comment count unavailable comments

October 04, 2019 06:04 AM

October 03, 2019


Molly de Blanc
(mdeblanc)

Meet Alyssa Rosenzweig and Panfrost

Hi, I’m Gaurav Agrawal, a member of the GNOME Engagement Team. I recently had the chance to interview Alyssa Rosenzweig, who is a lead developer at Panfrost project which is a free and open source driver Mali Midgard and Bifrost GPUs. Alyssa spent her summer as an intern at Collabora working on improving Panfrost’s OpenGL ES 2.0 userspace, which helps GNOME Shell work fluidly on supported Mali Hardware.

A screenshot of panfrost in action, with four open images of a Debian terminal, a logo, a jellyfish, and a computer generated landscape.

How about we kick off with a little bit of background on Panfrost?

Panfrost is a free, open-source graphics stack for Arm Mali GPUs, focused on the popular Midgard series. While these chips are popular among Android devices, they have been historical thorns in Linux’s side, due to the closed nature of the official drivers. Panfrost aims to change that, bringing the benefits of open-source to the Mali world.

What started out as a small community reverse-engineering effort has now matured into a reliable OpenGL ES 2.0 driver. Since May, I’ve been using Panfrost as my daily driver to program Panfrost. And yes, I’m answering these questions from a machine with Panfrost!

How did you get involved with the Project’s team/founded the team.

I’m passionate about spreading free software across the entire stack. To me, it’s not enough to have a free kernel; we also need a free desktop environment like GNOME. Yet it’s not enough to have just a free kernel and free desktop environment — we need free drivers and free firmware. Researching the state of free firmware for x86 systems, I realized that for long-term success, free software needs to win on Arm platforms, where free firmware at the lowest levels is still an option on systems like the Rockchip RK3399. These Rockchip systems have gained considerable mainline support, including support for the on-board video processing unit, thanks to past Collabora contributions. The future looked bright for Linux on Arm.

Unfortunately, despite these freedom wins, these Arm boards featured Mali GPUs, whose proprietary drivers prevented free software from truly taking off here. Frustrated with the GPU serving as the sole obstacle to a modern fully open source laptop, two years ago I purchased a development machine with a Mali — and the rest is history.

We will love to know, what were the issues with existing proprietary Arm drivers, which users were facing?

The issue with proprietary drivers is both practical and philosophical, and the proprietary Mali drivers are no exception. 3D acceleration is a de facto requirement of the modern system; even if a user is not interested in video games, they still need acceleration to run software using OpenGL like GNOME with full performance. Thus, philosophically, the requirement of the proprietary drivers for OpenGL support prevents normal usage of systems with Mali with free software.

Practically, the proprietary drivers pose a number of challenges for Linux users. Arm’s userspace drivers require the use of Arm’s kernel drivers. While these kernel drivers are technically open source, they are tightly coupled with the proprietary stack, which prevents their integration with the upstream “mainline” kernel. Today, most users never have to think about installing a kernel; the kernel for their hardware is part of their distribution, and distributions can easily maintain support for any hardware supported upstream. But a Linux user that needs a Mali chip cannot rely on their distribution for the kernel; the driver is maintained out-of-tree and requires a complex porting process to work against a normal upstream kernel. Far too often, users will resort to use outdated, buggy, insecure, downstream kernels, simply because they cannot use the mainline kernel if they need graphics.

Panfrost changes that. Our kernel module is designed for open-source and is included in the mainline kernel. Likewise, our userspace implementation is open-source and part of the upstream Mesa project, shared with the open-source Linux drivers for Intel, AMD, and Broadcom GPUs. Thus, with Panfrost, Linux users can install the distribution of their choice, using a modern, secure upstream kernel, while 3D graphics works out of the box.

Your project focuses on improving Panfrost’s OpenGL ES 2.0 userspace, we will like to know what this is about, and how it will benefit others?

OpenGL ES 2.0 is the core API for graphics on Arm platforms. Although newer versions of OpenGL ES exist, most software a user will encounter day-to-day can run on OpenGL ES 2.0. By focusing on this API, Panfrost is able to provide a smooth user experience where it counts.

Panfrost uses the open source Mesa implementation of OpenGL ES 2.0 to provide this experience to users. Mesa provides the OpenGL frontend via the common open-source “Gallium” API. Panfrost is a Gallium driver, thus enabling OpenGL ES 2.0 apps to run atop Mali with no proprietary components.

But Panfrost goes further! OpenGL ES is the “embedded subset” of OpenGL, the API used more commonly on Linux. The proprietary userspace drivers only support OpenGL ES, with no support for desktop OpenGL, leaving Linux users forced to specially compile software or use fickle translation layers. Fortunately, Panfrost provides a solution!

Leveraging the power of a strong open-source community via Mesa and Gallium, Panfrost is able to support OpenGL 2.1, a “common denominator” API prevalent on Linux. Other drivers have contributed to the desktop OpenGL support in Mesa and Gallium, and via this shared open-source framework, this work is shared and everyone benefits — including Panfrost users.

In practice, this support means a user running a distribution like Debian can install desktops like GNOME and have acceleration work out of the box. Whereas the proprietary userspace would leave a would-be GNOME user to fend for herself, Panfrost provides a smooth, Linux-first experience.

A young woman, against a blue background, wearing a red shirt. She has long, dark brown hair.We really want to know how are you so creative with commit messages ;) (… , :^, ./test-clear works, woo, I think I got it ?, Fix textures \0/, 🤔 , I tried…, Hmm )

Programming is mentally draining for some and physically draining for others. For me, I think programming is _emotionally_ draining. By the time my code works, sometimes you just have to let out all that emotion into the nearest text box. Sometimes that’s IRC, and sometimes that’s the commit message :-)

You went on a bug fixing adventure with GNOME, and we are excited to know what treasures you got ;)

Sometimes debugging feels like chasing my tail. But that’s not a problem — I’m not going in circles; I’m spiraling out and learning so much along the way. Sometimes that knowledge doesn’t help fix the bug, but it’s always a treasure!

GNOME offered no shortage of treasures. I installed a standard GNOME system from my distribution, which was built with OpenGL 2.1, rather than OpenGL ES 2.0. While OpenGL 2.1 has been tested with Panfrost, at the time, we had not tested it as extensively as ES 2.0, so there were all sorts of little gotcha’s I discovered. For instance, desktop OpenGL uses a slightly different texture specification mechanism, which challenged our previous texture implementation and demenaded a refactor — something I never would have noticed if I weren’t bringing up an app like GNOME.

_The_ bug, as it were, was unrelated to my research into complex topics like textures and tilers. No, in fact, it was a trivial piece of code related to the viewport descriptor. Panfrost’s implementation was correct for OpenGL ES 2.0, but again, OpenGL 2.1 offers more flexibility, so our implementation did not work there. After an agonizing bug search, a little bit of robustness improvements to the viewport code made all the difference in the world, and a moment later, I was running GNOME.

It will be really interesting to know how you all got nearer to the “Rasterization Discard” with the work “Scoreboard Implementation” on Mali’s Tiled Architecture, and we are curious to know simple explanation of these terms.

In graphics with OpenGL, the fundamental unit is a “draw”. Each draw has a pair of shaders, small programs running on the GPU. The first shader is the vertex shader, which determines where on the screen the GPU should render. The second shader is the fragment shader, which determines what colours the GPU should render. For an application like GNOME, these shaders are simple, copying the images of windows onto the screen. For a game, these shaders can be arbitrarily complex to implement fancy rendering algorithms.

Mali’s architecture subdivides draws into two parts, a vertex job (running a vertex shader) and a tiler job (setting up a fragment shader). If a simple app submits 100 draws, the driver will generate 100 vertex jobs and 100 tiler jobs. But these jobs have to run in a specific order: while all of the vertex jobs could run simultaneously, each tiler job (fragment shader) can only run once the corresponding vertex job (vertex shader) has run. Mali lets each job “depend” on other jobs, so one job can only run after its dependencies have run, much like a package in a package manager only installing once its dependencies were installed.

Originally, we hardcoded these dependencies, but this proved inflexible. This hardcoding was replaced by a high-level description of each job’s dependencies, so an automatic algorithm can compute in which order jobs need to be specified. This algorithm is knowing as “scoreboarding”.

The benefit of this automatic approach is seen in “rasterization discard”, an OpenGL feature that runs vertex shaders but does not draw anything to the screen. On Mali, that means we generate a vertex job, but we _don’t_ generate a tiler job. When we hardcoded jobs, this asymmetry was a problem, but once we implemented an automatic algorithm, this is as simple as just… not generating a tiler job. In negative lines of code, we can implement rasterization discard!

What are some popular devices that you believe can adopt your work, and through them it will benefit lots of people ?

A number of Arm-based Chromebooks use GPUs supported by Panfrost, including my personal development laptop, the Samsung Chromebook Plus. Collabora has contributed to the open-source mainline support for ChromeOS on these Chromebooks, and as a result of our open-first approach, Linux users of these Chromebooks benefit from a well-supported mainline stack. With Panfrost in the upstream kernel, these Chromebooks work on mainline _without_ sacrificing critical hardware support!

Beyond Chromebooks, based on the same high-performance RK3399 chipset, the Linux community’s own Pinebook Pro will support Panfrost. On a smaller scale, Mali chips are ubiquitous in phones and tablets; Panfrost will help the postmarketOS project achieve one of their stated goals, running the mainline kernel on phones for Linux for long-term support.

Looking back so far, what did you folks enjoyed the most with working around FOSS projects and communities?

The people! No matter where I go in the FOSS world, there’s always a friendly face. In real life, I can sometimes be timid, but online in the open source community, I can always hop into an IRC channel and strike up a chat with a developer or a fellow user. That sense of community, that despite coming from a myriad of countries, timezones, and identity backgrounds, we’re all united by a common purpose — that is a breath of fresh air from societies so focused on individual competition.

What are some inspirational lessons which you want to share with us, which will inspire newcomers contributing to FOSS ?

You can make a difference in the world of free software. It’s easy to be jaded and feel that nothing we do matters, that the tides of the world are set in stone at the whim of someone more powerful. Sometimes that can be true, but in the free software community, everyone has a chance to make a difference. If you can code, find an interesting open-source project to contribute to. If you’re multilingual, the community is always looking for translators. And even if you’re just an end-user, testing counts — if something doesn’t look right or doesn’t seem right, file a bug report and let the developers know! Or, if you’re a little extroverted and knowledgable on some software (even as a user!), try hanging out on your favourite project’s IRC channel and helping other users with the software — you never know whose day you could be improving with some patience and a little kindness. Little changes add up to making free software the beautiful place it is today, and you can help.

How can someone become involved?

Try Panfrost! Panfrost is shipping with Linux 5.2 and Mesa 19.2, arriving in popular distributions shortly. If you have a board with a compatible Mali GPU, grab the open-source stack and start testing! Maybe try your favourite desktop environment, or grab an open-source video game compatible with OpenGL 2.1, like SuperTuxKart. Give it a spin!

Edited for content and grammar. Images provided by Alyssa Rosenzweig, licensed CC-BY-SA 4.0.

October 03, 2019 01:04 PM


Matthias Clasen
(mclasen)

Some Flatpak updates

Flatpak development is not standing still. Here is a quick summary of recent and coming changes.

Better extensions

In 1.4.2, Flatpak gained the ability to use extra-data for extensions. This mechanism has been around for applications for a long time, but it is a new feature for extensions.

The 19.08 version of the freedesktop runtime uses it for its new org.freedesktop.Platform.openh264 extension, which uses the Cisco openh264 builds.

Since we are taking the ‘run everywhere’ aspect of Flatpak seriously, we’ve backported this feature from the 1.4 branch to older stable branches and released 1.2.4 and 1.0.9, so even users on very stable distributions can enjoy this new feature.

Future plans

We’ve quietly started to work on Flatpak 1.6, which should be out before the end of the year.

On the roadmap for the this release, we have

  • Support for masking updates and pinning apps.  This gives users more control about what updates Flatpak installs, without having to answer questions every time.
  • Parental controls. This optional feature uses libmalcontent to implement policies about what applications users can install and run, based on OARS content ratings.
  • Disk space checks. This is an ongoing effort to improve the accuracy of our disk- and download-size handling and to handle low disk space situations more gracefully.
  • Infrastructure for purchases/donations. This is still a bit of a research topic.

You can follow the discussion around these features, the flatpak roadmap and general flatpak topics on the flatpak mailing list.

Coming soon to portals

Things are happening on the portal side too. Some of these have already landed, and will appear in a release soon.

Secrets

We have a secrets portal now.  It works by providing a master secret to the sandboxed app, which is then used to store the applications secrets in an encrypted file inside the sandbox . The master secret is stored in the session keyring.

This is nice in that applications don’t leave their secrets behind in the keyring when they are uninstalled, and the application secrets are safe from others.

The backend for this portal will be provided by gnome-keyring and libsecret will automatically use it inside a sandbox. Backend implementations for other environments are more than welcome.

The secret portal is the work of Daiki Ueno, who gave a talk about it at Guadec.

Self-updates

The Flatpak commandline and tools like Discover or the Elementary app store do a fine job of handling updates for Flatpak apps and runtimes.

But the reality is that self-updating is a popular feature for applications, so we added an update portal that lets them do this in a clean way, with proper integration in the Flatpak machinery.

Backgrounds 1

The background portal monitors applications that are running in the background (without open windows). It gives apps a way to request permission to run in the background, and it notifies users when apps are trying to do so sneakily without permission. The portal also lets applications request to be started automatically when the user logs in.

To implement this, the portal needs information from the compositor about open windows, and which applications they belong to. Currently, this is implemented for gnome-shell, other backends are more than welcome.

Window sharing

The screencast portal now lets you select individual windows, in addition to screens, if the application asks for this.

For now, the portal identifies windows by the application icon and window title. We are looking to improve this by using thumbnails.

Backgrounds 2

We will add a small bit of desktop integration with a portal for setting desktop wallpapers.

A portal library

In the ideal case, portal functionality is used transparently by existing desktop libraries without the need for apps to do anything special. Examples for this are GtkFileChooserNative using the file chooser portal, or libsecret using the new secret portal.

But for some portals, there is no natural library api, and in these cases, doing the portal interaction with D-Bus calls can be a bit cumbersome.

Therefore, we are working on a libportal library that will provide GIO-style async apis for portal requests.

Open for contribution

If you want to get involved with Flatpak development, or are just curious, check out the flatpak project on github, chime in on the Flatpak mailing list, or find us on IRC in #flatpak on freenode.

October 03, 2019 11:43 AM


Nuritzi Sanchez
(nuritzi)

GUADEC 2019 | Part 1: Passing the Baton

This year, GUADEC was held in Thessaloniki, Greece from August 23rd – 28th. I had a great time at the conference and took some time to travel after, so I was able to see some of Northern Greece, in addition to hanging out with some of the best people I know while at GUADEC.

Since there’s a lot of talk about, I’ll be doing two separate posts, one about the Board meeting (in this post), and one about the conference itself (next post). 

Board Handover Meeting

I arrived in Thessaloniki a few days prior to GUADEC for the Board handover meeting. I really enjoyed my time as President and Chair of the Board, so passing the baton to the new Board was a bittersweet moment for me.

For those of you wondering, I didn’t run for the Board again this year because I won’t have as much time to dedicate to GNOME in the upcoming months. I pride myself on being a really active and proactive member of the Board, so having enough time to spend working on GNOME-related things is important to me. 

Don’t worry though, I’ll still be contributing to GNOME. For example, I’m one of the lead organizers of the Linux App Summit, and am helping with some other big initiatives, such as our Diversity and Inclusion work, and measuring impact at GNOME. 

Setting Strategic Goals

Helping architect the strategy that the GNOME Foundation is following is one of my proudest accomplishments because I think it’s the most far-reaching thing that I’m leaving behind. 

When I first started on the Board in 2016, I began questioning a lot of our budgetary categories and pushing for the Board to consider goals for the Foundation and how to use the budget as an instrument of achieving those goals. I established an annual hackfest in order to start working more strategically as a Board and to do a deep-dive on the budget. 

Flash forward, and we now have goals for the Foundation! We started these at last year’s Foundation Hackfest, and Philip Chimento and I spent time earlier this year refining them.

During the Board meeting at GUADEC, we gave our list of goals as input to our Executive Director, Neil McGovern, and he helped us turn them into something that could be adopted by the Foundation and presented during the Annual General Meeting (AGM).

Here are the Foundation’s long-term goals:

1. Sustainable Project & Foundation 

  • Sustain and increase funding levels
  • Increase number of contributors
  • Create and sustain infrastructure for Foundation Staff

2. Increased User Base

  • Foster a vibrant Linux desktop 
  • Uphold reputation as the most accessible desktop
  • Support improving the basic function of a desktop for everyone

3. Wider Awareness Through Leadership 

  • Develop better marketing and outreach tactics
  • Become an exemplary FOSS community
  • Evaluate and adopt new technologies to stay competitive with proprietary desktops

If you’d like to learn more about what these goals actually mean for the Foundation, check out Neil’s talk about GNOME’s Growth. 

It’s important to state that this is just the first step. The Foundation still needs to create KPIs, or something similar, in order to track and measure the Foundation’s progress towards the goals. 

Having publicly announced the Foundation’s goals is a move towards being a more data-driven organization and for us to be able to measure the GNOME Foundation’s impact. It marks a new stage of maturity for the GNOME Foundation, and I’m glad to have been a part of it.

Defining Board Roles

Since this GUADEC was later than other years, we held officer elections a few weeks prior to meeting in-person and had most of the transition stuff already out of the way. 

For those of you who missed it, these are the new Directors and relevant officer roles: 

  • Rob McQueen – President
  • Allan Day – Chair, Vice President
  • Carlos Soriano – Treasurer
  • Philip Chimento – Secretary
  • Federico Mena Quintero – Vice Secretary
  • Tristan Van Berkom
  • Britt Yazel

This year, the Board decided to split the Chair and President roles and adopt the gender neutral term “Chairâ€� instead of “Chairman.â€� The distinction here is that the Chair helps to run meetings, while the President has some differentiating management roles and special abilities, like signing power for the Foundation. The President is also usually the one who speaks at conferences on behalf of the Foundation, in addition to the Executive Director, although, really, any Director can do so. 

Rob and Allan will work as a team to manage Neil since we found that having a duo approach worked well last year when Rob and I comprised the management team. 

If you’re interested in putting names to faces, check out this year’s Annual General Meeting (AGM), where the Foundation Directors and staff were presented to the community.

Approving Committees

One of the things that the Board needs to do each year is to re-approve committees. We found this out while I was on the Board, when we were re-evaluating the Foundation’s structure and doing a deep dive into the Board’s delegated powers. So, now, we approve committees and members each year. 

In order to make sure that committees are functioning well and that they have the support they need from the Board, we decided to create liaisons to the committees last year. 

These liaisons are supposed to meet with the committee members they represent at least twice a year and try to understand any pain points that the committees may have, as well as to relate the Foundation’s goals and make sure that the committees think through ways to support those goals. 

Here’s a list of the new committee liaisons for the upcoming year:

  • Engagement – Britt Yazel
  • Membership – Tristan 
  • Code of Conduct – Federico 
  • Travel – Philip Chimento
  • Sponsorship – dissolved since we now have a member of the Foundation staff to work on fundraising for the Foundation

During the meeting, we also talked about re-evaluating the committee’s membership in order to make sure that only active members of committees have access to sensitive data. This is something that the new Board will be following up on this year. 

Handing Over Tasks

At the same time that the rest of the GNOME Project moved to using GitLab, the Board created a GitLab project in order to keep track of our open issues. This allowed us to prioritize initiatives and work more effectively on complex issues. 

Luckily, I had completed most of the tasks assigned to me, so there wasn’t much for me to hand over to new board members. 🙂

—–

That’s it for this post. Now onto the actual conference and BoF days.

October 03, 2019 05:51 AM

October 02, 2019


Daniel Espinosa
(esodan)

VDA 0.90 Beta 1 Released

Vala Data Access library has reached a 0.90 Beta 1 release.

VDA provides a set of interfaces to wraps database connection, execution of SQL commands and access to returned values of the queries. Read the previous introduction post.

This version supports:

  • First Beta version of VDA
  • Native implementation for PostgreSQL
  • GDA implementation with support for SQLite and PosgreSQL
  • Basic SqlValue implementation and conversion between values
  • Basic SQL commands parsing support for SELECT, INSERT, DELETE, UPDATE, using parameters in order to provide the values required to execute it
  • Object Oriented API for SQL commands: SELECT, INSERT, DELETE, UPDATE
  • Support for Parameters in queries using GDA declaration syntax
  • SQL command parsing use GCalc from GNOME Calculator
  • Async queries execution
  • Support to map Row’s values to GObject based classes’ properties using DataObject interface
  • Support for row modification/insert using DataObject interface
  • DataObject supports Vda.SqlValue properties, both generic or specific
  • DataObject support conversion between Vda.SqlValue values and between basic properties’ types like string, int, double, float, bool

No pre-releases was made, because the API was changed while implementing database providers and included most of the interfaces to implement for better more powerful features.

VDA return Vda.SqlValue objects when you access a Table’s row’s column’s value; the provider is responsible to create it when is requested, so no overhead is present for SQL queries execution.

October 02, 2019 06:48 PM


Felipe Borges
(felipeborges)

GUADEC 2019

Meeting my fellow GNOMies is something I look forward to every year. For eight years now I have traveled to participate in GUADEC and returned home with my head thinking of next year’s edition of the conference.

This year, I was busy with lots of activities, but still, I managed to chill with the friends I work with online throughout the whole year.  Putting faces into new names is also something very pleasant in these opportunities.

In the pre-registration party, I hosted a “Newcomers dinner“. Not many people could attend because of their personal travel plans, but those that participated were excited about being at the conference and getting to know so many cool people.

Besides that, it was the first GUADEC that we had a trained Code of Conduct Incident Response Team. We did an extensive training workshop with Otter Tech. Highly recommended!

Right at the first talks day, I hosted the interns’ lightning talks, that thanks to the amazing local team, are recorded and available online. The audience (and myself) were enthusiastic about hearing from the interns. After a few years of organizing these activities, I can still remember myself being an intern and giving my lightning talk back in 2012. Time flies! :-)

The quality of talks is always outstanding, so I listed below the ones I attended and recommend watching online:

  • Desktop Secrets Management for the Future by Daiki Ueno: I have lately been heavily interested in application sandboxing, so it was great catching up with Daiki’s work and ideas for our keyring story.
  • Managing GNOME Sessions with Systemd by Benjamin Berg and Iain Lane: It is being great and educative to follow their progress throughout the years on this task. The cherry on the cake is seeing this work landing and explained in Benjamin’s blog post.
  • Designing Multi-Process Application Security by Christian Hergert: Watching Christian talk is always exciting and educational. We are lucky to have such skillful developer in our project, and I definitely learned valuable lessons on application security.
  • Portals – Principles and Practice by Matthias Clasen: As I mentioned above, I have been lately interested in application sandboxing, so I couldn’t miss Matthias’ talk on Portals. It is so nice to see our application ecosystem evolving with Flatpak and its technologies.
  • GNU HEALTH: The Fight for our Rights in the Public Health System by Luis  Falcón: I personally care a lot about such social issues especially for being myself originally from the developing world, where people often don’t enjoy the same rights people in the developed world take for granted. The keynote was very well chosen.
  • Environmentally Friendly GNOME by Philip Withnall: IMPORTANT! We are running out of time to stop climate change, and I think every segment of society needs to discuss the issue. I hope to see the ideas discussed in this talk brought forward in our community.
  • Simple is Hard – Creating Beautiful App Icons by Jakub Steiner: Jimmac is so creative and talented that I can’t ever miss his talks. It is great to work with the design team on a daily basis, and this was a good opportunity to better understand their creative processes.
  • Accessibility Features for Mutter/GNOME Shell on Wayland by Oliver Fourdan: This work is very important. Oliver has made significant progress in shrinking the accessibility gap we currently have. Thanks for that!
  • Designing GNOME Mobile Apps by Tobias Bernard: Exciting work! It was great to see their progress on making GNOME apps adaptative. I hope this can make our platform even more attractive to vendors interested in building mobile OSes.
  • The Growth of GNOME by Neil McGovern: It is very reassuring listening to Neil describe the plans of growth for the GNOME Foundation.
  • Lightning Talks: It is always fun to see fellow GNOMies delivering their talk considering the lightning talks’ time constraint. :-D

During the BoF days, I conducted the Newcomers workshop, where we had various participants learning hands-on how to make their first code contribution to the GNOME project. Thanks everyone that showed up to participate and to help newcomers. I hope we can improve and repeat the workshop all over the world. GNOME.Asia will have its edition of the Newcomers workshop, so if you will be around in Gresik, don’t miss it!

In the Boxes BoF we discussed a roadmap to land some highly anticipated features such as UEFI support, Import/Export VMs, etc… Stay tuned here and also in the @BoxesGNOME Twitter account, where I have been doing outreach for our project by interacting with a part of our user base [wherever they are].

The social events were a blast. We had delicious food, great music, and passionate conversations at the Gala Dinner. The Picnic Day was fun and relaxing. The Museum BoF was enjoyable and nerdy (how I like it ;-)).

Checkout the photos!

Thanks to my employer, Red Hat, for sponsoring my trip and accommodation in the beautiful Thessaloniki!

October 02, 2019 02:07 PM

October 01, 2019


Ismael Olea
(Ismael)

The GNOME Conference

A new time and life next steps

the opensource symbol

Since the beginning of my career in 1998 I’ve been related with Linux and opensource in me or other way. From sysadmin I grow to distro making, hardware certification and finally consulting, plus some other added skills. Parallel I developed a personal career in libre software communities and got the privilege to give lots of talks particularly in Spain and Ibero-America. That was a big time. All this stopped in 2011 with the combination of the big economic crisis in Spain and a personal psychological situation. All lead me to go back from Madrid to my home city, Almería, to look for health recovering. Now, after several years here I’m ready to take a new step and reboot my career.

Not all this time has been wasted. I dedicated lots of hours to a new project which in several senses has been the inverse of the typical practices in opensource communities. Indeed, I’ve tried to apply most of them but instead in the world-wide Internet now with a 100% hyper-local focus. This mean working in the context of a medium-small city (less than 200k inhabitants) with intensive in-person meetings and Internet communications support. Not all the results has been as successful as I pretended, probably because I kept very big expectations; as Antonio Gramsci said «I’m a pessimist because of intelligence, but an optimist because of will» :-) The effort was developed in what we named HackLab Almería and some time ago I wrote a recap about my experience. To me was both an experiment and a recovering therapy.

That time worked to recover ambitions, a la Gramsci, and to bring relevant important and itinerant events to our nice city, always related with opensource. Retaking the experience of the good-old HispaLinux conferences we were able of hosting a set of extraordinary great technological conferences: from PyConES 2016 to Akademy 2017, GUADEC 2018 and LibreOffice Conference 2019. For some time I thought Almería was the first city to host these three… after I realized Brno did it before! The icing of the cake was the first conference on secure programming in Spain: SuperSEC. I consider all of this a great personal success.

Forgot to mention I enrolled in a university course too, more as a excuse to work in an area for which I have never found time: information and software methodology modeling. This materializes in my degree project, in advanced development state but not yet finished, around the ISO/IEC 29110 norm and the EPF Composer. I’m giving it a final push in the coming months.

Now I’m closing this stage to start a new one, with different priorities and goals. First one is to reboot my professional career, so I’m looking for a new job and started a B2 English certification course. I’m resuming my participation in opensource communities —I’ll attend LAS 2019 next November— and hope to contribute with small but not trivial collaborations to several communities. After all I think the most I’ve been doing all these years has been just shepherding the digital commons.

See you in your recruitment process! ;-)

PS: this is an Spanish version of this post.

October 01, 2019 10:00 PM


Benjamin Berg
(benzea)

GNOME 3.34 is now managed using systemd

If you are already using GNOME 3.34, then most likely your session is managed using systemd right now. For a long time now we were already running a systemd instance for every user, which is used to launch DBus and for DBus activated applications. So, with GNOME 3.34, we finally took the next step and moved the rest of the session over to run using systemd.

From a user’s perspective nothing should have changed and at this point I believe that most regressions have been dealt with. Neither will this change affect application developers for the time being as XDG autostart files continue to be supported and are prefered at least for the time being.

The great thing is, that this enables further improvements. There has been a lot of work to allow Xwayland to be started on demand and systemd plays a small part in that feature. Similar, we will also be able to shut down services that are only needed if specific hardware is present (e.g. smartcards). Also, using systemd it is now easy to sandbox all components which will give you an extra bit of security.

That said, there are a few changes, concepts and general information that is worth mentioning.

Slices, scopes and user sessions

On a systemd managed system each user is assigned a user-X.slice (systemd.slice(5)) and the user’s session will be run in a session-Y.scope (systemd.scope(5)). You can also see a few other user specific units on the host, including user@X.service, which is the user’s systemd instance. This is a separate systemd process for the user and it will shut down again if the user is not logged in anymore.

With the systemd move, not only DBus activated applications and services, but rather your entire session is now launched using your user’s systemd instance. This has a few side effects that may seem odd at first. For example, the previously mentioned session-Y.scope which used to contain over 200 processes is now down to a mere 4 processes. Another side effect is that it got harder to understand which session a process belongs to (this is relevant for a number of services) or that ps will not show a tty anymore.

But, we have addressed these side effects and hopefully there are no regressions at this point. Your GNOME session is still invariably bound to the session-Y.scope (e.g. using loginctl kill-session continues to work reliably). And services have been updated to understand the new regime and pick the correct session in all cases. To handle all this, new API was also added to the systemd DBus interface and further improvements may happen in this area.

Trying it out

So, if you have GNOME 3.34, you can now apply all the neat tools that systemd has manage your user’s session. Just remember to add the --user option, and things should work as expected. A good candidate for trying all this out is gsd-media-keys.

If we look at systemctl --user, we’ll find two entries:

  • gsd-media-keys.target
  • gsd-media-keys.service

Note that failed units will not show up in the list, so it is advisable to always check the log if you suspect a service failure. Unfortunately this is needed so that you can reliably log in again after a session failure.

We can control gsd-media-keys.target (not gsd-media-keys.service), so you can try stopping and starting it and you will notice that most global keybindings will stop and start working.

  • systemctl --user stop gsd-media-keys.target
  • systemctl --user start gsd-media-keys.target

We can also pull up the log messages for the service from journalctl.

  • journalctl --user -u gsd-media-keys.service

But, unfortunately, it will not log much information by default. But, knowing systemd and GLib environment variables we can run:

  • systemctl --user --runtime edit gsd-media-keys.service

and write:

  • [Service]
    Environment=G_MESSAGES_DEBUG=all

This enables debug messages when the service is restarted next. The configuration will not persist as we passed --runtime. If you now restart gsd-media-keys.target and inspect its log again, you will notice that it contains a lot more information.

Developing GNOME

If you have a development version of GNOME installed somewhere outside of your normal path (e.g. jhbuild) and use this to log in, then you may need to update your setup. In jhbuild there is an example jhbuild-session script that ensures that the correct unit files will be used. The relevant lines copy them into the user’s $XDG_RUNTIME_DIRECTORY and reload the systemd daemon.

On a final note, I would like to thank everyone who has worked on this in the past. As far as I know, the first experimentations were done by Canonical, in particular Iain Lane did a lot of work and submitted the first patches. I picked up this work and made plenty of improvements to get it over the finishing line.

If you don’t have GNOME 3.34 yet, then try it out by installing Fedora 31 beta or your favourite distribution that includes GNOME 3.34 already.

October 01, 2019 11:22 AM

September 30, 2019


Georges Basile Stavracas Neto
(feaneron)

Sprint 5: stability, stability, stability

The Sprint series comes out every 3 weeks or so. Focus will be on the apps I maintain (Calendar, To Do, and Settings), but it may also include other applications that I contribute to.

Calendar

GNOME Calendar saw a moderately busy spring, mostly focused on landing a few outstanding 3.32 merge requests (thanks Michael Catanzaro for writing and landing them!), and lots of regressions (#426, #432).

A few crashers were solved (#419, #455), and important regressions too (#383, #451). Given that the current sprint’s Calendar week is also before 3.34.1, I expect a few more inconsistencies to be ironed out, and an overall stable GNOME Calendar as a result.

To Do

I am positively surprised to see how much was achieved on GNOME To Do during the past sprint! The difference is massive; using GNOME To Do from the Nightly Flatpak is much more pleasant now. In fact, I’ve been using it for the past few weeks without any major problem!

Overall, a few nice cleanups landed (#282), To Do was adapted to the latest GTK4 API changes (#276), and a nasty crasher was uncovered (#279).

But to me, the spotlight goes to the micro annoyances that were smashed during this sprint. For example, GNOME To Do does not re-download all your task lists every time you focus the window anymore (#275). Various small problems in the Today, Next 7 Days, and All Tasks panels were fixed (#277, #278, #280, #281, #283).

I’m considering doing a GNOME To Do 3.96 alpha release during the next sprints, but the GNOME To Do Team (i.e. me and 5% of Tobias) needs to double-check if the current set of features is enough, and what would be a good way to handle the release (“closed” alpha? what kind of feedback do we want? how can we retrieve this feedback? would it be better if we have user testing sessions rather than open feedback?)

Settings

Unfortunately, this was not a productive sprint for GNOME Settings in terms of expectations. I expected to work on the most recent design updates for Settings (#296), but most of my time was spent reviewing merge requests (#622, #690). This heavily severed design & development coordination

However, in the middle of those merge requests, a few niceties landed, such as the improved Wi-Fi hotspot creating dialog (#669 – thanks Sadiq and Purism!) so it wasn’t a feature-absent cycle.

Retrospective

We are in the period of the release cycle that is between 3.34.0 and 3.34.1. Usually, this is when the majority of bugs reported by downstreams and individuals is fixed.

I tried to work on new features for Settings, but it didn’t work out as I expected. During this period, I ended up working and reviewing bugs much more than I thought it would be necessary, and the time to work on new features was severely reduced.

This is the biggest lesson learned this spring: focus on stability between the X.90 and (X+1).1 period, it’s the best time for that. New features that will already wait for the next release can wait an extra month.

September 30, 2019 11:35 PM


Lubomir Rintel
(lubko)

Open letter to Neil McGovern

Neil McGovern recently published an article entitled GNOME relationship with GNU and the FSF where he described parts of an e-mail exchange from Dr. Richard Stallman as “reprehensible” and called for him stepping down from his position at the Free Software Foundation. This eventually happened.

Mr. McGovern decided to close comments on his blog entry. I respect this decision, especially because the topic is bound to attract troll commenters and an attempt to moderate the discussion might just take too much effort. I might end up doing the same. However, I disagree with Mr. McGovern’s assessment and believe it shouldn’t remain without a response. I figured out that an open letter might be the right way to respond.

I’d like to stress that I’m, unlike Mr. McGovern, not speaking for GNOME, my colleagues, fellow hackers, my employer or anyone else but myself. Don’t cancel your GNOME Foundation membership because you think either of us is wrong. Engage in civilized discussion!

Mr. McGovern,

On your blog you wrote:

This came after the president of the FSF made some pretty reprehensible remarks saying that the “most plausible scenario is that [one of Epstein’s underage victims] presented themselves as entirely willing” while being trafficked.

I credit you for not twisting Dr. Stallman’s words and quoting them verbatim. I very much wish this was the case for the tabloid media that covered the same issue.

There’s no question that the lady in question has been subject to a terrible abuse and emotional distress. Dr. Stallman does not question that. Nor does he turn a blind eye — in the very same document as you linked to he does condemn the perpetrator.

It seems to me that Dr. Stallman has been punished by his forced resignation for the mere crime of touching a sensitive subject. This should not happen in a healthy discussion. Otherwise we’d let taboos exclude topics from discourse and we’ll all be poorer for not having them discussed.

I’m aware that Dr. Stallman has a history of making controversial remarks about topics such as necrophilia or pedophilia. Perhaps that is what you mean by claiming that “this isn’t the only incident”. I don’t know whether he’s capable of recognizing that those subjects are taboo. But precisely because of the taboo surrounding them the majority opinion has no chance but to end up getting formed without a reasonable discussion. Can you blame anyone for challenging it?

I applaud your and GNOME’s commitment to diversity and inclusion. It is also my commitment. I also do understand that sometimes there might not be a more fortunate way of dealing with those whose conduct harms others than to exclude them from the community. I’d just be somewhat happier if we grew more capable of listening and concentrated on getting the message right instead of obsessing over clumsy wording and personal quirks. We all have some.

Respectfully,
Lubomir

(Thanks to those who proof-read the letter and corrected many embarrassing mistakes, though they wish not to be named.)

September 30, 2019 08:00 AM

September 29, 2019


Colin Walters
(walters)

systemd is really well designed

One of the things I think has generally worked well about “Linux” and the ecosystem on top of it has been the variety of userspace.  There’s obviously some pointless things, but also some genuine innovation.  It works well when upstream projects are structured in a way that they can be mixed and matched.

For Fedora CoreOS we are combining two technologies; Ignition and rpm-ostree.  Previously they were used independently (Ignition with a ChomeOS style A/B updater) and rpm-ostree with the traditional Fedora-and-derivatives setup of Kickstart for bare metal, and cloud-init for clouds.

Putting the two together has been working well so far, but I’ve recently been working on support for root filesystem reprovisioning which is where the two projects intersect strongly.  This has meant a lot of time writing code in the initramfs.

And the topic of this blog is “systemd is well designed” because the design for systemd in the initramfs is very flexible and also well documented.  We’re continuing to support Ignition independent of OSTree, as well as OSTree independent of Ignition, while also having both of them work together.  Further, the projects are written in different languages; Ignition is Go, OSTree is C, we have the usual (unfortunate) mix of shell script in there, and it’s likely we’ll add some Rust soon too.

This is where systemd excels; we can plug these things together in a coordinated fashion by writing unit files with careful dependencies.  They can communicate however they want; in practice, writing files in /run is a common pattern.

Also worth noting is we’re using dracut, which is itself independent of systemd, designed to just implement the systemd boot sequence – our units plug into the “custom initrd services” section.  And it all Just Worked.  The systemd initramfs boot sequence (and the boot sequence in general) was designed long before either OSTree or Ignition were created, but it’s stood the test of time.

September 29, 2019 12:57 PM


Sam Thursfield
(ssam2)

Tracker developer experience improvements

There have been lots of blog posts since I suggested we write more blog posts. Great! I’m going to write about what I’ve done this month.

I’m excited that work started on Tracker 3.0, after we talked about it at GUADEC 2019. We merged Carlos’ enourmous branch to modernize the Tracker store database. This has broken some tests in tracker-miners, and the next step will be to track down and fix these regressions.

I’ve continued looking at the developer experience of Tracker. Recently we modernized the README.md file (as several GNOME projects have done recently). I want the README to document a simple “build and test Tracker from git” workflow, and that led into work making it simpler to run Tracker from the build tree, and also a bunch of improvements to the test suite.

The design of Tracker has always meant that it’s a pain in the ass to build and test, because to do anything useful you need to have 3 different daemons running and talking to each other over D-Bus, reading and writing data in the same location, and communicating with the CLI or an app. We had a method for running Tracker from the build tree for use by automated tests, whose code was duplicated in tracker.git and tracker-miners.git, and then we had a separate script for developers to test things manually, but you still had to install Tracker to use that one. It was a bit of a mess.

The first thing I fixed was the code duplication. Now we have a Python module named trackertestutils. We install it, so we don’t need to duplicate code between tracker.git and tracker-miners.git any more. Thanks to Marco Trevisan we also install a pkgconfig file.

Then I added a ./run-uninstalled script to tracker-miners.git. The improvement in developer experience I think is huge. Now you can do this to try out the latest Tracker code:

    git clone tracker-miners.git
    cd tracker-miners && mkdir build && cd build
    meson .. && ninja
    ./run-uninstalled --wait-for-miner=Files --wait-for-miner=Extract -- tracker index --file ~/Documents
    ./run-uninstalled -- tracker search "Hello"

The script is a small wrapper around trackertestutils, which takes care of spawning a private D-Bus daemon, collecting and filtering logs, and setting up the environment so that the Tracker cache is written to `/tmp/tracker-data`. (At the time of writing, there are some bug still and ./run-installed actually still requires you to install Tracker first.)

I also improved logging for Tracker’s functional-test suite. Since a year ago we’ve been running these tests in CI, but there have been some intermittent failures, which were hard to debug because log output from the tests was very messy. When you run a private D-Bus session, all kinds of daemons spawn and dump stuff to stdout. Now we set G_MESSAGE_PREFIXED in the environment, so the test harness can separate the messages that come from Tracker processes. It’s already allowed me to track down some of these annoying intermittent failures, and to increase the default log verbosity in CI.

Another neat thing about installing trackertestutils is that downstream projects can use it too. Rishi mentioned at GUADEC that gnome-photos has a test which starts the photos app and ends up displaying the actual photo collection of the user who is running the test. Automated tests should really be isolated from the real user data. And using trackertestutils, it’s now simple to do that: here’s a proof of concept for gnome-photos.

And I made a new tune!

September 29, 2019 10:42 AM

September 27, 2019


Jussi Pakkanen
(jpakkane)

A look into building C++ modules with a scanner

At CppCon there was a presentation on building C++ modules using a standalone dependency scanner executable provided by the compiler toolchain. The integration (as I understand it) would go something like this:

  1. The build system creates a Ninja file as usual
  2. It sets up a dependency so that every compilation job depends on a prescan step.
  3. The scanner goes through all source files (using compilation_commands.json), determines module interdependencies and writes this out to a file in a format that Ninja understands.
  4. After the scan step, Ninja will load the file and use it to execute commands in the correct order.
This seems like an interesting approach for experimentation, but unfortunately it depends on functionality that is not yet in Ninja. It is unclear if and when these would be added to Ninja, as its current maintainers are extremely conservative in adding any new code. It is quite difficult to run experiments on approaches that have neither usable code nor all the required features in various parts of the toolchain.

Can we do it regardless? Yes we can!

Enter self-modifying build system code

The basic approach is simple
  1. Write a Ninja file as usual, but make all the top level commands (or, for this test, only all) run a secret internal command.
  2. The command will do the scanning, and change the Ninja file on the fly, rewriting it to have the module dependency information.
  3. Invoke Ninja on the new file giving it a secret target name that runs the actual build.
  4. Build proceeds as usual.
The code that does this can be found in the vsmodtest branch in the main Meson repository. To run it you need to use Visual Studio's module implementation, the test project is in the modtest directory. It actually does work, but there are a ton of disclaimers:
  • incremental builds probably won't work
  • the resulting binary never finishes (it is running a job with exponential complexity)
  • it does not work on any other project than the demo one (but it should be fixable)
  • the dependencies are on object files rather than module BMI files due to a Ninja limitation
  • module dep info is not cached, all files are fully rescanned every time
  • the scanner is not reliable, it does the equivalent of dumb regex parsing
  • any and all things may break at any time and if they do you get to keep both pieces
All in all nothing even close to production ready but a fairly nice experiment for ~100 lines of Python. This is of course a hack and should not go anywhere near production, but assuming Ninja gets all the required extra functionality it probably could be made to work reliably.

Is this the way C++ module building will work?

Probably not, because there is one major use case that this approach (or indeed any content scanning approach) does not support: code generation. Scanning assumes that all source code is available at the same time but if you generate source code on the fly, this is not the case. There would need to be some mechanism of making Ninja invoke the scanner anew every time source files appear and such a mechanism does not exist as far as I know. Even if it does there is a lot of state to transfer between Ninja and the scanner to ensure both reliable and minimal dependency scans.

There are alternative approaches one can take to avoid the need for scanning completely, but they have their own downsides.

September 27, 2019 08:07 PM


Matthew Garrett
(mjg59)

Do we need to rethink what free software is?

Licensing has always been a fundamental tool in achieving free software's goals, with copyleft licenses deliberately taking advantage of copyright to ensure that all further recipients of software are in a position to exercise free software's four essential freedoms. Recently we've seen people raising two very different concerns around existing licenses and proposing new types of license as remedies, and while both are (at present) incompatible with our existing concepts of what free software is, they both raise genuine issues that the community should seriously consider.

The first is the rise in licenses that attempt to restrict business models based around providing software as a service. If users can pay Amazon to provide a hosted version of a piece of software, there's little incentive for them to pay the authors of that software. This has led to various projects adopting license terms such as the Commons Clause that effectively make it nonviable to provide such a service, forcing providers to pay for a commercial use license instead.

In general the entities pushing for these licenses are VC backed companies[1] who are themselves benefiting from free software written by volunteers that they give nothing back to, so I have very little sympathy. But it does raise a larger issue - how do we ensure that production of free software isn't just a mechanism for the transformation of unpaid labour into corporate profit? I'm fortunate enough to be paid to write free software, but many projects of immense infrastructural importance are simultaneously fundamental to multiple business models and also chronically underfunded. In an era where people are becoming increasingly vocal about wealth and power disparity, this obvious unfairness will result in people attempting to find mechanisms to impose some degree of balance - and given the degree to which copyleft licenses prevented certain abuses of the commons, it's likely that people will attempt to do so using licenses.

At the same time, people are spending more time considering some of the other ethical outcomes of free software. Copyleft ensures that you can share your code with your neighbour without your neighbour being able to deny the same freedom to others, but it does nothing to prevent your neighbour using your code to deny other fundamental, non-software, freedoms. As governments make more and more use of technology to perform acts of mass surveillance, detention, and even genocide, software authors may feel legitimately appalled at the idea that they are helping enable this by allowing their software to be used for any purpose. The JSON license includes a requirement that "The Software shall be used for Good, not Evil", but the lack of any meaningful clarity around what "Good" and "Evil" actually mean makes it hard to determine whether it achieved its aims.

The definition of free software includes the assertion that it must be possible to use the software for any purpose. But if it is possible to use software in such a way that others lose their freedom to exercise those rights, is this really the standard we should be holding? Again, it's unsurprising that people will attempt to solve this problem through licensing, even if in doing so they no longer meet the current definition of free software.

I don't have solutions for these problems, and I don't know for sure that it's possible to solve them without causing more harm than good in the process. But in the absence of these issues being discussed within the free software community, we risk free software being splintered - on one side, with companies imposing increasingly draconian licensing terms in an attempt to prop up their business models, and on the other side, with people deciding that protecting people's freedom to life, liberty and the pursuit of happiness is more important than protecting their freedom to use software to deny those freedoms to others.

As stewards of the free software definition, the Free Software Foundation should be taking the lead in ensuring that these issues are discussed. The priority of the board right now should be to restructure itself to ensure that it can legitimately claim to represent the community and play the leadership role it's been failing to in recent years, otherwise the opportunity will be lost and much of the activist energy that underpins free software will be spent elsewhere.

If free software is going to maintain relevance, it needs to continue to explain how it interacts with contemporary social issues. If any organisation is going to claim to lead the community, it needs to be doing that.

[1] Plus one VC firm itself - Bain Capital, an investment firm notorious for investing in companies, extracting as much value as possible and then allowing the companies to go bankrupt

comment count unavailable comments

September 27, 2019 05:47 PM

September 26, 2019


Umang Jain
(uajain)

Updating Featured apps without the need of an upgrade

This is a quick note to demonstrate how a distribution can update it’s list of “Featured” apps without pushing a new OS upgrade to its users. It’s quite beneficial to have such a functionality in gnome-software so that the list of “Featured” applications can be updated frequently, making overall user experience a further more dynamic. Let’s go shopping!

I will be focusing this post on updating the featured apps’ banner carousel that appears on the landing page of gnome-software. It displays various apps that are meant to be featured. The metadata for which apps are being featured lives in gnome-software.git tree; that means you can only update this list on gnome-software’s new release vis-a-vis a new OS release in cases of immutable OSes.

Markdowm Image

BUT!

There is also a functionality in gnome-software that lets you do this via external-appstream plugin. The external-appstream plugin helps to specify some extra-metadata for apps that is not included in the upstream appdata. Hence, distributions can decide their own subset of metadata they desire, which will append to existing appdata for an app in gnome-software. This can be “Feature this app” or even something like adding new set of <categories> to an app.

You will need:

  • An appstream file specifying desired metadata for apps.
  • A remote URL location which hosts this external-appstream file

Overall steps to achieve this:

  • Enable external-appstream plugin in your build system (it’s disabled by default)
  • Set external-appstream-urls org.gnome.software’s gsetting to the URL where you file is hosted

Once the setup is done, you should see gnome-software will fetch the external-appstream file for you and write to /var/cache/app-info/xmls/ directory(location is defined by the external-appstream plugin). The next run of gnome-software will also include all the additional metadata coming from the external-appstream (it might require to drop all the caches, typically at ~/.cache/gnome-software).

Short tutorial:

Let’s delete the /usr/share/app-info/xmls/org.gnome.Software.Featured.xml file which is the list of featured apps coming from gnome-software’s source tree. This is just to ensure that GNOME Software doesn’t pick up any featured apps from there for this tutorial. GNOME Software will fallback to one app-banner carousel which is embedded into it’s source code. This is probably done to avoid a hollow banner window on the landing page at all costs. In this case, the fallback featured app is GNOME Builder.

Prepare an external appstream file. For featuring a app in banner carousel, the app’s metadata should have GnomeSoftware::FeatureTile-css. This metadata is what we will provide to the app via external-appstream make it as a “Featured” entry. For demo purposes, I selected the Polari app and I will use a GNOME Logo SVG for it’s background.

<?xml version="1.0" encoding="UTF-8"?>
<components version="0.8">
    <component type="desktop" merge="append">
    <id>org.gnome.Polari.desktop</id>
    <metadata>
      <value key="GnomeSoftware::FeatureTile-css">border-color: #4e9a06;
text-shadow: 0 2px #418e64;
color: #a8c74f;
outline-offset: 0;
outline-color: alpha(#a8c74f, 0.75);
outline-style: dashed;
outline-offset: 2px;
background:
 url('https://people.gnome.org/~engagement/logos/GnomeLogoHorizontal.svg', #43a570;
</value>
    </metadata>
  </component>
</components>

(For brevity, formatting aspects of banner design are out of scope for this post. GNOME Software banners are be updated live using Banner Viewer.)

This external-appstream is hosted here.

Setting external-appstream-urls gsetting to this url on my system:

$ gsettings set org.gnome.software external-appstream-urls "['https://gist.githubusercontent.com/uajain/4d9b7ab373591b97357716c2425a07e5/raw/fa14e7e227aa165bee15be7c1940520a8f1b62e5/org.gnome.software.featured_demo.xml']"

Restarting GNOME Software and Voila!

Markdowm Image

External appstream is not limited to featuring apps. It can do much more like specifying categories and category-featured apps. EndlessOS uses this feature heavily in order to keep the list of featured apps fresh and crisp. Take a look at EndlessOS’s external-appstream file.

Markdowm Image

September 26, 2019 07:30 PM

September 25, 2019


Allan Day
(aday)

Towards a UX Strategy for GNOME (Part 4)

This post is part of my blog series on GNOME UX strategy. The other parts in the series covered background research and analysis for the strategy, then outlined some high-level goals and principles, followed by an outline of recent design work which fits within the strategy. This can all be thought of as answering “what” and “why” questions: what should GNOME be doing, and why?

In this, the final post in the series, I’m turning to the question of “how”: how can the GNOME project can deliver all this? For me, this how question is just as important as the what and the why. Having an effective strategy means nothing if we can’t successfully deliver it.

This post is primarily about design and development process. I’m going to draw on my experiences working on the GNOME project, as well as methodologies from the wider software industry, and recent experiments that have taken place in the GNOME project. Agile is clearly present, but it’s just one element, and has necessarily been adapted to an upstream, open source context.

While these reflections on development process are an important part of the strategy I’m laying out, they hopefully have more general relevance to our work in the GNOME project and beyond.

The process matters

The naive view is that software quality is primarily determined by the character and skills of the individuals who have worked on that software. While these individual capabilities are undoubtedly important, they are only one part of the story. Indeed, I would argue that the design and development process is just as important as the skillset of those doing the work.

One reason for this is that UX work is never a solitary endeavour – it involves multiple people with different specialisms. How we work together is critical to success, because each of those specialisms don’t just need to be aligned, but also need to feed into one another.

In my time working on GNOME, I’ve been involved in some really successful UX initiatives, where we’ve delivered new features or updated versions of our software, in a way that has pleased and even delighted our users. I’ve also worked on initiatives that haven’t been successful. I’ve reflected on these, and have identified a number of recurrent issues. These include:

  • New features that have been delivered in an incomplete state
  • Implementations that have significantly deviated from the intended design and UX vision
  • Usability or design issues which have been identified post-implementation, and have been subsequently unaddressed
  • Designs whose ambitions have surpassed our engineers’ abilities to deliver them
  • Rough and ready designs that have gone on to be implemented before they have sufficiently matured
  • Designs which have been incompatible or out of alignment with the technical plumbing that they’re built on top of

I’ve previously argued that driving up UX quality is critical to the future success of the GNOME project. If we are to do this, issues like these have to be eliminated from our development practices. We can’t succeed if they occur in core development initiatives.

The good news is that all of these issues stem from the design and development process, and can therefore be avoided. This is also a real opportunity to learn from the wealth of experience that we have in the GNOME project, and develop best practice approaches.

What we need to do

There are three main things that I think we can do to improve our design and development processes.

1. Embrace iteration

A great man once taught me that design is all about iteration. He wasn’t wrong: designs that have passed through a lot of revisions are usually superior to those that haven’t. The same is true for software development.

Many of the issues that I identified above are a result of a failure to incorporate iteration into the development process. Iteration is key to eliminating bugs, but it is often also critical to ironing out larger design issues. Despite all our expertise and experience, it is impossible to anticipate every potential UX issue, or fully understand how a design will perform in practice. We therefore have to assume that many implemented features will contain issues that have to be addressed.

The first and most important step in embracing iteration is to change the way we think about the design and development process. Iteration has to be treated as being essential and non-negotiable. The time and resources that are required for iteration must be accounted for at the outset, with the first implementation being seen as just one step in the process.

If you, as a designer or a developer, don’t have the time to iterate on a piece of work, you probably shouldn’t be doing it in the first place. I’ve been guilty of this is the past, and it can be a hard habit to break. It’s so tempting to make drive-by design recommendations, or quickly implement a new feature that you’ve been wanting for ages. We must all resist that urge. High-quality software takes time and care.

The other way to embrace iteration is to build user testing and feedback into the design and development process. This isn’t hard to do, and has been successfully done in the GNOME project. For example, earlier this year, Clarissa Borges successfully ran user tests on a development snapshot of Files, which allowed us to refine design changes prior to release. Another example: right now, we are using paper prototypes to get real-world feedback on potential Settings changes. These tests can take mere hours to design and conduct, and can save weeks of developer time.

2. A closer relationship between design & development

Design and development aren’t separate domains. Designs need to reflect technical realities. Developers need to be familiar with the UX vision that they’re implementing. Designers need to be involved in the development of the underlying technologies and platforms. This requires shared understanding between designers and developers, at all stages of the process.

A good number of the issues I identified earlier in this post are what happens when that shared understanding is missing. This leads to all kinds of problems, like designers over-estimating what developers can achieve, or not fully understanding the technological constraints, or developers implementing something different from the UX vision.

It has become my firm belief that the more interconnected that design and development are, the better our software will be. A close relationship between these two specialisms prevents problems, helps shared understanding, and increases efficiency.

I’m going to describe four things that we can do to bring design and development more closely together.

First, we need to ensure high-bandwidth communication between design and development, throughout the process. This communication doesn’t have to be talking or messaging – it can be sharing of mockups, screenshots and screencasts, and testing of development code – but it does need to happen frequently.

Second, designers need to treat developer resources as a design constraint. Design work has to be speculative sometimes. However, when it comes to sitting down and implementing features or changes, it is vital to fit the design to the amount of developer time that’s available.

Third, we need to champion transparent design. Transparent designs reflect how the underlying technologies work, and don’t try to present a different picture. They are good for all the reasons that reducing technical complexity is good, plus the fact that they avoid leaky abstractions. Transparent designs sometimes expose issues with the underlying technical architecture, which can be painful, but also exerts pressure in the right place.

Fourth, designers need to get their hands dirty, and touch the code. This can take many forms, including using GTK for prototyping, editing CSS or GtkBuilder files, or making simple code changes. This is hugely beneficial! It’s vastly more efficient for designers to make simple changes themselves, rather than having to go back and forth with developers to make them on their behalf. In turn, these efficiency savings enable a higher level of precision and quality, since they allow designers to be far more specific and wide-ranging in their polish work. Having designers directly involved in development is also a fantastic way to improve the platform, since it makes us aware of how it works, and makes us even more invested in improving it.

To make this last point happen, designers need to push themselves to get involved in development (I have a rule for myself: don’t ask someone to make changes you couldn’t have a go at making yourself). However, we also need developers to make their projects designer-friendly. This means using things like CSS, GtkBuilder, and high-level languages.

3. Time-Based Coordination

The third and final thing that we can do to improve our design and development processes is to coordinate around blocks of time. Coordination for upstream projects is tricky. However, for many of the things that I’ve described above, we need to have shared expectations for how and when work will be done. It is only then that we can do things like testing of in-progress software, or have conversations about how much developer time is available for a particular initiative.

One possibility here is to organise ourselves around sprints, and Georges has spearheaded some really successful experiments in this area. It’s a simple idea: he divides his time into blocks, and gives the design team advance notice of what he will be working on and for how long. We can then ensure that he has the designs he needs. We can also ensure that those designs can be implemented in the time he has available, and even arrange testing to happen in the periods between time blocks.

It would be great if more developers embraced this approach!

Conclusion

It’s taken a while, but we’ve got to the end! If you’ve stuck with me for the entire blog series, well done, and thank you. I hope you’ve found it interesting, and maybe even useful.

For me the best outcome of this series would be if some of these ideas could be taken up more widely by the GNOME project (or other Free Software projects), and I’d love to discuss strategy or development process with other contributors.

This last post has been especially important to me, because it reflects my own developing practice and concern with successful UX delivery. I genuinely think that these techniques could revolutionise how we work, and am already seeing some major improvements through their adoption.

September 25, 2019 05:23 PM


Richard Hughes
(hughsie)

Synaptics CX Audio Support

A couple of weeks ago, Synaptics (who now own Conexant) sent me 22,000+ lines of LGPLv2+ licensed C++ that was capable of updating the firmware of all the CXxxxx audio devices that exist in various laptops and peripherals. Most of last week was spent reading the code, and refactoring it to be a CX audio plugin in fwupd. There were a few things I could do to reduce the code size considerably:

  • Use the abstractions shared with all the other plugins, e.g. SREC file format processing, data chunking and low level USB HID
  • Drop support for hardware families which are no longer supported and not likely to receive updates
  • Remove the layers of abstractions and the macros-of-macros-of-macros so common with a codebase age measured in decades
  • Use helper objects in GLib and GObject rather than having to create everything from scratch

So, after all that we got down to a 1377 line fwupd plugin which is a 16x code reduction. It’s broadly comparable in functionality to the 22,000 line code drop but only works in fwupd as a plugin rather than as a standalone updater. To add support for new hardware to the plugin all we have to do is add an entry to the quirk file, which tells us which CX family the specific USB VID/PID is using. The rest is auto-detected.

I can’t tell you the OEM or the hardware all this work is being driven by, but eagle-eyed readers will work it out :) In some cases you might see an extra device appear in fwupdmgr get-devices if you’re running the soon-to-be-released fwupd 1.3.2 and hopefully we can get firmware updates which use this new device on the LVFS some time this year.

September 25, 2019 04:02 PM


Christian Kellner
(gicmo)

GameMode improvements for GNOME 3.34 and Fedora 31

Christian Schaller wrote an excellent blog post highlighting a lot of the cool new features and improvements that ship with Fedora 31. I wanted to add to that and give an overview of new things and improvements we did for GameMode that will be in Fedora 31. First of all a quick refresher about GameMode:

GameMode is a solution to optimize performance of a GNU/Linux system for gaming. This is to improve frames-per-seconds as well as make games run smoother, i.e. avoid stuttering. Performance optimization is done by applying various global and per-game tweaks: setting the CPU governor, adjusting the I/O priority, changing the niceness of the game and setting a different kernel scheduler (SCHED_ISO). It recently gained support for setting GPU performance modes (NVIDIA and AMD) and GPU overclocking (NVIDIA). Additionally it will inhibit the screensaver and can execute custom scripts on start and end.

There were two main issues that I focused on: First it was hard to tell if GameMode was currently active and what games/programs were requesting it. The second one was to make GameMode compatible with flatpaks. Both required changes to the GameMode daemon and the API. Upstream was very quick to review and merge all the required patches and roll a release (1.4), thanks a bunch of that.

Visibility and Integration

The whole point of GameMode is to increase the performance of the system in order to have a better gaming experience. This will (almost certainty) come with increased power draw, which is not great for computers attached to the mains but can be very annoying when running on battery. In any way it would be great to have a better idea if GameMode is currently active or not. In Fedora 30 and below this was very hard without dropping to the command line and running something like systemctl status --user gamemoded. Two improvements should make the situation better:

Shell extension

The first one is a smallish Shell extension (source) that will indicate via a status icon if GameMode is currently active or not. Additionally it will display notifications every time the GameMode status changes (this can be disabled). We needed to additional D-Bus API to the daemon for this, most notably a ClientCount property (PR#129) that the extension is watching and reacting to, so it needs GameMode 1.4 to work properly.

GameMode Shell Extension - displays a notification and shows a status icon.

GameMode Shell Extension - displays a notification and shows a status icon.

Usage integration

The other improvement to visibility, that turned out to be a bit more tricky, is indicating in Usage which process is requesting GameMode. This needed another set of additional D-Bus API endpoints (PR#155, PR#161) to expose all the currently active GameMode clients on the bus. With this, the initial support in Usage was quite straight forward (PR#60) and was basically done by maintaining a list of active GameMode clients and then matching those to Usage process entries.

Usage showing a little game icon for active clients

But it turns out that Usage didn't support flatpaks properly and one of the main ways to play games is Steam, which is best used as a flatpak. After quite a bit of internal refactoring that is now also done (PR#63). Speaking of flatpak, this was the other big area that I worked on:

Flatpak Support

Games (or in general clients) are requesting GameMode via a simple D-Bus call RegisterGame(int pid) which as the sole argument has the process identifier (pid) of the process, where it naturally is expected to pass its own pid. Processes can easily discover their own pid via getpid(2). The GameMode client library that games can use for easy integration with GameMode will do exactly that, i.e. effectively calling RegisterGame(getpid()). Flatpak, being Linux application sandboxing and distribution framework, uses a pid namespaces to isolate the process ids in the flatpak from the host. That means that a process will effectively have (at least) two process ids. The one inside the flatpak and the one outside, on the host; and it itself can only see the process id inside the flatpak. That is the whole idea about isolation and sandboxing. Now if the game requests gamemode to be activated via RegisterGame(getpid()), getpid() will give it the process id from the container and the GameMode daemon will be totally confused because the same number on the host will probably not exist or refer to a different process (probably owned by a different user). This prevented e.g. the Steam flatpak to ship with GameMode support (#77).

Flatpak portal

To solve this issue, we created a new flatpak portal. Instead of talking to GameMode directly, games inside a flatpak should talk to the flatpak portal and the portal will translate the process id from the one inside the flatpak container to the one on the host. The actual translation part was actually not straight forward and deserves a future blog post, but for the curious reader I recommend reading the discussion on the pull-request (#314). We patched the upstream GameMode client library to automatically detect that it is inside a flatpak and transparently use the portal (PR #146) and the daemon to find the executable for programs inside the flatpak (PR#136).

Small application to test GameMode

GameMode Tester

While working on the flatpak integration I needed something to quickly test various aspects of the integration, the client libs and the GameMode API all inside and outside of a flatpak. For this I created a small application, GameMode Tester, which someone besides me might find useful.

Summary

Fedora started shipping GameMode with version 28, with version 30 it is included in the workstation standard install. Fedora 31 will ship with all the necessary bits and pieces: GameMode version 1.4, the Shell extension has been packaged (dnf install gnome-shell-extension-gamemode) and a Usage with GameMode integration. Happy gaming, everyone!

September 25, 2019 11:49 AM


Kalev Lember
(kalev)

Out of box H.264 and AAC support in Fedora 31 Workstation

Up until now, playing video files has been problematic in Fedora as we haven’t been able to include the necessary codecs for popular video formats. This is now changing in Fedora 31 Workstation.

We have two independent changes that landed just yesterday:

  • gstreamer1-plugins-bad-free 1.16.0-4.fc31 adds support for AAC, which is the audio format used in most .mp4 videos
  • gstreamer1-plugin-openh264 2.0.0 package adds support for main/high H.264 profiles, which is the video format used in most .mp4 videos

These changes together enable .mp4 video playback without having to use extra third party repositories such as rpmfusion.

The openh264 codec is available through the fedora-cisco-openh264 repository that we include by default, but is set to enabled=0. You can either edit /etc/yum.repos.d/fedora-cisco-openh264.repo and edit it to enabled=1, or just rely on gnome-software automatically offering to install it and enable the repo when playing videos through Totem (note that you need to grab fixed gnome-software from updates-testing for this to work).

AAC support is enabled through the fdk-aac-free library that is included on the install media.

September 25, 2019 10:27 AM

September 23, 2019


Ismael Olea
(Ismael)

The GNOME Conference

LibreOffice Conference 2019 by numbers

LibreOffice Conference 2019 badge

LibreOffice Conference 2019 ended and… seems people really enjoyed!

Here I provide some metrics about the conference. Hopefully they’ll be useful for next years.

  • Attendees:
    • 114 registered at website before Aug 31 deadline;
    • 122 total registered at the end of the conference;
    • 102 total of phisically registered at the conference.
  • Registered countries of origin: Albania, Austria, Belgium, Bolivia, Brazil, Canada, Czech Republic, Finland, France, Germany, Hungary, India, Ireland, Italy, Japan, Korea - Republic of, Luxembourg, Poland, Portugal, Romania, Russian Federation, Slovenia, South Africa, Spain, Sweden, Switzerland, Taiwan, Turkey and United KingdomM
  • 4 days: 1 for board and community meetings and 3 for conference talks;
  • 3 tracks;
  • 68 talks, 6 GSoC presentations and 13 lightning talks;
  • 1 new individual certification;
  • 4 social events:
    • welcome party, 70 participants;
    • beach dinner party, 80 participants;
    • teathrical visit to the Alcazaba castle, 50 participants;
    • after conference city visit, 14 participants;
  • 1 hackfest, approximately 50 participants;
  • 1 conference shuttle service bus (capacity for more than 120 persons);
  • Telegram communications:
  • Conference pictures, at least:
  • Weather: two completely unexpected rainy days in Almería o_0
  • About economics, the conference ended with some superavit, which is nice. Thanks a lot to our sponsors for making this possible.

Next are a list of data tables with other more information.

Meals at university cafeteria:

    Sept. 10   Sept. 11   Sept. 12   Sept 13   Total
meals: expected 70 106 106 107 389
meals: served 54 92 97 86 329


T-shirts, ordered to our friends of FreeWear:

type   size (EU)   number
unisex S 9
unisex M 24
unisex L 36
unisex XL 15
unisex XXL 15
unisex XXXL 7
unisex - tight S 1
unisex - tight M 4
unisex - tight L 2
  total 113


The LibOCon overnight stays at Civitas were:

day   number
2019/09/05 1
2019/09/06 1
2019/09/07 5
2019/09/08 32
2019/09/09 57
2019/09/10 75
2019/09/11 77
2019/09/12 77
2019/09/13 64
2019/09/14 13
2019/09/15 3
2019/09/16 3
total overnights: 408


Twitter campaign activity at @LibOCon:

Month  tweets   impressions   profile visits   mentions   new followers
Apr 2 2321 228 9 10
May 6 8945 301 6 19
Jun 3 3063 97 3 5
Jul 3 5355 188 3 13
Aug 10 8388 208 10 2
Sept 75 51200 1246 158 (not available)
totals: 99 79272 2268 189 49


PS: I’m amazed I’ve not blogged almost nothing about the conference until now!!
PD: Added the overnight numbers at the conference hotel.

September 23, 2019 10:00 PM


Christian Schaller
(cschalle)

Fedora Workstation 31 – Whats new

We are laboring on getting Fedora Workstation 31 out the door next Month, with the beta release being made available last week. So here are some of the highlights of this upcoming release which I and the team hope you will enjoy. Many of these items I already covered in my June blogpost about Fedora Workstation 31, so if you read that one consider this one a status update as there will be some repeats.

Wayland improvements
Fedora has been leading the migration to Wayland since day one and we are not planning to stop. XWayland on demand has been an effort a lot of people contributed to this cycle. The goal is to only need XWayland for legacy X applications, not have it started and running all the time as that is a waste of system resources and also having core functionality still depend on X under Wayland makes the system more fragile. XWayland-on-demand has been a big effort with contributions from a lot of people and companies. One piece of this was the Systemd user session patches that was originally written by Iain Lane from Canonical. They had been lingering for a bit so Benjamin Berg took those patches on for this cycle and helped shepherd them over the finish line and get them merged upstream. This work wasn’t a hard requirement for Wayland-on-demand, but since it makes it a lot easier to do different things under X and Wayland which in turn makes moving towards XWayland-on-demand a little simpler to implement. That work will also allow (in future releases) us to do things like only start services under GNOME that are actually needed for your hardware, so for instance if you don’t have a bluetooth adapter in your computer there is no reason to run the bits of GNOME dealing with bluetooth. So expect further resource savings coming from this work over time.

Carlos Garnacho then spent time going through GNOME Shell removing any lingering X dependencies while Olivier Fourdan worked on cleaning up the control center. This work has mostly landed, but it is hidden behind an experimental flag (gsettings set org.gnome.mutter experimental-features "[...,'autostart-xwayland']") in Fedora 31 as we need to mature it a bit more before its ready for primetime. But we hope and expect to have it running by default in Fedora Workstation 32.

One example of something that was still requiring X that is now gone is the keyboard and mouse accessibility features in GNOME 3, which Olivier Fourdan got re-implemented and improved for this release. So if anyone out there reading this rely on the hover click accessibility feature then that is actually a lot nicer in Fedora Workstation 31. As seen in the screenshot below you now have this nice little pie animation filling up as it prepares to click which is a huge improvement over how it used to work.

Clock on hover

Click on hover in action

Another item we feel is an important part of reducing the need for XWayland is having Firefox running natively on Wayland. Martin Stransky and Jan Horak has been working tirelessly on trying to ensure Firefox works well on Wayland and in the Fedora 31 Beta it is running on Wayland by default. However there are a few bugs discovered that Martin and Jan are trying hard to fix atm so we can keep this default for the GA release, but if they miss the deadline we will ship the X backend version in F31 and then move to the Wayland version later on.

In Fedora Workstation 31 Wayland is still disabled by default if you use the Nvidia binary driver. The reason for this is due to lack of acceleration under XWayland, meaning that any application depending on GLX, like a lot of games, will just get software GL rendering with the binary NVidia driver. This isn’t something we can resolv on our own, Nvidia has to do the work since its their closed source driver, but we been discussing it regularly with them and we been told now that they are looking at the work Adam Jackson some time ago which was specifically aimed at helping them bring their X.org driver to XWayland. We don’t have a timeline yet, but it is being actively looked at and hopefully a proper date can be provided soon. I am actually running Fedora Workstation 31 using the NVidia driver myself at the moment on this laptop, and for those interested in helping dogfood this setup, in preparation for hopefully being able to enable Wayland on NVidia in Fedora Workstation 32, it is fairly simple thing to do. Under /usr/lib/udev/rules.d/ you find a file called 61-gdm.rules, just edit that file and comment out (#) the line that reads ‘DRIVER=="nvidia", RUN+="/usr/libexec/gdm-disable-wayland"‘ and you will revert to a standard setup where your standard session is a Wayland session, but with a x.org session available as a fallback. The more people that run this and report issues the better as it helps us make this rock solid before releasing it upon the world.

Atomic kernel modesetting
Jonas Ådahl has been hard at work this cycle on adding support for atomic mode setting. This work is not done, but the first parts of it has landed, but it has major long term advantages for us. I asked Jonas to provide a short description of the work and what it will eventually achieve as I don’t we articulated that anywhere else yet:

There are two ways for a display server to control the configuration and content of monitors – the old classic Kernel Mode Setting (classic KMS), and newer atomic Kernel Mode Setting (atomic KMS). The main difference between these two modes of operations is that with atomic KMS, the display server posts transactions containing configuration KMS that are then processed atomically by the kernel, while when using the classic KMS, the display server posts configurations command by command, where each monitor is configured by posting multiple commands. The benefits with atomic KMS are for example that the display server will up front know whether a configuration is valid (e.g. enough memory bandwidth), or that the display server can configure multiple aspects of the hardware atomically.

During the cycle leading up to Fedora Workstation 31 the foundations for how mutter (the window manager powering GNOME Shell) can make use of the new atomic KMS API was put in place. What was done was to introduce an internal transactional API for configuring monitors. This will eventually allow us to have much more control over how more advanced monitor features are utilized. For example it will be possible to place client windows directly in hardware overlay planes, meaning we can more often completely bypass full frame compositing when only the content of a single window changes. Another example for what this enables us to do is with color management; we will be able to do seamless switching between managing window color profiles using OpenGL and for instance gamma ramps. Yet another example of what this work opens the door for is framebuffer modifiers, which will among other things potentially result in higher performance with very high resolution monitors.
Finally an important aspect of the work done related to the new internal KMS API is that it aims to be thread safe, meaning eventually it will be possible to put KMS processing completely in a separate thread. This means that together with e.g. moving input device processing to its own thread it will be possible to get very short latency between mouse movement and the cursor
being moved on screen.

QtGNOME improvements
Jan Grulich has continued improved the QtGNOME module to make sure Qt apps integrate as well as possible into Fedora Workstation. His latest updates ensures that the theming keeps up to date with latest upstream changes in Adwaita, that we have a fully working dark theme, that accessibility theming work and that it works with Flatpaks. Below is a screenshot showing Okular running allowing you to see how the QtGNOME module affects the look and feel of Qt applications.

Firmware improvements
The LVFS firmware service keeps going from strength to strength. Richard Hughes presented on it during the Open Firmware Conference recently and was approached by a lot of vendors afterwards both thanking him and Red Hat for the effort, but also asking about getting more of their hardware supported. New vendors are coming onboard at rapid pace, for instance Acer joined recently and are planning to support more of their hardware on the LVFS going forward. It is also worth mentioning the GNOME Firmware tool that can now be downloaded from flathub and which works great on Fedora Workstation 31.

OpenH264 Greatly Improved
The much improved version of OpenH264 will be available soon for Fedora users. This new version adds support for the High and Advanced profiles of H264 which is what most videos found online or produced by your camera would be using. This means you can add H264 playback support to your Fedora Workstation without having to search online for 3rd party repositories like you have had to do up to now. We also are trying to ensure this will be usable by Firefox for video playback eventually. This was work we partnered with Endless, Cisco to hire the multimedia experts at Centricular to do, so another great example of cross company collaboration to bring improved functionality to the community.

Fedora Toolbox
Debarshi Ray has been working on many small improvements and better robustness for Fedora Toolbox going into Fedora Workstation 31. Fedora Toolbox for those not aware of it yet, is our tool to make doing development using pet containers simple and convenient, providing ease of use features on top of traditional container tools and integration with GNOME terminal and the GNOME Shell. The version shipping in F31 will be the last shell script based one as once Fedora Workstation 31 is out we will be going all in on rewritting Fedora Toolbox in Go, in preparation for future development and expansion. I strongly recommend trying it out as it will help open your eyes to the possibilities that using pet containers for development gives you. For instance you can easily set up a RHEL based pet container on your Fedora system to do development work that is mean to be deployed on a RHEL system or grab our special AI/ML development container for easy access to TensorFlow and similar tools.

Improved Classic mode
Another notable change in this release is the updates to GNOME Classic mode. GNOME Classic mode is a set of extensions to GNOME 3 that makes it look and behave a lot more like GNOME 2, which still has many fans out there. With this release we collected feedback from a group of Classic mode users and tried to improve the experience further, mostly be removing some remaining GNOME 3’isms that didn’t really fit the GNOME Classic user experience, like the overview and the hot corner. The session manager is now also easily accessible in the bottom corner. The theming also got cleaned up a little to remove the last bit of the ‘black’ GNOME 3 theming. That said I think it is important to remember that this is still GNOME 3 in the end, we are really just showcasing the power of extensions to tweak the user experience in quite fundamental ways here.

GNOME Classic improved

Improved GNOME Classic mode


Better support for non-English users
Fedora Workstation is used all over the globe, but we have not been happy about how our support for picking languages other than English has worked so far. The thing is that if you choose one or more languages at install time, things tended to just work fine, but if you wanted to add a new language afterwards it required jumping onto the command line and figuring out how to install the needed langpacks. In Fedora Workstation 31 Sundeep Anand have worked hard to improve this, so if you choose a new language in the GNOME Control center in Fedora Workstation 31, the required langpacks should be installed automatically for you.

Fleet Commander
Fleet Commander 0.14.1 is out just in time for Fedora Workstation 31. Fleet Commander is a tool for doing large scale deployments of Fedora and RHEL workstations, allowing you to set system wide profiles. So for instance if you have a GNOME Shell extension everyone in your organization or a specific team inside your organization should have enabled, you can deploy a profile with Fleet commander ensuring that extension is enabled for those users. Basically any setting within GNOME can be set using this, including network configuration options. There is also support for Firefox and LibreOffice settings in Fleet Commander. The big feature addition of 0.14.1 is that Fleet Commander now can be used with Active Directory, which means that even if your company or university use Active Directory for their user management, you can now deploy Fedora and RHEL profiles without needing FreeIPA. Fleet Commander is pretty much finished at this point, at least as far as any piece of software can ever be finished. Oliver Gutierrez Suarez is working on finishing up some last bits of Firefox support currently, but we don’t have any major Fleet Commander items on his todo list after that, so if you been waiting to test it out there are on new major features you need to wait on anymore, it is all there. If you are doing large scale linux desktop deployments I definitely recommend checking out Fleet commander. You will find that Fleet Commander definitely makes Fedora a great choice for doing large scale Linux desktop deployments.

Pipewire
We are not doing a lot of changes to Pipewire for Fedora Workstation 31. Mostly some bugfixes and minor improvements to the video infrastructure it already provides in Fedora 30 for Flatpaks and web browsers. We are planning major changes for Fedora Workstation 32 though, where we in fact plan to ship Pipewire as a tech preview for both Jack and PulseAudio users. The way it will work is that the system will still default to PulseAudio, but we will provide either a script or a UI option to switch over to Pipewire (and back again). There is also a plan to have a core set of ProAudio applications available as Flatpaks for Fedora Workstation 32 tested and verified to work perfectly with Pipewire, the current apps planned to be included are Ardour, Carla, a2jmidid, Hydrogen, Qtractor and Patroneo, but if there is interested contributors joining the effort we could have even more. Then for Fedora Workstation 33 the idea is to ship with Pipewire as the default audio handler, but with some way for users to switch back to PulseAudio if they have a need. Not unlike how the setup is currently with Wayland and X.org in Fedora. Wim Taymans will also be attending the Sonoj conference in Cologne Germany at the end of October to discuss Pipewire with many members of the Linux ProAudio community and hopefully help prepare them for a future where Fedora Workstation is the perfect home for ProAudio users and developers.

Sysprof
Christian Hergert spent some cycles this round on improving the Sysprof tool as it was becoming clear that to keep improving GNOME Shell and general desktop performance going forward we needing better data and ability to find the bottlenecks. Tools like sysprof often ends up being the unsung heroes of the system, but as we continue improving the overall GNOME performance and resource usage of the next few years the revamped sysprof tool will be a big part of that story.

Sysprof

Much improved Sysprof tool

Silverblue
A lot of the items we work on are part of our vision around Silverblue, a Linux desktop OS built on the idea of an immutable core image. We often mention the theoretic advantage that such a setup with an immutable OS brings, but actually as I upgraded from F30 and F31 beta on my RPM based laptop (I got a separate machine where I run Silverblue) I hit the exact kind of issue that Silverblue can help us and our users avoid. What happened was that after my upgrade I suddenly had no Wayland session anymore, just the fallback X.org session. After quite a bit of fault searching I discovered that the reason for this was that I had been testing Valves ACO shader compiler on F30. These packages had a newer version number than the F31 packages and thus where not overwritten as part of the upgrade. Unfortunately the EGL package that came as part of that repository did not work well on F31 and thus the Wayland session failed. Once I did a distro sync and forced all packages to be the actual F31 versions things worked correctly, but it did illustrate the challenges with systems where different parts of the core can and will get updated at different times. With a single well tested core OS image these kind of problems will not happen. That said being able to test such things as ACO is valuable and useful and luckily OStree and Silverblue do offer functionality for installing such things in a clean and non-damaging way through what is known as package layering. When you install new packages like that on using package layering they will only last until your next reboot, after you reboot your back to a clean original state system. Of course if you really want to keep some experimental packages around there are other things you can do too, like overriding, but for simple testing like I did with ACO, package layering will provide you with a simple and safe way to do that.

We realize that Silverblue is a major change in how a Linux distro is ‘supposed’ to work, so we are taking our time with it to ensure we do it right and that we have made sure applications and tools work in a way that functions well on an immutable OS. So if you are interested I do recommend that you grab the Fedora 31 Silverblue image and give it a spin, but we are still working on polishing the experience so don’t expect it to be a seamless experience at this point in time. Of course as things like Flatpaks, Fedora Toolbox and a host of smaller issues get improved upon we do believe this will be such an overall improvement over an ‘old fashioned’ linux distro that you will be asking yourself why the Linux world didn’t do this years ago.

Improved performance
A lot of work has gone into improving the general performance of GNOME 3.34. The GNOME shell team has been very active and is a great example of a large numbers of developers working together from different backgrounds. So this release features a lot of great performance work by Daniel van Vugt from Canonical and by Georges Stavracas from Endless for instance. The Red Hat team has focused on providing patch review and feedback and working on bigger long term changes and enablers, like Christian Hergerts work on Sysprof, Jonas Ådahl work on atomic mode setting and Benjamin Bergs work on systemd-user session support. All in all I think you will find that Fedora Workstation 31 with GNOME 3.34 provides a faster and smoother experience, an experience we will continue to build upon going forward as some of these long term efforts starts paying off.

Sonic Boom

Performance is better than ever

Summary
So this has been a roundup of some of the core items you should look forward to in Fedora Workstation 31. There are other items coming too in this release, like the Miracast GNOME Network Display application that Benjamin Berg has written, more Fedora Flatpaks available than ever before and more. We also have a lot of interesting items coming up in Fedora Workstation 32 like Bastien Noceras work improving low memory handling. So stay tuned.

September 23, 2019 05:45 PM


Will Thompson
(wjt)

Flatpak External Data Checker

(This post is a slightly longer version of a lightning talk I gave at GUADEC 2019.)

Many non-free applications’ binaries cannot be redistributed (particularly not in modified form), so they cannot be included directly in a Flatpak. To work around this, Flatpak supports the concept of “extra data”: files which will be downloaded and unpacked from a third-party URI when the app is installed. The URI is accompanied by a checksum and a size, to provide some hope that the data unpacked on the user’s system is the same as what the packager tested. This is used by, for example, the Dropbox Flatpak.

Of course, the Flatpak needs to be kept up to date when new versions of the app are released. At best, the old URL will still point to the same file, so at least the old version of the app will continue to be installed; in some cases, however, vendors publish new versions of the app at the same URL, which means the Flatpak cannot be installed until it is updated.

Some time ago, Joaquim Rocha started work on Flatpak External Data Checker to periodically check a Flatpak manifest and report when it needs updating. As well as just checking that a URL is reachable and has the expected size and checksum, it also knows how to follow a redirect to a stable URI for the latest version (a helpful pattern some apps use), or to find the latest package in an apt repository. I subsequently taught it how to determine the new app’s version, update the AppData file, commit the necessary changes to Git, and send a pull request (like this one).

I tried moderately hard to preserve YAML and XML comments and formatting. For JSON, I gave up trying to preserve formatting (let alone json-glib’s non-standard extensions); the output is at least deterministic, so once it’s reformatted the JSON, the diffs will be smaller in future.

At Endless, we run this for a short list of apps on Flathub (and a few on Endless’s Flatpak repo). If you want to get PRs for an app you maintain, add the necessary metadata to your Flathub application’s manifest, then send a pull request to update the list of repos we check. I hope that in the medium term we could move this over to Flathub’s build infrastructure and run it on every repo (with some way to opt out).

There are a fair few open issues – PRs, suggestions and bug reports all very welcome!

September 23, 2019 03:39 PM


Molly de Blanc
(mdeblanc)

Friends of GNOME Update — September 2019

At the end of August we wrapped up GUADEC and in September we shifted our focus to the GNOME 3.34 release.

A man in a yellow shirt using an icing bag to pipe the GNOME logo in white.

GNOME 3.34 released

On September 12, GNOME 3.34 released! Named after the location of the most recent GUADEC, Thessaloniki includes refreshed visuals, custom folders in the application overview, increased data sources in Sysprof, and multiple improvements to Builder.

We had a GUADEC!

GUADEC 2019 took place in beautiful Thessaloniki, Greece. We learned a lot in the conference sessions on the core days (videos available online); we had great strategic planning sessions and workshops during the BoF days; and had two fun day trips, with one group going to a beach and the other exploring museums in Thessaloniki. A full trip report is online. We’d like to give a thank you to the organizing team and the GUADEC sponsors.

GNOME on the Road

Federico Mena was recently at CCOSS, where he gave a keynote and ran a workshop. Molly de Blancwent to GitLab Commit and spoke about GNOME’s migration to GitLab.

Carlos Soriano, from the GNOME Board of Directors, will be at GitLab commit in London, on October 9th, discussing GNOME’s implementation of GitLab.

GNOME.Asia: Gresik, Indonesia

GNOME.Asia will be held in Gresik, Indonesia on October 11-13th. We hope you’ll make it to GNOME.Asia. There is a stellar list of speakers, including the Foundation’s own Neil McGovern and Rosanna Yuen delivering keynotes, along with Stephanus Koeswandi and Andika Triwidada. Registration is now open, so register today!

Linux Application Summit

LAS is coming up! If you’re going to be in Barcelona November 12-15th (or want to be!) please join us in growing the Linux application system. A schedule is online and registration is now open.

Endless & GNOME <3 Education

At GUADEC, we announced a collaboration with Endless: the Coding Education Challenge. We’re looking for innovative ideas to teach coding with free and open source software, with prizes up to $100,000 for winning proof of concept. More details to come!

Bylaw Updates Update

Last month we wrote about proposed changes to the bylaws. These changes 1) increase the length of terms of members of the Board of Directors and 2) change the language in the bylaws to be gender neutral. There was a vote at the Annual General Meeting, where both proposals passed.

Thank you!

Thank you for your interest in GNOME! Whether you’re using it, contributing code, writing, design, or anything else, if you’re attending events, or if you’re just enthusiastic about what we do, you’re part of the community! If you’re not already a Friend of GNOME, please consider becoming one to support the awesome work we do.

Photo courtesy of Rosanna Yuen, licensed CC-BY-SA.

September 23, 2019 11:08 AM

September 22, 2019


Ole Aamot
(oka)

GStreamer Conference 2019

I have published a lightening talk on GNOME Radio for GUADEC 2019 in Thessaloniki, Greece on August 23, 2019.

On September 10, 2019 I released GNOME Radio (gnome-radio) version 0.2.0 and I released GNOME Internet Radio Locator (gnome-internet-radio-locator) version 2.0.6 with support for Middle East Broadcasting Center in Dubai, Saudi Arabia on September 22, 2019.

On October 29, 2019 I am going via Paris on Air France to the GStreamer Conference 2019 held between October 30, 2019 and November 1, 2019 in Lyon, France to give a 5-minute lightening talk on GNOME Radio as part of my Bachelor thesis in Electrical Engineering at Oslo Metropolitan University in Oslo, Norway with the earliest delivery on June 30, 2020.

September 22, 2019 10:53 PM

September 21, 2019


Sébastien Wilmet
(swilmet)

Back to University

I stopped my master degree 6 years ago, partly because it was not compatible with open-source development. And with a bachelor degree that is worth something on the job market, I was able to apply to job offers and start working, and that’s what I did. But I now regret it, I was not satisfied by my day job, and when I see job offers requiring a bachelor degree in Belgium, most of the time I’m not interested.

So, I’ve taken the hard decision to start again studies, to finish my master degree in computer science!1) It’s a bit strange to go again to courses, studying etc. But I’m re-adapting.

In my last blog post I said “back to GNOME developmentâ€�, but this time around my studies are the priority. And to avoid stress/burnout, I try to no longer work the evenings and weekends, so it drastically limits my time that I’ll devote to GNOME.

Footnotes   [ + ]

1.   At the UCLouvain University, in the modern and pedestrian city of Louvain-la-Neuve, Belgium (link to the gastronomy page, the most important thing 🙂 ).

September 21, 2019 10:15 AM

September 20, 2019


Michael Meeks
(michael)

2019-09-20 Friday.

  • Up early to see the delightful wife & babes, a joyful time, so much to be listened to & encouraged, it's just not the same being away. Encouaging to see the pseudo-code and flow diagrams that N is writing.
  • Need to share Kendy's recommended sight reading video with the string-playing babes. Dug out a truck load of expense receipts, including a concertina of dozens of bus tickets.
  • Estimation, project planning, team call with Andras, Miklos, Kendy.

September 20, 2019 09:00 PM


Philip Withnall
(pwithnall)

Maintainer wanted: gnome-directory-thumbnailer

tl;dr: I’m giving up maintaining gnome-directory-thumbnailer as it no longer scratches my itch — it’s yours if you want it.

gnome-directory-thumbnailer is a little project I started a while ago for creating thumbnails for directories (rather than showing a plain directory icon for them in the file manager). Times change, I no longer have the itch that it was developed to scratch, and so I’m giving up maintenance of it after making the 0.1.11 release.

If you use it, or think you should use it, please care about it and take over maintenance. It needs porting to Meson, and some changes to handle working in the brave new world of sandboxed thumbnailers. It’s not a complicated code base to maintain.

If you’re interested, please get in touch, or send a merge request through.

September 20, 2019 12:43 PM


Philip Chimento
(ptomato)

The Cause and the Effect

This week Richard Stallman resigned as president of the Free Software Foundation. It is long overdue, and I am grateful to Selam G., the writer of the blog post that sparked it.

I was disappointed to read that Michael Meeks’ post Tuesday on Planet GNOME repeated the excuses I’ve seen on Twitter and Reddit about mob rule and mischaracterization. Michael is of course entitled to that opinion, and unlike most Twitter and Reddit threads I’ve seen, has expressed it thoughtfully (which is why I think I can actually achieve something by writing this in turn.) I personally believe that that opinion does not stand up under scrutiny, and I hope writing a counterpoint might give him or others in the GNOME community food for thought.

I believe that we — especially in the GNOME community where it’s a goal to hold ourselves to high standards of treating each other well — must not let ourselves fall into the trap of saying ‘Stallman was just defending a friend, out come the pitchforks, just for one email, who will they come for next’ and thereby fail to see the whole picture. If it was really just one email and not years of well-documented bad behaviour and refusal to change, we’d be having an entirely different conversation.

Many who are grateful that Stallman has finally left the FSF are nonetheless anxious or grieving in some way: for the ideal of someone who may have been a hero to us before we realized what he was like in person; for trepidation about the future of the free software movement; or even for having to watch Stallman bring himself down in an avoidable, decades-long slow-motion train wreck. This is all understandable, but we should not let grief channel itself into minimizing or excusing or working around bad behaviour, or rules-lawyering about the interpretation of Stallman’s words. These two lines from Leonard Cohen and Sharon Robinson, singing about a different kind of grief, seem oddly fitting here:

Do not choose a coward’s explanation
That hides behind the cause and the effect

I will also refer you to Thomas Bushnell’s reflections from which I’d like to emphasize this paragraph, which is a response (expressed better than I could myself) to anyone who thinks that this one event can be regarded in isolation:

RMS’s loss of MIT privileges and leadership of the FSF are the appropriate responses to a pattern of decades of poor behavior. It does not matter if they are appropriate responses to a single email thread, because they are the right thing in the total situation.

The words of Matt Blaze are also appropriate here:

We will, as always, be treated to much examination of the precise nature and mass of the last straw, with observations that it would not by itself be sufficient to cause spinal damage in camels, and is therefore utterly harmless.

This post is my personal opinion, and is not written on behalf of the GNOME Foundation, its board of directors, nor anyone else.

September 20, 2019 04:16 AM

September 19, 2019


Michael Meeks
(michael)

2019-09-19 Thursday.

  • ownCloud conference, met another set of interesting people and caught up with the new OCIS, Phoenix developers. A burger, and visited the party to bid 'bye to people. Flight home, taxi, arrived very late, relax.

September 19, 2019 09:00 PM

September 18, 2019


Michael Catanzaro
(mcatanzaro)

Epiphany Technology Preview Users: Action Required

Epiphany Technology Preview has moved from https://sdk.gnome.org to https://nightly.gnome.org. The old Epiphany Technology Preview is now end-of-life. Action is required to update. If you installed Epiphany Technology Preview prior to a couple minutes ago, uninstall it using GNOME Software and then reinstall using this new flatpakref.

Apologies for this disruption.

The main benefit to end users is that you’ll no longer need separate remotes for nightly runtimes and nightly applications, because everything is now hosted in one repo. See Abderrahim’s announcement for full details on why this transition is occurring.

September 18, 2019 02:19 PM

September 17, 2019


Allan Day
(aday)

Towards a UX Strategy for GNOME (Part 3)

This post is part of a series on UX strategy. In my previous two posts, I described what I hope are the beginnings of a UX strategy for GNOME. In the first post, I described some background research and analysis. In the second post, I introduced what I think ought to be the high-level goals and principles for the UX strategy.

Now it’s time for the fun bit! For this instalment, I’m going to go over recent work that the GNOME design team has been doing. I’m doing this for two reasons. First: I want to show off some of the great work that the design team has been doing! Second, I want to show this design work fits into the strategic approach that I’ve previously described. A key element of that plan was to prioritise on areas which will have the biggest impact, and I’m going to be using the prioritisation word a lot in what follows.

This post is intended as an overview and, as such, I’m not going to go into the designs in great detail. However, there are detailed designs behind everything I’m presenting, and there’s a list of links at the end of the post, for those who want to learn more.

Core System

In my previous post, I argued that prioritisation ought to be a key part of our UX strategy. This is intended to help us drive up quality, as well as deliver impactful improvements. One way that we can prioritise is by focusing on those parts of GNOME that people use all the time.

The obvious place to start with this is the core elements of the GNOME system: those parts of the software that make up the most basic and common interactions, like login, app launching, window switching, notifications, and so on. I believe that improving the level of polish of these basic features would go a long way to elevating the standing of the entire platform.

Unlock and Login

Login screen mockup

The design team has longstanding ambitions to update GNOME’s unlock and login experience. The designs have continued to evolve since I last blogged about them, and we continue to return to and improve them.

System unlock is a classic example of a touchstone experience. People unlock their computers all the time and, as the entry point to the system, it comes to define the overall experience. It’s the face of the system. It is therefore critical that unlock and login leave a good impression.

The new designs are intended to reduce the amount of friction that people experience when they unlock. They require users to take fewer steps and involve going through fewer transitions, so that people can get to their session faster and more seamlessly. This will in turn make the experience feel more comfortable.

The designs are also intended to be beautiful! As an emblematic part of the GNOME UX, we want unlock and login to look and feel fantastic.

Notifications

Notifications popover mockup

The design team has been systematically reviewing almost all parts of the core GNOME system, with a view to polish and refine them. Some of this work has already landed in GNOME 3.34, where you will see a collection of visual style improvements.

One area where we want to develop this work is the calendar and notifictions list. The improvements here are mostly visual – nicer layout, better typography, and so on – but there are functional improvements too. Our latest designs include a switch for do not disturb mode, for example.

There are other functional improvements that we’d like to see in subsequent iterations to the notification list, such as grouping notifications by application, and allowing notification actions to be accessed from the list.

Notifications are another great example where we can deliver clear value for our users: they’re something that users encounter all the time, and which are almost always relevant, irrespective of the apps that someone uses.

System Polish

System menu and dialog mockup

Our core system polish and refinement drive knows no bounds! We have designs for an updated system menu, which are primarily intended to resolve some long-standing discoverability issues. We’ve also systematically gone through all of the system dialogs, in order to ensure that each one is consistent and beautiful (something that is sadly lacking at the moment).

These aren’t the only parts of the core system that the design team is interested in improving. One key area that we are planning on working on in the near future is application launching. We’ve already done some experimental work in this area, and are planning on building on the drag and drop work that Georges Stavracas landed for GNOME 3.34.

Apps

The principle of prioritisation can also be applied to GNOME’s applications. The design team already spends a lot of time on the most essential applications, like Settings, Software and Files. Following the principle of prioritisation, we’ve also been taking a fresh look at some of the really basic apps that people use every day.

Two key examples of this are the document and image viewers. These are essential utilities that everyone uses. Such basic features ought to look and feel great and be firmly part of the GNOME experience. If we can’t get them right, then people won’t get a great impression.

Today our document and image viewers do their jobs reasonably well, but they lack refinement in some areas and they don’t always feel like they belong to the rest of the system. They also lack a few critical features.

Document viewer mockup
Document viewer mockup
Image viewer mockup
Image viewer mockup

This is why the design team has created updated designs for both the document and image viewers. These use the same design patterns, so they will feel like they belong together (as well as to the rest of the system). They also include some additional important features, like basic image editing (from talking to GNOME users, we know that this is a sorely missed feature).

It would be great to extend this work to look at some of the other basic, frequently-used apps, like the Text Editor and Videos.

There’s a lot of other great application design work that I could share here, but am not going to, because I do think that focusing on these core apps first makes the most strategic sense.

Development Platform

Another way that we can prioritise is by working on the app development platform. Improvements in this area make it easier for developers to create apps. They also have the potential to make every GNOME app look and behave better, and can therefore be an extremely effective way to improve the GNOME UX.

Again, this is an area where the design team has already been doing a lot of work, particularly around our icon system. This is part of the application platform, and a lot of work has recently gone into making it easier than ever to create new icons as well as consume the ones that GNOME provides out of the box. If you’re interested in this topic, I’d recommend Jakub’s GUADEC talk on the subject.

GTK widget mockup
Mockups for menus, dropdown lists, reorderable lists, and in-app notifications

Aside from the icon system, we have also been working to ensure that all the key design patterns are fully supported by the application development platform. The story here is patchy: not all of the design patterns have corresponding widgets in GTK and, in some cases it can be a lot of work to implement standard GNOME application designs. The result can also lack the quality that we’d like to see.

This is why the design team has been reviewing each of our design patterns, with a view to ensuring that each one is both great quality, and is fully supported. We want each pattern to look great, function really well, and be easy for application developers to use. So far, we have new designs for menus, dropdown lists, listboxes and in-app notifications, and there’s more to come. This initiative is ongoing, and we need help from platform and toolkit developers to drive it to completion.

What Next?

UX is more than UI: it is everything that makes up the user’s experience. As such, what I’ve presented here only represents a fraction of what would need to be included in a comprehensive UX strategy. That said, I do think that the work I’ve described above is of critical importance. It represents a programme to drive up the quality of the experience we provide, in a way that I believe would really resonate with users, because it focuses on features that people use every day, and aims to deliver tangible improvements.

As an open, upstream project, GNOME doesn’t have direct control over who works on what. However, it is able to informally influence where resources go, whether it’s by advertising priorities, encouraging contributions in particular areas, or tracking progress towards goals. If we are serious about wanting to compete in the marketplace, then doing this for the kind of UX programme that I’ve described seems like it could be an important step forward.

If there’s one thing I’d like to see come out of this series, it would be a serious conversation about how GNOME can be more strategic in its outlook and organisation.

This post marks the end of the “what” part of the series. In the next and final part, I’ll be moving onto the “how”: rather than talking about what we should be working on and what our priorities should be, I’ll set out how we ought to be working. This “how” part of the equation is critical: you can have the best strategy in the world, but still fail due to poor processes. So, in the final instalment, we’ll be discussing development process and methodology!

Further Reading

More information about the designs mentioned in this post:

September 17, 2019 02:41 PM

September 16, 2019


Neil McGovern
(nmcgovern)

GNOME relationship with GNU and the FSF

On Saturday, I wrote an email to the FSF asking them to cancel my membership. Other people who I greatly respect are doing the same. This came after the president of the FSF made some pretty reprehensible remarks saying that the “most plausible scenario is that [one of Epstein’s underage victims] presented themselves as entirely willing” while being trafficked. This isn’t the only incident, but it is the straw that broke the camel’s back.

In my capacity as the Executive Director of the GNOME Foundation, I have also written to the FSF. One of the most important parts of my role is to think of the well being of our community and the GNOME mission. One of the GNOME Foundation’s strategic goals is to be an exemplary community in terms of diversity and inclusion. I feel we can’t continue to have a formal association with the FSF or the GNU project when its main voice in the world is saying things that hurt this aim.

I greatly admire the work of FSF staffers and volunteers, but have now reached the point of concluding that the greatest service to the mission of software freedom is for Richard to step down from FSF and GNU and let others continue in his stead. Should this not happen in a timely manner, then I believe that severing the historical ties between GNOME, GNU and the FSF is the only path forward.

Edit: I’ve also cross-posted this to the GNOME discourse instance.

September 16, 2019 06:05 PM


Bin Li
(Bin Li)

GUADEC 2019

Morning at Thessaloniki

Sorry for blogging lately, better late than never. :)

Thessaloniki is very peaceful place, every morning I liked to walk along the seaside to the venue. As usual, it was a great and enjoyable GUADEC, thanks to everyone who helped to make it.

In core days I attended a lot of great talks in this year, I learned a lot of latest status of GNOME, and here are my favorite talks, “Managing GNOME Sessions with Systemd“, “State of the Shell“, “Packing up Boxes“, “Modernizing Desktop Linux Development with Containers“, “Is the Linux Desktop Really Dead?“.

I also enjoy watching Lighting talks every year. In this year Britt Yazel’s lighting talks, I knew the GUADEC App was based on Connfa, and it’s also an open source project. This App is very convenient, I could check schedule at any time.

And after the core days, I took part in “Rust BoF” by SebastianDröge , it’s a great BoF to learn the Rust and GStreamer step by step. And of course the Beach BoF, not to be missed, the amazing beach is unforgettable.

GNOME Bingo is a very good ice-break game, it gave me a lot of fun. From it I knew about the current GNOME staffs, GNOME ‘s Old Farts Club, Daiki Ueno could speak 4 languages counting c++, and so on.

I hope that we could also have GNOME.Asia App and GNOME.Asia Bingo in GNOME.Asia Summit. :)

Sunset at Thessaloniki

As usual I would like to thanks the GNOME Foundation for sponsoring my trip to Greece and making all this possible, it gave a good chance to meet old and new friends. And also thanks Canonical for conference leave.

September 16, 2019 03:12 PM

Planet GNOME

Planet GNOME is a window into the world, work and lives of GNOME hackers and contributors.

Planet GNOME is edited by Alberto Ruiz, Daniel Mustieles García and Frederic Muller. Please mail them if you have a question. If you would like your blog added to the feed, please file a bug. Make sure to read the Planet GNOME guidelines first, as it should cover most questions and as it contains detailed instructions for a blog addition.

Design by Vinicius Depizzol and Alberto Ruiz, inspired by earlier work from Jeff Waugh, Steven Garrity, Seth Nickell and Diana Fong.

Planet GNOME automatically reposts blog entries from the GNOME community. Entries on this page are owned by their authors. We do not edit, endorse or vouch for the contents of individual posts.

Updated on October 09, 2019 12:05 PM UTC. Entries are normalised to UTC time.

GNOME World Wide

GNOME communities around the world by region and language:

© The GNOME Project.

Planet GNOME. Hosted by Red Hat. Powered by Planet aggregator, Python, cron.