Subscribe to RSS Subscribe to Comments

Font sidecars: dream or nightmare?

At DebConf this year, I gave a talk about font-management on desktop Linux that focused, for the most part, on the importance of making font metadata accessible to users. That’s because I believe that working with fonts and managing a font collection are done primarily through the metadata — like other types of media content (audio files, video files, even still images, although most people fall back to looking at thumbnails on the latter). For example, you need to know the language support of a font, what features it offers (either OpenType or variable-font options), and you mentally filter fonts based on categories (“sans serif”, “handwriting”, “Garamond”, tags that you’ve assigned yourself, etc.).

That talk was aimed at Debian font-package maintainers, who voluntarily undertake the responsibility of all kinds of QA and testing for the fonts that end users get on their system, including whether or not the needed metadata in the font binaries is present and is correct. It doesn’t do much good to have a fancy font manager that captures foundry and designer information if those fields are empty in 100% of the fonts, after all.

At the end of the session, a question came up from the audience: what do we do about fonts that we can’t alter (even to augment metadata) from upstream? This is a surprisingly common problem. There are a lot of fonts in the Debian archive that have “if you change the font, you must change the name” licenses. Having to change the user-visible font name (which is what these licenses mean) defeats the purpose of filling in missing metadata. So someone asked whether or not a Debian package could, instead, ship a metadata “sidecar” file, much like photo editors use for camera-raw image files (which need to remain unmodified for archival purposes). Darktable, Digikam, RawTherapee, Raw Studio, and others do this.

It’s not a bad idea, of course. Anecdotally, I think a lot of desktop Linux users are unaware of some of the genuinely high-quality fonts available to them that just happen to be in older binary formats, like Adobe Utopia. The question is what format a metadata sidecar file would use.

The wonderful world of sides of cars

Photo editors use XMP, the Extensible Metadata Platform, created by Adobe. It’s XML-based. So it could be adapted for fonts; all that’s needed would be for someone to draw up a suitable XML namespace (or is it schema? Maybe both?). XML is mildly human-readable, so the file might be enlightening early-evening reading in addition to being consumable by software. But it’s not trivial, and utilizing it would require XML support in all the relevant font utilities. And implementing new support for that new namespace/schema. I’d offhandedly give it a 4 out of 10 for solving-the-problemhood.

On the other hand … almost all font-binary internals are already representable in another XML format, TTX, which is defined as part of the free-software FontTools project. There are a few metadata properties that aren’t directly included in OpenType (and, for the record, OpenType wraps both TrueType and PostScript Type 1, so it’s maximal), but a lot of those are either “derived” properties (such as is-this-a-color-font) or might be better represented at a package level (such as license details). TTX has the advantage of already being directly usable by just about every font-engineering tool here on planet Earth.

In fact, theoretically, you could ship a TTX sidecar file that a simple script could use to convert the Adobe Utopia Type-1 file into a modernized OpenType file. For licensing reasons, the package installer probably cannot do that on the user’s behalf, and the package-build tool certainly could not, because it would trigger the renaming clause. But you could leave it as a fun option for the user to run, or build it into a font manager (or a office-application extension).

Anyway, the big drawback to TTX as a sidecar is that creating hand-crafted TTX files is not easy. I know it’s been done at least once, but the people involved don’t talk about it as a personal high point. In addition, TTX isn’t built to handle non-font-binary content. You could stuff extra metadata into unclaimed high-order name table slots, but roundtripping those is problematic. But for the software-integration features, I’d call it at least a 8 out of 10 possibility.

Another existing metadata XML option is the metadata block already defined by the W3C for WOFF, the compressed web-font-delivery file format. “But wait,” you cry, leaping out of your chair in excitement as USB cables and breakfast cereal goes flying, “if it’s already defined, isn’t the problem already solved?” Well, not exactly. The schema is minimal in scope: it’s intended to serve the WOFF-delivery mechanism only. So it doesn’t cover all of the properties you’d need for a desktop font database. Furthermore, the metadata block is a component of the WOFF binary, not a sidecar, so it’s not fully the right format. That said, it is possible that it could be extended (possibly with the W3C on board). There is a per-vendor “extension” element defined. For widespread usage, you’d probably want to just define additional elements. Here again, the drawback would be lack of tool support, but it’s certainly more complete than DIY XML would ever be. 6 out of 10, easily.

