mjg59 | The desktop and the developer

Entry tags:

advogato,
fedora

The desktop and the developer

I was at the OpenStack Summit this week. The overwhelming majority of OpenStack deployments are Linux-based, yet the most popular laptop vendor (by a long way) at the conference was Apple. People are writing code with the intention of deploying it on Linux, but they're doing so under an entirely different OS.

But what's really interesting is the tools they're using to do so. When I looked over people's shoulders, I saw terminals and a web browser. They're not using Macs because their development tools require them, they're using Macs because of what else they get - an aesthetically pleasing OS, iTunes and what's easily the best trackpad hardware/driver combination on the market. These are people who work on the same laptop that they use at home. They'll use it when they're commuting, either for playing videos or for getting a head start so they can leave early. They use an Apple because they don't want to use different hardware for work and pleasure.

The developers I was surrounded by aren't the same developers you'd find at a technical conference 10 years ago. They grew up in an era that's become increasingly focused on user experience, and the idea of migrating to Linux because it's more tweakable is no longer appealing. People who spend their working day making use of free software (and in many cases even contributing or maintaining free software) won't run a free software OS because doing so would require them to compromise on things that they care about. Linux would give them the same terminals and web browser, but Linux's poorer multitouch handling is enough on its own to disrupt their workflow. Moving to Linux would slow them down.

But even if we fixed all those things, why would somebody migrate? The best we'd be offering is a comparable experience with the added freedom to modify more of their software. We can probably assume that this isn't a hugely compelling advantage, because otherwise it'd probably be enough to overcome some of the functional disparity. Perhaps we need to be looking at this differently.

When we've been talking about developer experience we've tended to talk about the experience of people who are writing software targeted at our desktops, not people who are incidentally using Linux to do their development. These people don't need better API documentation. They don't need a nicer IDE. They need a desktop environment that gives them access to the services that they use on a daily basis. Right now if someone opens an issue against one of their bugs, they'll get an email. They'll have to click through that in order to get to a webpage that lets them indicate that they've accepted the bug. If they know that the bug's already fixed in another branch, they'll probably need to switch to github in order to find the commit that contains the bug number that fixed it, switch back to their issue tracker and then paste that in and mark it as a duplicate. It's tedious. It's annoying. It's distracting.

If the desktop had built-in awareness of the issue tracker then they could be presented with relevant information and options without having to click through two separate applications. If git commits were locally indexed, the developer could find the relevant commit without having to move back to a web browser or open a new terminal to find the local checkout. A simple task that currently involves multiple context switches could be made significantly faster.

That's a simple example. The problem goes deeper. The use of web services for managing various parts of the development process removes the need for companies to maintain their own infrastructure, but in the process it tends to force developers to bounce between multiple websites that have different UIs and no straightforward means of sharing information. Time is lost to this. It makes developers unhappy.

A combination of improved desktop polish and spending effort on optimising developer workflows would stand a real chance of luring these developers away from OS X with the promise that they'd spend less time fighting web browsers, leaving them more time to get on with development. It would also help differentiate Linux from proprietary alternatives - Apple and Microsoft may spend significant amounts of effort on improving developer tooling, but they're mostly doing so for developers who are targeting their platforms. A desktop environment that made it easier to perform generic development would be a unique selling point.

I spoke to various people about this during the Summit, and it was heartening to hear that there are people who are already thinking about this and hoping to improve things. I'm looking forward to that, but I also hope that there'll be wider interest in figuring out how we can make things easier for developers without compromising other users. It seems like an interesting challenge.

Flat | Top-Level Comments Only

It's worth noting that in many significant ways, Linux is not, practically speaking, more tweakable. Have you ever mapped out the sequence of steps it would take to go from "I'm using OpenOffice and I'd like to turn this button blue" to actually doing so?

Despite being somewhat neglected in the gold-rush of mobile everything, the automation tools on OS X, by contrast, are phenomenal.

