Re: systemd as external dependency

Wow, crazy.

I go debugging gdm for half a day, and come back to find press
headlines about 'GNOME 3 is dropping FreeBSD support'... the reality
is of course much more nuanced, and much less dramatic. There are many
things that could be said here, and much has already been said, so
I'll try to keep my points short:

- GNOME will probably always work best on the platform used by most
contributors, which is a fairly modern Linux distribution. But that
doesn't imply that we strive to ship something that can only be built
on bleeding edge distributions. Looking back at GNOME 3.0, the
NetworkManager 0.9 situation was certainly not a showcase of great
dependency handling. But even so, it was the right decision to finally
have networking as an integrated part of the experience (it feels
funny to even having to mention this in 2011...)

- Posix is not good enough: we expect networking, usb, sound, hotplug,
etc etc. Our unwillingness to settle and rely on suitable interfaces
between the kernel and the desktop has hampered us for a long time.
GOME 3 is the first release that has official built-in support for
networking and printing, after all these years of coming and going
interfaces and frontends. Many of the 'middleware' layer of d-bus
services and other compontents that sit between the kernel and the
desktop have been developed and maintained by people who are close to
GNOME, to satisfy the needs of the desktop (or really just the needs
of a modern OS, period).

- Many of these services can serve as a vehicle for portability too:
If there's just minor differences in the underlying platform, it may
be possible to port the service by just adding a few select ifdefs. If
the service is very close to the kernel (and /sbin/init typically is),
then it may be more maintainable and practical to reimplement the dbus
interfaces from scratch. But an important point is that we don't want
these services to degenerate to pure portability layers; they need to
be able to develop and adapt to improvements and changes as they
happen in the kernel. If that means that alternative implementations
have some catching up to do every now and then, then that is the price
to pay for freedom -- there's freedom on both sides here: freedom to
develop the OS without being constrained by overly strict,
standardized interfaces, and freedom to take the OS and replace bits
and pieces as you like.

- In practice, our portability is story is already pretty nuanced, as
can be seen in, and it
probably always will be. I don't think that will change; we will
always welcome reasonable patches that make our software work on more
systems. But portability is a secondary quality. The primary quality
of our product is that it actually works, and is awesome. It is no
good to produce something that can be built on any free unixoid
system, but doesn't really work right on any of them.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]