There are also text-based formats that already exist and cover some of what is desired in a sidecar. For example, the FEA format (also by Adobe) is an intentionally human-writeable format geared toward writing OpenType feature definitions (think: ligature-substitution rules, but way more flexible. You can do chaining rules that match pre-expressions and post-expressions, and so on). FEA includes formal support for (as far as I can tell) all the currently used name table metadata in OpenType, and there is an “anonymous” block type you could use to embed other properties. Tool support is stellar; FEA usage is industry standard these days.

That having been said, I’m not sure how widespread support for the name table and anonymous stuff is in software. Most people use FEA to write GSUB and GPOS rules—and nothing else. Furthermore, FEA is designed to be compiled into a font, and done so when building the font from source. So going from FEA to a metadata database is a different path altogether, and the GSUB-orientation of the format means it’s kind of a hack. If the tool support is good and people agreed on how to stuff things into anonymous blocks, call it 5.5 out of 10.

Finally, there’s the metadata sidecars used by Google Fonts. These are per-font-family, and quite lightweight. The format is actually plain-text Google protobuf, although the Google Fonts repository has them all using the binary file extension, *.pb. Also, the Google Fonts docs are out of date: they reference the old approach, which used JSON. While this format is quite easy to read, write, and do something with, at the moment it is also minimal in scope: basic font and family name information, weight & style, copyright. That’s it. Certainly the extension mechanism is easy to adopt, however; this is trivial “key”:”value” stuff. And there are a lot of tools capable of reading protobuf and similar structured formats; very database-friendly. 6 out of 10 or so.

Choose a side

So where does that leave us? Easy answer: I don’t know. If I were packaging fonts today and wanting to simply record missing metadata, unsure of what would happen to it down the line, I might do it in protobuf format—for the sake of simplicity. It’s certainly feasible to imagine that protobuf metadata files could be converted to TTX or to FEA for consumption by existing tools, after all.

If I was writing a sidecar specifically to use for the Utopia example from above, as a shortcut to turn an old Type-1 font into an OpenType font with updated metadata, I would do it in TTX, since I know that would work. But that’s not ultimately the driving metadata-sidecar question as raised in the audience Q&A after my talk. That was about filling in a desktop-font-metadata database. Which, at the moment, does not exist.

IF a desktop-font-metadata plan crystalizes and IF relying on an XML format works for everyone involved, it’d certainly be less effort to rely on TTX than anything else.

To get right down to it, though, all of this metadata is meant to be the human-readable kind. It’d probably be easier to forgo the pain of writing or extending an XML namespace (however much you love the W3C) and keep the sidecar simple. If it proves useful, at least it’s simpler for other programs and libraries to read it and, perhaps, transform it into the other formats that utilities and build tools can do more interesting things with. Or vice-versa, like fontmake taking anonymous FEA blocks and plopping them into a protobuf file when building.

All that having been said, I fully expect the legions of XML fans (fxans?) to rush the stage and cheer for their favorite option….

The OpenType in Open Source workshop at LGM 2015

This year at Libre Graphics Meeting, we held a workshop / discussion session about OpenType support in open-source graphics applications. I proposed the session, but really only to act as cheerleader.

OpenType features have been possible (and available) in fonts for well over a decade. But few if any applications make them easy to access and use. At the ATypI meeting in October 2014, type designers got so upset at how bad Adobe’s OpenType feature support is in things like Illustrator and InDesign that they actually started a petition in protest.  That raised a red flag with me, since open-source applications aren’t any better in this regard. So I proposed on the CREATE list that we get together and talk about it.

Turnout was excellent—we didn’t do a full headcount, but representatives from every large free-software graphics tool at LGM were there (and several of the smaller ones, too).  The meeting room was packed. That’s good news, because it indicates a lot of interest in getting proper OpenType support working and in coming up with implementation approaches that will feel consistent from app to app.

To be more specific (for anyone with the misfortune to stumble onto this post from outside), we were there to look at how application projects could add support for optional advanced OpenType features that the user should be allowed to switch on and off as desired.  That turns out to be a bit complicated.

A little background

OpenType features come in two general forms: look-up rules that change the positioning of one or more glyphs (which you’ll see called GPOS lookups), and rules that substitute glyphs for other glyphs (which would be GSUB lookups).  There is a big, public list of “tag” names that font developers can use to designate their various GSUB and GPOS rule sets with some semantic meaning.

