A recent proposal be PulseAudio and systemd lead developer Lennart Poettering to add systemd raised rt-for-bsd-solaris-unix/" >concerns that GNOME might drop support for non-Linux platforms.
Rest assure this is not the aim. Lennart, in follow ups to his proposal, explains that systemd could be separated into a core set of interfaces which could take replacement backends that support e.g. FreeBSD so long as it implements the interfaces systemd cares about or as it was their init system. What Lennart doesn’t want is a lot of additional code in systemd as it is today to support these platforms as one of the main advantages is the simplicity and elegance obtained by relying on the functionality presented by Linux.
photo © 2011 atzerok | more info (via: Wylio) Why should we care about what systemd cares about?Systemd gives us a powerful set of tools to improve the user experience along the improvements promised and shown in performance and standardization (read Lennarts excellent series explaining systemd on his blog). With systemd we can replace some core functionality such as ConsoleKit which would allow for a smoother multi user experience.
Solving simple problems such as setting the pretty host name that gives your machine identity. Systemd strives to allow this now by standardizing on such things as where this data is stored and it what format. Fundamental assumptions about the system that will benefit the user experience.
Systemd goes beyond that, its interfaces provides us a set of information and functionality which we can use to make GNOME more user friendly. E.g. systemd lets us provide a smooth experience via it’s control group tracking of all processes. This allows balancing of CPU (and likely also IO) resources between applications making a system slow down more graceful and the overall experience smoother. This tracking also allows GNOME precise knowledge of these processes. data which might be used for improvements in how gnome-shell displays information to the user.
Shouldn’t we wait depending on systemd till other platforms are supported somehow?
In honesty, resources are scarce and the truth is that the vast majority of developers and users of GNOME are on Linux. We have a reference implementation now on that most used platform and replying on its interfaces would allow us to provide a superior user experience both short term and long term. Depending on ystemd only means depending on its interfaces and competing kernels can init systems could very well provide these interfaces as well. That effort is though on their shoulders but with apparent willingness to cooperate.
How this is analog to PackageKit longterm
Many people misunderstand PackageKit, mostly I suspect because they have had poor experiences with the default PackageKit user experience. PackageKit is not about these tools, PackageKit is about defining a common interface to talk to the package manager. This allows e.g. integration so that the system is requested to install support for missing formats if it is available. Common examples of these situations would be missing compression formats like .rar, missing codec support such as .mp3.
It is not about .deb vs. rpm, nor yum vs. apt-get!
PackageKit like systemd exist precisely to avoid those fights. The existing tools and package repos are excellent, what we care about is not replacing them but working with them in a consistent fashion. In PackageKit every package manager implements a backend which supports a common interface. In the same way that depending on systemd allows the assumption of a common set interfaces which can be used to enhance the user experience. There should be nothing technically baring an analog solution for systemd as what PackageKit has for separated backends.
But the PackageKit user interfaces are still ugly David!
That is true and it is widely agreed that the Ubuntu Software Center is a superb experience. It currently works not using apt-get directly but using an incompatible PackageKit fork aptdeamon. Porting this to PackageKit is being undertaken by Alex Eftimie under Google’s Summer of Code 2011 so fear not you shall have the same experience as always, and it will be available on any GNOME platform. Naturally depending on completeness of PackageKit backend and existence, though most major distributions are covered to some degree.
Ubuntu’s other tools such as the update experience are also aptdeamon tools and could be ported. My personal feeling would be that the better investment of resources would not be specifying GNOME3 stories for upgrades and updates in additions to the stories already told by PackageKit.
PackageKit and systemd are slow!
And I postulate to all that slow is a bug. In the case of systemd one of benefits should be performance an Lennart is already matching an Ubuntu Upstart powered 10 second boot. As I understand with patches to a standard Fedora 15 install and no LVM as I understand. PackageKit might have hard problems to solve to match what aptdeamon gives Ubuntu in terms of performance and certain features but Richard Hughes has shamed concerns before with actual hacking. I would trust him to solve this problem long term and reap the benefits of being allowed the assumptions PackageKit gives GNOME now.
GNOME as an OS is (partly) about interfaces, not defining a Linux only desktop that runs only on Thursdays if the window is open
Interfaces like PackageKit and systemd allow GNOME to solve problems and provide real improvements to the experience. The sad side effect of leveraging what the vast majority of GNOME users already have in Linux is short-term that GNOME will be Linux only. Long term it is up to the competition to provide the same interfaces. This is no different from depending on Tracker or GTK+, these needed tools which provide the interfaces we need might not run on a given platform. Given resource constraints it must sadly fall upon these platforms to contribute in providing those required interfaces.
“Given that the focus is on Power Users, anything and everything should be able to be exposed as an option; there should be no concern for confusing the user with too many options – the goal here would be completeness…check-box heaven if you will…a haven for click-happy config junkies.”
