Slashdot Mirror
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!"
I agree, but here's what I want:
EASE OF PROGRAMMING.
All the existing toolkits have APIs that are daunting to say the least.
TODO: Something witty here...
They have some Linux around. Little utility type functions.
At a company > 10,000 people, there is a difference between "interested" & "using" and in "we are using it for critical systems and rely on it and recommend it and tell our partners to use it."
But then, lots of large fortune 100 wall st companies have had "the future" of desktop unix years ago. They just forget the part where I could fix problems around the world without moving my chair. When admins cost more, but you needed half as many.
If anyone can make this happen it is Novell. They understand the corporate market better than anyone and can deliver corporate desktop solutions that work and have a name that people trust.
Engineering is the art of compromise.
In a vacum, this is not impressive. Is the interest in Desktop Linux due to quality of the platform, available technologies, developer friendly environment, ease of integration, or is it simply based on cost.
If its simply cost then, well, where is the pride in that? As a true propeller-head, I find winning on price, well, cheap.
Sarcasm and hyperbole are the final refuges for weak minds
Nat is always very interested in National labs.
Then I guess he's going to have a hard sell to make. After pulling a no-show with nearly 100 participants planned (most of whom are in a position to make purchasing decisions), we are certainly going to be taking any claims regarding customer service with a sizable grain of salt.
Had we given Microsoft's representative a similar opportunity, they would have crawled over broken glass with a killer fever to make the meeting.
Determination to meet the client on their terms and on their time is what makes a sale. Having a superior technology with crappy customer service will not make it.
"Rocky Rococo, at your cervix!"
If anything this just goes to show how much the average consumer cares about usability. Most consumers don't really care how usable their software is. Usability and $0.50 will get you a Snickers bar. Don't get me wrong. I think that Apple really does have the edge when it comes to making usable systems. Especially if you don't have to share documents and files with Windows users. However, when push comes to shove, consumers want "usable enough" at the lowest price, and that's not Apple.
"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."
Actually, I think you will just pile another GUI toolkit on to an already large pile, and create a new set of applications with a whole new look and feel. In particular you seem to be understating the major effort you are proposing either intentionally or unintentionally.
First off it takes a lot of work to develop a complete GUI toolkit from scratch. Once you do it then you have to migrate a large body of applications to it which is probably a larger effort than developing the toolkit in the first place. Are you planning to rewrite all the applications in GNOME and/or KDE, OpenOffice, Mozilla etc. How long do you figure that will take. It would take a long time and it would be time spent not developing the capabilities of the applications. In many respects it would be hitting a master reset on the Linux desktop and starting over, which isn't likely to lead to world domination for at least a few years.
Chances are you wont even get a majority of the developers on some of these major projects to buy in to your new toolkit, though some probably will so you will probably end up with a bunch of new splinters.
I'm just not sure what it is about GUI toolkits and window managers that exert this constant allure on geeks, compelling them to constantly develop new ones, the vast majority of which never develop critical mass.
But hey, maybe through superior uber geekness you will develop a new superior uber geek toolkit and you will be able to migrate a complete set of applications to it, and all others will be abandoned in the face of its superiority. Its just seems like something of a long shot. One thing positive I can say about this plan is it might be the only way to end the death match between GNOME and KDE.
Exactly how much time were you estimating to achieve this grand unified GUI?
@de_machina
With ever increasing Windows problems, it may be more of a hope for Linux Desktops to finally be useable enough for enterprise users, rather than genuine interest. How many non-geeks even know what the various linux desktop systems are, besides not Windows. Linux geeks know that Linux is the kernel, and nothing more, so what desktop is the Linux Desktop?
Today's Linux desktops fall over themselves trying to act similar to Windows, while having the unfortunate problem of not being even as consistent as Windows. This problem is rooted in the whole X11+Gnome+GTK+KDE+Qt+Ximian+Lestif+kitchen sink quagmire that is required to supply the pieces of this quite disjointed user experience.
In my not so humble opinion, the interest for the Linux desktop is the hope of Microsoft liberation, without scrapping existing hardware. This is quite silly, as the cost of the disruption in retraining all of the users, will far outweigh the cost of either switching to a useable, coherent UNIX desktop like Mac OS X, or staying on the MS Treadmill. Unfortunately, there is no quick fix here, as the bazaar is not willing to collaborate on a unified, coherent Linux Desktop.
-- Len
Really, have you tried Qt? It's a pretty fun toolkit in which to code. A beautiful API, IMO.
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
Hmmm, 2 open source guys dancing with the microsoft cto, am i the only one afraid? IIRC, they are the ones working on the mono project, i won't be surprised if microsoft crushes them if they finally catch up.
Please, prove me pessemistic
In my experience 10kbps is not enough to have a smooth desktop experience.
;) I'd expect any individual client to have spikes of high bandwidth usage separated by long periods of low bandwidth usage, consistent with pointing and clicking. When you combine a bunch of clients, the spikes combine too and even out to the quoted 150K/s.
Of course not. The 150K/s is probably an mean over time of all clients' usage, not a sustained transfer - if it were, Ethernet would been designed to be circuit switched like the PSTN and not packet switched
But the beauty of separating out the look and feel of the toolkit from the implementation of the toolkit via a network protocol is that porting the widget set to a new platform is now much more straightforward: you simply have to write a widget server on the target platform, which will take widget requests and display them through the native widget set.
Where you'll have to write some code is when the native widget set is missing a widget type defined by the protocol. In that event you have a couple of options: reject the protocol request, or implement the look and feel of the widget in software (using as much of the native widget set as possible, of course). You can always do the latter -- how else do you think new widget types are created on a platform such as Windows?
No, this isn't the problem. The problem is that right now the existing widget sets under Linux all implement their own look and feel. They've duplicated a lot of effort as a result.
With a widget protocol, you implement GTK or QT the same way as before, except that whenever possible you make widget protocol calls instead of doing direct drawing, mouse handling, etc. For cases when the widget protocol doesn't supply the kind of widget you want, you'll have to implement the look/feel in terms of more primitive graphics calls (and thus the widget protocol will have to support the ability to do direct graphics, including 3D graphics) -- but even that should be done on top of existing widgets whenever possible.
There might be other ways to approach the problem of extensibility, e.g. by making it possible to dynamically define to the widget server the properties of a widget: the inputs it expects, the areas that have to be drawn on, etc. But I haven't thought any of that through.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.