For instance, replacing the “f” and “i” glyphs with the “fi” ligature glyph is a GSUB rule that is usually listed under the “standard ligatures” tag, ‘liga’.  Semantically, liga is supposed to be for ligature substitutions that are active by default.  In contrast, the “discretionary ligatures” tag ‘dlig’ is supposed to designate ligatures that are not required, but that the user might want to enable for decorative purposes.  A lot of historical fonts have a “Qu” ligature that would fall under this category, with the tail of the Q sweeping out way under the u.  Similarly, there are GPOS rule sets like “case-sensitive forms” or ‘case’ that are supposed to be always on: ‘case’ is meant to adjust the vertical position of punctuation like hyphens and parentheses so that they line up correctly for ALL CAPITAL TEXT instead of for lowercase.  Then there are GPOS rules that are optional, like “tabular numerals” or ‘tnum’—which shifts all numeric digits to make sure they line up in columns.

[Side note: there’s also a large set of these features that are defined specifically to enable shaping of complex scripts (like Arabic and Indic scripts), where the context of the letters and words requires a lot of flexibility for shape and placement when compared with scripts like European alphabets or CJK text.  Consensus was clear that these features are meant to be handled by the shaping engine, not the application, and the shaping engine is already doing a good job here.]

First tricky bit is, though, that what’s “supposed” to always be on and what’s supposed to be left up to the user as an option is kind of arbitrary.  The creators of OpenType don’t even agree.  Adobe has one list with such advice; Microsoft has another, and Adam Twardoch of FontLab has yet another.

Discussion and analysis

So we spent some time discussing the various types of OpenType features—at least those on the “official” lists of “registered” tags linked to just above. The question came up how often that list of registered feature tags gets expanded; the answer is evidently “not often.” Then we talked a lot about the different kinds of features and how they may be used.  Some of them a user might apply only to a few selected characters (even one); others would be desirable for whole blocks of text or documents.

But it’s not that simple.  An “default on” feature cannot be trusted to work flawlessly in every font and every situation, so the user needs some way to switch it off. And a contextual feature like “smart fractions” (‘frac’) might match some text pattern but actually be semantically different in the document. My example was when a user writes “I’m working 24/7″—that numeric sequence looks like a fraction, but in reality it isn’t one. [Note: part of the complication has to do with the fact that there are two slash-like Unicode characters, the ‘slash’ itself (U+002F, “SOLIDUS”) and the ‘fraction bar’ (U+2044). Usually only the ‘solidus’ slash is on the keyboard.]

We also looked at several UI proposals (1234567) related to OpenType features that had been previously published by others, just to see what the landscape looked like.  Here (as well as in all of the discussion about when and how a user might want to access a particular feature), we got a lot of good feedback from interaction designer Peter Sikking.  For starters, Peter pointed out that many of the UI suggestions’ complaints are more reactionary about what isn’t working right than they are carefully-considered interface rules, so they may be interesting, but are not work to copy.

Peter also pointed out that the application projects represented have very different needs: an interface that works for Scribus—which is text-centric and offers lots of typography features—would not work for GIMP, where the text tool is a less important component (and one that has far less screen real estate available to its user interface). The best we can hope to do, he said, is come up with some “best practices” that apply to different scenarios, and let each application project implement them on their own as best they can.

Someone (and I think it was Peter, but I’m not 100% sure this many days later; please let me know if it was you) then pointed out that a few of the features amount to typeface-wide choices that are often implemented (at present) in separate fonts.  The prime example is small caps, which is frequently available as an OpenType feature (‘smcp’) but even more frequently is pulled out into a separate font, e.g. “Foo Serif SC”.  Though less used, there is an italics feature tag, too (‘ital’).

Making matters worse, many applications also allow “fake” small caps and italics. The user, however, will likely not care whether small caps or italics are implemented as an OpenType feature or in separate font files; they just want to apply them as a text style. That both presents a UI issue and impacts implementations.

We also briefly discussed whether supporting OpenType features in text markup would affect file formats.  Generally speaking, everyone seemed to think this would not be a difficult problem. There was a general desire to implement something that follows the approach used by CSS.  It seems to be working well for users (and developers), so that looks good.

