Alex Hudson

Thoughts on Technology, Product, & Strategy

Month: September 2011

Is package management failing Fedora users?

(For those looking for an rpm rant, sorry, this isn’t it….!)

Currently there’s a ticket in front of FESCo asking whether or not alternative dependency solvers should be allowed in Fedora’s default install. For those who don’t know, the dependency solver is the algorithm which picks the set of packages to install/remove when a user requests something. So, for example, if the user asks for Firefox to be installed, the “depsolver” is the thing which figures out which other packages Firefox needs in order to work. On occasion, there is more than one possible solution – an obvious example often being language packs; applications usually need at least one language installed, but they don’t care which.

I don’t particularly have much skin in this particular game; but what I would note is that I find it particularly bizarre that this task is delegated to an algorithm. What we’re saying, basically, is that the configuration of a given installation is chosen by a bit of software. So long as the various package requirements – which could be library versions, files, or something entirely synthetic – are all met, the configuration is “valid”. Of course, that doesn’t necessarily mean it works – it may be totally untested by anyone else, and things get particularly grizzly if you’re doing something “fun”. Such fun includes:

  • deploying “multi-arch” packages. Maybe you want a 32-bit browser plugin on your 64-bit PC, for example;
  • installing third-party packages. Maybe it’s RPM Fusion, maybe it’s an ISV – but where-ever it’s from, it’s another set of variables the depsolvers looks at;
  • installing your own packages. See above.

The package management system doesn’t have a concept of “OS” and “other stuff”. Being able to override such a concept would be a feature; not having it is not a feature however.

Now, fans of package management frequently tout the many benefits, and they are indeed multiple. It makes it easy to install new software and be reasonably sure it works (it may need a lot of configuration, though). Splitting stuff up into a thousand different bits makes security updates more straightforward (at least, in theory – see later). But in general, to conflate all these issues is a bit of a mistake: there are other forms of installation system which provide these benefits as well.

So, what’s wrong with this? We’ve already seen that the choice of depsolver can potentially make or break the system, or at least lead to configurations which were not intended by the packagers, but to some extent that could be solved by tightening the specification/package dependencies, so that the “right choice” is obvious and algorithm-independent. But, there are other issues.

It’s difficult to estimate the number of Fedora users, but the statistics wiki page makes a reasonable effort. And looking at that, we can see that about 28 million installs of almost 34 million (that are connecting for software updates) are currently using unsupported releases of Fedora. That’s over 80% of installs using a release which is no longer supported.

This of course has security implications, because these users are no longer getting security updates. No matter how fancy the package management, these people are all on their own. And unfortunately, the package management tools are not much use here: effectively, unless you use the installer in one of its guises, the procedure is difficult and potentially error prone.

You’re also out of luck with third-party repos: the package manager doesn’t insulate them from each other, so mixing is frowned upon. It may work, it may not. You may be able to upgrade, you may not. It may alter core functionality like your video driver, and you might be able to downgrade if it failed, but let’s hope it didn’t manually fiddle with things.

In the meantime, we’re also failing to deal adequately with many types of software. The Firefox update process causes enough problems with the current setup; Google’s Chromium on the other hand appears to be almost entirely impervious to being packaged in a Fedora-acceptable way. Web applications also don’t work well; Javascript libraries don’t fit well/at all into the concept of libraries a la rpm, so there’s loads of duplication.

There’s probably an awful lot more that can be written on this topic, and of course package management right now, for the most part, works pretty well. But I worry that it’s a concept which has pretty much had its day.

Speculation on Google’s “Dart”

Just yesterday people jumped on the biographies and abstract for a talk at goto: the Keynote is Google’s first public information on Dart, a “structured programming language for the world-wide web”. Beyond knowing a couple of the engineers involved – which allows a certain amount of inference to take place – there’s also some speculation that Dart is what this “Future of Javascript” email referred to as “Dash” (this seems entirely possible: a dash language already exists; Google already used ‘Dart’ for an advertising product but have since stopped using that name, potentially to make way for the language).

I thought it would be interesting to have a look at some of the details of this new language. One thing seems quite certain: Google’s Javascript engine, V8, is going to target this, because it’s going to target client-side application programming to begin with. V8 is, of course, very popular – it’s in Chrome, it’s in Node.js, it’s going to be put in Qt. However, it hasn’t really been a brilliantly standalone project (witness the problems getting Chromium into Fedora, as an example) and the addition of Dart will almost certainly make this worse.

So, what else do we know?

Compiles to Javascript

It seems likely that the language will, at least in a proper subset, compile into Javascript – a lot like Coffeescript does. Personally, I cannot stand Coffeescript for the same reasons I really don’t like python, but there is some obvious win to this approach: you get backwards compatibility with existing systems and, usually, a method of interacting with existing code and libraries.

I suppose the first question is, how different to Javascript will it be? It will almost certainly be object-oriented, but that need not imply prototypical inheritance – it could be the Javascript compiler will do some fancy trick with object to make things appear more classical. Coffee does this to a large extent too, and I think we’ll see a similar approach. I doubt much of Coffee’s syntax would be copied – it’s almost Perl-like in its terseness sometimes – but I think there will be a similar approach to the object model.

