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.

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.

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.

1. some programmers, the “alphas”, are as much as ten times more efficient than the common programmer;
2. there are people who “get” computers, and those who don’t. Cooper splits these into “humans” and “homo logicus”. Those who don’t grok computers are destined to never be able to program;
3. there are people who are paid to cut code, and who simply can’t – they rely on auto-complete IDEs, cut’n'paste library code, etc.;

For the purposes of this post, I’ll separate between these different concepts: the “goats” (people who cannot code, at all), the “sheep” (people who code, perhaps professionally, but poorly) and the alphas. Sheep and alphas are collectively referred to as coders.

Saeed Dehnadi’s PhD homepage cropped up recently, on Hacker News I think, and mentions some tests which have had varying degrees of success in differentiating between goats and coders. Somewhat surprisingly, it’s claimed that it’s possible to administer tests to people before they have been taught to code and yet still determine whether or not they will be able to code. The tests are disturbingly simplistic, but although they involve (pseudo-)code, they’re actually designed to determine the mental models people apply to the problem, and in particularly whether people apply a consistent model.

I have to say, I remain a little bit sceptical about all of that. It reminds me of a question a lecturer once asked our class, while working on set theory: “Why to people refer to ‘∀’ as ‘upside down A’, and refer to ‘∃’ as ‘backwards E’? They’re both simply rotated π radians”. I remember thinking to myself that he obviously had little clue how the human mind approached novelty – and in particular attempt to label things with a communicable tag. “`A’ transformed with a π radians rotation about the centre point” not having quite the same ring about it. But maybe there was a point in there, somewhere, about finding single consistent models that can be re-applied.

It’s really tempting to think about this in terms of tests. This is, after all, one of the reasons vendor certification programmes came into life: to reassure employers of whatever description that the person they’re hiring to do a task with a specific product really is able to do what they say they are able to. And it does work, kind of, after a fashion. If what you need is within the narrow scope of the studies of the certification, you can be generally assured that the person does at least know the theory. However, for programming, this is a bit different – frankly, there is no such thing as “narrow scope” when you’re talking about cutting code. Some people, like Paul Graham, go as far as to say questions like “how do you pick good programmers if you’re not a programmer?” are basically unanswerable (mistake 6 in his classic list of 18 mistakes that start-ups make).

It’s also difficult to talk about how you can tell the difference between sheep and alphas (let’s pretend, for a moment, that there is no spectrum in between there – that’s probably not true, but it might be a somewhat valid simplification). How many people read Reg Braithwaite’s discussion of using FizzBuzz during interviews and didn’t recognise the picture he paints? Let me repeat here his main thesis:

“199 out of 200 applicants for every programming job can’t write code at all. I repeat: they can’t write any code whatsoever.”

He refers back to another classic, Joel Spolsky’s thoughts on the hiring process from back in 2005. So, what are all these people doing applying for jobs that they are effectively incapable of doing, and how many of these people actually end up being hired and contributing to the sheep pool? It’s difficult to know exactly why they are applying, but part of the reason has got to be the modern tools available to programmers: both the editing environments, the IDEs, and the documentation and programming resources available. Some coders will have no idea about the types of tool I’m talking about, having never used the likes of IntelliSense and visual designers.

Let me give you a clue. Take a long hard look at this abomination. Just to be really clear about what’s going on there, they have a tool which can effectively write code based on semantic guessing – the words you’ve written, the types of the variables involved, the context of the code, that kind of thing. This is like a builder using a brick-laying machine to build a house without the need of any intervening thought about such trifles as “how strong should this wall be?”, “am I putting this wall in the right place?” and even “what if I need to later put a door in here?”. Simplifying the coding process is an admirable goal, and in fact has been an ongoing process since we wrote the first assemblers to translate mnemonic instructions into machine code. However, the ideal has always been to raise the level of abstraction to the height at which it makes sense to solve the problem at hand. You don’t want to write an entire database system in assembler, it’s not really a high level enough language. But you may want to dip into assembler in specific parts. Sometimes, it will hide the details of what’s going on underneath from the programmer, and occasionally that will annoy the programmer. In general, you do not what to be writing large pieces of code where you actually have no idea of what’s going on – an alpha would never, ever stand for that; a sheep, on the other hand, would.

Jeff Atwood has another collection of thoughts on his 2007 post about coders who can’t code. The conclusion he reaches is relatively natural, based on his references and the above: you ask people to actually write some code. Amazingly, surprisingly, gob-smackingly, this still isn’t happening – even today. I could name, but won’t, places which are hiring programmers based on not much else but their claimed experiences. I know people who’ve been through such processes, and have seen such myself. Do you need to ask a question of each candidate, make them do something original? No, of course not – you could even simply ask for a sample of code and take it on trust that they wrote it. My experience on the hiring end is that it’s actually quite easy to tell whether someone wrote a piece of code or not, and the most telling piece of information is not the code itself, but the problem it solves – seeing the type of code that a candidate thought was appropriate to display actually says an awful lot about their tastes and sensibilities.

If I was doing this again right now, what would I do? Probably about the same as I did last time: ask people who turn up to do some simple tests. It’s shocking how often people with an otherwise interesting CV just totally bomb even the most simple request, but it’s nothing much more than a filter. Trying to determine higher-level skills is actually fundamentally more difficult, because the more skill you’re attempting to detect the more parochial your test necessarily becomes, to the point where you’re filtering out people who simply don’t have the exact same background / knowledge set as yourself. Much more important is the capacity to learn and apply problem-solving techniques – part of me thinks that asking them to write code in a language they’ve never seen before might be an interesting test, but it would be fantastically difficult to pitch it at the right level.

I’m going to end with a link to a discussion on StackExchange about how to detect a passionate programmer. I’m not sure I agree with much more than about 50% of it, but there are a lot of ideas in there for predictors of programming expertise. Interestingly, there are even some companies out there who claim to be able to help out in the hiring process to clear out goats and sheep. I have a lot of sympathy for people like Eric Smith who are rolling their own tests to attempt to judge skill. I have to say, though: it really shouldn’t be this hard.

(this is a deeply opinionated blog post. feel free to skip it, take it with a grain of salt, whatever.)

A lot of people are talking about this as mainly a license issue, with one commentator spelling it out: “It will be interesting to see, after the first wild set of commentary flies, which project – and which license – that various developers and corporations alike choose to actively support” (the juxtaposition of the opinion and the title of the blog is especially delicious). After all, it’s easy to see this as a license show-down: given the same code base, and two different licensing strategies, which will succeed? Sadly, it’s not really a race LibreOffice can “win”: if that project is more successful, well, they had a head-start, didn’t they.

I don’t think much of this is really relevant. I’m not sure IBM care too much about who develops the code, and I don’t think an LGPL’d code base would fundamentally stop them from shipping a proprietary product if that is what they wanted to do (it makes it harder, of course). I actually think this is all about OpenDocument Format, which is a subject virtually no-one has raised.

If you look at the OASIS TC, you can see it’s pretty obviously dominated by Oracle (was: Sun) and IBM. There are a few representatives of various other companies and open-source projects, but fundamentally this is a closed shop with a pay-to-play rule which means you have to pony up to join. The v1.2 spec – which has been used by OpenOffice.org since 2008 – has only just managed to crawl out as a committee specification, incredibly late. What this means for OpenDocument v1.2 documents as read/written by OpenOffice.org 3.0, who knows. But with Oracle fading into the sunset (sorry), large chunks like OpenFormula finally done, maybe v1.3 will actually show up on time.

So here’s where this really matters. ODF is nothing if not a stick with which to beat that other vendor. And having a large say in ODF is not really anything unless you have implementations around, and until now, OpenOffice.org has not only been a leading ODF implementation, but effectively the reference implementation of ODF. This is what IBM really want control of: this is why they’re so involved in the TC, and this is the reason for the sudden outburst of passion for OpenOffice.org (all in my opinion, obviously). They almost cannot allow LibreOffice to obtain the de facto mantle of “reference implementation”: ODF as a standard is supposed to follow implementation, and obviously IBM (and most of the rest of the TC, for that matter) have no skin in the LO game. Worse, I don’t think they want LO adding and changing features  in ways which necessarily touch ODF: imagine if it had been LO only who had released ODF1.2 support in 2008. This is a very real risk – there are still critical features missing from ODF (want CMYK support do you?!) and control of the TC alone means precious little without the reference implementation.

Is this going to be a bad thing overall? My suspicion is that this isn’t going to be a terribly short-lived fork; I think IBM’s decision to move OpenOffice.org to Apache (well, Oracle’s, but we know whose advice they were following) is going to have a long term impact. It’s already pretty easy to see how the divisiveness has taken hold:

• the AOOo project has recently discovered that OpenOffice.org used to solicit donations, and don’t sound amazingly thrilled about how it was set up. It’s quite intriguing to watch people like Rob Weir claim that the community has moved to Apache, when the people at Apache seem to have little idea about how OOo operated, where money came from, who spent it, etc. It’s a sad day when bystanders to your project (such as myself) appear to know more than the project leaders. (If someone on the Apache list could also let them know that the SPI holds c. $20k on their behalf, that might be a good idea – they don’t seem to have figured that at the time of writing). Anyway, the likelihood of you bring able to donate to one non-profit which supports both projects (as you can right now) seems to be diminishing fast.
• there’s been a lot of talk about AOOo code somehow making its way into LO. I strongly suspect this isn’t going to happen that much either: I think these projects are going to diverge must faster than people realise. LO has already moved ahead and dumped a lot of old code; by the time AOOo actually gets off the ground this will be even more so. When AOOo arrives, what core features is it going to get early on? I imagine IBM will make various “donations” – they’ve already talked about accessibility, pivot tables, file format stuff. Some of that may get pulled in, other bits (like pivot tables) is probably going to be too different. After that… I think there will be some work to integrate AOOo with other Apache projects, like POI, and Apache people are quite happy using Java. I don’t think LibreOffice will want much/any of that. It’s going to take non-IBM AOOo hackers time to get up to speed enough with the core to make interesting changes, LO will be years down the road at that point.

There’s enough momentum behind AOOo that means it’s not going away any time soon. I rather suspect there isn’t enough momentum to reach “IBM escape velocity”, and sans some rather large contributions that LO is unwilling to take (which is quite possible – even for potentially desirable stuff like the Symphony UI changes) it’s difficult to see the project making the same strides LO has. More likely, there will be various “quick wins” early in the project but not much else.

It would be interesting to see someone write a full history of StarOffice from the very beginning. It has always been a project full of potential, and one particularly important to the Linux desktop even though its main userbase is on Windows, but it’s also a particularly political project in terms of what it attempts to achieve. As such it has been turned into something of a football.

I was really pleased with the feedback on my idea for Fedora Greeters, from both established Fedora community members and not. Equally, I got feedback offline as well – and I should make it clear right now that I’m more than happy to receive such communication; the amount of trepidation shown by some I think just highlights some of the problems.

One thing which is really interesting is that much of the feedback wasn’t of the form, “Yeah, I agree, [this thing] sucks and really needs to be improved”. People decided to give me, instead, their own story – you can see a couple of them in the comments of my blog. Of course, these are just anecdotes and must be treated carefully, but I thought it was extremely interesting that people approached the issue in a manner more like, “Well, this was my experience..”

This has convinced me that a SIG in this area is, at the very least, worth of some investigation and work. So, I’ve started a wiki page properly for this, and set up an IRC channel at #fedora-welcome. I need to migrate the previous stuff I wrote, but I’ll get on that today. What I would love is for those who expressed interest in this work to contribute their ideas and experiences.

I think what’s particularly important is to work on actual problems first: what are the things which new users find tough? Seasoned members of the Fedora community, which I kind of count myself in, are probably those that would find this the most difficult to comprehend, simply because we’re furthest away from the experience of the problem.

Some of these problems are undoubtedly technical: I’ve seen a number of people totally fail to setup dual-boot systems (either with Windows or just another distro) a number of times, and it’s one of those things that is actually tough for a new user to fix once it has gone wrong. Sadly, though, it’s going to be really tough to talk about some of these things with any kind of data, though: at least initially, I suspect the SIG is going to have to work anecdotally because we really don’t have the information about what goes wrong for people (either technically, socially, or otherwise).

Part of me also wonders if part of being a welcoming community is having the ability and the resources to say goodbye to people: or, at least, see you soon. What data the community has right now – via smolt, package updates, that kind of thing – is about how people use Fedora right now. We have very little information about why people don’t use Fedora after trying it – what made them leave? What went wrong? This information is all key to a Welcome SIG, though, because really there are two classes of users we need to address:

1. those who came into the community, struggled, but stayed with it;
2. those who came into the community, struggled, and left.

I actually think those distinctions are as important, if not more important, than whether or not someone was a power-user on another O/S or a complete IT newcomer. While the Welcome SIG absolutely needs to address the needs of those in category 1), I think for it to be truly successful we have to address the group in category 2) – either bringing them back, or helping prevent them leaving in the first place.

One last thought. A couple of people asked about whether we were trying to help people who might be users, or those who might also contribute. But one commenter on my previous post, Dave S, said: “Any tool that eases the trip through the learning curve nightmare helps transform a newb into an evangelist”. I think that actually spells out the motivation in one simple, powerful statement: this SIG isn’t about getting people into Fedora and making it easier for them to use. It’s about turning that first impression into a positive experience, and have the people who come into contact with Fedora take away nothing but enthusiasm and good vibes. Even if Fedora isn’t for them, let’s make them feel positive enough that they can still recommend it to friends. And I think that’s quite a high bar to set.

Fedora, on the other hand, hasn’t really ever had much of an issue catering to “power users”. While the standard Fedora install is incredibly easy to use, for the most part people using it have a reasonable idea of what they’re doing. But it got me to thinking, is there a gap in the Fedora community, in the same way as there apparently was one in the Ubuntu?

Let me ask a simple question. If you are a new user to Fedora, are the resources helpful and is the community a welcoming place? (by “new user”, I refer only to experience of Fedora, not computing experience more generally). Allow me to chuck out a few selectively-chosen “facts” (yes, this is biased, etc.):

• the Fedora FAQ, while being high-quality, doesn’t have many metrics on frequency. It’s the number one resource listed on the “Get Help”page, and is undoubtedly a useful resource, but covers a range of different use cases and user types. I don’t think one of the frequent questions a new user “getting help” would have would be “When is the next release?”, which apparently makes the top 5.
• the link to the Docs project is also a link to high-quality information. But you get a lot of information all in one go, and the navigation isn’t amazing – for Fedora 14, the “Power Management guide” and “Musicians guide” have equal billing with the install and user guides.
• the links to online resources are numerous. Hit the Forums button, you’re given a choice of three different fora to start with, none of them “official”, and one labelled “Fedora” is really tough to navigate (and I say this as a supporter of online forums). We’re also offered IRC, which starts with a warning that you might be banned if your identd isn’t setup right (wtf) and you can’t get in until you learn IRC and register, and then a list of some probably 50 different IRC rooms. Most would pick the first on the list, #fedora – my experience there yesterday was one of name-calling and abuse as much as help. And then you have mailing lists. Again registration, again the Heinz 57 varieties.
• No knowledge base, troubleshooter or other self-help mechanism people might be used to.

I offer the above not as criticism of the various resources: everything can be improved. But, as they say, you only get to make your first impression once. Many of the resources are truly excellent, but excel mostly for existing/experienced users. So, I would make the claim that for someone who is new to Fedora, the situation isn’t great – in fact, I suspect for many, it is entirely off-putting and unreliable.

I think Fedora, as a community, needs to do something in this regard, and currently I don’t see anything. We have some great SIGs – marketing and ambassadors in particular – who do wonderful work promoting and explaining Fedora to the wider world. But there is no group currently working toward a cohesive, designed experience for new users coming to Fedora.

I’d like to suggest, then, that a Fedora Greeters SIG be set up. Please take this blog post as a request for comments: I’d like to know whether or not other people think this is needed, and if so, whether or not they’d be willing to help contribute – as part of their role in an existing SIG or specifically for this.

The over-arching goal would be to make Fedora a more welcoming community for those arriving, whether from Windows, other distros, or new to IT in general, but more specifically to present the wider Fedora project and community in a manageable and more easily understood fashion. Specific goals, though, could include:

• developing “conversion” guides for people knowledgeable about other systems, allowing them to transfer their knowledge into Fedora and understand our system. Other systems have their own jargon, and Fedora certainly has plenty of its own too – sometimes just knowing what the words mean is a barrier in itself.
• creating new support resources, or working with existing SIGs on their resources, to specifically address the needs of new users and their support requirements.
• providing more interactive “signpost help” – Fedora has many great resources that simply go unused because people don’t know they’re there.

The great thing about this is that honestly, there’s not an awful lot to do in many areas: a lot of the resources needed are already there! But there’s no co-ordination in many respects. I also think this is going to become increasingly important over the next few months and years: Fedora now has a track record of some extremely stable releases, and with other notable distributions deciding to develop a vision of the desktop which is on a trajectory away from the GNOME community the need for Fedora to be open and welcoming is more important now than ever.

Update: I’ve started a wiki page about this, to develop the ideas more fully in a more appropriate place than my blog

I said last time I would go into the file maangement side of GNOME 3 a bit more, and I think I would be right in saying that there are a number of people who think this is probably one of the weakest aspects of the release.

The first thing to say is, I vaguely surprised myself by the lack of problem in this area. If you read various reviews, the changes in accessibility to file management and the lack of desktop icons are quite often brought up as serious issues, and as a relatively heavy user of the desktop file space I imagined that this would be the thing which would hurt the most.

Turns out, it didn’t. And I don’t think I’m praising GNOME 3 here: thinking about it, what I’m actually doing is saying GNOME 2 was an awful lot less good at this than I remember. So, sure I did use the desktop file space, it because a dumping ground for current work and I would move stuff in and out of that area because it was handy to be able to jump into files that way rather than have to go navigating for them. But it turns out, I didn’t really use that as much as I thought – what I actually do is I go into applications and either use the recent lists within applications, or I go wandering from their open dialog. That, and I open up terminals and find directories manually, and then run software like geany directly from that terminal.

So, what I’m really saying is yes, it is sucky – but no, the suckiness isn’t actually that much worse than it was. Nautilus the file manager itself has not really changed that much, it’s a bit more streamlined, and it’s mainly useful for burning CDs for me. And general bits of file area cleanup, and mounting remote file systems, and that’s really about it. There’s nothing in GNOME 3 that really helps me manage this stuff properly, but this doesn’t seem to be much of an step backwards.

I’m not sure how this is going to get resolved going forwards – it clearly does need to change for the better – but what is extremely reassuring is the little peek into the design process on the GNOME wiki. On the whiteboard space is a little page about finding and reminding, which covers many of the problems I’ve talked about here. I’ve no idea if that’s the direction it will actually go in, but what is nice is seeing design decisions being taken in the context of actual research findings of people who’ve studied this area properly. I’m sure there are plenty of kick-ass designers who can come up with nice flows for this kind of thing, but call me old-fashioned: nothing beats a proper study with some real data and genuine findings.

This is a bit short and sweet. The next post I make is going to be a little bit more on the technical side, looking at the Javascript underpinnings of the system. This is extremely interesting to me: I’m a power user, and I love being able to open stuff up, tinker with it and customise it. GNOME 3 promises more toys in this regard than ever before, and my initial dabblings with GJS and the various libraries in the GNOME stack make me think that there is so much more possible in this area. There is a heck of a lot of power in the current GNOME stack, and although some people have written 3 off as a “newbie’s desktop” I think they do so at their own peril: they literally don’t know what they’re missing. Of course, it’s not all great – the documentation for the Javascript APIs is almost totally absent right now – but the potential is incredible.

First up, disclosures: I’m an extremely happy GNOME 2 user. I have a copy of Fedora 12 on my Eeepc 901 netbook, with what is now a relatively ancient version of gnome-shell on it, but to be honest the shell is little more than an interface for launching Firefox on that machine. Other than that, I’ve not really used GNOME 3 / gnome-shell in more than passing. I called this post “Drag me to shell” quite deliberately: honestly, I’m happy with GNOME 2. But, I’m somewhat forcibly trying to move myself to GNOME 3 full time. (Yes, I have seen these various KDEs and Unitys an other desktops. No, I’m not interested, and this isn’t meant to be taken as some kind of comparative to other systems. Also, I’m running this on what is to become Fedora 15, which has changed like wind blowing sand recently, so there’s stuff in here that may well change before the final GNOME 3).

When you log into a desktop for the first time, when it’s freshly installed, it kind of has this blank newness look to it. It’s a lot like new car smell, and it doesn’t tend to last very long as you install stuff, reconfigure the theme, stick files on the desktop and all that – very soon, it’s looking a bit worse for wear and you have to start tidying up things again. Now, initially, getting into GNOME 3 felt quite restrictive: there’s a few things which aren’t there, there are limited controls on how the desktop feels. But, a few days in, I’m already beginning to appreciate this – like a self-cleaning oven, that new car smell hasn’t yet gone away. It will be interesting to see if it does.

Of course, I have already installed a lot of my business apps. I need Firefox, Evolution and LibreOffice like most knowledge workers, and to be honest things really aren’t much different here. Firefox 4 is an awesome upgrade to 3, and although there isn’t much in the way of genuine GNOME integration, this is all meat and potatoes stuff. However, I also do a lot of development – both web development and “real” software – and it’s relatively crucial to me that these other things work well. I’m a keen user of MySQL Workbench for administration and schema design, and I tend to edit my code in either Geany or vim depending on the project.

Thankfully, the workflow with these apps hasn’t really changed much. Like many “enterprise” apps, Workbench presents a tabbed MDI interface with only a single window: it doesn’t really take advantage of any of the new stuff in the shell, but it doesn’t come a cropper much either. The only slight oddity is that the interface now sprouts entirely out of a “Home” tab in the most peculiar fashion:

I don’t think this is a GNOME 3 thing, it seems to be something that Workbench as acquired all on its own. Very odd, but hardly a huge issue in practice  – I just end up with an awful lot of grey space on the toolbar.

So that’s normal apps which tend to run as single windows. However, for apps that have multiple windows, I think things have improved tremendously in GNOME 3. I’ll walk through one example – using the GIMP for graphical editing – the terminal/command line being an obvious one.

Now, right off the bat, there are some nice touches in GNOME 3 that either weren’t in earlier versions or I just didn’t notice them. One thing I really appreciated was the hook up between the local MIME database and the remote list of applications available. I’d logged into my fresh install, but hadn’t yet put the GIMP on – so when I asked it to open a picture, it didn’t have that in the options though. But look what I could do from there:

The window on the left is what I got – the “which application should I open?” – but then, at the bottom, as well as showing me other apps I have available on my system, there’s also the “Find applications online” button. Click on that, and I get this new list on the right. Granted, it’s not amazingly pretty, but it basically just gave me a list of applications which fiddle with images, and right in the middle there was GIMP. Click, click, done. Excellent: I didn’t have to go all the way into add/remove applications and do a search there and come back, the workflow was really smooth.

And once you get into the GIMP things have improved again. GIMP is an MDI application as well, but gives you multiple windows, not tabs. You have a toolbar window, another window for layers, and then a window each for every image you have open. With other window managers, I have to say sometimes it was a bit of a pain to navigate around these windows using either the mouse or the keyboard.

So here’s where it starts getting good. Whether by chance or design, the toolbar opens up stuck to the top-left corner, and the layers window stuck top-right. The picture opens up in the middle. This is a really great, sensible default. But then, as you open up further windows (copying image parts between different buffers is a really common workflow for me), the new Alt-Tab switcher really starts to come into its own.

Sadly, I can’t seem to screenshot this (having to hold down Alt interferes I suppose), but as well as the application icon coming up in the switcher, the two windows appear beneath. I can click on them with the mouse if I want, or – even better – I can use the brand new (to me?) Alt-` combo (the key above tab) to cycle through the application windows. Note, it doesn’t cycle to toolbar or layers – just the actual windows I’m operating in, the images. I cannot sufficiently describe how cool Alt-` is and how it’s already becoming part of my muscle memory.

I have a feeling the window management stuff is going to be a little bit make-or-break for some people. I use workspaces a lot, and it’s crucial to me that they work well. Because of this, having to Alt-Up or Alt-Down to switch feels somewhat unnatural – I don’t know why, but the landscape of left-to-right just makes more sense. Now, I don’t yet have a dual monitor setup, and I have to say that as a power user I would imagine it would make more sense to spin workspaces up and down like a slot machine if I had screens side-by-side. But, right now, this does jar a bit.

Next post, I’m going to go into file management. Right now, I have a lot of problems in this area: as an obvious example I used the “Desktop” folder as a project space. I have scripts which would move files on and off the desktop while I was working on them. Now, Desktop as a folder still exists – but, it just doesn’t mean anything any more, and Nautilus basically prefers to be in the home directory. Accessing files through the GUI is now much more of a pain. However, I’m going to work on this and see how I feel after a week – maybe there are things I’m missing, maybe there will be new ways of doing things, maybe right now it just is that bad. Tune in for part 2 if you care.

Timing-wise, it’s quite co-incidental, but it’s enlightening (I think) to read Mark Shuttleworth’s latest “Internal competition is healthy, but depends on strong and mature leadership” alongside Mark Wilcox’s “What happened to Nokia?” of a month ago. I’m quite clearly going to side with latter-Mark on this one: internal competition is generally not healthy; in fact, in my experience, it can be of the most damaging things you can do to a group of people. That’s not to say that it’s always a bad thing – to a large extent, it works for the Linux kernel (who I think are a special case in this regard) – but in a community telling someone their contribution isn’t wanted is a hurtful thing. You can see the hurt if you read what Mark S. is saying, it’s both implicit and explicit. Internal competition isn’t a solution to this, though, of course – it’s the equivalent of taking the disagreement outside and settling it mano-a-mano, swapping one hurt for another. It’s a red meat solution, a particularly macho form of solving problems.

For me, from the outside, Gnome 3 has been an example of a particularly successful collaborative project. If you go to gnome3.org and “Try it out”, you’re not downloading a copy of Red Hat / Fedora there – it’s OpenSuse underneath, built on their rather wonderful Open Build Service. All of the design has gone on in public (Hylke’s list of designers was interesting), and as a long-term gnome-shell user (I’ve been using it regularly since Fedora 12 on my Netbook) it’s easy for me to appreciate just how much work has really gone into this system.

Of course, Gnome 3 is not going to be for everyone. That’s ok, there’s KDE (and others). This is another example of where competition isn’t really: sure, you can run the same apps in both desktop environments, but generally users of one are not going to be immensely happy in the other environment (particularly power users). They don’t compete head-to-head in that sense. In the same sense, I think that’s the same thing that happens with distros. Yes, Fedora 15 will almost certainly lose some users because of the default setup. The inclusion of Gnome 3 will irk some, the inclusion of systemd will irk others, and to a large extent it was always thus (pulseaudio, networkmanager, etc.). Again, there are other distros, the Debians, OpenSuses, and even Ubuntus of this world, and to a great extent they really don’t directly compete with each other. Sure, some people move from one to another like they’re changing underwear. I think this is why Fedora can afford to be an adventurous distro, why Debian can’t really afford to put out bad releases, etc. – each to their own.

So, how much competition is too much? Where does the line lay? I don’t think it’s easy to tell. What is clear is that the amount of drama on this issue way, way exceeds the amount it deserves. Owen Taylor has said that including “appindicators” in gnome-shell is still on the table – so in that sense, there is a bit of a fuss about nothing (of course it’s arguable, and hypothetical, that his opinion has changed on this subject).

What is really needed, though, is a much clearer vision of where the desktop ought to be going. Mark S. has said that the Gnome 3 “trajectory” is wrong and has already failed. So where should it go? Where is Unity trying to go? Mark S. has already given up on Gnome, but talks about having Unity and KDE co-ordinate closely via freedesktop.org.

I think what is sad about this is the focus on the differences by the participants. Looking from the outside, gnome-shell and Unity are incredibly similar, and have been since release. Anyone looking at screenshots can see that; they obviously have the same influences. The Unity 2D system is even implemented in QML, which is another variant of Javascript just like gnome-shell’s gjs underpinnings. I find it difficult to believe that one could not be modified without a lot of work to look/behave much like the other. This isn’t a technical dispute.