Friedman on Linux Desktop Expectations

An anonymous reader writes "SearchEnterpriseLinux.com is featuring an interview with Novell/Ximian's Nat Friedman on the increasing interest about the Linux desktop. Quote from the interview - "A day doesn't go by when I don't talk to a Fortune 1000 customer from the financial services market, automotives or others that are not looking at dipping their feet into the Linux desktop." And by the way, both Nat Friedman and Miguel de Icaza's April 12th blog entry have a picture of Miguel and Nat dancing with David Vaskevitch, CTO of Microsoft. Now that's something you don't get to see everyday!"

Comments

We need a new toolkit...

[kcbrown]

I sent this in response to this, but I think it's quite relevant here, too, because it addresses the problem of desktop consistency:

Btw, if you have been following my posts on my blog and on the desktop-devel-list, you will know that my feeling is that all of the existing toolkits today (Gtk, Qt, XUL and VCL) will become obsolete and we need to start looking at the next generation toolkit system.

If you're going to do a next generation toolkit system, then do it right: start by creating a network protocol for it.

You heard me right. The right way to do a toolkit is to make it networkable in a client/server fashion. There are a few reasons for doing so:

1. Speed over the network. Instead of having to transmit low-level graphics primitives, you now only have to transmit higher-level widget information. This should represent an order of magnitude reduction in the amount of network traffic required. It also means the bandwidth between the code that draws the widget and the code that renders it will likely be as high as possible (a local socket or some such).

2. Consistency. With a client/server widget architecture, all applications running anywhere will have the same look and feel when they're displaying through your widget server. Additionally, changing the theme in use will change the look and feel of all the applications using the widget server (which, ideally, should be all of them).

3. Abstraction. Because the widgets are implemented on top of a protocol, widget libraries simply have to all talk the same protocol. This means that it doesn't matter what the widget library itself looks like, what language it's implemented in, what object paradigm it uses, or anything else: the look and feel will still be the same. This is markedly different from the current situation with GTK, QT, and all other Unix widget sets, each of which implements its own look and feel. A client/server architecture can, and should, abstract out the look and feel of the widget set.

Do it that way and I think it's likely that you'll finally eliminate the one big problem on the Unix desktop: the disparity in look and feel between applications written for different widget toolkits.

Re:We need a new toolkit...

[pdamoc]

we don't need another hero (toolkit)!
It is not the toolkit that is needed but a shift in programmers mentality. We should stop wasting time and use the wisdom of people whom are way better than us at this. We should use PATTERNS. Like MVC for example. When applications will have all the code separated in Models, Views and Controllers toolkits will become irrelevant because as long as you can access the model you can create your own Views and Controllers. The use of higher level languages should be encouraged. The higher the language the easier is to understand the program and so more people can get involved. The cross-platform issue will fade due to the fact that there are already a lot of great cross-platform toolkits in which the View-Controller part can be implemented (scripted.
The separation of the Model will have yet another benefit, no more reinvention of the wheel, at least in some parts. It could be highly optimized due to the fact that such an approach will encourage only one instance of the model per functionality. No more complex compiling schemes: script the interface (View-Controller) in python and compile only the model or provide it as a binary: .so, .dll, whatever.

quite simply ...

[Neuropol]

people will expect things to 'just work'. email, spreadsheet, document editing, and other office functions are all well covered on the desktop.

it's the little things that will get people turned off fast: like browser plugin integration, javascript issues, etc. even though MozillaFirebird(rip), and the like, are great for allowing instant plugin installation, there is yet a large hole for media plugin usage considering all of the formats that microsoft and mac have floating around. this is a current limitation, imo. not necessarily a negative on the linux part, but an obstacle created by microsoft and other companies that continues get in the way of total success. that's potentially a major issue and a lot to overcome. i think it's possible to break the stigma regarding linux on teh desktop. it's come miles in the last few years. on the path it follows now, it will over come the general fear that it just doesn't do what windows can. because it can. time has brough a lot of things closer to completion. hardware compatibilty is no longer an issue if you are running current distributions and licensing is an age old argument but if you're in to function for a small fee then why not?

personally, i'm waiting for the linux desktop that comes loaded with enlightenment (absolutely manadatory!), and all things audio editing, and every funky/odd thing that was available in the rh7.3 stage of development. then i will be satisfied.

Basics tasks & understanding of the UI (on any

[zymurgyboy]

Friedman: The No. 1 misconception is that usability is a major barrier to adoption and that's not true. It used to be. There was a study done recently with a group of 20 users who had never used a computer before. Ten were put at a Windows PC, 10 at a Linux PC and they were given a list of simple tasks like sending an e-mail, surfing to a Web page and the usability results were pretty much the same.

Yes! This is so true. A lot of users I've had to support over the years have trouble doing the very basic tasks Mr. Friedman describes. Why would it make any difference which desktop OS they get minimal training on to do these tasks with?

If serious inroads are ever made in the US the argument for staying with Windows for compatibilty with clients or customers would fade pretty quick, weather this happens with Linux- or OS X- or whatever-on-the-desktop.

Even more likely to take off if more people start using Apple's at home. They're less afraid of this when things they make with their computer are as useful at work as they are in their livingrooms.

Ximian Bails Out

[geomon]

"A day doesn't go by when I don't talk to a Fortune 1000 customer..."

Not *exactly* true.

We had Nat scheduled to show up and he blew us off. I was left standing in a conference room for nearly 1/2 hour telling participants that I was sorry that Ximian bailed on us.

I had to apologize for their no-show. Not a great feeling.

Guess a national laboratory isn't the market segment Ximian was interested in.

X works just fine thank you

[codepunk]

I dont seem to be having much in the way of bandwidth problems running 150 desktops off of a single server. It takes about 150 k sustained bandwidth to suppor that. Now come back when you know what you are talking about.

I guess you've never used Mandrake Linux, then?

[leonbrooks]

Neither my wife nor my SIL know how to mount stuff, wife would be aghast at the thought of having to type unrepresentative mumbo-jumbo into an unresponsive black window (or, heaven help us, a text screen - which she calls "dos"). It Just Works(tm). The coloured bar graph in K3B is a lifesaver when SWMBO is building CDs to go, the raw numbers would only be confusing. As an artist or musician, she excels, but sit her in front of a command prompt and terror reigns supreme.

On package management

[harikiri]

I had a workmate come up today and start explaining what his issues were with Linux. This guy is a network engineer, who recognises the usefulness of having a free unix system to use on his spare pc's.

His beef was that he had installed Mandrake 9.2 on his system, and went to setup NTP. NTP was not installed. So he started looking for an RPM (he knew what they were!) for NTP for Mandrake. He said that he found one (probably from rpmsearch), but that when he downloaded it - it had additional dependencies that he couldn't find.

Now if it was me, I would've first tried rpmdrake (the distribution's own package management tool), and failing that, built it from source. But this guy was looking at Linux like a tool to be used. He wanted to do something simple (setup NTP), and the software wasn't installed. He found the software package for NTP online. This however required additional packages that were not immediately available. In the end he threw up his hands in disgust and stopped working on his new Linux box.

I ended up showing him a freebsd box I had here, and the ports mechanism for software installation. I then also discussed apt and the problem of too many ways of managing software installations, and none (that he could find) that accomplished the job for him.

So I'm going to bring in a copy of Mandrake 10 community edition for him to try out. In the meantime, I'm waiting for him to wander over one day and say "gosh Linux is great, I installed it and setup NTP in a few button clicks..."