Among the other points raised:

  • Behdad Esfahbod pointed out that CSS feature support is frequently accessed with a simple slider option that turns features on and off without significant headaches or dependency problems. For example, contextual ligatures, historical ligatures, and discretionary ligatures are all just “ligatures.”  The users don’t care (nor need to know) which feature provides the ligature they want. Similarly, its irrelevant to users that the ‘frac’ feature has a hidden dependency on separate numerator and denominator features.
  • Some of the features, like stylistic sets and character variants, come not just with a set of GPOS/GSUB rules, but also a human-friendly name that is encoded into the font.  For example, a font that includes ornamental caps in a stylistic set might name that set “Ornaments”.  This name would be a string in the uiLabelNameId field within the font file; so the application will need a way to access that and expose it to the user.
  • There should probably be some way to specify an “on by default” set, since it seems to be expected, but also a way for the user to switch it off.
  • There should be controls for the common (and well-defined, publicly “registered”) features, but there should also be a fallback mechanism that allows the user or application to access any feature via the feature’s four-letter tag.

Where to now?

Looking forward, we settled on a few “next action” items. For starters, we are going to try and coordinate our future discussions through the CREATE mailing list, which was invented to be a home for just this sort of collaboration.

Regarding the UI and UX questions, Peter agreed to work on developing what will eventually form the “best practices” and related recommendations for different applications.  The first step, however, is to spend some time talking with typographers and other graphic-designer-like users (who care about OpenType feature support) to study their processes and expectations.  This sort of process is what Peter does professionally; he most recently has been undertaking a similar systematic approach to interaction development with the Metapolator project (which he gave a talk on at LGM).  I mention this to explain that there are several steps between getting started and actually seeing prototypes, much less full-blown recommendations.

Regarding the lower-level plumbing layer: Fontconfig already catches the presence of OpenType feature tables when it indexes a font.  To get access to such a feature, though, the shaping engine (i.e., the software library that takes Unicode text characters, looks them up in the active font, and returns the right glyphs) also needs a way to report the presence of OpenType features, and a way for applications to request that the feature be turned on or turned off.  HarfBuzz is the shaping engine used by almost all free-software tools, and Behdad agreed to take on adding the necessary functions and API calls.

Moving one level up, some applications use HarfBuzz directly, but a lot of applications (including GIMP and Inkscape) use an intermediate text-layout library called Pango.  So Pango will also need hooks for OpenType features.  Behdad indicated that he is on top of this feature request as well.

Application projects, at the moment, do not have a lot that they need to do.  However, since the eventual ‘best practices’ are going to require using HarfBuzz, any application project that has been considering porting its text handling to HarfBuzz would save a lot of trouble later by getting started on that project now.  Earlier in the week, we held a HarfBuzz documentation sprint to develop a “porting manual” so to speak.  It isn’t quite finished yet, but the core example is there and will hopefully prove useful.

The exception to the above is that FontForge may need some work to support access to all of the OpenType features that may be exposed to the applications. The eventual plan was that FontForge (or other font editors) ought to provide a way to test features that somewhat resembles how feature usage is implemented in applications, but getting there may require some groundwork in advance.  The same may also be true for apps like GNOME Characters or the KDE and GNOME font managers, but I don’t think those developers were on hand at LGM.

Similarly, the thinking was that Fontconfig may also require some tweaking in order to allow testing of OpenType features.  During the smallcaps discussion mentioned above, Behdad noted that Fontconfig already lets the user define, in essence, “virtual fonts” that are simply fonts.conf references to existing fonts but with different OpenType features switched on or off.  A quick test revealed that this feature works to a degree, but has some bugs that need attention.  Here again, though, Behdad said he’s happy to take them on.

There were also open questions about real-world font implementations of several features. Google Web Fonts and Open Font Library, unfortunately, don’t index which fonts have these features. I agreed to do some research here.

We may also need to gather some good test cases: fonts with a variety of features implemented, and perhaps fonts that we will add features to (e.g., ‘ital’, which seems pretty rare).  If you’d like to help me that, get in touch, of course.

As for a web presence, I have tentatively set up a GitHub organization to use—at this point, primarily for the wiki and progress-tracking functionality.  You can find it at … you may need to request membership if you want to contribute, although I’m new to “organizations” so bear with me if I have the details a bit off.  We’ll see.

Onward and openward!