Here's a practical example. On Linux, if I want to ask Chrome to tell me what URL is displayed in the current window... I'm not even sure what I can do. I guess there might be some kind of IPC I could do to, like, an extension or something? I could write a bunch of JavaScript? I mean, I'm not just saying this off the cuff - I spent about a week trying to figure it out at one point. The only thing I really learned was that if I were able to make it happen, absolutely nothing about that learning process would translate to getting the URL out of Firefox or Konqueror.

By contrast, if I want to do that on the Mac, I just pop open a Python (or Ruby, or AppleScript, or ObjC) and do this:

>>> from ScriptingBridge import SBApplication
>>> SBApplication.applicationWithBundleIdentifier_("com.google.chrome")
<GoogleChromeApplication @0x7feaddf58b10: application "Google Chrome" (303)>
>>> chrome = _
>>> windows = chrome.windows()
>>> list(windows)
[<GoogleChromeWindow @0x7feadd996b30: GoogleChromeWindow 0 of application "Googl
e Chrome" (303)>]
>>> windows[0]
<GoogleChromeWindow @0x7feadddeecd0: GoogleChromeWindow 0 of application "Google
Chrome" (303)>
>>> win = windows[0]
>>> tab = win.tabs()[0]
>>> tab.URL()
u'http://mjg59.dreamwidth.org/31714.html?mode=reply'
>>>

This was a literal interactive session that I did as I was writing this reply to prove the point. A couple of experimental tracebacks are elided, but otherwise this is actually what I did, and it took under a minute.

With BPython or IPython I get interactive tab-completion of the relevant method names. With AppleScript Editor, I can get nice HTML documentation of the various scripting objects present in applications.

I am rooting for the Linux desktop, I really am. But while Linux gives me the legal right to modify my environment in arbitrary ways, OS X gives me the practical agency to do so in useful ways.

Have you looked into using LDTP for non-testing purposes? (It's a functional test framework for GUIs which uses the accessibility APIs to implement AppleScript-like robust programmatic scriptability of GUI widgets)

I haven't had time to try it yet but I get the impression it should be possible and should produce an experience similar to your example session.

The difference is that the day your "practical agency" becomes strategically unimportant to Apple, they will simply revoke it. You compute this way at Apple's grace.

The appleevent infrastructure is 20 years old or more.

Substitute Gnome for Apple and you have one of the major problems with Linux today.

Changing legal terms and conditions is just one way of revoking my access. I'm not comfortable with the dystopian legal infrastructure that Apple's business rests on top of, but again, practically speaking, the GNOME cascade of attention-deficit teenagers has broken all of my code and forced me to upgrade literally orders of magnitude more than Apple has. When I switched back to OS X in 2009, the bits of random automation that I wrote in 2003 for using OS X was still working just fine (some of it even reaching back as far as the NeXTSTEP days!)

Of course, I could, legally speaking, spend literally all of my time maintaining a fork of GNOME 1.4 instead of just using the perfectly functional and useful software that Apple has provided me.

Basically, this anonymous comment is exactly everything that is wrong with the Linux desktop community: while your point is correct, it is also totally worthless, and you have deliberately ignored the entire substance of what I was saying to score some arbitrary rhetorical points in an argument you're having only with yourself.

(By contrast, I thought that the original post by mjg was actually very insightful, and pretty much all of his work has been on real, substantive stuff that is keeping people off of Linux as a desktop platform.)

((This post composed on a Mac.))

Yours are some of the points I often make, but there seems to be zero interest in resolving these harder problems.
Aside from those issues, you get both better battery life with osx and a more stable yet snappier DE.

Please tell me how to disable the global menu bar or remove the dock in OSX. Then we'll talk about customization.

He mentioned "useful" for a reason. Removing menu bar is not, by any means.

It is. I don't like global menus, I want menus inside windows. That's one of the reasons I don't use Macs and Unity. Another one is the dock. If Apple let me choose another UI I might consider their laptops.

What we want is quite obviously GNUStep.

Hear hear!

Anyone who has tried to maintain a nontrivial GNU/Linux desktop application for 5+ years, especially outside of the DE ivory towers, knows exactly why the the GNU/Linux desktop is still not viable.

I like Matt's idea's but it's a cart before the horse. The horse is long-term work on accessibility, consistency, documentation, and API stability.

Yes.

Since I am, as I said, someone who cares a great deal about the success of Linux on the desktop, and actual free-desktop linux (not Android) on mobile, Let me emphasize this:

1. API stability.

Please, somebody, get them to STOP SCREWING AROUND WITH THE DESKTOP API. Staple every GNOME contributor's eyeballs open and make them read Raymond Chen's blog for one hundred consecutive hours.

Give up on Wayland. Give up on Mir. Xorg is fine, just please make it work right. Stop changing the init system. (OK, SystemD is actually a really good idea, but seriously, once that's in there, stop it.) Stop changing the window manager. Stop changing the way the control panel is laid out. Stop changing the way network manager works. Just fix bugs for five or six years and then we can talk about maybe adding some crazy new whiz-bang stuff.

If you are going to screw around with some new display system, stop telling people about it and just work on it quietly in the background with the graphics community until it's ready. Make sure there is a totally seamless upgrade path from X11 that doesn't go away for at least 10 years. Work with ISVs like game developers to make sure it handles the stuff they care about - SteamOS is about to be the biggest deployment of desktop linux in just about ever, and it looks like they seriously do not care a whit about these fancy new graphics things despite being substantially more concerned than the average distributor about graphics performance.

2. Basic functionality.

Make a sound API that works. Make a sound API that stays supported for two major versions of at least *one* distro. Make a sound API that can play sounds through more than one device.

Make suspend work.

Include proprietary graphics drivers out of the box, if that's what getting graphics cards to work is going to take. Ideological purity should be an option during the install that defaults to off, not something you have to disable so that you can avoid kernel crashes when launching OpenOffice.

Well, the Xorg development community seems to think that it is not "fine" in a medium to long term context.

Wouldn't it be plausible that they, being the creators and maintainers, are in a position to judge that correctly?

Regarding your point of working in secret, that is rather hard to do in any non-closed non-secret community.

But if you know about a open method to keep communicating with just developers, without any users or the media seeing any of that communication, I am sure quite a lot of development communities would like to hear about it.

The issue with proprietary drivers is most often a legal one rather than an ideological one.
While some distributions will also avoid shipping proprietary code for ideological reason, there are several which do not and still do not ship proprietary drivers.

But maybe the distributors' legal counsels are just the wrong people to judge that

Re: Xorg development community:

1. [citation needed]. I've spoken with folks in that community who seem to think everything is OK, which seems to be the null hypothesis.
2. No they're not. The "creators and maintainers" of GNOME royally screwed up its API compatibility at least 3 times now.
3. I didn't say "work in secret". I said "stop telling people about it". Perhaps I should have been clearer: it's fine to tell people you're working on it, it's not fine to tell people that you're going to pull the rug out from under them and replace working infrastructure with some crazy new science experiment which is not even barely functional yet. Especially if you just gave up on a similar project which didn't work out. It's open source, just say "we're trying to come up with something which could, in a couple of years, replace the display subsystem; but don't worry, ISVs, there's nothing you have to do to prepare for this, we won't make it the default until it's ready".

The legal issues with proprietary drivers are eminently possible to work out. Send someone over to nvidia. Do you really think they're going to say "no, you absolutely may not ship our zero cost drivers to your multi-million-user market, because then they might actually have a good experience with our hardware out of the box"? They won't open-source stuff (mostly, in my understanding, due to patent concerns) but unless I severely misunderstand the way this stuff works, they'd be falling over themselves to get drivers included in a distro.

As far as legal counsel telling people not to even attempt to distribute proprietary drivers - again, [citation needed].

ad 1: https://www.youtube.com/watch?v=RIctzAQOe44

ad 2: creators and maintainers in the context of Xorg was referring to the creators and maintainers of Xorg, not some random other project

ad 3: nobody claims they are "pulling the rug from underneath" anyone. Especially in the context of Wayland, the communication is very clear that this is ongoing work, that current infrastructure is maintained in parallel to that work and that there is a lot of work also put into compatibility for early adopters and, later on, unmaintained legacy applications.

In other words the developers do exactly what you suggest they do.

ad 4: "Send someone over to nvidia."

You are right! Man, why did never anyone ever think about that?! Those managers and legal experts must be really dumb to have not been able to devise such a simple solution.

"unless I severely misunderstand the way this stuff works"

I know it is strange, but I somehow think that this is more likely than nobody ever coming up with the idea of talking to Nvidia and Nvidia never ever coming up with the idea of talking to Linux distribution companies.

Really, do you think proprietary friendly distributions such as Ubuntu, who ship proprietary software (e.g. firmware and applications) would put extra effort into making download and installation of proprietary drivers as easy as possible if they could just ship them instead?

1: Thanks for the reference. I'll watch with interest and try to get better informed about these issues - I am commenting almost entirely based on PR announcements, which I realize is not the best technical basis for critique.

2: What I was saying about GNOME's maintainers is that they were making the wrong decisions for GNOME, not that they were making the wrong decisions for X. Therefore it's perfectly reasonable to believe that X's maintainers will make the

3: Here is one example of the rug being pulled out: http://digitizor.com/2010/11/05/ubuntu-to-ditch-x-for-wayland/

Here's a different rug being pulled out again: http://www.omgubuntu.co.uk/2013/03/canonical-announce-custom-display-server-mir-not-wayland-not-x

Neither of these are ready replacements, and it is premature to

Maybe it's just Shuttleworth who keeps doing this, and it's unfair to blame him personally for the disaster in the whole desktop ecosystem, but... well, he's highly visible.

Regarding the relationship with nvidia; OEMs manage to work out these deals, Microsoft manages to work out these deals,

ahem, "Therefore it's perfectly reasonable to believe that X's maintainers will make the same mistakes for X"

ad 2: I see and yes, it is of course possible that the Xorg community would do something similar. It is, however, a lot less likely.
One important thing to keep in mind is that the latter group's product is infrastructure and people working on such do tend to have different priorities than people working on user interfaces.

The fact that they kept a lot of legacy features working for so long inspite none of the modern toolkits needing any should be a good hint regarding their mindset.

I would put them more in the category of the likes of groups working on other services, e.g. Apache or Samba

ad 3: I think these are actually good examples of not pulling the rug.
The change of the first link did not happen because allegedly Canonical found it unlikely that the technology would become available in the timeframe they wanted.
Pulling the rug would have been more like going along with it anyway

The change announced in the second article has also been postponed due to stability concerns. Again a good example of not pulling the rug.

In either case, i.e. both for Wayland and Mir, there is built-in compatibility for applications using X, because the people involved are aware of the need for it.
In my books again a very good example of not pulling the rug

ad 4: neither OEMs nor Microsoft are anologies or counter examples, because they do not ship a kernel licensed under GPL.
As I wrote before, the problem is not unwillingness on either the distribution's or Nvidia's part, but a legal one.

Nvidia chose to use a proprietary code base for their driver which is incompatible wth the GPL used by the Linux kernel.
Nobody can distribute these two together without violating licenses.

http://www.tldp.org/HOWTO/Module-HOWTO/copyright.html
http://linux-beta.slashdot.org/story/02/11/05/0051225/gpl-issues-surrounding-commercial-device-drivers

Or from a different point of view: people have been talking to Nvidia for years, but have so far not been able to convince them to relicense the driver in a way that would allow it to be distributed together with the Linux kernel.

Flat | Top-Level Comments Only

The desktop and the developer

tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks

Re: tweaks