Two months ago in April ’14 I’ve been in San Francisco to meet with other FOSS developers and discuss current projects. There were several events, including the first GNOME Westcoast Summit and a systemd hackfest at Pantheon. I’ve been working on a lot of stuff lately and it was nice to talk directly to others about it. I wrote in-depth articles (on this blog) for the most interesting stories, but below is a short overview of what I focused on in SF:
- memfd: My most important project currently is memfd. We fixed several bugs and nailed down the API. It was also nice to get feedback from a lot of different projects about interesting use-cases that we didn’t think of initially. As it turns out, file-sealing is something a lot of people can make great use of.
- MiracleCast: For about half a year I worked on the first Open-Source implementation of Miracast. It’s still under development and only working Sink-side, but there are plans to make it work Client-side, too. Miracast allows to replace HDMI cables with wireless-solutions. You can connect your monitor, TV or projector via standard wifi to your desktop and use it as mirror or desktop-extension. The monitor is sink-side and MiracleCast can already provide a full Miracast stack for it. However, for the more interesting Source-side (eg., a Gnome-Desktop) I had a lot of interesting discussions with Gnome developers how to integrate it. I have some prototypes running locally, but it will definitely take a lot longer before it works properly. However, the current sink-side implementation has a latency of approx. 50ms and can run 30fps 1080p. This is already pretty impressive and on-par with proprietary solutions.
- kdbus: The new general-purpose IPC mechanism is already fleshed out, but we spent a lot of time fixing races in the code and doing some general code review. It is a very promising project and all of the criticism I’ve heard so far was rubbish. People tend to rant about moving dbus in the kernel, even though kdbus really has nearly nothing to do with dbus, except that it provides an underlying data-bus infrastructure. Seriously, the helpers used for kernel-mode-setting without including the driver-specific code is already much bigger than kdbus… and in my opinion, kdbus will make dbus a lot more efficient and appealing to new developers.
- GPU: GPU-switching, offload-GPUs and USB/wifi display-controllers are few of the many new features in the graphics subsystem. They’re mostly unsupported in any user-space, so we decided to change that. It’s all highly technical and the way how it is supposed to work is fairly obvious. Therefore, I will avoid discussing the details here. Lets just say, on-demand and live GPU-switching is something I’m making possible as part of GSoC this summer.
- User-bus: This topic sounds fairly boring and technical, but it’s not. The underlying question is: What happens if you log in multiple times as the same user on the same system? Currently, a desktop system either rejects multiple logins of the same user or treats them as separate, independent logins. The second approach has the problem that many applications cannot deal with this. Many per-user resources have to be shared (like the home-directory). Firefox, for instance, cannot run multiple times for the same user. However, no-one wants to prevent multiple logins of the same user, as it really is a nice feature. Therefore, we came up with a hybrid aproach which basically boils down to a single session shared across all logins of the same user. So if you login twice, you get the same screen for both logins sharing the same applications. The window-manager can put you on a separate virtual desktop, but the underlying session is basically the same. Now if you do the same across multiple seats, you simply merge both sessions of these seats into a single huge session with the screen mirrored across all assigned monitors. A more in-depth article will follow once the details have been figured out.
A lot of the things I worked on deal with the low-level system and are hardly visible to the average Gnome user. However, without a proper system API, there’s no Gnome and I’m very happy the Gnome Foundation is acknowledging this by sponsoring my trip to SF: Thanks a lot! And hopefully I’ll see you again next year!
I wonder if the criticism of kdbus would have occurred if it had just gone by a generic name like “kbus” or similar?
Maybe.. maybe not. In my opinion, there’ll always be people spreading non-sense so I’d have done the same and called it kdbus.
“[Treating multiple logins as separate, independent logins] has the problem that many applications cannot deal with this. Many per-user resources have to be shared (like the home-directory). Firefox, for instance, cannot run multiple times for the same user.”
Why not fix firefox so it can, instead?
“Therefore, we came up with a hybrid aproach which basically boils down to a single session shared across all logins of the same user. So if you login twice, you get the same screen for both logins sharing the same applications.”
Blargh! Imagine if that were the solution for console logins on VTs. Yeah, you can totally log in to multiple VT’s. Except both sessions are merged into a single session across all assigned seats. What you type on one screen appears on the other.
What’s that, you want to run multiple commands at once? Well, obviously that’s what “&” and job-control commands are for. No, no, you only *think* you want the ability to really log in multiple times. Trust us, this will totally be adequate for all your needs.
What do you mean, you want a “guest” account that multiple people could use simultaneously, yet independently? Um, er…., hey, look over there – Miraclecast is shiny!
If you have a single guest account, multiple such logins can kill(2) each other. They can snoop, they can ptrace and whatever.. such setups are *crazy* and totally unacceptable. If you want multiple guest logins, you’d create an ad-hoc user for each login and trash the whole state after logout. And, fortunately, this way you’d never need multiple logins of a single guest account.
Now regarding fixing firefox: Firefox already supports multiple simultaneous sessions. It’s called “multiple windows”. So imagine you have multiple logins, each of them can choose the virtual desktop which is active. Why would that be worse than two separate logins? I mean, this is much better, because it allows you both: mirroring both sessions and keeping them separate, by either selecting the same virtual desktop or different ones.
“such setups are *crazy* and totally unacceptable.”
Right. Because having a couple of friends use my multi-seat PC, at the same time, for random “Let me find this thing I saw on youtube the other day” browsing, with the “don’t be a dick” rule in play, is “crazy and totally unacceptable”. I should either create them their own accounts (along with anyone else who ever comes around and wants to do likewise), or write – what – a brand-spanking new PAM module? – to create ad-hoc accounts on an as-needed basis for such frippery. Or have them on actually the same session where they can *accidentally* affect each other’s activities. (What do you mean, Ctrl+Q will close *their* windows too! WTF? How was I supposed to know that?)
And of course, there’s the other situation which I actually have at the moment, where I leave myself logged in at my home PC, but sometimes have to ssh into it externally to do something, and some X program or other doesn’t work right because it assumes that you’ll only be logged in once, and gets confused.
I was hoping that we’d eventually fix this by doing what’s worked perfectly well for most programs for the last 40 years or so, and write apps which can be run multiple times by the same user simultaneously. *Especially* with proper multi-seat systems that are just starting to be easily supported almost OOTB with some of the new init system infrastructure that’s landing…
But instead I’ll have some “huge session” shared across my local login and my ssh’d login? Hang on, does the “screen sharing” mean you’ll try to send the whole screen to my ssh’d login like a “rooted X”, rather than just the “rootless” window for the one app that I wanted? As for “The window-manager can put you on a separate virtual desktop” – what do you mean by *the* window manager? Because I’m likely running different window managers on different computers here.
Why always assume the worst? Your conclusions are far-fetched, I seriously don’t know why you apply technical restrictions to the user-level. Furthermore, I didn’t even describe the details you base your conclusions on: why on earth do you think an ssh-login is affected by this? Even if you use X-forwarding, this is totally unrelated.
If you *want* to share a guest-account, then the guest-account is no different from a normal account. My comment about ad-hoc guest accounts was regarding the usual concept of isolated and private guest-accounts like on public terminals. If your premise is “don’t be a dick”, then feel free to share a single user-account across multiple logins as I described.
For applications, that *support* running multiple times as the same user (usually they don’t support it, but pretend to do.. I mean, hello, anyone syncing your access to ~/.config?) you still will run these multiple times. Therefore, ctrl+q will *not* kill the instance of another login. *BUT* for applications that don’t support it, this is a consequence inherent to their design. I prefer being able to run firefox in all logins over a message telling me it’s impossible, how about you?
The “screen sharing” was related to multi-seat setups. I don’t know why you mention rootless-X or “sending the whole screen” here, this is not at all related to multi-seat systems.
In an article about gnome, I thought talking about “the WM” is obviously related to mutter. Sorry for not being clear. Other WMs are totally unaffected and can continue to pretend multiple logins just work fine.
“Why always assume the worst?”
Becuase apps not working properly when being run multiple times simultaneously really bugs me. And I thought with Free Software we tried to fix bugs where they occured, rather than paper over them, or work around them in different layers of the stack. This sounds like admitting defeat, and now app developers will have *less* incentive to do the right thing.
It just put a bee in my bonnet.
“why on earth do you think an ssh-login is affected by this?”
You said “a single session shared across all logins of the same user.” I thought “all logins” meant “all logins”. My bad. Plus, I figured with Gnome now (soft-?)depending on systemd-logind, and with talk I’m sure I read somewhere of having *all* sessions (as in actually all, including pure console sessions and ssh sessions) use systemd-logind to manage cleanup of backgrounded tasks and whatnot, with some tricksy fd-passing over kdbus it’s not entirely implausible to make iceweasel launched from X-over-ssh show up on an existing graphical session.
“usually they don’t support it, but pretend to do.. I mean, hello, anyone syncing your access to ~/.config?”
Yeah, if only we’d invented inter-process concurrency primitives like named semphores and file locks. 😦
“Therefore, ctrl+q will *not* kill the instance of another login.”
Sorry, I was *completely* unclear there. I was intending the ctrl+q phrase to apply solely to Iceweasel, desipte never actually mentioning it. (What, my psychic projection powers are on the blink *again*?) Won’t ctrl+q cause Iceweasel to exit, across all desktops in the session(s)?
“I prefer being able to run firefox in all logins over a message telling me it’s impossible, how about you?”
I actually prefer not to run Firefox :-p. If I did, I’d (obviously, to beat this dead horse one more time) go with the write-in third option of trying to get Mozilla to teach it to run multiple instances at once. As unlikely as that is.
“In an article about gnome, I thought talking about “the WM” is obviously related to mutter.”
Well, I’m definitely partly at fault there. I saw the article on planet.freedesktop.org, and read it with distinctly desktop-neutral glasses on. Sorry.
Sorry for offtopic, but what is the current status of SimpleDRM, is it going to mainline?
That got kinda delayed until we get fops-revoke support. But I think I should resend the SimpleDRM patches this week.