For everyone else: if you want to keep up with the discussion, you can follow (or join) the CREATE mailing list. You can also take a look at the Etherpad notes from the session, although I cannot guarantee that they’re free of typos.  If you find any … someone else made those.

More will surely come. If you work on open fonts—or if you use or develop free software—I hope you’ll stayed tuned or even get involved.

Linux and the Automotive Security Lab

Attached are the slides from my talk at the Fall 2013 Automotive Linux Summit. My session was entitled “Linux and the Automotive Security Lab,” and it was a survey of all of the security research that I’m aware of that dealt with actual cars—as opposed to theory.

Not that there’s anything wrong with theory in my book, mind you, but there are only so many times you can read “CAN bus lacks sender authentication and payload encryption” before your eyes glaze over.  It does, and that means that there are a lot of places where it needs major changes.  So many, in fact, that I referred to it in my talk as “Theseus’s ship.”  According to Plutarch, the museum of state relics in Athens included a ship used by Theseus in some daring adventure or other, and the Athenians took such good care of it that they replaced a part whenever it wore out … so much so that by Plutarch’s time, the Athenians had replaced every part, which led some of them even then to ask whether the museum still had Theseus’s ship at all.  The point is, if you need to replace all of CAN bus’s constituent parts to make it usable, you’d might as well just use something else to begin with.

But that’s kind of beside the point, since that’s a hypothetical.  In reality, as the research linked to here shows, there are a giant heaping metric Athenian boat-load of attacks that can be waged against existing cars right now.  Looking at some of them should give developers pause.  Because yes, CAN bus can be used to mount all manner of attacks—but there are a lot inroads into the vehicle that have nothing to do with vehicular network protocols at all.  Some are freshmen-level security programming mistakes, others are systemic flaws inherent to multi-sourced component supply chains, and some are just weird.

I probably ought to publish my speaker notes, too, but one thing at a time.  I hope the slides will be a good reference and starting point for anyone interested in reading more about IVI and automotive computing security.  And if you see any papers or presentations that I’ve missed, please, drop me a line; I’ll happily add them to the list.

ALS2013: Linux and the Automotive Security Lab

Big List of NGO & Public-Good open project feeds

Here’s a list of news feeds I’m following that fall into what I generally call the NGO/public-good/nonprofit space.  Essentially, that means open source / open data efforts that cover education, medicine, humanitarian needs, civic involvement, and just a whole bunch of other things that don’t revolve around sales, software engineering itself, or Internet infrastructure.  They’re only partially sorted.

Did I leave any off? Send me an email, or post a comment, if the robot-filter is feeling friendly today.

