Canonical’s Desktop Team is hiring

edit: this post is fairly old now, and we’re well on the way with the rest of the process – if you didn’t apply yet, it’s probably worth waiting until next time

Some good news for anyone who might read this. In the Canonical desktop team we’re hiring a new Software Engineer.

More details in the job description, but if you’re looking for an opportunity that lets you:

work remotely
work on GNOME and related desktop technologies (both upstream and downstream!)
help to ship a solid Ubuntu every 6 months
work with smart people
have the opportunity to travel to, and present at, conferences and internal events

then please apply. You do not need to already be a GNOME or a Ubuntu/Debian expert to apply for this position – you’ll be given a mentor and plenty of time and support to learn the ropes.

Please feel free to contact me on IRC (Laney on all the best networks) / email (iain.lane@canonical.com) / Telegram (@lan3y) if you’re considering an application and you’d like to chat about it.

Parental controls & metered data hackfest: days 3 & 4

no nice picture this time, sorry 😭

Following on from the first two days, we in days 3 & 4 we moved on to talking about metered data. There’s some debate about whether this is the correct terminology to use, but that’s the title of the hackfest so I’ll stick with it for now.

This is a set of features to handle internet connections that have limited amounts of data in some way. For example, I’ve personally got a “MiFi” mobile hotspot that provides internet over the 4G mobile network. I bought a pay-as-you-go SIM card that provides 32 GB of data, and when that’s used up I’ll have to recharge it to be able to get online.

Philip provided a summary of the current implementation in Endless. You can also watch a YouTube video of a talk Philip gave on this topic at GUADEC in 2018. Briefly, this is an opt-in system. The system knows details of your tariff, some of which you can provide in Settings, but which may also come with the system – for example if it’s sold with a mobile network connection already provisioned. Applications ask a new component for permission to begin a large data transfer, and this component tells the application when it can begin the transfer. This could be immediately or later on.

We reviewed prior art (other OS implementations), and had some discussion about types of metered connection that you might have. This turns out to be very complex! Some providers offer plans which come with “N hours” or “N bytes” restrictions. Others exempt certain websites from metering entirely.

Another topic is logging of used data across different applications. systemd has features to log the network traffic of units, so once we have proper support for using systemd to start desktop applications, we can begin to track this and then think about how to expose it in the UI.

I was personally arguing for somehow tracking the global amount of network traffic (tx/rx_bytes), so that the shell can tell you when you are approaching / over your cap. My feeling is that this would require some integration with NetworkManager, but we would need to work out the details of what to track – total bytes isn’t good enough; you would at least need bytes per day/week/… to implement support for some types of metered connection.

Finally, if you’re reading this through Planet GNOME then you’ve already seen, but Philip created a survey that we would like to use to help guide future developments. Go fill it out please.

Parental controls & metered data hackfest: days 1 & 2

I’m currently at the Parental Controls & Metered Data hackfest at Red Hat’s office in London. A bunch of GNOME people from various companies (Canonical, Endless, elementary, and Red Hat) have gathered to work out a plan to start implementing these two features in GNOME. The first two days have been dedicated to the parental control features. This is the ability for parents to control what children can do on the computer. For example, locking down access to certain applications or websites.

Day one began with presentations of the Endless OS implementation by Philip, followed by a demonstration of the Elementary version by Cassidy. Elementary were interested in potentially expanding this feature set to include something like Digital Wellbeing – we explored the distinction between this and parental controls. It turns out that these features are relatively similar – the main differences are whether you are applying restrictions to yourself or to someone else, and whether you have the ability to lift/ignore the restrictions. We’ve started talking about the latter of these as “speed bumps”: you can always undo your own restrictions, so the interventions from the OS should be intended to nudge you towards the right behaviour.

After that we looked at some prior art (Android, iOS), and started to take the large list of potential features (in the image above) down to the ones we thought might be feasible to implement. Throughout all of this, one topic we kept coming back to was app lockdown. It’s reasonably simple to see how this could be applied to containerised 📦 apps (e.g. Snap or Flatpak), but system applications that come from a deb or an rpm are much more difficult. It would probably be possible – but still difficult – to use an LSM like AppArmor or SELinux to do this by denying execute access to the application’s binary. One obvious problem with that is that GNOME doesn’t require one of these and different distributions have made different choices here… Another tricky topic is how to implement website white/blacklisting in a robust way. We discussed using DNS (systemd-resolved?) and ip/nftables implementations, but it might turn out that the most feasible way is to use a browser extension for this.

