Ramblings on computers…

Tag Archives: Fedora

After a couple of discussions at the DX hackfest about cross-platform-ness and deployment of GLib, I started wondering: we often talk about how GNOME developers work at all levels of the stack, but how much of that actually qualifies as ‘core’ work which is used in web servers, in cross-platform desktop software1, or commonly in embedded systems, and which is security critical?

On desktop systems (taking my Fedora 19 installation as representative), we can compare GLib usage to other packages, taking GLib as the lowest layer of the GNOME stack:

Package

Reverse dependencies

Recursive reverse dependencies

glib2

4001

–

qt

2003

–

libcurl

628

–

boost-system

375

–

gnutls

345

–

openssl

101

1022

(Found with repoquery --whatrequires [--recursive] [package name] | wc -l. Some values omitted because they took too long to query, so can be assumed to be close to the entire universe of packages.)

Obviously GLib is depended on by many more packages here than OpenSSL, which is definitely a core piece of software. However, those packages may not be widely used or good attack targets. Higher layers of the GNOME stack see widespread use too:

Package

Reverse dependencies

cairo

2348

gdk-pixbuf2

2301

pango

2294

gtk3

801

libsoup

280

gstreamer

193

librsvg2

155

gstreamer1

136

clutter

90

(Found with repoquery --whatrequires [package name] | wc -l.)

Widely-used cross-platform software which interfaces with servers2 includes PuTTY and Wireshark, both of which use GTK+3. However, other major cross-platform FOSS projects such as Firefox and LibreOffice, which are arguably more ‘core’, only use GNOME libraries on Linux.

How about on embedded systems? It’s hard to produce exact numbers here, since as far as I know there’s no recent survey of open source software use on embedded products. However, some examples:

Qt pulls in GLib as an optional dependency (automatically enabled if compiled for X11, QWS or QPA) for its main loop, and is used widely in embedded systems.

So there are some sample points which suggest moderately widespread usage of GNOME technologies in open-source-oriented embedded systems. For more proprietary embedded systems it’s hard to tell. If they use Qt for their UI, they may well use GLib’s main loop implementation. I tried sampling GPL firmware releases from gpl-devices.org and gpl.nas-central.org, but both are quite out of date. There seem to be a few releases there which use GLib, and a lot which don’t (though in many cases they’re just kernel releases).

Servers are probably the largest attack surface for core infrastructure. How do GNOME technologies fare there? On my CentOS server:

I can’t find much evidence of other GNOME libraries in use, though, since there isn’t much call for them in a non-graphical server environment. That said, there has been heavy development of server-grade features in the NetworkManager stack, which will apparently be in RHEL 7 (thanks Jon).

So it looks like GLib, if not other GNOME technologies, is a plausible candidate for being core infrastructure. Why haven’t other GNOME libraries seen more widespread usage? Possibly they have, and it’s too hard to measure. Or perhaps they fulfill a niche which is too small. Most server technology was written before GNOME came along and its libraries matured, so any functionality which could be provided by them has already been implemented in other ways. Embedded systems seem to shun desktop libraries for being too big and slow. The cross-platform support in most GNOME libraries is poorly maintained or non-existent, limiting them to use on UNIX systems only, and not the large OS X or Windows markets. At the really low levels, though, there’s solid evidence that GNOME has produced core infrastructure in the form of GLib.

As much as 2014 is the year of Linux on the desktop, Windows and Mac still have a much larger market share. ↩

The time has finally arrived, and I'm off on my travels in four days. I'll be away from the computer for up to two months, spending a month trekking in Chile, then a month doing various other things. I might be back in time for the GNOME 2.24 string freeze, but I should definitely be back in time to see the release. In my absence, I obviously won't be able to do any further work on this cycle, but I think all my current contributions are pretty much complete anyway. I won't be replying to mail for at least the period I'm in Chile.

I won't be around to see them get into the archives, but Stefan Ebner has been working on packaging both Diary (now called "Almanah" due to Fedora issues) and Hitori for Ubuntu. My thanks to him for his hard work on that, and patience in helping me fix all the nasty little autofoo problems.

I'll try to make an Almanah (Diary) 0.4 release before I go, but I want to leave as long as possible for translations to catch up with the several string changes.Almanah 0.4.0 is out! The main change for this release is to rename it and fix some problems preventing it being packaged, and so it should be compatible with old databases. The build requirements haven't changed.

Finally, my laptop's finished installing Fedora 8. I probably shouldn't have tried to install it, considering the laptop's an old Fujitsu Siemens Amilo M-6100, with a Celery processor and 128MiB of RAM.

I started the process on Saturday, first discounting using the install DVD, as the laptop doesn't have a DVD drive, then discounting the LiveCD since it has nowhere near enough RAM, and just times out when logging in. Talking with Bastien, he suggested I run it from the boot.iso file from the install disk, and then point that at the full DVD's ISO somewhere (either on an NFS or USB drive, or on the laptop's hard drive).

I duly started to try this on Sunday morning, but ran into some problems. The boot.iso kernel crashed when loading the drivers for the PCMCIA network card, so an NFS drive was out of the question. I handily don't have any USB drives large enough to contain the 3GiB of install DVD either, so that too was out of the question. The final option was to remove the laptop's hard drive, remove it from its caddy and connect it to my main computer using my Dad's Disk Jockey hardware, so that I could copy the ISO straight to the /home partition.

That worked surprisingly well, so I got the installation up and running about midday Sunday. However, since the laptop only has 128MiB of RAM, the whole package installation process only finished this morning, as I believe it had to seek to the DVD ISO to get the package, seek to the swap partition to cache it there, then seek all the way to the installation location and install it, for each package. Then there's the fact it's got less processing power than a reconstituted bacon sandwich…

Anyway, it's installed now, and I can now spend hours tweaking it so it doesn't use all the RAM just sitting on an empty desktop. Fun times!

In other news, I watched Alien on the TV. It was quite a disappointment really, I suppose due to its age, and how all children's cartoons are like that now, or something like that…