It seems like there ought to be more, but for some reason a lot of the groups that are active in this space FAIL dramatically at RSS.  Take Open Source Ecology (, for example.  They do some amazing stuff with construction and tooling for economically-struggling communities. You’d think they’d want to publish their news, but their “blog” page (*their* name for it, mind you) has no RSS or Atom feed of any kind.

Don’t believe me? Check it out:

I’d suggest you write to them and say “hey, I’d really like to follow your organization, but your news site offers me no way to do that. What gives?” Except that I’ve already done that, and they didn’t even reply, much less fix the site.  On the plus side, the Freedom Of The Press Foundation was in exactly the same situation up until a few days ago (well, the same except for the added irony); when I notified them via Twitter, they also did not reply, but they did silently fix their site.

Anyway, I hope you’ll find some interesting sites and projects on this list.  I may re-post to add to it later if I get a significant chunk of new feeds.  But it’s a refreshing set of content to browse through, since all of it is focused on helping people, one way or another.

[ed. note: I did try making this available as a “Google Reader bundle” which is a new feature, but sharing it is tightly bound to keeping it inside of Google Reader itself, which kills most of the value]

GUADEC a Galicia

Flaunting some Olympic-caliber procrastination, I’d now like to provide a brief recap of my visit to A Coruña, Spain for GUADEC 2012, at the end of July.  GUADEC is an annual conference for GNOME developers and users; I definitely fall into the latter category, but I was somehow lucky enough to still con the GNOME Foundation into providing travel assistance so I could be there and give a talk about font development and font repair.  But more about that in a separate post.

For starters, if you don’t feel like reading any further, I’d have to say that the conference was great by any measure.  As a journalist, I spend a lot of time in touch with open source developers but I’m hardly “in” any projects—and certainly not any large & organized ones like GNOME.  So it’s always both eye-opening and entertaining to get to spend a lot of time around developers who are there to develop, and who believe in what they are doing.  In GNOME’s case, this happens to be the 15th anniversary of the project, so they’ve been “doing” for quite a long time.

The program by the sea

I arrived early, on Monday evening, because I needed to keep a regular writing and editing schedule for my work with LWN, which publishes on Wednesday evenings.  I’ve attempted to go to events where I’m en route on a Tuesday, and it just doesn’t work.  The first half of the week, there were no talks, but there were plenty of GNOME people around: there were Foundation meetings, hackathons, and various other cabals, many situated at the local Igalia offices.  The sessions themselves lasted from Thursday through Sunday—and by that, I almost mean literally.  They started early and they ran late.  Which it turns out is perfectly practical, since restaurants in the area don’t even open until 8:30pm.  I have no idea what else you would do between 6:00pm and then, although the hotel (which was situated under a cliff in the mountains) did have an espresso bar (1 euro; I have no idea what that is in regular money, but it certainly beats instant coffee).

Over the course of the session days, I went to every talk I could get to, barring the two morning sessions I had to skip in order to file paperwork reporting that I had a camera lens stolen from my checked luggage on the flight in (in case you were wondering, it was on American, with the final leg handled by their oneworld partner Iberian, and both have been precisely as helpful as you would expect a giant faceless corporation to be. Meaning they appear to be making no effort to even investigate, and they only contact you via emails with no-reply-accepted return addresses.  So kids, if you’re going to pursue a career in crime, it sounds like baggage theft is the way to go—no risk of getting caught.  But I digress….).

Anyway, there were a lot of talks about new, weird, and unexpected projects, including Colin Walters’ OSTree (which is akin to a mashup of Git, OBS, overlayfs, and a package manager), SkelTrack (which is a framework for identifying the person in a Kinect-style depth image), and Dawati (which is a usability testing tool that records webcam video and desktop screencasts, then combines them into one video stream for analysis).  There were also lots of talks about new and improved GNOME components like Boxes, Folks, and GOA, and a large swath of design and interaction talks—nine or ten of which seemed to be given by Allan Day.  Seriously; I’m pretty sure there was one slot where he was giving two talks at the same time, in different rooms.

One build to rule them all!  Or, not

The other interesting bit was the repeated discussions surrounding the “GNOME OS” concept.  This is something that has come up many times before and is often either mischaracterized or is conflated with other, unrelated concerns.  The gist of it is that GNOME is currently 100% dependent on downstream distributions for delivering its software to users.  That is to say, whenever there is a GNOME Release … nobody downloads it.  Or installs it.  And that’s because they can’t, because they depend on their distro’s package management system for their GNOME environment (and which it would be a bad idea to break).  Trouble is, this means virtually no one tests GNOME releases, and the project gets no bug reports for ~six months (at which point the release hits downstream distros).  Plus, what bug reports they do get are always difficult to triage, since the distributions (essentially Fedora, Ubuntu, Debian, and openSUSE) all make their own adjustments and roll their own packages).  So GNOME is harder to debug, and thus is harder to maintain.

The proposed solution is to roll up each new release with an installable, runnable OS image.  So a GNOME release would be a bootable ISO image that someone—though not everyone—can install and try out, perhaps even use, rather than a set of meta-packages that will gradually trickle down to the neighborhood package repository.  Another side effect of this scheme would be that tablet and gadget makers could take the base image and use it as a “known platform” to build an embedded project on, which GNOME would like.  Though new, this binary, ROM-like release would not be the only way to get GNOME; distributions and source-compilation-fetishists would still be getting, building, and distributing ye olde traditional GNOME packages, too.

What this concept is not is GNOME wanting to cast off the chains of the distributions, give the finger to BSD, and try to maintain its own Linux distribution.  It should be clear that that would not work anyway (given the cost and personnel required), but people seem to think that about it anyway.  Partly this is speakers’ fault; in the first GUADEC talk that brought up the idea the Igalia speaker actually said “distribution” multiple times; if you were in the audience you would think he meant running a distro, too.  So some clearer messaging would help a ton here.  Perhaps even calling it GNOME ISO or GNOME Live, rather than GNOME OS.