There will be other differences. Javascript is relatively typeless, I suspect Dart will have types of some sort at least optionally. The scoping rules will probably be a bit different as well – the “let” keyword has never caught on wildly, but some level of block scoping (as an example) would be an obvious improvement.

Not just a language

I think it’s relatively clear from the “Dash” discussion that this isn’t just going to be a language: templating and possibly even MVC will be available alongside, some how. I expect to see some interesting things here, actually – there might not be much impact on the language (although a way of embedding HTML templates might be handled specially) but I think it will be closely aligned to these key tools. The Javascript world has been doing some interesting stuff – see Backbone.js and Knockout.js as two obvious examples – but it will be really interesting to see how much “platform” is put into Dart.

There is a worry here, of course, that it’s too restrictive. Knockout is actually a great example: it’s MVVM architecture, not MVC, and for a lot of jobs I’ve actually been really, really impressed with it. It’s simple, straightforward, but most of all productive. It would be a shame if you can’t do something similar in Dart, but I would bet you can. Binding data onto a web page is so fundamental, so basic, that I really think there will be some interesting stuff there.

Binary Dart?

I’m not really sure about this, but I’ll chuck it out there anyway: clearly, writing Dart in a text editor is going to be fine. However, I also expect that there would be alternative delivery mechanisms. Right now, people use tools like Closure to “compile” Javascript into a more compact representation. Clearly, if you’re starting with a new language, you could specify a binary format right from the start. This would also sit beside NaCl/Pepper quite nicely, and allow multiple resources to be included into a project without having to have multiple file downloads into the browser.

Google are going to be focussed on deployment of large, highly-interactive apps, I think – so although the small page enhancement stuff would still be on the table, really I think Dart is going to be about writing GMail and Google Docs. In that context, being able to wrap up everything into a nice deployment package makes a whole heap of sense.

A month to wait?

Sadly, I don’t think we’re going to know too much more before goto;. I had a look around the V8 source, there aren’t really many clues in there to what’s coming. If they’re offering a compile-to-Javascript option, that might be the only thing released at first – so Dart would effectively be a standalone compiler only to begin with, growing features to target specific engines later on.

The quality of Fedora releases

Scott James Remnant blogged his ideas about how to improve the quality of Ubuntu releases recently, triggering some discussion at LWN about the topic. I offered some opinions about Ubuntu which are not terribly interesting because I don’t get to use it often; however, I did also write about Fedora based on the last couple months’ experience of Fedora 15 & 16.

Before I get to that, at roughly the same time, Doug Ledford was posting his thoughts about the “critical path” process – essentially, saying it was broken. I’m pretty sure he will find vociferous agreement with his views, based on previous feedback, but not (alas) from me.

I made a number of claims about Fedora in the LWN comments, that it is essentially unusable for anyone non-expert. I stand by this: if you use Fedora, and care about things continuing to work on an ongoing basis, you have to be entirely au fait with:

  • upgrading your distribution every six months;
  • rolling back an update (including config) when (not if) things break;
  • knowing how to distinguish which part of the stack is broken (and oh boy, this isn’t easy).

People complain about Windows “rotting” over time and getting slower, and slower. Fedora is worse than this: it works great until you get an update which blows out something critical. At that point it stops working: maybe you stop receiving updates, maybe you can’t boot it, maybe you can’t log in. I haven’t had a release yet, that I can recall, that something crucial wasn’t broken.

Of course, in Fedora, we have the critpath process, which is supposed to stop this kind of thing. And this is what Doug is complaining about, because the process which puts roadblocks in the way of updates to crucial packages naturally gets in the way of “fixes”.

This is where I depart with Doug, I suspect. I have sympathy for his situation, particularly in F16. But the point of critpath is that it does cause pain.

The issue with critpath isn’t that it gets in the way; it’s that it highlights release problems. When major issues turn up in critical packages and get through to release, it hurts – it cannot be fixed quickly. And here’s my point of disagreement: we shouldn’t allow more direct fix releases just to avoid the pain, we should address the root cause of the problem – the release of bad code.

(Interlude: as a point of order, it should probably be made clear that the specific issue Doug is facing is a lack of karma on a specific release branch with a package which, although critical, is not necessarily widely used. That’s an obvious bummer, and I’m not sure is terribly instructive about the process as a whole because of that).

There have been a variety of other solutions proposed. AutoQA is something I have a huge amount of time for, and in particular would help reduce the incidence of obvious brown paper bag bugs. It’s not a solution itself, though. Equally, there will always be stuff which evades testing – hardware support in device drivers being an obvious case in point.

I am extremely jealous, though, of the quality Debian achieves, and I say this as a Fedora user. It’s stable, it’s easily upgradable from release to release, and generally the use:surprise ratio is reassuringly high. To a large extent, I think they illustrate that the specific processes don’t really matter a huge amount: what matters is actually getting to a point where maintainers don’t release bad packages often. And to me, that is the point of critpath: to encourage packages of sufficient quality that the pain is generally avoided. Simply short-cutting the process doesn’t encourage that; it just encourages more of the same in Fedora.