Get on the kdbus!
If you’ve poked around the running processes on a modern Linux system, you’ve seen something called dbus. You can read more about this on the dbus website, but the basic summary is that it’s a system for passing messages between programs. Mostly, it runs in the background and users don’t ever think about it — but it’s an important part of the “plumbing”, enabling integrated desktop environment notifications for both GNOME and KDE, role selection for Fedora Server, and more.
For the past decade, this has run as a user-space daemon — a system service that runs in the background, but outside of the Linux kernel. Fedora is experimenting with a new implementation, caled kdbus, which — as the “K” might imply — is actually integrated into the kernel. This will allow it to be available at early boot (before other system services are running), may also allow for better performance, and because it’s connected to the kernel, better security features.
Some developers have been running this themselves for a while now, and now we’re asking for broader testing, at least among those of you brave enough to run our always-moving development branch, Fedora Rawhide. (I do, on one of my main machines — in practice, it’s not that scary, as long as you’re willing to help debug things in the occasional cases where they go a bit… sideways.) For this, all you need to do is boot your Rawhide system with
kdbus=1 enforcing=0, and the kernel and systemd will automatically detect this and use kdbus instead of the traditional daemon.
(And, yeah – that’s disabling SELinux for that boot. Part of the current development is in writing the updated security policy.)
For more, see this devel list mail from Lennart Poettering.
A little warning on Rawhide this week…
As I just noted, Rawhide is usually pretty safe, but sometimes it is a little bit… well… raw. At this week’s Release Engineering meeting Dennis Gilmore notes that this week might be a little rough, with some infrastructure changes and a new version of RPM – which is in itself pretty interesting, as it supports the concept of “file triggers”, which will (eventually!) allow us to make package installation faster and more reliable.
In any case, if you’re a Rawhide user, keep an eye on the devel mailing list, and it’s a good idea to follow Kevin Fenzi’s “This week in rawhide” blog.
Fedora 23 construction continues
With a new Fedora release every six months, it doesn’t take long from the announcement of a new version until we’re in the thick of making the next one. Fedora 22 was released this May, and in just a couple of weeks, we’ll be releasing the Fedora 23 Alpha — currently scheduled for August 11th.
As always, please do remember that the schedule shows a target date, but the Fedora release process aims to strike a balance between strict calendar-based releases and the “release when it’s ready” approach. That means we do slip these dates by a week or two sometime, and if that happens, don’t be too alarmed.
Anyway, of particular note this week: the Alpha freeze, which means that any changes which are intended to go into the F23 alpha release need to go through the freeze exception process. And, we’ve activated Bodhi, the system we provide our packagers to push updates to the updates-testing — in early development, any updates go straight in to the main tree, but as we’re working on stabilizing the release, we add this additional process.
FUDCon Pune report
In addition to our big Flock conference (more on that last week, if you missed it), we have Fedora User and Developer conferences – “FUDCons” – every year in Latin America and in Asia/Pacific. This year’s APAC FUDCon was in Pune, India. Curious how it went? Read Kushal Das’s FUDCon Pune event report.
Is Fedora slowing down?
And finally this week… Fedora Contributor Jiří Eischmann provides some interesting commentary in a blog post with the somewhat-alarming title Growth of Fedora Repository Has Almost Stalled. It’s not as dire as all that, though – but definitely the opening to an important ongoing conversation. Jiří attributes this to the popularity of Copr, our service for building your own mini-repositories, with relaxed guidelines (it’s gotta be free software, and it’s gotta be legal for Fedora – after that, pretty much anything goes).
In parallel, there’s a conversation the Fedora Big Data SIG (a “SIG” is a special interest group – a lightweight association of anyone interested in the topic) mailing list, debating the value to users of repackaging upstream software to Fedora’s traditional standards. Long-term contributor and packager Haïkel Guémar notes:
In real world, if upstream says: “don’t use Fedora packages because they have crippled features”, no end users will ever use our packages. And no user base, means that we have no leverage to fix these poor practices, this is a vicious circle.
The software world has really changed since the beginning of Fedora. A lot of the problems are the same, but the scale is different and so are the pressures. Some of our work on Fedora.next is meant to address this, but we’ve got a long path of continuous improvement ahead of us still. We want users to be able to get the best, most useful open source software with the quality assurances we’re used to with the Fedora name – but we also have to figure out how to fit in with a world where that isn’t always the best model for our users. And, as Jiří says, we also need to build a better path for software which does fit best in the main repositories.