Adam Bieńkowski joined us to discuss the technical details of Elementary’s implementation and some potential ideas for future improvements there. Thanks for that!

Today we’ve spent a fair bit of time discussing the technical details about how some of this might be implemented. Given that this is about locking down other users’ accounts, the data ought to be stored somewhere at the system level – both so the admin can query/set it, and so that the user can’t modify it. Endless’s current implementation stores this in AccountsService, which feels reasonable to us, but doesn’t extend well to storing the information required to implement activity tracking. Georges and Florian have been discussing writing a system daemon to do this, which the shell and (maybe) browser(s) would feed into.

More detailed notes taken by Philip are available here.

For the next two days we will move to talking about the second subject for this hackfest – data metering.

Have you ever commented while angry?

Have these things ever happened to you?

You submit a patch, receive a review, and argh, the reviewer is just WRONG!
You receive a bug that just makes no sense.
You (the maintainer) and a patch contributor are discussing a proposed fix, and urghhhhh, they just won’t accept your opinion!

If they have, maybe you too have lashed out with an angry comment. I know I have, and I’ve done it recently. Sorry to anyone that this has happened to.

Here’s my proposal (feature request for GitLab / irssi? 😉): if I feel heated when writing a reply, I will take 5 minutes before hitting the send button. I expect when I come back that I’ll look like the bad guy, some re-wording will happen, and the world will become a little bit less bad than it would have.

😠🔥🚒💦😌

Starting sessions with systemd

I’ve been working on this as a project for a little while now, and it’s getting to a reasonably usable state, so I thought I’d write about it in public.

What?

When you fire up your machine and see GDM’s friendly face smiling back at you, how did it get there? Clearly it was executed, but by what? The short answer is that GDM asked gnome-session to start its UI up for you.

What you see is GNOME Shell started up in a special mode, which it was asked to do by being started in an environment where GNOME_SHELL_SESSION_MODE=gdm. Behind the scenes gnome-session also started a load of session services from the given XDG autostart directories, which gives you gnome-settings-daemon amongst other things. These services can specify at what “phase” they are started at – look for X-GNOME-Autostart-Phase in /etc/xdg/autostart/*.desktop to see this – which gives a form of ordering. The session specifies a bunch of required components, and gnome-session makes sure that these are all running before the session can be considered fully started. If any of them don’t start up, the session has failed to start. Much the same thing exists for the user session too.

Hmm… this is ringing some bells…

Why?

This is quite a crude dependency mechanism. While there are some mechanisms to add extra conditions to autostart services, such as only if a certain file exists or a GSettings key is set, we now (this is not actually a new idea; the bug for this problem was filed in 2012) have a much better way of starting programs when they are needed. That’s systemd of course. If the session needs program X, and program Y needs program X, we can express this. If X isn’t ready until it claims a name on the bus, we can express that too. Restarting things on failure, executing programs at a specified time (alarms), the list goes on.

We already use this stuff for system services in fact, so why not for user ones? If starting a session is essentially executing a bunch of programs at the right time, and we have a utility to execute things in a more flexible way – why not join the two together?

A year or two ago some of us from Ubuntu sat down and worked up an implementation of this for the Unity session we were using back then. We in fact shipped 16.10 (yakkety) with this scheme in place. Since we’re now using GNOME Shell in Ubuntu – and because it’s the right thing to do anyway – it’s time to start working on getting this upstream. Credit goes to Martin Pitt and Sebastien Bacher for the work back then which we’re building on now.

Where are we now?

I’ve got a bunch of patches that I’m starting this week to push to maintainers for review. Most of these are prerequisites for transitioning sessions to be started in this way, but are not harmful when the current method is used either. They can be applied immediately. The actual switch is performed in two places – one to GDM to instruct gnome-session to launch a particular target, and the second to gnome-session to update the session definition files to launch targets instead of executing parts itself.

There is scope for further work here. My initial conversions don’t use particularly advanced features or dependencies. We could probably move more things out of the critical path and have them started on demand.

If you’re worrying about your third party session needing to be reworked for this, don’t be (yet). I’ve been quite careful so far to not require this scheme to be used, so non-GNOME sessions should continue to work as they do now. However, since gnome-session is now duplicating a lot of the same work that systemd is doing, it makes sense for us to talk about how we will go about removing this functionality in a future cycle, so that gnome-session becomes a much smaller thing.

I’ve written a wiki page with a few more technical details. This will be updated as patches are posted and merged.

Hmm, I guess this is kind of lame if you can’t try it. I should make a repository or something.