The confusion is also partly due to unhappy users getting the proposal conflated with other criticisms about how GNOME is developed.  In recent years, a fair number of people feel like GNOME module maintainers at Red Hat are trying to encroach onto other parts of the OS stack—such as the init process—and are adding hard dependencies on either Linux-only subsystems or on Red Hat products.  This is pretty visible with Ubuntu, for example, which uses almost all of the GNOME stack, except for GNOME Shell.  But historically GNOME has not mandated things like the init system or the compositor/window manager, so replacing the Shell with Unity would be No Big Whoop.  If such components were to become hard requirements, however, that would further separate Ubuntu from the vanilla GNOME platform—and it would do so essentially by a module maintainer’s fiat.  That, naturally, aggravates people, and when they’re aggravated, they aggravate GNOME people in response, ad infinitum.

However::: I’m not going to discuss that, because that is not at all what the GNOME OS proposal is about.  As I said above.  That is an unrelated set of development and technical-goal-setting issues that GNOME, Ubuntu, and Red Hat need to work out somehow.  Wilderness retreat or whatever.  There were also a few discussions during the week about whether GNOME needs a Technical Board, which sounds like a good idea for other reasons, and might help here, too.  In any event, the GNOME OS idea is designed to make GNOME releases easier to test & provide feedback on, which is 100% in the good-things column.

Music cue

Anyway.  Back on track, the word count line at the bottom of this WYSIWYG form is telling me I just passed 60,000 words on this post, so I’m going to try to wrap it up.

All in all, I know how corny it sounds, but the best thing about my week at GUADEC was definitely meeting the people.  Multiple times over the week, I met someone, had a moment of mutual where-do-I-know-that-name-from contemplation, and then we realized I had emailed them and written something about their project.  And a lot of them said thanks, which doesn’t happen to me a lot.  That’s not because I usually write scathing personal attacks or anything, but simply because I usually write form home and not in an office with the people that I interact with.  So it was a blast to get to know them in person, since I genuinely like what they do.  Into this category I would put Eduardo Lima, who develops the awesome-and-under-the-radar file transport tool FileTea (and who generously put up with my lame questions about Cuba), Joaquim Rocha, who makes the excellent OCRFeeder (in addition to SkelTrack mentioned earlier), and Joanmarie Diggs, who does all the heavy-lifting on accessibility work (and has some good stories to tell about EU immigration law…).

I also met a lot of great people that I had never talked to even via email before GUADEC, including the Yorba team of Adam Dingle and Jim Nelson (whose Geary application I had reviewed, but without discussing it with them, and who are both way ahead of everybody else when it comes to thinking about funding open source software development, and about eating pulpo), testing guru Spider (who put up with my questions about home automation), and of course the GNOME power couple Jonathan Blandford and Rosanna Yuen (or power trio, if you also count Jonathan’s beard).  One of my great surprises was to discover that not only is Jonathan the author of the solitaire app AisleRiot (yeah, I don’t read a lot of “About” screens…), but that he also shares an interest in unusual card games, and secretly built in Aisleriot support for decks of cards with five or more suits—which happens to be a weird hobby of mine.  One of my great regrets about the week is that I had to leave at crack-early on Monday morning, so I had to miss out on playing a bizarre card game of Jonathan’s.  But that’s on the agenda for next time.  As luck would have it, my own talk was scheduled at the exact same time as the talk absolutely everyone most wanted to hear, Owen Taylor’s session on smooth animations.  In fact I considered skipping my own talk to hear it, but ultimately I couldn’t find Taylor’s room.  Subsequently, Jonathan tracked Owen down and did some sort of arm-twisting (behind closed doors, obviously) so that Owen agreed to meet me at lunchtime and essentially recap the talk and show me the demos.  I’m still writing it up for LWN.

It was also good to see folks that I bump into more regularly, like Garrett LeSage and Jakub Steiner, who are both regulars at Libre Graphics Meeting, Guy Lunardi, who I think knows everyone in the software business (and not just open source, either), and Karen Sandler who has always been exceptionally helpful with my press requests (and, I discovered, whose husband Mike is one of those guys who can have conversations about both the Beach Boys and about BIOS).  There are clearly a ton of other people that I enjoyed getting to meet at GUADEC 2012, including a lot of Igalia folks, but the bulk of them I need to save for my follow-up post, which will deal with my font talk—and what came out of it.

Next Page »

Based on FluidityTheme Redesigned by Kaushal Sheth