The desktop and the developer
May. 18th, 2014 10:53 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I 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.
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.
mac developer working with linux
Date: 2014-05-19 05:41 pm (UTC)Slowly, over time, I've been moving my development activities over to OSX where I can code and build in Xcode. Its just too annoying to operate on the linux side. There are all sorts of little things that just don't work conveniently or at all. At this point, I only have to use Linux to build my uboot and linux kernel images. One simple example... ON OSX, I can use the Finder to navigate down to arbitrarily complex paths. I can copy the file (cmd-C), then paste into Terminal.app (cmd-V and It will put a path on the command line. On linux, when I do that, it pastes a URL. So, I have to navigate to go delete the 'file:/' at the front of each path. On top of that, I must right-click to paste for whatever reason. If you want me to use Linux, simple things like that need to just work as I would logically expect. Things like mounting and managing network shares could be a lot better. All of that should be automated with zeroconf to the degree possible. I should be able to more-often-than-not have all the dirty details automated.
This is a statement of MY experience. I'm sure I can go spelunking into text files or installing other software to do what I want. I really don't want to spend time on that sort of thing. I want to spend my time on my problem to solve. I'm not interested in infinitely "tweaking" the system. I really don't care what the filesystem browser looks like or exactly how it organizes things. I can learn new tools. I just need it to work rationally, consistently, and simply. Simple things should be simple. Dirty details should be hidden.
The worst problem you have is X11. That horrid piece of garbage needs to be retired and replaced with something that just works. One should NEVER get into a state where he can't see his UI. It should be designed so that the graphics stack auto-configures based on the hardware profile and everything comes up in some rational, default mode even if there is some configuration problem. I should not have to be afraid of installing a ubuntu software update because an x11 update with knock out my UI because of some glitch or incompatibility. This sort of thing is unheard-of on a macintosh. It requires massive catastrophic failures for a mac to become usable from the GUI.
The reason I use Apple OSes and equipment and wouldn't consider switching to a Linux desktop for daily usage is because I can count on the mac to just work and get out of my way. Yes, there are sometimes problems. Nothing is perfect, but from my experience, for desktop use, OSX is far more reliable and idiocy-tolerate than Windows or Linux. Apple does do things that irritate me, but not enough to overcome the technical irritations of Windows and Linux desktops.
I'm sure that other people's experiences vary. I'm sure there are people who loathe the OSX desktop. Again, I'm speaking for MY experience. I'm the kind of user that this blog post is targeting for conversion. If you want to convert me, this message convey's some of my expectation.
In essence, I value quality and ease-of-use over customizability.
-James G
Re: mac developer working with linux
Date: 2014-05-19 09:32 pm (UTC)> I can learn new tools.
It seems to me you are used to ^C and ^V for copy-pasting, and, illogically, you assume these are rational. It also proves, by extension, that you cannot use new tools, although you believe you do. UNIXes terminals uses ^* for, emh, process control. Conveniently, Mac's added the Cmd button -- whether that is rational is irrelevant -- to bypass this behavior and harmonize desktop and console.
Regarding the file:// schema, they are defined in RFC 1630 and 1738, and, so, complying applications would resolve them correctly. However, you are right, the default behavior should be to assume this schema when not specified, or, more simply, change the file browser you use so it does not add the file schema.
Point is, one cannot generalize and rant when there is lack of knowledge or dogmatism.
Personally I do not use a DE, but a WM (when I am not using a 80x25 terminal). I do not believe in the uniformity some you believe exist. Apple simply provides a foundation and proposes best practices around which developers can build and extend. Now the FOSS community is incapable to agree on what the API should be, nor what should be those best practices. Hence, groups build DEs, others build VMs, others target the console users. All is right and okay, usability is not an exact science. Find what suits you best, pick the tool needed for the job. If it integrates, nice, if not, nice... a tool does the job. ;)
P.S. If one cannot navigate to arbitrarily complex path with a tool, pick an axe.
Re: mac developer working with linux
Date: 2014-05-19 10:17 pm (UTC)I also have this irrational expectation that the dude who developed the terminal app should be smart enough to know that (regardless of internal representation on the clipboard) it is worthless to paste a URL into a bash shell.
Yea. In the past Six months, I've gone from zero knowledge of linux to debugging kernel drivers for embedded hardware, but I have no ability to learn tools. I have built a mac-based cross-compiler for PPC-linux, integrated it with xcode 5, set up a mechanism to build ext3 formatted SD cards on a mac, but I have no ability to learn tools. Let me tell you...anyone who can navigate, understand and modify that rats nest of old-school source code called "linux kernel" can learn whatever he wants. I just don't want to waste my time hacking a terminal app to get it work more rationally. I'll just buy apple's and spend my time doing productive instead.
With that reply, you show why linux will NEVER be competitive on the desktop. Its advocates generally don't see any need to do the things that need to be done to create an experience most people expect. Most of you have a hacker's mentality...not the mentality of a person who has to sell a product to average people.
Don't get me wrong...I have no problem with a hacker's mentality. It's perfectly fine...but it ain't gonna create a general purpose desktop that is worth having. It hasn't in how many years of trying?
Re: mac developer working with linux
Date: 2014-05-20 05:59 pm (UTC)I also have this irrational expectation that the dude who developed the terminal app should be smart enough to know that (regardless of internal representation on the clipboard) it is worthless to paste a URL into a bash shell.
ENDQUOTE
Really? I never want to "wget $pasted-URL" in my BASH shell?
You are being way too dogmatic about your specific, narrow use case being the only one that needs to be supported.
Re: mac developer working with linux
Date: 2014-05-20 11:04 pm (UTC)Anyway, to paste in most standard Linux terminals, select whatever text you wish to paste, then do shift+insert or middle click. This works in gui apps as well.
Also please do note that there are generally at least two clipboards in Linux systems -- the "selection clipboard" and the "ctrl+c" clipboard. To paste from the ctrl+c clipboard in a terminal you will have to press ctrl+shift+v, since, as stated above, ctrl+v is reserved for another function.
Re: mac developer working with linux
Date: 2014-05-23 12:49 pm (UTC)Consider the possibility that complaining about having to use a right click context menu and/or two-key keyboard shortcuts to paste, when everything in the OS consistently supports X11's middle click paste, makes you sound like the ignorant and uneducated troll you are.